An Interview with John Fletcher
JF = John Fletcher
GAM = George Michael
GAM: Today's the 7th of September, 1993, and I'm talking to John Fletcher.
So, John, why don't you begin, and loosely follow that outline, but I'll butt in
every now and then.
JF: My name is John George Fletcher. I started at the Lab in the summer of
'61. I was just a summer employee for that summer. Then I came back permanently
in late August of 1962.
I was a physicist. I got my Ph.D. at Princeton in physics, and I wrote my
thesis on general relativity. And I had come out to the west coast to be a
Miller Fellow at the Berkeley campus. So that first summer was between my two
years as a Miller Fellow. When the fellowship ended, I had to go some place, and
I decided to come to the Lab. I thought I was just sort of trying it at the
time, because I had imagined all along I would end up on a university campus. I
looked at this as kind of a half-way move, because it was a university. In fact,
it seemed to me to be more closely associated with the University in a
practical, everyday sense back then than it is now.
GAM: Who was your thesis advisor?
JF: John Wheeler. There was not really that much opportunity for general
relativity work at the Lab. At that time they had some kind of group of
people�Malcolm MacGregor, Mike Moravchek, and Pierre Noyes were in it�names I
remember from the distant past. I was to be associated with that group, at least
loosely. The idea was that I would have some chance to engage in highly
impractical theoretical physics. But as it worked out, things did not seem
permitted to be that loose. So I got involved in some things which I can't
remember at all now�essentially physics application programming.
GAM: Hydro.
JF: Yes, hydro. There was a code called CEL which followed the particles, as
opposed to assigning values to mesh points. You followed the particles as they
moved through the mesh points. I was involved in that a bit. What happened to me
is that I found that I gradually got more interested in the computer programs
and putting them together, and their aesthetic qualities or whatever, than I was
in their answers.
Also at that time, there was a group at the Lab that had been set up to do
artificial intelligence, headed by Jim Slagle. There were�I don't
know�a half dozen people in it. One way or another I got involved with them,
and I cannot remember exactly how. I mean that I was involved not in any
official sense, but I started talking to them, and I learned about the language
LISP.
Another thing that happened sometime in those early years is that Mike May
and Dick White got interested in doing stellar calculations. They had reasoned
that a star was nothing but an enormous hydrogen bomb, and that maybe we had the
codes to deal with it. But they did realize that you had to take general
relativity into account, unlike in a real bomb. They were aware that I had
worked on that, so I became kind of their resident expert. Eventually they
picked my brains all they needed to, but for a while I was telling them what I
knew about general relativity.
One day Dick White came by, I can remember, and he said to me that it was
extremely tedious�which it is�to do general relativity calculations, because
they're all calculus and algebra. Well, eventually you get down to numbers. But
first of all you have got to take metric tensors and differentiate them again
and again�twice really�and add them up in various ways, and get things called
Christoffel symbols and curvature tensors, and finally get to the Ricci
tensor and the Einstein tensor. He said that was very tedious, and he thought
that maybe a computer could help him do it. And I said that I was aware of that,
because there were these guys over here in Jim Slagle's group who do
something along that line. Actually, they were playing games�they were not
doing algebra. But I was aware that there were algebra programs at that time
that did symbolic algebra. So I said, "I'll look into it."
The next thing I knew I was writing a code that differentiated metric tensors
enough times to come up with the Einstein tensor and put them together. The
story was that there was an algebra program available, and all I had to do was
plug my stuff in with that, and it would do all the algebraic simplifications.
Well, it turned out that the program did not work very well. The next thing I
knew, I was writing my own simplification program.
One anecdote from that time�which doesn't have much to do with the Lab�is
that for some reason one day I was over at Stanford on Lab business, or maybe I
was going to a talk. Whatever I did, it had two parts. There was an early part
and a late part, with a couple-hour gap in between, when I had nothing to do but
hang around Stanford.
So I naively just went to the Math Department and started walking down the
halls. I was working on a math problem at that time: I had found that in dealing
with the symbolic algebra there were expressions that I could invent that I
didn't know how to simplify. I had arrived at them by working backwards from the
simple form, but I did not know anything about the algorithm for going the other
way. So I thought these guys would help me.
I just knocked on doors and talked to assorted mathematics types, and none of
them were helpful. The greatest comment of all was from someone who�well, at
that time he looked elderly to me. I expect he might have even been younger than
I am now. But he listened to what I wanted to do, and then he looked at me and
he said, "Young man, we stopped worrying about things like that in the last
century!"
Anyway, it turns out, strictly speaking, that in some sense he was mistaken,
because there were people worried about simplification. Of course, a lot of
progress has been made since then.
Anyway, I bored ahead with this thing, and I wrote a program that I still
have�a deck of cards, if you can believe that�that embodies the program today.
It worked pretty well. I turned out some simple examples anyway. I don't know
whether Dick White ever really used it or not. As a result of having done this,
I went to a meeting of symbolic algebra types somewhere in the east, and I
determined that I was more or less near the forefront of the field�without
having gone very far. This was maybe '65. I had come to the Lab in '62, so this
was about three years later.
It was clear that my interests were shifting in this computational direction.
I was in the theoretical physics division, the head of which was Sid Fernbach,
who also was the head of Computation. He was the dual head up until I guess
about '68, when they split apart.
GAM: Yes.
JF: So one day, I screwed up my courage and confronted Sid and told him that
I would really like to work on the symbolic algebra stuff as my job. It turns
out that he outflanked me. He indicated that, no, that was not really the kind
of thing that the Lab did, that it was not appropriate, but that he did have
another job in computers that I might be interested in. It was in system
programming. A fellow named Bob Abbott was leaving at that time. I think he came
back again later, but anyway, he was leaving and there was a hole to be filled.
After some hemming and hawing, I finally decided I would take the job on the
theory that, once I was working in the Computation area, then I could eventually
work myself around to the algebra work I was interested in.
But it turned out, as I said, that Sid had outflanked me, because it
developed that I became interested in the system programming, and eventually I
forgot about the algebra. Of course, we all know there are things like Macsyma
today�that other people did not forget about the subject. Whatever I did is
hopelessly out of date. Meanwhile, I was having fun.
GAM: Do you remember coming and talking to me about whether to take that job?
JF: Yes, I talked to you and to Bob Cralle.
GAM: Bob Cralle, yes, and Alex Cecil.
JF: All of you pointed out that if I took the job, I'd be one of the first
Ph.D.'s to enter system programming and I'd have to work under a non-Ph.D. So it
was possible that some of my freedom to work in the way that I wanted would
disappear. When I mentioned these thoughts to Sid, he agreed, and was about to
withdraw the offer. But I reconsidered and took the job. As it turned out, there
was so much to do that the supervision never was noticeable; we worked at our
own pace and in our own way.
I started working on the system-programming job. It turned out that there
were three people working on a new project, which was centered around the PDP-6:
Clarence Badger, Garret Boer, and Gale Marshall. They had worked as a team on
the STRETCH. So I became kind of the "fourth horseman" or "d'Artagnan to fill in
the Three Musketeers" or something. I was added to their group, and I was
nominally their leader�because apparently Abbott had been nominally their
leader. I gathered that Abbott hadn't done anything concrete except try to
document what was going on. He gave me sheets full of stuff, but he hadn't
actually done any programming.
I remember sort of being interviewed by Clarence for the job of being his
leader, which was again a strange arrangement. From the questions he asked, he
was trying to determine whether I would really program or not. I assured him I
would, and of course, I did. But I think for several months there, when I
actually did not get around to programming because I was trying to figure out
what the hell was going on, he had considerable doubt.
I can remember, though, his great happiness the day I finally had a version
of the program that I was working on. I didn't know what to call it, so I named
it after myself. It was called FLETCH. It was a piece of the PDP-6 operating
system. I can't even remember what piece anymore. So I inserted this thing into
the operating system and started debugging it, and then I think Clarence heaved
a sigh of relief that it turned out I could program.
GAM: Do you remember that one of the things that earned you somewhat a great
notoriety was your polyomino program�the most intelligent use of macro facility
ever done?
JF: Well, that actually was prior to what I have been discussing.
GAM: Yes.
JF: Somehow I had the idea, which actually I think is a good idea maybe, but
it did not turn out to be an accurate idea, that real programmers worked
in assembly language. I had the idea that there were people around writing
physics codes in FORTRAN, but that the real aficionados didn't do that. So I set
myself the goal of learning assembly language. I got out the FAP manual, because
at that time FORTRAN was running on the 7094, so FAP seemed the thing to use.
And I read it. It included not only the regular part of the assembly language,
but also it had all kinds of other pseudo-operations, including a macro facility
which, in retrospect, is better than anything that exists today as far as I
know. It was just really a marvelous thing.
Somehow or other I had encountered Bob Cralle and regarded him as an elder
statesman I could come to. Well, backing up a little�I decided that it was fair
enough, since my purpose was to learn assembly language, that I could just pick
any old problem and do it in assembly language as an exercise to learn. Maybe I
was partly self-serving, because I had been very interested in the
polyomino�actually pentomino�problem of fitting the 12 pentominos into a box.
A friend of mine and I at Princeton had gotten all involved in trying to see how
many solutions we could come up with. It said on the little set that I bought in
a toy store in Annapolis, Maryland, I remember, that there were rumored to be
over 200 solutions. Of course, we know now that there are more than 2,000. So
that was a hideous underestimate.
But, anyway, I was interested in the problem, and I thought it could be
reasonably attacked just by brute force with the computer, and I could get all
the solutions, which I eventually did. But I also felt that speed�which of
course would not be much of a problem today�would at that time be a serious
issue, and I should do everything possible to speed it up. I concluded that if
could mainline in the code most of the decisions about the shapes of the
polyominos, that it would be much better than looking them up in a table. It
seemed clear to me that the FAP macro facility could do that, and that I could
have the macros recursively call themselves and essentially expand into a
straight-line code the entire structure of all 12 pentominos.
So having decided this, I went to Bob Cralle, and described my thoughts. He
couldn't say why it wouldn't work, but he felt in his gut that it really
couldn't be done, that something in the macro processor would not let me do it.
But he did not discourage me from trying. Well, of course it turned out that it
worked! The macro processor would do what the manual said, and it did it very
well. I just set the thing aside after I had done it. I had a printout of the
solutions that I've kept, and I still have it today.
Then, about a year later in the "Scientific American"�just as he had
originally had an article on pentominos�Martin Gardner had one on hexiamonds,
which are shapes made out of little triangles instead of little squares. And I
thought I that could modify my program to do hexiamonds and answer a couple of
the questions he raised. So I did that, and observed that one particular
arrangement had no solution�or whatever. Anyway, I sent in my results to
Gardner. He wrote back and said, "Great! What do I cite as the source?" It had
not occurred to me that he wouldn't just take my word for it or something like
that.
So I said to myself, "Gee, maybe I'd better check what one does to release
something that I've done at the Lab to a magazine." The advice was that you had to make a UCRL report of it; that was the first step. So I did that,
and then I was able to tell Gardner that it was UCRL 12345 or whatever. So now I
had this UCRL report in my hand, and I thought: Well, why the hell not? Why
should I not try to publish it, since I had gone this far? So I sent it to the
"Communications of the ACM" (a publication of the Association for Computing
Machinery) and they liked it. In fact, of course, as you can well imagine, it
was very picturesque, with pictures of the polyominos. So it made the cover of
some issue in '65, I think it was. Then later on, I remember Cralle, I think,
showed me that I was cited in a book by Brown, wasn't it?
GAM: Oh, yes, Brown's work on macroprocessors.
JF: Yes, and he referred to what I did as "Fletcher's Method," which of
course is great. But it seems to me that if you look at the FAP manual, it is
absolutely clear that it is set up to do what I did. In fact, there is a
particular pseudo-op called the IRP�it means iterate-in-prototype�that was
designed to do exactly what I did. In fact, I personally cannot imagine what
else you would do with it. So, the question is: who invented the IRP, and what
did they have in mind, if now this should be called Fletcher's Method? My
suspicion is that this unnamed hero deserves the credit.
GAM: Well, that was Dave Ferguson. He's the guy who wrote the FAP. He was
here. He came here�I remember he talked about your publication.
JF: It would seem that his work was like pebbles on the beach or something.
It was just lying there waiting to be used.
GAM: Well, somebody has to see how to use it before others become aware of
its value. I think you did a great thing�it's all right.
JF: Well, anyway, that is one of my two biggest successes in terms of
publication in either physics or computer science. The other one is an
error-correcting code [1] that came later, which eventually worked
its way into an American National Standard. Maybe at some later point we can
discuss that.
Both of these publications were flukes, you see: If Gardner hadn't asked me
for the reference, so that I had to produce one, then I might not have ever
published it. The other one turns out to be like that, too.
GAM: I wouldn't call it fluke, I'd call it serendipity.
JF: Yes, right! Whereas things that I thought were publishable�tried to
publish�I have often had a great deal of trouble publishing, because you have
the referees to fight. Anyway, all this was a kind of sidelight that preceded my
joining up with "the Musketeers."
GAM: Well, Alex had something to do with the polyomino problem, too, didn't he?
JF: Yes, Alex Cecil had a set of routines that would draw lines on�what was
it called�the dd80, which by today's standards is a primitive CRT device.
GAM: It was a great device.
JF: Yes, because that was how you produced pictures. So, I used his routines,
and he also gave me pointers about programming. I remember one day after I had
Alex's routines in my program, all hell was happening in it, and I couldn't
figure out what had gone wrong. I studied the thing before calling Alex. In
those days you had to debug with print statements. If you were very good, which
I wasn't, you could get in three batches a day. But mostly you could get in only
one and a half. Anyway, I confronted Alex when I had finally determined that the
trouble was his, and I said, "Where do you save the Accumulator and the MQ when
you are called?" And he said, "No, the convention is you've got to save them yourself!" So there I learned a little bit about the rules of the game.
GAM: A lovely way to get initiated.
JF: Yes, I remember another discovery about computer conventions. It was when
I was working on the CEL [2] code,
and I was tracking particles through a mesh�just a one-dimensional mesh.
I had made it a cylindrical symmetry. I wasn't really using the CEL code. I was
using a code of my own like it. So, the idea was the particles that went over
one end would appear at the other end.
GAM: On the side, yes.
JF: I said, well, you know, studying my FORTRAN manual, all I have to do is
use a Mod function and apply it to the position. If a particle goes over the
length of the mesh, it will come back to the beginning.
I started running that code, and it behaved very strangely. It would run for
a while. Some of the particles would start to disappear. (I kept a check on the
total number of particles, and the total wasn't right.) Then the code would
finally blow up. I scratched my head over that one for a long time.
Then, suddenly, something tinkled in my head: What did the mod function do to
negative numbers? I expected that when a particle went through the left-hand
origin it would pop up at the right-hand end. In other words I believe, and I
still believe today, that it is mathematically correct that, for example, if you
divide -5 by 3, you should get -2 and a remainder of +1.
GAM: No, -1, and a remainder of -2. Well, you're dividing 5 by 3. Three into
5 is 1, and 2 left over.
JF: Yes, but that would be a -2 left over. What I claim is that the remainder
should always be positive, when you have a positive divisor. But anyway, the
computer convention, which again I think is wrong, is that, as you say, the
remainder is the same sign as the dividend rather than as the divisor. So that's
where my particles were going. They
were going over the left edge of the mesh and off into whatever variables
happened to be there. That was easily fixed once I realized what it was. Again,
I had made an assumption, and I learned it was false.
GAM: That will happen.
JF: Back to my job with Clarence, and Garret, and Gale: I became a Group
Leader, sort of, at that time, and I essentially had that same job until
1990�about 25 years. The organization would change, and leaders would come and
go, and the name would change, but essentially there was a group that I was the
head of. You could never point to a moment at which it was replaced by another
group. You know, people would be added, others would go away. It split once,
because it got too big. That was my group.
By 1990, the definition of what a Group Leader was had changed. I finally had
to accept that. When I started out with four of us in 1966, or whenever it was,
I was essentially a�"first among equals" maybe is the phrase. I was just
another guy working on the thing and doing programming. I just had these little
side things of going to a few meetings, and writing evaluations, which in those
days didn't amount to much. It was all largely technical�90 to 95 percent of my
time.
But by 1990 it had been decided not only was a Group Leader supposed to spend
most of his time just being a Group Leader and not on programming, but he wasn't
even a technical leader anymore.
GAM: He was administrative.
JF: Yes, right! They had developed the idea that Computation should be in the
same matrix organization as everybody else, and that groups were horizontal.
They didn't have anything to do with the project you were working on or
anything. Well, my inability to come to terms with the change in the definition
of my job had alienated my Division Leader, and essentially by mutual agreement,
but under pressure from him, I finally threw in the towel on trying to be the
new kind of Group Leader.
Part of the reason, I guess, that I gave up is that I had observed the Group
Leaders no longer had much voice in what happened anyway.
GAM: Yes.
JF: I clung to the job in the hope that it would help me influence the way
things went. It did not. Anyway, things were a lot different back in the early
days. We had the PDP-6 as our main machine. That was because of the original
conception of what Octopus was to be: There would be a head, like on an Octopus,
with tentacles reaching out. The PDP-6 was to be that head.
Very soon after I got involved, it became clear to me, and I think to
everybody, that this was not a good way to do it, because the head was very
critical. Furthermore, it was very prone to going down, because every new thing
had to be added to the head. You would have to be debugging it, and it would be
down. So the idea of an octopus with a single head just really didn't fly.
Our next stage of design was the subnetwork approach, in which there were
multiple heads, one for each function. There was a file system head, a
teletypewriter head, and a printer head. It never really quite exactly got into
that form, because the next thing that happened is that we began to realize that
there could be, even within each of these functions, multiple heads. For
instance, the teletypewriter function was originally in the PDP-6, like
everything else; there was a piece of hardware built at the Lab that was going
to be the multiplexer.
Then Dave Pehrson, who was in the Engineering Support at that time, got the
idea that you could build a new multiplexer out of PDP-8 computers, which were
available then. So, rather than try to put everything into hardware, some of it
would be put into software in this computer. Again, his original conception was
these were kind of like satellites to the PDP-6, but before very long, it became
clear that, no, they were really free-standing little computers that were just
in the network. That's the way it went. The only role the PDP-6 had for the
PDP-8s was to load them with their software. That is the one sense in which they
were satellite to the PDP-6�that's where their brains came from.
So Pehrson and I did that job together. He did the hardware, I did the
software, and that has always been my model of how we did things in that
day�how we should do things.
GAM: Do you mean an engineer and a programmer working together?
JF: Right. The way we worked together was he would propose something that put
a lot of burden on the software. So I would study it, and I would make a
counter-proposal�something that, probably from his point of view, put a lot of
burden on the hardware.
GAM: Fair is fair.
JF: We would flip this back and forth, and I think we finally came to the
right compromise. I don't think it ever worked quite as well again, but I think
it worked very well then.
GAM: Well, you know, I'm not sure it's the right compromise, but it
was a compromise to satisfy minimalist requirements. If you had a different set
of requirements, you might have found a different compromise.
JF: That is true. We also had a limited computer. A PDP-8 had�what�4K,
12-bit words?
GAM: Yes, 4K memory.
JF: Boy, did I struggle to get everything in.
GAM: Yes, but the point is that you could have gone to a bigger machine just
as readily, and not have to worry about shoehorning it into a PDP-8.
JF: Right. Of course, there were money considerations. I don't know how that
was decided.
GAM: Yes, that's what I said�that was a minimalist thing.
JF: Well, you know, there were lots of other things going on at that time as
we branched out into other machines and new things came.
GAM: Now this is what year, roughly?
JF: This is late '60s, I guess.
GAM: Like 1967?
JF: Yes. I'm not sure exactly.
GAM: All right. Well, you see the Photostore starts to rear its ugly head
around '67.
JF: Right.
GAM: And you guys all jumped on that. I was complimenting Garret just before,
saying that the work that had been done on that was seminal.
JF: Yes. Well, that was largely Garret's baby. He deserves the vast bulk of
the credit for that.
GAM: Well, that's true, but before that there was John Fletcher interpreting
the Multics file structure, and making it happen here, among other things.
JF: We all read those Multics papers. That is certainly the case. In fact,
sometime I should try to find them, because I know one thing that we did in our
system, I swear, is the way those papers we read originally. Yet when Multics
actually came out, it had done it differently. Namely, our security was what is
today called capability-based�in the directories were coded objects called
capabilities. If you could extract a capability from a directory, which
essentially meant that there was a path to it from your root directory�I guess
today what they would call a home directory�to a capability, and the capability
showed the necessary permissions, it was yours. That is, unlike UNIX, you could
not get at the entire directory structure. You had to start at your personal
root or home directory, and trace from there. You could not go back to the root
of roots, like you can in UNIX to find anything. And if you could get to a
capability, if you could name it�that's another way of phrasing it�if you
could name it, it was yours. We thought that was a great system, and I still do.
There are arguments on both sides, but all in all, I think a capability-based
system would be actually better than what we have today.
Multics, on the other hand, ultimately went the other way�if you could name
it, it was not necessarily yours. It had things similar to what UNIX has
today�access lists�whether you were in the right group, and who you were, and
that kind of thing. So what is interesting is that either we misread their
paper, or they changed their minds.
GAM: Yes, right. I think they changed their minds. Remember, there was a big
troika there�General Electric, MIT, and Bell Labs. Too many cooks, etc.
JF: It might also have been that the Department of Defense, who I assume was
one their sponsors or customers, might have insisted on that, because, as I
said, there are arguments on both sides, and one thing a capabilities-based
system does not do for you is give you a quick way to revoke someone's access.
If someone had ever had a capability where he could reach it, he could have
squirreled it away where you would not know where.
You can't just wipe off someone's access with a stroke of the pen, a stroke
of the cursor, or the mouse, or whatever. So, yes, we used Multics. As you say,
we brought in the Photostore, which was just amazing.
GAM: It was a signal event.
JF: We had three major storage devices at that time. The first one that
arrived was the Data Cell. And the next one was the Librascope disk, and then
the Photostore. The Librascope disk was a giant. I guess they were about
6-foot-diameter platters, rotating on a horizontal axis.
GAM: It had a head-per-track.
JF: Head-per-track, right. I have always had in my mind something that
fortunately never happened�a picture of a catastrophic failure of the axle, and
these giant, spinning things would detach themselves, and roll�there would be nothing stopping them. They would go right through the side of the
cabinet and across the room, smashing everything in their path.
GAM: That's a neat fantasy.
JF: It always occurred to me that there was deadly stuff in there if it ever
got loose.
GAM: Well, I suppose that's true. But it was an interesting piece of
hardware. And it certainly fit nicely into the overall file structure.
JF: Yes. I remember when we first got going with the PDP-10, the only storage device we had on it was that Data Cell, which was�well, of course, it
wasn't as capacious as the Photostore, but it was more capacious than a typical
disk of that era. But it was slow. I would sit at the Model 33 Teletype, which
is what we used in those days�down there in the machine room, which is the only
place they were�and I would type the things I wanted to do. Well, of course,
this was a little later. We used to write our programs on sheets of paper and
have them keypunched, and feed them in as cards. But we got to where we had a
primitive text editor�primitive because we didn't have a screen: We had to do
it all on rolls of paper. We would edit programs down there in the machine room.
I remember I would get done editing and I would ask for an assembly. Then I
would spin my chair around and face the Data Cell, because it was going to take
some time. And that thing would go
"kerchunkity-chunkity-chunkity-chunkity-chunkity-chunkity-chunk." I could
recognize the moment when it must be done. I would spin around, and sure enough,
the machine would type out the result. This went on for many months�I don't
know how long.
Then one day, Garret got the Librascope running. We all cheered. So for my
next assembly, I went down, I did my editing, I typed, I spun the chair, and I
could hear the typewriter going behind me�it was already done!
GAM: Huzzah! Huzzah!
JF: I just wasn't prepared for that. I guess, in fact, I was slightly
thinking that I would hear the Data Cell do something, even though I knew now
that the file was on the Librascope. But the idea that it took less time than to
turn 180 degrees on the chair�it just took my breath away. What an advance!
GAM: Well, speed is just a remarkable stimulant.
JF: Yes. I guess one other silly story from that era had to do with those
Model 33 Teletypes. They kept wearing out what is called the distributor, where
a little motor ran a rotating member all the time. So, to protect them from
wearing out, our engineers installed timers, so that if you didn't type for a
certain period of time, the timer would shut off the running motor. Then before
you could type again you had to flick a little switch; so you were used to that.
Well, one of the Teletypes down on the floor had a recalcitrant switch. You
would flick it, and it wouldn't do its thing. So we gradually learned that you
had to get a little violent�you had to bang the top of the machine to help it
along. Eventually even that didn't help. I had finally decided that a
well-placed blow of the foot to the front edge of this Teletype was what it
needed. That was standard operating procedure for this particular Teletype.
So one day I was working down there, and the Teletype ran down. I pushed my
chair back and I whanged the thing a couple times with my foot. Then I looked up
in time to see Sid Fernbach with a bunch of visitors that he was leading by. He
justleft.
GAM: Oh, that's great.
JF: "Here's one of our highly trained scientific personnel kicking his machine."
GAM: You do what you have to do!
JF: That's right! Golly, we did all kinds of things. It was just the four of
us for a long time, and then we began to add people to the group. We began to
separate functions out of the machine. One function that we took over was
because of Bob Cralle, and I'm sure that you remember this story. If someone has
already told it, then I won't repeat it, but I will start.
GAM: No, tell it!
JF: It is about passwords, which we called combinations up until very
recently. In fact, sometimes I find myself still using that word. It is in
analogy with a safe: To get into your computing facilities you had to know a
combination. I don't remember how it came to be, but I guess it had always been
that a combination was six letters [3]. I don't know how that was decided. Anyway,
the combinations were stored on the mainframe computers, or worker computers as
we called them, which at that time were CDC 6600s. The combinations were looked
up by the computer.
The teletypewriter network had nothing to do with the passwords. It offered a
facility for suppressing the printing of the password, which was that you typed
a ctrl-Z, an arbitrary choice. Then the PDP-8 concentrator would know not to
echo the immediately following characters. We did not have single-character
interaction all the way to the mainframe. So echoing was done by the PDP-8. The
PDP-8 did not understand the context in which a password would occur so, you
know, you had to tell it with the ctrl-Z. But the combinations were looked up on
the mainframe.
It turns out it had been documented about the 6600 that a field length
violation, when the running program would try to access a word beyond the length
of the memory which it had been given, would cause an interrupt. If the attempt
was to store beyond the length, the store would be suppressed. But if the
attempt was to fetch beyond the length, the fetch would not be suppressed, and
the interrupt would occur after the fetch, which meant that the fetched
information would end up in the core image of the program that was just now
being dumped.
GAM: Right.
JF: This was a documented fact, and I don't know whether anybody had thought
about it. I will absolve myself by the fact that I hadn't even read the
documentation; so I didn't know one way or the other. In any event, Bob Cralle
had read the documentation.
GAM: Well, he and Al Ciplickas.
JF: Is that right?
GAM: I think so.
JF: Yes, that's right, Al Ciplickas. Anyway, they had read it, and
they had let the little gears in their heads run on this. They said to
themselves, "You know, we could look at the entire memory of this machine in a
kind of a haphazard fashion now. We can reach beyond our field length." I think
they determined that you could pick up two words if you did it right. What would
happen then is that their program would fault and be dumped.
But the facilities of the operating system were such that you could have
another program standing by, watching for the dump to occur. It could then
proceed, allegedly in the role of a debugger repairing the faulted program. It
would copy the two words to a file and restart the program. This would be done
again and again. Each time it would collect two words.
You didn't always know where you were in memory or what you were looking for,
but if you just kept doing this long enough, pretty soon you had the whole damn
memory copied. Then with a little bit of smarts, studying the memory, you
could figure out where the passwords were kept. So Cralle did this.
Then, I think perhaps somewhat unwisely, he managed to use this information
to demonstrate that he had beaten the system. If I remember correctly, he did it twice. After he did it the first time, someone put in an alleged fix,
which was not a fix; so Cralle showed the guy that he didn't know what he was
doing and stole the passwords again. As a result of this I think Cralle got into
some degree of trouble, but the bottom line was that then people decided that
the passwords (or combinations) should not be kept on the mainframes anymore.
So that is where the facility that came to be called Ostrich came about. It
was a little PDP-11 in the network that was going to hold the passwords and
check them. Ostrich became a job for our group, and I did the programming. The
PDP-11 kept its records of the passwords on a disk�if you could believe
this�which had 64K words; that was an entire disk. Its memory was, I
think, 8K words, with 64K words for the entire disk.
GAM: That was one of those single disks. I remember those.
JF: Ostrich was retired not too long ago�maybe five years ago, if that much.
We had replaced the disk, but there was never enough motivation, enough need, to
really fix the program very much. What I did at that time was simulate the
little tiny disk on the new, great big disk. So we only ever used a little bit
of the great big disk, rather than rewrite the thing for the new disk.
GAM: No one ever compromised it, though, did they?
JF: No, the passwords were safe. There were all kinds of funny things about
that. The whole security thing over all these years has to my mind always been
highly irrational. They would worry about things that you don't need to worry
about, and they would not worry about things that you should. You could never
get a statement of policy�what is it we are trying to protect against�so that
you could design for that. They would always tell you: Design something and then
we will tell you whether it is all right. It was a strange business.
I remember one thing was that we had the audit tapes, so-called. They were
DEC tapes�another antique device. In fact, I remember, since we were doing this
in assembly language on this little tiny machine, we couldn't use any existing
software. And I remember having a terrible time getting questions answered by
DEC about how the DEC tape was formatted, which I needed to know. Everybody I
would talk to would talk in terms of calling certain library routines. I said,
"No, no. I want to know what the library routine does." I finally got the
information I needed. All the audit information, which would tell who logged in
and when�it would not tell the password, but it would tell everything else�had
to be put out on the DEC tapes, even though it was perfectly feasible to ship
the information through the network to�you name it�anywhere.
And the question is, why would they not let us ship the information through
the network? The answer seems to be what I came to call the "frictional" theory
of compromise. Namely, somehow such messages leaving the machine, carrying the
audit information, might scrape up a password or two on the way; they just
seemed to be afraid that something important would get out with the audit
information if it was not put out on tape. I don't know why the frictional
theory didn't apply to tape, but, again, it just seemed totally irrational.
When we were to redesign and, well, did redesign the password-checking as a
new facility called Kiwi a few years ago, they fortunately gave up that crazy
requirement. It also had turned out that the audit tapes were particularly
uninteresting�namely, even though Security insisted that we put them
out, Security did not ever bother to look at them. I had put into the program a
feature�there were two DEC tape drives�that, when a DEC tape would fill up,
the program would detect it. It would then shift to the other drive, but I had
the thing arranged so that somebody had to intervene and change the tape number
before it would go back to the first drive. The theory was that he would unload
the little tape and put another one in its place. Well, as a result, the
operators had to regularly go over to the computer and turn the little numbered
wheels, as if they had taken the tape off, but they had not. This went on
for many years, this farce of supposedly forcing people to look at the
tapes, but it really wasn't working. Then they finally agreed that the
program could just flip back and forth between the tapes without having someone
intervene.
GAM: So you're just keeping the most recent stuff that way?
JF: Yes, you had roughly two tapes' worth, one of which would be partly
covered with the latest stuff.
GAM: Well, let me interpolate, here. One of the things that you are alleged
to have said was that�I don't know where this was said, probably in some
meeting or something like that�"If it was important, I would have thought of
it!" Do you remember that?
JF: No, I don't.
GAM: Okay.
JF: I can imagine provocations when I might say that.
GAM: Well, the other thing is that there was allegedly some sort of a
fight�not fight, but a big disagreement�about whether we had duplex or not
duplex Teletypes in the beginning. And you fought that or something for a while.
JF: Well, I wanted us to have full duplex, whereas typically terminals were
half-duplex.
GAM: They were half-duplex, yes.
JF: The Teletypes could be rewired to be full duplex. When the PDP-8s came
in, we went full duplex, so that the PDP-8s could look at every character typed
and make decisions like the ctrl-Z thing. Then there were efforts to get
successors to the Model 33, which, at 10 characters per second, seems primitive.
GAM: Yes. Now it does, of course, but in the '60s it was fast.
JF: So we went to the Silent 700, which was 30 characters a second, and then
finally we started going to soft-copy terminals.
GAM: Glass Teletypes.
JF: Right. One of those efforts was to procure an official kind of glass
terminal. They were starting to be called smart terminals, although by today's
standards they were pretty stupid.
GAM: You're right, they weren't smart.
JF: They had to be controlled by the PDP-8�I guess by that time they had
become PDP-11s. We wanted them to be full duplex. Well, it was amazing that the
typical glass terminals were not full duplex. They were designed mainly to be
half-duplex, but they had an option�either that you could flip a dip switch or
you could send it a signal or something�that would make it full duplex. We
specified in our spec, when we were picking our official terminal, that we
wanted them to be capable of full duplex.
It was amazing that the first year that we put our spec out, none of the
responses that came back were really full duplex. They would be full duplex for
the letters, and digits, the graphic characters, but the outboard keys, like
carriage returns and so on, they were not. You would hit carriage return, and
the terminal would carriage return, without waiting for the computer to do
anything. I can remember asking several of the vendor representatives that came
by: "Why are you doing that? What kind of use of the terminal do you imagine,
where someone would want this thing sort of partly full duplex?" None of them
could tell me, but that's the way it was.
As a result, we rejected all the responses, because they did not meet our
requirements. We told them why. The next year we tried again, and Hewlett
Packard had their ears out, and they heard what we said. They didn't really
believe us fully, but they had a dip switch that, if you flipped it and told the
terminal to be full duplex, then it really would be. If the dip switch
was the other way, then it would be like it had been the year before. They had
what we wanted as an option. We called that the fully full duplex option.
So that might have been what you meant about fighting for full duplex. It was
hard to get�pretty hard.
GAM: Ah, but it finally got through, didn't it?
JF: Yes, and it really lasted until the modern terminals, where the terminals
are really smart. I know I got a lot of flak in those days from people
who wanted to customize their terminal to themselves. They said, "Why can't the
terminal, as alternative to ctrl-X, for example, permit us to use backspace or
delete?" I tried to explain, but some of those people would not accept it.
The model at that time�and I could not find anybody in charge who would say,
"No, let's change the model"�was that terminals were basically available to
anybody. Even though you had it in your office, in principle somebody else could
use it. The problem is that a person walking up to a terminal would want it to
behave as he expected it to. Now, of course, today we actually live with it when
it is not like that. You go into someone else's office and try to use his
keyboard, and if he uses backspace instead of delete, or ctrl-Y instead of
ctrl-U, or something like that, it can get very irritating.
GAM: I'll say.
JF: So the question is, when in history was the crossover where the
convenience of having the terminal your way outweighed the inconvenience to
other people? You came to the point that it was so rare that other people would
be using your terminal that it was no longer a consideration. So, anyway, that
was one of our handicaps, with that little tiny PDP-8 and even the PDP-11 there
was no way to customize it to you.
GAM: Well, in UNIX now they have a Term Cap, or whatever they call it, that
allows you to set your terminal according to this set of prescriptions.
JF: Right. That's because the system that is making that setting knows who you are, whereas these little concentrators�PDP-8s and PDP-11s�did not
know you.
GAM: Yes, I understand.
JF: Just about the time that it became clear that we probably would not have
a next-generation terminal concentrator, because the terminals were getting
smart enough that you didn't need a concentrator, I was planning how to do
something like Term Cap. The mainframe, which knew who you were, would be able
to send a message down to the concentrator, and say, "Okay, set everything this
way." That was coming.
GAM: Well, that meant there had to be a profile of you every place that you
came through.
JF: Right. Every machine that you dealt with would have to know about you or
it would not work. In fact, we have a little bit of that, with the so-called
Micromux, which was the last generation of concentrators. You could do things
like load tab stops.
There was another big thing relatively early on: screen editing. When glass
terminals came in, the first one we had was the ADM-1.
GAM: Yes, I remember.
JF: Whatever else was wrong with an ADM-1, by golly, you could edit on that
screen. I don't know who, realized that early on: that would be a great
thing. But I worked on it and came up with a feature that went into the PDP-11s,
which was called the "Iditor" feature.
GAM: Iditor feature?
JF: Yes. At one time we were trying to get a generation of terminals that we
called IDIOT�interactive display, I/O-terminal�something like that. Finally,
it was decided that that was not a nice name. But it has survived in Iditor,
which was the IDIOT-editor. So we early on got the Iditor feature, and Hank Moll
incorporated it into�
GAM: TRIX.
JF: TRIX made use of it, and it was very successful. Another little story I
can remember illustrates something I came to believe: The typical computer user
cannot visualize what a new thing will be like. You ask a typical user, at least
in those days, what would he like, he would say, sort of, "what I have
now, but more." He wouldn't use those words, but that would be the gist of his
statement.
GAM: Yes, I understand.
JF: If you would say, "Wouldn't you like...," and describe something somewhat
new and different, he would say, "No, no. I get along fine the way I am." I saw
that work very definitely in regard to the screen editor idea. I can't remember
who it was, but I can remember very definitely describing to someone how the
screen editor would work, and how it would be unlike what people were doing with
TRIX and the TMDS at that time�where they would put their text up on the screen
and then would pattern-match in it to make changes. They got very good at that.
If you want to change this particular letter A, you type just enough pattern to
catch only that A. I was trying to explain to him: Wouldn't it be better if you
could point? Admittedly, we did not really have a mouse to move; you had to step
the cursor over and step it up and down, but anyway, you could point to a
letter. So, wouldn't it be better to point? Whoever I was talking to said, "Oh no!"
I kept working on the screen editor anyway, despite discouraging remarks like
that. Finally I had it working. One day I was seated down in the computer room
using it, and again the same guy�though I cannot remember who he was, I do
remember that it was the same guy�came by, looked over my shoulder, and said,
"Hey, what're you doing?" I said, "Well, this is a new feature." He said, "Gee,
I'd like to be able to do that. How do I do it?" I said, "It's all in TRIX
now�you can just do it." The difference was between having it described to him
and his seeing it. What a difference that made!
GAM: He must have been a manager.
JF: Yes. So, we really had to make sure that they, how would you say�
GAM: Well, you know, a lot of those people are FORTRAN users, and they see
everything through that set of eyes. But it's not very stimulating.
JF: I think I do that myself, too. People would talk about things like
electronic mail. I didn't tell them, well, it is no good, or that I don't want
it, but I certainly did not rush to make it available to myself. But then, now
that it is available, it is just the normal course of events. I certainly use it
a lot more than I probably would have guessed.
GAM: Boy, I know I use it a lot.
JF: I guess another thing is color. I don't use color at all. I just work
with black and white text, but I have a suspicion that maybe if color were
quickly available on my terminal�in fact, I have just now gotten one with
color�it might be different.
GAM: I'm pretty sure you're right. Yes. The use of color probably has several
facets. One of them is that just since you see in color, seeing on a screen in
color is a little more useful or normal than black and white. The other thing
is, if you're doing "applications" programming, you get to see highlighted stuff
that way, which catches your eye much quicker, and that's what makes it useful.
JF: Of course, I do not do applications, so that might be part of the reason.
I almost entirely work with text, either writing documents or writing programs.
The lock screen picture is about the only thing in color.
Well, I am about out of things to say.
GAM: Well, I'm going to interview you again a little bit later, with another
load of tape, essentially. I want to talk about your experiences at DAS, and
flesh in some of these other things that we just glossed over today.
JF: There is a question here somewhere about what is my favorite machine, I
think. In terms of programming in assembly language, which I did for a very long
time, the PDP-6 and the PDP-10 were the nicest ones.
GAM: I'm sure everyone would agree with you.
JF: There is an appealing orderliness to an instruction set that is so
orderly that�I think I counted them once�there are fourteen different no-ops.
These resulted from trying to make complete, logical sets of things. They had
all combinations of moving a half-word hither, thither, and yon. They had the
possibility of doing it to a single word: You could copy the left half to the
right half, and zero out the left half after you were done, and so on. If
you analyze what constitutes a complete set, then one of them is that you are
going to copy the right half to the right half and leave the left half alone. Or you can take the left half to the left half and leave the right half alone. So, those are just natural no-ops.
They did not put some oddball thing into that slot in their instruction set;
they just let it go.
GAM: Sure.
JF: The greatest no-op was the one called "jump". There was an instruction
called jump, and it was a no-op. You might say, "Now, isn't that idiotic?" No,
it was part of a set of eight ops that could jump on the sign and zero-ness of
an accumulator. So you have two choices for what you do if it's negative, two
choices for what you do if it's zero, two choices for what you do if it's
positive�you can jump or not jump. So that's eight choices. And one of them
will be that you always jump, and that was called jump A, meaning jump always.
And then there is the one that meant you never jump, and that happened to be
called jump, because you did not put a modifier after it; so it was the one that
did nothing. It was logical, and I liked it.
GAM: Well, you know, it was alleged that that extremely baroque set of
instructions cost the PDP-6, and perhaps the PDP-10, too, a lot of time. It
slowed the machine down quite a bit.
JF: Well, they were a great set.
GAM: And they're still running today! There are hundreds of PDP-6s and
PDP-10s running around all over the country.
JF: You know, in some sense the PDP-10 is still running here.
GAM: Oh?
JF: There were a number of programs on the PDP-10 that were essential to
things in the network. The assemblers, for example, for a lot of the little
machines were on the PDP-10. The assembler for the Octoport, for the SEL
computers, we actually took off the PDP-10. We had a contract with Control Data
to write us an assembler that would run on a VAX, which they finally produced.
It was like pulling teeth to get it right, so that was not a good experience.
But all the other assemblers�including the ones from the so-called regional
processing units of the SEL, the ones for the 8X300s, which are peripheral to
the SEL, the ones that were in the Micromux, which of course is now gone�all
those assemblers were on the PDP-10.
When the PDP-10 was about to go, the question was, "What the hell do we do
about this?" Gale Marshall had retired on a medical disability many years ago.
He had been hired back a few times by the Lab to do some of what he did well,
which was write assemblers. But the Lab's rules for hiring people that had
retired had gotten worse and worse. Finally Gale Marshall just would not come
back because he could not make enough money at it. So that avenue was not open
to us, and people were talking about all the things needed to be done to move
the assemblers off of the PDP-10s.
So one day at a meeting I said, "You know, the PDP-6�or PDP-10�instruction
set is sufficiently simple that it would not be hard to write an emulator for it
in C and run it on a Cray." So that is what we did. I wrote the instruction
decoding part of it, and Mike Nemanic then put the thing into a working package.
That thing now runs on the Crays, and I believe it runs faster than a real
PDP-10, at least the one we had back then.
GAM: Oh yes?
JF: So, if, by some terrible chance, we had to, say, do a fresh assembly for
something like an 8X300 or an RPU, that is where we would have to do it.
GAM: Well, if you remember how to do it. But there's not many others who
do�it's kind of slowly disappearing into the mists of time.
JF: So, they will have to consider what the rules will be for getting me back
if they need me back.
GAM: Come on bended knee!
JF: Yes.
GAM: Well, I certainly second your choice of the PDP-10 as being an
interesting machine to work on.
JF: For high-level languages�actually, I like C. And FORTRAN was not bad. I
guess it is recursive today. That was certainly a big handicap in the beginning.
But all those languages of that ilk�ALGOL, PASCAL�to my mind are very similar.
I am sure the PASCAL people look down their noses at FORTRAN, but the
differences are small.
GAM: Well, the control structures are different.
JF: The languages where people tend to position themselves in order to look
down on other languages are ones that take things away. They are proud that they
don't have a go-to, or they don't have a this, or they don't have a that.
GAM: Ah, the go-to.
JF: I write go-to-less C just partly for fun, but it is much better to have
go-to's available. Languages like PASCAL hem you in. A lot of people don't know
that the switch structure in C is such that you can place the switch labels
anywhere. If you have a loop inside a switch statement, you can switch your way
right into the middle of that sucker. It is almost as powerful as a go-to.
GAM: And probably as enigmatic.
JF: That's right. But there are cases when it is very rational to switch your
way inside an if-then-else sequence; you are coming in again, and you know you
are in this case. You don't have to cascade your way into it and set a bunch of
variables to fool yourself. But going into the side of a loop is something you
really have to think about.
GAM: Well, I think you'd have to think about when it would pay at all. I
don't think any of us are searching for microseconds anymore.
JF: Of course, another thing was the effort to save memory. In programming
machines like the PDP-8 and the 8X300, the whole thing was to shoehorn the
program into that tiny memory. Today, gosh, you can just throw memory
away.
GAM: Well, I don't see it as throwing it away. I think you use it rather than
to waste your strength on something that's just academic. Anyway, it's a new
generation of programmers that doesn't understand that the UNIVAC had only a
thousand words.
JF: A thousand?
GAM: The IBM 701 had 4K words.
JF: I remember doing something on the 7094, where you had 32K words. I had to
use trickery. The natural way to do the job would have taken exactly 32K words
of data�probably a few more, but 32K in the big array. So I figured out how to
cut that by a factor of 4 by being sneaky. Then of course I had plenty of space
for everything else.
GAM: Well, that's exactly one of the great rewards of programming�so to
say�"programming in the small," or something like that. These are intellectual
challenges that you meet and win, and they're good.
JF: There is the whole business in assembly language of managing the
registers so that you don't have to touch a thing after you have overwritten it.
I had a lot of fun with that, but I probably would not really enjoy going back
to it. It is an intellectual puzzle, which I guess I have solved enough times
that I'm not sure I would want to start solving them again.
GAM: Well, I expect that's correct.
JF: But as long as I kept doing it, it did not bother me. I guess it was kind
of natural. Obviously, you have got to keep this one in this register is what I
would think. You would get a real feeling for it.
GAM: How about you? Did you have to deal with Sid Fernbach a lot when you
were in the early days of this group?
JF: Sid was pretty much a hands-off guy. He let us take the ball and run with
it. The one thing�you have to give Garret credit for this�was that Hans
Bruijnes liked to�
GAM: Impose his personality.
JF: When Garret was�we were�putting together the PDP-6 storage system, we
discovered that Bruijnes had put a few of his group to work on an alternative
version, his idea being that theirs was going to come in and be used instead of
ours. He had done a similar thing earlier, I think, on the CDC 3600 or
something.
GAM: Yes.
JF: Anyway, we got wind of it, and Garret came in and worked nights and
weekends, and he got our scheme done first.
GAM: I remember that, yes.
JF: I have this clear impression�I do not know how I would have been
present�of Sid telling someone in the other camp that, well, he was going to
have to go with what Garret and Badger and the rest of us had done�sort of
apologetic. But I cannot remember why it was that I would have been in a
position to overhear that. Anyway, Sid was a results guy. You could see that if
we had not been first, we probably would have been chopped off�there is no
question about it.
I really liked Sid. He was a good guy to work for�well, present regime
excepted�better than his immediate successor. I will put it that way. I will
not judge the present regime.
GAM: Oh, I see.
JF: That is when everything that we did that was new and original either took
place, or the seeds for it were planted. It may be that the world passed us
by�we just could not possibly, single-handedly stay at the forefront like we
used to, but I don't think that things would have gone quite the way they did if
Sid had still been around.
GAM: Well, yes, I'm afraid we can't tell that. Sid's Waterloo so-to-say was
two STARs. I think he spent an enormous amount of emotional and just day-to-day
attention on that problem, and so other things just didn't get attended to so
much.
JF: In my view the STAR certainly did not turn out the way one would have
hoped. But you had to do something. Sid was trying to bring us more
computing power. What was the alternative?
GAM: I don't know, but I'm just emphasizing that the Waterloo is not STAR,
but two STARS, okay? One STAR is no more serious than one LARC, or one
STRETCH.
JF: The mistake was to get two of them?
GAM: Yes. That's what everyone says.
JF: Well, that might have been, that might have been. Another thing that may
be laid at his doorstep is the fact that we did not get our way of doing things
out into the world. Had we worked harder at making some of our ideas�
GAM: I don't think it was needing to work harder so much as we ought to have
published more.
JF: Yes, maybe just that. There was no encouragement, no pressure put on to
get our ideas out. That probably was a mistake.
GAM: Well, mistake may be a strong word. I would say it may be implied that
the job wasn't finished till the paperwork was done, or something like that. In
any event, the major difference between us and anywhere else is the
publication�just look. Other than that, the better stuff was in general made
here, especially in the early days�far better.
JF: Yes. There were lots of things that people had to give up in one way or
another when we went to UNICOS. We are fixing some of them now. We are working
on restarting jobs.
GAM: It's a different computer world now.
JF: Yes.
Note (added April 10, 2008): John's second interview can be found here.
Interested persons may also view his recently unearthed 1983 video, "Computing at the Livermore Lab" on Page 4.
[1] The error-correction algorithm:
Two counters, C0 and C1, are both initialized to zero.
All sums are performed modulo 255 (i.e., ones-complement).
As each byte B of a packet of 8-bit bytes is transmitted,
the counters are updated as follows:
C0 = C0 + B
C1 = C1 + C0
When the packet is complete, the sender appends two check bytes
as follows, using the then current values C0 and C1:
First check byte = -C0 - C1
This byte is then incorporated into C0 and C1 as were all preceding
bytes (which, as is easily seen, reduces C1 to zero).
Second check byte = -C0
Incorporating this byte into C0 and C1 also reduces C0 to zero.
The receiver simply computes the checksum for all received bytes.
An error is detected if either C0 or C1 is non-zero (modulo 255)
after the second checkbyte is received.
[2] The CEL code was a large, 2D hydrodynamics code developed by William (Bill) Noh, now deceased.
[3] Passwords were generated as follows:
There are seven forms of password, as follows:
1. 6 letters (e. g., "qwerty").
2. 5 consonants alternating with 4 vowels (e. g., "domifasol"),
where a consonant is b, d, f, g, j, k, l, m, n, p, r, s t, v,
or z and a vowel is a, e, i, o, or u.
3. 3 nonsense syllables (e. g., "non sen sil"), where a nonsense
syllable is 2 consonants separated by 1 vowel.
4. 2 nonsense syllables followed by 3 digits (e. g., "non sen 854").
5. 1 nonsense syllable followed by 6 digits (e. g., "sil 917 632").
6. 9 digits (e. g., "013 267 548").
7. enough (almost always 2) English words from a dictionary of
18,823 words, each of up to 7 letters, so as to total at least
8 characters including separating spaces (e. g., "two word").
A best effort was applied to purge the dictionary of offensive words;
however, it is impossible to foresee all subjective attitudes. Also,
the random processes may by chance generate offensive words or sequences
of words. A user obtaining a password regarded as offensive should
request another one and accept the authenticator's tacit apology.
Some forms of password are generated with embedded spaces to foster
readability; these need not be included when the password is used,
and in fact additional spaces (as well as control characters) may be
inserted so long as the total characters do not exceed 16.
The C subroutine used to generate passwords:
static void pwgen (pwd, fmt) /* Subr to generate password */
unsigned char *pwd; /* ptr to password */
unsigned char fmt; { /* format of password */
#define Lpwd 16 /* max password length */
#define Lpwdict 18823 /* length of dictionary */
static char *pwdict; /* ptr to dictionary */
static unsigned char map [6][11] = {
{1, 1, 1, 1, 1, 1, 0, 0, 0, 0, 0},
{2, 3, 2, 3, 2, 3, 2, 3, 2, 0, 0},
{2, 3, 2, 5, 2, 3, 2, 5, 2, 3, 2},
{2, 3, 2, 5, 2, 3, 2, 5, 4, 4, 4},
{2, 3, 2, 5, 4, 4, 4, 5, 4, 4, 4},
{4, 4, 4, 5, 4, 4, 4, 5, 4, 4, 4} };
/* password format maps */
static unsigned char conson[15] =
{'b', 'd', 'f', 'g', 'j', 'k', 'l', 'm', 'n', 'p',
'r', 's', 't', 'v', 'z'}; /* consonant list */
static unsigned char vowel[5] =
{'a', 'e', 'i', 'o', 'u'}; /* vowel list */
unsigned int random = Time(); /* random # */
int i; /* loop index */
char *w; /* ptr to dictionary word */
for (i = 0; i < Lpwd/(sizeof(unsigned int)); i++)
/* loop thru previous password */
random += ((unsigned int *) pwd)[i];
/* include it in random # */
if (fmt >= 6) /* if dictionary to be used */
for (i = 0; ; ) { /* loop thru chars of password */
for (w = pwdict[(random % Lpwdict)*8], random /= Lpwdict;
*w > ' ' && i < Lpwd; ) /* loop thru dictionary word */
pwd[i++] = *w++; /* include word in password */
if (i >= Lpwd/2) break; /* end password if long enough */
pwd[i++] = ' '; } /* get space */
else for (i = 0; i < 11; i++) { /* loop thru chars of password */
switch (map[fmt][i]) { /* select char according to fmt */
case 1: /* letter */
pwd[i] = 'a' + random % 26,
random /= 26; /* get random letter */
continue;
case 2: /* consonant */
pwd[i] = conson[random % 15],
random /= 15; /* get random consonant */
continue;
case 3: /* vowel */
pwd[i] = vowel[random % 5],
random /= 5; /* get random vowel */
continue;
case 4: /* digit */
pwd[i] = '0' + random % 10,
random /= 10; /* get random digit */
continue;
case 5: /* space */
pwd[i] = ' '; /* get space */
continue; }
break; } /* end password in other cases */
(void) memset(pwd + i, 0, Lpwd - i);
/* pad end of password */
return; }