Why systemd is winning the init wars and other things aren't

I am not seeing any justification for why these tools HAVE to be a single, monolithic tool.

> script glue

That's what shell scripts[1] are FOR - they are the minimal glue that binds the large applications together. Besides, "big brittle mess" is a matter of opinion. Are you trying to tell me that this OpenRC script is a "mess" that needs to be replaced, taken from /etc/init.d/cupsd my current desktop:

    #!/sbin/runscript
    depend() {
        use net
        need dbus
        before nfs
        after logger
    }
    start() {
        ebegin "Starting cupsd"
        checkpath -q -d -m 0755 -o root:lp /run/cups
        checkpath -q -d -m 0511 -o lp:lpadmin /run/cups/certs
        start-stop-daemon --start --quiet --exec /usr/sbin/cupsd
        eend $?
    }
    stop() {
        ebegin "Stopping cupsd"
        start-stop-daemon --stop --quiet --exec /usr/sbin/cupsd
        eend $?
    }

Yes, some scripts get much longer, because they have more complicated needs. Even in an alternate environment such as systemd, those will always be complicated.

Things like changes in power or network addresses have been handled by OpenRC just fine (note: that was opinion, and systemd is better in some cases). More important,y those requirements do not suggest a need to bind tools together into one package, thoug; instead, they suggest a well-defined API* (or ABI) is needed. In OpenRC, that is simply another runlevel that you trigger on power-plug changes, etc.

Your argument seems to be that the using many tools is too complex (even though each tool in isolation is much simpler, reduced in scope, and is likely to have fewer bugs), while tying that functionality together is faster to develop (despite makng the problems into a complex, interdependent mess). Despite being labeled an "april fools joke", RFC 1925 [2] has important wisdom. In particular, there seem to be a lot of people ignoring Truth #5:

    It is always possible to agglutinate multiple separate problems
    into a single complex interdependent solution. In most cases
    this is a bad idea.

This is really a restatement of the UNIX design philosophy. Or maybe you're prefer this version, written by some old hackers you may have heard of[3]

    Even though the UNIX system introduces a number of innovative programs and
    techniques, no single program or idea makes it work well. Instead, what makes
    it effective is the approach to programming, a philosophy of using the computer.
    Although that philosophy can't be written down in a single sentence, at its heart
    is the idea that the power of a system comes more from the relationships among
    programs than from the programs themselves. Many UNIX programs do quite trivial
    things in isolation, but, combined with other programs, become general and useful
    tools.

This idea about keeping problems separated was true when those guys wrote UNIX in the first place, it was true wen Dijkstra suggested structured programming instead of "goto", it was true when Alan Kay suggested sending Messages between Objects for yet more encapsulation, and countless other examples throughout the history of software. It is still true now.

If you're having a hard time seeing this, I suggest you re-examine the problem and ask if an API could tie the pieces together, because it probably already exist in an unspecified form.

> Finally, no one is forcing you to use a systemd based distribution.

Of course not, but the monopolistic tactics being used to vertically integrate systemd IS forcing a problem - on purpose - with various other tools such as udev and gnome.

I'm obviously going to stick to Gentoo for desktop use, but even there, the disruption caused by systemd has caused a significant mess by breaking previously-working software on purpose.

--

1: If this is merely a hatred of BourneShell/BASH, I would actually understand that as it certainly has its layers of cruft and gotcha/wtf behavior. A new Little Language[4] with special support so the standard "init script" support to make the scripts trivially small in general case could be really nice.

2: http://www.ietf.org/rfc/rfc3439.txt

3: Brian W. Kernighan, Rob Pike, "The UNIX Programming Environment"

4: http://c2.com/cgi/wiki?LittleLanguage

With kdbus (dbus in the kernel) on its way it is largely moot anyway.

"Disconnecting from dbus" at that point will not be very meaningful.

Say something comes along at that point and kills systemd. Now everything below it is orphaned and has init as it's new parent.

Sysv-init does not know what to do with those processes other than reap zombies.

Now you have a system full of unmonitored processes, just as without systemd, and no standardized way of restarting the services.

This is why systemd needs to run parts of its logic in pid 1 to be most compelling.

You can launch systemd without letting it be pid 1, but you lose functionality it can't provided outside it.

In userspace the Unix way is about disconnected utilities connected by pipes, but that hasn't been uniformly true at more of the "system" level (well, GNU did originally have that philosophy all the way through, even down to the kernel, but most Unixen haven't). The BSDs, for example, generally pride themselves on tighter coupling in the core OS than Linux has traditionally had. You can swap out some components from a default FreeBSD install, mostly more application-level ones (sendmail->postfix, clang->gcc), but the base system is integrated and does things one way, supporting some customization but not every kind of wholesale surgery you might want to do on it. You certainly can't swap out the init system for another one in any kind of supported way. The same is pretty much true of most other Unixen, such as Solaris (which has a pretty integrated init system, too).

I generally like the utilities+pipes model, but for system stuff it's seemed like false advertising to me for a long time anyway: the Linux kernel is monolithic, and many of its features (like cgroups) don't make much sense unless you have some userspace counterpart configuring/arbitrating them and a uniform way of making sure everything gets set up consistently. Traditionally this is handled by a tangle of shell scripts with distribution-specific conventions to make sure they don't step on each other's feet (Debian has piles of this in Debian policy). That's a unified system in practice, because you can't really arbitrarily rewrite the init/configure/reconfigure scripts or swap things out and still have a working system that is Debian-integrated. The scripts are literally separate files on disk, but in practice they're a spaghetti-code implementation of Debian Configuration, a monolithic system that handles initialization and services and package configuration and can't be modified without extreme care if you want things to keep working in the way all the other packages (and apt, dpkg-reconfigure, the diversions system, etc.) expect.

But if systemd was pid 1 and something killed it, you would have a kernel panic. How is that better than a system with a bunch of unmonitored processes? At least with the latter you can safely bring down the system, instead of having a hard crash.