KDBUS Won't Be Pushed Until The Linux 4.3 Kernel

[RahulSundaram]

Not to start a flamewar here but systemd is just as bad for being a complicated and overthought init system when SystemV has worked well for ages. Seems that keeping it simple (yet secure, I may add) has gone by the wayside.

Right. sysvinit worked so well that major distributions had already moved away from it to upstart (Ubuntu, Fedora, OpenSUSE, RHEL, SUSE etc) or openrc (Gentoo) or something else before systemd project was even announced.

[DeepDayze]

Right. sysvinit worked so well that major distributions had already moved away from it to upstart (Ubuntu, Fedora, OpenSUSE, RHEL, SUSE etc) or openrc (Gentoo) or something else before systemd project was even announced.

OK so there we have it...there's always that debate on which is the better init system

[RahulSundaram]

OK so there we have it...there's always that debate on which is the better init system

Well yes but there was broad consensus that sysvinit just didn't cut it anymore. There was debates on which alternative to sysvinit was better and for a while it looked like upstart might be the natural convergence point but the CLA was a stickler. In any case, the debate is over as far as major distributions are concerned.

[duby229]

Well yes but there was broad consensus that sysvinit just didn't cut it anymore. There was debates on which alternative to sysvinit was better and for a while it looked like upstart might be the natural convergence point but the CLA was a stickler. In any case, the debate is over as far as major distributions are concerned.

I'm pretty sure the implication is, that's terribly unfortunate.... (horribly so)

[RahulSundaram]

I'm pretty sure the implication is, that's terribly unfortunate.... (horribly so)

Yes, I am aware of your opinion. Did you have something new to add?

[Nobu]

Not to start a flamewar here but systemd is just as bad for being a complicated and overthought init system when SystemV has worked well for ages. Seems that keeping it simple (yet secure, I may add) has gone by the wayside.

Right. sysvinit worked so well that major distributions had already moved away from it to upstart (Ubuntu, Fedora, OpenSUSE, RHEL, SUSE etc) or openrc (Gentoo) or something else before systemd project was even announced.

Flamewar

That said...I've had 4-1/2 Angry Orchards in the last four hours, so I may not be completely sober yet. I'm only 130lbs, after all.

On the other hand, you could just make a library that had method calls which made reads/writes to the files...but then you still could never guarantee order, thus race conditions.

[ssokolow]

Agreed, the IPC protocols need to be kept simple yet secure and the only API should consist of read, write calls, along with a simple message passing protocol that's solid and secure. Why junk up something as important as the kernel with overly complicated IPC mechanisms when the old-style IPC (with some modernization) "just works".

KDBus is designed to be "as simple as possible and no simpler" (Einstein). Most of the D-Bus complexity you're probably thinking of is still in userspace. Most of the complexity in KDBus is concerned with security enforcement in a world that now includes things Plumber never had to deal with like cgroups.

[GreatEmerald]

Hm, yea, it looks like their early testing call did pay off, that's nice.
And hey, with all these delays, maybe we'll get KDBUS together with BFQ!

[anda_skoa]

Agreed, the IPC protocols need to be kept simple yet secure and the only API should consist of read, write calls, along with a simple message passing protocol that's solid and secure.

You also need a way to notify about file changes, to discover new services appearing, services disappearing, data becoming available for reading etc.
E.g. using inotify on Linux.

Why junk up something as important as the kernel with overly complicated IPC mechanisms when the old-style IPC (with some modernization) "just works".

One thing that is easily missed is that D-Bus does not require any kernel specific extension, while something like Plumber does.

And it is using old-style IPC (sockets) for doing that, just defining structure and semantics of data passing through the socket. A virtual file based IPC would still need parts of that, potentially some bits even in its kernel code.

However, most of the discussion on alternative mechanisms seems to be highly academic, there would need to be at least a proof of concept implementation demonstrating its viability for the use cases which applications currently handle via D-Bus.

We need to remember that D-Bus is itself a second generation IPC which successfully demonstrated its viablity as a replacement for KDE's DCOP and GNOME's CORBA usage.

Cheers,
_

[tinko]

