More at Linux Voice...

What do LQ members think; are rolling releases the future of distros?

--jeremy

I really don't think so. When there are MAJOR version upgrades, it's just tooo difficult to go from 1 version to the next without issues every time. There's a reason why rolling distro's have so many "my xxxx broke after upgrading" threads here. Yes, they're great. They can be used without incident if you watch closely what's being upgraded, check the upgrade warnings, etc etc etc. But for a production enterprise environment, it would require a MAJOR shift in how "rolling" distro's work to have them adopted. And I just don't see companies demanding it, or the major players in the Enterprise wanting to dedicate the manpower to making a rolling distro stable enough for enterprise usage.

I think it is major misconception that rolling release has to equal mostly untested bleeding edge software and breakages. If done right (with multiple branches for production, testing, development, ...) rolling release can be very stable and suitable for production use. I personally think that a mix of (well tested, as described above) rolling release base distro with container-based application deployment is what we will see more and more in the future.

I used to think rolling release distros were too unstable. Well, after using PCLinuxOS, I say they are not.
In fact, if Ubuntu was not under a lot of change right now, I'd recommend them to have an LTS stable version, and one rolling release. No more 6 months' versions.

Agree.

I haven't seen any evidence that a rolling release couldn't be stable enough for most uses -- that is to say it's simply not possible for things like kernel upgrades to not break somebody's hardware somewhere but with typical modern lifecycles I think rolling releases could work well for most applications.
It is possible to run Debian Sid for a few years without major incident if one is careful so if the care were taken by the people rolling out the distribution and not the people running it I see no reason it couldn't work.
The Ubuntu idea proposed above I agree with completely -- perhaps that's the model? Stable LTS releases for those who need fixed libraries and the like and rolling releases with more testing than happens currently for the rest? It certainly sounds sensible to me.

As an Arch user, I'm used to my distro being at the center of this debate almost by default. I can tell you, in 4 years, I've had one manual intervention. What usually happens is people install stuff from our Arch User Repository, (packages that are not quite popular to be in the stock repos) The "AUR" is not really a repo, rather a database of recipes for building these packages automatically from scratch. Often (almost always) these packages rely on dependencies that ARE in the stock repos. So, if a dependency undergoes a major change and the package "recipe" isn't updated to reflect such, the program built from the AUR will not work anymore. This is usually fixed easily by re building the AUR package, or in rare cases, downgrading the dependency. This is a mildly unfortunate consequence to a system that offers more access to more packages than any other distro out there. The AUR is in fact dramatically larger than all the stock repos put together. Also, our updates trickle down to us as the package is quickly tested, and passed on, rather than compiling a list of updated packages, then releasing them on a weekly basis. You have to take the good with the bad on that one.

I do agree the rolling model as it exists is not perhaps the best option for an enterprise environment where most of the users will presumably not be as knowledgeable about Linux as those who are more likely to chose a rolling release at home. In this case, I think there should be options for more solidity in the system as a whole. Arch already offers an LTS kernel as an option, though to install this, you have to know how to re-generate init images and such. I think this needs to go one step further if a rolling release like Arch would be a viable option in the Enterprise market. I believe there needs to be a third set of stock repos, I would call them the "solid" repos. These packages would be installed on top of the LTS kernel, and offer the benefit of a longer (much longer, perhaps) testing period.

I have no doubt we're a long way from seeing anything like that from a distro like Arch, given it's strict adherence to it's "KISS" policy, and the elitist rhetoric of it's community, but I do believe if cooler heads prevail, it would beneficial to all.

Personally, I prefer "major releases," which I may or may-not upgrade to and if so "at my leisure." For example, at this moment I'm writing this on OS/X Mavericks, and I will soon be upgrading to Yosemite, leaving El Capitan alone for at least another six months. I still get periodic security-updates and so forth for Mavericks. (My friends still get them for Mountain Lion.) But I don't run the risk of being on the bleeding-edge that I know still exists, even with Apple. And, it is not a complicated process, as dealing with "branches" and so-forth would be.

I want distributors to put their effort into perfecting major releases, and updating several of those releases to some extent and in parallel. I will move-forward, in major steps, at moments of my choosing.

You may have misunderstood what I wanted to say. The user does not have to deal with branches, he just runs the stable branch and is done with it. Different branches in a distribution is something that developers and those that want to help development by testing have to deal with. Look at Gentoo or Arch for example, both have a stable and a testing/development branch. If you don't want to help with testing/development just stick to the stable branch and be good with it.

Indeed, Debian Sid is almost a rolling release already in practice also. Isn't Slackware Current a similar thing too?
All Ubuntu would have to do, for example, is carry on releasing LTS releases as they are and track Debian Testing more directly meaning that sources.list wouldn't have to be changed every six months for those not running LTS releases. I don't actually understand why they release non-LTS point releases as surely anybody wanting a stable release doesn't use them as they won't want to (effecively) reinstall their OS every 6 months?
Fedora seems a bit odd in this regard -- won't anybody running Fedora long-term have to keep using Fedup every time there's a new version released?

It is even harder to understand when you realize that in those interim releases they don't really care for severe bugs and release anyways. For example, they knew well ahead before the release of 15.10 that there are major problems with the AMD drivers (both proprietary and open source), but didn't bother with it and released anyways.

Windows 10 seems to be trying to adopt a rolling release model, with major updates (formerly know "service packs") their newly expected to-be-tolerated speed bumps. Microsoft is forcing their non-Enterprise Windows version users to adapt to this model. There is a huge hue and cry among gamers and power users about this high-handed "forced upgrading."

I view Windows 10 Home similarly to Tumbleweed, and Windows 10 Enterprise to Leap. Like it or not the barons of Red Hat, Novel, and Canonical track what the overlords in Redmond are doing and experiment with similar ideas while trying to innovate.

Rolling releases are not just for the cognescenti. While I use Arch - not quite without problem, in the early stages I didn't know about the -c option to pacman and filled up my root partition :-) - I have a couple of non-technical friends who are happily using Manjaro (an Arch derivative) and finding everything about it easier than Windows, including running their updates.

I pity any poor soul stuck with Windows updating. A few months back another friend was running Windows updates on a newly acquired (second hand) laptop - some 400 odd Megabytes of download. When it showed 94% complete I started a 147Mb download for my Arch updates. Windows had reached 97% by the time mine had downloaded, been checked, verified and installed.

A well produced system like Arch makes a great basis for a rolling release, and isn't anything to fear.

I think Arch is a successful rolling release distro. I also think it's the exception that proves the rule.

Slackware-current and Debian Testing don't count because they're intended as release candidates for the versioned releases.

I am very much in favor of rolling releases. Whether or not rolling releases are the wave of the future, I couldn't tell you. I use Debian and a few years back Debian had a debate about whether or not to create rolling releases and they decided not to created a rolling release. However Debian has made it easy to upgrade from one release to another by allowing upgrades by changing your repository links. Changing repository links has changed Debian release upgrades from being a major nuisance to being a minor nuisance. I still think that Debian should go one step further and create a rolling release.

--------------------
Steve Stites