On Wed, 25 Feb 2015 17:02:42 +0100
Godefridus Daalmans <frits@???> 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