Comment by derefr | Hacker News Reader

Comment by derefr | Hacker News Reader

Parent Full thread

There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.

It's easy enough to understand their point of view: run through a Linux From Scratch install. You'll have to write your own init system. You'll be duct-taping a lot of things together, and your solution—while it might be something you're "proud of" in some sense—will definitely be lacking in engineering, no matter how much time you as one individual could ever throw at it.

After the LFS experience—which is essentially the distro creation experience—coming back to regular (pre-systemd) distros made one feel rather different: it was very easy to see how each distro was, at its core, just someone else's duct-taped-together init system with a pile of hacks accumulated on top. There wasn't any real Engineering; there was no shared knowledge-base of best practices for doing this or that. Each distro was a evolutionary Galapagos island.

From the LFS perspective, an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing. systemd is, finally, a reference implementation of an init system "at scale." If you want to build your own init system, you don't have to look at the init systems of 30 different distros to figure out what things each distro just did its own way for no reason, any more (which used to be "most things.") You can just start by looking at "what systemd does", and figure things out from there. Or you can use some systemd components, and some of your own.

> There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.

I work on a distribution (openSUSE) and don't hold systemd in high regard. There are many people who work for distributions and don't feel that way. Of course, the general openSUSE community decided to go with systemd, but it's not fair to claim that everyone who contributes to distributions that use systemd must therefore like systemd.

The reason I don't like systemd is that in my experience, systemd forces you to integrate system management programs (such as container runtimes) with systemd. And when you are forced to integrate, systemd then causes you nothing but issues. cgroups are a perfect example of this. In addition, systemd doesn't obey SIGPWR and as a result LXC has to write special code for systemd -- which is just ludicrous.

I've talked to some other people from other distributions and they feel so strongly against this that it's possible you'll see a new init system in a few years that rectifies the problems with systemd.

> an init system that exists as its own standalone FOSS project, containing contributions from hundreds of interested parties and battle-tested engineering choices after coming-up-on-a-decade of use in virtually every scenario, is a wonderful thing

There are several things wrong with that description of systemd. To be clear, the pre-systemd init systems were also horrible. The original idea of systemd which was a declarative and parallel init system was a good idea. The problem is that systemd has far out-grown being just an init, and it has been shown historically that it is far from "battle-tested engineering" (with the additional note that the maintainers are strongly against people allocating CVEs for their project).

Competition for declarative and parallel init systems would be good, but I slightly doubt that it will stay that way. The whole conflict feels very similar to the idea of declarative and dependency based initramfs, where for a long time there was basically only initramfs-tools in debian that had it, with everyone else just using a hard coded and very long shell script. If we like to talk about init shell scripts as something people avoid to touch, its nothing compared to the dark magic and undocumented mess that went on in the initramfs shell script.

Several years ago Red Hat decided they also wanted something like initramfs-tools but which themselves had developed (a remark I recall that the developers made on the mailing list), so they built a new system called dracut that models very close to initramfs-tools, in which Debian's response seems to be: "Great, someone else want to support that complex tangle of dark magic, let's use theirs!", so instead of competition I suspect things will return to a monoculture again. A good thing is that during all this, distributions like openSUSE has also switched over to dracut which hopefully shows a trend that the age of large shell scripts in the boot process seems to be over.

If one pays attention to SystemD bugs, it is pretty clear that SystemD is sorely lacking in engineering.

> There's a third, rather small community: the distro-makers, who nearly to a one are—if not in love—at least hold systemd in high regard.

I'm a distro-maker (Exherbo) and while we provide the option for systemd I wouldn't say anyone is exactly thrilled by it. Users use a variety of init systems including handrolled ones, and that choice is the users'. But we recognize it as the sensible current default and is too much effort to work against the grain here.

I'm a distro maker (closed source Linux distribution) and I don't use systemd, as doing so would add significant non-determinism to what is an otherwise deterministic process.

Linux From Scratch has been one of the most stable and problem free systems I have used.

It does take a lot of time, but one is protected from a lot of distribution nonsense.

Reply on news.ycombinator.com