Two Simple Suggestions for Ubuntu

As Ubuntu's popularity increases, how can we help to ensure that new users get the best experience possible?

My last (admittedly strongly worded) article appears to have touched quite a nerve out there in the community.

Perhaps some readers jumped the gun when they saw the title and didn’t read the whole article, or perhaps I didn’t make my point clear. Either way, I’ve decided to clarify my perspective a little (if anyone bothers to come back to read it), because I actually do care about Linux.


The first thing I want to clarify is that I’m not saying Ubuntu is a bad operating system, or even a bad Linux distribution. For ease of use for new users it remains one of the best choices available. I’m also not even saying that Karmic is a particularly worse release than any other. I’m also not saying that Windows is good, nor that OS X is perfect. The reason I referred to OS X is because that’s Shuttleworth’s goal for Ubuntu – to surpass it.

I’m a Linux guy. For me, of course Linux is the best operating system ever there was. I want it to be even better.

As I mentioned in my article, Ubuntu has done (and continues to do) a lot of good for Linux. They have made many of the previously hard tasks much simpler. As a result, they have also converted new users like no other distro before them.

What I am saying however is that, in general, a new version of Ubuntu is simply not stable enough at the time of release. I’m not particularly complaining about everything else Ubuntu does, just primarily that the releases are not solid enough. Many people know this, which is self evident by the number of major issues people are having, the bugs in the release notes, and the fact that it’s common practice to not upgrade for a month. This is not a good thing, especially for new users.

This is what the article was about – issues with a new release, primarily the upgrade experience failing or causing issues. Shouldn’t we make Linux the best it possibly can be?

The Cause

Ubuntu Community Manager, Jono Bacon, recently wrote on his blog in relation to this issue:

“Karmic was a ballsy release: we shipped some adventurous new technology and in the short six-month cycle that we are committed to, we tried to ship the most exciting, feature-full and compelling release that we could.”

Non-LTS versions of Ubuntu are more bleeding edge, we all know that. Even so, they are still meant to be stable releases. It’s a fine line between stability and features, I understand that. It’s a hard thing to judge and get right. Add to all that a strict timeline and commercial pressure and you might get a less than desirable result. Can we have an exciting, feature-full and compelling release that is also highly stable?

At the end of the day, Ubuntu (and Linux in general) gets judged by what is put out there. If a release does have some major bugs, the perception among the community will reflect that.

Jono also said:

“I don’t want to denigrate the experiences of our users who face problems: if something goes wrong, that user’s experience is genuinely marred. Irrespective of whether the fault was in our package, with hardware, with networking, in the upstream version of the software or elsewhere, that user had a bad experience, and we need to come together as a project to help prevent these problems from occurring again.”

Exactly. He’s spot on.

A few days ago, a proposal was put forward to increase community involvement in testing Ubuntu before it’s released. A post on their blog reads:

“We cannot leave quality to good luck. We cannot rely in having millions of users who will find bugs as they use the applications. Our users want to use the software, not to find bugs and report them. FOSS projects in general and Ubuntu in particular need a new way of rethinking testing as a skilled activity and an opportunity to contribute to the project.”

Once again, this is dead right. With Lucid 10.04 being a LTS (Long Term Support) release, naturally it will not be pushing the envelope as much in terms of new features. It will also be much more thoroughly tested with an earlier freeze.

The Downside

Of course, there will always be bugs. The fact is that Karmic has caused a lot of problems and broken many peoples’ machines. The question remains, is that a good thing? Is it acceptable? I don’t think anyone can honestly believe that it is.

I know that there are a lot of excuses; “It’s free software,” “Canonical is a small company,” “There’s too much hardware out there,” etc. I get that. The bottom line however, is that it’s a reality which we need to deal with and tackle. Relying on these excuses is not going to cut it long term, especially as Ubuntu becomes more and more popular.

As I’ve said many, many times, I’m not so concerned about the technical people out there who come across an issue and workaround or solve it. What does concern me is the average user who has finally taken the plunge from Windows. They need the best experience possible and an upgrade which breaks their machine is the exact opposite of that. End users don’t care that it’s free. End users don’t care about any of the excuses we currently make, they just want things to work.

Sure, over time each release gets better as more bugs are found and fixed, and that’s exactly the point. It takes time after the final version is out. Updating to Karmic today, is much better than it was two weeks ago. Currently however, the update manager prompts users to upgrade right at the time of release before many major problems are resolved, and that’s just a bit too risky.

If Ubuntu is going to throw in lots of extra changes to a release and are expecting things to be dodgy, perhaps they should communicate this more clearly. The oft recommended solution is to only use a LTS release of Ubuntu. These releases are usually more thoroughly tested (which is to say that non-LTS releases are less tested), which is good.

Unfortunately however, LTS releases are not really a great option for the desktop because they end up being so old. For example, current LTS users only have OpenOffice.org 2.4.1 because Ubuntu doesn’t update packages within a release unless there’s a security or bug issue. So LTS might offer a more stable system, but it’s not ideal.

Sure, there’s PPAs and backports and all that, but that’s not a solution to this problem. Firstly, average Joe is not going to know how to set that up (it’s meant to be easy, remember?) and secondly this can introduce more conflicts with less stable software which could mean a worse user experience.

Does Ubuntu even recommend for end users to use LTS releases? Nope. In fact, the webpage defaults to downloading the latest release, not the LTS. Furthermore, the option for LTS (which is hidden) says it’s “ideal for large deployments.” Does that sound like an average Joe home user to you?

Two Simple Suggestions

If a new release of Ubuntu improves dramatically in the first little while following a release, then naturally those updating at this later point in time would have a better experience.

