Systemd and The Unix Way

What follows is not for the benefit of systemd supporters. I write it because somewhere out there In the wilds of the internet, there might still be some youngster with a clue who needs to get this:

Systemd, OOP and a number of other technologies have been touted by people who have a curious mixture of cleverness and a lack of imagination or experience (something altogether too common in the world of software development). They claim that because they have solved a problem, they are therefore entitled to use the same approach to Solve All Problems Ever. So instead of exercising a little humility and moving their work ahead in a way that’s accepting of other approaches, they charge in full speed, damn the torpedoes and devil take the hindmost.

It happened with Microsoft and ActiveX. It happened with Object Oriented Programming languages – most notably with Java: there was a time when it was hard to find work programming in anything else. It happened, to a smaller degree, with design patterns. You can find numerous other examples if you search for them.

It’s happening again today with systemd.

Now, some may say that the conflict between The Unix Way and systemd’s kitchen-sink approach is a contest between equal ideologies. In other words, each represents a single thing, one of which is old and full of faults, the other of which is new and shiny and presumably lacking in faults. The only choice we have, then, is to weigh each in the balance and choose the one that’s superior.

There’s a fly in that ointment, though: You see, the Unix Way is a process, not a product. It states that it is better to take a toolkit approach – that is, chain together a series of tools that do one thing and do that one thing in a well-defined, simple manner. Systemd, on the other hand, is a particular set of services. Its implementation is antithetical to the Unix Way, because although it’s contrived out of dozens of smaller executables, they really only work when they’re chained together. You currently can’t, in other words, use journald outside of systemd (you’d have to build a completely new interface), or use systemd without journald.

The people who like systemd are willing to discard the decades of experience that brought us the awkward-but-workable Unix world, full of text files, single-purpose utilities, shims on shims on shims…. They see it as ugly and awkward and ungainly. It is all of those things. The place where they go wrong, though, is that they think they can do better in one simple stroke. They think that they’re good enough to design a system *cough* that inhabits the space between kernel and userland, and that they can do it in the course of a few short years. That’s admirable. I applaud their ambition.


But there is no way in Hell that I would let someone with that kind of confidence get within a mile of my machines. That would be Daedalus and Icarus all over again. (Google it; I’m not your nanny.) What systemd supporters fail to understand is that The Unix Way is the way of humility. It’s essentially a way of expressing our own understanding that we cannot do everything well. Therefore, we do the one thing that we can do, and we do it simply (which is not always as well as it might be, but will at least work reliably).

Empirically, systemd does things neither well enough, nor simply. For reasons that are particular to each of them, most adherents are incapable of admitting to either of those things. For example:

> [systemd’s] detractors are ridiculed as hidebound old neckbeards who don’t know any way of doing things but their own.

Its detractors rarely comment on technical merits/shortcomings, 99% of the time they only throw “pid1”, “monolitic”, “poettering blight”, “binary logs” and “they took our jerbs^wkludgy init scripts!” around.

See how the commenter rejects out of hand the complaints that too much happens at too low a level? How there’s no recognition that building a series of interlocking pieces which do not interlock with anything else except themselves, and only in a certain way can be called ‘monolithic’? How the issue of binary logs, of how logging should work generally, is tossed away as so much noise?

Now, it’s not that nobody has ever responded to these complaints. They have, and at length. The issue is that their answers have been rejected by a great many people as insufficient. But rather than show a little humility and learn a thing or two at the hands of those who are offering these criticisms, systemd devs and supporters instead treat dissent as antagonism, and indulge in name-calling (e.g. neckbeard) and such.

It’s shameful, really.

But yes, it’s happened before, and it will happen again. And those of us who are in it (init – heh) for the long haul will eventually get a modicum of sanity back once their fanaticism is ground down by reality.