Linux

Last Saturday, the Austin Free-Net held a fundraising computer garage sale. I helped run the "Linux installfest" table. I've already written about how we selected Ubuntu Linux as the Linux distribution and how the event went. Today, I'd like to talk about what's so good and what's not so good about the Ubuntu Linux load process.

The awesomeness of Ubuntu Linux lies in its packaging, so no surprise that its installer is tip top. Every time I've used the Ubuntu installer it has been rock solid reliable. The install has always run to completion without difficulty, and has always resulted in a successful install. That's been my experience on systems ranging from an old Pentium II victim machine to my spiffy Dell Inspiron 600m laptop.

Yesterday, the Austin Free-Net held a fundraising computer garage sale. I helped run the "Linux installfest" table. Yesterday, I wrote about how we selected Ubuntu Linux as the Linux distribution we'd provide, and why we selected just a single distribution. I had planned to talk about the Ubuntu load process today, but I think I'll do that tomorrow. Instead, I'll tell you how the event went.

We built and delivered two Linux systems to two happy recipients. To deliver those two systems I invested three days of research, got up at 6am on a Saturday morning, and sat in a Methodist church rec hall for six hours. Some people might question whether the payoff was worth the work, but they are not the kind of people we call "Linux enthusiasts."

The Austin Free-Net is having a fundraising tech garage sale today. They have been collecting used computer and electronic equipment, and today it all will be sold off. I'll be there with some local volunteers running a "Linux installfest" table. If anybody wants to try Linux, we will load it onto their computer.

Over the next few days I'll be discussing my research and preparation for the installfest. Today, I'll explain our choice of Linux distribution.

It's hard to believe that it's been over a month since I built my Linux based home media PC. My entire CD collection (about 250 discs) has been digitized, and I'm ready to move the physical relics all into storage.

The system is working fine. There are, however, a number of remaining issues that keep me from completely endorsing the ASUS Pundit-R for home media applications. Garry Parker wrote about putting Myth TV on the Pundit-R, and he identified a number of weaknesses. He says:

After living with the Pundit for a while, the main problem with it is that it's too loud. It's quieter than most desktop PCs, but is still louder than I'd like for a living room. The alternative would be a passively cooled system such as an EPIA, but the extra power is probably worth it.

He also notes, "The SPDIF digital output is on the front panel. This is crap and a real design flaw." I agree. I encoded my CDs in a lossless format (FLAC) to preserve full fidelity. Yet, I'm playing them back through the computer's low-to-mid-fi analog system. I really want to play the bits digitally to preserve the fidelity, but if I do I need to leave the front panel open with a cable hanging out. That's crap.

The sound quality issue is a big deal. I ran an A-B test, to compare the sound of a full-fidelity FLAC file played on the computer (analog stereo connection) to the original CD played on a DVD player with S/PDIF (digital optical) audio connection to the amp. The difference is significant. The presence is completely sucked out of the version played on the computer.

My other complaint is that the system does not return from hibernation correctly. This may be a Ubuntu 5.10 issue, but regardless of the cause, it is an annoying one. The system would be a lot nicer to use if I could hibernate when not needed, and quickly resume when I want to play or access music. This means I either need to keep the computer running or go through a long boot-up when I want to use it.

Originally, I planned to do both audio and video media with this system. I haven't done any work on the video, and, frankly, I'm not working up much motivation to do so. We don't have cable and our TV reception sucks. About the only thing I watch is the Simpson's repeats on Fox. Counting time and materials, it would be cheaper to just buy the box set DVDs than it would be build video capability.

So, I'm mostly satisfied with the audio capability, and I don't anticipate working on video anytime soon. When I do, maybe I'll be ready to upgrade to a box that addresses some of the problems I found.

I continue to be impressed by the packaging and polish of the Ubuntu Linux distribution.

A post on the Austin Linux Group mailing list reminded me that I'd never gotten around to upgrading chinacat from Ubuntu 5.04 (Hoary Hedgehog) to 5.10 (Breezy Badger). I'm using 5.10 daily on other machines, but my workstation was still at 5.04. Originally, I was being conservative about upgrading my primary workstation. I set it aside and neglected to come back to it.

I finally did so last night, and goodness! it was easy. Here is all that's required to do the Ubuntu 5.10 upgrade completely off the net:

• Edit the /etc/apt/sources.list file.
• Make a backup, then replace all instances of "hoary" with "breezy".
• To retrieve the updated package lists, run: apt-get update
• To download all of the packages, run apt-get -d dist-upgrade
• To install the downloaded packages, run apt-get dist-upgrade
• To cleanup, run: apt-get clean

The only manual intervention required was with four configuration files. I had to merge my local changes with the updated version. The upgrade process flagged them for me.

Ubuntu is built on top of the Debian Linux distribution, and uses the Debian apt package management system. A lot of the credit goes there.

