Ubuntu May Become Rolling Release With 14.04

Quoting:If anything, I’ll be excited because it will be that less often that I need to backup my home directory and move it to a new installation.

I really don't see much difference between rolling and non-rolling releases. I have been using Kubuntu for a long time. Disks on multiple machine I use pretty much have simple similar partition structure and mostly consists of root (/), /home, swap, /data. I never had the need to back up my /home directory for the purpose of re-installing the OS since Kubuntu 8.10. I always did update or upgrade. Of course there were a few issues initially that I was able to easily fix, but since 10.04, I haven't had any issues at all.

Can someone state any practical advantages a rolling release has over normal upgrade/update cycle on non-servers? Or Is rolling release an over rated over hyped buzz word?

@fettoosh -

They are different, I think (therefore I am) in that a rolling release doesn't require an upgrade per se, and you don't find yourself in the position where you have to do a big nasty upgrade to get the latest version of something you need.

The difference between a rolling release and what they currently do is a rolling release generally brings upgrades gradually - which in my experience in managing Bodhi makes bugs and issues MUCH easier to track down than having one massive upgrade every 6 months.

~Jeff

Thanks Dino, but still, to me it looks like the updates are going to be done sooner or later. I personally prefer major updates done all together on a test machine first where I can take my time verifying functionality.

Although we are talking about Linux, numerous rolling releases could keep you too busy.

From my perspective a rolling release distro makes bugs much, much harder to track down and fix than a fixed release distro. It makes support about impossible. You don't have one known good starting point. Every system is different. There is a reason all the enterprise distros do fixed releases. They can test against a known package set and get known results. This also makes life way easier for both FOSS developers and commercial ISVs to develop new apps for a given distro. It isn't a constantly moving target.

Rolling release distros are generally unacceptable in the enterprise. They are usually unacceptable for anyone who doesn't like to live on the leading (bleeding) edge. Of course, Ubuntu (other than LTS) is a bleeding edge distro so rolling release does make sense for them.

Put simply: when a distro says rolling release I move on and don't give it a further look. Sorry, Jeff, no disrespect to your work with Bodhi which generally gets good reviews. It's just not for me.

Last week I put Jeff's tablet release on my Nexus 7 and was very impressed. As far as I'm concerned, it's the best gnu/linux available right now for the tablets, and I think I've tried them all. Kudos to Jeff91 and the Bodhi team!

Quoting:From my perspective a rolling release distro makes bugs much, much harder to track down .

@caitlyn,

I agree and my last statement "numerous rolling releases could keep you too busy" was originally "numerous rolling releases could cause many more problems and more often" but changed it the last minute to make it more generic. :-)

@caitlyn -

What's nasty for the enterprise is nice for the workstation.

Ubuntu depends rather heavily on Debian. I don't see any "ditching" happening.

Debian's upgrade system is so good you can go for years without ever having to re-install it. Ubuntu has broken this; you can't count on being able to upgrade to new releases. Sometimes it works, sometimes not. I don't have much confidence they'll be able to manage a rolling release. Mint doesn't do upgrades very well, either, and Clem even recommends re-installation over upgrading. Which is daft. I don't have a preference for rolling release or release cycles, because what I prefer is a distro that works well and doesn't have rinky-dink flaws. Arch, Bohdi, and Debian get my vote as most maintainable and best-constructed distros. Red Hat and SUSE are probably up there too, but I don't have as much experience with them.

I don't see Ubuntu ditching Debian at any point in time. Ubuntu ditching Debian would increase the workload enormously for Canonical. I would envision key user-facing or developer-needed packages as something Canonical would roll in updates to like the newest VLC, Thunderbird, Transmission, etc. I would suspect that many low-profile packages wouldn't be bumped.

Re: Ubuntu and Debian, I still remember when I did my first Debian (then Etch) install during the Ubuntu 7.04 days -- I couldn't believe how alike both distros were on the desktop. Except for Debian running way faster.

I don't see Ubuntu ditching Debian, and I don't see where turning non-LTS releases into a rolling release would necessitate this.

The advantage to a rolling release is, of course, that when you find out about a new useful feature in an application, you don't have to either wait for the next release of your distribution or fiddle with non-repository versions of the program in order to take advantage of them. A relatively imminent update will just include the new version of the software. Of course this is not at all desirable on a server. On a server you want stability above (almost) all.

dino: I don't agree. I've gone to openSUSE on my desktop only because we're a SLES/SLED shop at work. Otherwise I'd be running CentOS. I'm done with bleeding edge. I like stability at home too.

FWIW, openSUSE 12.2 is one release where the SUSE devs got it right. I'd bet it's the basis for the upcoming SLES 12 release. It certainly deserves to be.

If you have the apps you want, CentOS is a great way to go.

It's simple really. A rolling release is immediately up-to-date each and every time you use the update-manager. A rolling distribution can "roll along" for years without requiring re-installation and always contain the latest versions of packages, kernel and libraries. Examples are Gentoo, Arch or Debian Sid. The disadvantage is that updating some packages may break others. A frozen release, such as Ubuntu, receives security and bug-fix packages only, unless custom repositories have been added to provide newer versions of key packages. To upgrade to a newer release on a frozen system, will require the update of nearly all of the installed packages at once, usually once or twice a year which may or may not go smoothly. The advantage is stability, the disadvantages are rocky upgrades and outdated packages.

Quoting:the disadvantages are rocky upgrades and outdated packages.

My workaround is to test before committing and go to the source for the latest.

If a distro doesn't have the apps I want I roll my own rpm package(s). I do it often enough in the course of my work that it's become really easy for me. When I upgrade the distro I usually can just run an rpmbuild --rebuild against the existing srpm and have a new package in a minute or so.

I've heard that doing RPM packaging is much easier than .deb -- any truth to that? I've heard the same about Slackware packaging being easier.

I'd say yes in both cases but it may just be a matter of what you know. What I like about rpms is that everything goes into one spec file: dependency lists, before and after scripts, patches, whatever... It's just one list of things to do in order.