Thursday, July 26, 2007

My Experience with Fedora 7

Like anyone that has been using Linux for a long time, I really like seeing what's new in my favorite distribution. I have been using Fedora since Fedora Core 3, and have happily upgraded to each successive version, and I finally got around to upgrading to Fedora 7 this week.

A big part of the reason I waited to upgrade, is my laptop is using an ATI Xpress 200M video chip, that doesn't have an open source driver that can do hardware accelerated 3D. The ATI proprietary driver didn't work with Fedora 7 when it was first released, so I thought it better to wait. Two months later, I read an article saying the new driver release fixed the issues with Fedora 7, so I downloaded the new driver, installed it on Fedora Core 6 first, and everything worked, so I popped in the DVD to do the upgrade and rebooted.

The laptop booted just fine off the DVD, and the upgrade process went smooth. It took a little longer than I would have liked, but I have a lot of software installed on this laptop, so there were 895 packages that had to be upgraded. This all went smoothly, and the upgrade finished, it ejected my DVD, and I rebooted. This is where the fun began.

The first thing I planned on doing after the reboot, was install the ATI proprietary driver. Of course, with the initial boot after the upgrade, with the new kernel in place, the driver wasn't there, and it booted in text mode, which is what is expected. At that point, I logged in, and ran the ATI installer, and everything installed fine. I then rebooted again, not specifically because I had to, but I like to make sure the graphical boot works as it is supposed to. At this point, when the graphical boot should kick in, all I get is a black screen.

So, I boot again, and this time use grub to boot into single user mode, and then I look at the Xorg.log file, and I find that the X Server is core dumping! Ouch! This release of the driver is supposed to work for Fedora 7. Well, I decide to reconfigure using the 2D open source radeon driver, and that works as expected, and I am able to get X working. I then go on-line, and find out that the driver is not recommended for use with Fedora 7, as others had encountered the same problem as I. So, I find myself still stuck with a 2D only system, because ATI has not released any fix for this problem. Hopefully, next months release will finally fix Fedora 7 compatibility issues once and for all (I am running out of hope for good ATI Linux support).

After that hurdle, I decided to see if the latest Broadcom driver for my wireless chip actually worked. I have a PCMCIA NetGear card that uses the Atheros chipset, that works great, and I oridinarly blacklist the driver for the internal Broadcom chip (bcm4318) because it has never worked reliably. I certainly would prefer to use the internal wireless, so I continue to experiment.

As it turns out, after upgrading the kernel to the latest Fedora 2.6.22, the driver loaded successfully, and I was actually able to connect to my access point with WPA. I was surprised, and happy to see this working, but the good news didn't last long. The connection speed that was being reported was only 1 Mb/s, and when I tried to open
my browser, it couldn't even open my home page. So with that disappointment behind me I went back to the Atheros based NetGear card. I had to use a snapshot release of the code for it to compile with the 2.6.22 kernel, but it works as good as ever, and maybe a little better.

At this point, everything is working quite well, and with some additional patches for Evolution's data server package, I now have a stable working laptop once again, albeit without working 3D. So after working with it the last few days, here are some of my observations.

I really like the fast user switching. The first time I tried it, it complained that it couldn't find the GDM binary, but after the screen saver kicked in, and I awoke it, I decided to use the "Switch User" function from there, and it worked! I was able to switch back and forth from two accounts without any issues. Since then, it has worked from the panel applet without complaint. I really like this feature, and its been sorely lacking in Linux for quite some time (I am used to this feature in Mac OS X).

Another area, that has been a pleasant surprise, has been using 32-bit Firefox plugins under 64-bit Firefox. This laptop is using an AMD Turion 64 processor, and the 64-bit Firefox is the default installation. Up to this point, I have always gone through the trouble of installing the 32-bit Firefox, just to get Flash, Adobe Reader, and other plugins working. I had read about some software called nspluginwrapper. This is not in the official Fedora repositories, but it has a build that works perfectly on Fedora 7. This has enabled me to use the 64-bit plugins for Xine, and, and at the same time use 32-bit Adobe Reader, Flash 9, and Java. Those along with the xine-lib-moles package, that adds the proprietary codecs to Xine, has opened up all the content on the web that I have
not been able to access before. I find my web experience to be so much more pleasurable then before! Of course, I would prefer that these web sites didn't use the proprietary formats to being with, and everyones lives would be much better.

The final area that seems to have improved dramatically is Firewire. I have a "My Book" external hard drive, that I use for backups, and it has both a Firewire interface as well as a USB 2.0 interface. The Firewire interface has never worked, so I broke out my Firewire cable, and plugged it in, and it powered up, and the drive mounted with a nice icon on the desktop, just like it should!

