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

The biggest fear i have after reading all of the latest articles popping up is that it's too monolithic, just as a lot of other people. However from reading on their faq it seems they've split out into several different processes and if the processes themselves are well scoped i can't really see the problem?

I tried googling for something but i can't find any good documentation about what different processes systemd uses and how they interact and their roles in systemd? Anyone have any tips?

And there you exactly pinpoint the problem. The FLOSS movement used to be about caring about other people and projects. RedHat* and its employees only give a damn about their use-cases and the rest of the "community" can go to hell.

Which, of course is a logical stance to take for any corporation, however how easily everyone goes along with it is just appalling.

*this, of course, goes for every corporate entity, though some work with the community better than others.

Because the potential upside is tiny. There's nothing in FreeBSD that I can't get in Linux that I have any particular need for. I'm sure there are features that are important and valuable to other people, but that doesn't help me.

That leaves near 0 benefit, and some unknown non-zero cost and risk associated with reduced experience with it, potential application incompatibilities and other unknowns, as well as a time cost of re-imaging servers and re-deploying vm's that would put tens of thousands on the cost side.

That's not exactly a cost-benefit situation that justifies spending time considering it.

If the FreeBSD guys develop something so amazingly much better than Linux that we could save lots of money by switching, that could change. I don't see that as very likely, though.

As it is, FreeBSD vs Linux is a bit like Coke vs Pepsi: If you have a preference, and its available, pick it, but it makes very little sense to expend lots of effort to replace one with the other.

> There's also a huge amount of redundancy inside, and between, SysVinit, atd, crond, supervisor, syslogd and the other things systemd replaces.

Such as? I'm pretty sure code shared between these systems lives in (or could easily be moved to) shared libraries, specifically to avoid this problem. But this is orthogonal to the design of the init system.

> But DRY is engineering philosophy. Each repeated piece of logic doubles the scope for errors.

While DRY is a great engineering principle within the scope of a single project, it doesn't justify excluding alternative implementations or entangling unrelated concerns. Specifically, DRY is not an excuse to forbid competing init system implementations, even though having more than one creates code redundancy. Moreover, "doubling the scope for errors" is meaningless from the user's perspective in the context of init systems: if there are X errors in systemd and Y errors in OpenRC, I will not be plagued by X+Y errors because I will only be running one of them at a time.

> One could also argue that 'doing one thing well' is handling services.

Ah, but "handling services" is not a well-defined task. To some, it means doing something like what sysvinit does--reaping orphaned processes and nothing more. To others, it means doing something like what systemd does--not only managing processes, but also managing devices, sessions, storage, power management, cgroups, system IPC, and network interfaces (and possibly more in the future).

> Do you have any idea how much code is in the kernel?

Yes I do, and that's kind of my point. It's a Kernel. I.e. it's the proverbial operating system. It's written as an operating system. Systemd wants to be the operating system, obviously, which is fine. Just call it the Systemd OS and provide the kernel and user shell as well, and you won't need linux anymore.