Josh Saddler

Gosh, just look at all the buzzwords in the title!

As you may have guessed, I'll be talking a bit about the recent developments on the FOSS drivers for RadeonHD cards, specifically for R700 cards. And some other hardware stuff.

Radeon

Yesterday, October 3, I made some big ol' changes to my workstation.

I decided to try out the new video driver stack that all the kids have been talking about. Kernel Mode Setting, git Mesa/xf86-video-ati/libdrm, git kernel 2.6.32_rc1-git3. All that jazz. I wanted to see if the 3D and KMS features were really working on my RadeonHD 4550 or not. I normally run a stable graphics stack, with ~arch Mesa/x86-video-ati/libdrm where necessary to keep up on 2D acceleration and features.

This was a big leap for me. So I first consulted some of the X11 team members, remi and nirbheek, who were quite helpful. I installed the latest git-sources kernel, which at the time was 2.6.32_rc1-git3. Mike Pagano has since added -git5. Next, I downloaded the individual -9999 ebuilds for the git master packages from the X11 overlay, stuck 'em in my local overlay, and merged 'em. Only thing left to do was reboot.

Lemme tell ya -- KMS in action is awesome. The console output is just beautiful, and there's no more flickering when SLiM and Xfce load.

I did notice some minor graphical corruption of the default mouse pointer. However, the corruption isn't present when using any pointer but the default "arrow", and it also isn't seen when hovering inside a Firefox window. I was told this is because Firefox uses its own cursors. Anyway, I reported the bug upstream.

Disclaimer: I know glxgears isn't a benchmark. But folks always want to know its results anyway. I tried running glxgears, which gave me a result of over 1300FPS with desktop compositing activated. My window manager is xfwm4, so all compositing is via Xrender, not OpenGL. Disabling compositing resulted in a 500FPS boost to over 1800FPS. What's this mean? Who knows. Probably nothing. Moving on.

I took the advice of my fellow developers on IRC and installed quake3-demo. Couldn't run it, though. It blanked the screen, then a message from my LCD firmware appeared, some kind of "input not supported" or "input not detected" error. It slowly repeated the window, drawiing it from center to the top right. I had to Ctrl-Alt-Bksp to get to the console. It also locked up SLiM in the background, pegging one of my CPU cores at 100%. At this point, I rebooted just to test that KMS was still working, then called it a night.

Today, I revisited my pointer corruption bug tried the workarounds posted by Alex Deucher. To my surprise, each one worked! Booting with radeon.modeset=0 removes the glitch, though it makes each boot extremely ugly, of course. Specifying EXANoDownloadFromScreen "true" in /etc/X11/xorg.conf also fixes the corrupted pointer, though it may also be slowing down all screen drawing operations by the tiniest bit. The jury's still out on that one; it may just be my imagination. I decided to keep this second fix, as KMS is just too glorious to throw out. I like pretty boots.

I also revisited quake3-demo, since I found some pointers on the Phoronix forums that had a workaround, which is to run OpenGL applications prefixed by LIBGL_ALWAYS_INDIRECT=1. To my surprise, this worked nicely. I tested resolution has high as 900-something by 720. My screen is 1440x900, but I haven't felt like pushing it that far, yet. The game is fluid and playable. I need to figure out how to display FPS so I can properly record what I'm seeing.

With the success of Q3demo, I remembered that QuakeLive has recently added Linux support. I installed the add-on for Firefox and tried it out. Works nicely, though I'm also running Firefox with LIBGL_ALWAYS_INDIRECT=1 just to be sure. As Alex Deucher and John Bridgman have pointed out on the Phoronix forums, that variable really isn't the safest thing to do, since if something crashes it can take down the whole X server, not just the application. However, it's also the only way I get working 3D games.

QuakeLive is pretty playable, though the framerates in a few places aren't smooth -- I can't tell if this is because of my card's capabilities, or the driver stack, or the whole weird idea of playing a 3D first-person shooter inside a web browser. The big problem with QuakeLive is that the sound is terribly distorted: the voices are greatly drawn-out and slowed down, like playing an old tape recorder at 1/4 speed. There are some solutions on the QL forums, but they're mainly for Ubuntu/Pulseaudio users. I haven't found anything that works for me, yet. The effects and music are okay; it's just the voices that lag horribly.

I've also installed the latest Nexuiz, version 2.5.2, in anticipation of future testing. One of these days I'll reinstall UT2004, but I haven't read any succesful reports of that game on R700 cards. There's a lot of testing to do in the future!

Overall, I'm thrilled with the new driver hotness for my ATI card. I bought it specifically because I knew the 2D support at the time was excellent, and because there would be so many good things coming down the way for other features, including 3D acceleration. (Yes, just like the latest XKCD strip. I swear, it's like that guy listens to everything I say and watches everything I do. It's really spooky!)

Hats off to all the developers for making it happen. Many thanks!

SSD

After August's fiasco with a defective SSD, I decided to use my refund from the RMA and order a different SSD a few days ago. This time I've settled on a SanDisk enterprise SSD from an HP blade server. Only cost $49, no shipping charges. Brand new. eBay for the win.

It packs 16GB of SLC flash, which makes it perfect for mounting /usr/portage and /var on it. This way I can feel free to sync whenever I want, instead of only once a week or more. My system drive uses MLC flash, so I've been trying to ease the write load on it, which means putting the high-write activity on a dedicated disk.

The SanDisk SSD "only" has sustained reads/writes at 60MB/sec, but that's plenty for syncing Portage, as the real limiter is not how fast data can be dumped to the disk, but how fast the rsync servers can send it to my box. Same for /var writes -- it's mostly just log files and some tiny temp things, as /var/tmp is already mounted on a RAMdisk. No large files that need >100MB/sec bandwidth. I'm lookin' forward to shovin' it in my box!

More hardware

Since September 28 was my birthday and all, I've been treating myself to various bits of cheap hardware. Like a replacement AC adapter for my DC PicoPSU. The current AC brick is rated at 102W, which is way more than I need, but the problem is that it spins up its tiny fan at only 50%-75% load. This means that opening up a bunch of tabs, compiling packages, playing Quake, watching large-sized Hulu videos and whatnot turns on the fan right away. And it's the world's most annoying fan. It's loud, whiny, it hisses, and it blows the bad smell of very hot electronics out into the room. Lemme tell you, hot plastic and PSU guts do not smell good.

I just ordered a replacement fanless adapter. This thing is high-quality, designed to run very cool. And it's rated at 150W output, meaning it can match my 150W PicoPSU. My max system draw is maybe 60W, but I'll have overhead room in case I ever feel like upgrading a key component somewhere.

I also bought a $40 wireless router, an Asus WL-520gU. I already have a WL-500gP v2, which I hacked and flashed with DD-WRT a long time ago. This new router is so that I can hook up my Xbox 360 to the network without having to run 50 feet of cable across the carpet. I chose the 520gU instead of the gC because the gU supports Xlink Kai, which seems prett cool to me, as I don't have a Gold Live account. Yay for tricky internets. Apparently it's pretty common to buy a cheap wireless router and put it into client mode, rather than buying the $100 official USB dongle . . . which doesn't even support WPA2-AES or any decent security. Asus routers are known for excellent open-source support, and I've had nary a complaint about my current one. Yay for Linux on routers! Yay for online gaming!

* * *

Oh yes, and before I forget, this month's Xfce desktop:

It's October, but my current desktop is so pretty (gallery link) I haven't felt the need to switch for the last couple of weeks. There's another clean version that just shows off the wallpaper in my devspace.

So, a couple days in, and I'm still trying to (re)install Gentoo. More on that in a bit. First, let's talk about speed.

It's hard to tell whether or not my new SSDs are really a speedy improvement over the old software RAID1 array of magnetic HDDs. Normally, a bare-bones commandline system feels much faster than an aging graphical desktop, even on the same hardware.

I notice that compile times are slightly faster, though I've also been using tmpfs for Portage and the usual tmp file locations, so putting it all on RAM will lead to a significant speedup anyway.

Boot times are indeed quite zippy; the longest wait is for my media HDD to finish mounting -- it's on ReiserFS, which is known to have very slow mounts.

Now, let's talk filesystems.

The critical showstopper that's made me reinstall two times (and counting) is ext4. So far, ext4 has completely corrupted a whole drive (/var and /usr/portage) and made the other drive (/ and /boot) almost unbootable.

ext4 has eaten my data, hosed my system, and ruined my life.

No amount of fscking has fixed /var and /usr/portage, both on the second SSD. Did you know that you shouldn't let fsck try to resize broken inodes? apparently the resize behavior is known to be broken in the latest versions. It's known to corrupt filesystems. I didn't know that, either. I'm sorry, but what part of "production-ready" applies to ext4? Yeah, it's a new kid on the block, but it's moved out of the "experimental" status into the kernel.

That does not make it ready for your system. The first and second Gentoo installs largely didn't work because (I think) there might have been an invalid mount option. Or something could not be found. Or a superblock was missing. Or the moon was wrong. #$#^#&@ shitty unintelligible error messages. (Here's a tip, developers: don't put every possible thing that could have gone wrong into an error message, then repeat that message for every different error.)

My mount options seemed to be good after double-checking the manpage and around the internet, including kernel.org. Here was my original fstab, from when I had only one partition for / (no separate /boot):

/dev/sda1  /     ext4  noatime,data=writeback,commit=60,nobarrier  0 1
/dev/sdb1  /var  ext4  noatime,data=writeback,commit=60,nobarrier  0 1
/dev/sdb2  /usr/portage  ext4  noatime,data=writeback,commit=60,nobarrier 0 1

Livin' on the edge here. I figured I wouldn't need a separate /boot partition on my first drive, so I lumped it all into one. I did that back in 2005 and 2006 with no problems, right? Right. The rest of the options were designed to maximize SSD performance.

Unfortunately, I couldn't get the system to boot. Made it past grub, the kernel loaded, but when it came time to mount /, it couldn't mount the filesystem rw. No amount of changing options worked -- adding rw to grub.conf, to the fstab options, nothing.

So I figured it must be my one-partition setup, and wiped my disks. Reinstalled again, this time adding a /boot partition on sda. Same ext4 options for /boot as for the other partitions. Rebooted and . . . nope, same errors. Now I'm also seeing a message about a possible bad option or other variable, which I can only assume was in fstab, thanks to the aforementioned shitty nonspecific error messages.

Hit up Google. Not much help. I again backed off on some of the ext4 options, tried playing with Grub parameters, but got the same results. The filesystems mostly weren't mounting, and when a few of them did, it was all readonly.

Sigh. Time to reinstall again. Set up a similar fstab, but this time I changed an ext4 option for /boot to data=ordered, based on this blog post. Reboot and . . . hey, it works. /boot gets mounted. Nothing else does, but it's a start.

I quickly booted back into the LiveCD, changed the other fstab entries to data=ordered, and reboot again. This time, the system seems to boot just fine . . . until it tries to mount /var and /usr/portage from the second SSD. *bzzt*, these cannot be mounted! Something's gone wrong. One more reboot, just for luck, then . . . *bzzt*, now there are filesystem errors! Fsck wants to fix them, so I let it run. Except it completely hoses both partitions. They seem to be so badly scrambled that even running mkfs.ext4 on them from the liveCD results in errors, some of which seem to be emitted from the libata system, which makes me wonder if now the SSD itself has also been corrupted.

I'll have to completely reinitialize and repartition that disk, now. Thanks, ext4. Thanks for hosing my data. Up yours, ext4.

I'm done trying to figure out why ext4 doesn't work. I don't care that it's supposed to be a fast file system for SSDs. I don't care that it's 40 times faster than ReiserFS to mount at bootup. I don't care. ext4 has lost my data three times now. I think my fingers are sufficiently burned to know that "the oven is hot; don't touch."

