My previous post on S4D did omit some of my notes from the conference. In particular, the very entertaining and serious keynote of Barry Lock from Lauterbach and some more philosophical observations on the nature of debugging.
Looks like S4D (and the co-located FDL) is becoming my most regular conference. S4D is a very interactive event. With some 20 to 30 people in the room, many of them also presenting papers at the conference, it turns into a workshop at its best. There were plenty of discussion going on during sessions and the breaks, and I think we all got new insights and ideas.
This post features some additional notes on the topic of transporting bugs with checkpoints, which is the subject of a paper at the S4D 2010 conference.
The idea of transporting bugs with checkpoints is some ways obvious. If you have a checkpoint of a state, of course you move it. Right? However, changing how you think about reporting bugs takes time. There are also some practical issues to be resolved. The S4D paper goes into some of the aspects of making checkpointing practical.
I have a new post at my Wind River blog, about variability and determinism and how these two concepts interact. In short, even a deterministic simulator can expose great variability in a software workload and target system behavior.
The EDSAC was an early computer in the mathematics laboratory at Cambridge in the UK. I have just read an old article on the machine and how it was programmed, from a 1998 issue of the IEEE Annals of the History of Computing.
There are many fascinating aspects to the machine and its utter simplicity, but one that struck me as I read the paper was that so many of the fundamental ideas of programming and practical computing were invented then and there. Indeed, the EDSAC was designed as a machine to experiment with programming, rather than as a machine for maximal computing performance.