<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Auto-whaaa?</title>
	<atom:link href="http://www.codemonkey.org.uk/2009/03/30/autowhaaa/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.codemonkey.org.uk/2009/03/30/autowhaaa/</link>
	<description>Dave Jones' Linux &#38; opensource stuff.</description>
	<lastBuildDate>Sun, 04 Jul 2010 17:35:25 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
<xhtml:meta xmlns:xhtml="http://www.w3.org/1999/xhtml" name="robots" content="noindex" />
	<item>
		<title>By: NateDS</title>
		<link>http://www.codemonkey.org.uk/2009/03/30/autowhaaa/comment-page-1/#comment-143</link>
		<dc:creator>NateDS</dc:creator>
		<pubDate>Tue, 31 Mar 2009 14:51:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.codemonkey.org.uk/?p=156#comment-143</guid>
		<description>Well the problem here is not that people that need to use NDIS wrapper time to time... the problem is that this sort of script is not going to do anybody any favors.

They are not protraying themselves as &quot;this is what you do when nothing else works&quot; they are saying &quot;This is what you do because Linux drivers are shit&quot;

I&#039;ve seen threads on Ubuntu forums were you have people telling other people that they need to uninstall the native driver and install NDISWrapper for hardware, that I know for a _FACT_ works very well with native drivers.  There was something else screwed up, but instead of trying to help the person or try to actually figure out what the real problem is they just plop down the kneejerk reaction and act like they were helpful. 


Problems with NDISwrapper include:

* Licensing issues. A end user can use it, but it is impossible for anybody to distribute software or hardware that uses it.

* Loss of data, loss of stability. Shoving Windows driver code into a Linux kernel can cause all sorts of issues. If the C code in the Window driver is not entirely correct it can operate well in a Windows environment, but cause all sorts of problems in Linux... like corrupting file systems, screwing up other hardware, and just general instabilities. If that driver screws up it can easily overwrite any part of the Linux kernel memory space with any sort of data. 

* Poor network performance. High latency, performance issues, etc. Generally I have found that working drivers in Linux are superior to their Windows counterparts.

* Excessive memory usage.

* Poor power management. Very likely to cause suspend to ram and suspend to disk to stop working correctly. Causes the hardware to use excessive amounts of energy in a laptop compared to proper native drivers.

* Loss of features. Newer Linux protocol stack offers up a lot more functionality then what you can get from a Windows driver IN Windows, much less what you can get by shoehorning a Windows driver into Linux. Stuff like multiple virtual ethernet devices, ability to monitor networks, working ad-hoc modes, effectively control the power output of the driver, and advanced stuff like packet injection.


So while it is lovely that NDISWrapper exists as a option it is not correct to say that it is &quot;Linux wifi made easy&quot;. It is correct to say &quot;Shitty and ill tempered Linux wifi made easy&quot;. Shitty wifi is better then no wifi, but it is not something that should be encouraged.

You see it is the misrepresentation that makes it so WTF. People actually do use Linux for important stuff and they may not be the the most computer savy people out there and they need good and correct information to operate on. People feeding poor and misleading information out there need to be slapped down.

It is actually much much better to simply tell users that Ndiswrapper may get stuff to work, but if they require stuff to perform correctly in Linux they need to go out and purchase a wireless card that will work correctly.

