Why systemd is winning the init wars and other things aren't

Why systemd is winning the init wars and other things aren't
utcc.utoronto.ca

There's a little piece of insight which seems to escape many: there is no serious technical reason why systemd must run as init. Systemd could have been written to coexist in a number of various ways following previous models, running under init and doing things for init.

Systemd is winning this war because it created the war, by conflicting with sysv init.

And yet again, the anti-init-choice people show how they still don't understand the argument many of us have against the systemd change.

This accusation presupposes that a change was necessary or desired in the first place. Sorry, no, some of these things should not be tied together. Without that tying, we already have (known, tested) tools that cover most of these features.

Yes, I understand that some people have needs that require more (or different) features in their init process. So they should use systemd or whatever else solves those needs. Requirements and uses for general purpose computers vary a lot, though - especially in an environment like UNIX that encourages customization. My needs, for example, were mostly met by OpenRC's reworking of sysvinit. Some minor customization solved that problem completely. I recognize that some people see systemd as a good fit for their needs. Why do the anti-choice people refuse to recognize that other people might have different requirements.

Again, I'm fine with systemd, as an option. It's the bundling and takeover of all the other tools that is a large part of the problem. Blaming others because we didn't implement your made up requirements is another part. Acting like a monopoly and tying other projects together to force upgrade because of vertical integration is yet another part that makes me question motive in addition to the technical issues.

You want us to support systemd? Disconnect it from other stuff like the INIT (pid=0), the logger, and IPC (dbus). Allow all those to remain as they were previously. Let systemd be just the process launcher/manager, and allow let all of those parts work stand-alone with existing tools. Note: providing more features when your tools are used together is fine (and expected). This way, the software can stand on it sown, and if it really is big of an improvement as the systemd supports suggest, the migration will happen naturally over time.

If, on the other hand, using one tool continues to have the requirement of trading many other system-level tools that I already know and use, for unproven newcomers that seem to ignore the lessons of the past, well... I'm sticking with what already works.