So is Hans Reiser back in business?

Back when the very first Linux port of Steam was released, there were a couple of Atom CPUs still 32 bit and Valve is relatively slow to change the fundamentals of the Steam client.

IMO one of be bigger mistakes Valve made and also the reason why I switched to the Steam Flatpak early.

Oh yeah. This actually seems to be a spam account,

Maybe it’s meant to show how bad it is outside of Linux gaming?

Direct link to announcement instead of low effort spam blog: https://www.ubisoft.com/en-gb/game/for-honor/news-updates/4WKJhG6v6C9sbCOZkFZ6wG/ranked-faq

Relevant part:

Competitive Update

Warriors, we are happy to announce that For Honor’s competitive experience is leveling up with the launch of Ranked Dominion and the rework of Ranked Duel.

The chance to prove yourself on a global level is here!

To reinforce a fair competitive environment, the team is introducing additional player safety measures. We are removing For Honor from the Linux platform to ensure a safer environment for our players as we cannot meaningfully deploy protection on this platform. This means that For Honor will no longer be playable on Steam Deck starting September 10th. We will continue to investigate different ways to improve our anti-cheat with the possibility of reopening the platform in the future.

I guess a GUI feature to actually enable this will be available through a dedicated Steam Client update.

Obligatory “wine is not an emulator”. So…

Obligatory *whoosh* because you missed the game developers referring to Proton as emulation.

I’ve had games with native Linux versions on Steam break more times than games I play through Proton

How many of these games target a proper Steam Linux Runtime? My guess is none and your experience is based on ancient Linux versions from a time SLR did not exist.

When native Linux games break it has been permanently, because the developers stop maintaining it.

Of course. “Valve refuses to promote it towards developers” I literally wrote that already.

Proton is a hacky workaround, targeting and properly maintaining Steam Linux Runtime is the proper solution but Valve does not promote this, so nearly nobody knows about it, and Lepton could be a properly promoted, directly based on AOSP instead of reverse engineering option, should Valve bring it to x86. That’s literally what I wrote already.

I’m up to date enough that I know that Nvidia drivers didn’t support a game mode feature until a few weeks ago. Also, those who don’t learn from history are bound to repeat past mistakes.

AMD GPUs have completely different drivers under Linux than Windows. What’s a card bug anyway?

There’s a reason you are talking in past tense.

Yes, the reason being that I no longer use Nvidia hardware under Linux myself, so I’m not actively looking for the very latest news. Nvidia and SteamOS game mode is a very recent development, literally within the last two weeks.

So? Valve didn’t remove Mesa drivers from SteamOS. Intel is supported by Mesa.

For a long time, easily a decade now, Radeon drivers work better under Linux than Windows: https://dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/

Nvidia fans kept insisting that “Nvidia works perfectly for me” even when Wayland was entirely unsupported and using highly insecure X11 was really not a bad thing at all.

More recently game mode didn’t work on Nvidia because their drivers again lacked features.

Just because you don’t use a feature not supported by your drivers, doesn’t mean that it’s not true. By the very nature how Nvidia develop their drivers, they will lag behind Mesa “standards”.

Nvidia GPUs will never fully catch up until Nvidia themselves switch their entire driver model to be open source and upstream developed within Mesa.

I curse Canonical whenever I have to use Ubuntu. #equality

In all fairness, not needing to install an OS is easier.

Man, if it was that simple, ALARM wouldn’t exist and arch would have (at least) allowed aarch64 packages in the AUR years ago.

Arch’s policy is to offer only x64 binaries. They don’t offer ARM packages because they don’t want to. ALARM exists because Arch does not want the contributions.

While it’s not zero work, your claim of reinventing the wheel overstates what compiling software that’s already compatible with ARM requires.

I’m reading what Collabora wrote and nowhere is that blog post did they state that compiling stuff for ARM and the packaging are the hard parts. They explicitly called out the reproducibility parts, not the rest.

If your small community project with dead forums and broken logs (see below) can do it, a team of full time Linux engineers can do it in a relatively small amount of time, probably with logs.

Package repositories, recipes, and support paths

The existing stuff needs to be adapted, not reinvented. In my time as packaging some software for my own use under openSUSE I barely seen software that needed adaptions in the package spec file for other CPU architectures. Emulators were the most common exceptions I encountered and even that changed a lot since then thanks to upstreams porting those to Android and Apple M processors. Collabora lists as main challenges the ability to access the upstream source codes for reproducibility, not “repositories, recipes, and support paths”.

What’s there to reinvent? Upstream Linux software already builds for ARM.