A quick search through Google and I find more articles talking about how slick the new release is or how fast it starts up and shuts down. If these articles are anything to go by, then the developers have clearly met one of the goals set by their BDFL, Mark Shuttleworth: Shorter boot speeds, some as short as 25 seconds, ensure faster access to a full computing environment on most desktop, laptop and netbook models. But I fear that the developers have focused on these goals too much that they lost focus on two of the most important things for (most) end users: system stability and seamless upgrades.

I have been using Ubuntu since the very first release (Ubuntu 4.10) and I have used every single release since then. I use my computer for 8 hours a day at the very least. I have several projects that I maintain and file system integrity is very, very important for me. System stability is something that I expect from a “stable” release. Almost all of the Ubuntu releases so far have been very stable. The 8.04LTS release had a few issues with Flash crashing under 64-bit Firefox and Wi-Fi would die abruptly and get back up again but that’s about it. The 8.10 release had a very annoying kernel bug that took 5 months for a fix to be released.

Upgrades between releases have always been pretty painless for me. I don’t do a lot of funky stuff like installing packages directly from sources and certainly none of that “automatix” crap. Upgrades via “Update Manager” have always worked for me, with very few problems. I have come to depend on the fact that I can simply fire issue an update-manager -d and everything falls into place more or less correctly. At the end of an upgrade the most that I needed to do was to tweak a few config files, re-enable some repositories that were disabled during the upgrade and I’m done.

The upgrade process from 8.10 to 9.04 went without a hitch. I would even be inclined to say that it was flawless. What disappoints me so much to the point of frustration was that the apparently flawless upgrade had a couple of very nasty gremlins under the hood. When I rebooted my laptop after the upgrade, the Bluetooth light. It did this every single time I booted up. It is not supposed light up if I had it off when I shut down. The much touted 25-second boot up time was a no show. Boot up speed was more or less the same for me.

On my first boot up after upgrading, I was about to update my Medibuntu packages. After hitting “Reload” on Synaptic, it complained about not being able to write to the file system because it was mounted as “read-only”. Uh-oh! This could only mean one of two things: full disk or file system corruption. I thought that this was only a post-upgrade hiccup and it should go away on the next reboot. I rebooted, cleaned up my APT package cache to make sure that I had enough disk space on my root file system and I was able to update the Medibuntu packages.

The next day, I spent most of my time trying to figure out how to turn off the damned Bluetooth light which seems to come on every time the ACPI subsystem was initialized on boot. The config files I tweaked required me to reboot in order to see if they worked in keeping the Bluetooth light off. At one point, rebooting caused fsck to run and it reported that my root file system had errors that needed a manual fsck. I ran fsck manually and there were quite a lot of errors that needed fixing, mostly having to do with unused inodes. During the repair stage, one of the libsvg library files were hosed, causing startup of some of my GNOME panel applets to fail. I reinstalled the library and that fixed it. A couple more reboots and I then fsck was forced to check my home partition because apparently, it was not unmounted cleanly. Boot-time fsck failed with errors and required me to run it manually. In the manual run, it reported a whole lot of unused inode errors, several superblock errors, and directory errors. I lost one photo file in my F-Spot Photos folder. I was starting to get really nervous now. All my project repositories are in my home partition. I can’t afford to lose any of those files so I decided to take a snapshot and dump it on an external hard disk.

I spent all day long rebooting and running fsck. This was because something would crash at some point because of some library not loading. At one point I even ran memcheck to see if it wasn’t my memory. This laptop is only about 7 months old and I would be really disappointed if this was caused by hardware failure. In my previous experience, file system corruption was usually caused by a bad memory stick. Fortunately there were no problems reported by memcheck. fsck with bad blocks checking reports no bad blocks on my hard drive. I can only come to the conclusion that this is a software problem caused by the upgrade. After several more crashes and fsck runs reporting more of the same thing, I was frustrated and I finally gave up. I downloaded the ISO image for Ubuntu 8.10, hoping that it would not crash during download and completely hose my home file system. I had no choice at this point and I wiped my root file system and installed Ubuntu 8.10, which surprisingly caused the Hibernate function to work.

