I don't think there's much chance of changing the American negotiators views on this, but I'm still going to contact my representatives in Congress. Nothing will likely come out of it. If you are a /.er in a more reasonable country, say New Zealand or Canada, I beg you to contact your MPs and demand transparency in this process. We shouldn't have to find out about the progress of negotiations through leaks.

Opera trusts CNNIC also.

Not always the case anymore. Web browsers and servers have implemented persistent connections (keep-alive) for a while. It's in the RFC.

Article is behind a paywall. Search for it with Google News, and the WSJ will let you read it all.

It would just go over the air as data. For example, 1500 minutes of G729a voice uses (4.12kB/s * 60 seconds * 1500 minutes) = 370 MB

The question is what kind deal Google could cut with the carriers to provide nothing more than 370MB a month of data transit.

Here's another data point for a random end-user: I've used Google Voice to the tune of approximately 1200 minutes per month for the last four months and haven't experienced service issues with receiving calls or placing calls. I've made very few international calls, however.

The Cisco ASA 5505 is a good choice, but prepared for a bit of a learning curve. For ASA 8.2, the command reference guide weighs in a 3534 pages. If the command-line scares you away, the integrated web management (ASDM) works well for what it is. The 5505 has no fan, provides an 8 port switch (including 2 PoE ports), and is probably slightly greener than an old box running Linux.

Because the package management system runs as root, may install setuid files, or system daemons which contain vulnerable code; an unprivileged user cannot normally do this.

Sure - only signed packages can be installed - but signing a package won't make those pesky buffer overflow vulnerabilities go away.

Certainly there can't be a problem here, says the Fedora team. According to the release notes, there are 15,000 packages which can be installed by these unprivileged users. That's a lot of fscking code -- surely some of it is poorly written. Consider this scenario: Package X suffers a critical {local, remote} root vulnerability. If the vulnerability isn't public, any local user (and maybe remote ones too!) has root. If the vulnerability is public, there is often a long window between downstream fixes and Fedora fixes. In either case, this is a security issue. The Fedora team really should have put this in the release notes and reconsider this implementation in the first place.