Yes, the data going through the USB may be digital, but as I have shown, the USB power, not data can cause interference.

For a vinyl ripper, the USB power has the ability to interfere with the audio while it's still analogue, before its conversion to digital prior to being sent over USB.

One would hope a vinyl ripper would use an external source of power and shield the USB well.

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.

Except OpenVPN doesn't support IPv6 transport yet. You can run IPv6 inside the tunnel, but not outside.

Though there is a patch or two floating around that does add this feature (and will presumably be added to OpenVPN unstable soon if not already).

I don't have that Google statistic, but I do know that Wikimedia run similar tests on Wikipedia. Here are the test results, updated daily. As of today, 2010-03-28, an AAAA breaks the request 0.39% of the time for Wikipedia users.

Those tests are done in the background to users at random by a snippet of JavaScript on Wikipedia articles.

This Google presentation says Google would lose 0.1% of traffic if they added AAAA, though it's not presented particularly prominently, so take that with a grain of salt.

Either way, adding AAAA's will break your website for some people. In my opinion, though, the number is so small it's not worth worrying about, but each to his own, I guess. All this pain will be over soon anyway. Hopefully.