An Interview with Jed Donnelley

JED = Jed Donnelley
GAM = George Michael

GAM: Today is the thirteenth of October, 1995, and we are talking with Jed Donnelley. We'll just ask him to start by telling us where he went to school and how he got to the Lab. Editor's note - more and updated information about Jed Donnelley is available from these professional and personal Web pages.

JED: I grew up in Palo Alto. My father, who flew for Pan American Airways, was an early influence on my interest in technology. I attended the University of California's Davis campus. When I started at U.C. Davis, I already had an interest in the brain, deriving from an early philosophical debate. In high school, some of my friends and I used to discuss, ad infinitum, appropriate or effective goals in life. Initially I became essentially a nihilist by finding that I could argue effectively against nearly any goal - money, fame, power, hedonism, doing good, etc. However, one goal that I found I could not argue against was knowledge, specifically knowledge about goals. If one tries to argue against knowledge about goals, the argument is self defeating. One needs knowledge about goals to effectively mount any such argument. I found that achieving such knowledge was the one goal that I could not argue against. Having no alternative, and nothing to loose, I choose seeking such knowledge as my goal. I came to refer to this philosophy as "optimistic nihilism" as I ultimately came to feel rather positive about it.

My next question was, what does knowledge about goals mean? Well, knowledge in general, what is that? So, I started studying brains. I got interested in brains and their relationship to knowledge. I decided that I would study neurophysiology and try to learn how the brain works. I had some advanced placement credit in chemistry and physics that gave me a bit of a head start. What I found when I started at the University was that, to find out about the brain, I needed to know an awful lot about biology. So, I started studying biology. But to really understand biology one needs to understand a lot of biochemistry. You also need a lot of general chemistry. So as an undergraduate I started studying chemistry. By the time I was a sophomore and had to declare a major, I declared a chemistry major. Of course one needs to understand physical chemistry to understand chemistry, and I kept dropping down into the sciences and, finally, I got down to physics. Even physics is mostly mathematical underpinning. By the time I was a senior I had three declared majors, Chemistry, Physics, and Mathematics. I loved being in college. I sometimes took as many as 36 quarter units. I found that by taking classes with no required homework, by limiting myself to courses with good lecturers, and by never allowing anything to get past me during lectures I could do well without spending much time on homework (impossible of course with 36 quarter units). I would often mix courses in Physics, Electrical Engineering, and Mathematics that required some of the same base skills - e.g. linear algebra. This worked out quite well for me as I could get reinforcing material from the different schools.

The last quarter I was an undergraduate at UC Davis (Spring 1970) was during the height of the Vietnam War. I had a middle-ground lottery number. It appeared that I might be drafted. I had filed papers to graduate with degrees in Chemistry, Physics, and Mathematics. To avoid graduating, and therefore give myself more time to deal with the threat of being drafted, I decided to fail a Chemistry class that would keep me from meeting the requirements to graduate in Chemistry. During the summer, it became clear that I would not actually be drafted. I had to decide whether to go back and make up that Chemistry credit or just accept bachelors degrees in Physics and Mathematics. Ultimately, I decided to settle for a B.A. in Physics and a B.S. in Mathematics. At that time, I was focusing on the underpinnings of Mathematics, logic and set theory. I really enjoyed the game-like aspects of such abstract Mathematics but, eventually, I decided that I needed to tie all my studies back to the brain understanding that was my goal. There were some pretty strange things that happened. I did develop a model of the brain which I still feel pretty comfortable with. I believe the brain is something that people feel is more difficult to understand than it really is. This is probably not an appropriate place to talk about that model, but there are some very interesting things that happened between that model and my own brain. Some kind of feedback cycles that would happen occasionally when I would see the model in my own actions.

Getting back to the Lab, I was doing a lot of computer programming to simulate this brain model. I was working on a Burroughs system at UC Davis and, also, I did a little work on a CDC-3400 that used to be in the old applied-science/CDC building over on East Avenue in Livermore. I remember going to that building; that was the first assembly language programming I did. Bob Anderson was there; that was when he was the operator on that early machine. He's still around in the Livermore Computer Center. I remember listening to the 3400 play Yankee Doodle with the register sounds. I was in an applied science class at UC Davis taught by Carl Jensen. That was during the early collaboration between the applied science department at UC Davis and LLNL. I came down to Livermore while I was learning some computational methods for solving certain differential equations (Adams-Bashford-Moulton with a Runge Cutta starter as I recall) and as a side effect got to program in assembly language for the first time.

On the Burroughs equipment you actually are not allowed to program in assembly language. It's a very odd computer system. They try to protect the whole computer system behind "safe" source language compliers. The compilers, loaders, debuggers, etc. are all supposed to be safe and not generate dangerous code. I also got into hacking back then. Hacking in both the pejorative and in the positive sense as it is used these days. I started hacking because I wanted to find out more about those Burroughs B5500 and B6500 computers. At one point I noticed a lapse in the compiling barrier on the B6500. They had accidentally made the Data Communications Algol compiler (which had full programming power, including embedded assembly language) available on the system. Using that compiler, I was able to develop a program that would input an array of data and then execute that data as machine code. Having done that I just saved that program away on disk and tape. Even after they fixed the hole by disabling the Data Communications Algol compiler for most users, I was still able to do anything with that computer. I could just send it code and it would execute it. I was mostly still working on my brain model but I was also "hacking" those systems to learn more about them. Since sometimes, either by mistake or design, such hacking showed that I had control over the systems I got a bit of a reputation around UC Davis as a hacker.

I had a girlfriend at Davis whose father worked at the LLNL, Bob Zimmerman. As I recall he was a machinist. He worked with some of the big metal turning machines. I didn't talk to him much after I came to the Lab. He worked here for a few more years after I started working at LLNL.

I came to the Lab in 1972 after getting my masters degree in Mathematics from UC Davis. Initially I was in the Department of Applied Science. I was in a Ph.d. program and got a part-time job to support myself. That job was a very interesting project; I was working for Bob Abbott on a project called RISOS: Research Into the Security of Operating Systems. I quickly found that I was learning so much more doing my work than I was in school that I dropped out of the school part of things and started working full time. This project was a hacker's dream! One of the things we were supposed to be doing (worked later termed that of a "tiger team") was to use the early ARPA network to access computer systems around the country and break into them. At that time, the ARPA network was still very early in its implementation. It had first started transmitting data in 1969 and so was still in a very early stage of development. It had perhaps 13 "host" computers on it and perhaps a somewhat larger number of IMPs (Interface Message Processors, the routers of the early ARPA network). With the RISOS access to the ARPA network we had access to the largest and most interesting collections of computers in the world and we were getting paid to hack into them! It was great! Of course, in some sense, finding a hole in a system is somewhat negative. You have found something wrong. That hole can, of course, be closed, but then what assurance do you have that there aren't just more holes? What you really wanted was assurance that there aren't any more holes in these systems. I took an approach that I haven't seen used since, but I still find it quite interesting and believe it has practical value. I called it the "exerciser". Basically, it is a dynamic-following technique.

Formal program proving was quite popular at that time. Many people in the security area felt that it would soon be possible to prove that a system like an operating system meets its specifications. That's very difficult to do. But, even if it were possible to complete such a proof, I was convinced that you still wouldn't know you had a secure system because those specifications are essentially just like another programming language—another way of describing what the system is. It doesn't say whether it's secure or not.

It appeared to me that some of the examples we saw of system flaws could be part of a system that was proven "correct." A good example of this was the flaw that showed up in the password checking subroutine for the Tenex system. That password checkering subroutine was called to validate a password that was passed in as a pointer into the virtual memory space of the user. The routine would compare the password one character at a time to the correct password stored in the systems memory area. It was easy to see that this password checking routing did correctly check the password passed in. Unfortunately it also constituted a fatal flaw in the system. It turned out that by a clever manipulation of that routine one could discover any password on the system in a few seconds. What one needed to do was to send a first guessed character to the routine in a location one byte before a page boundary that would cause a fault if the second byte was referenced. By doing this and going through all possible first characters one could discover the correct first character - it was the one that caused the system to make the user program page fault by fetching the next character. This condition was easily trapped and then the next character in the password could be discovered in the same way - leading to discovery of the password in linear rather than exponential time. This flaw was easily fixed by having the password checker first access the whole password parameter (e.g. to copy it). However, without such a fix, this provably "correct" password checking routine constituted a fatal security flaw in the system.

