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

Since my last reply to this thread, I have now standardized everything on Arch. Currently running with KDE 4.3.3.

So far, everything is stable, and things are as good or better than any other distro I have used.

What brought me to Arch (several years ago) was simplicity, plus--hands down--the best package management scheme on the planet. The only downside is that it takes some patience to slog through setting everything up. (Arch starts with **nothing**, and you have to install all manner of things that would be built in on other distros.)

I dropped Arch's KDE after openSUSE 11.2 came out. Now using Arch with xmonad. very fast and stable indeed.

Never heard of xmonad, but ran pacman -Sl and there it is!!

What's the connection between OpenSUSE 11.2 and dropping KDE?

i have stayed away from gentoo for the very reason posted in that blog. It seems unnecessary on modern hardware. modern hardware. I also agree that arch's pacman is the best package management. rivaled by FreeBSD, of course. this is LinuxQuestions, though, right? not that any distros package management is really "that" different. for some reason I get a different feeling of watching pacman work. maybe it is the different configurations one can use. I am writing this from within sidux, though. i do like sidux a lot. very easy to use, I guess. and gives me a little more confidence of stability than just straight sid. for rolling releases, I prefer arch. maybe for the pure fact that you do start with nothing. whatever gets built up over time that would be cleaned out by a six month release was actually put there by you. it does take patience at first, but arch seems to have a very helpful community. very unlike when i first switched to linux way back. greeted with the "if you don't know it you shouldn't be here" attitude. things have changed, but it made me appreciate the BSDs way more at the time.

xmonad is a tiling window manager.
openSUSE 11.2 has the best KDE implementation ever made. Complete KDE-Firefox and KDE-openoffice integration ootb. openSUSE is also very famous in KDE forums, as they stick true to the KDE releases and backports a lot of KDE features, other distros remove a lot KDE stuffs for various reasons. openSUSE specializes and puts a lot of effort towards their KDE releases. Just like ubuntu gives gnome more preference and kubuntu just feels half-baked, just put out there for the sake of it. openSUSE and Mandriva actually care about their KDE releases, like ubuntu and fedora care for Gnome.
For more info.

Well i did check out fore sight linux... it seems to be a rolling distro that is perfect for newbies... considering that the installation process for most rolling distros tend to be complicated.....

But i would love to go the hard way... so that i can learn some of the linux "internals"... So i am back to the gentoo or Arch question... Maybe i ll go with both arch and gentoo on a virtual machine...

Well... how easy is it to use arch/gentoo in an environment without internet?? can we install a manually downloaded package easily?? or is it overly dependent on internet??

By the way can a package manager be installed in slackware???

Slackware already has package management.

Sorry i meant dependency management....

I use Arch and Sidux ... Really, I've tried many distro's, these are the fastest and most responsive distro's I've used to date.

Well... how easy is it to use arch/gentoo in an environment without internet?? can we install a manually downloaded package easily?? or is it overly dependent on internet??

You can manually download packages and then install them from cache.

Like to know more about that.... can u point me to a tutorial?

Well, you will need a computer with interet access. Install Arch on it. Setup that system completely. Then you can take backup of all the cached packages and install it in another computer. Read a bit about pacman here:

http://wiki.archlinux.org/index.php/Pacman and http://wiki.archlinux.org/index.php/Pacman_Tips

On the same note what is the diff between makepkg and ABS?? Both seems to do the same thing... build packages from source.

Arch Wiki has the answer to all your questions. ;) Trust me, it's the best wiki of any distro.

http://wiki.archlinux.org/index.php/ABS_-_The_Arch_Build_System

http://wiki.archlinux.org/index.php/Makepkg

Basically makepkg is the command you use to build packages from sources using ABS which is a ports like system.

i did go through the wiki before asking the question but i fail to see the difference....

makepkg builds Arch packages. It's a tool. It takes your PKGBUILD, gets the source codes, patches/compiles them and outputs a .pkg.tar.gz formatted package which can be easily installed by pacman.

ABS - It's a ports-like system. Just like gentoo or BSDs. Check out http://en.wikipedia.org/wiki/Ports_collection

Hopefully, that helped.

Regards

So using ABS, package installation is done the Gentoo way... download source, optimized compile to create a package....
ABS is for compiling packages which are in the official repos right?? And if i wanna install a manually downloaded tar ball, i just use makepkg??

I've just skimmed through this thread & haven't seen PCLinuxOS mentioned as a rolling release yet. My PCLOS box started out as 2009.1 and is currently 2010... ;)

You're right that ABS is for rebuilding packages that in the official repos. It will sync with a database to download the PKGBUILD files and anything else needed other than source code with is available from the programs website. You then run makepkg which takes the PKGBUILD file a gets the source code, compiles it and creates a package that you can then install.

If there's something not in the repos, the first place would be to look at the AUR, which is a separate resource where users can submit their own PKGBUILD files to create packages that aren't officially supported. Between the official packages and the AUR almost every program I've needed is already available. If you come across something that isn't in either place it's not too hard to modify a PKGBUILD to work for a new program and submit it to the AUR yourself.

I forgot about PCLOS. I used it a while back. 2007.1 I think. I really liked it. I like that he/they added and made easily available software that other distros tend to shy away from. Freedom in an OS for me is using anything I want to use and not having to spend too much time searching for it. I also like that it used apt with the RPMs. It had gained a bit of popularity while I used it, but not a lot of work seemed to go into it compared to other distros with bigger development teams. Even though it was bleeding edge and stable, I began to feel left behind. Since I am lazy I didn't want to help. It looks as though development has picked up. Needless to say, maybe for that reason, or the fact that I get bored, I moved away from PCLOS. It is still one of my favorites I've used. I've been thinking of switching back.

Except, I am still very much happy with Arch. Even though I am still using sidux on this computer. Arch is installed on another machine. I think it all boils down to package management. The binary installation combined with ABS and AUR, there is not one package that I use that I haven't found readily installable in Arch. I can't say that for ANY other distro or operating system. Not that you can't get the source and build it anyway in other distros, but in Arch it is just one simple command away. And the flexibility and customization of the package management in Arch just can't be beat. And the wiki and forums are more thorough than anything I've used before. The walkthroughs on the Arch website are easier to understand and more thorough than any manpage or BSD handbook or other distro forums. In fact the information there can be applied to other linux distros.