Josh Saddler

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?

I was poking through the contents of my world file and USE flags the other day, trying to trim down the number of Gnome dependencies present on my Xfce laptop. Abiword is the application that requires all the Gnome stuff. If only it didn't need deprecated libraries like libgnomeprint, the rest of the Gnome desktop wouldn't get pulled in.

So, I started looking around at alternative word processors and office suites. There's always OpenOffice, but I don't really like using something as slow and bloated as OOo even at the best of times. There are some other office packages available, but they're for Qt/KDE. Or they're made of something really icky, like Java.

And then I found it: Siag Office. This office suite dates back a number of years. It used to be present in Gentoo, actually, but was removed five years ago.

I took a look at the upstream homepage; it still seems to be sporadically developed. Last release was in 2006. I poked around in the documentation, INSTALL, READMEs, and whatnot in the upstream CVS to get a better feel for what's required. Siag mostly relies on little-used X libraries, including old-school Athena widgets and their derivatives. It also has its own expanded widget kit, Mowitz. Siag ain't pretty, though at least it looks better than Motif-based apps. Most importantly, it's reputed to be very fast, needing very few dependencies.

The Portage CVS attic contained outdated ebuilds; the latest Siag release is 3.6.1, and the latest Mowitz release is .3.1. I used the outdated ebuilds as a foundation for creating my own ebuilds. And that's when the trouble, I mean fun, really began.

For starters, the old ebuilds had a lot of cruft leftover from the pre-modular X days. Stuff like virtual/x11, deprecated configure/make functions, unnecessary USE flags . . . even some bad configure switches from when the code did odd things, like --host=${CHOST}. These obvious mistakes required fixing. Then I checked the Getting Siag page to get more of an idea of the current dependencies.

Siag-3.6.1 has build dependencies on gmp, Mowitz, tcl, libXpm, and libXaw. It has optional runtime dependencies for Python, ccmath, and netpbm. The dependency on libXaw may be interchangeable with other Athena widget-compatible libraries. I sent an email upstream to verify this, as comments in the source code give the impression that while Xaw can be used, so can XawM (a variant created by the Siag folks), Xaw3d, and possibly even neXtaw. In my email, I asked specifically about neXtaw, as Mowitz relies on neXtaw. I figure it's best to just use one widget set if possible to give a more unified appearance. Perhaps neXtaw can be used as a drop-in replacement?

Anyway, once the dependencies were updated for the Siag ebuild, it was time to redo the configure/install section. This is actually still a work in progress; I haven't taken the time to really nail down the optional dependencies, add final USE flags, etc. I've been trying to get working ebuilds, not perfect ebuilds. Not yet.

Once the Siag ebuild was working, I moved on to the Mowitz ebuild. This required many of the same fixes that Siag did. The biggest headache, though, was trying to get the Xaw dependency hammered out.

The old version used to be able to use a number of Xaw varieties, same as Siag. However, the latest version seemed to have narrowed it down to either Xaw3d or neXtaw, default is neXtaw. The configure switch --with-xaw3d= should allow for either one, right? The source code comments in the INSTALL file say the same thing. Unfortunately, it doesn't hold up in reality. If neXtaw is not installed, the configure phase will fail, saying it can't find the Xaw implementation (aka neXtaw). I spent an hour throwing Xaw3d and Xaw name/path variants at it before giving in. How ironic that the --with-xaw3d= switch can't actually use Xaw3d. So I let it just run with the default neXtaw, updating the ebuild for this build dependency. Worked just fine. Good thing that neXtaw was never taken out of the Portage tree! The neXtaw ebuild, at least, is up to date.

In my email to the upstream maintainer, I mentioned that the configure and/or documentation is incorrect. Hopefully I'll get a response, but it has been a few years since the code was touched upstream.

Now that I'd hammered out the dependencies for Siag and its two required dependencies (Mowitz and neXtaw), it was time to merge the package. The sourcecode for Siag itself is only abou 1.5MB. That's right, a whole integrated office suite, with word processor, spreadsheet, animation app, file manager, text editor, and previewer . . . less than 2MB. That's quite an accomplishment! Only took a few minutes to compile.

I discovered that Siag is so old that it seems to predate the common .desktop files used to display an application in your program menu, or at least upstream hasn't bundled any. I'll have to write up my own .desktop entries and add in the accompanying installation function into the ebuilds. So I had to use the command line to launch 'em. That's when the biggest issue hit: Siag won't run.

None of the binaries installed can actually run; I have hit upon a rather famous error that dates back to 1998 or so, and has popped up here and there in the intervening decade:

