Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BusyBox: Life Without Systemd (2018)

busybox.net

Post reply on HN
Print view View original

31–37 of 37 posts

Re: BusyBox: Life Without Systemd (2018)

#31

Post by znpy »

sylware wrote: 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…

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

Re: BusyBox: Life Without Systemd (2018)

#32

Post by dark-star »

tapoxi wrote: post #7
dark-star wrote: post #5

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.

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

Re: BusyBox: Life Without Systemd (2018)

#33

Post by kesor »

sylware wrote: 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…

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

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

Re: BusyBox: Life Without Systemd (2018)

#34

Post by sylware »

kesor wrote: post #33
sylware wrote: 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…

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

Re: BusyBox: Life Without Systemd (2018)

#35

Post by mkoubaa »

arnaudsm wrote: post #15
mkoubaa wrote: post #9

Earlier quoted context omitted.

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

No one ever got promoted for reducing tech debt. It's better to ship fast and forget, and cash out before the system collapses years later. Unfortunately this is not exclusive to software.

As a counterexample, I've been promoted for reducing tech debt

Re: BusyBox: Life Without Systemd (2018)

#36

Post by bryango »

dark-star wrote: post #32
tapoxi wrote: post #7

Earlier quoted context omitted.

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

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.
Post reply on HN