Ubuntu's Engineering Director Debunks Rolling Release Rumours

Responding to yesterday's post indicating that Ubuntu might move to a rolling release schedule, reader ddfall writes "This is wrong! Engineering Director of Ubuntu Rick Spencer says 'Ubuntu is not changing to a rolling release.' He goes on to say, 'We are confident that our customers, partners, and the FLOSS ecosystem are well served by our current release cadence. What the article was probably referring to was the possibility of making it easier for developers to use cutting edge versions of certain software packages on Ubuntu. This is a wide-ranging project that we will continue to pursue through our normal planning processes.'"

Comments

That's a relief

[onionman]

I personally like the idea of scheduled releases which have been somewhat reasonably tested. Giving developers a mechanism to deal with the cutting edge versions of each package is nice, but I'd rather not have those in the releases on my servers.

Re:That's a relief

[Chrisq]

I personally like the idea of scheduled releases which have been somewhat reasonably tested. Giving developers a mechanism to deal with the cutting edge versions of each package is nice, but I'd rather not have those in the releases on my servers.

I agree. Rolling releases works for beta but the idea that substantial changes could be rolled out in a daily update (as opposed to security updates) would kill any corporate use. They don't want changes that could involve the users seeing something different appearing without testing, training, etc. Many people like the LTS releases for this reason.

Re:That's a relief

[lennier1]

Many people like the LTS releases for this reason.

Unlike the half-baked release of 10.10, where it was obvious that there was still a lot of critical stuff unfinished?

Re:That's a relief

[Adam Jorgensen]

I disagree. I run Sabayon linux and I find the rolling release system actually works very well.

Re:That's a relief

[Chrisq]

Many people like the LTS releases for this reason.

Unlike the half-baked release of 10.10, where it was obvious that there was still a lot of critical stuff unfinished?

I don't know what "critical stuff" you mean. I downloaded it on release day and it worked. There were a lot of big updates in the following week, so maybe it was stuff that broke other configurations.

Re:That's a relief

[BrokenHalo]

Similarly, I run Arch Linux, and have found its rolling release to be at least as bombproof as Ubuntu's cadenced release. The difference is simply that your upgrade cycle happens at a time when you and the individual program developers are ready for it, and you can be as selective as you like.

Re:That's a relief

[Anonymous Coward]

Many people like the LTS releases for this reason.

Unlike the half-baked release of 10.10, where it was obvious that there was still a lot of critical stuff unfinished?

I don't know what "critical stuff" you mean. I downloaded it on release day and it worked. There were a lot of big updates in the following week, so maybe it was stuff that broke other configurations.

Maybe something like when you install the Nvidia proprietary driver for the GeForce 8xxx series graphic cards and reboot, all you get is a sleeping monitor at boot up. Worked just fine from the first Alpha, all the way through the Release Candidate, then died on the Final Release.

Re:That's a relief

[MonsterTrimble]

Just for me, the biggie was the new Xorg 1.9 which broke almost every nvidia-produced driver out there. Mine (nvidia 96) was the last to get fixed. I had to put off upgrading for about a month until it was fixed.

I realize bitching about waiting a month extra for a new release makes me sound like a douchebag, but when it's something as high profile as display drivers I must take offense.

Re:That's a relief

[asvravi]

How about the broken lirc/IR ecosystem? Stock hauppauge IR controls stopped working because the 10.10 userland did not jive well with a premature backport to the kernel version used.

Re:That's a relief

[Anonymous Coward]

I downloaded it on release day and it was a pain in the ass to install, requiring me to load proprietary drivers from the installation, restarting X, just so my screen wouldn't look like garbage. After that, I had to reboot (so had to install proprietary drivers again for my screen to work fine), and then I found out that X was using 100% of my CPU and made the machine unusable. Typical Linux experience, I suppose.

Re:That's a relief

[Fri13]

+1

+ It is very easy to roll back to state before upgrade if the upgrade did not work. And especially if user use btrfs the snapshotting comes very very handy. Just take a snapshopt, upgrade and if there comes problems, rever to snapshot.

I have found that rolling release distributions (like Arch Linux) being more stable and more pleasant to use than 6 months release scheduled distributions and definitely nicer than Debian's Stable and Canonicals LTS based to Debian testing branch. On servers the situation is different but on desktops the rolling release is nicer.

