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.

Six months ago I posted some benchmarks of popular gtk+ engines. It's time to revisit those benchmarks and test the engines again, this time using FOSS drivers for my new hardware.

Today I installed my brand-spankin' new graphics card, an ATI RadeonHD 4550, by Sapphire. Getting working 2D acceleration with EXA was a cinch, now that the 2.6.30 kernel is out. Doesn't require anything special in terms of packages; nothing from overlays or bleeding-edge git checkouts. Only needs three ~arch packages: gentoo-sources, libdrm, and mesa.

For this updated round of testing, I used the same gtk+ engines, but also added some new ones. These can all be obtained by installing the following packages: gtk-engines, gnome-themes, gtk-engines-aurora, gtk-engines-candido, gtk-engines-rezlooks, and gtk-engines-xfce. New to the testing list are the Crux, ThinIce, HighContrast, and Redmond95 engines.

Once again, gtkperf-0.40 was used to obtain these benchmarks. With the exception of the graphics hardware and driver, the testing environment is mostly the same. Xfce has been updated to 4.6.1.

Let's see how all these engines perform on my Xfce workstation, eh?

Notes on the hardware:

CPU: Athlon 64 X2 4600+
Graphics: ATI RadeonHD 4550, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM

Notes on the testing environment:

OS: Gentoo Linux (duh)
Kernel: Linux 2.6.30-gentoo-r1 #1 SMP PREEMPT x86_64
xf86-video-ati: 6.12.1-r1
CFLAGS: -march=athlon64-sse3 -O2 -fomit-frame-pointer
DE: Xfce 4.6.1
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 2 instances of x11-terms/terminal

Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.

All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.

Engine: HighContrast
Theme: HighContrast

GtkEntry - time: 0.03
GtkComboBox - time: 0.63
GtkComboBoxEntry - time: 0.46
GtkSpinButton - time: 0.04
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.04
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.21
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.70

Engine: Rezlooks
Theme: Rezlooks Blue Ink*

GtkEntry - time: 0.05
GtkComboBox - time: 0.61
GtkComboBoxEntry - time: 0.41
GtkSpinButton - time: 0.05
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.94
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.11
---
Total time: 4.72

Engine: Mist
Theme: Mist

GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.45
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.04
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.07
GtkDrawingArea - Lines - time: 0.87
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72

Engine: ThinIce
Theme: ThinIce

GtkEntry - time: 0.03
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.42
GtkSpinButton - time: 0.07
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.91
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.88
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.72

Engine: Glide
Theme: Glider

GtkEntry - time: 0.06
GtkComboBox - time: 0.65
GtkComboBoxEntry - time: 0.49
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.05
GtkRadioButton - time: 0.14
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.09
GtkDrawingArea - Lines - time: 0.85
GtkDrawingArea - Circles - time: 1.20
GtkDrawingArea - Text - time: 0.87
GtkDrawingArea - Pixbufs - time: 0.14
---
Total time: 4.90

Engine: Redmond95
Theme: Redmond

GtkEntry - time: 0.04
GtkComboBox - time: 0.76
GtkComboBoxEntry - time: 0.57
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.10
GtkCheckButton - time: 0.12
GtkRadioButton - time: 0.13
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.08
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.16

Engine: Clearlooks
Theme: Glossy

GtkEntry - time: 0.02
GtkComboBox - time: 0.77
GtkComboBoxEntry - time: 0.56
GtkSpinButton - time: 0.19
GtkProgressBar - time: 0.12
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.10
GtkDrawingArea - Lines - time: 0.95
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.40

Engine: Crux
Theme: Crux

GtkEntry - time: 0.03
GtkComboBox - time: 0.89
GtkComboBoxEntry - time: 0.75
GtkSpinButton - time: 0.14
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.05
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.10
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 5.46

Engine: Industrial
Theme: Industrial

GtkEntry - time: 0.05
GtkComboBox - time: 1.13
GtkComboBoxEntry - time: 0.54
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.15
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.07
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.16
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 5.54

Engine: Aurora
Theme: Aurora

GtkEntry - time: 0.05
GtkComboBox - time: 1.10
GtkComboBoxEntry - time: 0.90
GtkSpinButton - time: 0.20
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.12
GtkCheckButton - time: 0.08
GtkRadioButton - time: 0.16
GtkTextView - Add text - time: 0.19
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.92
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.89
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 6.08

Engine: Pixmap
Theme: Elegant Autumn*

GtkEntry - time: 0.04
GtkComboBox - time: 1.00
GtkComboBoxEntry - time: 0.80
GtkSpinButton - time: 0.15
GtkProgressBar - time: 0.15
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.11
GtkTextView - Add text - time: 0.23
GtkTextView - Scroll - time: 0.23
GtkDrawingArea - Lines - time: 0.98
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.92
GtkDrawingArea - Pixbufs - time: 0.13
---
Total time: 6.19

Engine: Candido
Theme: Graphite Light

GtkEntry - time: 0.05
GtkComboBox - time: 1.94
GtkComboBoxEntry - time: 1.36
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.22
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.09
GtkTextView - Add text - time: 0.22
GtkTextView - Scroll - time: 0.16
GtkDrawingArea - Lines - time: 0.89
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.91
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 7.45

