The most unlikely subsystem of contention is definitely the init system used by Linux, with most popular distributions opting for systemd, while a vocal minority prefers to use something else. Neither of these two groups are wrong or right, as we live in a free world and different people have different needs and desires. Personally, I don’t think there’s a more utterly pointless and meaningless debate than this, and people who make the init system they use their entire personality more often than not come across as really, really sad.
It’s a tool; use the one you like and move on with life.
A brand new init system was recently released by Leah Neukirchen, who among a ton of other things, contributes to Void Linux. It’s called nitro, and it’s a “tiny process supervisor that also can be used as pid 1 on Linux”, and it also can be used on FreeBSD supervised by FreeBSD’s init. There’s some overlap with runit here, so Neukirchen published a blog post detailing the differences between the two, which should help in getting a better understanding of what makes nitro stand apart. While both use a directory of services managed by small scripts, nitro seems to opt for a more contained, monolithic approach, as it keeps everything in a single process.
On top of that, Nitro contains some new features runit doesn’t have. The focus seems to be on integrating a few capabilities that on runit require hacks, but on nitro are just built-in, like “support for one-shot ‘services’, i.e. running scripts on up/down without a process to supervise (e.g. persist audio volume, keep RNG state)”, running service directories multiple times, and more. Nitro also maintains its runtime state in RAM and provides an IPC service to query it, meaning it can be run on read-only filesystems without special configuration.
There’s a lot more information in Neukirchen’s blog post, including a look at some of the current limitations of Nitro. I highly suggest reading it, and perhaps we will see nitro as another valid alternative to the popular systemd.
Thom Holwerda,
It’s a debate you’ve partaken in though (and so have I). I see nothing wrong with some lighthearted debates, perfectly natural. Regarding “sad”, well maybe, but no sadder than any of the other debates we have in tech, haha.
I strongly agree with this: use what you want and be happy. But it is problematic that systemd pushes *nix towards tighter systemd coupling at the expense of alternatives.
I’ve been relying on debian for so long – it’s just easy to stick with what you know. But I’ve been reading a lot that suggests void linux could become my new favorite if I gave it a shot.
I like runit and I’d probably like nitro as well: Simple, doesn’t step on your feet, highly portable, runs as PID 1 or as a child or in a container without a care, doesn’t use binary logs, etc.
My own init system does this too. Being able to configure and control jobs in memory without a file system was an important consideration.
Nitro sounds like runit on steroids, and Leah definitely knows what she’s doing — I consider her one of the most talented developers of her generation — and that combination means I’m eager to give this a spin as a drop-in replacement for runit in Void (not that there’s anything wrong with runit, but I love to tinker!).
I really don’t mind binary logs. Outputting to Syslog is still an option with journald, but the binary logs make the data more structured. Plus Syslog is kind of limited, and journald is a good upgrade.
And completely inaccessible when journalctl won’t run, which has happened to me before. This is one of the few things I don’t like about systemd; text logs should always be the default as they are possible to read without the need of a binary to text translation layer.
I will never understand this war on simplicity and utility that plagues modern operating systems.
Most modern OSes aren’t built for people. They’re built for large businesses or governments, and the features make sense in that context.
It’s also the evolution of things. Binary is nicer since it doesn’t have to be parsed like plain text does, so it saves some CPU cycles.
I am surprised there isn’t a set of tools that can read journald files directly with out needing systemd or journalctl.
Unless I’m missing something. My quick search turned up a post about using the Journal API with C, Python, or Go and needing to link against libsystemd.
> Personally, I don’t think there’s a more utterly pointless and meaningless debate than this, and people who make the init system they use their entire personality more often than not come across as really, really sad.
> It’s a tool; use the one you like and move on with life.
Wouldn’t that be a problem if the ecosystem is hostile to the tool one happens to like?
It’s the init system one day, getting shoved into a google–apple lock-in by a government’s age verification system the next.
That slippery slope would make a great extreme theme park attraction. Many broken bones for sure.
This is interesting. I wonder if nitro could be used as a user init to replace the the login script. Systemd starting an instance per logged in user and managing services and timers for them is pretty nice. Specifically, this would be for some of my personal FreeBSD servers.
GNU Shepard is the init I’m mainly looking at for this.
I do have to wonder about going back to scripts rather then, basically, service configs in systemd. A Declarative Language DSL would have been a nice addition. It’s still possible since this is young and scripts are a quick win.
I wonder if something like mRuby, lua, or Perl could be embedded into nitro to get around shell? LOL
Getting rid of init levels and not having to write shell scripts is one of the nice features of systemd.
IPC built in sounds nice. Systemd really should have had built in IPC, or the Linux kernel should have provided it.
A couple things I missed…
I guess my next question would be is nitro going to support logging to remote endpoints for centralization of logs? Piping structured data (binary, msgpack, json?) to an endpoint (http/custom/syslog?) is more useful, especially since containers are a specific target.
I’m guessing the answer is no, but is nitro going to be systemd compatible? At least in the sense that it will work with systemd as a sub-init. Being able to start instances of systemd in different namespaces is a neat feature.
Flatland_Spider,
I’ve used perl scripts to manage processes and it works fine, it’s just that perl sometimes feels over engineered, especially if you need to use CPAN modules, it doesn’t feel quite right to do this in an init environment. Anyway, I think LUA is good for embedding.
While I am also glad systemd doesn’t use init levels, this was far from unique to systemd. There were a lot of init systems that did away with sysvinit conventions and did so several years before systemd. Almost everyone writing linux init systems had the same idea, myself included.
The linux init system I wrote is configured via IPC. All daemons/jobs get loaded though this IPC interface. There is an initial task that can be written in any language and who’s job is to load daemons into the init process. Since PID 1 doesn’t do any file IO (let’s ignore the mantra that “everything is a file”, haha), the file/directory format is irrelevant to PID 1, which doesn’t depend on the file system. PID 1 can monitor/restart daemons itself and/or delegate this responsibility to more specialized tools. This works very well with LXC, Qemu VM’s, network firewall/routers, etc, which is primarily what the OS was built for. It’s simple, but IMHO simplicity is a virtue!
Perl is pretty overengineered. It feels correct in this context though. LOL
Those are the 3 languages which aren’t LISP like that could make a good embedded language. eLisp or Guild could probably be added to the list, but I’ve looked at GNU Shepard scripts. Those are kind of noisy, and something closer to an imperative programming language would be better.
Yeah, the BSDs famously used that as a differentiator, and Arch Linux originally had a flat BSD-style init system.
It happens to be I agree with the BSDs more.
IPC in an init makes sense in so many ways.
I feel systemd is making up for limitations of the Linux kernel, and many of it’s features would be better served being part of the kernel. The kernel should facilitate IPC, or IPC should be built into the init rather then as a service.