Re: ndiswrapper configs

I'm going to agree with Luke on this one..  I think the last thing we 
need to trim down are networking devices.  None of my machines have 
working modems, and if wireless support isn't available on install, it's 
a pain in the butt to get it installed.  I think the more device support 
we have at install time, the happier people will be.. and the closer 
we'll be to having an OS that "just works" as ark is intended to be.  
(HOWEVER.. if we get to the point where we have a method for handling 
ndiswrapper configs gracefully, and want to streamline things somewhat, 
we might offer a "driver CD" and some means of loading the correct 
drivers.. 

Luke wrote:

>Bernhard Rosenkraenzer wrote:
>
>  
>
>>On Wednesday 12 January 2005 20:09, Zackary Deems wrote:
>>    
>>
>>>Great.. is this ALL configs supported by ndiswrapper?
>>>      
>>>
>>No, ndiswrapper supports virtually any network card, both wireless and
>>normal. I've packaged the ones I could verify to work (meaning anything
>>that is in any hardware I have access to that isn't supported natively),
>>and I think this covers most chipsets, but certainly not all.
>>
>>    
>>
>>>Do we have it
>>>documented someplace that these exist, so people will know they CAN
>>>install them like that?
>>>      
>>>
>>If you know where to look ;)
>>http://ndiswrapper.sourceforge.net/phpwiki/index.php/List
>>
>>Search the page for "Ark Linux" and you'll find a couple of references.
>>We need to document it better though, preferrably by just doing the right
>>thing automatically (see below)
>>
>>    
>>
>>>Is there some way we can do it automagically if
>>>we see that hardware on the system?
>>>      
>>>
>>Not yet, but I've thought about it too. The basic idea would be to add
>>another (optional) field to /usr/share/hwdata/pcitable, specifying the
>>package[s] containing a driver.
>>Then coldplug and hotplug must be patched to handle it -- problems that
>>need to be solved before that can be done:
>>- Must add and parse the extra field to pcitable
>>- coldplug/hotplug must have a way to trigger an action when the a
>>privileged
>>  user logs in (in GUI mode) for the first time after new hardware was
>>  detected -- we need to be able to prompt the user for things to do if we
>>  can't determine it automatically (e.g. do we download a wireless driver
>>  because the chip is there, even if the user is on a slow pay-per-minute
>>  connection and doesn't want to use the wireless chip in his notebook
>>  anyway?)
>>
>>This is definitely something we should do, and once done, we can also use
>>it to trim down the default install (there's not really a need to include
>>230 sound drivers in the core kernel package if there's an easy and 100%
>>automated way to install the one(s) you need...).
>>
>>I'll look into it.
>>
>>LLaP
>>bero
>>    
>>
>
>  
>
>>- we need to be able to prompt the user for things to do if we
>>  can't determine it automatically (e.g. do we download a wireless driver
>>  because the chip is there, even if the user is on a slow pay-per-minute
>>  connection and doesn't want to use the wireless chip in his notebook
>>  anyway?)
>>    
>>
>
>I don't think this is a very good idea here. If the users only means of
>accessing the net IS a wireless card then this totally nullifies the point
>of ndiswrapper and automagic detection.
>
>  
>