I decided to finally give KDE 4.1 a try via the new Kubuntu 8.10. Unfortunately, it was a frustrating experience. In a matter of minutes I encountered numerous serious bugs, many of which were related to my multi-monitor setup. It appears that bug reports already exist for the issues I had (see below), so hopefully they'll be fixed soon.

My first issue: upon docking, I hit my Thinkpad's blue "ThinkVantage" button which I have set to run a really handy script to take care of everything I want done. It sets up the wired network, mounts my file server, and runs xrandr to get the multiple desktops set up. In KDE 4.1, kwin crashed. It does this reliably each and every time. I'm not sure how common this problem is, because it seems like one of those issues that if every multi-monitor user (via xrandr) encountered it, the developers would themselves be annoyed enough to fix it.

My workaround was pretty simple, and gave me some hope that I could work through the problems. I simply had my dock script kill plasma (the application which sets up the desktop taskbar, etc), enable the second monitor, and start plasma again. No more crashes; so far so good.

A few more minutes and the annoyances mounted. Plasma wouldn't draw the desktop background or have any "widgets" on my laptop monitor when in dual monitor mode. One annoying workaround here is to create a panel on the new monitor and restart KDE. Then on single-monitor mode, you have two panels.

This is amongst numerous crashes. Plasma would crash if I turned off the setting for view hidden files while searching for a background wallpaper. Kontact would crash fairly frequently, but I didn't spend much time seeing what was reproducible. One of my most-used features in 3.5 was in-line editing of the TODO list. This doesn't appear to be implemented in the KDE4 version of KDE-PIM.

I should mention the good: the desktop was beautiful, most of the applications I wanted have been ported (amarok will be soon). The direction of KDE looks very good; the default desktop setup is far superior in appearance and functionality to KDE 3.5. Desktop effects actually work, and aren't horribly slow. If I didn't value snappiness so much, I would actually use them.

In the end, though, the crashes and the broken multiple-desktop behavior was too much. Rather than spend more time trying to find workarounds, I looked some of the more annoying behavior to ensure that a bug report was already filed; then I installed KDE 3.5 and Kubuntu 8.04 again. KDE 4.1 has definite promise, but some things (like scrolling and text entry) were noticeably worse than 3.5. The frequent crashes of kontact, kwin, and plasma were really the deciding factor. I hate to say it (as a huge KDE fan), but 4.1 still feels like beta software, at least in my multi-monitor laptop config.

I'll give it another try in 6 months with Kubuntu 9.04 and KDE 4.2.

Having used TaxCut for the last few years, I've been pretty happy with it overall. This year, however, I ran into a really annoying bug with the Mac version. I bought the Federal + State version retail and tried to install my state, but TaxCut wanted to charge me $29.95. It seems that the Mac version is blissfully unaware that I paid for the combined version, even though the box, CD, and CD cover are all clearly marked as including the state (not to mention the higher retail price).

Apparently I'm not the only one, as a few quick Google searches turned up people with the same problem. Rather than waiting on hold to try to explain this over the phone, I did the TaxCut online chat. The first guy I got seemed to have trouble understanding my problem, but after the chat disconnected (it was an auto-refreshing web page that started giving me a 404 not found error), I connected to a different guy. It took maybe 10 minutes of waiting for a representative but only about 2 minutes for him to issue me a download for my state.

Nonetheless, I'm not impressed by TaxCut's QA this year. One would think they'd have patched this issue, but the very first thing I always do upon installing TaxCut is to update the software. My other thought was that maybe it was getting confused by TaxCut 2006's "Library" (settings) files, but moving those out of the way didn't change anything. As far as I know, there is no workaround short of contacting tech support. Hopefully they'll patch things soon, because I imagine the do-it-yourself tax preparers really get into gear in March.

Getting Windows out of the way

In October I ordered a shiny (literally) new HP dv2000t laptop to replace a dying 5 year-old Acer. Having never owned a new laptop before, I found it interesting that the internet is not absolutely full of other people's accounts of Linux on this model. I thought I would provide my experience installing Fedora Core 6. I initially installed FC5 on this system, but a few weeks later reinstalled with FC6. I may update and expand this entry in the future.

