The Motivation Behind Systemd | Hacker News Reader

The Motivation Behind Systemd

unixsheikh.com

23 pointsmendelmaleh9 comments

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.

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.

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

Systemd binaries are not a monolithic system but they are so tightly coupled that they are almost like a monolith. There is no api spec so you cannot swap any component exactly like a monolith, and this is why people call systemd a monolith and this is one of many reason a lot of people dislike systemd, because it's a non swappable batteries included app.

That still doesn't make it monolithic. It's not exactly rare for an open source project to have no API spec. If you want to replace a part you just look at the code and then implement that API.

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.

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

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

Wording implies that it just took a while.

It took years to discover. I also take a bit of issue with this:

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

Reply on news.ycombinator.com