Not rejecting, as I stated those solutions fundamentally cannot be used for 2/3 of our users. The remaining 1/3 would get a worse experience, and any VR users would just have their setup broken.
That’s not acceptable and why we would be forced to give our users that year to transition to something else unless the timeline is extended or Neal’s concept is considered.
But you are providing an entire computer operating system. Why can’t you also provide your desired version of Proton…?
Proton versions live in your home directory, any solution where we provide our own in a pre-installed way would be kludgey at best. That still leaves our users having to manually set every game in their library to use that version, we can’t do that for them without messing with files we have no business touching.
I’m a newish maintainer (or, soon to be maintainer for MyGUI and hopefully openMW). While I don’t think 32bit would effect my packages personally, and while I ultimately do think that in the long run 32bit architecture will have to be discontinued at some point or another, I don’t think now is the time – or even that Fedora 44 is the time. Others have pointed out issues with various 32 bit programs; steam is a common worry. I believe the flatpak would still work, but I don’t really consider that an ideal solution/alternative.
Obviously, with regards to gaming, 32 bit games that are for Windows should be fine thanks to wow64 and proton’s handling of it (assuming valve releases a 64bit steam any time soon, but they seem to have little interest in doing so), but there’s the problem of legacy games. It’s easy enough to say “unmaintained software shouldn’t be installed”; largely, I agree with this principal. However, this is unfeasible with software like games in particular. Though games weren’t ported to Linux until recently, there are some native Linux games that might still be 32 bit that are effectively “abandoned”.
It’s the nature of how game development works, and that’s the field I come from originally; when a game is finished, assuming it’s just a single player game and has no major issues, it is generally not updated anymore. For other software, we would call this a security risk, but it’s just the nature of how games (esp indie games) are made. They aren’t developed like other software. While I have no specific examples of 32 bit legacy games for Linux off the top of my head, if they do exist they will effectively become unplayable on Fedora. Which I personally think is a preservation issue; I realize it’s hardly Fedora’s responsibility to preserve games, but surely we should figure out a workaround before we drop all support entirely?
Jumping in here because I’m picking up on perhaps a little bit of a knowledge gap that’s making discussion more difficult than it needs to be.
When @kylegospo is providing the 2/3s number, he is referring to users of the -deck image variants (which make up roughly 2/3s of image pulls).
These are not typical desktop images - they do not boot into a traditional desktop environment, like KDE or GNOME.
Instead, they boot directly into Steam’s “Gaming Mode” environment, which is built on the gamescope compositor (a barebone compositor specially developed by Valve). This provides a tenfoot/console-like interface, as follows:
These images are intended to be a drop-in replacement for Steam Deck OS for handheld console-like gaming PCs like the Steam Deck (Lenovo Legion Go, ASUS ROG Ally, MSI Claw, and other hardware in the same space).
These are also to be used to create gaming theater PCs, for streamlined use on a living room television.
The issue with “just using Flatpak or a container” is that the gamescope compositor simply does not work in those situations, when paired with Steam’s Gaming Mode, as it has the same concerns as a desktop environment. There would simply be no way to serve Gaming Mode as an environment.
As such, moving to this would essentially force Bazzite, as a project, to abandon its primary reason for existing - alienating 2/3s of their userbase. The remaining 1/3s would be served a lesser experience for a variety of more paper cut reasons, and VR is already a complex topic which would get even worse.
Alongside the reasons that were elaborated on above with regards to Proton (no way, without polluting Steam configuration files that Bazzite shouldn’t be touching, to provide the streamlined experience which is the intent of Bazzite), this is one of the main points of contention with this proposal as it stands. It may be emotionally charged, but it stems from a completely practically-driven usecase concern.
Strongly against it! I can see 32bit being dropped at some point eventually but I don’t think we anywhere near it just yet that’s at least another 5+ years away. We have plenty of software that use it, yes there is work arounds in some cases but its not ideal and creates additional problems. Would negatively impact great downstream projects like Bazzite as well.
I would argue that Steam is a special case and thus should be treated as such. If I understand the difficulty it would be older proton (assuming newer proton gets Wine’s new wow64) and a few Chromium deps which may vanish once they up the requirements taking it out of compatibility range with older versions such as EL8.
Of course, spec files can be patched back or patched a-new and 32bit packages could be produced for edge cases by those interested in such things. It is your OS after all according to the footer.
I think it’s a bad idea, at least until actual solutions for gaming are put into place. Not theoretical workarounds, that might or might not exist, when this proposal could be implemented. That’s my opinion, anyway.
Sorry but I am sure when Linux was first conceived, and computing was first conceived, nobody even thought people would eventually do many things they do now on computers.
A lot of people DO game on Fedora. GOG is not nearly as big as Steam. Steam is the main platform people are worried about here.
The evolution of a platform should follow its usage, and lead it, not cut people off. This is the DESKTOP experience we are talking about.
Now I have seen that ticket for Steam requesting 64 bit support, and it’s 11 years old. I do wonder how we can push that to make it happen to alleviate at least some of the problems, because I don’t think this is entirely Fedora’s problem (and it definitely should not be).
I just don’t like the attitude of your post basically saying, “Screw you, segment of people I don’t really care about.”
The irony here, coming from the Flathub-first side is this is the one actual use case where having Steam be on the image makes the most practical sense. Lots of people have put effort looking into this, it’s not just us.
bootc makes it easy to customize at the build step anyway, this is why the pattern exists, to in turn enable a Bazzite to exist. It’s this ability to customize that makes the pattern so powerful. See ublue-os/image-template and bluebuild for two examples. Steam is just an example here, but also edge, automotive, etc. That’s why people are into it, and this conversation can probably apply to an embedded device as well.
Those of us with skin in this game know the absurdity of having to keep this stuff around. This is costing distributions developer time and resources, and it’s not cheap. The core problem is Steam’s technical debt, at a time when open source developer time is under so much stress. It doesn’t feel good.
We all have tech debt, this isn’t a unique problem, I think the right path forward is for folks to get together as a group and open a dialogue with Valve. We are after all their customers!
Hearing Fedora contributors saying “Just use a flatpak from Flathub” does put a smile on my face!
The thing is, “kludgey at best” is also an excellent description of multilib. The choice here is not whether or not there need to be kludges, it’s where the kludges ought to go.
We don’t have to do the merged repository thing if we don’t want to. Making a separate repository and shipping the repo file (and also passing it into the FEX rootfs image build) is a valid option.
In this conversation I see many people claiming that RPM Steam will not be installable anymore.
I would argue that is not necessarly the case. In fact, any other repo could provide the tens of 32bit packages required by Steam, and the Steam (but also Bazzite, etc) users would have 0 knowledge of this change.
I think the real question is: is it correct that the Fedora Community has to make the effort of providing those packages, considering that Steam does not even consider Fedora a supported platform?
The answer to that in a moral and just world is a resounding no.
In this one, the answer is yes, particularly if you all want to ship and have a successful product.
I completely understand the issue of unpaid volunteer time and being involved in large projects but this change should not be done exclusively because there’s not enough man power.
It’s not right that it’s Fedora’s problem, but it’s here and it’s a requisite problem to have as a growing Distro.
Nuking steam and other important 32bit tools that might be needed (for the record, if the steam issue could be resolved, I’d be all for getting rid of it for the most part) is against the spirit and written text what members of the fedora committee and other members involved with the project ad a while have posted over the years.
I use fedora as my main coding and gaming platform, depending on how tech savvy the person is, I’ve also gotten countless others on fedora or bazzite(if they just want the ootb gaming experience to just work).
The only sane solution that should be supported is the one @kylegospo and @ngompa have proposed.
An opt in solution instead of opt out. Anyone who thinks otherwise sounds a bit out of touch. This had already done immense damage to the Fedora brand from countless articles to people talking about it online like it’s the end of days.
Note that ubuntu 26.04 LTS will literally be released within weeks of Fedora 44 (the release this proposal is currently targeted at), so any changes they make in 26.04 will need to happen in a similar timeframe than the changes outlined in this Change Proposal, so I don’t think we’d even necessarily need to delay this Change to see what ubuntu does.
It seems very strange that first you say “resounding no”, and in the statement after you say “but in this case yes”.
Resource constrain is a real thing, and Fedora (as all other distros, projects, etc) will continuously need to make decisions on what to add, what to keep, and what to drop.
As other have pointed out, this dicotomy is not correct. The fact that 32bit libs are not present in the Fedora official repos does not mean that Steam has been nuked. There are many other ways for Steam to work (external 32bit repos, copr, flatpak, etc).
Sorry, but this is how Fedora works. Anyone is free to propose changes, then the community discuss about the proposed changes, and the FESCo votes for the proposed changes. This proposed change is not, and should not be, different from any other.
For the sake of productive discussion, I think it is worth looking at the bigger picture.
I see that at least 2 of 3 owners of this proposal are employed by Red Hat. Considering that RHEL dropped support for 32-bit libraries, the desire to remove these from Fedora as well is not surprising from the prespective of cutting maintenance costs (hardware + human-hours). However, this change proposal appears to not consider other perspectives and it makes me doubt my understanding of Fedora’s role in the grand scheme of things.
My understanding is that Fedora for Red Hat is a testing ground available for general public, and the “contract” here is “get functional OS at no charge, participate in gratis testing of new software”. I am using Fedora for quite some time as a workstation for software development and a general purpose desktop OS for various day-to-day things, including recreational activities like playing video games through Steam.
I believe that majority of people who use Steam on Fedora are not using OS exclusively for video games. Making them jump through hoops to use Steam reduces convenience and as a result, makes them more likely to select another distribution (for instance, Canonical provides their Pro subscription for Ubuntu at no charge for up to 5 PCs while maintaining i686 packages required to run 32-bit Steam client).
If you visit About Us - Valve Corporation you can see number of concurrent online Steam users (26,357,963 at the time of writing; yes, millions). Recent Steam Hardware & Software Survey shows that 37% of Valve clients still use Windows 10, and with it becoming not supported this year together with improvements in Proton compatibility layer may make these people consider other OS options, including Fedora.
Regarding Flatpak — if you visit Install Steam on Linux | Flathub the package is explicitly marked as “Unverified”. A lot of video games cost money (+ in-game purchases) and people may be reluctant to trust such package with their Steam account.
Considering the above, timing and sentiment of both the proposal and messages posted here by some Red Hat employees, I think it will be beneficial to properly manage expectations and state, what is Fedora now an what it wants to be? Is general public convenience worth extra maintenance efforts (all packages, subset of packages required to run Steam and other widespread software, …)?
