Why can't we have more programs like NdisWrapper?

[hazel]

I have been using Linux for two years now and I am seriously annoyed by the failure of manufacturers to provide proper Linux drivers for their hardware (Does Microsoft pay them not to, I wonder?). Sometimes there is a driver of sorts, mostly open source but with a lump of proprietary object code in the middle, but it doesn't necessarily work the same way as the Windows one. For example, I couldn't get my Lucent modem card to work in Linux in spite of much help and encouragement from the discussion board at linmodems.org, probably because I have a non-standard motherboard. Needless to say, the original Windows driver worked just fine.

I recently read about a program called NdisWrapper which acts as a kind of virtual device driver for wireless network cards. You compile it as a kernel module and it provides a Windows kernel API which Windows drivers can use. So if you can't find a working Linux driver for your wireless card, you can use the Windows one instead. And it occurred to me that if similar programs could be written for other types of hardware, such as modems, we would have a level playing field with Windows at last. I believe such programs would actually be more compatible with the Linux philosophy than many present Linux drivers because they would be purely open source.

Would this actually be practcable? I'd be interested to know what other people think.

[kakariko81280]

It sounds like a good idea, particularly with modems because of the endless difficulty of setting up a winmodem under Linux. The problem is you end up with "a driver of sorts, mostly open source but with a lump of proprietary object code in the middle."

What I and a load of other people would like is open code all the way to the metal. At the moment I choose my hardware based on what has native support. Presumably so do a bunch of other people, and market forces pressure hardware vendors to release code and specs. If the standard way to make hardware work under Linux was to use a wrapped Windows driver then I imagine most hardware vendors wouldn't make the effort because it would cost them to do so and they wouldn't gain anything.

I would imagine it is quite practical to make more classes of wrappers and I wouldn't be surprised if one doesn't happen for modems. I think it is an impressive hack in the best sense of the phrase, but I don't think it levels the playing field, rather it leaves us parasitic upon a windows codebase.

A good question though, I look forward to hearing other points of view.

Chris...

[Zelmo]

The kernel developers see ndiswrapper as a bad thing, since it allows closed code to access the kernel. In fact, existence of the ndiswrapper module is explicitly checked in recent kernels and the kernel is marked as tainted if the module is found. On top of that, ndiswrapper provides manufacturers an excuse not to write real Linux drivers.

I see it as a band-aid fix that provides critical functionality for the time being, but something better (read: real drivers) needs to come along, if only for the sake of preserving the open-source philosophy. To accept something like ndiswrapper as a long-term solution would be defeatist.

[bryansmith]

I agree with Zelmo here. Ndiswrapper, while providing a great service, doesn't really provide anything in the long run except potential problems. Those problems listed by Zelmo should be enough to make the average user stay away.

Although it is a double edged sword - ndiswrapper makes up for shortcomings that it could be argued it is perpetuating.

Lucky for me, there's support for my wireless card in the kernel .

Bryan

[burntfuse]

I agree that we shouldn't have to rely on proprietary drivers in an inherently open-source system (I wouldn't really trust any closed code running in kernel space!), but a Windows driver wrapper could be really useful for reverse-engineering the protocols that certain pieces of hardware use, to write native Linux versions, by monitoring their inputs and outputs (without disassembling the drivers, which unfortunately would be illegal under most license agreements).

[easuter]

On top of that, ndiswrapper provides manufacturers an excuse not to write real Linux drivers.

Right on!
A bit like Cedega as well.
If someone else is doing it for you, why bother making the effort...... :-\

[fingal]

It's a tough one! I've been in the position of having a so called Linux driver supplied with my hardware (and I don't always look for a GPL licence) only to find I can't compile it anyway ... no matter what I try.

My Linux knowledge is pretty good these days, but I stop short at tweaking source code or Make files to get things to compile!

Having said that sometimes I've found there's an open source driver that'll make my hardware work anyway. Then I ask myself, 'Am I getting the most from my hardware?' Sometimes no ... Especially from my horrible old ATI card. My ethernet card does a fine job though.

Just speculating, but maybe the rise of open source programming languages - Java no less! - will raise the profile of FOSS. It all helps!?

Opinion piece
One further thing. It's often said that hardware manufacturers can't be bothered to write open source drivers; market forces don't make it cost effective etc. IMHO this is rubbish! I've worked for a few organisations now, and they usually waste time and resources on useless projects. If they really knew their markets they would pay attention to Linux. I would use almost any decent hardware shipping with FOSS code, and I bet there are 1000s of people who feel the same way. A market!

Code is code, and these days the market is big enough for all of us.

[Cabhan]

Well, here's my opinion.

In the future, I will certainly 100% look for hardware that has native, open-source support. However, I, and I'm sure many others, had most of my hardware before ever coming to Linux. Without ndiswrapper, I would have been unable to have Internet access at home. And frankly, wireless support is very poor under Linux. The best solution would be manufacturer-supplied specs and such so that the OSS community could write their own. Next best is manufacturer-supplied closed-source drivers.

I disagree that accepting ndiswrapper is bad. Making ndiswrapper the permanent solution would be unfortunate, but ndiswrapper is a fantastic tool for many (most?) wireless users.

In regards to the original question, I do believe that more products like ndiswrapper would help. Let's face it: most manufacturers do NOT provide Linux support. If we cannot get our own drivers (as in, say, the case of winmodems), since people are still going to use winmodems, why not have SOME sort of support for them?

This may be a bad example because I don't know much about the modem situation under Linux, but if we have a technology with no manufacturer support and (currently) poor community support, I feel that technologies like ndiswrapper provide an essential service.

[easuter]

I disagree that accepting ndiswrapper is bad. Making ndiswrapper the permanent solution would be unfortunate, but ndiswrapper is a fantastic tool for many (most?) wireless users.

Actually, i've noticed that as of Kernel 2.6.17, the ntive card support has increased quite dramatically. all the different cards (all carrying diff chips) i've installed none have needed ndiswrapper so far on 2.6.17.13.

[hazel]

Actually I agree with a lot of this. I certainly didn't float the "ndiswrapper option" as an ideal solution. The ideal solution, we all agree, would be for all hardware manufacturers to publish the source code of their drivers. But how likely is that to happen? Meanwhile those of us who depend on existing rather than newly purchased hardware, sit and fume. And it's not only ndiswrapper that taints the kernel. Supplied drivers like lt_modem with proprietary code in them do that too. You can't win whatever you do! I ended up having to use an external hardware modem to get online; it works at only half the speed that my winmodem did under Windows so I am not pleased but if that's the price I have to pay for using an OS that I can trust, so be it. I just wish there was some alternative, that's all.