On Wed, Nov 19, 2025 at 2:04 PM Rob Landley <[email protected]> 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 > [email protected] > http://lists.landley.net/listinfo.cgi/toybox-landley.net _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
