Are there any comparisons of init systems that focus daily use metrics? Stuff like what writing scripts looks like and boot times and logging capabilities? (And any other use cases that are common)
These comparisons assume the systems do the same thing, resulting in a comparable system once everything is up and running.
That is just not the case. Systemd does a ton more wrt. security, hardening and reliability. E.g. it has udev integrated and not running “stand-alone” since it tends to lock itself up when it needs to start long-running services in response to HW showing up. Yes that happens rarely but there is nothing you can do about it. Logind locks down permissions to HW way more tightly than the “forks” that have the same problems that the pre-logind system had – and that led to logind getting developed in the first place. Lots of sandboxing options are built into systemd and widely used tomrun services (I rarely saw any sandboxing elsewhere so far outnofmthenbox), measured boot is pretty much a systemd-only thing at this time, … .
Dood. Boot times are useless ‘flex’ metrics more influenced by processor and disk speed than init systems. My el5 and el6 archive systems boot faster than my el7 ELS system, which itself is faster than el9; but not by enough to matter when you’re booting every week to a month. It’s never BEEN an issue.
Compare complexity: Has your init system metastasized over the entire host and re-implemented (poorly) other core systems, so long-dependable features just simply don’t work, and everything has its own rinky-dink silly-walk to configure instead of
/etc/fstabor/etc/exports, instead of staying in its lane? No? You’re good. Diversity and specialization will give you excellent results and security. Yes? You have systemd.There’s your comparison.
the pistack article seems like potential ai slop
Systemd is feature-rich but controversial. Its monolithic design bundles service management, logging, networking, device management, and more into a single codebase exceeding 1.4 million lines of code.
That is a gross misrepresentation of systemd…
It’s like saying GNU coreutils is monolithic because all of the individual tools combined are bundled together.
Systemd is comprised of many individual applications.
Even systemd-less distros need to implement ‘fake’ systemd components. It’s like a cancer. No one’s voluntarily using sub-components of systemd without systemd. It is a monolithic thing.
You can dislike systemd, its6okay. But there’s no need to be stupid about it.
Yes - things built to work with systemd… require systemd to work.
But you don’t need to use all the systemd services. You can use other tools. Because systemd is not a monolith.
How does systemd dare to provide useful functionality? It should be just as useless as all the other inits that nobody ever felt the need to depend on, simply because they do nothing interesting.
You can just build a way more functional and secure system with all the cool features systemd provides.
Fantastic resources, especially that pistack article. Tysm!
You can just try them out in a VM if you’re interested. Systemd can become quite a deep rabbit hole, but most of the others are quite simple and best learnt by doing.
I realize this is the best option, since it centers my experience and needs better than anyone else’s summary, but what to do if I don’t have the time to daily drive enough init systems long enough to understand the scope and limitations of each?
E.g. Gentoo’s wiki has a comparison chart of all the systems I’m aware of, but I don’t know what some of the rows mean, so I would have to daily drive multiple types to get a feel for what it’s like with and without those options and how that affects me as an end-user. It also doesn’t include metrics that often get referenced but not quantified in the comparisons I find (stuff like boot times)
Furthermore, the only two times I’ve tried to switch out the init system on my PC, I’ve somehow managed to bork things so bad I had to do a fresh reinstall. Yes, I could do troubleshooting, but that’s even more hours (or even days) of downtime up front.
All this to say: I’m just looking for a little bit of a shorcut to reduce the amount of documentation I have to read, and tweaking I’ll end up doing.
I think if you’re at the point of poweruser where you’re deciding an init system, you probably should just try them out in VMs. It doesn’t have to take loads of time. Install an OS, try writing some basic services, try doing some basic config for your use-case.
For the vast majority of users, they’ll never have this problem, because they’ll just use whatever init system comes with their OS. I know some distros give init freedom, but most are locked in to one or another init. The fact that you have this problem suggests that either you’re using the wrong distro and should switch to one that chooses for you (or just pick based on one-line descriptions), or it’d be worth your time to spend a day or two poking around with the init systems under consideration in VMs.
Unfortunately, you do what everybody else does. You use your reading, patience and time to research test and try various options over the course of weeks, months and years until you get experienced and knowledgeable about Linux and the ever changing options and configurations. There is no ultimate manual that tells you everything there is to know about Linux.
