Fedora Linux devs discuss dropping 32-bit packages - potentially bad news for Steam gamers

Shouldn't Steam as a flatpak not just keep working?

This is just moving the problem from outside the Flatpak to inside the Flatpak: If we want to run all those old 32 butt games, they need 32 bit libraries somewhere.

The Steam client is basically based on Chromium and it is a known fact that Chromium's security sandboxing is not compatible with flatpak's one making Chromium-based browsers as flatpaks -even Chrome- insecure. There's a reason why ALL of the Chromium-based browsers are unverified there. No wonder Steam doesn't want you to be using the unofficial, unverified version as well, so no, using flatpak is not the solution.


Last edited by sudoer on 25 Jun 2025 at 9:47 am UTC

Well of course the moment I have just decided to go with Fedora for my new computer this happens.

The more I read about this, the deeper the rabbit hole goes, and the messier it looks. And it gets worse every day.

Upstream 32bit versions of applications/libraries started to be unsupported, untested and/or unused by upstream since some time now. "Doing nothing" and maintaining the status quo is worse than difficult: it's dangerous.

Fedora volunteers cannot keep providing a better product downstream than they have access to upstream. As a side note: can we please stop blabbering about corporate greed and for-profit progressism? These are guys helping for free in their free time. It's not IBM, it's not RedHat, it's a different thing. The corporate world abandoned 32bit AGES ago (and support it only in front of quite substantial payments).

Resources are scarce. Whoever is on the roof shouting that we must keep things running like twenty years ago should come down and start helping contributors. Or become one.

Associated projects, like RPMFusion, have the same resource starvation (people/time/interest) as Fedora maintainers, and they wouldn't pick up the slack. After all, it's rather unrealistic to offload one volunteer to overburden another.

Fedora is too small for Valve to care? Maybe. Or maybe this could be the last straw to push Gaben (always be praised His Name) to make Steam 64bit only and including in itself some "soft virtualization" in the form of 32bit runtime environments for abandonware 32bit native games. This wouldn't help extra-Steam native games. But at some point, we should stop complaining we can't run Amiga games without an emulator.

Other important subsystems, like Gamescope and OBS, are equally critical for a modern, gaming-friendly environment. We cannot dictate what others do with their free time, but asking kindly is always an option. And the best option is start contributing actively to the projects to help them get out of 32bit technical debt. That's the beauty of Open Source, after all: not backward compatibility, but technical excellence.

This need to happen, sooner or later. It's a matter of when, not if. It's too early now? Most likely yes. So, when it's the right time? Ubuntu tried it in 2019-2020 and it backfired horribly. But even five years ago, the rationale about letting 32bit die was strong and pressing. We're half a decade later debating exactly the same stuff, with exactly the same problems. https://canonical.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts

Do I have a solution? Of course not. Will I miss some late 90's games unless there's an user-friendly way to run them? Probably. But in all honesty, I have no heart to ask Fedora maintainers (or any other distro maintaner, for that matter) to keep doing this maintenance work forever because Reeee mu games.


Last edited by syylk on 25 Jun 2025 at 10:51 am UTC

But at some point, we should stop complaining we can't run Amiga games without an emulator.

Excuse me? I'll kill off every second daemon in my system if that'll let me run A500 games natively!

This is just moving the problem from outside the Flatpak to inside the Flatpak: If we want to run all those old 32 butt games, they need 32 bit libraries somewhere.

That's what the Steam Runntimes and org.freedesktop.Sdk.Compat.i386 are for. 32bit support on 64bit systems.

You do not need a single 32bit library to run 32bit software on 64bit systems with flatpak. Also there is WOW64 for Wine / Proton which is to run 32bit Windows game on 64bit. Even Windows uses 32bit abstractions on 64bit to run legacy software.

Removing 32bit support is not an issue at all.

i recomend this presentation for anyone thinking legacy dont matter, but i dont think its your case:
https://www.youtube.com/watch?v=65crLKNQR0E

It's not that legacy doesn't matter.
It's that we do no longer really need legacy itself to keep other legacy alive.

Some things will no longer work, no doubt.
But I'd argue that those things were no longer important to people or someone would've made an effort to modernize or preseve them - just as people did with Flash, which can still be enjoyed without having to have Flash installed (with a bit of effort).

Who knows how many books we lost because nobody ever read them. It happens, it's normal.

Ahem. Library person here. Sure, books disappear, but just disappearing because "nobody ever read them" is not "normal". So for instance, in my region all the academic libraries have a kind of catalogue-sharing thing called "last copy" to make sure that when we weed books that aren't used, we don't all accidentally dump the same one. Somebody will have one last copy of that weird old book.

The macOS client was recently ported to aarch64 (a completely different CPU architecture!). If an x86_64 build is harder than that then Valve should completely rewrite the Steam client.

@The_Real_Bitterman

That's what the Steam Runntimes and org.freedesktop.Sdk.Compat.i386 are for. 32bit support on 64bit systems.

