Slashdot Mirror
Linux Kernel Devs Offer Free Driver Development
schwaang writes "Linux Kernel hacker Greg Kroah-Hartman, author of Linux Kernel in a Nutshell has posted an epic announcement on his blog. This could portend increased device compatibility for Linux users, higher-quality drivers, and fewer non-free binary blobs." From the announcement: "[T]he Linux kernel community is offering all companies free Linux driver development... All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. If your company is worried about NDA issues surrounding your device's specifications, we have arranged a program... in order to properly assure that all needed NDA requirements are fulfilled. Now your developers will have more time to work on drivers for all of the other operating systems out there, and you can add 'supported on Linux' to your product's marketing material."
I wonder how many companies will be imprudent/progressive enough to take up this offer.
Something bad is coming when people are suddenly anxious to tell the truth.
Seems like a good idea, but it also seems like it would give the device manufacturers an out. "I'm sorry, but we don't officially support the linux operating system". This way they get drivers written for them for free, and don't need to provide any tech support for the device to those users who purchase it for linux. Anyone else see this happening?
"All that is needed is some kind of specification that describes how your device works". They also need some real hardware to test the brand new written drivers. Specifications are not enough. Who will test the real hardware with the fresh drivers in a real-world operation ?
-- Rastignac was here.
Whatever you might say about the Linux community - that it is elitist or sanctimonious or whatever - it is impossible to ignore their commitment to what they believe in. That somebody would be willing to write device drivers for nothing, apparently just to forward the cause of a free operating system, is pretty impressive. Microsoft and Apple can match this devotion only in the ferocity with which they defend their control over their customers, in anti-trust trials and by imposing DRM.
Peter
A really quick scan of the price of windows driver development, demonstrates how much actual value this is for business. Now all you would need to do is pay someone to extend the drivers to other platforms! Eureka!
The dangers of knowledge trigger emotional distress in human beings.
I think this kind of action, and offer for help is needed by companies. I hope it will be touted enough. What I know is that, companies having really hard times finding skilled coders for developing Linux drivers. Most of them does not care about the specifications, as they have already patents pending for their works, but they can't actually find people to code for Linux and/or they don't willing to pay more than Windows developers for Linux developers for a smaller market.
Is this realistic though? Are companies actually going to take this offer up? If they do, the impact could be awesome (hardware compatibility that could rival Windows and/or Mac OSX)...
Nice one!
ilovegeorgebush
I have never written drivers so I may be way out in left field here, but how close are we to being able to specify a standard driver model, with compatibility across operating systems? It seems to me that drivers are one of the biggest impediments to OS adoption. They are also a huge cost center for device manufacturers. Imagine if 99.9% of the driver code could be the same across platforms. Is this even remotely possible? Or perhaps the Linux Kernel driver developers could figure out a way to adapt Windows drivers to run, perhaps in an interpreted or emulated fashion, on Linux (ala Virtual PC). Just a thought.
The more you regulate a company, the worse its products become.
Other than the public announcement, how is this any different from the way things already work?
The community already writes free drivers for vendors who provide specs and (even better in some cases) loan some hardware.
There are already situations where Linux devs have been able to work out NDA-acceptable solutions.
Really, all the announcement is saying is, "Look, we do this. We've been doing this for years. Just letting you know how things work over here."
retrorocket.o not found, launch anyway?
Other than the public announcement, how is this any different from the way things already work?
Actually this really is something new, and quite an announcement. It was never the case before that any old random driver would get created by the open source community. The way OSS development generally works is there has to be a strong need, strong backing, or a high fun factor, for things to get done.
Prior to this announcement it's not like there was a group of people dedicated to writing drivers -- just waiting for companies to release new hardware, then they'd scurry to reverse engineer it and write a driver. Nor do companies (generally) release hardware specs in the hopes that others will provide a driver for their product.
A significant portion of initial open source driver development comes from the device manufacturers themselves, and smaller companies without the resources to spearhead these developments simply don't have the ability to have Linux support.
Your conception that "The community already writes free drivers for vendors who provide specs and loan some hardware" isn't true in the vast majority of cases.
This really is a big change, because now anyone can create a hardware device and actually have formal linux support, and have this printed on the box. This creates a formal avenue for companies to easily, reliably, and cheaply have Linux support for their products.
The folks at Xiph have had a similar offer for a few years:
We've got a fixed-point implementation of the Ogg Vorbis 1.0 decoder, called Tremor. As of this evening, Tremor is licensed under a BSD-style license, is free for all use, and you can download it right here. If you need help implementing Vorbis support into your hardware player, we will give you any resources at our disposal to make it happen (including engineer time). If you want Vorbis in your player (like your potential customers do), we want to help you.I don't know if anyone ever took them up on it. Ogg support in portable hardware has come a long way since then. I used to come back to this page every couple of weeks to see if anything had changed. Now a lot of players have it... I hope this takes off.
perl -e 'foreach(values %SIG){$_="IGNORE";}while(){}'
The arguments about out of the box driver support for linux happen all the time. The reality is that the issue is not out of the box support. I often have more functionality out of the box with a modern linux distro than windows on the same hardware but that only gets me so far. The biggest hurdle is supporting less common hardware. Adding driver support in the kernel is great, but there is no way they can keep pace with the release of new obscure hardware. We need a way to support less common hardware without constantly trying to bundle drivers into the kernel. Also the kernel developers are not always willing to merge 3rd party code into the kernel if it isn't to their standards or is perhaps not 100% complete. I completely understand this process, but it doesn't help people who have to search out these drivers and try to compile them from source.
The best example I have is my webcam. I know that when I purchased it it would have linux support because i did my research, but I still had to know how to do the research, how to track down the right driver and then how to build it from source. What we need is a driver manager that operates similarly to or in conjunction with our package managers. If during install or after a first boot I was told that a driver for my webcam was not installed as part of the distro it could then either download a driver package if one is available or it could at least suggest a link to download a driver not yet being packaged for my distro. Having to check my dmesg to see if my webcam shows up as a generic USB device or if a driver has been assigned to it is a terrible solution, we need a more friendly means of checking a supported devices database and better way to get access to the drivers that support our less common hardware. This is especially important for people who don't hand pick their hardware and are less familiar with exact model numbers or sometimes know even less.
This system that manages drivers might also do well to phone home to the distro maintainer when possible to catalog all of the hardware that is not being supported by a driver. That way we can at least get a better idea of where the biggest holes in device support are.
Fear trumps hope and ignorance trumps both
Who is he speaking for? The whole Linux kernel community? I didn't think it worked that way. Even Linus is as much a cat herder as a boss, once you get beyond a few core people. The population of kernel developers who can be ordered (the difference between "might get a driver" and "will get a driver") to write drivers for obscure hardware they have no interest in must surely be fairly small. Who's actually in on this? Are there a few hundred kernel devs who've agreed to work on whatever they are assigned? I'm worried that this will backfire when they can't actually find anybody who wants to write the driver for a engraving machine that sells 400 units per year and has a particularly baroque interface. I don't expect there will be a problem for WiFi, TV or video cards, but there's a whole lot of hardware out there and not all of it is interesting.
Those are some pretty big promises he's making. I'm wondering what's there to back them up.
Chernobyl 'not a wildlife haven' - BBC News
As an example of extending to other platforms, we may cite the 3DFx Voodoo board.
After the company collapsed, users were left with no drivers for recent windows version (XP, XP64 and Vista).
But, the Linux drivers happened to be open source.
So most of the work you may see on websites like http://3dfxzone.it/ for Windows, is mostly based on libglide and Mesa3d for linux.
(This is also another proof that open-source enable something to survive beyond the death of it's parent company)
Another example may be the linux USB stack, which was later ported to both the Cromwell xbox bios and ReactOS (opensource clone of the Windows NT system, cousin of Wine project).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Some of it's Microsoft's doing, yes. But it's a lot more complicated than that.
"Show me the money"
"We have to protect our IP"
Those two statements I get told QUITE often in relation to my driver consulting work I currently do.
Both are varying degrees of wrong- and where the trick lies is in convincing the company in question that it's wrong to hold that position in the first place. Both are very difficult to shift because they're usually NOT fact based positions to begin with.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
Your first sentence is correct, but your second is a bit lacking in understanding I think.
The technical specifications that they're requesting access to usually are the specifications for the entire product. Let's take, for sake of example a Video card.
The specification covers not only just how the device interfaces to the computer, but also how the VRAM and GPU integrate, etc.
In other words all the driver will tell someone who hasn't signed the NDA is how to access the hardware, but not how the parts of the hardware work with each other.
That's how maintaining the NDAs would be advantageous to companies.
- My two bits and a ha'penny.
Put it next to the Intel Inside! or Powered by AMD:
'Has been reported to work on Linux!'
WARNING: Smartphones have side effects--most of them undocumented.
To that, I would add that Epson is a particularly good choice. They've cooperated with the SANE project in providing hardware specs, sometimes even for hardware not yet released. They even make available a binary-only Linux driver and scanning utility through their Japanese division, though of course the open-source SANE support is preferable.
I have a Perfection Photo 2400, from a couple years back. It works flawlessly with xsane. (Do double check against the supported-hardware list, however, because some Epson models actually use third-party components for which no specs are available.)
iSKUNK!
"Am I missing something, I don't see your point?"
Apparently not. What PP said was that there is the potential for profit there, but the hardware industry may be underestimating the buying power of the Linux desktop market.
For example, I, and many other Linux users buy my WiFi based on what works in Linux. I am not a Linux-only human; I have a Mac, a Windell at work, and a Ubuntu laptop.
But therein lay the point: The commercial OS developers already support your product; you wrote drivers for them. Now, at no extra cost, you can have the edge up on your competition for that 1.6% of the computer-using market that has Linux in one form or another. As of 2004, that's 1.6% of 61.8% of all people in the US, or about two-and-a-half million people. At median income of $30k, and assuming that 5% of their purchases are technology-oriented, that's a chunk of $3.75B you're fighting for.
Not a small number, and the slice of it you get could mean the difference between shelling out a new product in a month or shelling it out in a year. Meanwhile, if you can expand that slice at low (rather than building a monolithic driver, build drivers as modules that can be 'plugged in' to existing kernel scaffolding for Linux, Apple/Mach and NT) or no (having the Linux Devs build it) cost, there's no reason you shouldn't.
Of course, the bigger the company, the less this matters to them; large companies have the opportunity to 'rest on their laurels', as it were, when it comes to new accessibility.
110100 1101000 1101000 1100110 0 1101111 1101000 1100011 1
if Linux is going to become a viable alternative for the girlfriend
Dude, don't get me wrong, I think Linux is sexy. But not that sexy.
http://www.opensource.org/docs/definition.php - Section 2 of OSI's Open Source Definition
That said, an NDA still may not make it impossible to write a driver. If the specs are under NDA, that means nobody else can see the specs. It doesn't *necessarily* mean that nobody can write a driver that interfaces with those specs. This depends a great deal on the wording and intent of the NDA itself. Naturally, some people will consider a driver to be a description of the spec, and hence not allowed under the NDA. Some people will not. Specs often contain a lot of things that aren't strictly required to make a device go; it may be these parts, the implementation details, that the NDA is intended to protect. The best thing to do would be to separate an interface specification from the implementation specification, and release the former NDA-free. The next best thing would be to invite a developer to sign an NDA and develop an Open Source driver.
Not possible for every piece of hardware out there, but possible for many.
It's rare that you're presented with a knob whose only two positions are Make History and Flee Your Glorious Destiny.
> That's called extortion, and it's illegal.
Like that ever stopped Microsoft before.
> I would hope the DoJ steps in at that point.
Like that ever stopped Microsoft before.
I'm not sure I believe this.
I worked doing VLSI design for a short time as an intern, so, though I can't claim overwhelming expertise, I've learned more about the industry than I think the general public knows. Foundry tech is hideously expensive, requiring gigantic investments. It costs so much that it's gotten to the point that even competitors do joint work (with tension and assorted legal handcuffs, to be sure -- and they keep it quiet -- but in the end they all cross-license with each other) to develop new foundry technologies (and, to a lesser extent, "I.P."), because it's just so. damn. expensive. Old rivals are forced to quietly build each others' chips, because neither can handle it on their own.
You might be able to design a chip, send it off to TSMC, and have them produce it -- but even that costs boatloads. And it's not going to work quite right the first time!
I recall, maybe a year ago, there was a big press release about a Chinese CPU which was supposed to demonstrate China's rising power. It was about as fast as a Pentium III. Given what they were starting with, that's pretty damn impressive -- but you also notice that they couldn't pop out a Core 2 Duo. There's a lot of infrastructure required that's just not there yet.
Even people like PowerVR, with their Kyro cores, couldn't effectively challenge ATI and nVidia: They produced a decent budget core, for a little while, but they couldn't keep up, and now they're designing cores for chips other people design which end up in cell phones. They're probably making more money that way -- but they just couldn't stay on the bleeding edge.
So, no, a company in China can't build a low-budget ATI-killer overnight -- and I don't believe it's just the drivers.
People who fall into the trap of installing and using proprietary video card drivers then later discover that their video card (which still works fine) is no longer "supported" by the latest driver update would disagree with you that "Video cards are already well-supported by their manufacturers.".
I believe this kind of thing happens more than others know, particularly as GNU/Linux distributors that distribute proprietary software make it easier for users to acquire proprietary software (as I understand Ubuntu is working on). Users shouldn't be left without their software freedom, nor should they have to choose between updating their system kernel and using their video card.
Making users helpless and keeping them separate is no way to live. Users need software freedom now.
Digital Citizen
That happened to me with my Radeon. At that point, the open source driver supported my card, and I didn't have to futz around with building kernel modules every time I tinkered with my kernel.
tasks(723) drafts(105) languages(484) examples(29106)