I believed it was important to push human beings into the equation. I believed that by rubbing somebody's nose in the policies that were actually implemented in the system, people would have the best chance of finding out whether a system was actually secure or not. The trouble was that there was no sense of completion to the sorts of analysis that were being done on systems at that time (or even today). They would have a system review/audit and, after perhaps five months, they'd say, 'We found this bug and this bug and this bug. We fixed those and, beyond that, it looks pretty good to us.' We and others would issue statements that were modeled after the sorts of statements auditors issue: "We have analysed this system with the best practice procedures of the auditing profession. From the results of those analyses and according to all of our training and blah, blah, blah this system looks good to us."

I wasn't satisfied with that. I wanted an analysis with a sense of completion. The technique I developed required a human being, knowledgeable about the intended security policies in the system, to look at and understand every conditional statement in the system. The auditor was required to generate a series of test cases. They had to look at the code and describe how each one of those test cases is going to execute through the code. At every conditional statement, they had to describe which branch the code would take with the test case under consideration. There are very interesting problems with this approach. Sometimes there are conditional statements where the branch is unpredictable. For example, it might be reading a clock — if it's after 3:00 o'clock do this. Because of such issues there had to be facilities in the "path flow" language I developed that indicated a random exit. Still, with any particular test case, an auditor could generally predict at least some part of a flow through the system. With this approach it was possible to measure how complete the audit of the system was. I also developed a "follower" code. This was a program that would follow the execution of the test cases. It was kind of like a debugger in some ways. It would examine the code from its starting point, look for the first conditional instruction, set a break point there, and then execute the code until it hit that break point. Then it would interpretively execute that conditional instruction to see where the code would go next. At that point it had a new starting point and the cycle could be repeated, usually until the system returned to user mode. In doing such following it would create a path through the system which could then be checked against the path flow that the auditor described. If the auditor was wrong in their prediction about where the code would go, then they were told of the error and they had to go back and analyse this code a bit more to get the path flow correct. If the flow was as predicted then that amount of the code was checked off and one could consider that much of the system audited. It was certainly a rather difficult and tedious procedure, but it did yield a measure of positive completeness. I felt the development of this exerciser method was one of the more positive things that we did in RISOS - though as far as I know it was never developed beyond the RISOS project.

GAM: That was when you were in RISOS?

JED: Correct. The RISOS group was quite an interesting group of people. Bob Abbott lead the group. Shig Tokubo was second in command. I was a young hacker coming straight out of college with essentially no real systems programming experience (except what I could hack). One person, who joined the group from MIT, Charlie Landau, had already done a fair amount of systems programming. Charlie had worked on an early PDP-1 system at MIT whose name I've now forgotten. The one that had the early space wars program on it.

GAM: That was Steve Russell's system.

JED: Our main computer was a virtual memory PDP-11/45. We wrote our own operating system for it called RATS: The RISOS ARPA Network Terminal System. It was a capability-based computer system. More on capability system development at Livermore is described in this Capability Computing at LLNL document [0]. It was quite an interesting system. It was modeled after that system on the PDP-1 at MIT but, of course, Charlie Landau had an opportunity to make some improvements. The rest of us also had a chance to do user-level programming for RATS. It needed a command line interpreter and, of course, we had to write any needed applications for it. I thought it pretty impressive that Charlie was able to write a complete and quite advanced operating system like RATS in assembly language in the period of about a year or two. I learned a lot by programming for that system.

Since RISOS was ARPA funded, one of the things we did was get on the early ARPA network. We were the first and for many years only ARPA network node at the Lab. Some time in 1973, we got our IMP, an Interface Message Processor, and our two 56-Kilobit lines. I think we were initially connected to SRI and to NASA Ames. We had to develop our own Network Control Program (this NCP was the closest equivalent to TCP in those days) which implemented the early ARPA network protocols for that system. We were developing a model of a secure system. I wouldn't say that RATS was ever developed effectively as a research vehicle. The system worked and satisfied our communication needs with its Network Control Program and application level tools like the still-developing Telnet and FTP along with a lot of custom telephone dialing and related communications software. We were able to do almost all our system testing from the RATS system.

One interesting aspect of the RISOS hardware was that it was designed to be mobile. It was configured in a trailer so we could hook it up to a truck, drive it out of the Lab and inside another secure facility, connect it to computers there, and test them with it. Since ARPA is part of the Department of Defense, they wanted us to be able to connect our test system to other systems that weren't connected to any external network. That big trailer used to sit next to building 218. Every once in a while I reminisce about the pad and some of the old cable ducts that are still out there. We had all sorts of cables coming from 218, going under the ground, and coming up under that trailer while it was there. I think that trailer is still at the Lab. It is easy to spot with the special doors that we had put on it to get in and out and the little door that we had put on to connect up to computer systems. After the RISOS project was completed in 1975, ARPA took the PDP-11/45 elsewhere but the Lab kept the trailer. For years, there was a PDP-11/70 (a slightly more advanced system) in that trailer that was used for some of the early distributed computing work at the Lab. Interestingly, we never did take that trailer out of the Lab to any classified sites. We did all of our work either on the ARPA network or with telephone connections.

The telephone dialers that we had were another interesting aspect of the RISOS equipment. We had an outward-going WATTS line we could use to dial for free anywhere in the US. Back then I seem to recall that line cost some thousands of dollars a month. Telephone calls were certainly much more expensive in those days. We also had 5 or 6 other telephones. With those telephones and dialers we would call up the WWMCCS (World Wide Military Command and Control System) computer or an Exec8 system or other systems that we were trying to check out that weren't on the ARPA network. Of course most computers weren't on the network in those days. Our use of telephone dialers during the later part of the RISOS project had some very interesting ramifications related to the early days of NERSC. In those earliest days it was called...

GAM: MFE?

JED: Actually, it had another name before it was called the MFECC (the Magnetic Fusion Energy Computer Center). As I recall it was initially called the CTRCC, the Controlled Thermonuclear Research Computer Center. Of course nobody would use such terms these days for political reasons, but back then when the program was called the CTR program (directed by Alvin Trivelpiece), it seemed reasonable to call the computer center by the same base name. When they first started up their computer center for fusion researchers they had it in building 115. That center was the first shared scientific computer center. They allowed people to connect to it using a number of dial-in telephone lines. Their network connectivity was kind of poor early on. A lot of people in their research community wanted to get at their machine. I forget what it was, probably a CDC 6600 back then.

GAM: It was a 6400 and a 6600 to begin with. I remember that.

JED: Well, it happened that many of the people who were trying to access the early NERSC computers were on the ARPA network but were not on the early network that NERSC set up (the predecessor to ESNet). Those people could connect to our RATS system with the high speed (56 kilobits was high speed in those days) ARPA network lines that we had. That allowed them to get to the Lab, but not quite to the early NERSC computer center. Also, we had telephone lines with dialers on them that we didn't use most of the time. So, we set up software running on the RATS system that allowed people on the ARPA network to Telnet to a guest account on the RATS system and then use our telephone dialers to make a local call to the early NERSC computers. We set things up so that people could dial any local telephone number. Fortunately nobody came in and harassed the people of Livermore by writing a program to call all the different numbers in the City or anything like that. Hackers weren't quite as sophisticated back then. I seem to recall that Argon Laboratory and the New York Courant Institute were two of the organizations that used our ARPA net to telephone dialer facility. They would connect to RATS using Telnet software and then make a local call to the early NERSC computers. Once they made the call they would have a 300 bps connection to the NERSC computer system, the greatest speed that was typically available in those early days.