Up yours, ext4. I'm going back to ReiserFS. At least it works. It's never failed me in more than four years.

Update: On top of the initial ext4 errors, fsck problems, and mount issues, the Mobi drive was also going bad. Now the motherboard BIOS can't see it, regardless of which SATA port or cable I plug in. So just a day or so after trying out the device, when it was initially working for the first install (though the filesystem was throwing ext4 errors, at least /var and /usr/portage worked okay), and it finally finished failing. F***. I contacted the seller to request an RMA; I have a feeling that I'll end up having to go through the manufacturer, which will take a long time. Meanwhile, I'm without a workstation for an indefinite time, so I've set my devaway on dev.gentoo.org. I did find a couple other reports on the internets that say that their Mobis also died shortly after they arrived, so maybe there was a batch of bad drives.

But don't get me wrong, the Mobi drive dying doesn't absolve ext4 of any guilt. The ext4 filesystem still completely f**ked itself repeatedly on the system drive, the UltraDrive ME. It still refuses to do what it's told to do. But rather than continue to investigate related LaunchPad bugs on mounting ext4 rw and fsck errors, I'm going to move back to ReiserFS for the UltraDrive, and just live with longer boots. The RMA process will take awhile, so I may have to reinstall everything on a single drive and just avoid syncing Portage for awhile.

On a good note, OCZ (the company that makes the Vertex, an identical drive with an Indilinx controller), has been experimenting with a homegrown beta firmware that lets the drive do online garbage collection in the background. This is important for keeping the performance of the drive as fresh as when it was first used, even after it gets filled up with files and repeated (re)writes. The firmware is still in testing, but I'm hopeful that it'll make it out the door soon. Hopefully the same firmware features will find their way to my Super Talent drive -- and hopefully the TRIM command will also be implemented in the firmware.

Of course, the only Linux filesystem I know of that supports TRIM is ext4 . . .

So, in between being super busy with Gentoo yet not having enough time to keep up with all the bugs, document updates, and project commitments . . . I've added yet another item to my plate: a fresh install of Gentoo onto a pair of SSDs.

I've never reinstalled Gentoo on this workstation; this is the original install from October 2006. I had thought about just finding some stage4/stage5 backup scripts and tips from the Gentoo Forums, but it seems to be more cumbersome and time-consuming than reinstalling. Besides, installing Gentoo from scratch gives me a chance to create an even more lean, minimal system. No more accumulated packages and cruft that I don't use, just the essentials.

And it'll let me see how good these SSDs really are for compilation times.

I purchased two: a 32GB Super Talent UltraDrive ME for /, and a 16GB Mobi 3000 for /var and /usr/portage.

The Super Talent is a new-generation MLC drive with an Indilinx controller. It's not as good in some areas as Intel's controller for the X-25, but it's better than everything else out there, and it doesn't have the chronic stuttering problems that all cheaper JMicron-based controllers suffer.

The Mobi is an older drive, "only" SATA-150. But it is an SLC drive, so I'll use it for the partitions that see the highest write activity, as SLC is more resilient than MLC. Plus, the contents of the drive are more or less throwaway, so if any corruption does develop, I can just replace it with no issues. /var sees log frequent writes, and there may be some Portage compilation in the tempfiles. I've been using a tmpfs on RAM for /var/tmp/portage for some time now, so I don't really think it will hit up the drive much, not with 4GB of RAM installed:

none  /var/tmp/portage tmpfs	noauto,nr_inodes=1M,size=2000M 0 0

See? A dynamic Portage compilation space, ready to occupy 2GB RAM if need be. During compiles, the only time I ever really see the HDDs light up is during the src_unpack (to RAM) and src_install phases.

So I've figured out my drive and partition usage, but the things that are causing the most headaches, and occupying the majority of my research time, are:

1. Which filesystems
2. Which mount options
3. Which schedulers
4. Partition alignment schemes

See, I will have two SSDs in there with Gentoo installed on 'em, but I'll also have a separate magnetic HDD for media storage, so that means a different for each drive.

For 1, ext4 is looking increasingly attractive for the SSDs. I may continue to use ReiserFS for the media drive, as it's worked very well for a few years now. But, given that the Portage tree is just lots and lots of tiny files, perhaps I could continue using ReiserFS on it? Though I would need to deactivate the journal. The Mobi drive should not have any journaling on it -- too many writes.

NILFS2 is another interesting filesystem, but it seems immature. BtrFS also has potential, especially after reading Val's excellent article, but its developers warn against using it for anything other than testing. So I'll stick with something a little more mainstream, yet not so old and cranky as ext3/ext2.

Which brings me to 2: mount options. I've only just begun to read up on suggested options for ext4. data=writeback seems to be one of the more popular suggestions. noatime is a necessity; I've used this option on every single Gentoo install I've ever had. There are several other options I need to investigate, including the dir_index variations.

If I go with ReiserFS, I'd need to research the performance differences between notail and tail. In theory, the latter option could be more efficient for packing more data into fewer blocks, resulting in fewer writes/rewrites. This is at the expense of slightly more CPU usage. notail may result in more speed, but I haven't found many detailed reports of ReiserFS usage on SSDs. One last thing to look up would be the difference between ReiserFS with the journal and without.

The next piece of the puzzle is 3, schedulers. Most of the schedulers in the kernel are designed to keep spinning magnetic disks happy. But since there aren't any moving heads or rotating disks to spin up, the algorithms that are designed for efficient, minimal motion aren't very helpful for SSDs.

The usual solution proposed is to bypass the traditional HDD seek layer overhead by just using the noop scheduler. It's a very simple FIFO-based scheduler. System requests a file, it gets it. No complex queuing up done in the kernel. It lets the extremely fast drive controller do all the work, since it's capable of getting the data where it's needed without stuttering or delays.

However, the deadline scheduler may be as good as noop, as deadline does a certain amount of prioritizing. My understanding is that it's similar to NCQ in this regard, and that using deadline doesn't have any overhead costs. Still doing the research on this.

These two schedulers may be all well and good for the SSDs, but since I'll have two SSDs, a magnetic hard drive, and an optical drive in my box, I can't use the same scheduler for all of 'em. noop would be a poor choice for the HDD, so I may use deadline or stick with the tried-and-true CFQ scheduler.

Fortunately, using different schedulers for different drives is fairly easy:

# echo deadline > /sys/block/sda/queue/scheduler
# echo noop > /sys/block/sdb/queue/scheduler
# echo cfq > /sys/block/sdc/queue/scheduler

It's just a matter of putting these commands into an initscript to be run at boot.

The last puzzle piece (so far) is 4, partition alignment schemes. This is the most confusing one. The most headache-inducing. The most worrisome one, in that if I screw it up, I could completely hose the performance of the drives, and severely impact the wear and tear on the drive.

The OCZ Vertex is functionally identical to the Super Talent UltraDrive. Same controller and firmware, so Vertex tips will apply to my drive. The OCZ forums have proven rather useful. There's a fair amount of material at the OCZ forums, and even some suggestions by Gentoo users. Unfortunately, some of the threads are rather old, so I'm unsure how much still applies. Given that there have been new hardware revisions, new firmware shipped with the drives, and improvements to the Linux kernel stack (schedulers, libata, etc.).

Ted Ts'o has a pretty good explanation, but it differs from some of the other suggested block sizes. Also, some guides have a radically different approach.

* * *

So, four pieces to the Gentoo installation on an SSD puzzle. Lots of notes so far, and despite four months' research, I feel like I've barely gotten started. I've been thinking and planning to move to an SSD for quite awhile now; it's mostly been a matter of waiting for prices to fall. Now all the components are here, so I'll just have to dive right in and see what I find. Results will, of course, wind up here.

My next bit of tinkering (after a guided tour of hacking up Abiword ebuilds) will be hardware and software.

NewEgg is having a sale, so I just purchased an ATI RadeonHD 4550. This is the cheapest one on the 'net, and it has free shipping in addition to the sale price. And most importantly, it's fanless! And it's got a low-profile bracket!

I've been planning to downsize or "sidegrade" (not upgrade) my main desktop workstation for some time now. Moving to a smaller desktop case saves a few square feet of precious floor space, and it's part of reducing the overall system energy consumption.

I intend to change my computing habits, starting with using less power and quitting 3D games (such as UT2004). So moving to a less capable graphics card is a big step in that direction. As of right now, the radeon and radeonhd drivers only have working 2D acceleration, which is all I expect to need.

The last time I used an ATI card, I was extremely impressed with its 2D rendering speed and flicker-free video playback. Granted, that was an R500 card and the RadeonHD 4550 is an R700 card. However, supposedly its 2D driver is just as good as the code for the older card, so I expect a similar experience. Although KMS and 3D acceleration are nowhere near ready, I don't need them. Working KMS on my Intel laptop is nice, but it's not crucial. Nor will it be for my desktop.

The most important things for my new desktop are good FOSS driver support/performance, silence, and adaptability for case changes. I'm completely spoiled by running nothing but fanless graphics chips. After the terrible experience with the fan on my X1950Pro, I purchased an AC Accelero S1 rev. 2. It made a world of difference! The 4550 I bought today is also fanless, and has a much smaller heatsink.

Which brings me to my next point: adaptability. Sure, I could have just (re)used my X1950Pro, since it already has working 2D and 3D acceleration, and has a fanless cooler, but it also uses more power than even my GeForce. Which makes sense, since the 1950 was a high-end card for its day, and the 7600GT was a low-to-midrange card. In every test I found, the RadeonHD 4550 uses 18W or less at max 3D load, and idles at about 7W. That's outstanding for regular desktop usage.

That'll let me stuff the card and the rest of my computer into a microATX case such as the Antec NSK1380. Or even into a low-profile case like the super-slim desktop form factors. I'll need a new CPU heatsink, possibly even a more modern CPU. My current Athlon X2 is a 2.4ghz 65W chip, but moving down to a 45W chip that's even faster (say, 2.7ghz) saves even more power and heat. That'll let me run my whole system off a tiny, super-efficient, space-saving PSU like the PicoPSU.

And it probably won't stop there . . . I'll probably trade my 160GB RAID1 array for a single SSD, and just be smarter about making more frequent offline backups. The SSD will likely be an OCZ Vertex or one of the other Barefoot ARM-based drives. No sh*tty JMicron controllers for me, thankya very much.

A small, cute new case, a seriously efficient PSU, CPU, GPU, and HDD . . . so that's basically a whole 'nother workstation, but I think it's worth it. Fun, too! The challenge of choosing and assembling parts is the shortest. The longer challenge is reinstalling Gentoo, tweaking the SSD for max performance and longevity, and getting the graphics driver to work.

These last two bits will likely be the trickiest, as the radeon driver seems to work best when using either a .28 kernel or a really recent 2.6.30. However, the later .30-rcX kernels have serious issues with ReiserFS, my preferred filesystem. And only some folks have reported that the latest -rcX versions have fixed the regressions. Ah well. While I've always experienced the best performance with ReiserFS, that's been on normal magnetic drives. Apparently the new hotness is stuff like BtrFS, NILFS, and ext4. Probably end up going with ext4 as I wouldn't entirely trust the first two with my data safety just yet.

Ahhh, hardware hacking. It's so fun, yet it's over so quickly. It's an expensive hobby to keep up constantly, which is why I try to go years between component changes, and spend the intervening time tweaking the software. Will it ever be "good enough?" Time will tell.

Man, it's been awhile since I blogged. I meant to keep putting up a monthly Xfce desktop, share some tips, talk about the latest Gentoo work, etc. And then real life got in the way.

