Check out our Monthly Survey Page to see what our users are running.
We do often include affiliate links to earn us some pennies. See more here.

Recently it was noticed that users on more bleeding-edge Linux distributions that updated saw Easy Anti-Cheat no longer working on Linux, the culprit was glibc and now a Valve developer has spoken out about it.

Writing in a small thread on Twitter, Valve developer Pierre-Loup Griffais said:

Unfortunate that upstream glibc discussion on DT_HASH isn't coming out strongly in favor of prioritizing compatibility with pre-existing applications. Every such instance contributes to damaging the idea of desktop Linux as a viable target for third-party developers.

Our thoughts on the topic from this prior compatibility issue in BlueZ apply more than ever: https://github.com/bluez/bluez/commit/35a2c50437cca4d26ac6537ce3a964bb509c9b62#commitcomment-56028543
It is unfortunately yet another entry in a growing list over the years.

We understand that working with a focus on compatibility requires more resources and more engineering trade-offs, but strongly believe it is nonetheless the way to go. We are very interested in helping with any underlying resource constraints.

This prompted CodeWeavers (who work on Wine and with Valve on Proton) developer Arek Hiler to write a blog post titled "Win32 Is The Only Stable ABI on Linux" and their ending statement is something people should think on:

I think this whole situation shows why creating native games for Linux is challenging. It’s hard to blame developers for targeting Windows and relying on Wine + friends. It’s just much more stable and much less likely to break and stay broken.

Hiler certainly isn't the only one to think like that, with another CodeWeavers developer Andrew Eikum mentioning on Hacker News some time ago:

As a long-time Linux dev (see my profile), I have also found this to be true. Linux userland APIs are unstable and change all the time. Some transitions that come to mind that have affected me personally: ALSA->pulse; libudev->libudev2->systemd; gstreamer 0.10->1.0. All of those changes required modifications to my software, and the backwards-compat tools that are provided are buggy and insufficient. Meanwhile, you can still write and run winmm[1] applications on Windows 10, and they will work in almost all cases. It's simply the case that the win32 API is more stable than Linux userland APIs, so it's entirely plausible that games will run better in Wine, which shares that stable ABI, than they will on Linux, especially as time goes on and Linux userland shifts yet again.

[1] winmm dates to the Windows 3.x days!

Situations like this can be pretty messy and this is not a case of open source versus secret closed source anti-cheat stuff either, since the glibc issue affected a Native Linux game (Shovel Knight) and Linux software libstrangle. No doubt there are other things yet to be discovered that were broken by the change.

It is of course also a case that Linux distributions need to ensure they do quality assurance testing, especially for gaming which can end up showing up issues quite easily and that bleeding-edge distributions can and clearly do end up breaking things by pulling new software in so quickly.

Article taken from GamingOnLinux.com.
43 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly came back to check on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly.
See more from me
123 comments
Page: «6/13»
  Go to:

omer666 17 Aug
I agree with many clever comments in here.
I don't know if anyone is right or wrong on this particular topic, but it shows one thing: Linux on the desktop is several products pieced together (hence why it's called a "distribution") so sometimes when a project goes its own way (and rightly so, it's their own work we're talking about), the other actors of said Linux desktop don't always take the time or resources to work on the issues that could potentially come from it (and rightly so, for the exact same reason).

I think it's part of how things are on Linux, it's not necessarily good or bad, I learned to live with it as a matter of fact. Things could certainly be improved though.


Last edited by omer666 on 17 August 2022 at 5:43 pm UTC
dibz 17 Aug
Quoting: EagleDelta
Quoting: dibzPersonally I still prefer how Debian labels things with stable / testing / unstable. It's clear what it is and isn't, I would consider unstable to be their bleeding edge. I'm not personally advocating using Debian or anything, it's just a good example.

The problem with that is that, as great as Debian is, "stable" runs a LOT of software that the upstream developers no longer support at all and haven't for years.

Which, IMO, is very different than what's happening here. glibc accidentally broke some software and games, but refuse to revert the change. Most projects don't take that kind of stance. They will revert breaking changes and work on a future resolution to the problem instead of pointing blame at someone else.

As for comments on Valve using an Arch-base. That's needed for what they do as fixes for gaming specifically are only found in newer software, drivers, and Linux kernels. Running something like Debian stable would be a nightmare for gaming as things are out of date and unusable for a lot of games really fast. Especially newer games and especially of those games (or WINE/DXVK/etc) rely on newer driver features that may require newer kernel features to function, etc.

