In theory, maybe, but in practice I get noticeable EM noise from USB.

I have a USB-powered speaker (uses a normal 3.5 mm jack for audio) for my computer which also has an earphone port on the side, which is handy. It used to be part of a HP LCD monitor (L1740 if you must know), which had a USB port for plugging the speaker into for power. Why you would design the speakers to get their power off a monitor they were specially designed to be an accessory for with USB I do not know -- surely a normal DC plug would have done the job. But I digress.

Anyway, I no longer use that monitor, but kept the USB speakers. To power them, I now plug them directly into my desktop PC's USB port for the power. Now when I plug my earphones into the side of the speaker bar, there is a noticeable hum that is directly correlated with the CPU usage. Normally it's like "bzzt zzt zzt". But if I drag a window around or compile something, it goes like "BZZT THH ZZT THH ZZT TTH ZZT".quite loudly.

It does that with two separate motherboards with two separate PSUs. However, it does not do that if I plug the USB power into my Eee PC (laptop) instead.

So there you have it. USB does suffer from EM noise. If you have a solution, I'd like to know -- it drives me batty some days.

The GP did use AD. Re-read this quote from the GP, my friend:

If that doesn't convince you, read this quote, then read up up on the description for the likewise-open package.

If the GP wasn't using AD, then what the heck were they doing using a tool that provides "authentication services for Active Directory domains"?

A bit like how Gmail, Twitter, or many other sites don't use the document fragment identifier to do such a thing. Or a bit like how there's no such thing as history.pushState() to implement that (and because it doesn't exist, it doesn't work in Google Chrome, but if it did, it would work perfectly).

Yep, sometimes you have to break the back button.

I don't get why that is an issue. If you want to write clean markup, write clean markup. And today's browsers are perfectly capable of handling all manner of weird and wonderful markup.

The only situation I can think of where lax HTML5 markup would cause you a problem is if you're deploying to a custom mobile device or custom-written browser for a specific deployment. But in that case, you'd likely have control over both the input and output, in which case what I said above -- just write damn clean markup -- still applies.

If I saw problems with my browser struggling to render all the HTML5 content out there, I'd agree with you. But the reality is that browsers are mature, and can deal with the markup out there. And those that are writing markup are testing. It's a cycle that is working in practice, not just theory.

There is nothing stopping you from using well-formed XML in your HTML5, or serving your document as application/xhtml+xml (explicitly stated in the HTML5 spec). Serving HTML5 as proper XML is dubbed "XHTML 5". It uses the same doctype. All the new tags -- video, audio, section, header, etc. are supported, but obviously the lax markup features of HTML5 (like being able to omit most tags) no longer apply.

That's a very encouraging statistic. To the GP: Jeff Rosen (one of the guys behind Wolfire) wrote an enlightening blog post ("Linux users contribute twice as much as Windows users") on the subject too.

You should definitely read more of the Wolfire Blog. One of my favourite posts is about their reasoning for why you should support Mac OS X and Linux.

Mac OS X optionally includes a case-sensitive file-system, so as with OpenGL, once ported to OS X, it should be trivial to port that area to Linux.

That said, one of the Adobe CS versions crash when installing on a case-sensitive file system (find a link yourself -- I can't be bothered at this time of the morning), and Haiku won't build unless you build on a case-sensitive file system.