The process took a couple hours start to finish, most of it during the package download phase. Everything updated fine, and the system rebooted without incident. Color me happy.

I am using a Dell wireless keyboard for the home media PC that I am building. After so many difficulties setting up the system, it's nice to report a small success: I got the multimedia keys on the keyboard programmed.

RF wireless is great: I can control the computer from the couch. The wireless base receiver plugs into USB and Linux boots fine. I did have to relocate the receiver outside the equipment cabinet. All those metal boxes must have blocked the radio signal from getting through.

FedEx delivered the parts for my new media PC today. It took a few hours time (and an unplanned run to Fry's Electronics) to put it together, but now I'm ripping and playing CDs.

Here are the parts I'm using:

• ASUS Pundit-R "booksize" barebone computer
• Intel Celeron D 335 Prescott CPU, 533MHz FSB, 2.8GHz operating freq
• Hitachi Deskstar T7K250 160GB SATA hard drive
• NEC ND-3540A DVD Burner
• two Kingston 256MB DDR400 CL3 memory modules
• IOGEAR GWU523 USB 802.11G WiFi adapter

For years, I've used an old PC running Linux or BSD as my network gateway at home. I was, however, getting seriously tired of the space and the noise—particularly the noise—of the HP Vectra computer that served as my gateway. It was time to replace it.

I initially thought a shoebox-sized mini-ITX computer could be a nifty solution. When, however, I considered cost, that quickly became silly. The mini-ITX system would cost hundreds of dollars, while "residential broadband gateway" routers are readily available for a fraction of the price. These are devices that connect to your DSL or cable modem, and offer connections for all your network devices. Some, such as the Linksys WRT54G, even add wireless capability.

A PC-based router offers nearly infinite flexibility. When your router runs Linux, you can deploy any function that has a Linux implementation. Would I have the same flexibility with a device such as the WRT54G? I found out, surprisingly, I would.

Next week, I'm building a Linux-based media PC. I've been doing some research and planning. The first goal is to setup a digital music library. I started my research at the beginning, with CD ripping. My initial performance results were so bad, it called the whole project into question—or, at least, the decision to use Linux.

Here is a message I posted to the Austin Linux User's Group mailing list.

I'm getting ready to setup a media system, and I'm distressed at the thoroughly horrible CD ripping performance I'm seeing.

My test system is a Dell Dimension P4 2.8GHz with 512MB memory and Phillips DVD8631 (40x speed).

When ripping under Linux (Ubuntu 5.04), it takes about 25 minutes to RIP a CD. I've tried both Sound Juicer (reports about 4x performance ripping to FLAC) and cdda2wav (rip to WAV).

When I reboot the system to Windows, Apple iTunes rips the disc in about 4 minutes (reports about 30x performance).

It turns out that although ripping performance may be slow in the default Linux configuration, there are adjustments you can make such that Linux can actually rip faster than Windows.

There are two significant issues that lower Linux ripping speed. First, for stability reasons, most Linux distributions do not enable DMA for the CD drive. If your system can handle it (I think most modern systems can), then you should enable it with the hdparm command. To do so, run (as root):

# hdparm -d1 /dev/cdrom

On Debian systems, you can make this setting permanent by editing the /etc/hdparm.conf file.

The second issue is that most Linux CD ripping tools enable error checking (sometimes called "paranoia") by default, while most Windows tools do not. If you disable error checking, you will see a significant improvement in ripping performance. It's not clear that this is an advisable adjustment, but it explains part of the significant performance difference.

I ran some tests on the aforementioned Dell system to measure the effect of these various settings. I used the grip CD ripping tool and ripped to raw WAV format. The trials were all timed by the wall clock, so take the results as plus/minus a few seconds.

By comparison, when I rebooted this system into Windows XP and ripped with Windows Media Player to Windows Lossless Format, it took 2:23. (This isn't quite apples-to-apples since there was an additional encoding step under Windows, but that should have only added a few seconds at most.) This was an unexpected surprise: Linux actually outperformed Windows. I was shocked, given how poor the initial results were.

Now that I'm over this hump, the research continues. I'd like to investigate whether "error checking" is a valuable protection, or unnecessary overhead. Also, I need to determine which ripping and playing tools I want to use. A database backend would be nice. I'm pretty sure I want to rip into the lossless FLAC format. I need to verify that's going to be feasible for our CD collection.

Last month, I switched my network gateway from a cast-off PC running Linux to a Linksys WRT54G router—also running Linux. Yes, these devices actually run Linux. I'm using the OpenWRT package.

One concern is that I need to access my network remotely. That's a little tricky, because my network gateway is assigned a dynamic host address by my broadband provider.

DNS names, such as www.unicom.com, typically are fixed, always resolving to the same Internet address. Dynamic DNS allows you to create names for addresses that change, such as that on my network gateway. The nsupdate utility, part of the BIND nameserver suite, issues DNS update requests to a nameserver.