On Wed, Mar 4, 2020, at 9:42 PM, Rick Moen wrote: > Quoting tekHedd (tekh...@byteheaven.net): > > > 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 _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
