If the permission was necessary, the Flathub package would enable it by default. I can’t remember ever having a bad experience with the Flathub package.

When I first read that the ship a dedicated Distrobox container just for Steam, I was utterly confused as to what the benefit would be and I still cannot see it. Maybe the Bazzite developers dislike some of the restricted permissions of the Steam Flatpak or maybe they just want to package it on their own but the benefit for the user escapes me.

I’ve read another comment and then I realized it’s because of Bazzite’s Game Mode session. It’s a special login session and not just Steam in Big Picture Mode. Flatpaks cannot be used for this kind of specific use case.

I still had to go multi-arch on my x64 Debian system, leading to a lot of problems…

That’s what Flatpak is for. 32bit crap is moved into its own corner without interfering with any system level stuff.

How is that an SoC feature?

Back then Steam was a downgrade.

It’s not really enshittification when “Google reads your mail” has been the entire point since the launch of GMail. Relevant ads, grouping mails into topics, find spam, etc. has always been the selling point of GMail.

Sounds like they’re leaving the option open for Android developers to make their APK distributions compatible with Steam to play on Frame.

It was first reported months ago that Valve is involved with Waydroid (Android app compatibility for Linux with Wayland) and then at the Frame announcement confirmed to ship on Frame.

This could also potentially mean that Steam itself comes to Android (at least in the EU) to allow cross-buy and cross-progression.

Google is developing a Linux runtime for Android, Valve are making an ARM version of Steam, so it could be usable but I don’t think it’ll light the world on fire.

Sure, you get an A for answering the question, but my point was that the hate they get today on Linux is misguided because people only have vague or non-specific complaints.

Not learning from the past means repeating the same mistakes. I see little evidence that NVidia’s overall approach changed. It’s always that everyone has to adapt to their way of doing things and rarely that NVidia seek collaboration first. That’s why it has taken years and three entirely different memory management technologies.

With NVidia it’s always “This is the last piece of technology and then everything will be perfect.” ExplicitSync is only the latest episode. Now that ExplicitSync is there, compatibility on Linux is still a crapshoot with NVidia.

When Nvidia announced that they were going to move the proprietary parts of their driver into the GPU firmware, and open source the kernel module, there was a lot of hate about how they’re being assholes for not releasing the whole thing as open source, relying on proprietary blobs, etc. Yet that’s stupid, because it’s literally the exact same thing AMD and Intel do for their much beloved drivers.

Where is the closed source user space of Intel and AMD drivers? It doesn’t exist because they use Mesa for the best possible compatibility. NVidia don’t. I’ve read comments by people bashing the recent Baldur’s Gate 3 Linux release and being full of graphics glitches. Then they list their hardware as proof how great it is and they all have NVidia GPUs.

Afaik, their drivers support GBM today so it’s kind of outdated.

Well, of course. I literally said this was a fight over years, so of course in the past. You wanted to one example of why the hate and I gave you one example of why the hate.

Can you give an example?

Trying to push three different technologies years after AMD, Intel, Mesa, … agreed on GBM.

In case you aren’t aware, Nvidia was the main driving force behind getting explicit sync support into Wayland, which is a feature that greatly improves performance for modern graphics APIs.

In case you’re not aware but it took years of fighting NVidia for them to finally conform to standards and conventions agreed by everyone when NVidia didn’t care to participate.

The issues may be totally valid but yeah, Nvidia can be expected to have patches ready.

Looks similar to the Google ffmpeg situation where Google AI file bug reports, bury the developers, and don’t send any patches at all.

Patches welcome

In one of the interviews they said that Frame is only the first of several ARM devices in development. My guess is that some sort of Steam Deck Mini is likely to launch next but once the ARM Steam client is out, tinkerer at Valve also have more options.

So not “on purpose”

Inventing and implementing non-standard protocol messages to initiate the display is 100% on purpose. It would be easier to just source an off the shelf board and merely design casing around it.

Seems excessive when you can just as well use RustDesk.

That’s like saying that the year of Linux came when Android release.

It’s usually “Year of the Linux Desktop” and Android is a mobile platform, not a desktop OS.

it’s a bastardized monster clone of the original.

Android developments did benefit areas like power saving, so why the hate. Android is no GNU/Linux because of the lack of glibc.

MacOS is “Unix” in paid certification dollars only.

macOS, the Darwin layer specifically, is totally a BSD. Even with the Mach bits in the kernel because Mach itself is derived from BSD.

Early Valve was totally pro Windows tech. Back when HL1 launched, it was the first idTech-derived game with a Direct3D renderer out of the box (yes, Doom95 existed but that wasn’t the default, DOS was). OpenGL was still a massive force on Windows and yet Valve decided that what their fork of GLQuake needed was a Direct3D renderer.

Valve’s stance only changed after Microsoft’s attempt to force Windows Store on everyone and Valve’s subsequent “Faster zombies” experiment (because DirectX was stagnant as well).