Don't care. When will it obey window manager hints like every well mannered software does?
Linux Gaming
Discussions and news about gaming on the GNU/Linux family of operating systems (including the Steam Deck). Potentially a $HOME away from home for disgruntled /r/linux_gaming denizens of the redditarian demesne.
This page can be subscribed to via RSS.
Original /r/linux_gaming pengwing by uoou.
No memes/shitposts/low-effort posts, please.
That includes posts generated by LLMs. It doesn’t matter if you “don’t have the time” or “would’ve written the same anyway”, or if “everyone’s doing it geez get with the times”.
For now it’ll also include “AI”-assisted projects that haven't had at least two months of (public, verifiable) dev time behind them.
Resources
Help:
- ProtonDB
- Are We Anticheat Yet?
- r/linux_gaming FAQ
- Fork of an earlier version of the above
- PCGamingWiki
- LibreGameWiki
Launchers/Game Library Managers:
General:
Discord:
IRC:
Matrix:
Telegram:
Hopefully one day the steam library and store will be separate.

Huh, I didn't know gifs could have audio.


Great news, no more headache with 32bit libraries. Now we need wayland support to get rid of xwayland and anything xorg as well.
I assume we'll still need the 32 bit libraries to play 32 bit games, which at this point is probably just older games that will never be updated. I guess it depends on what you like to play, but I'll be stuck with them for some time yet.
You still won't get rid off xwayland because there are native linux games that use X11, but xwayland can be moved from compositor into xwayland-satellite thing
Now we need it and Proton to support wayland and we're good
Technically Proton supports Wayland. It's just not the default. You can override it with a launch flag to use Wayland.
finally
Kinda funny to think that I won't be living through any more migrations to the next power of 2. They happened so rapidly at first.
Each "bit" in the architecture is mainly related to how many different memory positions you can address with a CPU opcode (i.e. an assembly command) that needs to access memory or with a CPU register that holds an memory address (so an 8 bit register can only address 256 memory positions, a 16 bit one 65,538 memory positions, a 32 bit one 4,294,967,296 memory positions and so on) - basically every additional bit in the register size of a CPU that addresses memory roughly doubles the memory that CPU can access and thus use (not considering hacks to go around those limits, such as the Spectrum 128K had).
Meanwhile Moore's Law predicts that "the number of transistors in an integrated circuit doubles about every two years" which for integrated circuits roughly means that every two years the amount of memory that can be in the same integrated circuit area doubles.
So if Moore's Law kept working, each architecture bit roughly gives you two more years until the availability of memory catches up- This means that the transition from 32-bit to 64-bit architectures per Moore's Law gave us 64 years until we have to move to an architecture with more bits because memory available is so big that CPUs are unable to use so much memory.
Were we are now, 64 bits is enough to address 8 Exabytes of memory.
That said, extrapolating from the current trend in growth of memory in PCs, we will reach the point when we will start hitting the constraints of that in ... NEVER - thanks to the AI bubble the newer PCs are coming out with the same or less memory than the previous generation, so the trend of available memory is not upwards but downwards.
Moore's Law finally caught up with our ability to make rocks calculate for us. It was going to happen eventually, I find it somewhat comforting that hardware has finally plateaued, and will only get incremental changes for a while. It means that the next computer I build, I can expect it to last for multiple decades, rather than just one.
Ohh fear not! Hardware didn't plateau. Our current architectural needs plateaued. We're still doing everything on 2d layers layers in a way that makes things organized. I'm sure they'll shove AI in there and the next gen stuff will be unsupportable chaotic 3D tetris stuff and the memory/bus sizes will be old hat.
The thing is though that now build quality is going to matter WAY more. Like you need that laptop chassis built like a tank. Which is harder to find in new devices these days.
Yeah, and power supplies and such that aren't limited by silicon but capacitor cycling are going to matter more and be limiting factors. Replaceable batteries and power management in phones, laptops, etc are going to be crucial
Does this mean I won't need the multilib Arch repo anymore? Or at-least after it has matured enough to not need 32bit stuff?
wrong, instead it is still 32 bit, but now it is running under steam's own runtimw which has 32bit libs, just like the games
wrong, instead it is still 32 bit
With this first part of your sentence you are directly contradicting the words in the primary source, so do you have good evidence for this?
For reference here's the relevant part from the primary source:
Linux
- The Steam client is now a 64bit application.
- The Steam client now runs inside a Steam Runtime container.
- This will help the Steam client provide a more consistent experience across multiple distributions. This is the same technology used by Steam games.
Thank you. That's interesting and actually supports the assertion that some executables are still built in 32bit, this reaper thing in particular.
It also lead me to a requirements list explicitly containing the following:
Architectures:
- x86_64 systems must support multilib and have both 32-bit (x86, i386, lib32) and 64-bit (x86_64, amd64) versions of required libraries and graphics drivers installed
- 64-bit-only x86_64 systems are not supported
- 32-bit-only x86 systems are not supported
It's here: https://github.com/ValveSoftware/steam-for-linux/blob/master/README.beta.md
Found via this comment from what seems like a valve employee: https://github.com/ValveSoftware/steam-for-linux/issues/13015#issuecomment-6204720307
I feel like it's kinda the same thing, their application is now 64 bit in a sense that they don't need 32-bit dependencies, not in a sense that they changed anything in the real application
That sounds a little too made up. An application being a 64bit application ordinarily means that it uses 64bit executables and libraries.
Additionally Valve have been on this journey to drop 32bit for a while. Last November they published a 64bit beta for Windows, in December they switched the Windows version to 64bit, in January they dropped support for 32bit Windows.
At the moment I have no reason to believe they didn't compile the Linux version for 64bit architectures as well now. That's why I asked if furry toaster had any evidence. Maybe there is something to change my mind.
Noob question here, but what’s the benefit of moving an application like Steam to 64bit? I understand for memory intensive applications it allows for more memory usage (it was a big deal when Stellaris made the change) but does Steam often use more than 4 GB of memory?
The benefit to/for Steam itself is marginal. The benefit to the entire community is significant, because there's now an entire metric shitload of obsolete 32-bit shit that can be safely deleted and forgotten for 95% of the Linux world and efforts can be focused on things that actually matter in the 64-bit world. The entire 32-bit ecosystem of libraries and system layers still had to be maintained and supported basically only for Steam's sake, Steam was the only thing still using them for the vast majority of people. It's not that Steam needs 64-bit, it's that 64-bit is the standard now and has been for a long time, and Steam was the only thing that had no 64-bit version.
It's kind of like cutting loose the anchor that the community has been dragging around everywhere for years for no purpose. It was a totally unnecessary effort that just caused suffering and added no value.
Anyone know why it took so long? Wasn't important?
Wine couldn't run 32 bit games without 32 bit libraries. They added experimental support for WoW64 a few years ago and now it's considered stable. There was probably just no rush to make Steam 64 bit if it still needed 32 bit libraries for older games.
I asked WINE devs for WOW64 support back in XP 64-bit days. They argued about it and said no lol. Good to see it finally landed 20 years later.
VINDICATION!
Distros have been pushing really hard for this since Ubuntu in 2019, then fedora in 2025 because it's very hard to keep maintaining multilib and i686 for basically only wine and steam. So with this change we can finally get rid of that baggage.

