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)
Far too many people have a careless 'U.S.A. laws suck, merge it anyway' attitude
Sometimes, like at this point, it's the right attitude. They better take action soon, or openbsd will make them look like a joke.
can be found by reading the man pages
Linux is dead. Now, when will BSD be ready for the desktop?
Weaselmancer
rediculous.
Well as the article itself says the clean room method isn't required by law. It would seem to make sense then to drop it until it is required by law, or alternately host your distribution overseas and have the developers working on the drivers be non-US residents as well, so that you are less vulnerable to US law. Wi-Fi problems are one of the reasons this laptop doesn't run Linux, although BSD is sounding cooler and cooler.
Philosophy.
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.
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.
Trolling is a art,
Fantastic, I just read through the supported chipsets and my laptop's onboard chipset is on there. So now I want to test it. Are there any decent bootable CD distros (Knoppix style) of OpenBSD that I could simply download and play with? If so I'd be more than interested in getting Windows off of it and cruising with BSD.
I'll be honest, we're throwing science against the wall to see what sticks. -Cave Johnson
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.
Trolling is a art,
I think it is a combination of laziness and philosophical issues. Linux is being held back by both unfortunately.
Jesus was a compassionate social conservative who called individuals to sin no more.
ndisWrapper isn't counted because the thing it's wrapping around is a binary blob. That's basically the opposite of a BSD driver.
"[Regarding the 'cloud,'] ownership was what made America different than Russia." -- Woz
So what exactly is stopping them from download ing the BSD drivers and making a linux driver from the BSD sourcecode?
Is there some kind of problem with that?
Do not look at laser with remaining good eye.
But developing Linux drivers with documentation under NDA is popular, though.
...as would the zombie apocalypse.
Paul Grosfield - the quicker picker upper.
If those OpenBSD drivers are under the BSD license, doesn't that mean anyone (except the very few under some kind of other legal constraint for some other reason) with the chops can port them to Linux? And those chops don't have to be as tight as the original BSD coders. Shouldn't the lead be very short-lived?
--
make install -not war
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?
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
Bruce Perens.
netcraft will confirm it.
I have freaks! I did something right...
There are many things that don't work with ndiswrapper. Wireshark (formerly Ethereal) is one.
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. Companies like intel and texas instruments still don't want to cooperate. Something to keep in mind when purchasing new hardware perhaps.
Error: password can't contain reverse spelling of ancient Chinese emperor
> Drivers developed under the constraints of an NDA are usually released as blob, no? Not always. There are several drivers in the Linux kernel with docs under NDA. UltraSPARC III support, for instance. Drivers written with docs under a NDA are the open source equivalent of a blob.
Drivers written with docs under a NDA are the open source equivalent of a blob.
But the GPL source is still there, and that counts for a hell of a lot.
"I don't know, therefore Aliens" Wafflebox1
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.
I'd double that, and allocate most of it to synthesis/P&R software. Although such software obviously needs to be free (libre), I think you really want to pay people to write it or it'll never become useable.
Apart from the sheer amount of work, I have to admit it does sound like fun. Although I only have experience in targetting FPGA's (I've written a couple of microprocessor cores as well as some I/O devices), not developing them myself.
Error: password can't contain reverse spelling of ancient Chinese emperor
i've taken a large linux driver and gotten it running in free with no
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.
i just finished fighting with my PCMCIA WiFi card and ndiswrapper and wpa_supplicant, becasue they only choose to work when they feel like it - everything from Segmentation Faults to perfected working happens from time to time - I guess it's because of the voodoo invloved in making a windows driver run on linux, so i guess i shouldnt complain. but it still begs the question why there's no "ndiswrapper for *BSD drivers", or something along those lines. AFAIK, windows drivers have to have a rather rigid interface (NDIS?), and this might not be the case for the BSDs, but i'd still guess that it should be easier to build a wrapper for other open-source drivers than for windows drivers?
I realize, of course, that many companies supply proprietary Linux drivers, but will not release the source. They don't want to support the Linux code, and they may have 3rd party licensing arrangements that prevent them from opening the source. In many cases though, they are not making money off the driver. TurboPrint drivers are a notable exception.
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 when they will not release the source. Don't overlook the possibility. The worst they can do is say no. But getting such written consent in-hand is a much more reliable way of protecting yourself and Linux, than any clean-room technique.
Hope that answers your question.
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 don't know how good it is.
Bruce
Bruce Perens.
We're working on it. The OpenGraphics project 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 graphics pipeline, it's got a big header on it, so there's no reason it couldn't be used for something else. Accelerating POVRay, perhaps?
Pirate Party UK
As far as I can tell, the new Slashdot software does not prevent the joke posting from coming before the one with substance. :-(
Bruce Perens.
can they also do it with video cards? I'd love to see the day when I can use an open source nv driver and still have a usably fast rxvt.
Place-and-route for the logic to load into the device.
I know of free (libre) VHDL synthesis software targetting silicon (eg. Alliance), 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 (which is gratis for their lower-end devices) for a couple of years now, but it is still being outperformed by more expensive software.
Error: password can't contain reverse spelling of ancient Chinese emperor
OpenCores isn't the only open hardware group. Check out www.opengraphics.org, particularly the OGD1 section. Real hardware engineers are making real hardware, and they're making it OPEN (and libre).
In my experience, My toaster has more good wifi drivers than linux. :P
Yes there is.
Error: password can't contain reverse spelling of ancient Chinese emperor
Has Netcraft confirmed this?
the major advances in civilization are processes which all but wreck the societies in which they occur - A.N. White
That's a simulator. It doesn't create a netlist.
Mad Software: Rantings on Developing So
Error: password can't contain reverse spelling of ancient Chinese emperor
...linux supports thousands of other devices that BSDs doesn't support. Seriously, why a "openbsd ahead of Linux" story written in this way? It looks like some people love to start flamewars between linux and BSD communities or what? Linux developers are just as interested in getting opensource drivers just as the next guy. We're all in the same ship.
(replying to myself is probably a bit of a faux-pas here, but I'll do it anyway)
An interesting project (sadly now discontinued) was MPGA: 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.
Error: password can't contain reverse spelling of ancient Chinese emperor
...and those two are not the only two either: http://openeeg.sourceforge.net/
Yeah, I have a Hawking Technology USB wireless device, but no driver for Linux. :(
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
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.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
I have no idea what you are trying to say, but copyright has nothing to do with it. If I want to take BSD-like licensed code, port it to Linux and GPL it, I am free to do so.
How we know is more important than what we know.
I think that their site is actually http://www.opengraphicsproject.org/
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 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.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
No, it's because they are bad at respecting copyright. :P
No SIG for you!
Thanks
Bruce
Bruce Perens.
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 changed very often. Once a design is done, it's really done, and rarely gets altered. This makes manual layouting a very viable option. As a bonus, it allows end-users to recreate the FPGA image from source without having to wait for P&R.
Error: password can't contain reverse spelling of ancient Chinese emperor
Indeed having it GPL counts a lot.
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 the way, OpenBSD devs never accept and never signs NDA, as stated there http://www.openbsd.org/goals.html for instance.
I have been a linux AND BSD user for a number of years... I'm going on 2 years with just Archlinux alone (man, I love it) and about a year and a half with FreeBSD. I love them both dearly and would never opt for any other distros besides these two. I love the work OpenBSD is doing with the wireless community and I appreciate every bit of it but given my comfortable state with linux/BSD which have become rivals somehow? I guess it's like Pepsi/Coke... they taste the same to me but apparently there is a difference? Eh, ignorance is bliss, right? Anyways... I just do my research before I buy something. Atheros: fully supported under Linux and BSD... Madwifi works flawlessy on both of my laptops both of which running Archlinux and/or FreeBSD. Netgear WG511-T 108Mbps (miniPCI) and D-Link G650 108Mbps (PCMCIA). Perfect examples of two different form factors that work flawlessly either way you go for a price that doesn't make your wallet wish it had "parental" controls on it. Most of the complaints I see are people using chipsets like Texas-Instruments and Broadcom, ralink and realtek... yea no kidding it doesn't work. Sure, some of them are starting to develop some decent drivers out of the realm of Ndiswrapper, but they aren't stable and I wouldn't bother wasting my time... and I hate seeing people complain about it. You get what you pay for (or the lack there-of). Kismet-wireless.net is my Buyers Guide for wireless cards. If its chipset isn't supported here... it's not getting my money.
I have a Xilinx FPGA experimentation/evaluation board. The total cost involved in getting started: $100. I ordered the board itself off of Xilinx's web site, and they offer the synthesis and simulation software (native Linux version included!) as a free download (it's also included in the box). The board comes with a manual, and features a "200,000-gate" FPGA, two serial interfaces (one RS-232 port and a bare connector), a 3-bit VGA interface (I've managed 800x600 so far), a PS/2 port (keyboard or mouse), a number of on-board switches and LEDs, four 7.1-segment displays, and three 40-pin external interfaces. The FPGA can handle internal clock rates in excess of 200 MHz, driven by an external 50MHz crystal oscillator. There's a socket for user-installed crystals as well.
I can't seem to find the original board I ordered, but you can find a much better one (64MB DDR SDRAM! Includes a CPLD on-board! I kind-of wish I'd waited a bit...) for $150 + shipping in their online store. The software can be downloaded free from their website (free registration required).
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat
This is a pretty cool idea. I only have one chip design under my belt (using MOSIS and MAGIC), but it certainly seems feasible.
On the larger scale I'm imagining a "Open Source Hardware Foundation". All documentation required to make a production run of anything they produce would be freely available. It might be possible to get a significant amount of university involvement as students would be able to look at a finished design and drill down to the most basic levels to understand how it works.
If you have a mailing list for this project, put me on it. Your first guess at my email at yahoo.com will be correct.
Life is too short to proofread.
Seriously, if I were you I'd talk to the good folks over at Ubuntu. Last I heard, they were sitting on something like $10 million; maybe you could convince them to develop and release their own wireless card + Linux driver. :)
.
== WolfriderV6 == I'm willing to admit that *I just might* be wrong... Are you??
USB is meant for digital cameras, portable storage and "bandaids" for hardware failures. The fact that USB Wireless and "doesn't work" are in the same sentence doesn't suprise me.
Uhh, it works fine in Windows and Mac OS X.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
reverse engineering, a way to over the shoulder of your classmate in a test....
If they made wireless cards that plugged into your headphone port I'm sure they would work in Windows too... and besides... signal strength is lacking... you can only fit so many antennas on a tiny little stick. Waste of money whether it works or not. Fact remains you can get the best of both worlds in Linux if you go with the right form factor/chipset. There should be no conversation about Windows... this thread is not about Windows and nor should Windows stick it's pimply face in here.
OK, if USB wirless network devices can't have all the antennas, how can PCI cards have all inside especially the onboard ones like in notebooks/laptops?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
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.
Alternatively, ask the author of the BSD-licensed driver for permission to re-use his/her code in a Linux driver, then modify whatever is required to make the code run in Linux. No need for all this clean-room garbage. Actually, it should be pointed out that clean room reverse engineering isn't *required* even if you're reverse engineering the manufacturer's Windows driver. The only reason to bother with it is if you think there's a chance the original author of the driver may sue you for copyright or trade secret infringement, i.e. for copying the code, rather than reverse engineering it. Most of the time, they won't care at all, because few drivers really contain anything worth protecting (video card drivers are a notable exception -- or at least ATI and nVidia think they are).
Also, note that the process Bruce described is not an adequate defense against copyright or trade secret suits. He left out a crucial step in the middle: Have an attorney specializing in software IP law review the specification to verify that no copyrighted material has been copied into the specification. If you're going to bother with the clean-room process, make sure you get the legal review. Further, if you want to be completely safe, don't use a friend because the plaintiff's attorney will point out that the two of you communicate and could easily have passed key information verbally. There's really no good way to fight that accusation unless you can demonstrate that the two teams have never communicated except via the specification document.
Of course, even if you do a perfect clean room reimplementation, that doesn't guarantee you won't be sued. It just means that you'll probably win, assuming you can afford the fight.
So the best thing to do is to let someone in a less litigious legal system do the work. And suggest to them that they reuse the OpenBSD driver (with permission).
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
Actually, the onboard ones usually have an antenna which runs up the side of the screen of the laptop and connects to the miniPCI card. The PCI ones typically have an external antenna connector.
Hey, the Ubuntu project has an all-libre version of the distribution as well. But if you've got hardware you can't support without some restricted stuff that makes you feel icky... I'm not sure what distribution developers are expected to do. Tell users what hardware they should buy so that their distros will work?
+++ATH0
I've tried lots of distros with my usb DWL-122 by D-link and it wasn't until suse (10.0 and 10.1) that it worked without NDISwrapper. Detected, driver installed, and ready to go.
The main improvement in gate-arrays is in density, not architecture, and density is a property of the fabrication process, so we're not really talking about 10-year-obsolete chips.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
Bruce
Bruce Perens.
The USB one (Hawking Technology's Hi-Gain USB Wireless-G Adapter (Model: HWU54D)) I have also has an antenna mini-dish/receiver(?).
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Dead on... miniPCI use dual U.Fl connectors, most often to seperate antennas attached to the side of the laptops frame. Sometimes in addtion to ones already onboard.
PCI cards rely mainly on external antennas most commonly with RP-SMA connectors. I have the following cards at home and sitting maybe 20 ft away from my router heres what the signal strength is
atheros miniPCI 108mbps (netgear wg511-t): [XXXXXXXXXX]
atheros pcmcia 108mbps (dlink g650): [XXXXXXXXXX]
prism54 pcmcia 108mbps (netgear wg511-t): [XXXXXXXXXX]
orinoco pcmcia w/ 7dbi antenna (gold): [XXXXXXXXXX]
prism3 pcmcia (dlink 650 rev P1): [XXXXXXXXX-]
broadcom miniPCI (Broadcom A/B/G): [XXXXXXXX--]
admtek PCI w/ 7dbi antenna (dlink 520): [XXXXXXX---]
My PCI card is absolute crap... the only PCI card I have EVER LIKED was the 2wire PCI card. I wish I could get my hands on one for a relatively decent price, I'd like to play around and see what kind of chipset it has.
I can't imagine having to deal with that everytime I wanted wireless. Simple integrated type solutions that are less protrusive are much more appealing (minipci/pcmcia). If I want to move my laptop from desk to desk I want to be able to do it with one hand and not have to juggle... I just don't understand the appeal of USB wireless devices.
I don't think madwifi worked for my D-LInk DWL650+. Got it to work fine with airlink101 wireless cardbus adapter though (atheros).
Well, this was on desktops and I use between multiple computers.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Do you know about TAPR?
Not until today. It looks like an interesting organization.
Kit building is sort of a lost art these days.
One one hand, I wish more people built kits. On the other, I suspect any packge type used for a decent-sized FPGA would not be (easily) hand solderable.
I suppose the first thing to do would be to develop a manifesto. To ask, "What would hopefully be achieved with an open-source FPGA?"
I'm finding myself weighing the benefits of this vs. "open" hardware using proprietary FPGAs.
Not that I think the effort is not justified, but trying to figure out what the goal is. I have some ideas of my own, but I'd like to hear what yours are.
Life is too short to proofread.
... did you just "foe" me because I advocated making friends with recalcitrant hardware companies?
Lame, man.
By running with closed source blobs crammed into their systems they make the hardware companies feel secure in their choice to distribute those blobs and encourages them to not give proper documentation or open source drivers.
This is unlikely to happen. What is MORE likely to happen is that Linux will continue to grow on both the desktop and server, and soon enough all hardware companies will start documenting their products properly for Linux.
How many hardware companies REALLY provide open-source drivers? There is a big problem with doing this for some companies, especially graphics ones, because doing so exposes some of the trade secrets that allows them to produce their hardware in the first place.
Hardware is not software. There is a fundamental difference between the business model of selling each.
+++ATH0
You're allowed to port, but you're not allowed to relicense it.
It *is* ready for the desktop. I have been using FreeBSD on my notebook for three years as my primary desktop computer. Because: FreeBSD Just Works(TM).
You sure are. You're not allowed to remove their copyright or their list of conditions, but there's nothing in the license that says you can't add more, even ones that negate theirs.
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.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
* Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
* And you have to give me $400,000 per copy and say "Linux rules" 100 times.
Perfectly legal.
How we know is more important than what we know.
Ummm, it works just fine for me under FreeBSD (I have one of those Linksys wireless cards with speed booster crap on it...) using ndis wrapper... Same goes for anything else, the applications don't give a rats ass if it's using NDIS. Now, if your Windows drivers suck ass and don't support certain hardware features then it's the fault of the Windows drivers you used when you converted them not NDIS.
To make the average developer able to research various approaches to this, an open FPGA architecture needs to be available, of which every single part and feature is documented and understood. There's no such architecture yet.
Getting truly open PC-hardware out of this a merely a nice short-term goal.
Just because Xilinx' and Altera's toolchains are gratis (for low-end devices) right now, that doesn't mean they'll be gratis in the future. Also, because of its closed-source nature, such software cannot be studied and improved upon by its user, making him/her forever dependent on the device maker.
Finally, the portability of HDL code is greatly exaggerated. Sure, simple stuff like asynchronous logic and flipflops usually are portable, but once you start using more specialised features of an FPGA (eg. blockrams or embedded multipliers), you'll find every device maker's toolchain has its own quirks regarding component inference. So in practice, a HDL design is pretty much locked to a few specific devices.
No thanks, I don't do NDAs.
Error: password can't contain reverse spelling of ancient Chinese emperor
First of all, let me say that it's an honor to reply to The Real Bruce Perens.
Xilinx actually does publish at least some information on their configuration bitstream formats. See, for example, application note XAPP452 for the Spartan-3, or UG071 for the Virtex-4. I have not studied them in enough detail to know whether they are complete; it is clear that they have to be read together with other documentation on the device architecture to make any sense at all.
They developed advanced wireless driver framework, which will in some time be ready to be included in linux kernel.
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.
I always thought reverse engineering was something that is very frowned upon. Is Ben Affleck behind this?
geek n performer who performs morbid or disgusting acts, as biting off the head of a live chicken
I suppose that from the accompanying documentation and from incremental reprogramming of the device one might figure out what's in each frame.
Thanks
Bruce
Bruce Perens.
Kubuntu Dapper works quite well with my Asus 167g (wireless usb) using the native ralink driver not ndis wrapper...
Its not quite plug and play. I do have to enable it in network settings after I plug it in.
Adapters using the Ralink chipset generally work quite well. I would specifically recommend Minitar (instrumental in the creation of gpled ralink drivers) and Asus (usb driver)...
What do you do about graphics? Neither ATI nor NVIDIA provide OSS drivers.
+++ATH0
Reading this article I was wondering what the problem with reverse engineering code was. I didn't see there being a legal issue and as others pointed out: there is no illegality involved.
The only time when a cleanroom approach is necessary is if the source has been published as the original IBM BIOS was. Forgive my memory if I forget the exact entity, but I believe it was Phoenix Technologies that created their own BIOS to compete with IBM's BIOS. In that case, IBM had published the code in their 3-ring, hard-bound BIOS tech reference.
In the current situation, no source code has been published. The vendor is a hardware manufacturer and provides the binary-driver to enable their hardware to be something more than an ugly paper weight.
Now it comes to trying to use the same piece of hardware, but under a different OS. Even the DMCA has a clause allowing reverse engineering of "access control routines" when the purpose is to provide compatibility. Reverse engineering a DVD access routine, was problematic because it did alot more than simply allowing compatibility, it also allowed circumvention of region lockouts, and would allow skipping of "mandatory" sections on the DVD. The latter was considered bad because they want to enable advertising sales on home DVD media, among other reasons.
However, there is no "content-control-industry" behind network drivers, the binary drivers are not protecting copyrighted material. So the two situations are completely different.
Secondly, providing an alternate driver for hardware manufacturer's device doesn't create economic harm to the harm to them, but conversely, directly enlarges their potential market and if anything, creates economic benefit to the OEM.
Unless a party (like the OEM) is "harmed" in some way (usually economic), there is no basis for a lawsuit. A plaintiff must show harm or damage in order for them to have grounds for a lawsuit against another party.
Unless someone can think of a situation where an alternate OS driver would create some economic damage to the hardware manufacturer, I submit, that talk about "legal issues" is complete FUD.
To be concerned about nebulous "legal issues" for a situation like this would be akin to worrying about legal issues in creating computer aids for the "visually impaired" that magnify book text, or for the blind that allow a hand-held scanning wand to be passed over text that speaks the words under the wand.
In both situations, you are enabling a larger class of people to access the object that the object-creator (OEM, publisher) is selling.
To me, creating fear, uncertainty and doubt, by claiming "potential legal issues", might as well be applied to going to the bathroom wherein you decide you can't, because of "potential legal issues".
Where's my FUD-B-Gone Spray?...
-l
I'm fairly certain I'm not stupid. I'm also growing increasingly more certain that you're mean.
Beyond that, however, I *am* interested in having a serious conversation about this. How do you propose to build a hardware system out of existing components that uses all-libre drivers?
+++ATH0
"If they made wireless cards that plugged into your headphone port I'm sure they would work in Windows too... and besides... signal strength is lacking... you can only fit so many antennas on a tiny little stick. Waste of money whether it works or not. "
...
The proxim devices I have are not those little stick ones; they look about like a RadioShark (perhaps 5 inches high). They're frankly a bit bulky! But they were also only $10 each, and contain an Orionco Gold (or is it Silver?) I forget card inside.
USB is a bus that's perfectly well suited to (current) typical wireless bandwidth, and has (to me) one big advantage, or at least it did when I got these devices, which is that I have two laptops with broken PCMCIA slots, and this seemed a good way to give them wireless network access. (Or network access at all, for the one without integrated ethernet.) Also, can be suction-mounted on the roof of my car, which I like -- USB cables are relatively low loss; pigtail connectors aren't, and they're expensive, and generally take expensive cards to work with
Maybe SUSE will work 'em, as another poster suggested.
Cheers,
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
Built-in and unobtrusive certainly are nice, but the laptops I hoped to use these on are old, predate minipci. One has a busted PCMCIA slot (the other's may yet work, but it's flakey). And there's a specific usage scenario I got them for, which I'll admit is pretty esoteric: I used to drive around a lot, editing Slashdot from the front seat of my car at (among other places) many locations of the Flying J truckstop chain, and wanted a USB wireless dongle that I could either mount on top of my car's roof or mount in a dish (or both). (See http://www.usbwifi.orcon.net.nz/) USB having no appreciable signal loss would make my parking location less important than my antenna placement.
(Frustratingly enough, the reason that PCMCIA slot is busted, though my own fault, was because I thought I'd be clever and get a 200mw PCMCIA card (Engenious I think is the brand name) and external antenna -- which got tangled underneath and then torqued the slot when I stupidly moved the thing without paying attention to the antenna.)
timothy
jrnl: http://tinyurl.com/c2l8yr / foes: http://tinyurl.com/ckjno5
How is the possible?
As I understand it, you're allowed to redistribute the code, but you are not allowed to relicense code whose copyright you do not own. If the original owners wanted to relicense sure, but you sure aren't allowed nor is anybody else.
There's absolutely nothing prohibiting you from adding clauses to the copyright notice because the copyright notice does not say you can't. It's that simple.
How we know is more important than what we know.
A comment about Ubuntu networking in a story about BSD driver support, with a title that basically says "I'm not going to be talking about the topic of the story, but..."
No comment ever needs replying to.
Slashdot automatically blocks posting comments after two weeks of silence in a story. Until then, if I chance on something and wish to reply to it, I click Reply to This and type my thoughts into the handy text box, click Submit, set fire to my hair, and jump out of my window.
Don't have nightmares, do sleep well. Goodnight.