|
My experience is that it broadly falls into two categories. The first is comprised of people who never actually had to wrangle sysvinit/upstart (openrc is relatively sane), and have never seen the ridiculous amount of engineering time which went into hacky stuff like supervisord and bizarro, bespoke hacks to try to do things which systemd makes trivial: socket activation, optional service dependencies, file-based service activation/restart, "failing fast", timing various parts of the boot chain, etc. This class of people, broadly, probably never actually understood how `init` worked anyway (or how booting worked once dracut came into the picture), but they now feel like it's an opaque, unobservable system. They would have felt like that anyway if they had tried to work with pre-systemd tooling. The second mostly thinks that systemd is against the "UNIX philosophy". This class of people, broadly, has never touched a "real" UNIX other than MacOS (and they probably never had to deal with netinfo) or BSDs (which are great). There was absolutely no sanity or consistency between, say, AIX, Solaris, IRIX, and Tru64, and all of them had various classes of "god" tools. Lennart is not always right, but he does have a vision of Linux for the 99%. That is, one of the "against systemd" links is this:
https://edgeofsanity.net/rant/2017/12/20/systemd-resolved-is... This is indicative of the problem. Ninety-nine percent of users don't WANT to configure 40 different baroque things with their own configuration files (rsyslog/syslog-ng, dhcpcd, resolv.conf, ntp.conf, /etc/hosts|/etc/hostname, etc). They want Linux to work. They want systemd-networkd to get them an address in 1/10th of the time, and they have absolutely no need to start a daemon which can set every DHCP option ever when ACKing. They to fuss with nameserver rotation to deal with flaky stuff for split-horizon DNS -- they want systemd-resolved to handle "this server can't be reached right now, so I'll put it in timeout, keep returning cached results, and send new queries to a nameserver which is responding." If you still WANT to do the other stuff, nobody is stopping you. Yes, you probably need dbus and udev and udisks, and all of those things are light years better than the tools we used to have before, but systemd itself can be trimmed down to almost nothing if you want to. The alternative, building up a stack which can sort of approximate systemd, would take a very competent admin at LEAST a week to build deployment tooling for, and that's assuming they already knew all the stuff they needed to plug in. |