The big features sysvinit are missing require user space applications to be able to interact with [generic launch system]. Those applications must use some sort of standard taxonomy and flow control. As applications are ported to [generic launch system], they cease working on sysvinit systems because sysv either doesn't support those features or supports them in a different manner.
Sysvinit doesn't really do all that much, to be honest. So it's really easy for [generic init system] to emulate most of its functionality. [generic init system] does a lot more, so it's harder to copy. Even more, if you were to "clone" [generic init system], applications make big assumptions as to how [generic init system] functions, so your [generic init system] replacement would need to function nearly identically to [generic init system].
Basically, someone made a call and said "this is how a modern init system should function". There is a vocal group of people who disagree with that definition. But no matter what the definition is, people would disagree because different people have different ideas about what Linux is/should be. You would see the same problem if a sysvinit derivative was the leading candidate instead of systemd.
So I guess I can amend that to say "you can't have multiple init systems that do the things that systemd does".
That is a total misrepresentation, I'm sorry. The fact is SysV was probably one of the weakest init systems around, besides deliberately minimal ones like busybox-init and sinit.
I devoted the "sysvinit: the eternal red herring" section precisely to debunk that. I just want people to stop comparing everything to SysV, because it only demonstrates that you're unwashed or closed-minded more than anything. The recent parody site forkfedora.org really aggravated me for that same reason. Instead of doing some witty response to the Debian fork stupidity, they just basically posted "LOL look at this SysV initscript, and now this systemd service file. Checkmate, systemd-haters!"
Much to my disappointment, people keep committing the same fallacies even when discussing an article meant to try and silence them at least this one time. I guess it only proves my point, I don't know.
Anyway, I think the pro-systemd folks often think that anti-systemd folks would react the same way to any init system that isn't sysv. This is probably fair, because there haven't been many credible non-systemd alternatives to sysv.
This is wrong, too. Only upstart, systemd, and runit include any form of System V rc compatibility. (It's worth noting that no alternative system has implemented System V init compatibility.) None of the others do.
I'm not on either side, but I appreciate the way some complexity is dealt with simple little things. So elegantly solving problems: https://www.youtube.com/watch?v=S0mviKhVmBI#t=450
The entire systemd debate is as bad as it is because this is a can that has been kicked down the road for two decades because nobody wanted to have the same argument again. Everyone has known for a long time that at some level, Linux needed better coordination between user applications, hardware, and system services. systemd seems to deliver on most of the functional requirements of such a system, though the implementation method has upset some people on a philosophical level because they believe it's counter to the Unix way, whatever that means.
I would argue that software development in general has drifted away from "the Unix way". Modern software development is a mess of dependencies, abstraction layers, control points and dominant standards controlled by individuals/companies with a vested interest. Linux is a good counterbalance to that, but at the same time it can't stray too far away from the way that people use systems or it becomes too outdated to matter. Is systemd the answer? Who knows. But in the absence of something that performs its function, companies will step up with proprietary solutions for their use cases (launchd on OS X/iOS, whatever Android uses) that lead to more walled gardens, not less.
People like the whipupitude, because they know it. But nearly every init.d script I've read has bugs. There isn't a testing framework to ensure correctness and even if there were it would be needlessly complex because you'd spend a bunch of time mocking out the filesystem / the process table / whatever else init scripts do.
We know what initialising a process should look like and we should be stabilising this API so that we limit mistakes/bugs.
Plan9 seems to have better distilled and refined the "unix way". But it's been too little too late and I'm sure if it became popular there's be wars about it too.
There are multiple solutions that all have their supporters. And we generally actually get along and work together pretty well. BEcause we don't think that one solution is necessarily better than the other in all aspects. It shouldn't be “provide a reasonable alternative to systemd and then we will compare”. “We” won't “compare” anything. Competition is awesome, “we” shouldn't “choose” just one implementation of anything just because the majority of distros uses it. It should be “let people do their thing and please don't hard-depend on this one init system or anything else without a really good reason to do so”.
If someone makes something else, go for it. But API wise it is best to stay the same.
The problem is the following: GNOME depending on GTK+? Just an API.
Of course, it's not your fault, the problem is systemd developers don't want to separate the components as individual programs. So if you want to use logind you also have to install the whole systemd, requiring linux to boot. (pun not intended)