Easy Anti-Cheat not working on Linux? Seems a glibc update broke it

Quoting: setzer22I'm an Arch user, and have been for quite a long time. But I'm starting to grow increasingly worried about the sustainability of their distro model. Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.

Why are we okay with the basic model for Linux dependencies being to have *all* the system's dependencies share the same global namespace, while a bunch of overworked (and often underpaid!) enthusiasts make sure that updates happen in lockstep and nothing breaks. Of course things are going to break randomly during updates! There's not enough people willing to donate their time to QA test all of this.

Keeping all this machinery working sounds like a tremendous amount of work, and for what? So that our things break randomly every now and then? So that we can feel good about "memory reuse" while in practice all software we use is Electron crap that happily spins up a chromium instance per window?

The only seemingly valid argument supporting all of this rube goldberg machinery is that we want system updates to automatically patch our applications when a CVE is detected in a system-wide dependency like glibc. But that's (1) Much less of a concern for desktop Linux, which are rarely open to the wide internet in a way that most common exploits could be achieved, and (2) Sysadmins and anyone deploying software on servers are moving away of this traditional distro model in favor of Docker precisely because distro updates break things and environments are non-reproducible.

Anyway... I won't side with Epic on this because they used a deprecated function long after it was documented as such and that's not good practice, but things that work should keep working after an update, I'm tired of this.

At least now we have Valve carefully curating the system updates on Steam OS, so there's less of an incentive to boot up windows when some game stops launching after an upgrade.

statically linking wouldn't help here, at least not forever.
glibc stands between the kernel and userspace.
So if you don't plan to stay with an outdated kernel forever, a statically linked executable will face the issue sooner or later.
We are talking about a deprecated feature since 16 years, while the new feature replacing it has been available since 2 decades.
Somebody, please, explain me WHY on earth one should still rely on it with a software written today.
This is not a glibc fault.

Quoting: kokoko3kstatically linking wouldn't help here, at least not forever.
glibc stands between the kernel and userspace.
So if you don't plan to stay with an outdated kernel forever, a statically linked executable will face the issue sooner or later.
We are talking about a deprecated feature since 16 years, while the new feature replacing it has been available since 2 decades.
Somebody, please, explain me WHY on earth one should still rely on it with a software written today.
This is not a glibc fault.

Good blog post about the problem: https://blog.hiler.eu/win32-the-only-stable-abi/

TL;DR -

* DT_GNU_HASH has been around for 16 years, but has very little documentation associated with it. Especially compared to DT_HASH.
* For those 16 years, it was Glibc who provided the compatibility and overrode the defaults for everyone and there never were any easy-to-spot deprecation warnings.
* The constant changing of libraries in Linux with all disregard for applications targeting them is why for most GameDevs, Win32 is a far more stable ABI to target than anything provided in Linux.

And my personal opinion (from experience) - you are not going to get GameDevs to conform to the "Linux" way or the "Right" way of doing these things. If you want gaming on Linux, we have to go to the GameDevs.


Last edited by EagleDelta on 15 August 2022 at 5:59 pm UTC

Quoting: setzer22I'm an Arch user, and have been for quite a long time. But I'm starting to grow increasingly worried about the sustainability of their distro model. Honestly, this obsession with dynamically linking everything and updating as soon as possible is a huge house of cards waiting to fall under its own weight.

I feel the same way sometimes, Arch likes to spin their wheels.

I also generally don't like the way Arch compiles things (I want optimizations, not hardening flags and stack canaries, and I don't want my compilers producing position independent objects by default, thank you) so I change it.

Arch really jumped the gun on glibc this time. I maintain two setups on this box, a customized Manjaro* that I mostly maintain myself, and a custom "from scratch" system that I use for more serious stuff (and I also have that one on other boxes). I also have a customized Slackware 15 on one box. I keep them all binary compatible so I can run some builds on all systems.

