[DanielHB]

I don't get the systemd hate, as a user I find it quite nice. Centralized place all services live and I can see all the stuff I use and need. Good CLI for inspecting services and getting logs.

But like, I don't manage linux servers and stuff so I am sure it sucks in certain very specific ways for people who need to deal with it day in and out.

I remember my young days of using Slackware with init.d. That was hell.

[packetlost]

I've managed Linux systems of all sizes and don't really get it either. Systemd is largely a good thing, though there are occasionally bugs that make if frustrating to deal with.

[simoncion]

It's those bugs and weird cases (and the fact that -IME- systemd provides zero diagnostic help when you hit them) that are the killer.

In my professional experience, I've come to understand that the systemd project has an assload of accidental complexity that the systemd folks are unwilling to reduce. At least once a year, we'll have a production-down page from a customer whose root cause turns out to be systemd failing in some bizarre and entirely inscrutable way. After a ton of digging, we'll eventually find someone who has run into something similar, and either got no response, or a "Wow, that's weird. Well, there's nothing WE can or should do." response from the systemd people.

"Solving" these issues is very frustrating, because we usually end up changing things from one way that the docs indicated would work just fine, to a different way the docs indicate would work just fine... which doesn't give us any confidence that what we did won't suddenly stop working next year. A project that is as fundamental as systemd wants to be really should be aggressively reducing complexity to the minimum required to get the job done and regularly documenting caveats and quirks as they're discovered and deemed "E_WONTFIX".