1. HTTP Pipeline support proved very difficult to implement reliably; so much so that Opera was the only major browser to turn it on. It can be enabled in Chrome and Firefox but expect glitches. By all accounts SPDY's framing structure is far easier to reliably implement.

2. WIth SPDY, it's not just the content that's compressed but the HTTP headers themselves. When you look at the size of a lot of URLs and cookies that get passed back and forth, that's not a insignificant amount of data. And since it's text, it compresses quite well.

3. SSL is required for SPDY because the capability is negotiated in a TLS extension. Many people would argue that if this gets more sites to use SSL by default, that's a Good Thing.

4. If you're running SPDY, the practice of "spreading" site content across multiple hostnames, which improves performance with normal HTTP sites, actually works against you, since the browser still has to open a new TCP connection for each hostname. This is an implementation issue more than an issue with the protocol itself; I expect web developers to adjust their sites accordingly once client adoption rates increase.

5. The biggest gains you can get from SPDY, which few have implemented, is the server push and hint capability; this allows the server to send an inline resource to a browser before the client knows it needs it (i.e. before HTML or CSS is processed by the browser).

But as someone else as pointed out, the author's test isn't really valid, as he didn't test directly to sites that support SPDY natively, he went through a proxy.

The website I work for is supporting SPDY, and the gains we've seen are pretty close to the ~20-25% benchmarks reported by others. As many have pointed out, this author's methodology is way broken. I'd recommend testing to sites that are known to support SPDY (the best-known are Google and Twitter), with the capability enabled and then disabled (You can set this in Firefox's about:config, Chrome requires a command line lauch with --use-spdy=false in order to do this, though).

I remember these. They weren't even electronic - each button on the remote caused a tine to be pulled and released which was tuned to a specific ultrasonic frequency. This is why the early remotes were called "clickers" - releasing the tine made a metallic clicking sound. It also meant that random ambient sounds that matched the target frequency could cause your TV to turn on/off, change channels, etc on its own.

There were also remotes that weren't even wireless, with a 10' long tether wire to the unit. The advertised "advantage" of these was that they didn't need batteries.

Hear hear. For example, my mother uses 3G (and soon LTE) for internet access to her home, which is a rural area that isn't served by either cable or DSL, and has no line-of-sight access for satellite service.

That's how perl was fixed - XOR each incoming key with a random value generated when the hash is initialized.

The real problem here is that it's fairly easy to compute a set of hash keys that are known to generate collisions on a specific hash table implementation. The easiest fix by far - the fix that perl implemented in 2003 - is to generate a random value when the hash is initialized, and XOR each incoming key with it before processing. That breaks collision prediction on the attacker's side quite effectively.

To be precise, it elements with equal *exit* hash values - the same hash key will simply overwrite prior values. Internally, the language runs a hash algorithm against the key and uses the resulting value to generate an index to the array that *actually* holds the key/value pair. If multiple keys hash to the same index, then the value will actually be another array, containing all the key/value pairs that mapped to that index. You then need to walk that index to find the key you're looking for.

The downside of this, of course, is that if all of your keys map to the same hash value, then you have to walk the list of *all* key/value pairs to find your value. Producing this scenario on demand is how you kill servers with it.

The "real" code fix so far is to transmute the key with a random value (generated at application startup, or at instantiation of the hash map) before running the hash algorithm, thus making it impossible to predict which keys will generate hash collisions. This is how perl was fixed this back in 2003 :)

Most folks seem to simply be setting limits on the number of fields in POST (or the maximum size of a POST payload) for now until they can fix their code. Putting limits on the number of HTTP headers in a request is needed as well, as apache itself puts headers in a hash map.

Entirely plausible. Conficker's phone-home mechanism was an algorithm that hashed the current date/time to generate a nonsense domain name, which it would then try to look up and grab a payload from. All the Bad Guys had to do was register one a few hours in advance, put up the payload, and wait. The groups who were fighting the thing managed to decompile the algorithm and play it forward, generating a list of hundreds of thousands of domain names that they then took to the various registries to get blocked. Paul Vixie was a big part of this, and here's a pretty good article on the group.

It would not surprise me at all if CIA/Mossad/etc managed to get one of those domains un-blocked and used to deliver the Stuxnet payload.

More to the point, it seemed that the biggest initiatives within Yahoo while I was there (from 2009 until early this year) were *all* centered around profit, not users - mainly, cost-cutting and ad tech. As if the goal wasn't to grow users, just grow revenue and profit per existing user. What opened my eyes was when the cost-cutting initiatives that made sense - primarily the data center consolidations, which definitely needed to get done ASAFP - started getting pushed back due to the need for quarter-to-quarter profit management. Bartz should have grown a pair, pushed forward the consolidation even if it meant missing the street for the quarter, allowing Yahoo to reap the rewards much sooner.

I'll also never forget the quarterly all-hands meeting where the major product announcement for the quarter was...*full-page ads on the login page*.

Sorry I didn't stick around to see Bartz go, but I couldn't risk her *not* going.

I'm guessing the $3 comes from $1 for each of the three charges in the original suit - the lowest amount a US Judge is allowed to award a plaintiff. In other words: "I have to decide in your favor, but I'll be damned if you actually get anything out of it".

Richard Branson, Bill Gates, Warren Buffet, Michael Bloomberg, Brin/Page, Zuck, and Larry Ellison would all like to have a word with you.

"Work For Hire" provisions are unenforceable in recording contracts because US copyright law is rather specific about what can be considered a work for hire - and sound recordings are not on the list. It was briefly added in 1999 but was removed a year later.

http://www.salon.com/technology/feature/2000/06/14/love/print.html

Apparently a "work for hire" provision did get slipped into federal copyright law - and I mean literally slipped in while no one was paying attention. After Love's speech brought attention to this, the provision was repealed a year later.

So unless the laws get changed again (and the RIAA *will* try), the artists have the upper hand. Sad to imagine how much they'll spend in legal fees to get to their money though.

As a 39-year-old who switched from perl to python about 3 months ago, I can agree with this statement.

No, unfortunately...I think I just renamed it 'irc' or 'company-irc' or similar.

Is this the same scanning that Google does with GMail? If so, why no outcry there?