They thought they were doing me a favor. I needed a new laptop, and as a typical management-type road warrior, what could be better than IBM’s latest and greatest: a ThinkPad G40 laptop with Windows XP and Office XP preinstalled. Built-in wireless, built-in gigabit ethernet, built-in modem, DVD drive, everything the road warrior could want, right?

The problem is I’ve been a dedicated Linux end user since the 1.0.8 kernel. Knowing that the first thing I’ll do is set this machine up to dual boot between Windows and Linux, I’d prefer to have a slightly older machine that thus has better Linux support. That’s just one of the little lessons I’ve learned over the years.

Few people know both less about programming and more about Linux than I do. From the beginning one of my requirements has been to have a graphical word processor that creates files I can easily share with the Windows world, without them having to know or care that the file originated from a Linux box. When I was running the 1.0.8 kernel, my convoluted soution was to run a Mac emulator called Executor that enabled me to run Word 5.1 for the Mac on Linux. Linux has come a long, long way since then, but alas, the more things change, the more they stay the same.

“Is Linux ready for the desktop?”

This question is really oversimplified, and thus the source of a lot of confusion in the debate. I’d like to break it down into six questions:

• Is Linux managable to install as an enterprise desktop system?
  
• Is Linux managable to install as a home user desktop system?
  
• Is Linux usable as an enterprise desktop system?
  
• Is Linux usable as a home user desktop system?
  
• Is Open Source software usable as an enterprise productivity suite?
  
• Is Open Source software usable for typical home user applications?
  

Putting the debate this way makes a couple of key distinctions. On the one hand, Linux can and does run a range of proprietary software that can make the end user experience both easier and more compatible with the rest of the world. Asking if purely Open Source software is sufficient is a rather different question. On the other hand, the greatest challenge with any operating system — installation — is largely removed from the user experience by Microsoft, leading to an apples an oranges comparison: Windows’ ease of use vs. Linux’s installation challenges. For a fair comparison, these issues — how hard is it to install vs. how hard is it to use — need to be separated out.

I won’t attempt to answer all these questions here, but offer a perspective based on my own experience.

I’m a committed Debian user, so getting a cutting edge laptop automatically sets me up for a couple of problems. First, nondestructively repartitioning Windows XP partitions is more challenging than nondestructively repartitioning Windows 9x partitions. Second, device driver support for graphics migrates slowly into Debian, meaning I almost certainly will be unable to use a stock Debian kernel to run the X Window System.

For repartitioning Windows 9x, I recommend GNU Parted. It’s fully Open Source, and has worked flawlessly for me for years. For Windows 2000 or Windows XP you’ll need a program called ntfsresize, as well as a means of booting something that can run that program. There are several choices here, but my choice is System Rescue CD, a bootable Linux distro that runs a program called qtparted, which in turn provides a nice, graphical front end to ntfsresize.

Note that as installation steps these are well beyond the typical home user, though not unreasonable for the sys admin charged with managing enterprise desktops.

The ThinkPad G40 uses onboard graphics via Intel’s i830 chipset. You won’t find support for this in Debian’s Stable release, and even going with Debian Testing as my install system I had issues. I ended up grabbing kernel source for the 2.4.22 kernel, and patching it with the 2.4.23pre9 patch before I could get graphics working properly. That was also the only stable kernel I could find where the tg3 kernel module for the ThinkPad’s Broadcom gigabit ethernet card worked. That module exists in some earlier kernels, but for some reason it only compiled and configured properly for me under 2.4.23pre9.

Again, compiling from source is not something the home user will master easily, and patching source before compiling is way beyond what the typical home user wants to tackle. For the enterprise desktop sys admin, all of this should be within reason, if a bit of a hassle.

Several things just worked “out of the box” on the Debian installation: the built-in Prism wireless card worked, as did the onboard sound support (again, Intel i830). USB support also worked flawlessly, a must for me since I do a lot of temporary backup and file moving via a “keychain” USB storage device. By the way, the actual user interface for Debian installation has gotten dramatically better over the years. With less finicky hardware, and a little hand-holding, this is probably something the home user could figure out. I couldn’t have said that about Debian two years ago.

PCMCIA did not work, even with a custom kernel compile. That’s not as critical as it used to be. I seldom connect by any means other than wireless any more. I run a wireless home LAN, my employer runs a wireless network, and on the road my most frequent means of connecting is via a WiFi Hotspot in any of our countless Starbucks. Still, there are occaisions when I have no better means of getting online than modem, and my choices are either: try to get the WinModem working under Linux (something I’ve been able to do in the past), or get PCMCIA working so I can use a modem PC card. I opted for the latter approach. Compiling and installing PCMCIA separately worked just fine, and wvdialconf had no problems subsequently recognizing and configuring my PC card modem.

This level of tweaking starts to go beyond what even the typical enterprise sys admin might be expected to know. You have to know that there are two parallel development tracks for PCMCIA in Linux: the kernel modules, and a separate standalone PCMCIA package. You also have to know that even though they are ostensibly interchangable, there are rare occaisions — like mine — where something will work with the standalone package that does not work with the kernel modules.

At this point I was ready to move from system installation to application installation and configuration, to turn my Linux laptop into a real road warrior’s productivity machine. That’s a story for another time.

A few comments in closing. With almost a decade of Linux experience, I still could not have done this installation unaided. It took the occaisional support and encouragement of more technical Linux gurus to get me through all of this (Dean, Gareth, Andy: thanks).

The larger lesson is that Linux will only be a reasonable enterprise choice and a possible home user choice when hardware manufacturers get behind Linux in a big way. Right now Windows’ single most unfair competitive advantage is that it comes preinstalled on virtually every new PC sold. If that were a common and well-known option for Linux, and if hardware manufacturers took quality assurance for Linux as seriously as they take quality assurance for Windows, then Linux would at least be a worthy end user platform. It’s viability, either in the enterprise or the home, would then depend on the applications it supported.

Note that this is a vital issue, because it precedes other issues, and that it is an issue that neither the Linux nor the larger Open Source community can affect directly. No amount of coding will guarantee that Linux works smoothly with hardware it has never seen before. The best the Open Source community can do is lobby — graciously — for more cooperation from hardware manufacturers.

In my next installment, I’ll look at my experience with software installation and configuration, and try and suggest how that bears on the larger questions of Desktop Linux.

What’s your experience installing Linux on laptops?