I’m opposed but could be convinced is solutions for us gamers can be found.
We can tell people to go make a fork or whatever but really what will happen is that people will just switch distro.
I would rather stay on Fedora but the primary use case for my PC is gaming. If that becomes untenable I would have to switch.
Is it really a legacy technology if people still rely on it and there is no viable alternative presently available?
What specific technology do you rely on, and why?
I’m not clear why 2,3 and 4 are needed.
I certaintly can see why a copr might be needed, but for the rest its unclear.
That would be fine if Valve would be willing to actually do that.
Another option would be to just change the date of this change proposal to allow more time. Fedora 44 vs. Fedora 46 makes no difference to me.
Why?
It’s really weird for an entire computer operating system to shut down because you don’t want to build your own packages? That’s strange. But you still have multiple other options: ship the final Fedora builds of the i686 packages that you need, or just use the Steam Flatpak.
Do you want fedora to become like windows? I mean it nice and all to be able to play retro games like dos, but i prefer using an emulator for that, not bloat the whole system with every code ever created.
It’s funny when pp complain ms is bloated with code from dos era, but they argue with them when someone want to move on, and lose the bloat…
This doesn’t make any sense. It’s not old code, it’s code compiled for specific architecture. Steam code is not old
The problem is that Fedora was never intended to be a gaming distro; its focus is on software development (that’s why Torvalds uses it) and being at the forefront of Linux technologies (goodbye xorg).
The entire video game industry is targeting Windows 11, even Playstation and Xbox ported their games to the OS. Furthermore, GOG.com has been porting video games (like Resident Evil and most likely the Silent Hill trilogy in the future) for over 20 years to be 64-bit compatible (through reverse engineering).
It’s already a waste of time, because only the maintainers are volunteers (like @decathorpe) who support 32-bit.
Therefore, my position is very clear: we have to say goodbye to full 32-bit compatibility; we can no longer postpone the discussion.
Windows was never intended to be a gaming OS either.
I read the proposal/comments more; Wine doesn’t seem a problem, but if I was entertaining PC gaming on Linux today, I need Steam as an RPM.
I don’t use Flatpak, and any complexities with installing Steam I feel could be easier with an entire distro switch.
I used Fedora Workstation/GNOME since 22, along with SteamVR on RX 6600 XT and RTX 3060 Fedora 30s. Fedora with Steam RPM was the most ideal conditions for me, but I could also do it on openSUSE TW and Ubuntu.
Fedora dropping 32-bit and not having Steam available would have me use another distro. Fedora benefits from users.
It sounds like 32-bit support is being used as maintenance burden as a reason to drop it; that’s fair, but why isn’t there motivated effort to maintain the support? What exactly is driving Fedora’s future if people don’t want to put in effort?
I find 32-bit support useful as Steam relies on it, and 32-bit games under Wine work better with it.
I regularly play World of Warcraft 3.3.5, and it’s low-performance in Wine’s WoW64 mode unless I don’t use a certain graphics API (maybe OpenGL?) or introduce 3rd-party DXVK. DXVK is overkill, and I don’t like adding things if avoidable. WoW runs no problem Wine 32-bit on 64-bit distros currently that have a 32-bit mode.
So Fedora removing 32-bit adds effort on me to either fix a game with 3rd-party deps and likely lose Steam (although I’m sure I can figure out SteamCMD with motivation 
), and I’m not sure who on Fedora would benefit from that.
I am more of an end user, but i do want to provide some info and my opinion.
Bazzite cant use Flatpak, as there are a lot of kernel and other patches made that won’t work in the flatpak due to the sandboxing nature of Flatpak. If it was an AppImage, different story. Nobara would suffer a similar issue. So many of the benefits of Bazzite would be pulled out.
I know this because i prefer Steam Flatpak and disable Steam native on my Bazzite install, i get none of the benefits of the gaming focused patches.
Second, i don’t know why people are complaining about Gamescope when there is a Gamescope flatpak that works with Steam Flatpak, i have used it in the past.
At the same time, i find @kylegospo 's comment disingenuous, because while not great, they can revert to how they used to run Steam, as an exported app from a Distrobox container. It wasn’t perfect, but it worked for a long time. Also, making a copr repo of these packages wouldnt be so bad, there is already a copr repo for many custom packages in the project.
At the same time, i also understand that the handheld experience probably works better outside the distrobox.
I personally support this proposal, we need to stop dragging our feet and let obsolete architectures and packages and tech just die instead of dragging their corpses through the mud. I feel the same way about the X11libre nonsense. Just let it go and move on.
Flatpak Steam works fine. Ive been using it for a long while now. And there are workarounds for many things. Steam Flatpak is a community project. You can add tools through addon flatpaks and make the Steam Flatpak aware of them. Its probably time people invested themselves in learning how Flatpaks work anyway, or helping improve and grow the capabilities.
This won’t kill gaming on Fedora, it will just change which path we take to setup gaming on Fedora.
And with the nature of Bazzite and the Universal Blue project, it will be forked, workarounds will be found, and new layers will be made on top of Bluefin or Universal Blue core, its now hard, just time consuming, and i respect Kyle and the surrounding team for their work, but its also not impossible to work around this.
And in reality, Valve needs to really fix this. They do so much for Proton and such, but making their client 64bit is all of a sudden too much.
And fedora was? Other than orbis and other console os, there aren’t any “gaming OS”…
That’s what I’m saying. Just because something isn’t a “gaming OS” doesn’t mean it the devs/maintainers shouldn’t focus on the gamer end-user. A lot of people are coming to Linux nowadays because of stuff like the Steam Deck and proton, and proposals like this are just going to discourage them. Also I’ve used Linux full time since 2011 and Fedora since 2019 and I don’t want to have to change distros if Fedora makes some decision that makes my life harder.
DirectX is a core part of Windows. I don’t compile game servers with DirectX, but the games played use it
Isn’t Linux supposed to appeal to what user’s do? MS could suddenly say they’re not gaming, strip DirectX, and still sell Windows. Linux doing it instead would have gamers probably back on Windows.
Fedora was offering latest vanilla Linux that happened to work well with games. I’d use Fedora for SteamVR before RHEL like I’d use Windows Pro before Windows Server.
If Steam’s the limiting factor, companies should push Valve for 64-bit. If they choose not to, it’ll suck for users.
But that makes this proposal decisive; some argue maintenance burden while being end-users, while end-users argue specific use-cases.
I’m not sure how Steam and macOS went, but afaik Steam’s 64-bit there. If Apple removed 32-bit support and forced users to demand Steam provide 64-bit, that sounds like what should happen.
But 64-bit enforcement needs to be the OS’s job: It’s going to happen because future, and should just happen already without a decisive proposal. Wine has Wow64. Valve as big as they are shouldn’t be able to say anything as an excuse about 32-bit only in 2025 imo, but maybe there’s something holding them up? If it’s technical (like DRM), then it’s likely on the OS to decide for its users; in which case having 32-bit support for the largest gaming platform on an alternate OS is probably beneficial for the effort.
But it doesn’t lower the maintenance burden for release engineering or test at all.
Putting i686 packages in the x86_64 repo is a fundamentally weird thing to do that requires all kinds of gnarly hacks at every level of the releng/test stack from Koji all the way up, like this whole ball of wax. It would make our lives a hell of a lot easier if we could get rid of all that mess, but so long as even one single solitary multilib package exists, we have to keep it all.
You know this isn’t immediate, and the fault is at steam and other devs who can’t/won’t keep their code updated, right?
For my part i see that this is inevitable, and unlike ms who outright killed older pcs with win11, fedora should run on these if i’m right, and 32bit cpus were eol around 2020 both linux and ms. So i think this is the right move and i won’t argue about it.
I’m not clear why 2,3 and 4 are needed.
I certaintly can see why a copr might be needed, but for the rest its unclear.
2 would be needed because 32-bit wine and 32-bit games are still prevalent, and shipping all of the dependencies of true 32-bit wine is untenable for a project like Bazzite. Wow64 fixes that problem, but it’s still experimental.
3 is needed because of what I mentioned at the end of problem 2 - If we need a custom version of Proton to work around this, every end user of ours would need to manually install that version of Proton, keep it up to date, and individually set every game in their library to use it.
4 occurs because OBS VKCapture depends on 32-bit Mesa and is itself a 32-bit plugin for capturing 32-bit games, which while uncommon now, make up the majority of games in the Steam library.
I apologize for any theatrics, they’re not intentional or an attempt to apply pressure, rather I wanted to make it clear that this change as-written makes it impossible for us to guarantee a stable and functional gaming experience as we have been.
At the same time, i find @kylegospo 's comment disingenuous, because while not great, they can revert to how they used to run Steam, as an exported app from a Distrobox container. It wasn’t perfect, but it worked for a long time. Also, making a copr repo of these packages wouldnt be so bad, there is already a copr repo for many custom packages in the project.
@yulian
There’s some revisionist history going on here. While we did experiment early on with containerizing Steam, this was only done on Desktop images. We dropped it completely because it has numerous unfixable problems that make it a bad experience. At no point did this power the gamemode session images of Bazzite because it can’t, for the same reasons the Flatpak can’t, and the gamemode session images are 2/3rd of our users.
I think this aspect is being overlooked a bit. I fully agree we need to eventually figure something out, and I appreciate @decathorpe and the other change owners starting this conversation early, but oddly enough Fedora doesn’t have to be the one to blaze this particular trail. Other distros with longer lifecycles need to figure this out long before Fedora does. Due to the year 2038 problem, RHEL 10 already dropped 32-bit libs, because its ELS phase extends into 2038. Ubuntu 26.04 will see its Legacy Support extend into 2038 as well, so it will be interesting to see what Canonical does in that release regarding 32-bit. If they drop it outright as well, that means Valve will be faced with two of the largest distros no longer having 32-bit support. Deferring this change a release or two would buy us time to see how that plays out.
Deferring this change a release or two would buy us time to see how that plays out.
No objections here, that would be perfect. I would also happily accept the solution proposed by @ngompa
Kernel patches shouldn’t matter? Of course Flatpak apps use the host system kernel?
Regarding userspace patches: yes, you indeed lose all of those. But since Steam is going to eventually need its own Flatpak runtime anyway, you might as well add the gaming-focused patches there? (Or best of all: upstream them whenever possible, so you don’t need extra patches anymore.)
Notably, if Bazzite has kernel and userspace patches, we know it is capable of building its own packages. Sure seems like it could just build 32-bit versions of packages? (That said, we surely want Steam to be usable on upstream Fedora, without depending on Bazzite.)
I’m not sure if AppImage might work or not? Is it a real container, or does it depend on host glibc? I bet it depends on host system for that?
Since you aren’t willing to use the Flatpak version, and also don’t want to use your own container either, I guess Wow64 is your path forward? Honestly it sounds like you’re rejecting all your best solutions, but OK.
But you are providing an entire computer operating system. Why can’t you also provide your desired version of Proton…?
Wait… is VKCapture somehow injecting binary code into third-party proprietary software games…? Seriously? Is this using LD_LIBRARY_PATH or LD_PRELOAD? Are you sure about this? If not, then why would it need 32-bit anything? This sounds like something to stop doing.
Why can’t it use the screencast portal? Does it not perform well enough?