The SystemD Platform:
an Unbiased Critique

There is a crying need for a rational discussion of
SystemD as well as other operating system initialization systems
that lends credence to all sides.

Introduction: We Have Far-More Urgent Duties

Let me assert at the outset that far, far more important than any manner of new or improved OS initialization system is to refactor existing code in such a way that it produces the same output for each possible input, and that saves energy.

I am very strongly of the opinion that for operating system, library, daemon, command-line or GUI application developers to do otherwise is a morally reprehensible abnegation of our responsibilities not just to our users, our employers, our investors but to humanity as a whole.

I'll explain just why, as well as how to implement such energy-saving refactoring, in some other article. That savings of energy Is Not The Matter Before The Court.

First, I'll say something good about SystemD: when it was first introduced, there was a desperate need for a new Linux init system. SystemD really does solve many quite-serious problems.

Now something bad: in the same way that Everything Looks Like A Nail, SystemD has grown and mutated into A Platform Unto Itself, as the once-minimal Java Programming Language grew and mutated into the extremely Vendor Locked-In Java Platform.

However I will not emphasis this last, as it would be unfair to The Gentle Reader to introduce my own personal biases into this work. While I shall discuss SystemD as a platform, I shall do so only in the ordinary course of our discussion.

To keep from pissing off way too many readers, I will alternate SystemD's positive and negative aspects.

Bad: SystemD is Monolithic, and So Violates The Unix Way

Last I checked, SystemD had sixty-eight separate binaries. So it's not directly monolithic as so many of the ill-informed assert.

However, the architects' effort to implement modularity was executed quite poorly, as there is a great deal of interdependency between what should be completely independent modules. This has the effect that while not a single binary as so many claim, in reality it is monolithic, or nearly so.

This problem is readily solved - at the cost of lots of refactoring - through a process known as "Lakos Levelization", as explained in John Lakos' "Large Scale C++ Software Design".

That title is unfortunate, as most of his book isn't in any way specific to C++; really Lakos would have done well to have published a language-neutral and so far more widely read volume, then a separate text with the C++-specific stuff.

To Be Continued.

One Must Not Trifle With Wizards For It Makes Us Soggy And Hard To Light