The reddit post is simply using Gaming on Linux’s headline, which is an accurate headline. The article itself is fairly reasonable, and it is correct to say that if we phased out 32bit now, or even as early as F44, it would be disastrous for gaming on Fedora. The thing commenters on reddit etc are getting wrong is that they’re assuming this proposal is all or nothing. They’re assuming either this proposal gets accepted or rejected, and if it’s accepted, gaming is “dead” on Linux; the reality is, this proposal as-is will almost certainly be revised as things go down the road. It’s something Fedora needs to figure out eventually. People are scared of the timeline.
5 Likes
The rather maintainer-unfriendly approach would be to catch the i686 packages on the CI/Koji/Bodhi side and maintain an explicit allow-list for letting them pass the gate.
This is a creative and possibly reasonable idea for keeping new packages from slipping in (although one should remember that the allow-list is dynamic as packages already in the list gain or lose dependencies).
I think someone would still need to start with a mass change, though. There are many packages in Fedora that are basically only rebuilt in mass rebuilds, either because they are adequately maintained downstream but their upstreams are very stable, or because they are actually unmaintained downstream but they haven’t broken yet, and their maintainers haven’t been affected by the inactive or non-responsive packager processes.
Also, as it stands, an individual maintainer dropping i686 causes anything that depends directly or indirectly on their package (and hasn’t also dropped i686) to FTBFS altogether, which isn’t acceptable because it breaks Rawhide. It’s not reasonable for me to have to drop i686 support in order to update a low-level library like re2 if that means I also have to coordinate dozens of packages also dropping i686 support – possibly involving waiting for the non-responsive maintainer process and/or requiring provenpackager action. The original act of dropping i686 still needs to be done either from the leaves inward or all at once en masse.
1 Like
Hey,
I’m probably just dense, but I’m still trying to understand what the least disruptive and easiest to implement path forward here is that lets us make headway.
I had hoped that spinning out the i686 builds in a copr, would be sufficient for consumers, including the ublue collective space, but kyle tried to explain to me why it wouldn’t be from the bazzite perspective, and that several other things would be needed. I’m trying to understand the concerns here and I’m missing something.
From a Fedora Project perspective moving the i686 builds out into a dedicated consumable repo structure makes the sense to me. It allows the infra team to start kicking out all the multiarch kludges that make it possible to keep i686 and x86_64 toegther.
I’m trying to understand why this isn’t workable path forward for consumers.
Fedora endusers would at worst have to enable an additional repo to get i686 packages.
I would have naively thought that I could think of other other types of consumers, build system consumers, like end users. But kyle’s attempt at an explanation suggests my mental model is insufficient at present.
3 Likes
I wanted to provide some additional context as a Bazzite user since the founder of the project has stated, “I’m speaking as it’s [sic] founder, if this change is actually made as it is written the best option for us is to just go ahead and disband the project.”
Bazzite specifically targets users that want a SteamOS experience on PC gaming handhelds. This is a growing market. Since the Steam Deck released, approximately 6 million PC gaming handhelds have been sold, 3 million of which are Steam Decks. Bazzite provides support for all the most popular PC gaming handhelds, such as the ROG Ally, Ally X, and Legion Go, as well as the Steam Deck (for those that want more control than sotock SteamOS). The Steam Hardware Survey shows that 31% of all Linux gamers on the platform are using a Steam Deck (based on the Deck’s iGPU profile). However, this doesn’t include folks using other handhelds like the ROG Ally or Legion Go, which use newer SoCs - that may be using Bazzite or another Linux-based OS. It also doesn’t include the recent Legion Go SteamOS handheld.
Bazzite’s developers have indicated approximately 2/3 of its users are using an image specifically targeting the Steam Deck or another handheld. Desktop users are actually in the minority. All the PC handhled images utilize Gamescope to provide a proper touchscreen experience. The poor UI on Windows 11 handhelds is one of the primary reasons people choose SteamOS or Bazzite. Flatpak is incompatible with Gamescope, and if you force Flatpak Steam, you’re killing the main reason to use Bazzite.
Bazzite has seen rapid growth. Since October 2024, monthly active users have increased approximately 350% from around 5500 to 20,000.
Sources:
from bazzite.gg
8 Likes
This is not really a new activity for us though. Every time we bootstrap a new RHEL release we work on trimming the Fedora packages(~20000 of them) into a RHEL subset(~2000).
While we might be not willing to setup completely independent ELN-like build infra for this change alone, we still have some tools which can be reused.
For example, there is Content Resolver.
It works like this: someone creates a definition of the workload, a yaml file which contains the list of packages which need to be present on the target environment.
And then the tool resolves it to the full tree of dependencies, using existing repositories as a data source. The result is available per architecture:
It is then updated regularly (with every nightly, I guess?)
Maybe we can start defining the Bazzite and Asahi workloads there, and get the dependency tree resolved by the tool so that we can better track and estimate the impact.
5 Likes
COPR isn’t workable because it exists outside of the build environment. That means it’s impossible to correctly handle build chains like we can in Koji. That’s why I suggested leveraging the technology we have been using for building ELN to build this.
Mechanically, it’d basically be fXX-x86_32 for every fXX target, and distrobuildsync would sequence every eligible source package built/merged into fXX for fXX-x86_32. The eligibility would be determined by content resolver, as noted by @bookwar. The tooling already has plenty of tricks to handle things like side tag update merges and such. Pungi can then pull the result and publish it as an extra architecture repository for x86_64, and a repo subpackage can be added to fedora-repos for it.
This would finally give us a Fedora use-case for the stack, since it is currently only used by RHEL people.
8 Likes
As we know, Steam being not even OSS is the ultimate origin of this problem, because nobody can fork it to implement 64-bit support. Albeit tangentially relevant, there’s a chicken-and-egg problem here, since its 32-bitness makes re-implementing the client in 64-bit significantly more difficult without violating the DRM ToS:
Whatever eventually forces Steam to update its client shall make this problem easier to work around in the future, if it has the effect of incentivising Value to remediate this. That’s why I support this effort to deprecate all 32-bit support. I’d like to leave Steam’s client behind.
By the way, someone mentioned the Y2K38 problem. That shouldn’t matter significantly for Steam, since it’s somewhat trivial to work around in all the situations I’ve seen: just add counters together.
In Fedora, aarch64 is a primary architecture. All packages are expected to build and work there by default, and the overwhelming majority do. Those that don’t must explicitly add ExcludeArch: %{arm64} and, per Fedora Packaging Guidelines :: Fedora Docs, open a tracker bug in Bugzilla blocking https://bugzilla.redhat.com/show_bug.cgi?id=F-ExcludeArch-ARM. For 32-bit ARM, it used to be a primary architecture, but was retired all at once in Fedora 37, Changes/RetireARMv7 - Fedora Project Wiki.
2 Likes
That’s well and good, but how is it supposed to handle new dependencies not yet in “the set” or bootstrap problems?
For ELN, it can fall back on content from rawhide. But for i686, there would just be no fallback available.
1 Like
Conceptually it’s because we sit at different layers - we’re not rigged to do deep distro work, this is why we say we’re not a distro. However, you can say “you make your own kernels and you make your own RPMs, you are so a distro”. That’s true from a technical perspective but from a 10k view:
We consume Fedora as base images. It’s a base container with handheld daemon, homebrew, and flathub - stamped out as an image. We sit at the top of the stack.
Our model is closer to how Bitnami operated back in the day, they took ubuntu base images, made a super cool wordpress all-in-one that people could consume. They made one of everything. Their value was “here’s a great way to wordpress.” But they weren’t involved in the minutea of how ubuntu made it’s base image. They operated at that application layer, and we’re the same way.
We sit at the layer on top of Fedora – people interested can come work on Fedora, but that’s a different discussion – I like to see us as a very “cheap” way to deliver an experience to users, and the reason we can move so fast is because 99% of the time we can use what Timothee ships and deliver something nice. That last 10% of UX that the Bazzite team can deliver via bootc is the reason we’re successful in the first place - this is how Kubernetes won everything, we just want to apply the same pattern to the desktop. 
But there are certain things that just need people who are the experts in that field, we’re a hot rod shop and some things the manufacturer just has to take care of. We may have to limp along for a lap or two but it’s an endurance race not F1.
14 Likes
While I agree with this in principal, in practice this is kind of not viable.
I am a developer primarily, and I want Fedora’s stability. However, I’m also a gamer, and I need a distro that supports steam and, yes, proprietary games. I don’t want to go back to Arch due to the instability, and I don’t want to go to Ubuntu because the release cycle is too slow. Fedora is the perfect distro for me but Steam is a dealbreaker for myself and many others, not to mentioon downstream problems with regards to Bazzite, Nobara, etc.
As a secondary issue, I believe software preservation is important, and being able to run legacy software is important. This is hardly Fedora’s responsibility, but I wish there was an easier way to run legacy software on a user-end. Sure, many non-packaged software include workaround scripts to set the LIBDIR to point to their provided libraries, but that requires someone to actually make those scripts, etc. From a purely “we want people to adopt Fedora” perspective, making it harder to run legacy software is not great. That said, I agree the current situation is not tenable either.
Maybe some day someone will make something like bottles, but for Linux 32bit software 
3 Likes
As a sysadmin who, until recently, had to support Windows Server 2003 in production, I get that supporting old/legacy applications is untenable.
However, as a gamer, who just yesterday found Bazzite, I am strongly opposed to this proposal as it is currently written.
If this proposal can be rewritten to adopt a gradual roll out that gives concessions to Steam/Bazzite/etc., I will support that proposal, but the 100% cut off/sheer cliff approach proposed here is not in any way acceptable as it has wide reaching (dare I say damaging) implications.
1 Like
I do not use Silverblue or Kiniote. Does toolbox work on non-immutable systems?
If you don’t build the i686 package at the same time as the x86_64 ones then you’ll have syncing issues and it’s going to be a constant pain to catch up with build failures when those would have been caught up earlier in the normal process.
5 Likes
This probably deserves a separate thread.
Even with the current x86 support in many cases it is much easier to install a game in wine than to use the native Linux version of it. Exactly because you have lutris/bottles and they provide a specific isolated env for each game, managed independently and containing all deps, while native games have a high chance of version mismatch with system libraries.
So containerizing games (flatpak runtimes? toolbox-es? wine-for-linux? 
) and a database similar to WineHQ, could be a good way forward no matter the architecture discussion.
2 Likes
I am not a developer but I thought Gamescope was available as a Flatpak.
Flatpak Steam and Gamescope do work together I believe, and the problems arise when only one of them is a flatpak.
Obviously there are other issues I don’t understand given that it seems to be such an obstacle.
@chapien, yes. I’ve utilised it to evaluate brew’s support for Linux:
Another user above confirmed that this works for Steam.
1 Like
gamescope is a microcompositor. The details are in the weeds but basically, it can serve as 3 types of compositor:
- Nested compositor - running on top of your current desktop environment.
- Embeded compositor - embedded in a specific application.
- Session compositor - running like a desktop environment, essentially.
The flatpak for gamescope can serve the first two. The last one, which is what console-like experiences like bazzite-deck provide, cannot.
6 Likes
For new users Bazzite is ready to go, regardless of their graphics card, and they don’t have to use silly workarounds to even start Steam, which happens on Fedora and in no other distro, it doesn’t start properly without a workaround after you just installed it.
Enabling third party repos to install Nvidia drivers is sort of fine, except the installation experience different between GNOME and KDE for example.
GNOME will give you a guided experience from the store, actually tell you that you need to reboot and will give you the password to enable your secure boot keys.
KDE does not tell you that, it doesn’t make you aware that you have to go through the signing process in the same way that GNOME does.
Yea you can use the akmod command, it gave me problems with Secure Boot, where it saw an old key used in a previous installation and refused to build the drivers.
None of the above is user friendly, and not being able to even start Steam is a little silly.
So yes, people don’t want Bazzite to die because it does wonders for gamers who are just swapping to Linux.
And Bazzite IS basically Fedora, they are just layering packages on top. It’s not a fork in the traditional sense where they are going their separate ways. They are bringing new users to Fedora itself. It’s also pushing the immutable design from Kinoite and Silverblue and making more people aware of it.
It’s not about Bazzite, Bazzite is just a symptom of what would happen to gamers in general when using Fedora. If Bazzite shuts the project, what do you think the gamer users will do, even those who just use Fedora? They will leave, because the reason why Bazzite would shut shop is that gaming becomes too difficult on Fedora.
4 Likes