> In his blog post "The Biggest Myths", from January 2013, Lennart Poettering says: “A package involving 69 individual binaries can hardly be called monolithic.”
> The fact is however, that many of these so-called individual binaries has functionality that simply will not work without other systemd components.
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.
If you ask me a lot of systemd is actually pretty easy to swap if you're interested, most is separated out into clean d-bus APIs.
Is the author attesting that RH/USMil backdoored OpenSSL with Heartbleed, or just that it took many years to discover?
> The U.S. Military has been Red Hats biggest customer since 2002
Ah, so, the US decided they need well-supported domestic Linux company. The horror. Pretty sure most US government agencies, not just the military, mostly use Red Hat.
I can track the angst at the loss of the "little guy" in the process, but the arguments offered in the article seem FUD.
If systemd were dodgy, it would fail.
Also, if systemd is really ao evil, maybe *BSD is worth a look.
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.
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.
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.