[Toybox] Which distro?

[enh]

On Wed, Nov 19, 2025 at 2:04 PM Rob Landley <rob at landley.net> wrote:
>
> 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"

to be fair, i'm pretty sure that's the default autoconf experience...
it's always a joy to see 127 of my 128 cores idle through the endless
"configure" part and then the "make" part being so fast i can barely
measure it.

(especially because the configure part is the part that's most likely
to fail and need you to retry [for stuff you don't actively work on
yourself], so you get to see it over and over. and while cmake's
equivalent system's caching helps with that, caching brings the usual
set of cache invalidation problems.)

> 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net