Stuff to read, late May edition

Happy Memorial Day, a little bit in advance.

• Silicon Valley Is a Big Fat Lie

  What was once a land of upstarts and rebels is now being led by the money-hungry and the unspirited. Which is why we have a start-up that mails your dog curated treats and an app that says "Yo." The brightest minds in tech just lately seem more concerned with silly business ideas and innocuous "disruption," all for the shot at an immense payday. And when our country's smartest people are working on the dumbest things, we all lose out.

  That gap between the Silicon Valley that enriches the world and the Silicon Valley that wastes itself on the trivial is widening daily. And one of the biggest contributing factors is that the Valley has lost touch with reality by subscribing to its own self-congratulatory mythmaking.

• Google systems guru explains why containers are the future of computing

  Inktomi and also early Google ended up using essentially a Unix process model and doing everything in terms of processes, running many processes on the same piece of hardware. In fact, Google didn’t use virtual machines really at all until it started doing some corporate stuff where it wanted to run third-party things. But all the internal stuff never used VMs.

• A Repository with 44 Years of Unix Evolution

  The evolution of the Unix operating system is made available as a version-control repository, covering the period from its inception in 1972 as a five thousand line kernel, to 2015 as a widely-used 26 million line system. The repository contains 659 thousand commits and 2306 merges.

• Microsoft, Salesforce talks fizzled over price: Sources

  The deal envisioned Microsoft using a significant portion of its $95 billion cash pile to pay for Salesforce, but there was discussion of allowing Benioff to roll his 5.7 percent stake in Salesforce into Microsoft stock, while other shareholders would have gotten paid in cash. Benioff would have had a management role at Microsoft under the deal, according to people close to the talks.

• Top 10 data mining algorithms in plain English

  Once you know what they are, how they work, what they do and where you can find them, my hope is you’ll have this blog post as a springboard to learn even more about data mining.

• Why should I have written ZeroMQ in C, not C++ (part I)

  While the possibility to handle the exceptions differently in different contexts may seem appealing at the first sight, it quickly turns into a nightmare.

  As you fix individual bugs you'll find out that you are replicating almost the same error handling code in many places. Adding a new function call to the code introduces that possibility that different types of exceptions will bubble up to the calling function where there are not yet properly handled. Which means new bugs.

• Why should I have written ZeroMQ in C, not C++ (part II)

  The real reason why any C++ programmer won't design the list in the C way is that the design breaks the encapsulation principle: The implementer of the "person" class has to know that its instances will be eventually stored in "people" list. Moreover, if a 3rd party chooses to store it in a different list, the implementation of the person would have to be change. This is an anti-pattern that OO programmers learned to avoid.

  However, if we can't place the "prev" and "next" fields into "person" class, we have to put them elsewhere. Thus, there's no other option but to allocate a helper object, the way std::list<> does.

• Don’t Stack Your Log On My Log

  Our work investigates the impacts to performance and endurance in flash when multiple layers of log-structured applications and file systems are layered on top of a log-structured flash device. We show that multiple log layers affects sequentiality and increases write pressure to flash devices through randomization of workloads, unaligned segment sizes, and uncoordinated multi-log garbage collection. All of these effects can combine to negate the intended positive affects of using a log.

• How Could a Flash Cache Degrade Database Performance Rather Than Improve It? Lessons to be Learnt from Multi-Tiered Storage

  Contrary to intuition, host-side flash caches can degrade performance rather than improve it. With flash write operations being expensive, cache hit-rates need to be relatively high to offset the overhead of writes. Otherwise, the end-to-end performance could be worse with flash cache.