Last week, we looked at how the operating system became increasingly important as hardware alone became less useful for describing what a computer did. Similar hardware could serve as a workstation, provide network services, or perform several roles at once depending upon its operating system, software, and configuration. That discussion ended with UNIX, an operating tradition that had developed around shared computing long before networked personal computers made those characteristics increasingly useful.

UNIX did not begin as a networking operating system in the modern sense. It developed in an environment where computing resources were shared among multiple users and where multiple programs needed to operate within the same system. Users, processes, permissions, files, and small programs that could work together were part of its operating model from relatively early in its development. As networking became more important, many of those existing assumptions translated naturally into computers that increasingly needed to interact with other computers.

The same characteristics that helped UNIX adapt to changing uses also helped it spread. Rewriting much of UNIX in C reduced its dependence upon a particular machine, allowing it to move across hardware architectures more readily than an operating system closely tied to one computer. Universities, researchers, and commercial vendors could encounter UNIX, adapt it to different environments, and develop it in different directions. Berkeley became particularly important to that development, while AT&T continued its own UNIX lineage and commercial vendors created systems for their hardware and markets.

UNIX became more than the operating system originally developed at Bell Labs. It became a family of related systems with common ancestry but increasingly distinct implementations, purposes, and identities. Understanding how that happened requires returning to UNIX’s beginning, examining the operating model that developed around it, and following the branches that appeared as UNIX moved beyond the machines and organization where it began.

From Multics to UNIX

UNIX did not appear in isolation. Its development followed Bell Laboratories’ participation in one of the most ambitious computing projects of the 1960s: the Multiplexed Information and Computing Service, better known as Multics. Developed jointly by MIT, General Electric, and Bell Labs, Multics was intended to create a large time-sharing system in which many people could interact with a computer at the same time.

Time-sharing represented a different way of thinking about access to a computer. Instead of preparing a job, submitting it, and waiting for the results, users could work interactively through terminals while the operating system managed access to the underlying machine. Multics took that idea considerably further. It was designed around multiple users, processes, protection between users and programs, a hierarchical filesystem, and an operating environment that could remain continuously available while serving a changing workload.

Those goals made Multics influential, but they also made it extraordinarily ambitious for the computers and software-development practices of the period. Bell Labs became dissatisfied with the project’s progress and withdrew in 1969. Its researchers no longer had Multics, but they had gained experience with both the possibilities and difficulties of building an interactive, multi-user computing environment.

A Smaller Beginning

Ken Thompson was one of the Bell Labs researchers who had worked with Multics. After Bell Labs withdrew, he continued experimenting with operating-system ideas on a much smaller DEC PDP-7. The machine was considerably more limited than the hardware intended for Multics, which forced a different scale of development. Rather than attempting to reproduce the larger system, Thompson began assembling the pieces of a useful computing environment on the hardware available to him.

Dennis Ritchie soon became another central contributor, along with other researchers at Bell Labs. The new system acquired a filesystem, processes, a command interpreter, utilities, and the ability to support multiple users. Many of these concepts were not unique to UNIX, and some reflected lessons learned from Multics and other time-sharing systems. What distinguished the emerging system was the particular way those pieces were assembled into a comparatively small and practical operating environment.

The relationship with Multics even appeared in the new system’s name. The earliest name, Unics, was a play on Multics. The spelling eventually became UNIX, and the joke became the name of an operating system that would develop far beyond the PDP-7 on which its earliest form had been assembled.

UNIX Becomes a Real System

The PDP-7 system demonstrated the idea, but UNIX did not remain an experiment on obsolete hardware. Bell Labs acquired a DEC PDP-11, and UNIX development moved to the newer machine. The system continued to gain capabilities as it began supporting work within Bell Labs, giving its developers a practical reason to improve an operating environment that people were actually using.

UNIX was not designed once and then released as a finished operating system. It grew through use. Researchers added capabilities as they encountered problems to solve, while the system itself provided an environment in which they could build additional tools. Features that would later be recognized as characteristic of UNIX developed over time rather than appearing together in a single original design.

Many of the commands used by UNIX and UNIX-like operating systems are separate programs rather than functions built into the operating system itself.

By the early 1970s, UNIX had moved beyond its beginning as Thompson’s PDP-7 project. It was becoming a practical multi-user operating system and a development environment in its own right. The next question is what kind of operating environment UNIX had become—and which characteristics would allow it to move beyond Bell Labs and eventually develop into an entire family of systems.

