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.
BlackBloodRum Aug 17, 2022
Maybe now they can understand why we do it that way. 😂
With that said, we shouldn't stop developing or pushing ahead in our FOSS software by holding back development just to keep some proprietary spyware like EAC working that doesn't play nice in the first place.
BlackBloodRum Aug 17, 2022
For example, RH very much keep up with latest CVEs and catalogue them for their customers and detail whether it's fixed, unaffected or vulnerable:
https://access.redhat.com/security/security-updates/#/cve
With that said having the latest versions of software doesn't make you immune from security issues either, nor less likely.
It can also go the other way, a security issue can occur only in a new version of software but not affect older versions, there have been several security issues over the years that simply didn't affect RHEL because the security bug was only present in newer versions of software.
Also, a security issue can go unnoticed for years in software, even eith latest versions. Then there's developers who deem certain things "not a priority" who don't patch a security bug they know exists (this affects proprietary software like windows mostly)
Don't assume that just because patches are backported that the software is more vulnerable as a result. RH has a lot of professional employed security experts keeping tabs on this.
Edit: Typos.. I hate typing on smartphones...
Last edited by BlackBloodRum on 17 August 2022 at 9:19 pm UTC
Quoting: F.UltraNew releases of WINE/Proton breaks games that worked with the older version from time to time so yes they are wrong in that WIN32 is the only stable ABI on Linux since it clearly isn't stable.
It's not a either/or, binary reality discussed here. It's not a question if this or that ever breaks at all, ever.
I don't think things like this breakage can be tested automatically since you'd have to create so many obscure test cases that the effort would make it infeasible.
BlackBloodRum Aug 17, 2022
Quoting: KlaasYes, obviously. But my point was that the supposedly stable things have large caveats as well and it is really not related to the current issue at all to constantly state that rolling release distribution break everything constantly. This is not an issue of rolling vs frozen distribution.
I don't think things like this breakage can be tested automatically since you'd have to create so many obscure test cases that the effort would make it infeasible.
It's all on usage case. For a server, stable is better.
Both options have caveats and issues to deal with.
My point was that people (such as yourself) often believed that enterprise level distros were pointless even for servers (You have no idea how many times I've had this exact discussion over the years) and proceed to attack enterprise grade distros, citing false security concerns and caveats and would suggest that running arch on a server was a better option.
Meanwhile in the enterprise world we always cited compatibility as a primary concern which this EAC issue highlights.
So my point was merely it would help you understand why we use such software in a stable environment that allows us to keep our systems running without breaking software.
That rolling isn't always a better option, software changes and it's the nature of the beast, it's how you handle those changes that matters.
In my case I use both, I use rolling release for my desktop and stable for servers. Best of both worlds 🫠
Last edited by BlackBloodRum on 17 August 2022 at 9:30 pm UTC
CyborgZeta Aug 17, 2022
But wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?
Last edited by CyborgZeta on 17 August 2022 at 10:12 pm UTC
Cloversheen Aug 17, 2022
Quoting: dibzYeah, 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.Autistic is not the word you are looking for here. It is a common and widespread misconception, but it really isn't what you are looking for to describe the individuals you are hinting at. Autistics are often asocial, generally not antisocial. Typically, if an autistic person learns they have said or done something that have hurt someone, they will feel intense remorse.
A "borderline autistic" person is a perfectly average person, you likely won't even notice anything different except perhaps slightly increased anxiety compared to baseline human their age. At most you might describe them as someone who likes to stay home and read a book on a Saturday every now and then.
They are not people who will try to rally the masses, they will probably just stand at the sideline wishing they could contribute more. There are exceptions though, a certain fellow countrywoman is a strong personality who does quite a bit to hold people accountable for the climate.
Quoting wikipedia,
QuoteThe autism spectrum is a range of neurodevelopmental conditions generally characterized by difficulties in social interactions and communication, repetitive behaviours, intense interests, and unusual responses to sensory stimuli.The difficulty in social interaction and communication refers to discomfort and avoidance and reduced body language. But many autistics won't put themselves in most social situations to begin with, either because of a lack of interest in social activities or because it confuses them. Even mailing-lists, or forum posting is something that scares many.
Source: I've done a lot of reading on autism, I have talked to a lot of professionals, I have friends who are autistic and I am autistic myself. I am however far from an expert, and open to learn more.
PS. What I have described as autistics above is not a set of all people with autism spectrum disorder, it is a generalised set of the ones who are high-functioning enough that you are likely to have been in contact with them in something as complex as technical online discussions.
BlackBloodRum Aug 17, 2022
Quoting: CyborgZetaI am not a software developer or a progammer; I am just a regular computer user. So please do not get angry at me for asking this, as I probably don't know what I'm talking about.
But wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?
Yes and no.
It's not so much a technical limitation at this point, but rather a legal one.
It could be done in a number of ways but EAC, being proprietary, cannot bundle a glibc binary into their closed source product for redistribution in another closed source product (the game) for legal reasons since it breaks to LGPL terms.
In addition the glibc devs heavily advise to always dynamically link to the OS's glibc for best overall compatibility and security.
(EAC did correctly here by dynamically linking)
Usually this isn't a big deal in FOSS projects because someone will come along and patch an application to work in a newer glibc and happy days.
But the kicker here is that EAC is compiled directly into the distributed games. Which means distro vendors can't patch it, steam can't patch it and neither can EAC themselves.
The only way to properly fix it (to work with newer glibc) at this point in deployed EACs would be for EAC to update EAC, and then each EAC game updates their EAC and recompiles with the patch.
The other legal issue is that neither EAC nor steam can just come along and just stick a closed source game into a new flatpak with needed libraries, because that would break the games license terms.
Considering many games may not see an update due to inactive devs, it doesn't look good.
At this point best case is that EAC patch to use the modern hash and the game devs update their EAC.
PS: Sorry if I came off a bit brash earlier.. long and bad day...
Cloversheen Aug 17, 2022
Quoting: CyborgZetaI am not a software developer or a progammer; I am just a regular computer user. So please do not get angry at me for asking this, as I probably don't know what I'm talking about.
But wouldn't running games, and programs/applications in general, inside containers fix this kind of issue? Isn't that one of the goals of Flatpak?
A great question CyborgZeta!
Yes and no. It is really quite overkill to use something like flatpak for the use cases we are talking about, the industry have dealt with this issue for decades and the solution (which is typically used on the windows platform) is to bundle your dependencies either statically in your binary or as dynamic libraries next to your binary.
There are pros and cons to that, for something like a game it is usually "good enough" to bundle only some dependencies given the non-critical nature of games. Programs written in Go(lang) are built as independent static binaries by design. As far as I know this means that they will run pretty much on any system as long as the architecture is compatible (linux x86, windows x86, linux arm, etc).
For drawbacks there are three big ones, one is size. Statically built binaries are larger in size since they bundle everything the program needs inside the binary itself. Another is that if the assumptions those dependencies made about the platform were to change they would still break. Lastly, security. If my program uses curl dynamically and a security flaw is discovered in curl that can be updated independently of my program.
Containerised solutions share the same first two drawbacks and has the third built in "by design" (both good and bad).
Another one you can make a solid argument for is that containerised applications like flatpak add a lot of unnecessary complexity to an already complex chain.
An advantage that a statically linked binary have over a container is reduced resource consumption and a smaller size on disk. A container needs the entire runtime to be present, which will include a ton of stuff the program won't need. Granted, if you install enough containerised applications that rely on the same runtime the differences go away.
Patreon
PayPal
See more from me