My opinion is that Lucid improves on Karmic in almost every way. That’s not saying much, since the KDE 4 upgrade has been so painful. We’re finally back to KDE 3.5 functionality, and speed is improving with each release. On the other hand, there are a lot of new features in the OS since Hardy – grub2, ext4, ecryptfs, upstart, kernel mode setting, compositing window management, Strigi indexing and Nepomuk semantic desktop. Some of these have dramatically improved performance, while others have increased system requirements just to add eye candy. It’s hard to evaluate KDE on its own, so I’m not going to focus on that.

I backed up my entire drive to an external USB drive formatted for ext3 using rsync. I then booted from the Kubuntu 10.04 AMD64 Desktop CD, and followed the default install options until the disk partitioning step. I always install with separate /, /home, and swap partitions (this normally makes upgrades easier, unless you are reformatting as I did here). I used ext4 for / and /home, and chose to encrypt my home directory. I then followed the rest of the steps and rebooted at the end.

Following the reboot, I used rsync to restore my lost files and most of my dotfiles – .mozilla, .gnome, .gconf, .Virtualbox, and the like. However, I did not restore .kde. Instead I manually copied only some configs, for KGPG, Akregator, and Kopete. The rest of my KDE apps I reconfigured from scratch. I did this because we use Kolab at work, which integrates with Kontact but can be fussy with local contacts files. As of Lucid, Kontact uses Akonadi to manage contacts. I expected trouble, and found it. More on that later.

Finally, since I have an encrypted home directory, I also encrypted swap and created a tmpfs on /tmp. I followed the steps in my guide, and rebooted with no problems.

What’s better:

The ext4 filesystem is noticeably faster. This is the reason I reformatted instead of upgrading. I used ext3 under Karmic, and really wanted to see if what I’d been hearing about the speedy new filesystem is true. It is. It’s faster for booting and it’s faster for reading large data. My Virtualbox virtual machines load in almost half the time, even compared to the same Virtualbox 3.2.6 release on Karmic. I suppose there could be other differences contributing to this but it really stands out. I haven’t run an fsck yet but others report that it is much faster as well.

ext4 has definitely improved performance of copying data inside my encrypted home directory. I barely notice the performance hit from using ecryptfs now. The only time I do is when using rsync to compare large directories (like when my backup process examines my mail archive).

There is a new touchpad control in KDE Control Center. This enables gestures, including two-finger scrolling (but not pinch-to-zoom, which I hope is forthcoming), and different actions for tapping in corners, multi-finger tapping, and so on. Still missing is tap suppression (accidentally tapping while typing), so I still use syndaemon. Create ~/.kde/Autostart/syndaemon.sh, make it executable, and insert:

#!/bin/sh
# Disable touchpad while typing to prevent accidental tapping.
/usr/bin/syndaemon -d -t -i 1

The device notifier plasmoid now has multiple actions when opening attached storage devices, and can be configured to automatically mount drives. This is a vast improvement.

The system tray plasmoid now obeys my auto-hide preferences. Under Jaunty and Karmic, some applications had overriding preferences that caused them to always be hidden or visible. For instance, it was impossible to make KGPG always visible. I frequently use KGPG, so this caused me to almost always have the system tray expanded to show all applications.

Firefox/KDE integration works very well. Open/save file dialogs use KDE, and menus and icons use KDE defaults. The printer dialog is still the native Firefox one.

virt-manager is vastly improved. The GUI is more responsive when connecting, is prettier, and has graphs for CPU, disk, and network I/O.

ClusterSSH works with KWin again. Since 8.10, ClustterSSH has been nearly broken in KDE. First, simply starting it caused copy (to clipboard or selection) to stop working in most QT/KDE apps. Second, the ClusterSSH master window would grab focus and prevent you from giving focus to any of its children xterms. This made it very hard to run commands on just one host without running it on all. I gave up and used various other techniques for managing my servers. But nothing beats ClusterSSH for managing 2-20 servers at once, and I’ve sorely missed it. Welcome back, old friend!

