Ubuntu's "restricted" repository holds a collection of proprietary device drivers and other software.
|(click for image gallery)|
That said, Linux notebook users still face two major hardware-support issues: Windows-only drivers and binary-only (i.e., non-open source) drivers. In a sense, both of these issues are tightly related. The lack of an open source driver doesn't pose an immediate obstacle to usability, but in the long term it can be frustrating since it stymies the kind of community-oriented, bottom-up development that has long been a mainstay of the Linux world.
To the open source community, a closed binary driver for Linux isn't much better than a binary-only Windows driver. And in many cases, a Windows driver is all that's available for many pieces of notebook hardware -- typically networking devices. Those devices can be made to work in Linux using the NDISwrapper utility, which allows Windows network device drivers to be used as-is in Linux. This isn't a long-term solution, though: 64-bit support for NDISwrapper is patchy; no support for Windows Vista (NDIS 6) drivers is available yet; the full range of features on the network card is not always available; and people have reported that using NDISwrapper can sometimes result in system instability.
Linux developers and users typically have to resort to a couple of strategies for dealing with these issues:
1. Working with hardware vendors under non-disclosure agreements. Signing an NDA with a hardware vendor typically means one of two things: the specs for a given piece of hardware are made available only to the developers and not to the general public; or information about the device is to be kept secret until a given date. Novell Linux developer Greg Kroah-Hartmann was able to attract a fair number of hardware vendors in this fashion through the Linux Driver Project.
2. Reverse-engineering devices for which there is no Linux support. Since this requires a good deal of technical skill, it's not something any user can do. (A non-technical user might be able to provide feedback about whether or not a given build of a reverse-engineered driver works, but not much beyond that.) Consequently, it's something that tends to be a small-scale undertaking, and it's generally only resolved permanently when -- or if -- the device manufacturer in question decides it's worth their time and effort to support a community-written driver.
3. Providing community-contributed and -maintained documentation of which devices do work in Linux. Various repositories of this sort of information are available all around the Web, such as the Ubuntu HCL and its partner sites.
4. Encouraging users to support hardware manufacturers that do provide open drivers. In some sense, this tactic is similar to #1, in that it requires people who have the time and dedication to bring their concerns to the company in question. Other people are simply likely to buy hardware that already works with Linux as-is, or find another option entirely -- which, in turn, causes the market for Linux devices to contract slightly.