And if you have a piece of hardware or configuration that does not work well with Linux drivers, but really should, (like the open source Atheros, Ralink, or Intel drivers) then do everything you can to find out what the problem is and do bug reports on it. Spending time hacking on python scripts that make something easy that already had scripts and such is not very productive.  It is very likely that the reason those things are performing poorly is because the developers are unaware of that hardware or specific configuration and have not been able to test it using that. A single well-made bug report could solve the problems for hundreds of other users in the next OS update.</description>
		<content:encoded><![CDATA[<p>Well the problem here is not that people that need to use NDIS wrapper time to time&#8230; the problem is that this sort of script is not going to do anybody any favors.</p>
<p>They are not protraying themselves as &#8220;this is what you do when nothing else works&#8221; they are saying &#8220;This is what you do because Linux drivers are shit&#8221;</p>
<p>I&#8217;ve seen threads on Ubuntu forums were you have people telling other people that they need to uninstall the native driver and install NDISWrapper for hardware, that I know for a _FACT_ works very well with native drivers.  There was something else screwed up, but instead of trying to help the person or try to actually figure out what the real problem is they just plop down the kneejerk reaction and act like they were helpful. </p>
<p>Problems with NDISwrapper include:</p>
<p>* Licensing issues. A end user can use it, but it is impossible for anybody to distribute software or hardware that uses it.</p>
<p>* Loss of data, loss of stability. Shoving Windows driver code into a Linux kernel can cause all sorts of issues. If the C code in the Window driver is not entirely correct it can operate well in a Windows environment, but cause all sorts of problems in Linux&#8230; like corrupting file systems, screwing up other hardware, and just general instabilities. If that driver screws up it can easily overwrite any part of the Linux kernel memory space with any sort of data. </p>
<p>* Poor network performance. High latency, performance issues, etc. Generally I have found that working drivers in Linux are superior to their Windows counterparts.</p>
<p>* Excessive memory usage.</p>
<p>* Poor power management. Very likely to cause suspend to ram and suspend to disk to stop working correctly. Causes the hardware to use excessive amounts of energy in a laptop compared to proper native drivers.</p>
<p>* Loss of features. Newer Linux protocol stack offers up a lot more functionality then what you can get from a Windows driver IN Windows, much less what you can get by shoehorning a Windows driver into Linux. Stuff like multiple virtual ethernet devices, ability to monitor networks, working ad-hoc modes, effectively control the power output of the driver, and advanced stuff like packet injection.</p>
<p>So while it is lovely that NDISWrapper exists as a option it is not correct to say that it is &#8220;Linux wifi made easy&#8221;. It is correct to say &#8220;Shitty and ill tempered Linux wifi made easy&#8221;. Shitty wifi is better then no wifi, but it is not something that should be encouraged.</p>
<p>You see it is the misrepresentation that makes it so WTF. People actually do use Linux for important stuff and they may not be the the most computer savy people out there and they need good and correct information to operate on. People feeding poor and misleading information out there need to be slapped down.</p>
<p>It is actually much much better to simply tell users that Ndiswrapper may get stuff to work, but if they require stuff to perform correctly in Linux they need to go out and purchase a wireless card that will work correctly.</p>
<p>And if you have a piece of hardware or configuration that does not work well with Linux drivers, but really should, (like the open source Atheros, Ralink, or Intel drivers) then do everything you can to find out what the problem is and do bug reports on it. Spending time hacking on python scripts that make something easy that already had scripts and such is not very productive.  It is very likely that the reason those things are performing poorly is because the developers are unaware of that hardware or specific configuration and have not been able to test it using that. A single well-made bug report could solve the problems for hundreds of other users in the next OS update.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AdamW</title>
		<link>http://www.codemonkey.org.uk/2009/03/30/autowhaaa/comment-page-1/#comment-142</link>
		<dc:creator>AdamW</dc:creator>
		<pubDate>Mon, 30 Mar 2009 20:18:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.codemonkey.org.uk/?p=156#comment-142</guid>
		<description>nine: hmm...you haven&#039;t really tried much hardware, I&#039;m guessing.

Most broadcom devices still don&#039;t really perform very fast or reliably with b43. Some just flat out don&#039;t work. wl works rather well, but doesn&#039;t support all chipsets, is a closed first-party driver, and wasn&#039;t an option till recently anyway.

acx100 devices don&#039;t have a really usable native driver available, AFAICT. ath5k and ath9k both still have substantial issues with some hardware. The list goes on. Native drivers are obviously The Way Forward, but normal end users are still often stuck with ndiswrapper as the only usable solution. Hell, I was stuck with ndiswrapper as the only usable solution on my old laptop until wl showed up. b43 was very slow and would drop the connection entirely every two hours or so.</description>
		<content:encoded><![CDATA[<p>nine: hmm&#8230;you haven&#8217;t really tried much hardware, I&#8217;m guessing.</p>
<p>Most broadcom devices still don&#8217;t really perform very fast or reliably with b43. Some just flat out don&#8217;t work. wl works rather well, but doesn&#8217;t support all chipsets, is a closed first-party driver, and wasn&#8217;t an option till recently anyway.</p>
<p>acx100 devices don&#8217;t have a really usable native driver available, AFAICT. ath5k and ath9k both still have substantial issues with some hardware. The list goes on. Native drivers are obviously The Way Forward, but normal end users are still often stuck with ndiswrapper as the only usable solution. Hell, I was stuck with ndiswrapper as the only usable solution on my old laptop until wl showed up. b43 was very slow and would drop the connection entirely every two hours or so.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: AdamW</title>
		<link>http://www.codemonkey.org.uk/2009/03/30/autowhaaa/comment-page-1/#comment-141</link>
		<dc:creator>AdamW</dc:creator>
		<pubDate>Mon, 30 Mar 2009 18:21:47 +0000</pubDate>
		<guid isPermaLink="false">http://www.codemonkey.org.uk/?p=156#comment-141</guid>
		<description>This would, sadly, be very useful for a rather large number of people, because the native drivers frequently don&#039;t work as well as using a Windows driver via ndiswrapper. Or, indeed, at all. Sure, it&#039;s messy from a freedom POV, but if you just want to run Linux and use your wireless card, you are often going to wind up using ndiswrapper, unfortunately.</description>
		<content:encoded><![CDATA[<p>This would, sadly, be very useful for a rather large number of people, because the native drivers frequently don&#8217;t work as well as using a Windows driver via ndiswrapper. Or, indeed, at all. Sure, it&#8217;s messy from a freedom POV, but if you just want to run Linux and use your wireless card, you are often going to wind up using ndiswrapper, unfortunately.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nine</title>
		<link>http://www.codemonkey.org.uk/2009/03/30/autowhaaa/comment-page-1/#comment-140</link>
		<dc:creator>nine</dc:creator>
		<pubDate>Mon, 30 Mar 2009 18:15:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.codemonkey.org.uk/?p=156#comment-140</guid>
		<description>What the hell? &quot;Oh, let&#039;s disable whatever perfectly good driver is running and replace it with something totally unreliable&quot;. Whatever happened to diagnosing driver issues? I&#039;ll bet that most wireless driver issues these days are due to missing firmware. Kernel wireless support is excellent now, and -ve not found something unsupported in a long time.

I see a lot of posts regarding ndiswrapper on another distro list and keep feeling like responding &quot;what the hell is wrong with the native driver? Did you even look before you started installing this cruft then complain about stability?&quot;

I recall giving ndiswrapper a spin in the past. World of hurt. Most of what I encountered was it only working with specific (old) versions of drivers. Sure, support was patchy at the time, but that&#039;s why everyone was aware that the first thing you should do before buying is check the supported card list.</description>
		<content:encoded><![CDATA[<p>What the hell? &#8220;Oh, let&#8217;s disable whatever perfectly good driver is running and replace it with something totally unreliable&#8221;. Whatever happened to diagnosing driver issues? I&#8217;ll bet that most wireless driver issues these days are due to missing firmware. Kernel wireless support is excellent now, and -ve not found something unsupported in a long time.</p>
<p>I see a lot of posts regarding ndiswrapper on another distro list and keep feeling like responding &#8220;what the hell is wrong with the native driver? Did you even look before you started installing this cruft then complain about stability?&#8221;</p>
<p>I recall giving ndiswrapper a spin in the past. World of hurt. Most of what I encountered was it only working with specific (old) versions of drivers. Sure, support was patchy at the time, but that&#8217;s why everyone was aware that the first thing you should do before buying is check the supported card list.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
