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)

from the article:

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

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.

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

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.

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