from Hacker News

The Motivation Behind Systemd

by mendelmaleh on 4/11/21, 3:26 AM with 9 comments

• by smitty1e on 4/11/21, 12:01 PM

  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.

  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.

• by jrm4 on 4/11/21, 4:26 AM

  Appreciate this sort 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.

  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.

• by xref on 4/11/21, 7:40 AM

  > Fact 3: No, it's not a myth, systemd is truly a huge monolith

  > 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.

• by CameronNemo on 4/11/21, 4:09 AM

  >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.

  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.

• by tsujamin on 4/11/21, 4:01 AM

  > 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.

  Is the author attesting that RH/USMil backdoored OpenSSL with Heartbleed, or just that it took many years to discover?