Steam uses a number of commands from the running operating system to look at your hardware/software configuration (graphics card, window manager, IPC mechanism, etc.). All of these things are "obfuscated" when you run inside a container (snap, flatpak, etc.), which means that Steam is fed (somewhat) incorrect information about your system.

What exactly are you referring to? The Steam Flatpak has access to all these information because almost all of the device tree is shared, only a small part is filtered due to security. It knows exactly what hardware I'm using, which window manager, etc..

The host system is obfuscated somewhat because a different root system is used. But this doesn't matter because it doesn't use much from the host except the kernel (whose version Steam exactly knows).

View this comment - View article - View full comments

You'll get any updates quickest that way too, as you don't have to wait for Canonical to update the snap after a new Steam release.

You really don't know how Steam works, do you?

It makes absolutely no difference if you've installed it via the distributions package, Flatpak or snap because the package is irrelevant for Steam updates (in its core, it's still a bad Windows software).

View this comment - View article - View full comments

Games containing Nazi swastikas are region blocked or region adapted in Germany and Austria.

That's not necessary the case anymore. Nowadays, games can contain Nazi symbols. As far as I know Austria never had this limitation & were only affected because there was usually only one German version (the German version of the Wolfenstein games are still censored even though one can buy the international uncensored versions).

Steam basically blocks all 18+ games

That's not correct, there are plenty of 18+ games on Steam (with USK-18 & the new simplified rating system). The limitation you describe only affects games which are unrated / indexed / banned or "problematic" content (e.g. porn games). But I'd expect age verification to happen in the coming years (with all the porn hysteria that's currently happening).

View this comment - View article - View full comments

Omfg. This again. The problem with games and steam isn’t that the client it 32bit. (Actually is 64bit). But the games that are on steam are 32bit. Wine and proton are 64bit and 32bit. However a vast major of the games are not 64 bit only. A lot are 64/32 hybrids or just 32 bit because windows. Stop thinking of just 1 and 0. Didn’t we learn anything from the Ubuntu debacle? I moved to Manjaro after that.

You can't run Steam without the required 32-bit libraries - making it a 32-bit software. But Valve already has their own runtimes, they can provide whatever they want independent from the host system (it only requires kernel support). Steam games should already run containers (see pressure-vessel). So no, the games should not matter.

"Worst case scenario": They simply disable native 32-bit games on 64-bit system & just always run Proton instead.

View this comment - View article - View full comments

What about my 32 bit games? I care more about that than Steam

@poiuz the problem they'd run into would be two fold and you'd have to put 32 bit libraries in anyways to be able to install. If bazzite is its own fork they can add back in the 32 bit libraries unless they flat out remove and all ability to do that which is going to kill any game that isn't written for 64 bit which means older games that work now will be screwed

Run it in a container.

I also don't really know why software should be 64 bit if it doesn't need to be or why an OS would want to drop 32 bit support.

Because it costs resources (which are scarce) to maintain it (in terms of people who invest time & actual resources to build it on computers). For what benefit? It's enough that we have few projects who maintain compatibility, the rest can use that in one way or another (e.g. Debian or FreeDesktop runtime or even Valve's runtimes).

Just to answer it: "But then I can just go ahead & use Debian". Yes, you can. But there are good reasons why aren't simply using Debian today. These reasons are of less importance if you want to run legacy software.

Where did i say anything about steam?
Steam probably will get the 64bit treatment sooner or later, iIwas talking about all the legacy stuff like native games or applications that don't have active development

Steam should be of the few affected software. You should be able to run all other software in some form of containers, but you can't run Steam in a runtime if you want to use it as your shell (as pointed out by the Bazzite devs). But that's Valve's because they simply need to update Steam.

View this comment - View article - View full comments

Then expanded into 3 different OS& architectures, regularly updated, receiving new features quite often, got at least 3 UI overhaul switches, is the backbone of Windows and Linux gaming.

That's my point: Its actively maintained. You claim that removing 32bit software f**** with legacy software. It doesn't, there are enough solutions to solve this issue. The only issue is the actively maintained Steam because Valve is a crappy developer. What a great backbone that is… (but that's no wonder given Valve's Windows roots).

View this comment - View article - View full comments

But that being said, you just dont f**k with legacy stuff.

Because Steam is legacy software… (but this explains a lot).

View this comment - View article - View full comments

This is precisely why it is so important that the volunteers step up to maintain these old technologies. You know that -- with the possible exception of companies like GOG or Valve -- the for-profit sector is not going to do it.

We're only talking about this because Valve seems too incompetent to fix their crapware. Instead you're blaming all other to fix Valve's stupidity. They're not supporting the old technologies, Steam requires an x86_64 CPU. If they want to support x86 binaries (instead they could move all games to Proton, too), they can provide their x86 runtime. No need for all others to do their job.

It is too early. We need to fully develop and deploy the containers, runtimes and technologies like WOW64 that enable 32-bit apps to run in a 64-bit environment before we abandon the libraries needed to run them right now.

x86_64 is ancient. People are already striving to move to the next, more efficient architectures (aarch64 & Risc V). We already can run x86 software without any problems in containers but generally don't need to: "Our" software is build for x86_64 by the distributions. Again, it's only crapware from crap developers which blocks this.

For now, IMO, the solution is to continue supporting 32-bit libraries.

Nobody is stopping you, have fun: https://docs.fedoraproject.org/en-US/infra/sysadmin_guide/copr/ [External Link]

View this comment - View article - View full comments

As I pointed out earlier, Steam client is 64 bit on macOS for both x86-64 and ARM64, yet it is still not fast. The problem is CEF, as long as CEF remains as it is, changing and/or upgrading architecture won't change much.

x86_64 is not about performance, it's about compatibility. It shouldn't be slower than x86 (if it is then I again suggest Valve rewriting the whole client).

And aarch64 was only recently released as a beta. Currently it runs the x86 client via Rosetta2 which simply is slower. The aarch64 port is much faster (check the various user reports).

View this comment - View article - View full comments

The macOS client was recently ported to aarch64 (a completely different CPU architecture!). If an x86_64 build is harder than that then Valve should completely rewrite the Steam client.

View this comment - View article - View full comments