Softpanorama
(slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Google   


Slightly Skeptical Unix History with Some Emphasis on Scripting

News

Recommended Links

Recommended Articles

Multix

CTSS

Chronology Creators Selected Homepages

Early Unix

Early Unix source Classic papers from Bell Lab Portraits of Open Source Pioneers History of Unix shells

BSD

Sun OS and Solaris

Linux
Shells pipes C Unix filesystem System calls ksh A Quarter Century of UNIX review  
Ken Thompson Dennis Ritchie Douglas McIlroy. John Mashey Steve Bourne Bill Joy David Korn Etc
The book Life with Unix by Don L

The book Life with Unix by Don Libes and Sandy Ressler is fascinating reading for anyone interested in Unix in general and scripting history in particular. It covers a lot of the history, interactions, etc. Much in the present section is summarized from this book. Some interesting info is in UNIX FAQ.

As most of the readers know Unix history goes back to 1969 and the famous "little-used PDP-7 in a corner" on which Ken Thompson, Dennis Ritchie (the R in K&R), and others started work on what was to become Unix.

But what is less known and appreciated is the fact that Ken Thompson was also the author of the first UNIX shell and that concepts of this shell greatly influenced the subsequent work of John Mashey and Stephen Bourne. Influenced to the extent that John Mashey actually objected to calling his shell Mashey shell considering it as a direct extension of Thompson shell.

The name "Unix" was intended as a pun on Multics (and was written "Unics" at first, for UNiplexed Information and Computing System). As Ch 9 of the Netizens Netbook  (   On the Early History and Impact of Unix Tools to Build the Tools for a New Millenium) aptly stated:

When AT&T made the decision to pull out of the Multics collaboration, they took the research operating system off their GE 645  computer and put up the GECOS operating system. Though GECOS was adequate  for applications, it was "nowhere near as satisfactory if you were trying  to do things that were technically difficult and imperfectly defined,"  explained Vyssotsky, "which is the main task of research."(23)

 For the pioneering work of Bell Labs research programmers like Ken Thompson and the research purposes of the Labs, an operating system more  like what Multics had promised was needed. Along with the advantages of  immediate feedback which time-sharing provided, the Bell Labs researchers  wanted to continue the ability to work collaboratively which time-sharing  had made possible.

"What we wanted to preserve," one of the creators of Unix, Dennis  Ritchie writes, "was not just a good programming environment in which to  do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close  communication."(24)

Ritchie describes how an informal group led by Thompson had begun  investigating alternatives to Multics before the GE-645 Multics machine  had been removed from the Labs.(25) 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, Thompson found a little used PDP-7 computer. According to Vyssotsky, the orphaned PDP-7 computer was a machine, "more in the class of a Commodore 64 than the class of a PC-AT."(26)

For the first 10 years, Unix development was essentially confined to Bell Labs and most scripting related work was also done in NJ. The initial versions of Unix were labeled "Version n" or "Nth Edition" (of the manuals) and some milestones in shell history are directly related to particular Unix releases.  Major early Unix implementation were for DEC's PDP-11 (16 bits) which was so tiny by today's hardware standards (typical configuration were limited to 128K memory, 2.4M disc, 64K per-process limit (inc the kernel)) and similar configurations can be found only in palmtop computers and top electronic watches ;-). The fact that they managed to created pretty powerful shells for such a computer is nothing but simply amazing and attests tremendous ingenuity of early creators of Unix extremely well.

There several questions that are usually swiped under the carpet when writing about Unix history

Multics seems to be a dramatically under-appreciated predecessor of Unix -- all key Bell Labs folks that participated in Unix development were trained in Multics and borrowed a lot from this system including the key idea of the hierarchical filesystem, many commands (ls, ps, etc) as well as the key idea of using high level language for writing OS. C language was essentially a simplified dialect of PL/1 with BCPL address arithmetic (see also links in Multics Home page). For example Thompson in recent interview stated:

Thompson. The one thing I stole was the hierarchical file system because it was a really good idea—the difference being that Multics was a virtual memory system and these "files" weren't files but naming conventions for segments. After you walk one of these hierarchical name spaces, which were tacked onto the side and weren't really part of the system, you touch it and it would be part of your address space and then you use machine instructions to store the data in that segment. I just plain lifted this.

