Wandering Thoughts

Link: A Short History Of Removable Media Behind The Iron Curtain

Pete Zaitcev's A Short History Of Removable Media Behind The Iron Curtain is a fascinating look into the history of (re)movable hard drives in the USSR. Apparently these were far more common there than they were in the west, to the point where it was routine to do this with what the west thought of as fixed hard drives. As a bonus it also includes some information on the early history of byte order independence in Linux filesystems, which Pete Zaitcev was there for.

(I know just enough about the history of computing behind the Iron Curtain to know that it was fairly different from the history in the west. My impression is that there was a fair amount of fascinating hacks and improvisations, and presumably some amount of really impressive original work.)

Link: Against DNSSEC by Thomas Ptacek

Against DNSSEC by Thomas Ptacek (@tqbf) is what it says in the title; lucid and to my mind strong reasons against using or supporting DNSSEC. I've heard some of these from @tqbf before in Tweets (and others are ambient knowledge in the right communities), but now that he's written this I don't have to try to dig those tweets out and make a coherent entry out of them.

For what it's worth, from my less informed perspective I agree with all of this. It would be nice if DNSSEC could bootstrap a system to get us out of the TLS CA racket but I've become persuaded (partly by @tqbf) that this is not viable and the cure is at least as bad as the disease. See eg this Twitter conversation.

(You may know of Thomas Ptacek from the days when he was at Matasano Security, where he was the author of such classics as If You're Typing the Letters A-E-S Into Your Code You're Doing It Wrong. See also eg his Hacker News profile.)

Update: there's a Hacker News discussion of this with additional arguments and more commentary from Thomas Ptacek here.

Link: My current dmenu changes

As I've mentioned before, I have a set of changes I've made to dmenu to make it work better for me. I have now put my current patch online as dmenu-4.5-tip.patch in case anyone is interested. I happen to like all of my changes, but then I would. See the start of the patch for a description of what it includes (and then the documentation for the new switches in the revised dmenu.1 manpage).

I expect that I'll update this patch periodically as the main dmenu source itself gets updated, but so far the latter doesn't seem to change very often.

PS: to save the energy of anyone asking: while my patch set contains a bugfix for dmenu's handling of -m (and the manpage), I don't currently feel like breaking it out as a separate patch and then trying to send it upstream. It's too much work for too little chance of success.

Update, August 4th 2015: The patchset linked above is now out of date, per here. My dmenu changes are now in my github repo for my version, split up into multiple commits that you can cherry-pick as desired.

Link: Go at Google: Language Design in the Service of Software Engineering

Go at Google: Language Design in the Service of Software Engineering is an article version of a Rob Pike keynote on, well, let me just quote:

The Go programming language was conceived in late 2007 as an answer to some of the problems we were seeing developing software infrastructure at Google. [...]

Go was designed and developed to make working in this environment more productive. [...]

The article then discusses what this means and how various aspects of Go's design were consciously shaped by a number of pragmatic software engineering issues in building large software across large(r) teams. I find it really interesting reading (and I keep referring to it and having to re-find it, so it's clearly time to put this somewhere more obvious).

Link: Getting Real About Distributed System Reliability

Jay Kreps' Getting Real About Distributed System Reliability is a very interesting discussion of the reliability of distributed systems in the real world. He patiently explains that a number of assumptions normally made to reason about this are in fact wrong in practice, especially the assumption that failures are independent. I'm not going to try to summarize his entry beyond that; go read it instead.

(I suspect that his logic extends to all real systems, not just distributed ones, and in any case he has given me a lot to think about.)

By the way, several of the links in his entry are themselves worth following and reading carefully.

(I believe I got this from my Twitter stream but I cannot find the original source now.)

Link: Filenames.WTF

In Filenames.WTF, Daniel Rutter runs down the reasons first why paying attention to file extensions is ridiculous, and then the reasons why it's still the best solution to the problem that we have. Spoiler: it's because people have spent decades creating file formats that suck.

(Via philliph on Twitter.)

Another Russ Cox regexp article: How Google Code Search Worked

Russ Cox has just added another article in his series on regular expressions; this one is titled Regular Expression Matching with a Trigram Index, or How Google Code Search Worked. It's as worthwhile as all of the previous three.

Link: Russ Cox's articles on regular expressions

If you have any interest in regular expression matching, especially efficient regexps and understanding why Perl, Python, and so on have sometimes oddly slow implementations, you really want to read Russ Cox's series of articles on regular expressions.

The core things to read are his three part series, Regular Expression Matching Can Be Simple And Fast, Regular Expression Matching: the Virtual Machine Approach, and Regular Expression Matching in the Wild.

(I know, this is late, since Hacker News discussed this a couple of years ago (plus the comment here). The gears of my link-pointing machinery evidently grind very slowly, but better late than never.)

Link: Pollution in 1.0.0.0/8

IANA has recently allocated 1.0.0.0/8 to APNIC, which has caused a certain amount of concern that it is 'polluted' by people already using it for various reasons. Pollution in 1/8 is a report from RIPE Labs on what happened when they announced routing for some bits of it as part of their debogonising work.

This is clearly going to be what they call 'interesting'.

(via Hacker News.)

Link: Using colour well in data visualization

Why Should Engineers and Scientists Be Worried About Color? is about how straightforward use of colour in data visualizations can mislead you and hide information (and how to do better). Some of their examples are eye-opening and alarming.

(Via Hacker News.)

(Since I took up photography I've had a much increased interest in how we perceive things, including colour.)