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