During the formative years in the creation of the Arpanet, which was to become the backbone to the Global Computer Network, there were similar seminal developments taking place at the Bell Laboratories, the Research and Development unit of the Bell System. These developments were to have a significant impact on the future course of computer science research and networking in the world. As early as 1957, Bell Labs found they needed an operating system for their inhouse computer center which was then running lots of short batch jobs. Describing the situation facing the Labs, Victor Vyssotsky, who had been involved the techanical head of the Multics project at Bell Labs and later Executive Director of Research in the Information Systems Division of AT&T Bell Labs, explains, " We just couldn't take the time to get them on and off the machine manually. We needed an operating system to sequence jobs through and control machine resources." (from "Putting Unix in Perspective", Interview with Victor Vyssotsky, by Ned Pierce, in Unix Review, Jan. 1985, pg. 59)

The BESYS operating system was created at Bell Labs to deal with their inhouse needs. When asked by others outside the labs to make a copy available, they did so but with no obligation to provide support. "There was no support when we shipped a BESYS tape to somebody," Vyssotsky recalls, "we would answer reasonable questions over the telephone. If they found troubles or we found troubles, we would provide fixes." (Ibid., pg. 59)

By 1964, however, the Labs was adopting third generation computer equipment and had to decide whether they would build their own operating system or go with one that was built outside the Labs. Vyssotsky recounts the process of deliberation at the time, "Through a rather murky process of internal deliberation we decided to join forces with General Electric and MIT to create Multics," he explains. The Labs planned to use the Multics operating system "as a mainstay for Bell Laboratories internal service computing in precisely the way that we had used the BESYS operating system." (Ibid., pg. 59)

The collaborative project by GE, MIT and AT&T to create a computer operating system that would be called Multics (1965-68) was to "show that general-purpose, multiuser, timesharing systems were viable." (See Douglas Comer, "Pervasive Unix: Cause for Celebration," Unix Review, October, 1985, pg. 42) Based on the results of research gained at MIT using the Compatible Time-Sharing System (CTSS), AT&T and G.E. agreed to work with MIT to build a "new hardware, a new operating system, a new file system, and a new user interface." (Ibid.) Though the project proceeded slowly and it took several additional years to develop Multics, Doug Comer, a Professor of Computer Science at Purdue University, explains that "fundamental issues were uncovered, new approaches were explored and new mechanisms were invented." (Ibid) The most important, he explains, was that "participants and observers alike became devoted to a new form of computing (the interactive, multiuser, timesharing system.). As a result, the Multics project dominated computer systems research for many years, and many of its results are still considered seminal." (Ibid.)

Evaluating the influence of the MULTICS research on Bell Labs researchers, Comer points out that top researchers in computer science and mathematics from the world's premier industrial research center, Bell Labs, were able to work with top researchers from academia. When Ken Thompson, Dennis Ritchie and their "Bell Laboratories colleagues," writes Comer, "later began work on their own implementation of a Multics-like time-sharing system, they drew heavily from the Multics experience. So, despite popular myth, Unix was not an accidental discovery at all -- it evolved directly from experiences with academic research." (Ibid., pg. 41-42)

By 1969, however, AT&T made a decision to withdraw from the project. Describing that period, Dennis Ritchie, another of the inventors of unix at Bell Labs writes, "By 1969, Bell Labs management, and even the researchers came to believe that the promises of Multics could be fulfilled only too late and too expensively." (from Dennis Ritchie, "The Development of the C Language," ACM, presented at Second History of Programming Languages conference, Cambridge, Mass, April 1993, pg. 1)

Detailing the reasons for the decision, Vyssotsky responds, "It turned out that from our point of view the Multics effort simply went awry. In the first place, we were naive about how hard it was going to be to create an operating system as ambitious as Multics. It was the familiar second system syndrome. You put in everything you wished you'd had in the other one." (Vyssotsky, pg. 59) Also he details how GE, MIT, and AT&T each had different goals for the project, which made it difficult for them to work together. While GE wanted to develop Multics to "strengthen its product line," MIT wanted Multics "to advance the state of art" of computing, and Bell Labs' purpose was "to have a good environment for our people to work in." (Ibid.) Given these different objectives, Vyssotsky explains, "It turned out that under the stress of slipping schedules and the increasing realization that we had difficulty agreeing on a common course of action, we ended up simply pulling out of Multics. We said, `OK, it's too wet to plow. We aren't going to get from here to there'." (Ibid.)

When the decision to pull out of the Multics project was made by AT&T, Vyssotsky explains there was an operating system that he called a "precursor of Multics" running on their GE 645 computer. "From the point of view of the few people who could use it," he notes, "it was a very nice programming environment. In particular, Ken Thompson thought it was a very nice programming environment." (Ibid.)

However, when Bell Labs pulled out of the Multics project they took the Multics precursor off their GE 645 computer and put up GECOS, a much less state of the art operating system. "If you were an old line Spanish American War type computer user like me," Vyssotsky admits, "GECOS was a perfectly satisfactory system for getting from here to there in a well-designed application. You knew what it was going to do." (Ibid., pg. 60)

