Slashdot Mirror
OpenBSD Ahead of Linux for Wi-Fi Drivers
algae writes "It looks like some kernel developers have noticed that the OpenBSD project is including reverse-engineered drivers for wireless ethernet cards while Linux is still using binary blobs. A large part of the issue is that much OpenBSD development takes place abroad, where having to do clean-room reverse-engineering isn't as important." From the article: "Christoph Hellwig took another stance, 'please don't let this reverse engineering idiocy hinder wireless driver adoption, we're already falling far behind openbsd who are very successfully reverse engineering lots of wireless chipsets.'"
I just started using FreeBSD 6.1 recently and I was surpised about the ease of setting it up. (Still not for the faint of heart, but Windows isn't either. If you want a nice custom setup that does what you want, you need a lot of time in Windows). My primary laptop is a P-III 600MHz with 512Meg RAM. An old fucker I bought for peanuts. It didn't have a network interface, so I added a Sweex wireless adapter. It shows up in both FreeBSD as Windows under RaLink 2500. (Note that Sweex is a cheapass brand, but for another product I had *excellent* support by email with them)
Linux.... Nothing... No out of the box recognition.
OpenBSD also recognised it but doesn't support WPA-PSK which I do require. FreeBSD supports WPA-PSK. I've been an OpenBSD fanboy for a long time, but I like FreeBSD equally now. Linux... well, somehow I have problems with most distributions. Either philosophical problems or technical problems :-) With *BSD, I have neither.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
Leaving BLOBs in the kernel might just mean you have different plaintiffs than if you used a reverse-engineered driver.
However, full clean-room reverse-engineering a free driver with full source code, rather than one that you have to disassemble and figure out, is a reasonably easy task. And, we have to write a Linux driver anyway. So, find one friend to work with and get started.
One person must not write any kernel code concerned with the driver. That person must read the existing driver, document the hardware, and publish the document. The document should not reproduce algorithms in the existing driver unless they are integral to driving the device and there isn't another way to do it.
A second person must not look at the existing driver. This person reads the document and writes a new driver.
Keep notes about the entire process. You could someday have to testify that you did it the right way.
Bruce
Bruce Perens.
In reality, on the other hand, the reverse engineered drivers can serve as excellent documentation for how the same logic can be implemented in another OS, but that's about as close as it's likely to get.
Dewey, what part of this looks like authorities should be involved?
Openbsd is going to maintain the anti-blob. I was down a wireless security with openbsd talk in Calgary after the hackathon last week which Theo attended and you can be sure OpenBSD will maintain the anti-blob. The discussion about blobs centred around what has been said before on openbsd.org. OpenBSD is first and foremost about security in its default state. You can't include arbitrary code that you don't compile yourself in such a system, you can't verify that's it doing what it says its doing. Further more Asian developers are more then happy to hand over all the required spec documents to get wider support for their wireless chipset. American companies however are going the otherway and would rather build drivers for each system the feel is important enough to warrent them.
I'm sure they have their reasons but at the end of the day their way attempt at full circle development control will probably back fire. In an attempt to maintain a clean intellectual property enviroment where every participant is governed by NDA's and priorities are set by Mama corporate they have traded in creditabilty and grass root adoption. Whether this will ultimately cause them bottom line trama will be determined later in life. But one must only look at the economic trend in america as a whole to take a guess as to where this is going.
America is becoming a service industry economy and losing its development and manufacturing roots, those jobs are being shipped oversea to asian companies that care more about making product then protecting copy rights. The cards that history played out however means that America still has trillions in wealth and the world's economies will continue to market heavily to americans to buy their products. Until that money dries up and their attention turns elsewhere. Once that occurs you won't see Toyota putting plants in Indiana to demonstrate how many local jobs it produces. It will put them in South America where the labour is half the price.
As I see this is just another example of how American values of fairness, quality, openess and honesty have been lost in the boardroom and consequently the world is turning elsewhere.
Hillbilly1980(damnit what's my password)
1) Form a consortium of major Linux vendors to build and maintain an exhaustive but relatively friendly Hardware Compatability List (HCL).
2) Spread the word that if users don't consult the HCL before purchasing new hardware, they risk a lot of compatability headaches.
3) Invite hardware OEMs to participate directly in maintaining their corner of the HCL. Under each model listing, provide a button to send user feedback (or petition) to the hardware vendor.
4) Watch as hardware vendors begin to take Linux drivers much more seriously, due to constant and coordinated pressure from consumers. Vendors will get a clear message that the days of the haphazard "plug-n-wish" habit are over, since users will avoid buying their products of questionble compatability in the first place.
OS vendors must work to keep their patrons informed about hardware suitability. There is no other way around it in the near-mid term, and we will never get to the point where most OEMs automatically accommodate Linux unless a sturdy bridge is built to organize and convey the users' purchasing interests.