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.
ndiddy · 3h ago
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.
jdboyd · 5h ago
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.
jajuuka · 4h ago
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.
TheAmazingRace · 4h ago
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.
frollogaston · 53m ago
Also dropped Mac support entirely in Counterstrike. The previous versions were Mac-native (no translation layers) but still ran noticeably worse than in Windows.
goosedragons · 3h ago
Apple Silicon support is currently in beta.
DiJu519 · 7h ago
Doesn't flatpak solve this?
ttctciyf · 6h ago
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.
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.
delduca · 6h ago
Does this affect Proton?
progval · 5h ago
from the article:
> Steam is huge and requires 32-bit to work properly for the client and for Proton / Wine
jekwoooooe · 5h ago
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
cogman10 · 5h ago
> 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.
jajuuka · 4h ago
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.
yjftsjthsd-h · 4h ago
> 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.
Cloudef · 4h ago
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
frollogaston · 5h ago
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.
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.
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)
[1] https://www.phoronix.com/news/Arch-Linux-WoW64-Wine
This means ironically my Mac is more compatible with old Windows software than old Mac software.
> Steam is huge and requires 32-bit to work properly for the client and for Proton / Wine
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.
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.
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.