Fedora Linux devs discuss dropping 32-bit packages – bad news for Steam gamers | Hacker News Reader

Fedora Linux devs discuss dropping 32-bit packages – bad news for Steam gamers

gamingonlinux.com

30 pointsspeckx23 comments

Is Steam even dependent on 32bit distribution packages anymore? Doesn't it ship with its own whole set of 32bit libraries? If I look at my running Steam processes currently, it's all a huge stuff of wrappers, alongside the steamwebhelper binary, which however is 64bit. So I'm not sure at all if removing 32bit distribution packages would even be a problem nowadays. Even back then, you had to convince Steam to use system libraries by using things like STEAM_RUNTIME_PREFER_HOST_LIBRARIES=0 or similar.

Steam bundles a lot of 32-bit libraries, but still requires at least 32-bit glibc, mesa, and libgl to be provided by the system among others. AFAIK this is for ABI reasons, they wouldn't be able to ship these with Steam without also running 32-bit software in some sort of containerization runtime. I believe the compromise when Ubuntu dropped 32-bit support was that Canonical would still provide the 32-bit versions of specifically the packages required for Steam to work. I hope that Valve will work out a similar compromise with Red Hat. The problem Valve faces is that there's thousands of 32-bit Linux games on Steam, so dropping support for 32-bit means that users would see a lot of games they used to play stop working.

Doesn't flatpak solve this?

Yes, that's what I do on Arch. I don't have multilib enabled and manage to run everything just fine.

Another solution is Conty[0] which is a download-and-run containerised Steam based on Arch; I use it to run games on Slackware without multilibs, and it's worked flawlessly so far.

However, it seems Arch are also dropping multilibs as a dependency of Wine, and moving to WoW64[1], with "reduced performance for 32-bit applications that use OpenGL directly".

What this implies for Steam on Arch (and hence for Conty) I'm not sure, though as of May some Proton versions have a PROTON_USE_WOW64 env var according to [2], so maybe multilibs can already be avoided running Steam natively anyhow.

0: https://github.com/Kron4ek/Conty

1: https://archlinux.org/news/transition-to-the-new-wow64-wine-...

2: https://github.com/ValveSoftware/Proton/issues/6889 (comment from artemyto on May 3)

It seems like all the 32bit stuff could be wrapped in a container of some sort. Part of the issue, as I understand it, is that the Steam client itself is still 32bit. I don't understand why they are still doing that.

It's odd since they updated to 64 bit to run on macOS when they dropped 32 bit years ago and haven't transitioned to Apple Silicon native yet but I imagine they will when Apple drops support for Intel next year.

Maybe a bit of "if it's not broke don't fix it." Not like moving to 64 bit would see any real improvement in their client.

Assuming Valve won't drop macOS completely at this stage. Most of the games for Mac in Steam aren't even Apple Silicon native, if I'm remembering correctly.

Also dropped Mac support entirely in Counterstrike. The previous versions were Mac-native (no translation layers) but still ran noticeably worse than in Windows.

There are definitely enough people playing on Mac's to justify continued support of the client. Plus developers are still making macOS ports. The Mac App Store isn't very popular for games and most gamers tend to prefer Steam still. So that's just money on the table.

Valve hasn't updated their own games but that's a whole a different calculation. Wouldn't be surprised if they never update those to run on Apple Silicon or whatever else they change to in 10 years.

Apple Silicon support is currently in beta.

What happens to 32-bit Wine?

I'm not sure what it does because it's impossible to Google this, but I was able to make a 32-bit bottle and run 32-bit Windows programs on my Apple Silicon Mac of all things using PlayOnMac's "32on64" Wine builds. Like, Steam and GTA IV both ran.

This means ironically my Mac is more compatible with old Windows software than old Mac software.

Wine supports WoW64 since recently [1]

[1] https://www.phoronix.com/news/Arch-Linux-WoW64-Wine

Does this affect Proton?

from the article:

> Steam is huge and requires 32-bit to work properly for the client and for Proton / Wine

It’s time to rip off the bandaid and force everyone to get on the bandwagon. What’s a single reason to keep 32 bit packages? It’s dragging Linux down in general to have such zealotry about compatibility with things built in 1994

There must be some compromise that would still allow 32-bit programs to run if needed. Windows has WoW64 for example. Even 64-bit Intel can be seen as technical debt at this point, but both the Apple Silicon macOS and the ARM Windows provide translation layers for it.

> What’s a single reason to keep 32 bit packages?

They don't take up much space and mostly just require compile time.

That'd be the main reason to keep them around.

As far as the drag on linux, AFAIK there's really no drag caused by having 32bit binaries floating around. There's more drag in supporting really old architectures like the Pentium 2.

Yeah I don't understand this argument of "it's holding back the platform". Keeping around 32 bit makes the platform better since it keeps more software usable and relevant. Even if it hasn't been touched in ages.

I wish Fedora was in it's own bubble where its decisions didn't affect anything else but as we've seen numerous times what happens in Fedora eventually cascades through the other major distro's as well.

> What’s a single reason to keep 32 bit packages?

Perhaps not every package is needed, but you need some 32-bit support for games.

>> Linux distro developers may not like it, but Steam is huge and requires 32-bit to work properly for the client and for Proton / Wine.

Steam ships its own runtime that has all the required 32bit libs for proton and linux games, valve only really has to update steam client to target 64bit

No, the graphics stack needs to be native and in sync for obvious reasons, and that includes the mesa libraries. What can be in the runtime is already in the runtime.

Reply on news.ycombinator.com