It seemed to me that i810 was fine up until Intel got involved with it. I have an unusual chipset (855GM on a desktop with no LVDS output), and new versions of Intel drivers keep totally failing to work on it in various exciting ways. Before Intel engineers started showing up on xorg bugzilla (i.e. when the module was called 'i810' instead of 'intel'), this happened once in a blue moon and I got responsive, polite fixes reasonably quickly. Now, it happens constantly, and I have to beat the engineers over the heads just to stop them closing a bug with comments which more or less translate to "we can't be bothered, sod off". When bugs do get fixed, it tends to take them a respectable fraction of a year to do it.

Interacting with Intel engineers on xorg bugzilla has sort of made me yearn for the days when GNU/Linux hardware drivers were crappy, desperate efforts slapped together with enormous difficulty without any specifications to work from.

1. Linux desktops get 95% or more of their software from a single, trusted source, and savvy users will not click on random executables that they download. Windows users are forced to run executables they download from web sites without really having a way to verify that the source is trusted. I have to do this all the time on Windows; even though I consider myself reasonably savvy, there's simply no way around third-party software if you want to get your work done. That right there constitutes the largest difference between the two in terms of desktop security IMHO.
2. "Opening an infected file," if that file is a data file opened by an already-installed program, and being compromised, indicates that the already-installed program has a vulnerability. Linux security advisories consider these vulnerabilities serious business (they make up the majority of Linux security patches), and have a centralized mechanism for solving them, neither of which seem to be true on Windows in my experience.
3. Servers, by their nature, process requests from anyone anywhere in the world. There's no need to "trick" anyone into clicking on something to get your foot in the door; you can run any CGI program with any input you like anytime you like. The CGI program has to be vulnerable, just as a user program has to be vulnerable to the "infected data file" that you're putting into it. I think the two are different (not really one more vulnerable than the other; they're just not immediately comparable), but saying, "once you've gotten the exploit onto a consumer PC, they're more readily vulnerable than a server is once you've gotten the exploit there, therefore desktops are easier to attack" is just as one-sided as saying, "it's much easier to get access to a server to exploit it than it is to get the exploit onto a desktop PC, therefore servers are easier to attack."

You do realize that using Linux to host a world-accessible web site based on custom PHP scripts, and using Windows to browse the internet as an end-user, and having them both get broken into is not an apples-to-apples comparison?

If you were using IIS to host a web site with a boatload of custom ASP scripts, and that got broken into, I would not be surprised. If that breakin installed an exploit which invaded your up-to-date-with-security-patches Linux/Firefox machine when you browsed the site from Linux, that would be serious news (and an indication that the two were comparably vulnerable to attack).

I agree with the poster who said you are blaming the victim. ISO manages a process and counts votes. Nothing more. Nothing less. There is nobody at ISO with the authority to say: "Well this standard passed through the procedures but we can't allow it through, so we'll change the procedures." After the fact it might make sense to change the procedures but it would be totally wrong to change the rules of the game in the middle of a standardization process.

Well, that's a problem with ISO then. There _is_ a proper balance to be struck between "we counts the votes and we reports the totals, questioning the totals is not permitted for people in my position, have a nice day" and "the vote may have passed but I don't like it, nyah nyah." The people in charge of implementing the ISO procedures should keep firmly in mind that the end goal is _not_ to follow every procedure to the letter no matter how badly distorted the outcome, but to use the procedure as a means to the end. The end is to ratify standards which have broad support in the technical community; if the voting procedures are showing strong evidence of being blatantly rigged -- which they are -- the ISO leadership needs to say so, and deal with the problem. That's not arbitrary. That's taking responsibility. At most organizations it's required for anyone above the level of assistant manager.

It's not clear to me whether the ISO leadership is also corrupted by Microsoft, and is letting the irregularities go unchallenged on a nudge-nudge-wink-wink basis, or if someone at ISO honestly believes that it's not their place to call out blatant corruption when they see it, but either one is a black eye for ISO.