It was a really disappointing and frustrating experience. I think the Ubuntu team has succeeded in their goal of trying to out-Windows Windows. This latest release was so unstable that it made me long for the good old days of Windows ME. This unhealthy obsession with faster boot and shutdown times is causing them to lose focus on system stability and seamless upgrading. I can’t see how having the fastest boot and shutdown time will help make Ubuntu any more useful than it is right now. I don’t really give a flying fart if the OS boots in 25 seconds or 25 minutes. I don’t really care about how slick the on-screen system notifications are. All I really care about is a clean, stable, easily maintained and easily upgraded operating system that does not play Russian Roulette with my files. Hopefully the Ubuntu team gets through this “my OS can boot faster than yours” phase and start working on the more important things. Otherwise, we will all be stuck with an OS that can do nothing more than boot and shutdown: Really fast.

Side note: A “Jackalope” is a mythical creature and sightings of this creature have been attributed to rabbits infected with the Shope Papilloma virus. I think the codename really suites the 9.04 release. It’s a beast that has sprouted some rather curious but completely useless appendages at the expense of being healthy.

a

It’s been quite a spectacle ever since I saw that security vulnerability report on the NVD RSS feed. Even though the bug has been patched and fixed, system administrators are now left with the task of cleaning up the mess. It would have been OK if it only affected Debian and Debian-based systems. But it turns out the damage is far reaching. Even if you don’t run Debian, if you are using SSL certificates generated by a CA who generated the certificate using a Debian system, your SSL certificate will have to be revoked and replaced! See here.

Amazing what a couple of lines of code can do.

a

For a Beta release, Firefox 3 is pretty solid and feels really fast. I haven’t had nspluginwrapper crash on me yet, as opposed to the previous version which would crash from time to time especially when viewing sites with multiple Flash movies. Hopefully, Evolution mail client crashes have been fixed in this LTS release. It’s caused me a lot of grief before when it would crash randomly and then keep crashing when I restart it.

Desktop effects still suck though. When I enabled it, I still get that ugly black screen flash whenever I start Firefox. The new clock applet finally supports multiple timezones, very useful since I deal with clients in different timezones.

Two apps the I use a lot, Wine and Cinelerra, both have repositories for 8.04 so it looks like I have everything I need. Overall it feels like a solid release worth of the “LTS” designation.

a

For about half of what it would have cost me about 3 months ago, I was able to get a pretty decent (for my purposes) rig based on an Intel Core 2 Duo processor. Fortunately, I was able to keep all my IDE hard drives so that cut the costs even further. But my new motherboard has only one IDE port, the rest are all new stuff like SATAII and PCIe. The motherboard is based on Intel’s 945G chipset and as far as cheap motherboards go, it looks like a pretty solid board. I have no need for a new graphics card (yet) as I don’t have any “must play” games right now. Come to think of it, it’s been a while since I last played games on a PC since I got a PS2.

What I ended up with for PhP 17,000:

• Intel Core 2 Duo E4300 (from what I read on Intel and hardware review sites, this chip is now discontinued which explains why I got this one for half of its initial release price)
• ASRock ConRoe945G-DVI motherboard I had to bump up it’s factory-installed BIOS because it kept resetting my S.M.A.R.T. settings for the hard drive)
• Funky looking ATX case that whines like a dying animal when its chassis fan is turned on.
• 4 512MB DDR2 memory sticks

I was able to reuse my old IDE drives. Too bad I could use only one of them. The two remaining hard drives are relegated to “backup storage device”.

As usual, it’s a dual-boot setup with both Windows XP Professional SP2 (32-bit) and Ubuntu 7.04 (64-bit). I really notice the performance difference between the 32-bit and 64-bit versions of Ubuntu. I tried both versions to see if there was any perceptible difference. Suffice to say, things are a lot snappier on 64-bit. As expected there were some problems with apps that stubbornly refuse to go 64-bit (Adobe Flash, JRE plugin). But nothing that a quick visit to the Ubuntu Forums didn’t fix.