And this makes the development and testing much nicer when developers gets bug reports from the newest code what they itself can use, without solving so much possible problems caused by depencies to code what is older.

Well it must say that Canonical had it glory few years ago and now it is going down. Other distributors are already packaging their distributions in such manner they meed more casual and basic users needs than Canonical's Ubuntu does. But it does not make Ubuntu bad distribution, just not best one.

(this all after maintaining 15 computers with rolling release and all with custom upgrade schedules on different houses)

Re:That's a relief

[lennier1]

Typical Linux experience, I suppose.

Sounds familiar. The last kernel update just prior to 10.04 suddenly caused serious problems with RTL8194SE chips, leading to kernel panic reboots whenever a user tried to switch between wi-fi and cable connections. Mighty annoying and the first time it happened to me I was right in the middle of a company-internal presentation.

Re:That's a relief

[lennier1]

And 10.04 was the reason why I put off upgrading the laptop for over a month. The joy of Nvidia graphics.

Re:That's a relief

[lennier1]

* 10.10

Re:That's a relief

[billcopc]

I'm not trying to troll, but before someone less noble says it: why are you running Ubuntu on a server in the first place ? I'd like to know why you would choose Ubuntu over something like CentOS.

I'll be perfectly transparent here, I'm just as bad: I run Gentoo on my servers. So don't be shy to profess your love for the easy-to-use distro, I'm not here to judge :) I use Gentoo because I have zero patience for binary package "management" and the dependency hell / obsolete libraries that come along with it. Yes, Gentoo takes ages to set up, but I love its creature comforts and Portage, for all its pains, is a godsend when you want to apply your own patches. And well, the elitist in me loves the fact that the Gentoo forums are mostly populated by like-minded coders and sysadmins, with a relatively low ratio of attention-whoring noobs. Sorry, but when I'm hunting down a pesky segfault I'd rather not have to read through 20 pages of unrelated comments and "me too" bugs just to find the pastebin link to a fix.

So now, enough about Gentoo... tell me why you like Ubuntu and why I should too :)

Re:That's a relief

[fotoguzzi]

Suspend and hibernation for the ThinkPad seems to have died between 10.04 and 10.10. This is something that had worked great for years!

Re:That's a relief

[Urza9814]

Rolling release is the reason I love Arch, and half the reason I'm planning to put it on a server I'll be building soon. Between Arch, Mandriva, Ubuntu, Slackware, and Fedora, Arch is the most stable distro I've ever used. It's not like the packages they distribute are alpha quality or anything - they're stable versions, they're just the _newest_ stable version. Meaning they've hopefully fixed the major bugs from previous releases. Plus, Arch is rather minimal...which I think any rolling release distro would have to be. The distros that release versions every x months always seems like a carefully balanced house of cards - I can't tell you how many times upgrading _one_ package to the latest version screwed up a large portion of the entire system. Never had that problem on Arch. It's a bit harder to set up, but once it's up and running, everything just works.

Re:That's a relief

[hedwards]

I don't think that rolling releases work well for an OS which is comprised of a Kernel and 3rd party contributed apps. Especially since Ubuntu doesn't have much control over the Kernel. To try and enforce a release schedules on 3rd party developers would be foolhardy at best.

However, for OSes like FreeBSD where the entirety of the userland is maintained and controlled by the project they probably could get away with it. And in a sense they do with -STABLE.

In general though, it's not particularly easy to balance the needs of QA and the production environment with regular releases. Less so when you're pulling in a set of outside programs which might very well be on a different release schedule.

Re:That's a relief

[Knuckles]

Sounds like something to complain to Nvidia for.

Re:That's a relief

[Dr_Barnowl]

My experience with CentOS is that it's very stable. Which for me is a euphemism for "antiquated".

For example ; my organization has a contract with CollabNet for server hosting on their TeamForge platform. In addition to the usual forge servers, there are hosted servers (both virtual and "real" with lights-out management) in the back for running build services, etc. The provided OS build on most of these servers is CentOS 5.0

Now CollabNet are very big on Subversion, and selling services related to Subversion. So why oh why are they providing a server OS which installs a truly ancient version of one of their flagship products - 1.4.2 ? Lucid is on 1.6.6, Maverick is on 1.6.12 ; 1.4 is from 2006 ; there have been 2 LTS releases of Ubuntu Server since then.