Agreed, the IPC protocols need to be kept simple yet secure and the only API should consist of read, write calls, along with a simple message passing protocol that's solid and secure. Why junk up something as important as the kernel with overly complicated IPC mechanisms when the old-style IPC (with some modernization) "just works".

Not to start a flamewar here but systemd is just as bad for being a complicated and overthought init system when SystemV has worked well for ages. Seems that keeping it simple (yet secure, I may add) has gone by the wayside.

I'd say that dbus and systemd reduce complexity and here is my argument:

1. There is an inherent complexity in both tasks, that has to be handled, no matter what you do:
init system/service manager: dependency resolution, stopping services, killing services failing to stop, restarting services cleanly, killing services cleanly that fail to start, killing all processes that belong to a services and forked off some time ago... and a lot of stuff I didn't think of.
IPC: Send stuff fast, send stuff from 1:1 or 1:n, allow filtering of messages, allow identification of senders, allow ordering of messages and a lot of stuff I didn't think of.

2. There are two options to handle the inherent complexity
option 1: you provide simple to use tools, which are simple themselves i.e. they don't handle the complexity internally. Then you have easy to use tools but you have to handle a lot of complexity yourself. Now you have a MySQL-maintainer of distro X handling the issues of init systems which is not necessarily his field of expertise. So he writes some 3-digit-lined init script with interesting subroutines such as ( for i in `seq 1 10`; do sleep 1 kill $pid done if(notkilled) kill -KILL $pid, not a direct citation but I have seen snippets that are nearly identical). Now you have thousands of lines of init scripts for all kinds of services with tons and tons of duplication among the individual scripts and then among the distros, written by people who aren't necessarily interested into init scripts. Whenever something that's relevant to init scripts in general changes, you've got to change all of them.
All abstract init stuff like dependency resolution has to be figured out manually, for example by asking whether the stuff has started in the script and by giving the script a name that has a number in front of it and putting it into /etc/init.d (an ingenious, scalable solution, right? right?).
If you want to provide a package not through the distro maintainers repo, but through your own package you can write the init scripts for all distros and get yourself educated about possible subtle differences (terribly interesting again and not your field of expertise).
In the worst case init scripts get copied around and edited slightly without deeper understanding.

option 2: you provide hard to use tools, which are complex themself and able to handle the complexity internally. Much better solution imho, since the complexities are handle by people who specialize in init systems or at least system internals/lower layer stuff. This removes a lot of potential for bugs and bitrot but still burdens the maintainers somewhat by having to think about the complexities enough to fill in the config fields mostly with default values.

option 3: you provide easy to use tools, which are complex themself and able to handle the complexity internally. The best solution, obviously. And systemd is just that. A simple unit file has a low one-digit line count and all the standard stuff is taken care of. You can use more functionality by adding lines to the unit file, you don't have to. You'll find no example of a unit file being longer than an init script and especially you won't find any unit file that's harder to read than an bash script. Thousands of lines of init scripts can be deleted.

I don't see any way of defending SystemV vs. systemd. You're free to point out flaws in my logic.
premise 1. Systems get more complex (more service, more events one should react too, more diverse configurations, more complex interactions with services)
premise 2: That complexity has too be handled.
solution 1: With simple (as in simple feature sets) tools everyone has to handle this complexity on his own. Massive waste of time, lots of critical stuff written by people who specialise in other stuff. This approach does not scale for
- rising complexity
- more people who write apps who are not involved with the internal distro stuff (do you think some startup that writes the hip services that synchronizes your shopping list with your smart freezer, has programmers who want to learn bash?)
solution 2: With powerful (as in large features sets) tools, this complexity can be centralized. Ideally those tools are still easy to use, as in systemd, if they aren't easy to use, as in dbus, Lennart Poettering will create a new library that's easier to use.

If you believe that premise 1 is wrong for your system, I'm sorry. Why should everybody else have to deal with the growing problems of using more and more complex scripts only so that some people, who have systems that never change, don't have to learn anything new. You are free to take over the maintainership of SysV and of any init script you need and of the necessary backends of your favorite DE and so on.