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.'"
yay for BSD (Score:4, Interesting)
Bootable Distro? (Score:2, Interesting)
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:4, Interesting)
confused... (Score:3, Interesting)
Is there some kind of problem with that?
Re:Ha, wireless BSD (Score:5, Interesting)
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-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 mind when purchasing new hardware perhaps.
ndiswrapper for *BSD? (Score:3, Interesting)
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 good. If a company is going to put in 25 or more man-years to write a piece of very specialist software, they're going to ask money for it, not release it under the GPL.
Xilinx has been working on their own synthesis/P&R software [xilinx.com] (which is gratis for their lower-end devices) for a couple of years now, but it is still being outperformed by more [synplicity.com] expensive [mentor.com] software [synopsys.com].
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 that would make the device more expensive and frankly give the end user no real benefit except that you can have an open source driver for it.
The real solution is to admit that we live in an imperfect world and provide a stable binary device driver interface for Linux. Hardware providers could then include binary Linux drivers with their hardware. Right now even if a company wanted to include a precompiled driver for a piece of hardware it really is impractical. There is no way of knowing if it will work with what ever version of the kernel the user may have installed. You may say that they should open source the driver but that doesn't change the issue. They could release the driver as OSS but that still will not allow the manufacture of the device to include a precompiled version with the device.
The lack or refusal to include a stable binary device interface is an artificial method too try and force hardware manufactures to release OSS drivers at the expense of the end users.
The fact that Nvidia provided binary drivers shows that it doesn't work.
Just as people with Windows may want or need to run FOSS under a closed source OS. Some people want or need to run Closed Source software under Linux.
I would love to have a 90% free software stack including Linux. Instead of a 60% free software stack under Windows.
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.
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: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 hardware' is an attractive one, but it's hampered by the very high cost of entry. Having a Free simulator is certainly a big step, but I think a lot of people are turned off by the fact that they can't produce a netlist of their design for use on an FPGA without very, very expensive tools. (Although I've seen references [berkeley.edu] to some old [c. 1983] tools published by Berkley on tape for VAX that might still be around.) Unless I'm just confused and you can program an FPGA directly from an HDL program without synthesizing to a netlist first...?
I'd be curious to see someone who's gotten involved in hardware, particularly FPGA, programming give a breakdown of the minimum costs required to experiment and actually fabricate (not just simulate) some circuits. Maybe the perception of high cost on my part is false, in which case I'd be happy to be corrected.
Re:You can help end this argument (Score:2, Interesting)
And yes, commercializers are guilty ; but, to some extent, their user community have a responsability too: they (the users) had means to make commercializers/distros change their mind. They didn't, despite TdR and RMS calls for help.
That's why I'm talking about this here, I want this little slashdot post contribute to pass the message among free software users: we're responsible too. When needed, we should educate our software providers (aka commercializers aka distros), we should tell them that we expect them to play the rules fairly. They'll listen us, we're the user base, and after all, we're also their marketing & PR force.
Re:yay for BSD (Score:3, Interesting)
(Further, if clean room engineering is the de facto standard for documenting compliance with the law, people are likely to assume that the only reason for doing it any other way is to conceal wrongdoing. That attitude may have little to do with the law, but it might have some influence in a courtroom. On that point I'm out of my depth; ask a real lawyer.)
Re:Ha, wireless BSD (Score:3, Interesting)
Deviceescape (Score:2, Interesting)
I'm all for it, ASAP. Practicall all linux wireless dev people agreed on it, so it's just a matter of time.
Porting drivers shouldn't be as hard, while current wireless driver model is seriously lacking.
BSD code could be very helpful for reverse engineering.
Comment removed (Score:3, Interesting)