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

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?

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.

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

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

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.

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

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

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.