An Interview with Garret Boer

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 forth?

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 [1] 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 [2].

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 for physicists 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 something else.

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...

GAM: Right.

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?

GAM: Multics?

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 system.

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 Unix represents.

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 lack something.

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 bit-slice processors. 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.

GB: Right.

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 programming language.

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.

GAM: Yes.

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 referenced.

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 reports.

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 at least.

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 different?

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 bad.

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 very good.

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 well because 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.

GB: Yes.

GAM: I want to thank you for this most interesting chat.



[1] 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.

[2] SAP stood for Symbollic Assembly Program. FAP stood for FORTRAN Assembly Program.