Laptop

I killed yet another piece of hardware when updating my Thinkpad R61i on Friday. I've been sick this whole week, so I had some free time. The laptop hadn't been updated since early February, so there were 176 packages, including the big move to GCC 4.3, which necessitated a system rebuild. Unfortunately, I left the battery in while the system was on AC power for the compiling work. I guess the heat must have built up too much, because the battery got fried. Got the dreaded "battery light flashes amber rapidly" error. So now I only have the extended-life battery, which is heavier and bulkier.

Add that to the list of hardware that compiling Gentoo has killed over the years. The list includes another battery, an external power brick, an internal PSU, two motherboards, two RAM sticks, one RAM slot, two hard drives, and a fan. I'm really on a roll, here.

I still can't find a replacement battery for less than $90, even on eBay, so I may hold off. What I did do was order two more gigs of RAM, to bring the total up to 4GB. Only cost $40 at Amazon, free shipping. Why the RAM? While updating, I ran into the dreaded OOM-killer! The GCC 4.3 compile uses more than the 2GB available and it aborted the merge. This was with nothing else running, too. So be warned: if GCC dies when you move to 4.3, back off on your MAKEOPTS. I had to adjust mine from -j3 to -j2 while compiling GCC and glibc.

Also, while I was updating my whole system, I decided to move the rest of my X/kernel stack to ~arch, as I wanted the new Intel KMS/GEM/UXA hotness. This necessitated using ~arch xf86-video-intel and Mesa, as well as ~arch gentoo-sources, as 2.6.29 has some needed code not present in 2.6.28. I discovered that while this part of the graphical stack was just fine for KMS and fast graphical login, xorg-server-1.5.3 resulted in hard lockups as soon as I opened any windows. I had to grab xorg-server-1.6, libXfont, and randrproto from the X11 overlay in order to get a usable environment. It works great! No more lockups.

So, how much of an improvement is the new stack over what was available in February? I'll let the following numbers speak for themselves. These are the median-high numbers recorded. For the old stack, the numbers varied from 48FPS to 59FPS. For the new stack, from 489FPS to 504FPS. Sync to vblank and vsync have never been enabled.

xorg-server-1.5.3-r1, libdrm-2.4.4, xf86-video-intel-2.6.1, mesa-7.3, gentoo-sources-2.6.27-r8

$ glxgears 
Failed to initialize GEM.  Falling back to classic.
292 frames in 5.0 seconds = 58.272 FPS

xorg-server-1.6, libdrm-2.4.6, xf86-video-intel-2.6.3-r1, mesa-7.4, gentoo-sources-2.6.29-r1

$ glxgears 
2516 frames in 5.0 seconds = 503.174 FPS

Now, the usual caveat about glxgears not being a good benchmarking tool applies here. However, it is useful for relative comparison from one version to the next. And as you can see, it's an order of magnitude better. I notice that stuff is drawn much smoother; there's less flickering especially when shifting Terminal windows around. And I haven't hardly begun to tweak my system for best UXA performance. KMS is nice and smooth; it happens pretty quick in the boot process. No more flickering, just fast loading of SLiM and then Xfce.

My xorg.conf is pretty minimal; the only changes I've specified for the Intel driver section are these:

Option	    "FramebufferCompression" "false"
Option	    "AccelMethod" "UXA"
Option      "Tiling" "false"
Option      "EnablePageFlip" "true"

There are probably some other things I should add for maximum performance, so I'll have to spend several more days hunting for 'em. But out-of-the-box, I'm extremely impressed with the current X stack.

Now all I need is smooth full-screen Flash video performance . . .

Xfce 4.6

The other thing I put on the laptop was Xfce 4.6.1. Decided that as long as my core graphics stack is part ~arch, it wouldn't hurt to try out the latest and greatest Xfce hotness. Now that some outstanding bugs were fixed from 4.6.0 (including a remote security bug, and an icons issue), I thought it'd be worth it. It's pretty slick. The desktop environment is initialized a bit faster than even a fully tweaked 4.4.3.

About the only outstanding issue I have with it is that there is no graphical menu editor. At first, I couldn't get a satisfactory menu even editing the XML file by hand; it was just too different from the old one. So my menu was cluttered with useless toplevel entries, such as Web Browser, File Manager, and so on. Fortunately, Mike pointed me to the solution, so now all offending stuff has been cleared out. Right now my menu works just fine, so I only really need a graphical menu editor for convenience's sake.

I really like 4.6 a lot. The artwork packaged with it is outstanding; I'm using one of the stock backgrounds because it's just that sexy.

Xfce 4.6 is a smash hit, so well done, guys. Very well done. And there's even more good stuff planned for the future. There's a great interview on Planet Xfce with one of the core developers. He discusses some of the exciting stuff coming down the pipe for Thunar, so make sure to read it.

Gentoo

I've been rather quiet on the Gentoo front for the last three months, because life in the outside world has a way of unexpectedly intruding on me. I've been on devaway since February while I try to get stuff into some semblance of order. Sadly, however, I've had to do much more documentation work than I originally scheduled, which keeps cutting into my plans for other areas. I've made a bunch of bugfixes and commits over the last couple of weeks especially. One of the most visible changes is in the Get Gentoo page, putting the automated weekly builds at the top. The handbooks will be updated, too, but they require a tremendous overhaul, so I'll need all the resources of my fellow GDP members to accomplish that. If I can get 'em, that is.

One of the other things I like to do is find some interesting little-known application, determine its usefulness, then hack up an ebuild for it. It's really good practice, actually.

Out of all the applications I've written and updated ebuilds for, the only one that's got me stumped is WordGrinder. I've been in contact with WordGrinder's upstream author, who's a really helpful guy, but I still can't get the ebuild working. While compiling and installing by hand works great, something happens during the compile phase as run by Portage where it violates the sandbox, killing the merge.

Plus, given the pmfile used by the package, it doesn't really respect a user's CFLAGS/CHOST and related configuration. That has to be altered somehow, so I've been trying to work out a similar solution to the one used by our dev-lang/lua ebuilds. No real luck there, but it's not my first priority. What I really want to do is have the merge workin' with Portage. So it's an interesting, informative, occasionally frustrating learning process.

Anyway, take a look at all the stuff in there. I recently reorganized the ebuilds by category/package, instead of dumping everything into a single directory. Some of these have since moved into Portage sometime after I wrote the ebuild for 'em, and some (like Songbird and WordGrinder) are works in progress. I've run into quite a few nifty apps; places like GnomeFiles are excellent resources. Most of the stuff in here I discovered on GnomeFiles, and a lot of the packages on the website are simple enough that it's just a few minutes' work to hack up an ebuild.

I've just discovered two very interesting minimal word processors. They're designed by writers, for writers. They aim to get out of the way and let you just write, with no distractions.

PyRoom

First is PyRoom, which relies only on pygtk. It's really quite minimal and not distracting in the slightest, and easily themeable. I like it a lot. I created an ebuild, available here. Thank goodness for distutils!

WordGrinder

Second is WordGrinder, an even more minimal application that's entirely console-based. Unfortunately, it uses some weird freaky build system called PrimeMover, and it's scary. I asked one of my fellow developers who maintains the Lua package about it, but he's never heard of it. There aren't any eclasses for dealing with any Lua build system.

According to WordGrinder's Readme, the PrimeMover setup should be pretty simple. However, take a look at the pmfile itself. Man, that's ugly. It looks like three hours of judicious sed usage within the ebuild. I can't see any other way to alter it to something sanely installable to /usr.

If anyone has any tips, I'm all ears. I've got a skeleton ebuild for WordGrinder available in my repository, but it really needs fleshing out. So, who's willing to help?

Hardware: graphics shuffle redux

In other news, I had a really fun time getting my ATI X1950 Pro to work (again) with a silent aftermarket cooler (AC Accelero v1 rev2) and the latest bleeding-edge radeon, mesa, and libdrm packages. The hardware mods were fun, but the software . . . well, that's a long story for next time.

Desktop

Oh yes, and this month's Xfce desktop. Token uncluttered version here. All those artists in that Thunar window are amazing. You should be listening to them right now.

icons: Meliae-dust (needed something reddish)
gtk+: Rezlooks L & D
xfwm4: Rezlooks-gtk (yes, it is confusingly named)
background: The Empire (from pixelgirlpresents)

On Christmas Eve, a special present arrived from UPS: the HIS Radeon X1950 Pro I purchased on eBay. For the week prior to Christmas I removed the discrete nVidia 7600GT and ran off the integrated nVidia Geforce 8200 chip in my motherboard. Utter pain!

Drawing the screen, whether compositing was on or off, was painfully slow. Running any kind of game was out of the question. UT2004 was impossible. I managed to gain a bit of 2D speed by adding GlyphCache and InitialPixmapPlacement options to xorg.conf, but the desktop was still slow as molasses. Made using the computer quite painful. I can personally verify all the reports that nVidia's drivers for the Geforce 8000 series suck balls are quite true. The only thing I gained was being able to run the framebuffer console at 1440x900, my monitor's native resolution. The Geforce 8200 supports this framebuffer mode; the 7600GT only supports up to 1024x768. Not that it matters once Xorg is launched. Anyway, that was a miserable failure, so I was really happy when the HIS Radeon card showed up.

To be honest, I spent a few more bucks on it than I'd like. With shipping, it was about $51. But I figured this could be a tech toy for the next several months. After this fall's debacle with that HIS RadeonHD 4670, I picked up an older R500 card for half the cost, and this one is at the top of the line for its generation. It should have been an upgrade on my nVidia 7600GT even with the FOSS drivers. With all the documentation ATI has released, the developers of the FOSS driver (xf86-video-ati in my case) were able to get working 2D and 3D acceleration some months ago. So, emboldened by all the articles and forums posts over at Phoronix on the exciting things happening to the FOSS Radeon/Xorg/Mesa stack, I gave it a whirl.

The Good

1. There is indeed 3D acceleration. It's partly usable.
2. The 2D acceleration is the fastest of any chip I tried, faster than even the 7600GT with the proprietary driver. Once I switched from XAA to EXA acceleration, it was even faster!
3. Running at my monitor's native resolution at the framebuffer console is possible.
4. It was nice to be able to remove all proprietary kernel modules.
5. The whole desktop stack loads a bit faster, with less modesetting flicker.
6. 3D performance is actually better with the FOSS drivers than it is with ATI's Catalyst (fglrx) driver.

All the stuttering and lockups I'd run into with the RadeonHD 4670 card a few months ago? Yeah, I now believe those weren't hardware issues at all, but shitty, shitty fglrx driver code. I ran into the exact same thing when trying to use fglrx with the X1950 Pro. UT2004 was a constant stutter-fest. Absolutely unusable. When it comes to the proprietary vs. FOSS drivers for usability, there's no contest. FOSS wins across the board.

The Bad

1. Keywording 70 packages or so in package.keywords is a tedious chore. I was after the latest X-server, Radeon, and Mesa updates, which necessitated moving to ~arch for most of the required X packages.
2. I can't switch virtual terminals. The monitor shuts off if it's running on anything but VT7 once X is loaded. Apparently I'm not the only one to experience this issue with this card.
3. Poor 3D performance. I had to turn down all settings to minimums in UT2004, though I kept the resolution maxed. And even with all the minimizing, framerates grew pretty choppy throughout the game. Though the R500 performance has come a long way in the Radeon driver, it's still nowhere near the level offered by my 7600GT and the proprietary nVidia driver. I dunno if the RadeonHD driver would offer any improvement; it shares a large part of its codebase with the Radeon driver.
4. The "gotchas" involved with switching from the proprietary nVidia driver to anything else. If you switch from one proprietary driver to an open-source driver, or a proprietary (nVidia) to proprietary (ATI), you'll have to manually delete a few libGL files, as the symlinks get shattered in a way that eselect doesn't know how to handle. Let's hope that bug gets fixed soon.