An interesting aspect of our allowing that guest account and the open local calling (we did set things up so that our use had priority over those free outside calls) was that it ended up getting us in a bit of hot water with the NERSC folks. We really didn't have to do any actual work to set this facility up beyond what we had already developed. We put a minor tweak in the telephone dialing software and added the NERSC telephone number to a symbolic table. The people from Argon and NYU and elsewhere were saving some thousands of dollars a month on long distance calls. After a while, enough people started using those dialers that when the next one tried to make a call the system told them that there were no dialers available. By that time the people who saw that error didn't really know what they were doing. You know how it is. We told somebody at Argon how to use the facility. They told somebody else how to make such free "calls", they told somebody else, and before long all that was being passed along was the procedure for getting connected, not how it was being done or what facilities were being used. They didn't even know there was a telephone dialer in the middle of the connection. So, when the lines were busy and they couldn't connect to NERSC, they complained to people at NERSC (CTRCC). Of course the people at NERSC (I remember Jim Leighton was involved) had no idea what they were talking about when they mentioned "no dialers available." The NERSC people had them describe the procedure they went through. The NERSC people followed the procedure themselves and they finally traced it back to us. One day we got a telephone call and they asked us what we were doing. We described the system we had configured, how people were using it, and how much money they were saving. From their perspective it was a system that could have problems that they couldn't control. They didn't want to deal with the complaints. They asked us to turn off the facility. We felt kind of bad about that because it seemed a good way to save people a lot of money. That argument didn't sell with them, so we did as they asked and turned off the guest account and the open local dialing.

You can guess what happened at that point. The NERSC users on the ARPA network who were saving all the money by using the ARPA network connection to RATS asked us to turn it back on. Of course we couldn't do that. However, when they complained loud enough and long enough to the NERSC people about how much money it would cost them to make all those long distance calls, the NERSC people came back to us and reluctantly asked us to turn the facility back on, so we did.

Naturally that still didn't solve the problem with inadequate dialer resources. We would still run out of telephones for local calls. At that point I suggested what became an interesting, if rather strange, project. We actually got funding from the NERSC program to run a 9600-baud line from our computer to Building 115. They paid for the hardware and we supplied the software. At that time, NERSC was still using the old PDP-11 terminal "concentrators", with the code that John Fletcher wrote, to handle terminals and to multiplex the lines between the concentrators. We wrote code to implement that protocol on a line that we connected to the early NERSC computer center so that we could multiplex the line as wide as was needed. We had what amounted to old octopus terminals going down that line to the NERSC center. Now people could connect to NERSC from the ARPA network through RATS and they would never get a busy signal. They could all share that one 9600-baud line from our RATS system to the NERSC center. With that facility people could get much (!) better performace coming in over the ARPA network! That system got implemented a fairly short time before NERSC moved their computer center to another site at LLNL. Their new site was too far from our RATS system to run a 9600 baud line. The system with the multiplexed 9600 baud line probably only ran for about 6-8 months. Perhaps it was lucky it didn't run any longer. If it had, enough users might have been on it that they wouldn't be able to turn off the service when they moved into their new building. Even at that I think their users got enough of a taste for that connectivity that NERSC ended up later taking over the costs for the ARPA network IMP (the network connectivity node) and moving it to their new facility at a later time.

I remember having some run-ins with Jim Leighton back in those days. RISOS was on the ARPA network and, by that time, we knew quite a lot about the ARPA network protocols. ESnet was just starting up. They were looking at a variety of possible protocols, among them the ARPA network protocols. They felt the ARPA network protocols wouldn't perform adequately for them. We pointed out to them that there were already implementations of the ARPA network protocols on all the computers they needed to use. Also that the protocols could get all the performance available in the lines at that time. These protocols were pre-TCP, but they were still pretty general communication protocols. There was quite a lot of flexibility in tuning those protocols, very much like with TCP/IP today. Since those implementations were already available, we suggested that they use them and tune them if necessary. Instead, they decided to go with a very early version of what eventually became DECNet. I looked at the documentation for that first try at DECNet. It looked like a dream to me. It seemed very incomplete.

GAM: So it was "vaporware."

JED: Exactly, vaporware. They had implementations in pieces, but it just didn't hang together. Despite our suggestions to the contrary, the NERSC folks decided to go with that early DECNet as their protocol. As I recall, DEC eventually got their act together and essentially completely rewrote DECNet. ESNet ended up with their own version of the old DECNet protocol implementation that they tried to fix up. They ended up supporting their own thing for a number of years. I believe that if they had gone with the ARPA network protocols and transitioned to TCP/IP as the rest of the ARPA network did in the early 1980s (when it transitioned to the Internet) they would have been a lot better off. I got into quite an argument with Jim Leighton about this. I remember sitting around a table debating with him and Dieter Fuss and some others (Barry Howard?) for the better part of an afternoon. Jim Leighton and I weren't very good friends after that, and I haven't talked to him too much since. I just thought he wanted to build an empire and wasn't interested in doing the technology right. He did build an empire. I give him credit for that.

So, what else?

GAM: Well, I could jog you this way. There was a point when you were actually in the act of breaking into an MIT computer and caused some trouble back at MIT.

JED: Oh, that was actually a Bolt Beranek and Newman (BBN) computer. BBN was the organization who developed the IMPs, the routing hardware/software for the ARPA network. They later became famous for their analysis of the Watergate tapes. This event ties back into the exerciser program I described earlier. One of the people in the RISOS group was Steve Lai. He was trying to use the exerciser auditing approach to audit some code in the BBN "Tenex" system. One day he came into my office and said, "Okay Donnelley, look at this code. This code is so simple it's ridiculous trying to go through all of this formal procedure to analyze it." The code was a system call that you could pass a mask to and it would test a bunch of system flags against the mask. It did a logical "and" between the mask and the system flags and, if the result was nonzero, it would skip the next instruction. That next instruction would typically be a branch instruction that would transit to a part of the code that did whatever was needed if one of those flags was set. Steve said that this particular code was just so simple that I couldn't possibly think we should go through this whole formal procedure with it. I agreed that it was a really simple code, but I thought we ought to follow the procedure through. I asked him to start looking carefully at the code with me. There were some conditional instructions in there. I started going through it with him until we had followed it all the way to the return sequence. What we saw there was the code performing a logical "and" of the system flags and the mask, and incremented the return word if the result was nonzero. The final instruction was the return instruction itself. I looked and looked at that last instruction and thought, "My gosh! There are some interesting possible values for that return word."

To understand what was interesting about it, you have to know that, on this particular computer system, a PDP-10 system with a 36 bit word, such a return word consisted of two halves. The left half of the return word contained some system flags (including, importantly, the monitor mode or "system" flag) followed by an index register field. The right half of the word contained the address that the system call had originally been made from plus one (i.e. the nominal return location). What got my attention was considering the possibility that all the bits in the right half of the word were ones. In that case, if the flag mask returned nonzero, then incrementing the return word would overflow into the index field. The way a nonzero value was interpreted in the index field was to add whatever was in the designated index register with the return word, the whole thing. So, what was in index register number 1? The answer was that the user code could put anything there. In particular, it could be set to turn on the monitor mode bit and return anywhere in the user's code. I had discovered a huge glaring hole in the Tenex operating system (what would now be called a local root exploit) just by the simple exercise of going step by step through the exerciser procedure. Back then such exploits were nearly unknown.

At that point, we got pretty excited and decided to check further into this problem. There was actually some additional code involved that we hadn't analyzed completely. We didn't know for sure that some of that additional code might be able to set things right before the actual return happened, but we didn't expect that it would. I decided to test this possible flaw by writing a small test code that would go into monitor mode, test something that could only be tested in monitor mode, and then return to user mode.

Unfortunately, it turned out that there was a minor typo in my test program. Because of the typo, instead of testing the flaw as I intended, the test program ended up crashing the system. Coming from a hacker background, I had crashed systems before, but I certainly hadn't intended to do so in this case. These systems would crash occasionally anyway, so I didn't know that my test program was the cause, but it certainly was suspicious. I eventually realized the mistake that I had made and corrected the test program. It also happened that the system programmers for the Tenex system at BBN were quite sharp. They had figured out what I had done and patched in a work-around that same afternoon. I eventually ran my corrected test code on another system and was able to verify the flaw. Two or three weeks later the Tenex system programmers figured out how to properly fix the problem, and they distributed the fix to other systems. But in the meantime, they were angry.

I really didn't understand their anger. Yes, BBN was running a production computer center. Still, their systems already crashed some two or three or more times a week. Of course, another crash was an inconvenience, but we were supposed to be doing such dangerous system testing. When it was us instead of them crashing their system, I think their pride was hurt and they got upset. At that point, a big flap started happening about whether we should be doing our testing during the day or should we have our own system to run such tests on, etc. We had, of course, asked for dedicated system time previously and been refused, it was too expensive. The decision that was originally made (when they were confident we wouldn't find holes in their system) was that we should go ahead and do our testing at our convenience. Now when we found a serious bug they wanted to restrict our testing time.

