On Wed, 25 Feb 2015 17:02:42 +0100 Godefridus Daalmans <fr...@daalmansdata.eu> wrote:
> Well, I have an idea for a discussion about "re-architecting" Linux, > however it is very likely that this is just my lack of understanding > speaking: > > I am aware that task #1 is providing Devuan Jessie (without systemd), > and that is already enough work. > > Personally I consider task #2 to do a little discovery and > documenting of what kinds of "middle-ware" I have on my Linux box and > how it all interacts (things like: what is > akonadi/nepomuk/colord/avahi and do I need all of that). My personal belief is that akonadi and nepomuk are every bit as evil as systemd. But that's not the main thrust of your post... > So I have a weird question for discussion, to study the *design* of > dbus together on this mailinglist with you lot who are probably a lot > smarter than me. I think that's a good idea, either on this mailing list or some sort of DNG SIG list. > > Please be gentle and provide arguments if you think I'm talking > crap :-) Alright, I'll be gentle. I HATE YOUR GUTS. Just kidding :-) > > ============================ > Why is there 1 dbus program (instead of 2 or 3)? > ============================ > > I have not looked at the source, but from the freedesktop.org > documentation I learned that dbus is responsible for the following > tasks in modern user-space Linux: > > 1. IPC between user programs in a GUI user session context (dbus > --session) > > 2. one-way system -> GUI session notification of events (dbus > --system), e.g. when a USB stick is inserted > > 3. one-way GUI session -> system root-privilege system commands (dbus > --system), e.g. suspend, shutdown, reboot My impression of dbus is dbus is to your OS as a global variable is to a Python program. Everybody reads it, everybody writes it, that's how everybody communicates, and if somebody gets it wrong, the results are very hard to diagnose. By the way, I try never to use global variables in my programs. Dbus afficianados will counter that dbus has addressing schemes so that process A can tell dbus it's only interested in messages from process K and process M, and that process A must name recipients when posting to dbus. OK, fine, it's more like a global object in a Python program, but things can still go wrong. And if somebody maliciously sends to dbus... I see where your 3 way division could cut down on dbus vulnerability. Theoretically, having a field in a dbus send identifying which of the 3 the send was meant to be would do the same thing, I think. [snip] > Why does this need to be a complicated and error prone message bus? > Why not just an executable? Describe it for the LSB and be done with > it: dbus_system shutdown = shutdown, dbus_system powersave = order > the CPU to slow down, etc. The preceding is waaaaay beyond my level of knowledge. I've always tried to avoid using dbus. Like you said, a discussion would be interesting. SteveT _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
