OpenBSD Ahead of Linux for Wi-Fi Drivers 256
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.'"
Ha, wireless BSD (Score:5, Informative)
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 [sweex.nl]. 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.
Re:Ha, wireless BSD (Score:5, Interesting)
Re:Ha, wireless BSD (Score:2, Informative)
It does make it a PITA if you want to use a network you have no control over, but the OpenBSD crowd are like that sometimes.
Yes, it does... but it still won't keep me from financing them. They have an excellent server platform and I just delegate the wireless functions to embedded devices. It just keeps me from becoming a desktop/laptop OpenBSD user, but I don't think that it's their target.
Re:Ha, wireless BSD (Score:2)
Re:Ha, wireless BSD (Score:5, Informative)
Re:Ha, wireless BSD (Score:3, Interesting)
Re:Ha, wireless BSD (Score:3, Informative)
This how-to [advogato.org] implies that reverse engineering "for purposes of interoperability" is legal in many places, but that's just one reason people reverse engineer stuff. With legal limits on what and when you can reverse engineer products, it's definitely possible to be sued for it. And successfully sued if you're violating the law (wheth
Re:Ha, wireless BSD (Score:3, Informative)
Re:Ha, wireless BSD (Score:3, Informative)
Re:Ha, wireless BSD (Score:2)
Re:Ha, wireless BSD (Score:2)
Re:Ha, wireless BSD (Score:3, Informative)
in other news... (Score:2)
Re:in other news... (Score:3, Insightful)
very good. we need opensource supporting all sorts of hardware. only this discussion is in regards to WiFi support.
Linux developers are just as interested in getting opensource drivers just as the next guy. We're all in the same ship.
i don't see where the flame is. the OpenBSD folks want open unencumbered drivers (hence the 3.9 blob theme [openbsd.org]) while the Linux folks have NDIS wrappers, blobs and other such hacks. it's fact. no need to get
Re:in other news... (Score:2)
There is no single standard `OpenBSD folk' and no single standard `Linux folk'. Both camps are made up of large numbers of people who each want something different.
Of course, OpenBSD is a much smaller market than the Linux market, which is probably part of why binary blobs just aren't availble for it at all -- the hardware developers just ignore Ope
Re:in other news... (Score:5, Insightful)
OpenBSD doesn't have any blobs because the project's leaders will not consider using them. What's the point of having an open source, audited, secure operating system if you allow arbitrary blocks of binary code into the kernel?
The reason OpenBSD doesn't have blobs is not because of their size -- they could port FreeBSD blobs in easilly. The reason is that the project is focused on quality. Their view is that quality and openness go hand in hand. Can't have one without the other. See this interview with Damien Bergamini, who implemented a driver for the Intel 3945 802.11abg NIC without any of Intel's blobs. [kerneltrap.org] The OpenBSD driver is considerably fewer lines of code than Intel's. Because its simpler, its easier to audit, and easier to find bugs in. Of course, you can't find any bugs in Intel's driver because you can't see the source code. Not because the Intel driver is bug free.
Re:Ha, wireless BSD (Score:3, Informative)
This is not the fault of the operating systems, it's the concrete.... One doesn't have to be a genius to figure that out.
My parents have a wooden house and the same Linksys WPA. With my network adapter I can go anywhere and have a perfect
Take Action (Score:3, Insightful)
Sometimes, like at this point, it's the right attitude. They better take action soon, or openbsd will make them look like a joke.
Re:Take Action (Score:2)
Oh, puh-leez. You think Red Hat & SuSE are going to drop Linux and pick up OpenBSD, just because OBSD has better wireless support?
Re:Take Action (Score:2)
I've thought for a while that it would be nice if somebody based in a nice, free jurisdiction (Sealand or similar) put together a "Functional Linux" disto. Something that ignored all the artificial, non-technical barriers that make Linux a bit of a PITA to install. Built in MPEG encode and decode. Built in eBook decryption. Built i
Re:Take Action (Score:3, Insightful)
Re:Take Action (Score:2, Insightful)
Sometimes, like at this point, it's the right attitude.
I second this. IP owner are kinda terrorists (presuring gvt agencies, senates, parliaments, etc), and succeed well in spreading fear. There's lot of irrational going on this matter:
OpenBSD supported wireless chipsets (Score:5, Informative)
You heard it here first... (Score:5, Funny)
Linux is dead. Now, when will BSD be ready for the desktop?
And pretty soon... (Score:2, Funny)
Next year is the year of BSD on the Desktop (Score:2)
Wait wait wait... (Score:2)
Re:You heard it here first... (Score:2, Informative)
yay for BSD (Score:4, Interesting)
Re:yay for BSD (Score:2)
Re:yay for BSD (Score:2)
Re:yay for BSD (Score:2)
GP wrote overseas not over-the-seas!
Re:yay for BSD (Score:3, Interesting)
(Further, if clean room engineering is the de facto standard for docu
You can help end this argument (Score:5, Insightful)
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
Re:You can help end this argument (Score:5, Interesting)
> Of course really free drivers that let us extend devices are better.
It would be helpful if the Linux developers would be more supportive
of OpenBSDs work on getting hardware manufactures to release
documentation that is not under a NDA. When OpenBSD had the campaign
for release of wi-fi chipset docs, it seemed that the Linux developers where
sitting on the fence.
Re:You can help end this argument (Score:2)
Re:You can help end this argument (Score:2)
on giving public recognition for this (2004 FSF Award). I do
not imply that Linux developers does not care in general.
Re:You can help end this argument (Score:5, Informative)
But FSF aren't the Linux developers. If you ask them, they will be very adamant about that.
Bruce
Re:You can help end this argument (Score:2, Insightful)
i can hardly imagine theo was ever supportive of the idea of shipping a bsd-licensed blob with openbsd
Re:You can help end this argument (Score:3, Insightful)
In fact there were two differents campaigns goals, about two very different kinds of "blobs":
Re:You can help end this argument (Score:3, Insightful)
Bruce
why not ask for permission first? (Score:2)
In the cases where they are not directly selling a driver, you may be able to get written permission to reverse-engineer the company's binary driver. Even
new Slashdot software... (Score:2)
Re:You can help end this argument (Score:3, Interesting)
Yes you could make cards that enforce the legal limits of power and frequency but th
Re:You can help end this argument (Score:3, Informative)
Bruce
HCL: A strategy to get off the driver treadmill (Score:5, Interesting)
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.
Re:HCL: A strategy to get off the driver treadmill (Score:2)
Just two flies in this otherwise tasty bowl of soup though.
1. The makers haven't the manpower to do anything but wholesale deletion of the messages that would be generated by such a setup. They would be forced to resort to that because their mail servers hard drives will be filled to 100% with unread messages eventually. I have serious doubts that very many of them would even have multlingual employees who could translate our rantings
Re: (Score:3, Interesting)
Re:You can help end this argument-Buy foreign (Score:2)
Re:You can help end this argument-Buy foreign (Score:5, Insightful)
Yes, that would be excellent. How do we get there? OpenCores.org has the start. However, all of the gate-arrays that they have to work with have a proprietary bitstream format and thus they require proprietary tools to program them. We need an Open Source gate-array to facilitate Open Source hardware. Initial full-custom full-wafer mass fabrication cost is about $1 Million. At that point, you can get the parts down to a reasonable price. You can do small runs in MOSIS (or whatever they have these days) to make sure the design works before you go that far.
I figure this is at least $2 Million to get done. We need good hardware designers and people to help write the grant. If I can hook up with such people, I'll do whatever I can to help. I don't have the hardware expertise to lead this, or I'd already be started. Any volunteers? I'm quite serious.
Bruce
Re:You can help end this argument-Buy foreign (Score:3, Informative)
Please don't forget the software, as most intelligence for programmable logic is contained there. Developing a wafer for an FPGA is easy compared to writing synthesis/P&R software for it. Automatic place and route is a really hard problem [wikipedia.org].
I'd double that, and allocate most of it to synthesis/P&R software. Altho
Re:You can help end this argument-Buy foreign (Score:2)
One is place-and-route of the full-custom design itself. We might have to use proprietary software to make the mask. I'm not insisting on starting from first principles.
The second is compiling VHDL to the Open Source bitstream. In this process you have to decide how to make the requested logic by interconnecting the raw logic blocks of the gate array. My impression is that Open Source does exist to do at least part of this job. I
Re:You can help end this argument-Buy foreign (Score:3, Interesting)
Place-and-route for the logic to load into the device.
I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance [lip6.fr]), but I'm not aware of similarly licensed P&R software targetting programmable logic. And even if it were to exist, because the problem is so very hard I don't think it's going to be any goo
Re:You can help end this argument-Buy foreign (Score:2)
An interesting project (sadly now discontinued) was MPGA [archive.org]: an FPGA in programmable logic. That's a very nice way to develop and test various techniques for implementing programmable logic devices. Probably a lot cheaper than having multiple mask iterations too.
Re:You can help end this argument-Buy foreign (Score:2)
Thanks
Bruce
Re:You can help end this argument-Buy foreign (Score:2)
Also, providing a way to do manual place-and-route and saving the resulting component locations in a separate file could go a long way. Developers could then use the automatic P&R whilst developing (and just live with the speed hit) and layout (part of) their design manually when they're done with the logic itself.
An interesting thing about HDL code wrt. "real" software is that it doesn't get
Re:You can help end this argument-Buy foreign (Score:2)
Yes there is [ghdl.free.fr].
Re:You can help end this argument-Buy foreign (Score:2)
Re:You can help end this argument-Buy foreign (Score:2)
Re:You can help end this argument-Buy foreign (Score:3, Informative)
Re:You can help end this argument-Buy foreign (Score:3, Interesting)
Does anyone know if there are any plans/projects out there to build an actual free HDL synthesizer? Something that can go from the Verilog or VHDL to a netlist? It seems that's kind of key to all of the "open source hardware" projects; without one it's like the FSF in 1986, before gcc. You can write all the code you want but doing anything with it requires finding someone with the right commercial software.
The concept of 'hacking hardwar
Open Source Hardware (Score:5, Interesting)
But calculating these values isn't enough if you're designing anything of high complexity. You then really need CFD software to model how the heat will flow around your design. It's easy to build something that is quite incapable of remaining within temperature limits.
When building network interfaces, other problems creep in. You have no control over whatever you connect your device to (wirelessly or wired) and so must provide suitable tolerences. You also have potential problems from interference generated from within the device itself. A wireless network card that jams itself is of very little use.
I'm not saying this is impossible - the University of Manchester uses Open Source tools for designing async microprocessors which are suitable for cell phones, so obviously it's possible. It has been done. The problem is in moving from "possible" to "practical". That is an area that looks interesting and - as programmable computable devices become more powerful - more open to experimentation.
One of the problems with commodity hardware is that the only reason it is cheap and useful as a commodity is that it is ultra-generalized and therefore inefficient at any given task. As such, it should be very easy to design things which are more specialized and more efficient, even without a multi-billion dollar budget. Most of that budget is going to be in cramming all possible features onto as little silicon as possible without causing a meltdown. Microcomputers were buildable because no individual user really needed the full power of a mainframe. I could easily see the next stage being people designing components and cards that aren't perhaps equal to AMD's or Intel's latest mega-product but which are perfectly good for a special-purpose embedded device.
Is this likely? I don't see why not. The 65I02 is a popular microcontroller. Yes, that is a more modern 6502 processor, and 6502s are NOT rocket-science. Open Cores is already well past the simple design of a 6502, and probably more than capable of designing fairly decent control systems with Open Source tools alone. Once you get a cottage industry going with Open Source hardware, then more advanced tools will inevitably follow.
Re:You can help end this argument-Buy foreign (Score:3, Interesting)
I take it you mean as in programmable logic? That's not much of a solution either. You still need good documentation, as reverse-engineering VHDL/Verilog code is hard (speaking from experience here).
What's maybe interesting to note here is that most asian hardware manufacturers are rather open about their hardware documentation, notably ralink and realtek [theaimsgroup.com]. Companies like intel and texas instruments still don't want to cooperate. Something to keep in
OpenGraphics project (Score:2)
We're working on it. The OpenGraphics project [duskglow.com] is working on an open-architecture GPU which will have BSD-licensed drivers, and GPL'd board schematics and artwork.
There's nothing stopping another group of hackers setting up similar projects: OpenWireless, OpenSATARaid, ...
Especially since the OpenGraphics project will be bringing out an PCI card with a big FPGA on it soon (OGD1). Although it'll be primarily aimed at development of the OGA gra
Re:OpenGraphics project (Score:2)
Thanks
Bruce
Blob is bad! (Score:3, Insightful)
I really hope the OpenBSD group's steadfast stance on "blob" is maintained. The Linux guys, who overall don't seem to mind blob, sound like they're starting to see the light. In the end it can only be good for all open source, not just OpenBSD.
Re:Blob is bad! (Score:5, Informative)
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)
Re:Blob is bad! (Score:3, Funny)
Bootable Distro? (Score:2, Interesting)
Re:Bootable Distro? (Score:3, Informative)
http://g.paderni.free.fr/olivebsd/ [paderni.free.fr]
Haven't used it myself, however.
Re:Bootable Distro? (Score:2, Informative)
I'm sure there are others.
Re:Bootable Distro? (Score:2)
Search those sites, and I'm sure you'll find it.
confused... (Score:3, Interesting)
Is there some kind of problem with that?
Re:confused... (Score:2)
Not that it's -extremely- hard. But few code monkeys can do it right while maintaining the high kernel code quality standards.
Re:confused... (Score:2)
Re:confused... (Score:2)
Re:confused... (Score:3, Insightful)
Of course, if this is really the reason, the OpenBSD drivers are probably illegal f
Re:confused... (Score:2)
Re:confused... (Score:2)
So, so long as the person writing the spec is in a "safe" jurisdiction, and the person implementing it, if not in a "safe" jurisdiction, didn't coordinate with them (which might be illegal in their "unsafe" jurisdiction), then this is probably legal.
Re:COPYRIGHT is stopping them. (Score:2)
Re:COPYRIGHT is stopping them. (Score:3, Informative)
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* R
Open Secrets (Score:5, Insightful)
Re:Open Secrets (Score:3, Informative)
No. Finding someone "with the chops" and interest simply isn't easy. There are simply tons of projects in the open source world that would be done very quickly if someone with the skills would do it. Instead, you have to wait around for someone with skill to get that particular itch.
Re:Open Secrets (Score:2)
Even if you found someone who'd be willing to work on them, chances are they won't have examples of every different wireless card available for testing. However, one-by-one, I think yes, the lead-time could easily shrink. But chances are you'd have to find a new developer for each wireless chipset, unless you're willing to donate hardware.
(It would be cool if there was some kind of pool resource that p
Re:Open Secrets (Score:2)
And even if so, doesn't that demolish the excuse that Linux lacks drivers because of proprietary tech blocking the path? Rather, the reason is that Linux developers just don't produce the drivers they could.
I don't believe either of those propositions. That's why I believe the BSD lead will be short-lived.
Re:Open Secrets (Score:3, Insightful)
No, it's that this has been an "itch" in the OpenBSD community for quite a while now. Linux developers simply chose to focus their attention elsewhere, since their wireless cards were working fine...
Re:Open Secrets (Score:2)
Or for someone with the bucks to pay someone to scratch their itch.
ndiswrapper for *BSD? (Score:3, Interesting)
If they can do this for wi-fi cards... (Score:2)
Re:If they can do this for wi-fi cards... (Score:2)
Re:This seems bogus (Score:3, Interesting)
I think the problem is that the BSD code may not be considered "clean room" by the Linux people, hence it's "dirty" (not my opinion) and not to be touched. You can probably trace a lot of this obsession to the SCO lawsuit.
Re:This seems bogus (Score:3, Insightful)
But developing Linux drivers with documentation under NDA is popular, though.
Re:This seems bogus (Score:3, Insightful)
Re:This seems bogus (Score:2)
But the GPL source is still there, and that counts for a hell of a lot.
Re:This seems bogus (Score:2, Informative)
But still, if the driver was developed under NDA and is bloated of "magic numbers" (as often in drivers under NDA, the implementation can't contain too much comment/infos), practicaly, we're near to loose one of the fundamentals rights supposedly granted by the GPL: the right to modify and re-use it. Well, you have this right, but you can hardly use it.
In practice, source code designed to hide IP secrets is in-between normal source code and binary exec. That's why, by
Re:This seems bogus (Score:4, Interesting)
Re:This seems bogus (Score:5, Insightful)
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.
Re:This seems bogus (Score:3, Informative)
source changes by defining the linux interfaces as macros and
inlines. i think the only thing that didn't just fall out was
the bit-sense of PAGE_MASK.
i don't see any reason why you couldn't do the same thing in the
other direction.
Re:This seems bogus (Score:3, Insightful)
Re:Almost on-topic! :) Wireless USB on Linux? (Score:2)