There was a whole lot of discussion recently for the Fedora Linux proposal to drop 32-bit support, with the current plan being dropped.
I covered the initial proposal here on GamingOnLinux with the current problems it would cause, like how Bazzite would have been forced to shut. Thankfully, for now at least, the whole proposal has been withdrawn by the original developer that submitted it.
Writing in the Fedora forum feedback thread about it, the developer Fabio Valentini said:
Given feedback in this thread (and to a lesser extent, also on the mailing list) I have decided to withdraw this proposal.
It is clear that the Fedora 44 target for this Change was too early. To some degree, I expected this to be the case, and was prepared to move the proposed implementation of the Change to a later release. Fedora 44 was just the earliest “reasonable” target. However, I think this also shows an inherent conflict in the current Changes process - if a big Change (like this one) is submitted quite early (out of caution!), that also front-loads the discussion and decision process instead of giving things more time. For example, I don’t think the discussion would have been meaningfully different if the targeted release had been Fedora 46 instead of 44 - which is one of the reasons why I decided to withdraw the change instead of just re-targeting it at a later Fedora release.
I don’t think the problem that was attempted to be addressed with this proposal will go away. With more and more projects dropping official support for building / running their software on 32-bit architectures, it’s just going to get worse over the next few years. Dealing with widely used software falling out from under our feet won’t be fun. To some degree, always pushing the latest and greatest
software in Fedora is also working against us here - if we just stuck with foo 1.0 LTS for 10 years, we just wouldn’t need to care that foo 3.0 dropped support for running on 32-bit systems …
I am disappointed in some of the reactions this
proposal
has received, with some people apparently reading it in the most uncharitable way. It was a proposal that tried to address technical problems package maintainers and release engineering is facing, not some conspiracy to break the “gaming use case”. That said, I was expecting a lot of feedback feedback on this one, but not hundreds of people shouting "DON’T DO THIS WHY DON’T YOU CARE ABOUT YOUR USERS I WILL SWITCH DISTROS IMMEDIATELY levels of feedback (though to some degree, I also blame clickbait “tech press” or YouTubers for that …)
I am now looking forward to seeing actual (and actionable) counter-proposals.
At least for now there's no issues continuing gaming on Fedora, but this situation will come up again in future. Hopefully a more thought-out plan will be made for it as to not cause issues with the likes of Steam and various 32-bit games and apps that will never be updated.
2038 is the hard cut-off date for 32-bit applications. After this date, 32-bit applications will not be able to measure time accuratelySo, basically, the Y2K problem all over again? I must be really out of touch -- I didn't even realize this problem existed. That being said, 32-bit systems can still use 64-bit numbers. Odds are pretty high, though, that the default was to use 32-bit numbers on 32-bit systems. Just like with Y2K, adjustments to existing software are going to be needed ...
Fedora can't just drop the ~9000 packages that have nothing to do with Steam because of the way their build system is made.I got that sense as well. It would take a great deal of study and careful planning. I think that one of the goals of the proposal was to get the ball rolling on that process.
Native 32-bit Linux games not being playable on Linux is an overblown issue. The fact is, most of them are not playable even with Steam Runtimes in my experience. Proton is the better choice in most cases.I tried to argue that "Proton may be a better choice than Native" a year or so back on this site, for this reason. The hostility I got as blowback was palpable.
There was also some amount of civil discussion and quite a lot of good points raised. I think this change proposal was pretty successful in that respect.Once I got around to reading a bit of the thread, I thought so too.
Hopefully, when they decide to revisit this problem, they will be a little clearer on the goals of the new proposal -- particularly avoiding short soundbites that can be exploited by the clickbait sites and YouTubers. We all know that this issue will need to be revisited again at some point.
I've read multiple times "Flatpak Steam has it's own set of issues": After many years running the flatpak Steam I still questioning, which are these issues everyone talks about? I am sure I must have had run across them by now shouldn't I? Yes I've read some (mean while years old news) about how the flatpak sandbox interfered with the Steam runtimes. But those where fixed long ago.
Actually, even though this is a personal perception, the Flatpak Steam worked much better than any "native" Steam ever has. Be it the *.dep shipped by Valve or any native package shipped by which ever distribution I had ran it on.
Therefore from my personal point of view. I do not understand how removing 32bit form the base OS kills gaming? It clearly does work. As well as for the other 7.42% of Linux Steam users running the distro "Freedesktop SDK 24.08 (Flatpak runtime) 64 bit". Which leads me to the conclusion the host does not need to still maintain 32bit libraries if flatpak seems to be capable of handling all this already?
Can some one please enlighten me. With sources / proofs preferably? I know I did not provided "proof" or sources myself. Beside not understanding the discussions.
All I can give is a list of all installed packages and the huge lack of anything "-32bit" as this is what openSUSE does label their 32bit packages: https://gist.github.com/VortexAcherontic/cc550a5b33b03c0fc7bdef1874b02947 Especially there is a lack of 32bit nvidia driver stuff which otherwise would be vital for running 32bit games. But neither are nvidia-compute-G06-32bit, nvidia-gl-G06-32bit or nvidia-video-G06-32bit installed. As well as no libgstvulkan-1_0-0-32bit, libvulkan1-32bit or Mesa-vulkan-device-select-32bit.
Yet Steam runs fine: https://i.ibb.co/zh43QKtv/grafik.png
It is not fair to bash Fedora or the FESCO on this proposal. The world moves on. Most 32bit software (except Steam) is probably out-dated and unmaintained anyway. Shouldn't it be the preferred approach to run them via Flatpak to have at least some sort of Sandbox they run in rather to compromise the base OS with old libraries and stuff?
Or do I fundamentally misunderstood here something? I mean it, please I'd really like to understand this.
Last edited by Vortex_Acherontic on 30 Jun 2025 at 5:30 pm UTC
I actually do not understand the arguments till this very day. I validated my previous claim on how am I running a 64bit only distro and it turned out to be true. Yet Steam works just fine even old 16bit Windows games via 32bit Wine as 64bit Wine can not emulate Win95. As well as any old unmaintained 32bit native Linux game (Unreal Gold, UT2004, The very first SDL Port of Quake called Fitz Quake just to name a few). All thanks to flatpak running either Bottles, Lutris or Steam.
[...]
Therefore from my personal point of view. I do not understand how removing 32bit form the base OS kills gaming? It clearly does work. As well as for the other 7.42% of Linux Steam users running the distro "Freedesktop SDK 24.08 (Flatpak runtime) 64 bit". Which leads me to the conclusion the host does not need to still maintain 32bit libraries if flatpak seems to be capable of handling all this already?
[...]
Can some one please enlighten me. With sources / proofs preferably? I know I did not provided "proof" or sources myself. Beside not understanding the discussions.
[...]
Or do I fundamentally misunderstood here something? I mean it, please I'd really like to understand this.
How do you think Flatpak "solves" the problem of running 32 bit games? It contains the 32 bit libraries! So, the problem is not different, the libs are still needed and still need to be maintained and still need to be packaged!
Getting flashbacks to the absolute shitshow 2 years ago when Fedora had another brilliant proposal that people went to war over, I thought I recognized Fabios name from the discussions. If you forgor, perhaps purged your memory banks or just live under rock-sized boulders, you may interwebsearchnaningans the following: F40 Change Request: Privacy-preserving Telemetry for Fedora Workstation (System-Wide)
Yeah, no. This guy can't convince me he could not see the big picture with the SteamDeck, EoL for Win 10 etc.
And his attempt at an excuse for picking 44 instead of something reasonable like 48 or even 50 kinda confirms it for me. He knew what he did, and knew how it would be perceived, he wanted the drama.