So if we have non-technical users who need a system which is as reliable as possible, they could get a better experience by updating at some later point after a release. Is there a way to achieve that?

Last week on my personal blog (yes, you can leave hate mail there too), I made two simple suggestions which might help overcome (or at least alleviate) these problems.

The first is for the update manager to not prompt the user to upgrade until the stable release has been out for a month (or whatever time frame works. It could even be dynamically flagged when ready).

The problem as I see it, is that the average user gets notified and upgrades straight away. Problems occur and they’re stuck. Ubuntu (and Linux in general) looks bad.

Simply delaying this a month or two means they are blissfully unaware of the newer version until all the major issues are resolved. They will still continue to receive updates on the previous version. Then when they do upgrade, they should have a much more trouble-free experience. Advanced users would still upgrade straight away, discover problems and get them fixed. This won’t solve issues with a fresh install, but many bugs seem to come from upgrading an older version.

Secondly, it seems to me that many of the problems faced with a new version of Ubuntu are due to the fact that it’s a time based release. Come hell or high water, it’s released in that scheduled month. The problem with this is that there’s no room to slip the release, especially when its due date is already at the end of the month.

So my other suggestion is simply to schedule the release for the 1st day of the month. If all is well, release it. If there are major bugs that need fixing, then you’ve got 4 weeks to slip the release and still make that month.

Missing The Point

Ubuntu improves over time once bugs are found and fixed. That’s how free software works. The problem is that the final release is shipped with too many bugs (for whatever reason), which means there are often all sorts of issues, especially with the upgrade process.

Of course it’s hard to find these bugs without a massive user base testing the release. That is supposed to happen with beta and release candidates, but it doesn’t seem to work that way. Most people will upgrade when it’s “stable,” not when it’s officially still in testing.

A month or so after a new release, the upgrade process in Ubuntu is much more smooth. Major bugs have been found and fixed. Known bugs have often also been resolved. How can we make the end user experience better for average Joe? After all, don’t we all want Linux to be the best it can be? Don’t we want user experiences to be as positive as possible?

If we can’t get more testing done before the release, and if bugs are going to be fixed afterwards, then there seems only one simple solution – delay the update option for end users by default.

What I care about is Linux looking good for the average user, that’s the bottom line. For technical users who are happy to fix problems, it doesn’t really matter. I work around the problems I run into with Ubuntu, but I have a lot of friends and colleagues who I have helped put onto Ubuntu whose machines often break every time there’s a new release. This means all the things I say about Linux being stable and not doing “weird things like Windows,” etc, make me out to be a liar and make Linux look bad.

On one hand you want Linux to have lots of new features and push the envelope, but on the other hand it needs to be rock solid. I understand that this is hard to achieve.

It’s hard to be stable when you’re always pushing the envelope, and it’s even harder when you do it on a short time-line. Ubuntu should keep doing what they’re doing but as it becomes more popular some things will need to change. If a stable release is going to have lots of issues (for whatever reason), then delaying the prompt to update seems like a simple and reasonable option (even though I’m not saying it’s the right answer).

We all want Linux to excel, but above all we need new users (especially those less technical) to have a really smooth and seamless user experience. Hopefully the Ubuntu community can achieve that.

Comments on "Two Simple Suggestions for Ubuntu"


\”Perhaps some readers jumped the gun when they saw the title and didn’t read the whole article\”.

You think? Or perhaps they saw an inflammatory headline and an almost entirely negative article.

I\’ve used every single Ubuntu release, and this one has been the cleanest by far – and that\’s based not only on my own experience but the much lower traffic on the user lists than is usual after a new release.

Neither of your suggestions are remotely feasible. Ubuntu has a time-based release cycle _precisely_ because waiting for a release to be bug-free made Debian Sarge such a painful wait; and not offering users the chance to upgrade for a month (or whatever) after release will only push that flood of new users suddenly discovering bugs back a month.

A far more useful suggestion would be that beta-testers should never install in a VM. The beta releases are tested to death in Virtualbox, and probably VMWare, and they work great there.

Finally, regarding LTS and backports: yes, they _are_ a solution. Backports aren\’t \”less tested\”, and should iirc be enabled by default. PPAs are a whole different ballgame. Still, if people were prepared to run their desktops on an older, stable, version, Ubuntu wouldn\’t have picked up so much of the Linux sharee.


Just because Karmic might have been the cleanest so far doesn\’t mean it\’s good enough.

Pushing the update back for a month would only be for the less experienced users who are unlikely to report bugs anyway. After all, people currently recommend waiting a month, so this would be just making it more official.

You\’d still have the majority of technical users updating and reporting bugs, and so the majority of show stopper bugs would be fixed. It\’s those less experienced users who would benefit, which is who I care about.



Oh, and I didn\’t say backports and PPA weren\’t \”a solution\”, I said they weren\’t a good solution to this issue.



Christopher Smart is right. A lot of people outside the industry and community are now using GNU/Linux for their business and serious affairs, and as that increases, there is an onus on Canonical and other commercial distributors to ensure working stuff doesn\’t break with a new release. Non-savvy users turn off pretty easily. Recall the brickbats Microsoft suffered with Windows 98, with national newspaper editors writing angry editorials. That\’s surely not where Linux wants to be.


Although I like the idea of scheduling releases for the beginning of the month rather the end, I think a more fundamental issue is the release cycle being tied to a calendar year. I believe 6 months is probably too often, but every year would be too few. So why not split the difference and go for 9 months (or any other number which makes sense)?


