If a DNS reply passes DNSSEC validation, I can be confident the response is what the zone administrator wanted it to be and it hasn't been tampered with. DNSCurve provides no such assurance.

Widespread DNSSEC and client-side validation would kill OpenDNS's business model, which revolves around tampering with DNS responses. DNSCurve continues to allow them to do this.

However, if someone could develop a drop-in replacement for Windows which was compatible with all the APIs

Have you just described the goal of Wine?

There is also the question whether this video will influence more people to commit suicide. The Samaritans have a section on their website explaining how to report and dramatize suicides responsibly.
http://www.samaritans.org/media-centre/media-guidelines-reporting-suicide

The problem is that it encourages other people to commit suicide too.
http://www.samaritans.org/media-centre/media-guidelines/advice-media-copycats-and-social-contagion

Remember - we're comparing IPv4 with NAT against IPv6.

Yes the ISP allocates the IPv6 prefix, but then again with NAT every source packet has the same IPv4 address. The real difference is that with IPv6 every single request can be given a different source address. If the source addresses are picked randomly from the /64 pool then it should be impossible to identify individual hosts within the /64 based solely on IP address information. As you rightly point out there are other effective ways of doing this already, but that's not an argument against using IPv6.

I've never understood this concern. With IPv6 I have, say, 2^64 addresses to use. I could use a different source IP address for each and every HTTP request I send out. Even at 1000 requests a second we'll all be long dead before you had to reuse a source address.

IPv6 gives you loads of room to hide. This is my concern - address based blocklists will quickly become infeasible.

All these posts and no-one has mentioned it runs on FreeBSD?

Netflix's New Peering Appliance Uses FreeBSD

feel free to operate your own resolvers.

Preferably with DNSSEC turned on.

Facebook are willing to sue. They don't want people to do this either. It devalues their service (even if the users are the "product", they still need to provide something of value to attract users).

Facebook probably wants to be able to charge companies for access to potential employees' data

businesses actually have a product if they're offering Cloud services, whereas dotcom companies generally did not.

If there is a Dotcom bubble and if it does burst, how many customers are the cloud services going to have left?

Does the operating system not provide the SSL libraries? Or do you actually have to code the encryption routines into each application on iOS?

I would have thought the export restrictions would only apply to the SSL libraries, not the application that uses them.