By the same token, Multics was a virtual memory system with page faults, and it didn't differentiate between data and programs. You'd jump to a segment as it was faulted in, whether it was faulted in as data or instructions. There were no files to read or write—nothing you could remote—which I thought was a bad idea. This huge virtual memory space was the unifying concept behind Multics—and it had to be tried in an era when everyone was looking for the grand unification theory of programming—but I thought it was a big mistake.

The good, but biased (bashing of Multics is completely misguided and from the point of view of Unix history completely stupid) description of origins and history of UNIX can be found at Origins and History of Unix, 1969-1995

A notorious ‘second-system effect‘ often afflicts the successors of small experimental prototypes. The urge to add everything that was left out the first time around all too frequently leads to huge and overcomplicated design. Less well known, because less common, is the ‘third-system effect’; sometimes, after the second system has collapsed of its own weight, there is a chance to go back to simplicity and get it really right.

The original Unix was a third system. Its grandfather was the small and simple Compatible Time-Sharing System (CTSS), either the first or second timesharing system ever deployed (depending on some definitional questions we are going to determinedly ignore). Its father was the pioneering Multics project, an attempt to create a feature-packed ‘information utility’ that would gracefully support interactive timesharing of mainframe computers by large communities of users

... ... ...

Information about the history of Linux, one of the most recent Unix re-implementations, can be found at Nikolai Bezroukov. Portraits of Open Source Pioneers. Ch 4: A Slightly Skeptical View on Linus Torvalds

See also my review of  A Quarter Century of UNIX

Old News ;-)

[Dec 15, 2007] Unsung innovators Robert Kahn, the 'stepfather' of the Internet

One big moment that isn't often recognized, he says, is when DARPA -- working with a number of contractors, including Collins Radio, BBN and others -- demonstrated the first successful TCP connection traversing three dissimilar but interconnected networks. November 22, 2007, marked the 30th anniversary of that demo.

... ... ..

After his stint at DARPA, Kahn didn't stop pioneering. In 1986, he started the Corporation for National Research Initiatives (CNRI). The Reston, Va.-based organization helps shepherd various technology infrastructure projects. With funding from the National Science Foundation and DARPA, the CNRI helped create the first Gigabit networks operating at speeds above 1 billion bits per second. The CNRI also funded the development of Mosaic, the first popular Web browser, at the University of Illinois.

 

[Sep 14, 2006] ONLamp.com Confessions of a Recovering NetBSD Zealot by Federico Biancuzzi

...Charles M. Hannum: I'm one of the creators of the NetBSD Project, and served as its de facto technical lead for a long time. I was also involved in creating the NetBSD Foundation, and served as its president and chairman of the board. (Note: I was never the Foundation's secretary or treasurer.)

How did the NetBSD Project start?

Charles M. Hannum: The four people who started NetBSD were Chris Demetriou, Adam Glass, Theo de Raadt, and me. At the time, Chris and Adam were attending Berkeley and close to graduating. Theo was working for a living. I was doing other things. Chris is still sort of around, but doesn't really do anything; Adam went to work at Microsoft and is now lost to us; and we all know about Theo. There is some info in the NetBSD entry on Wikipedia.

I think the most striking difference between late 1992 and today is that there really was no "web." The original software had been released, and some of us had started using it for small (non-graphical!) websites, but it was still very much a hobbyist thing. More people were getting "email accounts" of various types, but penetration of the internet into homes was still quite low. Even so, this was near the end of the NSFNet era, and there were increasing problems with the backbone being overloaded. There were also some as-yet-undiscovered problems with TCP flow control which caused additional performance problems. And lastly, nobody had started taking network security seriously.

On the open source side, you could liken it to the Stone Age. The operating systems (primarily 386BSD 0.1 and Linux 0.12) were nothing to write home about; they were buggy and incomplete. There were no "desktop" packages or "office" suites of any significance. (I actually ported Applixware to NetBSD under contract, because a certain blue company wanted it for their thin clients that ran NetBSD.) Development of X was hampered by the dissolution of the X Consortium and a vacuum of leadership there. We discovered later that GCC development was also being hampered by mismanagement (since fixed).

What I'd like to stress is that there was no Dummies Guide to Starting an Open Source Project. The term "open source" wasn't even being used yet, but that's beside the point. We were the first big collaborative project to use a version management system. (As examples, Linux used none, and most GNU software at best used "backup files" for version management.) There were no previous successes--or really even significant failures--to look at for guidance about how to organize the project. So we made it up.

