Some good long-form writing

I'm not sure if it's because the days are cold and dark, so everyone is staying inside and reading and writing, or because there is some sort of harmonic convergence, or perhaps I just got lucky, but I've been reading some very interesting longer-form CS writing recently.

Here's a few examples:

• Carlos Bueno: The Mature Optimization Handbook

  Bueno's e-book is a clear, compact, well-organized treatment of performance optimization. The title is a riff on Don Knuth's 40 year old tongue in cheek sound bite, which sadly is all that many computer professionals ever learn about performance observation.

  If you want to go further, start with Bueno's superb book: he points you in the right direction, saves you from several basic pitfalls, arms you with a collection of useful tools and techniques, and points at resources to help you move further once you've grown comfortable with the basics. I particularly like the fact that Bueno links to some of Richard Cook's, as I think Cook has some fascinating ideas and deserves more attention.

  And I just love this hard-won advice:

  Your instrumentation should cover the important use cases in production. Make all the measurements you want in the lab, but nothing substitutes continuous real-world data. Think about it this way: optimizing based on measurements you take in a lab environment is itself a falsifiable theory, ie, that lab conditions are sufficiently similar to production. The only way to test that theory is to collect measurements in production too.

• Michael Nielsen: How the Bitcoin protocol actually works.

  I've read, oh, approximately 8 trillion articles about Bitcoin; these days, writing a "here, let me explain Bitcoin to you" article seems to be one of the rites of passage.

  Most of them are rubbish.

  But Nielsen's exposition is clear, nicely paced, compactly worded without being dense, and somehow hits just the right level of explanation for me. As I read it, I was reminded of another great document that, while wildly different, is still very similar in approach and technique: Bill Bryant's Designing an Authentication System: a Dialogue in Four Scenes. In both documents, the approach is to start with a solution that seems like it should work, identify the problems with that solution, and evolve from there:

  My strategy in the post is to build Bitcoin up in stages. I’ll begin by explaining a very simple digital currency, based on ideas that are almost obvious. We’ll call that currency Infocoin, to distinguish it from Bitcoin. Of course, our first version of Infocoin will have many deficiencies, and so we’ll go through several iterations of Infocoin, with each iteration introducing just one or two simple new ideas. After several such iterations, we’ll arrive at the full Bitcoin protocol. We will have reinvented Bitcoin!

  This strategy is slower than if I explained the entire Bitcoin protocol in one shot. But while you can understand the mechanics of Bitcoin through such a one-shot explanation, it would be difficult to understand why Bitcoin is designed the way it is. The advantage of the slower iterative explanation is that it gives us a much sharper understanding of each element of Bitcoin.

• Ralph Langner: To Kill a Centrifuge : A Technical Analysis of What Stuxnet’s Creators Tried to Achieve.

  Langer has devoted 6 years of his life to studying, analyzing, deconstructing, and, most importantly, explaining Stuxnet, the most sophisticated and fascinating piece of malware yet unleashed upon the world.

  Although Langer is not the most natural of writers (in his defense, I suspect English was not his first language), he more than makes up for his dry prose with the amazing depth of detail and knowledge that he includes in this work.

  The attack continues until the attackers decide that enough is enough, based on monitoring centrifuge status, most likely vibration sensors, which suggests a mission abort before the matter hits the fan. If the idea was catastrophic destruction, one would simply have to sit and wait. But causing a solidification of process gas would have resulted in simultaneous destruction of hundreds of centrifuges per infected controller. While at first glance this may sound like a goal worthwhile achieving, it would also have blown cover since its cause would have been detected fairly easily by Iranian engineers in post mortem analysis. The implementation of the attack with its extremely close monitoring of pressures and centrifuge status suggests that the attackers instead took great care to avoid catastrophic damage. The intent of the overpressure attack was more likely to increase rotor stress, thereby causing rotors to break early – but not necessarily during the attack run.

  If there is something you want to know about Stuxnet, you will find it here.

  Much of what Langner writes remains controversial, and certainly this story is far from complete. But Langner has done the world a tremendous service by sharing his deep and broad knowledge of Stuxnet widely and openly. Read it. Think about it. Understand just that little bit more about the strange new world we occupy.

So if, wherever you should be, the days are short and the nights are cold, pull up a comfy chair, grab your reading device, and sink your brain into some deep thoughts. Enjoy!