News has been doing the rounds for a little bit about Easy Anti-Cheat (EAC) suddenly not working after system updates for some users, turns out it's an issue with glibc.
Reported on GitHub over a week ago, the issue has been growing as more and more users have been updating their systems. Only certain Linux distributions are affected, mainly those that pull in package updates a lot faster like Arch and derivatives.
EAC is not the only thing broken as there have been reports about the frame limiter libstrangle also being broken by it, the game Shovel Knight and there's probably more too.
In the upstream bug report for glibc there's been plenty of back and forth on it. Hopefully a true resolution will be found. Until then, multiple distributions seem to be readying up an update (Arch looks to have it out now) that reverts the change to get EAC games to work once again. So if you haven't updated recently, it might be an idea to hold off for just a little bit until this situation is sorted.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
To be fair to glibc, this is a problem on the part of Epic using the deprecated DT_HASH instead of DT_GNU_HASH. EAC's Linux implementation is frustratingly half-baked. It really feels like Epic is the biggest barrier to gaming on Linux now.
17 Likes, Who?
Quoting: RustyTo be fair to glibc, this is a problem on the part of Epic using the deprecated DT_HASH instead of DT_GNU_HASH. EAC's Linux implementation is frustratingly half-baked. It really feels like Epic is the biggest barrier to gaming on Linux now.
Question is: why does glibc constantly break the API(/ABI)? It's a damn c library and should be backwards compatible. If at all, functions should be altered on major releases, so distributions have a chance to handle such stuff. Couldn't they just have redirected that damn call? It's really infuriating they don't care for backwards compatibility at all and this hurts linux in many ways.
Last edited by const on 15 August 2022 at 11:11 am UTC
4 Likes, Who?
Quoting: constit doesn't constantly break though, things like this have been deprecated for over a decade before removal, everyone else stopped using it before EAC even began development.Quoting: RustyTo be fair to glibc, this is a problem on the part of Epic using the deprecated DT_HASH instead of DT_GNU_HASH. EAC's Linux implementation is frustratingly half-baked. It really feels like Epic is the biggest barrier to gaming on Linux now.
Question is: why does glibc constantly break the API(/ABI)? It's a damn c library and should be backwards compatible. If at all, functions should be altered on major releases, so distributions have a chance to handle such stuff. Couldn't they just have redirected that damn call? It's really infuriating they don't care for backwards compatibility at all and this hurts linux in many ways.
13 Likes, Who?
Quoting: RustyEpic using the deprecated DT_HASH
to be more precise: deprecated for 16 (!) years.
16 Likes, Who?
I'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.
Last edited by setzer22 on 15 August 2022 at 1:55 pm UTC
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.
Last edited by setzer22 on 15 August 2022 at 1:55 pm UTC
4 Likes, Who?
Quoting: setzer22Honestly, 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.
Sounds like you should take a look at NixOS ^^
0 Likes
EagleDelta Aug 15, 2022
Quoting: RustyTo be fair to glibc, this is a problem on the part of Epic using the deprecated DT_HASH instead of DT_GNU_HASH. EAC's Linux implementation is frustratingly half-baked. It really feels like Epic is the biggest barrier to gaming on Linux now.
While I can understand that attitude, the issue isn't just EAC. Other Linux native games are also broken as well as some other tools. Regardless, non-service based games generally don't keep their games updated and good luck trying to get the industry to change. Microsoft has been fighting this battle with Windows for a couple of decades. Simple fact is that users want their old software, especially games, to continue working. So if we want Linux gaming to succeed, we have to be willing to meet the game devs where they are and not require them to come to us (hint: they won't come to us).
For 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.
2 Likes, Who?
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.
Because the alternative which is how software is distributed on Windows (and how the "new" distribution ways of flatpak/snap/whatever) where the responsibility of keeping the shared libraries up to date for security holes and other bugs are shifted onto the developers of each and every single application that you install of it being done just once for your entire OS by a much larger and more competent team.
And thinking that Linux is somehow less impacted by security holes by "something internet something" is naive, we are just as conencted and impacted by this as the Windows users. Now for games in particular, security is rarely an issue what so ever, but if we take applications instead then holes in shared libraries can be exposed by you opening a file in OpenOffice, VLC, GIMP or whatever, it does not have to be an exploit in port X where some Windows subsystem listens to external connections.
The main issue in this particular case though is the "and updating as soon as possible" part which only happens on rolling update distros like arch that want's to be on the bleeding edge for everything instead of the slow and methodical way of Debian or Red Hat.
Last edited by F.Ultra on 15 August 2022 at 3:50 pm UTC
4 Likes, Who?
Patreon
PayPal
See more from me