What needed tweaking:

The Oxygen window decoration theme still doesn’t colourise the active window. Open System Settings, go to “Appearance”, then the “Windows” side bar. Under the “Window Decoration” tab, choose “Oxygen”. Under the “Decoration Options” area, choose the “Fine Tuning” sub-tab. Check “Outline active window title”.

Hotkeys in Kmenu are ignored. I use a few quick-launch shortcuts, such as “Win+T” to start a terminal. You can set these when editing the K menu, but they are ignored by default. Open System Settings, select “Input Actions”, and then check “KMenuEdit”.

VirtualBox and virt-manager don’t play well together. I don’t use Xen or KVM on my desktop, but I do manage several KVM-based virtual machine servers. Thanks to the new “install recommends” preference in the package manager, simply installing virt-manager also installs libvirt-bin. This loads the kvm-intel or kvm-amd modules on boot, which then prevents VirtualBox from starting virtual machines, with the error “VirtualBox can’t operate in VMX root mode. Please disable the KVM kernel extension, recompile your kernel and reboot (VERR_VMX_IN_VMX_ROOT_MODE).”

I suppose this is really a problem with the “install recommends” behaviour. I’ve complained about that elsewhere, but I always repeat a good gripe when the opportunity presents.

The solution is to edit /etc/default/libvirt-bin and disable libvirtd:

start_libvirtd="no"

And for good measure, blacklist the modules. Create /etc/modprobe.d/local.conf and insert:

blacklist kvm-intel
blacklist kvm-amd

What still needs work:

Akonadi doesn’t start before Kontact tries to access it. This solution (autostarting “akonadictl start” at login) worked for me, although I (painfully) developed it independently. If only I had used Google.

openvpn with knetworkmanager still doesn’t work. I still prefer Gnome’s network manager applet, which works just fine with Kubuntu. Kill knetworkmanager, and start nm-applet. Next time you login, KDE will tell you that another network manager is running, and ask you if you still want to use Knetworkmanager. Say no. Also, OpenVPN support is more reliable under Lucid. Using Gnome network manager with Kubuntu Karmic, the OpenVPN service would periodically fail to start. Editing VPN preferences and then hitting OK sometimes resolved it, but at other times it was an annoying and random dance to make it work. This seems to be resolved under Lucid.

OpenOffice/KDE integration is improved since Karmic, but still has drawing bugs. In particular, the zoom slider in the lower right often disappears. It’s still there, and clicking in the area makes it reappear and zooms. I prefer the “100% / 75% / …” pull-down of the stock OpenOffice theme, however. This is a vast improvement over the Karmic integration, where simply dragging a spreadsheet tab in Calc crashed OpenOffice, but I’d like to see more development here.

Otherwise, my comments regarding Karmic still hold. Google Earth and Kwin play nicely, qtcurve (KDE/GTK integration) is awesome and no longer has the font bug, and Plasma and Kwin are faster and more stable. Lucid is no great leap forward and Kubuntu is still not an innovator among KDE distributions like Ubuntu is to Gnome. But it is an incremental improvement worth using if you prefer KDE.

I have had a Lucid repository since upgrading my media PC and servers. It now includes dfreer’s znes32 for AMD64 (still working on Lucid) and kregexpeditor (you can have it when you pry it from my cold, dead hands).

The bug appears as:

1. Start virt-manager.
2. Connect to a KVM host server using connection “Remote tunnel over SSH” with hypervisor “QEMU/KVM”.
3. Double-click on a VM to open a VNC connection to console.
4. The error message “Error bringing up domain details: invalid argument in virDomainGetXMLDesc” appears, and no VNC session opens.

The problem is with the latest version of virt-manager, 0.7.0. To work around it I’ve repackaged virt-manager 0.6.1 from jaunty with the fake version “0.7.1~really0.6.1-1ubuntu4″. Packages for i386 and amd64 are now in my APT repository.