The Ugly

1. The fan. I think the video card's fan may have been damaged in transit. I took out the card after just a week because the noise from the fan was so damned annoying. Now, it's not that it's particularly loud; it's not all that much louder than the system fans (which are pretty quiet even when at max). No, what really grated on me was the hideous noise character of this fan. I've asked for some help from folks in the know, so we'll see where this goes. Too bad too; it uses the same IceQ cooler that the 4670 uses, and the 4670's cooler was amazing. I couldn't hardly hear it no matter the load on the card. It had a smooth, pleasant noise character, blending right in with my system fans at low RPMs.
2. Running into the ALSA and OpenAL updates at the same time I was trying to upgrade my hardware and its drivers. ALSA cannot compile. Bug still not fixed.

The new OpenAL version seems to be from a different upstream, one who has no idea what he's doing as far as documentation goes. I had a working config file for .0.0.8, and 1.5.304 broke it. There's nothing but an extremely sparse sample config to suggest what to do. No matter what I put in the new .ini-style config file, I couldn't make it pick up my microphone. When it finally did seem to be able to identify plughw:0,0, it then petulantly died with the message that the requested buffer size was too large. Based on IRC logs I found via Google, upstream suggests that's ALSA's fault, not OpenAL. Whatever, man. All I know is that the previous versions of OpenAL have always worked regardless of my ALSA version. The new one doesn't. So I added 1.5 to package.mask and downgraded. Presto, working microphone. Just the thing for the upcoming UT2004 tourney.
3. Spending $50 just a week before ATI releases the long-awaited R600/R700 programming documentation. Yeah, I'm kicking myself a bit. I'm wishing that I still had that HIS RadeonHD 4670, something that should have better performance than even an X1950 Pro, no matter which drivers are used. But as it is, the FOSS driver devs don't really expect to get a working driver with any kind of OpenGL acceleration for another few months. Approximate feature parity with the R500's current driver codebase is expected in another 8 months or so. So it'd be a long wait, but one that I'm starting to think is worth it.
4. Did I mention the fan? I can't stick that thing back in the case until I've found a cheap solution to silencing the beast. It's not worth pouring a lot of money into it. I mean, if money is being tossed about, I may as well pick up a silent low- to mid-range 4000 card off NewEgg (again).

* * *

The X1950 Pro is currently stored in the closet. I'll dig it out again once I find some solutions to various bugs. Or when more 3D performance improvements are merged. I'd like to use it for UT2004 as well as general desktop work, but I need better 3D performance. And I need to fix that fan! Maybe I can find a decently priced Arctic Cooling Accelero S1 rev 2 someplace.

I'm also really looking forward to the coming KMS and GEM support for R500 cards, hopefully that will all be merged into the 2.6.29 kernel. Just a few more months . . .

I installed Ubuntu Studio 8.10 on my laptop a couple of days ago, wiping out the unused Windows Vista partition. Eh, the laptop didn't come with a recovery DVD anyway.

I know. Why Ubuntu, right?

Simply put, I didn't want to waste time trying to install audio applications that either aren't available in Gentoo, don't compile, or otherwise require excruciating configuration. I wanted an out-of-the-box setup ready to work immediately. My piano has MIDI and line out jacks, and it's about time I finally did something with 'em.

I shopped around the various specialty multimedia production distributions, and finally settled on 64 Studio and Ubuntu Studio. Haven't yet tried the former; I've just installed Ubuntu for now.

Alone among the various official Ubuntu flavors, it still uses the ugly ncurses installer. At least it worked perfectly. It correctly detected my existing Gentoo partition and left it alone.

I have some notes on the experience so far, though as I'm still waiting for my USB-midi adapter to arrive, I can't actually comment on the audio applications themselves. But first, a digression on troubleshooting Ubuntu.

Due to the complexity of the software, with all the vendor configuration, patches, package integration and the like, when problems do arise, they feel much harder to fix. Part of this is that I'm not sure what all's been installed. With Gentoo, I know exactly what's going on the box; there's nothing there ahead of time to discover. Not so with Ubuntu. Figuring out what's on there (that I don't need) is an ongoing process. That being said, when problems do arise, they're not the kind that I run into with Gentoo. I suppose my unfamiliarity with the distro contributes quite a bit to my initial ability to fix things -- what isn't a problem on Gentoo can be in Ubuntu, and vice versa. Ubuntu has solved problems I didn't have the first clue how to fix on Gentoo. By contrast, trying to fix the things I take for granted, like decent hardware acceleration everywhere, is unfamiliar turf on Ubuntu. Here be dragons. Ye be warned!

The Good

• All kinds of hardware working that I was sure I didn't even have. Apparently I actually do have a bluetooth chip, as advertised. For ten months now not a single LiveCD or distro has picked it up, so I thought they left it out when they refurbished my laptop. No need for the USB dongle.
• Working hardware that I had no idea how to make work in Gentoo. ThinkPad features like hotkeys and decent power management. Onscreen popups for backlight and sound. Only thing not working is the mute button.
• Exceedingly nice desktop integration; I generally appreciate the extra upstream patches. The "hidden" options for such things as desktop icon behavior for Xfce are made available in the Desktop dialog. Proper power options on the shutdown menus. Preconfigured audio bundles that all work together out-of-the-box? Heaven.
• Package management is generally a snap. I'm not as concerned with bloat since everything's binary. Lots of package choices, and many 3rd-party repositories that seem trusted and well-used.
• Beautiful desktop environment. Finally, a decent dark theme.
• Good documentation on the Ubuntu homepage, though the search function for both official and community docs sucks big-time. It really can't be counted on. The wiki itself is freaking weird; the generated page titles aren't so human-friendly. Takes some getting used to, as it's not as intuitive as Wikipedia.

The Bad

• No wireless networking ready out-of-the-box, though at least it doesn't ship with the bloated POS that is NetworkManager. Fortunately, wicd was an easy install.
• Slower bootup. Uses Gnome, so that's noticeably slower than my usual Xfce setup.
• In spite of some small improvements here and there to specific areas of power management, battery usage is actually a little higher overall than Gentoo.
• No real working HDAPS. Documentation is spotty, inconsistent; scattered across thinkwiki, ubuntuforums, and the internet. In fairness, this isn't working on Gentoo either, but you'd think Ubuntu would have this working, since all the other ThinkPad hardware works.
• Synaptic sucks for managing multiple installs/removes. Having to right click a million times for each package is a pain. The database is kinda slow to load. The search features needs work.
• I still miss USE flags. Having to install Ruby just to install gVim is bleah. Same for other packages.
• Manually compiling packages doesn't bear contemplation. I miss the automation Portage provides.
• Despite following the official instructions on enabling DVD playback and DVD navigation, the default player in the menu (Totem) can't actually play DVDs, failing with an error message that said "No reason." (No, really. That's what it said.) I had to go to the command line and run totem-gstreamer. Unnecessary stumbling block. Similarly, mplayer can't go through the menus, even though the appropriate libraries are installed. Mplayer was one of the suggested players to use with libdvdnav, but a quick scan of its binary doesn't indicate it was built against it. It can play the main feature, however.
• DVD playback is somewhat slower than Gentoo. So far I've tried gxine, mplayer, VLC, and totem. All exhibit more clipping and framedropping in Ubuntu than in Gentoo.
• The ubuntuwiki font is ugly. Need a way to change that without disabling custom fonts for all sites in Firefox. Yes, it hurts my eyes enough to merit inclusion here.
• Not being able to eject discs after playing them. Why doesn't the button work? Could just have been a bad session.
• No Handbrake available? Sad day.
• Right-clicking in gVim to copy text doesn't work, despite the same config files copied from Gentoo. Neither does pasting it with Ctrl-V in Firefox. Something's screwy here.

The Ugly

