Comment by ragall

3 days ago

Upstream developers declaring a release as "stable" isn't sufficient to make it so. Distros and users are the ones who decide what is stable and what isn't.

I've had more problems in point releases in my last 15years of using Linux. The problem and issues usually happen because of the said holding off of outdated software. If it's desktop computing, Arch (or rolling releases) are the best option. Arch, when it breaks, it's also the easiest to fix. I'll agree with you if it's about server side of things.

I wrote a lil about it all here: https://www.unsungnovelty.org/posts/01/2024/a-linux-distro-r...

Trouble is, there's an enormous gap between when maintainers accept that a package as stable and when it actually makes it into the next release. I'd be plenty happy waiting an extra month or two for a stable release, but am not thrilled with waiting a year or more for one.

  • I used to think that way when I was young and with plenty of free time. Nowadays I want stability more than anything else and I'm fine with software that's 1 year old. The only problem still present is how to buy a new laptop and have everything work from the beginning.

    • Which is exactly why I use Arch. I've has more papercuts from point releases than arch. My argument is not even Arch. But rolling releases.

Arch actually has testing repos (and has had for as long as I can remember), plus other project-specific testing repos like kde-unstable when upstream is taking a very long time to push out a new actually stable release. It also has lts packages for projects that offer those (like the kernel), and sometimes stays on old versions and backports fixes if the upstream definition of stable is too out of whack.

People seem to believe arch is much more yolo than it actually is (though forks of arch have tended to be pretty yolo, and I assume cachyos is a bit yolo as well based on the issues people have).