The system V init approach did the job fine for a couple of decades—even if the actual service definitions were a glorified shell switch statement as you insinuate.
Canonical did their upstart thing for a couple of years that wasn’t too bad to use, personally I’m glad they ended up switching to systemd though.
All of them are worse in my experience. In a embedded context I use busybox init and if I need something more I used systemd. Systemd actually has a fairly small footprint. A few years ago I ran it on a system with 32mb of ram.
I still don’t know what people use to create services other than systemd
If you’re writing bash scripts you’re basically replicating a lot of the functionality of systemd but with larger foot guns
We can use dinit, s6, runit, and openrc.
There are more, but these are all top contenders.
I switched to dinit recently, it uses declarative service management (like systemd unit files). Very clean, fast, lightweight, and portable.
The system V init approach did the job fine for a couple of decades—even if the actual service definitions were a glorified shell switch statement as you insinuate.
Canonical did their upstart thing for a couple of years that wasn’t too bad to use, personally I’m glad they ended up switching to systemd though.
Abaci and mechanical differentiators did the job just fine for a couple centuries.
s6, dinit, openrc, BSD rc, are all alternative init systems with their own method of doing thing
Guix_SD has its own init system, Gnu shepherd
All of them are worse in my experience. In a embedded context I use busybox init and if I need something more I used systemd. Systemd actually has a fairly small footprint. A few years ago I ran it on a system with 32mb of ram.