Hacker News new | ask | show | jobs
by sylware 700 days ago
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).
3 comments
znpy 700 days ago
> 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)

link
kesor 700 days ago
Which minimal init process? The one that comes builtin in busybox?

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

link
sylware 700 days ago
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"...

link
liveoneggs 700 days ago
no one ever accused GNU of having taste
link