Quoting: EagleDelta

Quoting: BlackBloodRumIt's all on usage case. For a server, stable is better.

What is the definition of "stable" here? For things like RHEL, CentOS, Debian Stable, SLES, sometimes even Ubuntu Server "stable" generally means very, very old versions of software that many times is no longer maintained by the upstream developers. In many cases when I was a SysAdmin, that meant we had to install external YUM or APT repos to install the software that the project or company "supported" because what was included in the distribution was no longer supported by the community or the company behind the FOSS project and as such, support was entirely on us to manage.

As for enterprise, the advent of patterns like containerization (Docker, containerd, Flatpak, etc) has enabled the ability to have a stable OS with newer (or older) libraries running inside the application "container". However, in the case of glibc, I'm not sure that's an option. Especially on Desktops. glibc is so core to the OS that the container would have to ship GFX drivers as well that are built on the shipped glibc version separate from the host OS and anything else that entails.

When it comes to core system functionality, compatibility will always win out from the non-technical customers/users. There's a reason Microsoft has not successfully moved away from win32 yet, despite the amount of times they've wanted to and tried.

Stable means that the API/ABI are unchanged for the lifecycle of the distribution so that enterprises can build software for say RHEL7 and their customers can then be sure that this software will work exactly identical on RHEL7.0 as it will on RHEL7.9 even though there are 5 years between the two releases.

While the included software might be versions that are no longer being maintained upstream they are being maintained by the distribution developers (this is why a subscription to RHEL does not come cheap) and security features are backported, which is why even if it might look like you run PHP v3.4 you do infact run a highly patched version of PHP that is just as secure as PHP 8.x but walks and talks like 3.4

That you had to import external repositories with newer software was a decision made by your company developers to use that newer software instead of the one provided by the distro of choice. Either the devs have to be kept in check (they will always want the new shiny) or the choice of distribution have to match what they need/want, the kind of combination that your workplace tried is usually a road to unnecessary complexity and problems.

View this comment - View article - View full comments

Quoting: JordanPlayz158

Quoting: F.Ultra

Quoting: JordanPlayz158

Quoting: ShabbyXIt's made exactly so that libraries *can* break ABI if they have to, without the world imploding. glibc made a breaking change, and no matter how small, they should have made an incompatible version change. Yes that would still be inconvenient, but at least it's detectable and fixable. Imagine if python3 did all its backward incompatible things but still called itself python2.