For me, Ubuntu has been pretty good. The problem is that something important is always broken. It\’s pretty random what that is, but I guess it\’s 1/3 kernel related (which is usually fixed soon), 1/3 gnome related (which isn\’t fixed, for example there is no beagle or tracker email indexing in 9.04 or 9.10) and 1/3 is some other application (eg could not browse windows shares inside a domain, ie a typical corporate environment). The non-kernel issues are never fixed once a release goes out. You\’re left to hack something together via someone\’s PPA, or wait for the next version, which in my experience always introduces a new problem. The problem is the model: Ubuntu doesn\’t test releases properly and it includes everything in a release snapshot: thousands of applications. Once that snapshot is made, it isn\’t changed. A minor packaging bug in 9.04 stopped gcompris from working. A really easy fix solves the problem, but that fix will never be made because the release is history. OS X and Windows provide much less functionality, have much more resources, and take one to three years to test before release. What Ubuntu is trying to do is impossible. The open source philosophy is \”release early and release often\”.Ubuntu releases early, but they don\’t release often. It looks like a \”release often\”, but each version is a completely different piece of software. Ubuntu is like moving every six months from one half-finished house to another half-finished house. They should take one year to finish a LTS release. Or make \”Ubuntu\” releases only an inner core of Ubuntu, and not freeze the outer core.


Here is part of the problem with your first suggestion. Instead of having the option to upgrade to the latest and greatest when available, move it back a month and then allow people to upgrade. Isn\’t that the same as expanding the release schedule from 6 months to 7? The question then becomes would that make a difference in some of the problems people are having with Karmic? Moving the availability of the upgrade back, does not change anything.

The fact that people expect a new release to be perfect is beyond the scope of any release. Look at the Windows 7. Some hardware vendors are still trying to get drivers out for the OS. Mac OS just released a huge patch for Snow leopard. So to expect Ubuntu (or any Linux Distro) to be perfect vs. other OS new releases is not fair to Cannonacal.

What needs to happen is longer testing (Alpha / Beta) for the release. They need to figure out what works best. Should the alpha/beta be 1 year instead of 6 months? Who knows, that may be the answer; but that also gives more time for the introduction of new features to the distro that have the potential to \”break a system\”.

In short, to expect a completely bug free, perfectly working OS is unrealistic. It doesn\’t happen with Windows, it doesn\’t happen with Mac OS. To expect it to happen with Linux because its Open source or worse because its IS Linux is even more unrealistic.


@gdonwallace – What Chris is suggesting first isn\’t the same as what you\’ve said at all.

The release schedule would still be every six months and all the linux geeks will continue to upgrade the on the day of (or soon after) release. Bugs will be encountered by people who have the know-how to mess around under the hood and fix them. Then, 30 days later (or whatever timeframe is set – Chris suggested it be dynamic), the automatic updater prompts everyone who hasn\’t upgraded yet that there is an update available. After n days/weeks of bug-finding and fixing, the upgrade process for non-geeks should cause a lot less problems to those people whose opinion linux seems to be trying to change.


So your solution is to have a longer beta testing period. Brilliant! I\’m sure Ubuntu contributors never thought of that. Sorry, this article isn\’t really any better or more clear or more productive than the last one.


I\’m sorry but this is 100% bull****. How many XP machines are running out there for fear of Vista or W7 (especially in businesses). How many times have you heard about waiting to upgraded OS X because xyz happens (including recently toasting a user account on logout). This is not a problem easily solved by anyone who makes an operating system. It\’s easy as a user to say this should be x, but that\’s easier said than done. Software get\’s released and then incrementally improved, that\’s how it works. You want to change how it works, start writing software instead of articles, you can\’t be much worse at that.


I understand where he is coming from, but still do not like his solution. The problem is many advanced users do make the jump early. I for one usually make the jump late alpha stage and was one of those people reporting bugs. This article does identify a valid issue, but I would like to make my own two suggestions instead:

First, invent a user skill rating from one to ten. Make this rating default to one, and needs to be changed manually. Then, have update manager make the updates available, based upon this rating. For example, on a non-LTS release, rating 10 users get prompted at the last alpha, Rating 8 users at the beta (9\’s mid way in between), 6\’s at RC (again 7\’s midway in between), and 5\’s at release. Then 4-1 in four day increments after release. This would have two positive effects… First it gets the most advanced users on the distro sooner, and graduates them in, as fewer and fewer bugs are found, less and less experienced users are now folded into the mix. And, it relieves the pressure off the servers for the few days after release day since users are graduated into the new distro.

The second suggesting is to get over the idea that you should upgrade forever. Ubuntu make a huge mistake (brought on by shear arrogance) by insisting on everything in one partition. This makes these mistakes even more egregious. As bad as the instabilities are, if the data is not protected by having home on its own partition, you not only angered your user with the crash, but put their data in danger. Leave the install exactly as it is, but make the default disk partition layout much more defensive. How about this rule for calculating it:

– Boot on sda1 and formatted ext2, it is 64mb in size, plus 12% of any extra space (space after all minimums are accounted for) up to a maximum of 512mb

– Swap is on sda5 and is equal to the size of RAM, plus 12% of any extra space up to three times RAM

– Root is on sda6 and is formatted ext4, it is 4.5gb in size, plus 26% of any extra space up to 40gb. This should be overkill for the average user, and well within safety parameters.

– Home should be LVM\’d and contain all the remaining space given to Linux.

These rules are not hard to implement! I have been suggesting them for years, and get geeks saying, \”but what if I don\’t want that configuration\”… well, your a geek, manually configure! This is meant to be the default for John Q Public. It builds a machine that will hopefully never go though the pains that Ubuntu just went through with Karmic, but if it does, can\’t some of the damage be mitigated when the end user realizes that all their files, settings, and whatnot are safely stored on a different partition. That having to reload the entire OS from scratch is still less painful than when the same problem occurs in Windows (and lets be fair, it happens even more often in Windows).

