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