Interesting. Six months (and one new graphics card and driver) later, there's been a bit of a shuffle. All engines tested are clustered much closer together. There used to be a 12-second gap between the fastest and slowest engines. Now it's only 3 seconds. Part of that disparity comes from new versions of the engines. Aurora in particular has made phenomenal improvements since 1.4; the numbers you see here are from version 1.5.1. It's no longer at the back of the pack -- last place now belongs to Candido, which is still rather slow, especially in the ComboBox tests.

Curiously, although the completion times are stacked very closely, there seemed to be a general slowdown. While the older gtk+ engines still turn in respectable times, they're not always at the front of the pack. In particular, the Pixmap engine, which has historically had a speedy reputation, is now trailing most other engines. The theme used is extremely simple. I'm not sure what's causing the slowdown here. Perhaps its reputation for speed is no longer deserved; even six months ago it wasn't a standout.

There's no longer an engine that can turn in 3-second completion times; in fact, the four fastest engines all tied at 4.7 seconds. Of the four, Rezlooks is without a doubt the prettiest. Many of the screenshots in my devspace feature Rezlooks themes.

Two of the engines added for this round of benchmarks, Crux and Redmond95, end up in the middle of the pack. They're not particularly fast, nor are they pleasing to the eye. The other two newcomers, ThinIce and HighContrast, distinguish themselves by jumping to the very top of the charts. HighContrast is undoubtedly the ugliest engine presented here, while ThinIce's appearance rather resembles Mist. It's tolerable, but nothing I'd use, personally.

Once again, I'll stick with Rezlooks-based themes, as well as the occasional standout Pixmap or Clearlooks theme such as ClearLUX. ClearLUX in particular is extremely easy on the eyes when doing late-night computer work.

---

But where are the Xfce engine results? Let's take a look . . .

The Xfce engine results baffled me. The completion times varied wildly, everywhere from middle-of-the-road to flat-out fast to back-of-the-pack. So I intermittently benchmarked the Xfce engine for an hour, under varying degrees of desktop activity. Everything from lots of different applications open to a completely blank desktop. I couldn't generate consistent results. So, I decided to close down all applications and run a final series of three tests. Presented here are the slowest and fastest times logged for this series.

Engine: Xfce
Theme: Xfce

Slowest times
GtkEntry - time: 0.06
GtkComboBox - time: 1.18
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.08
GtkProgressBar - time: 0.07
GtkToggleButton - time: 0.08
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.20
GtkTextView - Scroll - time: 0.14
GtkDrawingArea - Lines - time: 0.90
GtkDrawingArea - Circles - time: 1.17
GtkDrawingArea - Text - time: 0.94
GtkDrawingArea - Pixbufs - time: 0.15
---
Total time: 5.56

Fastest times
GtkEntry - time: 0.02
GtkComboBox - time: 0.55
GtkComboBoxEntry - time: 0.43
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.06
GtkToggleButton - time: 0.06
GtkCheckButton - time: 0.03
GtkRadioButton - time: 0.04
GtkTextView - Add text - time: 0.18
GtkTextView - Scroll - time: 0.12
GtkDrawingArea - Lines - time: 0.86
GtkDrawingArea - Circles - time: 1.19
GtkDrawingArea - Text - time: 0.90
GtkDrawingArea - Pixbufs - time: 0.12
---
Total time: 4.63

Look at that. A completion time of 4.63 seconds, well ahead of any other engine. That's best-case though; it can be almost as slow as the Aurora engine, which is notoriously heavy. The DrawingArea and TextView numbers are fairly static in both sets. Everything else tends to vary widely. No idea why. Perhaps the developers have made some changes under the hood between Xfce 4.4 and 4.6?

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.

Note: this post was originally written a few weeks ago, shortly after the Siag Office experiment. Since the draft was written, an Abiword bug has been opened with a different ebuild. Guess I was too slow about finishing up my draft and publishing it. Ah, well. Now you can at least track the progress of the latest Abiword.

After the lengthy but fun entry on working with Siag Office, I've got s'more goodies. It's time to remove more Gnome packages, as I want to have as close to a pure Xfce desktop as possible. Abiword has always been my default word processor, but it has always been burdened with Gnome libraries and other dependencies. The 2.7 development series changes that, removing the need for many Gnome packages.

After reading a comment, I decided to hack up an ebuild for Abiword 2.7.1, the latest developmental release. This is not a stable release; the changes made to the 2.7 series will eventually become the stable 2.8 series. As upstream warns, don't run developmental releases on production servers.

The first step was to copy the latest ebuild, 2.6.8, to my local overlay in /usr/local/portage and renaming it to 2.7.1. The next step was to determine what's changed since 2.6.8.

I took a look through Abiword's ViewVC to see for myself whether or not the pesky Gnome dependencies have been removed or made optional. Seems they have.

I also discovered that there are several totally unnecessary dependencies present in our current ebuilds. Moreover, several configure switches have been renamed from --enable to --with. This means changing the $(use_enable) bits to $(use_with). Also, some switch options have been renamed or removed; there's no more gnomeui or symbol switches, and the printing switch was renamed to print. These were all simple, quick changes to make in the 2.7.1 ebuild. Removing a line here, deleting 3 letters there. Basic stuff.

Another change was getting rid of the xml and expat configure switches, since they're no longer used. While Abiword does use expat, it's already pulled in by libgsf, so we're safe there. Even the internal Abiword documentation notes this in the various configure files, which is why they don't have explicit configure switches any longer.