That actually ties into another amusing anecdote. This was all happening during the early days of the ARPA network and the early days of email. Most of our interactions were via email. We regularly exchanged email with ARPA folks like Steve Crocker and Larry Roberts. As I recall Steve Crocker was our contract officer. We also corresponded via email often with the people from Bolt Beranek & Newman, I can't seem to remember their names now (Ray Tomlinson, by most credited with the invention of e-mail, was one of them. I remember also interacting with Bob Thomas and Dave Walden.) but I'll bet I could find them from some of that old e-mail. I tend to keep such things. Anyway, while all these email exchanges were taking place, I was scheduled to take a trip back to Washington, D.C. and then down to visit my Aunts who lived in Florida at the time. I didn't want to get disconnected from the discussion while on vacation because I was defending myself. I was also defending the RISOS project and I didn't want us to have to jump through all sorts of hoops to keep doing our work.

I decided I should try to keep in touch with the discussions while on travel and during my vacation. At that time there were a few computers scattered around the country called TIPS or Terminal Interface Message Processors. These TIPS allowed one to dial in by telephone and get connected to the ARPA network. They acted much like dial-up Internet Service Providers do today. There was a TIP in Washington, D.C., so I could stay connected there. However, the only TIP in Florida was a long distance call from where I was going to be on my vacation. I was afraid I would be out of contact while I was visiting my aunts.

After thinking about this problem for a while, what I decided to do was to write a program that would dial out from our RATS computer system (with that outward-going WATTS line) and allow whoever it called to get connected to the system. Writing this software was a hurry-up affair because I was about to leave for Washington, D.C. What I wrote was a program for the PDP-11 that would allow me to input a time and a telephone number and it would call the telephone number at the specified time. Once the call was made, there was some handshaking of the modems required that is probably too detailed to get into. I think it's worth mentioning that back then we had these big TI (Texas Instruments) Silent 700 terminals which you could hardly pick up. Also, since the computer was going to call me, I had to have a different "answer" modem, another two or three pound wooden box.

GAM: Answer-backs as opposed to originates.

JED: Right. So, in addition to this heavy and unwieldy terminal, I had to lug around this answer-type modem. I had to work for quite a long time on that software. Since I was going to leave on Sunday and I had plans for Saturday (I was going to go windsurfing - something that was also just starting in those days) I felt I needed to get the software finished Friday night. I worked on it until about 3 A.M. Saturday morning when I finally thought I had it ready. I knew I was going to have a difficult time waking up to go windsurfing at 9:30 A.M. I thought it would be clever to have the computer call me to wake me up. This would both test my program and probably startle me enough to actually wake me up. My alarm went off that morning but didn't really wake me up, I went right back to sleep. Then, sure enough the computer called. It called right on schedule at 09:00. I picked up the telephone and there was no sound from the other end. Not even a modem whistle. In those days, I had developed my own whistle to the point that I could get a computer to think I was starting a handshake. I thought I would try that in this case to verify that it was the computer that was calling me.

GAM: Jed, the blue box.

JED: Well no, that's actually another story.

GAM: We'll get to it.

JED: So, anyway, after I had verified that it was indeed the computer on the other end, I hung up the phone and immediately started going back to sleep. Well, about thirty seconds later, the phone rang again. I again picked up the phone. It was the computer again. I had only instructed the program to call me once. Why was it calling me back? I hung up the phone again. It rang again. At that point I began to realize that I was in trouble. My telephone was basically out of order. I had to take the receiver off the hook. My program had gone into an "infinite" telephone-dialing loop. Instead of popping, I had pushed. I had pushed that same number back onto the stack of calls so it was just calling again and again. It took about 3 or 4 hours before that program overflowed its memory segment and crashed. Only then could I use my telephone again. I did go off windsurfing. I was just learning back then in 1974. Later on, I found the bug and corrected the program. That was one of a couple of incidents that got me to be a little leery of mixing computers and telephones.

It turned out that the corrected program actually did work when I was in Florida. My Aunt and my cousin were very impressed. I used the TIP in Washington D.C. to set up the first call to my Aunt's home in Florida. When I was in Panama City I told my Aunt that at 7:30 the computer was going to call. Of course she had no idea what I was talking about. I got everything all set up and sat waiting by the telephone as it got close to 7:30. Right on the dot at 7:30, the phone rang. I started the TI Silent 700 terminal and the modem and got connected to our RATS system. I was able to get and send email (to defend RISOS some more). I also demonstrated an early Star Wars computer game for my cousin. He remembers that experience to this day. After Panama City, I was going to Miami to visit another Aunt. While on the line in Panama City I set things up for a later call to Miami where my other aunt lived. Things worked there also. That operation went better than I expected.

GAM: That's neat.

JED: With the low price of long distance telephone calls today, it might seem kind of silly but, in those days, the cost of such calls was significant.

Fast Eddy: You mentioned blue boxes. It made me think of another guy in the RISOS group. His name is Onnig Minasian. In fact, I would like to know what happened to that guy. He was a fascinating character. We called him "Fast Eddy" because he was a real fast talker.

GAM: I remember him. I don't know what happened to him.

JED: I heard that he went off and taught in a girls' college in the north east. When I first met and talked with Onnig I never knew whether to believe him or not. I always thought he was full of baloney. He went on and on about fancy technical stuff, initially with nothing he could show me about it. For example, he talked to me about system blackjack. I didn't really know anything about it at the time. I had this belief, kind of like people do in the stock market, that if there was a way to beat gambling then everybody would do it and the casinos would figure out what was going on and defend against it. So I didn't believe him. He also talked about blue boxes and black boxes. He said he had this digital design which, back then, was state of the art. He also did some work on a digital circuit that could beat roulette. There is a book that came out about that work, "The Eudaemonic Pie" by Thomas Bass. I think you have read that.

GAM: Yes I have.

JED: Well, as I recall, Minasian said he was doing his work in electrical engineering at UC Berkeley. Perhaps he just said "UC" and I assumed Berkeley. Anyway, he told a story that was nearly identical to the one in The Eudaemonic Pie, about the roulette wheel and how they beat it except that the story differed in very subtle details which I think I remember precisely. I can't believe there were two groups doing the same thing. But he talked about using an electronic device that they'd built. They wore it on their hip and they had buttons in their shoes. But, in Minasian's device, there was a little electronic probe under their arm that gave them an electronic jolt every time the spot on the wheel went by where the device was predicting the ball would land closest to. Well, I could go into that more later if it seems appropriate. I just thought the differences in the stories somewhat odd.

Let me tell you the blue box story. Minasian claimed he had developed a digital blue box (in addition to the roulette device). I never really believed him. One time we were on a trip back to Boston to visit Bolt Beranek and Newman to talk about the ARPA network in the early days of the ARPA net (~1974). We rented a car. Of course, since Minasian was kind of a pushy guy, he was driving the car. He was driving crazily, sometimes going the wrong way on one-way streets. We decided we would go visit MIT. We were there the day before the conference at BBN so we had some time to look around. I had never been to MIT before. We went in, looked around, saw the school and all sorts of other great computer stuff (another story). It was then time to coordinate and make sure we knew the directions, the room, and everything we needed for the meeting the next day. We looked around and found a pay telephone to call BBN. Minasian picked up the phone and dialed, but it turned out he dialed the wrong number. I was standing there next to him and watching as he started talking to some unknown person at the other end. He is one of those really loquacious talk-to-anybody kind of guys. I was standing there thinking he should hang up and make the call we needed to get the information for the meeting the next day. Instead he goes on and on talking to somebody at the other end of a wrong number. It turned out that guy at the other end was a phone freak. I was only hearing one part of the conversation but, even with just that, I could tell that these guys were chatting to raise each other's level of confidence that they were actually talking with a fellow phone freak. One would reveal a secret and then the other would reveal a somewhat deeper secret, etc. They keep going back and forth about how much they knew about blue boxes. Finally I kind of got interested and thought I'd like to really see what's going on with this guy at the other end. I don't actually recall if we ended up calling the people at BBN or not. The interesting thing is what happened after the telephone call with the phone freak.

