Glibc 2.27 Is Being Released Soon With Numerous Performance Optimizations

[phoronix]

Phoronix: Glibc 2.27 Is Being Released Soon With Numerous Performance Optimizations

Glibc 2.27 will be released as soon as next week as the latest half-year update to the GNU C Library...

http://www.phoronix.com/scan.php?page=news_item&px=Glibc-2.27-Release-Imminent

[dungeon]

You forgot to say



Only 2.x release in 30 years, in comparison to 64 for Chrome in 10 years

[FishPls]

Ideally Ubuntu 18.04 would pick this up.

[PLum]

Ideally Ubuntu 18.04 would pick this up.

lets hope so

[FireBurn]

The reason distros don't ship new versions of Glibc sooner is they tend to be buggy. Glibc 2.26 took ages to be unmasked in Gentoo's portage because it broke a whole load of packages. You might criticise Chrome for going through 64 versions in 10 years, but I'd rather see more point or patch releases from Glibc rather than a dump of code every 6 months with distros backporting fixes.

[arokh]

New versions of glibc requiring source changes does not equal "buggy". Arch had glibc 2.26 like two weeks after release. Sounds to me like Gentoo does not have the manforce to fix the available packages.

[geearf]

New versions of glibc requiring source changes does not equal "buggy". Arch had glibc 2.26 like two weeks after release. Sounds to me like Gentoo does not have the manforce to fix the available packages.

And for a while many games failed to run without some form of workaround.

[Guest]

New versions of glibc requiring source changes does not equal "buggy". Arch had glibc 2.26 like two weeks after release. Sounds to me like Gentoo does not have the manforce to fix the available packages.

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.

[dungeon]

The reason distros don't ship new versions of Glibc sooner is they tend to be buggy. Glibc 2.26 took ages to be unmasked in Gentoo's portage because it broke a whole load of packages. You might criticise Chrome for going through 64 versions in 10 years, but I'd rather see more point or patch releases from Glibc rather than a dump of code every 6 months with distros backporting fixes.

Well it require a lot of time and testing i agree, releases are usually not perfect even when they are but require month or two PITA on switching minimum for distros.

Yeah and that month or two on 64bit x86. Otherwise if distro (and if it is binary one) support 10+ architectures then it probably require an year or two of testing It is far from ideal, depending on POV, but that is what it is since it is so core library some shits are expected on any move there.

[duby229]

New versions of glibc requiring source changes does not equal "buggy". Arch had glibc 2.26 like two weeks after release. Sounds to me like Gentoo does not have the manforce to fix the available packages.

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.