[0] Arch Linux, btw, because that must be mentioned.
I have been using Linux for nearly 30 years now, including running CS (HL1) via Wine with better performance and stability than Windows 9x on a LAN party. Good times.
Sometimes native ports don't get updates, while Windows port does. If you can then run it via Wine, you may have a more stable/less buggy experience.
Note I use both Wine and Proton. BG3 I run with Proton. But Proton is 'just' a fork with (neat) improvements which also partly got backported.
Oh, and I have to mention, I don't use Arch Linux.
So if you force it to run on your Linux desktop you don't get an experience commensurate with your hardware.
[0] I still use Arch, btw. :)
I was playing Project: Gorgon recently, I was about to refund because it ran terribly on my machine (despite the low end graphics), when I noticed it was using the native build, switched to Proton and got a 200% FPS boost.
As long as I can play on Linux, I don't care what translation layer it goes through.
Among many game developer studios, the Steamdeck is increasingly becoming the defacto low-spec hardware target. Running their game on a Steamdeck becomes a core part of the QA process, because there's a few million Steamdecks out there actively playing games, and if your game runs on a Steamdeck you basically know it'll also run on a very wide range of hardware configs.
So while the game might be targeting a different API than the standard ones exposed on Linux machines, a lot of games now are directly designing their software to make sure they run well on a Linux handheld. Meanwhile, Linux is adopting more and more features to better support this non-standard API set.
At a certain point I think we can just call Proton/WINE a 'native' API for gaming on Linux, and say that games developed with Proton/WINE in mind are native games.
Perhaps we're not at that point yet, but we might be there soon.
In fact, I went with console + linux laptop for ages simply because that combo excelled at their respective roles, were cheaper together than a gaming pc, and it 'just worked'.
I did eventually cave and build another gaming pc, but that was after I acknowledged that I could push out on the price / perf curve to something less 'optimal' (and it let me play with local LLMs)
I have a couple more things to figure, I need XBox authentication to work for Halo Infinite and Sea of Theives, among others, and I need to figure out some solutions for some ancient software I have to run, which will probably end up being a Windows 11 VM. But as for my daily driver OS, I am so excited to get off Windows once and for all.
The stow approach is something that I considered but ultimately rejected for a couple of reasons around handling conflicts of game-installed files as well as how to ultimately handle the symlink lifecycle (eg wrapper to make the "non-running" state always clean or to let it always persist and then need to run manual cleanup/update steps). But if you're interested in that approach when I was applying for Nexus Mods approval I discovered https://github.com/Marc1326/Anvil-Organizer in the overall list of mod tools which I believe uses that strategy (though I haven't really looked too closely)
But basically my original idea to just install the files directly into the game directory stems from the fact that when I switched to linux for gaming and not having success with MO2 that's literally what I was doing. I would download the mod from nexus and unzip/tar it into the game directory manually. When I wanted to uninstall or update I'd find the original archive list the files in it and then delete them from my game directory. After doing this too much I realized that I was basically missing the functionality of a standard linux package manager (eg apt, pacman, etc)
So if you need to persist changes into the lower layers, I think you may need to do tricks like taking snapshots and then swapping the bind mount (maybe with some diffing logic) or some other offline methods.
I should add that it's a CLI tool only (I may add a TUI later but it probably won't ever have a GUI if that matters). Anyway if you check it out and have any feedback whether positive or negative that would be cool
I don't want to discourage you, but what's wrong with helping MO2 and Vortex get ported to Linux?
How did you install it? Maybe with a different method it would work for me better (even though now I'll probably just stick with my own tool I'm still curious)
https://github.com/Furglitch/modorganizer2-linux-installer
Download, run install.sh, follow the instructions given. It replaces the game effectively in Steam, which does mean you have to launch MO2 anytime you want to play the game, but I found that at worst, slightly annoying.
I would say custom modding and online multiplayer anti-cheat systems are the last real hold outs, and even then it doesn't affect every game.
My point is, you may find the one or two games holding you back won't be missed much.
Heroic is a launcher aggregate/wrapper I think? for 'Epic, GOG and Amazon Prime Games' It's either Steam, native/standalone or arr for me. for non-steam stuff I use umu.
* I should add that I am launching a steam purchased copy of SoT, not the one from Xbox store/gamepass or what have you, so the process is likely different, but maybe not cus you are likely going to see the same auth popup served via wine/proton.
It didn't use to be complicated, but an update messed stuff up a few months ago (halo infinite).
And, assuming your are doing x86, you probably already have an EFI partition so even doing motherboard bios updates isn't much of a big deal. You just drop the update in the FAT32 EFI partition, reboot, and point the motherboard at that location. Some motherboards even support just doing that as part of an online update.
That said some Linux distros can do the same now though I've used so many the last few months I don't know which.
It's the same tool the person you were replying to was pointing at via the Arch wiki. It's pretty standard. I'd expect most distros to support it by now.
For the OSes runtime side you can depend on SteamOS / Apple's Game Porting Toolkit / Crossover / Proton / DWProton / Wine / and Android's Winlator/Gamehub/Gamenative .
For DirectX compatibility you can depends on Apple's D3DMetal , DXMT , VKD3D , DXVK and WineD3D .
I've likewise got a lifetime of experience on the Windows / MS stack, decades of custom tooling I've adapted or coded from scratch, etc. It's frustrating to see so many great advancements to core fundamentals like the kernel, tracing tools, I/O performance, etc. get completely overshadowed by such chronically user-hostile and frankly stupid business decisions.
I wish I could have the good bits without all the nasty cruft. I wish they stopped assigning junior devs who haven't even heard of Win32 to work on UI touched by millions of end users. I wish they hired back QA staff and rediscovered proper quality control methodologies like, say, regression testing. I remember a story from back in the day when they bought up one of every software title from the local tech store and had staff each pick one to dogfood on their prerelease OS. That passion to ensuring a good user experience.
I don't look forward to the time it will take to recreate all my infrastructure in Linux (including no doubt several detours tinkering into source codes to fix little issues and upstream little enhancements). But I fear Microsoft as a whole will never get their heads screwed on straight in time for me to avoid having to do so.
I would pay good money for something like ReactOS, Wine, or whatever, to offer the equivalent for business applications as Proton is for games. I applaud all the hard work done by people on those projects. I expect one day when kids have never heard of the word Microsoft, the code those heros wrote will still be in use by some grateful beneficiaries.
Anyway, that's the end of my rant. And in the meantime, just in case you haven't tried it yet... Windows 11 IoT Enterprise LTSC is the least offensive flavor I've found, and works as a daily driver.
1. An equivalent of kernel level anti-cheats. Cheating really sucks. It ruins online games. Kernel level anti-cheats aren't perfect, but they're much better than user-space or server-side anti-cheats. Maybe in the future AI solves this, but inherence-based anti-cheats are likely going to be a cat-and-mouse game. Valve have stated they are working on this problem and I think if anyone is going to solve it, it's them.
2. Immutability. Right now distributing games on Linux isn't distributing games "on Linux." It's distributing games to 12 different distros with a hundreds different configurations and a thousand customisations. This is impossible to support. When SteamOS gains traction, developers will be able to target exactly one distro with fixed configurations and limited customisations. Valve will set the standard for other distros.
3. An enforced equivalent of .exe. One of the most wonderful parts of Windows is the near universal acceptance and use of the executable installation method. You just double click the file and install it. Linux is an absolute clusterfuck of installation manuals and scripts and competing app stores with their own repos and permissions and packaging methods. If Valve were to mandate the use of, for example, flatpaks in SteamOS, that will become the universal standard. I think this is one of the most frustrating parts of using Linux for regular people.
4. Better hardware support. My Fanatec peripherals don't work well in Linux. Fanatec doesn't offer drivers and open source options are limited in functionality (and stability). There are many products for which drivers support sucks in Linux. I think AI will solve many of these issues over the next few years. Unless the manufacturer has gone out of their way to encrypt of obfuscate the communication layer with the product, you can basically point Codex at the peripheral and tell it to build an interface driver. Within a few years, I imagine operating systems will have this kind of functionality built in. If the OS encounters a peripheral it doesn't recognise, it will just build its own driver on the fly.
I am more optimistic about all of these than ever before. Linus Torvalds famously said it will take Valve to fix this fragmentation problem for us, and that looks like where we are heading. No doubt there will be Linux fans who lament the loss of diversity and competition, but I think we end up with a true competition to Windows for gaming. That's when I will make the jump.
Steam has already solved that problem. You target steam (not steamOS) and all other distros will do the work for you.
Your quoted quote.
Ultimately, you can’t trust the user computer unless you go for the secure boot things backed by a hardware key. I’m sure there are multiple ways to bypass anti-cheats on Windows.
> 2. Immutability[…] It's distributing games to 12 different distros with a hundreds different configurations and a thousand customisations
Does it really matter? You can always ship a statically compiled games. There’s only one kernel that is greatly back compatible.
> 3. An enforced equivalent of .exe.
I think ELF is the official standard for executable binary. The competition is illusory. There’s nothing preventing anyone from distributing a self extracting archive that installs on /opt. Packaging on Linux is about your system consistency, not software availability.
> 4. Better hardware support
That’s not a linux issue. If the manufacturer is not keen on getting it in the kernel or making it open source, they can always create a binary blob and distribute some shim that loads it.
Trials in Destiny 2 were a struggle before BattlEye, and the day BattlEye was enabled everyone suddenly forgot how to click heads. I put it "good enough" category.
There's more to it than dependencies. It's a valid point.
> I think ELF is the official standard for executable binary. The competition is illusory. There’s nothing preventing anyone from distributing a self extracting archive that installs on /opt. Packaging on Linux is about your system consistency, not software availability.
I think he meant .MSI and not .exe, but the point remains and is still valid. Why are there multiple ways to skin the same cat?
However, the real issue I'm getting at is the ability to run the same statically compiled binary many years later. That requires a dedication to compatibility (in this case, protocol compatibility). X11 was a bit all over the place on this, though it is probably stable enough now by dint of not getting much attention anymore. It seems like Wayland takes protocol compatibility pretty seriously [1] but there's an important caveat:
[W]hen a protocol transitions from unstable to stable, one last breaking change is permitted.
[ ... ]
Note that many useful protocols are still unstable at the time of writing.
[1]: https://wayland-book.com/protocol-design/design-patterns.htm...
Most games however need GPU access and that is only possible by either dynamically loading libraries or shipping the code for all the hardware you want to support with your binary (not an option).
That said, you don't really need a fully static binary but "just" target the oldest Glibc you want to support and minimize your imports as much as possible to avoid any unexpected compatibility problems. I put "just" in quotes because the toolchains on Linux don't make that easy if you also want modern programming language support, but it is viable.
Even that will not protect you from hardware cheats.
Of course, you can use DMA over Thunderbolt, but the bar is so high (cost, specialised hardware) that most people who cheat won't do it.
> Does it really matter? You can always ship a statically compiled games
This isn't completely viable, you can't statically link the graphics driver.
I personally hope they never do, because present day anticheat systems are literally closed-source rootkits. You should not let that software onto any computer you own.
But then I don't really have a horse in the race, because I don't find competitive gaming with strangers enjoyable at all.
With what stable module ABI like Windows has? There isn't one.
You can build a module that targets the current kernel Ubuntu 24.04 is using, but that module won't load on 26.04, let alone a completely different distro like Fedora.
eBPF /might/ help, but one could make a module that lies to eBPF.
The notion that there is a meaningful difference between distros here only betrays your lack of knowledge.
FiveM, modded servers for GTAV, had anticheats before Rockstar added any which already prevented Linux players. Face IT for CS2 does the same.
- Quickplay
- Server / Game / Match finder
- LFG - for a more detailed search
Each of these has a different use case, and a single user may make use of all of them (I include myself here). Not everyone wants to just click "play", it's very dependent on the type of game.
Helldivers 2, for example, implements the first two. Destiny/Destiny 2 has mostly the first one. Destiny on Xbox has a XBL-provided LFG functionality (but prior to that external sites were used). You really needed LFG for finding a raid group.