> Why would a server use a different init system than a desktop or embedded device?
The futzing around with resolv.conf(5) for one.
I take to setting the immutable flag on the file given all the shenanigans that "dynamic" elements of desktop-y system software does with the file when I want the thing to never change after I install the server. (If I do need to change something (which is almost never) I'll remove/re-add the flag via Anisble's file:attr.)
Of course nowadays "init system" now also means "network settings" for some reason, and I have often have to fight between system-networkd and NetworkManager on some distros: I was very happy with interfaces(5), also because once I set the thing on install on a server, I hardly have to change it and the dynamic-y stuff is an anti-feature.
SystemD as init replacement is "fine"; SystemD as kitchen-sink-of-the-server-with-everything-tightly-coupled can get annoying.
> Why would a server use a different init system than a desktop or embedded device?
The server and desktop have a lot more disk+RAM+CPU than the embedded device, to the point that running systemd on the low end of "just enough to run Linux" would be a pain.
Outside embedded, though, it probably works uniformly enough.
Until you need to actually dive deep into complicated scenarios. In sysv init you were on your own, which could be for better or for worse. In the world of systemd you either do as LP says or you do not at all.
If this is a hard job for you well maybe get another career mate. Especially now with LLMs.
The thing to me is that services sometimes do have cause to be more complex, or more secure, or to be better managed in various ways. Over time we might find (for ex) oh actually waiting for this other service to be up and available first helps.
And if you went to run a service in the past, you never know what you are going to get. Each service that came with (for ex) Debian was it's own thing. Many forked off from one template or a other. But often forked long ago, with their own idiosyncratic threads woven in over time. Complexity emerged, and it wasn't contained, and it crrtainly wasn't normalized complexity across services: there would be dozens of services each one requiring careful staring at an init script to understand, with slightly different operational characteristics and nuance.
I find the complaints about systemd being complex almost always look at the problem in isolation. "I just want to run my (3 line) service, but I don't want to have to learn how systemd works & manages unit: this is complex!". But it ignores the sprawl of what's implied: that everyone else was out there doing whatever, and that you stumble in blind to all manners of bespoke homegrown complexity.
Systemd offers a gradient of complexity, that begins with extremely simple (but still offering impressive management and oversight), and that lets services wade into more complexity as they need. I think it is absolutely humbling and to some people an affront to see man pages with so so so many options, that it's natural to say: I don't need this, this is complex. But given how easy it is, how much great ability to see the state of the world we get that SysV never offered, given the standard shared culture tools and means, and given the divergent evolutionary chaos of everyone muddling through init scripts themselves, systemd feels vastly more contained, learnable, useful, concise, and less complex than the nightmares of old. And it has simple starting points, as shown at the top, that you can add onto and embelish onwards as you find cause to move further along the gradient of complexity, and you can do so in a simple way.
It's also incredibly awesome how many amazing tools for limiting process access, for sandboxing and securing services systemd has. The security wins can be enormous.
> Because last time I wrote systemd units it looked like a job
Last, an LLM will be able to help you with systemd, since it is common knowledge with common practice. If you really dislike having to learn anything.
Yeah, I've been using Claude and Codex to create bespoke systemd services for my random tools and automation stuff and have been really impressed by how easy it is and how rock solid they are once setup. It's really nice not living in constant terror that a reboot, network connectivity loss or gentle breeze will cause my duct taped scripts to collapse under their own weight.
That was almost 15 years ago and the support is evidently not as useful.
Also it's entirely contained within a program that creates systemd .service files. It's super easy to extract it in a separate project. I bet someone will do it very quickly if there's need.