I don't know what that was, but your link seems broken. It also seems to be from 2007, by the link. Googling the address turns up the cache, though. A quick read and most of the bullets are more or less accurate, save for some important details.
First, though, let me preface this by saying that, as she notes, the kernel develops frighteningly fast. There is simply no comparison to it in how much has changed in just the past year. Like all technological advancement, it happens incrementally, but things can change significantly in just one release. That article was published a miserly five days after the 2.6.23 kernel was released and probably doesn't factor in even the changes there (though as I recall the real magic of the year in driver-space began just after that release).
The kernel tends to release about quarterly (a month or so for new patches, two for bug-fixing and stabilizing), but sees thousands of patches in that short window before the debug cycle (the upcoming 2.6.27 release saw >8000 changesets. That is, greater than eight thousand sets of patches), including some exciting driver things.
I'd like to also say that the part about "somewhat lacking hardware compatibility" is absolutely laughable; to wit, there is no operating system that supports as many devices and architectures as Linux. Period. Incidentally, windows has never held any spot remotely close to that ;)
Anyway, details.
- She mentions that x86 works, but so too does x86_64. And ARM, MIPS,
SPARC, Alpha, and IA64 among others, Suffice to say, if it exists,
it's likely that you can run the Linux kernel on it. Why does this
matter? Well, you can run a fully 64-bit system on that shiny new
processor with ease in Linux, all without worrying about whether you'll
have drivers at all. That's pretty nifty. Or if you ever wind up with
an old PPC-based Mac and don't want to pay for OSX or something, well,
you can't run Windows on it, can you? :) She sort of mentions that,
but doesn't really point out the significance (she also seems to imply
the powerpc is at all compatible with x86, which is patently false).
- The firewire stack was rewritten a couple months after this went up, so there's likely a bunch more supported devices, now.
- I take issue with the use of "all" in most any field, especially technical ones. I'm sure there are motherboards and NICs that don't don't work somewhere-- you can never prove the absence of bugs, or something.
- Flash has been supported for years. If she meant SSDs, then they were supported not long after they first came out. If she was talking about UBI, that took so long to merge because it's rather complex to implement proper wear-leveling (and isn't at all related to being able to use flash devices so much as use the same ones for more reads and writes).
- The input devices thing is only part of a larger class of human-interface devices. It's also not really related to configuring the xorg.conf, which is something the X.org people have spent the last couple years killing off (they're not done yet :/ ).
- She makes a couple mistakes on networking hardware. One is understandable as the mac80211 driver rush was still gaining momentum, The other is an annoyance because it assumes that wireless firmware can't be fetched via package managers (which, in this day and age, if you don't know what one is, you very likely have one). For reference, the new wireless stack donated by Devicescape and included in the 2.6.22 kernel was a fantastic leap forward and we'll be seeing improvements to kernel-level wireless drivers for years to come because of it. Even the much-maligned madwifi driver (for Atheros chipsets) is being rewritten for inclusion in the kernel (one of the guys doing it is being paid by Atheros to work on it).
- If a monitor didn't work, I'd be disturbed and take it back immediately. That's like saying "VGA" doesn't work. As for configuration, that's X again, and they've actually improved that from what I hear.
- If you use network-attached Samba printers, there should be no problems, even with new ones (though printer setup and troubleshooting is still kind of pain because CUPS is old and clunky)
- "Pro" sound cards are actually more likely to work, as it happens-- they tend to use well-documented chips in them (like the envy24-based card I have, which is fantastically supported). I note, however, that nothing made by Creative falls into that class of device. ;)
- The major thing about graphics cards is that there are binary drivers provided by nVidia and AMD. They're not GOOD drivers, but they at least work (in most cases). Recently AMD has been making better headway in providing decent drivers, including some specification releases that have helped a lot. They're not there yet, but it might not be too terribly far in the future that you see proper 3D acceleration for new Radeon cards in the kernel itself. Certainly helped Intel's GPUs. :/
- Webcams have undergone a game-changing transition with the refactring of the v4l2 codebase and merging of those patches into the mainline. As kernel hacker Jonathan Corbet put it, "As of 2.6.27, Linux supports almost every webcam model on the market." So if it's not working now, it'll very likely work in about a month (2.6.27 is in debug, remember).
- Winmodems have not miraculously started working. Incidentally, few have miraculously started caring :/
Anyway, that's my (somewhat long-winded) perspective on where we are about a year later.
73,
Wyatt
"Users' expectations are higher than they used to be—if your interface isn't easy to use 'out of the box,' users will not think well of it...frustrated users can give up and switch to your competitor with just the click of a button. So the cost of building a mediocre interface is higher than it used to be, too." --Jenifer Tidwell, Designing Interfaces