The guy at the other end of the wrong number eventually invited us over to his flat. We got back in the rented car and went over to his place. He had a split-level flat that ran three floors up the side of a hill that he shared with a number of other guys. We went into this flat and these guys were all phone freaks. I have no idea where it was. I didn't know Boston back then. When we went into the flat I was just sort of tagging along. Minasian was the thief in our party. They just sort of let me come along for the ride. These guys started bringing out their telephones and their blue boxes and their black boxes and all. They had these six, eight, and sixteen button phones and just about any kind of telephone equipment you can imagine. One guy referred to his early model blue box as "Old Bess". "On a cold night you have to hold her under your arm when you're in the phone booth to warm her up to get the tones just right". Minasian was the big hero because he had a digital blue box. While there, he started talking about it enough and describing enough that I started believing him. Minasian had been kind of hush, hush when talking with me previously, but with these fellow phone freaks he really opened up and described, in much more detail, all the things he had done with the telephone system. Then they started hacking the phone system and putting their blue boxes to work. They were able to call the "time of the day" in Beirut. They also called the "song of the day" in London. Then they were trying to do some technical international loop thing. I didn't really understand it. They were trying to call Kentucky via Europe. Somebody had a relative or family or something in Kentucky. Minasian said he knew how to set up this call. They worked and worked on it but, in the end, were never able to make the connection.

After that experience I realized that there was a little more to Minasian than I had thought. When we came back to Livermore, he showed me the schematic diagram for the blue box chip that they had done. This thing was small enough that you could swallow it. That was the idea. You could go into the phone booth and be using this blue box. If the police came and you were facing some trouble, you could swallow it.

After that, I also started believing Minansian's talk about system blackjack. I investigated it more, and found out that, sure enough, you actually can win at casino blackjack. I learned how to count cards and I went up and made some money at the casinos. You do have to watch out not to be cheated. Most people won't go to the trouble to learn to count. Initially, when the casinos learned that they could be beaten, they change the rules. However, the initial rule changes actually ended up decreasing their income because so many people stayed away. They then changed the rules almost back to where they were originally - allowing card counters to again win as long as they weren't detected. I went up many weekends and, while I went up and down many times, I never came out behind after a whole weekend.

I haven't played much recently, but I believe you can still win at the honest blackjack games by counting cards. It turns out that there are cheating dealers. They call them "mechanics". There are probably about ten percent mechanics at the casinos. If you run into a mechanic, you need to recognize it quickly and get out of the game. Otherwise, they can eat up all your winnings. I'm quite sure I was cheated many times. Sometimes, I would lower my bet size and just keep playing and playing with a dealer I was quite sure was a mechanic, because I was intrigued to see how they did it. I only actually caught them cheating me twice. It was interesting to watch them at it, but all I could do was to watch and eventually leave the table. Calling attention to their cheating would do no good as they would, of course, deny it. That would draw unwanted attention to me and not otherwise help.

GAM: Well, you know Charlie Weatherell was involved in this study. He was using the Sigma 7. I think he ran out a million games to develop the statistics he wanted.

JED: Weatherell, John Beatty and Kelly Booth were all working on that software. Those were a lot of fun guys. I was a little bit separate from them in my work at the Lab. What was their system? The "Spade" system, and the old "SEX" system back at UCLA on the Sigma 7? That was one of the systems on the early ARPA Net, so I knew a little bit about it. I went over and watched those guys do their graphics and magic sometimes on the Sigma 7 at the Lab. I seem to recall that Sara Bly also worked some with them in those days.

GAM: Did you save any of the old manuals or anything like that? We can separate you from those and save them in a museum archive.

JED: You know, I think I might. I am pretty sure I kept the "SEX" manual, just for fun.

GAM: Those would be very interesting to have. I have the first ARPA manual that described the ARPA Net.

JED: I have a number of those early manuals. I'm pretty sure I have one of the SEX manuals from the Sigma 7 System at UCLA. I also believe I still have an old BBN Report #1822 that describes the interface between the IMP and a host on the early ARPA network. They used quite an interesting "Here's your bit, got your bit," type of protocol. I was partly inspired by that protocol in my later design of a dataflow computer.

GAM: When RISOS died at the Lab, you stayed. Where did you go?

JED: Hmmm. I am not sure "die" is the right way to describe the end of the RISOS project. RISOS was supposed to be a two-year project. It went on for three years. It started winding down in 1975 after the final reports were written. I was excited about the systems we had developed. About that time, I came up with a mechanism for distributing access to the sorts of abstract "capability" resources we had in the RATS system across a network. I wrote up an internal paper on that mechanism [1]. I still think it's a pretty clever technique. It was later used commercially by Mach which eventually served as part of the underlying ideas for the Windows NT System and, more recently, has been incorporated into Apple's OS X. I haven't seen that mechanism used in modern systems. I think the reason is that the application interface to today's systems are Unix or Unix-like. Unix doesn't support any sort of abstract object. Unix uses a "user" based protection model. Under Unix when you run a program the program gets all the rights of the user running it. In a capability system a running program gets only the rights specifically granted to it as capabilities. Under Unix it wouldn't make much sense to share access to individual resources across the network, but in a capability based system such a mechanism was quite natural.

The idea in that mechanism was that, in a capability-based operating system, you had an abstract-object notion. These objects were protected by the operating system. They could be files, or directories, or terminals, or telephones, or whatever. We exploited this in our system, but it was actually a generic thing. The operating system supported this abstract notion of "capability" and allowed anybody to write server software to support whatever new kind of capability they wanted. I got very excited by this and discovered a technique to extend the abstract-object notion out into the network. Actually, I remember the night when it occurred to me how to do it. It was around eleven or twelve at night, and I was nearly asleep. It just dawned on me how to do it. I woke up and spent the whole night and morning writing it down. I came into work the next day having had absolutely no sleep. My girl friend at the time thought I was a bit crazy.

The essence of the mechanism was that you would have a server on the network that would serve generic "objects." If you wanted to share a resource, one of these objects, you would put the object on the list. Somebody out on the network can't directly access the object. They can just send bits across the wire. But I designed a protocol where they could send bits across the wire and say, "I want to access your object number so-and-so and here is my right to do so". The request would come with access permissions sort of like a password. Then, on behalf of that request, the server and would go off and execute the request that was made on this thing and return the results back through the network. The key thing that really got me excited about this was that the server did not have to have any idea what the thing was. It was just an abstract "resource". It could be a telephone, a graphics entity, a file, a process, or whatever else. It had this notion that you could extend the concept of a protected computing resource through the network. I developed a system for doing such network sharing of abstract resources that I included in the second paper I wrote on this topic, published in the Proceedings of the Third International Conference on Computer Communication (ICCC-3) [2]. It turned out that while I did work on this mechanism for a while, we never did implement it in the RATS system. The RATS system had a minor technocal feature of its file access mechanism that would have had to be modified to get this mechanism to work. The RISOS project was winding down and at about that time I got involved with Victor Hempel. He needed some networking help on some database work he was doing. Later I did use a related mechanism to share resources in the NLTSS system [3].

The work Victor Hempel was doing and that I next got involved with was work for The Department of Transportation (DOT). The DOT had databases all over the place. One typically had to dial into them. They each used a different access protocol. The DOT wanted a more uniform way of accessing their databases. This is something that eventually got commercialized at the LLNL. CDC picked it up. I convinced Victor Hempel that this technique that I was using for distributing capabilities could be useful in that. It was probably a bit of a stretch, but he bought into it, and I got support doing some work on it. Back then with "reimbursable" (not Lab/DOE funded) contracts, it was very different than it is now where people are going out to get money almost anyway they can. Back then the Lab was very restrictive about what sort of money they would accept. There had to be a significant research component. If you did some work, and you got so much money, you had to put 30-40% away into some internal research project. The Department of Transportation bought into this policy and we started developing. Initially, I called it a Transaction Controller. The name changed after I left the work, but I forget what the later name was. We started working on the software. I was able to continue working working on our PDP/11 RATS system where we had telephone dialers and access to the ARPA Network, Timenet and some other networks that we could use for the communications the DOT project needed for database access.

