BusyBox: Life Without Systemd (2018) | Hacker News Reader

BusyBox: Life Without Systemd (2018)

busybox.net

49 pointsbryango31 comments

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?

Busybox is designed for extremely minimalist and embedded use cases, so they have a legitimate reason for avoiding systemd as a dependency.

I made a small busybox based statically compiled distro which used busybox init, busybox init is basically just a bunch of shell scripts

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 "..."`).

You can make similarly small deployments with systemd. I’m not sure it’s that legitimate

yes, I know, but the linked page does it on a Fedora Desktop system. Not exactly what anyone would use for a stripped down embedded system

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.

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.

Just using the standard image they provide for Kubernetes.

I didn't do the work of reverse-engineering all the bloat that's in there.

Because they do a lot of stuff some is complex.

> If it's not gonna boot fast, I don't see the point of replacing straightforward shell scripts.

If you do a lot of stuff and have a complex boot shell scripts are neither fast nor 'straightforward'.

Why?

Systems don’t just boot slowly “in general”, there’s specific things happening slowly and if you know exactly what the you can fix it.

such instances might be booting more than once.

One for general startup expanding the root fs to the available boot disk size, one more to run cloud-init or equivalent, and the a final more.

Then again, depending on what services are actually enabled... It might take a bit more to become available/ready/green for use.

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).

no one ever accused GNU of having taste

> 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)

Which minimal init process? The one that comes builtin in busybox?

https://github.com/mirror/busybox/blob/master/init/init.c

Nope, I wrote one a decade ago...

https://www.rocketgit.com/user/sylware/muinit (ofc not on github, but on a git repo with noscript/basic (x)html clean support).

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"...

http://web.archive.org/web/20240724001825/https://www.busybo...

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.

Not an embedded linux guy, but from what I hear yocto is the kinda default option for embedded linux nowadays.

From what i read at https://docs.yoctoproject.org/dev-manual/init-manager.html (quick google search) you should be able to configure it to use any of sysvinit, busybox init or systemd.

Funny that the url is https://www.busybox.net/kill_it_with_fire.txt

Compiling mininal version of systemd init and systemctl is not that hard. Static with musl libc.

In 2024 it is not worth to deal with alternative init systems.

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.

Reply on news.ycombinator.com