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).

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.

Please be gentle and provide arguments if you think I'm talking crap :-)

============================
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


From my naïve (and slightly wary) point of view, these tasks are all
very important, but not of the same *nature*.

For example, why is there no watershed between two different services,
call them dbus_session and dbus_system, where:

- dbus_session will open a UNIX type socket
/var/run/session/<uid>/<sessionid>/dbus (/var/run/session/<uid> is
-rwx------), all the user's programs have equivalent security access to
this, so there is no need for crypto and security in dbus_session at all
(simplifies), very fast and useful for IPC, cut-and-paste etc. This
program needs to be fast because it performs tasks that happen often,
e.g. copy-paste of a large photo from gimp to e-mail. Doesn't X11 have
some really crappy IPC implementation already, and doesn't it use
/tmp/.X11-unix/X0 UNIX type socket?


- dbus_system_notification: I don't know why this must be secure. On the
one hand, you might want to limit transmitting sensitive information to
all users of the computer (e.g. "somebody put DVD "The Sound of Music"
into DVD drive 8"), but on the other hand, how are you going to
distinguish which users or even user sessions are allowed and which are
not allowed to discover this information? Anyway, my naïve idea is why
not read "man 7 unix" carefully and have some kind of group that is
allowed to connect to this "event subscription" socket, and somehow
grant those users who are actually logged in on the console or local X11
session, temporary membership of that group? (I have not tried this
myself, can you tell?)
These things probably are of a "publish-subscribe" nature so a message
bus makes sense, I guess. But then a message bus where only root can
write to it and the subscribers can only listen to it. Maybe this is
best done with an UDP INET type socket? (I don't actually know if you
can do connectionless or no-timeout one-to-many stuff over an UNIX
socket)
I suspect that the amount of data sent is really small and will fit into
1 packet, but latency might be a nuisance.

- dbus_system_command: must be highly secure. I haven't thought as much
about this one. It is silly to use crypto to talk to it over a
systemwide open socket, because that means you have an instant privilege
escalation problem on fast machines: a hacker can break into e.g. lpd
account, and do a brute force attack via the dbus system bus to shut
down the system, change the hostname, date, or whatever. The only
protection is that the correct bitstream sent to the dbus daemon needs
to be guessed.

I suspect that all of these tasks are security-critical but not
time-critical, i.e. a shutdown command doesn't matter if it takes a
whole second but it does matter that a student doesn't shut down the
workstation where another student is running a 3 month long quantum
chemical calculation (this kind of shit happens in workstation-land,
believe me).
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.

If you have read all this, a 10 for effort! :-)

Frits