Overall, it’s been a pretty good experience running 64-bit as a first class citizen…

a

a

One other thing I noticed with the recent upgrade is that shutdown seems to hang randomly. I have seen this behavior before on my desktop and it was due to an APM bug in my BIOS and it would happen consistently. This time however, the hangs seem to be random and I suspect that some process is in an uninterruptible sleep and killall5 -9 in sendsigs is unable to kill the process.

Initially, I thought the hang was caused by a bug in my laptop’s ACPI and I decided to investigate. Searching around the web, I found out that my laptop is really a “white box” system from Clevo rebranded as “Neo”. It’s interesting because apparently Clevo has been supplying white box laptops to Alienware and other companies abroad, as I found out on this forum posting on notebookreview.com.

a

I decided to try it out and later found that it’s a waste of space to back up everything on my local computer. A lot of my messages on my Gmail account are from mailing lists and those are already available on the mailing list archives. What I really needed to do was to back up only important messages and discard the rest. For that, I needed procmail.

The instructions here are geared towards Gnu/Linux and specifically Ubuntu (or any Debian-based distro). I also assume that you have already enabled POP in your Gmail account. We start by installing the packages we need:

$ sudo aptitude install fetchmail procmail

That should pull in all the packages needed to run both programs. I already have postfix installed on my local computer as my SMTP server. So the instructions below are for postfix:

1. Edit /etc/postfix/main.cf and make sure the following lines are present:

   mailbox_command = procmail -a “$EXTENSION”
   home_mailbox = Mail/inbox/
   

   Save the configuration file and then restart/reload postfix. The settings above tell postfix to invoke procmail for local mail delivery instead of delivering it to your local mailbox. Your local mailbox is specified in the second configuration line above. It tells postfix that you want your mail to arrive in your ~/Main/inbox/ in Maildir format (note the trailing slash).

   Those familiar with postfix will notice that the home_mailbox option is no longer needed as mailbox_command takes care of local mail delivery. I added it there to make it easy to switch off procmail processing. Simply comment out mailbox_command and restart postfix when you want to turn of processing and delivery using procmail.

2. Create your ~/.fetchmailrc configuration file:

   poll pop.gmail.com with proto POP3 and options no dns
   user &#8216;<full GMAIL ADDRESS>&#8216; there with password &#8216;<gmail PASSWORD>&#8216; is &#8216;nimrod&#8217; here options ssl sslcertck sslcertpath &#8216;/etc/ssl/certs/&#8217;
   limit 5242880 limitflush
   

   Substitute your FULL GMAIL ADDRESS and GMAIL PASSWORD above. You may notice that it is a slightly modified version of the config file found in the lifehacker article. The second line is the one that specifies our authentication options to Gmail. In this case, I have opted to enable SSL (or TLS) authentication. The third line tells fetchmail to discard messages larger than 5MB (explained below).

   Make sure you set the correct permissions for your ~/.fetchmailrc. Do:

   $ chmod 0600 ~/.fetchmailrc
   

3. Create your ~/.procmailrc. In my case I only wanted to save messages that were directly sent to my GMail address. Anything else is discarded. So in my ~/.procmailrc I have the following (with my actual email address removed.):

   # Download only stuff directly sent to my email address…
   :0:
   * (^TO|^CC).*my\.email\.address@gmail\.com
   Mail/inbox/
   
   # Everything else goes into the bottomless pit…
   # If you don’t want unwanted emails to vanish without a trace, change /dev/null below
   # to point to another Maildir or mbox in your home directory.
   :0:
   * !(^TO|^CC).*my\.email\.address@gmail\.com
   /dev/null
   

   You will need to replace my\.email\.address@gmail\.com with your actual email address. Dots in your email address need to be escaped with a backslash if they appear in a condition line. Read more about the .procmailrc file by typing:

   $ man procmailrc
   

   To see some examples of procmail recipes:

   $ man procmailex
   

