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.
Loosely yes, but I rarely see anyone expound on it beyond “It’s bloated and therefore bad”. I also rarely see specific criticisms outside of that like
journalctlbeing slow or using a binary format for log files.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.
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.