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.
Quoting: slaapliedjeWe'll have to agree to disagree on that front, most of the outrage I've seen is about glibc developers not making it clear they were removing DT_HASH (and that you needed to go to mailing lists and such to know it was depreciated, incremented the patch rather than the major for a breaking change) and I'd say the bigger deal of hurting the prospect of the Linux desktop being ported to or getting more native applications (especially for game developers when games inevitably stop getting maintained and typically do not get their source released once the game is EOL) due to these sort of changesQuoting: JordanPlayz158Well, it 'sort of' is about open vs closed. If it was open (Shovel Knight) someone could have given them a pull request to change to the newer method. That's pretty straight forward.Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
This wasn't really about backward compatibility, and more about deprecated methods still being used in software. This should be a wake up call for those projects that use old crappy code, and hopefully they'll get updated to be faster.
Quoting: JordanPlayz158Quoting: slaapliedjeWe'll have to agree to disagree on that front, most of the outrage I've seen is about glibc developers not making it clear they were removing DT_HASH (and that you needed to go to mailing lists and such to know it was depreciated, incremented the patch rather than the major for a breaking change) and I'd say the bigger deal of hurting the prospect of the Linux desktop being ported to or getting more native applications (especially for game developers when games inevitably stop getting maintained and typically do not get their source released once the game is EOL) due to these sort of changesQuoting: JordanPlayz158Well, it 'sort of' is about open vs closed. If it was open (Shovel Knight) someone could have given them a pull request to change to the newer method. That's pretty straight forward.Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
This wasn't really about backward compatibility, and more about deprecated methods still being used in software. This should be a wake up call for those projects that use old crappy code, and hopefully they'll get updated to be faster.
This was certainly a documentation mistake, but as well misunderstanding what they (glibc) consider as their api/abi, and what some applications did consider by it.
That said, it should have been a wakeup call to those using it, and we will probably see ports to DT_GNU_HASH, and DT_HASH will disappear with a major release at some point.
That will give them thoughts about what they want to deprecate of the ELF sections too for a next major release. And it's good this process started.
It's a real nieche usage, I personally never did require to use DT_HASH or DT_GNU_HASH since dlopen pretty much did work for my cases. But I undetstand wanting to directly read library information in some use cases (security scanners being one, they certainly don't want something messing with dlopen, and I know some commercial tools messing with the dlopen and generally library loading process, dynatrace comes to mind as an example).
Last edited by STiAT on 19 August 2022 at 7:00 pm UTC
Kuduzkehpan Aug 19, 2022
no native computing?
still no?
why should we expect rather than this?
""")
native = input("Native Computing Or not Choose wisely and case sensitive")
if native != "Native Computing":
print("you deserved that")
else
print("Finally May the open source be with you")
Quoting: KlaasQuoting: KuduzkehpanelseSyntaxError: expected ':'
and what's that? Python? lol... the langauge best known to break API in minor versions and even bugfix releases. By honest mistakes which got fixed with fast follow up releases, but still. Got better in the past few years though, was a lot worse in 2.x, but happened in 3.x too (3.6 series in example).
Last edited by STiAT on 20 August 2022 at 1:35 am UTC
slaapliedje Aug 20, 2022
Quoting: STiATBash is notorious for this as well.Quoting: KlaasQuoting: KuduzkehpanelseSyntaxError: expected ':'
and what's that? Python? lol... the langauge best known to break API in minor versions and even bugfix releases. By honest mistakes which got fixed with fast follow up releases, but still. Got better in the past few years though, was a lot worse in 2.x, but happened in 3.x too (3.6 series in example).
So in a case like this with glibc, did they need to yell from the rooftops that they were now going to remove the 'both' from the automake file? Maybe post it on Twitter, Facebook, CNN? I'm honestly curious how something like this gets stated so people know that something that was added has deprecated older bits, and you should no longer use them. This is longer ago than a huge majority of people even know what Linux was...
Quoting: JordanPlayz158Quoting: PublicNuisanceSo an employee from a company who makes a closed source game store client that hosts a closed source game that uses closed source anticheat software had an issue with an open source library and i'm supposed to side with the employee ? Do I about have that right ? Would it not be an easier issue to fix if more of that equation I listed were open source ?It wasn't just EAC that broke but a few other applications like Shovel Knight, a game with a native linux port and libstrangle, an fps limiting library, this isn't about open vs closed source software, this is about maintaining backwards compatibility to not only make linux more enticing to port to but also to make it so things like games that do not get maintained forever won't get lost to time.
More to the point, I understand why EAC cares about the internal representation, but I don't understand the usecase of shovel knight and libstrangle. What they do with the hash table that can't be accomplished with the standard API?
Patreon
PayPal
See more from me