The future of 32-bit Linux

Thanks for the feedback. I agree I could have expanded the section on compat mode, which is indeed an extremely important tool for reducing memory usage on 64-bit machines, and should in my opinion be the default on any machines with less than a few gigabytes of RAM.

For the performance benefit of running 32-bit code, the tradeoff is less clear than you describe it. While there are obvious benefits to running smaller code because of cache footprint, TLB usage and and memory interface limits, the two most common architectures also benefit a lot from running 64-bit code: on x86, 32-bit mode is limited to eight general-purpose registers compared to 16 on 64-bit, and on Arm, you go from 16 to 32 registers as well as a more modern instruction set. Unlike other traditional architectures (powerpc, sparc, mips, parisc, s390), this means you only get the clear performance benefits when you run the 64-bit instruction set with an ILP32 toolchain (x32 in case of x86). As I described, these have largely failed to gain traction despite being faster, because of the cost of maintaining a third set of binaries in addition to the ones that are already needed.

Even the mixed 32/64 environments are on their way out in common distros. This used to be common in Android and ChromeOS and well supported in Red Hat, SUSE, Ubuntu and others, but these days the binary distros either only offer full builds for 64-bit or like Android always pick the 64-bit binaries when both are available. Debian is the most notable exception of course, allowing to mix and match binaries from three different targets (arm64/armhf/armel or x86_64/i386/x32) plus more if you count qemu-user. A more common and more practical way of mixing nowadays is to use containers to e.g. run a 32-bit Debian or Adelie docker image on an Arm64 or x86-64 host, as this avoids tricky library dependencies. Note also that a mixed root file system is less portable on Arm as it does not work on modern aarch64-only processors, and it adds overhead for keeping two sets of shared libraries on disk and in memory, but that is a similar overhead to any container setup.