I think it is good that this discussion was started up again. This will eventually need to be addressed, and I understand there is a lot of overhead as a result of continuing support for it. The reality is, there are a lot of people who would be immediately left in the lurch and quite a few people having to pick up a lot of work they are not ready to do. I would have very much liked to have seen a list of core apps and features, top 100 list, that would stop working if not converted by maintainers. I think this would help paint a much clearer picture of the impact. The fact that Wine and Steam are called out directly in the proposal seems like it's pretty clear it is mostly games.
Last edited by Magicaster on 30 Jun 2025 at 7:26 pm UTC
In the meantime this could be used to put some pressure on VALVE to at least start working on port to 64.
How do you think Flatpak "solves" the problem of running 32 bit games? It contains the 32 bit libraries! So, the problem is not different, the libs are still needed and still need to be maintained and still need to be packaged!
Yes but the Fedora proposal was to remove 32bit from the base OS. Nobody was talking about removing 32bit from flatpak.
Therefore I do not understand why everybody freaks out here. Nobody is in fact taking the precious 32bit apps away from anyone. But instead of running them natively ppl may want to finally adopt flatpaks?
Last edited by Vortex_Acherontic on 30 Jun 2025 at 10:13 pm UTC
But if he really wanted reasoned responses that didn't take sides, he had an option. Rather than saying "I propose that we wholesale rip out this stuff a lot of people depend on", which is what he said, he could have said "Maintaining this stuff a lot of people depend on is difficult the way we do it, is there some way we could arrange for users to still be able to do what they want to do, but with less overall maintenance effort?"
But he didn't do that, so he got the response he asked for. His snidely bitching about it now seems disingenuous to me.
The question is, how do we get rid of 32-bit support in a way that doesn't inconvenience end users? To that end, there isn't an acceptable solution yet.
One of the big road blocks is, indeed, the Steam client, and secondary reason is 32-bit games that can't run in a 64-bit environment.
I'm no expert in this sort of thing, but couldn't there be a conversion layer (not unlike WINE) that would allow 32-bit applications (games) to run in a pure 64-bit environment? We can do it with x86/amd64-to-arm64, so what is the technical reason it can't be done with x86-32 to x86-64?