It makes perfect sense that CachyOS is dominating the ProtonDB charts right now. As the article points out, they are basically pre-packaging the tweaks, driver configurations, and heroic duct tape that the rest of us have spent years applying by hand. But while we're looking at these adoption numbers, we need to be honest about what we are actually cheering for.
The harder and more honest argument is that desktop Linux gaming is still, to a depressing extent, a compatibility story -- not a first-class commercial platform. Proton is not some triumphant proof that Linux gaming has arrived on its own terms. It is Valve's game-tuned Wine fork, wrapped in DXVK, vkd3d-proton, Steam runtime glue, and a thousand game-specific evasive maneuvers to keep Windows binaries from faceplanting on a non-Windows OS. That is technically impressive. It is also an admission that the center of gravity is still Microsoft, and their bloated OS.
Linux gaming advocates keep pointing at ProtonDB as if it settles the argument. It does not. It is a compatibility scaffold, not a native ecosystem. It exists because the commercial desktop gaming world still targets Windows first, last, and always, and gaming on Linux survives by translating, shimming, wrapping, and shaking a dead chicken in the general direction of Redmond. I am not speaking theoretically here. I built a high-end Ubuntu gaming rig around a 4090 a year ago, and spent weeks discovering that "runs on Linux" often means "runs after enough ritual incantation."
The worst bugs weren't even game-related. It was my audio stack. First, Linux did an embarrassingly bad job managing multiple audio streams at different bitrates, something native Windows apps have no issue with at all. Even with pipewire/pulseaudio, I had to do major surgery in both my audio stack and in my Steam launch strings to get clean audio when I had Spotify or Winamp running in the background instead of the game's native music. Second, my HDMI-connected soundbar vomited a bogus EDID payload into the DRM path advertising a phantom VGA display. Because EDID is an ancient compatibility sewer that still gets to vote, the kernel decided that the imaginary monitor hanging off the soundbar was the primary display, not my actual Samsung Odyssey G8 on DP-1. So on boot, the desktop went into the void until I physically disconnected HDMI. The fix was not a setting, not a package, not a friendly little checkbox. The fix was kernel surgery: patching drm_edid.c so the kernel would stop believing the lies my soundbar was telling it. That is not a consumer gaming experience. That is field-expedient systems archaeology.
And that is why I remain skeptical whenever people talk about Linux gaming winning the battle for gamers' hearts and minds on the general-purpose desktop. The article explicitly mentions Bazzite and Chris Titus. I saw both his review and JayzTwoCents' take on Bazzite on YouTube, and I honestly couldn't stop laughing. Their hearts are in the right place, but watching them attempt to frame Linux gaming as a seamless, drop-in replacement for Windows is both amusing and misguided. They are deliberately hiding the complexities of Linux-anything compared to the sheer ease of Microsoft Windows. They are promoting an illusion of parity, not championing parity itself.
Full disclosure: I got Doom running on a Slackware distro when I was an undergrad CS student way back in 1994, but it was an actual port. I got sucked into the compatibility world several years later, trying to get Diablo to run under wine on my Mandrake distro. I spent a lot of time surfing comp.os.linux and browsing tsx-11 and sunSITE for anything that would help. I gave up in frustration and I spent the next couple of decades contentedly gaming on Windows via steam. I switched away finally last year when Microsoft's aggressive telemetry became too much to tolerate, and I got hit by that borked windows 11 upgrade path last year that actually bricked my gaming box. It has become increasingly clear that the actual way forward for Linux is curated appliances and forks: Android phones, SteamOS-style consoles, handhelds like the ones Bazzite targets, locked-down vendor stacks, and other environments where somebody else absorbs the compatibility blast radius.
If you stay perfectly within those curated lines, it's fine. But the moment you step off that path to push high-end hardware, you are back in the trenches. On my rig, getting MechWarrior 5, Cyberpunk 2077, and Horizon: Zero Dawn to behave required a dissertation-length launch string on Steam. Here is what it takes running against Steam's GE-Proton9-20 compatibility layer:
PULSE_PROP="channel-map=front-left,front-right,rear-left,rear-right,front-center,lfe,side-left,side-right" NVPRESENT_ENABLE_SMOOTH_MOTION=1 VKD3D_DISABLE_EXTENSIONS=VK_KHR_present_wait PROTON_ENABLE_NVAPI=1 VKD3D_CONFIG=dxr11,dxr VKD3D_FEATURE_LEVEL=12_2 ~/.local/bin/run-with-vibrance.sh 256 gamescope -f -W 6144 -H 3456 -r 120 --force-grab-cursor -- %command% --launcher-skip
See what I mean? You are not just playing a game; you are performing postmodern systems integration on a consumer entertainment product. Proton is impressive engineering, but let us not pretend it is normal consumer software: any platform that asks me to hand-feed PULSE_PROP, VKD3D_CONFIG, PROTON_ENABLE_NVAPI, a custom vibrance wrapper, and a 6144x3456 Gamescope envelope before I can go shoot stuff in 6k at 100 FPS has not solved gaming on Linux. It just makes the ritual reproducible.