Don Marti

Tue 11 Jul 2006 11:39:02 PM PDT

Hardware support models

(Updated: added link to Robert O'Callahan. Original posting date 28 July.)

The old Linux hardware support model, which basically amounted to releasing new hardware and waiting for the Linux developers to figure it out after it's been on the market for a while, is broken.

But so is the old proprietary OS hardware support model of putting software on a CD in a box, knowing that the OS will be updated while that box is being shipped to the store, and the OS running on the customer's system is unlikely to be the same as the one that you tested with.

Keith Shaw hits that one head-on. New security policies restrict some bundled software that must have worked fine when the hardware vendor tested it with a previous OS release.

What all hardware customers, regardless of OS, need is a driver process that recognizes three fundamental facts of life. First, people invent new hardware. Second, people discover security bugs and fix them. Third, if you don't test two pieces of software in combination, they're going to break when the user tries to run them.

I have a lot of hope for the Novell Partner Linux Driver Process. Also, Greg K-H (who works for Novell) comments on Microsoft's WinHEC and compares driver development models.

(Worst of all is the bastard spawn of the two hardware support models that people are now fighting in Linux 3D support. Jamey Sharp and Greg are making me happy about the future of this area, though. Between Intel's push into higher-performance 3D hardware and the r300 project's ATI support efforts, we should have a decent 3D scene soon.)

If you're interested in these issues, and in trying to come up with a driver development plan that works for your company and for the users, check out OSDL's Linux Open Drivers page. Upcoming event: Open Drivers Summit, which should cover some of the same things we talked about at FreedomHEC 2006, along with product management and legal considerations.