Live data from Hacker News

BusyBox: Life Without Systemd (2018)

busybox.net

21–30 of 37 posts

Re: BusyBox: Life Without Systemd (2018)

#21

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.

Re: BusyBox: Life Without Systemd (2018)

#22

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.

Re: BusyBox: Life Without Systemd (2018)

#23
post #7

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.

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

Re: BusyBox: Life Without Systemd (2018)

#24
post #11

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 no…

no one ever accused GNU of having taste

Re: BusyBox: Life Without Systemd (2018)

#25

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.

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

Re: BusyBox: Life Without Systemd (2018)

#26

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.

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.

Re: BusyBox: Life Without Systemd (2018)

#27

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?

[dead]

Re: BusyBox: Life Without Systemd (2018)

#28
post #22

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 c…

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.

Re: BusyBox: Life Without Systemd (2018)

#29

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.

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.

Re: BusyBox: Life Without Systemd (2018)

#30
post #20

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…

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.

Post reply on HN