The first task with this system was to ensure that I could return it to the factory state if necessary. To that end, I burned the recovery CDs right away. The only problem is that I didn't expect 15 recovery CDs. Seriously, what is contained on a 10GB recovery partition? So that process took about 2 hours while I worked on other things.

The next step was to boot the FC6 installer and partition the disk. I did this with fdisk, though other utilities would work fine. The real issue is to ensure that an NTFS partition remains as the first partition on the disk, and that the recovery partition (3) and DVD-playing partitions (4) remain intact. I don't think the graphical partitioner can handle this (it kept making / the first partition), but I'm not sure about the text-based utility.

With a smaller Windows partition set up, I hit F11 on boot to initiate a recovery of the system. Fortunately, rather than repartition the drive back to factory settings, it just takes the first NTFS partition and installs Windows onto it. This takes 20-30 minutes.

Then I went through the fun Windows setup process for the second time (I had to do it before to be able to burn the recovery CDs). The HP utilities install themselves and the system has to go through a few reboots. Then I moved on to the standard process of removing unneeded software (MS Office trial, Quicken, Norton trial, etc). Following that, I set up the network and updated Windows itself (behind a firewall, of course). The computer shipped with service pack 2, so the updates weren't too bad.

With Windows safely into its partition and out of the way, I moved on to installing Linux. My favored method is often to use the first CD of the distribution and perform an FTP install (keeps the CD burning down). Here, however, I kept running into a snag. I would get all the way through the setup process and have it ready to start installing packages, and it would stall at "Starting install process. This may take several minutes", or something to that effect. I could see some network activity, so after a few retries I let it sit there for probably over 20 minutes. Still nothing. It wasn't hung (I could get to the other consoles), but it wouldn't get anywhere. So I burned the other 4 CDs and proceeded with a normal CD install, which worked fine.

Here are some of this notebook-specific hardware issues in Linux I encountered.

Wireless

I choose the Intel Pro Wireless upgrade when I customized my system, and thus needed to use Intel's driver for this chipset. Unfortunately, the packages are not part of Fedora Extras, so one must use a repository like atrpm or install from source. I find it easiest to accomplish this with apt, so that only the packages of my choosing are taken from atrpms. Of course, this requires an ethernet connection.

yum update to get the new repository info and do security updates

Install apt (yum install apt)
Add rpm http://dl.atrpms.net fc6-i386/atrpms stable to /etc/apt/sources.list
add:

Package: *
Pin: release o=atrpms
Pin-Priority: 1

This keeps atrpm from replacing any packages I don't explicitly want it to.

apt-get install ipw3945-kmdl-[current version of my kernel]
apt-get install ipw3945
depmod -a
add alias eth1 ipw3945 to /etc/modprobe.conf

The daemon /sbin/ipw3945d needs to be run (after the kernel module is loaded). Things like the physical wireless switch work fine (the switch also disables bluetooth).

