Journal npsimons's Journal: Stable API Nonsense 2
Recently there was a discussion about how Linux cell phones are basically DOA, and within that discussion was a thread on a stable driver interface in Linux. Rather than respond to every comment as to why this is a bad idea, I figured I would just post the original response to this request for a stable driver API which was put together the first time people noticed it was hard to ship binary drivers for Linux:
Let me just point out that this approach *works* and *has worked* quite well for quite sometime. These days, when I buy a new piece of hardware, I throw out the driver CD without even looking at it. I plug in the hardware to my Linux box fully expecting it to work; if it doesn't, I figure it's broken. Occasionally, it's not broken hardware but rather I have made a mistake and invested in a piece of hardware from a company that has not seen the light and open sourced their drivers. I make a point never to buy from that company again, and I get a refund for the hardware. I might point out that this is a very rare occurrence. Most of the time there is support for hardware out of the box under Linux - no driver CDs, no install and no reboot required - just plug and go.
Implementing a stable API for drivers would lead to bloat, insecurity and instability; we've seen it happen in Windows, and even starting to happen with binary drivers under Linux! The technical argument is that Linus (and his kernel devs) reserve the right to rip out or reimplement anything they please in the kernel, with no regard whatsoever to backwards compatibility. This model has worked very well so far, as evidenced by the fact that you can plug in 99% of hardware into a Linux box and have it just work, no driver CD, download or install required.
Still, some people argue this is a political issue, not a technical one. I would agree, on one point: the hardware vendors are the ones making this a political issue. By refusing to release their source code, they limit how well their device can be supported. For what purpose do they need to keep their drivers closed? They sell hardware, not software, therefore they don't even have an economical reason. The arguments for releasing source are legion: support in ALL distros on ALL architectures by default; more stable and better tuned drivers; no need to ship driver CDs; no worry about having to support your drivers as they are now in the kernel, etc. I can think of no reason other than petty greed to keep drivers closed. And it's greed that doesn't even function properly at that, as it doesn't gain the greedy companies anything.
Is there any *technical* reason to keep drivers closed source? Please elucidate, and remember that even if there is, it must somehow outweigh all the benefits of having the same driver as an open source driver in the kernel in order to argue that there should be a stable driver API. This isn't an ideological, or even political issue; open source drivers have been shown *in practice* to work better, and provide all of the benefits I've listed. Why should we throw out one model that works for one that has been shown to not work nearly as well?
I can think of one (Score:1)
Hiding stolen code. Or code so bad it is to laugh out loud.
Besides that..not a lot of reason for joe gadget company to try and hide code. They'd do much better sales on all platforms if it was open and better community derived and maintained drivers were available.
Re: (Score:2)
Ah, the legal angle. I tend to ignore that one, but I suppose it's a valid concern.
There's no code so bad it can't be fixed. Well . . . almost no code. As someone who does a majority of his work as a maintenance coder, I think I can say that just releasing the code would be welcome. Or specs; specs are always useful.