Replacing "speed" with "data rate" and making a few other substitutions, we have a question I find interesting. "What was the data rate of that particular laden African swallow?"

The story is missing an absolutely critical piece of info though - how much data there was. Without that knowledge, the story is pretty meaningless. If I transport 30 GB of data by thumb drive physically (whether by pigeon or car or whatever) in an hour, I can get it there far faster than my home cable modem. If it was 1 MB of data, it's a very different story.

Judging by the fact that the time "including download" to the destination system was about an hour longer than the time it took for the pigeon to fly, I'd say it very well could have been at least a few GB.

For sake of a wild-ass guess, giving, say, 20 min overhead for fumbling around with the data card, putting it on and off the pigeons leg, etc., and dividing the remaining time by two (1 transfer onto and 1 transfer off of the device), that puts each transfer at around 15-18 min. At 20 MB/sec, it could have been around 18 to 21 GB of data being transferred. That translates (under the aforementioned massive and barely justifiable set of assumptions) to about 2.3 to 2.8 megabytes per second moved by pigeon (20-ish GB moved in 7617 seconds).

I'm not going to waste (more) time analyzing sensitivity to changes in my assumptions, but at a guess I'd say the result is moderately sensitive to changes in both pigeon-to-computer transfer time and pigeon-to-computer data rates. In other words, take the numbers above with a pretty big grain of salt.

The inconsistency is only annoying if you're one of the poor schmucks whose browser developers thought having a feature was invariably better than not having said feature. In fact, there's a whole slough of other "features" I've wished weren't in my browser throughout the years, too. Audio, for one.

Actually, I'd say he described (not exemplified) the disaster that is humanity.

Actually, your blog paints a picture of your readership. Agreed, 99.997% is probably made-up. After, all, 99.997% of all statistics are made up on the spot ;). But (and I mean no offense when I say this as I don't know the first thing about you or your blog) I really doubt that your blog is representative of the market as a whole.

Lots of engineering problems have been solved. What's your point? I'm not normally one to defend MS, but honestly - designing an XBox (even one called "360") to withstand rotation while reading a disc is really not necessary. Not every device needs protection from every possible mode of failure. Not only that, but in this particular case your examples do not demonstrate a solution to the problem because they do not involve the same kind and amount of motion.

A discman spins its disc much more slowly ("1X" in the old-skool models, typically around 500RPM according to wikipedia) than a DVD drive, and thus gyroscopic precession is much less violent. I haven't checked, but I'd also suspect the read head is not as close to the disc due to less stringent focusing requirements. A car CD player is positioned so that the axis is vertical so that the disc experiences very little precession (the axis of the disc's rotation does not change much, ever), AND it also typically spins at around 1X. An XBox may or may not be resilient to the type of shock a jogger or a pothole would give a CD player, I don't know, but shock is not the cause of the scratch in the OP's story.

Neither of those examples demonstrates resilience to the situation described in the OP - a small plastic disc spinning at around 6000 RPM (12x DVD) undergoing a 90 degree change of axis in the span of maybe around 3/4 of a second. Neither a discman or a car CD or DVD player ever faces that situation. Honestly, I'd be a bit surprised if a cheap solution for that particular engineering challenge exists on today's market. And any solution that is not cheap would be wasteful over-engineering for an XBox, because it's just not something an XBox needs to be able to do.

Well, given an 8k or 16k block size, a 12k file *DOES* consume 16k of usable disk space. Plus 600-700 bytes for the inode and directory entry. Plus more if there's any magic Apple-y metadata associated with the file.

For what reason do you expect any filesystem browser to report the exact number of bytes in a file? I'm almost always more interested in knowing how much disk space is used by the file - 16k in your example. In a filesystem like JFS that dynamically allocates inodes, I might even expect it to report the space used by the inode. FWIW, 'du' will report 16k in your example as well. Is 'du' wrong too?

Also, what should it report for directories? Taking a directory of the source of GHC 6.10.4 on my computer as an example (lots and lots of smallish source code files):

$ find . -type f -exec cat {} \; | wc -c
  29776950
$ du -sk .
35036 .

Those numbers don't match (taking into account the conversion between bytes in the first case and kb in the second), but I can't see a reason ever to care about the first one. It's not even a very good indicator of what size an uncompressed tar file would be.

Finally, I just went and took a look at a small file on the desktop of my mac. "Get Info" tells me:

Size: 8 KB on disk (782 bytes)

So it *does* report the number of bytes in the file, as well as the disk usage, clearly labeled. Now I really don't exactly know what you're whining about.

Sounds like we need a /. poll on this. Personally, I'd have to rate "Scrum" as a worse name than "Extreme Programming", though they're both way up there.

I would not be surprised if the rates have not changed significantly. The problem is not the phones, the problem is the people who do not have enough respect for the 1 million or so Joules of kinetic energy in their control. People have always had things that could have distracted them.

And it's for an architecture you don't have.

). Captured your post! You've been parenthesized!

Captcha FAIL :P

There ought to be rest G after you hit $max_lvl

If you seed it long enough to reach a 1:1 up/down ratio, then it has in turn been stolen from you, giving no taxable net gain on your part, right? ;)

Unless you're Microsoft... *ducks*

All that means is that the viewers aren't the customers.