The Birth of UNIX

The Birth of UNIX

Over the past year, we’ve published a number of articles about the early history of BSD and FreeBSD. Today, we are going back to where it all started. We are delving back to the birth of Unix.


Before we dive into our story, remember to check some of the other articles we’ve published on the topic: Unix and BSD, BSDi and USL Lawsuits, Early Days of FreeBSD, or BSD and TCP/IP – How a Game Winning Team Was Formed. Now, let’s begin.

In his 1999 book In the Beginning… Was the Command Line, Neal Stephenson said the following about Unix: “Windows 95 and MacOS are products, contrived by engineers in the service of specific companies. Unix, by contrast, is not so much a product as it is a painstakingly compiled oral history of the hacker subculture. It is our Gilgamesh epic.”

In the Beginning was Multics

Unix has its roots in an earlier project named Multics or “Multiplexed Information and Computing Service”, which was started in 1956. The project was a joint collaboration between AT&T, Massachusetts Institute of Technology (MIT) and General Electric (GE) with the goal of creating “an interactive time-sharing system”. This was a big departure from the previous punch card based systems. The Multics system allowed you to enter commands with a keyboard “and then have the results printed out right away right above you” on a teletype printer. The project was worked on by Ken Thompson, Dennis Ritchie, and other big names.

To give you some idea how big of an advance this was, let’s take a quick look at punch card based computers. To write a program in FORTRAN, for example, you’d have to punch holes in a card. Each card was about the size of an index card but a little bit wider “because it has 80 columns”. Each of these 80 columns stood for a single character. To write your program, you would punch holes in these columns to correspond to the character you wanted to use. “Each punch card represents one line of FORTRAN code… So if you had a 1,000-line program, you would have 1,000 cards.”

As if that wasn’t bad enough, there was no instant feedback to let you know if you made a mistake. Instead, you had to hand the stack of cards that represented your program to the people that ran the computer systems. According to Brian Kernighan of C and AWK fame, “And a while later, back would come your results, very often where it’s just something like there was a syntax error somewhere, and you had to find the cards that were wrong, replace them with new cards that were right and repeat the process, but with a very, very long latency that could be often measured in hours or sometimes even days.”

Using this punch card system to print a thesis was no picnic, as Kernighan explains. “And so the thesis was basically three boxes of cards, 6,000 cards in each box, probably weighed 12 pounds (five kilograms). And so you’d take these three boxes, 1,000 cards of which the first half of the first box was the program and then the remaining 5,000 cards was the thesis. And you would take those three boxes and you’d hand them to the operator. And an hour or two or three later back would come a printed version of thesis again. And you’d just keep iterating until it was good enough.”

Unfortunately, the Multics project was canceled after five years. The project has been hugely ambitious and fell behind schedule. The AT&T managers decided to end the project while they were ahead. This decision caused the managers at Bell Labs to stop “any further work on computer operating systems”. This left many researchers very unhappy.

Did you know?

Improve the way you make use of ZFS in your company

Did you know you can rely on Klara engineers for anything from a ZFS performance audit, to developing new ZFS features to ultimately deploying an entire storage system on ZFS?

Then Came Space (Kinda) 

Even though their bosses had put an end to all operating system projects, Thompson and Ritchie continued to explore the idea of what an operating system should look like with other colleagues. 

During this time, Thompson wrote a computer game entitled Space Travel. According to Kernighan, “you had a complete, accurate model of the solar system and you could navigate your little rocket around the solar system and land on various things, so you can land on one of the moons of Jupiter or something like that.” 

Originally, Thompson wrote the game to run on a GE-645 mainframe computer, which was the same computer that Multics was written on. The problem was this made the game expensive to play, about “$75 a game for the CPU time”. Thompson started searching for a cheaper alternative. He finally found it in the form of a Digital Equipment Corporation PDP-7 minicomputer. The PDP-7 was outdated, but it was available. So, Thompson set to work porting Space Travel to the “new” computer. 

Next Came Patents 

In the summer of 1969, Thompson’s wife, Bonnie, took their newborn son to see her parents. Thompson took advantage of his new-found free time to write a basic operating system for the PDP-7. Thompson considered the project “an emasculated version of Multics and dubbed it “Un-multiplexed Information and Computing Service,” or Unics.” That later mutated into Unix. 

Others joined his effort. However, the group realized that the obsolete PDP-7 would not be able to sustain their work for very long. They also knew that the managers would never approve the purchase of a PDP-11 for operating system development, so they came up with a different tactic. At the time, Bell Labs “produced lots and lots of patent applications, typically one or two a day at that point.” The patent applications had to be formatted in a very specific manner with numbered lines. At the time, there was no commercial word-processing applications that handled numbering. Thompson and his team offered to write a such a word-processing application for a PDP-11. Of course, they failed to mention that they would need to write an operating system to run the word-processing application. After all, that wasn’t a big deal. 

Management agreed and placed an order for a PDP-11 in May of 1970. The computer arrived shortly thereafter, but it took the disk drives “more than six months to appear”. Once the drives were installed, the team moved their operating system over from the PDP-7. Next, they rewrote the runoff text formatting program for the PDP-11 and named the new program roff. The results were a hit with the “three typists from AT&T’s patents department…using it to write, edit, and format patent applications”. 

Happy with the work that had accomplished, the Bell Labs managers purchased another computer for the team, “a newer and more powerful PDP-11 model”. With this new machine, Thompson, Ritchie, and the rest of the team continued to add features and complexities to their new operating system. 

Like this article? Share it!

You might also want be interested in

FreeBSD development is easy when you have a team of world-class developers at your fingertips.

At Klara, we dedicated our team dedicated to helping you develop and take your FreeBSD infrastructure project further. Whether you’re planning a FreeBSD project, or are in the middle of one and need a bit of extra insight, we’re here to help!

More on this topic

Avoid Vendor Lock-In with MinIO and OpenZFS

Modern web and mobile applications are increasingly dependent on software defined storage. Most commonly, this means Amazon Web Services’ S3 storage buckets. What you may not realize is that you don’t actually need Amazon for Amazon-compatible cloud storage! In this article, we’ll discuss how and why to avoid vendor lock-in by providing your apps fully S3-compatible storage using free and open source software.

Open Source Storage

5 Key Reasons to Consider Open Source Storage Over Commercial Offerings

Although easy to overlook, storage is the most fundamental part of any computing project—without storage, there is neither code nor data! The right storage solution should be accessible, reliable, easy to maintain, and free from vendor lock-in. In this article, we examine some of the reasons that open source software is a natural fit for this crucial component.

Part 3: Building Your Own FreeBSD-based NAS with ZFS 

Today, we’ll concentrate on exposing the data on your NAS to the network using NFS, Samba, and iSCSI shares. Network File System (NFS) is a commonly used protocol for accessing NAS systems, especially with Linux or FreeBSD clients. We’ll provide an overview of each type of share to help guide you in deciding which is most suited to the clients that will be accessing the NAS.
Let’s examine how non-developer contributors enhance user experience, improve bug reporting, and influence feature requests, all while becoming advocates and evangelists for your open source project.

Tell us what you think!