An Interview with Garret Boer
GB = Garret Boer
GAM = George Michael
GAM: Today is the 7th of September, 1993, and we're going to interview Garret Boer.
Well, Garret, why don't you start by telling us when you
got to the Lab, and what your assignments were, and so
GB: Ok, I began at the Lab October of 1956. I remember a little about
being in the cooler. Tad Kishi came out once to bring a manual on the
704. The only other thing I remember there is playing
with one of those old Marchant calculators, learning how
to take square roots with a calculator. The 704 was my
first computer that I really studied. I do remember one
problem I had, initially, when I was studying it, and that
was that I couldn't grasp how data would get in and out of
the computer. Once it was in, I was having a lot of fun
learning how to play with it. It was a while before I could
make the connection between the outside world and the
inside of the computer. Anyhow, the 704 was the first
computer I worked with. I don't remember for sure what
my first assignment was. I remember a couple of early
ones. One had to do with some physicist doing calculations
in connection with the Ising  model.
The problem dealt with a rectangular array of cubes. Each
cube is one of two colors, say red or black. I was to do
some calculations on every possible combination of
colored cubes in a 6 x 6 array. This would be 236 cases,
requiring an eternity of calculation by a straight-forward
approach. I worked hard on this and developed what I
considered a rather ingenious method of doing the
calculations by starting with one cube in the array and
adding one cube at a time until the array was complete.
This sped things up by, at least, half a dozen orders of
magnitude. When I approached the physicist, telling him
of the initial problem and of my clever solution, he said,
"Oh. Well, if you had told me it would take that long, I
would have figured something out myself."
Well, that was my first introduction to physicists, which helped me
appreciate subsequent stories I heard about other people's
experience with them.
GAM: It's sure a mixed bag. How about some of the computational tricks you
discovered? I remember Gale Marshall figured out
what's called a "sneak-on," so you didn't destroy any of
the memory when you wanted to take a dump? He used
one word of memory, or something like that?
GB: I'm the one who wrote that dump. That was one of my achievements when
I began working on my own. There was a dump in use
that took all sorts of memory. I don't know if we ever got
down to a one-word sneak-on; the older dump destroyed
quite a bit of memory, and was about 40 cards long. My
first independent effort was to write that dump, which
was an octal and a decimal dump, the decimal being the
most challenging part to squeeze in. And it did, indeed,
save a lot of the user's memory to disk. I'd say
that you got practically all of memory. Another
interesting thing about that thing: We had, at that time, of
course, an assembly program. The standard cards it
produced were cards that had to be preceded by a loader.
For a normal program you would write, you would take
this little loader deck, put it in front of your deck,
and read it in.
Well, I needed a special kind of a card for my dump. I didn't want to
precede it with a loader, because it would wipe
everything out that I was trying to save. I was too
inexperienced to realize that there was actually a mode in
the assembler that permitted you to essentially make your
cards any way you wanted them. You didn't have to use
this particular format. So, the first dump I wrote was done
by punching holes in cards individually on these old IBM
cards. Then, when I had to patch them, very often I
would, instead of redoing the entire card, I'd either
punch a new hole or you'd take the pieces that came out
of the holes and put them back in the cards.
GAM: I remember that trick, wonderful.
GB: Eventually, I think it was Clarence Badger who told me I was wasting a lot
of time, because the assembly program could do that for me.
GAM: Now, that assembler was the SAP assembler or FAP .
GB: SAP? It sounds familiar. I'm not sure.
GAM: It was a good assembler, and so was FAP.
GB: Yes, I guess that was a good machine to get started on, too. I was happy
with the 704. Gale
and I did some other work
now and then, but we often seemed to go off
on our own and wander into systems work. We
wrote a very early plot routine, enabling people to make
use of the 704 CRT, which had an attached camera. As a
matter of fact, that thing was carried on for generations of
machines, by people adapting it to new computers.
Then, for a long time, I worked with John Killeen. I guess it had something
to do with the plasma code, but I can't remember the details of that very much.
GAM: Yes, that's what John was doing.
GB: I never got to learn much about FORTRAN. I used assembly language my
entire career, which fit into the kind of stuff I was doing.
And then, at some point, I guess I just was into systems
work all the time.
GAM: Well, shortly after you got onto the 704, you must have switched over to
the work on the Photostore.
GB: Well, before that, there was the Stretch.
GAM: Oh, yes, that's true.
GB: There was a 704, of course, then a 709, which is a follow-on to the 704, just
a faster, bigger machine. Then Clarence, I, Gale, and
Norm Hardy, to a great extent, got involved when the
Stretch got here. Norm Hardy would come
by and leave all the ideas, then we'd pick them up and
hang around and do the systems work. Norm was very
instrumental. That was the first machine we ever dealt
with that had interrupts. Norm wrote some basic things to
handle interrupts. But I don't remember the details. He
came by and left all sorts of great ideas, and moved on to
GAM: He's still that way.
GB: Well, I think we need that kind of person. He engendered an awful lot of
stuff here at the Lab, for the Stretch and beyond.
That also was the first
computer around here, and possibly the first anywhere,
that had an actual disk operating system. You didn't have
to load a deck when you got on; you could keep your files
on disk, and the disk was probably not as big as a floppy
disk these days.
GAM: That's probably true, but it was the biggest thing around then.
GB: But it was good enough to actually hold people's programs that were
running. Of course the Stretch turned out to be something
of a disappointment, as you may remember. It didn't live
up to its advertised capabilities.
GAM: Well, you know, it depends. From a programmer's point of view that may
be true, but from a physicist's point of view, the Stretch
paid for itself in 1962 by letting them turn designs around
during the Christmas Island tests.
GB: Well, I didn't know that detail. I just know that it wasn't nearly as fast as it
was it was supposed to be. And we got a lot of money
back because we ran some very severe tests on it. We had
to renegotiate the contract, because it didn't meet the specs.
GAM: Yes. That's a neat story. We should have a special tape on that one.
Well, that was one time when Sid did some real clever
bargaining. IBM cut the prices, but they didn't do it across
the board. They cut the prices of the CPU and the
Exchanges, but not the memories or I/O units. Sid tried to
buy more of the stuff that had reduced pricing, but IBM
wouldn't sell. It would have been great, costing only a
few hundred thousand for what was originally $8 million.
GB: They couldn't afford to build a building to hold it in, too. Do you
remember how big that thing was?
GAM: Oh, yes.
GB: Rows and rows and rows of God knows what.
GAM: But IBM demurred. They didn't want to sell another one.
GB: Well, they were probably wise, actually. They would have lost even more
money just maintaining the thing.
GAM: It's a matter of how you count, you know. They used the Stretch to test the
design of the entire 360, and that certainly made money.
GB: And the 7090s, I understand they used Stretch memory...
GB: Yes. It had its spin-offs. It kept them going until these last couple of years.
Things have turned around a little.
GAM: Indeed. Well one of your big adventures is the mass storage thing. You
should be canonized for the work you did. No user ever
suffered a loss, and they were always able to get their
stuff, they can get these by file name rather than where
things were, and so forth. All those things were incredible
innovations in their time.
GB: Yes. It was a big step forward. I don't think it's quite true that
nobody ever lost anything.
GAM: I never heard of it.
GB: There were files, I mean there were chips, that got smashed, so
something must have been lost, maybe nothing of
sufficient importance to worry anybody. And, of course,
we didn't have any backup. But that was kind of
interesting. There was a little adventure ahead of that,
you know. When the PDP 6 arrived we began developing
the operating system for it and the central directory
system, which was the clue to why, as you suggest,
people were able to refer to things by name.
There turned out to be a little race. As you may recall, there was a group
consisting of John Fletcher, myself, Clarence Badger,
and Gale Marshall working on that machine. And then
Hans wanted to get on the machine, too, with his gang of
fellows. So they actually set up a situation where the first
one that got a directory, a working directory system, to
run on the PDP 6 sort of got the job. So, as it turns out, we
won that little race, and therefore assembly language
became the thing that went on the PDP 6 rather than
FORTRAN, which they were about to put on it.
At the time I thought that was a great boon. Whether it
was, long-term, or not, I don't know.
GAM: Well, I think a lot of people thought that. And specifically, that time
was what, about 1967 or '66?
GB: Yes, it was about '67, I think. Now, that was before the Photostore. We
actually set up our central storage system with an IBM
Data Cell. A Data Cell was a marvelous little thing that took
these thin strips of magnetic film and wrapped them
around a drum, and then tried to shove them back into
their storage slots. It was a marvel that it was able to ever
put those wobbly little things back away.
It didn't always succeed, of course. And that was where
our first directory system resided. I think we put together
a damn good system. We essentially lifted it from, what
was the name of that thing at MIT?
GB: Multics. Yes. I don't think the others in my group went, but I
went to this conference where Multics explained all its
ideas, and I came back and sold it to all my compatriots.
Multics really had the basic ideas of how things should
be, how it should be run, the directory system and
processes, the idea of processes. And so we essentially
implemented them. We had it before they did, actually.
Again, we got the idea from Norm Hardy. Yes, that's been
a pretty good success story, the central storage system. I don't
know how many times we've had to move the directory
structure. We had to pull it off the Data Cell because that
became obsolete. Then, as we got bigger disks, we had to
move to the bigger disks, and we have the same thing on
the Amdahl. Where it still is, I might say. Now we're
finally trying to dump the last trace of the thing which we
had in 1967, and turn it into a Unix database, and we're
not quite there yet. That's what, well, 26 years.
GAM: That's a nice longevity record.
GB: Well, we were hoping this last year to go out for a bid. Of course,
some people may have been hoping for a Convex. I haven't
kept track of it. We seldom, if ever, get the machine we
want, you know, unless we write the specifications in
such a way that it points one way without obviously
pointing one way. But, no, that money was taken away
from storage to buy the MPP. So we still have the
Amdahl machines, which haven't been around as long as
the PDP 10 existed, but they're still obsolescent. But that's
not the main thing to do with the conversion. The
conversion to the new database will take place on the
Amdahl. Later, the whole thing can
easily (more or less) be transferred to another
machine because it will be a standard product. It will be a
Unitree product. Initially it won't be a standard Unitree
product for many reasons. In any case that will finally
be the absolute end, the last trace of the old directory
GAM: Well, in your opinion, is that a step forward, or not?
GB: Well, I don't think the Unix directory system is nearly as flexible
as ours was. The biggest problem in conversion is we have
to now assign owners and groups and permissions to all
these directories. What we know is
going to happen is that the day after we've come up with
a new system, some people will not be able to get at what
they previously could get at and, probably, to a lesser
extent, some people will be able to get at things that they
previously couldn't get at, because Unix doesn't have the
complete flexibility of structures so that any group of
people could all point to a given set of files.
GAM: Building their own group, essentially?
GB: Well, building as many as you want arbitrarily. Any two people can share
anything in our system. Or any three people can share it.
You don't have to sweat yourself trying to figure out how
to establish groups so that this subset of people can
always get this subset of files, and so forth.
GAM: Well, I would think you could maybe save that, preserve file sharing as
you move from one system to the other.
GB: Well, see, we didn't really have groups in the old system. It was just a
matter that any particular time you wanted to share with
somebody, you'd give them a pointer to it, thereby
sharing it. That's incompatible with the standard way
Unix is done. I think the presumed main advantage of
going to Unix is that now you're compatible with the rest
of the world, and all the good things they're doing out
there you'll be able to use. But there's a lot of weaknesses
to their system. I think Unix is a great system for code
development. But, as far as a system on which you run
production, there's an awful lot of difficulties as people
are finding out around here.
GAM: Right. And one of its seeming difficulties is it doesn't seem to do very well
for very large things, very large objects, that type of
thing. A lot of people throughout the country are
complaining that when Livermore gave up doing
operating system research, that was a bad thing. So
whereas it may have been that NLTSS had some
misdirection, or it was too slow, or it took too long to get
to it, or whatever you want, the reaction of going straight
to Unix is seeming a little bit unwise.
GB: Yes, from what I hear, I'm not in touch with the people who really use it
all the time, but what I have heard is that the tools that
are supposed to be out there all over the place that you
use, don't do what some of the tools they've had here do.
The editors aren't quite as sophisticated, the debuggers
don't get in there and handle things like the old ones did.
So, there's two sides to the question. I think the
unfortunate thing, as I see it, there will probably never be
another really good innovation in operating systems.
Unix just permeates everything to such an extent that it's
almost impossible to imagine overcoming the inertia that
GAM: I'm not sure. There's some who say that NT will be the new thing, from
Microsoft. And others are trying to get the KEYCOS thing
onto a big computer. KEYCOS is Norman's operating
system that they started developing while he was at
TymeShare. It's a capabilities-based system similar to
what NLTSS was. It does have really high-level security
certification already, but it only runs on IBM equipment,
in a native mode. And the other thing is, it's difficult to
put anything like that on a Cray because there's no virtual
memory. So, if Cray ever relents, and gives you virtual
memory, you might see KEYCOS over there.
GB: Well, I guess on the other hand, Unix hasn't really hasn't penetrated the PC
market at all. So, maybe there's a chance for something
new and wonderful to happen there at least. And maybe
someday there won't be anything but a PC market. There
will be one million little PCs all in a row.
GAM: That'll be a challenge for those who have to write algorithms or develop
algorithms. How do you make your algorithm behave
across a million PCs?
GB: Yes, well they're working on it. They're having to face that right now, at
considerably less than a million of course, but it will be
interesting to see how.
GAM: Well, I watched some of that stuff, with a morbid eye, and what I see is,
generally, whenever people have some real computing to
do, they go to a Cray. No matter where it is, in this
country or in Japan or in Europe.
GB: In spite of all these MPPs that are coming along?
GAM: Yes. In spite of all the advances being made all the time, the MPPs
just don't seem to be ready for real users, especially when it comes
to the software. Big computations, like the ones around
here need lots of memory and I/O bandwidth, and the
Crays seem to provide that best. The others still seem to
GB: Do you think that's because they haven't been clever enough to develop
the algorithms, or that there's just something that can't
really be done?
GAM: Well, part is the algorithm problem, but it's partly also that these little
things just don't do I/O. Or maybe it would be fairer to
say that the users haven't yet learned how best to use
them. Mostly, those things are built by people who put
parts together rather than completely designing the whole
system like Seymour does. And the consequence is that
they pick off the shelf whatever I/O capabilities are there.
Three megabytes a second is what's available, but you want to run into
a gigabyte memory. Three megabytes a second is pretty damn slow. They don't
want that. They're tending to stay on Crays more,
although that's just for the really big problems. I'm sort of
morbidly amused by that sort of thing. However, it's hard
to tell what the two Cray companies will be doing in
another five years, if they're even around.
GB: What is Cray himself working on now?
GAM: I don't know. They say he's got enough money, allegedly, to last through
next year. And it is his intention to have a Cray 4 up and
running before the second quarter of next year. That will
be slightly over twice as fast as the Cray 3. The Cray 3
experience at NCAR is that it's still sort of flaky. The
gallium arsenide stuff still seems to be giving him some
trouble, and I suppose some of the connections are still
giving him trouble. The engineers that are there from
Cray are learning a lot about maintaining a Cray. There
are some people who say the real problem is that this is
the first machine that Seymour has ever done without the
help of Les Davis to do the real debugging. I don't know
where the truth lies. It's probably not so clear. But, I
believe we should be fostering Cray, and I'm not sure if
enough of that's going on. I think the National Security
Agency is staying with them. They're probably the
biggest Cray customer in the world. They're with
Seymour, and they're doing some pretty innovative
things from what I'm told. One of them (I may be able to get the
guy here to talk) is a technique for doing computation in
the memory of the Cray. You lose half the memory so you
can put more memory out. But it picks up speeds alleged
in the range of 1015 binary operations per second.
That's not bad!
GB: It's a good start.
GAM: Well, once it looked like that was an impossible thing to get to, but they're
doing it now. And when they do it that way, it will have
the logical structure similar to any good SIMD machine. I
plan to invite that guy to come here, the one who's been
leading the development at SRC. He was going to come
and talk about PETASYS as it's called, but every time we
set a date, something interferes. He's an interesting cat. I
hear they've talked Seymour into building the necessary
conversion hardware in the memory, so maybe there'll be
a test soon. We'll see what happens. Listen, we're
supposed to be interviewing you.
GB: Not Cray?
GAM: Well I find that stuff interesting, but you're the star of the hour. Go ahead.
GB: You have a question here about favorite languages. I've really worked
almost exclusively with assembly language. Now I'm
working with C on this new project. It requires that we get
beyond assembly language and, so, that's really the only
major, higher-level language that I've ever dealt with. But
I've dealt with an awful lot of interesting assembly languages.
GAM: Oh, yes.
GB: In fact, some you might not even be called assembly language. There was
one, it was really a machine language. The first bit-slice
control processors that came out.
GAM: That was due to Gary Kildahl.
GB: What was the name of the project when we had all the tapes
over there? The little cartridges?
GAM: That thing was a CDC 38500, and there was a TI machine on there,
and TI 980, that did the controls.
GB: Right. And then there was, to do the actual process control, these little
It was Irv Ferris over there that
built this thing to handle all the data transfer between the...
GAM: The CDC 38500 and the rest of the machines.
GAM: That was a hundred megabits a second to go between the Crays and the
CDC cartridge store. I remember that. But I never learned
any of the details of it.
GB: Well, anyhow, part of it was programming what they call a bit-slice
processor, which, to gain speed, they did some
fantastic things. I guess part of the
problem was they had a very limited instruction
repertoire, where an instruction word would contain the
instruction and its addresses. It had peculiarities and had
very tight geometric features. Because of that the memory was
sort of laid out in a rectangle. And, for a given instruction,
you could jump to the next instruction if it was in the
same row, some only if they were in the same column,
and some only if they were in column two or column
four. Gale Marshall wrote something to assemble code for
this, but it was really not an assembler, because it couldn't
do anything for you, really.
You couldn't just
write out a sequence of what you wanted to do. We couldn't think
of any algorithm on God's green earth to put these
instructions in the right places so that they could all fit in
this little mesh. So that was really a fun thing to do.
GAM: And Gale did that?
GB: Well, I programmed it. Gale wrote something to convert mnemonics to
bits. At least I didn't have to put the bits out. You couldn't just
put a symbol somewhere and have everything sort of fall
into place. It was really a fascinating thing to program for.
GAM: But what's your opinion of C?
GB: Oh, I think C is all right. I guess it's about as close as you can get to
assembly language program instructions thus far. And,
certainly, I have to admit it does save you an awful lot of
time. Of course, the old challenge to squeeze the last bit
out of your memory, and the last microsecond out of your
timing, is just so unimportant these days. Just buy more
silicon, and you buy a faster machine. If you really take
the time to squeeze out anything extra, it just doesn't buy
you much. It wouldn't be worth the effort.
GAM: Well, but is it more readable, for instance, or succinct?
GB: C is more succinct than assembly language, certainly. It's as readable as
you want to make it. You can make the most unreadable
code imaginable in C, and some people do. It's not
self-documenting, as they say. You can write extremely
obscure code in C. It's also awfully difficult to learn all the
ins and outs, the replications of things, all the precedents.
I've read some of John Fletcher's code in C on
occasion. John is one of the guys who has these precedents
very firmly in his mind. Which operators take
precedence, and "which one" is quite a list in C. I think
there's something like 12 different levels of precedence,
and each one also may be modified by left to right, or
right to left. So, when you read John Fletcher's code, and
you're some ordinary mortal like myself, what you do is
you get the C book and you open it to this page, where it
lists all the precedents, and follow it down there.
Another very interesting language I was working with was
"ladder logic". That was when I spent about a couple of
years out in the applications area. I was surprised at how primitive things
were, because this is process control country, and this
was working for Lasers. What was the name of the
project to separate the uranium by bombarding it with
light, you know? Anyhow, I was out there. There's two
sides. There were the people who worked on the lasers,
and the people who worked on this big tank where all the
separation goes on. And I was on the tank side.
GAM: AVLIS was the name.
GB: AVLIS, right. Anyhow, you had to control, in this case, a lot
of relays and heaters, and all sorts of the kind of thing
they use for their control process is what they call
ladder logic. The
basic idea of ladder logic is that it's broken down into sort
of pages. What you think of is a power bar that comes
down the left side of your page, and then it feeds through
these things which are timers, and "or" circuits, and
"and" circuits, and gates, and all that kind of stuff. Then
the power gets out to the end, and it does something,
which may mean it goes down to another page and
begins there. Or it may actually go out and open a relay,
or close a circuit. And you have sensors coming in, that
kind of stuff. So actually you take a page of this at a time,
and program this, fitting in these little things, making
lines to connect the timers, and the rest of it. And you do
it on a CRT.
GAM: I can imagine that you'd want to know on this page what was being done
on another page.
GB: Yes, but that's probably a drawback of almost any
GAM: Well, how did you avoid that, or how did you get around that?
GB: Oh, well, it's unambiguous. You just say, I'm going to
go to a certain point, and that certain point is identified
on the other page. But it was curious. All this stuff that
could've been done by a PC, was done by this peculiar
logic. I guess they developed these machines presumably
because the engineers were used to doing all this stuff in
these big boxes with real relays and timers.
GAM: Yes. It's called a pyramid of control computers. I think Jim Green would
have a lot to do with that, at least initially, or Bob
whatever his name is � he's now in the Director's
office. But each one of these little computers was a PDP
and an LSI 11 or something like that that will control this,
that, or another thing, and passes information on.
GB: Well, that was not the scheme they had when I was out there. I would
presume by now they're doing things quite differently.
GAM: Well, was there anything ever reported on ladder logic?
GB: Reported on it?
GAM: Well, you know, like is there a manual?
GB: Oh, yes.
GAM: I never heard of the word before just now.
GB: Well, I had never heard it before I got out there. But, evidently, this is
widespread in process control. These kind of computers
weren't developed at the Lab. These were
standard products. As I say, I think it was developed
because engineers who were used to doing process
control by using these huge arrays of relays and timers
and that kind of stuff thought that way. And so somebody
said, well I'll make the computer work that way.
GB: So, essentially, what you're doing is you're using a computer to wire up
timers and relays and all that kind of stuff.
GAM: Let's go back a bit. Probably the most fertile period was the development in
Photostore. You had four people working there, and you
didn't have any of these modern tools that are supposed
to make work so easy and communicative and all that. So,
how did you guys do what you were doing? Did you ever
talk to each other?
GB: Oh, yes. We talked to each other quite a bit. It was a very compatible
group. On the other hand, we just also sort of sliced up
the cake. We only had to talk when we had to interface. I
worked mostly on storage. John worked mostly on
communications between us and all the other machines.
Gale did the operating system for the PDP 10, and also
worked on all sorts of utilities. At one point, we all
cooperated on making the assembly routine. And I
remember, from that point, Gale sort of took the basic
skeleton of the one we'd all worked on (I think back as
far as the Stretch actually) and at some point he could
turn out an assembler for the new machine in a couple of
months just by plugging in different parameters and
things in the same basic skeleton. And he did that several
times, because we had all sorts of different computers,
well, like the TI 980. It seems like we could never
get the same computer twice to do the little jobs that needed
to be done out there, and so Gale would crank out
another assembly routine as fast as he could. I remember
the thing I did for the assembly routine originally was to
do the second part, which sorts symbols so you can have
a list of all your references and where the symbol is
GAM: Sort of like a code analysis or something.
GB: Yes. It's a code analysis. But it's interesting to me that we tackled the
program originally by just dividing it up. But that's
essentially what we did. Before something big and new
would come into place, like how are we going to do the
operating system, we'd all sit around and talk about it.
But then once we had talked about it, then Gale would do it.
GAM: Well, you didn't meet daily, for instance?
GB: No. Well, we were all near by for the most part. Four of us were
paired off in two adjacent offices, for the most part.
GAM: Well, weren't there cases when you would be trying to change a table that
somebody else was going to use also?
GB: Oh, I'm sure.
GAM: And how did you avoid walking on each other's toes?
GB: We talked when we had to talk. There never seemed to be a problem. We
worked together very well. It was really a good arrangement.
GAM: That's certainly not the way it is today.
GB: And, also, what was very interesting about that era was how closely
we worked with the engineers and the technicians. We
had input to how things were designed. We gave them
great help in debugging and that kind of stuff.
GAM: Yes, that's true. We had to build a lot of interfaces.
GB: We certainly did. We built the one here for the Photostore and for the
Data Cell. Then there was that marvelous, 5-foot-high
disk that we got.
GAM: Yes, the GD disk.
GB: Yes. A head-per-track disk. Incredible marvel.
GAM: That was a marvelous piece of stuff.
GB: It was in its time. I can remember, to speak of anecdotes, one of the
aspects of that thing is when they brought it up from stop.
Something had gone wrong and they took it down for an
occasional head crash. It had extra tracks. They relocated
the tracks, and they'd have to take it down and fix it. For
one thing, after it was brought up, it had to run for an
hour or something to warm up, just so everything would
be right. Otherwise, if you started writing stuff, evidently
the metal would expand and the tracks would be offset,
and you couldn't read it. But they used to go down there
to start it up with a stethoscope. And they'd be listening
very carefully as it came up, and they tried to start flying
the heads. I guess they're just ready with their left hand to
pull the heads back off or whatever they had to do if
anything sounded the least bit bad. It was a sensitive little
gadget for its enormous size.
GAM: Wow! It may be delicate but it really was an important component.
GB: Oh, yes. I mean it really improved our life a lot. That's where we put the
directory structure. We backed it up but it was
dynamically up there on the disk, and that was a big step
forward. I suppose that didn't hold as much as a floppy holds today.
GAM: I don't know.
GB: But it had a head-per-track. That was pretty good.
GAM: That was one of the original design parameters that some of us had when
we were talking about the Octopus to begin with, a head-per-track disk.
GB: Yes, I remember you and Norm had the idea that the central
thing would be nothing but a big, huge disk that everybody would communicate with.
GAM: Yes. It might have worked, but Burroughs didn't build it.
GB: It probably would have. Disk technology was a little bit shaky in those
days, I think.
GAM: But performance of that genie disk is probably better than any they've got
right now, in terms of latency time to get a track.
GB: Oh, well, latency to get to a track, yes.
GAM: It was 8 milliseconds.
GB: Possibly. I don't remember, but it couldn't have been to get to a sector,
because that thing couldn't have gotten around that fast. To get to a
track it was very fast.
GAM: It switched fast, yes.
GB: That was probably as good as almost anything is today, because the head
was always there. Waiting for the right block to come up,
or sector to come up. But I
remember the basic programming challenge was to
exploit that in such a way that you could pick up a new
sector very fast. If we switched to another head, we didn't
wait for a revolution to pick up the thing. We picked up
the sectors as fast we could. Well, that was a lot of fun.
GAM: I remember somebody telling me it was 8 milliseconds.
GB: Well, you're probably right.
GAM: That's bodacious fast, okay?
GB: Right. The best you get today is what, 17? Which is bodacious fast
considering that they have to move the heads, actually.
Actually, 8 milliseconds is an eternity for electronics
switches. It was good in those days, but I don't really
know what the time was.
GAM: Let's see, switching a little bit, Sid was our
boss. How did he come across to you and to your little
group with John, Gale, and Clarence, and
things like that? Did you have to deal with Bill Masson?
GB: No, I don't think we had to deal with Bill Masson or, for the most part,
with Sid. If I look back on it, the great thing about Sid was
he believed in you, and he backed you, and you did your
thing. He gave you all the elbow room you needed.
GAM: Well, did he ever come by and sort of look in and say how are you doing or
something like that?
GB: I don't think hardly ever.
GAM: You don't recall him doing that?
GB: One thing I remember, when I was telling you about the rush to see who
could get the directory system done first: On the occasion
that ours was ready, put together, I went down to the
machine and made a demonstration.
I remember that demo. I guess the decision was made then
that we'd go ahead with ours. And we did. But
Sid must have gotten that from the computing
community somehow. It wasn't by asking us for progress
GAM: He didn't get it first-hand is what you're saying.
GB: Right. Yes. He just must have seen the results, and hoped they were good
enough. Yes, I think he was far and away the best as a Division or Department
Leader. As a Department Leader, he was as close in those
days as Division Leaders now, I think. There weren't that
many levels. There weren't as many people.
GAM: Well, in the early days he was pretty effective. I think that the basic
breakdown came when he had to defend the Stars, two
of them. And he lost his credibility in the Director's Office
GB: Yes, that was too bad. The Stars were certainly oversold by CDC, that's for sure.
GAM: Any more than Stretch was oversold by IBM?
GB: Well, I don't know. Maybe not. But what they required to get that to work
was far and above what was required to get the Stretch to work.
GAM: It was a new architecture. And it may have been oversold, as you say. It
certainly wasn't able to pick up the production load at the rate we expected.
GB: Incredible sink of manpower.
GAM: Yes. I remember Jim LeBlanc saying, "We spent seven years trying to get
physics done on that damn machine. Never again!"
GB: Now they're trying to do it on Unix operating systems.
GAM: Well, the old order passes, and there's new guys who don't have that bitter
experience. Did you work on the Star at all?
GB: No, I didn't work on the Star at all.
GAM: You were nicely insulated.
GB: I guess so. At the time, I was kind of wishing I could; it sounded pretty
interesting. I was especially fascinated by the array of
drums they had there, but I didn't do anything about it.
GAM: Well, with the benefit of 20-20 hindsight, can you think of
things we could have done better, or quicker, or easier, or
GB: Yes, I saw that question. I don't know. I never had a very broad view of
things. I've just sort of taken the mole's eye view, you know.
GAM: Well, you were a terror in your youth. You don't remember that, though, hmm?
GB: A terror?
GAM: Yes, you were a terrorist. Do you remember lying down on the couch up at
Abbott's house and playing blindfold chess? You were half-drunk, I think.
And you were playing chess against three or four people. Do you remember that?
GB: I don't remember it at Abbott's house. I do remember playing blindfold
chess. But probably not the time I was drunk. But that certainly never
terrorized anyone, did it?
GAM: I heard you were pretty good.
GB: If you pick your opponents very carefully, multiple blindfold chess isn't so
GAM: Maybe so. Still, it speaks of a really neat
mental picture you have which lots of people don't have.
I certainly don't have it.
GB: Yes. That was fun. I do play blindfold chess with my boys, simultaneously.
GAM: Do you play chess much these days?
GB: No, I don't play chess very much. I was never all that good a chess player. I
never got above Class A. I'll never be a world-class chess player.
GAM: Well, I don't know, you won every time that I saw you doing it.
GB: Well, that's what I say. You pick the opposition.
GAM: I don't know that you picked your opposition. There were just guys ready
to come in and chew you up.
GB: Well, chess-wise around here was small potatoes.
GAM: Well, yes, I suppose that's true. Did you ever play Frank Adleman? He was
GB: Yes, was he at Berkeley?
GAM: He was a physicist here at the Lab.
GB: We had a chess team here at the Lab, and he was on it?
GAM: Yes. In the early years.
GB: Somehow I keep thinking he was in Berkeley, but maybe not.
GAM: Well, he spent a lot of time there.
GB: One of the interesting things about
that was the chess team went to San Quentin a couple of times
and played the inmates there. They never
got mad enough to hurt us. I don't know if we lost every
game or what, but we had a pretty active chess team.
GAM: That's neat.
GB: But, what could we have done differently? I don't know. I think the best
move we ever made was to plagiarize Multics. I mean the
simplicity of that system, its basic utility, certainly carried
the central storage system for two decades.
GAM: Well, it's said by outsiders that there were three things that were first rate
at the Lab. One of them was the storage system, one of
them was the television monitor display system, and one
was the operating system. It was the only one that was
able to take the mixture of programs or problems that
people generated. Now, the trouble is, if that never got
into a place where you won a medal for it or something
like that, where you got recognized for doing this kind of
stuff, but the storage system and television monitor
display system are still active, as you say.
GB: Well, it may be if it's a matter of getting publicity, maybe we could have
done a lot more on that.
GAM: Oh yes.
GB: We certainly could have striven to get our systems out into the world. Now
I'm not sure operating system would have been received
it was so well tuned to the
idiosyncratic needs of the people here. And it might not
have been as general-purpose as we were told. But I'm
not sure about that either. As a matter of fact, this new
Unitree operating system we're going to in many respects
derives from the central storage system here. The division
into different functions and
that kind of thing came from the IEEE storage system standard,
and a lot of the basic ideas of that
grew out of what we did, which arose out of the Multics.
GAM: Well, I remember we have tried to have you invited as the Lab's expert for
those expert panels that we started with, where you could
come and say, "I've been working on a mass storage
system. Let's talk about this now." I remember those.
You went to Boulder to do that. Well, now it's
grown all out of proportion, and I'm not sure it hasn't lost its way.
Do you have any other things you want to add before we stop this?
GB: No, I guess I can't think of anything in particular. You
asked about supervisors. I guess my favorite supervisor
was John Fletcher. That's because there was
essentially no supervision working in his group.
It was a great way to work. Mutual respect.
GAM: In fact, it could even be a paradigm, okay? That is, you get good people,
and tell them what you want done, and then get out of the
way and let them do it.
GAM: I want to thank you for this most interesting chat.
 The Ising model was proposed originally around 1920 to
explain the phenomena of phase transitions in a ferromagnet. As
used in computational procedures it came to imply a procedure
that used the Monte Carlo method for the study of particles in a
lattice undergoing phase changes or other motion dynamics.
There is a good, general discussion by Brian Hayes of
the computational aspects of the Ising model. It
appears in "The American Scientist, vol 88, no. 5, pp 384-388.
 SAP stood for Symbollic Assembly Program.
FAP stood for FORTRAN Assembly Program.
For information about this page, contact us at: firstname.lastname@example.org