On Wed, Mar 4, 2020, at 9:42 PM, Rick Moen wrote:
> Quoting tekHedd (tekhedd@???):
>
> > Re this thread, clearly a multi-user system with a GUI does need
> > polkit and /some/ sort of dbus mechanism (which I will henceforth
> > refer to as the "dbus mechanism" as if it were some sort of doomsday
> > device).
>
> I don't think I buy that assumption, at all. Users who need access to a
> sound device can be added to the group with privileges to that sound
> advice, etc. Proper user-friendly administrative tools can front-end
> that granting of user privilege. A whole new system layer to regulate
> access to everything strikes me a solution in search of a problem.

Cool software doesn't really happen without the ability for apps to communicate and read/write the state of the system and communicate with other user level components. I maintain that at the core of each of these new annoying packages is genuine user need, combined with poor execution and massive feature creep.

And the reason for this:

- execution is actually difficult
- requirements management is more difficult

I think most people on this list would agree that the core requirements could have been/should be solved without creating a configuration nightmare and/or discarding the UNIX paradigm. I maintain that this can be accomplished by isolating the actual requirements that are the reason polkit/dbus are shipped on every system, and separating them from the "other things that these things also do".

Mind you, I'm not sure /why/ I care, maybe it's because I like using Linux. :)

> dbus as a generic object-and-message-passing mechanism seems per-se
> harmless enough, but the history of component software using a messaging
> bus (e.g., CORBA, KCOP, Microsoft's OLE) is wretched and wasteful enough

DCOM :/

Yeah, dbus is extra sad considering that it came after all that. Message systems can be handy, but I agree: the implementation was (obviously?) not driven by requirements other than that of a developer going "wouldn't it be neat if I made a thing called dbus". My hypothesis is not "dbus is needed" but rather that "projects that use dbus are /sometimes/ driven by a genuine need that is not solved elsewhere". Hmm, perhaps scraping the dbus issue tracker for past feature requirements would confirm or disprove this..

I don't know, maybe it's not a solvable problem.

t