What Is UNIX?

By the early 1970s, UNIX had become more than a small operating-system experiment. It provided an environment in which multiple users could run programs, organize files, communicate with the system through a command interpreter, and combine programs to perform more complicated work. Many of these capabilities existed elsewhere, but UNIX brought them together in a form that could grow while remaining comparatively understandable.

UNIX is not defined by a single feature. Multi-user computing existed before UNIX. Hierarchical filesystems existed before UNIX. Command-line interfaces, processes, and eventually networking were not unique to it either. What became characteristic of UNIX was the way these mechanisms worked together and the operating model that developed around them:

• A Multi-User, Multitasking System
• Files as a Common Interface
• The Shell and Separate Programs
• Small Tools Working Together
• Written Largely in C

A Multi-User, Multitasking System

UNIX grew from the time-sharing tradition, so multiple users were part of its environment from early in its development. Each user could have an identity, own files, run programs, and work within the same computer while the operating system managed the resources underneath them. Rather than treating the computer as belonging to whichever person happened to be sitting in front of it, UNIX assumed that the system itself might be shared.

Processes extended that model to running programs. The operating system could keep track of multiple processes and allocate processor time among them, allowing more than one program to make progress without requiring one program to finish before another could run. Users could interact with their own programs while other users and system processes were doing work on the same machine.

Ownership and permissions helped make that sharing manageable. Files and directories could belong to users and groups, with permissions controlling who could read, modify, or execute them. These mechanisms were not merely security features added to a single-user computer. They were part of operating a system in which different people and processes were expected to coexist.

That assumption would become increasingly useful as computers became networked. UNIX did not need networking to make multi-user operation relevant; it already came from a world of shared computing. Networking would eventually provide additional ways for users and systems to reach those shared resources.

Files as a Common Interface

UNIX also used the filesystem as an abstraction for more than ordinary data. Ordinary data was stored in files arranged within a hierarchical directory structure, but the file interface could represent more than documents and program data. Devices could also be exposed through file-like interfaces, allowing programs to interact with hardware using many of the same operations they used when working with ordinary files.

This did not mean that everything inside UNIX literally worked the same way. Different devices and system resources still had different capabilities and underlying implementations. UNIX could provide a relatively small set of common interfaces instead of requiring every program to understand every device independently.

The result was an operating environment in which programs could often concentrate on reading input, transforming it, and producing output while the system handled where that input came from or where the output went.

The Shell and Separate Programs

The UNIX shell provided the command environment through which users interacted with the system. Rather than requiring every command to be implemented as a permanent part of the shell or operating-system kernel, many commands were independent executable programs. When a user entered a command, the shell could locate the corresponding program, start it as a process, and connect it to the appropriate input and output.

That separation made the command environment extensible. Adding a new utility did not necessarily require changing the shell or rebuilding the operating system. A program that followed the expected conventions could become another tool available from the command line.

The shell itself could then provide mechanisms for connecting those tools. Redirection allowed input and output to come from files instead of the terminal. Pipes went further by allowing the output of one program to become the input of another.

Small Tools Working Together

This ability to compose programs became one of the most recognizable characteristics of UNIX. Instead of requiring one large program to anticipate every possible operation, smaller utilities could perform focused transformations and be connected when a more complicated task was required.

Consider three familiar UNIX tools: grep, sed, and awk. Each is useful independently, but they can also participate in a pipeline:

grep "error" system.log | sed 's/^/LOG: /' | awk '{print $1, $2, $3}'

The command can be read from left to right:

1. grep searches system.log and outputs lines containing error.
2. The pipe (|) sends those lines to sed instead of displaying them on the terminal.
3. sed adds LOG: to the beginning of each matching line and sends the result onward.
4. The next pipe sends that output to awk.
5. awk prints the first three whitespace-separated fields from each resulting line.

None of these programs needs to know that the others exist. grep produces text. sed receives text, transforms it, and produces text. awk receives that text and performs another operation. The shell connects them.

A user can construct a new operation from existing programs without modifying any of them. Programs become building blocks, while standard input, standard output, and pipes provide conventions through which those blocks can work together.

The often-repeated idea that UNIX programs should do one thing well is a useful description of this style, but it should not be mistaken for a complete specification handed down with the first version of UNIX. UNIX developed over time, and so did the tools, conventions, and philosophy associated with it. What matters here is the operating pattern that emerged: programs could remain relatively independent while common interfaces allowed them to participate in larger workflows.

