[trashface]

Feels like there is some real momentum on linux gaming now. I mostly play older games but I've gotten most of them working acceptably in proton on my old system 76 laptop (oryp5, with a nvidia 2060; ~7 years old). The laptop actually has plenty of power for the games I play, but I underclock to keep the heat/fan speeds down (been doing the same on the win10 install on the same system), still getting acceptable framerate in proton for most of the things I do in game, non intense stuff.

Decades ago I ported some games to linux but I do think proton is the correct approach now. One underappreciated advantage is you get most of the mod environment too. In ESO for instance, there is an addon (tamriel trade center) which lets you download item prices, but it requires a windows client exe to do that. That client works on proton.

I also do some modding myself and can cross compile my rust code to windows with cargo xwin, and run it right away in proton, which is fairly amusing to behold.

I actually don't mind windows generally (been a MS user since DOS 5), but Win11 is a game changer, pun intended, and not in a good way.

[Quekid5]

Yeah, I've been playing BG3 on Linux[0] for about 2 years at this point (using a Lutris "recipe" or whatever they call it). Ironically, the biggest issues have been with some of the modding tools needing specific versions of DotNet and whatnot. The game itself runs flawlessly.

[0] Arch Linux, btw, because that must be mentioned.

[Fnoord]

Actually, I have been having a specific issue with pickpocketing in BG3. On native Windows and native Linux, the client crashes if I pickpocket too quick. One time, on Linux, it even made my whole OS crash (and then some weird error BIOS error). But specifically with Wine on Linux, it does not occur. The only reason I even tried with Wine on Linux is because I wanted to try some mods unavailable otherwise. It does seem the native port has better latency, but latency in a game like this is pretty irrelevant.

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.

[brandnewideas]

Huh, I was unaware that BG3 had a native Linux release, as it's not listed on the Steam store page. Turns out that they released it only for the Steam Deck. Strange

[frameset]

Yeah there's some weirdness too, it's heavily optimised for the Deck, low rez textures, low shadow quality etc.

So if you force it to run on your Linux desktop you don't get an experience commensurate with your hardware.

[Quekid5]

It was released at "end of life" for Larian patches for BG3, so I can imagine they didn't want to support any old Linux distro. I believe it is technically possible to run it on distros that are "similar enough"[0], but it's pretty pointless if you want to use any PC-only mods, etc.

[0] I still use Arch, btw. :)

[KolibriFly]

This is exactly why Proton feels like the pragmatic path. Native ports are nice in theory, but PC games are rarely just one clean executable anymore

[sph]

I have stopped playing native ports and just prefer Proton when I have the choice. Many devs using Unity & co. just tick the "export to Linux" option and never try the build, which is often much slower or bug ridden.

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.

[eigenspace]

I'd argue that "native" is much more of a state of mind than a clear delineation anyways.

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.

[GlumWoodpecker]

Disagree. The word "native" in a software execution context has a very specific meaning—it means that the software is running on the target hardware with no emulation, translation layer or modification by any middleware. Games running through Proton/WINE will never be native, by definition.

[account42]

I'm not super sold on Wine/Proton being the solution to Linux gaming as it still leaves Microsoft in control of the future, but the distinction is quite murky. A lot of "native" ports also use translation layers internally to various degrees.

[naniwaduni]

x86 bytecode isn't the native instruction set on any real hardware you're running games on either, just one of the lowest-level publicly exposed interfaces.

[ms_menardi]

if it's the lowest level available, then it's as close to "native" as we can get, so therefore it has to qualify, if we want to consider anything at all to be running "natively"

[jurgenburgen]

Isn’t that moving the goalposts? If an API isn’t exposed for native code then maybe we should just accept that we can’t write native code anymore instead of stretching the definition.

[eigenspace]

From that point of view, native software effectively does not exist, and was long gone before the Linux project even started.

[needle0]

And exactly why Apple's push for Mac gaming (which still puts native ports as the ultimate goal and treats things like GPTK, despite having made it, only as "ways for developers to preview how the port would end up" and not intended for general consumer use) is never going to work, no matter how much cash they throw at it.

[rightbyte]

EA's horrible launcher comes to mind.

[imtringued]

Yeah, PC games are like console cartridges. You plug them into a compatible slot and they work.

