This time I’m really going to do it. I am going to put Linux on my gaming PC. Calling it now. 2026 is the year of Linux on the desktop. Or at least on mine.

It’s the year of Linux on my desktop.
This time I’m really going to do it. I am going to put Linux on my gaming PC. Calling it now. 2026 is the year of Linux on the desktop. Or at least on mine.
Linux has been a perfectly viable desktop OS for ages. But gaming on Linux is now viable, too. Valve’s hard work getting Windows games to run well on the Linux-based Steam Deck has lifted all boats. Gaming handhelds that ship with Windows run better and have higher frame rates on Bazzite, a Fedora-based distro, than they do with Windows. And after reading about the upcoming Steam Machine and Antonio’s experience running Bazzite on the Framework Desktop, I want to try it.
To be clear, my desktop works fine on Windows 11. But the general ratio of cool new features to egregious bullshit is low. I do not want to talk to my computer. I do not want to use OneDrive. I’m sure as hell not going to use Recall. I am tired of Windows trying to get me to use Edge, Edge trying to get me to use Bing, and everything trying to get me to use Copilot. I paid for an Office 365 subscription so I could edit Excel files. Then Office 365 turned into Copilot 365, and I tried to use it to open a Word document and it didn’t know how.
Meanwhile, Microsoft is ending support for Windows 10, including security updates, forcing people to buy new hardware or live with the risks. It’s disabling workarounds that let you set up Windows 11 with a local account or with older hardware. It’s turning Xboxes into PCs and PCs into upsells for its other businesses. Just this week, the company announced that it’s putting AI agents in the taskbar to turn Windows into a “canvas for AI.” I do not think Windows is going to be a better operating system in a year, so it feels like a good time to try Linux again.
I’m not normally one to change frogs midstream, but the water sure is getting hot.
That’s not to say I know what I’m doing. I’ve used Macs for a decade for work, and I dabbled in Ubuntu 20-something years ago, but otherwise I’ve been a Windows guy since 3.1. At first, that’s because it’s what we had at home, later because that’s where the games were, and finally out of force of habit (and because that’s where the games were). I brought a desktop to college instead of a laptop (so I could play games), and I’ve been building my own PCs for 18 years. I started my journalism career at Maximum PC magazine, testing gaming PC components.
I try to stay familiar with all the major operating systems because of my job, so in addition to my work MacBook I also have a Chromebook, a ThinkPad, and a collection of older hardware I refuse to get rid of. I can work pretty well in Windows, in macOS, or in ChromeOS.
My experiences with Linux over the past decade, on the other hand, have largely been as a series of extremely optional Tasks:
All of those projects, except the Chromebook one, took longer than expected, and cut into my vanishingly rare discretionary time. That’s also the time I use for gaming, reading, staring into the void, and half-starting organizational projects, so you can see how precious it is to me.
The prospect of instead using that time trying to get my computer back to a baseline level of functionality — that is, as useful as it was before I tried installing Linux — is tempting, but it’s also why I haven’t done it yet.
It’s a good time to try gaming on Linux. Antonio and Sean have been having fun with Bazzite, a Linux distro that mimics SteamOS; my friend and former colleague Will Smith is cohosting a PCWorld podcast called Dual Boot Diaries with this exact premise.
And what better device to try it on than my personal desktop with an AMD Ryzen 7 9800X3D processor and Nvidia GeForce RTX 4070 Super graphics card? I just rebuilt this thing. The Windows install is only like six months old. It’s working about as well as Windows does.
So really, why wouldn’t I blow that up and start over?
Based on listening to two and a half episodes of Dual Boot Diaries and a brief text conversation with Will, I’m going to install CachyOS, an Arch-based distro optimized for gaming on modern hardware, with support for cutting-edge CPUs and GPUs and an allegedly easy setup.
I don’t expect things to go smoothly. I don’t really know what I’m doing, and Linux is still a very small percentage of the PC gaming world. As of the most recent Steam Hardware & Software Survey — the best proxy we have for PC gaming hardware info as a whole — just over 3 percent of Steam users are running Linux. Of those, 27 percent are using SteamOS (and therefore a Steam Deck), 10 percent are using Arch, 6 percent are using CachyOS, 4 percent are using Bazzite, and the rest are split over a bunch of distros.
So if anything goes wrong in my install, it’ll be a lot of forum-hopping and Discord searching to figure it all out. But I’ve cleverly arranged it so the stakes are only medium: I have other machines to work on while my desktop is inevitably borked (and to run programs like Adobe Creative Suite), and if I end up spending hours of my discretionary time learning Linux instead of gaming, well, that’s not the worst outcome.
Maybe it’ll all go smoothly and I’ll report back in a few weeks, another prophet of the revolution. Maybe it’ll go terribly and I’ll come crawling back. Only one way to find out.
I recently had my Framework Desktop delivered. I didn't plan on using it for gaming, but I figured I should at least try. My experience thus far:
* I installed Fedora 43 and it (totally unsurprisingly) worked great.
* I installed Steam from Fedora's software app, and that worked great as well.
* I installed Cyberpunk 2077 from Steam, and it just... worked.
Big thanks to Valve for making this as smooth as it was. I was able to go from no operating system to Cyberpunk running with zero terminals open or configs tweaked.I later got a hankering to play Deus Ex: Mankind Divided. This time, the game would not work and Steam wasn't really forthcoming with showing logs. I figured out how to see the logs, and then did what you do these days - I showed the logs to an AI. The problem, slightly ironically, with MD is that it has a Linux build and Steam was trying to run that thing by default. The Linux build (totally unsurprisingly) had all kinds of version issues with libraries. The resolution there was just to tell Steam to run the Windows build instead and that worked great.
> I later got a hankering to play Deus Ex: Mankind Divided. This time, the game would not work and Steam wasn't really forthcoming with showing logs. I figured out how to see the logs, and then did what you do these days - I showed the logs to an AI. The problem, slightly ironically, with MD is that it has a Linux build and Steam was trying to run that thing by default. The Linux build (totally unsurprisingly) had all kinds of version issues with libraries. The resolution there was just to tell Steam to run the Windows build instead and that worked great.
I've heard it said in jest, but the most stable API in Linux is Win32. Running something via Wine means Wine is doing the plumbing to take a Windows app and pass it through to the right libraries.
I also wonder if it's long-term sustainable. Microsoft can do hostile things or develop their API in ways Valve/Proton neither need nor want, forcing them to spend dev time keeping up.
MS _can_ do that, but only with new APIs (or break backwards compatibility). Wine only needs to keep up once folks actually _use_ the new stuff… which generally requires that it be useful.
Or MS does deals with developers causing them to use the new APIs. I still haven't forgotten when they killed off the Linux version of Unreal Tournament 3. Don't for a second forget they are assholes.
Plus if it does happen, folks need to laern a bunch of new hostile stuff, given how linux is taking off, why not just move to treating linux as the first class platform.
> why not just move to treating linux as the first class platform
This is where the argument goes back to Win32 is the most stable API in Linux land. There isn't a thing such as the Linux API so that would have to be invented first. Try running an application that was built for Ubuntu 16.04 LTS on Ubuntu 24.04 LTS. Good luck with that. Don't get me wrong, I primarily use and love Linux, but reality is quite complicated.
stability has critical mass. When something is relied on by a small group of agile nerds, we tend not to worry about how fast we move or what is broken in the process. Once we have large organisations relying on a thing, we get LTS versions of OS's etc.
The exact same is true here. If large enough volumes of folks start using these projects and contribute to them in a meaningful way, then we end up with less noisy updates as things continue to receive input from a large portion of the population and updates begin more closely resembling some sort of moving average rather than a high variance process around that moving average. If not less noisy updates, then at least some fork that may be many commits behind but at least when it does update things in a breaking way, it comes with a version change and plenty of warning.
> Try running an application that was built for Ubuntu 16.04 LTS on Ubuntu 24.04 LTS. Good luck with that.
Yea, this is a really bad state of affairs for software distribution, and I feel like Linux has always been like this. The culture of always having source for everything perhaps contributes to the mess: "Oh the user can just recompile" attitude.
I'd love to see a world were game devs program to a subset of Win32 that's known to run great on Linux and Windows. Then MSFT can be as hostile as they like, but no one will use it if it means abandoning the (in my fantasy) 10% of Linux gamers.
That's basically already happening with Unity and Unreal's domination of the game engines. They seem dominate 80% of new titles and 60% of sales on Steam [1], so WINE/Valve can just focus on them. Most incompatible titles I come across are rolling their own engine.
[1] PDF: https://app.sensortower.com/vgi/assets/reports/The_Big_Game_...
Same with Godot. I'm writing a desktop app, and I get cross-platform support out-of-the-box. I don't even have to recompile or write platform-specific code, and doesn't even need Win32 APIs.
One aspect I wonder about is the move of graphics API from DX11 (or OpenGL) to DX12/Vulkan, while there have been benefits and it's where the majority of effort is from vendors they are (were?) notoriously harder to use. What strikes me about gaming is how broad it is, and how many could make a competent engine at a lower tech level, but fits their needs well because their requirements are more modest.
I also wonder about the developer availability. If you're capable of handling the more advanced APIs and probably modern hardware and their features, it seems likely you're going to aim at a big studio producing something that big experience, or even an engineer at the big engine makers themselves. If you're using the less demanding tech it will be more approachable for a wider range of developers and manageable in-house.
I believe it's already happening to a minor degree. There is value in getting that "steam deck certified" badge on your store, so devs will tweak their game to get it, if it isn't a big lift.
I am seeing that number increasing soon with The SteamDeck and SteamMachine (and clones/home builds). Even the VR headset although niche, is linux.
The support in this space from Valve has been amazing, I can almost forgive them for not releasing Half Life 3. Almost.
There are strong indications that Half Life 3 (or at least a Half Life game) is coming soon. Of course, Valve might decide to pan the project, but I wouldn't be surprised seeing an announcement for 2026.
> Microsoft can do hostile things or develop their API in ways Valve/Proton neither need nor want, forcing them to spend dev time keeping up.
If they decide to do this in the gaming market, they don't need to mess up their API. They can just release a Windows native anti-cheat-anti-piracy feature.
> They can just release a Windows native anti-cheat-anti-piracy feature.
Unless it's a competitive game and it's a significant improvement on current anticheat systems I don't see why game developers would implement it. It's only going to reduce access to an already increasing non-windows player base, only to appease Microsoft?
Also in order to circumvent a Windows native version wouldn't that be extremely excessive and a security risk? To be mostly effective they would need to be right down the 0 ring level.. just to spite people playing games outside of Windows?
Existing anticheat software on Windows already runs in ring 0, and one of the reasons that competitive games often won't work on Linux is precisely that Wine can't emulate that. Some anticheat softwares offer a Linux version, but those generally run in userspace and therefore are easier for cheaters to circumvent, which is why game developers will often choose to not allow players that run the Linux version to connect to official matchmaking. In other words, for the target market of developers of competitive games, nothing would really get any worse if there was an official Microsoft solution.
On the other hand, using an official Microsoft anticheat that's bundled in Windows might not be seen as "installing a rootkit" by more privacy-conscious gamers, therefore improving PR for companies who choose to do it.
In other words, Microsoft would steamroll this market if they chose to enter it.
Also Microsoft closing the kernel to non-MS/non-driver Ring 0 software is inevitable after Crowdstrike, but they can't do that until they have a solution for how anti-cheat (and other system integrity checkers) is going to work. So something like this is inevitable, and I'm very sure there is a team at Microsoft working on it right now.
> just to spite people playing games outside of Windows?
These things are always sold as general security improvements even when they have an intentional anti-competitive angle. I don't know if MS sees that much value in the PC gaming market these days but if they see value in locking it all down and think they have a shot to pull it off, they'll at least try it.
In theory a built in anti-cheat could framework have a chance at being more effective and less intrusive than the countless crap each individual game might shove down your throat. Who knows how it would look in practice.
>I've heard it said in jest, but the most stable API in Linux is Win32.
Sometimes the API stability front causes people to wonder if things would be better if FreeBSD had won the first free OS war in the 90s. But I think there's a compromise that is being overlooked: maybe Linux devs can implement a stable API layer as a compatibility layer for FreeBSD applications.
Steam has versioned Steam Linux Runtimes in an attenpt to address that. Curently it's only leveraged by proton but maybe it will help in the future.
It's like a flatpack, stabilized libraries based on Debian.
Hear me out:
Containers. Or even just go full VM.
AFAIK we have all the pieces to make those approaches work _just fine_ - GPU virtualization, ways to dynamically share memory etc.
It's a bit nuts, sure, and a bit wasteful - but it'd let you have a predictable binary environment for basically forever, as well as a fairly well defined "interface" layer between the actual hardware and the machine context. You could even accommodate shenanigans such as Aurora 4X's demand to have a specific decimal separator.
We could even achieve a degree of middle-ground with the kernel anti-cheat secure boot crowd - running a minimal (and thus easy to independently audit) VM host at boot. I'd still kinda hate it, but less than having actual rootkits in the "main" kernel. It would still need some sort of "confirmation of non-tampering" from the compositor, but it _should_ be possible, especially if the companies wanting that sort of stuff were willing to foot the bill (haha). And, on top of that, a VM would make it less likely for vulnerabilities of the anti-cheat to spread into the OS I care about (a'la the Dark Souls exploit).
So kinda like Flatpak, I guess, but more.
Check out the Steam Linux Runtime. You can develop games to run natively on Linux in a container already.
Running the anti-cheat in a VM completely defeats the point. That's actually what cheaters would prefer because they can manipulate the VM from the host without the anti-cheat detecting it.
There is no "real" GPU virtualization available for regular consumer, as both AMD and NVIDIA are gatekeeping it for their server oriented gpus. This is the same story with Intel gatekeeping ECC ram for decades.
Even if you run games in container you still need to expose the DRM char/block device if you want vulkan,opengl to actually work.
I try to get as many (mostly older, 2D) Windows games as possible to run in QEMU (VirtualBox in the past). Not many work, but those that do just keep working and I expect they will just always work ("always" relative to my lifetime).
WINE and Proton seems to always require hand holding and leaks dependencies on things installed on the host OS as well as dependencies on actual hardware. Used it for decades and it is great, but can never just relax and know that since a game runs now it will always run like is possible with a full VM (or with DOSBox, for older games).
GPU sharing for consumers is available only as full passtrough, no sharing. Have to detach from host.
MS has supported doing gpu virtualization for years in hyper-v with their gpu-pv implementation. Normally it gets used automatically by windows to do gpu acceleration in windows sandbox and WSL2, however it can be used with VMs via powershell.
12th gen and later intel iGPU can do sr-iov.
>I also wonder if it's long-term sustainable. Microsoft can do hostile things or develop their API in ways Valve/Proton neither need nor want, forcing them to spend dev time keeping up.
Not while they continue to have the Xbox division and aspire to be the world's biggest publisher.
[dead]
Yeah that's been my experience with native Linux builds too. Most of them were created before Proton etc got good, and haven't necessarily been maintained, whereas running the Windows version through Proton generally just works.
Unfortunately it seems supporting Linux natively is pretty quickly moving target, especially when GPUs etc are changing all the time. A lot of compatibility-munging work goes on behind the scenes on the Windows side from MS and driver developers (plus MS prioritizing backwards compat for software pretty heavily), and the same sort of thing now has a single target for peoples efforts in Proton.
It's less elegant perhaps than actual native Linux builds, but probably much more likely to work consistently.
Sometimes you see developers posting on /r/linux_gaming and generally the consensus from the community is mostly "just make sure proton works" which is pretty telling.
It's sort of a philosophical bummer as an old head to see that native compatibility, or maybe more accurately, native mindshare, being discarded even by a relatively evangelical crowd but,
- as a Linux Gamer, I totally get it - proton versions just work, linux versions probably did work at some point, on some machines.
- as a Developer, I totally get it - target windows cause that's 97% of your installs, target proton cause that's the rest of your market and you can probably target proton "for free". Focus on making a great game not glibc issues.
I mostly worry about what happens when Gabe retires and Valve pivots to the long squeeze. Don't think proton fits in that world view, but I also don't know how much work Proton needs in the future vs the initial hill climb and proof-of-success. I guess we'll get DX13 at some point, but maybe I'll just retire from new games and just keep playing Factorio until I die (which, incidentally does have a fantastic native version, but Wube is an extreme outlier.)
1. I think targeting compatibility is 99% as good as targeting native.
2. You’re discarding the shifting software landscape. Steam OS and Linux are trending towards higher PC gaming market share. macOS has proven you don’t need much market share to force widespread (but not universal) compatibility.
3. I don’t see the value in a purist attitude around Linux gaming. The whole point of video games is entertainment. I’m much less concerned with if my video game is directly calling open source libraries then if my {serious software} is directly calling open source libraries.
On point 3, I guess my views are different because my {serious software} is usually work, and if it stops working that's kind of a B2B problem and part of doing enterprise. It's just business as they say.
Gaming is much more meaningful to me as a form of story and experience, and it is important to me that games keep working and stay as open and fair as possible. In the same way it is important I can continue to read books, listen to music or watch movies I care about.
> Unfortunately it seems supporting Linux natively is pretty quickly moving target
With the container-based approach of the Steam Linux Runtime this should no longer be a problem. Games can just target a particular version and Steam will be able to run it forevermore.
I would hope Vulkan also does a lot of work here for linux native builds but I must admit I am only now starting my journey into that space.
A lot of those Linux native builds will have been using Vulkan.
Parity between DX12 and Vulkan is pretty high and all around I trust the vkd3d[0] layer to be more robust than almost anything else in this process since they're such similar APIs.
The truth is that it's just a whole lot harder to make a game for Linux APIs and (even) base libraries than it is to make it for Windows, because you can't count on anything being there, let alone being a stable version.
Personally I don't see a future where Linux continues being as it is (a culture of shared libraries even when it doesn't make sense, no standard way of doing the basics, etc.) and we don't use translation layers.
We'll either have to translate via abstraction layers (or still be allowed to translate Win32 calls) to all of the nasty combination of libraries that can exist or we'll have to fix Linux and its culture. The second version is the only one where we get new games for Linux that work as well as they should. The first one undeniably works and is sort of fine, but a bit sad.
0 - vkd3d is the layer that specifically translates D3D12 to Vulkan, as opposed to vkdx which is for lower D3D versions.
I have a slightly different view. The former scenario is essentially having our cake and eating it too. I'd rather not "fix" Linux culture.
Too late for an edit now, but `vkdx` in the note here is supposed to say `dxvk`.
A wise man once said "The most stable ABI on linux is win23". It sounds like a joke, but it is actually true.
In my experience, Steam client and most games work great on Debian and Ubuntu, but you should know for GNU/Linux systems, it's only officially supported on Ubuntu (maybe SteamOS is implicit), I can't find the information on Steam's website or support pages, but this is a response I got from Steam Support when reporting a Steam client UI bug on Debian with GNOME, a while ago.
Which is funny because Ubuntu is also the only distro that wants you to install the Steam snap instead, which is then again unsupported.
When I run into issues with running games on Linux (Steam or otherwise), I found it useful to consult protondb.com to see what others have gotten to work. You can filter by OS or keyword etc.
https://www.protondb.com/app/337000 for Deus Ex: Mankind Divided
I wiped windows 10 from desktop. Installed cachyos and steam Installed path of exile 2
and it worked surprisingly, also i see people joking about how win32 is the only stable api on linux xD. Also heard red dead redemption 2 also works well on linux that might be the next game i will check out.
I can confirm I finished RDR2 in story mode in Bazzite, zero issues. Never played the multiplayer part, though.
Story mode is good enough for me
It's the same with Dying Light. They have a neglected Linux version and I downloaded 16GiB before i realised to switch to the Windows version and start again.
I run Fedora 43 and all games (single tickbox in settings) are running through "compatibility mode" (wine/proton). Works great!
>So if anything goes wrong in my install, it’ll be a lot of forum-hopping and Discord searching to figure it all out
This is not inaccurate, however every time I've had to interface with either Microsoft or Adobe issues, both the professional and community support have been abysmal. Both community forums seem to incentivize engagement to the point where every response is 3+ hyperlinks deep to someone else's vaguely related post.
Maybe the linux forums self select for independent problem solvers..
Community forums/support from big companies like Microsoft and Adobe tend to be completely useless. In most cases, all threads follow the same flow:
* Question with reasonable amount of detail.
* A reply from some "Community Helper" (Rank: Gold): "did you try reading the help files?"
* Another person with a "Staff" badge: "this isn't our department"
[Thread closed.]
Or
* Helper: This is a great suggestion which I'll flag for the team to add support (5 years ago)
For what it’s worth the people who made that sort of post are probably vaguely annoyed at the lack of progress on this change, or on other ones on their own particular list of requests that have been moldering for half a decade while everyone spends three dev cycles adding half-assed AI bullshit features.
At least it's not Qualcomm support forums.
"Talk to the sales about this functionality. [Thread closed]"
I have some respect for the Oracle's honesty in putting stuff like "this bug can't be solved in the cheapest version of the software, buy the upgrade package X if you need it fixed" right on the forum.
There’s absolutely nothing wrong with this. Every enterprise OSS company operates like that. People paying for support and funding the project get to make requests. Anyone else can submit a PR or be happy with the free software. It’s a pretty good deal if you ask me.
Granted, Oracle charges a lot just to even use the software, but I still don’t think it’s unreasonable to limit certain types of requests for higher paying customers. Pay base price and you get to use the software, get updates and call tech support. Pay a premium and they prioritize bug fixes and features for you.
The "no guarantee of fitness for a purpose" people put on the terms of software they sell is bullshit. There is something wrong with selling software with some functionality and then requiring customers to buy other pieces of software to make that functionality work.
That said, yes, they still handle that bit better than most large companies.
Hah, this gave me a good laugh. There have been countless times where I have ran into this exact kind of situation, and it's not just limited to Microsoft and Adobe.
This is true, I chose to pick on MS and Adobe because the article closes with the admission that the author has backup Windows machines to run Adobe Creative Cloud in the 'inevitable' event that Linux has a problem.
For myself, those issues have been largely evitable; I think my longest current uptime on a running linux install is approaching 5 years..
Many OpenSource forums and software are like this. None of the help is there to help you use the system. It’s there for you to gain some deep knowledge that you don’t care about.
But I’ve said it before and I’ll say it again. some Linux distro needs to adopt some hardware line and partner with them to release a known good line of computers and polish the hell out of it. Like System 76 but nicer.
Almost all community help forums (for commercial and open source software) suffer from what I like to call "HaveYouTrieditis". You post a question, and without any root cause analysis or even a description of why it might work, people start posting "Have you tried X?" and "Have you tried Y?" and "You should try Z." These kinds of responses are almost always unhelpful.
I'm asking for help because I don't want to just try random things.
"Hello, thank you for posting. I understand you are having a problem with X. I assure you that you have my deepest sympathy in this time of trouble, and I will stop at nothing until this problem is fixed.
Have you tried running sfc /scannow?
...
Restart in Safe Mode?
...
Backup and Reinstall Windows. You can use OneDrive to backup if you have not already purchased a subscription."
The Microsoft Way (tm)
Nailed it.
Lmao true.
The worst online fora for support are for 'for profit' companies.
I had one where I was trying to get mongosh (or similar, I think they have had multiple shells) to change some print behavior I had multiple users coming in and giving me incorrect answers to a different question that was easily found in the docs and then begging me to mark the question as solved with them as the respondent and they were always written as though I was some sort of child-king that needed to be kow-towed to.
This kind of gamification of support fora incentivises responding rather than responding with correct answers.
Conversely Linux fora always have people who are at best polite and largely know their shit. They will help you hunt down the problem until the point where you hit that it's actually a firmware bug and you gain skills along the way.
The use of the Latin plural fora really resonates. It's like they are their own class of organism evolving in a digital terrarium.
> either Microsoft or Adobe issues
Please run sfc /scannow closes topic
Both MS and Adobe's forums are a complete joke, LLMs give better support than their respective "communities."
My biggest hope for LLM's was to finally be able to make sense of all the Microsoft documentation; the constant churn in product naming, different versions with varying levels of support and compatibility, the multitude of different API's to accomplish the same operation.. turns out the LLM's are just a confused as me :(
Every single auth related MS library/api I've tried to use has had three different doc pages saying a slightly different version of a slightly different part of what I actually need to know, and then the actual needed information being buried in a stack overflow post somewhere (and that information being slightly different again from the official MS docs).
Stack overflow was wrong then somehow ChatGPT knew what I was talking about when trying to set a dotnet environment variable in azure for an array in an app service. It has to be foo__0 not foo:0 so I broke production in a very nonobvious day for a day. At some point the foo__0 gets transliterated into foo:0 apparently?
The absolute worst location for this was, of course, the Azure or dotnet documentation sites. Cmon Microsoft you make both of these products surely this is a huge use case for your customers?
Asking Bing AI anything to do with MS Purview, (which is an M365 product for a range of data security applications), will result in several answers, all wrong and outdated, pointing to documentation that is also wrong and outdated, pointing to other documentation that doesn't exist.
To be fair, that's an improvement over the status quo. Generally they are far more confused than me.
... and reinstall Windows is offered as the next step after sfc /scannow.
This is grossly unfair.
You've entirely omitted the `dism /cleanup-image /(scan|check|restore)-health` rain dance
Blast. Soz.
I've been using Windows since v1 or perhaps 2 - we had a "CAD" workstation at school back in the day. It was a RM Nimbus with a 80186 (yes!) in it. I own a Commodore 64 from 1984ish (still have it - it now has USB).
I also recall using telnet to access the internet (gopher, WAIS etc) and being asked by my boss in 1994ish to investigate this www thing that was making waves.
I found it after a lot of navigation through menu systems. This is a discussion about the real differences by Sir TBL: https://www.w3.org/History/1992/WWW/FAQ/WAISandGopher.html
My report was: it looked pretty much the same as the rest, which shows exactly how prescient I was! To be honest, back then it was hard to tell what on earth was going on in a telnet session. At the time I could get at a sort of hyperlinked system on my telly (CEEFAX) and there were other similar systems around the world.
In hindsight, I think graphics cemented the www's dominance. I remember discovering the Mosaic browser and leaving telnet at around the time when a MS President (yes the speccied one) decided the web was not going anywhere), and thinking "fuck: that's the future".
For sure. Despite its reputation, troubleshooting is much easier on Linux than on commercial OSes. It's not even close.
Even just knowing that most of the time if I launch an application from the terminal it'll probably tell me what it's doing. For Windows, I'm looking for log files uhh... maybe %appdata% somewhere... maybe C:\Windows\Temp... maybe debugview... maybe a crash dump which is umm... somewhere...
Beyond the sensibility of Unix compared to Windows, it turns out having the source code for everything and a fleet of AI agents makes it really straightforward to diagnose problems.
I've set Kagi to blacklist sites like answers.microsoft.com for a reason.
> Both community forums seem to incentivize engagement to the point where every response is 3+ hyperlinks deep to someone else's vaguely related post.
As a total sidenote, I do wonder when exactly stack exchange/overflow saw the writing on the wall with AI coding?
I don’t need to look for Denver 069 2004 post about MQTT request response options where someone pointed him to a now 404 link, I just talked to Claude about it and we came up with a solution directly to my problem, using my code as an example.
> and Discord searching
Yikes. This is the main issue of Discord, it's not publicly searchable.
[dead]
This week we closed the doors on our Linux gaming podcast, which has run continuously for the past 13 years. No fuss, no drama. With the announcement of Steam Machine II (we also covered the original launch), it just seemed like the right time. Proton has evolved to the point where most things work out of the box. Few people are bothering with native support, and it’s become difficult to find new things to cover.
It really feels like everything is lined up for the year of Linux in the living room, and it’s great to see.
I never listened to the podcast, but I see where you're coming from and thanks for doing it anyway.
Twenty years ago I was in university and had a Debian install on a cheap-ass Acer laptop and I managed to get exactly two and a half games working under Wine: the first two Fallouts and about three hours of Civ IV before crash. Getting games to run at all was A THING so a podcast for that makes a lot of sense.
Today I have a full-time job and deleted the Windows partition from my expensive PC about three years ago... pretty much every game I've ever wanted to play since then has just WORKED. Better than on modern Windows, even. Not a lot to talk about there, I guess.
One thing I wish is that Valve could publish a 'Proton spec' that people could build against to ensure compatibility, but I imagine that that this would be an IP nightmare.
Anticheat is a big issue that nobody seems to mention. I had to go back to windows for online games and it’s my understanding that there are deep technical reasons why anticheat on linux can’t be done the same way as on windows.
Not sure what you mean, in every thread there's someone that mentions anticheat as if to stress why Proton is never gonna be good enough.
You can be a true gamer™ even if you don't play the latest $90 AAA multiplayer FPS. To me not having a proprietary rootkit is a feature, and Windows is always there for those that are OK with being spied upon.
Anti-cheat is the only reason why I had to build a Win11 machine for games, and only games, some months ago.
Hadn't touched Windows in more than 10 years, and it's as bad as I remember it, everything is clunky, badly designed, no polish whatsoever.
The moment developers find a way to get their anti-cheat working in Linux I have absolutely no reason to ever boot a Windows machine again...
> The moment developers find a way to get their anti-cheat working in Linux I have absolutely no reason to ever boot a Windows machine again...
The trouble is that kernel-level anti-cheat sounds like something useful but it doesn't actually get you anything because the cheat developers are going to analyze and modify the anti-cheat code the same as they do the game code. And then having it running in kernel mode on the non-cheater's PC doesn't buy you anything when the anti-cheat code you wrote isn't actually running unmodified on the cheater's PC.
The cheat developers do have to put in the effort to analyze what it's doing in order for that to work, but the same is true of user-mode anti-cheat. Being in kernel mode doesn't solve or improve anything, it just creates a hazard because then bugs or malware in the anti-cheat code can compromise the entire system and are effectively granting themselves access to things you didn't approve, e.g. a game running as the kid's user account can't normally access the parent's tax returns, but in kernel mode it can. So what you want is for them to stop doing that.
Meanwhile the Windows kernel and the Linux kernel are completely different, so you're not going to be able to take Windows kernel anti-cheat code and run it in the Linux kernel even if you're not attempting to cheat. You'd have to have them to make a Linux-specific one, but you don't want them to, because they shouldn't be doing it at all.
This is entirely possible using TDX/SEV-SNP, running in a vm alongside a host OS. It's just a big engineering lift. They're almost certainly already working on it.
Anticheat is a big non-issue that multiple people mention whenever Linux gaming is brought up. 5 popular anti-cheat games do not outweigh the whole ecosystem.
It is when those anticheats gatekeep the most popular PC games. For most gamers, they can't compromise on what they play and there is still a very large amount of potential games that would forbid a switch to another OS. See : https://areweanticheatyet.com/
Most of those are addiction machines and f2p shitholes, that they isolate themselves from the system is a win in my book.
sour grapes
> For most gamers, they can't compromise on what they play
I'm sorry, but 98% of video games are not competitive multiplayer IAP fests.
Because it's intractable on Linux and advocates don't want to admit that. The entire security model on Linux is resistant to deeper levels of access and control for applications, which is required for kernel level anti-cheat. While these forms of anti-cheats can't stop cheating, they are clearly more effective than user-space anti-cheats. For 99% of users, we gladly accept these more "invasive" anti-cheats because it means less cheating in the games we enjoy. Linux developers will never allow this kind of access because it is antithetical to their ideological beliefs around security. They gladly exclude any kernel level cheats to maintain the security model. It is a permanent impasse. One which I believe will never be solved with user-space or server-side detection. This is why the most common retort is: "just play different games."
To be frank, the argument that kernel level anti-cheats are invasive has never been all that accurate or compelling. Any user-space application already has numerous privileges which could ruin your day. You trust a developer and application every time you run it, irrespective of its access level. Valve has an opportunity now with SteamOS to impose technologies like SecureBoot and "safe" deeper layer anti-cheats which actually work. Yes, Linux enthusiasts would be up in arms, but it would mean that the most popular online FPS games would be supported on Linux, and I think that's far more important.
> For 99% of users, we gladly accept these more "invasive" anti-cheats because it means less cheating in the games we enjoy.
The modal user likely doesn’t even know anti-cheat exists, and if they did, wouldn’t care at all. They just want to play the game.
They want to play the game without cheaters. That's why studios use anti-cheats.
Well, it's not intractable if it's pushed to the underlying hardware and signed drivers.
Valve could build something into their chipset and start signing the Steam Deck drivers, create secure boot etc and essentially create an Apple SIP equivalent. Wouldn't work for the rest of the Linux ecosystem or other devices, and people would absolutely howl about it, but they could do it.
The other side is linux totally permits you to do whatever you like to your system, and then it's similar discussion to DRM (digital rights management, not direct rendering manager). When you're trying to the user from doing things they're not allowed to and the same user can fiddle with the system, there's no starting point for trust.
I run Steam in flatpak, so my games are sandboxed and do not have access to my home directory. I don’t have to trust anyone.
That's an added layer of protection but it's hardly foolproof. A malicious game/app can still:
* Exfiltrate personal data from allowed Flatpak directories
* Steal data you intentionally open via portals (e.g., documents, password files, wallet backups)
* Store malware or persistence files inside the Flatpak sandbox
* Use network access to phone home data or join botnets
* Abuse CPU/GPU for crypto mining
* Delete or modify files in your home directory if granted --filesystem=home
* Read browser cookies, auth tokens, SSH keys, cloud credentials if home is exposed
* Install persistence via ~/.config/systemd/user/ services
* Global keystroke logging on X11
* Screenshot entire desktop on X11
* Inject fake input events to the system (mouse/keyboard) on X11
* Record screen via portals if user once granted permission
* Gain full FS access if granted --filesystem=host
* Abuse DBus to change system settings or trigger polkit actions
* Install software outside the sandbox (e.g., ~/.local/bin or autostart scripts)
* Interact with hardware via /dev if granted --device=all
* Trigger kernel or driver privilege-escalation vulnerabilities
* Load or execute unsafe third-party mods, DLLs, or anti-cheat binaries
* Malicious patchers or mod loaders downloading external payloads
* Replace shell history or alter aliases to hide malicious activity
* Encrypt local or network-mounted files (ransomware)
* Spread laterally via stolen SSH keys to other machines
* Manipulate GPU/driver calls for rootkit-like persistence
* Abuse Wine/Proton compatibility layers to escape sandbox using native loaders
* Modify dotfiles (.bashrc, .profile) for stealth persistence
* Abuse LAN trust to attack other devices on the network
* Disrupt system performance via thermal abuse (extreme sustained loads)
* Exfiltrate browser sessions or wallet seeds stored in plaintext
* Execute background processes whenever game is launched without user awareness
Same.
This is The Way.
Bonus: No game files junking up my home directory.
Wait, what was the reason for winding down the podcast?
> Few people are bothering with native support
Was the podcast an attempt to increase porting efforts to Linux? But Proton (and now Steam Machine II) took the wind out of your sails?
I'm quite sure it's this one: https://linuxgamecast.com/podcasts/
Hmm, nothing about shutting down on that site?
> where most things work out of the box
i really doubt this very much. i hope i am wrong.