In the case of a Hadoop task failure, the errant monkey was genetically cloned but put into a different environment. So it also served as a nature vs. nurture experiment. :)

Yup, I realize that going to Atom or ARM for a CPU bound process is suicide, but so is only using the tiny amount of money to try and solve the problem. :)

This is absolutely correct and if I had mod points, I'd spend them here.

If your budget is only £4000, you don't have the funding to build a real, actual grid for something that is CPU bound. If you are lucky, you have enough to get one or two boxes and some network gear to put on the top of someone's desk.... at least if you are doing AMD or Intel higher end procs.

Here are two ideas worth exploring...

1) Look at boxes like SeaMicro and other Atom-based mini-grids-in-a-box.
2) Look at building your own with Atom- and Arm- based machines

Yes, but I don't think Yahoo! is adding any more universities to it. In fact, I don't think it ever expanded beyond CMU.

ObDisclosure: I was on the ops-side of that project for Yahoo!.

I wonder if PHP has the same problem we do in Hadoop-land... the lack of enough qualified security people interested enough in a project to actually review code. For example, I'd love for someone with a clue to review Alfredo ( http://cloudera.github.com/alfredo/docs/latest/index.html ) before we build a dependency on it ( https://issues.apache.org/jira/browse/HADOOP-7119 ) . But it seems as though getting the right people involved is extremely difficult. :(

Harmony is an effort that was begun and shepherded by Amanda Brock"

To some of us, Harmony is the name of Apache's Java implementation. Sort of surprising that this naming clash wasn't considered given the context. Heck, TFA even mentions Apache HTTPD.

For the record, we actually used ApplixWare prior to StarOffice.

Even if the schedule is "Tuesday-9am: Give trach to Mrs. Lattimer"?

You might want to take a read through this: http://www.imdb.com/title/tt0056751/board/nest/175533855

Someone is watching all of the complete episodes in order. As someone who has watched almost all of the remaining episodes (in fact, I started watching Troughton's War Games episode for the 3rd time last night), it is fascinating hearing an outsider's perspective of some of the episodes.

I tend to agree with most of what has been said here. For Classic, start with Baker and work your way up. Even though I still think most of Pertwee, Troughton and Hartnell is great to watch, there are a lot of slow episodes in those first three Doctors that you likely won't survive.

For modern, start with Eccleston (altho he wasn't my favorite) if only because there is a lot of background provided that you'll need for the rest of the (new) series.

... and to make matters worse, top500 is based primarily on LINPACK. So top500 is really a measure as to how fast something can do floating point with a distributed shared memory model and not much else. Most of the systems listed in the top500 would fail miserably at heavy IO loads, which is what most of the increasingly common Big Data problems need. It concerns me that manufacturers are building systems for one top of heavy duty computing based on top500 while ignoring the others.

To me, this is just more evidence that they will be dropping OS X and moving to iOS for all devices over the next five years. If they were to introduce a new Xserve now, I suspect that the support date is past whatever EOL date they have in mind for OS X. What is essentially an appliance OS won't work for what are technically meant to be back end servers except for very limited applications. The people who buy the most Xserves (HPC, etc) do not fall into that category.