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

There are _numerous_ problems with the argumentation being used here. Starting from the top, the first one is actually kind of silly.

"none of these alternate init systems did the hard work to actually become a replacement init system for anything much."

This conveniently overlooks whether or not there was any reason to do so. The scope of "classic" init is very simple. Its scope is well defined. It amounts to "start and stop the services when they're supposed to be started and stopped" and that is _all_. Those other init systems mentioned all expanded the scope of the problem of starting and stopping service a bit further, but only a tiny bit along the lines of deciding whether a county border should be on one side of a twisty creek or the other--in practice, very few people even care. Systemd expands its scope by _miles_ and strides boldly forth as a proud example of _scope creep_.

The bulk of the rest of the argument amounts to "Well, systemd did all this hard work!". This isn't KINDERGARDEN. Its insane to argue that people should be giving systemd a free pass simply because the developers _worked really hard on it_. All those edge and corner and simply misbehaving daemon cases aren't things systemd should be more than peripherally concerned with--they're things to push back on the original developers to fix from the start, and in the meantime those workarounds should be held in their proper regard... as _workarounds_, not major features, because again... _scope creep_.

Lastly, while they're busy giving systemd points for trying real hard and solving a bunch of problems that it shouldn't be bothering with, they ignore the fact that systemd was busily creating _new_ problems... but I'm sure they'll also credit systemd for solving those as well. Specifically Poettering himself recently posted about a "bug" with apparent filesystem corruption caused by systemd failing to properly unmount a filesystem when it's upgraded... during which at some point they appear to have decided that PID 1 is some mystical holy number (which it is _not_) and that going back to the initrd the system booted with is a completely fine and reasonable thing to do, and that it is not, in fact, a sign that one has seriously painted themselves into a corner. They're essentially arguing that they didn't paint themselves into a corner because they're standing in the middle of a long hallway... surrounded by paint... and that the real problem is the lack of roof access.

It's a _huge_ workaround for what is simply not a problem for a small, simple initd that _only_ handles a small, well-defined problem and handles it correctly.

...but you pro-systemd people enjoy having to explain why half the core system functionality has to stop whenever you have to upgrade any of it. The rest of us will continue to use systems that do what they're supposed even while being upgraded.

Oh I agree entirely with you there.

Forget the words bloatware, outsourcers and money for a minute...

Surprisingly it's rarely the core products of the companies that are problematic. It's usually the army of consultants and cash backhanders (the enterprise lot) who come wading in to pillage everyone. That's where the bad rep comes from. They build half-arsed products on top of these platforms which everyone comes to hate.

Regarding open-source talent; much as it is anywhere else, it's hard to come by. In fact a lot of the open source software out there is considerably worse than the closed source stuff that I've seen over the years. There are a few gems here and there for example the FreeBSD operating system, LLVM, valgrind, postfix, postgresql etc but the vast majority is total half-baked shit. I include a big chunk of GNU in that as well which is shameful.

The vast majority of commercial software is total shit too.

Regardless of that, the core of Windows and even Java (but not SAP - I've had my fair share of integration there) are good products. Just don't go and grab piles of enterprise integration junk on top and it's fine.

That, IMHO, is where all the pain comes from and why people have such hatred.

Hatred is infectious as well. It takes experience to distinguish justified hatred and rumors.

Towards the idea that you can write them in another language, we in the Perl community ended up developing something of that nature[1]. It was originally intended to make writing daemons in Perl easier by pulling out common functionality (double fork and such), and giving a consistent clean interface. One of the bigger requested things was the ability to use it as basically the entire init script ([2] for an example).

[1] https://metacpan.org/pod/Daemon::Control [2] http://hashbang.ca/2012/04/16/wherein-i-realize-the-bliss-of...

Great comment.

The thing that strikes me as the very weirdest about all of this is that many of the systemd proponents seem to be incredibly animated and aggressive about systemd, but most of their arguments are either non-technical or completely wrong. Like, what's the motivation? Why have so many people gotten to this mentality?

Since there's different needs (I ansolutely really want my bind, httpd, crond and others to restart when they die - I have no desire to log in and do that manually), you just opt in to the auto restarting in the .service file - systemd does not restart anything by default.