Sometimes its not enough to think you can prevent all the problems from occurring by strengthening the beta process. Bug reporting only works if you don\’t keep changing the software all the time (ifupdown -> network manager, pidgin -> empathy, etc, etc). Sometimes you need to play a little defense, a little ball control (you American football fans will understand that reference), to place yourself into the best position to attack what the Ubuntu community refers to Bug #1. Don\’t know what Bug #1 is? Look it up.

Just my $0.02


I have been reading and watching this debate with interest because, like many, I\’ve had about all the Microsoft that I can take. Linux is an exciting alternative for most of our servers and I am reading and trying to learn enough about it to deploy some test units. I loaded the latest Ubuntu release on a desktop and a server at the recommendation of a programmer friend who is a long time Linux user. Both machines had serious issues which cast doubt about the proposed switch to Linux. It was unstable. Thanks to the article read here, I learned it may be the release of Ubuntu and not all of Linux or all of Ubuntu. I then loaded SUSE 11.1 on the test machines and they are both stable and performing well. Thanks for the article, thanks to the community for the comments and input. They are all valuable as I try to learn as much as possible in a very short period of time.


I agreed with your first article, because I think that anyone that uses debian or a debian derivative must be drunk.

I have only briefly used dumbuntu, Why don\’t you put a delay on the updates, make the default 2 weeks or something. Have critical updates that bypass the delay, or have several options.

On a side topic. The people at linux-mag.com must be the drunkest people ever, don\’t they know that when the average user sees a site for the first time that is the impression they will get and keep. There are lots of great articles on linux-mag.com but all the delays and the occasional extremely stupid article get in the way and that is all the average user sees. Just because the power users will keep coming back and deal with the site, make excuses, turn a blind eye and wait. Because the average user just won\’t, they will say well this site is just broken. You can keep making excuses or whatever but it just doesn\’t cut it.

Because OMFG this has got to be the slowest website on the entire WWW. yes ill wait and read tomorrows articles too.


Now I may be missing something here but why do we need to upgrade every six months or whatever?

This is what the propriety software companies do in order to keep up their revenue streams: \”Look here is this year\’s shiny new model\” deliberately not compatible with last year\’s, so everyone\’s got to upgrade (and pay).

Here in the non-capitalist Linux world, we should be able to move on from this.

Can\’t we have a Linux distribution where we NEVER have to upgrade because every component:- kernel, applications, desktop, etc. are continually upgraded to the latest stable (well tested) release? Even then, only for new features or to fix something not just a new look.

Then, if something did break, you would probably have a good idea what caused it and might be able to roll back.



Good article.

I have personal experience that supports the first suggestion. I installed Intrepid for a friend on their work computer. He wanted to switch from Windows to Linux. But he couldn\’t just make the jump cold turkey. So we had Windows running in VirtualBox and he was learning to use Ubuntu for as much as he could, and resorted to Windows for only what he had to. Everything seemed to be working well for a month or so.

And then one day it all just stopped working. The machine started locking up every 15 minutes. There was no indication of kernel panic. Nothing in the logs. It was a complete mystery. But it got so bad that he could not work. He was having to reboot every 15 minutes, and he was clearly starting to get frustrated with \”this Linux thing.\”

Come to find out that he accidentally clicked the \”Upgrade\” button that one day appeared in update manager, it upgraded him to Jaunty which apparently had a horrible bug that was causing the problem. After rather painful searching, I found a bug kind of related to his problem was filed on LP, but despite the lengthy thread, there was no solution, nor even a clear idea as to the problem other than X was locking hard on some specific hardware. End result, I spent hours in the middle of my otherwise busy day restoring his machine back to Intrepid, after which we had a little training session on how not to ever click the \”Upgrade\” button.


Related to point one, Update Manager\’s upgrade message should be changed. I have over 40 years experience, and it \”tricked\” me into upgrading incorrectly. When I finally located the documentation (not a trivial task) at https://help.ubuntu.com/community/KarmicUpgrades, it says,

\”* Be sure that you have all updates applied to Ubuntu 9.04 before you upgrade.\”

That is probably the best way to do it, so Update Manager should at least prompt the user to bring the current system up to date before upgrading. The default should be to do the update before allowing an upgrade.



In my company we have regular users and test users.
The testusers have a subscription on the test release, and use the release while they know their system was upgraded with the newest release.
They know, by choice, that they are testers. And they are willing to send in those bug reports.
The regular users get the software on the official release date, when most bugs are really solved.

This is how a \”user\” software should be released.


Linux users who encounter problems with a new release of a free distro should not be surprised, and should be prepared (e.g., with backups) to deal with the fallout. Overall progress is faster if more people get involved in testing at the right time. Release too soon and there will be so many problems the support resources won\’t be able to keep up. Spend too long on testing and users who need new features or support for new hardware suffer. Application developers/maintainers need early access in order to ensure their software will work with newer kernels and libraries, which in turn benefits all users. Users are often advised to wait a few months before installing a new release. My advice is 1) test the new release in a virtual machine before installing it natively, 2) have a recovery plan if things go wrong, and 3) upgrade as soon as possible, but don\’t upgrade when a critical deadline is looming and give yourself ample time to install the upgrade and do troubleshooting.


As a relative n00b to linux – I got started with Ubuntu back around 5.10 or 6.04. I remember that I upgraded when prompted, fried my install, and was back running XP for 18 months before I had the time and energy to go back to Ubuntu. Once burned, twice shy.

Now I\’m learning my way around the CLI now, and most of our home computers are running linux – actually one *buntu variant or other (except my fiancee\’s MacBook which is running OS X and XP). I love linux, and am going further that way all the time.

I think that the community as a whole owes Chris a debt of gratitude for having the gumption to criticize one of the standard bearers for the linux community.