The longer changes involved studying configure.in to see what it says are the new optional dependencies and adding those as new USE flags within the ebuild. goffice is now optional, and requires an updated version (0.6). So I added an "office" flag to IUSE at the top of the ebuild, and a line to the pkg_setup function:

$(use_with office goffice)

This USE flag can always be renamed later. The important thing is getting the initial functionality in place. It's very easy to add new flags into the Abiword ebuild; it really just requires copying and adjusting the existing USE info.

Once the critical dependencies and versions were sorted out, it was time to update the internals of the ebuild itself.

One of the things that tends to happen when you have a package in the tree for a long time is that cruft from old ebuild versions tends to linger around for a few years. In this case, the ebuild has a few EAPI-1 tidbits like SLOT dependencies, but it also has a lot of leftover baggage from the pre-EAPI days. Part of that includes redundant numbering. There were a lot of specific minimum versions that are completely unnecessary, as the minimum version hasn't existed for a long, long time. So I went through the ebuild and stripped out all the unnecessary versions, leaving just the category/packagename.

Only one package now needs a specific minimum version, gtk+-2.14. Once gtk+-2.12 is removed, then the dependency can be simplified to a SLOT dependency on gtk+:2, to avoid pulling in gtk+-1.x. I did the same SLOT update for the new required version of goffice and for glib-2. All part of the process of updating to the good stuff present in the EAPIs.

With the EAPI-2 update, it's possible to include USE dependencies in ebuilds. This means that you can get rid of hacks like built_with_use, which require a dependency of Abiword (such as Pango) to have been built with the X flag. The whole function to abort the merge if Pango was not built with USE="X" took 4 lines:

if ! built_with_use --missing true x11-libs/pango X; then
eerror "You must rebuild x11-libs/pango with USE='X'"
die "You must rebuild x11-libs/pango with USE='X'"
fi

With EAPI-2, I was able to update the ebuild to this RDEPEND:

x11-libs/pango[X]

Pretty slick, huh?

The next step was to try a test-compile. Run emerge abiword and watch the results.

Hmm, the merge aborts right at the very end. Turns out that the sed scripts carried over from the 2.6.8 ebuild aren't working: they die because the files they worked with no longer exist. Time to figure out where that .desktop file and other stuff have gone.

The first sed script is looking to change some install directories in a nonexistent Makefile. A quick grep through the Makefiles shows that the old change is no longer necessary; nothing has the old incorrect path. This sed script can be commented out.

The second sed script wants to alter the lines in the .desktop file Abiword installs. However, Portage can't find the file to sed, so it aborts the merge. Turns out that Abiword wants to install the file to /usr/share/abiword-2.7/applications/abiword.desktop. That is a nonstandard location, so no wonder Portage can't find it. If it installs here, Abiword won't show up in your desktop menu. The trick is to get Abiword to install its .desktop file to the right location.

Let's review what's happened so far:

1. Create a copy of the latest ebuild to work on.
2. Visit the upstream homepage and changelogs.
3. View the various configure files to determine new dependencies, versions, unnecessary dependencies, optional dependencies, renamed arguments, and the like.
4. Go to work on the ebuild!
a) Hammer out the raw dependency changes.
b) Fix up the USE flags and related functions.
c) Fix up version and SLOT stuff.
5. Give it a test run.
a) Since a couple of minor errors were found, revisit the ebuild. Fix sed scripts.
b) Test it again.

Now Abiword is compiling, installing, and running. The next step is to tidy up the ebuild. This means putting the dependencies and USE flags back into alphabetical order, removing extraneous whitespace, fixing typos present in the original 2.6.8 ebuild, and deleting any unnecessary comments. There's also the small matter of getting the .desktop file to install to the right location . . . call it homework.

The final step (for me) is to upload the ebuild where you can view it. This ebuild is a working template for the 2.8 releases. I plan to keep tracking it, keeping up with the changes. No more forced Gnome dependencies! Yay!

Of course, I was only able to remove two packages: goffice and libgnomeprintui. Something is still pulling in libgnomecups, libgnomeprint, gnome-keyring, gnome-vfs, and several others. The next thing I'll investigate is all the gtk+ Bluetooth apps lying around. I won't rest in my quest to have a totally lightweight, Gnome-free, Xfce laptop.

* * *

This is a follow-up to my Siag Office experiment:

I've discovered that some of Siag's peripheral programs run in spite of the font errors. xedplus, tsiag, gvu, and xfiler all run. They still display the same font errors in the console output, but at least the application itself works. Though I'm not sure that xfiler is working correctly. It pops up a file browser window, but I can't click on an item to open it. I can select it with the mouse, but to open it I have to hit Enter. Annoying. But at least it does go to that folder, or open the document/picture in the appropriate Siag utility.

I still can't get the word processor or spreadsheet working, and those form the core of Siag Office. Any tips?

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.

Here are some fast and dirty benchmarks of various gtk+ engines installed on my system, using app-benchmarks/gtkperf-0.40.

Notes on the hardware:

CPU: Athlon 64 X2 4600+
Graphics: nVidia 7600GT, DVI 1440x900 @ 60Hz
RAM: 4GB DDR2-667
Mobo: ASUS M3N78-VM