[wing-_-nuts]

What? Look, things have gotten much better, but pc gaming, esp via proton is no where near as seamless as playing on console.

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)

[account42]

Not the ideal path though - that's still source ports.

[ToucanLoucan]

I'm looking to finally get off Windows for good. My experience with the SteamDeck started me, later I upgraded to a ROG Ally X for beefier performance but found Windows insufferable on a handheld, and installed SteamOS. I was blown away by the performance gains. A few months later I installed Kubuntu for the first time since 2013 or so, Steam shortly after, and while the desktop linux route is definitely more taxing (manually installing things like Mod Organizer 2 instead of Vortex, for instance, and all of that needing to run differently as opposed to Windows where it's all just .exe's) I've been absolutely blown away by the performance gains again. Mind you this machine is no slacker, it's a GE76 Raider from MSI, 3060 under the hood, but games just run smoother in Linux. And the alt-tab experience is untouchable, Fallout: New Vegas hates it and crashes, but everything more modern utterly doesn't care. I can alt-tab in and out, check messages, desktop composing works great no matter what game I'm playing, no more issues in modded games where the game completely locks the machine as Linux just doesn't seem to allow it, it's fantastic.

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.

[mfinelli]

Re: modding with MO2/vortex I had a similar problem in that installing them on linux isn't super straightforward, and then once I did get them installed when I launched the game through them like I used to do on windows the performance was abysmal. I decided to tackle the problem myself and so I wrote this: https://github.com/mfinelli/modctl. It's a mod manager that I wrote specifically for linux. It's not really ready for primetime yet, but if you're willing to experiment depending on your needs it might work for you. The repo might look like work has slowed down, which I guess is true but that's mostly because I implemented all of the main stuff that I wanted to and now I've just been using it instead of building it for the past few weeks though there are still a few rough edges and a couple of bugs that I need to sort out (but nothing game breaking that I've found yet).

[HiPhish]

Have you considered using OverlayFS[1] instead of installing all files into the game directory and tracking them with a database? Or maybe what GNU Stow is doing where it installs each package into its own directory and then uses symlinks which it tracks to "install" the files into the global file hierarchy?

[1] https://en.wikipedia.org/wiki/OverlayFS

[2] https://www.gnu.org/software/stow/

[mfinelli]

Ooh overlayfs is quite interesting. I'll have to take a closer look at that. I imagine it's similar to what MO2 was doing on windows with the virtual filesytem to keep the game directory clean.

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)

[karlding]

Keep in mind that overlay file systems are designed to treat the lower layer as read only. Changes made in the merged view are written to the upper layer while the original lower files are untouched.

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.

[mfinelli]

Ah that's good to know. That makes it more complicated than I was thinking because some mods obivously write data (other than cache etc which could be dropped between runs) that they expect to have persisted. Thanks for the heads up; I'll research this some more but I think it might stop there...

[ToucanLoucan]

Interesting! I was modding Fallout New Vegas and 4 if that adds context, what did you have issues with? All the same happy to bookmark it, might play with it at some point, thanks!

[mfinelli]

I've really only tested it with Cyberpunk 2077 (and a bit of WH40K rogue trader). The issues (so far) are with tangential features. For example it's possible to define rules when you extract files (eg the mod author sticks them in a subdirectory or something you can have the tool automatically strip that leading directory) the "preview" feature to see how to rules affect the files before extraction isn't working as expected. But the main loop of create a profile for the game, add/remove mods to it, and have it spit them out into your game directory works without issue.

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

[ToucanLoucan]

It's funny you say that, I've been considering another run through of 2077 and some mods would give it a fresh coat of paint... :think:

[imtringued]

I know that running Vortex is a pain but I never ran into any problems once it was installed. I did this back in 2022.

I don't want to discourage you, but what's wrong with helping MO2 and Vortex get ported to Linux?

[mfinelli]

That's a fair question! When I was on windows I never actually used Vortex, I only gave it a try on Linux when I had problems with MO2. But being an Electron app it's very unappealing to me. As for MO2, well, I don't really know C++ and wouldn't even know where to begin contributing even if I did... just for starters there's the whole question of how the virtual filesystem that MO2 does would work if it were native linux. In any case I know Go and wanted to implement some things that I didn't like how MO2 worked (eg tracking the version of additional mod files instead of just the main one). Plus new stuff like making a portable mod bundle that you can either backup or move to a new machine. Plus I generally like a CLI workflow :)