Ubuntu NEEDS to be criticized (honestly and accurately) precisely because it is so successful and so awesome. It is only by way of honest and open discussion that we can keep improving Ubuntu. Pretending that a problem doesn\’t exist will not help all of the brilliant minds involved to solve the problems that DO exist.

There are all kinds of technical issues that are way beyond my ken at the moment. What I can speak to more confidently is the issue of culture. Ubuntu has become an important part of the general Linux community and culture, and has quickly earned a strong reputation. But nobody\’s perfect, and if we are able to offer honest and constructive criticism, we can all help to improve. That\’s the whole POINT of the open source community – open and honest discussion of weaknesses and bugs – whether technical or strategic – allows the community to move forward.

Chris – the whole open source community – and Ubuntu in particular – owe you thanks for having the courage to hold Ubuntu to a higher standard. We must remember that the reason we are criticizing Ubuntu is precisely because it is already such an excellent system and such a strong community. Those strengths are what make it so very deserving of improvement.

Thanks again Chris – I hope your example will inspire others to offer constructive criticism in future.


The main reasons I prefer Fedora or Mandriva to Ubuntu is as was mentioned by someone, the one partition thing. Although I think you can customize it, Fedora and mandriva have the home folder on a different partion as default(if it didn\’t change, or if I remember correctly). Also, I don\’t like the fact that my root password is the same as my user password. I prefer Fedora\’s and Mandriva\’s su to the sudo and my user password. I feel more secure having 2 seperate accounts/password. And the main reason I prefer Fedora to mandriva is I can get firestarter to work in fedora. Read all docs on how to do it in mandriva, but their fix doesn\’t work for me. Fedora with RPMfusion packadges does it for me. I think Fedora should be the most popular desktop or shipped OEM. Ubuntu is too M$ like in my humble/newbie opinion in the security department.


People who do not like Ubuntu should use something else instead of trying to change it into something that it isn\’t. I run Ubuntu and Kubuntu from alpha to final without any problems save a few crashes in the early stages. I have done both the upgrade and a clean installation on more than one computer without a hitch.

This does not mean that others don\’t experience problems, but they would likely experience problems with other distributions because the hardware is not well supported outside of the OS that came with it. Most of the problems that I have seen have been easily remedied. I help on several forums and we have not seen any increase in problems. Certainly there are far fewer than last spring when many people experienced problems with graphics due to kernel changes and having ATI or Intel driver problems.

I like things the way they are. Ubuntu is not competing with Debian but with Fedora and more bleeding edge distributions. If they slow down then they risk getting left behind, the way Debian, PCLinuxOS and MEPIS have. Mediocrity serves nobody, except a small few who crave stability at all costs.

Ubuntu is what it is. Linux has over 300 distributions, so pick one that suits you and stop whining.


Some people make comparison between Ubuntu and XP, for instance. Here\’s a big difference. XP is really old, yet many people using are running the latest Office and Firefox. So they have a mature, stable operating system with the latest applications. That\’s what you can\’t get with the Ubuntu approach. Every six months, Ubuntu releases a new universe and abandons the old one,and you can\’t get a universe working in only six months.



You must be deaf. This article is pointed at the average user experience. The average user has no desire nor inclination to do all of that for an upgrade. Whether or not they should is beside the point-they don\’t and are not going to, not on Windows, not Ubuntu or any other distro and not on a Mac.

The ideas that are presented in the article and various posts that the distro (and developers) protect the users from themselves and from buggy upgrades are the only way to ensure or at least minimize bad user experiences. Why do you think Windows is so popular? If we want broad adoption then we must take that approach to some degree.

So what if the developers don\’t get to put out their shiny new updated driver to average Joe when s/he wants to? If it breaks the user\’s machine it is worthless anyway and creates an unhappy user who will promptly return to what he trusts: Windows. And no it doesn\’t matter if Windows breaks just as much so can that argument. The average Joe user is not going to listen to it and trusts Window. A known problem is better than an unknown solution in his/her eyes.

My vote: Don\’t give the average Joe users a chance to upgrade until the frozen beta (they do freeze ubunutu don\’t they?) is extensively tested and fixed by the community that WANTS to do the testing. Make the LTS versions the default version. The people who want bleeding edge are going to find it. After all Red Hat does it like this and is a very profitable company.

My .02 worth.


I\’m not your biggest fan (your last article was a disgrace) but…

>The first is for the update manager to not prompt the user to upgrade until the stable release has been out for a month (or whatever time frame works. It could even be dynamically flagged when ready).

Yes I would agree with that one – I do clean installs so I actually thought Canonical did this delay thing (by at least a week, but I could be wrong).

>Secondly, it seems to me that many of the problems faced with a new version of Ubuntu are due to the fact that it’s a time based release.

Completely wrong:
1st remember they have delayed a release once (6.06 LTS – Dapper Drake).

2nd The WHOLE point of Ubuntu is the six month release cycle – that why we use it and why it is so popular. Large repositories of up to date packages all built to work against the latest Ubuntu release.

Its a trade off, if you want to play it safe go LTS, if you want all the latest toys and up to date packages you pick the latest and greatest.

If you are the administrator of your machine you have a responsibility to do your homework, to decide what is the right Linux distro for your particular set of circumstances. If you have looked into Karmic and read the reviews and release notes you would be aware that they were being very ambitious, ext4, GRUB2 new gdm etc… also that with a LTS due next anything new was going in _this_ release.

I think they got it right on most of the calls, although no x failsafe in the new gdm may have been a little close to the line ;)


Chris was right on with this article and with the previous one though it came on way too strong at the beginning.