Notes on the testing environment:

OS: Gentoo Linux (duh)
Kernel: Linux 2.6.27-gentoo-r2 #3 SMP PREEMPT x86_64
nvidia-drivers: 177.82
CFLAGS: -march=athlon64 -O2 -msse3 -fomit-frame-pointer
DE: Xfce 4.4.3
- Xfwm4 with Composite enabled, effects: drop shadows & transparency
- Open applications: 1 instance each of www-client/mozilla-firefox, app-editors/gvim, xfce-extra/terminal
- Cairo: 1.6.4, compiled with glitz support. Not all engines use Cairo, but those that do should benefit from a small speed increase.

The gtk+ engines are all available in Portage. If you're not on Gentoo, look in your distribution's repositories or check here. Custom themes are noted with *. These are personal themes I've made, nothing more than simple color modifications of an existing freely available theme. No additional images are used, so rendering time should not be affected.

All tests were conducted 3 times, using a Test Round setting of 100. I picked the best score of the 3, as I was looking for best-case usage conditions. The results are ranked in order from fastest to slowest.

Engine: Mist
Theme: Mist

GtkEntry - time: 0.01
GtkComboBox - time: 0.53
GtkComboBoxEntry - time: 0.47
GtkSpinButton - time: 0.09
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.13
GtkCheckButton - time: 0.06
GtkRadioButton - time: 0.24
GtkTextView - Add text - time: 0.28
GtkTextView - Scroll - time: 0.13
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.07

Engine: Xfce
Theme: Xfce

GtkEntry - time: 0.03
GtkComboBox - time: 1.12
GtkComboBoxEntry - time: 0.50
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.04
GtkToggleButton - time: 0.14
GtkCheckButton - time: 0.07
GtkRadioButton - time: 0.06
GtkTextView - Add text - time: 0.27
GtkTextView - Scroll - time: 0.17
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.16
---
Total time: 3.56

Engine: Rezlooks
Theme: Blue Ink*

GtkEntry - time: 0.07
GtkComboBox - time: 0.95
GtkComboBoxEntry - time: 0.65
GtkSpinButton - time: 0.06
GtkProgressBar - time: 0.03
GtkToggleButton - time: 0.28
GtkCheckButton - time: 0.28
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.34
GtkTextView - Scroll - time: 0.15
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 4.31

Engine: Industrial
Theme: Industrial

GtkEntry - time: 0.08
GtkComboBox - time: 1.52
GtkComboBoxEntry - time: 1.04
GtkSpinButton - time: 0.12
GtkProgressBar - time: 0.05
GtkToggleButton - time: 0.59
GtkCheckButton - time: 0.35
GtkRadioButton - time: 0.39
GtkTextView - Add text - time: 0.39
GtkTextView - Scroll - time: 0.21
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 5.86

Engine: Glider
Theme: Glider

GtkEntry - time: 0.04
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.62
GtkSpinButton - time: 0.42
GtkProgressBar - time: 0.02
GtkToggleButton - time: 0.25
GtkCheckButton - time: 0.19
GtkRadioButton - time: 0.32
GtkTextView - Add text - time: 0.37
GtkTextView - Scroll - time: 0.29
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 6.59

Engine: Pixmap
Theme: Elegant Autumn*

GtkEntry - time: 0.09
GtkComboBox - time: 1.64
GtkComboBoxEntry - time: 1.34
GtkSpinButton - time: 0.24
GtkProgressBar - time: 0.17
GtkToggleButton - time: 0.52
GtkCheckButton - time: 0.48
GtkRadioButton - time: 0.89
GtkTextView - Add text - time: 0.69
GtkTextView - Scroll - time: 0.22
GtkDrawingArea - Lines - time: 0.26
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.28
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 7.37

Engine: Clearlooks
Theme: Glossy

GtkEntry - time: 0.08
GtkComboBox - time: 1.93
GtkComboBoxEntry - time: 1.45
GtkSpinButton - time: 0.40
GtkProgressBar - time: 0.29
GtkToggleButton - time: 0.61
GtkCheckButton - time: 0.50
GtkRadioButton - time: 0.59
GtkTextView - Add text - time: 0.41
GtkTextView - Scroll - time: 0.32
GtkDrawingArea - Lines - time: 0.27
GtkDrawingArea - Circles - time: 0.35
GtkDrawingArea - Text - time: 0.31
GtkDrawingArea - Pixbufs - time: 0.18
---
Total time: 7.68

Engine: Candido
Theme: Graphite Light

GtkEntry - time: 0.08
GtkComboBox - time: 2.10
GtkComboBoxEntry - time: 1.86
GtkSpinButton - time: 0.17
GtkProgressBar - time: 0.26
GtkToggleButton - time: 0.63
GtkCheckButton - time: 0.53
GtkRadioButton - time: 0.60
GtkTextView - Add text - time: 0.48
GtkTextView - Scroll - time: 0.25
GtkDrawingArea - Lines - time: 0.28
GtkDrawingArea - Circles - time: 0.36
GtkDrawingArea - Text - time: 0.29
GtkDrawingArea - Pixbufs - time: 0.17
---
Total time: 8.05

Engine: Aurora
Theme: Aurora