Written Largely in C

One of the most consequential characteristics of UNIX was not something a user necessarily saw at the command line. Early UNIX was written in assembly language for the PDP hardware on which it ran. During the early 1970s, Dennis Ritchie developed the C programming language, and UNIX was subsequently rewritten largely in C.

Operating systems were commonly written substantially in assembly language because systems software needed direct access to the underlying machine. Assembly provides that access, but instructions written for one processor generally cannot simply be moved to another architecture. An operating system written primarily for a particular processor carries a substantial hardware dependency.

C did not make hardware differences disappear. Some portions of an operating system still needed architecture-specific implementations, and a C compiler had to exist for the target machine. What changed was how much of UNIX had to be rewritten when the operating system moved.

Much of the system could now be expressed in a language that was not itself tied to one processor’s instruction set. Porting UNIX to another architecture could concentrate more heavily on the machine-dependent portions while retaining much of the operating system above them.

Rewriting UNIX largely in C helped separate the operating system from the hardware on which it had been created.

This portability would have consequences far beyond making UNIX easier to maintain. An operating system that could move between different kinds of computers could also move between organizations. As UNIX left its original hardware and spread beyond Bell Labs, new groups would encounter the system, modify it for their own purposes, and eventually carry its development in different directions.

UNIX Spreads Beyond Bell Labs

Portability made it possible for UNIX to move between computers, but hardware was only part of the story. UNIX also began moving between organizations. Universities were particularly important because they provided environments where researchers and students could study the system, modify it, and use it as a foundation for additional work.

AT&T’s position in the regulated telephone industry shaped how this happened. Bell Labs could develop software for its own purposes, but AT&T faced restrictions on entering other commercial markets. Rather than initially treating UNIX as a conventional commercial software product, AT&T licensed the system to universities, government organizations, and other institutions. Academic licenses could include source code, giving researchers an unusual opportunity to examine and change a working operating system.

UNIX Goes to the Universities

UNIX began reaching universities during the early 1970s. For computer-science departments, access to the source code was particularly valuable. Students and researchers could do more than learn how to operate the system. They could examine how an operating system was constructed, modify it, develop new utilities, and adapt it to the equipment and research taking place around them.

Bell Labs remained an important center of development, but it was no longer the only place where UNIX was being used and changed. Improvements could emerge from institutions with different hardware, different research interests, and different problems to solve.

Portability reinforced that spread. Because much of UNIX was written in C, moving the system to another computer did not necessarily mean beginning again from assembly language. UNIX could reach additional hardware while carrying much of the same operating environment with it.

Portability allowed UNIX to move between computers. Source availability allowed people outside Bell Labs to understand and change what moved with it.

Berkeley Builds on UNIX

One of the most important destinations was the University of California, Berkeley. UNIX arrived there in the 1970s, where faculty and students began modifying and extending the system. Those additions eventually became substantial enough to be distributed as the Berkeley Software Distribution, or BSD.

BSD did not begin as an independently created replacement for UNIX. It grew from AT&T UNIX while adding software and changes developed at Berkeley. As those distributions continued to evolve, Berkeley became one of the major centers of UNIX development.

That work included improvements to the operating environment, performance, utilities, and eventually networking. BSD became more than a collection of convenient additions. It developed into a major UNIX lineage whose work would influence other UNIX systems and whose descendants would continue independently.

Networking Becomes a UNIX Strength

Networking became one of the areas in which Berkeley’s UNIX work proved particularly important. During the development of BSD, researchers incorporated and developed support for the TCP/IP protocol suite and created the sockets programming interface that applications could use to communicate across networks.

BSD did not invent TCP/IP, and UNIX had not originally been created around TCP/IP networking. The significance was the combination. A portable, multi-user operating environment was gaining a practical networking implementation and programming interface at a time when computer networks were becoming increasingly important.

Many of UNIX’s existing assumptions continued to make sense as interaction expanded beyond a single computer. Processes could provide network services. Users could connect remotely. Permissions could control access to shared resources. Small programs could communicate through established interfaces while networking provided another way for computers and users to reach one another.

Networking did not make UNIX relevant. Networking made a set of assumptions UNIX already possessed increasingly useful.

Networking did not make UNIX relevant. Networking made a set of assumptions UNIX already possessed increasingly useful.

