Meh: It’s inevitable. It’s really Valve that we should blame for dragging their feet for so long.
I wonder how much power Valve even has here. I mean, we’re talking about Windows compatibility. How many Windows games can run properly in a 64-bit WINE environment?
Dropping 32-bit support has to happen eventually, but there’s bound to be collateral damage. It wasn’t a painless change even on macOS, which is generally a more tightly controlled “adapt or die” platform.
I was using Flathub’s Steam years ago already to avoid installing any 32bit system packages. Works fine. This change is no problem at all.
I wouldn’t expect anything ready any time soon. Especially when you look at Valve’s own stats where Fedora doesn’t even register in the top 11 distributions used on Steam. Although, we don’t know what distros make up the 7% for the Steam Flatpak - but that’s not supported by Valve anyway.
Isn’t Bazzite built on Fedora Silverblue and installs the Steam Flatpak? I could take a guess.
Isn’t Bazzite built on Fedora Silverblue
Kinda.
installs the Steam Flatpak?
Actually no. Bazzite installs Steam from the RPM Fusion repo.
As for an attempt to shed light on why Fedora is absent from Steam’s numbers, see this comment. Finally, perhaps this is worth looking into to see how big Fedora’s gaming community is compared to the rest of its users.
Right, Steam is baked into Bazzite, not installed on top. I stand corrected.
The first set of numbers you link match my intuitions about what’s happening to the Steam data. The second seems… less reliable, given the methodology, and don’t say much about Fedora gamers in particular. The overall takeaways about the size of Fedora desktop do make sense to me, though.
To complete the cryptic “kinda” answer, because you made me look it up, their Gnome variation is built from Silverblue and they have a KDE variant built from Kinoite. Fedora Atomic either way, for our purposes here.
Well articulated reply. Thank you!
It’s just dropping them from distribution, I think it’s a good idea to separate this codebase before 2038.
The Unix epoch problem is completely unrelated to a program being 32-bit or not. The architecture affects the maximum addressable memory space, not the size of individual types. You could easily define and use a 128-bit type in a 16-bit environment, for example.
The epoch problem is simply due to a bad design call a long time ago - one that proved foundational and incredibly difficult to change once it’d become an entrenched standard. They could have made timestamps 64-bit at the time, and probably would have if they’d known their work would survive the several decades it’d take for that decision to pay off.
SLES, is that you under there?