$ siag
Warning: Cannot convert string "-*-helvetica-medium-r-*-*-12-*-*-*-*-*-iso8859-*" to type FontStruct
Warning: Missing charsets in String to FontSet conversion
Panic: can't load any fonts!

I'm not entirely positive what causes this; Google searching has widely disparate bug reports. It's probably something to do with the way pre-modular X did font handling. Siag seems to want to do stuff in certain ways that the old monolithic X did. It may be able to compile against more modern libraries, but whatever it wants to do is too old-school. There's probably some leftover cruft hardcoded somewhere. I just haven't found what, yet.

At least I can see the errors when running the main applications like siag and pw. The animation app, egon, won't even show that much. Just as in the linux.com review, egon simply would not run:

$ egon
Segmentation fault

I'm unable to perform any further diagnosis. I don't have any debug libraries or applications installed on the laptop, and at this point I'm not going to waste any more time on just this one application.

I'll still try to get the rest of Siag running -- there are a few solutions for the runtime font failure, but none of them have worked for me so far. I have not yet given up; I'm still trying to find ways to slim down my laptop, get rid of Gnome dependencies, and lighten up my Xfce environment.

I've put my work-in-progress ebuilds in my devspace. Once again, I should remind you that the Siag ebuild in particular is not yet finished. It'll do the most important things--compile and install Siag--but it's not finished. If you're looking to cut your teeth on some simple ebuild tasks, you're welcome to spend some time in our Gentoo Development Manual and send me a patch. Working with ebuilds really isn't intimidating the way it may appear at first. Mostly, the work just requires time to sort through issues as they turn up. Time, not arcane knowledge of the most secretive inner workings of code.

Also, if you've got any potential solutions to the font startup failure, I'd love to hear from you! This is the last remaining barrier that I know of to getting Siag working. Well, that and setting up Siag to print, as it doesn't have a graphical interface. Instead, Siag needs you to tell it the proper CUPS commandline stuff. Which, again, is just a bit more time and reading the manpage for lpr. Time and reading. That's most of the process. Time, effort, and persistence.

I'm hoping it'll pay off for Siag Office.

Thanks to Markos Chandras, RedNotebook is now in the tree. RedNotebook is a really cool lightweight journal for your desktop. It needs only pygtk and pyyaml. It's got nifty features like a calendar, tags, templates, searches, format export, and more. It's quite actively developed upstream; I plan to proxy-maintain it for the good of Gentoo users everywhere. Go on, try it out!

* * *

Also, as you may have noticed, the look of my weblog has changed. Instead of the Evopress skin, I'm now using the Gentoo skin I created for Planet Gentoo, based on Evopress. Now it's all-purple, just like the old Planet look before the b2evolution upgrade some months ago. You wouldn't believe how long it took me to create the top purple graphic; I ended up having to hand-edit that thing pixel by pixel. I couldn't find any easy way using the GIMP to recolor the existing blue gradient into a purple gradient. So I made my own, pixel by pixel. I think it looks pretty good.

All developers that want to switch to the new skin:

1. Log into your backoffice
2. Go to Blog settings -> Skin
3. Select the "evonews" skin
4. Presto, a nice new purplish blog. Wear your colors with pride!

Ignore the "evogentoo" skin; that's a leftover test skin. I still have to iron out that bug, and fix the preview so that it appears on the correct skin entry. Enjoy!

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

Laptop

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

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

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

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

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

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

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

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

$ glxgears 
2516 frames in 5.0 seconds = 503.174 FPS

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

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

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

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

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

Xfce 4.6

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

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

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

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

Gentoo

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

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

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

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

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

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

PyRoom

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

WordGrinder

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

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

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

Hardware: graphics shuffle redux

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

Desktop

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

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

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

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

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

The Good

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

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

The Bad

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

The Ugly

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

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

* * *

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

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

For all the forumites, bloggers, wikifolks, mailing list members, bugzilla commenters, and general Gentoo netizens:

Please stop spreading bad advice such as ebuild foo digest. It does not exist. Digests have not been present in the Portage tree for a year, ever since the tree was converted to Manifest2 format.

If you've made a local modification to an ebuild, patch, or added anything else to your local overlay and need to make Portage aware of the changes so the package can be properly merged, do not use the "digest" command. Use "manifest" instead. For example:

ebuild foo-1.0.17.ebuild manifest

Digests have been dead for a long time. Please don't encourage bad practices.

This has been a December public service announcement. Thank you for flying Gentoo Air, and please enjoy the rest of your Christmas!

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.

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

Revamping the desktop

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

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

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

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

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

Graphically challenged

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

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

Hacking the routers

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

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

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

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

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

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

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

* * *

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

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

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

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