This gets into another sort of interesting anecdote in a different direction. There was a guy on this project back then by the name of Szilard Zabo. He had a Ph.D. Such a formal degree was very important to Victor Hempel in his efforts to get funding and recognition. Victor wanted his project to be doubling every year. Having people with status helped. Dr. Zabo was interested in language issues and databases. He sort of took me under his wing when I was casting about for work after RISOS. He was already established with his Ph.D., working on a project and impressing Victor Hampel. I was a networking expert and Zabo needed networking expertise, so he took me in and, for a while, I was his fair-haired boy. I could do no wrong. I was always a little uncomfortable with this relationship. He talked so much about his Ph.D. and training and such status things that I felt he was talking down to me, not seeing the relevance of such things to the work we needed to do. However, Dr. Zabo got me into the project and got me working on it. One aspect of the work was that it was Dr. Zabo's research work that was getting the internal research component of the funding. He had something that was called "Mathematics and English" that he was doing. This was back when Master Control was the early database system at LLNL. They were putting an English front-end on the Master Control database system. Zabo was working on this project that I knew nothing about - which was fine with me at the time. Another guy working in this area was my old apartment mate, Ed Birss. Ed later went to Apple Computer and rose high up in the management chain there. Ed eventually became the chief technical officer at Taligent (the joint IBM/Apple software development company). I haven't talked to him recently. He was also in the database area and working with Dr. Zabo.

The work funded by DOT ended up being separated into the more purely database work that Dr. Zabo and others were working on and the communications work that I ending up working on by myself. Dr. Zabo kept wanting more and more resources, far beyond the 30% or so stipulated by the policy at the time. Ultimately it got to the point that I was the only one doing any of the communications software which we were supposed to deliver to the Department of Transportation. There were four or five people being funded on the project, but I was the only one working on the deliverable. When I realized I wasn't going to be able to finish the needed communications software adequately I went to Victor Hempel and explained the situation. I needed some help. I was trying to get Jeff Yeh, who was also in that group, to help me with the communications side of things. After I made that request I wasn't Zabo's favorite boy anymore because I was starting to take his resources. He got really upset. That was my first experience with somebody that truly "lost it", got so angry that they completely lost control. We were having a meeting where we were getting ready for a trip to the Department of Transportation, Ed Burss was there, Jeff Yeh was there, Szilard Zabo was there, but early in the meeting Victor Hempel wasn't there. I told Dr. Zabo that I thought we needed to have more people working on the DOT deliverable. He just wouldn't have it and was very angry. I had talked to Mr. Hempel earlier about this. Victor was trying to soft-pedal and make things work and collaborate. But finally it was clear that there was a fundamental disagreement and we needed an "executive" decision.

We went out and found Mr. Hempel and brought him in. Victor said yes, we need to apply the additional resources so Jeff Yeh was going to have to work on the communications software and not on Dr. Zabo's "Mathematics and English" work. At that point Dr. Zabo almost literally "hit the roof." He was red, screaming, bouncing off the walls figuratively. It became clear that it wasn't possible to talk with him and we couldn't take him back on this trip to the Department of Transportation. Finally, we (mostly Victor Hampel) just had to tell him that he wasn't going to go. In my opinion at that point Dr. Zabo changed modes. He must have decided that he could no longer work in that group and perhaps at LLNL, because he went out on a vendeta to discredit people. He started going around collecting dirt on all the people in the center. Of course one person he tried to discredit as effectively as possible was Victor Hampel. However, he didn't stop there. He also went after Sid Fernbach. This was about the time of the transition from Sid Fernbach to Bob Lee as head of the Livermore Computer Center. It seemed that Dr. Zabo was on a mission to gather as much damaging information as he could. He tried to get documentation that discredited Sid Fernbach's work in purchasing the Star computer from Control Data. He also gathered whatever he could that was negative about Victor Hempel. I remember when Bob Lee learned of his campaign/search he got really upset. Zabo was running around to all the Xerox machines copying things. Bob Lee pulled his badge. It went down hill from there. Eventually things ended in litigation. At some point I was pulled into the process to testify. What a mess. Anyway, I worked in that area for a couple of years on that Department of Transportation project.

At that time I was doing more work on computer networks. That was about the time Dick Watson came to LLNL, the late 1970s. With Dick's support I started a project called the Local Network Research Project. That was about the time people in the Livermore Computer Center were starting to think that some of the new networking hardware that was becoming available commercially might satisfy some of their high speed local networking needs. Prior to that time all the networking hardware had been build in house. What I focused on in the Local Network Research Project was simulating in great detail the workings of the first high speed LAN product, the "Hyperchannel" product from Network Systems Corporation (NSC). That work was really fascinating to me. I really enjoyed it. I'm a person who really likes completeness. It was very satisfying to me to do a simulation that followed the leading edges of the electronic wave as it spread out on the wire in both directions. The code knew when these packets on the wire ran into each other. One of the interesting things that I didn't know, early on, was what happens when two packets run into each other. Can they pass each other and still be identifiable? It turns out they can-the medium is linear enough. I got mixed signals from the engineers on this. Finally, I got the correct physics and I put that in my simulation. It turned out to be significant for a Hyperchannel network cable that is long enough. The way Hyperchannel worked is they would send little packets to negotiate the sending of a bigger packet. The idea is that if two nodes happened to both send such little packets at the same time, those little packets would collide and the hardware would go into a "retransmission" mode. After the retransmission logic completed one of the original senders would be selected to be first to get their data sent on the network. It turned out that with a long network (shared "Ethernet"-like cable) and the right set of nodes two nodes could both transmit their little packets, succeed, both get their replies, and then collide on the big packet. That unexpected result (verified with the actual hardware) didn't turn out to have any serious practical consequences (most network cables were too short), but it was interesting to see how things actually worked.

Some of the work that we did in the Hyperchannel simulation did have quite practical consequences. We showed that they had some serious problems with the firmware dealing with contention resolution. NSC used a priority scheme in Hyperchannel that worked very nicely at the lowest level. At the media-access level they would prioritize the nodes by adjusting timers in the node hardware. Using this mechanism if the network got loaded the higher priority nodes were allowed to transmit before the lower priority nodes. At a higher level Hyperchannel had mechanisms to transmit actual data frames that would make use of that lower level priority mechanism. It turned out that the higher level protocol ended up having just the opposite effect of what they wanted to do. I wrote a paper with Jeff Yeh describing this effect that I called "Priority Reversal." What would happen is that the higher priority nodes would indeed get higher priority in using the contention protocol to get the line. Consequently they would be able to get more contention protocol packets on the line and when a retry count (256) was exhausted, they would give up first - allowing the lower priority noted to actually transmit their large data packets first.

In the early appications of Hyperchannel the load was not so high that they got into the sort of contention described in our paper. They did read our paper and used some of the ideas in it to improve their firmware. Later on, when they loaded their network, they had better performance as a result of those changes.

The experience of interacting with the manufacturer and writing this paper was very interesting for me politically. I learned a lot about manufacturers from the experience. We had a relationship with Network Systems Corporation where we depended on them to get detailed information about their hardware. We simulated the hardware and the simulation proved useful to them. On the other hand, they would rather not have some of the information about weaknesses in their hardware and firmware published. We were required to publish the findings from our simulation work. For a time there was some tension between NSC and our research project about this.

GAM: Well, I think that's probably only with the administrative people. The guys in the technical area like to know how you can jam up their thing and, then, they can fix it.

JED: True. However, it is the managerial people who have to allow us to talk to the technical people, so it did get a bit awkward.

It was during about that same time frame (late 1970s) that I finally did some work on a concept I had for a dataflow computer that I called IMPACT - Integrated Machine for Processing Asynchronous Cellular Transactions. I got the initial idea from a visit (in about 1975) from Jack Dennis (from MIT, famous for his "packet" architecture computer designs like the "Dennis-Misunas" machine). When Dr. Dennis described his packet architecture I thought there was a much simpler/better way to architect such a dataflow machine. I'm still really excited about this architecture and would like to do more work on it. At that time I simulated it and showed how fast it could execute simple parallel programs. Unfortunately with an architecture so different from traditional "Von Neumann" machines there is a problem finding software for it. Any such software has to be written from scratch. I never really got any formal support from LLNL to work on this architecture. While I did have some discretionary time that I could use for such work, I found that despite my strong belief in the architecture I didn't enjoy working on it by myself and quickly stopped such work.