• Worst nonworking version of Alacarte EVER. Don't bother trying to adjust menus or move items up or down or drop items into a new subfolder. Almost nothing works.
• At boot, when the desktop tries to load, occasionally I'll get a frozen, garbled screen that repeatedly resets as X tries to restart. So much for "bulletproofX". Whatever Ubuntu developers have done to the kernel for Intel graphics, they screwed up. Odd; this X3100 chip works perfectly in Gentoo for every kernel up through 2.6.27.
• Having to spend hours tweaking the system to get something only vaguely close to my comfortable, familiar Gentoo setup. (And hoping that I don't just uninstall the whole thing after all that work!)

Will it stay? Will I completely make the move to Ubuntu Studio, at least on this laptop? Too soon to tell. But I am very, very impressed with what I see. I like it a lot. I'll know more after I've had the chance to use the audio production software in a few days.

That's right, no longer will I be writing a series of failed hardware posts. No, now I've had some successes on the hardware front. I've slowly started coming back to my usual Gentoo work. Still not all the way back yet, but I'm almost there.

Revamping the desktop

First: it was a dead motherboard, possibly also a dead PSU. The motherboard for sure didn't work; tried it with the rest of my new hardware but got nowhere. I'm not willing to risk my new hardware with a possibly faulty PSU, so I won't be doing any further testing there.

Anyway, I went to Fry's a few weeks ago and purchased an ASUS M3N78-VM motherboard. It's a microATX motherboard, so already all the slots are used up (the graphics card takes three slots, and the PCI sound card has the last). Now I have a reasonable upgrade path, as this is an AM2+ board. Phenoms and their successors are now available to me!

Even though the board does have an nVidia chipset, its storage system has a working AHCI implementation, so all my drives work just fine. Except that for some reason, the Samsung RAID array doesn't have NCQ enabled, while the single Seagate storage drive does. A minor bit of lame, but I didn't have working NCQ with sata_nv anyway. The SATA optical drive that's been gathering dust in the closet for a few months now works, too. Score for AHCI.

The BIOS is fairly limited in terms of doing anything with processor frequency or voltage at stock or lower speeds. Yes, I would have liked to undervolt the CPU to save a bit of power and heat, but unlike the MSI motherboard this one can't do that. It's only setup for overclocking, not under.

The BIOS is easy to update -- just toss the file onto a USB stick, reboot, select it from the BIOS menu. Alas, this board isn't one of the midrange/higher-end models, so it does not have ExpressGate installed -- it's funny, but I would have to use the DVD to install it, and that's designed only for Windows Vista. Yes, you read that right. If I want ExpressGate, a Linux-based operating system, I have to use the Windows Installer CD on a Windows System to install it to the hard drive. This motherboard is a bit more budget; it doesn't have onboard flash for ExpressGate.

Graphically challenged

That new ATI graphics card I liked so much? Well, it seemed to have a few problems even on the new board. Framerates were terrible; UT2004 was a constant stutter-fest, and that was with DRI enabled and working correctly. This card should have been running circles around the old nVidia 7600GT. So either the hardware was defective, or ATI's Catalyst drivers still suck assballs. Probably both, but I still sent the card in for a refund.

The motherboard has an nVidia 8200 IGP, but I decided to plug in the old 7600GT. Presto, it works! The card never went bad, after all. Was just the crap 'board it was on. So I'm now back to nVidia -- I won't be buying any ATI products in the near future, either. Also, using nVidia makes kernel configuration much simpler; no need to enable crazy stuff in the "Kernel debugging" section just to use the Catalyst drivers.

Hacking the routers

Just when I was starting to get the last of the hardware issues fixed, my router finally craps out. Really, I should have replaced it 3 months ago, when it first started flickering. I finally threw in the towel after I was power-cycling it 7+ times per day. Crappy D-Link firmware.

Bought myself an ASUS WL-500g Premium v2. Same price as the new Linksys WRT-54GL Linux-based router, but the ASUS has at least twice the hardware specs, and it's just as friendly to flashing with Linux. I should know -- it arrived earlier today, and a few hours later I had it successfully flashed with the latest DD-WRT. Used a custom mini-USB version pulled from SVN, actually, as suggested in the installation instructions.

I couldn't use the default ASUS web interface to load the flash, and I lacked a Windows computer to use their included flash tool. I ended up doing a few trial-and-error experiments to TFTP the DD-WRT firmware onto the machine. Which reminds me: I hate tftp-hpa, for the sole reason that there's no tab-completion. I expected the experience to be more shell-like? Darned retyping every command . . . and apparently I was doing it wrong with the options listed in the manpage. Ah, well. The result was the same in the end.

The last thing I needed to do was setup the print server, which was accomplished with minimal fuss. So now I have a working print server. Plugged in our printer, and now we can print from any machine in the house. Wireless printing is pretty sweet. Still have one more free USB port on the router, too. Gosh, the possibilities....

I'd run Gentoo on the router, but it seems like too much work, if it's possible at all. Besides, it's hard to beat the attractiveness of prepackaged firmware that needs next to no configuration.

I was about to toss out the old router, a D-Link DI-624 rev. E1 (apparently NewEgg sold me the European model a few years ago?). However, I discovered that D-Link released source code for it. Apparently, this crappy firmware that's required periodic resets and many, many reboots since I purchased it is actually Linux-based. D-Link had been violating the GPL for some time and only just released the source last year. No wonder they never released a single firmware update; the product was EOLed not long after I bought it.

Anyway, the thing comes with some variety of MIPS R4600 chip, and included in the source tarball is the stuff for doing a full cross-toolchain compile, ending up with a kernel and a firmware image. Internet reports via Google are a little sketchy about whether or not custom images will actually work, since I think the device only has about 2MB flash. That's probably too small, though somehow D-Link made it work. This is a fun stretch of my embedded hacking skills, at least. I'm going to make the effort to get my own firmware on the thing. Anything's gotta be more reliable than what was originally on there.

* * *

Update: I did some searching of manufacturer product pages, and I think this particular DI-624 has way more flash than I'd allowed for; the chip seems to be the 32MB variety.

Also, and this totally floored me: the router runs on Gentoo. I kid you not. Gentoo. All the source code is setup for building another Gentoo image, too. It's got Portage 2.0.51-r15, and a few of our initscripts. The rest is altered a fair amount, but not unrecognisably so.

I now have Gentoo firmware for the Atheros AR2316 SoC at the heart of the router. Time to see if I can successfully flash this MIPS critter.

Gentoo: it powers rockets, the backbone of the internet, lighting and HVAC controls (go read the GMN), and common home routers such as the DI-624 and DI-524 (same source for both.) Who knows how many other D-Link products are powered by Gentoo Linux? Only way to find out is to grab the source code from the manufacturer.

Yes, the ongoing saga of my hardware meltdown continues.

The Seasonic M12II-430W power supply I ordered finally arrived today, and oh man, is it nice. The modular cabling makes it so much easier to work inside my case, besides improving airflow since I need far fewer cables.

I threw in my RAID1 array and booted the machine up, and it ran just fine . . . for a half hour. And then it froze again. Went out to lunch and never came back.

So, since the PSU is good, the new graphics card is good (the old one is completely dead; it won't output at all), the drives are good, the outlet and power strip seem good . . . I guess the only suspect is the motherboard itself. It can't be software: I ran a few liveCDs that don't use x11-drivers/ati-drivers, and they all locked up at some point.

I thought about switching to Intel, given the excellent chipset support in Linux, but it's cheaper to just keep my existing Athlon X2 CPU, rather than buy a whole new motherboard and CPU.

I believe I'll purchase this board, the Asus M3A78-EM HDMI. Sure, it's microATX, but I only have a single dual-slot PCIe graphics card and a separate PCI sound card, so it's not like I need lots of expansion space. Another plus is that the board supports AHCI for drives, though I've read that there may be issues with AMD's AHCI implementation in SB700 chipsets. Reports are mixed, however, and there's next to no information for Linux users. Hopefully I can get it working; it'd be nice to finally use my Asus SATA DVDRW. It doesn't play nicely with sata_nv for nVidia MCP55 chipsets, so it's been gathering dust in the closet.

Any experiences ya'll have for this Asus board (or other good AMD chipsets for socket AM2/AM2+) would be appreciated.

* * *

What with all the hardware craziness, I've put myself on devaway; I don't know when I'll be able to really get any work done this month. Once I get my new hardware, assuming it works, I should be able to pick up Gentoo development where I left off.

I really don't know what I'll do if the motherboard doesn't solve the lockups. Weep quietly in a corner, perhaps. Swear off computers forever, maybe.

More updates on the constant meltdown of my workstation. Thanks to the folks who commented on this blog and on IRC -- I had some helpful suggestions and thoughts.

I managed to get rid of the graphical corruption by switching to a different graphics card. Yes, I know the same kinda corruption can occur with a bad or missing grub splashimage, but I'd been running with one for two years and no issues. Since my grub.conf doesn't really change, that wasn't the cause. So I kinda fixed one issue -- new graphics card, no framebuffer/grub corruption.

Unfortunately, the lockups continue. So the biggest issue the new purchase was supposed to fix . . . didn't. I got shafted on tax and shipping, so what should have been an $86 card turned into $101. Ouch. That's a fair bit above the $80 neighborhood that the RadeonHD 4670 is supposed to be. Still, I got a nice HIS IceQ card. I truly can't hear its fan; it's got a very nice Arctic model. It's a nice enough upgrade, but since my system still has issues it's fairly pointless.

I switched power outlets, thinking maybe it was bad wiring in the walls. No change. Tried switching NICs again. No change. Played with some BIOS settings; I noticed a couple of IRQs being shared that really didn't need to be. No change. Tried removing my sound card, since it's the only PCI device in the system. No change.

Then I tried booting a LiveCD. SliTaz, actually. It runs entirely in RAM. It worked okay for about an hour and a half. I let my system mostly idle for a few hours; when I came back, it was hardlocked and showed no sign of recovering.

Fortunately, I'd backed up all my data to a separate disk, in preparation for reinstalling. My system stayed stable just long enough to copy the data and pull the drive; it actually hardlocks on shutdown and reboot now, too.

So, since a completely different kernel and operating system didn't show any improvements, and neither did the graphics card or running without CD drives or hard disks, I figure the problem must lie with the motherboard.

Right?

To that end, I've been searching for cheap ($80) motherboards that support socket AM2/AM2+, since I plan to save some money and reuse my Athlon X2 4600+, rather than switch to Intel. Based on all the failure reports out there, I'm avoiding Gigabyte, EVGA, and ECS motherboards. ASUS has a very attractive line of M3A78 boards, usually AMD780G chipset. I'd like one with a 790GX chipset, but that's in the $150 range. The ASUS boards I've looked at are all in my price range; it's just a matter of finding one that I like. About the only requirement I have is that it uses only solid-state capacitors and power circuitry. I'm not going to touch anything that has the possibility of leaking/exploding caps.

The other major requirement is that it needs to have working AHCI mode for SATA disks. I ran into a recent Phoronix forums post that said ATI chipsets have "buggy as hell" AHCI support, which doesn't bode well. But I don't really want to go down the nVidia route either, not since I filed that bug awhile ago for the failure of sata_nv to work with optical drives on the MCP55 chipset. Any suggestions, chipset-wise?

I suppose it's not really a good time to be buying stuff from either AMD or Intel right now, given the nifty stuff coming out next month and after, but I've no time to sit around waiting. I've got stuff to do. Ebuilds to be hacked. Newletters to be sent. Docs to be written. I mean, what with the coming stabilization of baselayout-2, OpenRC, Portage-2.2 . . . you name it.

First, thanks to everyone who wrote in on that last entry, and thanks also to Robin and Tony for some specific kernel/hardware ideas.

My workstation continues to lockup not-so-randomly, with the majority of freezes occurring while gaming.

I remembered that I undervolted my CPU a respectable amount a long time ago, so I upped the voltage just a little bit, to 1.175V, thinking that maybe it was undervolted a bit too far, and the issue took a long time to manifest. No change. Can't say I noticed any difference.

Next I thought I'd upgrade to the latest hardmasked nvidia-drivers. No change. Then Marius suggested using the nv driver to see if that fixed things, but the problem there is that a good amount of freezes occur while I'm doing something with 3D graphics, which nv can't do. So that wouldn't tell me much. Also, the graphical corruptions occur at boot and prevent the display of grub.conf, so I figured the X drivers may not be related to the issue.

To test this, Robin suggested that I remove framebuffer support from my kernel entirely. It made the issues worse! Now I seem to be on the right track. Previously, with the framebuffer enabled, the Grub screen doesn't display, but as soon as the kernel loads uvesafb and my initrd early in the boot process, the screen clears up and returns to normal. The fbsplash theme displayed just fine.

With framebuffer disabled, the severe corruption continues all the way up until init enters runlevel 3, as you can see in the following pictures I snapped with my cell phone.

Early in the boot process, just after grub loads the kernel

More mangled text

A clear screen once runlevel 3 begins

Tony figures the graphics card memory is bad, and based on what I see, I'm inclined to agree. I already figured it was probably time to replace the graphics card, so now I'm shopping around.

I've always liked my nVidia chips over the years, and this one has served me well. Still, now that the ATI RadeonHD 4670 is out, I'm strongly considering getting one. I like that it offers better performance than my 7600GT for about $80, which is half of what I paid for the nVidia card two years ago. It can handle UT2004 and any current games, assuming they run on Linux. I only have a 19" monitor, so I don't need to spend a lot of money to find a powerful card at extremely high resolutions.

Plus, the ATI card has basic support from both xf86-video-ati and xf86-video-radeonhd, though neither driver seems to be capable of 3D acceleration. I'd stick with the binary fglrx driver for the time being. The only thing I'm not sure about is whether or not the new & improved Catalyst Control Center Linux Edition (AMDCCCLE, phew!) actually supports fan adjustment, or if the temperatures can be queried and reported in a panel applet. I've been spoiled rotten by my passively cooled 7600GT, so I want to keep control over the fan noise. If there were passive 4670s on the market, I'd get one, but that hasn't happened yet. Maybe in the future, once I'm ready to use the FOSS driver, there will only be one. Right now I couldn't choose between the two; I'm hoping they merge on down the road. Too confusing; this consumer wants less choice.

Y'know, I used to be fairly avid nVidia Linux fan, simply because for so long ATI's support was a joke. It took them forever to come up with a hardware counter to nVidia's SLI tech, and then another ~3 years before the Linux support for it rolled around, and that's just the beginning of their disregard for Linux. But 2007 marked a turnaround, so now I'm actually rather impressed with the amount of work they've done for open-source drivers. They've really been making progress.

nVidia still shows no signs of opening up their stuff, aside from the largely-unnoticed-and-irrelevant CUDA initiative. But for years, their stuff just worked, as much as a binary driver can be expected to, especially compared to fglrx. Maybe old age has mellowed me a bit, as I'm feeling pragmatic enough to think that purchasing a card from the Red Team would be smarter than buying another Green card. I mean, sure, nVidia usually just works for me, but I know they don't plan on doing much featurewise; they've already killed off hardware video playback accel, and they haven't announced anything special for Linux or put out any kind of roadmap. ATI has, with things like UVD2, Xvmc and many other features they intend to bring to Linux in the various drivers. They want users to actually use their hardware features. What a concept! nVidia, you listening? And for reasonable card prices, too.

I mean, nothing nVidia has at the $80 mark comes close to the performance of the 4670. I could immediately put it to use with fglrx in UT2004 and Xfwm4's light window compositing, while at the same time look forward to open-source acceleration in the months to come.

That seems like a win all around, but I'll need to do some more research. Hopefully I fix these hardware issues with just a new graphics card. I'd hate to end up purchasing a whole 'nother machine before the problems disappear.

Oh, how the hardware hates me. My poor Gentoo development box and primary desktop workstation has been suffering a long string of random lockups lately.

It's not heat. CPU temps are anywhere from 26C to 42C depending on load. GPU between 48C and 62C depending on load. Hard disks are steady at about 30C. All well below anything approaching a danger zone.

I figure it ain't my power supply. I have a quality Seasonic SII-380W that's given me two years of sterling service. My system doesn't come close to exceeding its capacity.

I tend to get more frequent lockups when doing 3D-intensive stuff, such as playing UT2004. That's when I get the most lockups. However, they also happen when I'm just doing desktop work or have a browser open. I normally run Xfce with the compositor enabled, so at first I suspected it was unstable. Turning it off made no difference to the frequency of lockups. Scratch that.

Today I cleaned out the machine, getting rid of a fair amount of dust. I had to remove the graphics card to get at its cooling fins, and ever since reinstalling it and rebooting, there are minor graphical glitches covering the screen at bootup, at least until the initrd is loaded. Everything's fine once fbsplash and X kick in. Maybe I shoulda wiped off the PCIe contacts or something?

About the only thing I can do to check the graphics issue is upgrade my drivers, which I'm doing now. I'll go with the latest 177 version. nVidia has listed several stability fixes that may help.

I checked my logs -- there aren't any messages that give me immediate clues. No kernel panics or graphics errors or anything useful in dmesg. Except possibly one thing: in every case of a lockup, immediately before and during it there's a stream of bad/invalid packets running in and out of my NIC.

I'm only noticing this because I have my iptables rules setup to notify me anything that doesn't fit all the chains I've established. I'm wondering if my NIC is on the fritz; perhaps the hardware is getting confused, and it's doing something to . . . something else.

Coincidentally, my router has been quite screwy lately; I usually have to powercycle it in order to connect; it just stops working overnight when my computer's off. And even during the day, it tends to go down while I'm in the middle of doing something. My router's weird, and I have weird stuff in my NIC logs. Could they be related?

The only test I can do right now is start using my other NIC; my motherboard comes with two, each with a separate controller. And I have a few spare ethernet cables, though in my experience they aren't as fragile/problem-prone as SATA cables. May as well swap those too.

To sum up, if the easy software fixes or NIC swaps don't work, I'm going to have to throw hardware at the problem until I get a solution. I could spend $30 (new NIC or router), $140 (graphics card), or even $400 for a new motherboard and CPU.

I hate troubleshooting hardware. It gets expensive real fast.

Hello again, Planet. Another month, another week, another doc or three, another bug, another GMN. Etc.

* * *

For the last month I've been dealing with optical drive issues. First my IDE drive, then the new SATA drive.

The issues with the Samsung IDE optical drive seem to be resolved with kernel 2.6.25, and with the newest stable gstreamer packages. Audio applications can not only see the drive and the media inside, but can actually play the tracks.

Now, however, I'm having issues with the Asus SATA drive I bought when the IDE drive was acting up. It's giving my system fits, as you can see in bug 221145. Libata just hates this drive, no matter what kernel I use.

I did discover that the SATA cables I had been using were bad; they were the original cables packaged with my MSI motherboard. I ordered replacements and plugged 'em in. No more cryptic. I/O errors in /var/log/messages.

However, the drive is still no better off than it was. Applications can see what's in the drive, but can't read from it. The weird thing is that I can sometimes use the drive to burn discs. I was able to burn distro ISOs, and copy them from the Samsung to the SATA drive for on-the-fly burning. But reading is right out. Strange. There are no error messages; there are no unusual messages of any kind. For awhile, I wasn't sure if the errors were of the common variety (poor SATA cables; seems it's universal), or if the SATA ports on the motherboard itself were bad. Given that just swapping out cables removes the errors messages, I assume it was the former.

So basically, I've spent $53 on a drive (Asus DRW-2014L1T), SATA cables, and shipping, and I'm stuck with a piece of nonworking hardware. Maybe I should have gone for another IDE drive, but I only have one IDE port on my motherboard, and it's in use by the other drive. Besides, SATA is supposed to be the way forward. I'd like to eventually have just one kind of interface for everything. Better bandwidth than IDE, no master/slave hassle, etc. Alas, the kernel and my applications refuse to cooperate with the drive. And there's no updated firmware available from the manufacturer, either.

If anyone has any suggestions not already covered in the bug, lemme know. I'm about out of ideas. The only thing I've come up with is booting with some other distro CD, one with known good hardware detection, like Knoppix or *buntu, from the IDE drive, then try to play a disc in the SATA drive and see if it works. If it does, I'll have to hunt up the kernel config and version for the LiveCD.

* * *

Now on to the good news. Jeremy Olexa (darkside) has added wicd to the tree. And not just wicd -- a working version! So now my laptop is amazingly happy. As am I; I had been trying to make wicd work for a long time without success. Fortunately, upstream released 1.5, which creates a much simpler dependency chain, and introduces better networking scripts.

Wicd really makes networking much easier when jumping between networks. It removes all the guesswork from network configuration, as well as the long, arcane iwconfig and wpa_supplicant command sequences. Random public hotspots are no longer a challenge. Just point and click to connect. Wicd is faster and more reliable than NetworkManager, and it has fewer dependencies.

I filed a bug requesting configuration information to be added to the ebuild. Jeremy obliged, so do read the output after you've installed wicd. It really is simple to setup, though baselayout-2/openrc users will need to make a couple of changes, replacing /etc/conf.d/rc with /etc/rc.conf. Here's how I setup wicd for my laptop:

# rc-update del net.wlan0
# rc-update del net.eth0
# rc-update add wicd default battery
# nano -w /etc/conf.d/rc
RC_PLUG_SERVICES="!net.wlan0 !net.eth0"

I rebooted, just to test its autostart capabilities; previous versions could never start properly. 1.5 does; no issues so far. It displayed my network, asked for my key, and then connected. Simple, but oh-so-wonderful.

I'm now a proud wicd user.

My AMD desktop workstation is dependable. It's always worked like a champ, with nary an issue. Until now. Now, I'm getting issues in spades.

Let me direct your attention to bug 221145, which contains the details of my woes. It started out as a simple (apparent) kernel issue, in which the newer libata subsystem can't be used with my IDE optical drive. I'd been using the old IDE subsystem. libata is supposed to work for SATA and PATA devices alike, so it should work with the IDE controller on my nVidia MCP55 chipset, right?

Wrong, apparently. Ah, but this was only the tip of the iceberg. Turns out that it's not just my kernel (or whatever it is), but my applications themselves aren't working with the drive. Especially gstreamer-based audio apps, and Gnome audio apps. Totem, Decibel, gnome-cd-player, and a few other gstreamer-based apps I briefly tried. Nope, none of them can play audio CDs. Or DVDs. The really weird thing is that they can see the media in the drive. Decibel will recognize the disc ID, get the info from CDDB, load up the tracklist, but then refuse to play the individual tracks. It doesn't really believe they exist. gnome-cd-player is hardcoded to look for /dev/hda apparently, and can't be changed to look for the correct drive.

It gets better. I switch to the 2.6.25 kernel, and now some CDs have a few playable tracks. But I can't play anything past track 4, or track 9, if I'm lucky.

The woes continue: I bought an Asus SATA DVDRW drive off Newegg, which I installed this morning. It seems that it'll use the same sata_nv drivers that my SATA hard drives use, so no kernel changes needed. Reboot the machine, fire up Decibel, and . . . you guessed it. Track info can be fetched, but nothing will play. So I tried booting with "libata.dma=1" appended to my kernel line, as suggested in the bug, but nothing changes.

This is really weird. A native SATA device that can't work with libata. Not an IDE device masquerading as a SATA drive, but the real deal. At least my SATA hard drives still work. Did I not get some memo on nVidia MCP55 chipsets not liking SATA drives? Or that the kernel code for 'em may not work? Or something.

I'm at my wit's end. If you've got any ideas that haven't been covered on the bug, I'm all ears.

* * *

In other rocks and hard places, I did have Xubuntu on my old Toshiba laptop for a coupla weeks or so. Installation went smoothly, but man . . . Synaptic is slow. Same for the Gnome apt frontend. Remember, this thing ain't for me, it's for my wife, so going to the commandline for packages is forbidden. Anyway, I spent two rather disappointing weeks trying to slim it down into something with better performance. I'd wanted to go for a lightweight WM-only environment, instead of the default Xfce. But Xubuntu is just too bloated; it's far too much work to trim down everything. As "light" as it is, compared to vanilla Ubuntu, it's still not a good place to start building a small system.

So I ended up installing SliTaz, as a new "cooking" edition was just released. Man, SliTaz is nice. There's no support for wireless, unfortunately, but that's about my only quibble. Oh, and there might not be essential Toshiba-specific packages available; I couldn't get working internet, so it's hard to tell. But still, I mentioned a few months ago that SliTaz was the most impressive of all the distros I'd tried, and that's still the case.

I may give it another shot, but in the mean time I've been downloading more ISOs, getting ready for the next batch of testing and reviews.

Coming soon: Damn Small Linux, Linpus Linux Lite (seems to be optimized for mini-laptops with specs not much better than mine), Shift Linux, OpenGEU (E17-based, which apparently performs better than the last time I tried it a few years ago), and another stab at NimbleX and Zenwalk.

Assuming, that is, that I can ever get my stupid optical drives to work. CURSES.

I'm in search of a lightweight distro for an ancient 1ghz, 128MB RAM laptop. One of these days, I'll find a distro that properly supports ACPI and VGA-out. I hope.

In the first article of this series, I test-drove three lightweight distros: Fluxbuntu, TinyMe, and SliTaz.

In the second article of this series, I tested Linux Mint 4.0 Fluxbox Community Edition.

In the third article of this series, I tried Puppy Linux and antiX.

Now it's time for DeLi Linux.

DeLi: the good
DeLi Linux is specifically designed for older hardware, and declares it will only use lightweight software. Good news so far. I actually seem to have working hardware support for both CLI and X session. For most distros, I get proper screen blanking and automatic fan control only during a console session; once an X session is started (and/or HAL, that damned dirty animal) the fan kicks in and can't be turned off. And neither can the screen. But DeLi succeeds there.

DeLi: the bad
The 0.8 liveCD is actually just an installer; there's no try-before-you-install desktop environment. And it's an ugly installer. It's probably the absolute worst installation experience I've ever had, for any operating system.

For starters, though you can partition your hard drive however you like (indeed, the installer assumes you've run fdisk ahead of time), DeLi will use just one partition for everything. Also, it insists on ext3; other filesystems aren't an option. As if that isn't bad enough, it forces a complete format of the whole partition. None of the usual 5-seconds-to-mkfs.ext3 quick creation found in every other distro. Oh, no. It went sector-by-sector, bit-by-bit for my entire 60GB disk. Yeah, thanks.

You already have a completely formatted ext3 partition? (Perhaps from a previous DeLi installation attempt?) Too bad. There's an option to skip this step, but this just ends the installation process immediately. You're forced to format the partition if you want to proceed.

And it comes with the ancient and user-unfriendly Lilo bootloader. I'm a grub man, and I felt like control was being taken out of my hands. Fortunately, lilo installation to the MBR worked correctly, so it boots properly.

The installer is, surprisingly, even more painful to get through than the old curses-based Ubuntu installers, worse even than Fluxbuntu's installer. The DeLi installer is an arcane mess. Instead of doing all the initial user-specified configuration up front and then waiting for the automated install process to finish, the DeLi installer treats you to the sit-and-wait game, complete with extremely scattered bits of user input followed by long waits and progress bars that don't actually move. The user config bits are the worst, as once you select an option, there usually isn't an obvious way to move on to the next screen. Take the keyboard maps and language selection screens. I picked en_US, and hit enter. Nothing happens. Huh? Scroll back up to the top. Nope, nothing there. K, let's go the other way. Way down at the bottom, dozens and dozens of language selections later, is a single button for the next step, but get this, it's pointing backwards, as if to say "go back a step, because you screwed up, genius!" I dunno if this is leftover from some right-to-left version, but it ain't nice, considering the installer is written in English.

Also, I realize that, as a Gentoo guy, I may not have much room to talk about "sit-and-wait" installation methods, but hey, at least with the CLI-based Gentoo install, it's a busy activity. You can run much of the install in parallel, on different terminals, excepting a few critical steps. Also, assuming you have a working network for the minimal CD, you can always do stuff online. You're not forced to babysit the install process. Well, not the same way, at least. Plus the Gentoo install is scriptable. It's possible to get it started and then walk away.

Not so with DeLi -- this thing has to be monitored constantly, so that you can deal with the elusive bits of user input.

DeLi: the ugly
The installer is a chore, but the real work lies ahead. For starters, I had a rough time getting a (semi)working desktop. IceWM was installed, but there's no X session started by default. Good thing I know how to setup ~/.xinitrc on my own. Also, several services that I take for granted, including net, GPM, and pcmcia, weren't started by default. Not nice. As a "desktop" distribution, all this should have been setup ahead of time.

I could do it the manual way, or I could use the delisetup tool. This is a CLI app to configure things like keyboard, language, lilo, network access, X server, WM, mail, package installation, and local services to run at boot.

Unfortunately, it's buggy as hell. Though it seems to remember the last items selected, it doesn't actually do anything. No real configuration changes were made, and yes, it's properly run as root. Also, the "mail" and "services to run at boot" sections crashed the app entirely, with no traceback or error output. "Install additional packages" seems limited only to installing inetd, gpm, coldplug, net, pcmcia, and a few other basic daemons. Basically, the things I thought I'd already dealt with during installation.

Okay, so how about the rest of the desktop/CLI experience? Slow and glitchy. Both console and X are filled with constant, irritating flickering, when entering commands (and especially tab-completion), and during scrolling output. The X session is no exception. I've never used a slower IceWM setup, ever. My laptop can run Gnome from a liveCD faster than whatever setup DeLi uses for IceWM. It's also replete with flickering and excrutiating slowly redrawn windows. Opening up the ROX file manager is an exercise in frustration. Moving it or resizing it is even worse. Same goes for the hideous stock xterms. If you're going to ship plain ol' xterm (instead of something like aterm, urxvt, or Sakura), at least give it a different color scheme and something besides its default eye-gouging fonts, okay?

The included webbrowser is NetSurf, and it actually comes up fairly quicky, considering the poor performance of everything else. Same goes for the email client, Sylpheed. Unfortunately, they can't access the internet, because the delisetup configuration tool doesn't work. Also, despite manually starting up the appropriate initscripts and manually configuring my system for DHCP, I still can't get net access. Chalk up another failure for DeLi where every other distro succeeds here.

While on the subject of daemons, initscripts, and config file locations, DeLi is a bit weird. It feel like it took the most failtastic parts of Slackware and Arch Linux. Which is weird; both those distros on their own do much better.

DeLi does include pacman (from Arch) for software installation, but it's no good without a working internet connection. Too bad; despite installing everything available on the CD, there's hardly anything there. Sylpheed, NetSurf, xterm, ROX, Gnumeric, Abiword, ePDFview, and GQview. That's it. Oh, and an unnamed calculator. That's a bit too minimal.

But it's not like I'm able to actually do anything with this system. Time to close down this DeLi.

Coming up: PCFluxboxOS, Damn Small Linux, Arch Linux, and possibly even NimbleX. Stay tuned.

I'm in search of a lightweight distro for an ancient 1ghz, 128MB RAM laptop. One of these days, I'll find a distro that properly supports ACPI and VGA-out. I hope.

In the first article of this series, I test-drove three lightweight distros: Fluxbuntu, TinyMe, and SliTaz.

In the second article of this series, I tested Linux Mint 4.0 Fluxbox Community Edition.

Now, I'll sum up my impressions of Puppy Linux and antiX.

Puppy Linux is a homegrown mini-distro with several different flavors available. It's well-known for being lightweight, able to run entirely in RAM even. It's also the distro that has introduced me to several different applications I've never heard of before, including some CD burning programs. A fair amount of the applications and configuration utilities available on the liveCD are written specifically for Puppy; they're definitely newbie-friendly, and seem to be especially focused on Windows-to-Linux converts.

So, let's talk about the CD itself. It had just about the fastest boot I've ever seen, wasting no time to get me into a JWM environment, which ran quite speedily. It loaded itself into RAM by default, and provided a handy panel applet that displayed free memory available. Unfortunately, it was rather broken in my case; it showed that I had at least 512MB total memory, and that Puppy was using about half that. Oops, not quite -- I only have 128MB installed.

Still, the CD had quite a nice selection of packages; it's amazing how much was crammed in. It came with the Seamonkey suite for internet access (and for HTML editing). I was a bit worried about this, as the ol' discontinued Mozilla has always felt bloated to me in the past. Not so in this case; Seamonkey ran better than the typical Firefox on every other LiveCD I've used. It felt like an embedded browser, actually, in terms of quick response. Puppy has the most comprehensive array of packages I've come across on a mini-LiveCD so far. There's even a CD remastering tool available, similar to the one SliTaz offers. Want your own Puppy variety? A few clicks will do it!

However, Puppy's support for ACPI and the other necessary bits of my laptop wasn't working in the slightest. I opened up a root terminal to start loading modules, but ran into tons of "module not found/does not exist" errors. I checked /lib/modules to verify that the ACPI-related modules I was looking for did in fact exist, but they still could not be found. What's up with that?

Puppy has a lot to offer, and like SliTaz, I'll be watching it closely in the future. but for now . . . no way to turn off the fan o'doom or get dynamic CPU scaling means this Puppy is going back to the pet shop. Next!

I gave the MEPIS-based antiX a try simply because a reader mentioned it in a comment on one of the earlier articles. It definitely sounded interesting, so I downloaded the "base" edition and got to work.

It booted reasonably fast, and dropped me into a pretty SLiM screen. The liveCD has both IceWM and Fluxbox, so I went with the latter. The "base" CD was indeed quite minimal. Though it ran speedily enough, much better than most other distros I've tested so far, it didn't come with much in the way of software. Most menu entries were to plain ol' xterms that launched some CLI application or another. There's not much in the way of graphical configuration apps, and there's nothing resembling a real power/ACPI manager.

Which brings me to the biggest failing of antiX: it doesn't have working ACPI or APM for my Toshiba. Sure, the toshiba_acpi kernel module can be loaded, but I can't do anything with it from there. Can't turn off the blasted fan, nor did CPU speeds ever seem to vary as needed, despite opening the antiX control center and checking the appropriate box.

antiX has promise as a lightweight distribution; it's speedy enough, but it can't handle the hardware. So long, antiX.

Coming up: PCFluxboxOS, Damn Small Linux, DeLi Linux, and Arch Linux. Stay tuned.

In the first article of this series, I test-drove three lightweight distros: Fluxbuntu, TinyMe, and SliTaz. I'm in search of a lightweight distro for an ancient 1ghz, 128MB RAM laptop. Of the three distros I tried, I was most impressed with SliTaz.

I took Linux Mint 4.0 Fluxbox Community Edition for a spin yesterday. How did the second Ubuntu-based distro do?

Worst-performing LiveCD ever.

And I mean ever, on any hardware I've had to use. Even booting a Gnome-based LiveCD and running Evolution and OpenOffice on this old laptop showed better performance. Booting Ubuntu 5.04 on my wife's ancient iMac G3 (128MB RAM, CPU about 400mhz) took less time than Linux Mint did.

Linux Mint offers the standard Ubuntu-style bootscreen, followed by an etremely long boot time. There was no way to get detailed boot messages or status, just a splashscreen with a bouncing progress bar. Fluxbuntu at least had the usual function key for verbose boot. The only indication I had that my laptop was still working for the 5 minute bootup was the constant thrashing of the CD drive. Fail for transparency -- I need to know what's going on during the boot process so I can tweak it for my system later, if need be.

Once the graphical desktop was loaded (another 6 minutes), the CD thrashing continued. At this point I was worried about what it might be doing to my drive, but grimly pressed on. Supposedly the LiveCD was using the existing 512MB swap partition on my hard disk, but not very well, as performance was abysmal. Also, just like Fluxbuntu, the annoying fan never turned off.

Desktop load times were further increased because of a couple of panel applets. The first sucked up bandwidth and CPU usage dialing out to find software updates ("1 update available;" who cares since it's a LiveCD?!), and the other took awhile to examine my hardware and tell me "1 restricted driver available." I assume this was for the integrated nVidia graphics chip, but I didn't bother trying to install either update. The functionality is nice enough, I suppose, but really shouldn't be activated in a limited-resource environment like the LiveCD.

Mint contains a minimal Fluxbox environment, with a single desktop "Install" icon, presumably provided by iDesk. Alone among the distros I've tried so far, Linux Mint does not by default display a more practical panel like FBpanel, Perlpanel, or Pypanel. However, in the Fluxbox menu there was an entry to start FBpanel. Why couldn't that have been already running, replacing the extremely limited Fluxbox toolbar? I clicked it, and discovered why. It took 8 minutes to load. Eight minutes to launch FBpanel, fer cryin' out loud. FBpanel is known for being tiny and fast; I had no problems with it in the other distros. The Mint panel starts up on the bottom of the screen, right under the Fluxbox toolbar. Fail for positioning; they shouldn't both occupy the same space.

I poked around the Fluxbox menu to see what was available. Linux Mint offers its own toplevel menu, laid out mostly sensibly by the developers. But for some reason, the menus generated by Fluxbox are also available at the bottom, and those are confusing as heck. The one nice thing is that the application name was displayed, rather than just "Picture viewer." Fluxbox's generated menus were quite poorly designed; it would have been better if the developers had left it out, in favor of their own menu. The generated Fluxbox menu had the most application entries (though poorly laid out, in multiple submenus), the Mint-designed menu had fewer listings, though better organized, and the FBpanel menu has the fewest entries, though it's the layout most familiar to Gnome and Xfce users.

Software selection is okay; the filemanager seems to be Rox, but I couldn't get it to actually load. Several minutes of disk churning, and then things went back to normal. At least OpenOffice isn't bundled with Linux Mint; who knows what that would have done. The Xfce Terminal is included, but its performance is just as piss-poor as the rest of the apps on the CD. Took 3 minutes to launch and get to the prompt. Now, even under load, when running Terminal on my old laptop, worst startup was around 10 seconds. It's a little unusual that they picked a terminal emulator that requires several Xfce runtime dependencies, when similar apps like rxvt, aterm, and eterm are available.

Having had enough of the poorly performing LiveCD environment, I decided to give the "Install" icon on the desktop a shot. Maybe it won't behave so badly once installed, right? Double-click.

Fifteen drive-thrashing minutes later, there's still no sign of the installer. Clearly it's trying to load something, but what--oh, look, the screen went blank. It was still backlit, so I'm not sure if it was trying to load a fullscreen installer or a screensaver or what. Wait, wait, wait some more. It never came back up. I put it down as "more retardedness," and decided to hell with this. I powered off the laptop the hard way. Oh well, it's not like there was any data on the hard disk. I wanted to throw the CD-RW across the room, but I still need it for the other distros.

If I'd been manually reinstalling Gentoo, I would have been at least halfway through at this point.

The verdict for Linux Mint: fail. A solid 0 on any scale. Not recommended for any machine, really. Especially not old hardware. Linux Mint 5.0 is currently in beta status, but even if the Fluxbox edition is updated, I doubt I'll ever try it again.

Coming up: PCFluxboxOS, Damn Small Linux, Puppy Linux, DeLi Linux, and Arch Linux. Stay tuned.

Almost a year ago, I wrote a series of articles called "Distribution Checklist," parts 1, 2, and 3. The articles pose a series of questions to be answered when trying to decide "Which distribution is right for me?"

I wiped Gentoo off my old Toshiba laptop a couple of nights ago, and have been trying out binary distros with a smaller-is-better philosophy. The laptop has anemic I/O, and only 128MB RAM (nonupgradeable; the socket is fried).

I need a distro that is lightweight, mostly self-contained (if it can run from RAM, all the better), yet also has a decent package repository for the edge cases, like Toshiba hardware support utilities. I'm planning to turn the laptop into a useful secondary work environment for my wife. She'll need to run presentations from it, so there needs to be an easy way to get the VGA-out and/or TV-out working. No commandline intervention should be required to do anything.

So far I've been through Fluxbuntu, TinyMe, and SliTaz. Of the three, SliTaz shows the most promise.

First up is Fluxbuntu. Fluxbuntu is quite dated; latest available is a release candidate for 7.10, from October 2007. For an Ubuntu-based distro, it didn't have hardly any configuration tools. Also, booting takes forever, as others have noted. Well over 3 minutes.

While trying to install useful apps, I got my first hands-on experience with Synaptic, and, well, I definitely didn't think much of it. The button labels are not at all intuitive, nor is it especially obvious how to go about actually installing a package or series of packages. A button marked "Install" would have been appreciated ("Apply" means what to the new user?). And a more up-front list of packages to be installed would have been helpful. Perhaps it was just Fluxbuntu's particular config?

In addition to the package manager interface, the rest of Fluxbuntu wasn't exactly userfriendly, and I'm used to Fluxbox. The odd setup & configuration and poor preinstalled packages were enough for me to wipe the Fluxbox install. No PDF or image viewers. Ugly gtk1 audio player (XMMS). Oh, and seriously, preinstalled OpenOffice? With Rox? OpenOffice for a "featherweight" distro. Right. Ugh, Rox. I prefer something intuitive and attractive, such as Thunar, PCmanFM, or Nao.

Another annoyance was that even after installation (terrible; it seems to reuse the very first Ubuntu Warty installer), hardware support for my Toshiba was nonexistent. Even after installing apps that are known to work on Gentoo, such as tosh-utils, fnfxd, and the like, they just wouldn't work in Fluxbuntu. Something was interfering with the fan utilities; the noisy fan ran constantly. Also, the CPU never seemed to idle; it was constantly at full speed. Excessive heat and noise. Felt like the distro was fighting the very tools I installed to take care of it.

Fluxbuntu was toast after just one day. On to TinyMe.

This one is based on PCLinuxOS. Its main attraction was its lightweight claim to fame. It comes with a decent assortment of packages, for a 300MB or so download. However, even though it's running Openbox, it feels rather bloated. Both the TinyMe Control Center and the PCLinuxOS Control Center are slow to run. They're good ideas; they offer the configuration options Fluxbuntu lacked, but they subscribe to the KDE philosophy of control: multiple similarly-named (also badly-named) apps that do more or less the same things. Lots of redundancy, so wading through them all was a bit of a chore. Also, networking steadfastly refused to work, despite throwing all my Gentoo-learned command-line tricks at it when the graphical utilities failed. Ironically, I got further in wireless config than I did with the basic Intel PRO/100 wired adapter. It picked up my Atheros PCMCIA card as soon as I ran the configurator; a few clicks and it prompted for the WPA key of my home LAN. That was the only bright spot in the whole thing. CPU usage was uncomfortably high, while RAM usage was decent, staying between 37 and 56 percent with Opera and a couple of other windows open. Something was making my CPU work too hard to do anything useful though, so TinyMe came off. It just feels like a waste of a (potentially) good environment.

Next up: SliTaz. This one has been making waves at the review sites and distro centers because it's reputed to have the world's smallest desktop environment, weighing in at only 24MB. That's a tiny download, though if fully loaded into RAM it'll occupy about 80MB. That's pretty good for everything running at once.

I first tried SliTaz Cooker, as even though it's "unstable", it's more recent than the 1.0 release. It had more interesting features, such as using Openbox by default instead of JWM, and it has a graphical package manager. Also, more of it is in English. However, the Cooker LiveCD kept freezing up at "Preparing initramfs", so I switched to the 1.0 stable release.

This was the best-running LiveCD I've ever used. Fastest, too. I was surprised at how well-configured the environment was, and it had a nice selection of apps. There's some stuff we don't even have in Portage! LXDE, burning apps, etc. I was able to use my wired NIC out-of-the-box, which meant I could get live updates to the CD via Tazpkg, the rather nifty package manager. SliTaz includes a great tool to roll your own LiveCD variant: either what's currently installed, pre-configured alternative images available from the central server, or you can specify your own config files separately.

Alone among the three distros I tried, SliTaz seemed to properly work with ACPI, spinning down the laptop's fan when temperatures were low. I didn't even have to tell it to load the few laptop-related kernel modules at the commandline, either. It has pretty basic hardware support, but SliTaz lucked out and actually got my Toshiba right, something the fatter LiveCDs couldn't do.

It seems like every small and light distro these days is using slightly customized LXPanel, and SliTaz is no exception. Probably just as well; FBpanel and perlpanel are dead. Still, LXPanel provides a fairly configurable, useful panel. I prefer it to the standard toolbar in Flux and Openbox. It's basically a reverse Xfce setup. I like to run just one panel though, because of extremely limited screen real estate. Too bad you can't right-click on the bottom panel to configure or delete it. Couldn't find a way to put the launchers and the window list all on just one panel. But it's still relatively early in development; maybe with increased usage we'll see more features added.

The rest of the desktop is nice enough, though all the red wallpaper is a little wearing on the eyes. Also, I couldn't find a GUI configurator for font hinting. In the past, Gnome and Xfce have provided everything I need to get my fonts just right. I can't be arsed to hand-edit config files for this, Gentoo developer or not.

The app selection is great overall, but Firefox is an (un)fortunate choice, because while it's familiar (I use it on my other machines), Kazehakase or webkit-based browsers would have been somewhat faster options.

My only real problem with SliTaz is that it doesn't install. It freezes about halfway through the "copying packages" stage. Hard lockup. Have to reboot. Also, the 1.0 stable installer is written entirely in French. It's mostly noninteractive, but I suppose I could have mistranslated something and done something I shouldn't have.

Still, I'll be watching future SliTaz releases closely. It's got a lot of potential, and is the most attractive of the distros I've tried so far.

Next up for review are PCFluxboxOS (similar to TinyMe), Damn Small Linux, Puppy Linux, DeLi Linux, Linux Mint (Fluxbox community edition), and the latest Arch Linux beta CD. Though this last one is the most like Gentoo -- it's only as lightweight or fast as I'm capable of making it. I've had issues with Arch in the past, mostly related to retarded source and kernel package management, but since I don't intend to do any compiling (finally) on this laptop, maybe that won't be an issue.

I get the feeling that I may well not find a distro that suits my needs, so I may just setup a chroot on my AMD64 workstation and compile packages on it, then rsync it over the network. beandog gave me a good basic procedure list, though this would easily be the most time consuming of the available options. Still, it would be a very familiar environment to work in. Though I'd have to figure out, on my own, all the neat integration and graphical/one-shot configuration mechanisms binary distros already have.

Tune in next time for more mini distro reviews.

Oh, and Gentoo users, take a look at GPytage. This is a neat little app written by our very own ken69267. It's a very nice Portage config file manager available in Sunrise. Its sole dependency is pygtk. It's a one-stop shop for easy, fast management of your /etc/portage/* config files. Take a look at this screenshot, then go get the ebuild and install it.

What have I been doing lately?

Patching Drivel, that's what!

I like using Drivel. I never lose a blog entry with this thing, which is more than can be said when Planet Gentoo suddenly crashes when I'm submitting an entry. (Side note: are there any good graphical clients that work with b2evolution? I've yet to find anything in Portage.)

Even though Drivel upstream seems mostly dead, there are still patches to fix problems or add features floating around Bugzilla, so I've been grabbing them and testing, and if they check out, adding them to the ebuild I use in my local overlay.

So far, I've added patches & fixes to my ebuild that fix a memory leak, fix compiling with gtksourceview-2 (Thanks ecatmur! one fewer app that needs 1.x), update the Blogger login URL, and add tag support for LiveJournal. Upstream left a weird version in ltmain.sh; it was giving libtool version mismatch fits. Some judicious sed usage killed it. With extreme prejudice.

Anyway, Drivel's now much more usable. I haven't been through all the open bugs yet, but there's probably another patch or two that can be made presentable. One thing I discovered is that Drivel is using a few deprecated libraries and functions. It's got several deprecated uses of libegg (which has been replaced by equivalent functionality in gtk+), and it still relies on GnomeVFS.

Fortunately, the open bug for libegg has some info on porting to the appropriate gtk+ code, and there's also the guide to Migrating from GnomeVFS to GIO. I'm actually going to give it a shot. It's well documented, and it looks like it's nothing more than an long, intensive search-and-replace session. Right? Right? Guys? Guys?

Even if I fail utterly, well, it'll be fun to try it. Will follow up on this later.

In the meantime, you can get the updated Drivel ebuild and patches here. Just untar it in your ${PORTDIR_OVERLAY}/net-misc/ directory.

* * *

In other news, my new keyboard arrived in the mail a couple of days ago. It's much cleaner, slightly less resonant, and more interesting than the old keyboard. The Delete key got moved up near Backspace (what's the use in that?!?), so some judicious Xmodmap usage shoved the Insert key left, replacing Control_R, and I changed Ins to Del. I need my Del key right next to the arrowpad when working on documents.

The keyboard isn't as quiet as I'd hoped, but it's less squeaky than the old one, and it masses more, so it sponges up some of the resonance when hammering keys. Also, it's got 17 hotkeys, and every single one of them are correctly detected in Linux, no drivers needed (take that, included Windows XP driver CD!). More productivity, whoo!

Gnome's keyboard utility picked up the hotkeys and allowed me to assign them to various standard media key behaviors, but I chose to forgo that and use Xmodmap, since it works for both Gnome and Xfce. Xfce initially couldn't see the hotkeys, but it recognized them after I setup my /etc/X11/Xmodmap. Interestingly, Xfce correctly executes Xmodmap at login with no further setup needed, but Gnome doesn't. I had to go into the Sessions dialog and create an "Xmodmap" startup program entry.

This is weird, because GDM is supposed to execute any Xmodmaps found, whether in the user's home or systemwide in /etc/, and if it finds both, it's supposed to combine 'em. Poke around in /etc/X11, and you'll see that multiple files try to execute Xmodmap. However, GDM and Gnome have utterly failed here. They're weird like that sometimes. Fortunately, Xfce saves the day yet again.