Josh Saddler

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

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

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

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

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

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

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

* * *

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

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

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

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

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

Alternative distros

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

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

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

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

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

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

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

Alternative desktops

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

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

Gentoo

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

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

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

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

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

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

Now it's time for DeLi Linux.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Worst-performing LiveCD ever.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Tune in next time for more mini distro reviews.

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

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!

In case you missed it, the Gentoo Foundation has been reinstated, so we're all nice'n'legal again.

Thank you, trustees, for all your efforts!

You can view our updated paperwork with the state of New Mexico here.

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.

$ history|awk '{a[$2]++ } END{for(i in a){print a[i] " " i}}'|sort -rn|head
77 cd
69 ls
63 eix
46 gvim
38 cvs
36 su
27 less
26 exit
16 rm
15 grep

Yay for gvim. I'm surprised nano doesn't appear, though. Now that the meme's out of the way, on to the docs business.

For those of you on the bleeding edge, OpenRC and baselayout-2 are now ~arch. Before you even attempt to perform the update, read the OpenRC Migration Guide written by myself, Doug, and Roy. And then read it while updating. I run systems with stable keywords, so I'm not updating until the code and kinks have settled down some, and the packages are stabilized.

As part of the OpenRC documentation changes, I've replaced references to resolvconf-gentoo with openresolv, as the latter is maintained and stable for all arches. The former is dead and will be removed from Portage at some point.

Speaking of documentation, if you're interested in helping out with an up-and-coming documentation tool, take a look at Beacon, an XML editor. It's designed to be an easy way to create and edit documentation; this makes it easy for newcomers to contribute to Gentoo's GuideXML documentation. However, it does need some more work, so contact Anant if you're interested in making Beacon usable for the masses.

In hardware-related news, I just received my silent mouse from Quietmouse.com. This thing is silent. You can't hear the clicks, but it still feels like a normal mouse. No more annoying clicks during gaming or any other computer usage! The wheel is silent too at slow to medium scrolling speeds; it has a hushed whispery noise character during rapid scrolling. Faint, but not unpleasant. It's perfect if you're a silent computing enthusiast like me. The mouse works in Linux; no special configuration needed. Works well in gaming too; it's got a nice high scanning rate. It doesn't randomly freak out the way my old Dynex mouse does.

I've also got a new keyboard on the way from NCIX. My current one's not remotely quiet anymore, and it's pretty discolored after 3 years of use. Cheap silver plastic, go figure. I'm hoping the new one is much more quiet; it took awhile to find an identical layout to my current keyboard. The home/page/del keys are right where I want them.

Quiet keyboards are few and far between, so if the replacement keyboard doesn't work out, well, it's only $7. I wouldn't mind moving to the new slim Apple keyboards; I've heard they're decently quiet, as well as being rather sexy. Rather pricey, though, at $50.

I'd take cheaper and quieter over sexy and expensive, if it comes down to it. Must have scissor-key action, and it should preferably have a laptop-style layout. Any suggestions?

Another day, another release. Another handbook written.

I'm so happy I finished writing those things. Once 2008.0 final is released, the only change I know I'll have to make at this point is changing the release name from 2008.0_beta1 to 2008.0, and as others have mentioned, that change is easy to make. Keys in the TOC allow me to make conditional evaluations in each handbook. So in the XML source, if I write:

<p>
Stage3 tarballs can be downloaded from <keyval id="release-dir"/>
</p>

This will replace release-dir with the location of the release, as fetched from the corresponding key. So depending on the handbook you're reading, you'll see something like:

Stage3 tarballs can be downloaded from releases/amd64/2008.0_beta1/stages/

Simple, but oh-so-maintainable. I don't just use keys in the handbook TOC, but I also can add conditional evaluations that pull in paragraphs, sections, subsections, code blocks, you name it. These can also be from external files, too. That's one of the things I've been doing for this release -- finding duplicate content for all arches, and moving that text into a separate external file.

One example is the text that explains block devices. Each arch used to have similar text, sometimes slightly (or significantly!) different. I unified all arches -- put them on the same page, so to speak -- by creating an external include. I first pitched the includes proposal back in March 2007, and it's finally coming to fruition with the 2008.0 release.

By using the following tidbit:

<section>
<title>Introduction to Block Devices</title>

<subsection>
<include href="../hb-install-blockdevices.xml"/>
</subsection>

<subsection>
<title>Partitions</title>

I can drop the contents of hb-install-blockdevices.xml into place, providing the same descriptive text. If it ever needs changing, rather than having to change 16 handbooks, I can change just one, and all 16 will use it. This example is taken from a file in /handbook/2008.0/, so it refers to the included file one level up, in /handbook/. The included content doesn't even have to be in the same directory as the file using it!

I'll be implementing even more of these kinds of changes in the future. They increase maintainability, increase uniformity, and, more importantly, preserve my sanity when editing handbooks. And if I stay sane, I don't retire.

