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.
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)
I saw the writing on the wall then and abandoned Fedora. It's unfortunate because the software is great but the developers have become toxic to the user and say what you want but there is a clear influence by RedHat and it's not a good one. It's totally legitimate for users to say they will leave if they feel abandoned by the product and Fedora is abandoning the well being and needs of the users. They are becoming like Microsoft where they think they know what is in the users best interest better then the users themselves do. Anything they decide to do is correct because THEY THINK it is in the best interest of the users even if the users don't. Some of these developers seethe with contempt for users while claiming to be looking out for their best interests. It's fine if you're going to have that perspective, it's your right. But it's against the history and values of what Fedora used to be. Granted they've removed some of the privacy language since the telemetry fiasco but at this point they might as well say it's made by developers, for Redhat but you're free to use it if you want. I've comfortably settled in Debian since then and I'm much happier.
Last edited by m2mg2 on 2 Jul 2025 at 2:54 am UTC
Don't you think Flatpak will face the same problem as Ubuntu and Fedora?
Why would it? That's antithetical to the concept of Flatpak itself. The purpose of it is to provide sandboxed environments for applications that contain the exact dependencies they need. These dependencies are not installed to the system resources directory (/usr) like typical libraries, and it would make absolutely no sense to disallow the use of i386 libs since they aren't actually touching the base OS.
There's no problem with "touching the base OS". 32 bit and 64 bit can reside side by side all fine.
The problem is that 32 bit libraries are more and more unmaintained, more and more difficult to build.
(Fedora people are saying this in 2025 - and Ubuntu people have been saying this in 2019 already! (https://discourse.ubuntu.com/t/intel-32bit-packages-on-ubuntu-from-19-10-onwards/11263/2)
What's "antithetical to the concept of Flatpak" here?
Delivering maintained software? (Sorry, I could absolutely not resist.)
Anyone see the irony of this situation? Linux users have been enticing Windows users to start using Linux because Microsoft has the audacity to block users of older technology from using the most recent version of its desktop OS. Meanwhile, Linux distros are on the verge of doing the very same type of thing. You know, some folks would probably still prefer to use typewriters, carbon paper, and whiteout. Does that mean the rest us should keep that stuff around, just in case?I think that the situation is the opposite. Windows doesn't kill anything, it keeps very old components for decades that makes the operating system extremely heavy and inefficient. By other hand, some Linux distros try to kill old components to only maintain modern and maintained components and to lighten the operating system.
Many people say that IBM is turning Linux into Windows, but are the nostalgics who try to transform Linux into Windows dragging tons of old components.
But forcing every distribution to drag around 32bit libs just for Steam ... I don't think Valve should be allowed to hold us all hostage with this.It's not just Valve's Steam client, you know ...
if ppl would have adopt FlatpakIf people would have to adopt Flatpak? ... What happened to free choice here? Why should I be forced to use it if I don't want to use it?
@Eduardo Medina
Windows doesn't kill anything, it keeps very old components for decadesHuh? Since when? These days, old Windows software runs better on Linux than it does on newer versions of Windows. Admittedly, M$ isn't as ruthless as Apple but still ...
Also, refer to the quote from @CajunMoses
Microsoft has the audacity to block users of older technology from using the most recent version of its desktop OS.In case you didn't know it, Windows 11 enforces planned obsolescence by unnecessarily requiring specific hardware security features that are only available on new computers (mostly 2019 or later), forcing the discard of perfectly good hardware to use Windows 11. For those of us who prefer the quality of older hardware, M$ is giving us the finger.
It's not just Valve's Steam client, you know ...
Same story if you ask me. They shouldn't bee allowed to force distributions to drag around 32bit libraries.
If people would have to adopt Flatpak? ... What happened to free choice here? Why should I be forced to use it if I don't want to use it?
Never said that ppl should use Flatpaks no matter what. I brought it up as a solution to the issue and if a broader audience would be using it the whole discussion might have taken a different turn.
I did not wanted to argue away ppls freedom of choice here. If some don't like Flatpak this is fine by me. If ppl like to run 16bit OSes to run 16bit Software. Go ahead do it. In the end I am not affected by an individuals choice of software.
If flatpak does not suite the user then maybe Distrobox and Toolbox are more suitable to run 32bit Linux (or one with 32bit support) from a container on 64bit. Apparently the choice of distros supporting 32bit will shrink over time. Also not as well sandboxed as Flatpak thought but this works as well. I use it on a daily basis to run software not designed for my distribution of choice for example.
Maybe even Snapcraft has 32bit compatibility? Idk maybe someone can tell if this works.
Therefore I do not see any issues in removing 32bit support from a distro if they want to do it. As compatibility seems to be already there and in a seemingly more secure way.
In the end we all can probably agree 32bit support will vanish over time. Why not taking the opportunity to seek ways to run the legacy software in a more future proofed scenario? Instead of being required to rely on the good will of distribution to still supporting 32bit packages?
The bottom line is, there are a lot of people using 32-bit software. Either the 32-bit versions of what that software needs in order to run have to be maintained, or some emulation thing needs to exist that creates the same result with less maintenance overhead. Putting stuff in a Flatpak neither maintains any libraries nor represents emulation. It is not relevant.
The alternative is to just not do it and pretend this is a defensible position. I don't think "but having my OS actually run software is hard and users who insist on it are being unrealistic" is a defensible technical position.
Last edited by Purple Library Guy on 2 Jul 2025 at 10:28 pm UTC
I think that the situation is the opposite. Windows doesn't kill anything, it keeps very old components for decades that makes the operating system extremely heavy and inefficient.
When we're talking about old libraries, the "advantage" of Windows is "DLL Hell": Every game has it's own libraries lying around, and nobody cares that the versions are outdated, unmaintained and have more holes than a Swiss Cheese.
The alternative is to just not do it and pretend this is a defensible position. I don't think "but having my OS actually run software is hard and users who insist on it are being unrealistic" is a defensible technical position.
"I'm not going to do this in my free time; it's no fun" is an understandable position, though...
Last edited by Eike on 3 Jul 2025 at 6:50 am UTC
Flatpaks have to get the libraries somewhere, why are so many people ignoring this?Huh? I don't see this getting ignored. Flathub is not reliant on Fedora to have 32bit support. It has it's own runtimes compiled from sources. Which are maintained by the respective upstream or the community itself.
Edit: As for individual apps, often times it's the developers or who ever takes care of the faltpak. If a developers/maintainer know they require 32bit than they can do it. There is full guide on how to get this setup if distributing on flathub: https://docs.flatpak.org/en/latest/multiarch.html
Last edited by Vortex_Acherontic on 3 Jul 2025 at 9:52 pm UTC
But wait, it gets worse! Much of the point here is precisely about apps, such as old games, that people want to use but which are not maintained and furthermore are not open source. There is nobody to package them, let alone each do all this individual compiling of libraries. And it would probably be illegal for anybody to try. I suppose someone could make a Flatpak for a game without the actual game files, with instructions for people who own the game on how to stick the actual game files into the Flatpak. Sounds like just a marvelous approach! Not.
Well then that's really not a solution. So first of all, it involves massive duplication of effort. If every individual app is individually re-doing the work, then the maintenance the Fedora people don't want to do once would have to be done hundreds or thousands of times. That's insanely stupid.There is no duplicate effort. Maybe I was a bit unspecific here: The 32bit runtimes are there. As an application developer all you have to do is to tell which runtimes are required for your app to function so flatpak can link them at runtime for your application to be used. Just as if you would install any given set of libraries on a native Linux distribution in order to run the application. Additionally runtimes are shared across flatpaks. No duplicate installation no additional space no need for self packaging them either.
Actually there is duplicate effort as things are right now as every single Linux distribution has to repackage libraries themselves. Defaulting to Flatpak would massively reduce duplicate effort here. Not increase it. That one of it's key features after all.
But wait, it gets worse! Much of the point here is precisely about apps, such as old games, that people want to use but which are not maintained and furthermore are not open source. There is nobody to package them, let alone each do all this individual compiling of libraries.I don't understand how this argument supports your point of view at all. There is nobody to package these applications for any Linux distribution as well if they are closed source. What is the point here?
However most devs of proprietary software bundle required libraries with their application anyway. Looking at any random Linux native game here for example. If they work on a native Linux distribution with 32bit support. So they will work with flatpak too.
An application does not need to be open source to be packaged as a flatpak. You can think of flatpak as it's own mini distribution running atop your distribution of choice if you will.
If the game is on Steam, simply run it from flatpak Steam and it will keep working. If they are not on Steam, then run them via Lutris, Heroic Games Launcher, Minigalaxy, Faugus Launcher, Cartridges, Bottles the choices are endless they all have the 32bit runtimes made available to them. This way nobody needs to package said application as a flatpak.
Mark my words: "There is not a single application I can not run on my 64bit (immutable and rolling release) distribution. As long as it is technically possible to run said software on Linux at all obviously."
-----
I will now end the discussion with you at this point as it seems to me you lack vital knowledge here to take this discussion any further. I wish you all the best and thank you for your time.
Maybe I was a bit unspecific here: The 32bit runtimes are there.The 32bit runtimes are where, exactly? A major part I don't understand is how this is apparently a major burden for Fedora or Ubuntu devs to maintain in existence, but somehow automagical for Flatpaks. Like, do distros use much more primitive compiling techniques for some reason? To put it a different way, no doubt they exist today, but if Fedora and Ubuntu were to stop having them, at what point would Flathub or whoever be saying "man, these things are a pain to maintain, we should drop them"? Why is the effort different, and who in the Flatpak world has the workforce and motivation to put it in if it's being claimed to be too hard for major Linux distributions?
I don't understand how this argument supports your point of view at all. There is nobody to package these applications for any Linux distribution as well if they are closed source. What is the point here?You don't really need to "package" them if the OS already supports them. But if they're closed, and you do need to package the application (which is what everyone has been talking about up to this point), you legally can't, or at least you can't then distribute it, so that's a problem.
What you seem to be suggesting is that you don't actually need to put the games in Flatpaks, but instead you have various game-running platformish applications which can package the needed stuff and run all the games. That's not as bad, but note that it's not what anyone had suggested. Over and over I was seeing people say put the things in Flatpaks--not, have Heroic or whatever bundle the needed libs. So what I'm seeing here is I've been saying solution X is bad, and you're coming back at me with "You fool! Solution Y is great, what are you talking about?"
That works all fine natively or in Flatpak or however.
The problem is how to get/make/maintain the libraries in the first place.
Ubuntu people said (6 years ago already!) that the environment, tools and the libs themselves are brittling.