Dell Promises Pre-Installed Linux (PC World)
Dell Promises Pre-Installed Linux (PC World)
Posted Mar 30, 2007 17:57 UTC (Fri) by madscientist (subscriber, #16861)In reply to: Dell Promises Pre-Installed Linux (PC World) by nim-nim
Parent article: Dell Promises Pre-Installed Linux (PC World)
> So what? You have the same problem on other OSes
No, you don't. The difference is that with other OSs, the kernel ABI is static or at least stable for a number of years at a time. Linux has no stable ABI, which means it's very difficult to distribute binary drivers that work for any length of time, across any wide cross-section of distributions.
That's all fine: I'm fully in agreement with Linus about ABI stasis in the kernel, and I want source code for my drivers as much as anyone. But let's not kid ourselves that this doesn't cause problems for even the most friendly hardware vendors, who are working to get their drivers into the kernel proper, as Greg K-H etc. recommend. Even with the advanced pace of kernel development there can still be a lag of a number of months before a driver for new hardware is accepted into the kernel.
And that doesn't do anything to help people who are using distros with older kernels: distros come out even less frequently than kernels, and by the time your distro releases (even if, like Ubuntu, it releases every 6 months) it's likely the kernel in that distro is 9 months or more old.
And of course, even the API in the kernel changes so drivers that you write for the newer kernel may well not work properly with older ones (and, to a lesser extent, vice versa), and that's not to mention that most distros are not configured by default to be able to build out-of-tree kernels: they don't install all the kernel headers or even, sometimes, a compiler. Yes, this is easy to remedy by the user but it adds a good bit of complexity to the entire operation.
Contrast this with Windows, where a hardware vendor can give a driver to Microsoft to be shipped with Windows, then put a disk or CD in their package with 2 or 3 versions of a driver, and cover all Windows systems shipped in the last 10 years at least, with virtually no support costs.
I'm not saying Windows has it right or that Linux should follow that model (I loathe Windows). I'm just saying we're not doing anyone, including ourselves, any favors by not admitting the truth: Linux is a more challenging environment for hardware vendors to support than Windows, EVEN IF they are completely committed to FLOSS principles (which is rare). That's a real problem and we need a real solution. I think DKMS, or something like it, is a good attempt to address this problem in a pragmatic fashion.
Posted Mar 31, 2007 11:27 UTC (Sat)
by nim-nim (subscriber, #34454)
[Link]
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)
>> So what? You have the same problem on other OSesDell Promises Pre-Installed Linux (PC World)
> No, you don't.