I primarily use my pc for gaming, and want to avoid upgrading to Windows 11. Beginning the journey of looking into alternatives.
I am ignorant, trying to be less so. I have a hard time understanding what exactly makes a game not work just because of OS.
At this point, it’s almost entirely kernel-level anticheat
Interesting question which to be honest I can’t really answer myself… but I’d basically inquire by taking the flip-side of https://www.protondb.com/
Namely gamers like me usually check ProtonDB to see what they can play. Here it would be interesting, and I’m 99.99% sure Valve does that already, to check which games do not work and what’s the commonality behind them. It means one can then identify the gaps and try to address them.
Still, to venture an ELI5 answer : games are usually build for Windows. Games are using “bricks” like Lego to avoid re-inventing the wheel. Instead of having a health bar, a game developer might use a “health bar” brick. When you have a collection of such useful bricks, you typically call that a library. That library then makes the work of a game developer much easier but not all libraries are made equal. Some popular libraries target only Windows and thus the bricks make assumptions on how the software running the computer, the operating system, works. So… what Valve does is trying to make new bricks to stack on so that game developers don’t even have to use libraries they are not familiar with. They “just” use their typical bricks, Valve “injects” in between their new compatibility bricks and voila, unbeknown to the game developer, their Windows game works on Linux!
Put simply, it’s like a translator that knows many of the languages Windows will speak. However, it’s not always fluent in every language it might speak. This is what proton does, it translates system calls into Linux, essentially. It almost always will work, specially with Steam games.
In other cases, it’s game devs making desicisons to disallow use of Linux. Specifically anti cheat. Not all anticheat is disallowed, but game devs could allow it. They just choose not too.
Most games will run just fine on Linux. I’ve switched entirely to Linux and said goodbye to those few online anitcheat games that disallow. Most everything works.
Also to add to this is if windows users understood what kernel level anti-cheat does most people wouldn’t want it on windows ether.
What does it do? Could you explain?
It runs in the kernel of the OS as a driver, which means that it’s basically a trusted malware that has even higher permission than the admin of the computer, and have access to more things than yourself, to closely monitor the whole system in order to find signs of cheating.
And for context, it does this because cheaters are willing to run cheats that run at that kernel level, and the only way to detect and prevent them is if the anticheat is in your kernel first.
Very accurate comment, and to expand on this, things like media codecs, windows dependencies, etc also cause problems. Luckily Proton can play just about any game on Steam.
For example, Marvel Rivals is a new game that just came out and its anti-cheat works with Linux. I play it with ProtonGE, which installs extra codecs that regular proton versions don’t include and it works awesome.
Check out protondb.com to search what specific games work for others on linux.
Does Steam ever deliver Linux-native builds instead of running games through Proton?
Yes. There are some games where the Linux-specific bugs don’t get fixed and it’s better to just run the Windows version thru Proton and take like a 10-20% performance hit so it runs with more stability.
Sometimes the Windows versions just run better than the Linux build because of bad optimization on the Linux build of a given game, as well (OpenGL vs Vulkan drivers, etc etc)
there’s no way it’s a 10-20% performance hit
Is it usually more or less than this?
Way less, even better performance than native windows in some cases
Linux Native builds generally have better performance than Windows builds running on Windows. That’s what I was comparing between
Flightless Mango used to have some good comparisons, but they’re about four years out-of-date, now. Even then, you’d expect between 10% worse and 5% better on Linux. https://flightlessmango.com/benchmarks/
Forbes article here is from this year; expect between 5% worse and 25% better when running on Linux. https://www.forbes.com/sites/jasonevangelho/2024/08/21/linux-scores-a-surprising-gaming-victory-against-windows-11/
General experience is that generally there’s no noticeable difference at all; some games that use new features might have bad performance until the new features are implemented. Last game I really had a problem with was Horizon Zero Dawn. Elden Ring had bad performance on launch day, but was fixed the next day I think.
Yes, I’ve run several games native. ProtonDB will indicate if it runs natively (though some people will report using proton on natively supported games out of habit)
EDIT: some games are supported natively, but should use proton for mods. For example, Mount and Blade Warband runs just fine without proton, but if using mods it should be run with proton. This will also be indicated on ProtonDB in my experience
When you see the Windows and Apple icons on a game, that indicates native Windows and MacOS support. The Steam logo is native SteamOS/Linux. You’ll also see a “SteamOS/Linux” section on the system requirements.
To expand on the translation metaphor:
Trying to run a window program on Linux (without proton) is like trying to read a completely alien text. Your have basically 0 in common and no way to understand it
Proton is doing the translator job of helping. And it’s doing a great job for a lot of the alien language. Which is why so many programs and games work on Linux with proton
But even it can’t always be perfect, and if the language is using some weird dialect, it might not understand or misinterpret things, which causes games to be buggy or unplayable on Linux
A Windows binary is just plain not compatible with Linux. Everything in the operating system is different.
Compatibility layers like Wine are pretty good, but not perfect.
Ususally, like 99% of the time, it’s absolutely the fault of the game developers and by choice.
Pretty much any game can run on Linux nowadays. Some do even run better than on Windows, but most equally good or a tiny bit worse.
The main problem is (very invasive kernel level) anti cheat.
And sometimes, games work fine on Linux, and then the devs actively lock out Linux users for some ludicrous reasons.
You can visit protondb.com for a very nice overview of which games work and how well they do.
That’s putting a lot of blame on devopers.
Not all games have a ton of contributors on ProtonDB and that’s not the developers fault.
But it actually is mostly the developers fault. There are weird corner cases, yes. But all game engines natively support Linux and even games that are not made for Linux will run there via Proton nearly always.
Exceptions are 95+% of the time due to anti cheat and like 2% due to a self written engine, that does exceptionally cursed stuff even for windows.
I play lots of games regularly that were never meant to be played on Linux but work flawlessly without the developer or “contributors on ProtonDB” (whatever they have to do with that) doing anything.
that’s not the developers fault.
Forcing Ring0 spyware on the users IS the developers fault by 100%.
FWIW, it’s actually more the publishers’ fault. Typically as a developer you get told what environment you’re targeting and how the publisher wishes to publish you.
Yeah, don’t let us be too nitpicky here. They intentionally make it not run on Linux because of their spyware. So it’s entirely their fault.
Since it’s ELI5, I’ll try to be as clear as possible. Windows and Linux distros are different operating systems, so their programs are their own. If there isn’t a compatibility layer present (or an emulator) you won’t be able run a program written for the other system. What Steam does on Linux is, it uses a compatibility layer (Proton) to run Windows games. Proton is Valve’s version of WINE with some specific improvements, mostly targeting Steam games. That’s how Steam Deck works. You can think the other way around of this is Microsoft’s WSL (not exactly).
So, because of there needs to be a compatibility layer, it might not always work as intended for some games (though numbers are decreasing with every update). Most of these games are games that use an anti-cheat, though Valve included Linux versions of BattlEye and EasyAntiCheat in Proton, and if a developer uses it, there is no problem for that game. For example, Hell Let Loose works fine because of this. Note that, some games will use kernel level anti-cheat (or currently using), those games won’t run at all.
From what I found, there is also a possibility that you might have a hard time with some older games that use a custom-built engine. I mostly encountered this with some Japanese games. Though, those games usually don’t work on something over Windows 7 too.
An analogy is that operating languages speak different languages. And an app built for one operating system doesn’t speak the language of others.
But in the case of Linux, there are lots of really good tools that let Linux understand Windows apps. Steam has those tools built right in.
Where it falls down is that the tools that let Linux understand and run Windows apps aren’t perfect. So things like DRM, anti cheat, propriety drivers etc, can be a challenge.
But currently, if you’re not running games that use kernel level anti cheat, the vast majority of games will work on Linux. The steamdeck uses Linux itself, so it’s a high priority for valve to get as much working as possible.
Most “normal” programs use some “abstraction” libraries, so the programmer doesn’t need to know which platform it is running on. This “platform” is important because it is the layer that actually talks to things like your SSD, RAM, GPU, etc.
Videogames, tho, are very very specific programs that really benefit from very optimized code, so some of these “abstraction” libraries simply will be worked on for a specific operative system.
Thankfully, the people from the WINE project and lots of work from Valve themselves have made it possible to “trick” these libraries into thinking they are talking to Windows. It’s not perfect, tho, so some stuff is still not working, but you’d be surprised how much we’ve got already. Check out the ProtonDB project.
It all boils down to how such games (and softwares, in general) depend on dependencies. Imagine two teachers, both of which lectures to several students. One of these teachers are a mathematician, and the other teacher is an engineer. The first depends on math books, the latter depends on engineering books. Sure, there are mathematical aspects to engineering, as there are engineering aspects to math sometimes, but a math teacher can’t use engineering books to lecture, while the engineering teacher can’t use math books to lecture. They need their own set of books, even though these sets can overlap sometimes.
That’s a similar situation to Windows and Linux softwares: one depends on Windows set of books, while the other depends on the Linux set of books. You can’t just “import” the Windows books into the Linux classroom, because the classroom will also change: back to the analogy, the engineering classroom has engineering instruments and equipment, while the math classroom has scientific calculators and computers running R and Wolfram Mathematica.
Operating systems can function very different. When creating software (like video games) the developer has to understand or use software dependencies which interact with the OS in a number of specific (OS dependent) ways. Stuff like where is app/user data stored, how to connect to the internet, how to display stuff on the screen (2D), how to display complex 3D geometry on the screen fast (3D graphics acceleration), where the host OS stores shared libraries (and what kind of libraries can the software expect to always be available), what security restrictions the host OS has, what filesystem the host OS uses, how to access the keyboard and mouse, how to interact with the kernel (very important).
Since Windows and Linux are so very different, built for different purposes by different developers, it is impossible to take a Windows exe and run it on Linux.
These days, the WINE project, with help from Valve’s fork Proton, is able to run basically any Windows game on Linux with similar performance (if not better because Linux is lighter to run than Windows). It does this by creating a environment for the software/game that provides all of the OS stuff Windows software expects and translating it to Linux specific things.
TLDR: Linux is very different from Windows. Software meant for Windows won’t work natively on Linux (since everything is different). For Windows software to work on Linux, the WINE translates all the Linux specific OS stuff and creates an environment for the Windows software that feels like Windows. Most things work with WINE except exceedingly complex stuff, like browsers which have native Linux versions anyways.
The ELI5 version is that developers can make a lot of assumptions about what a Windows pc means and what features are available. A while ago if you had videos as part of a game (for example a cutscene) it was actually played through Windows Media Player, which was virtually guaranteed to be present on the user’s computer. Sure you can play that video with other tools like VLC or Quicktime, but you couldn’t guarantee they were installed, so Windows Media Player was a safe bet. Nowadays that’s not how video is handled but the point remains for a few other things. For example if I need to load an image, maybe a background, I would look it up using the windows filesystem, so probably something like C:\Program Files\Steam\common\mygame\images\background.png. That’s not the same in the Linux or another os. Also the piece of software that handles loading images might be different, which means how we execute that load operation is probably different, and so our Windows-focused version of our game just doesn’t work.
Fortunately nowadays that’s a mostly solved problem with Steam investing a lot of time into Proton, what they call a “compatibility layer” that basically translates all of the windows-specific stuff to work in Linux. That’s a very simplified explanation but you get the idea. The games that still won’t run have kernel-level anticheat (Valorant, Helldivers 2) or are so dependent on things only available on Windows that even Proton can’t fix it. Some anti-cheat software doesn’t run properly so then you can’t go online, like Warhammer: Vermintide 2. That’s mostly a commercial decision rather than technical, they could make it work they just choose not to.
So far the only thing that has been an issue has been anticheat
I’d say the anti-cheat has only recently become the “only issue”. It’s not like wine and proton could run everything flawlessly before kernel level stuff came along. The translation was imperfect and incomplete, so shit simply did not work. Lots of hard work on those projects slowly but surely filled in the gaps, and now we are finally at a stage where we can say that if a game doesn’t work it’s by design.
Same here. Newer versions of Easy Anti-Cheat work fine, but pretty much anything else breaks. Rising Storm 2: Vietnam is an example of a game that uses EAC, but with a version too old to work with Linux
Different operating systems have their own interfaces to allow user level programs (like games) to communicate with hardware. This is a great-over-simplification, but one OS may understand something like “drawTriangle(x, y, z)” while another may expect “drawPolygon([x, y, z])”.
There are software projects to attempt to translate commands meant for one OS for a different OS (such as “Wine” or Valve’s “Proton”) and those work fairly well in cases that: 1) there’s an analogous command, 2) the analogous commands have been accurately mapped, and 3) the analogous commands operate in user space.
That last point is the primary reason why, despite the best efforts of developers, some games still cannot work across OSs. Operating systems are built on top of different levels with the lowest being the “kernel” (of “kernel level anti-cheat” notoriety) and the highest being the user space (where you interact). Both Windows and Linux have these, but the boundaries around them, what they can and cannot do, and how to interact across those boundaries differs between each system.
So when a Windows game installs a driver to monitor everything that your computer does that driver (kernel level anti-cheat) is tailored very specifically to the extremely powerful, low level, and unique Windows kernel. Linux cannot run that natively. If the game pretends that spying on you is an essential component to launch then the game will not launch. If, however, a game is perfectly happy to just stay in user space where it belongs then it will probably work fine with the available translation layers.
That makes sense, thanks!
there’s nothing about Linux itself that makes the steam game not work. it’s up to he developer to release a binary that supports Linux, most devs who are using tools like unity or unreal probably have the highest realistic chance of making a clean Linux executable
but the way proton works is to use the compiled binary for windows in a way to make it compatible for Linux
Steam pretty much has a translation layer that turns Windows programs run on Linux. Both operating systems execute code in a different manner, so it’s up to the translation layer to turn one into another. Sometimes, a game can call code that the translation layer cannot translate. A well known one of those is kernel-level calls made by some anticheat software.
