Posts

Unix Quiz answers

(Here's the next resurrected post, this time from Jun 8, April 30, 2012.)

A while back I posted the questions from the 1984 Unix/mpx Exit quiz:https://commandcenter.blogspot.com/2020/01/unix-quiz.html

Here they are again, with annotated answers. The answers are in the form of the simplified pattern that the mpx exit program used to verify them.

Note: I have never seen a correct set of answers posted on line except when they originated from this list. In other words, I don't believe anyone ever got all the questions correct, even with a web search engine. It may not even be possible.

1. Q:The source code motel: your source code checks in, but it never checks out. What is it?
A:sccs
The Source Code Control System. The reference is to the Roach Motel.

2. Q:  Who wrote the first Unix screen editor?
A: irons
Ned Irons wrote a full-screen editor (the first?) at IDA in the 1960s and a Unix version, perhaps a translation, at Yale a few years later.

3. Q:  Using TSO is like kicking a {what?} dow…

Unix Quiz

(Here's another resurrected post from April 30, 2012. Answers in a followup.)


People objected that there was no Exit item on the main menu for the mpx program that put windows on the Blit; see http://en.wikipedia.org/wiki/Blit_(computer_terminal) (which mistakenly says it implemented cursor addressing when turned on - as if!) and http://www.cs.bell-labs.com/cm/cs/doc/83/mpx.ps.gz. It seemed unnecessary, since you could just power cycle. Why clutter the menu? (Those were simpler times.)

After hearing too much complaining, I decided to implement Exit, but did it a special way. Late one night, with help from Brian Redman (ber) and Pat Parseghian (pep), I cranked out a set of trivia questions to drive the Exit control. Answer the question right, you can exit; get it wrong, you're stuck in mpx for a little longer. To make this worthwhile, the questions had to be numerous and hard, and had to be verified by the machine, so the quiz code included a little pattern matcher. It also had t…

Old things made new

A while back, Google Plus (google+?) lost its public face, removing from public view too much material. But Google, for all its faults, also has virtues, and it let me capture all my posts using its "takeout" feature before plus went negative.

I'm going to publish a few of the more worthwhile or at least fun ones here over the next little while.

To get things going, here's a link I posted from September 30, 2011:

Fashion for Work at the Google Headquarters

There's little merit and less verisimilitude in this, so file it under the fun category.

Computational reproducibility: Some challenges

There has been recent discussion about the reproducibility of scientific results, with some unflattering conclusions. One study suggests only a 62% reproducibility rate.

For some fields it's probably much worse. Any result that depends on computation is at great risk of continual change in its programming environment. A program written ten years ago has little chance of building today without change, let alone running or running correctly.

This concern is not widespread, but it is growing. One indicator is the creation of the Ten Years Reproducibility Challenge, which asks researchers to rerun their old code—ten years or more, very old by computing standards—and see if it still works.

Can you even find your old code? That's a challenge all on its own.

Any researchers out there with computational interests are encouraged to accept the challenge. The link above has details about how to proceed. The results are sure to be eye-opening. Even if you don't submit your results, th…

Notes from a 1984 trip to Xerox PARC

Someone at work asked about this trip report I wrote long ago. I had not realized it was ever seen outside Bell Labs Research, but I now know it was. It's a bit of a time capsule now, and I was able resurrect it. Importing into Blogger was a bit of an ordeal that informs some of the points raised here, but other than that I make no comment on the contents beyond apologizing for the tone.


This Dorado is MINE, ALL MINE!

Rob Pike
April 29, 1984

A collection of impressions after doing a week’s work (rather than demo reception) at PARC. Enough is known about the good stuff at PARC that I will concentrate on the bad stuff. The following may therefore leave too negative an impression, and I apologize. Nonetheless...

Dorados work, and although most people at PARC now have their personal machine, it is hard to find a spare one for a visitor (e.g. me), and the allocation method is interesting. There are rooms full of Dorados in racks, and each office has a terminal in it. To connect a machine…

CERN's iPod-like control devices, from 1973

A recent dig through some old papers uncovered this CERN memo from 1973 describing controls for the Proton Synchrotron being built at the time. I visited the control room some years later and saw the controls in action, installed on a room-hugging curved console reminiscent of a NASA mission control room. I was so impressed by the devices I asked for a copy of the documentation, written by (one assumes) their designers, F. Beck and B. Stumpe.

These are like the ur-controls for the iPod and (later) iPhone, but anticipate the music player by almost three decades. In fact, the CERN knob is better than the click wheel: It is programmable to be smooth, indexed, or with variable turning resistance and spring return. It was inspirational to feel how it responded when turned in the various modes.

Apple is very good at commercializing ideas, but big research institutions such as CERN, erstwhile Xerox PARC and Bell Labs excel at creating the ideas themselves.

This memo was from a different time,…

Error handling in Upspin

The Upspin project uses a custom package, upspin.io/errors, to represent error conditions that arise inside the system. These errors satisfy the standard Go error interface, but are implemented using a custom type, upspin.io/errors.Error, that has properties that have proven valuable to the project.

Here we will demonstrate how the package works and how it is used. The story holds lessons for the larger discussion of error handling in Go.

Motivations

A few months into the project, it became clear we needed a consistent approach to error construction, presentation, and handling throughout the code. We decided to implement a custom errors package, and rolled one out in an afternoon. The details have changed a bit but the basic ideas behind the package have endured. These were:

To make it easy to build informative error messages.To make errors easy to understand for users.To make errors helpful as diagnostics for programmers.
As we developed experience with the package, some other motivations…