I decided to give the new Ubuntu beta a whirl on my X60. Recently I’ve heard a few anecdotal success stories of running Ubuntu on laptops, so it seemed worth a try.
I was concerned about running a beta installer on my work machine, so I decided to run the Edgy installer instead. I backed up my important files and used the built in NTFS resize functionality to make space (which, worked surprisingly well, considering my past experience with it). Once Edgy was installed, I used the update manager to pull in the new beta version (you can do so by running
update-manager -d). The update took a while, as it had to download all the new packages, but the install completed without a hitch, and one reboot later, I was running Feisty.
First impression: looks mostly the same. Same brownish theme, and same ugly fonts in Firefox. I did get a bubble notification at start up that told me that I was using “restricted” drivers. A few clicks later, I was told that they were for my wireless chipset. Fine, whatever. I appreciate what they’re trying to do here, but I don’t think most end users really care. Feisty seems to make it very clear that “restricted” drivers are unsupported and may have problems that can’t be fixed. Yet it seems ironic and somewhat pointless, since for most users, Ubuntu is going to have problems that aren’t going to be fixed regardless of whether the at-fault component is open source or not.
Anyhow, I do applaud them for at least distributing the driver, and to make it work without any user intervention. It’s a good start.
The one feature that was going to decide whether I was going to be able to use Linux regularly on this machine was suspend-to-RAM. The first time, I just I tried it as a normal user would (by hitting the sleep hotkey), and it worked! I was rather surprised, since I had heard all kinds of fun stuff about having to write custom scripts that unload and reload things as your machine goes into and out of sleep.
The feeling of “finally!” quickly faded, though, as the second and third attempts all failed in different ways. The first time, the wireless card disappeared. The second time, the screen wouldn’t come back. The third time, I lost sound.
Well, so much for that. I tried a suspend-to-disk a few times, and that seemed to work. But I don’t feel motivated enough to debug the hardware issues to make the sleep work. It’s probably going to make me compile new kernel modules or god knows what.
That being said, it seemed that the whole sleep thing was very close to working. Much closer than any previous incarnation of Linux I had seen. Most of the special Thinkpad hotkeys worked, and it didn’t seem like any of the apps freaked out about the machine going to sleep underneath them. The battery, as well as the CPU frequency scaling seemed to work fine.
Not everything was negative, there were a few “I wish Windows did this” moments. One was the support for the conventional “middle button scroll” feature of Thinkpads. Since many Thinkpads don’t have touchpads, IBM had a feature where you press and hold the middle mouse button to turn the track point into a scroller. On Windows, it works fairly well, but you always run into apps that don’t support it. It’s as if the functionality is implemented a little too high up the stack. The most annoying effect is that the scroll functionality get’s lost when using remote desktop client software. Both VNC and RDP clients will not properly send the scroll events to the remote end, which sucks.
On Linux, you can just use the “EmulateWheel” option in your xorg.conf file to turn on this exact feature. And it works at the X-server level, so it works with all apps that understand scroll events. This is certainly an improvement over Windows.
At the end of the afternoon, however, it doesn’t make sense to run an OS that can’t properly drive all of your hardware. I suspect that this might actually be the case for my desktop, so I will investigate that when the final release is available.
For now, on the Thinkpad, I’m much better off running Feisty in a VMware Workstation environment (especially with the new version which will have VMI support so things will be pretty fast).
As someone who’s been using Linux in various forms for a while, I fully understand that it’s not really Ubuntu or Canonical’s fault that these things don’t work. ACPI is really hard, and closed drivers make everything hard. But until the community figures out how to overcome these problems, Linux doesn’t have a chance in the laptop space.
Maybe it’ll happen like this: People will realize Vista blows. Linux will continue to catch up and eventually get good enough to be equivalent of the XP experience (on a few hardware configurations). Maybe a migration to it will become possible with some extra pieces like Parallels-like “coherence” except with a Linux host and an XP guest. People will start to see Linux as a potential alternative, and all of a sudden, companies that write Linux drivers that work will have an advantage.
Or maybe some big hardware PC manufacturer will finally try to get off the sinking Vista ship, and release a limited line that is tested to run with Linux, and has a hardware configuration that is as Linux-friendly as it can be. Who knows. Maybe it’ll be Dell. Someone the size of Dell might be able to use it’s influence to convince suppliers of hardware components to even write drivers, or at least release specs.
Before I go, a few miscellaneous observations about Feisty:
- Still uses freetype 2.2.1. Not sure if there’s a reason. 2.3.1 seems to work fine for me at work, and works better with some fonts.
- The default font settings are “grayscale” smoothing and “medium” hinting. It looks pretty good for GTK apps, but for some reason Firefox looks pretty ugly.
- ThinkWiki is a pretty useful site that has a lot of random details about running Linux on Thinkpads. You can solve some of the smaller problems by reading those pages, but it doesn’t seem like it will help you solve big problems like getting suspend-to-RAM working.
- Battery life under Linux seemed pretty good. At full charge, the readout was at about 5.5 hours, and it didn’t seem to drain particularly quickly or anything.
- Firefox still doesn’t support GTK input methods out of the box. You still have to set up your GTK_IM_MODULE env variable to point to something