Why would a server use a different init system than a desktop or embedded device?

Why wouldn't you want unit files instead of much larger init shell scripts which duplicate logic across every service?

It also enabled a ton of event driven actions which laptops/desktops/embedded devices use.

> Because last time I wrote systemd units it looked like a job.

Fascinating. Last time I wrote a .service file I thought how muhc easier it was than a SysV init script.

I think you're way overstating things. Systemd units can be complex, but for most things they are dead simple to write.

> a multi user multi service server. The kind you're paid to maintain.

TIL. Didn't know I can get paid to maintain my PC because I have a background service that does not run as my admin user.

A systemd service can be:

  [Service]
  Type=simple
  ExecStart=/usr/bin/my-service

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.