GtkEntry - time: 0.47
GtkComboBox - time: 3.78
GtkComboBoxEntry - time: 3.50
GtkSpinButton - time: 0.96
GtkProgressBar - time: 0.31
GtkToggleButton - time: 1.53
GtkCheckButton - time: 1.29
GtkRadioButton - time: 1.66
GtkTextView - Add text - time: 0.58
GtkTextView - Scroll - time: 0.46
GtkDrawingArea - Lines - time: 0.31
GtkDrawingArea - Circles - time: 0.38
GtkDrawingArea - Text - time: 0.32
GtkDrawingArea - Pixbufs - time: 0.19
---
Total time: 15.73

As you can see, the older engines are generally the fastest, with the more modern Rezlooks engine coming in close behind. Though they're generally not as attractive, the old Mist and Xfce engines turn in very respectable rendering times. The Pixmap engine actually doesn't score too well, coming in at the lower middle of the pack. This is despite many reports I found via Google that suggest it's one of the best-performing engines out there. Not so much; it's about average.

But by far the worst performing engine is Aurora. Now, to be fair, Aurora does many graphical tricks the other engines do not. It came along some time after old engines like Pixmap, Industrial, Mist, and Glider. It features animated scrollbars, gauges, and many possible styles of dropdowns and arrows. In short, it's fully loaded. Yet it also doesn't seem to be optimized; at 15.73 seconds, it's almost twice as slow as the nearest contender, Candido.

The results for the Aurora engine were so dismal that I re-ran gtkperf another 3 rounds, thinking something was amiss. Every result turned in times between 15 and 16 seconds. Clearly, Aurora isn't the engine to use if you're on old hardware.

Conclusion:

Remember, these are down and dirty benchmarks. Cherry-picking the best time out of 3 runs may not be the most fair way of measurement, but since no single result varied more than 2 seconds either way, it can be considered pretty well representative of the engine's overall capabilities.

If you're on less capable hardware, the Mist and Xfce engines will go far. If you want something prettier, stick with Rezlooks. I have several screenshots of Rezlooks-based environments in my devspace. It's quite flexible, and it's still in the top three fastest engines, despite including goodies like subtly animated progress bars and gauges.

But even on my fairly powerful workstation, newer engines like Candido and Aurora were noticeably slower, suggesting they might not be a good fit for older hardware. Clearlooks and Pixmap are middle-of-the-road choices; neither has much of an advantage. It comes down to which engine you think has prettier themes.

Me? I stick with Rezlooks. And occasionally Clearlooks (the Glossy theme makes for a good wintry desktop foundation), and very occasionally I'll find a decent Pixmap theme that's worth modding for my system. Otherwise, it's Rezlooks all the way.

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.

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.

Alternative distros

In the last few weeks I've tried Arch Linux, Zenwalk, and Myah OS.

Arch is mostly the same ol' Arch it always is -- I used to dual-boot it with Gentoo on my old laptop, but I won't be moving to it at any point. It used to be hell on wheels for installed boot times, but now it's slower than many liveCDs. And like Gentoo, it takes a lot of initial configuration. Too much, I discovered. I don't really mind setting up things by hand, but the tools to do so need to be easy to use. Whether this means graphical applications or command-line tools (such as rc-update, which is one of the best selling points of Gentoo), they need to make system configuration quick and straightforward. Arch doesn't have much in this regard. Also, several packages that I consider essential to the light desktop I'll be building are only available as source packages. Binaries only, please. If I'm going to be spending at least as much time configuring and installing stuff on Arch as Gentoo, I may as well just install Gentoo.

Zenwalk's 5.2 release shows much more promise than the last version I tried. Except for the small problem where wireless networking won't work, that is. And I ended up not being able to finish installation or get a bootable desktop. The installation process heated up the CD drive to the point where the media started to become unreadable; packages on the CD would fail their checksums. When the machine was cool, there were no such issues. My laptop almost overheated to the point of shutdown. Once I finally got it to install several tries later, it couldn't boot -- the Lilo screen came up (ugh, Lilo) and tried to boot into Zenwalk, but then the computer reset itself. Repeat ad infinitum. Scratch Zenwalk.

Myah OS is a fairly promising new distribution that offers a "Box" edition built on LXDE, which looked to be perfect for my needs. Unfortunately, it comes with compiz by default and no real support for my GeForce 2 Go graphics chip; Myah includes only the unaccelerated "nv" driver, which is a real POS. So it sticks a heavyweight window manager into an otherwise decent desktop environment. Way to go. Fortunately, openbox is an option, and a few other window managers and desktop environments are available once you have an installed system.

Package selection in the installed environment was quite decent; lots of good, fast apps. LXDE (as configured by Myah) isn't the speediest desktop I've ever used, but it was acceptable. Unfortunately, wireless networking simply will not work. I couldn't figure out if this was because of the stone-age initsystem (and an equally antiquated config layout), or if it was the fault of ath5k. I've never used a kernel with ath5k before now; Myah ships with 2.6.25.2. Up till now I've just used madwifi, which works well. Whatever the cause, I could never get my card to initialize, much less see networks.

