> Like most, you could have simply moved to a distribution without systemd. Unlike Linux, the BSDs offer less choice when it comes to both init, service supervi

> Like most, you could have simply moved to a distribution without systemd. Unlike Linux, the BSDs offer less choice when it comes to both init, service supervision and service management options. It is also evidenced in the comparison table in the OP. If anything the debacle resulted in creating more awareness and leaving people open to more choice. systemd had the opposite effect of giving people more choice. Before systemd every major distro ran it's own init service. Often they were variants of init.d but sometimes they might vary quite significantly. Debain, Ubuntu, Suse, Arch, Slackware and Gentoo -- they all had different inits. One of the reasons systemd was push so heavily was to standardise things across the different distros. Now the only distros still offering anything different are either those that are also gradually falling out of favour due to the changes in user trend; or newer distros that are only a minor blip in the Linux community anyway and unlikely to ever grow beyond that. The exception here being dockerised Linux eg Alpine. But they fill a different use case. > This only scratches the surface. Daemons running under systemd have their PIDs supervised instead of using unreliable hacks like pidfiles. This is one of the reasons why systemd is preferred in large deployments and professional environments. Honestly, I'd take pidfiles over binary log files any day of the week. However you're right that systemd does bring some good ideas to the table (if it didn't, nobody would have adopted it). My issue with systemd is that it's needlessly hard to separate the wheat from the chaff. I know systemd isn't the monolith people often describe it as...but even so, it sure feels like it's an all or nothing deal at times.