Yes, I know there is RPMForge. But the whole thing seems very amateur.

Now, as for Gentoo vs Ubuntu ...

I have respect for the Gentoo way of doing things. Gentoo was the only way I could get my MythTV box running when I first set it up, because it was the only distro I could find with support for the bleeding-edge drivers my TV capture hardware needed. Just installing Gentoo taught me more about the innards of Linux than anything else had done at the time and I wouldn't hesitate to recommend it to someone who a) had a lot of time on their hands and b) needed to know a lot about the innards of Linux with little previous experience. I do agree that it tends to attract the kind of user who is knowledgeable. The wiki in particular provided excellent documentation - that said, a lot of it deals with problems you only get with Gentoo because of the way it is ;-)

Temper the comments above with consideration for the fact that I'm not up to date with Gentoo - I quit using it actively long before I cleaned it off my MythTV server and replaced it with Mythbuntu. There are still patches in the kernel to IR remote driver tables I wrote when using Gentoo, so it still has a place in my heart, but I really don't want to go back to watching compiler scrollback for hours on end.

You don't need to use Portage to apply your own patches. In Ubuntu, you'd use a Personal Package Archive (PPA) - check out the sources for your package using the Canonical-sponsored Bazaar version control system, patch them, push the result up to the server, and the Canonical build farm will build a shiny new set of packages for you. Add your PPA to your apt sources list and your machine will update from them. You can keep your patched packages up to date with the official ones by merging the new revisions from the Bazaar branch.

So overall, I use Ubuntu because it's more up to date than CentOS, because I understand it better (being my primary desktop OS and the basis of my MythTV server), and because it's friendlier than Gentoo. It has a larger user base - the squeakiest wheels get the most grease, so I think it's more likely that problems get found, making it more likely they get fixed. And I just can't justify waiting for my packages to compile ; I never got the hang of all the workarounds Gentoo has for this like farming builds out to other machines in your network.

I'll raise a glass to Gentoo and all the rest of the diversity in the GNU/Linux OS space. They all bring their own dishes to the table and we are all better off for it.

Re:That's a relief

[Anonymous Coward]

Suspend and hibernation for the ThinkPad seems to have died between 10.04 and 10.10. This is something that had worked great for years!

Try blacklisting hid_ntrig, that worked for me. Actually I also had to blacklist usbhid and hid for suspend to work reliably, lucky I don't use them much....

Re:That's a relief

[Ash-Fox]

why are you running Ubuntu on a server in the first place ?

I'll bite. In my instance, why I have chosen at times Ubuntu over CentOS:

1) specific daemons, libraries (if I'm using certain commercial software that relies up on it) are provided in the distribution's repositories, removing the need for me to package my own versions of the software where CentOS did not offer. This removes the issue of me having to monitor for security vulnerabilities, needing to back port code should the new library be incompatible with the given application that uses it etc.

2) Ubuntu's Apparmor configuration is not as assinine (and in theory, just as secure) as the configuration used in the selinux configuration that centos comes with, I don't want to have to rewrite all the selinux rules because I want to use pppd with a specific VPN protocol handler.

3) More daemons in Ubuntu run as non-root processes, but dedicated usernames for the given processes, reducing the risk of compromises. I am not happy with having the syslog running as root when it's streaming/recieving log data over the network and might be vulnerable to remote vulnerabilities that could compromise the entire system.

4) I generally prefer the speed of apt, it seems to run faster.

I use Gentoo because I have zero patience for binary package "management" and the dependency hell / obsolete libraries that come along with it.

I much rather sticking to LTS versions of Ubuntu-server for server things, I'm not fond of Gentoo's use-latest-anything-source-package-system-with-different-config-files-used-randomly-and-then-use-wiki-to-figure-out-how-to-do-the-rest-of-the-install style just for a random minor security update (the messing about with unstable packages is what drives me away from Gentoo).

I love its creature comforts and Portage, for all its pains, is a godsend when you want to apply your own patches.

I'm quite fond of apt-build for applying my own small patches/optimizations, the automation you can with it to handle apt-get upgrades is pretty nifty in my opinion. That said, source packages on Gentoo have more customizations using the use flags, apt-build doesn't have anything like that yet.