I like the ideas presented here but suggest a variation. How about freezing the RC at the beginning of the release month with the scheduled release near the end of the month as it usually is. But also let the Update manager have an upgrade button for the RC along with a warning about the danger and a request for testers. That gives 3-4 weeks of testing with more users during which there is a strong focus on fixing problems rather than adding/changing anything.

Development and Design teams who want to add or change features would then move to working on the NEXT release and STILL get 6 months to work on that. Obviously some of these folks would also be called upon to work on fixes for this release, but that basically happens anyway.



\”Mark Shuttleworth, said he had seen no sign that there were any major issues with hard drives, defaulting to older kernels or encryption. \”I\’ve no doubt there are regressions but none that have yet crossed the threshold to \’widespread consequence\’,\” he added.

The blank and flickering screens on boot have been identified as being caused by a missing kernel module and this was experienced by users who had computers with video cards that use nvidia chips.

from here:


See mr Smart? such a different attitude from your readers by writing something in a better way. Essentially you\’re saying mostly the same, but in a constructive manner, and this time its a whole different kind of comments the ones you\’re getting.

Food for thought.


owensmk said:
> End result, I spent hours in the middle of my otherwise busy
> day restoring his machine back to Intrepid, after which we had
> a little training session on how not to ever click the
> \”Upgrade\” button.

I guess your friend must have entered his password before he allowed this disaster to strike. Entering your password anywhere tends to get you in trouble in Windows or OSX as well.



I upgraded a week or so ago. Since than, there have been a number of significant downloads, a new minor release of the kernel, etc.. DNS is now finally working, the default autofs (automount) works and I have buried my custom version, nis still does not work correctly (it has never done so on Ubuntu or any other Debian release, at least for me) but NFS is working fine. Gnome works better and mostly remembers what I did (I save the desktop to a directory just in case). Authentication is still iffy. Also, the upgrade scripts still mess with files in ways that should not be (eg., /boot/grub/menu.lst, /etc/resolv.conf) but this has always been this way and is also true in OpenSuse.

I will reiterate what I said before; this is more reminiscent of a MS Windows update/upgrade with lots of rough edges in basic operation. What I mostly object to is not that I can fix most of it with either custom scripts or custom modification of source but that the average user would be at a loss. Apple has steadily done better in recent years due to the hassles and incompatibilities with MSWin updates and upgrades. For Linux to succeed it will have to approach the minimal rough edges of an OSX upgrade and eliminate the onerous price gouging for updates and basic utilities rampant in both the Apple and MS worlds.


For those of you supporting non-technical users, it\’s possible to limit the upgrade prompt to LTS releases, and I believe disable it altogether. My preference would be to download security updates automatically and not even show them the update manager at all.

Anyway, my opinion is the upgrade process is too monolithic. You\’re upgrading hundreds of packages at once, in massive permutations that the distributor can\’t possibly foresee all of. One thing I both miss and don\’t miss about Gentoo is the rolling upgrades. Generally you were only upgrading a small part of your system at a time. That made it easier to tell what broke and roll it back, but it also meant every daily update had the potential to break something.

I think a hybrid system would be ideal. First, upgrade the kernel and all the modules, reboot, and run some automated tests or even prompt the user to see if something broke. If it did, then roll it back automatically. Similar to when you set a new screen resolution and it has the countdown before reverting, just in case you screwed it up so bad you can\’t see to fix it. Next, update X, then gnome, then other applications in a similar manner. Maybe not that exact sequence, and it\’s obviously much more complex than that, but you get the idea. If any of the stages fails, it guides you through a bug reporting process if you want, and asks you to wait to upgrade.


Much better article – I was wondering if the original article was output from the M$ propaganda machine.

Open source is bleeding edge by its very nature. It must continually push the envelope.

If inexperienced users want stability then they simply don\’t upgrade or only upgrade to LTS releases.
But if inexperienced users want to keep up with the latest then they must accept the risks of this.
A warning dialog should inform of the risks inherent in non-LTS system upgrades and to backup, backup, backup!
Perhaps there should be an option to test out the upgrade in a live CD form prior to a real install?
Alternatively they could pay and take their chances with M$ or Apple but that\’s no guarantee either.
Its amazes me how well Ubuntu does compete on quality compared to those corporates.
Perhaps we need to give Ubuntu a bit of slack – is perfection achievable?

Open source will win in the end.


