As reiterated by the OP, the proposal is just a proposal and was proposed with heaps of lead time probably because they expected it to be controversial.
As also mentioned, heaps of volunteer time is spent maintaining the packages where most are barely used (even for gaming).
However, it does not seem like there is a viable alternative. Many comments say the suggested alternative, WINE’s WoW64, does not work for all games.
I can see both sides here. Fedora maintainers says “this is so much work!” and (mostly) gamers saying “But older games will stop working!”.
The response from the Bazzite guy does seem overblown to me. I would think the first step is to work out the impact, as I haven’t seen anyone quantify what proportion of games are affected and if there are alternatives like emulation.
Older games? What are you talking about? They say in that thread that Valve doesn’t release 64bit versions of Steam. That means any games through Steam using the official client would be unplayable.
The two solutions I’ve seen presented in the thread for the Steam problem are to run Steam in a flatpak or a distrobox. I’m not sure if using distrobox has the same issues as flatpak.
It seems to me that 16-bit applications are already basically broken with 32-bit wine if you’re running a 64-bit kernel, by default it places extra restrictions over what the hardware already does to prevent apps from loading 16-bit code entirely.
AFAIK, you couldn’t run 16-bit software on native Windows x64, so Wine is exhibiting the same behavior.
Anyway, these 16-bit softwares are old enough that running them in DOSBox or something like that won’t show any significant performance penalty through emulation vs translation.
Yeah most 16 bit stuff is old enough that there’s already a mature reimplementation of the game engine or old enough that it’ll run nicely in a translation layer or VM
From what I’ve seen if an online store provides a 16 bit classic without a reimplementation, it’s bundled with dosbox.
Of course, I’m pretty much blanking on any classic Win16 titles of note. As far as I recall the significant games just kept being DOS games with at most launch from icon. I suppose original Myst because QuickTime, but they released a Win32 build. But this 16 bit stuff was a speculation, this is about the 32 bit stuff that isn’t reasonably accommodated without a 32 bit runtime and certain bits being at odds with Flatpak isolation architecture.
I’m wondering what the problem even is. I mean, can’t you just put all the stuff relevant to 32 bit gaming into a ‘retro-gaming’ package and be like “there, now if you want updates, better find maintainers”?
If you have an old game, chances are you won’t need many new features. Only problem could be other packages or the kernel becoming incompatible. I don’t know how relevant that is in this instance.
As reiterated by the OP, the proposal is just a proposal and was proposed with heaps of lead time probably because they expected it to be controversial.
As also mentioned, heaps of volunteer time is spent maintaining the packages where most are barely used (even for gaming).
However, it does not seem like there is a viable alternative. Many comments say the suggested alternative, WINE’s WoW64, does not work for all games.
I can see both sides here. Fedora maintainers says “this is so much work!” and (mostly) gamers saying “But older games will stop working!”.
The response from the Bazzite guy does seem overblown to me. I would think the first step is to work out the impact, as I haven’t seen anyone quantify what proportion of games are affected and if there are alternatives like emulation.
Older games? What are you talking about? They say in that thread that Valve doesn’t release 64bit versions of Steam. That means any games through Steam using the official client would be unplayable.
The flatpak should still work. Though I agree it’s a problem.
The flatpak has its own issues. Namely, that Steam was never meant to be run like that, so you run into bugs the native version doesn’t have.
The two solutions I’ve seen presented in the thread for the Steam problem are to run Steam in a flatpak or a distrobox. I’m not sure if using distrobox has the same issues as flatpak.
I want to say no, but I’m sure if I did somebody who has tried that would pipe up with a problem they found.
Ok but is that because of fundamental limitations, or just because of bugs?
One’s easier to fix than the other.
If it works like real WoW64, then 16 bit applications won’t work ever but 32 bit applications that don’t work will be because of fixable bugs.
It seems to me that 16-bit applications are already basically broken with 32-bit wine if you’re running a 64-bit kernel, by default it places extra restrictions over what the hardware already does to prevent apps from loading 16-bit code entirely.
https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#16-bit-applications-fail-to-start
Guessing that’s why they don’t feel it’s that important to continue supporting, seems a VM is the future for these apps.
AFAIK, you couldn’t run 16-bit software on native Windows x64, so Wine is exhibiting the same behavior.
Anyway, these 16-bit softwares are old enough that running them in DOSBox or something like that won’t show any significant performance penalty through emulation vs translation.
Yeah most 16 bit stuff is old enough that there’s already a mature reimplementation of the game engine or old enough that it’ll run nicely in a translation layer or VM
From what I’ve seen if an online store provides a 16 bit classic without a reimplementation, it’s bundled with dosbox.
Of course, I’m pretty much blanking on any classic Win16 titles of note. As far as I recall the significant games just kept being DOS games with at most launch from icon. I suppose original Myst because QuickTime, but they released a Win32 build. But this 16 bit stuff was a speculation, this is about the 32 bit stuff that isn’t reasonably accommodated without a 32 bit runtime and certain bits being at odds with Flatpak isolation architecture.
I’m wondering what the problem even is. I mean, can’t you just put all the stuff relevant to 32 bit gaming into a ‘retro-gaming’ package and be like “there, now if you want updates, better find maintainers”?
If you have an old game, chances are you won’t need many new features. Only problem could be other packages or the kernel becoming incompatible. I don’t know how relevant that is in this instance.
Yea dependency management without updates is like 80% of the work that goes into package maintenance