The more I read about this, the deeper the rabbit hole goes, and the messier it looks. And it gets worse every day.

Upstream 32bit versions of applications/libraries started to be unsupported, untested and/or unused by upstream since some time now. "Doing nothing" and maintaining the status quo is worse than difficult: it's dangerous.

Fedora volunteers cannot keep providing a better product downstream than they have access to upstream. As a side note: can we please stop blabbering about corporate greed and for-profit progressism? These are guys helping for free in their free time. It's not IBM, it's not RedHat, it's a different thing. The corporate world abandoned 32bit AGES ago (and support it only in front of quite substantial payments).

Resources are scarce. Whoever is on the roof shouting that we must keep things running like twenty years ago should come down and start helping contributors. Or become one.

Associated projects, like RPMFusion, have the same resource starvation (people/time/interest) as Fedora maintainers, and they wouldn't pick up the slack. After all, it's rather unrealistic to offload one volunteer to overburden another.

Fedora is too small for Valve to care? Maybe. Or maybe this could be the last straw to push Gaben (always be praised His Name) to make Steam 64bit only and including in itself some "soft virtualization" in the form of 32bit runtime environments for abandonware 32bit native games. This wouldn't help extra-Steam native games. But at some point, we should stop complaining we can't run Amiga games without an emulator.

Other important subsystems, like Gamescope and OBS, are equally critical for a modern, gaming-friendly environment. We cannot dictate what others do with their free time, but asking kindly is always an option. And the best option is start contributing actively to the projects to help them get out of 32bit technical debt. That's the beauty of Open Source, after all: not backward compatibility, but technical excellence.

This need to happen, sooner or later. It's a matter of when, not if. It's too early now? Most likely yes. So, when it's the right time? Ubuntu tried it in 2019-2020 and it backfired horribly. But even five years ago, the rationale about letting 32bit die was strong and pressing. We're half a decade later debating exactly the same stuff, with exactly the same problems. https://canonical.com/blog/statement-on-32-bit-i386-packages-for-ubuntu-19-10-and-20-04-lts [External Link]

Do I have a solution? Of course not. Will I miss some late 90's games unless there's an user-friendly way to run them? Probably. But in all honesty, I have no heart to ask Fedora maintainers (or any other distro maintaner, for that matter) to keep doing this maintenance work forever because Reeee mu games.

View this comment - View article - View full comments

Valve should go full 64bit, and drop/integrate the 32bit requirement/legacy.

And, tbh, so should WINE.

AMD64 is 22 years old, x86-64 is 21 years old.

After two decades, you can safely assume (the mother of fuckups be damned) that most of your userbase uses the "new" technology.

View this comment - View article - View full comments

For a short, exciting moment after reading the title, I thought that Valve was letting players use Proton outside of Steam.

That would be something I'd put next to the adverb finally.

View this comment - View article - View full comments

Old timer here, used to purchase Atari VCS cartridges at (the equivalent of) ~60 EUR in 1980. Considering inflation, that value would be ~350 EUR today.

But.

At the time, the size of the market and the physical item production were completely different from today's "download a file that can be replicated an infinite amount of times basically for free".

So, yes, he may have been right, but with huge caveats.

View this comment - View article - View full comments

How much useless stuff must run in background to cut battery life by a 2.5x factor? By any means, it's a colossal difference...

View this comment - View article - View full comments

This is a bad trend.

Especially because Valve may not be interested in reverting it, as long as games work on SteamOS/Deck.

View this comment - View article - View full comments

The consumer in me says "bummer" and pretends to ignore an issue that may become prevalent: the platform split Deck/Desktop that may hurt far more than we realize at first.

The hacker in me says "how hard is to fake a whitelisted device to the routine asking for it?".

View this comment - View article - View full comments

Discord is very popular indeed, and extremely hard to replace also for a specific reason:

API

It's amazing how easy and "deep" you can interact with your Discord server from outside. Having users already assigned roles, channels, permissions and the like based on external databases is a godsend for large gaming groups. Until FOSS replacements (or any replacement, for that matter) can't offer comparable customization, Discord is the way to go - unless all your gaming needs are filled up by something that can manually manage a few users.

The enshittification will be a serious blow for more advanced/larger/more complex gaming communities, or games heavily relying on Discord as an external service.

View this comment - View article - View full comments

we've seen a meaningful reduction in the amount of cheating recently.

Fair.

But until that phrase reads "we totally, positively eliminated all cheating in our game", then it's just smoke and mirrors.

It means that even with their best ring-0 kernel anticheat, cheaters are NOT completely eliminated. And if even a single system works to defeat deep anticheat techniques, it means the shallow anticheats are good enough.

80/20 and how to teach them to software developers.

View this comment - View article - View full comments

Support for elevating process privileges.

This could be very important considering the Squirrel installer *requires* non-elevated privileges to install its payload, and would stop if run as Administrator - like all software running under WINE is.

View this comment - View article - View full comments