Linux 6.7 Will Let You Enable/Disable 32-bit Programs Support At Boot-Time

[phoronix]

Phoronix: Linux 6.7 Will Let You Enable/Disable 32-bit Programs Support At Boot-Time

From the perspective of Linux distributions trying to reduce their attack surface while still making it possible for users to run legacy software without recompiling their kernel, SUSE has spearheaded the effort for boot-time enabling/disabling of x86 32-bit support for whether 32-bit user-space programs and 32-bit system calls can be executed. That code has been submitted for the imminent Linux 6.7 merge window...

https://www.phoronix.com/news/Linux-6.7-IA32-Emulation-Boot

[pkese]

Are there any 32-bit executables included in any of the modern Linux installations (e.g. a typical Ubuntu or Fedora install)?

[Gps4life]

One user case I can think of are 32bit VST. Although you need wine 32bit for those.

https://www.youtube.com/watch?v=Y3GVvO4UeFk&ab_channel=AnonymousMusician

[avis]

Are there any 32-bit executables included in any of the modern Linux installations (e.g. a typical Ubuntu or Fedora install)?

In fedora zero i686 packages are installed by default. Not even glibc.i686 which is the prerequisite for pretty much all i686 applications and libraries.

i686 support is there if you need it. Unlike with Ubuntu and Debian where you need to run some magical commands to make it possible to install i686 stuff, in fedora you just

sudo dnf install something.i686

and you're all set.

[oiaohm]

Are there any 32-bit executables included in any of the modern Linux installations (e.g. a typical Ubuntu or Fedora install)?

Steam and Wine users are the two most common to need 32 bit Linux.

Wine with hangover work is reducing it dependency on 32 bit syscalls and 32 bit libraries. The wow64cpu.dll of hangover does allow doing i386 protected mode with 64 bit wrapper to kernel and syscalls on Linux kernel(yes running 32 bit windows applications without using Linux 32 bit syscalls). Basically the same way win16 applications work on the Linux kernel but instead of thunking from 16 bit protected mode to 32 bit protected mode you are now thunking from 16 and 32 bit protected mode to 64 bit protected mode. This is still work in progress.

Steam you have wine and old Linux game problem and the fact the Linux steam client application is still 32 bit.

[sophisticles]

I am surprised that towards the end of 2023 there is still the need to run 32-bit apps on a 64-bit OS.

Especially on Linux, where nearly all the apps people run are open source, why would a developer choose to keep something 32-bit?

[cjcox]

I still play UT2004 even today. Still one of the greatest native game ports to Linux.

[Weasel]

Steam and Wine users are the two most common to need 32 bit Linux.

Wine with hangover work is reducing it dependency on 32 bit syscalls and 32 bit libraries. The wow64cpu.dll of hangover does allow doing i386 protected mode with 64 bit wrapper to kernel and syscalls on Linux kernel(yes running 32 bit windows applications without using Linux 32 bit syscalls). Basically the same way win16 applications work on the Linux kernel but instead of thunking from 16 bit protected mode to 32 bit protected mode you are now thunking from 16 and 32 bit protected mode to 64 bit protected mode. This is still work in progress.

Steam you have wine and old Linux game problem and the fact the Linux steam client application is still 32 bit.

You forgot to mention that wow64 has overhead. If you have 32-bit libs installed and your Wine is compiled with support for them, it's better since it will be faster.

[ayumu]

I'd argue for 32bit disabled by default. Much safer.

The minority (because it is a minority) that need to run old binaries or steam games and can't or won't just use qemu for performance reasons can just add the parameter to their Linux commandline.

[Sonadow]

In fedora zero i686 packages are installed by default. Not even glibc.i686 which is the prerequisite for pretty much all i686 applications and libraries.

i686 support is there if you need it. Unlike with Ubuntu and Debian where you need to run some magical commands to make it possible to install i686 stuff, in fedora you just

sudo dnf install something.i686

and you're all set.

Debian's approach to multiarch is a lot more elegant and well thought out IMO.

In RPM distributions you get /lib and /lib64, and in source-based distributions you get /lib and /lib32. Both of which split /lib into two different directorys

Debian's approach is to maintain /lib and put the arch-specific stuff into subdirectories like /lib/x86-64-linux-gnu, /lib/i686-linux-gnu, /lib/aarch64-linux-gnu etc. Which makes it infinitely more extensible than lib and lib64, or lib and lib32.