Are Rolling updates ever going to happen?

You dont have to upgrade every 6 months. Normal releases are supported on the desktop for 18 months. LTS releases are supported for 3 years on the desktop.

If you install an LTS release then you can avoid upgrades for over 2 years. If you want to stay up to date then the only option is of course a major upgrade.

I don't see any way in which rolling upgrades could happen in a way that would be either efficient or indeed reliable.

Of course you could switch to the development version of Ubuntu and track that, but stuff in development breaks and breaks badly. 6-monthly release upgrades are the least-worst option as far as I can see.

Thanks for sharing your opinion Andrej.

The philosophy behind Ubuntu is quite clear and caters for the needs of a very large user's base:

a 6 months release cycle together with a Long Term Supported release.

Please note that there is no obligation for anyone to upgrade or even to update single packages.

There are other distributions available with different philosophies, for instance Debian offer a longer release cycle with more frequent updates.

I believe there is enough freedom of choices that should make everyone happy.

Yep, I know about the LTS/development versions and also about the drawbacks that switch would involve...

What I don't know exactly is how much are packages in ubuntu different from the vanilla ones.

Let's have KDE as an example - if some used dapper, he could have had just the 3.5.2 version (let's ignore the "side-repository" solutions) - if he wanted the 3.5.6, he would have to upgrade to feisty... Is it really fundamental so to upgrade the whole system just to replace KDE? Yes, maybe one would have to also update some kubuntu-specific configuration files, a few other packages, but then - why do I have to upgrade kernel, binutils or firefox? Is it because of linked libraries?

Or the kernel - the only thing I think it could depend on is the gcc version. I compiled my own (vanilla) kernel once (I had 2.6.15, I wanted 2.6.17) and there were no problems with the rest of the system. Sure, the kernel is a not-so-simple thing.. E.g. the 2.6.20 in feisty caused all /dev/hd* to be remapped to /dev/sd* :-) On the other hand - e.g. fedora does switch kernels even within the same distro release, and most of the time this switch is also without any major problems (or still with smaller problems than when upgrading the whole distribution at once).

And so on...

Some distributions (arch) handle the rolling upgrades seamlessly, so why wouldn't it work on ubuntu? Is it because of the deb package system?

Maybe some good official system of backports would nicely replace the need of rolling updates... But just who would maintain the legacy releases :-(

>What I don't know exactly is how much are packages in ubuntu different from the vanilla ones.

There is no set answer to that question. There are packages where I have seen changelogs with tens of different changes w.r.t. Debian, and Debian may as well have made quite some changes w.r.t. to upstream.
I have seen packages where the only difference is perhaps a .desktop file or even not that (grant you, thats mainly in universe).

I have seen people breaking their system just because they installed audio drivers from a non-ubuntu source and others (me and you included) that have happily compiled their own kernels.