(* A Manjaro install is just what I started out with. I was attracted by the more delayed update cycles. I actually follow Arch and edit their PKGBUILDs. I have a bloody novel's worth of text in IgnorePkg lines in pacman.conf lol)

I'm still paying for glibc 2.36. I don't do anti-cheat in games (I only like single player) but I had a lot of compile time issues to work around when bootstrapping toolchains and recompiling/upgrading things. I haven't had any binary compatibility issues though.

While I get angry, I always come back to the mindset that at least Arch provides me with a full multilib system environment that I can work with. There's no way I'd use some Ubuntu or Fedora distro or their ilk because those distros make it difficult for the way I do things.

I don't like containers, and I won't run software like that, so Arch base it is for me.

Quoting: EagleDeltaFor those that make comments about Debian "Stable" - I work in the tech space, security issues come in on a fairly daily basis and if things aren't updated almost constantly, they will sadly be vulnerable.

Hence why Debian stable includes frequent security backports fixing issues, without breaking functionality.

That's not to say that model is perfect, because there is no perfect model (or there'd be a single Linux OS); a few months ago I moved many of the programs I use (like Inkscape, Blender, GIMP, etc.) over to Flatpak to get updates more frequently. But for the underlying OS I like the stability and security.

I ran into this a few weeks ago and had to install the flatpak version of Steam to get around this issue.

The greatest weakness of Linux (some say that it is a strength) is not having its own libc. I would like to see Linux being the maintainer of glibc and refusing to break in every release and put the blame in the developer.

Quoting: EagleDelta

Quoting: kokoko3kstatically linking wouldn't help here, at least not forever.
glibc stands between the kernel and userspace.
So if you don't plan to stay with an outdated kernel forever, a statically linked executable will face the issue sooner or later.
We are talking about a deprecated feature since 16 years, while the new feature replacing it has been available since 2 decades.
Somebody, please, explain me WHY on earth one should still rely on it with a software written today.
This is not a glibc fault.

Good blog post about the problem: https://blog.hiler.eu/win32-the-only-stable-abi/

TL;DR -

* DT_GNU_HASH has been around for 16 years, but has very little documentation associated with it. Especially compared to DT_HASH.
* For those 16 years, it was Glibc who provided the compatibility and overrode the defaults for everyone and there never were any easy-to-spot deprecation warnings.
* The constant changing of libraries in Linux with all disregard for applications targeting them is why for most GameDevs, Win32 is a far more stable ABI to target than anything provided in Linux.

And my personal opinion (from experience) - you are not going to get GameDevs to conform to the "Linux" way or the "Right" way of doing these things. If you want gaming on Linux, we have to go to the GameDevs.

How is it possible that I know more than a easycheat dev when it comes to this particular issue, given that I'm not a dev?
I'm not talking about linking libraries, because you can solve the issue with flatpacks and similar or by just providing the correct ones.
We're talking about a technology old at least 16 years badly required by incompetent developers here.
And there is 16 years old windows software that can be run wothout issues under proton today and is not compatible anymore with windows itself.

Quoting: evasbThe greatest weakness of Linux (some say that it is a strength) is not having its own libc. I would like to see Linux being the maintainer of glibc and refusing to break in every release and put the blame in the developer.

That's like saying Linux should maintain its own distribution.

There are alternatives on every end of the spectrum. Some people are happy with the GNU libc, others are happy with systemd, some are happy with both, and even if you're neither, you still have the choice to run musl and sysvinit instead... or something completely different, and *still* not having to leave the Linux ecosystem.

So yes, I do see it as a strength, or maybe part of Linux' immune system, that "Linux" is "GNU/Linux" if and only if you make it so. Or conversely of course, "GNU/Linux" is only as much "Linux" as you make it, if you want to go that route. It's all about freedom of choice.

Quoting: kokoko3kHow is it possible that I know more than a easycheat dev when it comes to this particular issue, given that I'm not a dev?

Right?
Instead of people shouting "glibc broke my games" they should instead shout "Anticheat broke my game", that's what's actually wrong here.

But more to the point, I can definitely see Epic intentionally playing dumb. It hurts Linux, which they hate, and it hurts their competitor, which they certainly don't have much love for, either. And in the end, it's a simple fix where they can shine and bask in their glory as the saviours of both.
That may be a bit over the top, but still... keep that in mind.

No trouble on Manjaro Testing for me, could even play Warhammer: Vermintide 2