Slashdot Mirror
Intel Releases Linux Driver For Centrino WLAN
Werner Heuser writes "Finally Intel has made their different announcements about
Linux support for the WLAN part of the Centrino technology
become true. Though not yet officially announced
an Open-Source driver with included firmware
is available at SourceForge.
The driver is still experimental and supposed to work
with 2.4 Kernels as well as with 2.6 ones." (See these previous stories for some background.)
This really feels like Intel's finally feeling its stranglehold on the industry wavering a little (given AMD's 64bit success). I'd like to believe that this is going to lead them to start treating us like customers, rather than prisoners. Certainly, this is a nice first step.
Everybody, now this is your chance. Support Intel in their decision to open-source a driver, by buying their product. They are a rare breed.
Occam's razor is the blind faith in the natural selection of least resistance and in universal oversimplification. -- EF
I'm impressed. A real open-source driver from a major company...this shames the NVidias and the Lucents of the world who give stupid excuses for their closed-source drivers.
Looks like I'm going to be sniffing around for a refurbed IBM T41 ThinkPad with Centrino tech in the future.
Knowledge is power. Knowledge shared is power multiplied.
I fail to see how "Finally Intel has made their different announcements about Linux support for the WLAN part of the Centrino technology become true."
when the SourceForge web site clearly states in the first paragraph.
"This project was created to enable support for the Intel PRO/Wireless 2100 (IPW2100) mini PCI adapter. This project is intended to be a community effort as much as is possible given some working constraints (mainly, no HW documentation is available)"
Sounds like Intel haven't helped at all and some enterprising folks have done their own. Kudos to them, shame on Intel.
And shame on Werner and Timothy for getting basic cursory facts right. Unless of course the SF website is failing to give credit to Intel.
[)amien
Given the supposed lack of foresight in their hardware design that most wlan vendors have taken recently (using basically 'soft wlan' cards), it is probably more akin to a 'partially closed driver', in that you probably won't have access to the channel frequencies, adding new network modes (master, monitor, etc). HOWEVER given that, it should allow future patching to the kernel side of the driver to support whatever future interface changes happen to ensure the card won't suddenly become useless.
IMHO, this is what all wlan dealers should be doing... if you can't give direct access to the hardware due to possible legal/FCC constraints, then you should have firmware to handle the interfacing so that you can at least release firmware interface specs, and hopefully be able to cut down on cross development costs by having your firmware patches enhance both linux and windows functionality while stomping out mutual bugs.
They probably can't release the documentation for some reason, however as long as there are a number of intel people on the project _with_ access to the documentation this isn't as huge a problem as it would otherwise be.
This allows the community to help stear the portions of the code that don't require the documentation and to help them properly tie the driver into Linux.
As long as the code isn't a complete mess it will also be possible to get some understanding of the workings of the chip from the code.
I agree that it is not ideal, however it's better than a binary-only driver.
This is a great sign, if Intel starts supporting all of their products under Linux, other vendors will follow suit, and it won't be long before you'll see Lindows boxes alongside the Macs at CompUSA!
Yeah I know pretty soon we might get some linux support from other companies! Like NVidia, 3Comm, Ceative Labs, ATI, Netgear, Linksys, man pretty soon I'm gonna be able to build a sweet linux computer!
*Looks at his own two linux computers*
Oh...
I'd actually be more excited about Intel's decision if they had any products I actually wanted. I don't know of any companies I'd buy from whose products don't work in linux one way or another. Sure some things might not work, but I haven't run into anything in the past 2-3 years that I couldn't get working in linux although setting up my ATI card was a real pain. There are even a few no name devices that I wouldn't expect to work, that just happened to have support since they use the same chipset as like 40 other no name devies.
and that's why it hasn't been announced apart to a list mainly inhabited by developers
Judging by the scope of these variables and the fact that they seem to be docummented right at the top, I don't think anyone could have an issue with that.
In fact, sometimes explaining what a variable means and then using just a one letter name is much more helpful than names like "thisOneINeedToDoThisBecauseOfThat".
Just think of the use of "i" in for loops, no one in the right set of mind would use something like "loopCounter".
It's a bit like in PDE theory, if you use t, then you don't have to bother specifying that t belongs to [0,T] and that it's time - everyone expects that.
Just think of the use of "i" in for loops, no one in the right set of mind would use something like "loopCounter"
Quite, but if you're choosing decent variable names, you would never think of chooseing loopCounter!
What are you counting? That's what the variable name should be.
Iterating over rows in a matrix (or whatever)? then the variable name should be 'row'! Not rowCount or RowNumber or count or r, simply 'row'.
Then row++ makes sense - next row.
Yours Sincerely, Michael.
Not really. Most hardware nowadays contains firmware (modern wireless cards are often just ARM cores attached to a radio transmitter), but in many cases it's in ROM or flash and you've never noticed. Older wireless cards with entirely open drivers (such as the orinocos) had similar quantities of firmware, but the cards shipped with it in flash. Requiring it to be loaded by the OS makes hardware implementation slightly easier, and you can upgrade the firmware along with the drivers without involving potentially risky reflashing.
Would you consider Linux closed-source because on most hardware it requires a closed-source BIOS or firmware in order to boot?
(Yes, I know about LinuxBIOS. It supports a subset of x86 hardware)