Yes, that's exactly the point we were making, they didn't treat it as a breaking change as they just incremented the patch number by 1 rather than the major. Not to mention a lot of people have said it wasn't very clear and I could buy that as documentation doesn't seem to be a strong point in either linux or c in general (or I could be wrong (or xdg-desktop-portal could be a bad example of a c library) but when I attempted to make an application using xdg-desktop-portal they had the equivalent of a javadoc but that was about it, there are no examples provided in the repo for how to use any of the objects (or it wasn't clearly labeled or findable), there were no tutorials online and I looked into other repos (that are flatpaks as they must use xdg-desktop-portal to my knowledge) and it was a mess because different applications use different languages or sometimes used a middle man library or some combination of the two which made it difficult to know how to use the interface)

glibc is very well documented, as is most C libraries on Linux (don't know where this misconception comes from), they didn't see the ELF sections as part of the glibc ABI/API though which is why this went under the radar for developers that isn't on the glibc mailing lists.

This was not a code change, it was a change in the automake configure script to no longer pass in the argument to ld to include the old hash section when building glibc.

Normally no library/application dev ever sees a change like this as a ABI/API change, but it looks like the glibc devs will do from now on.

Well I just had one example experience (with xdg-desktop-portal, apologizes if they are an exception and not the norm for the standards of C libraries), I try to stay away from languages like C just as it doesn't really seem to click with me like a lot of other languages have (not to mention there are languages like Rust that some say will replace C and while I don't like rust either, it is leagues better for clicking with me). Also yeah, that makes a lot more sense as I was very confused by DT_HASH being in a build config file and not a function in the code when I saw the commit so again, thank you for clearing that up.

no probs, xdg-desktop-portal looks to be a 3d party tool for flatpak and unfortunately many such well intended extra tools are very rarely well documented.

To experience the glibc documentation just open a terminal and type in say "man dlopen" and see just how much information they have on that single function.

View this comment - View article - View full comments

Quoting: slaapliedje

Quoting: F.Ultra

Quoting: Beamboom

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.

So how am I then to interpret CodeWeavers "WIN32 is the only stable ABI on Linux" when it have broken more times for me on my Linux system than glibc have ever done, yet this change by glibc triggers CodeWeavers to make that tweet?!

Of course the Codeweavers dev would say that. It's kind of their business to sell Win32 compatibility to Linux users. I thought I'd be nice and throw some money their way for the mac version of Crossover, but for the most part I've found newer wine is just more capable.

I know, it just bothers me that there are whole reddit threads now filled with (very outspoken) people that believe them. Basically this whole thing is nothing with a storm in a glass, for a short period there existed a breakage for people using bleeding edge rolling distros, but thanks to this all being FOSS those distros could quickly patch the DT_HASH section back in and later glibc themselves fixed it upstream (yes they where initially a bit grumpy about it, which is understandably considering that they did it not for laughs but for actual benefits and have been waiting 16 years to do it. I also think that people put way to much emphasis on devs being grumpy, part of a devs job is to reject patches and being grumpy, otherwise things like glibc would be several GB by now).

View this comment - View article - View full comments

Quoting: JordanPlayz158

Quoting: ShabbyXIt's made exactly so that libraries *can* break ABI if they have to, without the world imploding. glibc made a breaking change, and no matter how small, they should have made an incompatible version change. Yes that would still be inconvenient, but at least it's detectable and fixable. Imagine if python3 did all its backward incompatible things but still called itself python2.

Yes, that's exactly the point we were making, they didn't treat it as a breaking change as they just incremented the patch number by 1 rather than the major. Not to mention a lot of people have said it wasn't very clear and I could buy that as documentation doesn't seem to be a strong point in either linux or c in general (or I could be wrong (or xdg-desktop-portal could be a bad example of a c library) but when I attempted to make an application using xdg-desktop-portal they had the equivalent of a javadoc but that was about it, there are no examples provided in the repo for how to use any of the objects (or it wasn't clearly labeled or findable), there were no tutorials online and I looked into other repos (that are flatpaks as they must use xdg-desktop-portal to my knowledge) and it was a mess because different applications use different languages or sometimes used a middle man library or some combination of the two which made it difficult to know how to use the interface)

glibc is very well documented, as is most C libraries on Linux (don't know where this misconception comes from), they didn't see the ELF sections as part of the glibc ABI/API though which is why this went under the radar for developers that isn't on the glibc mailing lists.

This was not a code change, it was a change in the automake configure script to no longer pass in the argument to ld to include the old hash section when building glibc.

Normally no library/application dev ever sees a change like this as a ABI/API change, but it looks like the glibc devs will do from now on.

View this comment - View article - View full comments

Quoting: JordanPlayz158

Quoting: minidouI fail to see how glibc devs could be blamed for removing a function deprecated for 17 years (though I can agree a major version bump should have been called for). Do videogame devs need that much nursing ? EAC linux lib is a recent piece of software, how many deprecated dependencies do they use ?

Quoting: TermyI tend to agree with the criticism about unstable APIs for many cases - but in this case, i really blame Epic for using a function deprecated for almost two decades in a recent piece of software.

From everything I've read from other people, it wasn't obvious that the function was depreciated. You shouldn't need to search up, "is x function depreciated glibc" for every function you use, it should be immediately obvious (like most languages I know have comments or a depreciation tag), some say that all distros somehow knew about this but you shouldn't need to be familiar with linux development or need to be in the right communities to know about a depreciated function.

Small nitpick here, but DT_HASH is not a libc function, it's a linker section in the ELF header of a shared object. The function that utilizes this section is dlopen() and that function have not changed and it works, it's only applications that tries to read the ELF data manually that have to handle DT_HASH and DT_GNU_HASH, and by all means it looks like the glibc devs "incorrectly" thought that dlopen was their ABI/API and not the actual linker section in the ELF headers.

View this comment - View article - View full comments

Quoting: Zagorim

Quoting: GuestThere's an easy solution, ban the use of EAC in GNU+Linux native games.
Oh, wait...

Except that Shovel Knight is a native linux game that doesn't use EAC and it's still broken by the glibc update.
I think the glibc devs need to be more careful about the kind of updates they push and the impact they can have.

The question is why ShovelKnight have the same problem, very very few applications (and none of them games) should ever have the reason the read the ELF data manually. Everyone else should use the libc provided dlopen() function to open shared dynamic libraries.

Does ShovelKnight use some EAC like middleware?

View this comment - View article - View full comments

Quoting: KlaasBackporting security fixes can lead to a lot of trouble if something is missed. Remember the Debian OpenSSL bug a few years ago?

That had nothing to do with backporting, it was the Debian maintainer thinking that he could improve the entropy of the OpenSSL PRNG with a quick hack of his own.

View this comment - View article - View full comments

Quoting: Beamboom

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.

So how am I then to interpret CodeWeavers "WIN32 is the only stable ABI on Linux" when it have broken more times for me on my Linux system than glibc have ever done, yet this change by glibc triggers CodeWeavers to make that tweet?!

View this comment - View article - View full comments

Quoting: minidou

Quoting: Guest

Quoting: minidouI fail to see how glibc devs could be blamed for removing a function deprecated for 17 years (though I can agree a major version bump should have been called for). Do videogame devs need that much nursing ? EAC linux lib is a recent piece of software, how many deprecated dependencies do they use ?

The blame is not really about removing the deprecated feature. Blame is for the failure to restore it after discovering that users for the feature still exist and the removal broke stuff.

They did restore it because of the backlash, but they really shouldn't have, there's no reason for it. This isn't some obscure lib we're talking about but the GNU C library. If a handful of program gets broken it's on them, the function was marked deprecated almost two decades ago. An outstanding majority of program have no issue at all with the removal of this function, why should a niche but maybe high visibility user dictate the direction of glibc ?

Something not discussed here is that the removal of DT_HASH allows a save of about 1% or 16kB of space per Glibc shared object [External Link]. This is an improvement. There clearly is a good reason for finally removing this deprecated function. But we shouldn't profit from this improvement because of some devs bad practice ?

Quoting: TheSHEEEP

Quoting: GuestThe blame is not really about removing the deprecated feature. Blame is for the failure to restore it after discovering that users for the feature still exist and the removal broke stuff.

Yes, a lot of developers (especially newer, younger ones that lack the experience) argue in favor of always using the very latest everything and always keeping everything updated.
I've seen that time and time again in several teams.

But that's not a position that can be maintained in reality.
You'd require armies just to maintain old stuff.

It's fine to remove a function if you can't see that anyone is using it. An understandable mistake.

This is off topic. The impacted softwares were initialised years after DT_HASH was marked deprecated. In the case of EAC lib, probably a good 15 years later. In every sector of the software industry this would be considered bad practice, but VG softwares get a pass for some reason.

Quoting: TheSHEEEPBut the moment you realize that there were indeed many still using it, it should clearly be restored (with a deprecation marker, but still).

They did that, almost two decades ago.

And it seems there isn't that many users impacted. I can count the EAC lib and some lib used in shovel night. Compared to the millions of programs using glibc.

I'm also wondering if this opens a hole in EAC. Aka since they only seems to check DT_HASH then I can craft a .so that have a nice DT_HASH for EAC to be happy about and then I create my real stuff in the DT_GNU_HASH section that is what the system really loads instead. Now I have never played around with low level linking like this so I don't know if this is possible, but it sure sounds like it.

View this comment - View article - View full comments

Quoting: landeelglibc compatibility has been a pain for a while.
I have released 2 games on Steam with native Linux ports.
I'm always afraid of doing a dist-upgrade, because it's very likely the compiled binaries won't run on the previous distro version.
It's absurd, but targeting win32 is more stable.
There should be a way to have multiple working glibc versions.

There are, you can also in your code tell a new version of GLIBC that you want the function from the older version X since GLIBC uses versioned symbols and keep the old ones around since they started to do that. It's a very painful process though since one have to do this for every single symbol one want's to use.

View this comment - View article - View full comments