4. Now all that’s left for you to do is to create your Maildir mailbox:

   $ mkdir -p ~/Mail/inbox/{cur,new,tmp}
   

5. Run fetchmail:

   $ fetchmail
   

It should start downloading your email now. fetchmail will download almost everything. I noticed that for some reason the number of messages left to download as indicated by fetchmail do not always equal the number of messages left on the Gmail server. But you can keep polling your account by repeatedly entering fetchmail at the command line or saying:

$ fetchmail –silent –daemon 120

This will put fetchmail into daemon mode (background process) and have it poll your Gmail account every 2 minutes (120 secs).

limit and limitflush

I have setup my fetchmail configuration in such a way that very large messages are not downloaded. I have one message that is about 13MB in size and Gmail seems to close the connection near the end of the download. I found the message and it’s one of those email forwards with a very large attachment. Deleting it from my inbox did not seem to cause it to disappear in the POP3 messages seen by fetchmail. Because download fails for this message fetchmail keeps seeing this message and attempts to download it. This causes fetchmail to get stuck attempting to download this message. It seems that downloading messages larger than 10MB causes the Gmail server to timeout if your connection is slow.

The limit option sets the maximum size of a message in octets. The option I specified above sets this to 5MB. limitflush tells fetchmail to “flush” messages larger than limit. This prevents fetchmail from getting stuck with a very large message if you put it into daemon mode where you will probably have no idea what it’s doing.

You can adjust limit to your prefered message size limit or remove both options if you are sure all your messages are smaller than 10MB or if you have a very fast Internet connection.

Notes

Recently, Ubuntu seems to have switched from postfix to exim4-daemon-light as the default SMTP server. At least that’s as far as I can tell from what’s installed on my portable computer (clean install of Ubuntu Edgy Eft).

You need to follow a different set of instructions in order to use procmail if your setup uses exim4 instead of postfix.

For The “Under-privileged” Among Us

For those who do not have the luxury of having administrator or sudo privileges, worry not: you can still use procmail if your local SMTP server allows QMail-style email aliases using dot-forward or ~/.forward files. Create your ~/.procmail file as above. Then simply create a file ~/.forward with the following contents (yes, those quotes belong there):

&#8220;|IFS=&#8217; &#8216; &#038;&#038; exec /usr/bin/procmail -f- || exit 75 <username>&#8221;

Replace USERNAME above with your username.

a

If you’re too lazy to dig it up, here’s the low-down on things:

• DRI is broken because the kernel drm.ko module refuses to load on start up.
• This is linked to recent updates concerning AIGLX.

Indications of this error:

$ grep WW /var/log/Xorg.0.log
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(WW) The directory "/usr/share/X11/fonts/cyrillic" does not exist.
(WW) fglrx: No matching Device section for instance (BusID PCI:1:0:1) found
(WW) fglrx(0): board is an unknown third party board, chipset is supported
(WW) fglrx(0): Probed monitor is 320x240 mm, using Displaysize 336x269 mm
(WW) fglrx(0): ***********************************************
(WW) fglrx(0): * DRI initialization failed!                  *
(WW) fglrx(0): * (maybe driver kernel module missing or bad) *
(WW) fglrx(0): * 2D acceleraton available (MMIO)             *
(WW) fglrx(0): * no 3D acceleration available                *
(WW) fglrx(0): ********************************************* *

Then when you try to manually load the drm module:

$ sudo modprobe drm
Password:
FATAL: Error inserting drm (/lib/modules/2.6.17-10-generic/kernel/drivers/char/drm/drm.ko): Cannot allocate memory

To fix it you should edit your /etc/X11/xorg.conf and add the following lines if you don’t already have them:

Section "Extensions"
        Option  "Composite"     "Disable"
EndSection

If you have been using the Open Source X.org drivers for ATI (ati) while you switched to fglrx, you must reboot your computer. Simply zapping your X server will not do the job. It seems that the kernel is left in a complete mess when you switch drivers. Additionally before rebooting, make sure that the fglrx module is loaded by the kernel on startup. Do:

