Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: