[Toybox] Which distro?

[Rob Landley]

On 11/16/25 13:00, zyxhere💭 wrote:
> On Wed, 2025-09-17 at 23:22 -0500, Rob Landley wrote:
>> On 9/17/25 12:08, zyxhere💭 wrote:
>>> Hi Rob what distro do you use, your youtube videos seem to suggest a
>>> glibc one tho you look more like an alpine guy.
>>
>> On my laptop?
>>
>> $ cat /etc/os-release
>> PRETTY_NAME="Devuan GNU/Linux 5 (daedalus)"
>> NAME="Devuan GNU/Linux"
> 
> https://beta.devuan.org/os/init-freedom suggests that it still defaults
> to sysvinit only?!

Why was that worth a "?!" ?

> I thought it would OpenRC as its the more popular
> one and is actually a service manager too.

You're always welcome to maintain a distro that does it your way if you 
don't like the way the existing volunteers do stuff for free.

> Or maybe you switch out it
> with OpenRC?

I don't, no. After the system comes up and x11 is running a desktop 
manager, the need to dynamically restart system services below that 
level which should never exit generally means something is wrong that 
should probably get noticed and be looked into. Silent failures hidden 
by retry aren't really my first choice.

But mostly I haven't had a strong opinion on this and was happy to let 
the people doing the work make that decision when it wasn't obviously 
fscking stupid like Ubuntu's https://wiki.ubuntu.com/DashAsBinSh or 
ubuntu's Mir or ubuntu's Unity or ubuntu's switch from upstart to 
systemd or... there's a reason I left Ubuntu.

> Actually looking at alpine they still use busybox as init

"Actually" they "still" use busybox as everything they can, last I 
checked. It was kind of the point of the distro.

Modulo the perennial "rewrite everything in rust" crowd, which somehow 
never wants to write a thingy-ng and migrate over it but instead 
introduce rust into existing projects so you have two contexts withing 
the same runtime and a glue layer performing translation and handoffs, 
all in the name of "security". Which is not how security has ever 
worked, but they feel they are "owed" existing projects and must 
therefore infect and convert them, so...

https://www.phoronix.com/news/sudo-rs-security-ubuntu-25.10

Security!

> but OpenRC on top as a service manager, Gentoo also still defaults to
> sysvinit with OpenRC on top of it.
> But I have heard rumors OpenRC will be removing the abiity to do so
> because it apparently causes issues for the new features they want to
> implement.

Yeah, systemd didn't want to interact with other people's code either. 
One big hairball, playing the katamari damacy theme as it expands and 
consumes. Always a good sign.

