It's 5,000 words and 2,000 lines of javascript, plus a few fair-size images, which may explain the long TTFB. But most of the delay is not bandwidth limits but PHP and SQL. The site runs on a creaky WordPress implementation. Someday I'll fix that, if I live so long.
My source for the statement that "instruments were being tuned to this scale well before the invention of logarithms" is an article by Edward Dunne and Mark McConnell, "Pianos and Continued Fractions," Mathematics Magazine, Vol. 72, No. 2 (Apr., 1999), pp. 104-115. They write: "Guitars in Spain were evenly tempered at least as early as the fiftheenth century, two hundred years before Bach. And Hermanus Contractus, born 18 July 1013, invented a system of intervalic notation that anticipated equal temperatment."
My source on Simon Stevin's work is a Rudolf Rasch, "Tuning and Temperament," published as Chapter 7 in The Cambridge History of Western Music Theory." Rasch gives an interesting account of the state of root extraction before the advent of logarithms. He attributes the errors to "Stevin’s sometimes rather reckless rounding of digits after the decimal period, which are often truncated rather than rounded."
This is an important point. The Google white paper does address it, though only in the abstract: They want to maximize both capacity and IO bandwidth. One can imagine large disks with multiple independently actuated head assemblies. But quite possibly you're right that it's not worth the both.
The interesting thing about Google's storage infrastructure was that teams were optimizing IOPs per drive and talking to thousands of them over a gigabit link. I had an interesting conversation with Sean about that one day, asking him if he got 100 IOPs per drive, and had 10,000 drives, and a gigabit ethernet port, how much data on the drive could be part of any service being provided over that gigabit link? Plot that over a RPS (generic 'requests per second').
In my case I was trying to get him to sign off on powering down some of the drives that could not be reached to save power. But even with the data staring him in the face he could not go there. Network bandwidth gets better, and that exposes more data to the pipeline, but if you want < 500mS request response you have to balance the system.
I'm the author of the story linked to here. I'm also the jerk who pulled it off the web when I thought my site was getting the DDoS treatment. Mea culpa.
I'm the site owner. It's open again, temporarily. Somebody's script has multiple machines (many are EC2 instances) downloading the same file many times per second. That's not something I want to encourage.
Interesting. I suppose an automated DDoS of everything on the hackernews front page isn't impossible.
Are there other explanations? Scribd definitely got it automatically at least once, maybe they do it too many times? How many HN users use EC2-based proxies?
It's 5,000 words and 2,000 lines of javascript, plus a few fair-size images, which may explain the long TTFB. But most of the delay is not bandwidth limits but PHP and SQL. The site runs on a creaky WordPress implementation. Someday I'll fix that, if I live so long.