Arch Linux Finally Rolling Out Glibc 2.27

[schmidtbag]

I expected to read what took them so long Debian Sid rolled it 40 days ago.

Unlike Debian Sid, Arch is actually pretty reliable. I have never had a Sid install that survived more than 2 years without major breakages, meanwhile I've had Arch setups that survived 4+ years just fine.

I'm not necessarily faulting sid here, but the point of that repo is to offer the latest release regardless of whether it actually works or should be used. Arch's devs have sometimes done same-day updates for new releases, sometimes they hold things back for over a month. For being a cutting-edge rolling release distro, they're pretty damn good at making things stable, or at least they make it relatively easy to recover from problems. Sometimes I tried a few packages in Arch's testing repo (which is basically the same idea as Debian Sid), where I was waiting for a package to be released that other distros already have. More often than not, I've regretted using the testing repo. If I were using Sid in these situations, I'd have a much harder time reverting the changes.

[chuckula]

Even though Arch has bad rep in some circles (underservedly so, imho), it aims (and succeeds at that most of the time) to be a solid, reliable, working system. It's not an unstable version for testing what may become a release in the future.

Remember who Sid is named after.

Arch tends to test things to at least make sure theybat least can give the users orientation on migration procedures. Not like what unstable does.

Having used Arch for a long time, shit most definitely does break. They do a decent job of trying to clean it up but sometimes when a bug gets introduced into an upstream package they will merrily pass the bug along to you and make it difficult to use the most recently working version of the package. The problem with the rolling release philosophy is that there's minimal regression testing going on to protect you from bad things that happen in the shiny newer versions of many projects. Glibc is probably an exception because it's so fundamental that a showstopper bug will crash everybody's system as opposed to more isolated regressions that don't affect everybody.

[dungeon]

Unlike Debian Sid, Arch is actually pretty reliable. I have never had a Sid install that survived more than 2 years without major breakages, meanwhile I've had Arch setups that survived 4+ years just fine.

I have 11 years old Sid install, but i don't use it nor update it so often - it still works fine... maybe that depends on luck

Joke aside, it is never luck. User needs to know how to manage breakages on any rolling distro, otherwise if you are not capable it is the best to not use it

I never recommend rolling distros, if someone asks me "should i use Sid?" i say No. If you don't ask me, then Yes

[tildearrow]

Typos:

potential snag die tp Glibc having dropped NIS/NIS+ support.

[jrch2k8]

Having used Arch for a long time, shit most definitely does break. They do a decent job of trying to clean it up but sometimes when a bug gets introduced into an upstream package they will merrily pass the bug along to you and make it difficult to use the most recently working version of the package. The problem with the rolling release philosophy is that there's minimal regression testing going on to protect you from bad things that happen in the shiny newer versions of many projects. Glibc is probably an exception because it's so fundamental that a showstopper bug will crash everybody's system as opposed to more isolated regressions that don't affect everybody.

I agree Arch does break some package every once in a long while(last time it happened to me probably was in 2012/3 when the bus changes were done and I didn't read the disclosures) but overall I can assert I had through the years way more problems with Ubuntu and Centos/RHEL totally breaking on me than I had with Arch.

Also I believe the combo Pacman/AUR is way more flexible for power users than yum or deb tools are and maybe this has made the difference for me through the years over the non conventional uses I have.

In resume, I trust Arch devs enough to wait calmly to glibc hit stable because if is not ready yet for them is not for me.

Disclosure:

I mean by non conventional uses, stuff like 0 day security patching of production software, custom compiled/optimized base packages, etc.

[geearf]

In resume, I trust Arch devs enough to wait calmly to glibc hit stable because if is not ready yet for them is not for me.

The problem is testing is just a vetoing pass.
If a package is in testing for a certain amount of time (I forgot how long) without a bug, it goes to stable, but that does not mean it's bug free.
That's why packages with very few users may move to stable with glaring issues that no one noticed because no one used it in testing.

As long as this is user-based, we need many more users getting testing packages if stable is to be somewhat stable.

[-MacNuke-]

but sometimes when a bug gets introduced into an upstream package they will merrily pass the bug along to you

They also give you many many bugfixes pretty fast. I also think it is not ArchLinux's fault when upstream says "this shit here is stable". Debian (and every other LTS-Distribution) leaves you alone with bugs when the fix is only applied to a new feature version that Debian blocks because it is not security related.

[schmidtbag]

I have 11 years old Sid install, but i don't use it nor update it so often - it still works fine... maybe that depends on luck

What's the point of using sid if you don't update often? Also, if this is some basic system where you're not doing anything special with it (like a media center) then yeah, of course it'll last for years.

Joke aside, it is never luck. User needs to know how to manage breakages on any rolling distro, otherwise it is the best to not use it

I agree, but the big difference here is Debian-based distros are notoriously difficult to fix breakages. If something breaks, it's a serious headache, relative to how another distro (like Arch) would handle it. This is usually because the package manager is trying to prevent the user from digging themselves into a deeper hole, but sometimes the user actually knows what they need to do while the package manager is holding them back. The irony here is sometimes you can just run "apt-get upgrade", blindly agree to the changes, and find dozens of your programs have been un-installed, or your system no longer boots beyond the command line. For something that seems to prioritize idiot-proofing, this is a starkly common user-unfriendly situation. That being said, I tend to use Debian Testing (the computer I'm writing on this is using that), since it's relatively new and isn't very prone to trash my whole setup.

[dungeon]

What's the point of using sid if you don't update often?

I meant _recently_ i don't use so nor updated it, that is temporarely... of course when i use it i update it non stop of course

Also, if this is some basic system where you're not doing anything special with it (like a media center) then yeah, of course it'll last for years.

For more than decade Of course it is base system and a bit on top Never full blown DE, just plain openbox sits there and apps around, what else?

It is mini really, for Desktop i have loaded there just - openbox, fbpanel and spacefm. That is fully functional clickete for me

[Scimmia]

I expected to read what took them so long Debian Sid rolled it 40 days ago.

People who pay attention to Arch already knew what the delay was.

https://lists.archlinux.org/pipermail/arch-dev-public/2018-February/029151.html

https://lists.archlinux.org/pipermail/arch-dev-public/2018-April/029219.html