Makin' good progress on the handbooks and other documentation for the upcoming 2008.0 release.

Sent off the networkless handbook tarballs to releng as promised by the deadline. Finished the Portage handbooks. Also got just about everything done for the networked handbooks, too. There's one blocker for the tracker bug, and that's something that doesn't really need to be.

Also there's some changes to make to a few of the other documents, but those aren't too bad...compared to last release.

I'm getting precisely zero help from the rest of the GDP with the release, though. That's not making me all that happy. It's the sort of thing to make someone retire, go on vacation for a year, or never work on the handbooks ever again and everyone is screwed because no one's left to work on 'em.

That being said, my stress levels are much lower this release. Much, much lower.

Which is good, since my sciatica has flared up since getting injured at SCALE a couple of weeks ago, making it almost impossible for me to walk sometimes. Excruciating pain at times. I'm starting to get better, but it'll be several more weeks before I'm "well."

SCALE

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

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

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

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

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

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

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

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

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

ebuilds

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

burning apps

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

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

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

gtk

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

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

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

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

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

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

Off to SCALE. Gentoo, represent!

See you there.

Right, I'm almost done setting up the Thinkpad.

The keyboard is still taking some getting used to -- I hate having the Fn at the far left, where the Ctrl key should be, and I hate not having the Del/Home/End keys vertically aligned with the right edge of the keyboard. I also keep forgetting I have a working middle mouse button for Firefox. Too used to having to Ctrl-click tabs on the Toshiba. And . . . I love the scroll function on the synaptics touchpad. Love it. The pad itself I don't use much; I'm too used to trackpointers. Plus it's too easy to turn a drag motion into a sudden click. I do like the IBM trackpoint more than my Toshiba; the IBM one is more accurate and has a nicer surface.

Fingerprint use: for the time being, I've uninstalled fprint, and installed thinkfinger instead. Why the switch? Because thinkfinger works out-of-the-box with SLiM, and pam_fprint doesn't work with it at all. If it worked with SLiM, I'd switch back. Also, thinkfinger's enrollment seems to work better. I'm getting far fewer rejected scans. I'd like to file a feature request bug with fprint upstream to get SLiM supported, but its bugtracker mails aren't getting through to my devmail. dsd, you reading this?

I still haven't bothered playing with hdaps yet or finding out why it thinks my disk is unsupported. While on the subject of disks, it occurs to me that I really should have created a /usr/portage partition and formatted it as ReiserFS. ext3 is just too slow for Portage ops.

I at least solved my networking issues by adding a couple of required modules and undoing parallel startup. I also fixed a typo in conf.d/net. I don't plan on using NetworkManager any time soon, as it requires lots of Gnome dependencies. For now, I added a second network block to wpa_supplicant.conf:

network={
        key_mgmt=NONE
        priority=-9999999
}

I haven't tested it yet, but I think this should work for unsecured public access points. Actually, I think this was probably in wpa_supplicant.conf before I deleted everything and added my own config.

My desktop and development environment are just about complete; got my keys imported and my firewall setup and everything. Still haven't setup my system for Bluetooth or audio production yet. Or games.

As promised, I've made my working kernel config available. For all you Intel X3100 users, this may be of use in setting up uvesafb. Also, if you've got an IPW3945 ABG network card, this may be useful if you're using the in-kernel iwl driver. I've enabled the appropriate statistics options to use powerTOP, which is a very nice way to monitor power usage. I get about 2.8 hours doing basic wireless internet, docs work, etc. with my screen almost at full brightness. Not bad. I think I waited too long to get an Ultrabay battery; SCALE 6x is less than a week away!

Speaking of SCALE, I'm going. So I should probably get tickets & registration for me and my wife, yeah? Oh, and a hotel reservation. My new laptop has been such a distraction.

I've discovered a really unusual bug/behavior. I removed alsasound from the boot runlevel, in case I'm running on battery. Now, unless you blacklist them, your sound modules will still get loaded regardless, taking that much more power (even with aggressive soundcard power management enabled.) So what I had been doing was starting and stopping the ALSA initscript once my desktop was loaded. Here's the bug:

Starting and stopping ALSA this way actually kills all GTK theming in Xfce. The decorations revert to GTK defaults, the window colors go to their GTK defaults, the panel becomes ugly, you name it. All I have to do to re-apply the default (pretty) Xfce GTK theme is open one of Xfce's configuration utilities. Any of them. Isn't that bizarre? I have no idea why the hell that happens. Every time I stop ALSA. It's a minor nuisance, I guess.

On thinkpad_acpi and hotkeys:

