Dell Promises Pre-Installed Linux (PC World)

Posted Mar 31, 2007 11:27 UTC (Sat) by nim-nim (subscriber, #34454)
In reply to: Dell Promises Pre-Installed Linux (PC World) by madscientist
Parent article: Dell Promises Pre-Installed Linux (PC World)

>> So what? You have the same problem on other OSes
> No, you don't.

Yes you have and it's proved every time a new major hardware family (usb, sata, x86_64...) is introduced. Once the base support is in the kernel all is fine but till it is hardware manufacturers have to wait.

It's a complex ecosystem, it's not a manufacturer-to-user one to one (it's not under windows either but that's less clear-cut). It works perfectly for server-class hardware because everyone involved knows its responsibilities (and you have cutting-edge hardware there too) but it seems desktop-class manufacturers still have their homework to do.

1. Manufacturers for a device class are collectively responsible to get the core infrastructure needed by their device class written (either inhouse, paid-for externalisation, documentation to interested developers, etc) and submitted to the core FLOSS project managing this kind of hardware (kernel, xorg, cups, sane...). This is where most of the time is spent and you don't see it overmuch under windows because it's usually done well in advance. You'll note even though Nvidia has a closed driver its people work with xorg to get the required infrastructure done (as do Intel)

2. Then when they're ready to ship one particular device the actual device driver writting and submission can be quick and compatible with time-to-market requirements.

3. Core hardware projects (kernel, xorg, cups, sane...) have to audit and integrate these submissions in a common source release.

4. System builders like Dell have to select hardware that went through 1. 2. and 3. to provide an incentive to their suppliers, and systems to their users distributions can support.

5. Distributions have to package the source releases and make them available to users, and do community or paid-for support.

Any delay before 3. is hardware manufacturer problem (and the system builder problem is he does not push its suppliers in the right direction). Delays at 3. are hardware manufacturer problem if the submitted code is not clean enough for quick integration, and community/distro problem if there's not enough people to audit it in time. Delays at 5. (what hardware people like to complain at) are distro-side, however major distros like Fedora have already make clear they'll pick up source release quick (not like in the bad old days). If the driver pump is correctly initiated at 1. and 2. every other distro will have to follow suit. They only get by with lagging because hardware manufacturers do not provide any incentive by failing to push drivers at 1. and 2.

Getting satisfied with a foolish distro shipping half-baked code only means others won't ship it any time soon because there's nothing working to ship (the mandrake firewire example is a good one it made everyone lose months/years, if we get proper support someday that's because Red Hat is restarting at 1. now and rewriting the base class support)