It's looks absurdly simple, but works very well. (Speaking as a long-term Void Linux user.)
Configuring a new service is also trivially simple.
Dependencies sort of can be handled: you can start (or stop) another service from within your service; runit will retry if your service fails to start due to a dependency not yet running.
I've had various issues installing Void so I succumbed to Manjaro, which works surprisingly well. I have noticed in general that many non-systemd distributions work less well over time for some reason. Slackware is the best example - one release per decade means it is factually dead, but even trying more modern variants simply no longer works as it once used to work. At the same time there is less and less adapted documentation to be found. It seems the non-systemd distributions not only declined in absolute numbers but also in regards to manpower and time investment. MX Linux also lags behind updating versions of numers programs: https://distrowatch.com/table.php?distribution=mx - it has gotten a bit better after libretto, but it still lags behind compared to e. g. Fedora.
The thing where Void really stands out in my opinion is "hackability" and providing an inviting on-ramp for making certain kinds of customizations that would be intimidating in terms of their complexity in other distros. -- I don't use it as a daily-driver desktop.
For example, I have a chroot'able tarball providing all dependencies for all software I write that runs on a server. I build that tarball myself from source in an airgapped environment. (I had been doing something like this, minus the airgapping, with Gentoo from about 2012 until 2024). I looked for a replacement for Gentoo in 2024 and landed on Void. Most of the time when I do a build, I just pull the latest commit from the repo, and it "just works", even though Void is not even advertising itself as a source-based distro. Sometimes it breaks because of the distro itself (just like Gentoo used to). But, with Void it has always been so much easier to diagnose and fix issues, and the project is also quite inviting to merging such fixes. With Gentoo, it had always been quite painful to deal with the layers of complexity pertaining to Gentoo itself, rather than any package that has decided to break. Void, on the other hand, has managed to avoid such extra complexity.
Lately, I've started to play around with Void's tool for creating the live installer ISO. It's quite malleable and can easily be repurposed for building minimalist live/stateless environments for pretty much any purpose. I'm using that to create VM guests to isolate some contexts for security-purposes like a "poor man's Qubes OS" kind of thing.
Artix is great IMO. You can choose your init system. It's not for your grandmother perhaps. It's a rolling distro like Manjaro and I think it generally benefits from the Arch ecosystem. I only really notice it getting better since I've been using it for the last 3-4 years. The change to using pipewire for sound was unpleasant and the one other major problem I had was Chromium breaking Signal for a time. Everything else has been happiness.
I've done small embedded Linux systems and it makes me so happy that there is a (mostly) compatible implementation built into busybox. svlogd's rotation and size capping makes it great when using limited-lifespan nonvolatile storage like eMMC.
I know some people frown on having multiple processes within a container but there are scenarios where it is needed. I've used both openrc and runit for that purpose and runit has been the simplest to setup and use.
this is probably one of the most promising candidates for an init system aside from systemd, right? I know openrc is still having trouble with parallel startups as a result of its design which is almost a must at this point. s6 is in the works from what I hear, but not configurable via simple config files yet.
Systemd isn't merely an init system though, so I always find these comparisons unfair.
They should focus on one simple and good alternative to the startup-functionality for non-systemd infected systems though. Void has one advantage: they have many clever people, a bit like how Arch used to be before they succumbed to systemd (today's arch is different from when Judd was in charge).
systemd scales. I love small init systems but systemd is just so convenient. It handles daemon process, encryption with cryptsetup, boot process (systemd-boot), hardening options you can define on unit files, good support for nested containerization etc. It's deeply entrenched in every major distro that it's impossible to administer a linux system without it
The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.
Well - the systems presented here are about the init part, not anything else. Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair. If you compare 5_000 lines of code to 500_000 lines of code, the comparison won't work. Systemd assembled numerous things (weed-collection via systemd-homie, for the home setup and I think you can also accidentally delete your home directory, with the systemd devs claiming this is a feature). None of those "features" listed is what I consider needed or necessary. All daemon-startup I already did via ruby as wrapper over the underlying system. For a campus site with many computers, systemd simplified managing them. I don't really see the same benefit for people who know more about computer systems at home - all the complexity is a trade-off with regard to having to learn, understand and apply what systemd brings to the table.
"It's deeply entrenched in every major distro that it's impossible to administer a linux system without it"
That's a non-sequitur, aka an after-the-fact claim made. Not every distribution transitioned into forcing systemd onto everyone - granted, the majority did, but you can find distributions that did not surrender user's rights here, be it devuan, slackware, void, gentoo (https://wiki.gentoo.org/wiki/Gentoo_without_systemd). But admittedly it takes more effort than going into systemd. Note that many of the statements made there such as "hardening options", is just buzzword promo for systemd. It just means nothing. What should "hardening" even mean? Also, it is perfectly fine to use linux on a non-systemd system. People used to do this for decades before systemd infected the linux world. It's a smaller crowd though compared to systemd-using systems and users indeed nowadays.
> Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair.
The real argument about systemd is whether you want an init system, or what is effectively an additional layer in the OS. It provides more standardisation, vs more diversity. The strongest argument for systemd is that it is not just an init system, which is also the strongest argument against systemd.
> ... granted, the majority did, but you can find distributions that did not surrender user's rights here...
I really don't like the phrasing of this. Nobody's rights are being "infringed" by distros going with systemd. Especially because, as other comments have noted, systemd is (not) just an init system, and more often than not I have found that people who hate on it or try to compare it to any pure init system are usually both arguing in bad faith and fundamentally misunderstanding what systemd actually is.
It is deeply integrated into distros that you cannot run these distros without them, it has bugs that ruin production for you, and if you complain about these bugs to the systemd project, they will consider you a bump in systemd's way of greatness that must be purged.
I hoped this kind of behavior would stop as soon as Lennart was busy with different things @microsoft (this happened to Pulseaudio and that was a good thing), but Luca continued where Lennart left, and this stuff goes on.
That suggests that we cannot be allowed to dislike it. I'm allowed to not like init systems e.g. I don't like s6 at all. Oddly, I don't like systemd either but it's not heresy or stupidity or whatever else one might ascribe to it.
What a cope. The hardening options highly restrict the unit files from accessing anything more than it's required for it's function. systemd has also made a lot of efforts in progressing the boot security: https://0pointer.net/blog/brave-new-trusted-boot-world.html. Have fun running your "non-infected" systems which is so easy to pwn
To make a comment like this, I imagine that you've set up BIOS security (password, case intrusion detection...), that you check your keyboard wire end-to-end daily, that you use a USB device whitelist, that you regularly check for hidden cameras spying on your keystrokes, etc., otherwise you're equally "easy to pwn" using equally-quick and roughly-as-cheap attacks.
Using luks to encrypt all partitions (incl. /boot) and it's only unlocked using yubikey. I have secureboot enabled (sbctl to enroll keys) and TPM PCR values to avoid tampering. systemd-boot (a lot more secure than grub) doesn't have password to lock the kernel editor so I have disabled the editor altogether. I use fapolicy for "whitelisting" apps. Unfortunately, coreboot doesn't have BIOS password feature so it's unlocked
It's looks absurdly simple, but works very well. (Speaking as a long-term Void Linux user.)
Configuring a new service is also trivially simple.
Dependencies sort of can be handled: you can start (or stop) another service from within your service; runit will retry if your service fails to start due to a dependency not yet running.
I'm a huge fan of Void as well. Surprised it didn't get a mention in the article. I didn't even realize that runit had an existence outside of Void.
I've had various issues installing Void so I succumbed to Manjaro, which works surprisingly well. I have noticed in general that many non-systemd distributions work less well over time for some reason. Slackware is the best example - one release per decade means it is factually dead, but even trying more modern variants simply no longer works as it once used to work. At the same time there is less and less adapted documentation to be found. It seems the non-systemd distributions not only declined in absolute numbers but also in regards to manpower and time investment. MX Linux also lags behind updating versions of numers programs: https://distrowatch.com/table.php?distribution=mx - it has gotten a bit better after libretto, but it still lags behind compared to e. g. Fedora.
> Slackware is the best example - one release per decade means it is factually dead
As a daily user of slack I find your statement quite interesting.
If you run "-current", all your programs are up to date, and you get new releases much sooner than any debian variant.
The thing where Void really stands out in my opinion is "hackability" and providing an inviting on-ramp for making certain kinds of customizations that would be intimidating in terms of their complexity in other distros. -- I don't use it as a daily-driver desktop.
For example, I have a chroot'able tarball providing all dependencies for all software I write that runs on a server. I build that tarball myself from source in an airgapped environment. (I had been doing something like this, minus the airgapping, with Gentoo from about 2012 until 2024). I looked for a replacement for Gentoo in 2024 and landed on Void. Most of the time when I do a build, I just pull the latest commit from the repo, and it "just works", even though Void is not even advertising itself as a source-based distro. Sometimes it breaks because of the distro itself (just like Gentoo used to). But, with Void it has always been so much easier to diagnose and fix issues, and the project is also quite inviting to merging such fixes. With Gentoo, it had always been quite painful to deal with the layers of complexity pertaining to Gentoo itself, rather than any package that has decided to break. Void, on the other hand, has managed to avoid such extra complexity.
Lately, I've started to play around with Void's tool for creating the live installer ISO. It's quite malleable and can easily be repurposed for building minimalist live/stateless environments for pretty much any purpose. I'm using that to create VM guests to isolate some contexts for security-purposes like a "poor man's Qubes OS" kind of thing.
Artix is great IMO. You can choose your init system. It's not for your grandmother perhaps. It's a rolling distro like Manjaro and I think it generally benefits from the Arch ecosystem. I only really notice it getting better since I've been using it for the last 3-4 years. The change to using pipewire for sound was unpleasant and the one other major problem I had was Chromium breaking Signal for a time. Everything else has been happiness.
Gitlab also uses runit for service supervision.
I am here to enjoy systemd vs alternatives comments...haha
I've done small embedded Linux systems and it makes me so happy that there is a (mostly) compatible implementation built into busybox. svlogd's rotation and size capping makes it great when using limited-lifespan nonvolatile storage like eMMC.
I know some people frown on having multiple processes within a container but there are scenarios where it is needed. I've used both openrc and runit for that purpose and runit has been the simplest to setup and use.
goodness that’s a lot of ads
this is probably one of the most promising candidates for an init system aside from systemd, right? I know openrc is still having trouble with parallel startups as a result of its design which is almost a must at this point. s6 is in the works from what I hear, but not configurable via simple config files yet.
Systemd isn't merely an init system though, so I always find these comparisons unfair.
They should focus on one simple and good alternative to the startup-functionality for non-systemd infected systems though. Void has one advantage: they have many clever people, a bit like how Arch used to be before they succumbed to systemd (today's arch is different from when Judd was in charge).
The best challenger to systemd in terms of feature parity is probably dinit: https://davmac.org/projects/dinit/
Have a look at Chimera Linux if you want to give it a try: https://chimera-linux.org/
runit, s6, and OpenRC don't have the downsides of systemd, but they also only cover a subset of its features
dinit is, imo, the one I'd pick. It's focused but it has dependencies and the services are defined by a DSL rather than startup scripts.
Having said that, I haven't used runit and from the look of it, it's a big improvement over SystemV at the very least.
systemd scales. I love small init systems but systemd is just so convenient. It handles daemon process, encryption with cryptsetup, boot process (systemd-boot), hardening options you can define on unit files, good support for nested containerization etc. It's deeply entrenched in every major distro that it's impossible to administer a linux system without it
The article and discussion are about runit, why bring systemd into it? Diversity in solutions is a good thing, there’s no need to feel threatened by that.
Least sane systemd hater, try using runit or sysvinit on a production system and come back crying when your runit bash scripts fail all the time
You never addressed GP's point...
This is just a thread about runit, what good is bringing tribal console-war like arguments about systemd to it?
Well - the systems presented here are about the init part, not anything else. Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair. If you compare 5_000 lines of code to 500_000 lines of code, the comparison won't work. Systemd assembled numerous things (weed-collection via systemd-homie, for the home setup and I think you can also accidentally delete your home directory, with the systemd devs claiming this is a feature). None of those "features" listed is what I consider needed or necessary. All daemon-startup I already did via ruby as wrapper over the underlying system. For a campus site with many computers, systemd simplified managing them. I don't really see the same benefit for people who know more about computer systems at home - all the complexity is a trade-off with regard to having to learn, understand and apply what systemd brings to the table.
"It's deeply entrenched in every major distro that it's impossible to administer a linux system without it"
That's a non-sequitur, aka an after-the-fact claim made. Not every distribution transitioned into forcing systemd onto everyone - granted, the majority did, but you can find distributions that did not surrender user's rights here, be it devuan, slackware, void, gentoo (https://wiki.gentoo.org/wiki/Gentoo_without_systemd). But admittedly it takes more effort than going into systemd. Note that many of the statements made there such as "hardening options", is just buzzword promo for systemd. It just means nothing. What should "hardening" even mean? Also, it is perfectly fine to use linux on a non-systemd system. People used to do this for decades before systemd infected the linux world. It's a smaller crowd though compared to systemd-using systems and users indeed nowadays.
> Systemd includes more functionality than merely init-stuff, so any comparison here was always biased and unfair.
The real argument about systemd is whether you want an init system, or what is effectively an additional layer in the OS. It provides more standardisation, vs more diversity. The strongest argument for systemd is that it is not just an init system, which is also the strongest argument against systemd.
> ... granted, the majority did, but you can find distributions that did not surrender user's rights here...
I really don't like the phrasing of this. Nobody's rights are being "infringed" by distros going with systemd. Especially because, as other comments have noted, systemd is (not) just an init system, and more often than not I have found that people who hate on it or try to compare it to any pure init system are usually both arguing in bad faith and fundamentally misunderstanding what systemd actually is.
It is deeply integrated into distros that you cannot run these distros without them, it has bugs that ruin production for you, and if you complain about these bugs to the systemd project, they will consider you a bump in systemd's way of greatness that must be purged.
Most recent breakage: https://lwn.net/Articles/1041316/
I hoped this kind of behavior would stop as soon as Lennart was busy with different things @microsoft (this happened to Pulseaudio and that was a good thing), but Luca continued where Lennart left, and this stuff goes on.
That suggests that we cannot be allowed to dislike it. I'm allowed to not like init systems e.g. I don't like s6 at all. Oddly, I don't like systemd either but it's not heresy or stupidity or whatever else one might ascribe to it.
What a cope. The hardening options highly restrict the unit files from accessing anything more than it's required for it's function. systemd has also made a lot of efforts in progressing the boot security: https://0pointer.net/blog/brave-new-trusted-boot-world.html. Have fun running your "non-infected" systems which is so easy to pwn
To make a comment like this, I imagine that you've set up BIOS security (password, case intrusion detection...), that you check your keyboard wire end-to-end daily, that you use a USB device whitelist, that you regularly check for hidden cameras spying on your keystrokes, etc., otherwise you're equally "easy to pwn" using equally-quick and roughly-as-cheap attacks.
Using luks to encrypt all partitions (incl. /boot) and it's only unlocked using yubikey. I have secureboot enabled (sbctl to enroll keys) and TPM PCR values to avoid tampering. systemd-boot (a lot more secure than grub) doesn't have password to lock the kernel editor so I have disabled the editor altogether. I use fapolicy for "whitelisting" apps. Unfortunately, coreboot doesn't have BIOS password feature so it's unlocked
Why does every article on runit have some reactionary runit haters in the comments.
The systemd project and its following can be quite cult-like, towards the more devout-end.
[dead]