I want to elaborate on the point about network security a little. Keep in mind that, in this time frame, most people were still using rlogin and unencrypted telnet. Buffer overflows were rampant. I (and other people) had already started doing experiments with subverting web sites; we all knew it was possible then, but nobody cared. It was several years before most people saw the writing on the wall and started clamping down access to central repositories and whatnot. Even today, most software distributions on the net (and this includes NetBSD) are not signed.

The primary reason for starting NetBSD at that time, ironically enough, is that there was a perceived lack of management in 386BSD. The actual 386BSD release only ran on a handful of systems, and was quite buggy. There was a rapidly growing community around it nonetheless, and many people had contributed patches. However, 386BSD's leader simply vanished. Nobody had any idea what he was doing, or whether he was even looking at the patches or working on another release. Eventually we decided that the only answer was to make a go of it ourselves--that's right, it all started with a fork.

Would you like to talk about the fork that originated OpenBSD?

Charles M. Hannum: No.

Since it came up in the /. thread, though, I would like to make one correction. It's widely claimed that I'm "the one" who ejected Theo from the NetBSD community. That is false. At that time in NetBSD's history, Chris G. Demetriou was playing the role of alpha male, and I wasn't even given a choice. I was certain it was going to bite us in the ass. I think the question for historians is not whether it did bite us in the ass, but how many times and how hard.

Why did you focus on portability?

Charles M. Hannum: At the very beginning, this was not actually a focus. It quickly became apparent that there were a large number of people interested in NetBSD (and open source OSes in general) who were currently on non-x86 platforms. Remember that this was still the 80486 era--PC processors weren't very good. Most "workstation"-class computers were based on something else--a myriad of Motorola 68k and 88k, SPARC, POWER, etc. On the HP9000/300 and SPARC platforms, we also had the advantage of access to code already written--though in both cases the integration was complex, and the code only supported a handful of systems at first.

I was also hanging out (and occasionally doing some work) at the Free Software Foundation, where there were a lot of HP9000/300s--running MORE/BSD, which had long since been abandoned. So I set out to get NetBSD running on these machines. Just getting a cross compiler working at the time was quite a bear, but it didn't take too long before these machines were all running NetBSD.

Yes, several of the earliest NetBSD development systems were owned by the Free Software Foundation.

With working 68k support in hand, we quickly spawned Amiga and Mac development groups. I then helped Theo get the SPARC support from LBL integrated. The whole thing snowballed.

Of course, the fact that you've ported the system to tons of machines does not mean you have good portability. We were still in the days of "copy and edit"--and so, for example, although the Amiga and Mac code [was] heavily cribbed from the HP9000/300 code, they were separate and had different features and bugs. Trying to fix bugs in this environment was making me crazy--and wasting a lot of time--and eventually I just started smashing the code together at high speed and sifting out the common parts. Other developers followed ("lead by example" works sometimes), and so this led into our global thinking about portability architecture, shared device drivers, etc. Oddly enough, Microsoft was working on similar ideas at the same time, in the development of Windows NT.

How was the relationship with hardware manufacturers at that time?

