The four pros I spotted were "cool", "learning and having fun", handle "a huge amount of data" and "distributed processing." There's no claim that it's trying

The four pros I spotted were "cool", "learning and having fun", handle "a huge amount of data" and "distributed processing." There's no claim that it's trying to give the complete picture. It's trying to solve a specific task for chess board analysis. Nor did it reject that Hadoop was always the wrong solution, only that a single node can be faster than Hadoop. An existence proof is a low barrier to cross. You say "this is a different scenario" and I have to shrug. I used to do molecular dynamics distributed across a compute cluster or using a supercomputer. That's yet another different scenario, and also one where Hadoop doesn't work. Last I heard, simulation software I helped write now runs across 8,400 cores. (See http://www.ks.uiuc.edu/Research/gpu/files/gtc2013_phillips.pdf http://www.ks.uiuc.edu/Research/gpu/files/gtc2013_phillips.p... .) The visualization project I used to lead now analyzes 100+ TB of simulated trajectory data. (See http://on-demand.gputechconf.com/gtc/2014/presentations/S4410-visualization-analysis-petascale-moledular-sims.pdf http://on-demand.gputechconf.com/gtc/2014/presentations/S441... .) MD definitely falls into "Big Data", yet the examples I gave don't use Hadoop or data partitioning like you suggest, so your statement about Big Data frameworks is really restricted to only a subset of what people do in Big Data. So yes, you're right. The original essay isn't complete. Neither is this new one, which didn't include all the problems with Hadoop, like poor inter-node latency, and lack of support for MPI. The 'real choice' isn't as dichotomous as you make it out to be. A set of powerful non-commodity hardware, like Blue Waters, may be the right approach for some scenarios. "Without the complete picture" I disagree. The new essay gives a different picture. A lot of pictures fit well in the frame of Hadoop, for the reasons given in the new essay. In this case the pictured scenario is chess data analysis. In this case it looks like a single node is faster. However, it's not better for the original original task, which was to experiment with learning Hadoop. ("I was skeptical of using Hadoop for the task, but I can understand his goal of learning and having fun with mrjob and EMR.") As the original original spec no longer exists, I cannot tell if fault-tolerance was one of them. As it was a personal learning project, no doubt it wasn't. So this new essay is adding details that weren't relevant to the original task, then complaining that the details weren't addressed. This is poor form. You ask "how can you say when you need one, ten or 100" and the easy answer is to go ahead and implement it on one node. If it takes an hour to write a single node solution would take, and it's fast enough for your foreseeable needs, then you're a lot better off than spending a day to try out a Hadoop solution. Plus, without the single node solution it's hard to know if you have a good baseline.