Systemd claims another unsuspecting victim
(published: 2023-07-28)
Or: How someone's progress is someone else's cancer.
Consider the following assertion:
We have a computer system with a given program/application. This application knows details about the boot process and/or initialization system, even though this application does not do power management, hardware control or boot/initialization and respective configuration. This is acceptable and normal in a sane architecture.
The question is: true, or false?
I suspect that the overwhelming majority of software developers out there would answer "false", based on the concept of loose coupling alone. In the world of systemd however, we promptly lob that out the window, "because integrayjun".
Let's take a look at one example I recently encountered in the wild:
$ sudo pacman -Su
:: Starting full system upgrade...
resolving dependencies...
warning: ignoring package systemd-libs-253.7-1
warning: cannot resolve "libsystemd", a dependency of "webkitgtk-6.0"
warning: cannot resolve "webkitgtk-6.0", a dependency of "newsflash"
:: The following package cannot be upgraded due to unresolvable
dependencies:
newsflash
:: Do you want to skip the above package for this upgrade? [y/N]
A bit of context is perhaps helpful here.
My main desktop machine runs Obarun, an Arch derivative which uses 66 and s6 in place of systemd for everything related to system initialization and service supervision. Unlike Artix, Obarun is very pedantic about keeping every single piece of software1 that depends on or is related to systemd miles away from your installation.
Obarun's repositories provide a systemd-free replacement for the most critical system components2, and your garden variety program or application can just be pulled straight from Arch's repositories without much fuss most of the time, although users are warned that this is for the "competent".
Every once in a while, Obarun's replacements for the afflicted Arch counterparts take a bit longer to bake, and it's not possible to update the system temporarily due to unresolvable dependencies. I'll take wanting to update and not being able to over having updates forcefully shoved onto my machine at the most inopportune of moments.
These occasional showstoppers are mostly minor nuisances, except for cases like the above. Why does webkitgtk-6.0, a web rendering engine/library, depend on libsystemd? Also what's going on with the PKGBUILD? I mean, where does the 6.0 come from?
In this situation, a systemd groupie might question why we're annoyed that this has happened, when we know very well that Arch is systemd-based and, as such, it is completely reasonable to have systemd as a dependency for a package, since it is always there.
But that's not the issue, Sherlock. The issue is that we're talking about a web rendering engine and an RSS feed reader.
Without much fanfare, systemd's metastatic nature claims another victim. This atrocity now has tentacles reaching almost all the way to the top of the stack. The devs have to be higher than weather balloons if they think it is ok for any of these pieces of desktop software to depend on what's supposed to be the init system when neither of them should touch power control or hardware directly, and they can't even be used unless X11 or a Wayland compositor is already running. This is certified organic fruitcake territory.
For some time the pro-systemd vs. anti-systemd debate was perhaps the mother of all long standing flame wars. It's been a while since it subsided, but only because the parties agreed to disagree. Debian was forked for this very reason: when faced with the certainty of having to use systemd instead of sysvinit on their machines, the Veteran Unix Admins said "screw it, we'll maintain it ourselves" and went their own way.
Occasionally, someone, somewhere, asks the question again: why did a significant part of Linux users oppose the widespread adoption of systemd?
Well, this (and many, many other reasons) is why. In 2023, a bloody RSS reader cannot be installed on a Linux system if systemd is not present. Please, show me the ultimate argument that justifies this, and I'll throw in the towel.
The most common arguments on the other side are usually some frivolous take along the lines of "faster boot times3", "dependency management", "declarative service files", or "finally dealing with the SysV init script mess". This is complete and utter nonsense. Not because they're falsehoods, but because those things are irrelevant in most contexts outside of desktops and big corporate. Out here in the open field, what we want is predictability, simplicity and the smallest attack surface possible. Small, simple and predictable, systemd is not.
It is, at the root, a clash of perspectives: one side sees systemd as progress, while the other side sees systemd as something between unnecessary complexity and cancer. I see it both ways. It is unnecessarily complex, and it is a type of cancer for software. Yet, it is also progress. It's just that the progress seems to be toward something I and many others don't like.
We're not just being "grumpy and stuck in the old ways". There was nothing wrong with BSD-style init and /etc/rc.conf. Nothing. It was awesome. We just want to run a system on our terms, one that we can hope to fully understand one day. Anything that gets in the way of that objective must be removed at once.
I can't help but to echo the maxim: If this is the solution, I want my problem back.
As a side note, we might want to keep an eye on the prime architect of this hot mess, as he has left RedHat and is finally with his people.
Anyway, back to my machine, and off with this annoyance. It shall be dealt with in the only appropriate way, ablation:
$ sudo pacman -Rs newsflash
checking dependencies...
:: gssdp optionally requires gtk4: gssdp-device-sniffer
:: libinput optionally requires gtk4: libinput debug-gui
Packages (5) graphene-1.10.8-1 gtk4-1:4.10.4-1 libadwaita-1:1.3.3-1
webkit2gtk-5.0-2.38.6-2 newsflash-2.2.4-1
Total Removed Size: 164.02 MiB
:: Do you want to remove these packages? [Y/n] Y
:: Processing package changes...
(1/5) removing newsflash [####################] 100%
(2/5) removing webkit2gtk-5.0 [####################] 100%
(3/5) removing libadwaita [####################] 100%
(4/5) removing gtk4 [####################] 100%
(5/5) removing graphene [####################] 100%
All feeds aboard Newsboat. And now we wait and watch, hoping to spot the next target before it's too late to save it.