> The only speed difference (which from what I can tell is the only reason anyone uses systemd)
Not even close. To the extent it improves performance, that's a nice side effect. For me, personally, it means a few lines of .service instead of a pile of init.d, service supervision when services unexpectedly exit, easy log integration to see what services are up to, and unified activation of services by a variety of means (socket, bus, path, dependency, etc).
In the long run, having a unified interface to every service on the system is a win. In the short run, we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before.
I've been a UNIX/Linux system administrator coming up on 20 years now (professionally since about '99), and I understand the pain. It's hard to break the habits of all that time; it's always worked before. In a pinch we've always been able to stick some shell commands somewhere and have it fire up the stuff we wanted to fire up.
But, it's nice to have one "thing" to ask questions of that will tell us a significant amount of data about the state of our system. It's something Windows Server has had for a long time (for Microsoft-provided core stuff; third party stuff has always sucked way worse than the state of things on Linux has ever been), and was arguably one of the (very few) reasons one might choose Windows over Linux on a server.
I have reservations about systemd. It's big, seemingly over-engineered and intrusive into places that init never went, and does some things in seemingly fragile ways (someone else mentioned that dependencies failing can lead to failure to boot, which is not something init ever really had a problem with). But, it's better than init, on nearly every axis. And, it is the new de facto standard.
So, I will learn it. I will work to make all the software I work on (which has an installed base in the millions, in the case of Webmin) work well with it. And, I'll probably even come to like it, eventually.
" we find ourselves with semi-broken, or somewhat less than ideal, tooling and interfaces and a reasonably large amount of learning friction where there was a low amount before"
Yes! Exactly! When you start breaking people's stuff that was working you will certainly not be getting compliments!
Not even close. To the extent it improves performance, that's a nice side effect. For me, personally, it means a few lines of .service instead of a pile of init.d, service supervision when services unexpectedly exit, easy log integration to see what services are up to, and unified activation of services by a variety of means (socket, bus, path, dependency, etc).