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.
This is by far the most nuanced critique of systemd I’ve ever seen. I don’t fully agree with its conclusions personally, but I think it makes a lot of good and valid points about its architecture and its flaws. It feels like such a breath for fresh air in comparison to the most vocal anti-systemd types who vaguely and angrily gesture at “scope creep” and refuse to elaborate further.
If you think OP’s link is nuanced, try this one: https://blog.darknedgy.net/technology/2020/05/02/0/
It’s the same bullshit everyone has always bitched about.
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.