Glibc 2.27 Is Being Released Soon With Numerous Performance Optimizations

[FireBurn]

Here was the Gentoo tracker bug https://bugs.gentoo.org/628768 some were source related others were real breakages

[wizard69]

While shipping early is indeed bad for a core component like this,we do need to remember that this has existed in clear Linux for some time. Hopefully the nature of the fixes means a higher potential for decent behavior. That is FMA implementations should be easy to implement and test.

Arch Linux's glibc 2.26 (I really should say glib 2.26 and not archlinux's glibc 2.26) had a massive bug from august till October. Pretty much anything using pthreads was leaking memory very badly. Eventually upstream fixed the bug and arch linux shipped an updated snapshot from 2.26 branch. Arch Linux lacks proper test screening. This was mitigated 10 years ago when they added 'signoffs' but it really is not enough. The bleeding edge argument is not an excuse to ship a broken libc that makes some applications eat 300MB of memory per 24 hours instead of 3.5MB.

For reference, https://git.archlinux.org/svntogit/p...packages/glibc (2.26-1 was the stock buggy glibc. 2.26-5 was the fixed snapshot).

It was very irresponsible of any distribution to ship 2.26 too quickly and I don't expect 2.27 to be any better.

[arokh]

No it wasn't that at all, it was that glibc changed some includes in source files and it broke the compilability of tons of packages.

It's exactly that, not bugs. Like I said, if they had the manforce they could simply fix the affected packages.

[duby229]

It's exactly that, not bugs. Like I said, if they had the manforce they could simply fix the affected packages.

The affected package is glibc. It's the thing that keeps changing includes. That's nobody elses fault but theirs. All they ever had to do was try to build some things to figure out it breaks. Apparently they don't ever try to do yhat. They just change what they want and just screw anything that breaks. They don't care, they don't test, they don't even know!

[arokh]

The affected package is glibc. It's the thing that keeps changing includes. That's nobody elses fault but theirs. All they ever had to do was try to build some things to figure out it breaks. Apparently they don't ever try to do yhat. They just change what they want and just screw anything that breaks. They don't care, they don't test, they don't even know!

So basically you have absolutely no idea what glibc is or how development is done in general.

[duby229]

So basically you have absolutely no idea what glibc is or how development is done in general.

That's not even an excuse, it's just a weak ass comment. The fact is glibc devs make changes that cause -other- programs to fail to compile. You might think it's ok for you to break other people projects, but..... It's not. There's a good reason why kernel devs try not to break userspace. It's just a damn shame that other critical components don't take the same policy.

[arokh]

That's not even an excuse, it's just a weak ass comment. The fact is glibc devs make changes that cause -other- programs to fail to compile. You might think it's ok for you to break other people projects, but..... It's not. There's a good reason why kernel devs try not to break userspace. It's just a damn shame that other critical components don't take the same policy.

It's not weak at all, you are very obviously not a developer as you are making a complete fool of yourself claiming that glibc developers have any responsibility to fix code in projects that use it. Show me a piece of your code that broke with a glibc update? The kernel devs break the nvidia driver (and many others) with pretty much every release, you must be joking right?

These days, completely clueless users seem to have very strong opinions on subjects that they have zero understanding of (like systemd and now glibc). Just curious, do you also walk into car factories or chemistry labs and tell them how to do their jobs?

In any case, API's change that's just the way it is. If a distribution wants to use a recent glibc, it's their job to patch incompatible software. In no way, shape or form are API changes within glibc BUGS which you claimed.

[duby229]

It's not weak at all, you are very obviously not a developer as you are making a complete fool of yourself claiming that glibc developers have any responsibility to fix code in projects that use it. Show me a piece of your code that broke with a glibc update? The kernel devs break the nvidia driver (and many others) with pretty much every release, you must be joking right?

These days, completely clueless users seem to have very strong opinions on subjects that they have zero understanding of (like systemd and now glibc). Just curious, do you also walk into car factories or chemistry labs and tell them how to do their jobs?

In any case, API's change that's just the way it is. If a distribution wants to use a recent glibc, it's their job to patch incompatible software. In no way, shape or form are API changes within glibc BUGS which you claimed.

Yes they are responsible for their own actions. Glibc breaks whatever they want whenever they want and you excuse them for it. That is itself your fault, not mine. Your weak ass argument is based on the premise that it's OK to break other peoples projects just as long as they have a dependency on yours? That's seriously fucking ignorant.

[arokh]

Point out what they broke that they shouldn't have, and why, then your whining might be taken seriously.

[Marc.2377]

Anyone knows which of the "Agner Fog's GLIBC Wishlist" (https://sourceware.org/glibc/wiki/AgnerWishlist) items are still pending implementation?


Context: Ten years ago, Agner Fog wrote in the libc mailing lists (https://sourceware.org/ml/libc-help/.../msg00000.html and https://sourceware.org/ml/libc-help/.../msg00007.html) about how the libc's memory allocation and string functions could be greatly improved by making use of SIMD instructions.

Quote:

Of course the old computers without SSE should still be supported, but the 99% users who have SSE2 or later should not be penalized for the sake of compatibility with old CPUs.