4 ms·

I had three breaking issues in a year and a half using Arch. By breaking - I mean some piece of software I rely on quit working reliably after an update. These

I had three breaking issues in a year and a half using Arch. By breaking - I mean some piece of software I rely on quit working reliably after an update. These were all upstream bugs - not Arch's fault (KDE in two cases, Erlang/OTP in the other), but Ubuntu and RHEL never saw these versions of software hit their repositories because the problems were found (in at least one case by Arch and Gentoo users) and fixed in upstream long before they made it through the long release and testing cycles. The nice thing about Arch, its absolutely trivial to rollback a package, or even rollback all your packages to the ones published on any given date. So I was able to deal with all of these issues quite effectively which is a credit to Arch, but it simply is the case that you will see more breakage on the leading edge.

laumars 9y ago
> I had three breaking issues in a year and a half using Arch. By breaking - I mean some piece of software I rely on quit working reliably after an update. These were all upstream bugs - not Arch's fault (KDE in two cases, Erlang/OTP in the other), but Ubuntu and RHEL never saw these versions of software hit their repositories because the problems were found (in at least one case by Arch and Gentoo users) and fixed in upstream long before they made it through the long release and testing cycles. What you're describing there is bleeding edge; not rolling release. If you ran a Ubuntu with the testing repos then you'd have experienced the same issues. > The nice thing about Arch, its absolutely trivial to rollback a package, or even rollback all your packages to the ones published on any given date. So I was able to deal with all of these issues quite effectively which is a credit to Arch, but it simply is the case that you will see more breakage on the [bleeding] edge. Indeed you will on bleeding edge. That was my point. Most of the complaints people attribute to rolling release are actually problems with bleeding edge distros rather than rolling release. You've downvoted me only to reiterate the same point.
- jeremyjh 9y ago
  I see your point now, but is there a rolling release distribution that isn't bleeding edge? I think that's the reason for the confusion. All the rolling release distributions are closing tracking their upstreams. Indeed, without a release cycle, what exactly would they be waiting for?
  - laumars 9y ago
    > I see your point now, but is there a rolling release distribution that isn't bleeding edge? I'd covered that in my first post as well (did you even read it? :P) > without a release cycle, what exactly would they be waiting for? Rolling release distros still have release cycles. eg they often have testing repos where many packages will be trialled before they hit the main repositories. Much like you see happen with packages which get updated between major releases on non-rolling release distros. The difference between rolling release and non-rolling release is a bit less pronounced these days because even most non-rolling release distros now have easy upgrade paths from one major release version to the next. Heck with the Debian / Ubuntu derived distros you can just update your apt config to point to the next release repos and apt will carry on as if you're a rolling release distro. So I think the real difference between rolling release and non-rolling is simply just that you're given greater assurances[1] that you don't need to perform manual intervention during package upgrades outside of the major version upgrades where as with rolling release the risk of manual intervention can come without warning[2] In terms of package stability, there's nothing stopping someone creating an Arch fork which runs packages a few months behind the main Arch repos. In fact I think that might have been the concept behind Arch Server - not that it ever took off. So anyway, back to my original point: rolling release doesn't have to mean "unstable". It just means breaking changes don't all get held back until major milestones are reached. But that's often true for non-rolling release as well. It just so happens that most rolling release distros are also bleeding edge - and that is where the trope come from. So saying rolling release can only be unstable is akin to saying Redhat can only be bleeding edge if you only ever use Fedora. [1] I was going to say "guaranteed" but that's not quite true either; eg FreeBSD will happily perform breaking changes to applications (within a major release version) if you're not careful what application versions are being installed [2] This is also not quite true but many distros will warn you about breaking changes in their news feed. But also the package manager itself gives strong clues too (eg Apache 2.2.x -> 2.4.x will obviously result in manually updating some Apache config files).

laumars 9y ago

> I had three breaking issues in a year and a half using Arch. By breaking - I mean some piece of software I rely on quit working reliably after an update. These were all upstream bugs - not Arch's fault (KDE in two cases, Erlang/OTP in the other), but Ubuntu and RHEL never saw these versions of software hit their repositories because the problems were found (in at least one case by Arch and Gentoo users) and fixed in upstream long before they made it through the long release and testing cycles. What you're describing there is bleeding edge; not rolling release. If you ran a Ubuntu with the testing repos then you'd have experienced the same issues. > The nice thing about Arch, its absolutely trivial to rollback a package, or even rollback all your packages to the ones published on any given date. So I was able to deal with all of these issues quite effectively which is a credit to Arch, but it simply is the case that you will see more breakage on the [bleeding] edge. Indeed you will on bleeding edge. That was my point. Most of the complaints people attribute to rolling release are actually problems with bleeding edge distros rather than rolling release. You've downvoted me only to reiterate the same point.

jeremyjh 9y ago
I see your point now, but is there a rolling release distribution that isn't bleeding edge? I think that's the reason for the confusion. All the rolling release distributions are closing tracking their upstreams. Indeed, without a release cycle, what exactly would they be waiting for?
- laumars 9y ago
  > I see your point now, but is there a rolling release distribution that isn't bleeding edge? I'd covered that in my first post as well (did you even read it? :P) > without a release cycle, what exactly would they be waiting for? Rolling release distros still have release cycles. eg they often have testing repos where many packages will be trialled before they hit the main repositories. Much like you see happen with packages which get updated between major releases on non-rolling release distros. The difference between rolling release and non-rolling release is a bit less pronounced these days because even most non-rolling release distros now have easy upgrade paths from one major release version to the next. Heck with the Debian / Ubuntu derived distros you can just update your apt config to point to the next release repos and apt will carry on as if you're a rolling release distro. So I think the real difference between rolling release and non-rolling is simply just that you're given greater assurances[1] that you don't need to perform manual intervention during package upgrades outside of the major version upgrades where as with rolling release the risk of manual intervention can come without warning[2] In terms of package stability, there's nothing stopping someone creating an Arch fork which runs packages a few months behind the main Arch repos. In fact I think that might have been the concept behind Arch Server - not that it ever took off. So anyway, back to my original point: rolling release doesn't have to mean "unstable". It just means breaking changes don't all get held back until major milestones are reached. But that's often true for non-rolling release as well. It just so happens that most rolling release distros are also bleeding edge - and that is where the trope come from. So saying rolling release can only be unstable is akin to saying Redhat can only be bleeding edge if you only ever use Fedora. [1] I was going to say "guaranteed" but that's not quite true either; eg FreeBSD will happily perform breaking changes to applications (within a major release version) if you're not careful what application versions are being installed [2] This is also not quite true but many distros will warn you about breaking changes in their news feed. But also the package manager itself gives strong clues too (eg Apache 2.2.x -> 2.4.x will obviously result in manually updating some Apache config files).