| |||||||||||||
The ipw3945 projectThe ipw3945 projectPosted Mar 2, 2006 10:07 UTC (Thu) by eskild (subscriber, #1556)Parent article: The ipw3945 project
This would seem to be one of those cases where the software community can prove its, for lack of a better term, "ethical values" by *not* messing with key parameters. The radio frequency restrictions in different parts of the world usually exist for good reasons, such as not interfering with other devices, and it would be problematic if someone released software that violates local requirements/restrictions, just because they'd then be able to play some game or browse the internet from further away.
The main issue is simply that we cannot see/feel radio waves. Thus, we cannot intuitively determine whether we're creating problems for others. It's much simpler if somebody is actually stumbling in the mess of cat-5 cables we've strewn all over the floor.
Here's to hoping.
(Log in to post comments)
The ipw3945 project Posted Mar 2, 2006 11:30 UTC (Thu) by cate (subscriber, #1359) [Link] I want a open source driver. I want to see the code. I want to see what restriction apply in my country.If the code contains a warning: "Check with your country rules, before to modify this parameters", it is fine for me, but why hide all the thing?
Anyway, the frequency and max power should be standardized. When I move abroad with my laptop, I never tell my laptop that I'm in an other nation. (I think I cannot do it).
The ipw3945 project Posted Mar 2, 2006 11:40 UTC (Thu) by gypsumfantastic (guest, #31134) [Link] As far as I can tell, the "driver" is open source. Admittedly there is a microcode blob (not part of the kernel at all, thus not linked), and an easily-straced daemon which is non-free, but this doesn't seem especially onerous at all because;
1) The microcode blob is not part of the kernel or its device infrastructure, and is not maintained by the kernel developers. It's simply using the kernel as a piggy-back loader mechanism to get the device started. To me, it's no more or less irrelevant than the absence of source code to my PC BIOS.
2) The daemon is easily reversed-engineered, barring legal restrictions. And the legal restrictions probably aren't Intel's fault, or if they are, it's the fault of the legal department covering their asses a bit too much. But covering asses is what legal departments do.
The ipw3945 project Posted Mar 2, 2006 13:41 UTC (Thu) by nix (subscriber, #2304) [Link] I want to see what restriction apply in my country.For that, you surely want to look at the appropriate regulations/laws, not at (possibly buggy) code, whether free or not.
The ipw3945 project Posted Mar 2, 2006 15:12 UTC (Thu) by danm628 (subscriber, #5995) [Link] There are several reasons your notebook's WiFi link works in multiple countries. The simplest reason is that most countries use the same 2.4GHz IFM band, so the odds are that your device overlaps the allowed spectrum in the country you are visiting. This is why most older devices work when in different countries. Of course there is no check that the device complies to local regulations. All countries (or most -- there may be an exception I don't know about) use the same band but they do have differences in the size of the band and the allowed transmit power levels.
Newer devices support 802.11d which allows a 802.11 STA to receive regulatory settings from a 802.11 AP. So your notebook will automatically conform to the regulatory domain defined by the AP.
The ipw3945 project Posted Mar 2, 2006 11:33 UTC (Thu) by gypsumfantastic (guest, #31134) [Link] That's all very well, but one might hope that "we" could be trusted, or at least the distros and kernel devs could be trusted by Intel, not to screw around with the spectrum in this way.
Still, if there are regulatory and contractual reasons why Intel cannot release the source from this code, providing it notably as a user-space daemon with an implicit "please us strace to provide a GPL replacement" seems a neat little hack around these restrictions.
I assume that issue of microkernel blobs being distributed with (not LINKED with) the kernel is now a non-issue? Except maybe Debian, I dunno.
Intel are playing pretty nicely on the driver front of late, wireless and graphics, and are to be commended, up to a point. No, I'm not gonna get all Stallman on anybody's ass. Sometimes a sense of pragmatism should prevail, and when it comes to having a working wireless, I'm prepared to make that concession.
The ipw3945 project Posted Mar 2, 2006 14:55 UTC (Thu) by kmccarty (subscriber, #12085) [Link] I assume that issue of microkernel blobs being distributed with (not LINKED with) the kernel is now a non-issue? Except maybe Debian, I dunno. Even in Debian, people appear to be perfectly happy to include these firmware binary blobs in non-free, as long as the license to distribute them makes sense. (For instance, a binary blob licensed under GPL is useless since the GPL specifically requires such binaries to be accompanied with "the complete corresponding machine-readable source code" when distributed. A BSD-type license would be OK though.) The only major remaining issue seems to be how to make these non-free packages available to the Debian Installer in cases where they are needed by required hardware.
The ipw3945 project Posted Mar 2, 2006 21:22 UTC (Thu) by iabervon (subscriber, #722) [Link] I'm amused by the idea of having it on the card's driver disk. I mean, it has to be there for the Windows drivers, and they could just split it out into a separate file in some useful standard format (like ihex). Of course, that's kind of annoying (since you'd have to swap CDs mid-install), but I like the idea of needing a binary file that can be used on any platform, architecture, etc.
|
|||||||||||||