More Than One Center of Development

Berkeley was important, but UNIX development had not simply moved from Bell Labs to a university. AT&T continued developing UNIX as well. Other universities, research organizations, and eventually computer vendors also adapted UNIX to their own hardware and requirements.

That meant UNIX was beginning to develop in more than one direction at the same time. Changes made in one branch could influence another, but the systems did not remain identical. Different organizations had different priorities, release schedules, hardware, and users.

The portability that had allowed UNIX to spread had another consequence. Once UNIX could move between machines and organizations, the people receiving it could take it somewhere new. The next stage of UNIX history would not be the development of a single system, but the emergence of distinct branches.

Once UNIX could move between machines and organizations, the people receiving it could take it somewhere new.

UNIX Begins to Branch

As UNIX spread, development no longer occurred within a single organization. Bell Labs continued developing the system, Berkeley built increasingly substantial distributions from it, and computer manufacturers adapted UNIX to their own hardware. These systems shared ancestry and continued exchanging ideas and technology, but they did not remain identical.

Two lineages became particularly important to the history that followed. BSD developed from the UNIX work taking place at Berkeley, while AT&T continued developing the original Bell Labs lineage toward what became UNIX System V. The distinction was never completely clean: technology moved between the branches, and later systems could incorporate substantial work from both. Still, BSD and System V provide useful reference points for understanding how UNIX developed into a family.

The BSD Lineage

The Berkeley Software Distribution began as additions to an existing AT&T UNIX system. Early BSD releases included software developed at Berkeley rather than constituting an entirely separate operating system. As Berkeley continued its work, however, BSD accumulated increasingly substantial changes to the underlying system.

Berkeley’s work included new utilities, improvements to the filesystem and virtual-memory system, performance work, and the networking development discussed earlier. BSD developed characteristics that distinguished it from the UNIX releases continuing through AT&T, even though the two remained historically connected.

BSD also demonstrated what could happen when UNIX spread through universities. Researchers were not limited to writing applications that ran on top of an operating system supplied by someone else. With access to UNIX source code, they could change the operating system itself. A university distribution could become the basis for further research and, eventually, another major branch of UNIX development.

The AT&T Lineage

Development also continued within Bell Labs and AT&T. Research UNIX progressed through a series of editions, with Version 7 UNIX, released in 1979, becoming an especially important point in the family tree. Version 7 was widely distributed and became an ancestor of several later UNIX systems.

AT&T’s own development moved beyond the numbered Research UNIX editions. UNIX System III appeared in the early 1980s, combining work from several internal AT&T UNIX efforts. It was followed by UNIX System V, which became the principal commercial AT&T UNIX lineage.

System V continued through several major releases and became an important foundation for commercial UNIX. Computer manufacturers could license UNIX, adapt it to their hardware, and add the features needed for their customers and markets. UNIX was becoming not only a research and academic family, but also the basis for commercial operating systems tied to particular vendors and computer platforms.

Vendor UNIX

As computer manufacturers adopted UNIX, the family grew wider. Vendors had reasons to provide an operating environment that customers could recognize while still adapting that environment to their own processors, workstations, minicomputers, and larger systems.

IBM developed AIX. Hewlett-Packard developed HP-UX. Sun Microsystems developed SunOS, initially with strong BSD ancestry, and later Solaris, which incorporated the System V lineage while retaining important BSD-derived technology. The Santa Cruz Operation developed commercial UNIX systems for increasingly important microcomputer hardware. Other vendors and organizations produced their own implementations as well.

These systems could differ substantially while still belonging to the broader UNIX family. They might use different hardware architectures, administration tools, filesystems, utilities, or combinations of BSD and System V technology. Software written for one UNIX system could not automatically be assumed to compile or behave identically on every other UNIX.

The name UNIX described something increasingly complicated. It could refer historically to the operating system developed at Bell Labs, to systems descended from that source, or more broadly to an operating tradition shared across a growing collection of implementations. Later standards and trademark requirements would provide more precise meanings, while systems designed to behave similarly without sharing UNIX ancestry would commonly be described as UNIX-like.

Branches Continue to Exchange Ideas

Branching did not mean the different UNIX lineages stopped interacting. BSD and AT&T development influenced one another, and vendors incorporated technologies that originated elsewhere in the UNIX world. A feature developed in one branch could prove useful enough to appear later in another.

