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