Also, KPackageKit ignores my “dpkg --set-selections“, forcing me to do this. Thanks, KPackageKit, for ignoring the standard! Otherwise I could install the jaunty package and mark it on hold.

The hardy version of kregexpeditor still works on karmic, and I’ve used pbuilder to port the jaunty package of grip to karmic. Both are now in the repo.

Nothing in this process is specific to KDE, so Ubuntu or Xubuntu users can use this as well. Steps:

1. Choose a strong password
2. Create an encrypted ~/Private directory
3. Copy home directory files into ~/Private
4. Move ~/Private to $HOME
5. Encrypt swap
6. Make /tmp a tmpfs

Caveat emptor: If you encrypt your home directory, then later forget your password and fail to write down the mount passphrase, you are screwed. There is no practical chance that you will recover your files. As always, make a backup.

Step 1: Choose a strong password

If you aren’t already doing this, you’re not likely to use this guide. Security is a mindset, not a tool. Get used to keeping strong passwords in your head. Ubuntu makes using encryption really easy, but it is only as effective as the strength of the password you choose.

My recommendation is to use pwgen with -B or even -By:

pwgen -By

Ohz:ah7s aiT7gex% AhNae)Z3 Ohph*i9e va9eZuo[ Mei7ieZ~ Ohb7Za]o Piek+ai3
fa!m3Sho ua~ch7Wa tom?oh9U do{i4Aep tuF4oof} Na#a4eiH epe\G3oh aR3ahp^i
...
Aip$aim9 Eph%a3pu gae7aY`a Ie^cah4t sha+uY3v ove3aeZ= Wie4yei| Oc\aeb9e

The -B option tends to generate passwords that are balanced between hands and at least partly pronouncible, so this isn’t as hard as you think. If you do use -y (special characters like +), consider the keyboards you might have to use. If you use both British and American keyboards, don’t use £, @, “, `, #, ~, \, or |, as all of these are in different locations.

Pick one and and make a mnemonic to help you remember it. Write it on a piece of paper, put it in your wallet, and burn it once you memorise it. Write it on your belly with a sharpie; whatever it takes. Change your password now:

passwd

Your password will later become the passphrase that protects the encryption keys to your home directory. ecryptfs includes excellent PAM support, so if you change your password later it will update the key too.

Step 2: Create an encrypted ~/Private directory

Since I upgraded from an earlier install without an encrypted home or ~/Private directory, I had to create one. If you are about to install 9.10 from a CD, the installer has an option to encrypt your home directory. Just use that. Or create a new user:

adduser --encrypt-home username

If you’ve already got an encrypted home, congratulations! The hardest part is done. Skip to step 5.

If not, let’s get started. Linux Mag’s Dustin Kirkland has written an excellent guide to this process. Much of my process is based on his, but I include a few corrections. For most of this you can remain logged in to your Desktop, but the process is simpler from the Linux console. The initial copy process will make you want to get up and do something else while it finishes anyway.

Logout from the Desktop, which should return you to the login screen. If your login screen is configured to log you in automatically, cancel it. Then press Ctrl+Alt+F1 to go to the first Linux virtual console.

Login at the prompt, and create an encrypted $HOME/Private directory:

ecryptfs-setup-private

Enter your login passphrase:
Enter your mount passphrase [leave blank to generate one]:

At the first prompt enter your user password. At the second, press Enter. Now record the mount passphrase which was just generated:

ecryptfs-unwrap-passphrase $HOME/.ecryptfs/wrapped-passphrase

Print it out and put it with your birth certificate in your fire-proof document safe. You do have one, right? If something goes wrong you will need this later.

Log out, and log in again.

Step 3: Copy home directory files into ~/Private

Make sure you have at least 50% free on /home, or this may fail.

rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

If you don’t have 50% free, first move some files from $HOME to $HOME/Private, and rsync the rest.

cd
mv -v Videos Music Pictures DirectoryOfBigFiles $HOME/Private/
rsync -aP --exclude=.Private --exclude=Private --exclude=.ecryptfs $HOME/ $HOME/Private/

