From Unix to Linux: Key Trends in the Evolution of Operating Systems (Part 1)

Linux is an odd creature: a technology rooted in the 1970s and developed in the 1990s that has come to dominate the early 21st century, while still showing some of the creases and chinks of its origins in the Unix operating system (OS). FOSS enthusiasts will find it worthwhile to learn more about the history of Unix and how it led to the development of Linux. In a series of articles, I will discuss the mentality created by Unix, as well as the importance of the other variants that contributed to Unix and GNU/Linux along the way.  

These articles do not represent a formal history, which you can easily find elsewhere online. The formal histories tend to be detailed and highly technical. This article, in contrast, takes a high-level look at social trends in computing and the impacts Unix and GNU/Linux have had, which often don't get discussed. I have also compiled a timeline of events (found at the end of this article) that provides an overview of milestones discussed in the series relating to the development of Unix, Linux, and more.

How Unix Fostered Continuity

Dennis Ritchie and Ken Thompson created Unix around 1970. When historians discuss what's special about Unix, they generally stress that it supported multiple users, whereas other early operating systems had enough on their hands running one job from start to finish without interruption. I think that another impact of Unix was more important: portability. Previously, most operating systems were tied to a single architecture. Unix meant you could upgrade your computer over the years and the decades and still use the same operating systems and applications—a big boost to computing.

If Unix had been tied to the PDP-11 computer from Digital Equipment Corporation where early development took place, the operating system would be barely a footnote in history. (I mention the PDP-11 because it had another lasting impact that we'll soon see.) But, becoming portable allowed Unix to survive the evolution of computer hardware and eventually dominate computing. As the official Unix timeline from The Open Group states, in 1973, "It was rewritten in C. This made it portable and changed the history of OS's." BSD expert Warner Losh, in commenting on this article, suggested that real portability took longer, but Unix made the leap by the early 1980s.

The portability of Unix and its utilities continues into Linux today. Originally developed for Intel chips, Linux now runs on more than a dozen architectures. When the Linux kernel made the leap from Intel to the ARM architecture, thereby making Linux available on the small mobile devices that were emerging in the 1990s, the move caused general excitement within the Linux community and opened up a new frontier in computing. Now, of course, Linux undergirds the Android operating system and offers a familiar computing environment to the RISC-V chip.

The Importance of the C Language

Unix was portable because it was written in a high-level language instead of assembly language. In fact, the Unix kernel was one of the first large programs to be written in the C language, whose creation is credited mainly to Ritchie (but Unix co-inventor Thompson provided important input, too).

C made it possible to write an operating system in a portable, high-level language because—well, because C actually wasn't so high-level. There were already plenty of high-level languages, such as FORTRAN, COBOL, LISP, and ALGOL, and they were impressively clever. In various ways, they hid the specific, intricate details of computer architecture and allowed programmers to think in terms of the knowledge domains they were working in. FORTRAN looked a lot like scientific functions and equations. COBOL looked like a description of business processing. Each language required its own discipline, but you didn't have to worry too much about the underlying architecture.

In contrast, C was very close to the computer architecture. It implemented bit operations through masks (which affect particular bits in a variable) and shifts (which move bits within a variable). From the PDP-11 architecture and assembly language, the developers chose a simple way to represent strings. Because strings are of indeterminate length, some overhead is required to represent them. C simply stores each string with a terminating null byte (zero), as did the PDP systems for which C was originally developed. The C language’s concept of a union, which let you read the same memory in different ways, was useful for device drivers and networking, because their headers could be laid out in different ways under different circumstances.

C also offered extremely efficient arrays. The name of an array pointed to its first element, which was numbered 0 instead of 1. Thus, an array could be assigned to a pointer, and the program could step through the array with minimal overhead.

In general, when people want to write very efficient, fast-running code, they still use C or some modern variant. Developers using other languages regularly compare their programs to C and boast when they manage to achieve the efficiency of C. This efficiency is achieved at the expense of safety: C doesn't provide the safeguards that other languages have and allows you the freedom to make drastic mistakes (notably by overflowing variables or stepping out of the bounds of arrays). But a knowledge of C is still recommended for every programmer.

Unix Conventions and Oddities

I should mention that an English-language bias is built into both C and Unix. They are designed to work with the ASCII character set, and the initial A in ASCII stands for "American." The C and Unix libraries have made great progress in supporting other languages, but the ASCII bias lives on. This is why a file named Foo is different from a file named foo, because uppercase and lowercase are different parts of the ASCII character set. Some modern filesystems on Unix-like systems try to support case-insensitive names, but they do so awkwardly.

Unix includes other oddities and idiosyncrasies, many related to memory constraints on computers of the 1970s. Consider, for instance, single-character options for commands.  When compiling your program, you used the -o option to assign a filename to the output. With options limited to single characters, Unix's case-sensitivity actually came in handy. While -o indicated the name of the output (or "object") file, for instance, the -O option turned on optimization. If the wealth of command options outstripped the 52 uppercase and lowercase letters, a developer could assign some other character, offering a -? or -% option.

In all sorts of ways, strange little Unix conventions have entered everyday programmer talk. For instance, a computer administrator who wants to mention the family of BSD operating systems (FreeBSD, NetBSD, OpenBSD, and so on) may borrow an asterisk from Unix file globbing rules and write "the *BSD systems."

A Trial Run for Open Source

Long before free or open source software licenses, Unix source code was open to users who licensed the operating system. The owners of Unix maintained copyright over the source code and sometimes exerted their control over it very harshly, as we'll see later in this series. But that stance doesn't detract from the revolution presented by the availability of Unix source code.

Because Unix users had the source code, Unix developers provided options that could be changed only by recompiling the code. It was fairly common for system administrators to recompile Unix after tweaking the options for their sites—another tradition carried on by Linux. In conversation with the author, BSD developer Greg Lehey pointed out that recompilation was actually a common practice for many operating systems at that time. For instance, a 1981 IBM manual for the VM/370 specifies on page 228 that their "SOURCE tape contains all source files, and macros of VM/370."

The availability of source code for a robust, contemporary operating system was also a boon to students. Unix not only pioneered important operating system techniques in memory management, scheduling, etc., it also contained interesting data structures and algorithms that were broadly applicable to other applications. Computer science professor John Lions documented the source code for Unix in a book that is considered a classic.

In this article, I have tried to convey some of the aspects of computing that we take for granted today, but that were made uniquely possible by Unix. The operating system has followed a long and unexpected path, which I'll continue to trace in upcoming articles. 

See also:

• From Unix to Linux: Key Trends in the Evolution of Operating Systems (Part 2)
• From Unix to Linux: Key Trends in the Evolution of Operating Systems (Part 3)
• From Unix to Linux: Key Trends in the Evolution of Operating Systems (Part 4)

Ready to find a job? Check out the latest job listings at Open Source JobHub.

Timeline of Unix and Linux