But for a research computer scientist like Ken Thompson, GECOS was inadequate. According to Vyssotsky, "It was nowhere near as satisfactory if you were trying to do things that were technically difficult and imperfectly defined, which is the main task of research." (Ibid.)

Not only for Ken Thompson's work, but for the research purposes of the Labs, an operating system more like what Multics had promised was needed. "I wanted a much more flexible system than BESYS or GECOS or OS360 or anything I could see," Vyssotsky recounts, "I had various things that I was trying to do with computers that were just plain hard to do with existing operating systems." (Ibid.)

"Moreover, for people like Ken Thompson," Vyssotsky emphasizes, "having this embryonic version of Multics taken away and GECOS slapped down in its place was something of a disaster. Suddenly they were back to square one." (Ibid.)

With the loss of the Multics experimental operating system, Ken Thompson, Dennis Ritchie and the others at the Labs who began work on Unix, realized they had to focus on creating an operating system for their programming needs. "I don't think," Vyssotsky relates, "that either of them was particularly fascinated by operating systems until they found themselves cast back upon GECOS. They sort of got interested in the subject out of self defense." (Ibid.)

In his account of this period, Dennis Ritchie writes, "Even before the GE-645 Multics machine was removed from the premises, an informal group, led primarily by Ken Thompson, had begun investigating alternatives." (Ritchie, pg. 1)

Thompson and Ritchie presented Bell Labs with proposals to buy them a computer so they could build their own interactive, time sharing operating system. Their proposals weren't acted on. Eventually, Ken Thompson found a little used and obsolete PDP 7 computer. According to Vyssotsky the orphaned PDP-7 computer was a tiny machine, "more nearly in the class of a Commodore 64 than the class of a PC-AT." (Vyssotsky, pg. 60)

Ritchie explains that Ken Thompson was attempting to create a programming environment which included "many of the innovative aspects of Multics," such as "an explicit notion of a process as a locus of control, a tree-structured file system, a command interpreter as a user-level program, simple representation of text files, and generalized access to devices." (Ritchie, pg. 1-2)

Describing the primitive conditions that Thompson faced, Ritchie writes, "At the start, Thompson "did not even program on the PDP itself, but instead used a set of macros for the GEMAP assembler on a GE-635 machine. A postprocesser generated a paper tape readable by the PDP-7. These tapes were carried from the GE machine to the PDP-7 for testing until a primitive Unix kernel, an editor, an assembler, a simple shell (command interpreter), and a few utilities (like the Unix rm, cat, cp commands) were completed. At this point, the operating system was self- supporting; programs could be written and tested without resort to paper tape, and development continued on the PDP-7 itself." (Ibid., pg 2)

The result, Ritchie explains, was that "Thompson's PDP-7 assembler outdid even DEC's in simplicity; it evaluated expressions and emitted the corresponding bits. There were no libraries, no loader or link editor: the entire source of a program was presented to the assembler, and the output file -- with a fixed name -- that emerged was directly executable. (Ibid., pg. 2)

The operating system was named Unix, to distinguish it from the complexity of MULTICS. Vyssotsky recalls that in addition to Thompson and Ritchie, "the two most active contributors at that stage were Joe Ossanna and Rudd Canaday. I should also add," he explains, "that Doug McIlroy was tremendously influential on their thinking." (Vyssotsky, pg.60) Vyssotsky elaborates, "I don't think that Doug actually contributed much of the programming, but for example, the appearance of pipes in Unix was clearly a result of Doug's discussions with Ken and Dennis." (Ibid.) Ken put them in, but "it was McIlroy who said, "Look you ought to do it. Pipes, like most things in Unix were not a radically new idea. Co-routines had, after all, shown up in SIMULA by the end of 1967." (Ibid.)

As work continued on the Bell Labs operating system, the researchers developed a set of principles to guide their work. Among these principles were:

"(i) Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new features.

(ii) Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.

(iii)Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.

(iv)Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them."

(from M.D. McIlroy, E.N.Pinson, and B.A. Tague "Unix Time-Sharing System Forward", The Bell System Technical Jounal, July -Aug 1978 vol 57, number 6 part 2, pg. 1902)

By 1970, Ritchie writes, the Unix researchers were "able to acquire a new DEC PDP-11. The processor," he remembers, "was among the first of its line delivered by DEC, and three months passed before its disk arrived." (Ritchie, pg. 5) Soon after the machine's arrival and while "still waiting for the disk, Thompson," Ritchie recalls, "recoded the Unix kernel and some basic commands in PDP assembly language. Of the 24K bytes of memory on the machine, the earliest PDP-11 Unix system used 12K bytes for the operating system, a tiny space for user programs, and the remainder as a RAM disk." (Ibid., pg. 5) "By 1971," Ritchie writes, "our miniature computer center was beginning to have users. We all wanted to create interesting software more easily. Using assembler was dreary enough that B, despite its performance problems, had been supplemented by a small library of useful service routines and was being used for more and more new programs." (Ibid., pg. 6)