Which is where part of the issue lies with gaming and Linux. A lot of "vocal" linux users and devs want GameDevs to develop for Linux, but ALSO to conform to what those "vocal" users/devs think is the "right way" and People don't work like that. Linux has to go to THEM and make their lives easy/easier when working with Linux and do so in a way that THEY are familiar with or they will just nope out and not care. And that will happen because the perception is that we, the linux community, don't care about their perspective.... so why should they care about us?

I wasn't actually advocating using debian stable (which I noted), it's simply a good example of a distro where updates are extremely unlikely to break it -- not that it's impossible, stable distros still receive security updates while they're still supported and you never know, some app or another might depend on the patched behavior.

Similar with Arch. I probably needed a /s for sarcasm. It's fine if you use arch by the way.

Yeah, one of the best and worst things about Linux is the vocal community. And let's be honest, the people that flock tend to have very strong personalities -- borderline autistic at times. Bad advice is extremely rampant, often times based simply on personal preference OR it puts themselves in a position of power where the advice seeker is forced to continue asking for help. It can be difficult for first timers to tell the difference. On the other hand, if one is able to navigate those waters, it's an amazing community with many different perspectives and often times intelligent reasoned discourse. Heck, look at the comment section on this site sometimes, it's rarely to the point of "requiring moderation" so to speak, but it can get fairly intense at times.

Unfortunately, and this isn't fair to engineers, but I tend to call your last bit and the behavior you describe the "engineer attitude." I'm a sysops guy, and I run into that a lot when dealing with purely-engineer folks, especially in more recent years (last 5 years maybe? could be 10...). The my-problem/not-my-problem strictness, which in the workplace can absolutely be necessary, but it can and often is abused as well. Some will recognize this as being strongly related to common workflows in practice today. You're a lot more productive the more work that isn't your problem, lol. Honestly it might be a little more fair to ascribe this to Project Managers, but certain personalities blend really well with it.


Last edited by dibz on 17 August 2022 at 3:38 pm UTC
pgr 17 Aug
Quoting: ShabbyXBut more importantly, it's because Linux actually doesn't follow the bloatware practice. Linux's ABI most definitely changes in backwards incompatible ways. It just happens to change mostly in actively developed areas where users are also developers of the feature and they adapt to new changes.

Linux's motto is not *never change the ABI*, but *never break userspace*. The difference is that if a change breaks ABI but not userspace (like, no active users of it, or userspace happens to not break), then the change goes through perfectly fine.
Yeah, but the problem with this glibc change is that it did break the userspace! :) This issue was not about "never change the ABI". Nothing prevents making this, or any change, if it is done without breaking existing programs. I think Linux (the kernel) should be good example that evolving without breaking stuff is definitely possible. I think that keeping stuff working is something to be proud of.
Kristian 17 Aug
Maybe what is needed is some Wine like compatibility layer but for running older Linux software on newer Linux systems.
DerpFox 17 Aug
Quoting: shorbergCase A:
At one point Windows server had an update with a breaking change which crashed our test machine; we reported to Microsoft, two days later we got a new update reverting the previous update. Business as usual. We were just one company out of the many many companies that run on Microsoft's platforms, yet they immediately gave us a quick-line to their experts and made a revert because breaking applications is not OK.

Being an admin too, I can relate to that. The only thing I can maybe "critic" is that here you are talking about Windows Server. So, I don't know if M reverting to the previous version is due to the company you worked for being huge or the problem being on Windows Server. On the server side, stability is an important thing.

This year, an important software, of a company I used to work for, randomly ceased to work on Windows 10. Fortunately, they produced a patch rapidly. "Something" was changed in Windows 10, and they had to update sone of their code for it.

Both you and I have stories about zombie systems still maintained because something was broken in the Microsoft APIs. So, when I hear Windows API are more stable, I'm a bit sceptic. Particularly when I read people writing things like "I can still run software from Windows 3.x on Windows 10". Yes, they can run some, but the vast majority won't work any more. I think 3.x software started to break around Windows XP era. Even as gamers, how may of our 90s game, can we still start today on Windows 10/11? Not much, same is happening or has already happened with 00s games. And I think I have a couple 2010s games that are starting to act weird.