Ubuntu\’s failure to put out a dependable product is a result of the team\’s increasing dependence on strict timing. Ubuntu has always been a six-month release, but if you look at the history ( http://en.wikipedia.org/wiki/Ubuntu_%28operating_system%29#Releases ), there has been a trend toward planning releases later in the month. Early releases didn\’t have a set day for release, instead being promised some time in the month. When the countdown banners were introduced, the policy was changed. This coincided with a tighter and tighter release policy.

In fact, 6.06 slipped two months because of release problems. As a result of the slippage, 6.06LTS was a solid release, unlike 8.04LTS, which _should_ have slipped, but didn\’t, and had a myriad of problems (e.g. F-Spot, a default application, failing to run on AMD64). 9.10 had known issues, but the release date was set for 09.10.29, giving two days of possible slippage. 10.04 is also scheduled to be released on the 29th, giving _one_ day to slip. This is silly management.

Ubuntu should move to a six-month release cycle with a one-year development cycle. 10.04 should be entering beta _right_now_ and development should be starting on 10.10. Branching should make this process simple. The releases should be planned for the beginning of the month they are scheduled for, and _all_ critical bugs should be cleared before release.

I\’d also like to see a more formal testing team for Alpha and Beta releases — a few days of general testing is not enough[1]. Right now, the testing is very hit-and-miss. Common hardware setups need to be represented and tested. A database of these tests needs to be kept.

[1] \”A few days before the release of any Ubuntu CD (including alphas, betas and release candidates), we download copies of the latest daily ISO images, burn them to CDs and test them. This brings to light many issues that might have been missed by other early adopters and developers, especially in the CD builds and installers.\” https://wiki.ubuntu.com/Testing


\”Non-LTS versions of Ubuntu are more bleeding edge…\”

Comments like this in your article and the comments as a whole here make me wonder if people really do remember what\’s going on with this distribution.
8.04 was a mess. My employer had me deploy this on a sizable scale (about 30 machines) for testing and it was a nightmare. Firefox 3 was brand new and was still unstable (and crashed with almost predictable frequency), we experienced problems with X on numerous work stations, and general application failure was rampant. Three months in, my client base knew what \”apport\” was, but weren\’t aware their desktop was GNOME or any other feature not blatantly obvious. Apport should not be obvious to the general user base.

As a whole, I agree with the article and that is exactly why you, me, and other experienced users need to begin using the Alphas as soon as they are available. Report those bugs and stay on top of those issues you\’ve reported. It\’s a lot of work sometimes, but I do it. And I do it because I really like this distro.

I think the greatest thing Canonical can do would be to organize free (or very inexpensive) classes on C programming and tutorials on the inner workings of the distribution so that those of us who are interested in contributing fixes don\’t have to crawl through years of Linux evolution on our own.

I\’m a member of the Texas LoCo and we are really struggling to get our stuff together (though I think we may have things worked out in a few months). I\’d love to see the LoCo\’s become bug busting splinter cells of the Ubuntu development teams. And that\’s where the paragraph above comes in.

And I wholly agree with daengbo on the development cycles. Six months is just not enough to bring together something as complex as Linux distribution.


freedom? anyone?


mmm… i think so.

this particular phrase sucks: \”Our users want to use the software, not to find bugs and report them.\”

what about collaborative work?

Ubuntu users don\’t care about what really matters… puaj!


I\’m just not seeing it – I\’m sorry.

First of all, perspective please. This upgrade had some real problems . . . but lets compare that to the genuine competition for problems, say an operating system that was sold, installed, on hardware that was supposedly \’Vista Ready\’ . . . and *still* didn\’t work.

Second of all – delay the release for most people? That\’s like saying \”I always find my keys in the last place I look . . . So I\’ve started looking there first!\”. Sure – that would solve all kinds of problems!

There may be a number of smart ways to do items – I can even imagine a system that lets you set you\’re auto upgrade option.

When Would you like to automatically upgrade to the next version of Ubuntu?
O Paranoid (Manual Only)
O Very Cautious (Long Term Service Only)
O Cautious (Launch + [14] Days)
* Reasonable (Launch Day)
O Beta Tester (Launch – [14] Days)
O Alpha (Option to update manually as soon as RC is set)

That might not be insane. But as a general default case? You\’re just putting off the inevitable.


Chris, your last article was inappropriate and offensive, it is a disgrace to Linux Magazine, and repels readers. This article is not a sufficient apology and does not make up for it, especially as the previous article is still being promoted offensively on the front page of the website, with a big ugly picture of you, making you look like an idiot and this magazine look like a piece of trash.

How can we help to ensure that new users get the best experience possible? Perhaps Ubuntu could ship with a virtual grinning \”Chris Smart\” doll which we could tear to pieces in inventive ways. That would improve my experience as a user.

Apologise properly.


(I find it offensive that some readers of this article find any discussion of a real problem to be offensive. So there!)

There is essentially one reason why a person would upgrade or install Ubuntu: to have a computer that is running well.

Conceivably, many people install Ubuntu because of some dissatisfaction with Windows or simply because they are curious; and some people upgrade because of curiosity… but the underlying fact is that everyone is expecting their computer to work reasonably well post-op.

I have been bothered for years that Canonical\’s and Ubuntu\’s marketing people haven\’t understood a very simple fact of how to market \”come back again\” services:

Don\'t oversell your product

Karmic is not (and Edgy and Breezy and Feisty, etc., were not) for general consumption. It is for hobbyists and hackers. ALL non-LTS releases are for hobbyists and hackers. It should not be promoted as a \”release for the common good of humanity\” – because it isn\’t.

But marketers seem to think that hyperbole is the only way to talk. So they\’ll tell you something is the greatest thing since Fortran… because otherwise they think no one will pay any attention to the new product.

The Ubuntu community would do well to remember that hyperbole is rarely useful, especially when you have to deal with its aftermath. The Ubuntu community and Canonical in particular should be VERY careful to let newbs and even the somewhat experienced know that upgrades and installs are serious business.


Well, it seems to me that the most efficient testing actually takes place by endusers. So, postponing by a month will postpone thorough (though unsolicited) testing by another month etc.

If Ubuntu could be tested by the development team alone, by all means drop this 6-month schedule and deliver only stable stuff. I suppose however that the combined effort of (unwilling, if not unaware) users is necessary.

BTW, Jaunty was a real nuisance, Karmic is a relief for me (and my computer/printer system).

What would certainly be nice is a deinstall option towards a previous release.


This does not explain why Ubuntu put the buggy Kdevelop beta5 in the release against the wishes of the Kdevelop project, and made Kdevelop look bad. Why refuse to put in a stable release of Kdevelop?

If Ubuntu really cared about quality it would have put in the latest stable release of Kdevelop, and the lastest beta.

Here is a rant by the Kdevelop people telling everyone to stay away from ubuntu 9.10 because of it:



Thanks for your comments.

This article was not an apology, so perhaps that goes some way to explaining why it wasn\’t a good one.

Certainly my previous article was worded very strongly and it was not my intention to offend people, however I make no apology for its content.

Also, I have nothing to do with the choice of picture on the front page (and no, it\’s not me). As far as I know, the list of articles which appears there is automatically generated.

This article was, like the poll, rather self-selecting in its audience and naturally the majority of readers who felt compelled to leave a comment disagreed with the article. That\’s not to say that everyone did, however, as the comments also show.



Wow. To see a reporter backpedal from what what essentially an opinion piece combined with a troll to promote forum activity is pitiful but speaks volumes about the readership here.

Congratulations linux thugs. I now picture linux zealots more like a country police department that flogs its detractors with battons than long haired Stallman-types.

Your transition to the dark side is nearly complete.


I have done some checking and there are some hard numbers in this article:
\”TuxRadar by the numbers 2.0: the rise of Karmic\”

The bottom line is that the vast majority of Ubuntu users upgrade almost straightaway.

55% of their Linux users use Ubuntu and of that 65% have upgraded to Karmic already.
If this is broadly followed by most users then approximately 6.5 million users have successfully upgraded.
Hopefully this helps to put things in context.


This piece fleshes-out the missing parts of your previous piece in a way that better helped me understand where you were coming from, so thank you.

I really agree, and further the idea that Canonical make the LTS release the default download. They can easily add an aside about the latest release, what it offers, and even link to some specific help forums topics so that their users can make a better-informed decision and have an idea of what to expect.

Moreover, however (and this is were I begin talking more to Mark Shuttleworth and not you), is the impracticality of a six month release cycle… They really _ought_ to employ some _consistent_ flow-chart/performance metrics in deciding the _when_ of a release. An open-ended goal of six months is fine, but people will appreciate it more when there are a consistent set of goals for delivering a useful system that meets a documented and public set of performance goals…even when it is three months late.

I totally understand the drive and desire behind Shuttleworth\’s six month release cycle…the typical Debian release cycle will simply not deliver on his goal of an OSX-killer in the shortest possible time. That being said, however, the six month delivery cycle must be balanced against the realities of the user space; people NEED to USE their computers every single day. It won\’t do in the long term to bork the user experience a few times too many and still expect to maintain the good (and very public) name of the Ubuntu brand when they are really onto something that is frikkin\’ awesome down the road. READ THIS, MARK! IT IS IMPORTANT!

* People NEED to USE their computers to DO WORK! Don\’t mess it up!

* Qualify your releases in English that can be understood by your target users.

* Don\’t become \”hit and miss\” in the public eye. Study and Learn the lessons of Vista.

* When it comes to six months or consistency always opt for consistency! The opportunities for a second chance to make a first impression are typically slim.

I am not a huge Ubuntu fan, and I can go either way on this. My server runs pure Debian Stable for a (very important) reason. Please take this to heart.


@justwally, it\’s a hard thing to achieve and I don\’t envy Canonical for it. Some are suggesting a 6 month release which has been in testing for a year. So right now Lucid should have been in testing for the last six months, with the next six months being the final squashing. It would also mean Lucid+1 would begin now.

Seems reasonable to me, except that you are running an older version of everything, which is what Canonical is trying to avoid. Still, I think this would make Ubuntu much more stable. I agree with your main \”important\” points.

Thanks for the comments.



@silverwave, thanks for the link, those are some very interesting patterns.

Less than 5% are using LTS and most users do appear to upgrade straight away. Even so, that doesn\’t mean they didn\’t have any number of issues doing so!



I must apologise beforehand if my comments seem too naive but this was what I experienced over the past two years (and thus makes me totally agree with csmart).

A few friends of mine and I run these informal \’ubuntu promotion campaigns\’ in our college promoting Gnu/Linux among students by installing ubuntu in their compuuters and informing them regarding the reasons they must make a switch from Windows. But that is just the beautiful part; for atleast another two weeks from that, we are busy sorting out issues (everything from missing sound to flashing display) in their computers. Worse still is when some packages go missing in newer versions while they were up-and-running in the previous versions. This only ends up in them asking us if it is common for Gnu/Linux distros to be so buggy.

So, I believe, ubuntu really needs to look into this aspect in future if it is to be trusted on par with Debian and the rest.


Enough of the \’hate mail\’, I must admit I was shocked with the \”…stop making linux look bad…\” article, fair enough, you were absolutely right. My \’man\’ Karmic Koala is giving me headaches, all you did was make constructive criticism which I applaud. We can\’t be hypocrites, 9.10 has issues, a lot of them, but I still love Ubuntu, with all my heart, and I am sure the people at canonical and the entire community will somewhat contribute for it to become a more stable release.

My Ubuntu Software Center has a bug, I try to report it, and Ubuntu won\’t allow it, it forever tells me the darn thing cannot be reported, \”check your connection\” it says, yeah right, my connection is working fine…

Let\’s all work together and stop hating, csmart\’s suggestions make sense. The avg user\’s alarm triggers whenever he sees an update is available. We are not MS (auto update), This is a totally different scenario (open source = free will)… If you guys get what I mean.


I love Ubuntu and think the six-monthly release cycle is an important part of its popularity. But I agree that buggy releases are going to put new (and not so new) users off and on my upgrade to Karmic my screen resolution fell from 1440×900 to 800×600, flash stopped working etc etc. While encouraging people to hold back a little before upgrading makes sense, isn\’t there a danger that that just puts the discovery of problems back a month or so? Perhaps the RC version could at some stage before official release be flagged by the update manager – with a clear warning about potential instability – to encourage a wider testing base before release to the masses. Clearly the more popular Ubuntu becomes the wider the range of testing is required. If people know they\’re involved in testing they\’re less likely to be upset by problems and – importantly – more likely to report bugs fully.


I agree with Chris, I upgraded to the latest version as a test on another desktop and I hated it. Sticking with version 9 for now.

Leave a Reply