This is just a thread about runit, what good is bringing tribal console-war like arguments about systemd to it?
You claimed that anything but systemd would "fail all the time", I pointed out that in many years of using other options I've never had them do that.
The most egregious systemd bug I've hit was it just freezing on shutdown, with zero error message or even warnings; there's nothing a user should be able to do to produce that outcome that's a "skill issue" and not a bug. In any event, you're just making up claims without evidence.
As a long-time runit user, systemd does far better with sequencing things. With runit you have to have a check executable, and then run 'sv check servicename' in the start script of the service which depends on another.
"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.
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.
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.
> ..., 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
The sentence is not about systemd having bugs, its about how the devs handle bug reports.
In the /run/lock situation that i linked, Boccassi unilaterally declared WONTFIX towards the users whose applications he broke. If i did this at work, I'd get fired.
... Yeah, except that system's excessive and ever expanding scope is one of its bigger problems. Are you sure they misunderstood anything?
Systemd's "scope creep" is a stereotypical haters argument and is nonsensical. The 'Unix Philosophy' was a hardware requirement more than a philosophical one because back then they literally couldn't fit more than one program into memory at a time. And, regardless of the hardware or philosophical debate, systemd does actually meat this requirement: systemd itself is just the init part and service manager. systemd-logind is a completely separate service which you can opt not to build and systemd will work just fine. systemd-resolved, systemd-timesyncd, etc., are likewise completely indepeendent programs which just so happen to share the same codebase and are under the same umbrella. Are you next going to claim that coreutils has scope creep because all of the tools share the same codebase? Or busybox?
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.
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.
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).
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
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.
s6 is just a process supervisor meant work alongside an init. That said, an init was developed exclusively for s6, and it's ready according to the author's website. You could in theory setup a full Linux system with it.
The author is currently working on a user-friendly UI/frontend for the system. But that's not an essential component.
> but not configurable via simple config files yet.
I don't know if that's the goal of the project at all. Config files defeat the entire purpose of its design.
It's a little complicated to set up if your root file system is read-only, since runit really wants to write to the disk, and you must set up symlinks pointing to tmpfs.
The daemontools family is the exact opposite of what we've come to expect from an init or process supervision system. It pioneered an approach that eschews large complex monolithic daemons in favor of the unix philosophy. They're made of numerous small and simple applications - a few dozen sometimes. Unlike the traditional init systems that most of us prudently stay away from (other than writing their service configurations), these applications are very easy to understand and tinker with independently. They have a coreutils feel - you can easily find other uses for them and mix and match them freely (because they're all very specialized). Sometimes it feels like they designed the utility suite first and then designed a supervision/init suite around it. It isn't just easy to setup a service hierarchy with it. The applications are so small and simple that implementing the suite yourself isn't a big stretch either.
The way they set up an init system or supervision tree is out of scope here. The blog post "Celebrating Daemontools" [2] by G.D. Ritter is the best description I could find. Instead, let's focus on the individual applications. Simplicity is a virtue in engineering. These tools try to get away with as little work as possible. For example, there is no complex config language, API or wire-format. Instead, these tools communicate the intent (config or commands) and the state of the service tree using the filesystem. Its API is a tree of directories, files, symlinks and FIFOs called a 'scan directory' - somewhat reminiscent of the /sys and /proc directories. Each service is started, monitored and restarted upon crash by a very small and stable daemon that takes its instructions from a sub-directory of the scan directory (a service directory). The files inside these sub-directories are arbitrary executables (scripts/binaries) or others that either contain a single value or are completely empty (the file itself is the data). They religiously avoid parsing.
Another trick they use heavily is 'chain loading' of applications (a.k.a 'Bernstein loading'). Here, one application 'execs' into another application, with the latter completely replacing the former in memory. This is used to, for example, set the environment variables (from files - one per variable) before execing into the required service. Sometimes, these chains are several commands long. There is even a scripting language called execline [3] that works entirely by chain loading. Unlike traditional scripting languages, the shell/interpreter doesn't stay resident in memory and babysit the child processes. It (execlineb) does some very simple initial processing and then completely exits the scene. The rest of the execution is a bunch commands invoking others using traditional syscalls. Writing execline scripts takes some getting used to, but it's very nifty afterwards.
They use these simple techniques to do everything including parallel service initialization with dependencies, setting up envvars, gid, uid, resource limits, logging and even socket activation. They are super light and extremely fast. They have such straightforward interfaces that composing systems with tools from different suites is also possible. Though I haven't seen it in practice yet, starting and managing containers (like systemd-nspawn) should be trivial to achieve. These suites grow on you once you start using them and remind you what could have been. They really show you that something as complex as init systems and process supervision doesn't require prodigious talent or the resources of MNCs. You just need to stick to the fundamentals.
Finally, some other members of this family that deserves some mention. Bruce Guenter's daemontools-encore [4] expands on daemontools with backwards-compatible changes including extra service states (besides just up and down). And then there are Gerrit Pape's Runit [5], Laurent Bercot's s6 [6] and Jonathan de Boyne Pollard's nosh [7]. These three can run as init systems on Linux and BSDs. Nosh features a systemd and upstart shim layer to make it feel familiar to the users of those software. Nosh also has utils that convert systemd service files and upstart scripts to its native service bundles.
[1] http://cr.yp.to/daemontools.html
[2] https://journal.infinitenegativeutility.com/celebrating-daem...
[3] http://skarnet.org/software/execline/
[4] http://untroubled.org/daemontools-encore/
[6] http://skarnet.org/software/s6/
nine_k•2mo ago
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.
gyulai•2mo ago
shevy-java•2mo ago
gyulai•2mo ago
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.
arp242•2mo ago
This fairly accurately describes why I generally prefer systems like Void (including for my daily desktop). Alpine has a similar experience (although I hate OpenRC), as do the BSD systems (mostly; there's some ridiculous historical complexity here).
t43562•2mo ago
enriquto•2mo ago
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.
jmclnx•2mo ago
Now another point of view :)
As a Slackware I stick with release because it is extremely stable and my main System (Thinkpad W541) works fast as most modern systems with 16G mem and 8 CPUs. If I ever got a brand new system (doubtful), I would use current until the next release.
Also, I like the fact I do not have to install patches every other day. Plus PV keeps the applications I use most up to date in Release.
That is the good thing about Slackware, you have current for the adventitious and release for people like me. And both you admin the exact same way.
FWIW, I use regular Window Managers as opposed to desktops and my main programs are Emacs (latest version), vim (close to the latest), Firefox (latest), mutt, tin, irssi and some games that come with KDE.
prmoustache•2mo ago
In slackware's case it just means most users have switched to the rolling release model of the -current branch really.
blueflow•2mo ago
nine_k•2mo ago
(Alpine is great, but I did not try it as a daily driver, it's sort of not intended for that, it seems.)
yjftsjthsd-h•2mo ago
I can't say what it's "intended" for, but I run stock Alpine on a desktop and a laptop, and postmarketos (an Alpine derivative) on another laptop, and I assure you it works great as a daily driver.
blueflow•2mo ago