This makes UNIX history difficult to represent as a simple sequence. A family tree can show where systems descended from earlier systems, but it cannot cleanly represent every piece of code, interface, utility, or idea that moved between them. Those exchanges are part of the history, but they are different from descent.

The distinction will matter when we build the UNIX family tree later in this article. The tree will follow where systems came from, while the surrounding history explains why related branches could continue learning from and borrowing from one another.

UNIX had reached a very different position from the small PDP-7 system developed at Bell Labs. Portability had allowed it to cross hardware boundaries. Licensing and source availability had allowed it to cross organizational boundaries. Once different groups began changing UNIX for their own purposes, those movements produced something more enduring than a series of ports: they produced a family.

Portability had allowed UNIX to cross hardware boundaries. Licensing and source availability had allowed it to cross organizational boundaries.

UNIX Express

By the late 1980s and early 1990s, UNIX had become difficult to describe as though it were still a single operating system. Different branches shared ancestry, exchanged technology, and retained enough similarities to remain recognizably related, while vendors and research groups continued developing their own implementations. The result could be complicated even for people who worked with computers.

An old computer-industry joke imagined operating systems as airlines. UNIX Express had its passengers arrive carrying pieces of an airplane and tools. They argued about what they were building, split into groups, and ultimately produced several different aircraft bearing the same name.

The joke worked because people could picture it. UNIX had begun as one operating system, but portability and continued development had allowed different groups to carry pieces of that system in different directions. By following the major lines of descent, those relationships become easier to see.

The UNIX Family Tree

A UNIX family tree can quickly become difficult to read. UNIX systems did not develop as completely isolated branches. Code, utilities, interfaces, and ideas moved between implementations, and some later systems incorporated substantial work from more than one part of the UNIX family.

The tree below has a narrower purpose: it shows descent. It does not attempt to document every exchange of code, feature, standard, or idea between UNIX systems. Where multiple lines of descent are important enough that placing a system beneath only one parent would be misleading, the relationship is broken into a smaller tree rather than duplicating the same descendants in several places.

Research UNIX

The earliest part of the tree begins with the UNIX editions developed at Bell Labs. The first several editions remained closely associated with the PDP-11, while Version 6 became particularly important because it spread widely outside Bell Labs. Version 7 followed in 1979 and became one of the major ancestors of the UNIX systems that followed.

Research UNIX │ ├── First Edition (1971) │ └── Second Edition │ └── Third Edition │ └── Fourth Edition │ └── Fifth Edition │ └── Version 6 (1975) │ ├── Version 7 (1979) │ │ └── UNIX/32V │ │ │ └── 1BSD │ └── 2BSD │ └── later Research UNIX editions

The apparent split between Version 7 and the early BSD releases needs some explanation. 1BSD was not originally a complete replacement operating system. It was a collection of Berkeley software added to Version 6 UNIX. The BSD lineage became increasingly independent as Berkeley continued developing it.

Version 7 also led to UNIX/32V, a Bell Labs port for the DEC VAX. UNIX/32V becomes particularly important because Berkeley used it as part of the foundation for the next stage of BSD.

BSD Becomes an Operating System

Berkeley combined the VAX-based UNIX/32V system with the software it had been developing through the earlier BSD releases. The result was 3BSD, a complete VAX operating system that included Berkeley’s virtual-memory work and the utilities developed through the earlier BSD lineage.

That gives 3BSD two useful lines of descent to show:

UNIX/32V ──┐ ├── 3BSD 2BSD ──────┘ │ └── 4BSD └── 4.1BSD └── 4.2BSD └── 4.3BSD

This is where BSD becomes one of the major branches of the UNIX family rather than simply a collection of additions distributed for an existing UNIX installation. Later BSD development would continue beyond 4.3BSD, but those descendants deserve their own treatment when we follow the BSD family in greater depth.

Several commercial UNIX systems also grew from the BSD side of the family. SunOS was strongly BSD-derived, while Digital Equipment Corporation’s Ultrix was based primarily on BSD while incorporating some System V features.

4BSD / 4.xBSD │ ├── SunOS │ └── 4.2BSD └── Ultrix

Those systems also show why the tree does not attempt to include every influence. Ultrix incorporated System V features, and SunOS would later participate in development that crossed the BSD and System V branches. Those relationships matter, but they are not the same thing as simply identifying a parent and descendant.

The AT&T Commercial Lineage

