What Else Should We Consider?
I said earlier that a kernel has two roles. The largest role is giving userspace programs access to the hardware. This is why a major proportion of the Linux code (and the code of most other kernels) consists of device drivers. There is an elephant in the room here, however: graphics.
The old driver model from XFree86 placed very little dependency on the kernel. The X server ran as a privileged process and accessed the hardware directly. I saw an example in action when I tried using a Matrox binary-only driver for Linux on FreeBSD. Although the driver was labeled as being for Linux, it ran perfectly on FreeBSD because it directly interacted only with the X server and the hardware, not with the kernel at all.
Newer driver models use a system called the Direct Rendering Infrastructure (DRI). This system has two components, typically called DRI and DRM. The DRI part is a userspace driver that issues commands to the hardware and exposes APIs to other userspace programs. The DRM component is a tiny kernel module that validates commands and passes them to the hardware.
A common criterion for judging whether "Linux" is ready for the desktop is asking how well 3D works. In fact, this isn't Linux's job at all on most systems. Linux just gives X.Org a direct interface to the hardware, and X.Org provides the drivers. The same drivers can be run on FreeBSD, OpenBSD, and a few other systems. In a GNU/Linux system, Linux is not the part providing the drivers for one of the most complex bits of hardware in a modern desktop (or laptop).
With the development of Filesystem in Userspace (FUSE), which also runs on FreeBSD, NetBSD, and Mac OS X, the kernel often doesn't provide all of the filesystem drivers, either—further reducing the importance of the Linux component of the system.