Support us on Patreon
PayPalRecently 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.
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.
ElamanOpiskelija Aug 17, 2022
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.
Quoting: dibzAn 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.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.
Last edited by omer666 on 17 August 2022 at 4:43 pm UTC
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.
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.
Windows, which have nearly entire market, so people must adapt.
Also, on one polish University device was created and they had problems write drivers for Windows. They wrote drivers for Linux without problems. Again.. This device do not be very popular due Windows had entire market and was stop existing. Simple - nobody bought it, so nobody produce it.
Quoting: Purple Library GuyUm, how many of these other thingies are we typically talking about existing at a time?Run ldd on a binary and count the number of libraries that are referenced.
Cloversheen Aug 17, 2022
Quoting: DerpFoxBeing 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.Fair critique.
Quoting: DerpFoxThis 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.Aint that a blast. Gotta love the "something" part.
Quoting: DerpFoxBoth 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.I'm not sure if that is because of the Win32 API or some other APIs but that was definitely already a case with XP as you noted. For the uninitiated (I envy you) this was when Windows stopped being built as a DOS application and moved to the NT-platform.
And to add to what DerpFox said, it has also been a big pain point for many gamers with the switch to Windows 10, as $SEARCH_ENGINE can tell.
Quoting: DerpFoxI'll now say monster names that will make some Sysadmins have cold sweat. AS400, Sun Solaris, OS/2, HP-UX, DOS.Geez.. Language, man!
Since you love to throw around scary words like that on poor unsuspecting strangers; I'm gonna have to pay you back and ask if you have read the fine blog by Raymond Chen?
Last edited by Cloversheen on 17 August 2022 at 5:56 pm UTC
See more from me