Systemd's fate will be decided by whether or not it works

September 7, 2014

I have recently been hearing a bunch of renewed grumbling about systemd, probably provoked by the release of RHEL 7 (with a contributing assist from the Debian decision for it and Ubuntu's decision to go along with Debian). There are calls for a boycott or moving away from systemd-using Linuxes, perhaps to FreeBSD, for example. My personal view is that such things misread the factors that will drive both sides of the decision about systemd, that will sway many people either passively for or actively against it.

What it all comes down to is that operating systems are commodities and this commodification extends to the init system. For most people, the purpose of an OS, a Linux distribution, a method of configuring the network, and an init system is to run your applications and keep your system going without causing you heartburn (ideally all of them will actually help you). For (some) management and organizations, an additional purpose is making things not their fault. Technical specifics are almost always weak influences at best.

(It is worth saying explicitly that this is as it should be. The job of computer systems is to serve the needs of the organization; they can and must be judged on how well they do that. Other factors are secondary. Note that this doesn't mean that other factors are irrelevant; in a commodity market, there may be many solutions that meet the needs and so you can choose among them based on secondary factors.)

This cuts both ways. On the one hand, it means that generally no one is really going to care if you run FreeBSD instead of Linux (or Linux X instead of Linux Y) because you want to, provided that everything keeps working or at most that things are only slightly worse from their perspective. On the other hand, it also means that most sysadmins don't care deeply about the technical specifics of what they're running provided that it works.

You can probably see where this is going. If (and only if) systemd works, most people won't care about it. Most sysadmins are not going to chuck away perfectly good RHEL 7, Debian, or Ubuntu systems on the principle that systemd is icky, especially if this requires them to step down to systems that are less attractive apart from not having systemd. In fact most sysadmins are probably only vaguely aware of systemd, especially if things just work on their systems.

On the other hand, if systemd turns out to make RHEL 7, Debian, or Ubuntu machines unstable we will see a massive pushback and revolt. No amount of blandishment from any of the powers that be can make sysadmins swallow things that give them heartburn; a glowing example of this is SELinux, which Red Hat has been trying to push on people for ages with notable lack of success. If Red Hat et al cannot make systemd work reliably and will not replace it posthaste, people will abandon them for other options that work (be those other Linuxes or FreeBSD). And if systemd works well only in some environments, only people in those environments will have the luxury of ignoring it.

That is why I say that systemd's fate will be decided by whether or not it works. If it does work, inertia means that most sysadmins will accept it because it is part of a commodity that they've already picked for other reasons and they likely don't care about the exact details of said commodity. If it doesn't work, that's just it; people will move to systems that do work in one way or another, because that's the organizational imperative (systems that don't work are expensive space heaters or paperweights).

Sidebar: The devil's advocate position

What I've written is only true in the moderate term. In the long term, systemd's fate is in the hands of both Linux distribution developers in general and the people who can write better versions of what it does. If those people are and remain dissatisfied with systemd, it's very likely to eventually get supplanted and replaced. Call this the oyster pearl story of Linux evolution, where people not so much scratch an itch (in the sense of a need) as scratch an irritation.


Comments on this page:

From 46.144.78.131 at 2014-09-08 04:27:29:

I fully agree on your systemd stance. However I disagree on the selinux one :-)

Today most users do not even notice selinux is enabled by default because it just works. Only when stuff breaks you will disable it. They are not pushing it down our throats, the initial breakage has been fixed (and I might add: a long time ago).

Their documentation on how to fix selinux problems is also very good.

By Matt Campbell at 2014-09-08 11:25:40:

You mentioned that Red Hat has been trying to push SELinux with notable lack of success. Why do you think Red Hat is doing something like this that is apparently not in (most of) its customers' best interests? Is it somehow advantageous to Red Hat for SELinux to work? Or is this a case of the engineers doing something that's not in the business's best interest?

By cks at 2014-09-08 22:00:26:

SELinux is an interesting case that I don't have a good explanation for. My impression is that at least some of the engineers involved believe passionately that SELinux is a good thing and that it can be made to work (and also that it usually works and that people like it). And SELinux half-works in that for a certain number of people it doesn't get in the way. I think it also helps a great deal that SELinux has always been made easy to disable (and that the transition to SELinux enforcing things has been very slow).

Or in short: Red Hat engineers believe passionately in SELinux and it hasn't hurt enough for commercial concerns to override them. I see this as a case of running X instead of Y because you like its technical side more and it's not too much less functionally attractive than Y is, which you can often get away with.

From 46.144.78.131 at 2014-09-09 02:46:32:

I do not think people like or dislike selinux as long as it does not get in the way. Just the same principle as systemd :-)

I do not follow your X/Y analogy. There is no alternative to selinux in redhat/fedora that gets activated unless you specifically tell it to deactivate.

My guess as to why they enable it is that some clients (financial institutions/government agencies) need to check some boxes (mandatory access control vs discretionary access control for instance) in order to white-list the use of one brand of OS vs another brand. The only way to do that is to have selinux enabled by default during the OS installation.

By Ray at 2014-09-15 05:09:03:

As far as i care, they can shove systemd somewheres.

Its fragile and brittle, and gets in the way of doing anything, because its taking over everything.

For those that like to do things, there is slackware and others that allow you to avoid rube goldberg clusterdorks.

Even linux containers/namespaces look to be getting poisoned with this malady, so you end up using a simple chroot with a few bind mounts to run an arch or other distro userspace instead of a container.. it avoids all the zombies.

that fragile brittle complexity spaghetti and interlocked interdependent shaky house of cards prevents learning for noobs, its chaff and smoke tossed in the air by those that think it makes them look smart.

Nobody forces you to use anything based on that tangle of half baked ideas, not as long as there are still KISS based bsd/init choices like slackware around,

As long as they are, we are not forced to eat the dog food.

Written on 07 September 2014.
« The kernel should not generate messages at the behest of the Internet
What an init system needs to do in the abstract »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sun Sep 7 23:17:36 2014
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.