LinLog

I knew something like this would happen. I just knew it!

Today I found a broken package in Kubuntu, and it got me so mad I could barely see straight. The package in question was gamin 0.0.26, which is, apparently, a replacement for FAM, which monitors the filesystem, for some reason. I discovered that this package was broken when I tried to configure ivman and autofs (I'll discuss that later). I noticed that after I closed the file manager window, my automounted USB storage device was not being unmounted. It turns out that gamin continued to monitor the mount point, preventing the drive from unmounting.

The really sucky thing about this problem was that there is no way to disable gamin. Apparently it's linked directly with the KDE libraries and is started automatically. There's no way to stop it from starting and if you kill it, it just respawns immediately. Fortunately, though, I found a post on Ubuntu Forums that linked to unofficial, third-party gamin 0.1.0 packages. After installing these, the problem went away.

So that's strike one for the Ubuntu guys. I can't believe they didn't backport a fix for such a truly sucky state of affairs. And I'm not even going to talk about depending so heavily on a package that hasn't even reached release 0.1.0! What were they thinking!?!

Everybody who cares about this has probably seen it already, but Opera Software ASA is giving away free registration codes for their Opera web browser. It's a one-day offer in celebration of their 10th anniversary.

Their server has been Slashdotted for several hours, but it seems to be back up now, if still very slow. You just give them your e-mail address, click OK, and they give you a page of registration codes. The really cool part is that they give you codes for the Windows, Linux (x86, PPC, and Sparc), FreeBSD, Solaris, and Mac versions. For the more paranoid people out there, you might also like to know that no e-mail verification is required, so the old me@here.com will probably work.

This is great news for me, because it means I can finally dump Firefox on my Windows box at work without having to convince my boss to spend $40 on a web browser when one comes with the operating system. Not that I have anything against Firefox - it's just that I like Opera better, if for no other reason than that I don't have to rely on buggy extensions to get the functionality I want.

So far, things are going well with Kubuntu. I was able to copy my mouse configuration from Slackware without any problems, and I was able to run the setkeycodes commands for my Microsoft Natural Multimedia keyboard at boot time after looking up a Debian Debian equivalent to /etc/rc.d/rc.local. The only real problem I had was with the SDL audio drivers. When I installed some SDL applications, the automatic dependency resolution installed libsdl1.2debian-oss, which obviously doesn't work when the system uses ALSA. This was easily fixed by installing the libsdl1.2debian-all package instead.

And speaking of packages, I am very pleased with package management so far. For one thing, the number of packages available for Kubuntu is very good - better than the Slackware selection you can find on LinuxPackage.net, which isn't too bad itself. The automatic downloading and dependency resolution of APT is quite nice too. Of course, you can get that in Slackware using Swaret or one of the comparable tools, but with APT, you get the added benefit that it's actually officially supported as part of the distribution. Swaret, Slapt-get and whatever other tools are out there are unofficial, not supported everywhere, and seem to be somewhat mistrusted by the community.

As for Kynaptic, the default APT interface, it's not terrible, but it's not that good either. The interface is pretty spartan and somewhat unpolished (when displaying menu names in the status bar, somebody forgot to strip the ampersands for the accelerators). It's also very short on functionality. It lists packages and lets you install, remove, or upgrade them, but that's pretty much it. It shows short summaries as tool-tips and doesn't show details at all. It also has no interface for configuring APT.

I'm actually surprisingly disappointed in Kynaptic. I wasn't really thrilled with QtSwaret, but it at least tried to be feature-complete, including package details and a Swaret configuration interface. And compared to the slick look of the Xandros Network tool, Kynaptic just feels very amateurish. With work, I'm sure Kynaptic could be very good, but right now, it just feels like there's too much missing to use it as the default package management tool. In the mean time, I may have to give Synaptic a try, despite the fact that it's based on GTK+.

I'm making progress with Kubuntu. The essential network services are up and running now, so I can leave the system booted into Kubuntu without worrying that Sarah won't be able to print or play MP3s. And at the end of the day, that's really what matters, isn't it?

I got the RaLink RT2500 wireless card set up without too many problems. In terms of difficulty, it was someplace between Slackware, which required editing the init scripts, and Xandros, where the graphical tool handled everything but the driver. To build the driver, I had to start by get the kernel source through Kynaptic, unpack it, copy the config file from /boot, and start the build (which I canceled after a few seconds) to generate the needed files and directories. I was then able to downloaded the rt2500 driver and build the module without difficulty. I did have a small problem with the installation - apparently I got the wrong kernel source archive or something, because the "make install" placed the driver under /lib/modules/2.6.10 instead of /lib/modules/2.6.10-5-386, where the rest of the modules were. However, that was easily fixed with a quick mv and depmod -a. The only other problem I had was setting the alias. Debian doesn't use the standard /etc/modprobe.conf for module aliases. Instead, I had to create an "rt2500" file containing the text "alias ra0 rt2500" in /etc/modprobe.d and /etc/modutils (well, maybe I didn't need both, but I figured it couldn't hurt).

Once the driver was installed, configuring the interface itself wasn't too difficult. I used the KControl network settings module to deactivate the integrated VIA NIC, enable the RaLink card, and set my static IP information. This worked well, except that, for some reason, it didn't set my gateway. This was strange, because there actually was a box specifically for setting the gateway for each interface. For some reason, though, the setting didn't seem to take, so I ended up adding the line "gateway 192.168.0.1" to the ra0 section of /etc/network/interfaces by hand.

Setting up my network services was a mixed bag. My three essential services are the NFS server, CUPS server, and Secure Shell server. NFS and SSH were trivial - I just installed the nfs, nfs-kernel, and openssh-server packages through Kynaptic, copied my old /etc/exports file, and I was good to go. CUPS, however, was a bit more difficult.

Let me preface this part of my account by saying that I have never, in my entire life, had good luck with printing. Almost every time I try to work on a printer, something goes wrong and I spend hours trying to fix it. (At this point, I've probably developed a mental block about it.) I was hoping beyond hope that things would go smoothly this time, but alas, it didn't quite work out that way.

At first, I was able to get my HP PhotoSmart 7760 working with the hpijs drivers without too much trouble. That was fine, but I don't want the hpijs drivers - I want the hplip drivers, which offer support for things like the printer's integrated media card reader. So I set up my /etc/apt/sources.list to include the extra repositories described in the Unoffical Kubuntu FAQ and installed the hplip package with Kynaptic. (Note: Am I the only one who finds it odd that installing hplip required uninstalling the "kubuntu-desktop" package, which, despite it's name, appears to only contain a couple of files worth of documentation?) After this, I was still able to easily set up local access to the printer using the KDE printer configuration wizard, but remote access from the Xandros box was shot. To cut a long and frustrating story short, after remembering to change the default "Location" in my /etc/cups/cupsd.conf file to 192.168.0.* (i.e. allow connections from everything on the LAN) and finding that it still didn't work, I ended up doing a diff of my old /etc/cups/cupsd.conf and my current one and removed the "Listen 127.0.0.1" line and replaced it with "Port 631". I couldn't tell you why this was necessary because, when it comes to CUPS and printer configuration in general, I have no idea what I'm doing. All I can tell you is that it seemed to do the trick.

The next chapter in my Kubuntu adventure will be on package management and installing all my favorite software. I'll include some thoughts on Kynaptic, Apt, and more comparisons to Slackware and Xandros.

I got the upgraded system up and running with a minimum of hassle the other night. So today, I decided to use the new hardware as an excuse do an experiment in changing Linux distributions. I've been a Slackware user since about 2001 and I've never seriously used any other distribution. In fact, up until I built those Xandros boxse for Sarah and my mother, I hadn't even tried to install any other distribution in years. Come to think of it, it's been a while since I installed Slackware - my current installation has survived three version upgrades.

So now starts my experiment in Kubuntu. Being kind of a chicken, I decided to maintain my existing Slackware installation, just in case. To that end, I moved what little data I had off the 8GB partition I used for /usr/local and used that as the root for Kubuntu. I reused my existing partitions for /home and /boot. I'm also starting out in Kubuntu with a fresh user account and will slowly migrate my data over from my old account.

The Kubuntu install process was not quite as nice as I would have hoped. Next to the Xandros installer, Kubuntu's text-based installer seems positively primitive. Of course, aside from the lack of visual polish, the installation was pretty painless. The only sticky point for me was the partition setup. I found the partition configuration tool to be a bit hard to use. For one thing, I was unnerved by the fact that the "confirm" function was labeled something like "write partition table," which was a bit scarry because I actually didn't want to change the partition table. There was also the unintuitive screen for setting up each individual partition, which forced me to pick a filesystem for partitions I had no intention of reformatting, and the partition list with cute little icons, but no key as to what they mean. Not a big stumbling block, but not encouraging either.

The only real problem I had during installation was a lack of space on /boot. I only have a 10MB boot partition and I've never needed more for Slackware. In fact, with Slackware, I can keep three or four old kernel images in /boot without worrying about space. However, Kubuntu has a 4.2MB initrd image that it puts in /boot, so I had to free up a little space. It turned out that doing this was as easy as switching virtual consoles, mounting the partition, and deleting a few older files.

Now begins the real work. I'm currently typing this from my virgin Kubuntu desktop. My first order of business will be to get my Ralink RT2500 wireless card up and running so that I can put away the 25 foot ethernet cable I had to run downstairs to do this installation. After that, I'll copy the configuration for my extra mouse buttons and my Microsoft Natural Multimedia keyboard. We'll see how it goes from there.

It's time to turn off Tallgeese and take it apart. "Tallgeese" is the name of my home desktop workstation (and yes, I do have a Gundam Wing naming convention - Sarah's box is "DeathScythe" and the one I built for my mother is "Sandrock"). It's an aging 500MHz K6-III with 224MB of RAM, which is serviceable, but it's painful to program on using anything other than Vim. In fact, even Vim takes a while to start up on it. So, for my birthday last week, I ordered myself an upgrade - one of those new 64-bit Semprons with half a gig of RAM. Not the greatest development system on the face of the earth, but the motherboard has lots of expansion slots and I managed to get away with spending just $215 after shipping and a sound card (I bought a $15 card with a C-Media chipset, because I didn't want to fight with the integrated Realtek piece of crap).

So this will be the last post from the old Tallgeese. Later tonight, I'll finish putting the new system together and, hopefully, make my first post from the Tallgeese II (refer to the anime if you don't get the reference). The remaining old components will probably be put together with what I had left over from Sarah's old PC to make a test server, or possibly an MP3 jukebox. Or maybe both - I haven't decided yet.

I've had this problem a couple of times now. I'm using the KDE 3.4.2 Slackware packages downloaded from the official KDE mirrors. When trying to build a KDE application, the configure script bombs out on "checking if UIC has KDE plugins available" with a message that that I need to install KDE libs first. This time, the message was:

If you did install kdelibs, then the Qt version that is picked up by this configure is not the same version you used to compile kdelibs. The Qt Plugin installed by kdelibs is *ONLY* loadable if it is the _same Qt version_, compiled with the _same compiler_ and the same Qt configuration settings.

So does this mean that somewhere along the line I ended up with Qt and KDE builds that don't exactly match? I guess that's it. Not that I know why they need to exactly match, but that's a different story. I'm not going to worry about it, though, since it'll fix itself the next time I upgrade.

As a stop-gap, a little Googling revealed that you can sneak by that check by editing the configure script, finding this line:
if test -f actest.cpp && grep klineedit actest.cpp > /dev/null; then
and changing "klineedit" to "KLineEdit". I don't know if this causes any problems with the build, but I don't think I've tried to build anything that requires UIC plugins yet.

You know what I hate? People who do business from lame e-mail accounts. For instance, I was reading the latest issue of Skeptic this morning, and one of the authors had an e-mail address listed as somethingorother@aol.com. And this guy had co-written a book that was reviewed in a previous issue! Why can't his publishers just give him a corporate e-mail address? Of course, it could be worse - I've also seen people doing business from free accounts at Hotmail and Yahoo!

It's not that I have anything against people who use Hotmail, Yahoo!, or any other free e-mail service. They're perfectly fine services for personal use. It just annoys me when people do business from them. It's one thing to use a Hotmail account to send your cousin a link to a Dilbert cartoon, but it's quite another to use one to sell me a product, service or idea. I mean, getting your own domain is cheap these days. I only pay US$70 a year for my domain and hosting account. It isn't even hard to manage - it's got a nice web-based control panel and everything. And yet some people still expect me to take them seriously when they can't be bothered to invest a lousy $70 a year in their product? Give me a break!

The past couple of days, I've been trying to make my Slackware desktop not suck. OK, that's not entirely fair, but it's not completely off either. Slackware is a very capable distribution, but it has its down sides, and those are what I'm trying to remedy.

One project I started last night was getting the extra stuff on my printer working. I have an HP PhotoSmart 7760 with one of those built-in flash card readers. The printing works fine out of the box with CUPS, but the card reader doesn't function at all. For that, you need the low-level HPLIP drivers. The good news is, they weren't too hard to set up. Linux Packages.net had Slackware packages for HPLIP and all the supporting libraries I needed. So now I can mount flash cards inserted into my printer (for whatever good that does me). Now I can set it up with automount and I'll be good to go.

The other thing I tried out tonight is the Qt GUI for Swaret. If you're not a Slackware user, Swaret is an automatic retreival and installation program, in the same vein as apt-get. I've used swaret for a while, but this is my first experience with QtSwaret. I'm thinking this might be a good chance to learn some Qt, as QtSwaret is in serious need of work. It's a good start, but it's way, way to quite for comfort. Package management tools should give verbose feedback, or at least accurate progress bars. It also needs more error checking, because it took me a good three or four tries before I realized that the reason it wasn't actually doing anything when I click the buttons was because swaret wasn't in my path. A warning would have been nice.

Another annoying thing about it is the complete lack of documentation. For example, I was stupid enough to click on the "DB Update" button, thinking it was the button to run swaret --update, which is the command to update the package list. However, after the progress bar finished, I noticed that the system was a little sluggish and the hard drive was quite active. To my horror, it turned out that swaret was upgrading some packages! Apparently I clicked the wrong thing at some point, but it wasn't readily apparent because QtSwaret doesn't give much in the way of feedback. Oh, you can watch the output of swaret in a text window on a tab in the upgrade screen, but that only works if you get to that tab before you run anything, because the progress dialog is modal. As if a a stupid, inaccurate percentage reading is the most important information you could possibly want from the program.

Regarding my post on getting the scroll buttons working on my Logitech Marble Mouse, Jordi pointed out that the configuration can be improved even further. After trying out his configuration, I decided to RTFM and see if I could make it even better.

It turns out that the mouse options are all documented in the X11 man pages. On mystem, the mouse manual page is in /usr/X11/man/man4/mouse.4.gz. From reading this, it appears that there's no way to do what I really want (hold down the button and the window keeps scrolling), but I can make another small improvement on Jordi's configuration.

My small improvement is to add horizantal scrolling to the wheel emulation. See, with Jordi's configuration, holding button 4 while moving the mouse up and down will scroll the current window vertically. However, if the window also has a horizantal scroll bar, nothing will happen. That's because of the default values for XAxisMapping and YAxisMapping. The mapping for the Y-axis is to buttons 4 and 5, which is what we want, but the Y-axis mapping is off by default.

So, to change this, I added the following to my /etc/X11/xorg.conf file. Note that I changed the wheel emulation button and inertia to match my personal preference.
Option "EmulateWheel" "1"
Option "EmulateWheelButton" "5"
Option "EmulateWheelInertia" "10"
Option "XAxisMapping" "6 7"
Option "YAxisMapping" "4 5"
Now, if I have a window with horizantal and vertical scroll bars, I hold button 5 and move the mouse to get a Windows "auto-scroll" type behavior, where the window scrolls on both axes as the mouse moves. Things are just getting better all the time! At this rate, the pain of being a Linux user will be completely gone in no time!