Nope, way more common to have that pesky slow audio fiber.

Try sqrt(12000/pi) = ~ 62 mile radius. (AKA 99 km... )

You monster.

Righto - I misread his as the CAs should reject certs for unqualified domains. But then, how can a browser determine unqualified vs. qualified? The DNS server is the authoritative record of domains, so unless you override to an external DNS server, you are not going to impact intranet software.

Intranets can run their own CAs - that's the Right Way to do it, not to issue a public cert for a private domain.

"Bertamax" has me picturing a muscle building product whose spokeswoman is a large german woman...

BertaMAXX!

Depends on the car. The numbers here seem pretty accurate: http://www.ecoworld.com/energy-fuels/electric-car-cost-per-mile.html - they claim 2.9 miles per kWh, or 350 Wh/mile.

Considering a 100hp engine peaks at 75kW, and a (generous) peak speed of 220 mph, we'll assume a 10kW constant load at 30 mph, which gets us 330 Wh/mile (awfully close to the above!), or 33 kWh per 100 miles. You're off by an order of magnitude, unless you're referring to an electric moped.

So, divide my numbers by three. 1500 Amps, and you'll only need 7 of your closest neighbors to donate their power, assuming you drive a truly wimpy car.

A nice electric car, with some get up and go, should line up with my numbers fairly closely (a 200 hp/ 150 kW car).

kW per hour is a meaningless metric. If they're right in saying that electric cars consume 80 kWh per 100 miles, your 60 kW "pump" will charge the car in about 80 minutes. You're off by an order of magnitude.

Assuming a 200 mile battery (minimum useful in my opinion), we're talking about 160 kWh dumped in over the course of 10 minutes, is 960 kW - or about a megawatt. At 220V, that's about 4500 Amps, and normal home service is usually not more than 200 amps. So, if you got 20 of your closest neighbors together, and wired all their houses into one giant charging station (and shut down all appliances, computers, lights, heaters, and stoves), you could charge your car in 10 minutes.

Not seeing this working with our current power grid...

Yup. you're waaayy off. It's hydrophilic. Hence the "dispersing" and not "beading" of the water on the surface. Hence the anti-fog capabilities.

But given all the other demographics, the non-random first 5 digits can often be guessed with some accuracy. So, with a database loaded with demographics tied to those last four random digits, you're bound to be able to successfully complete several SSNs.

Yes. Albeit the lesser of two evils, and infinitely preferable in the scenario you propose.

White hat hackers tend to work "for the good of all". Black hats exploit weaknesses to subvert protective measures for their own (or their organization's) benefits. The goal of white hats is to close security loopholes. Black hats exploit those loopholes.

1. Why do you want NAT? What does it achieve that a simple firewall does not?
2. Once IPv6 is live, there's only one address to worry about. The local one is not only automatically selected, it's automatically used in place of the public one when routing packets locally. You literally never have to use it yourself. Windows even randomizes this to an extent, so remembering it is fruitless.
3. That said, I agree that there's no valid reason to tunnel all traffic to IPv6, slowing your bandwidth. Those tunnels are great for testing and not much else to the general consumer.

That's fine and all, if you're only concerned about the latest revision of the software. But then, why are you using a VCS? Your WC has no record of the (potentially thousands) of revisions on the server. If you're diffing more than one revision backward, you're asking the server for the info, and the server is no longer trustworthy.

Who cares about doubt around the allegations? Look at what happened to ReactOS when it was alleged they had stolen Microsoft code. Development all but stopped. OpenBSD took a hiatus to audit their security libs when it was alleged that there were backdoors included. And those were completely unsubstantiated (and untrue) claims.

We're not talking about wholesale project hijacking, and we're not talking about individual developers having consistent working copies. We're talking about project histories, user privileges, and reputations for all projects hosted on sourceforge. The site administrators must go through their due diligence, verifying every project against full backups that could not possibly have been affected in the attack.

It's fine that you don't understand why the checking is necessary, I'm certain a lot of people don't understand why you need to re-install from scratch after somebody has rooted your box. The fact remains that what's being done is necessary.

Sourceforge uses SVN & CVS, which are fully centralized. If git were being used, I'd agree. As it stands, they only have a working copy (and one prior revision), not the whole history.

What if the code injection were targeted at inserting history to "prove" that the project stole code from a commercial program in order to shut down/cast doubt on the open source project?

Compression algorithms (which these video encodings are) have little to do with sampling rates and channel capacity. A better compression algorithm *allows* you to use a higher sampling rate with the same data rate (thereby mitigating the impact of the Nyquist theorem), and *allows* you to send the same data through a smaller channel (mitigating the Shannon theorem). Neither phenomenon has an impact on the ability of a compression algorithm to compress. That said, I still think we're approaching the limits of A/V lossy compression.