Package management is also a cast-iron bitch; the thing uses a weird mix of xterm output and a gtk frontend. The frontend fires up an xterm window with output in the background, but they're both slow as molasses. The frontend is extremely difficult to navigate; you first have to choose whether you want to add, remove, or update packages, then proceed through category menus and select individual packages. Stepping forward or backward through each window is a laborious process, forcing multiminute waits as the installer does whatever the hell it's doing. It's like it's fetching package information via the internet at each screen, and then executing a hell of a lot of code at each stage. Really, I've no idea what was going on under the hood. I just knew that it was a profoundly dissatisfying experience. Scratch Myah -- but I'll look in on this project in the future. It could be going places.

What's next? Well, I downloaded Xubuntu 8.04, so now I'll try a distro that's known for having "easy" configuration and management. Sure, I'll be getting an Xfce desktop (which is in itself too much for my laptop) further bloated with lots of Gnome cruft, but I figure I can use it as a decent base for getting a better environment. It's a lot better than starting with Ubuntu's Gnome desktop. There seem to be packages for everything I need so far.

Alternative desktops

I've also recently switched my workstation's desktop from Gnome and Firefox 2 to gnome-light and Firefox 3. The latter necessitated moving to the former, as right now, too many packages force dependencies on Firefox 2 and/or xulrunner-1.8. Plus, now that I'm on gnome-light, I've discovered the joys of unmerging Epiphany, Evolution, sound-juicer, and sundry other miscellaneous bloat. I've also given up on trying to use Midori and webkitgtk. While I appreciate that both are now in Portage, Midori is just too broken to consider using as a worthwhile browser, even though its rendering speed (thanks to webkitgtk) is second to none.

Besides, the primary advantage of Midori was its integration with my desktop environment. Now that Firefox 3 is installed, it blends in as a proper gtk app. And it's faster than 2.x; Gmail and other AJAX sites load much faster. I must say that I'm impressed with its overall speed despite my initial pessimism over the inclusion of a fricking database (sqlite). I still regard it as so much unnecessary bloat, since I have absolutely no use for all the new bookmarks features, but maybe someone out there will get some good from it.

Gentoo

In other news, we're looking to release 2008.0 final soon, after dealing with lots of security updates and miscellaneous fixes for the snapshot. What's this mean? To new users, it means a newer set of packages will be installed than what's on the beta2 CDs. To current users, it means nothing at all. Gentoo isn't like other distros that force you to reinstall or upgrade your entire system at release time. Releases are made solely to update the installation media -- CDs, stages, etc. -- to bring them up to date.

I've sent in the final documentation tarballs to the rest of the releng team and updated the tentative release schedule with the info provided by Chris, so now I can focus on finishing up the next issue of the GMN. There's one article in particular that I'm excited about, so stay tuned . . . it's coming soon!

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.

SCALE

It's been a coupla weeks now since SCALE 6x, so it's about time for an after-action report.

My wife and I arrived Friday night after suffering a two-hour delay because of heavy traffic. The 405 was the worst. LA traffic always gives me nightmares.

Saturday morning came far too early, but at least we were already registered. We got there the same time as omp, who'd brought a Windows-using friend along as a booth slave--er, volunteer.

Our booth setup included a giant Gentoo poster, omp's desktop rig, and one (occasionally both) of my laptops, displaying Xfce. It was more popular than the extremely minimal openbox desktop, so HAH! We gave out lots of bribes--snacks--and even more LiveCDs. It's too bad we didn't have flyers, business cards, shirts, or other Gentoo swag this year. Lots of folks were asking for them. At least we gave out snacks'n'luv.

Wireless internet sucked throughout the weekend. Apparently it was the same for everyone. Spotty, minuscule bandwidth, and nameservers couldn't be reached. Made it hard to demo things that needed internet access, such as emerging packages, looking up our homepage, or highlighting documentation.

One of our users, calculus, was around much of the time to help out; was nice to see him at SCALE again this year. And wormo made an incognito appearance, too. To all the users and everyone else who stopped by and asked questions, gave feedback, or just chatted -- thank you. You're terrific. I'm always excited to meet a Gentoo user in person. It's like "Really? you use Gentoo? No way!" We were possibly the least-known distro there (tied with Foresight and Damn Small Linux?), certainly the least commercial one. The other distros were all heavyweights: Ubuntu, Red Hat, Suse, Fedora, etc.

Still, we had lots of traffic. Several people wanted to know what's up with Gentoo in regards to our recent legal status issues, so I provided the news in-person, and that seemed to go over well. Curiously, none of the enterprise-level folks were much interested in our legal status. They pretty much all said the same thing: "We're not worried. All the technical development is still there; nothing's changing." It was only the individual users who had all kinds of worries and needed the explanation. The corporate sector wasn't worried at all: "As long as it's still being developed."

There are plenty of pictures of our booth around the 'net in reviews and photo sites; you just have to look for 'em.

I had a blast at SCALE. I plan to attend next year, too.

ebuilds

Lately I've been poking random ebuilds from the tree, posting updates to Bugzilla, creating new local ebuilds, asking for keywords/stabling, and so on. It's a lot of fun. A fair amount of edgy experimentation, but that's what my new laptop is for. Things like wicd that I'd like to see in the tree, or the latest version of brasero.

burning apps

Speaking of burning software . . . brasero seems to be the only actively developed gtk+-based application. Everything else hasn't had a release in years. Xfburn, gnomebaker, graveman, xcdroast....you name it. That's not good news. Brasero is a good choice for my Gnome desktop workstation, but I wouldn't even think of putting Gnome on my laptop, which is a pure Xfce machine. And yet I hate the idea of putting K3B on my laptop even more, because of the ugly, ugly Qt and kdelibs dependencies.