And well, the elitist in me loves the fact that the Gentoo forums are mostly populated by like-minded coders and sysadmins, with a relatively low ratio of attention-whoring noobs.

Since I don't use forums, I didn't even know this was an issue until you pointed it out (I haven't gone out of my way to verify it).

Re:That's a relief

[kthreadd]

Rolling releases probably work just fine when you're only running it on your personal laptop or desktop. It's a very different matter when you have a site installation on a large number of machines where installations and upgrades are a bit more complex than to insert the CD and click next a few times. It is in those environments you appreciate that you can come in one day and things still work consistently with what they did yesterday.

Re:That's a relief

[Zebedeu]

I don't think yours was the last to get fixed...

Me and most people with a recent Vaio laptop are still waiting on nvidia. Apparently they have the problem fixed in testing, but we're still waiting for a release.

Meanwhile I'm happy I can still use 10.04. I don't know if this would be possible in a rolling release scenario.

Re:That's a relief

[MonsterTrimble]

Not really, I lay it at the feet of Ubuntu for that. They knew early on that a major showstopper bug existed with Nvidia & Xorg 1.9 and they should have made the decision not to upgrade until the fix was done and tested.

Re:That's a relief

[MonsterTrimble]

Did you look for a PPA for it? That's where I found mine.

I wanted to upgrade for a bunch of LXDE packages myself. I see a lot of improvement from them so I like to keep on top on it.

Re:That's a relief

[Anonymous Coward]

Rolling release systems can be made work as one. It is just question of administration skills.

Re:That's a relief

[ONU CS Geek]

I work for CollabNet's engineering team for TeamForge -- CollabNet does provide a yum server for updates and current versions of subversion for TeamForge users. While CentOS (What our VMWare image uses) is at 5.x, we stay with that version so that companies get the benefits of having a stable release (as far as underlying software versions go) with security updates (through the upstream).

Feel free to email me and if you have any questions, or any additional feedback about our installer or the product in general, I'd love to have it.

Re:That's a relief

[Anonymous Coward]

I don't think any distribution should bend for some hardware manufacturer to get their proprietary drivers working on a primarily open-source system. It should be the other way around; if nVidia wants to be the sole maintainer of drivers for their cards (ie. keep it proprietary), then they need to get their asses in gear and start fixing and update their drivers. The exception being if part or all of the bug lies in Xorg itself and need fixing, then I can safely say that Ubuntu may be better off using a more stable and bug-free version of the open-source package. That is, assuming the bug is considered to be bad enough, but this could be argued when talking about making proprietary software/drivers work in an open-source system. Sometimes, they're the least of anyone's worries on a distribution's development team. In the meantime, surely Xorg would be working on the problem if it's on their side, so it would soon enough get fixed.

Re:That's a relief

[Adam Jorgensen]

Indeed. Ones admin skills should extend beyond the "Click to install ALL upgrades" style anyway.

Re:That's a relief

[junglee_iitk]

I wanted to install Kubuntu using USB. Guess what, installer segfaults after creating new partition. I had to waste 2 days getting anything installed on my laptop.

And this problem was known at launchpad.

Re:That's a relief

[arose]

The problem must have been less widespread then you are trying to imply. My 8xxx was unaffected.

Mark Shuttleworth about Cadence

[geschild]

Last year in his speech at the Open World Forum in Paris, Mark was trying to convince people that more open source projects should get in lockstep with the Ubuntu six-month release cycle. I would be surprised if he had changed his mind so soon.

Re:Mark Shuttleworth about Cadence

[Anonymous Coward]

He wasn't saying the world should revolve around Ubuntu, but rather that everyone should work together. A little different, don't you think? If everyone agreed to work in cadence to a different cycle than ubuntu's, I think he would have still called it a success.

Re:Mark Shuttleworth about Cadence

[Fri13]

Mark has never listened the open source community saying that the community is already working together. Mark believes that the magical fix would tie everyone to same schedule. As everyone would work at same corporation and at same building and at same room with same working times and everyone would get paid from 8-16 hours working.

Open source has worked wonderfully now since the first mainframes were started at 50-60's in universities. And Linux community (big role in the OSS community) has proofed that current schedule thing works very flexible and powerful way.

We do not need Mark to ruin everything with his RDF talks.

The important thing is the users and their connection to developers and skills to discuss about changes between projects. Locked schedules would not change that at all.

Re:Mark Shuttleworth about Cadence

[Anonymous Coward]

We do not need Mark to ruin everything with his RDF talks.

Yeah, he has a big semantic web around him. He's such an RDF schemer.

Faked Story?

[TaoPhoenix]

Yesterday's article was based around the following:

"Ubuntu founder Mark Shuttleworth said during an Ubuntu 10.10 conference call last month that a move to daily updates would help the popular Linux distro keep pace with an increasingly complex software and platform ecosystem ...Today we have a six-month release cycle," Shuttleworth said. "In an internet-oriented world, we need to be able to release something every day. ...That's an area we will put a lot of work into in the next five years. The small steps we are putting in to the Software Center today, they will go further and caster than people might have envisioned in the past."

Word wise, that's pretty clear. It goes to the top of the food chain. It sorta says when.

So is this just another completley fabricated story to get page hits?

Re:Faked Story?

[Bill_the_Engineer]

Or the Engineering Director didn't get the memo...

Re:Faked Story?

[shish]

So is this just another completley fabricated story to get page hits?

From what I can see, Mark is basically saying "backports might be something worth looking into"; then the media, being the media, blow it out of all proportion into "Mark Shuttleworth declares that every Ubuntu package will be bleeding edge tomorrow".

I wonder what it's like for the poor guy, any time he mentions anything, in any context, people take it to the extreme then claim that that is what Ubuntu will do next...

Re:Faked Story?

[PhrstBrn]

When Shuttleworth talks about the Ubuntu Software Center, it makes me thing he's talking about daily updates to user software. So software like OpenOffice, Firefox/Chromium, Pidgin/Empathy, GIMP, etc would get version updates between releases. I don't see this as being a bad thing. I'm sure they can make this work without creating problems. They already have a mechanism for this, it's the -updates repository, they just need to iterate at a faster pace.

I assume they're not stupid enough to actually attempt stuff like updating the kernel, X11, servers (httpd, mysql, samba, cups), compile tools, libraries, etc between releases. Users who don't want this behavior would only need to remove the -updates repository (you shouldn't be using this repository anyways if you're that paranoid). -security would still be available for those who only want the security updates (ie Enterprise)

If you catch yourself saying "FLOSS ecosystem"

[Rogerborg]

Please take it as a sign that you need to spend more time with your compiler and less with the Director of Buzzword Bingo.

Re:If you catch yourself saying "FLOSS ecosystem"

[Anrego]

The whole OSS -> FOSS -> FLOSS thing has always bugged me.

It's not enough to say it's open source.. we have to emphasize that it's FREE open source.. and now even that's not enough.. we have to describe the specific _kind_ of free that it is.

And yeah, using the word ecosystem in a non-biology context is _so_ management.

Re:If you catch yourself saying "FLOSS ecosystem"

[blai]

FLOSS ecosystem is nowhere near EcoFLOSS Cloud 2.0.

Re:If you catch yourself saying "FLOSS ecosystem"

[CODiNE]

Is the FLOSS ecosystem in danger of overpopulation or global climate change problems?

Re:If you catch yourself saying "FLOSS ecosystem"

[andrea.sartori]

FLOSS sounds like dental hygiene, especially in the same sentence as "ecosystem". With all due respect (to both.)

Re:If you catch yourself saying "FLOSS ecosystem"

[Anonymous Coward]

It's enough to say free software.

The freedom to open and view the source code is implied. All free software is open source software.

There is also no need to distinguish between gratis and libre. Thanks to the Internet, any libre software is gratis. In other words: to anyone who's invested in an Internet connection, free software is both free as in free speech and as in free beer.

Rick Spencer says no rolling releases?

[Samantha Wright]

Man, there goes a good Astley moment.

Re:Rick Spencer says no rolling releases?

[camperslo]

Hmmmm, Ubuntu Live CDs would be great for every holiday stocking... just figure out how to burn them to boot up and auto-play Rick Astley. Would be a nice addition to the maintenance scripts too...

UBUNTOO DEBUNTO RUMOURS ??

[Anonymous Coward]

Ubuntoo is not in a posistion to debunk anything. Except concocting this free publicity stunt !!

Re:UBUNTOO DEBUNTO RUMOURS ??

[Ash-Fox]

Ubuntoo is not in a posistion to debunk anything. Except concocting this free publicity stunt !!

English, motherfucker - Do you speak it?

Like Arch Linux

[Bryan Ischo]

My distribution of choice, Arch Linux, uses a rolling release schedule, which has its good and bad points. I suppose the worst part of it is that with Arch Linux, old versions of software are not retained in the repositories and the package management tools don't make it easy to go back to a prior version of the software in the event of a problem. As a result, upgrading is a bit of a 'cross your fingers' endeavor and more often than not, I've regretted a full system upgrade.

I think that rolling release can work well but only if the package management system is designed to, and the repositories are set up to, allow easy rolling forward and backward on software versions as necessary. It's my number one wish for Arch Linux, which otherwise is the best distribution I've used.

Re:Like Arch Linux

[bema]

Since pacman caches any package you download, downgrading is in my opinion pretty easy (execpt the package depends on some library of a certain version). All you have to do is to install a previous version of a faulty package from the cache directory and let pacman ignore the package for future updates.

Re:Like Arch Linux

[Anonymous Coward]

If you like rolling releases and crave more stability, you should try aptosid [ http://aptosid.com ]. It's built on Debian sid and stabilized with it's own fix.main.

Re:Like Arch Linux

[Fri13]

How big is your Pacman cache? I have 12Gb and since installation (over 11 months) I have only used 5.5 GB from it. I could even roll back to the base level what I had after installation. It is not as "press this button", but easier than doing a fresh install with Ubuntu install image.

And do you know what you would gain with the snapshot features from the filesystems and joined it with LVM?

I upgrade system now and then (usually 2-3 weeks) if I can not find otherwise bugs. And so far I have not yet needed to do a roll back system upgrade. Once I have got bug what did not allow me to enter one application settings panel. But it was fixed in 2 hours and I got it updated.

It is very nice to go to pacman cache to check what was the earlier version of the software and downgrade it to that version. As Arch tools really gives the nice function for it.

You are only gaining problems if you do not have enough space for pacman cache or you clear it too often.

Re:Like Arch Linux

[Anonymous Coward]

I share a similar experience. I think Arch Linux is great. I've been using it as a scientific workstation for the past 3 years at work, but this christmas it has to go. Rolling release just doesn't work on this kind of system. The first time I did a "pacman -Syu" it upgraded Python to 2.6 which broke, well, everything. Which taught me not to run an upgrade at 1am, but the handy /var/cache/pacman/pkg saved me at least, though it took 3 hours to get everything back into shape. After that I left things alone, but eventually when you want to install a package, it starts wanting to upgrade everything too. So the second time I wisely left it until the Christmas period, ran the -Syu and watched it promptly break the RAID and wouldn't boot any more. At least I could take it home and fix it at this point. So I'm running an Arch with packages 2 years old or something. I was going to upgrade but noticed that now Python is version 3 in the repos. I *suppose* I could work my way around it with a custom pythonpath etc etc... but for a workstation, it's too much heartache running rolling release. I guess it's Debian or something for me again.

That said, if I wasn't sitting on piles of departmental Python code that needs Python 2.x I would definitely try and stay with it longer. It's a great distribution.

Re:Like Arch Linux

[Bryan Ischo]

I use SSDs exclusively (will never buy a spinner platter drive again) and I would prefer if the old packages were hosted on a server somewhere instead of having to be cached on my drive. Seems more efficient to me for 12 GB on a server to serve hundreds of thousands of users than for each of those users to have to spend 12 GB to cache their own packages.

That being said, I have never deleted anything from my pacman package cache so I could probably use the technique that you described. There are cases where even that is not sufficient (for example, if I want to install on a new computer and want to use an older package version because I know that I have a problem with a newer version) but those are less frequent problems. To be honest, I never even realized that using pacman to downgrade via the local package cache was an encouraged, or reliable, option, but if you're saying it is, then I believe you.

Re:Like Arch Linux

[Bryan Ischo]

Actually, I don't really like rolling releases, but I tolerate it because it's what Arch Linux uses. I prefer Arch Linux's extreme simplicity over Debian's incredible complexity which is why I use it. Just having to keep track of the 10 programs you need to just manage packages on Debian gives me migraines, not to mention the convoluted system configuration setup on Debian. Arch Linux is *dead* simple which is why I use it. The shortfalls of Arch Linux are:

- Rolling releases with little support for choosing package versions
- As a result of the previous, if you want to install software that you don't happen to have, you often have to upgrade a whole bunch of stuff because the only version available from the servers will be the newest version which probably has dependencies on half your system
- Packages that break/have bugs *much* more frequently than on other systems
- It's x86/x86_64 only, which is the biggest shortcoming for me

But the positives of Arch Linux far outweigh the negatives so I choose it whenever I can.

Re:Like Arch Linux

[Adam Jorgensen]

Come of it, it's not *THAT* hard to run multiple versions of Python at once. In fact, it's mostly pretty easy. This is one reason why I use a proper IDE for my python work now. It tends to handle multiple python versions very well.

Re:Like Arch Linux

[Anonymous Coward]

Just having to keep track of the 10 programs you need to just manage packages on Debian gives me migraines

Can you elaborate on that? I've been running Debian (and debbased) systems for about six years now, and I don't think I can get past 2 in my daily usage: aptitude and apt-cache. And that's cheating, because apt-cache is only an informational tool, not a management tool.

The only time I've ever used something else was when dist-upgrading Ubuntu from breezy to edge: I had to resort to dpkg -P --force-depends to resolve conflicts. What other tools did you use on a regular basis?

Already possible

[paugq]

Do you want rolling releases in Ubuntu? It's always been there, really

You only need to edit /etc/apt/sources.list and every file in /etc/apt/sources.list.d and replace "maverick" with "natty". Now apt-get update && apt-get full-upgrade.

When Natty is out, repeat only this time replacing "natty" by the natty+1 name.

Same thing works for Debian: replace "stable" or "lenny" with "testing" (or "unstable", if you are brave).

IMHO, Ubuntu should provide a "next" name, like the "testing" and "unstable" release version names in Debian, for people who want rolling releases.

Re:Already possible

[paugq]

Clearly you have not tried what I said and you have no idea how Debian and Ubuntu repositories work.

It's more or less like this:

• Maverick is released
• The day after maverick was released, the natty repository was created. It contained an exact copy of maverick
• New packages are imported from Debian and added to the Natty repository. These packages show up in the repository as they are added: 5 new packages today, 20 new versions tomorrow, a new kernel in 2 months, etc

• By replacing 'maverick' with 'natty' in your sources.list, you get updates daily, not just when natty is finally released (in fact the day natty is released you will not get any new update if you have been updating every day since the maverick release).

Re:Already possible

[andrea.sartori]

It's always been there even if you don't edit sources.list. I didn't understand the hype (was there any?) yesterday, nor I do today.

Re:Already possible

[andrea.sartori]

No, because new versions of windows come out every 7-8 years, unless one particular version is a royal screwup, in which case it only takes 2. "Rolling releases" here was meant as "often" I think.

Re:Already possible

[Anrego]

I found Debian's unstable to be a little bit _too_ unstable. It didn't feel like it's really meant for daily use (which given the name it probably isn't).

Disclaimer: I'm a Gentoo user, and while I did give Debian a fair try (about a year and a half) a lot of the issues I ran into were probably due to my own stupidity.

Gentoo isn't exactly the hallmark of stability either, but I think it pulls off the rolling update approach better (which of course makes sense, as this is how it's meant to be used by everyone.. rather than a small subset).

