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. 

<strong>Meet the author:</strong> John Paul Wohlscheid
Meet the author: John Paul Wohlscheid

John Paul Wohlscheid has always been fascinated by the early history of the computer industry. He discovered open-source software while in college and now spends as much time using it as he can. In his limited free time, John Paul enjoys writing detective stories and playing games.

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

FreeBSD and OpenZFS

Part 2: Tuning Your FreeBSD Configuration for Your NAS

Building your own NAS isn’t just about having the right storage configuration. It starts with the right hardware, the right OS setup, and finally going through the right choice for your storage – OpenZFS. In this edition of our 4-part article series on how to build your own NAS we discuss about fine tuning your FreeBSD OS for excellent NAS performance.

Improving Replication Security With OpenZFS Delegation

OpenZFS privilege delegation is an extremely powerful tool that enables system administrators to carefully provide unprivileged users the ability to manage ZFS datasets and zvols at an extremely precise level —with much finer control than would be possible with generic security tools like sudo or doas.

Tuning recordsize in OpenZFS

Beginning with version 13.0, FreeBSD supports the long-anticipated OpenZFS native encryption. If you’ve used FreeBSD’s GELI encryption in the past, you may wonder if switching to OpenZFS native encryption makes sense.

Check out the differences between GELI encryption and OpenZFS native encryption, and the main benefits of native encryption, let’s take a look at how to create an encrypted database and reroot to an encrypted database.

Tell us what you think!