Charles M. Hannum: Terrible. We rarely got documentation from anyone. I actually wrote a lot of device driver code by guessing what the device was supposed to do. (Lots of previous experience reverse-engineering code helped there, I'm sure.) We had severe problems trying to deal with things like the "programmable" Adaptec SCSI controllers that became very popular; it was so bad that I was honestly talking about staging a sit-in at Adaptec HQ, and probably should have done it.

There were some notable exceptions, though. It took a while, but NCR, and later LSI, finally came around and dropped a heaping pile of (fairly good) documentation on me for their SCSI controllers. We did eventually get some material out of BusLogic, but only for their older "heavyweight" controllers (what we call "bha"<-- should bha be in code style? -->).

Intel, for its part, has been pretty good about putting CPU and chipset documentation online for the last several years, which I applaud, but their networking documentation (both wired and wireless) has been extremely poor. The strangest part of the Intel story was when the i82559 manual became restricted, even though it was substantially identical to the i82557 manual [that] had been published in their networking databooks earlier. Most other companies producing Ethernet controllers have been decent to us, except for Broadcom and Marvell, which have [each] been a 100% loss. Wireless vendors have generally been a tremendous annoyance, generating excuses but no documentation--I think Atmel and Realtek are the only exceptions.

We got some scattered documentation from other companies--e.g. Ensoniq and Realtek--but it's sometimes been incomplete and very difficult to make sense of.

Fortunately we didn't have to deal with most of the PC video card circus ourselves; XFree86 and now X.org have taken care of that.

What type of relationship did you have with the license? Is this relationship changed during the time?

Charles M. Hannum: Most of us had a very strong distaste for the so-called "virus" clause in the GPL, and this is the primary reason we did not adopt it. There was also some thinking that CSRG (Berkeley) and the X Consortium had been successful with leaner, looser licenses, so why bother. In retrospect I think this was naive; if you look at the history, you'll see that neither CSRG nor the X Consortium were really successful in getting third parties to contribute back most of their changes--and so what we really got in both cases was a long list of derived but very different, and often incompatible, systems.

Linux has not been wholly successful in this either, and today there are myriad distributions which are subtly incompatible. However, they definitely did better.

If I were doing it again, I might very well switch to the LGPL. I'll just note that it didn't exist at the time.

How much did the (in)famous BSD lawsuit hit NetBSD code base and popularity?

Charles M. Hannum: There was a lot of FUD around this issue--some of it from Linus, actually--and it did cause us some problems. The reality is that we had a signed agreement with USL that essentially said we had to upgrade certain files from their Net/2 versions to 4.4-Lite, and not distribute some other files at all (which we never used in the first place). We were in the process of moving to a 4.4-Lite base anyway, so this had virtually no impact on development. It did, however, delay making our CVS history public--far longer than it should have--because we needed to remove some of that early history in order to meet the conditions of the agreement.

I've never seen the similar agreement between USL and FreeBSD, but my understanding from what I've heard is that it is quite different. This caused some more FUD to be generated, because apparently what we did would not have met the terms of FreeBSD's agreement.

Had Novell not bought USL when it did, it's unclear to me how this would have panned out. I've never been able to convince myself that Berkeley was in the "right." However, Novell put a swift end to the suit, the agreement is very clear, and nobody cares about that early code history any more--so this is all water under the bridge.

Have you read the legal settlement after it was recently made public? Any surprise?

Charles M. Hannum: Yes, I read it. The first thing to note is that this agreement was with Berkeley. We executed a separate agreement with USL (which has not been made public), and that is what governs our relationship. There were no surprises when we read the settlement, but it wasn't really relevant to us.

If you had a separate agreement, you were free to work on your software without problems. Do you think that the general and chaotic FUD about the lawsuit hit you even if you had already solved the problem?

Charles M. Hannum: Absolutely it hurt us. A lot of people (and I don't want to be divisive, but honestly they were mostly Linux proponents, including Linus himself) spread FUD for years about BSD systems being "unsafe"--even after the UCB/USL lawsuit was settled. The fact is that there was no danger in using NetBSD in a product, and a number of companies did so.

How was NetBSD funded during these years? Who managed these funds and how?

Charles M. Hannum: In the beginning, we just put the machines on the UCB and MIT AI lab networks, because we had access to do that and nobody minded. The server equipment was purchased by Chris Demetriou. The project per se had no "funds." Later on, colo space and machines were donated by a variety of organizations (NASA, iki.fi and hut.fi, etc.), and again no money changed hands. Later on we started collecting donations to purchase hardware; colo space was (and is) still donated, primarily by ISC now.

As far as funding marketing work, such as conference appearances and merchandise, most of that was paid for by me, d.b.a. The NetBSD Mission. A fraction of the cost of the Comdex booths was paid for by LinuxMall. Most of the other conferences gave us "free" booths--that means the conference itself didn't charge for the booth, but we (I) still had to pay for everything else (carpeting, furniture, shipping or renting equipment, union labor, etc.). Producing CDs and T-shirts to give away (we tried selling them at conferences, but that didn't go over well, especially at Comdex) was also fairly expensive; it adds up quickly.

Do you have any regret about the way NetBSD promoted the project and did advocacy at conferences around the world?

Charles M. Hannum: No. Unfortunately there is no longer a concerted effort to do this, and particularly to give away copies that people can try. Frankly I'm not sure (and wasn't even then) that giving away copies to install on a PC will impress people much anyway, given that NetBSD's installer is still very primitive compared to the Linux distros. Many reviews have focused on this and lambasted NetBSD for it.

[July 5, 2005 ] LinuxPlanet - Reviews - Classic UNIX Programming Text Updated - Interview with Steve Rago, Co-author of Advanced Programming in the UNIX Environment


Ibrahim Haddad
Tuesday, July 5, 2005 12:18:35 PM

After 13 years, Addison-Wesley has published an update to a classic UNIX System programming text: Advanced Programming in the UNIX Environment. After the death of the original author, Rich Stevens, in 1999, it was difficult to find someone to tackle a project this big. We recently caught up with the co-author, Steve Rago, to get a behind-the-scenes look at this project.

Steve, you were one of the developers of UNIX System V Release 4. Can you tell us more about your background and contributions and how you became the co-author of the second edition of one of the most popular UNIX books?

After getting a BE and MS from Stevens Institute of Technology, I got a job working in the UNIX System V Development Laboratory at AT&T Bell Labs. I had wanted to work at Bell Labs, where my father worked, since I was 12 years old. Ironically, a year after joining Bell Labs, AT&T reorganized us into a different business unit, so we weren't Bell Labs anymore. I started out working on System V Release 2.0, helping to maintain and benchmark the VAX port. Eventually, I worked on networking software, which led me to STREAMS. After most of the original STREAMS developers completed the port of Dennis Ritchie's streams to System V Release 3, I ended up taking over responsibility for it somewhere between SVR3.1 and SVR3.2. During SVR4 development, I enhanced the STREAMS mechanism, converted the open file table to use dynamically-allocated memory (thus removing the historic NOFILE limit to a UNIX process's open files), moved the poll(2) system call under the vnode framework, and did a lot of general clean-up work in the kernel.

I spent 7 years at AT&T, then left for a small start-up company just before AT&T created USL. I worked on file systems, writing one that transparently compressed and uncompressed files on the fly, and another that sped up system throughput and used an intent log for fast recovery. These were eventually ported to the SCO OpenServer V UNIX System. Then I developed stackable file systems for commercial UNIX systems. The file system business evolved into a file server business, and then the company was bought by EMC, where I still work as a manager of one of the file system groups. In total, I have about 20 years of UNIX programming experience, both kernel-level and user-level.

Since I was involved in the review of the first edition of APUE, Addison-Wesley contacted me for suggestions for candidates to update the book. I wanted the book to be updated properly, the way Rich would have wanted, and to honor his memory, so I volunteered for the project.

Why did you update APUE and how does the second edition of APUE differ from the first edition? Where did you have the most changes?

Rich's book is a classic, but the world has changed a lot since it was first published in 1992. Standards have evolved, UNIX system implementations have come and gone, and technology has advanced significantly. I added a chapter on sockets, two chapters on threads, and totally rewrote the chapter on communicating with a printer to reflect the technological advancement from a serial PostScript printer to a network-attached PostScript printer. I removed the chapter that dealt with modem communication, but I made it available on the book's Web site. Other than the printer chapter, Chapter 2 shows the most change. It deals with standards, and these have changed significantly over the past 13 years. One other major change is that I shifted the implementation focus from 4.3+BSD and SVR4 to more contemporary platforms: FreeBSD 5.2.1, Linux 2.4.22, Mac OS X 10.3, and Solaris 9. (The source code for the examples is also available on the book's Web site.)

Daemon News Seen it all before

SCO - Ancient UNIX

The Unix Heritage Society

Open Resources Twenty Years of Berkeley Unix

Stanford Computer History Pages:

Feature OMU - One Man Unix

In the late 1970s and early 1980s (the good old days of "hobby computing") before the IBM PC and its clones took over the world Steve Hosgood built a Unix clone at home. He was used to V7 Unix on the PDP-11 at university and wasn't keen to step backwards 10 years to the technology of CP/M and BASIC programming.

He did not know that eight years later a guy called Linus Torvalds was going to think the same thoughts and do much the same things. The big difference was that he was in the right place and the right time and had internet connectivity - Steve didn't have any of these advantages!

Daemon News 199903 A History of UNIX before Berkeley UNIX® Evolution, 1975-1984 -- very good.

[Jan 27, 2002]Slashdot Caldera releases original unices under BSD license

Caldera International has done a very good thing. They have released the "Ancient" Unices they inherited when they purchased SCO under a "BSD-style" license. The license is available here, instructions on finding the source are here. Caldera (and before that SCO) had required people to obtain a free (as in beer) but somewhat restrictive license in order to get these old sources. The new BSD-style licensing only applies to the 16-bit PDI-11 versions and some of the early 32-bit releases (excluding System III and System V), but it's still very cool.

The Unix archives are available via http://www.tuhs.org/archive_sites.html. The Unix Heritage Society website is at http://www.tuhs.org/. And the PDP Unix Preservation Society (PUPS) Home Page is at http://minnie.tuhs.org/PUPS/. This webpage has information on installing and running the software.

According to the PUPS FAQ, the Santa Cruz Operation (SCO) owned Unix research editions 1 to 7, PWB/UNIX, Mini-UNIX, 32V, System III, System V, and parts of 2.xBSD. In May, 2001, Caldera completed the acquisition of SCO's Server Software and Professional Services divisions, and SCO's UnixWare and OpenServer technologies. (The Santa Cruz Operation already provided free personal source code licenses.)

UNIX Chronology

Datametrics--The UNIX Industry A Brief History -- a transcript of a very interesting talk by Dr. Kelly who gave this talk at the 1995 Spring Unite Conference, a users group meeting for Unisys customers.

History of the Usenet

History of the ukr Internet K.I.S.S.
 

[Nov. 30, 1999] A Brief Histroy of the 'ls' command LG #48
 

[June 11, 1999] The Unix War: Epilogue.
 

Netizens Netbook
 

AN ARTICLE ABOUT LINUX AND ITS SIGNIFICANCE (1994)
 

[Feb. 7, 1999]The return of BSD - SunWorld - January 1999

I's been a long while, but finally people are coming to accept Solaris, the System V-based operating system that replaced SunOS 4. Still, six years is a long time, and it would have taken much longer if Sun had continued to maintain SunOS 4. Why such loyalty? They are, after all, both versions of Unix.

The last thing I want to do here is revive the SunOS vs. Solaris debate, but I will draw attention to the biggest single difference between SunOS 4 and SunOS 5, the operating system component of today's Solaris: SunOS 4 is based on 4.2 BSD, the version of Unix developed at the University of California at Berkeley and the first operating system with support for TCP/IP. By contrast, SunOS 5 (commonly called Solaris, though that's not quite accurate) is based on AT&T's Unix System V.4. BSD is different enough from System V that six years after the "death" of SunOS 4, it still has a large number of supportsignificantly hampered when Unix System Laboratories (USL) filed a lawsuit against BSDI, alleging abuse of AT&T source code.

Historically, each project was founded after differences of opinion about what constituted a good operating system. Since the software is free, any group of people can decide to custom build their own operating system. If it doesn't work, they can just stop building. In fact, all current BSD varieties, including BSDI, stem from Bill Jolitz's 386 BSD project, which faded into oblivion in 1994.

On the face of it, this doesn't seem to be a good approach: why not bite the bullet and compromise? In practice, the system shows remarkable self-regulating tendencies: 386 BSD is the only project that has closed up shop, and its descendents are all doing well and actively cross-pollinating. The fact that each version has a different kernel means survival of the fittest applies to kernel code as well, whereas in Linux it applies only to user code. For example, the fledgling FreeBSD SPARC port didn't start from scratch: it started from the NetBSD implementation and immediately raised the question, What can we do better? This process automatically raises the standard necessary for success. As a result, many such attempts fail, but the ones that don't create world-class code.

Recommended Links


In case of broken links please try to use Google search. If you find the page please notify us about new location
Google     

Classic papers from Bell Lab

Unix philosophy

Creators of Unix

Most of the key people for Unix project( Ken Thompson, Dennis Ritchie, Joe Ossanna, Bob Morris, Doug McIlroy, Brian Kernighan) came from Multics project were they were trained in OS design. Here is the relevant quote from UNIX and Multics:

When Bell Telephone Laboratories (BTL) joined with MIT Project MAC and General Electric's computer department to create the Multics project, BTL contributed some of the finest programmers in the world to the team. I first met Ken Thompson because he had written a slick editor for CTSS called QED. It was descended from QED on the SDS-940, but was quite different because Ken had added regular expressions to it, and made many other changes. (Ken had published a paper on compiling regular expressions into machine code just before joining the Multics project.) Ken worked on the Multics I/O switch design. Dennis Ritchie and Rudd Canaday were BCPL jocks. Joe Ossanna worked on the I/O system design and wrote one of the original six Multics papers; Bob Morris, Doug McIlroy, Dave Farber, and Jim Gimpel worked on EPL, Stu Feldman worked on the I/O switch, Peter Neumann managed the team and worked on file system design, Brian Kernighan worked on the support tools.

Ken Thompson

Chronology

UNIX History Unix Timeline by  Éric Lévénez

Datametrics--Handout for UNIX a Brief History

UNIX Chronology

Early Unix

Jargon File Resources

Unix History  -- a rather funny version.


Early Unix Source

 


BSD

 

Etc


Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.

Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.

Last modified: November 08, 2008