Yes, the ongoing saga of my hardware meltdown continues.

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

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

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

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

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

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

* * *

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

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

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

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

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

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

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

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

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

Right?

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

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

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

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

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

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

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

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

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

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

More mangled text

A clear screen once runlevel 3 begins

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I hate troubleshooting hardware. It gets expensive real fast.

I discovered a really nifty trick the other day, one that makes for a pleasant work environment and that fills the need for a launch area of some kind. It basically eliminates the need for iDesk, too.

While you may be aware that Xfce can draw the usual home, trash, and volume folders directly on the desktop, it can also do things with the icons on the desktop. Like . . . use them as application launchers.

Open up a browser, and drag a .desktop entry from /usr/share/applications onto the desktop. Presto, there's your application launcher. Much larger than the usual miniscule panel icon sizes, too. The downside is that you can't drag items directly from your Xfce menu, but as long as you know where they come from, you can add any launcher you want. A bit of tinkering results in the following:

Who needs a panel, when the desktop launchers, right-click desktop menu, and keyboard commands work just fine? Unless you really need one, of course. It's almost like the ever-popular spartan Openbox + iDesk combination. Xfce distilled to its finest essence. Thank goodness for flexibility.

Over a month since my last entry. Anyway.

The Work

I've been busy churning out the August issue of the Gentoo Monthly Newsletter, as well as a GMN Howto. This is a guide that details the process for creating the GMN, from start to finish. Over the last couple of months, it's gone from a simple 15-line cheat sheet to something a lot more useful for future GMN staff and any interested contributors.

A fair amount of documentation updates for the GDP, too. I was curiously unmotivated most of the month of August, though that's in part because of my health; I spent the first bit of it in the emergency room trying to figure out why my insides were coming apart. Still no idea.

And I've updated my devspace. Lots of changes. Lots of new stuff added and rearranged; I expect I broke some old links, but oh well. All that stuff in misc/ really needed organization.

I also poked aballier to get the new version of Decibel into the tree. Oh yeah. Upgrade to 0.11; it adds album cover art, among other things.

The Apps and the Machine

I've also been hacking up various ebuilds for packages not yet in the tree, such as tint2. This is all for my laptop, which I'm trying to slim down even more. Been removing various applications and making it much more of a minimal Xfce environment. Plus, I like pseudo-transparency. Apps like stalonetray, tint2 (ebuild available here), netwmpager, dzen2, and conky are all curiously appealing. I'm trying to find lightweight, useful, complementary apps to Xfce, in my perpetual quest to create the perfect Xfce environment.

I discovered many of these applications by reading urukrama's blog and kmandla's blog. Both are excellent sources of information on small, light apps, and setting up clean, minimal, functional environments. Quite tasty; be sure to give 'em a read. Especially urukrama's Openbox guide. It's loaded with configuration info, application tips, and much more.

The Environment

I've replaced most of my Xfce panel with stalonetray, conky, and a couple of instances of tint. I just installed dzen, and will be investigating it as a possible replacement for conky. Dzen, however, seems to need a lot of initial time-consuming configuration. And it doesn't seem to do transparency. And it doesn't look like it can even do useful fonts like Verdana.

What I'd really like to do is get rid of all but the start button on the panel, but first I need to find an icon launcher bar that does pseudo-transparency. Why not real transparency? Because compositing with the Intel X3100 graphics chip doesn't seem to be too friendly on my battery life. Actually, I'd be happy if tint had launcher capability now; I hear it's going to be in a future release. I'll just use it when that time comes.

Here's my current desktop: 1 and 2. I've managed to find a nice-looking level of transparency regardless of light or dark background, so everything's fairly clear. Too bad conky can't provide transparency and shade, similar to everything else. That left-hand panel will be going shortly; all I really need are the launchers and the start menu button. Must find a way to slim it down; it takes up too much space. Plus I don't care for vertical panel arrangements.

Since folks are always curious about what's what in any given screenshot:
Left to right: Xfce panel, stalonetray, tint, conky, and tint (just date/time). The wicd applet is anchored in the tray, and a few terminals and gtk+ apps are open in tint.
Background: (1) Liquid Crystal, (2) VSE Grass Flow.
Screen: 14.1", resolution of 1280x800. I notice that when viewing it on my 19" 1440x900 desktop monitor, the fonts look extra-large. Well, they're much smaller on the laptop. The laptop resolution is so high that I have to enlarge things considerably; my eyes aren't what they used to be.

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

* * *

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

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

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

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

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

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

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

* * *

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

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

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

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

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

I'm now a proud wicd user.

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

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

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

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

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

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

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

* * *

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

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

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

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

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