For me, the only thing we can hold glibc dev accountable for is the poor communication around the depreciation of this function. (proprietary software are not better on that one) But let's take it with a grain of salt because anyone who has been asked to write a doc will tell you no one like to write them and no one want to write them. If the communication was done properly this wouldn't have happened.

On Linux, we are not yet used to run zombie systems. But I feel it will soon come, as there is not only zombie Windows out there. I'll now say monster names that will make some Sysadmins have cold sweat. AS400, Sun Solaris, OS/2, HP-UX, DOS. They are still out there waiting in the shadow for your helpdesk to be the more vulnerable. And then they strike, they have a hiccup making some big company piss their pants because their whole business rely on them.
View PC info
  • Supporter
GlibC is the reason why I haven't used Fedora for games, in my case I believe it were some Feral launchers which were not working even with the Steam Flatpak (I guess it doesn't matter, if what fails is the game launcher).

Anyway when I looked into the reason behind the issue... yes, it is hard to blame the distro nor GlibC.
Humans will invent general artificial intelligence, and maybe go to Mars, but, if and when that happens, games will still be using 32 bit libraries and running on x86.
omer666 17 Aug
Quoting: dibz
Quoting: EagleDeltaWhich is where part of the issue lies with gaming and Linux. A lot of "vocal" linux users and devs want GameDevs to develop for Linux, but ALSO to conform to what those "vocal" users/devs think is the "right way" and People don't work like that. Linux has to go to THEM and make their lives easy/easier when working with Linux and do so in a way that THEY are familiar with or they will just nope out and not care. And that will happen because the perception is that we, the linux community, don't care about their perspective.... so why should they care about us?
Yeah, one of the best and worst things about Linux is the vocal community. And let's be honest, the people that flock tend to have very strong personalities -- borderline autistic at times. Bad advice is extremely rampant, often times based simply on personal preference OR it puts themselves in a position of power where the advice seeker is forced to continue asking for help. It can be difficult for first timers to tell the difference. On the other hand, if one is able to navigate those waters, it's an amazing community with many different perspectives and often times intelligent reasoned discourse. Heck, look at the comment section on this site sometimes, it's rarely to the point of "requiring moderation" so to speak, but it can get fairly intense at times.
An interesting fact is that the very reason why we can talk about those issues in the first place is precisely because of Linux's open source nature. A Windows user could say "Windows Update broke my toy", but on Linux it's much easier to point out one (group of) person's fault. It is a double edged sword, really. We are a very tech-savy, software engineering curious community, but like every enthusiast population, we can have very strong-minded opinions.


Last edited by omer666 on 17 August 2022 at 4:43 pm UTC
There's a lot here I'm not qualified to comment on. But one thing I've seen a bit that I think is pretty clearly a misconception:

This is not about Arch, or about Arch's bleeding edge nature.

I don't use Arch and I'm not the kind of guy who wants to run bleeding edge. But if anything, Arch here functioned as a useful coal mine canary. If a new GlibC had contained a bad behaviour that the GlibC people just hadn't caught yet, and they quickly rushed out a bugfix point release that no longer did that, and the only distro that pushed out that first, buggy GlibC without waiting was Arch, then it would be about Arch. But that's not the story here--the story here is that the GlibC people created the breakage deliberately and are hesitant about the idea of un-creating it. Whether the breakage is justified or not (I'm leaning not), that means everyone, all distros, in the end would be finding themselves distributing a GlibC that creates that breakage. Arch was just the first to expose the issue.

This is doubly not about Valve using Arch as the base for SteamOS because SteamOS is not a bleeding edge distro in any way. It just uses a heavily curated snapshot of Arch as a base, but there is no way it would find itself inheriting a problem like this.
Question: There has been talk about how not getting rid of the old version of the function thingie requires these other thingies taking up 16K more memory each. Um, how many of these other thingies are we typically talking about existing at a time? Cuz like, if there's often a billion of them on a desktop system, I can see that being a big problem, but if there's like five, I don't give a damn.
Shmerl 17 Aug
Quoting: JpxeIsn't Flatpak the solution to this?

I think lbic is low level enough to be considered a fundamental library even for the above.
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone with no article paywalls. We also don't have tons of adverts, there's also no tracking and we respect your privacy. Just good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
Login / Register

Or login with...
Sign in with Steam Sign in with Twitter Sign in with Google
Social logins require cookies to stay logged in.