I went ahead and installed brasero on my laptop anyway, since it's gtk+, and it can work with DVDs. None of the other apps I mentioned support 'em. That added 33 huge Gnome deps, including (ugh) nautilus. The irony? K3B only wanted 18 total packages. Still, it's uglier. That's what counts, right?

So thinking about this sad state of affairs for gtk+-based burning apps got me thinking . . . what would it take to create a new one? Something fast, with minimal dependencies, and gtk-based.

gtk

I've skimmed the gtk tutorial and the reference manual before, but only as a passing curiosity. Today I really took a shot at figuring 'em out. This is where I ran into the cliff known as "C programming."

I'm not a programmer. I can do markup languages, I can do some bash, some javascript, little things like that. But I've never been trained in OOP. Or any kind of programming, except some BASIC in elementary school and college. My degree is in theatre, not computer science!

Still, I'm determined to make what headway I can with these gtk+ guides. I've started to see what does what, and why. And some of the necessary parts of an app. Now I need to find out how to get that button press to do something, like . . . burn a CD. Copy a disc. Save an iso. And so on. For that, I've been poking at the source code for Xfburn, libburn, and brasero. This is all still just a bit over my head, but I'm trying, at least.

I've already partly answered my own question of "Why aren't there more up-to-date gtk+ burning apps available?" because I created a sample task list.

Writing a graphical app is a huge undertaking. What burning backend will be used? cdrtools, cdrkit, libburn/libisofs, dvd+rwtools are all possibilities. Same goes for the media types used in writing audio discs. The app has to handle notification (possibly via dbus), disc drive status/detection, set/get write speed, and a dozen other critical tasks. Oh, and it needs to be translatable (those pesky .po files that take up space), and it really should make use of autotools. What other libraries will it use? Will any of its features be optional compile-time switches? Got to add those too. Where will the project be hosted? What VCS? And so on.

Lots of stuff to do. No wonder brasero's the only active gtk+ burning app. And that's too bad, too. It has a ton of dependencies that folks using Xfce or just a WM don't care to install. I'd like to see the huge gap between "brasero" and "nothing" filled by a low-dependency, fast, capable application. I just don't think I'm up to the task of creating it all by myself.

Off to SCALE. Gentoo, represent!

See you there.

I finally picked out an acceptable laptop and managed to win it on eBay, after trying unsuccessfully for several days, losing out at the last hour. I also spent many hours hunting through online shops; I almost went through Lenovo.com's store, but customers are reporting terrible experiences with 'em, so I went with eBay instead. No word on shipping; I assume it'll go out via priority USPS tomorrow.

I snapped up a new Thinkpad R61i for just over $600, counting shipping. That's $200 more than I originally planned to pay, back when I was still looking for the ultimate low-end laptop, like a $399 Acer Aspire or Everex StepNote.

On paper, the Thinkpad should be fully supported in Linux, though I won't know about the integrated fingerprint reader until it arrives. Lenovo recently decided to use a slightly different UPEK product that seems to be missing crypto logic, so there's no support for those kinds of readers whatsoever. They won't work with binary drivers (like bioapi), nor with thinkfinger or fprint. I'm keeping my fingers crossed! (Pun intended.)

The specs:
CPU: C2D T5250 1.5ghz (Yes, I'm aware that this may make me somewhat of a traitor to my fellow AMD enthusiasts)
GPU & screen: Intel X3100, 15.4" widescreen 1280x800
RAM: 2GB
HDD: 120GB
Networking: Intel gigabit LAN & 3945ABG wireless

For the first time ever, I'm actually up in the air about whether or not to install 32-bit or 64-bit Gentoo on the thing. I've been doing enough reading over at ThinkWiki and other places to consider a 32-bit installation. Since there's only 2GB of RAM in the machine, I don't have any particular hardware reasons to go 64-bit. And some of the audio applications I intend to run on it aren't keyworded amd64, or just plain don't work on 64-bit CPUs. It's been giving me and my desktop headaches.

I think one of the first upgrades I'll be making will be to order an Ultrabay battery, as well as check the included battery. I need something with long life at a reasonable cost. I'll probably have to shop at Lenovo's store to get the battery, so I guess "reasonable cost" is right out. Which means that, according to resellerratings.com, if it ever arrives, it'll be in a few months. Joy.

But hey, that can't diminish my enthusiasm for actually snagging a (great?) laptop at a great price. Happy belated Christmas to me!

Once the laptop arrives, I'll see about getting a USB-to-MIDI cable so I can put the thing to use as a digital audio workstation. So much fun ahead!

I definitely want a ThinkPad. Since my previous entry, I've done some serious scouting around for one. I want one. I do.

I'm really attracted to the R61 series (R61, R61i, R61e), but I've just uncovered some scary problems with the recent models:

1. Wireless issues: seems iwlwifi doesn't work for some users, and/or they use ndiswrapper.
2. Fingerprint issues: the R61 series will likely come with a fingerprint scanner that is completely inoperable in Linux. There's an open bug for supporting it in fprint (dsd's awesome project; go check it out), but I'm not hopeful. The manufacturer is entirely uncooperative. Why, oh why did Lenovo switch to them?!?
3. Touchpad issues: seems that some later-model 61s are shipping with an ALPS pad, rather than the tried-and-true Synaptics. Users are having to resort to all kinds of hackery to get the useful features out of their pad.

