An MRD for Linux on the Desktop

There are really several issues involved with this problem. First of all, while there are a lot of drivers out there for many common components, there aren't but a handful of vendors who are actually writing device drivers for their products directly. Rather, most of the device drivers out there now are the result of end-users having to figure this stuff out for themselves. Sometimes these drivers work really well, but sometimes they don't.

Obviously, the best solution to this problem would be for vendors to write their own drivers, and to ship them on the same floppies that also hold the drivers for Windows 3.x, NT and OS/2. This is true for everything, from SoundBlaster cards to 3Com NICs to Adaptec SCSI cards to all of the different video cards. Without vendor-developed and supported drivers, Linux on the desktop will eventually suffer the same fate as OS/2 Warp: "I can't use it, so I won't" will be its epitaph.

However -- and this is where things get tricky -- the biggest advantage that Linux has over every other operating system is the fact that end-users can write their own device drivers. In turn, the drivers that are available are typically available in source code form, allowing them to be used on alternative architectures. So even though some of the user-written drivers may be weak, they are usable on Alpha and PowerPC versions of the operating system (and not just the platform that the vendor chooses to support), which is a huge advantage over every other operating system on the market.

Therefore, if the Linux vendors are able to convince hardware vendors to write device drivers, those drivers need to be made available in source code form whenever possible, allowing them to be used on as wide a variety of different platforms as possible. Granted, this won't always be possible, but it should be the considered the bulls-eye of the target. Getting vendors to write device drivers in the first place would be a huge win; getting them to release the source code for their drivers would be the golden ring.

I think that the best way to sell this idea to those vendors is to pitch the bazaar development model as a way for the vendors to capitalize on the eager development community that's out there, similar to the way in which Netscape opened Mozilla. Rather than asking each of the vendors to do all the work themselves, ask them to champion the development of their drivers, hosting the source tree for the efforts, and accepting modifications and enhancements from end-users. To be sure, vendors will also have to guide the development of the drivers (and ship them with the hardware), but this is a lot less work than doing everything themselves. This, I think, is a more viable sell than the cost-laden, limited-return development model that prevented Warp from ever reaching critical mass.

Of course, us end-users also have to needle the vendors for driver support. I know that I've been bothering 3Com, Creative Labs and NeoMagic (with no results, unfortunately). Everybody needs to get in on the act before anything will happen in this space.

As can be expected, this is also a multidimensional issue. On the one hand, we need a simple configuration engine with well-documented APIs that is similar to the Windows registry. While that model has problems, it is also a tremendous improvement over the schizophrenic model of individual configuration files for every service on the system. Simple APIs for configuration information make it easier for developers to read/write configuration information, protect the user from misconfiguration, and are generally easier to work with.

I personally would like to see such an engine divided into two forks: one for the system-specific settings (where is WordPerfect installed? what are the settings for the network card?), and another for user-specific settings (where are my document templates? what are my PPP settings?). In a perfect world, the user-specific settings could even get stored in LDAP or NIS or some other network-based repository, getting copied to the local host whenever a user logs in. I don't think this would be hard to handle if applications just talked to a few well-documented APIs, while the configuration service itself did all the legwork.

There are also portability concerns here, of course. Many of the services that are used on Linux come from other UNIX platforms (which wouldn't have such an engine), and developers don't want to code for each system specifically. One way around this would be to make the code for the configuration engine widely available, and even port it to those other UNIX platforms if necessary. If the APIs are documented well enough and are easy to use -- and if there are end-user tools for managing the data -- then I bet that developers would eventually start making such a service the default, and making individual configuration files the secondary choice.

Another problem here is that drivers, services and applications would have to provide an interface to the configuration services. This means providing graphical (or textual) configuration tools that are also easy to use. Just as most of the common add-on cards have some sort of DOS-based or GUI configuration tools, the same needs to start happening for Linux. This can be a problem when you don't know what interface is in use, but I think this particular issue is resolvable through TCL-based tools. Maybe not entirely, but it'll get us closer.

Regardless of the implementation details, the thing to focus on is to make configuration simple enough for Mom to use. She's just not going to hack at PCMCIA, XFree86 and PPP configuration files. And this isn't a shot at Mom (mine's a PhD), but rather a wake-up call for the Linux community; end-users shouldn't be required to know these details in order to use it.

But there's a huge number of holes here, too. Where's the Notes client, for example? Where are the Norton Utilities and the Reflection terminal emulators? This list could go on for miles, and we haven't even started talking about the applications that have long been associated with UNIX, like FrameMaker and AutoCAD. Heck, even companies like Corel who are pushing the market with their port of WordPerfect aren't following through with ports of CorelDRAW, Paradox or Quattro Pro. This has all got to change.

So in many ways, Linux already has a lot of applications going for it. But in many ways it doesn't have nearly enough. As long as folks like me still have to dual-boot to load another OS so that we can get real work done, then it just isn't going to become our primary OS for everyday use. I'd also like to point out that I don't think that these vendors should open up their ports of these products. Indeed, they need to be financially motivated to do the hard work of porting these applications over to the Linux community. In addition, users have to buy them if they want to see more vendors bring more applications into this market.