M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering Handout 2 - February 6, 2000

Assignment 1: February 6 through February 15

Each week you can expect to find an assignment like this one on the 6.033 home page, telling you what you should read over the course of the following week. Occasionally we will be organized enough to predict the readings a few days beyond the next Tuesday. Numbered readings, such as "reading #2," refer to materials in the packet you pick up from the EECS Instrument Room (38-501).

Each week you are expected to complete two assignments. The first is a short reading report, called a "one-pager." It is a short (one page) written report due at the beginning of every Tuesday recitation. The specific topic to be addressed in the report will be given on the previous week's assignment sheet. In recitation you should be prepared to talk about the whole paper, not just the particular point of the writing assignment. Note that we strictly adhere to the single-side, one-page limit. This forces you to prioritize issues and write concisely.

The second is a hands-on experimental assignment, which you can usually complete at an Athena workstation, sometimes using the Web. The idea is to try and reinforce some of the abstract concepts from the lectures or papers that week by getting your hands dirty using software tools.

For Lecture: Wednesday, February 7

Read Chapter 1, and begin reading the paper by Simon, "The Architecture of Complexity" (reading #3).

For Recitation: Thursday, February 8

Finish reading Simon, "The Architecture of Complexity" (reading #3). Simon discusses the power of hierarchy using an astonishing variety of examples from many fields. As a personal exercise, after reading the paper, you may want to identify two examples of the use of hierarchy in Project Athena, and understand how hierarchy provided significant leverage or advantage.

In addition, read Gabriel's paper (reading #2). This is a lightweight paper, but makes a thought-provoking point. In general, we will have at most one heavy-duty technical paper per recitation, sometimes accompanied by an easy-to-read paper with up-to-date information, a thought-provoking point, an issue important to society, or high entertainment value.

For Special Lecture: Friday, February 9

This lecture is provided by the staff of the Writing Program and is intended to help you do a better job on weekly one-page reports. In preparation for this lecture, read Gopen and Swan, "The Science of Scientific Writing" (reading #4).

For Lecture: Monday, February 12

Read Chapter 2.

For Recitation: Tuesday, February 13

Read the Leveson paper (reading #5) and write a one-page reading report that addresses the following question:

The authors of the Therac-25 control software had several opportunities to reuse softare modules. In some cases they did use older, or off-the-shelf software components, in other cases they created their own implementations. Pick an instance of software reuse in Therac and an instance in which the developers "rolled their own" and evaluate each decision for its impact on the safety of the Therac-25. Do you think these outcomes are typical of software reuse?

Remember, use exactly one side of one sheet of paper for your report. We care about conciseness more than the amount of content. Since you will not be able to address every issue in one page, you will have to select only your best arguments for the one-pager. This assignment is due in recitation today.

The Leveson paper is also on-line: http://ei.cs.vt.edu:80/~cs3604/lib/Therac_25/Therac_1.html

Browse the 1999 6.033 web pages for examples of good writing on one-page reading reports. Also, please check the 6.033 FAQ for formatting instructions.

After reading Leveson's paper you may be flabbergasted by how badly the Therac-25 systems were designed. The next reading (#6, Lampson's "Hints for computer system design") has a number of suggestions that often lead to better systems. If you have time and energy left, browse through this thoughtful paper. You might want to ask yourself which hints the designers of Therac-25 violated. Don't worry if you do not fully understand this paper yet (or if you only have time to skim it); it will be assigned again at the end of the term.

For Recitation: Thursday, February 10

Read the paper on the X Window system (reading #7) and complete the following hands-on assignment.

The purpose of this assignment is to give you some hands-on experience playing with the details of the X Window system. In particular, by the end of the assignment, you should have a good understanding of how to use X and how X manages complexity using modularity (through client and servers) and hierarchy (in managing windows). This assignment should take one to two hours at most. Please turn in answers to the questions asked only! Do not submit pages of output from the various commands. Also include how long this assignment took you to complete so we can gauge the complexity of future assignments.

I. Warmup

Section 2 of the paper presents nine design requirements for the X window system. See if you can think of examples of how these requirements affect in X today. For example, the requirement of display independence is realized by the fact that the machines in an Athena cluster are different models and from different vendors, but all run X. In a few sentences, describe an example of something which uses the fifth requirement.

II. Basic X usage

The design of X has led it to be highly configurable and customizable. To begin understanding some of this, skim the generic man page for the X:

athena% man X

Create an xlogo (command: xlogo) with a differnt background and foreground color from the default, that is 1000x1000 pixels and starts out in the bottom right corner. Give the command you used.

III. Understanding the window hierarchy

Now, let's get our hands dirty playing with some of the more technical parts of X. There are a number of useful commands that are provided with the X Window System that helps you explore the different properties of the system. The first one we will look at is called xwininfo. Run it, and then click on the window you ran it from.

athena% xwininfo
xwininfo: Please select the window about which you
          would like information by clicking the
          mouse in that window.

xwininfo: Window id: 0x3000014 "XTerminal"

  Absolute upper-left X:  296
  Absolute upper-left Y:  244
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 499
  Height: 316
  Depth: 16
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x23 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +296+244  -5+244  -5-40  +296-40
  -geometry 80x24-0-35

As you can see, this reveals a lot of the properties of the window. Your reading from part II should help you make sense of most of these properties. xwininfo also has two options which help you explore the window hierarchy. First try:

athena% xwininfo -children
and select the xterm you ran that from. As you can see, the window has a parent and a child. In conjunction with the -id option to xwininfo, explore up and down the tree for your Xterm. Use the the different options to xwininfo to find out more about these windows. What is the function of each of the parents? What about the children? How are they realized on your screen? You may find the -tree option useful as well.

IV. Architecture

Consider figure 1 from the paper (p.85). Now consider the Athena workstation you are logged in to. On your display you have many windows. According to the figure, these windows are generated by applications that run over the network and talk to a server. In your case, what machine is running the server? What machine is running the clients? Does the network play a role?

V. Wrap-up

Hopefully this has given you a taste of how X works. There are other useful tools that will let you explore the details of X. Here is a list of some of them. If you are interested, you can run them and see what they tell you. You may find the man pages useful in understanding what they do.

System aphorism of the week

There is no such thing as a small change in a large system.
Go to 6.033 Home Page Questions or Comments: 6.033-tas@mit.edu