Linux: Upgrading from Hoary to Breezy
Last week I spent two days making backups to DVD-Rs for my preperation to upgrade to the new Ubuntu Linux. I basically compressed folders with tar and copied them to a DVD. The pain was that I would have to guess or go through trial and error to get images that were less than 4.2 gig in size so they would fit on a DVD.
At the same time I did
The process was full of errors because of my language settings. It decided that I am using the language en_BR (for English/Brazilian). Which is sort of correct, but it probably wants en_US or pt_BR, which is more common. The install didn't actually fail, it would just complain and then use the US language. So with some trepidation I ignored the messages.
Then it found some configuration files that I had modified that it wanted to overwrite. It did the right thing and offered to keep it, overwrite it or look at the differences. One thing it didn't allow is to manually edit the differences with a merge/difference editor. In most cases I let it overwrite.
But there was one case where I had made a bunch of changes and wanted to keep some of them, and, as luck would have it, it offered to use the 3 way merge (very experimental). I guess it was too experimental, because when I finished merging it quit the upgrade.
For some reason I thought everything was ok and decided to reboot the machine to make sure it's 100%. Well it wasn't and it rebooted to a non-graphical login shell, ouch.
I logged in and started playing with apt-get again and it offered some good advice on exit. I think it said something like try the -f command. Sure enough that resolved things. More installations and another reboot and I was back in Gnome with graphics and everything, phew.
But everything wasn't 100%, but again I often got useful error messages indicating what was wrong and how to fix it.
What I have often thought the most important difference between a good program and a great program is how it handles errors. A great program handles common errors gracefully and indicates how it might be solved as well. With Linux I think you seem more of this because
At the same time I did
sudo apt-get dist-upgradeto upgrade my Linux. This also took about two days of downloading. It took longer because my Internet service provider likes to kill my connection so that I need to turn the modem off and on and then type
ifup eth0.
The process was full of errors because of my language settings. It decided that I am using the language en_BR (for English/Brazilian). Which is sort of correct, but it probably wants en_US or pt_BR, which is more common. The install didn't actually fail, it would just complain and then use the US language. So with some trepidation I ignored the messages.
Then it found some configuration files that I had modified that it wanted to overwrite. It did the right thing and offered to keep it, overwrite it or look at the differences. One thing it didn't allow is to manually edit the differences with a merge/difference editor. In most cases I let it overwrite.
But there was one case where I had made a bunch of changes and wanted to keep some of them, and, as luck would have it, it offered to use the 3 way merge (very experimental). I guess it was too experimental, because when I finished merging it quit the upgrade.
For some reason I thought everything was ok and decided to reboot the machine to make sure it's 100%. Well it wasn't and it rebooted to a non-graphical login shell, ouch.
I logged in and started playing with apt-get again and it offered some good advice on exit. I think it said something like try the -f command. Sure enough that resolved things. More installations and another reboot and I was back in Gnome with graphics and everything, phew.
But everything wasn't 100%, but again I often got useful error messages indicating what was wrong and how to fix it.
What I have often thought the most important difference between a good program and a great program is how it handles errors. A great program handles common errors gracefully and indicates how it might be solved as well. With Linux I think you seem more of this because
- Linux programs are often written by great programers on their spare time.
- Linux users give good feedback early and often which helps evolve the program to perfection over time.
- Users sometimes become developers. What sometimes happens with shrinkwrapped software is that the software becomes abandoned or nearly so, so that bug fixes and improvements slow to a crawl. This may be because the company is focused on other things or a key developer has left or for a miriad of reasons. Users who use the software have basically no recourse, but to wait for a competitor to step in and make something better. But with open source software, however, they can take take the torch of the project keep improving it, if the original developer has left.
Comments