It's a known bug that the brightness hotkeys don't work, but echoing values directly to /proc does. There won't be a fix for this any time soon, either. I've been in contact with upstream, submitting reports to their database, etc. Still have to go through and test the rest of my hardware (Bluetooth, etc.) and submit another report, but the outlook is not favorable for hotkeys. I still need to find a good program that will recognize the Fn-Home/Fn-End key command for brightness adjustments. xbacklight works, but I need keybinds to call it. Xfce has a built in keybind program, but it can't see Fn key combos. I'll have to find a sane xbindkeys setup (or similar app); there's probably something on ThinkWiki or the Gentoo Forums.

Signing off for now . . . maybe I'll see ya'll at SCALE? Come on by the Gentoo booth! Devs, users, groupies, etc. are all welcome.

I'm still busy setting up my Thinkpad R61i. In many ways, this thing is more of a pain than the ancient Toshiba it replaces. That's part coincidence, and part "I-really-want-to-do-this-right" and part "I-really-want-maximum-power-save-and-avoid-risking-hardware-damage".

One of the few bits of hardware that didn't take hours of setup was the fingerprint reader. I lucked out and got a working UPEK TouchStrip, vendor ID 0483:2016. It works for console logins and su to root. fprint is awesome!

I'm using stable amd64 mostly, except where I need the latest ~arch packages for hardware functionality. I used a stage3 tarball from Daniel. So nice to have an up-to-date stage.

The capacious-yet-quiet hard disk came preloaded with Vista Home Premium. Ugh. I used a Sidux LiveCD to shrink it and shove it off to a corner. Why did I use Sidux? Because they seemed to be the only distro whose LiveCD offered a 2.6.24 kernel, which meant....wireless installation! Wrong. Lies. They use .23, no iwl3945 drivers anywhere. I had to get out my ridiculously short ethernet cable. Bother.

On the Gentoo side, I ended up going with ext3 for / and ext2 for /boot. This is most unlike me, as I'm normally a ReiserFS man. I figure 1) it's possible that if something does go wrong, it may be easier to recover with ext3. 2) I can try out ext4 later. 3) Fewer packages to emerge; e2fprogs is already part of the system set. As far as usage goes ... ext3 is perceptibly slower for certain operations, but it also feels much faster when mounting.

The whole configuration process is still ongoing, with a few major problems:

1. Masked and unstable drivers for X. Still only xorg-x11 installed; no Xfce4 yet. At least I have working hardware acceleration with the X3100 chip, using xorg-server 1.4 and mesa 7.0.2.

2. Wireless. Day and a half to get it mostly working. At boot, it seems to associate with my WPA access point, but then goes inactive immediately. Unfortunately, it seems to take the service with it, so things like netmount and ntp-client don't start. Now, the device is actually associated and has retrieved its IP address. But it's an unresolved headache as to why it does all this but still doesn't consider the service "started". This is with kernel 2.6.24, in-kernel iwl3945 modules, as well as crypto modules. Once Xfce is running, I plan to undo most of my networking config files and just use NetworkManager or some other tool to do everything. I hate having to manually edit conf.d/net just to change from my home network to public access points in libraries, coffee shops, etc.

3. uvesafb. Day and a half to figure out. Apparently I needed a weird/unintuitive setting or two in my kernel config. Works now at native resolution, 1280x800.

4. hdaps. Apparently my harddrive isn't supported? It's possible the folks at IBM refurbished the laptop with a non-stock drive.

5. thinkpad_acpi. Not all buttons are working yet, specifically screen brightness. That's despite following the basic instructions at ThinkWiki on kernel module parameters. I haven't really delved into it yet, though. At least the thinklight works.

6. Touchpad & trackpoint. I figured out just an hour ago why the trackpoint wasn't working. Though the protocol was set to "IMPS/2", I had to change the driver to "mouse". So now both work in X. Will post config later. My hope is that the middle button works properly once I get Xfce and Firefox installed.

That's it for now. I haven't done much else besides get the bare necessities working for the console environment.

My goals are as follows, in no particular order:

1. Complete desktop installation & configuration.
2. Setup low-latency/realtime system and applications for music recording and editing.
3. Configure system to draw as little power as possible, regardless of activity. I really want at least 3 hours out of my existing battery, even though I'll also be buying an UltraBay battery.
- setup laptop mode for just about everything, including hard drive, CPU, wifi card, soundcard, bluetooth, screen, optical drive, reduce interrupts, etc. I'm really nervous about hard drive settings in particular, as we all know what happens to it under too-frequent spindowns.
4. Figure out how to turn off the darned green LED light by the optical drive. It's killing me.
5. Did I mention power efficiency?
6. Get the rest of thinkpad_acpi and all the nifty hotkeys working. I want hotkeys that work, unlike my Toshiba's nonworking keys.
7. Setup Gentoo development environment, GPG stuff, etc.
8. ???
9. Profit.

I'll post more in the coming days, and (if I still have the strength) I'll write up some installation notes and configuration information, probably in my devspace or on ThinkWiki. Not much info out there on the R61 series.