$ grep fglrx /etc/modules

You should get fglrx as a result. If nothing is displayed, then do:

$ sudo nano /etc/modules

add fglrx on a line of its own, save the file and reboot.

Note that it’s no longer required to use an older libGL.so.1.2 if you have an RV2xx card. The current driver version that ships with Edgy seems to work with these low-end cards.

a

Upgrade went smoothly and it was all done via the Update Manager GUI. A few minor niggles to the upgrade:

• 3D acceleration is broken again for my ATI Radeon 9250 graphics card. This time, it appears there is no workaround as the kernel drm module flat out refuses to load.
• I don’t like the new “silent” usplash where only a progress bar is shown. I liked the Dapper version better where you get to see what’s happening.
• Firefox 2.0 appears to have some issues with regards to the Flash plugin. Hopefully this does not have an effect on the upcoming Flash 9 player for Linux.

a

Lastly, and remember you heard it here, AMD is strongly considering open-sourcing at least a functional subset of ATI’s graphics drivers.

In the [article][infoworldarticle], Tom Yager points out some very interesting things that could come out of the acquisition. But the first sentence of the last paragraph is the one that really got me excited. I have been an NVidia customer for the past 3 years. Needless to say the only thing that kept me from ever considering ATI cards was Linux driver support. It is widely known that even under Windows, ATI’s Catalyst drivers cause a lot of headaches for users. And on Linux, the headaches were much worse. Anything from zero support for newer ATI cards to broken hardware-accelerated OpenGL drivers. I never had any of these problems with NVidia cards on Linux.

Two of my last graphics cards were NVidia cards and both of the burned out: literally. When the last card burned out after only about 12 months of use (and abuse) I told myself that it was the last time NVidia burned through my wallet as well.

So I bought a new graphics card, this time one with an ATI chipset. And it’s been working like a charm until I upgraded Ubuntu to 6.06 where the latest fglrx drivers shipped with b0rked OpenGL drivers. I had to resort to searching the many ATI user forums for the solution. It dawned on me that when it comes to driver support, ATI has a lot to learn from the NVidia folks. With every new driver release, which supposedly fixes problems of the previous release, a new crop of problems would come up. Even worse, problems that were supposed to have been fixed in previous releases would resurface. One step forward, two steps back.

One thing that caught my attention while I was reading through the forum posts was the significant number of posts that said “ATI should open source their drivers” or “if only the drivers were open source”. It’s not that different on the NVidia forums, but on the ATI forums there are a lot more of these comments.

So this recent tidbit from the Infoworld article is a welcome challenge to AMD. But a few things bother me the more I think about it.

AMD is only “strongly considering” opening “a functional subset” of the drivers

This is very important. There is no confirmation from AMD that this will happen. Considering the semantics of the statement, although there is a very high likelihood that this will happen, there is a very real possibility that this idea will be scrapped anyway. In the off chance that AMD opens up their drivers, what “functional subset” will they open up?

There are two parts to the drivers under Linux. One part is the kernel module for enabling the card itself, the other part is the fglrx drivers for X Windows that provide hardware-accelerated OpenGL support.

Will they open up the kernel module?

There has been a lot of heated debate with regards to allowing proprietary drivers to be loaded into the Linux kernel. Most argue that the GPL version 2, which is the license used by the Linux kernel, has a clause that forbids proprietary drivers from being “linked” with the kernel. They consider kernel loadable modules to be equivalent to dynamically linked code. Linus has already had his say in this matter, though this issue tends to bubble up every now and then, it has been considered “closed” at the moment.

If AMD does open up the kernel module, I am sure this would make a lot of devs happy and a lot of those involved in [Xen][xenproject] even happier. Considering that AMD has a lot at stake with their own virtualization technology, this would be a very good move on their part. Not only will it help them sell more CPU’s and chipset with virtualization technology, it would also help them sell more ATI-based cards as a combo with their CPU’s and chipsets.

Will they open up the fglrx OpenGL drivers?

