You can also read The problem with the anti systemd attitude.
This is not just hatred towards systemd, it can do things very well, the direction it is going isn’t great.
You can also read The problem with the anti systemd attitude.
This is not just hatred towards systemd, it can do things very well, the direction it is going isn’t great.
90% of his argument is just “UnIx PhIlOsOpHy” though. Or arguments (term used loosely) that are based on that. He keeps chanting “But systemd Is MoNoLiThIc” over and over as if that ended the discussion while handwaving away the same argument against Linux or Wayland. But somehow systemd is different. Systemd needs to be crap for some reason.
It turns out that system boot benefits from tightly integrated steps. Filesystem mounting can depend on network availability for example. Logging depends on filesystems to be mounted. The sub-systems are naturally inter-dependent. And service management and execution needs to know about all those things. Some services need networking, some need file systems, etc.
You match the design to the problem. You don’t pretend like the Unix Philosophy is some gold standard that everything must adhere to.
Honestly, I would be happy if there was a mature implementation that was practical to use and was more modular for these too. I’d argue Wayland is much better than X11 in this respect, since the Wayland protocol is much more minimalistic in its design, so I think a big reason why X was superseded was the need for removing things that had been needlessly integrated in the X server and added technical debt.
If there had been usable and working alternatives that were less monolithic at the time those were launched, and people were actually using them but had to switch due to the pressure of other bigger projects… then I’m sure there would have been criticisms too.
Imagine if someone came and proposed “graphicd”, a service that combines not just compositor & display manager but also management of priviledges (like polkit), GUI toolkit (like a Gtk/Qt replacement), password manager, terminal emulator, filebrowser, web-browser and any program that might benefit from tight integration with the GUI environment. And it used protocols and methods that are entirely incompatible with Gnome, KDE or other more modular desktop environments, but the API/ABI is so big and fast moving that it’s very hard for alternative apps to integrate well with the core of graphicd (the external API on the components is stable, but not the API between the components and the core). Then it started becoming the default everywhere, with some programs adding its specific components (and along with them, the graphicd core) as a dependency.
This is one of my pet peeves with systemd… I’ve multiple times tried to use mount units (the “systemd-native” way) but I often have always ended up just relying on either the older /etc/fstab configuration conventions or layers like gvfs and custom scripts (through the init.d-like rc.local compatibility service…) because when writting systemd units to mount conditionally remote drives that might or might not be available they sometimes (not even reproducibly) led to problems in one way or another (like sometimes slowing down my boot or even my shutdown).
The issue is that systemd is considerably more opaque and complex… so it’s hard to tell whether something is a bug in the software, an intentional behavior / quirk, something specific to particular circumstances/cases or an issue in your configuration.
And I’m not saying all of what systemd did is bad, it has advantages… but acting as if it doesn’t have problems that could be smoothed out with a different approach would not be right either… it’s not like it’s impossible to do what you are stating in a modular way, for a long time before systemd was a thing we had syslog implementations (like rsyslog) that handled structured, secure remote logging across networks without needing a monolithic init system to dictate how logging architecture should work.