So, though I still want a ThinkPad, I'm now having second thoughts about an R61. I want some kind of ThinkPad, though. Basically, it needs to have all its hardware functional purely with open-source drivers, or something resembling open-source. This is going to be a Gentoo development laptop, so said drivers should be in Portage.

Requirements:

1. Physical dimensions: minimum 15.4" screen; weight no more than 6.5 pounds, ~5 pounds preferred.
2. Working wireless: open-source drivers (Intel desired; Atheros is close enough). Absolutely no ndiswrapper!
3. Intel X3100 graphics.
4. Working Synaptics trackpad. I want one that can do scrolling and all the other nifty tricks it's famed for.
5. Working ACPI. This means the buttons and Fn combinations work, as well as the fan (which had better be cool & quiet).
(Possibly optional)
6. Working fingerprint scanner. Really. One that works. Now that I know some ThinkPads have 'em, I want one. Seems like an awesome feature!

So . . . since I've only studied the R61 series, what other ThinkPads are worth investigating?

Back again. Started to really get back to work on Gentoo, with more documentation commits, bugfixes, etc.

Also started using some new gtk+ applications: beandog added my ebuild for brasero-0.7.0 to Portage, and I got drac to keyword asunder-1.0. I've been meaning to ditch k3b for awhile now, so I finally unmerged it, and started cutting down on the number of dependencies. I still need qt for Rosegarden and Hydrogen, bah! In the meantime, I now have a pair of decent disc writing & ripping tools for my CD collection. Still a couple of bugs, though -- brasero doesn't seem to like writing single-layer DVDs (though dual-layer works fine), and asunder's mp3 encoding flat-out doesn't work, at least so far on amd64. Still doing further testing on x86. Also, it's rather slower than most other tools out there. At least FLAC, wav, and Ogg work, though I already have those through sound-juicer. Now that I've got mp3 encoding working in sound-juicer, I'll use it until I can figure out asunder. I'm working actively with upstream to get this worked out; major props to Andrew for being so responsive.

On the laptop front, I've found some possibilities. The hard cost limit is still under $600, but I've found several intriguing models in the $380 to $500 range. Originally, I was set on finding a used Everex StepNote of some kind and installing the developer edition of Zonbu on it, then using that stepping stone to turn it into my usual Gentoo environment. Don't get me wrong; the price on the Zonbu notebook ain't too bad, but for almost $500, I think I could do better. There are still used/refurbished StepNotes out there for only $400. There's also an Acer model or two at that price range, but they're usually out of stock at online merchants, as well as being only 14.1".

Side note: former Gentoo developer plasmaroo (Tim Yamin) works for Zonbu, and has been doing much to get that tricky VIA hardware working & other things, so congrats to him. Perhaps he's one of the reasons why Zonbu went with Gentoo as their base OS?

I've also found a couple of interesting cheap dual-core Gateway laptops such as the ML6720, though no real information can be found on their Linux compatibility.

I've been kind of hoping that my new laptop would be dual-core, but that's just asking for reduced battery life. It'd make compiling faster, but at the cost of power, heat, and definitely price. If I stay closer to $400 I won't need to worry about future-proofing with dual-core; I'd just buy a new laptop at a similar price point sometime in the future. Single-core desktop usage & development ain't that bad on a laptop, right?

Just tonight I found some extremely attractive Lenovo notebooks. Intel X3100 graphics and boast up to 4.5 hours battery life. Now, this last bit is flat-out amazing. I was all gung-ho on getting a cheap VIA-based notebook like this one because of the 3-hour battery life, and it is an alternative to Intel. Hey, I have an AMD workstation. But the Lenovos I'm looking at . . . sure, they're more than $400. And some of them are only Celeron chips (historically underpowered).

But man oh man . . . I found some new & used Thinkpad 61-series models that look good, as well as some Lenovo 3000 N models. And they're 15.4" widescreens. Light. Acceptably thin. They even have CD/DVD drives, which is almost optional for me. One's even dual-core.

So now I have to figure out how much money I really want to spend -- $400 to $600 is really a huge price gap; there are far too many features and choices available for any given manufacturer.

What's really starting to sway me over to Lenovo, despite my earlier post, is whether or not the integrated wifi, pointer, and fingerprint reader are in solid working condition. Specifically for the R/T/X/61 & 3000 N series. And whether the rest of ACPI, hotkeys, power management, HDAPS, and disc drives work correctly. And that I can get CPU/HDD temperatures, remaining battery life, and processor speed reported in a graphical utility. Apparently lm_sensors shouldn't be used on Thinkpads, so I wonder what else would report that info. On the fingerprint reader front, dsd is working on some kinda fingerprint software. Will have to check. Will also have to find some recommended spindown & sleep settings for Thinkpad hard disks.

For features, Thinkpads are looking better and better. It's true, they do look like refugees from 1985. Ugly as sin. Ugly as a dead cow in clown shoes. Splashed with hideous bits of color here and there. But still . . . they're starting to become attractive.

So, it's a new year. With new possibilities. Like laptops. Especially laptops. Now I just have to get my wife to sign off on one in time for SCALE . . .