You do not need a single 32bit library to run 32bit software on 64bit systems with flatpak.

Erm... What is inside of the Steam Runtime and org.freedesktop.Sdk.Compat.i386?


Last edited by Eike on 25 Jun 2025 at 5:27 pm UTC

@syylk

can we please stop blabbering about corporate greed and for-profit progressism? These are guys helping for free in their free time. It's not IBM, it's not RedHat, it's a different thing.

Since only two people commented about this, I'm going to assume you're talking about me.

Please slow down and read what I wrote more carefully. I did not say that corporations were directly involved or that the volunteers were corporate flunkies. I said that there is no need for open source volunteers to employ a philosophy developed by a corporate for-profit mentality. A completely different thing.

Besides, how do you know that this issue is not being influenced by IBM or RedHat in some way? If we maintain old things, we do not buy new things.

Resources are scarce.

This is precisely why it is so important that the volunteers step up to maintain these old technologies. You know that -- with the possible exception of companies like GOG or Valve -- the for-profit sector is not going to do it. Our society has been devaluing the idea of maintenance against the "convenience" of a throwaway habit that only benefits the for-profit sector -- at the expense of our society, culture and environment. In fact, it is the lack of maintenance that is causing this resource scarcity.

It's too early now? Most likely yes.

It is too early. We need to fully develop and deploy the containers, runtimes and technologies like WOW64 that enable 32-bit apps to run in a 64-bit environment before we abandon the libraries needed to run them right now. Honestly, even in the corporate world, there are businesses that still utilize Windows XP or Windows 98 because of a critical application that absolutely will not run in modern operating systems.

Do I have a solution?

For now, IMO, the solution is to continue supporting 32-bit libraries. Which, of course, means that we will see more reviews such as this one popping up periodically in the future.

The macOS client was recently ported to aarch64 (a completely different CPU architecture!). If an x86_64 build is harder than that then Valve should completely rewrite the Steam client.

As I pointed out earlier, Steam client is 64 bit on macOS for both x86-64 and ARM64, yet it is still not fast. The problem is CEF, as long as CEF remains as it is, changing and/or upgrading architecture won't change much.

As I pointed out earlier, Steam client is 64 bit on macOS for both x86-64 and ARM64, yet it is still not fast. The problem is CEF, as long as CEF remains as it is, changing and/or upgrading architecture won't change much.

x86_64 is not about performance, it's about compatibility. It shouldn't be slower than x86 (if it is then I again suggest Valve rewriting the whole client).

And aarch64 was only recently released as a beta. Currently it runs the x86 client via Rosetta2 which simply is slower. The aarch64 port is much faster (check the various user reports).

This is precisely why it is so important that the volunteers step up to maintain these old technologies. You know that -- with the possible exception of companies like GOG or Valve -- the for-profit sector is not going to do it.

We're only talking about this because Valve seems too incompetent to fix their crapware. Instead you're blaming all other to fix Valve's stupidity. They're not supporting the old technologies, Steam requires an x86_64 CPU. If they want to support x86 binaries (instead they could move all games to Proton, too), they can provide their x86 runtime. No need for all others to do their job.

It is too early. We need to fully develop and deploy the containers, runtimes and technologies like WOW64 that enable 32-bit apps to run in a 64-bit environment before we abandon the libraries needed to run them right now.

x86_64 is ancient. People are already striving to move to the next, more efficient architectures (aarch64 & Risc V). We already can run x86 software without any problems in containers but generally don't need to: "Our" software is build for x86_64 by the distributions. Again, it's only crapware from crap developers which blocks this.

For now, IMO, the solution is to continue supporting 32-bit libraries.

Nobody is stopping you, have fun: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/

x86_64 is ancient. People are already striving to move to the next, more efficient architectures (aarch64 & Risc V). We already can run x86 software without any problems in containers but generally don't need to: "Our" software is build for x86_64 by the distributions. Again, it's only crapware from crap developers which blocks this.

I really don't want to sound cynical but this makes me one. I keep reading about the wonders of Risc-v for at least 5 years, yet I am yet to see a working distro running all the legacy i386 apps and games that works seamlessly on risc-v.

I use Linux exclusively since 2009, I was reading about the heavens offered by Wayland even that early. Yet, we are witnessing its mass adoption in last couple years. Why? Because, some smart people didn't arbitrarily decide to drop x11 that would render old apps inoperable due to lack of efficient translation.

Nobody is stopping you, have fun: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/

Also, no one is stopping people to switch to other distros either. Unless its name is Debian, there is no irreplaceable distro. Have fun seeing people migrating to distros offer better and native compatibility.

. . . Of which there is probably quite a bit. Specifically relevant to this forum, nearly all older games are "unmaintained legacy software".

Certainly. But running old, unmaintained software is what emulators are for.

Sure. So is there a decent emulator for 32-bit? I haven't seen anyone suggesting one that others haven't rubbished fairly convincingly.