Comment by WD-42
Arch being unstable is a myth. I’ve had far more issues with major upgrades between versions of Debian, fedora and Ubuntu than I ever had on arch. I think my install is almost 6 years old now.
Arch being unstable is a myth. I’ve had far more issues with major upgrades between versions of Debian, fedora and Ubuntu than I ever had on arch. I think my install is almost 6 years old now.
Same here as well, using arch as daily driver for 10+ years now. I think just twice I've had major headaches due to package/kernel upgrades which required a few hours troubleshooting. Otherwise, smooth sailing and a pleasure to work with. Love the AUR (w/ pikaur)!
> Love the AUR (w/ pikaur)!
Never heard about pikaur before (Rua gang here), but judging by the screenshots, does it not allow you to review the PKGBUILD before building the package? Seems to me like the most basic feature a AUR helper has to have, since AUR is all user-contributed without reviews. Is pikaur really letting you install packages blindly like that?
> Arch being unstable is a myth.
Arch follows a rolling release model. It's inherently unstable, by design.
You are probably using some annoying pedantic definition of unstable. Most people mean it to mean “does stuff crash or break”. Packages hang out in arch testing repos for a long time. In fact, Fedora often gets the latest GNOME release before Arch does, sometimes by months.
> You are probably using some annoying pedantic definition of unstable. Most people mean it to mean “does stuff crash or break”.
English has a specific word for that: reliable.
Pedantry aside, having a complex system filled with hundreds (thousands?) of software packages whose versions are constantly changing, and whose updates may have breaking changes and/or regressions, is a quick way of ending up with software that crashes or breaks through no fault of the user (save for the decision to use a rolling release distro).
This isn't true in practice. It turns out incrementally updating with small changes is more stable in the long run than doing a large amount of significant upgrades all at once.
Have you ever had to maintain a software project with many dependencies? If you have, then surely you have had the experience where picking up the project after a long period of inactivity makes updating dependencies much harder. Whereas an actively maintained or developed project, where dependencies are updated regularly, is much easier. You know what is changing and what is probably responsible if something breaks, etc. And it's much easier to revert.
> Have you ever had to maintain a software project with many dependencies? If you have, then surely you have had the experience where picking up the project after a long period of inactivity makes updating dependencies much harder. Whereas an actively maintained or developed project, where dependencies are updated regularly, is much easier. You know what is changing and what is probably responsible if something breaks, etc. And it's much easier to revert.
Have you ever had situations where Foo has an urgent security or reliability update that you can't apply, because Bar only works with an earlier version of Foo, and updating or replacing Bar involves a significant amount of work because of breaking changes?
I won't deny that there's value in having the latest versions of software applications, especially for things like GPU drivers or compatibility layers like Proton where updates frequently have major performance or compatibility improvements.
But there's also value in having a stable base of software that you can depend on to be there when you wake up in the morning, and that has a dependable update schedule that you can plan around.
Same. My first Linux was Ubuntu 9.x, every time I upgraded the major version something broke. Eventually ignored the "Arch is unstable" as I saw my co-workers having zero issues, and been using Arch since 2017 now with zero breakages that I myself wasn't responsible for.