>> I've got various other distros in VMs I run under kvm: currently
>> Freebsd-14.2, alpine 3.19.1, archlinux-2021, linuxmint-21.2-xfce, fedora
>> 36, and xubuntu 22.04. Plus redhat 9 and redhat 6 from the dawn of time
>> (and knoppix 3.6 and 6.7) in case I want to ask historical questions,
>> and some non-x86 debian and buildroot images to run under qemu in case I
>> want to see how other systems handle something on an architecture (but
>> that's WAY slower than kvm).
> 
> With the qemu-user chroot thing or qemu-system-* still?

The presentation I gave on this is just about old enough to vote:

https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu?slide=59

Sigh, I know I gave multiple explanatory rants on all this stuff over 
the years, but ever since Prabhakar Raghavan unseated Ben Gomes, Google 
can't find anything anymore...

System emulation is reliable. Application emulation is WAY more 
complicated and brittle. It's not just "translating syscalls": normal 
read and write syscalls to "/proc" provide different information on 
different systems. And even when it IS an obvious syscall: if I make a 
uname() syscall should the emulator replace the results or pass them 
through unmodified, so will the result say it's host or target 
architecture" which are just judgement calls as to which is right in a 
given use case. Plus buckets of sharp edges like like differing mmap 
page granularity padding out the end of an allocation size where it's 
easy to know what the right answer is and hard to make it DO that.

With system emulation, you have a fake processor running a real target 
kernel and anything that kernel says is correct within that context, and 
then all I/O data goes through simple drivers into simple device 
emulations in a way that general purpose translations usually already 
exist and are well-tested and it's conceptually easy to understand what 
SHOULD happen at each step.

Then for builds I used distcc to get some of the speed back.

> I did the
> mistake of compiling gcc in an arm64 qemu chroot once instead of using
> a cross-compiler (took two days on my laptop)

Back in the day I had the performance quite reasonable on 20 year old 
hardware, building the whole of linux from scratch natively on a dozen 
different architectures all under qemu-system:

https://github.com/landley/control-images/tree/master/images/lfs-bootstrap/mnt

The distcc trick starts on slide 217 of the old presentation I linked 
above, and was also explained in comments in the scripts implementing it:

https://github.com/landley/aboriginal/blob/master/host-tools.sh#L141

I wrote up a LOT of documentation for that old project:

https://landley.net/aboriginal/about.html

I also blogged when I was working out how to do that, in entries like 
https://landley.net/notes-2008.html#30-01-2008 and 
https://landley.net/notes-2008.html#07-06-2008 and so on. (There was an 
aboriginal linux mailing list back in the day, web archive's still up: 
http://lists.landley.net/pipermail/aboriginal-landley.net/ .)

Somewhere I have a blog entry where I determined that statically linking 
busybox made autoconf run 20% faster under qemu because it did less 
dynamic translation each executable launch, but maybe that's so old it 
was on landley.livejournal.com. (This was probably back before 
relocations were rigorously grouped into PLT and GOT tables but were 
instead scattered through the code so it would traverse a list and dirty 
a whole bunch of pages and then qemu had to re-translate the entire 
page: self modifying code is hell on dynamic translation. This was also 
before https://landley.net/qemu/2008-01-29.html#Feb_1,_2008_-_TCG and I 
haven't re-benched since, but I doubt that improved it. 
https://unix.stackexchange.com/questions/55846/elf-shared-libraries-motivation-for-the-plt 
makes it sound like DF_TXREL was involved? It was very long ago and 
"just use static linked binaries" was consistently faster in testing so 
I didn't dig _that_ far into why or how it changed over the years...)

But yeah, native builds under emulation with distcc calling out to the 
cross compiler on the host would always boil down to each package going 
"autoconf runs for 5 minutes, then the actual compile takes 12 seconds" 
or some such. (I had metrics back in the day, easy to have the scripts 
"touch TIMESTAMP-$BLAH" at each stage and then do math on the timestamps.)

Sigh, I have observed that you can sing "autoconf is useless" to "every 
sperm is sacred" on mailing lists for DECADES but if you google for 
"autoconf is useless every sperm is sacred" you get one hit (that isn't 
me) with "missing: sperm sacred". (Checking ecosia.org at least finds 
https://www.landley.net/notes-2023.html#13-07-2023 and such, but I 
specifically said this on things like the busybox mailing list, which 
Google could find 5 years ago. I miss Google.)

Anyway, I have blathered at GREAT LENGTH about this over the years but 
whether it was https://www.youtube.com/watch?v=Sk9TatW9ino or 
http://free-electrons.com/pub/video/2008/ols/ols2008-rob-landley-linux-compiler.ogg 
or what I no longer remember, and Google died.

>> Plus I ssh to various other systems. (This laptop is slow and ancient,
>> sometimes I borrow a newer 32-way SMP machine to rebuild all the
>> toolchains and mkroot targets WITHOUT leaving it all running overnight...)
>>
>> Rob
> 
> I forgot to ask the most important question! What desktop environment!!

xfce, largely because basically it's the same now as it was 20 years 
ago. (If I get in a car and it has a joystick instead of a steering 
wheel, I get out again.)

Rob