A rolling release Distro....
 

I am quite frankly, i ve had enough of the 6 month release cycle of most of the distros....
Every 6 months, download an ISO burn it... then installation.... reconfiguring everything...

I would really like to install things once n then keep updating when ever necessary, rather than doing a "new" install every 6 months... a rolling distro i suppose....

Thats when i came to know about Arch, Gentoo n slackware... are there any other rolling distros??

Reading about the above rolling distros, makes me ask what really is the difference between distros.... everything runs the linux kernel n just different combination of packages n the package manager?? Can somebody kindly elaborate on the general differences between distros or of course provide me a few links???

I would also like to know the advantages/disadvantages of 6 month releases over a rolling release....

I realize that similar question has been asked before.... i have read through most of it.... however it was so spread out... i found more contradictions than an answer.... so guys plz help me....

thanks in advance....

All distros have a freeze and a release. It makes it easier for users to get the most up to date full version and then apply minimal patches to update it. Although Gentoo and Slack, etc release less often and work on stability and updates in between, they do release! You could give Debian (or derivatives) a go - although they release often, you can do a full distribution upgrade while on line and without grabbing a DVD.

I suggest you to take a look at sidux too. It's just a Debian Sid (a.k.a. the UNstable branch) system plus adjustments to make it more stable. --> http://sidux.com/
Debian stable uses dated software so it can be a concern.
If 'm not wrong SourceMage Linux is a rolling distro too...

And Slack isn't rolling.

Slackware-current is.
Just like Debian has testing and unstable.
Otherwise the only rolling release distributions are Gentoo and Arch which dont have stable branches, and some other small ones.

Yes. But it is intended as a mean to test, develop, the next stable realease and not to be used normally (OK, you could use it, but if Slackware or other distros in stable version aren't warranted, imagine a testing release). There was a time I installed Debian Stable and changed the repositories to unstable and upgraded, worked nice, but GNOME started to hang. lol

Otherwise, arch, gentoo, sidux, are intended to be used that way and have a lot of people using it, a strong community, so it has somewhat good warranty and support. Concisely, you are not alone.

---------------------------------------

TO THE POST AUTHOR and others too :^): I strongly recommend Sabayon Linux! It's based on Gentoo but adds a binary package system and install a nice desktop out of the box with nvdia or ati working. And you can continue to use portage and the USE flags.

There are at least two separate issues here:

• re-install/support heartbeat is too short
• when a new release comes along, you need to reinstall, rather than just update

The first issue can be solved (well, ameliorated, actually) by choosing an enterprise/server/lts product that has a slow release cycle and/or a long support horizon.

The second issue is addressed by the 'rolling release' approach, but be aware that it is not totally without potential disadvantages.

• what happens when a service is replaced by either an incompatible version of the same program or a different program altogether?
• (maybe this should never happen) but what about the cruft that can gradually build up and get cleared out by a good re-install every so often?

(I'm not suggesting that 'rolling release' is bad, just that there are downsides as well, and you should just be sure that you aren't trading problems that you know and don't like for problems that you don't know and will come, eventually, to hate.)

So, what should happen when, eg, Squid 3 replaces 2.x? Some of the config directives in 2.x break 3, so should your old config file be used? (No). But what about all of the other stuff that you have customised that is still good? Well, you can argue that you have this problem with the discrete release process too, but you have in a more formalised way and you are, to an extent, expecting it and your process should be built around it.

What happens when the distro's 'preference' changes from network manager to wicd? Should it totally wipe out your working NM in order to bring you up in to line? Should it ignore that you have a buggy NM? What about security fixes to NM, once it is no longer he distro's preferred package? And has anybody tested the combination of the old package combined with the new kernel (or whatever) or are you the only one?

There can be a large number of little issues like this, and while you'd like to be able to take an intelligent approach to each one, how is that going to happen, short of making the update process rather painful?

Well, you can 'kind of' turn a rolling release approach into a more conventional one by only making updates (...apart from vital security updates, obviously...) at pre-set periods, like six months, but then the only gain that you have over a conventional six month release is that it might save you some bandwidth, but then, whatever formal testing the distro does, it may well not do on your exact combination of software versions, which may or may not be critical for you. (Hey, maybe you only trust your own testing anyway, so you know you are always at the front line of testin, but surely it would be nice to know that what you are trying is supposed to work.)

For many applications -anything like a server, for example- 6 months is too short, plain and simple. Something with a 'conservative' approach to both cycles and support (debian, slackware, centos and the enterprise distros...), is better than something intended for ordinary end users, no question about that, but that is nowhere near the same as saying that the answer must be rolling release.

(...but 6 months for a server is, in part, too short because of all of the testing that you have to do before you decide that the server is correctly configured and production ready...it is not clear that slicing and dicing the updates into a larger number of smaller increments is a big help. Well, unless you believe that salami-slicing it somehow obviates the need for the testing that you would normally do. This seems a belief that is difficult to justify when expressed clearly even though it may be an unconscious one.)

