If one runs Linux, one runs a Linux kernel. The idea that there be a single main management daemon for this single kernel seems singularly simple.<p>I can track the angst at the loss of the "little guy" in the process, but the arguments offered in the article seem FUD.<p>If systemd were dodgy, it would fail.<p>Also, if systemd is really ao evil, maybe *BSD is worth a look.
Appreciate <i>this sort</i> of a look at the whole thing; I've been a long time Linux guy sort of consistently baffled at the more divisive moves that the big players make here, and I think I'm probably forgetting the extent to which there is big money/growth involved in being the biggest fish in the pond.<p>That being said, the strategies still seem pretty obtuse to me, it really does feel like all the Linux-powered companies and organizations who'd like to take a serious shot against Apple and Microsoft need to do way more cooperating than competing.
> Fact 3: No, it's not a myth, systemd is truly a huge monolith<p>> In his blog post "The Biggest Myths", from January 2013, Lennart Poettering says: “A package involving 69 individual binaries can hardly be called monolithic.”<p>> The fact is however, that many of these so-called individual binaries has functionality that simply will not work without other systemd components.<p>Hmm I don’t agree that services relying on each other’s functionality means they’re a “monolith”. That sounds like a very different definition of monolith/microservice than I’m familiar with.
>It has surprised me that the initial discussion on the Debian mailing list somehow managed to only address SysVinit, Upstart and systemd. Nobody took a serious look at runit or s6.<p>Was s6 even mature at the time? Runit has no reliable dependency or ordering features, so it is a poor substitute for startpar, upstart, or systemd.<p>OpenRC should have been considered, but at the time it had no supervision features. Which was something that people really wanted from a service manager and one of the primary reasons for moving away from sysvinit/startpar.
> Red Hat cannot be trusted from a security point of view and if the U.S. Military, or some other three letter organization, want Red Hat to put a backdoor into systemd, then this can easily go unnoticed for many years, just like it did with the Heartbleed bug.<p>Is the author attesting that RH/USMil backdoored OpenSSL with Heartbleed, or just that it took many years to discover?