Bazzite would shut down if Fedora goes ahead with removing 32-bit

Exactly. This scenario was brought up very early on in the Discussion and it's not treated seriously. Some outright gleeful about dismissing the usecase of natively installed Steam (take a guess who they are).

We cannot allow proprietary software that we cannot fix to hold back Fedora development. Removing i686 support is critical. It’s long past time to do this. Thank you, Fabio!

It’s not clear that there is any actual serious problem here anyway. The strongest argument I see above is “I don’t like Flatpak and now I have to install Steam via Flatpak rather than via RPM like I would prefer” which is just not a very convincing use case.

In regards to steam another issue with flatpack is that using VR with it it’s simply not possible.

Surely this is not important enough to merit continued production of i686 packages.

This is bad. We are doing the EndOf10 campaign and gaming is currently becoming a killer app / honeypot for getting more people on Linux Desktop. Bazzite is one of the desktop that has AMAZING growth, even if it may seem small right now (it's right there, in their public number, both the not very big number now but amazing growth trend).

To have this news of Bazzite potentially shutting down because "Steam is legacy" right when Windows is making headway into gaming is a bad news!

From a gamer's point, the fact that 32 bit will be dropped at some point is reason enough not to invest in Linux anymore. This is huge for Microsoft, as those people will buy Windows devices now. Microsoft still has a lot of work to do but in the end they will get Windows into shape as a great gaming OS. At that point, if they keep it open (as in: allow other storefronts) Valve will probably jump ship and be done with Linux.

Realistically though, as I pointed out in the initial article covering it on GamingOnLinux, Fedora's user share on Steam is low to the point Valve likely won't care until more distros do it which will delay it even further.

That's not a viable method, either. You can't have lots of distros planning on breaking everything and hope that Valve swoops in as a white knight to fix it - what if they don't? What if they just keep 32-bit on SteamOS and blow out all the seppuku distros?

The method that would work is to continue the approach that Ubuntu took after they got burned by this issue - identify the 32-bit parts that are needed to keep everything working and make sure they keep working. Ideally work with other distros and application developers to make that list get smaller over time rather than bigger. Perhaps they'd ultimately be able to be put in a separate container like snap or flatpak so that all distros could have access to the same set of 32-bit libraries without having to maintain them themselves. Breaking things is a Bad Plan regardless of what Valve does or doesn't do.

Meanwhile, on Debian...

> apt list --all-versions|grep " i386"|wc -l

71914

I wasn't saying other distros should do it, just that Valve wouldn't take notice unless some other major players did.

You can't have lots of distros planning on breaking everything and hope that Valve swoops in as a white knight to fix it - what if they don't?

It's not hoping that Valve swoops in, it's demanding that a multi-million $ company does its f****** job & fix their client. Its pathetic that isn't 64bit, yet.

@Eike I do like the idea of Debian... But the idea of offering Debian for Gaming in the same way Bazzite does sounds very complicated! Even Bazzite makes a point to use ublue-os Cloud Native configs which itself is downstream of Fedora Atomic, because they offered a solid base to build a stable yet up-to-date base image so we can support something like a ROG Ally day zero, having a separate base image for both legacy Nvidia system for both DE, and also supporting emerging open Nvidia drivers and new hardwares in general!

Fedora was a perfect middle ground for all of it and there's a reason why Kyle transitioned his custom setup into a proper OS image under Universal Blue!

Debian is great, but it isn't the answer to everything. I wonder though... Maybe NixOS under bootc???

But the idea of offering Debian for Gaming in the same way Bazzite does sounds very complicated!

I wasn't meaning to propose Debian as a Bazzite replacement. :) I guess they're not really in the same market. That said, I'm playing on Debian all fine, and it's by far not as complicated as many people seem to think (including Nvidia usage).

My main question would be: How is Debian doing that, and why are other distributions not doing that?

Perhaps open a separate one to talk about changing build architecture to build fewer 32-bit packages?

Canonical has been doing that in Ubuntu repos for years. Some apps simply don't have i386 packages. As bothersome as that is, it is a fine compromise rather than dropping x86 support entirely.

This does show the benefit of OpenSUSE's way of handling their distro.
Not a recommendation nor an attempt at starting a distro war, just explaining how it works:

OpenSUSE Leap and derivatives like the immutable Micro flavours do enforce higher CPU requirements and package less software.
But Tumbleweed keeps legacy support, both with packaged software and architecture support.
I will note that OpenSUSE's Open Build Service and Fedora's Copr are similar and that I am not familiar enough to explain the differences.

Practical examples:

SLES 16 will require support for x86_64_v3 CPUs.
Since Leap 16 follows this, it would have gotten the same requirement.
They since decided to keep supporting x86_64_v2 on the community Leap 16 distro, though communication has been contradictory on this.
Which is a blessing for my ageing but reliable home server, but besides the point.
This since Tumbleweed will keep full x86_64_v1 support, at the cost of the more thorough testing done on Leap/SLES updates.
And in-place switching to a different distro version is possible, going either way.

Steam has an 'official' re-package on Tumbleweed, but requires adding the still official but experimental and less supported games:tools repo on Leap.
This is only an opi steam command away from adding on Leap, but it not being on the main repo is significant here.
As the main repo is kept compatible on updates, even on Tumbleweed, but community repos might develop dependency conflicts.
If this occurs, Zypper is smart enough to uninstall the problematic package from the system.
This in stead of self-destructing in dependency resolution, like Ubuntu with a prioritised PPA or Pop!_OS in the infamous Linus situation (example, not hating on the distro).
More accurately, it will give you dialogues on what resolution to choose, sorted on how sensible the choices are.
But when updating in unattended mode or through packagekit (Discover, Gnome Software, ect.), it defaults to the first options, which is good enough with only a few community repos installed.

Leap 16 will drop YaST2, which is a controversial move since that software is well-liked in the community.
But Tumbleweed will keep the software around, in as-is no longer updated but functional form.
Though in their messaging, the team made it clear that they are open for community members to pick up YaST maintenance for their own use.

Furthermore, the immutable Micro flavours are directly based on Leap and allow for overlaying Leap packages over the image.
To my knowledge, this includes community repositories, including ones which re-add legacy dependencies.
Making it possible to just use those on otherwise incompatible systems, though the need for a re-start makes them only recommended for servers.
That said, here it makes more sense to build a different image with the needed software installed.
I am not familiar enough with immutable distro's to know how feasible or applicable to Fedora Silverblue this is.

Circling back to the issue here, OpenSUSE's Leap 15.6 documentation currently lists support for running 32-bit applications on Leap.
But it lacks support for building new 32-bit applications.
The links to Leap 16 information are very broken at the moment, in what I can find I am not seeing mention of this getting dropped, but time will tell.

Summarising, OpenSUSE does drop support for software and hardware on Leap, similarly to Fedora.
But they leave the door open for 'legacy' usecases on Tumbleweed, at the cost of the less thorough testing of updates.
Though they are still above average on testing their core repository.
And the package manager is smart enough to resolve dependency conflicts in a way which keeps the system reliable.

Well, I hope this gets sort out sooner rather than later. I was going to build mini PC for kids entertainment and Bazzite was no.1 distro to use. Now if this goes through what would be the alternative? ChimeraOS?

I've settled comfortably into Fedora for about a decade now but I might start eyeing something, probably Arch again, if this even starts going forward. While I hope the day can come soon, it is much too early to drop the entirety of 32 bit support and the apathetic responses to people showing actual (not even just Steam) use cases are disheartening.

It seems to me there is a lot of bad faith reaction to a statement of intend aiming to find solution for when critical upstream package will stop suporting 32 bits.

That's how I interpret

And it’s better to start planning for the removal of i686 packages now than when (insert foundational package here - for example, CPython) stops supporting 32-bit architectures and we need to scramble to adapt.

This is very sad, but I can't help but wonder why Bazzite (which launched on late 2023) trusted using Fedora as a base in the first place, since earlier in that year we have seen a major Red Hat / RHEL controversy regards source code restriction (and probably many more before I joined Linux back in 2021). That being said, perhaps changing the distro base could salvage the project? What about using openSUSE, which also relies on RPM packages? It's most likely easier said than done (I'm not a programmer myself), but that got me thinking if this is really the end for Bazzite.

I've been using Bazzite comfortably for almost a year and I'd really rather not have to find a replacement distribution for my desktop. I could go back to Kubuntu, but then I'd have to deal with Snaps again...no thanks.

I think this isolated comment in a very big thread misses a lot of the bigger picture.

A long-time Fedora packager points out:

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 other options: ship the final Fedora builds of the i686 packages that you need

Followed by a user (not developer) of Bazzite saying:

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.

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.

I feel compelled to add Neal Gompa, contributor extraordinaire to Fedora, openSUSE, CentOS, currently on the X.org board, big proponent for dropping Wayland for Fedora on KDE/GNOME among many other things, offered another solution far earlier in the thread: https://discussion.fedoraproject.org/t/f44-change-proposal-drop-i686-support-system-wide/156324/27

We have the infrastructure for this with the ELN stuff, a selection of packages could be autorebuilt for i686 in a secondary tag and then the result is merged into composes.

Essentially pairing down the 32-bit packages into just what's needed for Steam and a few other choice pieces of software. There was some discussion about the feasibility of this, but it doesn't seem impossible, and is the solution Fedora is most likely to go with.

P.S. Not a Fedora user.

@pleasereadthemanual, random user comments don't line up with the history of Bazzite.

As said Kyle Gospodnetich said in reply:

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.