Since, this worked, I decided to test out the Firewire interface for performance and reliability of my backups. I needed to take a backup anyway, so I started up my backup process which creates a gzipped tar of my home directory, and then I simply move it to the "My Book". I timed the move to the "My Book", and also opened the resultant file using file roller, and did the move and open again using the USB 2.0 interface. The Firewire interface was slightly faster at moving the 4.3 GB file, but only by 9 seconds, so there wasn't much of a performance difference, but the surprising thing was only the Firewire transfer resulted in a file I could open successfully. The USB transfer resulted in a file that got CRC errors. Obviously, that isn't a good backup, so I redid the transfer once again using the Firewire interface, and was able to open the backup file on the "My Book" with no issues again. This kind of problem has happened intermittently with USB for quite sometime, and it gets more prevalent with larger backups. Needless to say I really like the new Firewire stack in Fedora 7, and soon I'll be testing it with a digital video camera, just to see how far this new stack has come.

To sum things up, since getting over the hurdles of my hardware, I have a very stable platform for doing my daily work, and there has been progress on many fronts. The work going into the Broadcom drivers is improving rapidly, and I hope to be able to use my internal wireless chip soon. I only wish ATI would get their act together on the video driver, so I can fully exploit my hardware.

Tuesday, July 03, 2007

Google Desktop for Linux vs. Beagle

Recently Google released Google Desktop for Linux. I have been using Beagle on Fedora Core, since it was added, and currently am running Fedora Core 6. With that, I decided to try out the beta of Google Desktop, and compare search results between the two, to see if one was any better than the other.

So, I installed Google Desktop with their RPM for Fedora, and set the preferences. I setup my preferences for indexing the same as I did for Beagle, so the comparison would be fair on both sides. You can see the settings in the following image:

Most of the settings are the defaults provided, but I added /var, /opt, /etc and /tmp as file systems, because I like to be able to search for things in log files written by syslog, configuration files, etc., and I also am indexing all file types, and web history, with the only exception being https content.

This pretty much mirrors my Beagle preferences as you can see from below:

So, after setting the preferences, I watched Google Desktop go to work on indexing my file systems. What was interesting is that it took a very long time. Over two days to do the first pass at indexing. Now, granted, I have a lot of files on my laptop, so this is understandable, but Beagle seemed to index my files a lot faster, but I don't have a specific time to compare against, because there is no way to monitor the indexing progress of Beagle (at least not that I know of). Now that brings us to comparing search results.

With Beagle, I have been frustrated at times that it couldn't find files that I knew were there, but couldn't remember where I had saved them. Isn't that what desktop search is all about? In fact, as a result of trying to find a Portable Document Format (PDF) document that I had saved from the web, I opened a Bugzilla case thinking that Beagle was not indexing PDF's. It turned out that Beagle was indexing the PDF's, but Beagle only indexes based on a files metadata, not its entire contents. That explains why it couldn't find the file I was looking for, because the search phrase I was using didn't match the files metadata, but part of its content. So, I had the perfect test case to see whether Google Desktop could find what Beagle couldn't.

I searched with the term "Small is Beautiful", which is part of a subtitle of a document produced by Familiar Metric Management, and it is about software development productivity as it relates to team size. As you can see, from the image below, that this search phrase returns nothing using Beagle.

So, I did the same search with Google Desktop, and you can see the results below. Unfortunately, I couldn't find a way to capture a screen shot of the interface, without losing the results at the bottom, so I did the search from the browser interface instead.

As you can see from my cursor highlight, Google Desktop found the file I was looking for without any problem. This explains the major difference between Google Desktop and Beagle. Beagle trades off indexing speed, by just indexing the metadata on documents, while Google Desktop does a full index on the content, thereby taking much longer to index files, but giving much better results. I prefer the better results. There is one other difference that I would like to point out between the two.

In backing up my laptop, I noticed that my backup of my home directory was taking longer and longer, and the backup was getting very large. In looking into this, it turned out that a large percentage of my home directory was the beagle index. That led me to look into how large the Google Desktop index was in comparison. Well, there is no comparison. The Google Desktop index is much, much smaller (see below).

In fact, its 94% smaller than Beagle! This is a huge difference, and certainly pays off in disk usage.

In conclusion, I really liked Beagle, but Google Desktop offers better search results, with considerably less disk usage for the index. At this point, I'm ready to turn off Beagle (maybe even uninstall it), and rely on Google Desktop instead.