6.033--Computer System Engineering

Suggestions for classroom discussion of:

Butler W. Lampson. Hints for computer system design. ACM Ninth Symposium on Operating Systems Principles, in Operating Systems Review 17, 5 (October, 1983) pages 33-48.

by J. H. Saltzer, February 14, 1996, revised May 13, 1997 and May 18, 1999

This paper may be read either at the beginning or at the end of the term; it is actually a good idea to read it twice.

When read at the beginning of the term, this paper can be discussed only superficially, because the motivation for many of its suggestions is lacking. Nevertheless, even a beginning reader can sense that there is some substance to the paper.

This is a good paper on which to practice first nibbling around the edges...

• This paper was published in 1983. Is it still relevant? Why?

• Where was it published?: SOSP is a very high-grade conference. It typically accepts only one out of five submitted papers.

• What can we learn by looking over the references?

  • The list is quite long--54 citations. It suggests a scholarly approach

  • Seven of the papers cited are by Lampson. But that is only a small fraction of the total, so it suggests that he is familiar with other work. The seven citations to his own work were published in quite a range of places--books, prestigious journals, user's manuals, and a patent. This diversity suggests an interesting person wrote the paper.

  • He cited one of my papers, and several by former M.I.T. students of computer systems (Bobrow, Gifford, Janson, Metcalfe, Reed, Tanenbaum.) Obviously he knows where the good work is to be found. More to the point, several of the cited authors are found elsewhere in the 6.033 reading list.

This paper provides an introduction to "system thinking". What does that mean? (Relate to complexity lecture, methods of coping, and the general method of looking at the whole picture.)

Can you identify any of the hints as examples of the methods of coping with complexity discussed in lecture?

 plan to throw one away  --> finding the right modularity,
                                 design for iteration

            keep secrets --> abstraction

      Divide and conquer --> modularity

       Do one thing well --> functional modularity

         Use brute force --> use brute force

Most students will have absorbed the slogans without much comprehension of their subtleties; the thing to do now is to try to remember them for what is coming. One approach is to try to identify examples of the hints in designs that people are familiar with, or that were in the one or two case studies they have seen so far.

When read at the end of the semester, or for the second time, the best attack is to ask the class to help you compile a list of examples of Lampson's hints that appeared in the case studies during the term. There are a couple of ways to approach this:

1. Make it concrete. What is the {best, most obscure} example you can think of for slogan X that we have seen this term?

2. Look for connections. Where is Lampson restating things we have read (perhaps said quite differently) in other wisdom papers?

            wisdom             Lampson
     Do the right thing --> Get it right
        Worse is better --> Keep it simple
              Chocolate --> Safety first
 plan to throw one away --> plan to throw one away

Is there a debate between abstraction and open design? The hint is "Keep secrets". But open design teaches us to expose everything. Start with examples of ebstraction:

• TCP hides reordered delivery and packet duplication and loss.

• Client/server hides the implementation

• atomicity hides the compositeness.

• Open Source: Emacs, Linux, Apache, etc.

• IBM PC and SCSI were both open designs

• Crypto systems need it

• safety-critical systems need it (Therac)

• reverse: British law surrounding ATM's

From Frans Kaashoek: Another fun thing to do is to construct a list of failed computer systems, and figure out why they failed. In some cases the failed systems "violated" some of Butler's hints; in other cases, the reason of failure is more complicated. Nevertheless, making such a list is an interesting exercise.

From Dawson Engler: A possibly missing hint: use indirection. Go through an intermediary to an object. Examples:

• High-level language is a kind of indirection between the program and the underlying architecture

• Naming. Decouples identity from implementation.

• Virtualization--virtual memory, threads. Goes from physical/small-limits to virtual and unlimited.

• Emulation. Use indirection to emulate old on new or vice-versa. Forward compatibility--encapsulate new protocols inside old. Backward compatibility--emulate new instructios on old architectures.

Aside: Is this paper mistitled? Just what is a hint, anyway? See Hints versus Caches.