Comments on: Two Simple Suggestions for Ubuntu http://www.linux-mag.com/id/7607/ Open Source, Open Standards Sat, 05 Oct 2013 13:48:18 +0000 hourly 1 http://wordpress.org/?v=3.1 By: auspex http://www.linux-mag.com/id/7607/#comment-7382 auspex Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7382 <p>\"Perhaps some readers jumped the gun when they saw the title and didn’t read the whole article\".</p> <p>You think? Or perhaps they saw an inflammatory headline and an almost entirely negative article. </p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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. </p> \”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.

]]> By: csmart http://www.linux-mag.com/id/7607/#comment-7383 csmart Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7383 <p>Just because Karmic might have been the cleanest so far doesn\'t mean it\'s good enough.</p> <p>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.</p> <p>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.</p> <p>-c </p> 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.

-c

]]> By: csmart http://www.linux-mag.com/id/7607/#comment-7384 csmart Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7384 <p>Oh, and I didn\'t say backports and PPA weren\'t \"a solution\", I said they weren\'t a good solution to this issue.</p> <p>-c </p> Oh, and I didn\’t say backports and PPA weren\’t \”a solution\”, I said they weren\’t a good solution to this issue.

-c

]]> By: pmorton http://www.linux-mag.com/id/7607/#comment-7385 pmorton Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7385 <p>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. </p> 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.

]]> By: rbsjrx http://www.linux-mag.com/id/7607/#comment-7386 rbsjrx Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7386 <p>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)? </p> 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)?

]]> By: timrichardson http://www.linux-mag.com/id/7607/#comment-7387 timrichardson Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7387 <p>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. </p> 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.

]]> By: gdonwallace http://www.linux-mag.com/id/7607/#comment-7388 gdonwallace Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7388 <p>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. </p> <p>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. </p> <p>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\". </p> <p>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. </p> 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.

]]> By: ttchopper http://www.linux-mag.com/id/7607/#comment-7389 ttchopper Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7389 <p>@gdonwallace - What Chris is suggesting first isn\'t the same as what you\'ve said at all. </p> <p>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. </p> @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.

]]> By: sgsax http://www.linux-mag.com/id/7607/#comment-7390 sgsax Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7390 <p>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. </p> 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.

]]> By: textnotspeech http://www.linux-mag.com/id/7607/#comment-7391 textnotspeech Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7391 <p>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. </p> 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.

]]> By: kfries6 http://www.linux-mag.com/id/7607/#comment-7392 kfries6 Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7392 <p>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:</p> <p>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.</p> <p>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:</p> <p> - 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</p> <p> - Swap is on sda5 and is equal to the size of RAM, plus 12% of any extra space up to three times RAM</p> <p> - 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.</p> <p> - Home should be LVM\'d and contain all the remaining space given to Linux.</p> <p>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).</p> <p>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.</p> <p>Just my $0.02 </p> 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

]]> By: stoggy http://www.linux-mag.com/id/7607/#comment-7393 stoggy Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7393 <br />

]]> By: fsweet http://www.linux-mag.com/id/7607/#comment-7394 fsweet Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7394 <p>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. </p> 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.

]]> By: stoggy http://www.linux-mag.com/id/7607/#comment-7395 stoggy Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7395 <p>I agreed with your first article, because I think that anyone that uses debian or a debian derivative must be drunk.</p> <p>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.</p> <p>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.</p> <p>Because OMFG this has got to be the slowest website on the entire WWW. yes ill wait and read tomorrows articles too. </p> 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.

]]> By: jdt http://www.linux-mag.com/id/7607/#comment-7396 jdt Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7396 <p>Now I may be missing something here but why do we need to upgrade every six months or whatever?</p> <p>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).</p> <p>Here in the non-capitalist Linux world, we should be able to move on from this.</p> <p>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.</p> <p>Then, if something did break, you would probably have a good idea what caused it and might be able to roll back.</p> <p>John </p> 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.

John

]]> By: owensmk http://www.linux-mag.com/id/7607/#comment-7397 owensmk Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7397 <p>Good article.</p> <p>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.</p> <p>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.\"</p> <p>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. </p> 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.

]]> By: rplantz http://www.linux-mag.com/id/7607/#comment-7398 rplantz Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7398 <p>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,</p> <p>\"* Be sure that you have all updates applied to Ubuntu 9.04 before you upgrade.\"</p> <p>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.</p> <p>--Bob </p> 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.

–Bob

]]> By: henkdaalder http://www.linux-mag.com/id/7607/#comment-7399 henkdaalder Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7399 <p>In my company we have regular users and test users.<br /> The testusers have a subscription on the test release, and use the release while they know their system was upgraded with the newest release.<br /> They know, by choice, that they are testers. And they are willing to send in those bug reports.<br /> The regular users get the software on the official release date, when most bugs are really solved.</p> <p>This is how a \"user\" software should be released. </p> 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.

]]> By: gnwiii http://www.linux-mag.com/id/7607/#comment-7400 gnwiii Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7400 <p>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. </p> 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.

]]> By: mpetrachenko http://www.linux-mag.com/id/7607/#comment-7401 mpetrachenko Wed, 30 Nov -0001 00:00:00 +0000 http://www.linux-mag.com/id/7607/#comment-7401 <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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.</p> <p>Thanks again Chris - I hope your example will inspire others to offer constructive criticism in future. </p> 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.

]]>