Touchpad
The touchpad works fine in Linux (on the default Windows install, I couldn't get tapping to click, but it worked upon reinstall). To use all the fancy features of the touchpad, add

Option "ShmConfig"

to the input section of /etc/Xorg.conf, and install ksynaptics.

Suspend
Suspend seems to work, with around 10s to fully restore. There may be a problem restoring wireless after suspend, but I haven't tested it in a while.

Multimedia buttons
I've enabled most of these using the exact same file from my desktop for my Logitech keyboard. It's available .Xmodmap.

Sound
My last unresolved issue. Newer ALSA drivers will make the speakers work, and the headphones work as well. The issue is that the speakers will not mute with the headphones plugged in. A developer has documentation from the vendor and is working on a fix.

Fedora Core 6 issues
Clicking on the Fedora Extras repository during install will crash the installer (known bug). apt has a bug which causes its database to get corrupted. The issue is not yet fully resolved.

Kubuntu 6.10 on the HP dv2000t

A recent upgrade caused yum to stall in the middle of upgrading about 100 packages. It installed almost all of the packages, but failed to "clean up" after them. What this meant was a huge set of duplicate packages in my RPM setup. Unfortunately, this proved very hard to clean up. I decided that it would be faster (and have a guaranteed chance of getting things working) if I reinstalled.

My anger at yum made me appreciate apt - which can work under Red Hat, but has recently had some issues (and never seems to work as well as on Debian-based systems). So I decided to give Kubuntu another shot. The last time I loaded up the live CD, I recognized that my kpdf issue persisted. Still, I figured I'd plow ahead and see how things looked.

It turns out that Kubuntu goes on this laptop much more easily than FC6. Load up the live CD, click "install", a few clicks on the installer (no package selection - that comes post-install). It was nice only needing the one CD, and knowing that the entire distribution is centered around KDE (unlike FC6).

The biggest hassle on FC6, getting wireless working, was no hassle at all on Kubuntu. The ipw3945 packages were automatically installed, enabled, and the daemon running. Video was flawless (detecting the card and the correct resolution for the wide screen). Sound worked, in that the ALSA driver was new enough to get audio through the speakers, but the headphone mute issue is still unresolved.

Kubuntu does all configuration through a modified version of the KDE control center. This centralization is a nice change from Fedora. I'm not sure the networking configuration works as well (but I tend to do things from the command line anyway). Installing kwlan for WPA encryption via GUI doesn't seem to work out of the box, but my command line approach still worked.

Kubuntu 6.10 issues

Having integrated WPA encryption support with the network control panel would be a welcome addition. My test of hibernation was quite slow, and KDE/X didn't restore properly (blank screen). I haven't been able to get a good signal coming out of the VGA port for use on projectors (the sync seems to be weird) - it works in Windows, so I think it's a combination of driver/X setup issue (cloning/multiple monitors can be done in a variety of ways).

A little backstory: My laptop's hardware is starting to die; the remaining USB port is falling off, causing problems for any connected device and the interaction with the system. The symptoms here (when a mouse was installed) seem to include my keyboard functioning erratically. And either a hardware issue or what's widely known to be a poor video driver ("i810") or perhaps other software caused a brief (1/4 sec) blanking of my screen today.

To rule out the possibility that my computer was hacked (and that whatever software was installed was causing glitches), I ran some md5sum comparisons between binaries on my laptop and those on my desktop. Both run Fedora Core 4 with similar revisions of software (and I checked the RPM version of the files I was comparing to ensure I was comparing apples to apples).

The first one (perhaps it was bash) didn't match. Most of /bin didn't match. This really isn't the behavior of a rootkit; those only tend to replace the files they need to hide themselves. Still, I quickly rebooted with a CD of Knoppix and ran chkrootkit and did some manual searches.

Then I considered that my CDROM on my laptop has been less than reliable. I try to avoid using it whenever possible. I didn't remember at the time whether I tried to do a full install from CD, so my thought moved to read errors from the install. I did a hexdump of two versions of vi and did a diff to compare the results. The changes didn't seem random, but it didn't rule a media problem out.

This whole business concerned me because I was used to comparing md5sums on Debian systems. It turns out that Red Hat (and thus Fedora) have implemented a system called prelink, something with which I was only vaguely familiar before. Prelink modifies binaries in an attempt to speed them up (by, well, pre-linking them with the libraries they call). This changes their md5sum, but in my case, the filesize remained identical.

So the tip here is this: to compare md5sums between systems that use prelink, first run "/usr/sbin/prelink --undo" on the files.

I've learned a few things while setting up dual monitors at home under Linux.

• Mixing ATI and NVIDIA (one for each monitor) leads to serious problems with opengl (crashes X, rather than just having opengl apps work on one monitor). I'm not sure if there's a workaround for this or not.
• ATI open source drivers on a Radeon 9100 PCI give visual artifacts in things like titlebars in KDE (they appear in screenshots as well).
• ATI proprietary drivers have relatively lousy 2D performance (at least compared to my similarly-powered GF4MX). I don't think this difference can be explained by AGP vs. PCI. Which leads to:
• NVIDIA Quadros with dual dvi can be had very reasonably on eBay.
• Kile, my LaTeX editor of choice, works really nicely with dual monitors. A few simple changes and a build takes you to the correct part of the document, refreshing a window on the other monitor: Settings->Configure Kile->Build->Select a configuration: "Modern". Select "ForwardDVI" Select a configuration: "KDVI", and under "Advanced" select "Run outside of Kile". Finally, under QuickBuild, make sure the order is "Latex" "ForwardDVI". Then load up kdvi, Settings->Configure KDVI->DVI specials->Editor:Kile. The last option allows you to middle-click in a document and kile will move to the correct position in the document.
• Finally, Stewart Calculus books make excellent monitor stands.

After spending a day or two with acceleration basically disabled on my new wireless mouse (the trials and tribulations of which were chronicled in this posting), I realized how useful acceleration really is. Thus, I'm back to using my old mouse with the new keyboard. I really hope to see the xorg people address this soon.

Tonight was one of those Linux experiences where one realizes that Linux still has some work to do in the hardware compatibility department. I switched from an aging Logitech wireless keyboard and mouse to its updated version. The new version offered me a number of improvements. The biggest two were that the mouse is now optical and the keyboard is not worn and glossy (I am rather picky about how clean my keyboard feels). In addition, I like the USB interface (though PS/2 is also available, which I had not realized) and the new black coloring.

Initially, things seemed to work great. The keyboard has a different feel to it, but it's quieter and nicely responsive. The mouse, however, moved far too fast. No problem, I went to the KDE Control Panel and set the mouse acceleration to the lowest it allows - 1x. Still too fast. I figure that maybe I could change drivers or set the resolution of the mouse. Somewhere along the line I decided to try it on my Mac Mini, and sure enough, it was dramatically faster than the cheap Logitech wired USB mouse I have attached.

I believe this mouse, the Logitech Cordless MouseMan Optical, has a native resolution of 800dpi. This greatly exceeds most mice, so it makes sense that a small movement of this mouse might translate to a huge movement on the screen, unless this difference is taken into account. So I set about trying to figure out the best way to do that. Setting the resolution in xorg.conf? Sure, that works for some mice, but the mice must be PS/2, and it still only works for certain models. It doesn't appear to work for my mouse.

A little more Google searching (not a good sign for Linux usability) and remembering a similar case a while back, I realized that KDE's GUI is simply limited - you can really set the acceleration to less than 1x with the command "xset", and the KDE program that sets it can also take a decimal value for the acceleration in the config file (~/.kde/share/config/kcminputrc). So while I was happy that I didn't have to script up xset to load after logging in, I did vote for the relevant bug. I ended up setting the acceleration to 0.75, which seems reasonable. I'm playing with various acceleration threshold settings to get something that feels natural (right now 8 seems best). Comparing it to the Mac is proving difficult, since I think Mac OS X uses a much different-feeling algorithm for mouse acceleration. I should note that the discrete settings Mac OS X had for pointer acceleration yielded no decent results for this keyboard/mouse, so it's not as if it's a perfect system by any means.

As a side note, I also tried to get resolution changed on the mouse by some additional software, but I don't think the cordless mice can be configured as such. It appears that the KDE GUI also supports setting these options, but all options are grayed out because apparently Fedora doesn't set permissions of the USB devices appropriately.

I figured while I was spending this time trying to get my mouse working just so, I really ought to get those multimedia keys at the top working. After running into this resource, getting those keys to show up as the correct codes was straightforward. For my model (Y-RJ7) keyboard, my ~/.Xmodmap looks like the following:

keycode 162 = XF86AudioPlay
keycode 164 = XF86AudioStop
keycode 144 = XF86AudioPrev
keycode 153 = XF86AudioNext
keycode 174 = XF86AudioLowerVolume
keycode 176 = XF86AudioRaiseVolume
keycode 160 = XF86AudioMute

That only sets the multimedia keys, but I don't have use for the others at this point. It appears that kmix takes the volume events and applies them to overall system sound, and I used amarok's global shortcuts GUI to set the play/stop/back/forward buttons. My only complaint is that play does not function as pause as well; I'm not sure if there's a way to get Amarok to behave that way (perhaps a wishlist bug is in order).

After all this, I'm relatively pleased with the results. Still, it's way too much work. It would be great if xorg recognized more keyboards and set their multimedia keys correctly without user input (it had some of my buttons mapped, but most of them incorrect). KDE should be able to set pointer acceleration levels less than 1 through the GUI. Still, pretty much all mice I've used in practice work perfectly in Linux these days, now the trouble comes in enabling huge 8-button mice with high-end sensitivity.