4 ms·

Seems like an extreme response… other distros still exist. Plus they can still ship the 32bit binaries themselves. Fedora isn’t preventing you from using 32bit

Seems like an extreme response… other distros still exist. Plus they can still ship the 32bit binaries themselves. Fedora isn’t preventing you from using 32bit libs- fedora is just saying “hey we aren’t going to invest energy in maintaining something just 5% of our users use.”

rightbyte 1y ago
I think the fundamental problem is that there are many different 5% groups and that you are very likely to be in some 5% groups. In some way I feel dropping 32bit is capitulation to bloat. I for one use 32bit libs in x86 32bit mode quite a lot to test software I build for memory bugs such that it works on actual 32bit systems.
- holowoodman 1y ago
  32bit support isn't just bad bloat due to larger pointers. Only doing 32bit and not doing amd64/x86_64 is also leaving a lot of performance on the table: x86 traditionally has very few registers to work with, amd64 gives you quite a few more general purpose registers, so your hand-fiddled assembler will be faster, and if you use compiled code, your compiler will have an easier time with optimizations, faster function calls due to more register arguments, less register-to-memory spills and more execution station parallelism. Memory use is also an important point, your 32bit application will be limited to at best 4GB per process, usually more like 2GB (due to the kernel/user boundary at 2/2GB, absent weird tricks). With games currently being multiple times that size, you have to swap out assets and load new ones very frequently, which is why loadpoints are getting more common and level design has to add more corridors and doors to support those load points and segment level data into 2GB chunks. And the newer processor features, especially SIMD stuff like AVX and SSE work better with 64bit registers, if they work at all. Many support libraries that can utilize SIMD only do so in 64bit versions. Some features aren't even available if the hardware is in 32bit mode. And compilers can do automatic SIMD conversions, but those work far better (if they work at all) in x86_64 mode because of the insufficient number of registers in 32bit mode for copying around and splitting up stuff from a SIMD register. I think the real reason that especially game developers are opposed to amd64 is that they used to be stuck on 32bit on Windows for a long time and now have to be dragged into the future by force ;)
  - BearOso 1y ago
    I don't think this is very much about modern projects. Developers want to use 64-bit. It's more that removing the libraries breaks legacy 32-bit stuff that simply can't be updated. The steam client should be upgraded, though. I understand it has to do with their ancient web view library not doing 64-bit, so they would have to change it and possibly mess up some of the layouts and overlays. But they went ahead and changed it on macOS anyway, so you know it can be done.
    - arkx 1y ago
      Isn't Steam (or more specifically steamwebhelper.exe) using Chromium Embedded Framework for web views? It's already a 64-bit process for me on Windows. I also do wish they'd upgrade the client completely, but WoW64 isn't going anywhere. It's probably discussions like this on Linux side that would move their hand, if anything.
  - pantalaimon 1y ago
    There is x32 if you don’t need more than 4 GiB address space but still want to use the benefits of amd64. Gives you ~10% better performance due to better Cache efficiency
    - holowoodman 1y ago
      Yes, but that would be another set of libraries and another recompilation. Sticking with 32bit code is mostly to avoid that.
rurban 1y ago
No, they said: we don't want to build all 32-bit packages no one is using. libs which are used by games and such will be kept. So they need to keep gcc, glibc and binutils for 32bit also. Just not multilib, i686 cross is good enough
- BearOso 1y ago
  Read the discussion. They plan to remove those libraries, too. Their current automated build system apparently requires they build i686 for every x86-64 package. They don't want to spend the effort to adjust the build system to just build a selection of i686 packages. They plan to drop the whole architecture. It seems like these developers have tunnel vision. It's like when pulseaudio came about and the whole focus was streaming Bluetooth audio. It took over the system audio and broke everything else (games, coincidentally). They know this will break some things they don't personally use, and they don't care.
  - linotype 1y ago
    Are there stats on the number of people who are still running i686?

rightbyte 1y ago

I think the fundamental problem is that there are many different 5% groups and that you are very likely to be in some 5% groups. In some way I feel dropping 32bit is capitulation to bloat. I for one use 32bit libs in x86 32bit mode quite a lot to test software I build for memory bugs such that it works on actual 32bit systems.

holowoodman 1y ago
32bit support isn't just bad bloat due to larger pointers. Only doing 32bit and not doing amd64/x86_64 is also leaving a lot of performance on the table: x86 traditionally has very few registers to work with, amd64 gives you quite a few more general purpose registers, so your hand-fiddled assembler will be faster, and if you use compiled code, your compiler will have an easier time with optimizations, faster function calls due to more register arguments, less register-to-memory spills and more execution station parallelism. Memory use is also an important point, your 32bit application will be limited to at best 4GB per process, usually more like 2GB (due to the kernel/user boundary at 2/2GB, absent weird tricks). With games currently being multiple times that size, you have to swap out assets and load new ones very frequently, which is why loadpoints are getting more common and level design has to add more corridors and doors to support those load points and segment level data into 2GB chunks. And the newer processor features, especially SIMD stuff like AVX and SSE work better with 64bit registers, if they work at all. Many support libraries that can utilize SIMD only do so in 64bit versions. Some features aren't even available if the hardware is in 32bit mode. And compilers can do automatic SIMD conversions, but those work far better (if they work at all) in x86_64 mode because of the insufficient number of registers in 32bit mode for copying around and splitting up stuff from a SIMD register. I think the real reason that especially game developers are opposed to amd64 is that they used to be stuck on 32bit on Windows for a long time and now have to be dragged into the future by force ;)
- BearOso 1y ago
  I don't think this is very much about modern projects. Developers want to use 64-bit. It's more that removing the libraries breaks legacy 32-bit stuff that simply can't be updated. The steam client should be upgraded, though. I understand it has to do with their ancient web view library not doing 64-bit, so they would have to change it and possibly mess up some of the layouts and overlays. But they went ahead and changed it on macOS anyway, so you know it can be done.
  - arkx 1y ago
    Isn't Steam (or more specifically steamwebhelper.exe) using Chromium Embedded Framework for web views? It's already a 64-bit process for me on Windows. I also do wish they'd upgrade the client completely, but WoW64 isn't going anywhere. It's probably discussions like this on Linux side that would move their hand, if anything.
- pantalaimon 1y ago
  There is x32 if you don’t need more than 4 GiB address space but still want to use the benefits of amd64. Gives you ~10% better performance due to better Cache efficiency
  - holowoodman 1y ago
    Yes, but that would be another set of libraries and another recompilation. Sticking with 32bit code is mostly to avoid that.

rurban 1y ago

No, they said: we don't want to build all 32-bit packages no one is using. libs which are used by games and such will be kept. So they need to keep gcc, glibc and binutils for 32bit also. Just not multilib, i686 cross is good enough

BearOso 1y ago
Read the discussion. They plan to remove those libraries, too. Their current automated build system apparently requires they build i686 for every x86-64 package. They don't want to spend the effort to adjust the build system to just build a selection of i686 packages. They plan to drop the whole architecture. It seems like these developers have tunnel vision. It's like when pulseaudio came about and the whole focus was streaming Bluetooth audio. It took over the system audio and broke everything else (games, coincidentally). They know this will break some things they don't personally use, and they don't care.
- linotype 1y ago
  Are there stats on the number of people who are still running i686?