Josh Saddler

Even though I'm currently sick with H1N1, also known as swine flu, this morning I was feeling well enough to write an ebuild for an interesting media app I found: Tabu Audio Player. It's an interesting player -- while it still needs some translation work into English, it's simple and has an appealing UI drawn by Cairo.

It had only a single configure option, "debug," and a very short list of dependencies, so I figured it'd be a simple ebuild to write, right?

Wrong! Turns out that after a half-hours' worth of poking at configure.ac, the package's check for --disable-debug/--enable-debug was completely broken. If you explicitly passed --disable-debug, like "-debug" in IUSE, then it would enable the debug build every time. Thanks to rej and a3li on IRC for nailing this problem down; they were really helpful.

a3li also shared his solution for the same problem in one of his packages, so I used it in my ebuild to ensure that "debug" works properly as a USE variable.

Meanwhile, I sent a bug report to upstream asking for a smarter debug check. I also asked for CFLAGS="-02" to be removed from Makefile.am, that way folks are free to use their own -O levels without having to resort to using sed on the Makefile, as I had to in the ebuild.

Speaking of which: I have an ebuild for Tabu 2.1 waiting for you in my devspace, if you'd like to try it out.

Last night I installed UT2004 on my laptop, after not playing it since June. The laptop in question is an older ThinkPad R61i, with an Intel X3100 graphics chip. I know -- not the best for gaming. However, most online reports I found indicate that it's acceptable for such an old game as UT2004, so I figured it'd be worth a shot. The Intel graphics drivers have made a lot of progress in the last two years, especially on the 3D front, right? Right?

Kinda. After reducing all settings to "low" and dialing back the resolution to 1024x768 (native is 1280x800), the game is playable, but with very uneven framerates. Looking toward the middle of a map, or anyplace with a lot of action, introduces a good stutterfest; frames are down to between 8 and 18FPS. I enabled a few extra options such as pixel shaders and VBOs in UT2004.ini to add a bit more performance, but it's still marginal.

I'm rather disappointed. I'm not having nearly as great an experience as other Linux users, and certainly not as good as the Windows gamers who've benchmarked Unreal on this hardware. However, I did also catch the huge xorg-server 1.7 update as well, so maybe there have been some performance regressions since 1.6. It makes it a little hard to determine the areas that could use tweaking. I don't have anything special in my xorg.conf, just a default resolution. It's possible there's a setting I'm missing.

I'd like to try UT2004 on my desktop workstation, which has a RadeonHD 4550 card, but all reports indicate that even the latest git checkouts of the open-source drivers still don't work with Unreal. Apparently the game can't even launch, much less run at playable speeds. But as rapidly as the drivers are maturing, I'm hoping this'll be fixed in a month or so. Call me optimistic.

* * *

It looks like Abiword 2.8.0 was released today, so I wrote an ebuild and made it available in my devspace. I've been hand-writing these things for awhile. It took quite a bit of research to determine what went into the 2.7 betas, and now I'll have to do another overhaul of the 2.8 ebuild to account for the new plugin system. There's no longer a separate abiword-plugins package; they're all distributed in the base 2.8.0 archive. This means there will be a lot more tricky configure checks and USE flags, which sucks from a flexibility standpoint. Keeping the plugins in an external package was much simpler, so I'm a bit disappointed by this upstream decision.

Still, right now you can download and install Abiword 2.8.0 using my ebuild. While it needs a few cleanups, it will get you set up with a fully functioning basic Abiword install, though the only available plugin (as shown in the "Plugins" dialog) is .odt support.

This new version launches much quicker than 2.7.10, and it seems to have fixed all the rendering errors and even the crashes that happened with basic operations. Basically, you can click stuff now without worrying.

Cleaning up my ebuild is a long task, thanks to those darned plugins. Patches welcome, or I suppose you could always just wait and see what ends up in Bugzilla.

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

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

Radeon

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

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

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

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

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

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

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

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

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

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

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

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

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

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

SSD

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

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

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

More hardware

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

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

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

* * *

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

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

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 . . .

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tune in next time for more mini distro reviews.

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

It's official! Decibel Audio Player is now in Portage. Thanks to aballier for adding it, and thanks to everyone who provided feedback & testing.

Yay for yummy audio goodness!

The newest Decibel Audio Player is out, and it fixes several bugs and adds some new features.

The ebuild has been updated, so get it here!

More hacking and progress made on Decibel; I've finished (for now) ironing out the dependencies. I dropped some USE flags in favor of the latest gst-plugins-meta, which already has the same flags. The updated ebuild is available here. I also uploaded a screenshot for the curious. (You can download the album itself here.)

I got in touch with Decibel upstream to let them know of my efforts to bring it to Gentoo, so they kindly linked back to my page on it.

Go on, try it out. So far it's only been tested on amd64 and x86. I want to hear back from folks using it on other architectures. If gtk+ and gstreamer are available for your arch, you should be able to run it.

The only thing thing Decibel doesn't do -- yet -- is display album covers. That's the only feature I want that I can think of.

It's simple, clean, and awesome, so try it. Lemme know what you think, and especially let me know if it runs on other architectures. PPC? Sparc? HPPA? Come one, come all.

Presenting a new(ish) package, never before seen in an ebuild: Decibel Audio Player.

Took me all night to write the ebuild from scratch and finish the documentation, but here it is. Report any problems with the ebuild by emailing me directly. Contact upstream if you have problems with Decibel itself.

Here are some screenshots. Go on, try it out!

I filed a bug to get Decibel into Portage, so follow along at bug 219329.

Kudos to the Decibel developers; they've created one slick app.

Well, my efforts to port Drivel to the newer gtk+ functions and away from deprecated libegg stuff aren't going well, despite my earlier hopes.

Spent a couple of hours tackling the issues mentioned in the libegg bug. Fortunately, two of them are moot: Drivel doesn't seem to use EggCellRendererKeys or EggAccelerator anymore. The EggRecent -> GtkRecent change seemed to be extremely widespread, so I instead took a stab at porting Drivel over to GtkStatusIcon, instead of the old EggTrayIcon stuff.

Not looking so good. I thought I'd switched over everything as per the documentation, but I got compile errors: libegg/eggtrayicon.c, line 79 or thereabouts. Apparently everything was being used for the first time without being declared somewhere? Oops. I went ahead and wiped the Portage tempfiles and all my work thus far. If I go back to it, I want to start fresh.

Part of the problem was that I just couldn't find any documentation on whether or not a given bit of old libegg code was present in gtk+, or what it was called. Another problem was there was libegg cruft all over the place. It's got its tentacles everywhere; I've no idea how to entirely clean it out. Can new gtk+ code be used with old, outdated libegg bits? Where's the documentation for it? Etc.

So even thought it looked like I'd correctly changed EggTrayIcon to GtkStatusIcon, moved all the egg_tray_icon_foo bits to gtk_status_icon_foo, and remembered to change *icon to *status_icon (and a few other things), it just wasn't enough. The compile process mostly seemed to choke on renamed gtk_status_foo_init lines. Maybe I should have left those as egg_whatever_init? I may never know.

It's my first real shot at trying to clean up code that isn't a markup language. Markup languages I know. Programming, not so much. It's educational all the same, I'm sure. Gosh, just think about how fun porting Drivel to GIO will be.

I still aim to continue improving Drivel for Gentoo users somehow.

Sometimes you swing, sometimes you miss.

What have I been doing lately?

Patching Drivel, that's what!

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

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

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

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

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

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

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

* * *

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

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

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

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

SCALE

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

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

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

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

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

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

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

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

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

ebuilds

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

burning apps

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

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

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

gtk

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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