Where should they direct their payments? I’m certainly not opposed to paying something for Fedora, but AFAICT the usual response to that idea in the past has been to redirect money away from Fedora towards upstream projects instead.
Steam AppImage (AnyLinux-AppImages in general) is more secure than conventional AppImage, as it can use latest libfuse3 instead of old libfuse2 from the host, but I understand the point of relying on libfuse as a SUID binary for mounting. libfuse is used by default for less RAM usage, with fallback if it’s not available.
However, usage of libfuse can be easily disabled, so distros & custom-images can patch it easily & natively with sed as documented in uruntime to increase security & it basically being on-par with native packaging regarding that (if not a bit better due to usage of container). AppImage (along with any binary) can be also sandboxed with bubblewrap for more security, but that’s more work, even with simple-appimage-sandbox wrapper.
I agree that AppImage using a container is not an ideal solution, but it was needed, as 32bit+64bit packaging is not reliably supported for stracing in sharun at the moment. However, it’s in scope to get rid of container one day in Steam AppImage.
So yeah, that’s not ideal for Asahi Linux as mentioned.
Yes, I agree it doesn’t solve the problems with other 32bit software.
I wanted to also chime on discussing things outside of Steam, but just saw it now that edits are not allowed.
Ideally 32bit & other software would be packaged as statically-linked or in another portable way, so they don’t depend on the distro decisions, but it’s a reality they mostly don’t, so I’m -1 on Fedora implementing this proposal & +1 on holding it at least a bit more, to not hurt the users which depend on crucial 32bit applications.
Is @jwp 's proposal not acceptable? It looks in depth to me.
I think to be considered a “proposal”, it has to go through the Change Proposal process: Change submission guidance :: Fedora Docs
To my personal account 
Now seriously, I know that we are not dealing with money in the fedora community. I guess the main sponsor of the community is offering payed services. They maybe are willing to manage a fond for paying some developers/engineers which will initiate a Work-group which will resolve it with a smooth transition for the i686 support and also create timelines when this all should happen.
Does it matter that opting out from the leaf doesn’t scale? If only about 200 of the 10,000 libraries are needed, could you script opting out every package and then opt-in just those 200 packages?
1 Like
I know this has been said before, but this change would be entirely disruptive to me and my workflows.
I currently use Fedora to build software in many CI pipelines, and I build and test 64-bit as well as 32-bit binaries. Not being able to build or run 32-bit binaries would mean I would need to setup entirely different 32-bit CI configurations, and would need to pass artifacts between these different containers, etc.
“Everything is just code” of course, nothing that “can’t be worked around” but this would add significant complications and would probably end up with us dropping the use of Fedora, which is the preferred distribution of everyone I work with.
Even worse than the above, we also use various commercial (32-bit) programs (not games). Losing the ability to run these programs in our standard environments would mean Fedora becoming useless to us.
Would it be nice if all vendors only statically linked 32-bit binaries or provided 64-bit binaries? Of course it would. But that’s not reality.
I VEHEMENTLY oppose this change. It would be the end of a nearly 20-year run of Fedora for me - I’ve been using it since 2006.
2 Likes
Personally, I don’t really care (and for the record, I have no multilib packages installed), but I find it a bit unfair that just because some closed-source vendors, like Steam, refuse to provide a native 64b binary, distribution maintainers—often volunteers working in their personal free time—should be expected to maintain a 32-bit userspace indefinitely for them.
If those vendors want to continue providing proprietary binary software, they can and should supply working binaries for modern distributions. We have solutions like Flatpak, Snap, and containers that can greatly assist with these tasks.
1 Like
I think the discussion of Steam producing a 64-bit binary is mostly irrelevant.
Even if Steam itself was 64-bit, that wouldn’t change the fact a huge percentage of the games people use Steam to play are 32-bit. Unlike most software, games are mostly a “point in time” creation. Excluding a handful of long-running titles, most games don’t continue to get architectural updates. The game is created, patched for some period of time and that is that.
Dropping the small number of libraries that these games need to run or are needed by Wine basically means all of those games will stop running on Fedora. Most people won’t even understand why they aren’t working since there isn’t a clear delineation between these games.
This would cause users to generally feel that Fedora isn’t suitable for gaming.
1 Like
Let me be clearer about what I mean by actionable.
Its easy to propose a process around a set of hypothetical new tools, its more difficult to resource the manpower to build those tools.
Other proposals put forward so far feel more actionable to me because the tooling is less hypothetical. Neal’s suggestion, for example, to repurpose the ELN tooling feels more actionable because its already exists and is doing a thing. Transitioning it to do another thing seems like something that can be prototyped right now. That’s actionable.
I think Joel’s proposal is bolder and perhaps more forward looking in terms of rethinking the infrastructure. An unlooked for gem in the discussion from my perspective as the Fedora Project leader for sure, but not for the reasons that probably matter to anyone primarily focused on the impact of dropping the i686 packages.
But at present its not as clearly actionable because I don’t see a path forward right now to resource what it requires. I want to wrap my head around the implications of this proposal, because it feels bigger than just solving the i686 problem. If anything solving the i686 problem becomes a side-effect of solving more forward looking problems. But because its bigger it also means there maybe a need to align more resources to get it done which makes it less actionable in the moment.
2 Likes
I find it a bit unfair that just because some closed-source vendors, like Steam, refuse to provide a native 64b binary, distribution maintainers—often volunteers working in their personal free time—should be expected to maintain a 32-bit userspace indefinitely for them.
Even if Valve does its job right and provide a 64bit binary, there are thousands of 32bit Linux games in binary that will not run anymore. This problem is not limited on Steam.
I think this is the first time that there is such a high demand for backwards compatibility on legacy binaries on private Linux desktops.
1 Like
Since we have twelve years or so before 32 bit falls off the cliff regardless of what we do, is there not time to do both? Make a change now to prevent things getting worse while people build the infrastructure for a long term fix/improvement?
How about F43 is going 32-bit but lts for 2037, and F44+ will be the same as before but 64-bit only? That way those who against change can stay on that more and more stable with years version? That way maintainers, release engineering, infrastructure can focus on 64-bit only releases, and the 32-bit would only need to be updated with fixes, and no de breaking updates(looking at you ubuntu and windows).
And i feel like they really need the extra capacity as they want to change the boot loader in 43, and if you think there’s a lot of complain by bit32defenders, wait till you get put after ubuntu again(how they wanted to drop 32-bit before), how the update broke the system and now they can’t boot… And personally, i would also stay on this F43 version, but if nothing changes and we take the wait and hope valve do something, i have to stay at my original plan to update from 42->43 just before the 44 release…
Let me dissuade you from the idea that clock time is the only resource constraint.
I am concerned about people time. You can make a wish list of asks on how the infrastructure could change.. none of them actionable.. on any timescale…because the people with the skills and time to do it all don’t exist.
So no I don’t assume we have the ability to do both given the people constraints.
And let me reiterate i think the 2038 cliff is a copout to not avoid addressing the maintainer load that i686 builds represent. We must find a way to separate out the i686 in a way that lets people lay down that burden so other people who care about it can pick it up. Just telling people to wait till 2038 means accepting that more contributors walk away because they are overburdened. What I need is a way for more contributors to stand up and carry the load well before that.
Because ultimately if the right people are doing that work for self-interested reasons well before 2038.. then I have some measure of hope they can will for self-interested reasons blunt the anticipated doom because they will be empowered and trusted to make technical decisions for the 32bit software user-case well ahead of 2038. We need to build a space for those people as contributors well ahead of 2038.
5 Likes
Even if Valve does its job right and provide a 64bit binary, there are thousands of 32bit Linux games in binary that will not run anymore. This problem is not limited on Steam.
Do you have any suggestions about how we could identify exactly which libraries are required by these thousands of games? Hopefully, these libraries are all extremely mature and never have an ABI-breaking update, as that would make them unusable as dependencies for pre-existing closed-source software anyway.
We also have people talking about doing 32-bit CI testing of arbitrary software and running arbitary unspecified 32-bit commercial programs. Again, one could hope that most of these use cases would not require anything that isn’t already needed for Steam, because binary-only distributions tend to minimize shared-library dependencies, but there is no way to know what is needed without identifying specific programs that we need to support.
It does feel to me as if part of the discussion may be looping back to “we should actually keep as many 32-bit packages as we can, indefinitely,” and that’s not going to be viable. We are going to have to find a mechanism by which drawing a line in the sand is technically feasible, and we are going to have to base where to place that line on specific, identifiable requirements.
We are certainly not going to be able to keep supporting 32-bit builds of almost all of the distribution until 2038 (and perhaps beyond, as not all software will necessarily break when it becomes confused about what time it is), or even close to that long, just in case some unspecified commercial software might be trying to use it.
(I do apologize in advance if I’ve incorrectly implied that a particular commenter was advocating that; I am not trying to shame anyone for the valuable contribution of honestly stating their use cases; and I am not trying to single out the person I replied to in particular.)
1 Like
I appreciate this puts you in a very difficult position. I don’t mean to say that clock time is the only constraint, just that it’s the final limit, the ideal is of course that this problem is fixed sooner rather than later. As I stated in my first contribution to this discussion I see this as being very similar to X11 - The world needs to make something new and eventually leave the old behind but we’re so entangled in it that getting out of that is going to take a lot of time and care if we don’t want to break an untold number of known and unknown things.
In light of the clear damage that would be done, I don’t see cutting our way out of this entanglement as sensible, therefore I feel like the only way forward is to build our way out with some kind of system that maintains interoperability while minimising maintainer cost. With that said, if the maintainers are overworked as is, then I agree there has to be some immediate measure to reduce that load.
To that end, and please forgive my ignorance, is there nothing major Linux organisations (The Linux Foundation, etc) can do to assist in building infrastructure that solves this issue for all of Linux?
1 Like
I actually agree with you. I think Joel’s solution is fascinating, and exciting, but it would take a long while to implement.
One thing that needs to be made clear is that it is not solely a gaming issue, though that is the most visible issue. As others have pointed out, it would cause problems for developers, too. I’m a game developer who works for a small porting studio, and I use Fedora as my daily driver (I’m work from home, so I can use whatever system I want). I’m fairly confident that if we dropped 32 bit libraries with no contingency in place, I would not be able to continue to develop from my Fedora machine. And I would really hate to have to leave Fedora, because I love this project and this distribution.
I think the most actionable move would be look at how other distros (re: Arch, Gentoo) have handled it with their multilib repos. Arch does not include multilib by default, but it allows downstream projects (Manjaro) to do the same; surely the same could be done by Bazzite, Nobara, etc. for the sake of end users, while developers like me would be able to continue using Fedora Workstation and simply include a multiarch repo.
I say “simply” from my perspective, mind. I am fully cognizant that it is not so simple from the POV of the maintainers. But it’s also clear that some maintainers, while they are justifiably frustrated by the burden of maintaining legacy architectures, are not understanding the concerns of other maintainers. In this thread people have said “Why can’t Valve just do 64 bit” without understanding why they do 32 bit in the first place. They claim its solely the nature of proprietary greed, without understanding how messed up the game development stack really is for AAA and indie alike.
In the mailing list, I saw discussion of how GCC requires 32 bit libraries as well, and there were lots of responses from (well-meaning) maintainers ignorant of the nature of these sorts of projects claiming it should “be easy” for GCC to change their workflow to no longer require those libraries.
This is patently not true. Yes, maintaining packages is difficult and time consuming. So is developing software, obviously. It feels a lot of maintainers claim these things are “easier to fix upstream” but as someone who has worked upstream, that ignorance is extremely frustrating to see. I wish more maintainers and developers would have the humility to admit that none of us know how every single piece of software and library works, rather than claiming to know the answers just because we have expertise in this area or that area, and therefore know best.
I don’t agree with using this proposal as a “Sword of Damocles” to motivate other proposals to come forward. That means outsiders – gamers and devs like me – will see this as the “default” outcome, which will cause uncertainty in the long-term future of Fedora as a reliable gaming and developer platform. You can argue Fedora is a Workstation, sure, but if I can’t program on your Workstation, just what work am I doing?
Sorry, I went off on a rant that’s not so much directed at you as the general atmosphere. I want to contribute to Fedora. I’m working on unretiring a package and maintaining another one, which hopefully will be approved soon. But exhausting conversations like this drive people with less fortitude than myself away from even considering volunteering. Why should I volunteer if other maintainers (especially @catanzaro) are actively hostile to what I need for my development purposes? “We shouldn’t be burdened by proprietary software” okay, what about being burdened by compilers? By me needing an actual development environment? And to be met with repeated ignorant answers, to say things like “they can drop 32 bit, I know best, I’m an expert and know better than developers upstream”, despite explanations as to why it is difficult from a developer POV, is very very upsetting.
5 Likes
I’m seeing a lot of first time posters in this ridiculously long thread. Welcome to Fedora! We value your input, but please keep this bit of guidance from the start of the thread in mind before replying.
This applies to everyone, not just first time posters. If you find yourself using the words “reiterate” or “echo” or “switch to another distro”, please take a moment to consider if your reply is actually adding to the discussion.
22 Likes
I agree with this sentiment. Fedora 44 is not that far away and as Kyle has said earlier in the thread, this has already created brand damage and loss of user confidence in Fedora (and by extension Bazzite) for gaming development and as a gaming platform. We definitely don’t want to see that. Fedora has been gaining a lot of momentum as a great place to play and develop games. If we are talking about momentum, this is taking away that momentum and creating uncertainty. The proposal at the very least needs to be tweaked if it is going to be left as the default proposal for solving the maintainer burnout problem with i686.
I think that this is the key insight to this problem. We need to have an actionable alternative to avoid maintainer burnout and to solve the problems folks have brought forth to this thread. But we also need time to establish a separate proposal that takes into account all the stakeholders that are affected.
If we are talking about something actionable, how much time do we feel is reasonable for stakeholders to create a counterproposal or allow this proposal to be tweaked to create an actionable solution before this proposal goes for a vote and ultimately implemented?
2 Likes
To synthesize what I said:
The issue here is “whom are YOU (Fedora Devs) developing this Operating system for?”, because if they create something that nobody wants and/or needs, for how small Fedora is in the world of Operating systems, they will just create an OS that nobody will use.
1 Like