I'm convinced from that and related work that there are basically two types of algorithms. One type is fundamentally serial. These are algorithms for accounting, compiling, GUI interfaces, etc. There is lots of stuff that is very useful in that category. Sometimes they can use a little bit of parallelism, but they are essentially serial algorithms.

There is another set of algorithms that are fundamentally parallel. Algorithms for physical simulation like that for a gas, for example. The physics of gas molecules are local. That makes such an algorithm, in principle, massively parallel. I believe that the "Von Neuman", one instruction at a time sorts of architectures aren't suitable to that second category. You can make them work. You can even get some parallelism into them with extraordinary work. However, the architecture just isn't suited to parallel programming.

I did some work simulating a human-like brain on the early Burroughs 5500 and 6500 computers and a little bit on the Lab's computers. There I was simulating a massively parallel thing (a brain) with something that is essentially serial. You can divide such a problem up into multiple serial paths but it really doesn't doesn't work effectively. You need a paradigm shift. I'm still waiting for that paradigm shift to happen. I don't know if I'm going to live to see it.

GAM: I don't know. You might want to get re-involved in the thing. There are some indications that people are starting to look around.

JED: I'm also encouraged. One of the things that my architecture really required was asynchronous logic.

GAM: I think you ought to go and talk to John Theo about it. It's strongly possible that you can find some grant money to do some more software development or perhaps build a piece of hardware to allow it to be tested.

JED: Well, it's something that I occasionally revisit over the years. At one point in 1985 I even tried to start a company to build such a machine. I finally realized that it would take too much money up front (~$20M) and it didn't make sense as a business. There is a write-up about this architecture from that era that I have made available on the Web if anybody is interested in it [3].

GAM: As we age I remember the Jed of the unicycle and walking up and down stairs on his hands. How is that Jed doing?

JED: Well, I still walk on my hands. One of the challenges in the new house we have in Berkeley is to walk down the stairs on my hands. I also still ride unicycles. That reminds me of another anecdote; I don't know how many of these anecdotes you want. Bob Judd remembers this. I had two challenges at the Lab. One of them is related to handstand walking and the other is related to the unicycle.

The handstand-walk challenge was to start from the second floor where my office was in Building 113, walk down the stairs on my hands, walk into the elevator, ride the elevator up and then complete the loop, still on my hands. I really like loops. That's one of the things I really like about your house, it's got a loop here. I look for that in houses. If you have a loop, you can always keep running away and never get caught in a corner. When we remodeled our house in Berkeley we put several cycles in it, including looping through two stair cases. At LLNL a handstand-walk making such a loop down the stairs and up the elevator was one of my challenges. The time that I got furthest with it (good enough for government work) I had Bob Judd helping me. I started out on the second floor by the door to the stair. I was able to walk all the way down the stairs on my hands. Bob opened the door at the bottom of the stairs and I walked over to the elevator. Bob again had to help me open the elevator doors because I couldn't find the button to push while standing on my hands. I walked into the elevator (still on my hands) and rode it back up to the second floor. That was very difficult because by that time the blood circulation was not very good in my arms and head. Also I was very tired and the elevator created additional Gs. I was able to stand on my hands all that time, but when Bob Judd opened the elevator doors I only managed a step or two and I collapsed in the elevator doorway. That last few feet from the doors to close the loop was too much for me. It wasn't often I was able to get people to help me with such challenges. Partly this was a matter of scheduling, but I also think some people were rightly concerned that such activities might be frowned upon by Lab management - likely for safety reasons. Fortunately I never got hurt doing anyting like that. I decided that getting back up to the second floor was good enough and I didn't try again. (edited note added later - As I recall that handstand loop walk down the stairs in Building 113 with Bob Judd happened some time in 1978. Another challenge that I set for myself at that time was to walk down the aisle to get my 30 year pin in the Building 111 auditorium. Unfortunately by the time I got my 30 year pin I was working at the Lawrence Berkeley Lab, but I did manage that hand stand walk down the aisle as in the middle image at the right top of this page).

My other challenge was on a unicycle. I've had a unicycle since my college days. I even juggle on it. I rode my unicycle into work for a while. It's not really all that practical. I found that I would sweat even more than on a bicycle and that it takes about as long as walking. It has the worst of both worlds. Still, I had a challenge in that area. What I wanted to do was to ride my unicycle all the way from the Rhonewood Apartments (where I lived at the time) up to my office on the second floor of building 113, without touching anything. I had to have the guard touch my badge but, beyond that, I didn't want to touch anything. This is another challenge that was almost made, but not quite. Several times I was able to get from my apartment all the way into work, past the guard and inside the elevator door (sometimes I had someone open the door for me, but if there was nobody there I pushed the button myself) on my unicycle. However, I was never able to do the ride in from work and on the same trip ride the elevator up to the second floor and to my office. At different times I was able to ride the elevator up to the second floor on the unicycle. That's the really challenging part. The challenge with the elevator is to ride the unicycle into the elevator so as not to bump the elevator walls. On a unicycle, to stay balanced, you have to keep rocking back and forth. The elevator had barely enough room for an adequate rock so I had to make sure I was positioned properly in the center of the elevator and didn't bump the walls. Many times I managed to ride the elevator up to the second floor and to ride out of the elevator door and to my office. However, I never did manage to get all the way in from my apartment (which I only did 8 or 10 times) and at the same time ride the elevator up to my office without bumping the elevator walls. For me it was a worthy challenge. Nobody seemed to mind my trying it now and then. With that effort there really wasn't a safety issue. The guards seemed to get a kick out of my coming in on my unicycle and few other people noticed.

