There's plenty to disagree with RMS on, but he's absolutely right that Linux is not an OS; it's a kernel.
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
But I'm guessing the reason they don't is because there are some non-superficial differences.
I hear more often than not ubuntu users using the arch wiki for example because despite the package manager, lots of things are similar.
Your argument is like saying Lutherans and Episcopalians aren't both Protestants because they disagree on the meaning of the trinity, despite agreeing on 99% else.
Most Linux guides do work on all distros, as long as you're willing to adapt for package management solutions and Desktop Environments (when applicable).
Debian caring about reproducibility matters quite a lot to some people, but not most, etc
In a world that has almost completely standardized on grub, systemd, fhs, etc with major applications being shipped in container-like blobs (snap, flatpak, appimage) that mirror a Windows-style setup.exe workflow and then bypass the filesystem and package manager and talk right to the kernel anyway... yeah, if you're an end user, your distro choice doesn't much matter. Pick whatever has out of the box drivers for your laptop's trackpad.
And as a Debian user for many years, the differences are surface-level enough that the Arch Wiki is still one of the best resources with completely applicable answers.
Given the popularity of Steam, it's a high-visibility, high-priority application, which means your distro may be running it in one of three ways:
1) A snap
2) A flatpak
3) Your distro's native packaging format (deb/rpm, etc.)
So yeah, there might be a bit of variation there. I've already had a handful of problems on the Steam Flatpak on Fedora in which it's been suggested that I should switch to the RPMFusion Steam rpm instead, but so far I have resisted.
The fact that Steam is a program that installs other programs means that it will frequently test the boundaries of the OS and package format's security models.
Yes, Fedora defaults to and prefers Flatpak and Ubuntu defaults to and prefers Snap, but you can install either on either distro and it should Just Work. In which case, distro-specific differences are an even further moot point.
Proton has got so good that the best way of making games work on Linux is to target Proton and all your cross platform challenges are taken care of.
There was the famous "Win32 Is The Only Stable ABI on Linux" article last year which pretty much about this https://blog.hiler.eu/win32-the-only-stable-abi/ https://news.ycombinator.com/item?id=32471624
As you said, easier/better to target Win32 and just use Proton.
It's also funny because it kinda became true on another level as "Win32 Is Only Stable on Linux". It's easier to run old games and softwares (XP era and earlier) with Proton under Linux than on current Windows 10/11
Yeah, I'm gonna call that out as suspicious. Maybe on a few select titles, but the Wine database shows tons of titles that still won't run above "Silver"; all of which run just fine on newer versions of Windows. The older games that Windows can't run are usually due to some insanely intrusive DRM solution which also wouldn't run on Wine.
And this isn't me as some Windows fanboy, my comment history clearly shows I'm a Linux user; but that statement is just ridiculous on its face.
All gaming related checking is now on ProtonDB (pretty much everything that works on ProtonDB also works on Wine/Wine-staging with DXVK and VKD3D-Proton, this is how i play all of my GOG games - of which i have hundreds - for example).
In fact DXVK is so good that people use it to play Windows games... on Windows[0] and AFAIK it was how Intel Arc users played pretty much anything pre-DX12 for a while because Intel's own implementation was too slow/buggy.
[0] Actually this is how i decided it is time to ditch Windows a few years ago: i tried to play a D3D9 game on my Windows 10 PC and had various visual glitches - then threw the DXVK DLLs in the game's directory and everything worked fine. After a couple more occasions of this i decided that if i'm using DXVK for games on Windows might as well use it under the proper environment.
I found this usually to be true, but there are exception. For example I can't get Disco Elysium to work with Wine no matter what I try, but it's reported as working on ProtonDB. I've encountered some other exceptions too.
I can just about guarantee they will all run fine.
Also it'd be worthless to even try that, i made the switch almost three years ago and not only the software stack has changed a lot since then (IIRC Windows 11 didn't even exist), there is even a new discrete GPU vendor out. Today's comparison would not be representative at all.
And finally i never commented on how things performed[0] (i am assuming it is performance you have in mind with the "work better" as you mention that this "work" has to be "not equal but better" - anything else would be too vague to matter) - especially since the situation that made me decide DXVK was good was actually making the games i tried to play actually work regardless of performance (i happened to have some screenshots from a game i had issues with since i tried to report the bug in hopes the developer fixes it - they didn't - and this is the result i was getting [0][1][2]. Dropping DXVK in - under Windows - fixed all of those). FWIW in my experience performance was more or less the same (i did some testing with various games on Steam between Linux and Windows 10 after i installed Linux, some games performed better, others worse but the difference was miniscule that i only noticed with tools like mangohud on Linux and RTSS on Windows), which was great as i'd switch even if it was always slightly slower because i dislike Windows' UX, so that was a nice "bonus". But that isn't relevant to the experience i had anyway.
[0] Except that part about Intel Arc, but that was widespread knowledge when these GPUs came out, you can find several YouTube videos about the issues they had and some used DXVK to avoid them - BTW Intel kept improving their drivers, so even if you tried to replicate the results nowadays you wouldn't get the same results.
[1] https://i.imgur.com/b9apwRy.jpg
This has been a common saying for a long time. IIRC even before Valve made Steam available for Linux, the main Overgrowth developer who had Linux versions of some of their games break over time eventually mentioned (in a blog post) that you should just use Wine with their games as it is more likely to be stable.
(this may or may not have to do with the Linux version of their older game, Lugaru, using OSS - though at least the demo did run a few years ago when i tried it with a wrapper... and after removing/messing around with a bunch of .so files)
If you need Windows to play Call of Duty, you're probably going to stick with Windows for everything because of the hassle.
My understanding is there is no technical reason these anti-cheats cannot work via Proton, but the anti-cheat makers will ban if they figure out you're not on Windows out of some weird fear of people having root access to the system. I could be wrong, however.
So the big anti-cheat platforms VAC, EAC, BattleEye, etc. all support linux, however the developer has to enable it - last I checked Battlefield2042 could run on linux just fine (as BF1 and BF5 did) but they didn't enable the anticheat on linux.
I'm not sure how possible kernel level anti-cheat is via wine, the entire point of that is to be on the ring 0 layer where the best cheat software lives. Drivers generally get permissions to read/modify any memory anywhere using hooks that are difficult/impossible to detect from userland.
The reason you'll get banned on linux if they don't instantly nope-out on launch and don't want to support linux is because what anti-cheat software does is primarily two things: See what is hooked into the game, and see if all the memory is in an expected state. Obviously the compatibility tools don't match windows 1:1 and will look _bizzare_ to software comparing it to what you'd expect on windows. So the state doesn't match which it assumes means something is modifying it = cheat software.
tl;dr - idk if ring0 anticheat could ever work via wine, a lot of games use anti-cheat software compatible with linux but just don't enable it, if anti-cheat was somehow didn't instantly freak out on launch then it'll see a bizarre and heavily modified system compare to a real windows install, with unexpected behaviour.
EDIT: From my understanding DKVX for example presents as the direct3d/directx library which of course has very different behaviour and is very clearly modified/not actual direct3d/directx
To make this work, there has to be some compatibility layer good enough to fool kernel level anti-cheat into allowing the game to run.
I don't know how that would be possible... but that would be the silver bullet, so to speak.
That's the problem though - if the compatibility layer can fool the anti-cheat then so can actual cheats.
Both cheats and compatibility layers do the same thing - modify behaviour.
Generally anticheat will take a "blanket" approach and ban or crash by default and whitelist specific types of behaviour.
What we ultimately would need would be a kernel level interface/process that the game talks to if it identifies it's running under linux. Which is totally possible to do, linux users specifically would hate it, and it would be a lot of work. Without this you're stuck in userland.
Honestly the only realistic hope is the steamdeck becomes a lucrative enough platform for developers to target. Valve has already made sure the popular anti-cheat software supports linux. Valve's stance has been to provide cheat mitigation through other things such as overwatch/trust factor in CSGO (which works well from my experience). VAC itself is actually very primative.
For every other distro, someone in the community will take what you’ve done and patch together the pieces to make it work.
Say you’ve got SteamOS and Ubuntu support, let the user click an “OK I know what I’m doing” button, and they’ll figure it out.
* not so minimal but makes it highly compatible
Why bother posting who's opinion it is if you think it will cause disagreements? (curious)
I believe on Steam it's even better/easier, as it just ships with an Ubuntu base and uses that (but I don't really use Steam).
Point being: I think the differences between distros for this kind of stuff has been rather overstated. For most things, it doesn't actually matter all that much.
One minor correction, Modern Steam OS is Arch-based, not Ubuntu-based, but your point still stands.
As far as I understand correctly SteamOS might be based on Arch, but it uses Valve's kernel and mesa while running the games themselves in a container.
https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/b...
Basically everyone is using something Debian/Ubuntu-based or Arch-based. If you can install a flatpak or Debian package you’re pretty much golden (which includes Fedora users, who can install flatpaks).
Vulkan is pretty much the graphics API standard for the entire Linux ecosystem.