Wow?

It can be anything from some thin logic so people don't have to make a custom chip to play it to a entire embedded operating system.

The firmware for my Intel Iwl3945 is 184KB. That's a bigger binary then most of the programs in my /bin directory. It's bigger then the BSD-CSH. So it's obviously doing some very fancy things and is far removed from the traditional 'low level logic' that most people think of when they think of firmware.

It's not something that I particularly care deeply about and it's not worth getting into a war about, or anything. But all firmware is not made equal and if your in the market for a card then this is the sort of thing that I would like to know about. The drivers for Intel's cards are all pretty good, but the firmware has been a source of instabilities and trouble in the past for me.

Just last week, the reason I know about the Thinkpad error stuff, is that I was working on my Mother's Laptop I got for her off of Ebay. The stupid thing wouldn't hold a network connection for more then 7 seconds (XP's ping utility said 'hardware failure', then it would reconnect quickly), and when it did disconnect it would kill whatever downloads were occurring. This made it nearly impossible to install XP's service packs over the network.

So I booted it up in my USB flash drive I carry around for these sort of occasions and was able to download most of the software I needed using Linux and the Intel wireless. Now the same exact errors were happening in Linux, but Linux handled it much more gracefully. Instead of losing the connection the download would just get paused for the second it took to reconnect.

I tried reseting the router and all that happy stuff. We contacted the seller of the laptop and he sent a new Wifi card. Same freaking behavior. Eventually just gave up on the Intel 802.11b and bought a 802.11g cardbus card and it worked perfectly.

I am fairly certain that this behavior was due to Intel firmware bugs. I've had similar issues with my Iwl3945 device, and this is a OEM installed item with OEM Linux support. (Dell 1420n). Nothing earth shattering and the Linux drivers were more then capable of dealing with this stuff nowadays. But it took tracking the iwlwifi website for a while and a few firmware upgrades to get everything stable in Debian.

Like I said before, I use Intel wireless and am happy about the drivers and their Linux support, so I wouldn't put off buying a laptop with Intel stuff on it, but it's not ideal.

------------------------------------

Here; I'll give a (counter) example of why it's you should not get all religious about firmware code:

(now don't take this as gospel, I am sure that I'll get several facts wrong)

The AMD/ATI 'Atom Bios' for their video cards. The Atom Bios is firmware provided to Linux/X Windows driver developers that take care of a lot of the low-level functionality that is necessary to do 2D drivers for their newer video cards.

Well the Atom Bios is a binary blob. So you ended up with 2 different sets of 2D drivers being developed in parallel, one that used the binary blob, and the other which said 'no binary blob' and they proceeded to learn how to bang bits about on the surface of the card.

Well the deal is that there _is_no_source_code_. The Atom Bios is mostly shipped as it's developed.. the code in the blob is the code that they more-or-less hand programmed.

Using the Atom Bios is not perfect, it's not ideal.. but the thing is is that with the next-generation of cards all the work on 2D drivers and related items are going to be totally worthless. They won't be programmable using 2D acceleration any more. That part in the video cards will be totally gone and replaced with all 3D-related logic. The newest cards now don't have a 2D acceleration core.. they use hardware emulation and the atom bios to allow code-level compatibility with older 2D drivers.

So instead of putting all the effort into 3D driver development, which is the only thing that is going to be sustainable long-term, we have 2 or 3 different competing 2D drivers; one of the major reasons we have this issue is because of the black-n-white 'no binary blob' outlook. I mean it's nobody's fault how this all worked out.. it seemed correct at the time to shun the Atom Bios, so don't think I am putting the driver developers down or anything. (I think what they are doing is great.)