There is also a moderately related wheelchair anecdote (when you get me started talking about things like this I'll keep going until you stop me). This is a real brief one, but it interested me. There was a guy on a wheelchair at the Department of Applied Science, Andy Porter. At some point we happened to both be waiting for a lecture or something out there. I noticed that he was quite good at rocking his wheelchair up on two wheels (off the small wheels in the front) and riding around that way, balancing on just the two main wheels. This impressed me and I thought I would like to try it. I asked him if he would let me try it. He said "okay" and a couple of us helped him out of the chair so I could give it a try. We were both somewhat surprised at how easily I learned to ride it around on two wheels. Gradually I realized that the motion and control that are needed with the wheelchair are essentially the same forward and backward motion and control that is needed on a unicycle - except of course with hands rather than feet/leg control. On the wheelchair you are rocking back and forth to stay balanced just as on a unicycle. Ultimately, I came up with this equation: Wheelchair plus bicycle equals unicycle. What that means is that to learn to ride a unicycle, there are two skills you have to learn: One skill is the back and forth motion identical to the balancing motion on the wheelchair. The other skill is a right/left balancing which is like that used to balance a bicycle. The same thing happens on a unicycle when you are going forward. Those two balancing skills (forward/backward coupled with right/left) are what is needed to ride a unicycle. It would be interesting to take someone who knows how to ride a bicycle, teach them how to ride a wheelchair, and then see how they do on a unicycle. Unfortunately I don't know too many people that start out in wheelchairs and then learn to ride unicycles.

GAM: That's quite true. Do you remember the arguments we all use to have with Bob Crallee? You use to have these theories about eugenics and things of this sort that he would like to attack.

JED: Bob and I did have many heated debates. I have a number of pretty radical ideas. For example, I believe it isn't necessary (or necessarily ethical in the case of humans) for eucaryotes (multicellular animals like us) to age beyond adulthood and then die from aging effects. In my view, while death by aging is a useful "discovery" of evolution, it is one that's no longer needed in a world where the primary human evolution is social, not biological. An amazing aspect of eucaryotic animals is that as they grow they produce different proteins at different stages of their lives. For example, there are some four different kinds of hemoglobin that are made during the life of a human. One is fetal hemoglobin, one is infant hemoglobin, one juvinile hemoglobin, and one is adult hemoglobin. It seems necessary that some sort of clock must tell humans (animals) when to produce which type of hemoglobin. In my view that clock just kind of runs off the end of its program when continuing to live no longer helps reproduction (i.e. biological evolution). You get to the end of the program for development and that's when the animal dies. There is a theory of aging that suggests it's actually the physical running out of the telomeres at the ends of the cromosomes due to repeated replications (each of which shortens the telomeres) that ultimately stops the "clock." I see no particular reason why such a clock (whatever its mechanism) couldn't keep going or loop back or become constant at the end. No reason except there is nothing in evolution to select for it. In fact, just the opposite. In some ways evolution selects for animals to die because then it can evolve new animals that can respond better to variations in their environment.

GAM: If the animal doesn't die you don't need new animals. The point is there are good reasons why animals die or why anybody dies. It's unavoidable. We'll argue that another time.

JED: I disagree that it's unavoidable or even inevitable but agree that we can debate that another time. That was one point of contention I had with Bob Crallee. As I recall another was my brain model. I believe it's possible to make machines that think like humans do. Human beings and animals are machines of a sort. Biological machines. I believe that you can make other machines that think, fundamentally, like people do and think better, ultimately.

GAM: For some restrictive cases, I think that is true.

JED: I believe it's true in the general case.

GAM: We don't have any examples of that.

JED: True, not yet. There was a report written in the middle 1970s by a British physicist named Lighthill that related to this topic. The Lighthill Report really upset the artificial intelligence community. What Dr. Lighthill said in that report was that artificial intelligence, the way it is practiced by most of the computer people, is something fundamentally different from what goes on in brains. He said there are brains, the way human beings and animals and things like that think, and there are computers. Computers can be programmed to do some very interesting things, but they can't be programmed to think like brains do. Dr. Lighthill suggested that it was possible to do two distinct sorts of research in this area. One sort of research is to investigate natural intelligence, the way humans and animals think and perhaps develop technology that can allow that sort of thinking to be done artificially. That would be something that he would call "artificial intelligence" - distinct from what computers can be programmed to do that is currently referred to by the term artificial intelligence.

The other type of research one can do is on what are often called "expert systems", computer programs that are written to be smart about some things. This type of programming (e.g. as with the Eliza program that tried to mimic a psychologist) can do very interesting and sometimes useful things, but Dr. Lighthill wrote (and I believe) that this is very different from how people and animals think. That isn't to say that a powerful enough computer couldn't simulate or effect the operation of a brain, but that the current work on artificial intelligence for computers is very different, both qualitatively and quantitatively, from the little work that is happening on brain function.

GAM: There is certainly some evidence to that effect.

JED: I believe it is eminently possible to build machines that think like humans do. I see brains as essentially entropy engines. What I believe is happening in brains is that quantum mechanical randomness at a microscopic level in brains injects some randomness into their operation. I believe that it isn't possible to predict the small scale actions or even many large scale actions of a brain any more than it is to predict when a radioactive isotope will decay. In my opinion brains are not even just chaotic but are non-deterministic systems, as with the well known thought experiment of the storm caused by the flap of a butterfly's wing. What I believe is that brains are uniquely able to select from their microscopic level quantum mechanical randomness 'thoughts' (which have physical form in my model) that are beneficial. I developed a simulation model (yes, on a computer) of brain functioning that was a lot like early preceptron models, but it had an essential random element to it. I based this model on some neurophysiology study that I did on neural function. It derived from the observed fact that, while nerves take a certain average amount of neurotransmitter to fire in their resting state, after a nerve has once fired (and recovered), it tends to take somewhat less neurotransmitter from the same axo-dendritic connection to get it to fire again.

GAM: There is an indeterminateness in how quickly it will refire. Some nerves have an inhibitor and it's like a switch you have to reset it in order to fire it again. Others fire more rapidly. That's demonstrative.

JED: After the nerve has fired, and it's past its rephase period, it ends up being more sensitive to incoming neurotransmitters than before it fired. That has also been demonstrated/observed. I did a simulation that exhibited classical and operant conditioning that can occur because of that basic property. In my simulated model, there are loops of nerve firings that are more likely if they are just the right length. The loop length has to be long enough that when the firing pulse comes back around the nerves have recovered and are near their extra sensitive point. It can't be so long that the probability of having all the nerves fire in sequence is so low that the loop doesn't continue. From that basic property of nerves it was clear that there is an optimal size for loops of nerve firings. Of course thinking in terms of a single loop is convenient for describing the phenomenon, but in reality I believe there are actually very complex interconnected patterns of loops that end up reinforcing (or not) each other.

I defined a notion of an "active idea", which is when these feedback loops are happening. I also defined a "passive idea", which is essentially the residue left in the brain after these ideas fired. In my model these different "ideas" correspond to short-term (active) and long-term (passive) memory.

GAM: Let me get a couple of specifics. In the part of the career that you have had which you just covered, is there some high point, or the best machine you've found? What is your favorite computer and your favorite theory?

JED: My favorite computer was the PDP-11 because it was so obvious what was happening. You could toggle in programs on the front panel that were actually useful. I didn't have as much hands on experience with the PDP-10. There the Octopus system (actually the "Gator" system) was running at the lowest level. There were some fascinating things done with the PDP-10 at the Lab. I could tell a John Fletcher anecdote here. I really respect John. We had a very interesting history over the years. It started back in RISOS. John programmed the early terminal concentrators and also a system called the "Combination Checker." The Combination Checker (called "Ostrich") stored all the passwords for all the computer users at of the Livermore Computer Center. It was isolated in its own little room. One of the things John did with Ostrich was to write an algorithm to encrypt the passwords as they were stored on the disk. The idea was that even if technicians could get in to access the disk, they still couldn't get access to the passwords - much like the encrypted passwords in the "shadow" files on Unix. People use modern "hash" algorithms like MD5 for such purposes these days. Ostrich was physically protected so this extra protection probably wasn't critical, but John thought it was a good idea to protect the passwords also with with a hash algorithm.

At some point John heard about the RISOS project doing computer security. He didn't seem to think much of the RISOS work, partly because we never tried to find flaws in the computer systems at LLNL. The RISOS project was never asked to investigate the systems at LLNL. I guess this was partly political and partly because the LLNL systems were physically protected and not subject to hacking. Still, John thought that checking a hash/encryption algorithm like the one he used on the Ostrich system would be a good job for a group like RISOS (thought that wasn't a focus of the RISOS work as noted above). At some point he contacted somebody in the group (perhaps Bob Abbott?) and asked if we would look at the code. Ultimately that request came down to me. This was kind of a challenge. He said, "Well you guys think you're hot stuff. Here's an algorithm that I put on this combination checker system. See if you can break it." Of course such an encryption algorithm is not nearly as complex as an operating system and therefore not as likely to be full of flaws, but I decided to look at it for a bit. It turned out that he was doing an algorithm in two halves. It's a bit difficult to describe, but the first thing I did was to show that I cut in half the work needed to break an encrypted password. He said there was no honor in such a brute force approach - even if I had been able to do it in half the time he expected. So I went back and looked at his code some more. Finally I found out that I could break his encryption scheme with a variation of the Euclidean algorithm (used to factor numbers into primes). John's code was a number theoretic approach (anticipating such later programs like the RSA encryption mechanism that is the mainstay of modern public key encryption technology) where he took numbers and manipulated them through a number of multiplications. I went back to him and showed him that his encryptions could be broken in very short order by this variation of the Eucledean algorithm. That was the first time I got some respect from John Fletcher.

GAM: He is a great person, there's no question about that.

JED: John and I had quite a time together working on operating systems and networking protocols. I found it interesting that even after I showed him that one could break his encryption algorithm, he never (so far as I know) changed it. It was in there until the dying days of Ostrich. It was still physically secure of course, but the encryption that was put into its code with some effort never did help its security substantially.

GAM: Let's quit this one and stop here for the time being.

[0] Jed Donnelley, "Capability Computing at LLNL."

[1] J. E. Donnelley, "DCAS" - A Distributed Capability Access System, Lawrence Livermore Laboratory Report UCID-16903, August 1975.

[2] J. E. Donnelley, A Distributed Capability Computing System, Proceedings of the Third International Conference on Computer Communication, August 1976, pp. 432-440. Also available at: http://www.webstart.com/jed/papers/DCCS/.

[3] J. E. Donnelley, Components of a Network Operating System, Fourth Conference on Local Networks, Minneapolis, 1979. Also in Computer Networks 3 (1979) 389-399, also available at: http://www.computer-history.info/Page4.dir/pages/LTSS.NLTSS.dir/pages/Components.dir/index.htm.

[4] J. E. Donnelley, IMPACT: The Integrated Machine for Processing Asynchronous Cellular Transactions - unpublished. Early rough draft design/simulation information is available at: http://www.webstart.com/jed/impact.pdf.