"I don't know Unix, but I'll improve it."

¹

I'm a huge fan of change. Change happens. It's not always good, not always bad, but in any case it just... is. So when someone goes on a quest to make a new, modern replacement for the old init system on Linux, I am in principle all for it. This assumes several key requirements are met however:

1. The people involved have to have a solid understanding of the thing they're replacing
2. The person(s) have to develop a set of goals and requirements as well as non-goals
3. The architecture should be as modular and non-intrusive as possible
4. You should not reinvent the wheel unneccessarily (You kinda have to, replacing something existing, but you get the drift)
5. The new thing should be better than the thing it replaces

Now you probably expect me to say that Systemd is worse than System V init scripts in every way. I don't believe so. There are definite benefits to having configuration of system services work the way it does in systemd, at least in principle. For one, they are way easier to verify and harder to get wrong. And in the majority of cases they're simpler than plain shell scripts too.

This is where the praise ends. Systemd is not good software, and it is getting worse by the minute. Let's explore some of the issues:

Systemd is effectively a monolith

Helpfully, Poettering has written a blog post with the intent of dispelling this notion as a myth. The problem is he's wrong. His entire argument is that systemd consists of many binaries. "A package involving 69 individual binaries can hardly be called monolithic", he writes. Systemd is a monolith not because it's many binaries, but because almost none of these binaries can exist on their own. They require at least a base set of systemd services from pid0 to dbus to log and run services, and that's not even counting functional interdependencies. Now I understand that there is no hard border to draw, and you always depend on something, but usually that's the OS. Increasingly, systemd sees itself as being the OS itself, instead of a component. Can I run the init part of systemd without dbus? No. Can I use timesyncd on its own? No. Do most systemd services have source-dependencies to systemd? Yes. This ties neatly into the next point:

DBus is worse than what it replaces

Linux has methods for interprocess communication. They don't require any additional software or process to function. They're not without fault, but I'd argue that replacing signals and sockets - something that just works and you get basically for free - with DBus is a bad move. Especially considering that DBus uses sockets. If it's the protocol you want, you could still specify that and not require DBus. DBus works, but we've talked about "works" vs "works well" before. Don't get me started on arbitrary limits such as the 64MB message size limit. One could argue that sockets alone don't define a protocol, but that is completely missing the point. If that's the case, just define one. DBus is more than just a protocol. It is a complex codebase written in plain C, and when all is said and done, the main reason for it now is "well, it's been in for so long, it's too hard to replace now".

Bluescreen of Dumb

I won't go into too much detail here, except for this: There was a chance for the systemd BSOD to convey useful information. As it was planned, the stuff in the QR code was just the same text as the error message. And since it's systemd we're talking about, they also didn't consider that this is useless if userspace crashes. This initiative has since gone quiet, and was probably dealt the death blow by drm_panic which does not suffer from these limitations, and aims to encode actually useful information into the QR code.

Deliberate inconvenience

Have you ever changed a service configuration file and then tried to restart that service? Why is that neccessary? It's not. At least, there's no good reason for it other than, well, the developers didn't know how to deal with this otherwise. Don't get me wrong, systemd does more here than just read a file, but at the end of the day, it's a list of services with dependency relations. There is no reason for requiring a manual reload command, as there's practically nothing you can do until you initiate said reload. Try questioning such decisions on reddit for example. At best, you get an explanation of what daemon-reload does, but not why. At worst you get downvoted to oblivion. There's many such examples, like the verb-noun sequence reversal for systemctl, or how many commands are unneccessarily long and mix singular/plural arbitrarily. Heck even the tools themselves do this, there's systemctl singular, but powerprofilesctl plural.

Understanding Unix is optional

Hey remember when systemd started killing user processes on logout?. Oh wait, that was the fault of the distros because they didn't realize systemd had changed the default settings to something that no unix user would expect.

No matter how bad it is, it always gets worse

Every new release brings something odd or downright stupid. The systemd you've arranged yourself with three years ago is not the systemd you are getting with your next OS update. Systemd v258 will remove legacy System V init support. I am kind of suprised this wasn't done sooner, but it will of course hit people who perform distribution upgrades and will find some of their services no longer running.

Even today, v257 in the latest Ubuntu no longer supports utmp which actually breaks several utilities in coreutils. Except for those utilities that have started to inhale systemd code dependencies. I am aware that this was a choice made by Canonical, which may or may not have been made by mistake, but we all know that this option is first an optional setting, then it will default to utmp being disabled, and then the option will just go away for good. You know all those "this feature works if systemd support has been enabled in the build configuration" sections? They are slowly, one by one, becoming mandatory. Which brings me to...

Systemd dependencies seep in at the source level

Remember the XZ Utils Backdoor? Why was that even a thing? Because ultimately, some distributions decided to compile systemd code into openssh. Lo and behold, after this debacle, the direct code dependency was removed. A dependency that should have never been introduced in the first place, mind you.

There is no real way out

Like it or not, systemd is here to stay for the forseeable future. Yes there's systemd-free distros such as Artix but the reality is, you're probably not going to deploy those on production systems. As systemd scopecreeps into every aspect of Linux, it's becoming increasingly unlikely that users would shoulder the potential hassle of running into configuration issues or day to day problems without the massive community that now assumes you are running systemd and, in most cases, don't know anything else anymore. This too shall pass, of course. There will be a time after systemd. Hopefully with something better.