The one does not exclude the other. There's nothing stopping you from doing what Google did - funding development a CUDA accellerated Theora codec if you feel so inclined (and if you have the money). :-)

I guess Google thought Theora on the desktop was "good enough" and wanted to focus on ubiquity rather than perfection - for now.

Non-technical problems, such as H.264 requiring licensing patents.

Patents are specifically intended to restrict usage of technology (to those who are inclined to pay for it).

So - a royalty-free product which produces comparable (if slightly inferior) results *should* become the ubiquitously available option. It is as it should be. :-)

I very much doubt, however, that Apple and Microsoft will include Theora in their web browsers or in the iPhone. I think it is much more likely that the patent-encumbered option is set to become more ubiquitous than the free option, due to corporate politics. (After all, neither Apple's or Microsoft's products support Theora or Vorbis out of the box now.)

Baidu's real spiders obey robots.txt. However there are plenty of malicious spiders out there who pretend to be Baidu in their User-agent string - giving Baidu a bad name in this area.

IPv6 does nothing to protect you against malicious routing updates, as far as I'm aware.

IPsec is a mandatory feature of an IPv6 stack, but nobody's forcing anyone to use it.

This hijack was on the routing level, not the DNS level.

Blacklisting China's IP ranges would do nothing to protect you against bad routing - something you as an end user don't have any control over.

In the area of Swiss army knives, yes.

It's just as likely Victorinox bought some solution from some third party using some kind of snake-oil cryptography, and slapped their brand on it in good faith.

Two seats, not one - ever since the Lisbon Treaty was ratified.

As far as I know, yes - the Pirate Party Australia does not currently hold any seats.

If by "they" you mean the collection Pirate Parties in general, you'll find that Piratpartiet (Sweden) has two Members of European Parliament. That's more than some "established" or "legitimate" political parties in Sweden. ;-) Pretty good for a joke.

Here's a graph of the network structure as seen by BGP.

AS29216 at the right is the AS which I.ROOT-SERVERS.NET is located in. As we can see, it is only reachable through AS8674 (NETNOD-IX).

Which in turn is reachable directly from a few different AS:es, including AS24151 (CNNIC-CRITICAL-AP).

My guess is that Netnod simply started filtering out the routes to AS29216 via AS8674 on the BGP session to AS24151.

The DNS server itself might have been using BGP, it might not have. But in the end every system on the Internet is reachable with some kind of BGP route somewhere.

An important factor is that PNG is technically superior to GIF. The most glaring deficiency in GIF is that it only supports 256 colors.

PNG also brings alpha channel transparency to the plate (though it wasn't supported in IE6.)

The only thing GIF does better than PNG is animations. PNG has a companion format, MNG, for animations, but it is not supported by IE for example, so nobody uses it outside of cute tech demos. So, there's still a niche for GIF out there - lightweight animation without loading a browser plugin or a java appet.

PNG was simply a better solution for lossless compression than GIF ever was. The same cannot be said for Theora vs H.264, unfortunately, so the same situation does not apply.

This is not an issue of the secondary DNS vs the primary DNS. This will occur even on systems with only one DNS server configured.

The faults are intermittent. If you're using a DNS server that's whitelisted by Google (such as Hurricane Electrics nameservers) which return AAAA records for www.google.com - as long as the cache is clear when you ask your web browser to hit it, it'll hit Google over IPv4 most likely, since the A record will come back first.

Unless, of course, you ping6 www.google.com with a clear DNS cache, which will force an AAAA response to be cached. Oh joy. Then you'll get to IPv6 into google until the OS decides to mark the cache as dirty...

I sent a bug report to Apple about this earlier. You might want to see if you can reproduce it if you care. :-)

18-Feb-2010 11:57 PM Per von Zweigbergk:
'getaddrinfo-test.c' was successfully uploaded

18-Feb-2010 11:57 PM Per von Zweigbergk:
Summary:
getaddrinfo() will sometimes fail to respond with IPv6 information

Steps to Reproduce:
1. Make sure to be on a machine with IPv6 connectivity as well as IPv4 connectivity, with a DNS server configured to respond with AAAA records for www.google.com. Not all are - by default, Google only provides AAAA records to DNS specifically requesting it. Setting up DNS via Hurricane Electric's nameserver at 2001:470:20::2 should acheive the desired result.

2. Flush the DirectoryServices cache using "dscacheutil -flushcache", and then immediately "telnet www.google.com 80". Close the connection after it has been established.

3. Force an AAAA (IPv6 address) lookup of www.google.com by issuing the command "ping6 www.google.com". You may abort the ping as soon as you see that it's performed the name resolution.

4. "telnet www.google.com 80" again. Close the connection after it has been established.

Expected results:
Both times, running telnet should connect to google via an IPv6 address.

Actual results:
At step 2 (the first time telnet is run), it is very likely that only the IPv4 addresses of www.google.com will be returned to telnet.

Regression:
Mac OS X 10.5.6 seems not to be affected by this bug, in casual testing.

Notes:
I (and others before me) have tracked this down to somewhere past getaddrinfo() - so it's an OS bug, not a problem with telnet. Other applications are also affected. I first noticed this when running tcpdump to ensure that I am, in fact, getting Google over IPv6 with Safari and Firefox.

I have submitted a demo tool in C which will simply query getaddrinfo() and return the information it returns, to verify that the information it returns is in fact the cause of the exhibited behaviour. This tool may be built simply using gcc and requires no linking with any libraries beyond the standard library, and should build on other platforms as well. (I have tested it on Linux.)

Others have discussed this bug as well, as per http://lists.apple.com/archives/Ipv6-dev/2009/Oct/msg00057.html for example - suggests that this may be a race condition.

(I'd post the test application as well, but I have a feeling slashdot will mangle it horribly.)

I assume you're not using Mac OS X 10.6. There's a rather serious bug in Mac OS X 10.6 (still present in 10.6.2)'s DNS resolver making IPv6 completely broken for all practical purposes.

It's pretty embarrassing that they haven't patched it yet.

You're wrong. A compliant IPv6 stack must support IPsec as a mandatory feature. That doesn't mean that all IPv6 traffic is IPsec encrypted.

Deep inspection of IPv6 packets is still possible.

Geeks are unique in that respect, what applies to geeks doesn't apply to 99.9999999999999999999% of the school students of any age.

So, you're saying that there are on the order of 6.79 * 10^-12 geeks in the world?

Give geeks some credit. They aren't as rare as you think.