On the whole general subject, I think release cycles make sense for servers and production systems/desktops, and rolling systems make sense for a portion of desktop users. I love rolling updates on my desktop, but I don't mind sorting out the minor issues that crop up every once in a while.. most users (especially in the ubuntu crowd) do. That is, I think the current approach makes the most sense for ubuntu.

Re:Already possible

[Fri13]

Do you understand that that is not rolling release but that is developing and testing?

In Rolling Release you do not put alpha/beta/RC software there. you keep latest stable versions from the software there. You get upgrades all the time. Usually just fixes when the upstream adds them and now and then newest versions when the upstream release new version.

Then there is totally different [testing] and [unstable] in rolling release schedules as well. From there you get the GIT/SVN versions from the upstream. The software what you otherwise in next version of Ubuntu would need to compile by hands.

Closer the next Ubuntu release is, slower the update comes. Only few packages gets anymore updated and they start to get behind a lot from the upstream and that can be for months.

In rolling release, the distribution lives right behind the upstream, still not by default giving alpha/beta/rc versions from the software but always the latest stable. Something what Ubuntu development release does not include.

Re:Already possible

[choongiri]

Debian unstable is not, usually, the latest unstable GIT/SVN from upstream.

If I understand correctly, debian unstable is usually the most recently *released* version from upstream. So, if you want the latest *stable* version from upstream, you need debian / ubuntu *unstable*. I use this in practice on a debian (stable) web server, with a few select web apps such as wordpress pegged to unstable. It's the only way to ensure wordpress / drupal etc are up to date without installing by hand. (In theory, debian pack-ports security fixes to the stable version, but in practice, users typically demand the latest and greatest as soon as it's out, so we go with that.)

