Thank you for helping to keep GamingOnLinux civil and safe!
Please tell us why you're reporting this content. Please note we store your IP address for all reports to help prevent spam and abuse. You can also email any complaints to: [email protected].
- Survive an elevator trying to eat you in co-op horror KLETKA when it releases February 19
- Draft code submitted to KDE Plasma turns it into a full VR desktop
- Proton Experimental brings updates for MonoGame, Rockstar Launcher and more
- Valve tweak Steam AI disclosure form for developers to clarify it's for content consumed by players
- No Rest for the Wicked co-op update lands on January 22 and it hit a big sales milestone
- > See more over 30 days here
- Casual/Social places for developer chatter
- simplyseven - Will you buy the new Steam Frame?
- eev - One-time logout
- Liam Dawe - Away later this week...
- Liam Dawe - Weekend Players' Club 2026-01-16
- grigi - See more posts
How to setup OpenMW for modern Morrowind on Linux / SteamOS and Steam Deck
How to install Hollow Knight: Silksong mods on Linux, SteamOS and Steam Deck
Hollow Knight's Linux version exhibits both controller and graphics issues. It worked well in the past, but not anymore. If Silksong is already running into Linux-only-problems, the outlook isn't promising. Team Cherry's patch doesn't address a single Linux issue. I've given up hope for the Linux version of Hollow Knight, and apparently Valve has too. They are now verifying the game on Steam Deck for Proton.
Some thoughts and a question:
A "native Linux" label doesn't automatically mean fewer layers or better longevity. Unity's Linux export targets Vulkan/OpenGL and uses SDL2, but the core engine is proprietary. Proton is open source end-to-end, fixes classes of issues for many games at once, and can also be used independently of Steam (e.g. via Lutris). In practice, Proton's centrally maintained stack often delivers faster, broader fixes than a one-off proprietary Linux port.
Many of us still equate "native Linux" with fewer dependencies and better long-term stability. In reality, both paths are layered. The difference is who maintains those layers and how quickly fixes propagate when things break.
A one-off proprietary Linux port needs continuous care as distros, drivers, Wayland/X11, and ABIs evolve. Most studios cannot budget that care indefinitely. Proton's model is centralized, ongoing maintenance by design, with broad QA across titles and hardware. That is why long-standing issues in a "native" build can persist, while Proton get fixed within weeks or even days.
We assume native equals independence. But a proprietary engine plus changing system layers is not independence; it is just a different dependency set, with fewer possibilities for the community.
Unity’s open-source dependencies are compiled and linked together with Unity’s proprietary engine code. Many issues can’t be fixed by the community. You'd need changes inside the closed Unity runtime or the game project itself. Proton, by contrast, is OSS across the compatibility stack (Wine, DXVK, vkd3d-proton, FAudio, SDL2, etc.) and doesn't require modifying the game's Windows binary. In practice, the developer provide a working Windows build - they do almost always for commercial reasons.
So here’s the question: For closed-source commercial titles (not community-maintained OSS like 0 A.D.), what concrete benefits does a (proprietary) "native Linux" build deliver that outweigh Proton's faster fixes, wider hardware coverage, and transparent maintenance? If there are strong cases where a native Unity Linux export proves more robust over the long term, I'd genuinely like to see them.