On 11/12/25 12:27, Adrian Bunk wrote:
We are already providing a non-PIE version of the Python interpreter for users who need it for performance reasons, and it is for example possible that the benefits of providing packages without hardening (for situations where hardening is not necessary) might bring larger benefits than architecture-optimized versions.
Long ago when I was doing https://landley.net/aboriginal/about.html (work which eventually allowed Alpine to be based on busybox), I benched that statically linking busybox let the autoconf stage of package builds complete about 20% faster under qemu.
(My theory was lazy binding patched out the PLT indirection on the first call which dirtied the executable page and forced QEMU to discard the native code cache and retranslate it, often multiple times as multiple indirections were dynamically patched. I later found it hilarious that the dynamic linking people went on to do snap and flatpak and so on, using FAR more space for no obvious gain...)
Does that mean static linking is faster everywhere? Dunno, I haven't tried "everywhere". You can't "optimize" without saying what you're optimizing FOR, and the ground changes out from under you.
Loop unrolling was an optimization, then became a pessimization when cpu caches showed up, then an optimization again when L2 caches showed up, and the pendulum went back and forth multiple times before I stopped trying to even track it sometime around when branch prediction turned into a security hole and people started doing TLB invalidation mitigations for it. My takeaway lesson was outside of tight inner loops, do the simple thing and let the hardware and optimizers take care of themselves.
I do know I left the Red Hat world for the Debian world when the new Fedora CD wouldn't install on the Pentium Pro I had at the time (because they'd "moved on" to an architecture newer than the hardware I was still using).
I had to learn what x86-64-v1 vs v2 were when an android NDK update made all binaries it produced segfault on my netbook. I cared because I was maintaining their command line utilities, and it was nice to be able to actually test that environment. But I didn't discard my hardware to humor the change, I just ran my test binaries under qemu until that netbook died...
There was talk back then (what, 2018?) about teaching repositories to know about various architecture flags so it could pull optimized packages for your machine, but the discussion petered out because the gains were small and the overhead was huge.
> Would x32 optimized for v3 be the best option for many use cases?It would prevent the x86-64-v2 laptop I'm typing this on from running those binaries, but I've already talked to the netbsd guys and to them running on systems people want to use their stuff on is a point of pride. Like it used to be on Linux, before everybody got old and tired and needed to lighten the load.
Decisions have costs. It's your call to cull your herd and chastise the outliers, but it usually means some subset will move on to things that are still fun.
It's an interesting move giving ultimatums to people who never got forced onto windows and never moved to GPLv3. Not "I am stepping down from this and going this way instead", but "xfree86 is now under this new license, you will all comply hey where are you going"...
*shrug* You do you. Rob