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.

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

Indeed, that criticism makes no sense at all.

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

Don't forget VMs. Even in server space, they use hotplug/hotunplug as much as traditional desktops.

> 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.