> Having very frequent updates to bleeding edge software versions, often requiring manual intervention is not "stable". An arch upgrade may, without warning, replace your config files and update software to versions incompatible with the previous.

12 in the last year if you used all the software (I don’t many people are running dovecot and zabbix), so probably actually like 3 for most users: https://archlinux.org/

That’s not too dissimilar from what you’d get running stable releases of Ubuntu or Windows. And of course plenty of windows software will auto upgrade itself in potentially undesired ways, windows users just don’t blame the OS for that

> Having very frequent updates to bleeding edge software versions, often requiring manual intervention is not "stable".

I dunno. I have an arch installation that is maybe 4 years old, I might update every few weeks, and have only had one issue.

Any issues are usually on the front page of archlinux.org what the issue is, and how to fix it.

> without warning, replace your config files and update software to versions incompatible with the previous.

This is just nonsense, pacman doesn't do this. If you'd modified a config file, it will create a .pacnew version instead of replacing it. Otherwise you'll get the default config synced with the version of the software you've installed, which is desirable.

It's pretty rare to modify any config files outside of ~/.config these days anyway. What few modifications I have at the system level are for things like mkinitcpio, locale, etc and they never change.

It's the same train of thought as the modern cloud software notion that deploying small changes more often is safer than bundling "releases"; if you upgrade 3 packages 3x a week (or deploy 50 lines of code 3x a week), you catch small issues quickly and resolve them immediately, rather than upgrading 400 packages 1x a year (or deploying 50,000 lines of code 2x a year), where when things break you have a rather tall order just to triage what failed.

I think there are advantages to both, but I will say that I've found modern Arch to be quite good. The other huge benefit of Arch is the general skill level present in the user base and openness of the forums; when something breaks it's usually easy to google "arch + package name broken" and immediately find a forum thread with a real fix.

I don't think I'd use Arch for a corporate production server for change management reasons alone, but for a home desktop and my home server, it's actually the distribution that's required me to do the _least_ "Linux crap" to keep it going.

It’s stable in the way that a person taking small predictable steps at a time is stable compared to somebody who making large random lurching steps. Sure, the system is often changed, but if only a few packages have changed, should there be a problem it is easy to identify the culprit.

Although it is hard to say. Ubuntu also has, I guess, intentional behavior that is hard to distinguish from a bug, like packages switching from apt to snap. So it might just be that my subjective experience feels more buggy.

I think op meant the subjective feeling of having a system that runs in a stable manner. I don't quite follow their reasoning either (maybe the smaller changesets expose compatibility bugs before affecting general ux?), but I agree that arch was a joy for me to use and felt "stable".

It really is nothing new. People quickly close windows with errors, they go out of they way to avoid reading actual message.

That's what they said about GenX, Millennials, and probably every other generation before them. Something something, "OK boomer."