"C came into being in the years 1969-1973," Ritchie explains, "in parallel with the early development of the Unix operating system; the most creative period occurred during 1972." (Ibid., pg. 1) "By early 1973," the essential of modern C were complete. The language and compiler were strong enough to permit us to rewrite the kernel for the PDP-11 in C during the summer of that year. (Thompson had made a brief attempt to produce a system coded in an early version of C -- before structures -- in 1972, but gave up the effort.)" (Ibid.)

Each program they built developed some simple capability and they called that program a tool. They wanted the programs to be fun to use and to be helpful to programmers. Describing the achievements of the lab, Doug McIlroy, one of the researchers and Thompson's Dept Head when they created Unix, describes the atmosphere at the lab:

"Constant discussions honed the system....Should tools usually accept output file names? How to handle demountable media? How to manipulate addresses in a higher level language? How to minimize the information deducible from a rejected login? Peer pressure and simple pride in workmanship caused gobs of code to be rewritten or discarded as better or more basic ideas emerged. Professional rivalry and protection of turf were practically unknown: so many good things were happening that nobody needed to be proprietary about innovations." [from M.D. McIlroy, "Unix on My Mind," Proc. Virginia Computer Users Conference, vol 21, Sept. 1991, Blacksburg, pg. 1-6.]

The research done at the Labs was concerned with using the computer to automate programming tasks. By a scientific approach to their work and careful attention to detail, Bell Labs researchers determined the essential elements in a design and then created a program to do as simple a job as possible. These simple computer automation tools would then be available to build programs to do more complicated tasks.

They created a Unix kernel accompanied by a toolbox of programs that could be used by others at Bell Labs. The kernel consisted of about 11,000 lines of code. Eventually, 10,000 lines of the code were rewritten in C and thus could be transported to other computer systems. "The kernel," Ken Thompson writes, "is the only Unix code that cannot be substituted by a user to his own liking. For this reason, the kernel should make as few real decisions as possible." (from K. Thompson, "Unix Implementation", "The Bell System Technical Journal," vol 57, No. 6, July-August 1978, pg. 1931)

Thompson describes creating the kernel:

"What is or is not implemented in the kernel represents both a great responsibility and a great power. It is a soap-box platform on `the way things should be done.' Even so, if `the way' is too radical, no one will follow it. Every important decision was weighed carefully. Throughout, simplicity has been substituted for efficiency. Complex algorithms are used only if their complexity can be localized." (Ibid., pg. 1931-2)

The kernel was conceived as what was essential and other features were left to be developed as part of the tools or software that would be available. Thompson explains:

The Unix kernel is an I/O multiplexer more than a complete operating system. This is as it should be. Because of this outlook, many features are found in most other operating systems that are missing from the Unix kernel. For example, the Unix kernel does not support file access methods, file disposition, file formats, file maximum sizes, spooling, command language, logical records, physical records, assignment of logical file names, logical file names, more than one character set, an operator's console, an operator, log-in, or log-out. Many of these things are symptoms rather than features. Many of these things are implemented in user software using the kernel as a tool. A good example of this is the command language. Maintenance of such code is as easy as maintaining user code. The idea of implementing "system" code and general user primitives comes directly from MULTICS." (Ibid., pg. 1945-6)

Evaluating the achievement represented by the kernel, Vyssotsky explains, "I would say that the greatest intellectual achievement embedded in Unix is the success Ken Thompson and Dennis Ritchie had in understanding how much you could leave out of an operating system without impairing its capability." (Vyssotsky, pg. 60-62)

"To some extent," he continues, "that was forced by the fact that they were running on small machines. It may also have been a reaction to the complexity of Multics...It took some very clear thinking on the part of the creators of Unix to realize that most of that stuff didn't have anything to do with the operating system and didn't have to be included." (Ibid., pg. 62)

Eventually the unix operating system was adopted in other departments at AT&T to do a variety of work. "There is one piece of history that I think is very important to understand," explains Vyssotsky, "When Unix evolved within Bell Laboratories, it was not a result of some deliberate management initiative. It spread through channels of technical need and technical contact....This was typical of the way Unix spread around Bell Laboratories. You had MTSS Supervisors and Department Heads saying we had to go in this direction while Executive Directors were saying, `Well, I'm awful nervous about it. But if you guys say that is what we've got to do, I'll back your play." (Ibid, pg. 62-64)

Explaining the importance of how unix was implemented organizationally within the Bell System, Vyssotsky comments, "There are a lot of organizations that do not work that way. I brought out that little hunk of history to point out that the spread and success of Unix, first in the Bell organizations and then in the rest of the world, was due to the fact that it was used, modified, and tinkered up in a whole variety of organizations within Bell Laboratories....The refinement of Unix was not done as the result of some management initiative or council of vice presidents. It was the supervisors saying, "This thing is already better than our other options and flexible enough for us to make it a go." (Ibid. pg. 64)

