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 think Wine has had WOW support for some time and it seems it will be the default at some time (arch moving to wow64).
Edit: What is WOW64
All transitions from Windows to Unix code go through the NT syscall interface. This is a major milestone that marks the completion of the multi-year re-architecturing work to convert modules to PE format and introduce a proper boundary between the Windows and Unix worlds.
All modules that call a Unix library contain WoW64 thunks to enable calling the 64-bit Unix library from 32-bit PE code. This means that it is possible to run 32-bit Windows applications on a purely 64-bit Unix installation. This is called the new WoW64 mode, as opposed to the old WoW64 mode where 32-bit applications run inside a 32-bit Unix process.
The new WoW64 mode is not yet enabled by default. It can be enabled by passing the --enable-archs=i386,x86_64 option to configure. This is expected to work for most applications, but there are still some limitations, in particular:
Lack of support for 16-bit code. Reduced OpenGL performance and lack of ARB_buffer_storage extension support.
The new WoW64 mode finally allows 32-bit applications to run on recent macOS versions that removed support for 32-bit Unix processes.
I think Wine has had WOW support for some time
Wine has two forms of WoW64. Old WoW64 uses 32-bit libraries and has been around for a long time.
New WoW64 (first available in Wine 9.0 if built with a special option) works without 32-bit libraries, but is still incomplete. It cannot yet replace old WoW64 everywhere, and even where it can, it reduces performance in some APIs. (For example, OpenGL.)
It will eventually make sense to drop the old one, but doing so now would be premature.
Thanks, TIL.
Cool, sounds promising!
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 process being 32-bit or not.
SLES, is that you under there?