Version 7 also contributed to the commercial UNIX lineage developed by AT&T. UNIX System III combined several internal AT&T UNIX developments, including Version 7 and UNIX/32V, into a system intended for distribution outside Bell Labs. System III was followed by UNIX System V in 1983.

The resulting line became one of the major commercial trunks of the UNIX family:

Version 7 UNIX ──┐ ├── UNIX System III UNIX/32V ────────┘ │ └── UNIX System V ├── SVR2 ├── SVR3 └── SVR4

System V became the basis for numerous commercial UNIX implementations. Rather than every customer running an identical AT&T operating system, vendors could adapt the System V codebase to their own hardware and products.

Among the important descendants were HP-UX, AIX, and SCO UNIX. Their exact histories contain influences and additions from elsewhere in the UNIX family, but their primary commercial ancestry can be followed through System V.

UNIX System V │ ├── SVR2 │ └── HP-UX │ └── SVR3 ├── AIX └── SCO UNIX

The Santa Cruz Operation had already become important in microcomputer UNIX through its work with Xenix before releasing SCO UNIX, a System V Release 3.2-based UNIX for Intel hardware.

System V Release 4 Brings Branches Together

System V Release 4 illustrates why UNIX descent eventually becomes more complicated than a single vertical tree. AT&T and Sun Microsystems worked together on SVR4, combining the System V lineage with substantial technology from BSD, SunOS, and Xenix.

For purposes of descent, SVR4 remains part of the System V line:

UNIX System V │ ├── SVR2 │ ├── SVR3 │ └── SVR4

But the history behind that branch includes several already-established parts of the UNIX family:

System V ──┐ BSD ───────┤ SunOS ─────┼── SVR4 Xenix ─────┘

SVR4 provides a useful example of the difference between a family tree and the complete history of UNIX development. The first tree tells us where the release belongs. The second shows why describing its ancestry requires acknowledging more than one established branch.

Sun Microsystems subsequently moved from its BSD-derived SunOS foundation to the SVR4-based system marketed as Solaris. The family tree crosses between the previously separate branches again here.

SVR4 ──────┐ ├── Solaris SunOS ─────┘

Reading the Tree

These diagrams deliberately leave out many UNIX releases and implementations. Their purpose is not to catalog every system that has carried UNIX code or behaved like UNIX. They document the major lines of descent needed to understand how the operating system developed from the Bell Labs editions into BSD, System V, and the commercial UNIX systems surrounding them.

They also do not include every operating system described as UNIX-like. An operating system can reproduce UNIX interfaces, conventions, or behavior without descending from the original UNIX source code. Descent and compatibility are different relationships, and treating them separately keeps the history clearer.

UNIX became a family not because every branch remained the same, but because different systems continued developing from shared ancestry.

About the family tree: These diagrams were assembled primarily from the histories presented across Wikipedia’s UNIX-related articles, with major dates and branch points checked against The Open Group’s UNIX history. They focus on lines of descent rather than every exchange of code, features, standards, or ideas between systems. Complex relationships have been divided into smaller diagrams where doing so makes the ancestry easier to follow.

Summary

UNIX began as a comparatively small operating system developed at Bell Labs after the laboratory withdrew from the much more ambitious Multics project. What began on a PDP-7 grew into a practical multi-user operating environment with processes, a hierarchical filesystem, a shell, independent utilities, and conventions that allowed those tools to work together. Rewriting much of UNIX in C then helped loosen the connection between the operating system and the particular hardware on which it had been created.

Portability allowed UNIX to move to new computers, while licensing and access to source code allowed it to move into universities and other organizations. Researchers could study the operating system, modify it, and build upon it rather than treating it as an inaccessible layer beneath their applications. Berkeley became particularly important through BSD, including networking work that helped make UNIX increasingly useful as computers themselves became more connected.

That spread also meant UNIX no longer developed along a single path. Bell Labs and AT&T continued their own lineage, Berkeley developed BSD, and commercial vendors adapted UNIX to different machines and markets. Those branches continued exchanging technology even as they became increasingly distinct. UNIX had changed from one operating system developed for a particular environment into a family of related operating systems with shared ancestry.

The UNIX family grew from many of the same characteristics that made the original system successful. It could move between hardware, be adapted to different purposes, and provide a recognizable operating environment even as individual implementations changed. The result was not one UNIX frozen in time, but a collection of related systems whose common ancestry remained visible even as their branches continued developing in different directions.