It's a Dunning-Krugerish non-solution, sold as an init system trojan that is replacing more and more of the OS with less and less understanding of how it would need to work in order to do so effectively. It's a monolith that is almost pure attack surface, which requires the rest of the OS to change to work with it, thereby making it part of that monolith and extending the attack surface.
Every admin issue I've had over the last decade save two has been due to SystemD. I'm not opposed to change, but I'm also not going to embrace change for its own sake, particularly incompetently designed and implemented change.
Then we get to the project's social problems. But people get very defensive about that, so I'll just point out that if change is such an unalloyed good we certainly can't argue against changing away from using SystemD, can we?
> Every admin issue I've had over the last decade save two has been due to SystemD.
Do you administer systems with SysVinit as well? If not, please consider that of course the system which manages startup and background services is going to be responsible for admin issues. It is exactly the area you are responsible for administering! If yes, I'm curious how those are going in comparison. Are they less trouble?
Every admin issue I've had over the last decade save two has been due to SystemD. I'm not opposed to change, but I'm also not going to embrace change for its own sake, particularly incompetently designed and implemented change.
Then we get to the project's social problems. But people get very defensive about that, so I'll just point out that if change is such an unalloyed good we certainly can't argue against changing away from using SystemD, can we?