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.

RHEL users can countinue to run systemd in production without disrupting the rest of the comunity with an init that goes beyond its scope.

Because the latter community enjoys a hodgepodge of scripts doing arbitrary things instead of a standardized well organized mechanism?

How much time do you think a member of the latter group spend on init scripts?

When I did that job, I would estimate maybe one day a year at most. But core functions just stopping working and no one knows why would have been a very big deal

Perhaps. But then again, the RHEL people really need many of the features SystemD offers. The Ubuntu Beta people can keep running init if they must.

The Ubuntu people, like the Fedora people, used Upstart before they switched to systemd. You make the far too common error of thinking that only systemd and System 5 init/rc exist.

* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

Upstart had some really nasty gotchas too, but at least was limited in scope. It'll be interesting to see if we ever move from CentOS to FreeBSD to get away from the horror show that is systemd.

If your applications run on FreeBSD I would make the switch, but most originations need better reasons for switching. Have you ever had downtime associated with Systemd or Missed deadlines? Thats the only way I could think of that might justify the switch.

Honest question: I'm not familiar with FreeBSD, what init system does it use and why isn't it a horror?

FreeBSD uses FreeBSD init and Mewburn rc. Mewburn rc is somewhat different to van Smoorenburg rc. It has a huge library of standard shell script functions, and the actual rc files that ship with the operating system, and accompany packages, sometimes boil down to a few shell variable assignments and then an invocation of one of the shell library functions that does everything. This is not universally the case, however, and there are some giant exceptions.

Now read https://news.ycombinator.com/item?id=11550802 and https://news.ycombinator.com/item?id=10357589 . (The mentioned van Smoorenburg rc script has since moved to https://github.com/dun/conman/blob/master/etc/conman.init.in .)

The TrueOS people have replaced Mewburn rc with OpenRC, retaining the FreeBSD init as far as I am aware. I suggested to them back in January 2017 that since OpenRC has s6 integration, they might do well to add s6 to that to gain full service management. I never received a reply. I haven't heard that Laurent Bercot was contacted, either.

* https://news.ycombinator.com/item?id=13458186

* http://www.mail-archive.com/[email protected]/msg...

I personally use the nosh system and service managers on FreeBSD and TrueOS, of course. I released version 1.34 last week.

The biggest advantage is that its init system is just an init system. Systemd is so far beyond the scope of an init system it's not even funny.