Post a Comment
PCLinuxOS is the only Linux distribution that I've found which has a ndiswrapper GUI wizard to assist with installing wireless windows drivers on Linux. I found it remarkably easy to get a D-Link DWL-G510 wireless card working on PCLinuxOS than compared to using the same model with OpenSUSE.
I do agree it would be better to have native wireless drivers for Linux provided by manufacturers. Currently if I recall correctly Linksys is the only one that officially supports Linux.
You are boldly wrong, Ralink supports open source drivers via assisting developers of OpenBSD's drivers as well as providing a GPL licensed Linux driver, that's Ralink, since they produce wireless, while Cisco's Linksys division uses other people's wireless, mostly Broadcom.
> Ralink supports open source drivers via assisting > developers of OpenBSD's drivers as well as providing a GPL licensed Linux driver,
Even though that is true, the Linux driver is not very good.
The driver that is in FreeBSD works much better in my experience.
Edited 2007-02-09 15:43
That's the OpenBSD driver, Damien Bergamini develops it for OpenBSD and it then has to be ported to FreeBSD, much like the wpi, iwi and ipw wireless drivers. Damien used to develop for FreeBSD as well, but the developers around him kept making comments about the legality of reverse engineering and generally treating his work as useless. The efforts to get wpi working on FreeBSD have been quite terrible.
Intel's wireless chipsets have good official drivers.
http://ipw2100.sourceforge.net/
It would be really nice to have better native support for wifi cards. But in order for that to happen the manufacturers will have to finally open up the specs. For now Linux just needs to implement a better ndiswrapper config tool.
Thats not actually the problem; alot of the time the driver is actually there and opensource; ipw3945abg is opensourced and merged into kernels as shipped by distributions.
The big problem are the binary blobs (hence the Blob song for OpenBSD) and the binary only user land tool, as with the case of the Intel wireless drivers and the regulartory daemon which must run the background to enforce FCC regulartory requirements.
For once, more meetings are actually a good thing. One of the weaknesses of community open source development is that consolidation of effort is generally a gradual process (which I've discussed in previous comments). If the Linux wireless maintainer is pushing d80211 and cfg80211, then the driver development community better be on the same page.
Face-to-face meetings aren't necessary, but accountability is. There's the linux-wireless mailing list on vger.kernel.org, I'm sure there's an IRC channel, and they might even be able to use VoIP conferencing. However they want to do it, the development community needs to know which way to run with the ball.
It's obvious that this face-to-face meeting could have been a lot more productive if the attendees had done their homework first. Most of the major resolutions made at this summit involved the need to pursue more information. They could have figured that out on the mailing list.
This is one of those times where the presence of the OSDL is sorely missing. We don't need them to fund hackers. We need them to fund project managers that make sure the hackers are on the same page. Don't they understand this?
With the competing wifi stacks, I would love to know the rationale behind each of the camps decisions; I mean, there has to be a logical explaination as to why Intel insists on using their own stack over the one included with Linux, and vice versa - maybe someone can shed some light onto the subject.
The problem is with leadership, OSDL and opensource is this idea that there is something 'evil' about leadership - but like any large project, sooner or later someone has to put their foot down and say, "this is how it is to be done, like it or lump it" and for everyone to put their empire building ego's aside for the bettermeant of the group rather than flogging a dead horse.
Thats probably the one benefit with paid coders; they may hate the particular direction chosen by the powers that be, but they put their ego aside and remind themselves that they get paid and simply should fall inline.
I mean, I'm sure we've all been in situations where we think that the decision may have sounded stupid at the time, but when looking back, generally there is a reason for the decisions, may I suggest the volunteers in the Linux developer community take the said approach and put the development of the operating system ahead of flag raising on what ever mountain they think they must create, climb and claim as their own.
These are very good points. I think it's important to emphasize that a good chunk of the Linux wireless development community is directly funded by hardware vendors. These developers are accountable to their employers, so it is their responsibility to manage their managers. They need to bring it to their attention that the Linux wireless stack is evolving in a particular way, and therefore that they should strongly consider aligning their strategy to leverage the work of the kernel community.
The kernel community also needs to become more upfront about the rationale behind architecture overhauls. I believe that if we really had statistics on why the Linux kernel developers trash existing components, the most common reason would be that it had few users because it didn't adequately address the needs of its intended audience. We need to do a better job of collecting feedback from our clients, whether they be end-users, other kernel developers, or commercial vendors. With this information, and a more open dialog on architecture decisions, it will be easier to create lasting interfaces that serve their clients' needs.
I don't think that OSS developers are opposed to top-down leadership in general. They are opposed to leadership that ignores the opinions of the majority of the stakeholders. In community development cultures, we have an inherent meritocracy based on majority rules. Leadership in these scenarios involves driving consensus. There is an important role to be played here, and it isn't currently being done in a big way.
I don't think that OSS developers are opposed to top-down leadership in general. They are opposed to leadership that ignores the opinions of the majority of the stakeholders. In community development cultures, we have an inherent meritocracy based on majority rules. Leadership in these scenarios involves driving consensus. There is an important role to be played here, and it isn't currently being done in a big way.
But at the same time, you don't want to end up in a situation of 'the bicycle that was designed by a committee' - prime examples of how bloated, slow, inefficient committee's and communities get in the way would be OpenGL and how long it took to standardise OpenGL 2.0 - should it really have taken that long? whilst they were potificating over the patent bicker and cross licencing, DirectX was eating up customers because of its ability to address customers (developers and end users) problems in a prompt and efficient manner - as a side issue, I'd love to see Microsoft standardise DirectX and make it available so that people on non-Windows platforms can implement it; the actual design of DirectX in no way would require major changes as it isn't exactly something which is glued to Windows persay.
Back to developers, however, the problem with developers is this; its pretty much the same for many intelligent people; the brightest are not always able to express themselves in the best possible way, meaning, you don't always end up having the 'best idea' chosen, but instead, 'the idea that was best explained' - hence the need for a 'benevolent dictator' who is removed from the nitty-gritty development and can make a decision based on what is there, rather than letting the two pitch the idea, resulting in a wedge between two groups.
The other problem that ends up having is people love putting their name to something; there are those who couldn't care less about status and those who seem to be hell bent on wanting their name in lights at every opportunity and take any criticism of their project personally - prime example of that would be reiserfs developers and the fact that v4 hasn't been merged into the maintree.
Well, it did take OpenBSD a bit of work to merge wicontrol into ifconfig, so I can almost understand some people being a bit lazy about combining the two. The biggest problem is really what the summit is all about, that noone really works together in one spot, everyone develops their own project off on their own server, with noone tracking it all.
I really think that if all these wireless fans worked to improve OpenBSD's toolset and then port it over to Linux it would result in a better system, but that's a lot of work.
Why does 'iwconfig' exist? Wireless interfaces should be configured like any other network device, through ifconfig. OpenBSD does it this way and I find it to be much more intuitive.
Mainly because wireless needs to be treated differently than a wired network because of the issues of error correction, signal attenuation and the likes - its a different beast and needs to be treated different - hence the reason why Microsoft had to develop a whole seperate stack to take into account required wireless features suck as large frames, error correction and the likes.
Hi Moulinneuf,
You need to cheer up! Posting angry comments about the "traitor BSDs" doesn't seem to be helping your mood at all. I know that winter can be quite depressing in Quebec, but you need to get away from your keyboard and get outside for a sunny afternoon. If it happens to be snowing perhaps you could visit a tanning salon to relax, soak in some rays, and dream about the warm months that are just a couple of months around the corner.
Your friend
-- OpenWookie
RE[2]: Reality check ...
I guess making lists for you is getting angry , for me its not its quite interesting and it help figure out who's lying from who is telling the truth.
But that's just not the case. Every time there is a comment that claims that a BSD might in fact be useful for something, you go ahead and write a long winded diatribe about how much BSD sucks. And frankly it's gotten quite boring. You don't like BSD, or its license, and you feel that it's functionality is lacking. Fair enough. But you don't need to jump in with your (often insulting) comments. Frankly, it belittles you, and cheapens the other comments that you post about linux (which are occasionally insightful IMO).
I would be quite happy for BSD if they had more and better driver , but reality show me its not the case at all , so I respectfully point out that they are lying , nothing personal or emotional there
It is the experience of others (including my own) that BSD works flawlessly with a wide range of hardware, including some that various linux distros have had issues with (my Fujitsu laptop for example). On the other hand there are cases where the converse is true, and the BSDs are lacking drivers (my brand new Acer laptop for example, which runs Ubuntu). I usually run into this with newly released hardware.
It may be your experience that you've had driver issues with BSD in the past, but jumping to conclusions and calling others "liars" is frankly insulting to those who have had different experiences than you.
Also In Quebec winter is not depressing , you might not like winter sport , but I do , Hockey , skying , snow-boarding , ski-doo , etc ... is quite fun ... Come and visit :
http://www.bonjourquebec.com/qc-en/accueil0.html
I was in Montreal in December. It's a wonderful city. My parents own a ski-doo which I drive when I visit them (just outside of Ottawa). You do understand that my previous comment was entirely tongue-in-cheek, don't you?
RE[4]: Reality check ...
Take all Fujitsu , take all Acer , there is not 2% of those that run OpenBSD or BSD , 97% can be made to run GNU/Linux from experts
I love how you pull numbers straight out of your ass and expect me and everyone else to swallow it as truth.
You are 97% osnews troll, 100% when the subject is BSD. That's a fact.
Moulinneuf, do you do anything but troll? I mean, just look at how you're constantly getting marked down, perhaps you should reconsider how you spend your time, as many people seem to find your opinions offensive.
The BSD drivers are not ports of the Linux ones, I have explained this to you specifically before - they are reimplementations, new code created based on an understanding of how the original functions, this is, as I have told you, because the GPL is not compatible with the BSD licence, the code must be made anew in order for it to be of any use to a BSD.
Reverse engineering is a completely legal and viable means to create something, there is nothing illicit in finding out how something works and making a new implementation of it without including the original inside.
I could list a bunch of random companies that support OpenBSD in one manner or another, but I don't need to, they're listed on OpenBSD's website along with individuals that help out. They do include AMD, 3ware, AMI, and Google - companies I am sure you've never heard of.
* also worth checking into is how to properly quote someone, as you're misquoting me in response to someone else *
Edited 2007-02-09 20:33
RE[2]: Reality check ...
You are very confused, very, very, confused, I will leave it to you to google, since I am sick of trying to educate you, but here's the topics for you:
reverse engineering in Canada
the Mozilla Foundation's 10, 000 dollar donation to OpenBSD
GoDaddy.com's 10, 000 dollar donation to OpenBSD
Google's 10, 000 dollar donation to OpenBSD
the lack of tax deductions for donations to OpenBSD
When you're done with all that, fee free to correct your own damned self, I don't want to be bothered with all of it.
Edited 2007-02-09 22:51
RE[4]: Reality check ...
Wrong again. It took me all of 5 minutes to find this info:
Ralink
Ralink is a Taiwanese manufacturer of Wi-Fi chipsets. They are best known for offering open-source drivers under the GPL and in the past have given OpenBSD developers documentation for their chipsets. OpenBSD's ral and ural drivers support most ralink chipsets; the drivers have been ported to FreeBSD and NetBSD; an attempt is being made to port them to Linux.
(http://www.vendorwatch.org/index.php?title=Ralink)
AMD
"The coolest thing about AMD," Jason noted, "as just a regular user I went to their website and downloaded everything I needed. I didn't have to sign in, I didn't have to register, I didn't need to get a special login, I just went to the website and downloaded." He added that AMD has always been very open, something highly valued by the OpenBSD project.
(http://www.vendorwatch.org/index.php?title=AMD)
3ware
Not quite yet supported, but it's looking more promising.
"We will look into supporting OpenBSD, especially if we get several requests from customers for it, so far you are the first. If you would like, feel free to port the FreeBSD driver to OpenBSD."
(http://www.vendorwatch.org/index.php?title=3Ware)
[/i]
AMI[/i]
LSI is the manufacturer of the AMI MegaRAID range of RAID controllers.
Unlike most other vendors of RAID products, LSI Logic have provided sufficient documentation to develop tools to utilise the RAID functionality on the card. On OpenBSD, this has resulted in the development of the bioctl(8) tool that can interrogate array status, promote unused drives to "hot spare" status and control the alarms and LEDs on the controller and drive enclosures.
(http://www.vendorwatch.org/index.php?title=LSI)
Google
Google donates $10000 to OpenBSD
(http://undeadly.org/cgi?action=article&sid=20060517091103)
RE[4]: Reality check ...
NOT ONE OF THEM SHOW ANY BSD OR OpenBSD DRIVERS
You are a fool ... of course not. You never have to download OpenBSD drivers because OPENBSD DOES NOT ACCEPT DRIVERS THAT THEY CAN'T REDISTRIBUTE THEMSELEVES.
*All* of the driver are included with the OS, there is nothing to download.
In fact, OpenBSD has NEVER asked a vendor for a driver. They will not accept vendor supplied drivers. They ONLY ask for documentation so they can write their own.
We've been living through a particularly nasty cold snap in Canada for the last week or so, and until reading the article I wasn't aware of how far the vicious weather extended. But after seeing that Broadcom had representatives at the conference, it would seem that even hell has apparently frozen over.
Nice to see them there, regardless of the deep freeze it brought on. I was firmly under the impression that they had not heard of this linux-thing.
I've had great experiences with Broadcom. They maintain the linux kernel driver for their NIC's, and after some problems (multicast not working correctly) that I reported by email to the maintainer at Broadcom I got a call the next day from a Broadcom engineer!
Long story, but in the end (within 1 day) they came up with a patch for the problem.
Now, I use this example often to tell people what 'good support' can mean in the open source world.
It appears to me that FCC may be the biggest problem. That and the apparant use of software to limit the signal strength of the hardware. The FCC do not want people to up the signal strength in a simple way. The chip makers use software because its cheaper to make a global chip then many regional ones. And for fear of being banned from their biggest market, they cant open the source of said software.
Browser: Opera/8.01 (J2ME/MIDP; Opera Mini/3.0.6636/1558; nb; U; ssr)
It appears to me that FCC may be the biggest problem. That and the apparant use of software to limit the signal strength of the hardware. The FCC do not want people to up the signal strength in a simple way.
That's bull. Who started this awful rumor? It's simply not true.
"The FCC (or any equiv organization) has never attacked an open vendor
The radios cannot go that far out of range
The radios cannot generate enough power to be a risk
But the best part: These chips require firmware upload, so we could
already modify the firmware or the driver
This is an excuse ... but not from the vendors ... from the users"
http://www.openbsd.org/papers/opencon06-docs/mgp00021.html
Also, read the other slides in that presentation. It covers all of the reasons that vendors give to deny documentation. #1 reason? "Bad Engineering: EVERY rev eng'd chip has turned out to be badly engineered"
("When it comes to troublesome Linux peripherals, WiFi takes the cake." Never heart of 'takes the cake', wonderfull sentence.)
Funny that yesterday during dinner we talked about this. Someone said first thing to do when go to *NIX is choose optimal hardware, and don't wine when your strange/cheap/bad hardware is not supported...
After many years of using Linux (as part of a wider blend) I cannot name a PCI or USB that I can recommend for an Ubuntu user.
My Belkin (Ralink) PCI cards provide intermittent service and there are some 802.11b cards that work well.
NDISWRAPPER is not part of my recipe for a stable system: shims are ok for applications (e.g. Wine) but not for device drivers IMHO.
Partly because of this a couple of my machines now run OpenBSD but that lacks WPA PSK.
After many years of using Linux (as part of a wider blend) I cannot name a PCI or USB that I can recommend for an Ubuntu user.
Part of the problem with recommending cards (I have found) is when card vendors change chipsets between card versions.
For example I have used numerous Netgear WG511 PCMCIA cards in the past. V1 used and prism chipset and was wonderfully handled by the prism54 driver (with a firmware upgrade). Some V2 cards used the same until they suddenly switched to Marvell chipset which required ndiswrapper around the Windows driver.
I can handle recommending a "WG511 but not above version 2.1" but the card version (as printed on the card itself stayed the same when they changed chipsets!! I know I have two version 2 cards with different chipsets in them.
Have you actually tried NDISWRAPPER? With supported drivers, it is actually quite stable. I used a system that way for years without stability issues.
It's a pain to deal with (needing an occasional reinstall/reconfig as your system gets upgraded), but it works remarkably well.
1. Know your hardware before you buy it. As many have said, you need to know the chipset of the card - which means you need to know the revision number. I had a DLink card that used 4 different chipsets depending on the version number (I think it was DWL-650). Try to stay with main chipsents like Prism and Atheros, etc. There are several sites that list supported devices - use google!
2. If you already have a card that is not detected, you have two choices. Sometimes twiddling around with files in /etc/pcmcia/ (which helps your system "detect" the device) helps. Otherwise, look at the supported devices from Ndiswrapper.
NOTE: Don't just use the driver that came with card. NDiswrapper often has a link to a better driver for your card.
3. Use OpenBSD! It really does have the most drivers for a whole host of cards. I sell used Linux/BSD laptops. OpenBSD detects quite a few cards no one else does.




