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 nihilish" 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
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 . 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
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...
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
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
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
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
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
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
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 . 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)
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 .
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
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
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 .
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
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
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.
 Jed Donnelley, "Capability Computing at LLNL."
 J. E. Donnelley, "DCAS" - A Distributed Capability
Access System, Lawrence Livermore Laboratory Report UCID-16903, August 1975.
 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/.
 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.
 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.
For information about this page, contact us at: email@example.com