tomstokes

This is a very poor (and misleading) comparison.

First, the author admits that the Gigabit ethernet link was the bottleneck for the Xeon system, capping it at a mere 15% CPU utilization. However, he goes on to use published TDP numbers as the system power draw. TDP numbers are only approached under the most demanding of loads and 100% CPU usage, which this clearly was not. At bare minimum, the author needs some sort of power measurement device to make a reasonable comparison.

Second, serving static web pages is not a difficult task. The Xeon system is overkill for such a task, so of course it will be less energy efficient. In the real world, the extra capacity on this server could be used to perform more difficult tasks or run other processes.

Third, if we assume the Xeon server would scale linearly without being bottlenecked at 15% CPU usage by the Gigabit ethernet link, then it would serving approximately 46,300 pages per second, or almost 8.5X that of the ARM server. Take into account that the actual power consumed in the real-world will be less than the TDP, and the efficiency gap between the ARM server becomes very narrow. Even if the Xeon TDP numbers are accurate, the new margin is still less than 2X.

Finally, the Total Cost of Ownership calculations in the conclusion are based (as the author admits) on the flawed benchmark numbers. If they can only achieve a 77% TCO reduction by completing handicapping the Xeon system, then the ARM system may not be that advantageous. Especially when you consider that without the bottleneck or with a more demanding workload, you would might need as many as 8 times as many ARM servers to replace the performance of the Xeon server, which isn't going to help real-world TCO.

I'm a big fan of the ARM platform, and I'm very excited to see ARM servers enter the marketplace. However, false benchmarks like these aren't going to help anyone. ARM servers will have certainly have their place for a lot of different workloads, but to suggest that they are 15X more energy efficient and have a 77% lower TCO based on these numbers is disingenuous.

Very exciting to see the price of full frame cameras coming down toward more affordable levels. Of course, the camera body is only one half of the equation. DSLR Lenses that can properly cover a full-frame sensor are still going to be expensive.

For those who aren't familiar with camera terminology: 'full-frame' refers to the size of the image sensor. A full-frame sensor is a full 36mm x 24mm, equivalent to traditional 35mm film. Most DSLRs (as well as Sony's NEX series cameras) use smaller APS-C sensors which are 25mm x 17mm (varies depending on manufacturer).

Larger sensors allow for larger pixels, which in turn capture more light. This lowers the noise and improves low-light performance significantly. Furthermore, larger sensors have a more shallow depth of field for the same aperture size, making it easier to provide out-of-focus backgrounds for more artistic shots.

From my experience, this notion of martyrdom is only common among startup CEOs at companies that haven't yet gain traction or found their own success. Self-validation is easy to come by when your company is a success. When things aren't going well, it's much easier to justify if you can convince yourself (and others) that you're working on it as hard as you can.

The idea is that more work now == more success later. The martyr CEO who sacrifices every weekend and never sleeps a full eight hours is the extreme example of putting in more work. And until the company actually achieves success, the long hours of work are all the CEO really has to show other people (and themselves) that their company is worthwhile.

This design is explicitly not open source. From the linked page:

NO SCHEMATIC: Because YoYoDyne is taking considerable financial risk to produce an unproven DAC in relatively high volume, it’s not reasonable to have it be open source (see the previous ODAC articles). Once he’s hopefully recovered his investment, we plan to re-visit the open source question.

However, there are several other open source DACs available with plenty of documentation. One such example: http://www.amb.org/audio/gamma2/

Good question. The Space Monkey software mitigates these issues in two ways: First, all data is carefully encrypted before it ever leaves the user's Space Monkey device for replication across the network. This is obviously a key concern for all of our potential customers, so a lot of time has been spent getting this part right.

Second, the system breaks each file into many small blocks with built-in parity and other such redundancy measures. These blocks are then spread across many devices to both increase redundancy of the network and distribute the bandwidth usage fairly across nodes. As a result, you wouldn't really ever store any identifiable data from any one other customer.

Therefore, if the government wanted to seize evidence, they would gain nothing useful by seizing any Space Monkey device other than the suspect's, which contains the local cache of the user's own data.