[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#353277: ndiswrapper in main



On Mon, Feb 27, 2006 at 04:45:04PM -0800, Thomas Bushnell BSG wrote:
> If there are no uses of it (actual *uses*, where it is *useful*) with
> free programs, then it sure seems like a wrapper for non-free
> programs.

You want a useful use case of the NDIS CIPE driver? Allright, I'll give
you one.

I'm a GNU/Linux consultant. It is my job to help people with installing,
configuring, and generally using GNU/Linux. I prefer to use non-free
software as little as possible, and most of my own systems currently
have no non-free software installed (although not all of them).

On the other hand, I have no say over what a customer would want; and if
my choice is to either help them out with non-free software or loose the
contract, then I will do the former. That still doesn't mean that I'd
like to use non-free software myself, so I'll avoid it if possible.

The CIPE driver doesn't actually need hardware, since it is an
encryption layer. As such, I can use it as a test-case for ndiswrapper,
to find out how the latter works and to actually be able to test whether
I set it up correctly. If a customer should at one point ask me to help
them out with setting up ndiswrapper, I can then first experiment on my
own with the CIPE driver, and then help them out with their non-free
driver.

Want another one? Here goes.

A kernel hacker might be interested in helping out to hack on
ndiswrapper itself, but not be very interested in having their laptop
crash every five minutes by loading experimental versions of the driver.
An obvious solution would be to use a virtualization environment like
qemu, but then you can't use a driver that requires specific hardware.
The fact that CIPE exists, which does not have any hardware
requirements, can allow you to test stuff without having an unstable
computing environment for other things.

Right, so there's two examples. But then again, the above two are all
based on the assumption that it is impossible to test out ndiswrapper
without an NDIS driver -- and that having something in main for testing
purposes only would be something some zealot might not accept (for
clarity, I'm not claiming you are a zealot of any sort). So let's think
of another use case:

I don't know about you, but personally, I had never heard about the CIPE
driver before, while everyone here seems to know ndiswrapper already. It
is conceivable that projects which attract a high level of publicity
(such as ndiswrapper) also attract a lot more developers than projects
which do not (such as CIPE). Indeed, it would seem that there are
currently only a handful of developers working on CIPE.

Now consider that there is a change in some future version of the
kernel, which is security-related, and which breaks the kernel API wrt
network drivers incompatibly. While not incredibly regular, it most
certainly is not unlikely, either. Depending on the complexity of the
change, it might be that it will take a considerate effort to update
drivers to the newer Linux API, which the handful of people working on
the CIPE driver will take ages to do. The ndiswrapper folks, however,
because of their relatively higher number of developers, might get the
job done a lot sooner. People who don't want to be vulnerable (which
might be "all of them", seen as how this is about crypto intended for
use in VPN environments) will want to use the ndiswrapper driver until
the native driver has been updated.

There, that's three. I'm sure you can come up with more use cases
yourself; and I'm sure I can come up with more if you think none of the
above are any convincing. In the mean time, I'll tell you that just
because you can't come up with any reasonable use case of free software
without non-free software, even if the main purpose of that free
software is to use that non-free software, that this doesn't mean there
isn't any such use case.

-- 
Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4

Attachment: signature.asc
Description: Digital signature


Reply to: