From: geoff@world.std.com (Geoff Collyer) Newsgroups: comp.unix.wizards Subject: Re: Origins of Unix Mike Digdon: >If I remember my UNIX history correctly, Ken Thompson wrote MULTICS, which >was supposed to be a multi-user OS. However, it failed quite miserably >at the multi-user level. This is getting silly. We don't have to rely on inaccurate folklore and people's fault memories; there is a written account of the origins of UNIX, ``The Evolution of the UNIX Time-sharing System'' by Dennis Ritchie, originally published in Lecture Notes in Computer Science 79: Language Design and Programming Methodology, from Springer-Verlag, and later reprinted in the AT&T Bell Laboratories Technical Journal of October 1984 (volume 63, number 8 part 2). An executive summary is that Bell Labs, G.E. and M.I.T. had been partners in the development of Multics, a pioneering timesharing system, but it wasn't working out, so Bell Labs withdrew from the Multics effort. Ken Thompson, Dennis Ritchie, Doug McIlroy and Joe Ossanna, among others, wanted a replacement for the comfy environment they had had on Multics. During 1969, with help from Rudd Canaday, Thompson and Ritchie designed and implemented a small operating system for the PDP-7, which Brian Kernighan named `UNIX' in 1970; to quote the paper: ``Although it was not until well into 1970 that Brian Kernighan suggested the name `Unix', in a somewhat treacherous pun on `Multics', the operating system we know today was born''. -- Geoff Collyer world!geoff, world.std.com!geoff From: cjc@ulysses.att.com (Chris Calabrese) Newsgroups: comp.unix.wizards Subject: Re: Origins of Unix In article , digdon@ug.cs.dal.ca (Mike Digdon) writes: |> |> If I remember my UNIX history correctly, Ken Thompson wrote MULTICS, which |> was supposed to be a multi-user OS. However, it failed quite miserably |> at the multi-user level. |> |> Ken then started work on another OS, which Brian Kernigan (as a joke because |> of MULTICS non-multi-user abilities) quickly named UNICS. Of course, turning |> UNICS to UNIX was obvious.. Not that I'm the ultimate authority on the history of the name UNIX, but it goes more like this...(with my copy of the Bach book in hand): In 1965 Bell Labs joined GE and MIT Project MAC to developed a new OS called MULTICS (which stands for something like Multiple Access Time Sharing Computer System, but I can't remember exactly what at the momemt). There was a version working on GE iron by '69, but by that time the Labs had already left the project (it wasn't going anywhere). Thompson tried out some of his filesystem ideas that he developed while on MULTICS on GE/Honeywell iron running GECOS and developed Space Travel (an early video game). Later he took his stuff to an unused PDP-7. Since the PDP-7 had a lousy development environment (he was compiling his stuff on the GECOS machine), Thompson and Ritchie implemented a simple OS on it which they called UNICS. The UNIX name came from Kernighan (according to Bach). I believe the UNICS name came from Ritchie (if I remember Tannenbaum correctly). -- Name: Christopher J. Calabrese Brain loaned to: AT&T Bell Laboratories, Murray Hill, NJ att!ulysses!cjc cjc@ulysses.att.com From: ae547@yfn.ysu.edu (Ronda Hauben) Newsgroups: alt.amateur-comp,alt.folklore.computers,comp.misc,comp.unix.misc Subject: Early Days of Unix - Draft for Comment (pt 1 of 2) Date: 22 Dec 1993 08:42:33 GMT I am in the process of working on the current draft and I would appreciate any comments, suggestions, additional information, etc. regarding the early days of unix development and the work to develop computer science that this early work on unix represented. Thanks. Ronda DRAFT On the Evolution of Unix and the Automation of Telephone Support Operations (i.e. of Computer Automation) by Ronda Hauben Abstract: 1994 is the 25th anniversary of the invention of the UNIX kernel at Bell Labs. The following article is a chapter in a longer paper documenting some of the events that have contributed to the development of a Global Computer Network in the past 25 years. This article describes how the need to automate telephone support operations in the U.S. in the late 1960s and the early 1970s nourished the birth and developement of the UNIX operating system and how academic computer science contributed to and gained from the development of UNIX. This article is intended as a contribution to a 25th anniversary commemoration of the significance of the UNIX breakthrough and the lessons that can be learned for making the next step forward. "I don't believe UNIX is Utopia. It's just the best set of tools around." -- Dick Haight, Unix Review, Jan. 1985, p. 117 "What does industrial computer science research consist of?....Although work for its own sake resulting, for example, in a paper in a learned journal is not only tolerated but welcomed, there is strong though wonderfully subtle pressure to think about problems somehow relevant to our corporation....Indeed, researchers love to find problems to work on; one of the advantages of doing research in a large company is the enormous range of puzzles that turn up....Thus, computer research at Bell Labs has always had a considerable commitment to the world...." -- Dennis Ritchie, "Reflections on Software Research," Communications of the ACM, vol 27, no. 8, August 1984, p. 759 "Bell had already gained some field support experience switching machines and their software. Supporting a network of mini computers would be a significantly different problem." -- August Mohr, "The Genesis Story," Unix Review, Jan. 1985, p.24 "From hence it necessarily follows...Rich and Poor, Young and Old, must must study the Art of Number, Weight, and Measure. Sir William Petty," Political Arithmetic," in Collected Works, vol 1, p. 261. Part I 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, p. 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., p. 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., p. 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, p. 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., p. 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, p. 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., p. 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, p. 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, p. 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, p. 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., p. 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., p. 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., p. 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, p. 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, p. 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., p. 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., p. 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., p. 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. p. 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, p. 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, p. 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, p. 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, p. 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, p.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., p. 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, p. 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." Part 2 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, p. 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, p. 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.,p. 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, p. 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, p. 31, and Peter Ivanov, "Interview with John Lions", Unix Review, October, 1985, p. 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, p. 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, p. 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., p. 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, p. 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., p. 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, p. 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, p. 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, p. 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, p. 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, p. 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, p. 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, p. 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. -- Ronda Hauben write for email copy of Winter/Spring 1993 issue Amateur Computerist articles include Interview on Usenet and C News ronda@umcc.umich.edu Sir Francis Bacon and Shorter Hours Bill or ae547@yfn.ysu.edu Social Forces behind Usenet News From: edward.rice@his.com (Edward Rice) Newsgroups: alt.folklore.computers Subject: Pt 1/3: Early Days of Unix - Draft for Comment (pt 1 of 2) Date: Wed, 22 Dec 1993 13:50:14 RH> From: ae547@yfn.ysu.edu (Ronda Hauben) RH> computer science research and networking in the world. As early as RH> 1957, Bell Labs found they needed an operating system for their RH> inhouse computer center which was then running lots of short batch RH> jobs. Describing the situation facing the Labs, Victor Vyssotsky, who RH> had been involved the techanical head of the Multics project at Bell RH> Labs and later Executive Director of Research in the Information RH> Systems Division of AT&T Bell Labs, explains, " We just couldn't take RH> the time to get them on and off the machine manually. We needed an RH> operating system to sequence jobs through and control machine RH> resources." RH> The BESYS operating system was created at Bell Labs... Ummm... this reads (to me) as though Bell had the first demand for batch processing and the first need for a job monitor and invented the concept of an operating system. I would /never/ belittle the contributions Bell Labs made to computer science and data processing, but I think this is a generous overstatement. If you're going to give BESYS a big mention, it wouldn't hurt to throw in some discussion of FMS and IBSYS. RH> The collaborative project by GE, MIT and AT&T to create a computer RH> operating system that would be called Multics (1965-68) was to "show RH> that general-purpose, multiuser, timesharing systems were viable." Again, you ignore the larger context. DTSS and CTSS had already proven this point, and there were other (more significant, IMO) issues developed in the MULTICS effort. BTW, within the time period that Bell was involved as a participant, the correct name for the system mentioned above was "MULTICS," not "Multics." And isn't "UNIX (tm)" supposed to be all caps, and trademark-identified? RH> experience. So, despite popular myth, UNIX was not an accidental RH> discovery at all -- it evolved directly from experiences with academic RH> research." It wasn't a discovery at all. The existence of the planet Neptune was a discovery. The finding of the North American continent by Europeans was a discovery (for them). It's not like UNIX (tm), even in myth, was happened upon while people were browsing through a warehouse. RH> However, when Bell Labs pulled out of the Multics project they took RH> the Multics precursor off their GE 645 computer and put up GECOS... You might mention that GECOS was the standard operating system for the GE-600 series of computers, and was developed by General Electric. RH> "I don't think," Vyssotsky relates, "that RH> either of them was particularly fascinated by operating systems until RH> they found themselves cast back upon GECOS. They sort of got RH> interested in the subject out of self defense."(Ibid.) I like this quote a LOT. I plan to repeat it to a number of GCOSians I know. RH> In his account of this period, Dennis Ritchie writes, "Even before the RH> GE-645 Multics machine was removed from the premises, an informal RH> group, led primarily by Ken Thompson, had begun investigating RH> alternatives." Can you confirm that there was actually a GE-645 located on Bell premises? I had the distinct impression that this was /not/ the case. I was told by people in the USAF that Rome Air Development Center had the second Multics system, and they didn't get theirs until somewhat later. (It's possible that they got a system that Bell had returned, but this isn't my recollection of the story.) RH> generalized access to devices." (Ritchie, p. 1-2) This last item, however, was already being offered to most users of most systems. GECOS and IBSYS already provided users with significant device independence. RH> pg.60) Vyssotsky elaborates, "I don't think that Doug actually RH> contributed much of the programming, but for example, the appearance RH> of pipes in UNIX was clearly a result of Doug's discussions with Ken RH> and Dennis." (Ibid. ) Ken put them in, but "it was McIlroy who said, RH> "Look you ought to do it. Pipes, like most things in UNIX were not a RH> radically new idea. Co-routines had, after all, shown up in SIMULA by RH> the end of 1967."(Ibid.) I asked recently, in Alt.OS.Multics, whether anybody could identify a significant UNIX feature that had not worked its way from MULTICS to UNIX but had gone in the other direction. There's been /lengthy/ discussion of that issue for the last week or so, and the conclusion first leaned toward "pipes and cheap processes." However, Michael Padlipsky dug into his early papers and found that the concept of pipes was in fact sketched out in the original MULTICS design documentation. It was set aside during implementation, and UNIX first provided it. Later, a more advanced pipe implementation was added to the Multics command system late in the product's life. That leaves "cheap processes" as the major contribution which UNIX made to the systems world -- nobody could think of another real biggie. BTW, I realize this last point of mine may enrage a few UNIX boosters, and I suggest that they flame me over in Alt.OS.Multics rather than here. I'm /not/ familiar enough with UNIX to be able to properly respond to technical challenges to the above paragraph, but I believe I have correctly reported the gist of the discussion over there. From: dbarker@turing (Deryk Barker) Newsgroups: alt.folklore.computers Subject: Re: Pt 1/3: Early Days of Unix - Draft for Comment (pt 1 of 2) Date: Thu, 23 Dec 1993 00:46:20 GMT Edward Rice (edward.rice@his.com) wrote: : RH> From: ae547@yfn.ysu.edu (Ronda Hauben) [....] : RH> In his account of this period, Dennis Ritchie writes, "Even before the : RH> GE-645 Multics machine was removed from the premises, an informal : RH> group, led primarily by Ken Thompson, had begun investigating : RH> alternatives." : Can you confirm that there was actually a GE-645 located on Bell premises? I : had the distinct impression that this was /not/ the case. I was told by : people in the USAF that Rome Air Development Center had the second Multics : system, and they didn't get theirs until somewhat later. (It's possible that : they got a system that Bell had returned, but this isn't my recollection of : the story.) I heard, during my time on System M, that there was a 645 at Murray Hill. There also seem to be different versions of why Bell Labs pulled out of the project. One story I heard said that GE had agreed not to charge maintenance (a significant amount on mainframes in the old days) on the 645 as long as Bell were not using it for production work; Bell began to use it for production and GE told them to maintenance. According to what I heard this was a major factor in their decision to withdraw. Now, I just wish I could remember where I read this. : BTW, I realize this last point of mine may enrage a few UNIX boosters, and I : suggest that they flame me over in Alt.OS.Multics rather than here. I'm /not/ : familiar enough with UNIX to be able to properly respond to technical : challenges to the above paragraph, but I believe I have correctly reported the : gist of the discussion over there. I recall when the UNIXers would berate Multics for the amount of memory and horsepower it required. Of course this must have been versio 6 or 7 they were referring to. I'd like to see System V or BSD4.x support 200 users on a system with 4MB... -- Deryk. ================================================================= |Deryk Barker, Computer Science Dept. | Without music, life | |Camosun College, Victoria, BC, Canada | would be a mistake | |email: dbarker@camosun.bc.ca | | |phone: +1 604 370 4452 | (Friedrich Nietzsche).| ================================================================= From: tom_van_vleck@taligent.com (Tom Van Vleck) Newsgroups: alt.folklore.computers Subject: Re: Pt 1/3: Early Days of Unix - Draft for Comment (pt 1 of 2) Date: Wed, 22 Dec 1993 22:30:16 GMT Ed Rice commented on Ronda Hauben's article. I have several corrections, mostly to Ed's statements. 1. Ronda should make it clear that BESYS was a modified version of IBM's FMS. It had some nice features but was upward compatible with FMS. The BEFAP assembler introduced true macros (that could define macros) before IBM FAP had that ability. > BTW, within the time period that Bell was involved as a > participant, the correct name for the system mentioned above was "MULTICS," > not "Multics." 2. Wrong. The system's name was always mixed case. > Can you confirm that there was actually a GE-645 located on Bell premises? I > had the distinct impression that this was /not/ the case. I was told by > people in the USAF that Rome Air Development Center had the second Multics > system, and they didn't get theirs until somewhat later. (It's possible that > they got a system that Bell had returned, but this isn't my recollection of > the story.) 3. Wrong again. I can confirm that there was a 645 at BTL Murray Hill. When the Project MAC drum went down, we flew down to use the MH machine. Bell Labs folks generated GECOS input tapes on CTSS using the 636TAP facility, sent them to BTL via a 7711 link, ran jobs there, transmitted the output tape back to MAC where it was input to CTSS, and then debugged the result using the GEBUG command. It is true that the BTL machine probably didn't run a Multics timesharing service much; Bell dropped out of the development effort in April 1969, and service use of the system began at MIT in October. The RADC machine was not installed until August 1970, according to the chronology I can piece together. From: dp@world.std.com (Jeff DelPapa) Newsgroups: alt.folklore.computers Subject: Re: Pt 1/3: Early Days of Unix - Draft for Comment (pt 1 of 2) Date: Thu, 23 Dec 1993 05:41:28 GMT In article <756608561.AA07926@clone.his.com>, Edward Rice wrote: >I asked recently, in Alt.OS.Multics, whether anybody could identify a >significant UNIX feature that had not worked its way from MULTICS to UNIX but >had gone in the other direction. There's been /lengthy/ discussion of that >issue for the last week or so, and the conclusion first leaned toward "pipes >and cheap processes." However, Michael Padlipsky dug into his early papers >and found that the concept of pipes was in fact sketched out in the original >MULTICS design documentation. It was set aside during implementation, and >UNIX first provided it. Later, a more advanced pipe implementation was added >to the Multics command system late in the product's life. That leaves "cheap >processes" as the major contribution which UNIX made to the systems world -- >nobody could think of another real biggie. > There were other OS's that featured cheap processes around the time of unix's spawning -- ITS jobs were also "cheap", and users could have (for the day) lots of them. ITS even provided real controls for them (which was later adopted by the BSD folks -- right down to the choice of ^Z -- tho they never adopted the naming ability, settling for numbered.) You couldn't easily get the command interpreter to force two processes to communicate, but the underlying system did have the virtual device (the job: boj: pair) needed for this, but it was never directly available in DDT, a pity. From article <2dla2c$kfi@garnet.msen.com>, by brain@garnet.msen.com (Jim Brain): Subject: Re: The Original UNIX Newsgroups: alt.folklore.computers References: <2dla2c$kfi@garnet.msen.com> From article <2dla2c$kfi@garnet.msen.com>, by brain@garnet.msen.com (Jim Brain): > I want to talk to anyone who worked on any version of UNIX that ran > on PDP computers ... Unix was originally coded on a PDP-7 or 9 (I forget which, but one of the single accumulator 18 bit word machines), and written in assembly language. That machine had only a rudimentary memory manager, so process images were swapped to and from disk (most likely a fixed head disk). The second version was written for a PDP-11 (probably an 11/20), a 16 bit minicomputer with 48K (sometimes 56K) bytes of core memory, and no memory management hardware. This version of UNIX was written in the then-new language called C. It used swapping. No versions of UNIX were ever created for other PDP computers. In theory, the original PDP-7 or 9 version should have been trivial to port to a PDP-15 (also an 18 bit machine) or the earlier PDP-4. A port to a PDP-5, PDP-8 or PDP-12 would have been very tricky (those had 12 bit words and at most 32K words of memory). A port to a PDP-6 or PDP-10 would have been fun -- those had 36 bit words and nice big memories. The trouble with all of these other PDP machines is that they didn't fit C's addressing model very well -- for example, the PDP-10 with its 36 bit word offered equally fast support for both 6 and 9 bit bytes packed 6 or 4 per word. > ... I am inquiring about how the UNIX I handled pages of memory, > if the OS did software management. Basically, I want to know if > the original K and R era UNIX machines had big memeories, MMU's and > how the OS handled it if they did not. The next step was to use a PDP-11/45. This still limited processes to 64K each (well, you could go out on a limb and use 64K of code separated from 64K of data, but that was messy). It had a memory management unit that allowed the machine to address a total of 256K bytes, where each 64K address space was made up of 8 segments of up to 8K bytes each. This version of UNIX used a 3 segment model of memory for each process -- a code segment (shared and reentrant), a data segment (private, statically allocated, and initialized at load time, and a stack segment, initialized with argv and argc. The data segment could be expanded (by sbrk) to create space for such things as the heap used by malloc. Segments were not paged! In theory, it would have been possible to treat each 8K segment as a page, but this wasn't done. Instead, UNIX segments were made of one or more adjacent 8K segments (the last of which might be only partially allocated), and the whole segment was treated as a unit for swapping purposes. The result was that fork, for example, was quite easy to implement; you just swap out the data and stack segments, then use the copy in memory as the skeleton of the newly created process. The first version of UNIX I know of that used demand paged virtual memory was BSD UNIX on the VAX. The design of the UNIX fork primitive that had seemed so elegent in a swapping environment suddenly became a real problem, because you can't duplicate a segment without copying the pages from disk to main memory. Eventually, a fast solution to this was implemented, involving lazy copying where only pages that were actually modified got copied, and this solution is why UNIX now performs reasonably well in demand paged virtual memory environments. Doug Jones jones@cs.uiowa.edu From: avg@sprintlink.net (Vadim Antonov) Newsgroups: alt.folklore.computers Subject: Re: The Original UNIX Date: 3 Dec 1993 07:36:32 GMT I cannot tell about accuracy of pre-v6 Unix descriptions, but.. In <1993Dec3.034115.20370@news.uiowa.edu>, Douglas W. Jones,201H MLH,3193350740,3193382879 (jones@pyrite) wrote: : The next step was to use a PDP-11/45. Nah. PDP-11/34 and PDP-11/40. : This still limited processes to : 64K each (well, you could go out on a limb and use 64K of code separated : from 64K of data, but that was messy). It was impossible in PDP-11s w/o separate I/D space (11/34 and 11/40). Separate code and data space on 11/45 and later models was quite natural and straightforward. The only problem was necessity to keep two copies of binaries for old and new PDPs. MNOS RL 1.2 (my v6-based v7-compatible :-) and BSD 2.9 also had code overlays (i.e. they can flip one or more pages on procedure calls) effectively allowing to build real large programs. DEMOS 2/P (P is for PDP) inherited BSD 2.9 overlays but after some heavy hacking page flipping was accelerated by factor of 10 which made them a practical alternative. As a matter of fact, practically all BSD-derived utilities in DEMOS 2/P were ported from BSD 4.1 (a VAX system -- including real large things like INGRES v7). : It had a memory management unit : that allowed the machine to address a total of 256K bytes, where each : 64K address space was made up of 8 segments of up to 8K bytes each. 11/45 had two 64Kb spaces (one is r/o) and could address up to 248Kb RAM. Later models (11/70 etc) could address up to 4Mb (by extending the memory bus to 22bits) but 64+64 limit was still there. Actually there was a Soviet-made machine, SM-1420, which could address up to 2Mb but had no separate I/D! : This : version of UNIX used a 3 segment model of memory for each process -- : a code segment (shared and reentrant), There was a program format with *writeable* and no shared code; some programs actually used it (ULISP...) : a data segment (private, statically : allocated, and initialized at load time, and a stack segment, initialized : with argv and argc. The data segment could be expanded (by sbrk) to : create space for such things as the heap used by malloc. Stack segment was expanded downwards automagically on protected page interrupts. On 11/40 and 11/34 there was no way to recover from that interrupt in general case and some instructions (like mov -(sp),-(sp)) were "prohibited". Later CPUs have fixed that problem with a special register (control reg 2 :-). : Segments were not paged! In theory, it would have been possible to treat : each 8K segment as a page, but this wasn't done. Instead, UNIX segments : were made of one or more adjacent 8K segments (the last of which might be : only partially allocated), and the whole segment was treated as a unit for : swapping purposes. Made absolutely no sense to *page* programs spread over only 8 pages. For all practical purposes all those pages were in active set. Later versions of Unix actually swapped small processes as whole pieces for the very same reason. : The result was that fork, for example, was quite easy : to implement; you just swap out the data and stack segments, then use the : copy in memory as the skeleton of the newly created process. Actually, fork was a side-effect of swapping :-) Somewhere i read that initially it was thought as "swap in but don't delete image in swap area". : The first version of UNIX I know of that used demand paged virtual memory : was BSD UNIX on the VAX. The design of the UNIX fork primitive that had : seemed so elegent in a swapping environment suddenly became a real problem, : because you can't duplicate a segment without copying the pages from disk : to main memory. There also was an issue of rotten VAX MMU design -- it lacks functionality necessary for straight-forward COW implementation. The realistic COW for UNIX appeared in NET BSD (derived from Mach). : Eventually, a fast solution to this was implemented, : involving lazy copying where only pages that were actually modified got : copied, and this solution is why UNIX now performs reasonably well in : demand paged virtual memory environments. Depends on which Unix :-) Later-age BSDs do it reasonably well. --vadim From: jones@pyrite (Douglas W. Jones,201H MLH,3193350740,3193382879) Newsgroups: alt.folklore.computers Subject: Re: The Original UNIX Date: Fri, 3 Dec 1993 14:42:05 GMT From article <2dmqa0$bu4@news.sprintlink.net>, by avg@sprintlink.net (Vadim Antonov): > > Made absolutely no sense to *page* programs spread over only 8 pages. > For all practical purposes all those pages were in active set. On the contrary, the Berkeley Timesharing System on the SDS 940 had 8 pages per address space, with demand paged memory management, and it worked quite well. Of course, that was 1967-1968! Doug Jones jones@cs.uiowa.edu From: hoffman@cs.pitt.edu (Bob Hoffman) Newsgroups: alt.folklore.computers Subject: Re: UNIX Folklore Questions Date: 7 Jun 1995 15:40:32 GMT In article <3r4cl4$nef@eccdb1.pms.ford.com>, cpierce1@cp500.fsic.ford.com (Clinton Pierce (R)) writes: |> 1. The "vi" editor uses "hjkl" for cursor movement. It's been explained |> to me that one of the early tubes that vi was run on actually had |> "^h^j^k^l" mapped to cursor movement and that vi was simply left that way |> (minus the control key). What was the name of that early terminal? There are several old terminals that conform to that pattern: Soroc IQ-120 Lear Seigler ADM-3A Televideo 9xx |> 5. How big (estimation) were earlier UNIX source/binary distributions? |> For a full load of UNIX, how much disk was required? (For contrast against, |> say, AIX where a full load can easily exceed 500MB). All of Sixth Edition Unix, binaries and sources, fit onto one 800bpi 9-track magtape, so that means it had to be less than 20 MB. We used to keep the entire kernel source on one RK05 pack (2.5 MB). ---Bob. -- Bob Hoffman, N3CVL University of Pittsburgh Tel: +1 412 624 8490 hoffman@cs.pitt.edu Department of Computer Science Fax: +1 412 624 8854 Newsgroups: alt.folklore.computers From: enf1@ellis.uchicago.edu (Eric Fischer) Subject: Re: UNIX Folklore Questions Date: Wed, 7 Jun 1995 18:05:25 GMT Clinton Pierce "cpierce1@cp500.fsic.ford.com" (R) writes, >1. The "vi" editor uses "hjkl" for cursor movement. It's been explained >to me that one of the early tubes that vi was run on actually had >"^h^j^k^l" mapped to cursor movement and that vi was simply left that way >(minus the control key). What was the name of that early terminal? The Televideo 925 is one such terminal; there may be others too. I've read that vi was originally written for the ADM-3a but I've never used one of those so I have no idea how its keyboard is set up. Remember too that hjkl was not in the original version of vi -- the original cursor movement keys were space/backspace/-/return, and you can still use them (I do) in spite of the fact that hjkl has been the suggested set of movement keys for a long long time. Eric enf1@ellis.uchicago.edu Newsgroups: alt.folklore.computers From: dik@cwi.nl (Dik T. Winter) Subject: Re: UNIX Folklore Questions Date: Wed, 7 Jun 1995 19:52:25 GMT In article <3r4cl4$nef@eccdb1.pms.ford.com> cpierce1@cp500.fsic.ford.com (Clinton Pierce (R)) writes: > 1. The "vi" editor uses "hjkl" for cursor movement. It's been explained > to me that one of the early tubes that vi was run on actually had > "^h^j^k^l" mapped to cursor movement and that vi was simply left that way > (minus the control key). What was the name of that early terminal? Not a tube. It was the original ASR 33 I think. ... > 5. How big (estimation) were earlier UNIX source/binary distributions? > For a full load of UNIX, how much disk was required? (For contrast against, > say, AIX where a full load can easily exceed 500MB). Depends a bit. At one stage when Unix could use both a fixed and a removable disk, the fixed disk was 2MB the removable was 5MB. That is also the original reason for the split between /bin and /usr/bin. -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924098 home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik@cwi.nl From: cpierce1@cp500.fsic.ford.com (Clinton Pierce (R)) Newsgroups: alt.folklore.computers Subject: Re: UNIX Folklore Questions Date: 7 Jun 1995 20:17:51 GMT Whew! That was fast! I got several replies in E-Mail. The most complete and authoritative came from Tom Duff, here it is: To: cpierce1@cp500.fsic.ford.com Date: Wed, 7 Jun 1995 15:04:11 EDT Subject: Re: UNIX Folklore Questions 1) The terminal with ^h^j^k^l cursor motion was the Lear-Seigler ADM1 (also ADM2, ADM3, ADM3a, etc.). The arrows on the hjkl keys of their keyboards, rather than the motion codes they accepted, probably suggested the vi motion commands. (What I mean is that even if the codes were different, the arrows being on the hjkl keys probably would have decided the matter.) 2) The slash was picked because its easy to type, (corner of the keyboard, no shift) and carries no other obvious semantic weight. 3) All I know about Space Travel is that it drew the sky as seen from a space ship, rather than showing the ship on a map as in Spacewar. 4) Multics is certainly still in use, although I'd be very surprised if Honeywell still made Multics machines. Don't know where. 5) Here are the sizes of various early UNIX distributions, calculated by running du over our archive copies (sizes in kilobytes): 1804 v5 1457 v6 8646 v7 31887 v8 893 32v 40200 4.2bsd The sizes of the actual distribution media are mostly slightly larger than these numbers. For example, v5 was distributed as an rk05 file system image whose exact size was 2436K bytes, (4872 blocks of 512 bytes each), but that included the free list, i-list and other file system overhead. -Tom Duff -- ----------------------------------------------------------------------o------ Clinton A. Pierce | "If you rush a Miracle Man | \ / \ / cpierce1@cp500.fsic.ford.com| you get rotten miracles." | \ G / DCI, Inc. on loan to Ford. | --Miracle Max, The Princess Bride | / \ / \ ------------------------------------------------------------------Freemason-- From: tom_van_vleck@taligent.com (Tom Van Vleck) Newsgroups: alt.folklore.computers Subject: Re: UNIX Folklore Questions Date: Wed, 07 Jun 1995 13:42:23 -0700 cpierce1@cp500.fsic.ford.com (Clinton Pierce (R)) wrote: >4. Is MULTICS still used? Where? Hello Clinton, Multics (note correct case) is still used at Ford Motor Co, US National Security Agency, Canadian Department of Defence, and a few other sites. See http://www.best.com/~thvv/sites.html. That page will lead you to a lot of other info about Multics as well. I believe the answer to the question about / is that it was an unshifted character in the same place on all terminal keyboards in use by the UNIX creators. Multics used > but this required a shift: extra effort & chance for error. Newsgroups: alt.folklore.computers From: alderson@netcom.com (Richard M. Alderson III) Subject: Re: UNIX Folklore Questions Date: Wed, 7 Jun 1995 22:16:15 GMT In article dik@cwi.nl (Dik T. Winter) writes: > >In article <3r4cl4$nef@eccdb1.pms.ford.com> cpierce1@cp500.fsic.ford.com >(Clinton Pierce (R)) writes: >>1. The "vi" editor uses "hjkl" for cursor movement. It's been explained to >>me that one of the early tubes that vi was run on actually had "^h^j^k^l" >>mapped to cursor movement and that vi was simply left that way (minus the >>control key). What was the name of that early terminal? >Not a tube. It was the original ASR 33 I think. Now that makes no sense at all. "vi" was created by Bill Joy as a *v*isual *i*nterface to "ed" that would work on display terminals. Why, other than hack value (like the terminal type "printing" in TECO EMACS) would it have been modeled on a 33? -- Rich Alderson You know the sort of thing that you can find in any dictionary of a strange language, and which so excites the amateur philo- logists, itching to derive one tongue from another that they know better: a word that is nearly the same in form and meaning as the corresponding word in English, or Latin, or Hebrew, or what not. --J. R. R. Tolkien, alderson@netcom.com _The Notion Club Papers_