I’m planning to move over to Guix over NixOS, as soon as my current situation improves and possibly import a new libre respecting laptop (Star Labs is thankfully available in India). I do have a very old laptop with a Celeron processor and 4GB of RAM with Guix installed already, and what has come to my attention is that it uses shepherd.
I’m not actually against or for systemd, in fact, I am not really sure why I should even care - maybe it is because I’m still not on to the level of a power user. Since I’m starting to learn kernel basics to prepare for GNU/Hurd contributions in the nearest possible future and shepherd seems to be what the GNU folks will be using, is there any reason why I should even care about the freedom of init system?
Edit: I’m asking this because I came across this blog - What is systemd and Why Should I Care? and also because Guix uses shepherd, and I’m not sure how I’ll be affected.
To imply that systemd is merely an init system is ingenuous at best and dishonest at worst - systemd is so much more than an init system, as that article mentioned. Since the article was written in 2014 systemd has grown massively in scope, even more than the author feared.
It manages DNS, home directories, system services, seat managment, cron, system logging, booting… the list is ever growing. As such many people fear it is becoming too dominant through making more and more software dependent on it. It is not atomic - it is very difficult to have just one piece of systemd as its parts are tightly integrated and inter-dependent.
One could even claim that systemd failed in it’s original remit - to make startup as fast as macOS by running tasks in parallel and by deferring service startup until they are actually needed. The result has been a not very performant init system - many init systems are faster eg runit, dinit. The systemd people now claim that speed is not a design goal.
It is, however, open source and very widely adopted. Most people don’t care - they just want to run their browser and word processor.
I never understood why people care about 1-2s of boot time (unless maybe they are working on testing things after boot while developing a kernel or similar tasks that require boots every other minute).
The main problem with systemd has never been the time it takes to boot, it’s more on the lines of what @[email protected] and @[email protected] mentioned.
The main problem with systemd opponents has always been that they have not offered any compelling alternatives because as a sysadmin I know very well that I do not miss the days of debugging which of my environment variables from my interactive session slipped into and changed the behaviour of my init script call or indeed writing init scripts in general that re-implement the same 5 things badly for every daemon.
That has never been true, not at the point of the discussions on Debian (on Arch there was never a public discussion that I remember), and of of course not true now.
s6, dinit, runit, openrc and shephered are good options, currently in use by different distros. At the time of the public debian descussions, at least runit and openrc were available, but they were dismissed, and I don’t remember the arguments, but not so convincing at the time, thus the whole discussion about the topic.
I’m not a systemd opponent, but claims of not having compelling alternatives doesn’t feel right. I used Arch with systemd for a while, and I moved later to Artix with s6, and I’m thinking on testing dinit, and I have no issue. I guess if some major distros had made the move to runit or openrc, they would be more used as of now. BTW, at work, for containers and VMs I actually need to use systemd, and I see no problem with that.
It’s totally true sysVinit was way hard to keep maintaining on distros, and something else was required. Probably given the influence from major distros changed the game over systemd, and now that’s considered standardization now a days, but something else could also have become the standard. What’s for sure is that there are success stories of using something else, Guix with shepherd, Artix with several inits (dinit, s6, runit, openrc), Gentoo with openrc (one can choose others, like systemd), void with runit, chimera with dinit, and the list goes on. Variety is not necessarily a luxury, in this case it means one can choose whatever aligns better to one’s needs, believes (perhaps simplicity, perhaps minimalism, perhaps free/libre considerations, etc), and so on.
What’s also true is that for work purposes, one can’t be negligent learning about systemd, most probably one will need to deal with it sooner or later, because major distros, and in particular commercial ones, already embraced systemd, and that’s not changing any time soon.
The sad effect of wide adoption of systemd, whether one opposes it or not, is that now services/daemons developers focus on providing systemd ready daemons, and for anything else the distro developers need to port to non systemd alternatives, and even build applications without systemd if that’s possible at all. And if one is looking for a daemon not packaged by the non systemd distro of choice, ones is on our own creating the proper service/daemon, but not something impossible.
I used openrc for years before switching to systemd on my Gentoo systems and indeed it was the default there at the time (might still be a default, defaults on Gentoo tend to be very soft suggestions unlike some other distros). It had nothing particularly compelling compared to any of the other init script based systems as far as I remember. Certainly had all the same major downsides.
The very reason it is so hard to provide init scripts for alternative systems should be a hint that systemd actually does quite a lot of useful things because I certainly don’t consider it nearly as hard writing a systemd unit for a daemon that lacks on these days as it was to write an init script back in the bad old days. Especially if you give a shit about not just copy&pasting and then tweaking a random other init script for a total maintenance nightmare or care about it being usable on both Debian- and RedHat distros.
I guess for init system development making speed one of the goals makes sense