This will take a long time to complete. Every file is being encrypted as it is copied or moved. If you have a lot of files and an under-powered CPU (such as on a netbook), it will take even longer. I moved 178 GB of data on my Dell Vostro 1500 (Intel Core2 Duo 2 GHz, 4GB RAM) in about 5 hours. Get a coffee, walk the plants, shave the cat, come back later.

When done, logout to sync any remaining changes to disk.

Step 4: Move ~/Private to $HOME

Now we need to do some things with sudo. Still on console, login again. Unmount $HOME/Private:

ecryptfs-umount-private
cd /
sudo mkdir -p /home/.ecryptfs/$USER
sudo chown $USER:$USER /home/.ecryptfs/$USER
sudo mv $HOME/.ecryptfs /home/.ecryptfs/$USER/

Create a new home and populate it with the ecryptfs files:

sudo mkdir -p -m 700 /home/$USER.new
sudo chown $USER:$USER /home/$USER.new
sudo mv $HOME/.Private /home/.ecryptfs/$USER/
sudo ln -s /home/.ecryptfs/$USER/.ecryptfs /home/$USER.new/.ecryptfs
sudo ln -s /home/.ecryptfs/$USER/.Private /home/$USER.new/.Private
sudo ln -s /usr/share/ecryptfs-utils/ecryptfs-mount-private.txt /home/$USER.new/README.txt


Switch to the new home, tell ecryptfs that we’ll mount it at login, and make it read-only (until it is mounted):

sudo mv $HOME $HOME.old
sudo mv $HOME.new $HOME
echo $HOME > $HOME/.ecryptfs/Private.mnt
sudo chmod 500 $HOME

Now for the moment of truth. Still on console, logout, and login again. Your home directory should mount:

mount | grep ecryptfs