[MrDrMcCoy]

Vortex at one time did have a native Linux version. IIRC, it had very minimal game support, lagged behind the main branch, and was eventually canceled. I don't think they're interested in contributions for native Linux. A separate app seeking to implement Vortex API and package support would potentially be more free to improve the UX, do Flatpak/Appimage, or use more interesting Linux features like overlayfs and FUSE archive mounting. I have a mind to try my hand at it, would be a good starter project for a new language.

[ToucanLoucan]

MO2 works fine on Linux! It’s a bit slow to start but I found it very usable, a bit less polished than Vortex maybe but it absolutely gets the job done and I got my head around it inside of an hour.

[mfinelli]

I'm familiar with MO2 from when I used windows, but I had a hard time getting it working on Linux. First problem was getting it installed. I found https://github.com/sonic2kk/steamtinkerlaunch which is supposed to let you install it into each game's wine/proton prefix which worked, but when I then tried to launch the game it would run with absolute terribile performance (like even just the title screen would lag and stutter...)

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)

[ToucanLoucan]

I found this install script!

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.

[progforlyfe]

Modding will continue to be a challenge, but doable, thing, until more mod devs get onboarded to Linux themselves. If the mod devs enjoy using Linux, they'll probably start building mods with UIs native to Linux.

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.

[not_a9]

Does Wine have any debugging tools with equivalent developer experience to Visual Studio’s debugger?

[beart]

There were specific games keeping me on windows, mostly online PVP. At some point I switched anyway and I don't regret it at all. Now when my friends suggest a game and I'm not able to play it, I just do something else or we choose a different game. There are so many great games out there now, and more release every week. Plus, as I've gotten older, it has become more apparent the fun is in socializing, not the game itself.

My point is, you may find the one or two games holding you back won't be missed much.

[HiPhish]

Regarding mod managers, there is Limo[1] for Linux. I used it for Viva New Vegas[2], but some mods do not seem to work. I don't know if it's due to Limo or if I did something wrong though.

[1] https://github.com/limo-app/limo

[2] https://vivanewvegas.moddinglinked.com/

[Bombthecat]

