So... you can remove systemd and replace it with a few shell scripts? Isn't this, like, pretty well-known?
Or maybe I didn't get the point of this. It doesn't look to me like this is one of the regular rants against how systemd destroys everything. But I could be wrong about that?
I don't think the author intends to provide a serious production solution, at least not for now.
Runit tools in busybox - up to the task?
Let's test busybox's runit applets in a hypothetical ;) scenario
when someone needs to stop running, say, systemd on, say, a Fedora machine.
No doubt this will expose various shortcomings.
To me, This just seems like a fun experiment to demonstrate busybox's capabilities.
Busybox init is a binary. It can run anything (based on /etc/inittab) incl. other binaries. There's no need for it to run shell scripts (other than /etc/inittab lines which are executed under `sh -c "..."`).
One thing I found interesting recently while working with cloud instances (I usually work with traditional datacenters), is that those things boot extremely slowly.
The whole point of those new complex init systems was to boot faster. It definitely works for my desktop or laptop, but apparently not so much with the cloud.
If it's not gonna boot fast, I don't see the point of replacing straightforward shell scripts.
Most cloud providers can spin up an instance to SSH-able pretty quickly (seconds), if it's holding you back, you may want to look at the image you're using to boot those instances - perhaps it has dependencies you weren't hitting in your datacenter that you might in the cloud (multicast, firewall rule differences, etc). Alternatively - are you building "weird" instances? (A lot of extra disks/NIC's/resources) Those can take a longer time just to find a spot where there's locality with all of your parts (but these days that's less common).
Otherwise, if it's bare metal, I'm usually still waiting for the ram to finish counting by the time I'm done with whatever cursed thing put me back in a cage.
I use busybox with a minimal init process, _REALLY_ minimal, which is beyond enough for a desktop.
Minimal init is super stable in time, rock solid, code is close to zero, aka near 0 maintenance, doing a good enough job.
But, GNU with some of its minions is waging war on busybox: for instance the steam client is not distributing a static ELF64 of bash (and it could easily), but does distribute _mandatory_ bash and not sh scripts, and those scripts are carefull of using GNU command only niche options... but the main steam client binary seems about to kill those script abominations... hopefully... but that steam client binary is a ELF32 binary expecting x11/GL... oooh god... (it should be a super clean ELF64 binary: only glibc libs in NEEDED entries with a 2017-2019 manual ABI selection, dynamically loading system interface sharde libs, and without too brain damaged or recent ELF relocations (aka serious professional elf/linux binary crafting).
> Minimal init is super stable in time, rock solid, code is close to zero, aka near 0 maintenance, doing a good enough job.
I run systemd on desktops and servers and I rarely do any maintenance at all on systemd either... I get a bunch of features for free though (like service management, parallel software boot)
And for broken software still using udev instead of direct linux kernel event (or inotify or file system polling), a fork of udev: https://www.rocketgit.com/user/sylware/mudev (had to do some fixing for all the attempts at breaking old udev to force people to use that abomination of systemd-udev).
The "abomination" word is fair.
This init is still using C99, I plan to move to RISC-V 64bits assembly interpreted on x86_64, but this is a goal on the very long run. I wish for RISC-V success all over the board (desktop/server/mobile/embedded/etc). Because, ultra high complex languages with their very few compilers are a problem for real-life alternatives and because of "conveniently backdoored machine code generation with correct high level language code"...
I use runit to manage various service groups for projects (e.g. last week, everything I was running at Bornhack camp). It simply does what it needs to do. It can be used in any context and doesn't need to take over the system. I recommend trying it out, especially if you think the complexity of systemd is needed.
I've seen quite a bit of systemd-free embedded distributions (like OpenWrt et al).
But I'd like to see more general-purpose embedded-focused distribution with systemd. The only ones I know about are the special-purpose LibreELEC/Jelos/Rocknix/Lakka variants.
It'd be nice to see such a distribution, but with proper package management. I was hoping https://distr1.org/ would become this, but it seems like it's been more or less abandoned.
Systemd is sometimes very slow or unusable, compared to a very direct approach of just executing eactly what you need to initialize the system and then watching kobj events or netlink events yourself instead of using udev.
On one of my systems, systemd takes 40s vs a simple script with `mount` and other commands, which takes just ~200ms. And it also fails to reload, because system has "too little RAM".
It's more flexible, but that flexibility has a huge cost on smaller systems.
There are lot of things that are bizarrely still hard in 2024.
Formatting floating points as strings with maximum precision, for example.
I sometimes find myself rooting for another AI winter so that more talented computer scientists have nothing better to do than to go back and clean up these messes
> Formatting floating points as strings with maximum precision, for example.
That’s not hard to do[1]—rather, it’s hard to do fast (that is, without treating your CPU as a fast 8-bitter, which it sucks at being, comparatively speaking). The other direction is surprisingly difficult, though[2].
Or maybe I didn't get the point of this. It doesn't look to me like this is one of the regular rants against how systemd destroys everything. But I could be wrong about that?