From the acceptable use policy of Microsofts Anonymous Alcoholics^W^W academy alliance program:

• Windows XP may not be used only as a terminal for accessing a UNIX telnet server.

Interesting. Who would still be running a telnet server? Everybody I know uses SSH. And if it's just for telnet, there are no benefits from graphics or sound drivers that might not be available for Linux. If I'd ever use XP on "thin clients", I'd use NX or XDMCP or VNC, but never telnet...

Also this explicitely only applies to XP, not to Vista?

I always liked pretending that nowadays, there are no driver issues with Linux (well, except for ATI and NVidia not releasing specifications, so for some of their product there are no good drivers available).

Well, thats not entirely true. Just these days, I've been running into some driver issues with my Intel hardware; and Intel recently has been the favourite of Linux developers for actually publishing driver source code under a free license.

Some details on the driver issues I had:

IPW3945 wireless with WPA on dual core. Apparently, there is some kind of race condition in the dual core setup under load, when two interrupts end up being handled by different CPUs. The WPA path probably is a bit slower, I read that theoretically it should also happen with WEP.

The effect is as this: when transferring data quickly, e.g. from a local machine on a WPA encrypted network (such as my parents wireless; basic WPA via the common AVM Fritz!Box), it will drop the connection every minute or so, and take another minute to reconnect. Obviously, that makes the wireless rather useless...

This is what the errors looked like:

TKIP: ICV error detected: STA=...
N/A: Michael MIC verification failed for MSDU from ... keyidx=0
wifi0: MSDU decryption/MIC verification failed (SA=... keyidx=0)
TKIP: received packet without ExtIV flag from ...

Upgrading to Kernel 2.6.20 turned these errors into something like Firmware bug detected; reconnect already was a bit faster. Upgrading the firmware past the Debian-packaged (in non-free) version to a newer one change them again (I think the ICV error remained) and made the reconnects even faster; still large transfers don't work reliably with WPA.

This is with a newer firmware and 2.6.20 connected to a Cisco AP, using enterprise WPA (i.e. EAP-TTLS):

ipw3945: Error sending LEDS_CMD: time out after 500ms.
ipw3945: Microcode SW error detected.  Restarting.
ipw3945: Can't stop Rx DMA.
ipw3945: Detected geography ABG (11 802.11bg channels, 13 802.11a channels)
CCMP: received packet without ExtIV flag from 00:03:52:e4:38:43

Another reason I upgraded to 2.6.20 was that the microphone didn't work on my Dell 640m. The upgrade helped here, I now can record from my microphone.

Every now and then, my system kind of freezes on resume; it seems that some interrupts (especially the keyboard interrupt) remain disabled...

I also tried the newer i810-modesetting driver, that should be able to handle the 1440x900 resolution without the aid of i915resolution (which basically overwrites part of the video BIOS to add the resolution to the supported resolutions list). The screen remained black (with both unstable and experimental versions of the driver). Another reason why I was trying this driver is that the current driver has like a default gamma 1.5 for XV, apparently - all XV using apps playback videos way too bright. Even if they don't have an XV gamma control.

Well, on the other hand, thats what Windows users might be exposed to every day. 99% of the time, everything works fine for me, too.

It just remains open whether 2.6.18 is actually the right kernel to use for the upcoming release... 2.6.20 improved on some of my issues. On the other hand, yaird failed to make a proper initrd for my computer, because CBC (cipher block chaining, a common choice if you encrypt your harddisk) became a module and wasn't added. There are just so many details to iron out when upgrading the kernel... that would pretty much mean an unfreeze, I guess. :-(

If we would release more often, that wouldn't be as essential, but for a release interval of two years, we really should have a kernel with few driver issues. And even if we're going to ship newer kernels with "dot releases" of etch, we'll have to avoid issues such as the CBC-module being unknown to yaird.