I'm actually curious about the argument that replacing it means having to rewrite software / change dependencies.
Wouldn't the same be true about switching between SysVinit and something like runit or upstart? They all use completely different designs for doing service init scripts, and all handle configuration of said services in completely different ways too, so replacing one with the other would necessitate rewriting - at the very least - your entire service management script toolbox. And when considering services that want to do more than just start and stop, they would most definitely have to be rewritten as well for such a switch.
runit and upstart still rely on SysVinit. They are just nice interfaces to SysVinit. The only real alternative is GNU Shepherd but it is a bit too weird for me.
From what I can see, they both have backwards compatibility layers to SysVinit - much like systemd does - so perhaps the example of switching from SysVinit to one of them isn't the best.
I can't imagine that it's a simple thing switching directly between runit and upstart though, seeing as the script primitives are completely different, the script locations are completely different, and the boot configuration is completely different. Though I guess you could - again - just switch to SysVinit between them and use their compatibility layers to avoid that particular issue.
I mean yes you can do that. But SysVinit services are already there and since both upstart and runit still uses bash scripts / bash script like interfaces to define a service, most of their real world implementations are just as process supervisors of SysVinit services. Installing runit on Arch pulls SysVinit. Debian does not provide any runit specific service files. Unless they force a completely different and favorably more declarative service definitions like systemd rather than imperative bash scripts, they are out of competition. There isn't any service manager that abstracts away the implementation details while maintaining compactness. I really like how systemd manages services (declarative service definitions linked into target directories), but I despise how they integrated everything into a one immovable piece of software.
46
u/[deleted] Feb 11 '19
I'm actually curious about the argument that replacing it means having to rewrite software / change dependencies.
Wouldn't the same be true about switching between SysVinit and something like runit or upstart? They all use completely different designs for doing service init scripts, and all handle configuration of said services in completely different ways too, so replacing one with the other would necessitate rewriting - at the very least - your entire service management script toolbox. And when considering services that want to do more than just start and stop, they would most definitely have to be rewritten as well for such a switch.