During the same period that the search for an operating system to replace the promise of Multics had begun by Bell Labs computer programming researchers, the Bell System was faced with the problem of automating their telephone operations using minicomputers. Describing the problem facing the Bell System during this period, August Mohr, in an article in Unix Review, "The Genesis Story" (January 1985, pg. 22), writes "Bell was starting to perceive the need for minicomputer support for its telephone operations." (Mohr was editor of /usr/group 's CommUnixations newsletter.)

"The discovery that we had the need -- or actually, the opportunity -- in the early '70s to use these minis to support telephone company operations encouraged us to work with the Unix system," confirms Berkley Tague. ("Interview with Berkley Tague," Unix Review, June 1985, pg. 59) "We knew we could do a better job with maintenance, traffic control, repair, and accounting applications." (Ibid.)

"The existing systems were made up of people and paper," he relates, "The phone business was in danger of being overwhelmed in the early '70s with the boom of the '60s. There was a big interest then in using computers to help manage that part of the business. We wanted to get rid of all of those Rolodex files and help those guys who had to pack instruments and parts back and forth just to keep things going."

During the late 1960's, AT&T was under pressure from regulatory bodies like the New York Public Service Commission, to solve what was termed as a "service crisis." (See especially, "Wrong Number," by Alan Stone, N.Y., 1989, pg. 145) This pressure encouraged AT&T to explore technological advances that would make its support operations more efficient.

Tague explains that there had been local mechanization of processes but not large scale integration of the mechanization. "Take repair," he suggests as an example, "A lot of it deals with keeping the connections straight between what we call the main distribution frames in the central office and the wires that tie residential telephones into the switch. Prior to the use of computers, `mechanization' consisted of somebody on a remote test bench using electrical meters and instruments to test lines. To get those connections made, an intercom was used to broadcast requests to a bunch of people standing around with alligator clips and soldering irons down in the wire center. The requests went something like, `Would you kindly connect jumper x to terminal y?' to get testing done." (Ibid, pg. 60)

Tague describes how the mini computer made it possible to automate this process. "First, we were able to get more instructions out to the people actually making the connections. And, at the other end, we were able to centralize information about entire systems and end-to-end circuits."

"This meant," he elaborates, "that if I was responsible for keeping the Superbowl broadcast on the air between New Orleans and New York, I could -- with a single console -- view all the connections on that link and have access to all of the information automatically being collected about it. If something broke, I could immediately recognize that and orchestrate the process of getting it repaired. The repair itself would ultimately be left to a person working in much the same way as before." (Ibid.)

This change affected workers like those "plugging in an alternate module or pulling a manual switch and going to a backup system," he clarifies. "Suddenly, their work became much faster because the information was all in one place -- unlike earlier days when eight guys would have had to collect and sort out the trouble data in a series of phone calls before actually being able to get down to the business of working on solutions." (Ibid.)

Other applications were affected as well, he explains. "in areas like cable and wiring layouts. The algorithms applying to these layouts were well known here at the Laboratories, but they were not the sort of thing you could usefully put into a manual. They were, however, easily put into computer programs. Optimum layouts could thus be generated using the computer to assess all the complicated engineering tradeoffs." (Ibid.)

Not only did they need a good programming environment, but Mohr emphasized that the Bell System applications required, "Operations Systems, not Operating Systems. With the number of systems under consideration, the possiblity of being tied to a single vendor, or having each site tied to a different vendor, induced a kind of paranoia. There just had to be another way." (Mohr, pg. 22)

Tague elaborates, "If we faced the phone company with 18 different vendors and 19 different environments, neither the developers nor the phone companies were going to be able to maintain the thing once it got out in the field in large numbers. As a planner, I was trying to focus on a few vendors. At that time, it was primarily Hewlett-Packard and DEC, plus a few IBM systems." (Tague, pg. 60)

This led to the realization of a need for an operating system. "Vendor operating systems were available as a starting point", he adds "but a number of people had already started to build their own when they realized that what the vendors had was not adequate." (Ibid.)

Tague explains that his role in planning for the transition meant that he tried to warn those involved that they would need a good software environment to do the development of the software needed to use the mini computers for these new roles.

"I observed," he comments, "that people were starting to put these minis out in the operating company, and saw that it was an area of both opportunity and potential problems. I found," he adds, "that some of the people in development had never built an operating system for any computer before; many of them had very little software background. They were coming out of hardware development and telephone technology backgrounds, and yet were starting to build their own operating systems. Having been through that phase of the business myself, it seemed silly to go through it another hundred times, so I started pushing the Unix operating system into these projects." (Mohr, pg. 22)

Tague was familiar with Unix and its capabilities and tells the variety of reasons ranging from inadequate file systems, to inadequate performance, to poor user interface that he recommended the initial adoption of Unix to start the work. "We sold those first application developers on Unix simply by pointing out that the first job they were going to have to do was program development and that by using the Unix operating system they could get that job done more easily. I did not argue with them about whether or not they should develop their own operating systems -- knowing in my heart of hearts that once they got on Unix they wouldn't be able to do any better with the experience and the schedules they had. Indeed, that is what happened." (Tague, pg. 60-1)

Tague's backing of Unix, as a development system for operations, was not just a personal preference. "I had every confidence in the people who built it because I'd worked with them on Multics," he explained. "With their experience and training, I figured they could build a much better operating system than somebody who's building one for the first time, no matter how smart that person is." (Mohr, pg 22)

Tague describes how Unix had been functioning in the research environment and thus had demonstrated that it could be used as a beginning basis for this important job.

Also, he knew that there would be a need to develop a support system for those operating companies around the country that would begin to use Unix: "We were starting to put these things in the operating companies all around the countryside," explains Tague, "and the prospects were that there were going to be several hundred minis over the next few years that were going to have to be maintained with all their software and hardware." (Ibid., pg. 24)

Bell had created the needed field support system to maintain the electronic switching machines and software that were now being upgraded. "Supporting a network of minicomputers would be a significantly different problem, though," August Mohr explains. "Maintaining an operating system is not at all like maintaining an electronic switching system. The minicomputers had different reliablity demands, requiring a different support structure in the organization -- one that did not yet exist in any form. In many ways, the operations group was breaking new ground," writes Mohr. (Ibid.)

As head of the Computer Planning Department, Tague had been responsible for systems engineering. In 1971 Tague garnered support for Unix to be adopted. Then he pushed to have Unix made the internal standard and to provide central support through his organization. By September, 1973, he was able to form a development organization to provide support for a "standard Unix." This group, called Unix Development Support worked with Bell Labs Research. Though the two groups sometimes diverged regarding their priorities, Mohr explains that they agreed on the need for Unix portability.

According to Mohr, "Tague foresaw the possiblity of Unix becoming an inteface between hardware and software that would allow applications to keep running while the hardware underneath was changing." (Ibid., pg. 24)

"From the support point of view," he continues, "such a capability would solve a very important problem. Without Unix and its potential portability, the people building the operations support systems were faced with selecting an outside vendor that could supply the hardware on which to get their devlopment done. Once that was complete, they would be locked into that vendor." However, according to Mohr, "Portability obviated this limitation and offered a number of other advantages. When making a hardware upgrade, even to equipment from the same vendor, there are variations version to version. That could cost a lot of money in software revisions unless there were some level of portability already written into the scenario." (Ibid., pg. 24-25)

Just as Operating Systems people in the Bell system had come to recognize the need for portability in a computer operating system, Ritchie and Thompson and the other programming researchers at Bell Labs had created the computer language C and rewritten the majority of the Unix kernel in C and thus had made the important breakthrough in creating a computer operating system that was not machine dependent. Describing their breakthrough with Unix, Thompson and Ritchie presented their first paper on Unix at the Symposium on Operating Systems Principles, IBM Thomas J. Watson Research Center, Yorktown Heights, New York, October 15-17, 1973, (reference from Unix(tm) Time-Sharing System: Unix Programmers Manual, 7th edition, vol 2, Murray Hill, f/n pg 20). See also Ritchie's account of the creation of C by early 1973 in "The Development of the C Language," ACM, presented at Second History of Programming Languages conference, Cambridge, Mass, April 1993, pg. 1) Describing this important achievement by Bell Labs researchers, Mohr writes, "the integral portability of the system developed by Research proved adequate to make Unix portable over a wide range of hardware."

With the research breakthrough of a portable computer operating system, "the first Unix applications were installed in 1973 on a system involved in updating directory information and intercepting calls to numbers that had been changed. The automatic intercept system was delivered for use on early PDP-11s. This was essentially the first time Unix was used to support an actual, ongoing operating business." (Mohr, pg. 26)

Different operations sites had taken on to create computer software to meet similar needs, such as print spooling, mail, help, etc. Tague's group's assignment was to gather the software and to determine what the standard should be and send the standard back out to the sites. Tague credits the technical strength of Unix for making software standardization possible. Unix "made it easy," he explains, "to get the right stuff in without upsetting the whole world."

Establishing a standard Unix, according to Tague, was "a process of negotiation and compromise with the Unix-using community -- not a unilateral decision." (Ibid.) His group and the people at the variety of Bell sites "often ended up arguing things out until everybody understood the issues and a suitable compromise was made," he relates. (Ibid.)

Tague describes how his group the Unix Support Group (USG) which had been established in September of 1973 "released the first C version of Unix internally. [Generic I, II, and III were produced by these intitial efforts.] In parallel with our efforts," he notes, "the Programmer's Workbench gang under Rudd Canaday worked the same vein over in the BIS [Business Information Systems] area. (Tague, pg. 61)

The application of Unix to automating the operating systems at Bell also involved automating the monitoring, measurement, help for routing and ensuring quality of calls. That was a "tall order," writes Tony Culwick, "given the standards people have come to expect...but the fact remains that the fundamental integrity of the national telecommunications network depends on more than 1000 real-time, mini-computer-based systems that are built on a version of the Unix operating system." (from "Reach out and Touch the Unix System," by Tony Cuilwik, "Unix Review," June 1985, pg. 50. Cuilwik was the head of the Operations Systems Development Department at Bell Laborators and then director of AT&T Information Systems Laboratories in Columbus, Ohio.)

Describing the functions that Unix makes possible, he writes, "Among the varied and wide-ranging functions these systems perform are network performance measurement, automated network testing, circuit order planning, circuit order record- keeping, automated trouble detection, automated or directed trouble repair, service quality assurance, quality control, inventory control, customer record-keeping, and customer billing -- as well as any number of other operational and administrative functions. These functions all require," Cuilwik explains, "the ability to present data to users in real-time." (Ibid.)

The object in these systems is "to guarantee a minimal acceptable human response time. This challenge has been met by tuning the underlying Unix system." (Ibid.)

Cuilwik describes how the need for such real time applications was determined in the 1969-70 period, just when Unix was being created. Development, he reports, "began in earnest in 1971. Early in this period," he writes, "it was determined that an operating system and environment should be provided to system designers, who would then only need to develop application- specific software." By 1974, he reports "several sites had chosen the Unix operating system as this development environment. A few, meanwhile, had also selected it as an execution environment and were busy designing enhancements and improvements for the system." (Ibid.)

The need was also recognized for "a common operating environment between projects." (Ibid.,pg. 50-52) "Major additions" he writes, "necessary to move the timeshared Unix system into real-time applications included interprocess communications (name pipes, messages, semaphores, and shared memory), file access (logical file system, record access system), error recovery, power fail/restart, and line and terminal disciplines. These additions were developed, integrated or donated to the common good by people developing specific systems. By 1979," he reviews, "there was an enhanced real-time Unix system that was centrally supported, offering a collection of tools and a number of human/machine interface designs to protect system users from direct contact with Unix primitives." (Ibid, pg. 52)

The process of the development of Unix so it contained such a range of options involves its adoption and development by the academic research community. Early in its development, word of the Unix operating system and its advantages spread outside of Bell Labs. (Several sources attribute this to the paper that Ritchie and Thompson presented on Unix at the Symposium on Operating Principles at Purdue in November, 1973. See for example McKusick, "A Berkeley Odyssey" in Unix Review, January 1985, pg. 31, and Peter Ivanov, "Interview with John Lions", Unix Review, October, 1985, pg. 51, about the publication of the paper in July 1974 in the "Communications of the ACM".) The labs made the software available to academic institutions at a very small charge. For example, John Lions, a faculty member in the Department of Computer Science at the University of New South Wales, in Australia, reported that his school was able to acquire a copy of research Unix Edition 5 for $150 ($110 Australian) in December, 1974, including tape and manuals. (See "An Interview with John Lions," in Unix Review, October, 1985, pg. 51)

Unix was attractive to the academic Computer Science community for several reasons. John Stoneback, describing these reasons, writes:

"Unix came into many CS departments largely because it was the only powerful interactive system that could run on the sort of hardware (PDP-11s) that universities could afford in the mid '70s. In addition, Unix itself was very inexpensive. Since source code was provided, it was a system that could be shaped to the requirements of a particular installation. It was written in a language considerably more attractive than assembly, and it was small enough to be studied and understood by individuals." (from John Stoneback, "The Collegiate Community," Unix Review, October 1985, pg. 27)

Describing how research Unix helped make it possible for academic computer science departments to establish and develop research in computer science, he writes:

"Unix had another appealing virtue that many may have recognized only after the fact -- its faithfulness to the prevailing mid-'70s philosophy of software design and development. Not only was Unix proof that real software could be built the way many said it could, but it lent credibility to a science that was struggling to establish itself as a science. Faculty could use Unix and teach about it at the same time. In most respects, the system exemplified good computer science. It provided a clean and powerful user interface and tools that promoted and encouraged the development of software. The fact that it was written in C allowed actual code to be presented and discussed, and made it possible to lift textbook examples into the real world. Obviously, Unix was destined to grow in the academic community. (Ibid., pg. 27)

In trying to teach his students the essentials of a good operating system, John Lions describes how he prepared a booklet containing the source files for a version of Edition 6 of research Unix in 1976 and the following year completed a set of explanatory notes to introduce students to the code. "Writing these," he recounts, "was a real learning exercise for me. By slowly and methodically surveying the whole kernel, I came to understand things that others had overlooked."

This ability to present his students with a real example of an operating system kernel was a breakthrough. Lions writes:

Before I wrote my notes on Unix, most people thought of operating systems as huge and inaccessible. Because I had been at Burroughs, I knew that people could get to learn a whole program if they spent some time working at it. I knew it would be possible for one person to effectively become an expert on the whole system. The Edition 6 Unix code contained less than 10,000 lines, which positioned it nicely to become the first really accessible operating system." (Lions, pg. 52-3)

In keeping true to the Unix community spirit of helping each other, Lions wrote a letter to Mel Ferentz, Lou Katz and others from Usenix and offered to make copies of his notes available to others. After some negotiation with Western Electric over the patent licensing, he distributed the notes titled "A Commentary on the Unix Operating System" to others with Unix licenses on the conditions that Western Electric had set out. (Ibid., pg. 53)

Lions describes how he helped to develop a Unix tool "pack" which was eventually combined with tools created at Bell Labs called huff and unhuff and distributed as a standard Unix command. He and others from his college were invited to spend periods of time at Bell Labs to work with the unix researchers there. (See for example, pg. 57)

Describing how research Unix and its adoption at academic institutions has served to develop computer science, Doug Comer writes:

The use of Unix as a basis for operating systems research has produced three highly desirable consequences. First, the availability of a common system allowed researchers to reproduce and verify each others' experiments. Such verification is the essence of science. Second, having a solid base of systems software made it possible for experimenters to build on the work of others and to tackle significant ideas without wasting time developing all the pieces from scratch. Such a basis is prerequisite to productive research. Third, the use of a single system as both a research vehicle and a conventional source of computing allowed researchers to move results from the laboratory to the production environment quickly. Such quick transition is mandatory of state-of-the-art computing." (Comer, pg. 44)

Not only did research Unix serve the academic community, but the contributions of the academic community were incorporated into research Unix. An example, is the work by Babaoglu and Porker at UC Berkeley of designing a virtual memory version of Unix for the VAX computer which was later optimized by Bill Joy and incorporated into a release of Unix. (Ibid.)

Academic contributions which were incorporated into research Unix included the vi editor which was created by Bill Joy at University of California at Berkeley. Describing this phenomena Comer writes:

"Many universities contributed to Unix. At the University of Toronto, the department acquired a 200-dt-per-inch printer/plotter and built software that used the printer to simulate a phototypesetter. At Yale University, students and computer scientists modified the Unix shell. At Purdue University, the Electrical Engineering Department made major improvements in performance, producing a version of Unix that supported a larger number of users. Purdue also developed one of the first Unix computer networks. At the University of California at Berkeley, students developed a new shell and dozens of smaller utilities. By the late 1970s, when Bell Labs released Version 7 Unix, it was clear that the system solved the computing problems of many departments, and that it incorporated many of the ideas that had arisen in universities. The end result was a strengthened system. A tide of ideas had started a new cycle, flowing from academia to an industrial laboratory, back to academia, and finally moving on to a growing number of commercial sites." (Comer, pg. 43)

In the process of using Unix within Bell Labs, bugs would be discovered and reported to the programmers, or new applications would be created by the departments using the programs for their own tasks. The research labs would need to provide maintenance and updating of software as well as getting the bug reports to the programmer and sending out fixes.

To automate this maintenance work, Mike Lesk, one of the Bell Labs computer researchers, proposed an automated maintenance system that would make it possible to have the research computer call up the computers in the departments and automatically deliver updated software and test that it worked on the remote computer.

As part of the automated maintenance system, Lesk created a Unix program called UUCP (Unix to Unix copy) which made it possible to use a phone or hard wired connection to have one computer poll another computer and deliver the software.

Describing the considerations by Bell Labs at this time, Vyssotky explains, (from Vyssotsky, pg. 64)" In 1976, there were those three versions of Unix. The Change Control Process on all three of those versions was such that, at any moment in time, the people who were programming could tell what changes had gotten in and what changes were scheduled to go in. However, it was still a little hard for the users to tell what they were getting. It wasn't until 1978 that we had anything that I would consider to be a reasonable configuration management process of Unix. That was the point at which we finally realized we had something which, like it or not, was a major product. So we said, `Given that it is a major product, there can be no horsing around.' We could no longer regard it as something in the underbrush. We had to regularize our arrangements. We set up a process for configuration management and we focused the thing in the direction of a coherent system." (Vyssorsky, pg. 64-68)

But he emphasizes, "Perhaps, the most important one was that Unix was being used as the operating system basis for a bunch of operations support systems in the Bell Operating Companies and we could not afford to let those support systems go down. We put configuration management and all of the associated paraphernalia in place about 1978. (Ibid., pg. 68)

Lions says about the freezing, "Much of the development of Unix in Bell Laboratories occurred before 1978. After Edition 7, many of the original group went off to do other things. At the same time, Unix was becoming important within the Bell System, which gave rise to a support group whose charter was to develop a polished and stable version of Unix. This group was less interested in innovation than in stabilizing the system. Universities have simply picked up the slack. (Lions, pg. 56)

Meanwhile, academic Unix users had to do their own software maintenance. Lions describes how a community of academic unix users grew up who were willing to help each other.

"One very positive effect, however" writes Lions, "is that the number of universities using Unix and the lack of any formal support forced us to band together into AUUG. (Australian unix users group -ed) The connections we have thereby made have created and cemented bonds between people in the different departments. Unix has been a very unifying influence for computer science within Australia. This cannot be overestimated." (Ibid., pg. 57)

UUCP made such exchanges easier. It was included with the Version 7 Unix, which was made available to the academic community outside of Bell Labs. UUCP made it possible for Unix users to communicate with each other even when they were at spatially distant locations.

Using UUCP, the Unix community was able to pioneer still another advance, Usenet News. "Though large institutions have been able to avail themselves of communications networks such as ARPANET, the Unix community has made inexpensive electronic communication available to all of its members via Usenet," writes Stoneback, "A community that already had so much in common," he explains, "was strengthened and enhanced by the ability to move software easily among locations and to maintain a reasonable electronic mail system. The cost of this network has been borne at least in part by private industry, thus mitigating expenses for the users themselves. The Usenet network stands today as a clear sign that the Unix community is solidly in place. It now includes numerous corporate members providing universities on the network with the added advantage of pooling academic researchers, industrial developers, industrial researchers and regular users. Combined with a functional, cheap electronic communication system, Usenet offers the academic community unique advantages." (Stoneback, pg. 26)

"The network," he points out, "is the direct result of a community that supports its members and in turn is nurtured by the ones it serves. The community is a reasonably democratic one, reasonably open to new ideas, resonably open to change, and reasonably generous with its benefits." (Ibid.)

Thus by 1980, a survey conducted by the Computer Science Research Network (CSNET) of academic institutions to find out what computer system they used, found that "over 90 percent of all departments were served by one or more Unix systems." (Comer, pg. 42)

Explaining the surprising popularity that Unix achieved despite its grassroots distribution system, McIlroy writes, "Therein lies the genius of Unix, which, without a sales force, and without the support of hardware makers, was enthusiastically adopted around the world..." ("Unix on My Mind")

"Unix," he emphasizes, "was the distilled essence of operating systems, designed solely to be useful. Not to be marketable. Not to be compatible. Not to be an appendage to a particular kind of hardware. Moreover a computer running Unix was to be useful as a computer, not just a `platform' for canned `solutions'. It was to be programmable - cumulatively programmable. The actions of program builders were to be no different in kind from the actions of users; anything a user could do a program could do too...." (Ibid.)

Describing the environment that gave birth to these advances, McIlroy writes,

"Open systems! Our systems! How well those who were there remember the pipe-festooned garret where Unix took form. The excitement of creation drew people to work there amidst the whine of the computer's cooling fans, even though almost the same computer access could be had from one's office or from home. Those raw quarters saw a procession of memorable events. The advent of software pipes precipitated a day-long orgy of one-liners...as people reveled in the power of functional composition in the large, which is even today unavailable to users of other systems. In another memorable event, the unarticulated notion of software tools, which had been bolstered by pipes, was finally brought home by the liberation of the pattern matching program grep from within the editor." (Ibid.)

He continues:

"A parade of visitors came to marvel at the system and to copy it. The makers of our 1972 model phototypesetter goggled when they saw the paper tape input replaced by wires straight from a computer. On-line PicturePhone[r] service caught attention. Synthetic speech was initiated by a memorable `Come here, Watson' event when words typed in a remote office range out clearly in the lab: `It sounds better over the telephone.' The computer's readings and misreadings became a constant crowd pleaser. There was great, if somewhat conspiratorial, excitement over a stealthy version of the C compiler that would recognize and silently bug the Unix login program and would propagate the ability through future generations of the compiler itself....No trace of the bug appeared in source code." (Ibid.)

And UUCP and then Usenet News made this the experimental research environment available for those not at Bell Labs, or with access to the experimental Arpanet. "Eager to distribute his software quickly and painlessly, Mike invented uucp, thereby begetting a whole global network," McIlroy writes. (from "A Research Unix Reader: Annotated Excerpts from the Programmer's Manual, 1971-1986" by M. D. McIlroy, Computing Science Technical Report No. 139, AT&T Bell Laboratories, June 1987, pg. 3.

Summarizing the relationship between Bell Labs and the academic community in developing Unix, Comer concludes:

"Unix was not invented by hackers who were fooling around, nor did it take shape in a vacuum. It grew from strong academic roots and it has both nurtured and taken nourishment from academia throughout its development. The primary contributors to Unix were highly educated mathematicians and computer scientists employed by what many people feel is the world's premier industrial research center, Bell Laboratories. Although they were knowledgeable and experienced in their own right, these developers maintained professional contacts with researchers in academia, leading to an exchange of ideas that proved beneficial for both sides. Understanding the symbiotic relationship between Unix and the academic community means understanding the background of the system's inventors and the history of interactions between universities and Bell Laboratories." (Comer, pg. 34, 42)

Describing this fertilization, Dennis Ritchie wrote, "...Unix enjoyed an unusually long gestation period. During much of this time (say 1969-1979) the system was effectively under the control of its designers and being used by them. It took time to develop all the ideas and software, but even though the system was still being developed people were using it, both inside Bell Labs, and outside under license. Thus, we managed to keep the central ideas in hand, while accumulating a base of enthusiastic, technically competent users who contributed ideas and programs in a calm, communicative, and noncompetitive environment. Some outside contributions were substantial, for example, those from the University at Berkeley." ("Reflections on Software," August 1984, vol 27, No. 8, pg. 75)

John Lions, reviewing his experience as part of the Unix community, concludes, "We have made a large number of contacts and exchanged a great deal of information around the world through this Unix connection. Possibly that is the nicest thing about Unix: it is not so much that the system itself is friendly but that the people who use it are. " (Lions, pg. 57)

It is a rare and wonderful event in the development of human society when a scientific and technological breakthrough is made which will certainly affect the future course of social contributions wer substantial, for example, those from the development and which becomes known when its midwives are still alive to tell us about it. Unix, the product of researcher at Bell Labs, the then regulated AT&T system, and academic computer science, and a valuable invention for computer science, for computer education and for the education of the next generation of computer scientists and engineers, is such an event.

By Ronda Hauben    (ronda@umcc.umich.edu)

 Regresar    Arriba