My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control. (Appart from the kernel of course). It is modular, but also dependant as a whole, so in the end, it spreads almost like an invasion, slowly leaving the admins not other option than accepting it. That's quite off from the Unix philosophy (do one thing, do it well, be really modular)... so my conclusion going back to the beggining, that didn't happen by mistake, but is a deliberate design choice, with shaddy political reasons behind it, so I reject it. And then we could talk about the convenience or not of putting such amount of tools and complexity under PID 1, the crazy binary logs, the weird behavior of the service utilities, and the possibility of being able to modify/add services using regular scripts instead of binary excutables...

It's fine when it works, but it's very hard to solve problems when they happen as it's so complex, and doing stuff outside of "the standard thing" can be difficult.

I once had "systemctl restart unbound" reset my volume, consistently. How do you even start debugging something like that without a deep dive in systemd? This particular issue turned out to be a systemd bug, and that such a bug can exist in the first place didn't exactly increase my confidence in the system.

In another case I couldn't get my NFS to work at all, and it turned out that rpcbind.service somehow went missing. Not sure how that happened and it's a simple enough problem, but it was really non-obvious because systemd doesn't issue clear errors on this and the system is so complex it's not easy to spot either.

You should know that this is a religious topic like vim vs emacs, but worse: vim and emacs users don't feel that the other side is a threat to allowing them to continue using the software they prefer.

Something I can't accept is the use of binary logs and the requirement for programs to access the contents of the logs.

Yes, most distros will put compatibility layers in place and create text "logs" in parallel. But if everyone is doing that maybe systemd's paradigm isn't right for the desktop even if it's great for servers.

> what major reasons are there for not using systemd?

    ps aux | wc -l