/home/username/.Private on /home/username type ecryptfs (ecryptfs_sig=9cec4d81c9bcb6e0,ecryptfs_fnek_sig=c735e6facb299611,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

Create some convenient links:

ln -s /home/.ecryptfs/$USER/.ecryptfs $HOME/.ecryptfs
ln -s /home/.ecryptfs/$USER/.Private $HOME/.Private

Once you verify that all your user data is there, securely wipe any files that have important data, and then remove the old home.

cd $HOME.old
find .kde .gnupg .ssh PathsToDirectoriesOfImportantFiles -print -exec shred -u {} \;
rm -rf $HOME.old

Step 5: Encrypt swap

Your home directory isn’t the only place your private data may be written to disk. When your computer doesn’t have enough RAM for everything it wants to have open, it swaps. This means some RAM is written to disk to be read back later. Thus, swap can contain anything you have ever have open. Swap does not need normally to survive reboots *, so we’ll encrypt this with a random key every time we boot up.

* The one exception to this is hibernate mode (suspend to disk). If you want to use hibernate, don’t encrypt swap, or use a (less secure) static key. Encrypting swap has no impact on sleep mode (suspend to RAM). I never use hibernate.

Thankfully, this is a very easy process with Ubuntu. Despite the misleading name, this uses cryptsetup, not ecryptfs:

sudo apt-get install cryptsetup
sudo ecryptfs-setup-swap

Step 6: Make /tmp a tmpfs

The last place your private data is commonly written is the temp directory, /tmp. The contents of this directory don’t need to survive reboot either, and are commonly cleared at bootup. It is possible to encrypt it using cryptsetup just as with swap, but we don’t need to. Instead we’ll make this a tmpfs. This means /tmp will be an auto-resizing virtual RAM disk. By default it is allowed to grow to up to 50% of RAM.

Don’t worry about this consuming your RAM. If the contents of RAM is swapped to disk, static content like /tmp will be the first to go. And it isn’t much data anyway; my /tmp rarely grows beyond 200 MB. Plus, using a tmpfs will save power when in battery mode.

Add one line to your /etc/fstab:

echo "tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0" >> /etc/fstab

If you are logged in to the desktop, log out completely. Then login on console one last time, and run:

sudo rm -rf /tmp/*
reboot

That’s it! You are now running a cryptographically secure laptop, protected against all but the rubber-hose attack.

I read an article in the Dec 2009 issue of Linux Magazine, one of several Linux-focused magazines we get at the office. I’d like to link directly to it, but it the magazine’s own website doesn’t offer the article or even a reliable permanent link to the issue number. Hint: hey guys, sort that out.

The article was about configuring ACPI hotkeys to support your specific laptop. IE, the buttons for “sleep”, “brightness up”, etc. For most laptops this already works on Ubuntu. On my Dell Vostro 1500, every button except for “sleep” worked right after install. This is Linux, so there is always some way to fix that.

Unfortunately, ACPI cannot even detect my keypress. The instructions in the article suggest starting acpid with -d for debug mode, which will print any keypresses that reach it. Pressing Fn+F1, the sleep button, prints nothing. So we’re going to use KDE’s hotkey support instead. Gnome users can use a similar method; only the menu instructions differ.

First, create a script somewhere your user can run. I have $HOME/bin in my $PATH, so I created a file there:

touch ~/bin/sleep-kde-screen
chmod 755 ~/bin/sleep-kde-screen

Then I edited it to contain the following:

#!/bin/sh
qdbus org.freedesktop.ScreenSaver /ScreenSaver Lock
sudo /usr/sbin/pm-suspend

This calls DBUS to lock the screensaver, then asks power-manager to suspend. This way you will be prompted for your password when you resume from suspend. If you prefer to hibernate, change “pm-suspend” to “pm-hibernate”.

Second, you need to tell sudo to allow your user to run this /usr/bin/pm-suspend without prompting for a password. Run sudo visudo to edit /etc/sudoers, and add this line at the bottom:

%admin ALL=NOPASSWD: /usr/sbin/pm-suspend

Finally, add this script to your K menu with a hotkey. Right-click on the K menu and select “Menu Editor”. Add a new item to the “System” menu, give it a name (I like “Sleep!” *), and tell it to call sleep-kde-screen (wherever you’ve put it). On the Advanced tab, select “Current shortcut key” and press the sleep button. Now save and close the menu editor.

* I imagine saying “Sleeeeeep!” like a hypnotist bad guy from an old movie on MST3K.

Press the sleep button, and you’ll suspend!

At the time of this writing, my host OS is Ubuntu 9.10 Karmic 64-bit (actually an Intel Core 2 Duo 2.0 MHZ), with VirtualBox 3.0.10 PUEL edition. I run several 32-bit clients: Ubuntu 6.06 LTS (just in case, we still encounter them at some customer sites), Ubuntu 8.04 LTS, Xubuntu 9.10, and Windows XP SP3 (my actual legal copy that came with the laptop).

I left the Windows XP VM running but idle, and noticed that my keyboard and mouse occasionally skipped, and my CPU worked harder than expected. So I ran a few tests with top in batch mode:

top -b -d 10 -n 10

I then redirected that to a file, waited the 10*10 seconds to finish, and grepped the results. This is with VT-x enabled, and shows only the relevant VM (not the GUI or other VMs):

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30763 tyler     20   0 1020m 609m  73m S   10 15.4   0:28.05 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    9 15.4   0:28.98 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    5 15.4   0:29.52 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:30.10 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   20 15.4   0:32.06 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:32.63 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   10 15.4   0:33.60 VirtualBox
30763 tyler     20   0 1020m 609m  73m S   16 15.4   0:35.18 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    6 15.4   0:35.78 VirtualBox
30763 tyler     20   0 1020m 609m  73m S    4 15.4   0:36.20 VirtualBox

Here is the same data, after rebooting the guest and disabling VT-x:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30217 tyler     20   0 1027m 625m  73m S    4 15.8   2:21.32 VirtualBox
30217 tyler     20   0 1027m 625m  73m R    5 15.8   2:21.79 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    1 15.8   2:21.89 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   11 15.8   2:23.04 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   11 15.8   2:24.17 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    5 15.8   2:24.69 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    2 15.8   2:24.94 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   10 15.8   2:25.94 VirtualBox
30217 tyler     20   0 1027m 625m  73m S    5 15.8   2:26.44 VirtualBox
30217 tyler     20   0 1027m 625m  73m S   13 15.8   2:27.72 VirtualBox

Two conclusions:

1. Software virtualisation uses more RAM. The guest is configured with 1 GB of RAM. With VT-x, this uses 1020 M. Without, it uses 1027 M. Whether that represents a memory overhead of 7M per VM or 0.7% of total RAM per VM, I don’t care. It’s small enough.
2. Software virtualisation, under these conditions, is more efficient than using VT-x. The average CPU usage with VT-x was 9.2%. Without, it was 6.7%.

Engineering and science students will recall that all experimenters must note potential flaws and sources of error.

1. This tests only a guest which is completely idle. However, my general impression when doing actual work in the guest VM supports the idle observation.
2. top isn’t the best measure of performance, but it is indicative.
3. I only tested a 64-bit Intel host with a 32-bit Windows guest. As always, more data is better.

I also note that my keyboard and mouse no longer skip when the guest OS is busy. Clearly something is up with VT-x and Ubuntu 9.10 hosts. The right thing to do is to perform more tests confirm the initial observations, but I’m not going to spend any more time on this. Software virtualisation, so far, has been plenty fast for me. I’ll just disable VT-x on all guests, and test again after the next upgrade for VirtualBox or the host kernel.

Jaunty has been my Windows Vista. I wish I had never upgraded, and waited instead for Karmic. For anyone using Intel video (I use a Dell Vostro 1500 with an onboard Intel GM965/GL960), Jaunty and KDE4 was a terrible experience. Compared to Hardy and KDE3, video performance was dramatically worse. When playing videos frames would drop, 3D acceleration was slower, everything showed more tearing effects, and most KDE4 apps showed graphics corruption in various rarely-updated areas such as the icon toolbar in Kontact.

I had already discovered the video issues when I wrote my last upgrade post, but hadn’t yet realised the extend of the wireless issues. I have two cards in my laptop:

tyler@baal:~$ lspci | grep -i network
0c:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG [Golan] Network Connection (rev 02)
0d:00.0 Ethernet controller: Atheros Communications Inc. AR5001 Wireless Network Adapter (rev 01)

Under Jaunty, the Intel card caused kernel panics on shutdown. So I blacklisted the driver and used the Atheros card, only to discover problems with both the ath_pci and ath5k drivers. The former doesn’t work with network manager, and with the latter the card would sometimes fail in a state requiring full hardware reset, meaning powering the laptop off and on again. This would happen on bootup too, causing me to sometimes reboot several times to make wireless work. It is not good to begin the workday filled with frustration and rage.

I did my best to mitigate the issues under Jaunty, including using the latest KDE backports from the Kubuntu PPA. But the only real solution to my video problems was to upgrade to the latest kernel, X, and intel video drivers. I use Ubuntu because I want reasonably recent packages but without the headache of running true alpha / bleeding-edge releases. Replacing all the critical parts of the distro seemed like the wrong way to go. So I suffered and waited for the day Karmic came out.

The 9.10 release notes cover a number of known issues. What strikes me about the known issues is how few of them affect me. Many are related to the netbook remix, or specific to recent netbooks with proprietary hardware. Support for the general case of mostly Intel hardware released 1-2 years ago is all there.

Upgrading from Jaunty to Karmic was just a matter of doing what the GUI prompted me to do. This wasn’t like jumping from KDE 3 to 4, so I didn’t remove any dotfiles or reformat. I just made my usual backup and then did the upgrade. I had a problem and had to stop the upgrade during the post-download, configuration part, so I ran dpkg --configure -a in a terminal and everything finished just fine.

What went wrong:

Synaptics touchpad tap suppression (syndaemon) stopped working. This is an artifact of upgrading from Jaunty, where to use syndaemon you have to enable SHMConfig in xorg.conf and then run syndaemon as syndaemon -S -d -t -i 1. On upgrading to karmic, set SHMConfig to false, restart X, and call syndaemon without -S (the switch doesn’t exist anymore anyway). I just removed my xorg.conf altogether, since X doesn’t seem to need it.

ath_pci, the madwifi Atheros wireless driver, is gone. I use this for aircrack and kismet. It is likely that I can either compile it or use the ath or ath5k drivers for the same thing, but I haven’t had time to test this.

openvpn with knetworkmanager still doesn’t work, at least with certificates that don’t have a passphrase. So far, openvpn doesn’t even start. From syslog:

Nov  1 13:51:32 baal NetworkManager:   nm_vpn_connection_connect_cb(): VPN connection 'company vpn' failed to connect: 'No VPN secrets!'.

Even if it did work, the dialog doesn’t even have a tab for manually setting up routes. Since when is the equivalent Gnome app more configurable than its KDE counterpart?

Ozone, the default KDE window theme, doesn’t use colour to denote the active window. Instead it uses stripes to the right of the text in the title bar. Some people say that compositing window managers and transparency are supposed to make this a non-issue, but they are wrong. I expect my active window to have a blue window border, and the others to be grey. To fix this, open the Control Centre. Go to “Appearance”, then the “Windows” side bar. Under the “Window Decoration” tab, choose “Ozone”. Under the “Decoration Options” area, uncheck “Blend title bar colours with window contents”.

What went right:

kernel mode setting is awesome! This currently works only for those of us that use Intel video, which is perhaps a small reward for suffering through Jaunty. Switching between X and virtual terminals is fast and seamless. The console has a gorgeous high-res mode at boot-time. I haven’t seen the screen flicker once since GRUB booted the kernel, from X startup to the KDM greeter to Plasma startup.

Booting is very fast. On my laptop I see KDM within 15 seconds of the kernel loading. I have a usable desktop 15 seconds after that. I’m sure more things are starting in the background, but they don’t seem to slow down my login process.

Xorg just figures everything out. I no longer have an xorg.conf and all my hardware works. Plus xrandr now has a large virtual area by default:

tyler@baal:~$ xrandr
Screen 0: minimum 320 x 200, current 1680 x 1050, maximum 8192 x 8192

This should work just fine with multi-monitor setups.

Google Earth and Kwin with compositing work at the same time. So far I’ve had no issue with any 3D apps running together, and they are all about 3 times as fast as they were under Jaunty.

qtcurve, the new KDE/GTK appearance integration engine. This replaced the deprecated gtk-qt engine which had all kinds of drawing errors especially with firefox. Qtcurve uses your “general” font setting from KDE in GTK apps, and generally makes GTK apps look like KDE ones. Unfortunately it is broken out of the box. The solution is to install the “kcm-gtk” package, and then use Control Centre to edit your “general” font setting. Set it to something else and then back again, or put this in ~/.kde/share/config/kdeglobals:

[General]
XftHintStyle=hintmedium
font=DejaVu Sans,8,-1,5,50,0,0,0,0,0

Wireshark never looked so pretty.

Firefox 3.5, which really is as fast as you’ve heard. KDE users, give up and use the default theme. All the “hack it to look like KDE” themes just don’t work as well as the one the developers themselves test against.

Plasma is stable. This isn’t a surprise as I’ve been running 4.3.2 from the PPA under Jaunty. Since Karmic is stable I’m not going to use the PPA for bleeding edge KDE releases anymore (until another juicy feature gets released, no doubt).

fish, the Kioslave for file transfer over SSH, is fast once again. It no longer generates notifications for normal browsing activity, either, which was extremely irritating under Jaunty.

knetworkmanager works once again. It was more than a little annoying to use Gnome’s network manager.

They finally got it right with Amarok 2.2. iPod support seems complete, the GUI is configurable (why does the playlist default to the right pane?), the collection scanner is much faster than Amarok 1.4, and it hasn’t crashed yet.

Karmic has been added to the repository.