Debian reconsiders init-system diversity

Replacing sysvinit with something better was quite difficult because there actually wasn't a single implementation of "sysvinit." It was more of an idea than a program. There was a giant ecosystem of random shell scripts and utilities and conventions and tools that parsed comments to discover ordering and a mess of problems that were solved and resolved by every package or every distribution independently (creating users, creating temporary directories, and so forth). The transition was therefore quite painful because it wasn't replacing one package with another, it was replacing a bunch of quite hairy and undocumented components with truly esoteric behavioral interactions and wildly varying implementations across distributions with a standardized set of configuration files and implementations largely shared across distributions.

I understand that some folks are not happy that this has happened, but this is largely what has happened, whatever one's feelings about whether it was a good idea.

Like systemd or not, what it's done is turn a bunch of ad-hoc, tiny programs in a full if irritating programming language into an API based on configuration files that clearly specifies what a particular program wants to have happen. This is huge, because (as someone else pointed out earlier in the comments) this makes replacing systemd far, far easier, should anyone really want to do it, than replacing sysvinit.

The point that I am trying to make is that if you believe in init system diversity, the path forward is not back to an ad hoc mess of shell scripts. This makes no sense to anyone who comes at the problem from the outside. The path forward is to recognize that systemd is giving you a great gift, namely an implementation-agnostic API which you can reimplement in a way that's transparent to the consumer of that API and then add your own unique spin to.

I'm trying to get init system diversity supporters to realize that a standardized API is a *boon* to their cause, not some sort of nefarious attack on it, because standardized APIs are exactly what permit multiple competing implementations, and because there's nothing in the API that forecloses any of the things that folks who don't like systemd are arguing for. You can implement that API perfectly well with a variety of independently-developed programs that do only one piece of the problem, for instance.

Full credit to Lennart and the rest of the systemd team for the work that they've done, but another team of people absolutely could write a new implementation of that API from scratch and possibly even do it better. It's just months and months and months of work. I agree with the idea that, all things being equal, taking advantage of the properties of free software and forking systemd rather than starting from scratch and writing all new bugs would make a lot of practical sense. But everyone reading this certainly knows that free software developers aren't necessarily practical, and sometimes that's one of the wonderful things about our community. For example, I fully expect someone to eventually write a new init system in Rust just because they can, and there's no obvious reason to start such an effort by forking systemd.

But there is an obvious reason to start that effort by implementing systemd's configuration API. Because that's what makes diversity actually practical.