Re:Already possible

[petermgreen]

use this in practice on a debian (stable) web server, with a few select web apps such as wordpress pegged to unstable.
For those reading along be aware that while this may be workable for webapps (which are usually written in scripting languages) it can be a poor strategy for packages in general because often apps in unstable often pick up dependencies on unstable's versions of key libraries (this isn't as bad as it used to be due to the introduction of symbols files but it's still an issue).

Re:Already possible

[petermgreen]

use this in practice on a debian (stable) web server, with a few select web apps such as wordpress pegged to unstable.
For those reading along be aware that while this may be workable for webapps (which are usually written in scripting languages) it can be a poor strategy for packages in general because often apps in unstable often pick up dependencies on unstable's versions of key libraries (this isn't as bad as it used to be due to the introduction of symbols files but it's still an issue)

Re:Already possible

[petermgreen]

new versions of windows come out every 7-8 years
While your point in general is correct you are exaggerating. Looking at the years of windows releases (I could look at the months but I CBA to and it dosen't change the overall point) and ignoring server releases.

conventional series
1.0: 1985
2.0: 1988: 3 years from previous release
3.0: 1990: 2 years from previous release
3.1: 1992: 2 years from previous release
95: 1995: 3 years from previous release
98: 1998: 3 years from previous release
ME: 2000: 2 years from previous release
NT series
3.1: 1993
3.5: 1994 1 year from previous release
3.51: 1995 1 year from previous release
4.0: 1996 1 year from previous release
2000: 2000 4 years from previous release
merged series
XP: 2001 1 year from previous release
Vista: 2007: 6 years from previous release
7: 2009: 2 years from previous release

Looks to me like mostly 1-3 years with a few outliers.

Re:Already possible

[andrea.sartori]

Yes, of course I was exaggerating. Thanks however for taking the time of listing all Windows versions ever.

So called it!

[gaelfx]

I so called it in the previous thread. People just love to go crazy over little things, eh?

Re:So called it!

[Fri13]

It is the small things what makes your life worth of living!

look for the Grumpy Groundhog

[Anonymous Coward]

It seems that the Ubuntu equivalent of Debian sid is named : Grumpy Groundhog
see https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/GrumpyGroundhog

Re:look for the Grumpy Groundhog

[Tubal-Cain]

That page claims the Groundhog idea was posted (by Shuttleworth) in 2005. I'm not holding my breath.

Half-rolling releases anyone??

[RogerC]

In my personal opinion, a half-rolling release model would be a great idea. I want my base system(xorg/kernel/gnome or kde) to be as stable as possible. But why would anyone need to wait 6 month or use some PPA to get the latest version of Firefox/Chrome/GIMP/Whatever? I was taking a look at Chakra (a KDE-oriented distro with Archlinux roots) a few days ago and found their half rolling-release model idea to be extremely good. I hope to see something similar in other distros in the future.

People who aren't aware of libre

[tepples]

It's enough to say free software.

Except to people who aren't aware of libre in the first place. They think "free software" means what was in the 1990s called "freeware", or proprietary software distributed gratis.

This really isn't important for standalone users

[waitin4cpmrevival]

The ubuntu "rolling release" issue is critical for servers and corporate users, but not for individuals. For people with a handful of machines, a simple weekly or monthly cronjob with aptitude or apt-get (i.e. with debian ubuntu) will do. Besides, I don't think that most standalone users will see noticeable changes between slight incremental changes in the kernel. Waiting for a cronjob to take up an incremental upgrade a few days after the fact won't matter at all for most individual users.