Limo, last update a year ago :(

[cwel]

RE: Sea of Thieves on linux w/ xb/microsoft auth. I was able to work around it by just removing 2fa from my microsoft acc. Obviously not a great solution. but yeah. You may be able to reenable it afterwards, I never tried, its the only thing my microsoft account is useful for at this point anyways.

[ToucanLoucan]

Orly? I hadn't gotten that far yet but interesting data point. I'd only tried Infinite and the game just wouldn't even really launch, I didn't even get to the main menu, didn't open XBox authentication at all and I just assumed I had to have something installed. When I did some googling I'd heard of something called... my memory fails me, Heroic I think? I hadn't actually gotten around to trying yet though so I've no clue if that's any good.

[cwel]

I can't speak to Halo Infinite, but for SoT that's what worked for me. Another commenter is saying they were able to auth with a passkey (for infinite), which I never tried (for SoT), but id imagine it would work.

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.

[MayeulC]

I ended up being able to authenticate using a passkey, IIRC. Can't remember if that was my yubikey or bitwarden. I was surprised that it worked at all.

It didn't use to be complicated, but an update messed stuff up a few months ago (halo infinite).

[foo12bar]

What do you plan to do about firmware updates?

[cogman10]

Believe it or not, it's actually easier to handle on linux than it is on windows now [1]. Normal caveats apply, it depends on your HW manufacturer. However, a lot of them are participating which makes it pretty slick.

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.

https://wiki.archlinux.org/title/Fwupd

[hypercube33]

For a hot moment Windows would just update firmware for big vendors as an update. Worked slick. I think vendors are bailing out on this though.

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.

[isityettime]

All the distros that support it use the same system, fwupd: https://fwupd.org/

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.

[liamgm]

Yes , Win32 / DirectX in common HAL for games now , just compile your game for windows/steam , you can run everywhere , minimize the headache of doing native game development , like breaking with X11 / wayland kde / wayland gnome / wayland mutter .

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 .

[rkagerer]

Thank you for sharing that last paragraph. It's nice to know I'm not the only one out there who feels let down by the trajectory Microsoft has taken.

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.

[d3Xt3r]

How is ESO these days? Wondering if it's worth getting into from a solo (or finding some random party) gameplay/questing perspective.

[Gareth321]

I think Linux needs a few things before it will be ready for mass consumer adoption.

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.

[rowanG077]

> 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.

Steam has already solved that problem. You target steam (not steamOS) and all other distros will do the work for you.

[ChocolateGod]

SteamOS doesn't even ship with secure boot on, it has a long way to go before it's a platform game developers will consider tamper proof.

[bcjdjsndon]

Did you not read what you quoted?

[WD-42]

You didn’t. Steam already provides a runtime to target. SteamOS is largely independent from the actual game runtime. You already don’t need to target “12 versions” or whatever nonsense op posted.

[bcjdjsndon]

>> 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.

Your quoted quote.

[skydhash]

> 1. An equivalent of kernel level anti-cheats.

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.

[0x457]

> 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.

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.

[bcjdjsndon]

2. Does it really matter? You can always ship a statically compiled games. There’s only one kernel that is greatly back compatible.

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?

[kbolino]

I've been intrigued by the possibility of statically compiled games for Linux but I don't think they're the more compatible option. For typical games and players, the game needs to cooperate and interact with the window system. Even setting aside the X11 vs. Wayland issue, AFAIK neither have promised to maintain compatibility for static binaries.

[skydhash]

Aren’t both wayland and X11 protocols? Sure there are toolkits, but they’re not hard requirements (based on the little I know).

[kbolino]

I also don't know a whole lot, but yes, they both are ultimately implemented as families of client-server protocols over Unix domain sockets (X11 also supports TCP). Inasmuch as you are content with targeting a single version-set of those protocols, then that is sufficient to enable static compilation.

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.

Though this itself may be out of date by now (I can't find a date of authorship in that book).

[1]: https://wayland-book.com/protocol-design/design-patterns.htm...

[account42]

X11 and Wayland are not the problem as those do indeed have stable binary interfaces.

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.

[account42]

> 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.

Even that will not protect you from hardware cheats.

[ChocolateGod]

> I’m sure there are multiple ways to bypass anti-cheats on Windows.

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.

[not_a9]

Aren’t most DMA cards just PCI-E FPGA things? In any case, DMA doesn’t magically make your shit UD - you can look at Unknowncheats and see.

[LazyGooze]

the minute linux solves kernel level anti-cheat is the minute it wins the OS war, tons of friends have only windows on their PCs because of valorant or other multiplayer online game that uses anticheat.

[simonask]

"Linux" doesn't need to do anything here. What's missing is for anticheat vendors to develop kernel modules for Linux in addition to their Windows drivers.

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.

[ChocolateGod]

> "Linux" doesn't need to do anything here. What's missing is for anticheat vendors to develop kernel modules for Linux in addition to their Windows drivers.

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.

[account42]

> 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.

The notion that there is a meaningful difference between distros here only betrays your lack of knowledge.

[LanceH]

You let the people run their own servers and kick cheaters. That's one solution which has actively been taken away over the years.

[ThatPlayer]

If you look at modern games that still do this, plenty of them add additional anticheats, not less.

FiveM, modded servers for GTAV, had anticheats before Rockstar added any which already prevented Linux players. Face IT for CS2 does the same.

[account42]

Yes but then how do you get people to buy your microtransactions.

[ChocolateGod]

People just want to click Play and get dropped in a game, not have to mess with servers.

[wing-_-nuts]

Vehemently disagree with this. One of the reasons I loved BF4 so much were the community servers, with admins that could kick cheaters / griefers, and you enjoyed playing with the same group of folks. It was also one of the (many) reasons I was not remotely tempted to buy BF6. No servers? Not interested.

[RajT88]

Modern games should have:

- 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.

[notRobot]

You can just click play on a server without having to run one yourself, the enthusiasts do that. Eg: Halo CE, Armagetron, countless others.

[account42]

Is it really winning if you shoot your own foot to do it?

[gf000]

"Solving" is one thing, adaption is another.

[account42]

Well if you want an operating system you don't control and that actively works against you then you already have Windows...