A lot of the major problems out there seem to be caused by buggy or completely broken OpenGL drivers. I have personally experienced this and all I can say is that it’s horrible. When I recently upgraded to Ubuntu 6.06, which ships with the fglrx version 8.25.18, I suddenly lost hardware-accelerated OpenGL support. Suddenly, X.org fell back to using Mesa (ugh) and I was playing Quake 3 at 1 FPS.

My search for a solution drove me to download an older driver and extract the libGL.so that came with that and put it in place of the one found in 8.25.18. It appears that the new OpenGL drivers do not support my card (Radeon 9250-based). The frustrating part is that it is listed as supported based on the X.org log.

Recently, ATI released a new driver version and I was really hoping to try it out myself. But before jumping in and installing it like many users out there, I decided to wait it out and monitor the Ubuntu forums. It appears that ATI does it again, horribly broken drivers and R9250 appears to be unsupported as well. Worse, some users report that the “X.org GDM lockup bug” is back in the new drivers. This bug was already fixed in fglrx 8.8.25(?) so this just confirms the notion that it’s “one step forward, two steps backward” when it comes to ATI Linux drivers.

There is already an open source driver for ATI and it has support for my Radeon 9250 but as can be seen in this [Phoronix review][phoronix] there is a great gap in framerates between the open source and proprietary drivers. Not only that, the proprietary drivers also come with tools like aticonfig and fireglcontrolpanel. Though I never use those tools from the proprietary driver it provides the “hand holding” necessary for Linux newbies who are accustomed to using GUI tools for everything.

So, will opening up the OpenGL drivers actually improve the current situation with ATI’s buggy proprietary drivers? It’s difficult to say at this point. But one thing to consider is that the open source drivers were made using specifications from ATI. But the Phoronix review results (though a bit limited in scope) seem point to a far superior performance using the proprietary drivers. If those tests were done with much more than one game/application and they turn out the same results with the proprietary drivers beating the open source drivers by a wide margin, this could mean one of two things:

1. ATI was not totally honest in providing the specs to the open source Radeon drivers team and that they are using “hidden” interfaces and functions in their proprietary drivers.

   It has already be stated by both NVidia and ATI representatives that the reason why they refuse to release the source for their drivers is that they do not want their “intellectual property” out there. Both card manufacturers are neck-and-neck in competing for consumer (and gamer) dollars.

   You could argue that Intel has gone and provided open source drivers for their graphics chipsets, but then again, we already know that those things suck anyway and that no serious gamer uses them

2. Opening up the source for the drivers should vastly improve the existing open source Radeon drivers and would eventually result in getting those driver bugs fixed at a much faster rate.

   One of the reasons that you see users crying out “open source the drivers” on the forums is that apparently, it will get those bugs fixed much faster. More importantly, it should prevent old bugs from creeping up in new versions. We don’t know what kind of software development process ATI uses for developing their drivers, but apparently these guys have never heard of “regression testing”. Old bugs fixed in older versions should not come up in newer versions.

Both the open source Radeon drivers and the proprietary firegl drivers would benefit from opening the source, even for just the OpenGL drivers. If the solution to the OpenGL problem was replace the libGL.so from the new version with a libGL.so from an old version, it just goes to show that the problem lies within their OpenGL drivers.

I really hope that AMD really does go through with this. In the event that AMD actually does open source the ATI drivers, even if it’s just a “functional subset”, that would really nail it for them in terms of competing with NVidia (until NVidia does the same thing with their drivers ) The issue with Linux drivers was the one thing that kept me from switching to ATI. While these problems are solvable using work-arounds, I hate work-arounds. Work-arounds break eventually. I would rather have those problems fixed permanently, than having to constantly work around them with each new driver release.

[infoworldarticle]: http://www.infoworld.com/article/06/08/02/32OPcurve_1.html “AMD talks about ATI” [xenproject]: http://www.xensource.com/ “Xen Open Source Virtualization” [phoronix]: http://www.phoronix.com/scan.php?page=article&item=463&num=2 “ATI: Open v. Closed Drivers”

a