Live data from Hacker News

Bazzite would shut down if Fedora goes ahead with removing 32-bit

gamingonlinux.com

31–40 of 61 posts

Re: Bazzite would shut down if Fedora goes ahead with removing 32-bit

#31

Nothing is stopping apps from shipping with 32 bit libraries if they need them. This isn't like what happened with ARM where processors dropped support for 32 bit code.

That's always a good choice but

1. They need to also keep the multi arch support enabled in their kernels 2. Apps such as games and steam depend on Mesa, and you don't really want to ship Mesa

A good compromise would be for Valve to support Flatpak for Steam, but if they can't be bothered to build a 64 bit Steam they sure don't want to bother with that

Re: Bazzite would shut down if Fedora goes ahead with removing 32-bit

#32

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.”

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.

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 ;)

Re: Bazzite would shut down if Fedora goes ahead with removing 32-bit

#33

Bazzite maintainers have access to the source code of these libs, they can totally compile and distribute 32bits versions of them. Title should really be: Bazzite maintainers don't want to make a slight effort to maintain stuff.

It's absolutely this. They have the ability to put these into their build pipelines and include them. Or just grab the latest 32bit versions and just use those.

It's work for them surely. But it's not the end of the world.

I think we have all solved much harder problems as software engineers.

Re: Bazzite would shut down if Fedora goes ahead with removing 32-bit

#34

Bazzite maintainers have access to the source code of these libs, they can totally compile and distribute 32bits versions of them. Title should really be: Bazzite maintainers don't want to make a slight effort to maintain stuff.

Also their days are counted as SteamOS is now going to other handheld devices apart from the Steam Deck so... Not sure their project will still exist one year down the road.

Re: Bazzite would shut down if Fedora goes ahead with removing 32-bit

#35

Bazzite maintainers have access to the source code of these libs, they can totally compile and distribute 32bits versions of them. Title should really be: Bazzite maintainers don't want to make a slight effort to maintain stuff.

"slight effort" seems disingenuous, given this quote from the source thread:

> If this shipped today, to accomplish this we’d need to:

> 1: Build all of the packages Steam needs in a copr or similar

> 2: Build a custom version of Proton with experimental Wow64 features turned on

> 3: Instruct all users to manually change their steam settings to use that proton version because the ones Valve provides don’t have that.

> 4: Tell anyone using OBS game capture that they’re just gonna have to give up.

Re: Bazzite would shut down if Fedora goes ahead with removing 32-bit

#38

Nothing is stopping apps from shipping with 32 bit libraries if they need them. This isn't like what happened with ARM where processors dropped support for 32 bit code.

Actually, there are some things. libGL/libVK for OpenGL and Vulkan support is a big one, you need that to be fitting the exact version of your kernel Nvidia driver if you are using Nvidia cards. Of course all other vendors play nice with Open Source and Mesa libs, but especially for gaming, a lot of people unfortunately still buy Nvidia. Games cannot just ship their own 32bit libGL for reasons of license and versioni…

This wouldn't work well with Mesa, either.

On Windows, this is like telling game developers that they need to ship all the graphics drivers for their games. Let's skip the hassle for the developers' side. For the users, not only would that be a situation where you could no longer update your own drivers to fix problems, it would be a compatibility nightmare and likely introduce new problems because of interactions with the system drivers and kernel level.

Post reply on HN