OTOH, if you are an end user and you want the latest, greatest, glitziest, debian's slow cycles can be a bit of a pain, unless you go for the less well tested versions and do lots of incremental upgrades. If you think that and you have the net bandwidth and you are prepared for the trade-off between being a tinkerer and having a known-good stable system, rolling release may be for you.

And now a question for you: If you take a discrete release version with a long support horizon and frequently use the package management facilities to keep things up to date, is that really that different from a rolling release?

So what i gather from the responses is that a rolling release is unstable compared to a conventional 6 month release....

I cant resist arguing that the discrete release also faces this problem.... Rather a discrete release usually updates (jumps) software from one major version to another major version. So there could me major configuration changes when the new release is installed....
Where as doesnt the rolling system update thwe software by sub versions.... making the upgrade process gradual n actually easy to handle???

To use the same example, updating to squid3 from squid 2 would be more difficult rather than from say 2.9 to 3??? (Please note that this is just an example and does not have anythin to do with actual versions) There would be larger number of changes in first case as compared to the second case.... IMHO

I suppose it becomes the next release.....

Its funny...... I used to re install windows every six months..... simply because it crashed (i had no choice). Now in Linux, i am doing the same thing, the difference is, now i have the choice.....

(sorry that I didn't reply earlier, but I've been away for a while and I'm just catching up)

Yes, that is true, but it is more-or-less obvious what to do about it. You install the new default, having presumably manually done something to save a copy of your working customised copy.

Major updates in software occur at the rate at which they occur; the distro can be slow in adopting these, but that delay doesn't change the overall rate. So you'll get the same rate of major updates, whichever approach that you use, short of just saying "we'll ignore, eg, squid3" which would only be an approach that you could use for special cases.

The reason that I chose squid 3 for this example is that there are some incompatible config directives in a squid 2.6 config file, and attempting to use that would usually break squid 3.

I think that you can argue that anything that includes config directives that break the software really ought to be held over for major updates, whatever that means in the version numbering system for your app.

So, in principle, and assuming that squid defines a 0.1 upgrade as minor, upgrading from squid 2.x to 3.0 is allowed to be much more difficult than any upgrade from 2.4 to a later 2.x series. I'm not sure that it is clear whether an upgrade from 2.9 (which didn't exist?) to 3.0 is bound to be easier than an upgrade from an earlier 2.x series version, but I am not sure that this is relevant to this argument. At some point the 'big bang' comes around and you have to have a policy to deal with it.

On the desktop, I was, at one stage, using SuSE, but only alternate releases. Today, on the desktop, I am using SuSE and updating KDE between formal releases -roughly, monthly when the new KDE version becomes available (but that is because KDE isn't really in a good state yet...I wouldn't be doing that normally). That is getting old rather quickly.

For servers, I really need to find something that has a longer supportability horizon while still being something that I am comfortable with, but there, six monthly 'big bang' cycles are just not tolerable, if you value your sanity. Although what that has to with me... :rolleyes:

I like the Arch method (rolling release), but there is at least one downside: You do not have any easy choice to keep the older version of a particular program or utility. I would like to have the option to install the latest of everything, but also to have an easy way to revert to the older version of something.

Well there is this and this.

@ firewiz87
May I also add Foresight Linux, Sidux [or debian sid], fedora [scheduled rolling release],lunar and zenwalk-snapshot to the list? :)

Good info---thanks. I periodically hover on the edge of standardizing everything with Arch, but there is always some little thing that stops me.

Sorry for the late reply... i have been away for a while...

being a great fan of KDE and a user of SUSE, i know exactly what you mean....

In the present scenario... i am like burning DVDs every 6 months for a distro upgrade...

Wow... i just love choices... i ll check em out...By the way, is fedora actually a rolling release?? I thought it was a discrete release...

You seem to have good experience with gentoo and Arch... which would be better for a beginner???

Fedora has a six months release cycle, mostly during June-Nov each year. F12 just came out. However, they also call it "scheduled" rolling-release since technically you can upgrade after every 6months without reinstalling. Although ubuntu has also tried to implement this dist-upgrade feature since karmic, but most users have suffered due to this.
Funny coz someone from this forum asked me this exact question yesterday. Here's my opinion. Don't want to start a flamewar here.

Also I would like to add:
Slackware-current is actually a rolling release and far more stable than most rolling release distros out there. It's not as bleeding edge as Arch or Gentoo but eventually things get upgraded.

Regards

Thanks for explaining the fedora thing....

Flame war about the question was just too much... infact your blog was the only one i found without 3 pages of flame wars... usually contradicting each other... I am pretty much at the same conclusion as you are...

I considered slackware too... but came to know that it does not have a dependency manager...

PS: Nice blog by the way...

Well in LQ forum flamewars are not common. We are a big, happy Linux family. Doesn't matter which distro you use. But still to be safe, since there were countless flamewars in Arch and Gentoo forums on this topic.

No sadly that's something slackware doesn't provide and slackers like it that way.

Thank you. :)