The IBM-compatible PC took a different path. UNIX grew out of systems designed for multiple users sharing resources. Early personal computers were generally built for one person at a time. DOS became their common operating environment, allowing software to run across computers from different manufacturers. As PC hardware improved, the limitations of DOS became harder to ignore.

IBM and Microsoft initially cooperated on OS/2 as a successor to DOS, while Microsoft continued developing Windows as a graphical environment. Their partnership eventually ended, and Microsoft pursued Windows NT as a separate operating-system architecture. For several years, DOS-based Windows and Windows NT developed alongside one another before Microsoft consolidated its desktop operating systems around NT. Other companies developed DOS-compatible systems, and open-source projects have kept parts of that history alive.

Before looking at Windows and OS/2, it helps to understand what DOS provided, where it came from, and why replacing it proved difficult.

DOS

DOS, short for Disk Operating System, became closely associated with the IBM PC and its compatible descendants. Although several unrelated operating systems used the name DOS, the PC-compatible DOS family became particularly influential because of the widespread adoption of IBM-compatible hardware.

DOS loaded programs, managed files and disks, and provided basic access to hardware. On an early PC, with limited memory and processing power, those services were enough to make the computer useful without consuming resources that applications needed.

DOS also incorporated ideas from other operating systems as it developed. Microsoft was already working with UNIX through its XENIX product, and MS-DOS 2.0 introduced hierarchical directories, file handles, input/output redirection, and pipes influenced by that experience. Although these features resembled their UNIX counterparts, their implementations differed. DOS pipes, for example, used temporary files to pass data between sequentially executed programs rather than connecting concurrently running processes.

CP/M and the Origins of PC DOS

Before the IBM PC appeared, Digital Research’s CP/M was an important operating system for microcomputers. CP/M gave programmers a common set of operating-system services, even when the computers themselves differed. That made it easier to bring applications to more than one machine.

IBM needed an operating system for its new Intel 8088-based PC. Microsoft supplied one, although the software did not begin as a Microsoft product.

Seattle Computer Products had created an operating system called 86-DOS, initially known as QDOS, for Intel 8086-based computers. Its design drew upon familiar CP/M conventions while providing an operating environment for the newer processor family.

Microsoft acquired the necessary rights to 86-DOS, adapted it for IBM’s hardware, and supplied it for the IBM PC. IBM distributed the resulting operating system as PC DOS, while Microsoft licensed MS-DOS to other computer manufacturers.

IBM sold PC DOS with its machines, but manufacturers building compatible PCs could license MS-DOS from Microsoft directly. That arrangement helped establish DOS as a common platform beyond IBM hardware.

The DOS Operating Environment

DOS presented users with a command-line interface. Commands such as DIR, COPY, DEL, and CD allowed users to inspect directories, manage files, and navigate storage devices. Batch files made it possible to execute sequences of commands automatically.

Storage devices were identified by drive letters, while files were organized into directories. Early DOS releases used the FAT filesystem, which would remain closely associated with Microsoft operating systems for decades.

From the familiar C:\> prompt, a user could start a program, copy a file, or run a batch script. There was no desktop to navigate; the command line was the interface.

Traditional DOS was primarily a single-user, single-tasking environment. A program generally received control of the computer until it finished or returned control to DOS. Applications could use terminate-and-stay-resident techniques to provide limited background functionality, but DOS did not offer the kind of protected, preemptive multitasking associated with more sophisticated operating systems.

Memory management presented another difficulty. The original IBM PC architecture and DOS programming model imposed practical constraints on how applications used memory. Conventional memory was limited to the first 640 KB of the address space, while additional memory required specialized techniques and software.

Expanded memory, extended memory, memory managers, and DOS extenders helped applications use increasingly capable hardware. These approaches improved what DOS systems could accomplish, but they also introduced configuration complexity.

Hardware compatibility presented similar challenges. Applications, particularly games, frequently interacted directly with video adapters, sound cards, and other devices. That approach could provide excellent performance, but it also meant that software sometimes required configuration for specific hardware.

Those limitations mattered, particularly as PCs grew more capable. But DOS ran on modest hardware, and the amount of software written for it made switching operating systems difficult.

DOS compatibility helped establish a common software environment across IBM-compatible PCs, even when the computers came from different manufacturers.

IBM PC DOS and Microsoft MS-DOS

IBM PC DOS and Microsoft MS-DOS shared their origins and remained closely related through much of their development. Nevertheless, they were distributed by different companies and gradually acquired their own features, utilities, and release schedules.

IBM continued developing PC DOS after Microsoft’s attention increasingly shifted toward Windows. PC DOS 7, released in 1995, included additional utilities and improvements, while PC DOS 2000 represented a later release of IBM’s DOS family.

Microsoft’s standalone MS-DOS releases ended with version 6.22, although DOS continued as a component of Windows 95, Windows 98, and Windows Me.

Digital Research and DR-DOS

Digital Research, the company responsible for CP/M, developed its own DOS-compatible operating system.

DR-DOS was designed to run software written for MS-DOS while offering competing features and utilities. Its releases included improvements to memory management and system configuration that made it attractive to users attempting to get more from DOS applications.

The important distinction was compatibility, not ownership of the code. DR-DOS could run DOS applications by providing the services those programs expected.

Novell subsequently acquired Digital Research and released Novell DOS 7. The product later passed through additional ownership and development arrangements, including Caldera’s involvement.

The competition between Microsoft and Digital Research also produced controversy. The Windows 3.1 beta releases included the AARD code, which detected certain non-Microsoft DOS environments and displayed compatibility warnings. Compatibility was not just a technical concern. It was also a commercial one.

Other DOS Implementations

DR-DOS was not the only alternative. PTS-DOS provided another DOS-compatible implementation, while ROM-DOS was designed for environments where DOS functionality could be embedded in firmware or specialized devices.

PTS-DOS and ROM-DOS also showed how the DOS-compatible environment could be adapted to different uses.

A DOS program was no longer necessarily tied to one PC manufacturer or one DOS vendor. That expectation of compatibility would shape the next generation of PC operating systems.

The Lighter Side of DOS

Not every DOS program was intended to do useful work. Some were written to experiment with the hardware, change the command prompt, or simply amuse whoever happened to be sitting at the computer.

Love-DOS and Hate-DOS

Love-DOS and Hate-DOS were novelty command interpreters that changed how the computer responded to its user. Rather than replacing DOS itself, they altered the command-line experience by displaying affectionate or insulting messages.

I remember trying both programs and enjoying their unexpected responses. They also took advantage of a useful DOS feature: the command interpreter was separate from the operating-system services. You could replace the shell without replacing DOS itself.

HELPME.COM — Speech Through the PC Speaker

Another DOS program I remember is HELPME.COM. When I was young, my father called me into the computer room to hear a program that made the computer speak. A voice called for help, claiming to be trapped inside the machine.

The original IBM PC speaker was designed primarily to produce simple tones and alerts. By controlling the speaker rapidly, programmers could reproduce more complex sounds, including recognizable speech. The quality was limited, but hearing a computer speak without dedicated audio hardware was impressive at the time.

Years later, I found another copy of HELPME.COM and ran it through DOSBox for my own children. Initially, the speech played too quickly to understand. Some early programs depended upon processor timing rather than an independent clock, and modern computers can execute their instructions much faster than the original hardware.

Reducing DOSBox to approximately 900 CPU cycles allowed the program to play at a recognizable speed. Once I adjusted the timing, I could hear the same little program my father had shown me years earlier.

Download the historical HELPME.COM archive

The archive contains historical DOS software intended for use in a compatible environment such as DOSBox.

When trying early DOS software in DOSBox, processor timing can matter as much as software compatibility.

DOS Version Table

Microsoft’s DOS releases illustrate how the operating system evolved alongside IBM-compatible hardware. Early versions provided basic file and program management, while later releases introduced support for larger storage devices, more sophisticated memory management, and improved utilities.

The dates identify major releases rather than the length of their support.

The later DOS versions in the table shipped inside Windows. DOS was no longer always sold as a separate product, but it was still there.

OS/2

Intel processors were gaining capabilities that traditional DOS could not use directly, including protected memory and better support for multitasking. IBM and Microsoft began work on OS/2 to take advantage of that hardware.

Unlike early Windows, OS/2 was intended to replace DOS as the operating system, not merely provide another interface above it.

IBM and Microsoft’s Partnership

The original OS/2 was developed for Intel 80286-based computers, taking advantage of the processor’s protected mode.

Protected mode offered mechanisms for managing memory and separating operating-system functions from applications. OS/2 also supported preemptive multitasking, allowing the operating system to schedule execution among programs rather than relying entirely on applications to cooperate.

OS/2 1.0 arrived without a graphical desktop. Presentation Manager followed in OS/2 1.1, giving users a graphical interface for OS/2 applications.

OS/2 also introduced features such as the High Performance File System, or HPFS, which addressed limitations associated with FAT filesystems.

The IBM–Microsoft Split

Windows 3.0 sold well, and Microsoft increasingly favored Windows over the jointly developed OS/2. The companies disagreed about where PC operating systems should go next.

IBM continued OS/2 development after the partnership ended. Microsoft concentrated on Windows and the new NT architecture.

OS/2 2.x and Workplace Shell

IBM’s OS/2 2.0 introduced a substantially expanded 32-bit environment and the Workplace Shell desktop.

Workplace Shell used an object-oriented approach to desktop interaction. Files, folders, applications, and other resources were represented through objects with associated behaviors and properties.

OS/2 also maintained compatibility with DOS applications and supported selected Windows applications through compatibility facilities.

IBM promoted OS/2 as an operating system capable of running DOS, Windows, and native OS/2 applications. That compatibility was important because the existing DOS and Windows software libraries were already substantial.

Running existing software helped, but users also needed native applications and drivers for their hardware. Windows already had a growing software market, which made OS/2 a harder sell.

OS/2 Warp and Later Development

IBM continued developing OS/2 through the Warp releases, improving its desktop environment, networking, and application support.

OS/2 retained users in specialized business and industrial environments, but it did not displace Windows as the dominant operating system for IBM-compatible personal computers.

IBM eventually withdrew from active mainstream OS/2 development and support. Licensed successors continued the platform, however, including eComStation and later ArcaOS.

I knew about OS/2 while growing up and considered trying it, but never did. My experience with it has been from the outside rather than from using it on my own computers.

OS/2 offered protected memory and multitasking while maintaining compatibility with software written for earlier PC environments.

OS/2 Version Table

The final two entries are licensed successors, not IBM-branded OS/2 releases.

DOS-Based Windows

Microsoft took a different approach with early Windows: keep DOS and put a graphical environment above it.

Microsoft did not replace DOS immediately. Early Windows added a graphical interface while DOS continued to handle important parts of the system. Users could continue running familiar DOS applications while gaining access to graphical programs, windows, menus, and mouse-driven interfaces.

That arrangement changed as Windows gained more responsibility for memory, applications, and hardware. Windows 95 still included DOS, but much of the work was handled by Windows itself.

Windows 1.x and 2.x

Windows 1.0 appeared in 1985 as a graphical operating environment for MS-DOS.

It brought windows, menus, a mouse-driven interface, and graphical applications to machines that still started in DOS. Early PC hardware limited what it could do.

Windows 2.x improved window management and supported overlapping application windows. Later releases took advantage of newer Intel processors and their memory-management capabilities.

These versions established elements of the Windows interface, but Windows did not see widespread adoption until version 3.0.

Windows 3.x and Windows for Workgroups

Windows 3.0, released in 1990, brought major improvements to the graphical environment, memory management, and application support.

Windows 3.1 continued that development with improvements including TrueType font support and multimedia capabilities.

Windows for Workgroups added integrated networking features, making it easier for personal computers to share files, printers, and other resources.

Even with these improvements, Windows 3.x still started from DOS. Users could exit Windows and return to the DOS prompt.

Windows 95

Windows 95 introduced a substantially revised user interface, including the Start menu, taskbar, and a desktop model that would influence Microsoft operating systems for decades.

It also incorporated 32-bit components, improved multitasking, Plug and Play hardware configuration, and a more integrated operating environment.

Windows 95 was not based on the Windows NT kernel. Its startup process and compatibility architecture retained important DOS components. Windows 95 included MS-DOS 7.0, and users could configure the system to boot to a DOS command prompt rather than automatically launching the graphical environment.

Setting BootGUI=0 in MSDOS.SYS allowed the system to stop at the DOS prompt. The WIN command could then be used to start Windows.

That DOS startup option is easy to mistake for the Windows 3.x arrangement. Once Windows 95 was running, however, its 32-bit components handled tasks that earlier Windows versions had left to DOS.

Windows 95 still used DOS during startup, but its running environment was considerably more than the old DOS command line with a graphical shell.

Windows 98 and Windows 98 Second Edition

Windows 98 continued the Windows 95 architecture while improving hardware support, networking, and integration with the expanding Internet-oriented software environment.

USB support was particularly important. Although USB support had appeared in certain Windows 95 releases, Windows 98 made the technology more practical for a broader range of users and hardware.

Windows 98 Second Edition, released in 1999, added Internet Connection Sharing and refinements to networking, hardware support, and bundled software. It was a well-developed version of the Windows 9x system, not a move to the NT architecture.

Windows Me and the End of the DOS Line

Windows Millennium Edition, released in 2000, was Microsoft’s final consumer operating system based on the Windows 9x architecture.

It introduced features such as System Restore and additional multimedia capabilities while restricting some traditional real-mode DOS startup behavior.

Windows Me did not achieve the same reputation for maturity as Windows 98 SE. More importantly, it arrived at a time when Microsoft already had a separate and increasingly capable operating-system family built around Windows NT.

Windows Me and Windows 2000 both appeared in 2000, but they came from different operating-system families. Me continued the DOS-based consumer line, while Windows 2000 used NT. Microsoft would soon bring its consumer systems over to NT as well.

The Lighter Side of DOS-Based Windows

Once PCs had graphical desktops, the little novelty programs could wander around the screen instead of responding from a command prompt. Microsoft also tried some unusual ideas of its own.

eSheep

One program I remember particularly well is eSheep. It put an animated sheep on the Windows desktop, where it wandered around and interacted with the screen. It served no practical purpose, which was part of the appeal.

I remember running ten or twenty sheep at once. A whole flock wandering across the desktop was better than just one.

The original eSheep was a 16-bit Windows application. I eventually located a copy of its trial version, and its executable identifies it as software intended for the Windows 3.1 environment rather than a DOS program or a later Win32 application.

Download the original eSheep trial archive

Running the original program requires a compatible historical Windows environment or suitable emulation.

Microsoft Bob

Microsoft also experimented with alternative ways to present the graphical desktop. Microsoft Bob, released in 1995, replaced conventional desktop metaphors with a virtual household in which rooms and familiar objects represented computer functions.

The interface was intended to help inexperienced users navigate a personal computer without first learning the conventions of windows, directories, and application menus. Rather than organizing tasks around a traditional desktop, Bob presented them through recognizable household objects and animated guides.

Bob did not catch on, and the conventional Windows desktop remained. It is still an interesting example of how Microsoft tried to make the PC approachable to someone who had never used one.

DOS-Based Windows Version Table

NT Windows

DOS-based Windows grew out of the original PC environment. Windows NT was built on a different foundation.

Microsoft designed NT with protected memory, preemptive multitasking, security, multiprocessing, and hardware abstraction. It also had to support existing Windows applications if Microsoft expected businesses to adopt it.

Windows NT and Windows 95 could look similar on screen, but they did not manage memory, processes, or security in the same way.

Dave Cutler and the Development of NT

Microsoft recruited Dave Cutler from Digital Equipment Corporation to lead development of NT. Cutler had worked on VMS, and that experience influenced NT’s design.

The project grew out of Microsoft’s plans for an advanced OS/2 successor, but the company redirected it toward Windows compatibility. NT became a separate operating-system family rather than an extension of DOS or Windows 3.x.

NT Architecture

Windows NT provided preemptive multitasking, allowing the operating system to schedule execution among processes.

Protected virtual memory helped isolate applications from one another and from the operating system. A failure in one ordinary user process was therefore less likely to damage unrelated processes than in the DOS-derived Windows environment.

NT also incorporated security mechanisms, user accounts, access controls, and services appropriate for networked and multi-user computing.

Its hardware abstraction layer helped separate operating-system components from hardware-specific details. Early NT releases supported multiple processor architectures, reflecting Microsoft’s interest in an operating system that was not permanently tied to a single PC processor family.

NT also included compatibility subsystems intended to support existing applications. These allowed many DOS and older Windows programs to run, although compatibility depended upon processor architecture, operating-system version, and application behavior.

Application compatibility was a feature of NT, not evidence that DOS was running underneath it.

Windows NT Workstation and Server

Windows NT 3.1 appeared in 1993, using a graphical interface similar to Windows 3.1 while operating on the new NT architecture.

NT 3.5 and 3.51 improved performance, networking, and support for additional hardware and applications.

Windows NT 4.0 adopted the Windows 95-style interface, making the two families look increasingly similar despite their architectural differences.

Microsoft offered NT editions for workstations and servers. Server editions included capabilities intended for centralized administration, network services, and organizational computing.

NT became an important foundation for Microsoft business networks while Windows 95 and 98 continued serving much of the consumer market.

Windows 2000

By Windows 2000, the NT family had become a practical choice for more professional desktops. Its improved hardware support, networking, and administrative tools helped make that possible.

Windows 2000 Professional served desktop and workstation users, while the Server editions provided additional networking and enterprise features.

Active Directory, introduced with Windows 2000 Server, offered directory services for organizing and administering users, computers, and other network resources.

Windows 2000 still belonged to a different family from Windows 98 and Me. Businesses gained NT’s memory protection and administrative features, although some older hardware and applications still worked better under Windows 9x.

Windows XP and the Convergence of Windows

Windows XP, released in 2001, brought Microsoft’s mainstream consumer and professional desktop products together on the NT architecture.

Earlier consumer Windows releases had relied upon the DOS-derived Windows 9x architecture. Windows XP instead used the NT kernel and operating-system model while retaining a familiar graphical interface and substantial compatibility with existing Windows applications.

Windows XP brought NT’s process isolation, security model, and multitasking to home PCs. It was closer architecturally to Windows 2000 than to Windows Me, regardless of how familiar the desktop looked.

Modern Windows and Windows Server

Windows Vista introduced substantial changes to the Windows driver model, security, graphics, and system architecture. Some of these changes caused compatibility and performance difficulties, but they also established foundations that later Windows releases refined.

Windows 7 improved the experience of the Vista generation, while Windows 8 and 8.1 introduced major interface changes intended to accommodate touch-oriented devices.

Windows 10 and Windows 11 continued development of the NT family with changes to security, hardware requirements, application support, and the desktop environment.

Windows Server likewise continued as an NT-based family designed around network services, centralized administration, virtualization, storage, and enterprise workloads.

Not everything called Windows used the NT architecture. Windows CE, for example, was a separate operating system for embedded and specialized devices.

The name on the box did not always tell you which Windows architecture was underneath.

Similar-looking Windows desktops did not necessarily mean the same operating system was running underneath.

The Lighter Side of Windows NT

Some of the stranger things I remember from the Windows era came from applications rather than Windows itself. Microsoft put animated assistants into Office and other software, and developers hid games in a few Office releases. These were application features, not part of the NT kernel.

Clippy and Microsoft Agent

Microsoft Office introduced the Office Assistant, a feature intended to provide context-sensitive help while users worked with documents, spreadsheets, and other applications. Its best-known character was Clippit, commonly called Clippy, an animated paperclip that appeared with suggestions and questions.

The assistant attempted to anticipate when users might need help. Although the idea was intended to make software more approachable, its interruptions were not always welcome. Clippy nevertheless became one of Microsoft’s most recognizable interface experiments.

Microsoft Agent provided related technology for animated characters capable of speaking, moving, and responding to scripted interactions. Developers could incorporate these characters into applications, extending the idea of a graphical assistant beyond Microsoft Office.

Clippy was supposed to help, but anyone who had the paperclip interrupt their work can understand why it became a joke.

Hidden Games in Microsoft Excel

Microsoft Office also became known for Easter eggs: hidden features and demonstrations that were not part of an application’s ordinary functionality. Several releases of Excel contained elaborate graphical environments that could be accessed through particular sequences of commands.

Excel 95 — Hall of Tortured Souls

Excel 95 included a hidden first-person environment called Hall of Tortured Souls. Its appearance resembled the three-dimensional games popular during the period, particularly Doom, although it was an explorable maze rather than a complete shooting game.

Historical instructions for accessing it describe the following sequence:

1. Open a worksheet and select row 95.
2. Press Tab to move to cell B95.
3. Open Help → About Microsoft Excel.
4. Hold Ctrl + Alt + Shift while clicking Tech Support.
5. Explore the hidden environment.

The maze also contained a secret area associated with the code EXCELKFA.

Excel 97 — Flight Simulator

Excel 97 included a hidden three-dimensional flight demonstration. Users could move across a graphical landscape and discover developer credits.

To access it in the original release:

1. Open a worksheet and press F5.
2. Enter X97:L97 and press Enter.
3. Press Tab.
4. Hold Ctrl + Shift while clicking the Chart Wizard toolbar button.

I remember playing an Excel flight simulator while using Windows 2000 and Office 2000. The documented flight simulator Easter egg belongs to Excel 97, however, so my recollection of the software version may differ from the published instructions.

Excel 2000 — Dev Hunter

Excel 2000 included another hidden game called Dev Hunter. This demonstration used a driving environment reminiscent of arcade vehicle games.

The game is associated with the original Excel 2000 release before Service Release 1. Accessing it required saving an interactive worksheet as a web page and opening it in a compatible version of Internet Explorer with the necessary Office Web Components and DirectX support.

Historical instructions describe the process as follows:

1. Open Excel 2000.
2. Choose File → Save As Web Page.
3. Enable interactivity and save the page.
4. Open the saved page in a compatible version of Internet Explorer.
5. Navigate to row 2000 and column WC, select row 2000, then press Tab to make cell WC2000 active.
6. Hold Ctrl + Alt + Shift and click the Office logo.

The game depended upon software components specific to that period. Office 2000 Service Release 1 removed access to the Easter egg.

Microsoft Word 97 also contained a hidden pinball game, demonstrating that these experiments were not limited to Excel.

A flight simulator hidden in a spreadsheet is a strange idea, but I can see why developers enjoyed putting it there.

To try these Easter eggs, you generally need the original software and a compatible environment. They are not included in modern Office releases.

The hidden Office games belonged to particular software releases. Reproducing them usually means recreating the software environment of their time.

NT Windows Version Table

The Windows NT family developed alongside DOS-based Windows before becoming Microsoft’s primary desktop and server architecture.

The following table emphasizes major desktop releases, with server development discussed in the accompanying text.

Windows Server releases continued in parallel with the desktop family, sometimes sharing closely related underlying NT versions while providing different capabilities and release schedules.

FreeDOS

Microsoft stopped selling standalone MS-DOS, but DOS development did not end. Older programs and specialized equipment still needed it, and developers wanted a DOS-compatible system they could use, modify, and distribute freely.

FreeDOS is a free and open-source DOS-compatible operating system with its own kernel, command interpreter, utilities, and software packages. It does not use Microsoft’s DOS source code, and it is not an emulator pretending to be DOS.

Origins and Development

Jim Hall announced the project in 1994, as Microsoft’s attention shifted toward Windows 95 and the future of standalone DOS became uncertain. Initially known as PD-DOS, the effort soon became FreeDOS. Its goal was to provide a complete operating system capable of running traditional DOS software without requiring a proprietary Microsoft DOS installation.

Contributors developed and assembled replacements for the familiar components of a DOS system. The project eventually produced complete distributions rather than only a collection of separate programs. FreeDOS 1.0 arrived in 2006, followed by later releases that continued to update the operating system and its accompanying software.

FreeDOS 1.4 was released on April 5, 2025. Between major releases, the project also provides test distributions so people can try newer components.

The FreeDOS Operating Environment

FreeDOS retains the basic DOS model: drive letters, a command prompt, batch files, familiar filesystem operations, and the ability to run many programs written for MS-DOS. Its command interpreter, FreeCOM, provides the environment in which users enter commands and execute batch files.

The distribution also offers file-management tools, editors, archivers, memory-management utilities, device support, and other software. Packages allow users to install additional programs according to their needs, rather than limiting the system to the utilities bundled with an early commercial DOS release.

FreeDOS also includes tools for people who want to write DOS software. Compilers, assemblers, debuggers, and editors make it possible to develop programs rather than only run old ones.

Its architecture remains recognizably DOS. FreeDOS does not acquire protected memory, modern process isolation, or the Windows NT driver model merely by including newer utilities. Improvements to its software should not be confused with a replacement of the underlying DOS operating model.

Graphical Interfaces

FreeDOS normally presents a command-line environment, but a DOS-compatible computer need not be limited to text commands. Graphical desktops can run above DOS and provide windows, icons, menus, and mouse-driven applications.

OpenGEM is one option available for FreeDOS. It continues the GEM graphical desktop tradition associated with Digital Research and provides a graphical interface without replacing the DOS system underneath it. OpenGEM remains available with FreeDOS 1.4, although it is distributed on the BonusCD rather than installed as part of the basic system. Other DOS graphical environments, including SEAL and oZone, have also been developed. Both appeared in earlier FreeDOS distributions, but were dropped from FreeDOS 1.4 because of reliability problems.

Like Windows 3.x in its early days, these interfaces run above DOS. Installing one does not replace the DOS kernel.

Applications and Practical Uses

FreeDOS is useful for retrocomputing and software preservation, but those are only part of its purpose. It can run many DOS games, productivity programs, development environments, and utilities. It can also serve as a platform for writing and testing new software designed for DOS-compatible systems.

The available software includes networking tools and other applications that extend what can be done from the traditional command line. Some specialized maintenance and industrial tasks also continue to benefit from DOS-compatible software, although suitability depends on the particular application and hardware.

FreeDOS can run on compatible physical PCs and in virtual machines or emulators. Running it directly on newer hardware can be difficult because of firmware changes, missing legacy interfaces, and driver availability. Virtualization often provides a more predictable environment, but it is not the only way to use the system.

Compatibility is not universal. Programs that depend on undocumented DOS behavior, unusual drivers, or direct access to particular hardware may need additional configuration or may not work correctly.

DOS Continues

FreeDOS continues the DOS environment instead of trying to turn it into Windows or Linux. The command prompt and familiar interfaces remain, while the operating system and its utilities continue to receive updates.

You can still install FreeDOS, configure it, and write software for it. DOS is no longer the standard PC operating system, but it remains usable.

A graphical desktop can run above DOS without changing the operating system underneath it.

ReactOS

FreeDOS provides an open-source implementation of DOS. ReactOS attempts something different: an open-source operating system compatible with Windows NT, including the application and driver interfaces Windows software expects.

ReactOS is not a Linux distribution with a Windows-looking desktop. Its developers are implementing an operating system of their own.

Origins and Compatibility Goals

ReactOS began as an effort to reproduce the Windows operating environment without Microsoft’s code. Its compatibility goals have changed as Windows has changed, from NT 4.0 through Windows 2000 and XP-era systems.

The project eventually settled on Windows Server 2003 (NT 5.2) as a principal compatibility baseline.

I first discovered ReactOS when the project was targeting Windows 2000 compatibility. The idea of an open-source operating system capable of running Windows applications interested me immediately, and I have checked on its progress every few years since. I have never needed ReactOS myself, but if I had a Windows application that required a Windows-compatible environment, ReactOS would be my first alternative to try.

Using Windows Server 2003 as a baseline gave developers a defined collection of APIs, services, and driver behavior to implement. Supporting a particular NT generation is already a substantial undertaking without changing the target every time Microsoft releases another version of Windows.

Independent Implementation

ReactOS developers implement compatible operating-system functionality independently, without deriving it from Microsoft’s Windows NT source code. They rely on available documentation, testing, and other lawful development techniques.

The project also incorporates work from other open-source software, including components associated with Wine, which implements Windows application interfaces on other operating systems.

Wine provides Windows-compatible application interfaces on other operating systems. ReactOS needs an entire operating system beneath those interfaces, including kernel services and drivers.

A program may call a familiar Windows API and still depend on lower-level behavior that ReactOS has not implemented. The same is true of drivers.

Development and Limitations

ReactOS remains experimental. Although it can run some Windows applications and supports portions of the expected NT environment, compatibility is incomplete. Driver support, application behavior, stability, and hardware compatibility remain important development challenges.

ReactOS 0.4.16, released on August 29, 2026, introduced a graphical installer, a combined live and installation image, and improvements to storage, audio, networking, and hardware compatibility. The release also included work to update its Wine-derived components toward Wine 10.0.

The project has relaxed its earlier strict adherence to Windows Server 2003 compatibility so it can incorporate newer interfaces. Standard 0.4.16 release images still expose Windows Server 2003-era exports by default, however; newer Windows API exports remain experimental and require a specially configured build. These changes expand the work under way without making ReactOS a complete replacement for modern Windows.

The graphical installer makes ReactOS easier to try, but it does not resolve every application or driver compatibility problem.

Summary

DOS developed around the practical limitations of early personal computers. Its command-line environment, file management, and software interfaces became familiar across a growing collection of IBM-compatible machines. Microsoft played a central role in that development, but IBM, Digital Research, and other companies also produced DOS-compatible operating systems.

OS/2 represented an attempt to move beyond DOS through a more sophisticated operating-system architecture. Although IBM and Microsoft initially developed it together, their paths eventually separated. IBM continued OS/2, while Microsoft pursued both DOS-based Windows and Windows NT.

The Windows name came to describe two different architectural families. Windows 95, 98, and Me extended the DOS-derived environment, while Windows NT introduced protected memory, preemptive multitasking, stronger security, and other capabilities expected of a modern general-purpose operating system. Windows XP ultimately brought mainstream consumer Windows onto the NT foundation.

Those older operating-system families have not entirely disappeared. FreeDOS remains an actively developed DOS-compatible operating system, complete with its own tools, applications, and optional graphical desktops. ReactOS is still working toward a usable, open-source Windows NT-compatible operating system. Both projects are still being developed. They also show how long an operating-system interface can remain useful after the computers that first used it are gone.

Linux took another route. It did not descend from the UNIX source tree. Linus Torvalds began writing a new kernel in 1991 for his own computer, implementing an operating model that was already recognizably Unix-like. Linux eventually became compatible with many of the standards and conventions that allowed different Unix systems to work in similar ways, without generally pursuing the certification required to use UNIX as a formal trademark.

That difference can become surprisingly difficult to see from the command line. Log into a BSD system and then a Linux system and much of the environment remains familiar. There are processes, users, groups, permissions, pipes, shells, sockets, devices, daemons, and a filesystem rooted at /. The commands and administrative details may differ, but both systems belong to the broader Unix tradition.

Linux represents another way that Unix survived. BSD carried the original family forward through historical lineage. Linux independently implemented the model and then became the foundation upon which many different operating systems could be assembled.

Linux Begins With a Kernel

The history of Linux begins with a distinction that is easy to lose after more than thirty years of Linux distributions: Linux was a kernel, not a complete operating system.

Torvalds did not need to write every component of a Unix-like operating system because much of the surrounding software already existed. Once the Linux kernel could run that software, independently developed pieces could be assembled into a working system.

Linux began as a kernel. The operating systems we call Linux grew by combining that kernel with software from many other projects.

Linus Torvalds and the 386

Linus Torvalds began developing Linux in 1991 while studying at the University of Helsinki. He was using MINIX, Andrew Tanenbaum’s small Unix-like operating system, on an Intel 386 computer and wanted to experiment with features of the processor and operating-system design.

Linux initially depended heavily on the environment in which it was developed. MINIX was used as a development platform, and the early kernel was specifically written for the 386. That did not make Linux a modified version of MINIX, however, any more than compiling a program on Linux makes that program part of the Linux source tree.

More importantly for our family history, Linux did not contain inherited UNIX source. Torvalds was implementing a new kernel around familiar Unix concepts and interfaces.

This places Linux in a very different historical position from BSD. We can trace BSD backward through Berkeley UNIX and ultimately into the original UNIX family. With Linux, the historical line of source descent stops with Linux itself.

The ideas did not.

What the Kernel Actually Provides

A kernel sits between programs and the underlying machine. Applications normally do not manipulate the processor, physical memory, disks, or other hardware directly. They request services from the kernel.

Among other responsibilities, a kernel provides mechanisms for:

• scheduling processes and threads;
• managing virtual and physical memory;
• accessing storage through filesystems;
• communicating with hardware through device drivers;
• providing networking;
• enforcing process and user permissions;
• handling communication between processes;
• and exposing system calls through which programs request these services.

Those mechanisms are enough to make Linux a kernel. They are not enough to make it the operating environment most people imagine when they say they are running Linux.

A user still needs a shell. Programs need libraries. Someone needs compilers and development tools to build software. Basic commands such as copying files, listing directories, manipulating text, and managing the machine have to come from somewhere. A usable system also needs configuration, startup mechanisms, networking utilities, and eventually a way to install and maintain additional software.

Torvalds recognized this very early. Linux 0.01 was not presented as though the kernel alone constituted everything required for a useful system. The surrounding Unix-like software was expected to come from elsewhere.

Much of it already had.

GNU Had Much of the Rest

The GNU Project predated Linux by several years. Its goal was to develop a free Unix-compatible operating system, and by the beginning of the 1990s it had already produced important parts of the environment required to build one.

GNU software included components such as:

• the GCC compiler;
• the GNU C Library;
• the Bash shell;
• file and text-processing utilities;
• development tools;
• and implementations of many familiar Unix commands.

GNU’s missing piece was a production-ready kernel. The project was developing the Hurd, but that effort had not yet produced the practical kernel needed to complete the GNU operating system.

Linux and GNU met from opposite directions. GNU had much of a Unix-like environment but lacked a ready kernel. Linux supplied a usable kernel but depended upon software outside the kernel to become a practical operating system.

Other projects supplied still more pieces. A conventional Linux system was never simply the work of Torvalds plus the work of GNU. It became an assembly of software maintained by many projects, organizations, companies, and individuals.

This history also explains the argument over the term GNU/Linux. The argument can become more distracting than useful, but the technical point underneath it is real. Linux is the kernel. GNU supplied many important parts of the environment traditionally associated with a Linux system, while many additional components came from elsewhere.

Throughout this article, I will use Linux in the common broader sense when discussing the operating-system family and Linux kernel when the distinction matters.

Linux and the GPL

Licensing helped shape the family that developed around Linux as well.

Early Linux releases did not initially use the GNU General Public License, but Torvalds relicensed the kernel under GPL version 2 in 1992. The GPL allowed people to use, study, modify, and redistribute Linux while requiring distributed derivative versions to preserve access to corresponding source under the same licensing terms.

That differs from the permissive licensing tradition associated with BSD. BSD-style licenses generally allow code to be incorporated into other projects with relatively few requirements. The GPL uses copyleft: redistribution remains possible, but the freedoms provided by the license travel with distributed derivative work.

Neither approach prevented large communities or commercial systems from developing. They established different rules under which those communities could build upon existing work.

The BSD and Linux families therefore differ in more than technical ancestry. Part of the environment in which their source code developed was different as well.

Kernel, Userspace, and the Complete System

Once Linux is understood as a kernel, the variety of systems called Linux becomes easier to explain. The kernel provides a common foundation, but it does not determine everything above it.

The software running outside the kernel is generally described as userspace. This includes both the programs a person directly uses and much of the supporting environment that makes those programs possible.

What Lives Above the Kernel?

A conventional Linux installation may combine the kernel with several layers of software.

A simplified system might contain:

1. Linux kernel — process scheduling, memory, filesystems, drivers, networking, and other kernel services.
2. System libraries — interfaces that applications use to reach kernel and system services.
3. Core utilities — commands for manipulating files, text, processes, users, and the system.
4. Shells — interactive and programmable command environments such as Bash.
5. Boot and service software — tools responsible for bringing the system into operation and managing long-running services.
6. Package management — software for installing, upgrading, removing, and tracking other software.
7. System services — networking, logging, scheduled tasks, remote access, and other background functions.
8. Graphical environment — when required, display systems, desktop environments, window managers, and graphical applications.
9. Applications — everything from editors and compilers to databases, web servers, browsers, and games.

GNU supplies important pieces of this stack on conventional Linux systems, but it does not supply everything.

The same kernel can therefore sit underneath systems intended for very different purposes.

Android Shows the Difference

Android provides a particularly clear example.

Android uses the Linux kernel, but the environment above that kernel differs substantially from a conventional desktop or server Linux distribution. Its application framework, runtime, libraries, security model, user interface, and normal method of software distribution are designed around mobile devices rather than around the traditional GNU/Linux environment.

An Android phone demonstrates why uses Linux and is a conventional Linux distribution are not identical statements.

The kernel can travel without taking the familiar desktop or shell environment with it.

That separation became one of Linux’s greatest advantages. Linux could be adapted to servers, routers, phones, embedded systems, supercomputers, appliances, and desktops because the software above the kernel could change dramatically while the kernel continued performing the underlying work.

Turning Linux Into an Operating System

Having a kernel and a collection of compatible software still leaves a substantial problem. Someone has to decide exactly which pieces belong together and how they should operate as a coherent system.

That work produces a Linux distribution.

A distribution is not simply Linux with a wallpaper, installer, and project name added. It represents a collection of technical and organizational decisions about how the kernel and surrounding software become an operating system.

A Linux distribution is a set of decisions about how to turn the Linux kernel and the surrounding software ecosystem into a usable operating system.

Distributions Make Kernel Decisions

The common component between Linux distributions is the Linux kernel project and source—not necessarily an identical compiled kernel.

A distribution has to decide how Linux itself will be supplied. Those decisions can include:

• which kernel version or branch to use;
• how frequently to adopt new kernel releases;
• which processor architectures to support;
• which drivers and subsystems to enable;
• which features should be compiled directly into the kernel;
• which features should be built as loadable modules;
• whether distribution-specific patches should be applied;
• which security and hardening options should be enabled;
• how long a kernel release will be maintained;
• and whether fixes from later kernels should be backported into an older maintained version.

Two machines reporting that they run Linux may therefore not be running the same kernel build.

A long-lived enterprise distribution may deliberately maintain an older kernel while backporting selected security fixes and hardware support. A rolling distribution may move to newer upstream kernels much more quickly. An embedded distribution might compile only the functionality required for one device.

The distribution’s decisions begin at the kernel.

Distributions Make Userspace Decisions

Above the kernel, the number of choices increases dramatically.

A distribution must decide which software becomes part of the base system and how that software should be configured. Among the decisions are:

• C library and other system libraries;
• command-line utilities;
• available shells;
• filesystem layout and conventions;
• boot process;
• service management;
• networking tools;
• logging;
• security defaults;
• administrative tools;
• graphical systems;
• default desktop environment, if any;
• hardware-detection tools;
• proprietary driver and firmware policies;
• documentation;
• localization;
• and default applications.

Some distributions try to provide a complete working environment immediately after installation. Others deliberately begin with a minimal system and expect the administrator to decide what gets added.

Neither choice is inherent to Linux.

It is a distribution decision.

Package Management Solves Another Problem

Software installation creates another layer of complexity.

A modern Linux installation may contain thousands of packages maintained by hundreds or thousands of upstream projects. Those packages depend upon one another. A program may require a particular library. That library may require another package. Several programs may need compatible versions of the same shared components.

A distribution needs more than a file format for software packages. It needs an infrastructure for maintaining the relationships among them.

Modern package management generally combines several related mechanisms:

• a package format;
• a database of installed software;
• repositories containing available packages;
• dependency information;
• cryptographic verification;
• tools for retrieving packages;
• dependency resolution;
• upgrade mechanisms;
• and policies governing which package versions belong together.

This infrastructure is so routine today that it is easy to underestimate how much work it performs.

I remember when it was much harder to ignore.

Installing an RPM could lead to what became known as RPM Hell. Package A required Package B. Package B required C and D. D required another library, and that library might require a different version of something already installed. An installation that began with one downloaded RPM could turn into hours of searching for dependencies.

That was not really an inherent flaw in RPM. Debian could be just as unpleasant before its higher-level package-management tools handled these relationships automatically. RPM Hell is simply the name that stuck in the vocabulary.

A package format and a package manager are not the same thing. RPM defines how software is packaged; repositories and package-management tools handle retrieval, dependencies, upgrades, and distribution policy.

Commands such as:

```text id=”joqjo3” apt install dnf install pacman -S

look simple because the distribution has moved a great deal of complexity somewhere else.

### Release Models Are Distribution Decisions

Distributions also have to decide how change reaches the user.

One approach is to produce **discrete releases**. A collection of software is selected, integrated, tested, and released together. That release can then be maintained while development continues toward another version.

Another approach is the **rolling release**. Instead of periodically replacing one complete distribution release with another, packages continually move forward as newer versions are accepted.

There are many variations between those approaches. Enterprise distributions may maintain releases for years. Community distributions may release frequently. Some distributions divide development into stable, testing, and unstable branches. Others stay comparatively close to upstream releases.

These policies affect how a distribution feels at least as much as its package format.

The question is not simply, *What software does this distribution contain?*

It is also, *How does this distribution manage change?*

## The First Linux Distributions

The need for distributions became apparent almost immediately.

Early Linux users could assemble systems themselves, but doing so required knowledge and effort that limited who could realistically use Linux. Distributions began collecting the kernel and surrounding software into forms that could be installed and maintained more conveniently.

Several early projects helped establish the idea, including **MCC Interim Linux, Softlanding Linux System, TAMU Linux, and Yggdrasil Linux**.

Not all of them survived, but they established the distribution as a distinct layer of the Linux ecosystem.

### Softlanding Linux System

Softlanding Linux System, usually called **SLS**, became particularly influential.

SLS attempted to provide a relatively complete Linux environment rather than merely distributing the kernel and a few tools. It included a substantial collection of software and helped demonstrate that Linux could be distributed as something approaching a complete general-purpose operating system.

Its weaknesses were influential too.

Patrick Volkerding began modifying SLS, eventually producing Slackware. The company that became SUSE also interacted with SLS and Slackware during its early history before developing its own distribution.

A project does not need to survive indefinitely to influence the family tree.

### A Family Tree With Several Roots

The resulting genealogy is more complicated than drawing a line from one original Linux distribution to everything that followed.

Some distributions descended directly from earlier systems. Others borrowed tools or ideas without sharing ancestry. Some began from another distribution but eventually rebuilt enough of the system to establish an independent line. Later distributions could ignore the existing families entirely and return to the common Linux and free-software ecosystem.

A useful Linux genealogy therefore needs to show two processes:

- **descent**, where one distribution is built from another;
- **independent assembly**, where developers return to Linux and the surrounding software and create a new distribution family.

> Sharing technology does not establish genealogy. Two distributions can use the same package format without belonging to the same family.

SUSE and Red Hat both use RPM packages, for example, but SUSE is not therefore a Red Hat descendant.

### The Linux Family Tree

The Linux family tree does not have a single distribution at its root. Linux itself, GNU software, and software from other projects provided the common pool of components. Early developers assembled those components into distributions, some of which became ancestors of long-lived families. Later developers could return to the same underlying source projects and begin again.

The following tree is deliberately selective. It traces the major lines discussed in this article rather than attempting to include the thousands of Linux distributions that have existed.

```text id="2bio7e"
Linux kernel + GNU + other free software
│
├── Early Linux distributions
│   │
│   ├── MCC Interim Linux
│   │
│   ├── SLS — Softlanding Linux System
│   │   │
│   │   ├── Slackware
│   │   │   └── Slackware family
│   │   │
│   │   └── early S.u.S.E. history
│   │       ├── SLS distribution
│   │       ├── Slackware-based S.u.S.E.
│   │       └── Jurix influence / rebuild
│   │           └── SUSE
│   │               ├── openSUSE
│   │               └── SUSE Linux Enterprise
│   │
│   ├── Yggdrasil Linux
│   │
│   └── other early systems
│
├── Debian
│   │
│   ├── Ubuntu
│   │   ├── Xubuntu
│   │   ├── Kubuntu
│   │   ├── Lubuntu
│   │   ├── other Ubuntu flavors
│   │   └── Linux Mint
│   │
│   └── Linux Mint Debian Edition (LMDE)
│
├── Red Hat Linux
│   │
│   └── Fedora
│       └── CentOS Stream
│           └── Red Hat Enterprise Linux
│               ├── historical CentOS Linux
│               ├── Rocky Linux
│               └── AlmaLinux
│
├── Later independent families
│   │
│   ├── Gentoo
│   │   └── Gentoo family
│   │
│   └── Arch Linux
│       ├── Manjaro
│       └── EndeavourOS
│
└── Linux From Scratch
    └── instructions for assembling a Linux system
        directly from the underlying source projects

Linux Mint illustrates why Linux genealogy sometimes resists a simple tree. Its principal edition is based on Ubuntu, while Linux Mint Debian Edition (LMDE) is based directly on Debian.

The Red Hat branch also needs some explanation because the direction of development has changed over time. Fedora serves as an upstream source for future Red Hat Enterprise Linux development, while CentOS Stream occupies the development space between Fedora and RHEL. Historical CentOS Linux worked in the other direction: it was built downstream from released RHEL sources. Rocky Linux and AlmaLinux later emerged as RHEL-compatible distributions, although their exact build policies are not identical.

The rest of the upper chart mostly shows ordinary distribution ancestry. Slackware emerged from work on SLS. Ubuntu is built from Debian. Descendants can then become parents of additional distributions.

SUSE is more complicated. Its early history passed through SLS and Slackware before the project rebuilt the distribution and established an independent SUSE line. Modern SUSE should not be treated simply as a Slackware descendant, and its use of RPM certainly does not make it a Red Hat descendant.

Gentoo and Arch show another path. They did not have to descend from Debian, Red Hat, Slackware, or SUSE. Their developers could return to the Linux kernel and the larger collection of independently maintained software and construct new distributions around their own decisions.

Linux From Scratch takes that possibility almost literally. It is not another family equivalent to Debian or Red Hat. It documents how to return to the underlying components and assemble a Linux system yourself.

The Linux family tree has an unusual property: you can always go back to the roots and start another branch.

The Major Distribution Families

Thousands of Linux distributions have appeared over the years. Trying to place every one of them into a single chart quickly becomes more distracting than informative.

Four early families are particularly useful because they survived, developed recognizable approaches to system design, and influenced large parts of the Linux ecosystem:

• Slackware;
• Debian;
• Red Hat;
• and SUSE.

They all use Linux, and they often use much of the same upstream software. What separates them is how each project assembles and maintains those components.

Slackware — Keeping It Simple

Slackware emerged in 1993 from Patrick Volkerding’s work modifying and correcting SLS. It became one of the earliest successful Linux distributions and remains the oldest of the major early distributions still maintained.

Slackware has retained a comparatively traditional approach to Unix-like system administration. Rather than placing a specialized management layer over every component, it tends to expose the underlying system more directly.

Slackware still makes distribution decisions. Its preference for simplicity and conventional administration is itself a set of decisions about how the system should be assembled.

Its package management has historically reflected that philosophy as well. Slackware packages are relatively straightforward archives containing software and installation information. The system has generally placed less emphasis on automatic dependency resolution than distributions such as Debian or Red Hat.

That can require more knowledge from the administrator, but it also makes the machinery easier to see.

Slackware occupies an interesting place in Linux history. It was one of the earliest successful attempts to make Linux easier to install while continuing to expect users to understand what is happening underneath that convenience.

Debian — Stable Means Stable

Debian also began in 1993, but developed around a different organizational and technical model. Rather than becoming primarily a commercial distribution, Debian grew into a community project with a strong commitment to free software and a large repository of packaged software.

Its approach to releases is one of its defining characteristics.

Debian development is commonly encountered through three branches:

• Stable — the current released distribution, emphasizing consistency and reliability;
• Testing — packages being prepared for the next Stable release;
• Unstable — active development, where newer package versions normally enter Debian.

There are additional mechanisms and repositories surrounding those branches, but the progression helps explain why Debian Stable behaves the way it does.

I use Debian on servers fairly often, and stable describes exactly why. If I install Debian Stable, I expect it to stay stable. I do not expect a routine update to suddenly give me a substantially different system.

The tradeoff is obvious. Packages in Stable can become old compared with current upstream versions.

That is not necessarily neglect. It follows from the purpose of the branch. Debian Stable is trying to provide a collection of software that has been integrated and tested together rather than continuously replacing components simply because newer versions exist.

Debian’s commitment to free software has also affected the practical experience of installing it.

Historically, proprietary firmware, drivers, codecs, and other non-free components could require additional work. That could be frustrating when the component in question was not philosophically interesting at all—it was simply the firmware required to make the network adapter function.

Debian has adjusted that balance over time. Beginning with Debian 12, official installation media can include distributable non-free firmware, reducing one of the most common installation problems while maintaining distinctions between free and non-free parts of the repository.

Linux itself does not determine whether proprietary firmware should be included on installation media. Debian has to make that decision.

Debian also became the foundation for one of the largest descendant families in Linux.

Ubuntu is built from Debian but makes different choices about releases, hardware support, desktop configuration, software availability, and the experience presented to someone installing the system. Ubuntu then became a foundation for additional distributions and official variants, including Xubuntu, Kubuntu, and Lubuntu. Linux Mint’s principal edition is also built from Ubuntu, while LMDE follows Debian directly.

Descendants receive an enormous amount of infrastructure from their parent and then make another layer of decisions.

I currently use Xubuntu when I want a desktop system that mostly works without requiring me to construct the desktop myself. Ubuntu has historically been more willing than Debian to smooth over issues involving drivers, codecs, and desktop hardware.

I am less enthusiastic about Canonical’s integration of Snap into Ubuntu. That does not make Ubuntu bad or Debian better. It means Canonical has made a distribution decision that I would not make for my own system.

That is exactly what distributions do.

Red Hat — Linux Goes to Work

Red Hat represents another important branch.

Red Hat Linux emerged during the 1990s and helped demonstrate that Linux could support a commercial operating-system business. Red Hat developed RPM—the Red Hat Package Manager—and built tooling and infrastructure around packaged software.

The modern Red Hat family does not fit neatly into a simple tree because the direction of development has changed. Fedora serves as an upstream community distribution from which major Red Hat Enterprise Linux development draws. CentOS Stream sits between Fedora and RHEL, providing a continuously delivered view of work intended for upcoming RHEL releases.

Historical CentOS Linux worked in the other direction. It was built downstream from released RHEL sources, providing a closely compatible system without the Red Hat branding and commercial support. The CentOS Project later shifted its focus from that downstream rebuild model to CentOS Stream.

Rocky Linux and AlmaLinux appeared after that shift to provide RHEL-compatible community distributions, although their current policies and methods are not identical. CentOS Stream is upstream of upcoming RHEL releases, while Rocky Linux and AlmaLinux aim to remain compatible with released RHEL.

This family has long emphasized Linux as a platform for long-term administration, support, and organizational use.

That is where I have generally found Red Hat-family systems most comfortable. They make sense to me as servers.

Historically I found them less convenient as multimedia desktops. The official repositories often did not contain everything I wanted, particularly software involving patent, licensing, or proprietary-code complications. Adding third-party repositories became part of setting up the machine.

That was not a limitation imposed by the Linux kernel. It followed from decisions about what the distribution was willing to package, support, and distribute.

RPM became much larger than Red Hat itself.

Other distributions adopted the package format, including SUSE. That sometimes produces the mistaken impression that distributions using RPM belong to one family.

A package format is a technology, not a genealogy.

Two distributions can use RPM while maintaining different repositories, dependency solvers, release processes, configuration tools, policies, and kernel builds. Sharing RPM tells us something about how software is packaged. It does not tell us who descended from whom.

SUSE makes that particularly obvious.

SUSE — The Slightly Eccentric Cousin

SUSE has always felt to me like Linux’s slightly eccentric cousin.

Its early history is appropriately complicated for that description. The German company that became SUSE initially distributed SLS, later provided a German version of Slackware, and released an early S.u.S.E. Linux based on Slackware. It subsequently rebuilt the distribution around Jurix, with SUSE Linux 4.2 in 1996 representing what SUSE describes as its first true distribution.

Slackware therefore belongs in SUSE’s early history, but modern SUSE should not simply be drawn as though it remains a Slackware derivative.

SUSE also adopted RPM packages, but approaching SUSE as though it were Red Hat with different branding quickly demonstrates how little a package format tells us about an operating system.

SUSE developed its own repositories, configuration conventions, release structure, administrative tools, and system-management philosophy. YaST became one of the most recognizable examples, providing a central interface for installation and system configuration.

I remember SUSE when its German origins were much more visible. One of its attractions was the sheer quantity of software available with the distribution. SUSE seemed to come with everything.

Shared technology does not necessarily mean shared ancestry.

New Families Can Begin Again

If the Linux family behaved like a conventional genealogy, every new distribution would have to descend from one of the established families.

It does not.

A developer can return to the Linux kernel, GNU software, libraries, package-building tools, desktop environments, and the enormous collection of other open-source projects and assemble them according to a new set of decisions.

Linux can therefore continue producing new root branches even after mature distributions already exist.

Gentoo — Build From Source

Gentoo developed around a particularly source-oriented answer to the distribution problem.

Most mainstream Linux distributions primarily provide software that has already been compiled into binary packages. Gentoo’s Portage system instead makes building software from source a normal part of system management.

That exposes choices that binary distributions often make on behalf of the user.

A Gentoo administrator can influence questions such as:

• which optional features are compiled into software;
• which supporting libraries are used;
• which capabilities are omitted;
• which compiler options are applied;
• and how much functionality is installed on the system.

Gentoo still makes distribution decisions. It provides Portage, ebuilds, defaults, profiles, patches, documentation, and an organized software ecosystem. It simply moves some of the boundary between distribution decision and administrator decision.

Arch Linux — Build What You Want

Arch Linux represents another independent branch.

Arch appeared in the early 2000s and drew inspiration from existing systems, but it was not created simply by taking Debian, Red Hat, Slackware, or SUSE and modifying it. It established its own package-management infrastructure, repositories, release model, installation approach, and administrative conventions.

Its base system is intentionally small. Rather than installing a large predefined environment and removing unwanted components, the administrator can begin with a relatively minimal system and add what is required.

Arch also follows a rolling-release model. Instead of periodically replacing one numbered operating-system release with another, packages are continually updated as newer versions move through the repositories.

For my own personal projects, Arch has become my favorite distribution. I enjoy the installation process precisely because it makes me decide what the machine will contain. For a desktop I can begin with a small base, add a lightweight graphical environment, and stop when the machine does what I want.

That does not mean I want every computer to work that way.

Sometimes I want to build the system. Sometimes I want to install Xubuntu because I need the computer to work and have something else to do.

Those are different requirements, and Linux can accommodate both.

Arch has since produced its own descendant ecosystem, including distributions such as Manjaro and EndeavourOS. An independent distribution becomes established, other developers decide they want to make different choices, and another branch grows from it.

Linux From Scratch

Linux From Scratch takes us underneath the distribution family tree.

It is tempting to place LFS beside Debian, Slackware, Gentoo, or Arch as another distribution. That misses its most useful role. Linux From Scratch is primarily a set of instructions for constructing a Linux system from source.

Instead of installing someone else’s integration decisions, the reader performs many of those decisions directly.

What a Distribution Normally Does for You

Building an LFS system exposes work that conventional distributions usually hide.

The process includes tasks such as:

• constructing a temporary build environment and toolchain;
• compiling fundamental libraries and utilities;
• establishing the filesystem hierarchy;
• creating system configuration;
• building and configuring the Linux kernel;
• selecting kernel functionality;
• determining what is built into the kernel or provided as modules;
• installing boot components;
• and assembling the pieces into a bootable operating system.

This makes LFS useful even for someone who never intends to maintain an LFS machine as a daily operating system.

It reveals where the distribution exists.

Debian did not simply download Linux and add a Debian logo. Red Hat is not Linux plus RPM. Arch is not Linux without a graphical installer.

A distribution is the accumulated result of decisions about how all these independently developed components become one system.

Here Are the Engineering Drawings

Most Linux distributions hand the user an operating system that has already been assembled according to the project’s decisions. Even source-oriented distributions such as Gentoo provide an established framework for making those decisions.

Linux From Scratch goes one layer deeper.

Linux From Scratch hands you the engineering drawings.

The metaphor is not exact—LFS still provides instructions and makes assumptions of its own—but it captures the important difference. The reader sees the toolchain being constructed, the libraries and utilities being installed, the filesystem taking shape, and the kernel being configured and compiled.

It also explains why the Linux family tree can always grow another root branch.

Nothing requires a future distribution to begin with Debian, Fedora, Slackware, SUSE, Gentoo, or Arch. A developer can return to the underlying projects, make a different collection of decisions, and start again.

What Makes All of This Linux?

After looking at how differently Linux systems can be assembled, the obvious question is what still makes them members of the same family.

The kernel provides the clearest common foundation, but the shared Unix model and overlapping software ecosystem are nearly as important to the experience of actually using the systems.

A Common Kernel Project

The defining technical component is the Linux kernel.

Every Linux distribution does not ship the same kernel binary. Distributions choose versions, configurations, patches, modules, security options, hardware support, and maintenance policies.

What they share is the Linux kernel project and the interfaces it provides.

That common foundation can support radically different systems while retaining a recognizable kernel architecture underneath them.

A Shared Software Ecosystem

Conventional Linux distributions also draw from a large overlapping collection of software.

GNU utilities are an important part of that ecosystem, but so are many projects that are not part of GNU. Linux distributions routinely share shells, compilers, libraries, graphical environments, web servers, databases, network utilities, programming languages, and applications.

The software may be packaged differently and configured differently, but much of it remains portable across distributions.

A program available as a Debian package can often be compiled and packaged for Fedora or Arch because changing the distribution does not require the application itself to become an entirely different program.

The Unix Operating Model

Underneath both the kernel and much of the userspace is the larger Unix operating model.

Linux inherited the concepts rather than the UNIX source.

Among the familiar characteristics are:

• hierarchical filesystems;
• files and file-like interfaces as major abstractions;
• processes with distinct execution contexts;
• users and groups;
• ownership and permissions;
• shells;
• standard input, output, and error;
• pipes connecting programs;
• devices represented through filesystem interfaces;
• sockets for communication;
• background services;
• and command-line tools designed to be combined.

Not every detail is identical across Unix-like systems, and Linux has developed many mechanisms of its own. The continuity is nevertheless strong enough that someone familiar with one Unix-like environment can usually recognize another.

That is why moving between BSD and Linux can feel simultaneously familiar and strange.

Unix-like Is Not the UNIX Trademark

UNIX is also a formal trademark associated with systems certified against the Single UNIX Specification. Meeting the certification requirements allows a system to use the UNIX name officially.

Linux distributions generally have little reason to pursue that certification. Compatibility with Unix interfaces, standards, tools, and operating concepts provides most of the practical benefit without requiring the operating system to carry the UNIX trademark.

Keep the terms separate: UNIX lineage describes ancestry. Unix-like describes design and compatibility. UNIX certification grants the right to use the formal UNIX trademark.

Three ideas should remain separate:

1. UNIX lineage — historical descent from the original UNIX source family.
2. Unix-like design and compatibility — implementing the interfaces, conventions, and operating model associated with Unix systems.
3. UNIX certification — meeting the requirements to use UNIX as a formal trademark.

BSD and Linux occupy different positions in those categories. Calling both of them simply Unix without qualification can conceal more history than it explains.

From a 386 to Nearly Everywhere

Linux began as a kernel for an Intel 386 personal computer. What allowed it to escape that original machine was the combination we have been examining throughout this article.

The kernel could be adapted to new hardware without requiring every userspace environment to come with it. Distributions could configure the kernel and assemble different collections of software for different purposes. Source availability allowed developers and manufacturers to modify the system, while the Unix operating model provided familiar interfaces and concepts on which software could be built.

Add a large development community, increasingly broad hardware support, and substantial commercial investment, and Linux could move into computing environments that looked almost nothing like Torvalds’s original PC.

Servers and the Internet

Servers became one of Linux’s most important homes.

A Linux server does not need a graphical desktop, consumer applications, or much of the software expected on a personal computer. A distribution can install only the components required to provide web services, databases, file storage, networking, authentication, or other infrastructure.

Linux’s Unix-like design made it comfortable in a role Unix systems already understood well.

Distributions such as Debian, Red Hat Enterprise Linux, Ubuntu Server, SUSE Linux Enterprise Server, and their relatives turned that foundation into systems intended for long-term administration.

Linux consequently became deeply embedded in the infrastructure behind services whose users may never realize they are running Linux.

Cloud Computing and Containers

Cloud computing extended that server role.

Virtual machines made it practical to deploy large numbers of Linux systems without dedicating a physical computer to each installation. Linux could be reduced to a relatively small server image, copied, started, stopped, replaced, and automated.

Containers pushed the idea further.

Linux kernel mechanisms allow groups of processes to be isolated and given controlled views of system resources while still sharing a kernel. Container technologies built deployment and management systems around those mechanisms.

The modern cloud took advantage of characteristics already present in Linux and Unix-like system design: processes, permissions, namespaces, filesystems, networking, and composable tools.

Supercomputers

At the opposite end of the performance scale, Linux became the standard operating-system foundation of modern supercomputing.

Supercomputers are specialized machines, and specialization is exactly where the ability to modify an operating system becomes valuable. Builders can adapt Linux to unusual processors, enormous clusters, specialized interconnects, and workloads that ordinary desktop operating systems were never designed to handle.

The desktop may be the most visible place to compare operating systems, but it is a poor measure of Linux’s overall reach.

Embedded Systems

Linux also moved downward into smaller machines.

Routers, network appliances, televisions, storage devices, industrial controllers, development boards, and other embedded systems can use Linux without resembling a conventional Linux computer from the user’s perspective.

An embedded system may have no desktop, no ordinary login prompt, and no expectation that its owner will install arbitrary software. Linux is simply the kernel underneath the function the device was built to perform.

Separating the kernel from assumptions about the surrounding environment made that possible.

Android and Mobile Computing

Android carried the Linux kernel into billions of mobile devices.

As we saw earlier, Android does not look like Debian, Fedora, or Arch because it surrounds Linux with a different userspace and application platform. That difference became an advantage rather than an obstacle.

Linux did not have to conquer the smartphone by putting a traditional Linux desktop onto a phone.

The kernel could become one component of something substantially different.

The Desktop

Desktop Linux followed a different path.

Linux has supported graphical desktops for decades and offers environments ranging from complete integrated desktops to small window managers assembled almost component by component. It is entirely practical as a daily desktop operating system, and I use it that way myself.

It has not achieved the same dominance on conventional personal-computer desktops that it achieved in servers, supercomputers, embedded systems, or mobile devices through Android.

Looking only at laptops and desktop PCs makes Linux appear like a minority operating system. Looking at computing infrastructure as a whole produces a very different picture.

Linux often succeeded most completely where the person benefiting from it never sees the operating system at all.

Summary

BSD and Linux reached the modern Unix world through different histories. BSD carries a line of source and historical descent back through Berkeley UNIX. Linux was independently developed, implementing the Unix operating model without inheriting the original UNIX source.

Linux itself began as a kernel. GNU supplied many of the components needed around it, while other projects supplied still more. Distributions turned those components into complete operating systems by making decisions about the kernel, userspace, packages, repositories, hardware, release models, maintenance, and system administration. Slackware, Debian, Red Hat, and SUSE became major early examples of how differently those decisions could be made.

The family tree does not grow only through descent. Gentoo and Arch demonstrate that developers can return to Linux and the wider software ecosystem and create new distribution families. Linux From Scratch exposes the process directly, showing how many decisions normally disappear beneath an installer and package manager. The common Linux kernel project connects these systems, while the larger Unix model makes them recognizable as relatives despite their differences.

Linux did not replace UNIX by becoming another branch of the original UNIX source tree. It demonstrated another way for Unix to survive. Its interfaces and operating concepts could be implemented independently, combined with freely available software, packaged according to many different philosophies, and adapted to almost any kind of computer. What began on a 386 eventually became the foundation for systems ranging from small embedded devices to phones, servers, cloud infrastructure, and the world’s largest supercomputers.

BSD is one of the clearest examples of the original UNIX lineage continuing forward. The Berkeley Software Distribution grew directly from licensed UNIX source code and gradually became independent from it. That ancestry continues through operating systems still developed today, making BSD a living branch of the UNIX family rather than an independent reimplementation of the Unix model.

The BSD family did not remain a single operating system. FreeBSD, NetBSD, OpenBSD, DragonFly BSD, and other descendants separated at different points for different reasons. Each developed its own technical priorities while retaining a common ancestry. BSD code and technologies also spread into firewalls, network appliances, storage systems, and operating systems that do not necessarily carry BSD in their names.

Following BSD means looking at more than a family tree. We need to understand why its major branches separated, where they went afterward, and how technology moved both out of and into the family. That helps explain how BSD could become less visible than some other operating-system families while remaining deeply embedded in modern computing.

From Berkeley UNIX to an Independent BSD

BSD did not begin as an independent operating system. The earliest Berkeley Software Distributions were collections of programs and modifications created at the University of California, Berkeley for systems already running licensed UNIX. As Berkeley’s work expanded, BSD became a recognizable branch of UNIX, but it still contained AT&T source code. Anyone receiving a complete BSD system therefore needed the appropriate UNIX source license.

BSD has direct UNIX ancestry because it really did begin with UNIX source. The later BSD systems did not recreate Unix behavior independently from published interfaces or standards. Their lineage runs backward through Berkeley to the original UNIX family.

What changed was how much of the operating system belonged to Berkeley. The Computer Systems Research Group continued replacing, extending, and developing parts of the system until BSD contained a substantial body of code Berkeley could distribute under its own terms. Eventually, enough of the proprietary UNIX source would be replaced for the BSD lineage to continue without it.

Berkeley Builds on UNIX

Berkeley’s contributions became substantial long before BSD could be distributed independently. BSD introduced or advanced technologies including virtual memory, job control, the Fast File System, and networking capabilities that would influence systems far outside Berkeley.

Networking is especially important to where we are in the Foundations of Computation series. Berkeley received funding from DARPA to integrate TCP/IP networking into BSD, and 4.2BSD included a TCP/IP stack and the sockets programming interface. BSD became an important platform for the protocols connecting previously independent computers into networks.

The sockets interface gave programs a practical way to use those networks. An application did not need to manipulate network hardware directly. It could create a socket, establish or accept a connection, and send or receive data through an interface provided by the operating system. Sockets spread well beyond BSD and became one of Berkeley’s most enduring contributions to networked computing.

BSD was developing an identity of its own while remaining part of the UNIX source family. Berkeley was not simply packaging AT&T’s work. It was changing the operating system, adding capabilities, and producing code that other Unix vendors and researchers wanted.

The remaining AT&T code still mattered. Berkeley could distribute the portions it had written, but it could not simply release AT&T’s proprietary source along with them. For BSD to become independently distributable, those dependencies had to go.

Removing the AT&T Source

Berkeley removed those dependencies incrementally. The Computer Systems Research Group replaced code still restricted by the UNIX license while separating Berkeley-developed components that could be released more freely.

Networking Release 1, commonly called Net/1, was an important step. Instead of distributing a complete BSD operating system containing restricted UNIX source, Berkeley released networking code it could distribute under its own license. This also helped establish the permissive licensing approach that would become closely associated with BSD.

Work continued on the remaining proprietary components. In 1991, Berkeley released Networking Release 2, or Net/2. Despite the name, Net/2 contained substantially more than a networking stack. Most of the components needed for a complete BSD system were now available without the traditional AT&T UNIX source license.

Net/2 was not quite complete. Important portions of the kernel still needed replacement before it could function as a standalone operating system. Developers outside Berkeley would soon supply that work, moving BSD development beyond the institution where it began.

There was also an unresolved legal problem. Berkeley believed it had removed the restricted UNIX code necessary to make Net/2 redistributable. UNIX System Laboratories disagreed.

The BSD Lawsuit and 4.4BSD-Lite

The disagreement became a lawsuit after Berkeley Software Design, Inc., commonly known as BSDi, began selling its own Intel-based operating system derived from Berkeley’s work. UNIX System Laboratories sued BSDi in 1992, and the dispute subsequently involved the University of California as well.

The legal fight reached farther than the two companies. If Net/2 still contained protected UNIX code, every project attempting to build a freely distributable operating system from it faced uncertainty over its foundation.

The dispute was eventually settled after Novell acquired UNIX System Laboratories. A small number of files from Net/2 were identified for removal or modification, and Berkeley produced 4.4BSD-Lite as the release projects could use going forward without the same UNIX source encumbrances.

4.4BSD-Lite gave the growing BSD family a cleaner source foundation. BSD development could continue without depending on the old AT&T licensing relationship.

Removing the proprietary portions did not erase BSD’s history. The lineage remained continuous.

The lineage remained continuous even as Berkeley and later BSD developers replaced the pieces that could not be freely carried forward.

BSD Moves to Commodity Hardware

While Berkeley was separating BSD from its remaining proprietary dependencies, the hardware underneath Unix systems was changing. The Intel 80386 provided a 32-bit processor with memory protection and other capabilities suitable for a Unix-like operating system, but it belonged to the rapidly expanding world of IBM PC-compatible hardware rather than the traditional workstation and minicomputer markets.

William and Lynne Jolitz used the Net/2 source as the foundation for 386BSD, filling in missing portions and porting the system to the Intel 386. The first public release appeared in 1992.

BSD could now move beyond university systems, proprietary workstations, and expensive Unix hardware. It could run on the same increasingly ordinary PC architecture that had already transformed personal computing.

386BSD attracted a community that wanted to improve and maintain the system. Patches accumulated, hardware support needed to expand, and users wanted development to move faster. Difficulties incorporating that work back into 386BSD eventually encouraged developers to organize projects of their own.

A commercial path was developing at roughly the same time. BSDi produced BSD/386, later renamed BSD/OS, as a commercial BSD operating system for Intel hardware. BSD’s move onto commodity computers produced both commercial and freely available descendants.

By 1993, developers from the 386BSD community had begun creating NetBSD and FreeBSD. Berkeley supplied the UNIX-derived foundation, the effort to remove proprietary dependencies made independent distribution possible, and 386BSD demonstrated that the system could live on commodity hardware.

BSD’s future no longer depended on Berkeley maintaining a single operating system. It was becoming a family.

The BSD Family Splits

NetBSD and FreeBSD marked the beginning of the modern BSD family, but the branching did not stop there. Each project developed its own priorities, community, and technical direction. Later disagreements and new goals produced additional descendants, while commercial and specialized branches developed alongside the better-known free BSDs.

The major branches look like this:

Berkeley BSD
│
├── Net/2
│   │
│   ├── 386BSD
│   │   │
│   │   ├── NetBSD
│   │   │   │
│   │   │   └── OpenBSD
│   │   │
│   │   └── FreeBSD
│   │       │
│   │       └── DragonFly BSD
│   │
│   └── BSD/386
│       │
│       └── BSD/OS
│
└── continued Berkeley development
    │
    └── 4.4BSD
        │
        └── 4.4BSD-Lite
            │
            └── source incorporated into the
                continuing BSD projects

This is a simplified ancestry tree, not a complete map of source-code inheritance. Code continued to move between projects, and the modern BSDs incorporated later Berkeley code, particularly 4.4BSD-Lite. For ancestry, the important relationships are clear: NetBSD and FreeBSD emerged from the 386BSD environment, OpenBSD later separated from NetBSD, and DragonFly BSD later separated from FreeBSD.

NetBSD: Portability Across Architectures

NetBSD began in 1993 when Chris Demetriou, Theo de Raadt, Adam Glass, and Charles Hannum organized a new project around the freely available BSD work. Problems surrounding 386BSD development helped motivate the project. Patches were circulating outside the main source tree, developers had difficulty getting changes incorporated, and maintaining a coherent system was becoming increasingly difficult.

The new project also had a broader goal than maintaining BSD specifically for the Intel PC. NetBSD emphasized clean design and portability across hardware architectures. The operating system should not depend unnecessarily on assumptions specific to one processor, bus, or machine.

Portability became NetBSD’s defining characteristic. Over time, it was ported to an unusually broad collection of computers, including x86, ARM, SPARC, VAX, Motorola 68k, MIPS, PowerPC, and many others. The project’s long-standing slogan, “Of course it runs NetBSD,” grew from that emphasis.

Portability has value beyond keeping unusual or obsolete hardware alive. Moving the same operating system across substantially different machines exposes assumptions hidden in the code. Differences in byte ordering, memory layout, processor behavior, device access, and platform architecture force the boundaries between machine-dependent and machine-independent code to remain clearly defined.

NetBSD’s answer to what BSD should become after 386BSD was a portable operating system designed to follow the hardware rather than remain tied to one platform.

FreeBSD: BSD on the Growing PC Platform

FreeBSD also emerged from the 386BSD community in 1993, but with a different early emphasis. Instead of making support for many architectures its defining objective, FreeBSD initially concentrated on producing a practical BSD system for the Intel 386 PC platform.

That was not a small target. IBM-compatible hardware was becoming increasingly capable, inexpensive, and standardized. The same commodity-hardware transition that transformed personal computing was making PCs suitable for jobs that previously required workstations and specialized Unix systems.

FreeBSD concentrated heavily on making BSD useful on that hardware: installation, hardware support, networking, performance, and system administration. When the USL settlement made the Net/2 foundation problematic, the project moved to 4.4BSD-Lite and released FreeBSD 2.0 from the new foundation.

As commodity x86 hardware became more capable, FreeBSD grew with it. The system found substantial use in Internet servers, network infrastructure, storage, and later appliances. Its BSD networking heritage, integrated base system, Ports Collection, and permissive licensing made it useful both as an operating system and as a foundation for building other systems.

That second role became important. Many people who have never deliberately installed FreeBSD have still used systems built on it.

OpenBSD: Security, Correctness, and a New Branch

The next major branch came from NetBSD. Theo de Raadt had been one of NetBSD’s founders, but disagreements within the project eventually led to his removal from the NetBSD core team. In 1995, he began OpenBSD from the NetBSD source tree; its first official release followed in 1996.

The split explains where OpenBSD came from. What happened afterward defines the project. OpenBSD developed a strong emphasis on code correctness, auditing, security, documentation, and a coherent base system with carefully chosen defaults.

Security is treated as a property of the complete system rather than something added afterward. OpenBSD developers have repeatedly audited existing code, removed unsafe practices, introduced exploit mitigations, and replaced components when they believed they could build something better.

Some of that work spread far beyond OpenBSD. OpenSSH, developed by the OpenBSD project from the earlier SSH codebase, became one of the most widely deployed implementations of the Secure Shell protocol. The PF packet filter likewise became important within OpenBSD and other BSD-derived systems.

OpenBSD’s reach is larger than the number of computers running OpenBSD itself.

Software created because the project pursued its own goals became useful throughout the wider computing ecosystem.

DragonFly BSD: A Different Approach to Multiprocessing

The BSD family branched again in 2003, this time from FreeBSD. Matthew Dillon created DragonFly BSD from FreeBSD 4.8 after disagreeing with the direction FreeBSD was taking as it redesigned portions of the operating system for symmetric multiprocessing.

Multiprocessor hardware was becoming increasingly important, and operating systems had to determine how kernel work should be divided and synchronized across processors. FreeBSD was pursuing its approach during the transition toward the FreeBSD 5 series. Dillon believed a different architecture would provide a better long-term foundation.

DragonFly BSD provided a place to pursue that alternative without requiring FreeBSD to accommodate two competing kernel designs. The project developed its own approaches to concurrency, messaging, clustering, and other parts of operating-system architecture.

It also developed its own storage technology. HAMMER, followed by HAMMER2, provided DragonFly with a filesystem designed around features including snapshots, historical data retention, checksumming, and large storage systems. DragonFly remained much smaller than FreeBSD, but its continued development showed that BSD branching did not end in the 1990s.

Forks do not always happen because a project failed. Sometimes separate systems are the practical way to explore competing architectural ideas.

BSD/OS: The Commercial BSD Branch

Not every important BSD descendant followed the free community-project model. Berkeley Software Design developed BSD/386 as a commercial Unix operating system for Intel hardware. The product was later renamed BSD/OS.

BSD/OS shared the Berkeley lineage but occupied a different part of the market from the emerging free BSD projects. It provided a commercially supported BSD system at a time when Unix vendors commonly sold the operating system, support, and related products as commercial offerings.

The company and operating system changed ownership as the Unix market consolidated, and BSD/OS was eventually discontinued. Its technology and developers still crossed back into the wider BSD ecosystem. Wind River, which had acquired BSDi, later transferred BSD/OS technology to the FreeBSD Foundation, while people associated with the commercial BSD world contributed knowledge and code elsewhere.

BSD ancestry and open-source community development are not the same thing. The lineage produced both commercial and freely developed operating systems, just as the larger UNIX family had done before it.

The Family Continues to Branch

FreeBSD, NetBSD, OpenBSD, and DragonFly BSD form the major independently developed open BSD operating systems surviving from these branches, but they do not account for every system carrying BSD ancestry. Other projects have taken one of these operating systems and adapted it for security, desktops, storage, firewalls, embedded systems, and other specialized purposes.

These later descendants are somewhat different from the major forks. OpenBSD and DragonFly BSD separated to pursue independent operating-system development. Other projects begin with an existing BSD because it already provides a useful foundation for a more specialized goal.

The BSD family can therefore grow in two ways: independent branches can emerge over the direction of the operating system itself, while derived systems can build something more specialized on an existing BSD.

There is another difference we need before following those derivatives. FreeBSD, NetBSD, OpenBSD, and DragonFly BSD are not BSD equivalents of Linux distributions. Each develops an operating system as an integrated whole.

BSD as a Complete Operating System

The modern BSD projects share ancestry, exchange code, and provide many of the same familiar Unix tools, but each develops a complete operating system. FreeBSD, NetBSD, OpenBSD, and DragonFly BSD are not different collections of software placed around a common BSD kernel. Each project maintains its own kernel together with the core userspace that makes up its base system.

This differs from the model familiar to Linux users. A Linux distribution combines the Linux kernel with software from many independently maintained projects to create a complete operating environment. GNU utilities and libraries have historically supplied many of those components, while other projects provide init systems, networking tools, package managers, graphical environments, and applications. Different distributions can combine those pieces in substantially different ways while sharing the Linux kernel lineage.

BSD development starts with the operating system as an integrated project. The kernel, commands, system libraries, startup infrastructure, administrative tools, manual pages, and other components of the base operating system can be developed together instead of being assembled afterward from unrelated upstream projects.

BSD Tip: FreeBSD, NetBSD, OpenBSD, and DragonFly BSD share ancestry, not a common modern kernel. They are separate operating systems, not BSD versions of Linux distributions.

The Base System

The base system is the portion of a BSD maintained as part of the operating system itself. Its exact contents and implementation differ between projects, but the concept provides a useful boundary between the operating system and additional software installed on top of it.

In FreeBSD, for example, the base system includes the kernel and the fundamental userspace needed to operate and administer the machine. Its source is maintained together, and the project produces coordinated operating-system releases from it. NetBSD, OpenBSD, and DragonFly BSD follow the same broad integrated-system approach while maintaining their own implementations and release processes.

A change to a BSD does not have to stop at the kernel boundary. A project can modify the kernel, a system utility, a library, its documentation, and the interfaces connecting them as parts of the same operating system. This helps explain why the individual BSDs developed such distinct identities after their forks. Their differences are not limited to kernel patches or which software gets installed. Each project can make decisions across the complete base system.

The manual pages are a good example. Documentation for the base system can evolve with the code it documents and ship as part of the same project. The documentation installed on the machine is intended to describe that particular operating system rather than a generic collection of Unix-like tools.

Packages and Ports Build on the Base

An integrated base system does not mean BSD projects try to develop every program their users might need. Web servers, databases, programming languages, desktop environments, editors, and thousands of other applications remain separate software projects.

BSD systems provide ways to install this additional software without making it part of the base operating system. FreeBSD, for example, provides binary packages and the Ports Collection, which contains the information needed to build and install third-party software from source. The other BSDs provide their own package and ports systems.

The basic division is:

• Base system — the kernel and core operating-system components maintained by the BSD project.
• Packages and ports — additional software installed on top of that operating system.

BSD Tip: When reading BSD documentation, keep the base system and installed packages separate in your head. The operating system is more than its kernel, but it also does not include every application installed on the machine.

The base system can still contain software that originated elsewhere. BSD projects can import external projects into their source trees and integrate or maintain them as part of the operating system. What matters is responsibility: once something becomes part of the base system, its integration and release are managed within the operating-system project.

Different BSDs Are Different Operating Systems

FreeBSD, NetBSD, OpenBSD, and DragonFly BSD should not be described as BSD distributions. There is no single modern “BSD kernel” underneath all four systems. Their kernels and base systems have diverged, and each project makes its own decisions about interfaces, security, hardware support, networking, filesystems, utilities, and release engineering.

Their common ancestry remains real. Code still moves between them, and similarities inherited from Berkeley remain obvious. But installing OpenBSD instead of FreeBSD means choosing a different operating system, not another packaging of the same underlying BSD.

When BSD becomes a foundation for something else, the distinction changes. A project can begin with FreeBSD and build a firewall, storage appliance, desktop system, or other specialized environment around it. Then there really is an underlying BSD with another system built from it.

This is one reason BSD’s influence is much larger than the number of computers whose users say they are running BSD. Much of the modern BSD family is hiding underneath something else.

BSD Underneath Other Systems

The BSD family becomes harder to see once we move beyond operating systems carrying BSD in their names. FreeBSD, NetBSD, OpenBSD, and DragonFly BSD are identifiable operating systems, but BSD’s permissive licensing and integrated design also make the family useful as a foundation for other projects. A developer can begin with a complete BSD system, change it for a particular purpose, and distribute the result under another identity.

These descendants are not all additional branches equivalent to OpenBSD or DragonFly BSD. Some remain closely tied to their parent BSD and make it easier to use for a particular purpose. Others substantially change the system around a specialized workload. Apple’s Darwin combines BSD technology with components from entirely different operating-system traditions.

A person can use BSD code every day without ever deliberately choosing to install a BSD operating system.

Firewalls and Network Appliances

Networking is a natural place for BSD to appear beneath another system. The family already carried Berkeley’s long networking history, while a complete BSD operating system provided the routing, packet filtering, interfaces, storage, user management, and other facilities needed to turn ordinary hardware into a network appliance.

m0n0wall was an important example. Beginning in the early 2000s, it used FreeBSD as the foundation for a small firewall system managed primarily through a web interface. The administrator did not need to treat the machine as a general-purpose FreeBSD server. FreeBSD supplied the operating system while m0n0wall turned it into an appliance built for a specific job.

That model produced descendants of its own. pfSense began as a fork of m0n0wall in 2004 and continued using FreeBSD as its operating-system foundation. It expanded the appliance model into a broader firewall and routing platform while retaining FreeBSD’s networking capabilities.

OPNsense forked from pfSense in 2014 rather than starting again from scratch. It continued along the inherited FreeBSD-derived path, later incorporated work from HardenedBSD, and eventually moved its base more directly back toward FreeBSD.

This portion of the family has a genealogy of its own:

FreeBSD
│
└── m0n0wall
    │
    └── pfSense
        │
        └── OPNsense

The tree shows project ancestry rather than every source-code relationship between them. Several generations of firewall projects could concentrate on firewall and routing functionality because BSD already supplied the operating system underneath.

Someone installs OPNsense because they want a firewall, not because they decided to deploy a general-purpose BSD server. BSD remains underneath doing the work.

Security-Focused and Desktop Derivatives

FreeBSD has also provided a foundation for projects that retain more of a general-purpose operating system while changing its emphasis.

HardenedBSD began as a FreeBSD-derived project focused on additional security and exploit-mitigation technologies. Instead of creating a new kernel and userspace independently, the project could begin with FreeBSD and concentrate on its security-oriented changes.

GhostBSD takes the idea in another direction. It builds a desktop-oriented operating system from the FreeBSD family, providing a graphical environment and installation experience intended to make BSD more approachable on the desktop.

These differ from the major BSD branches discussed earlier. NetBSD and FreeBSD emerged as independent operating-system projects. OpenBSD and DragonFly BSD forked to pursue their own continuing development of the operating system itself. HardenedBSD and GhostBSD show how an existing BSD can instead become the platform for a more specialized system.

The boundary is not absolute. A derivative can develop substantial technology of its own, and its relationship with its parent can change over time. The distinction still helps explain why the BSD family contains both a handful of major independently developed operating systems and a much larger collection of systems built from them.

BSD as a Storage Foundation

Storage is another area where FreeBSD became useful underneath a specialized system. FreeNAS used FreeBSD to create a network-attached storage platform that could be administered as an appliance instead of a manually assembled general-purpose server.

FreeNAS eventually became part of the TrueNAS product family. TrueNAS later developed both FreeBSD-based CORE and Linux-based SCALE, with new feature development eventually shifting toward the Linux-based branch. FreeBSD nevertheless played an important role in TrueNAS history as a storage platform.

One technology became particularly important to that relationship: ZFS. Unlike the Berkeley networking stack and other technologies that originated within the BSD lineage, ZFS came from another branch of the UNIX family. Sun developed it for Solaris, yet it eventually became strongly associated with FreeBSD storage systems.

This time the technology was moving into BSD rather than out of it.

Darwin and macOS

Apple provides a different example because Darwin is not simply another FreeBSD derivative. Its ancestry combines technologies from several operating-system traditions.

Part of the path runs through NeXT. NeXTSTEP combined the Mach kernel work developed at Carnegie Mellon with BSD-derived Unix facilities and NeXT’s own software. When Apple acquired NeXT in 1997, that technology became the foundation for the operating-system architecture that ultimately became Mac OS X.

At the center of Darwin is XNU, whose name originally reflected the idea that “X is Not Unix.” XNU combines Mach with BSD-derived components and Apple’s own development. Its BSD portion provides important Unix facilities including process and user models, networking, sockets, permissions, and familiar Unix interfaces.

FreeBSD also became an important source for BSD userspace and kernel components incorporated into Darwin. Apple could use BSD code without turning Darwin into FreeBSD or making macOS a BSD distribution. BSD’s permissive licensing allowed the technology to become part of a larger proprietary product while open portions continued to exist in Darwin.

BSD Tip: macOS is built partly from BSD technology, but it is not FreeBSD with an Apple interface. Mach, XNU, NeXT technology, BSD components, and Apple’s continuing development all contribute to the system.

The Darwin/XNU foundation later spread across Apple’s other operating systems. BSD-derived technology consequently reached an enormous number of computers and mobile devices whose users would never describe them as BSD machines.

Influence Without the BSD Name

Installation counts provide an incomplete picture of BSD. The family can appear in several forms:

• a directly installed BSD such as FreeBSD, NetBSD, OpenBSD, or DragonFly BSD;
• a specialized system built from a BSD, such as a firewall or desktop derivative;
• an appliance whose BSD foundation is largely hidden behind its purpose;
• or BSD code and interfaces incorporated into a larger system with a different architecture and identity.

Permissive licensing helped that movement happen. BSD code could be adopted, modified, and incorporated into open or proprietary systems without requiring those systems to become BSD projects themselves. The same characteristic that helped BSD technology spread could also make its influence less visible.

BSD did not need every system using its technology to carry the BSD name.

ZFS shows technology moving in the other direction. BSD could absorb an important technology from another UNIX branch and provide it with another place to develop and survive.

ZFS Moves into BSD

Not every important technology associated with modern BSD originated at Berkeley or within one of the BSD projects. ZFS came from a different branch of the UNIX family entirely. Sun Microsystems developed it for Solaris as a new approach to managing storage, then released its source through OpenSolaris.

ZFS eventually became deeply integrated with FreeBSD and particularly important to BSD-based storage systems. Sun had created an unusually capable storage technology that could help distinguish Solaris and OpenSolaris from competing operating systems. Once the code was available, however, the technology proved more portable than the platform that created it.

ZFS left the boundaries of Solaris, found new homes, and continued developing after OpenSolaris itself disappeared. FreeBSD became one of those homes.

Rethinking the Filesystem and the Disk

Traditional storage systems commonly separate several responsibilities. Physical disks may be combined or divided by RAID and volume-management layers, while a filesystem is created on the resulting block device. Each layer performs its own job, but the filesystem does not necessarily know what is happening beneath it.

ZFS was designed differently. It combines the filesystem with storage-pool management, giving ZFS knowledge of both the logical organization of files and the storage holding them. Disks and other devices become part of a storage pool, and filesystems draw capacity from that pool instead of being permanently tied to individually sized disk partitions.

That integration lets ZFS treat storage integrity as a system-wide problem. ZFS uses copy-on-write instead of overwriting live filesystem blocks in place. New data is written elsewhere, and the filesystem’s metadata is updated to reference it only after the write is complete.

ZFS also checksums data. When data is read, its checksum can be compared with the value recorded when it was written. If redundant copies are available through a mirror, RAID-Z, or another supported form of redundancy, ZFS can use a correct copy to repair corrupted data instead of merely reporting the corruption.

The integrated design also provides features particularly useful for servers and storage appliances:

• storage pools combine available storage instead of requiring administrators to preallocate fixed filesystem partitions;
• copy-on-write preserves previous blocks until replacement data has been safely written;
• checksums allow ZFS to detect corruption instead of assuming a successful disk read returned the correct data;
• scrubs systematically read stored data and verify its integrity;
• mirrors and RAID-Z provide redundancy ZFS can use when repairing damaged data;
• snapshots and clones preserve filesystem states efficiently through copy-on-write;
• compression can be managed directly by the filesystem;
• replication allows snapshots to be transferred between ZFS systems.

No single feature makes ZFS important. The strength comes from these capabilities working with knowledge of the same storage system instead of being assembled entirely from independent layers.

From Solaris to FreeBSD

Sun introduced ZFS through Solaris and later made its source available as part of OpenSolaris. FreeBSD developers began porting ZFS to their operating system, and FreeBSD 7.0 shipped with ZFS support in 2008.

FreeBSD was already used for servers and network infrastructure, and its integrated operating-system model gave ZFS room to become more than an unusual third-party filesystem. Over time, FreeBSD gained the ability to use ZFS throughout the system, including for boot and root filesystems.

Storage appliances made the relationship especially visible. FreeNAS originally used UFS but moved to the FreeBSD ZFS port in 2010. Its later development as TrueNAS continued making ZFS central to the storage platform.

Berkeley networking technology had moved outward from BSD and into other systems. ZFS moved inward from Solaris and became an important part of the BSD ecosystem.

ZFS Outlives OpenSolaris

ZFS initially gave Solaris and OpenSolaris a substantial storage technology of their own. Sun controlled the operating system where ZFS originated, and Solaris could integrate the filesystem as a native part of its storage architecture.

Once ZFS was released as open-source software, other operating-system communities could bring that technology to their own platforms.

FreeBSD did exactly that.

ZFS did not cause the decline of OpenSolaris. Solaris and OpenSolaris existed in a much larger environment involving hardware support, applications, administration, commercial support, Sun’s business decisions, Linux’s rapid expansion, and eventually Oracle’s acquisition of Sun. Reducing that history to a filesystem would miss most of it.

What happened to ZFS is more specific. A valuable operating-system technology does not necessarily preserve the position of the operating system that created it. If the technology can move, some of its advantage can move with it.

When Oracle discontinued OpenSolaris in 2010, the open ZFS code did not disappear. The illumos project continued development from the OpenSolaris codebase, while ZFS development increasingly occurred across several operating systems. OpenZFS eventually became the common upstream project for continued open development.

FreeBSD later moved from maintaining its older illumos-derived ZFS implementation to the common OpenZFS codebase. TrueNAS made a corresponding transition with OpenZFS 2.0, bringing FreeBSD and Linux ZFS development around a shared upstream implementation.

ZFS had outgrown the operating system that created it.

Licensing Changes the Linux Story

There is a limit to how freely ZFS could move. Sun released ZFS under the Common Development and Distribution License, or CDDL. The Linux kernel is distributed under version 2 of the GNU General Public License, and code incorporated into the kernel source needs licensing compatible with GPLv2.

The CDDL and GPLv2 are generally considered incompatible for distributing ZFS as part of the Linux kernel itself. That does not mean ZFS cannot run on Linux. OpenZFS supports Linux, and Linux systems can use ZFS through separately distributed kernel modules. The licensing issue affects how ZFS can be combined and distributed with the kernel, not whether Linux can use it.

ZFS Tip: The CDDL/GPL issue is about combining and distributing ZFS with the Linux kernel. It does not mean Linux cannot use ZFS.

FreeBSD does not have the same conflict. Its permissive licensing model allowed CDDL-licensed ZFS to be incorporated into the operating system while ZFS retained the requirements of its own license. FreeBSD could integrate ZFS deeply without requiring it to be relicensed.

This puts the software-licensing differences discussed earlier in the series into practice. Licenses do more than determine whether source code can be read. They establish the conditions under which independently developed software can be combined, modified, and redistributed.

There is an interesting tension here. Open-source licensing helped ZFS escape Solaris and survive the end of OpenSolaris as a Sun project. The particular license Sun chose also created a boundary that kept ZFS from being incorporated into the Linux kernel as straightforwardly as it could be incorporated into FreeBSD.

ZFS connects several parts of the BSD story: FreeBSD as a storage platform, technology crossing between UNIX branches, BSD as the foundation for specialized appliances, and licensing having practical technical consequences.

The technology that survives is not always attached to the platform that invented it.

Summary

BSD began as additions to licensed UNIX, but Berkeley’s developers gradually replaced the proprietary dependencies while adding important technologies of their own. Networking, sockets, the Fast File System, and other Berkeley work gave BSD an identity beyond the UNIX source where it began. Net/2, 386BSD, and ultimately 4.4BSD-Lite provided foundations from which BSD could continue after Berkeley stopped developing the operating system.

That continuation did not produce a single successor. NetBSD emphasized portability across architectures. FreeBSD initially concentrated on the growing PC platform and became important in servers, networking, storage, and appliances. OpenBSD branched from NetBSD and developed its emphasis on security and correctness, while DragonFly BSD later branched from FreeBSD to pursue a different approach to multiprocessing and operating-system architecture. BSD/OS shows that commercial development existed alongside the freely developed BSDs.

BSD’s influence extends much farther than those operating systems. FreeBSD became a foundation for firewalls, storage appliances, desktop systems, and other specialized projects, while BSD technology became part of Darwin and Apple’s larger operating-system family. Permissive licensing allowed BSD code to move into systems that did not need to retain the BSD name or the development model of the project where the code originated.

Technology moved in the other direction as well. ZFS began in Solaris, migrated into FreeBSD, and continued through OpenZFS after OpenSolaris disappeared. Its history shows both how useful technology can cross operating-system families and how licensing affects where that technology can be integrated. BSD survives as a direct branch of the original UNIX lineage, but its reach extends far beyond the systems carrying the BSD name.

That fragmentation also complicated what it meant for an operating system to be UNIX. Some systems could trace their development directly back to Bell Labs UNIX. Others could implement interfaces defined by standards such as POSIX without sharing that ancestry. UNIX would also become a certification and trademark applied to systems meeting a defined specification. Source lineage, compatibility, and the UNIX name were becoming separate questions.

There was another possibility. If the important interfaces and behavior of UNIX could be described, developers could reproduce them without using UNIX source code at all. Such systems could be Unix-like: built around many of the same concepts and interfaces without becoming another branch of the original UNIX source tree. That distinction became increasingly important as UNIX ideas spread beyond systems descended directly from Bell Labs.

Commercial UNIX systems continued the original source lineage. Standards increasingly defined what software could expect from a Unix environment, and independent projects could pursue Unix compatibility without UNIX ancestry at all. Following these paths separately helps explain how UNIX became both a family of operating systems and a model that extended far beyond its original source code.

UNIX by Code

The oldest meaning of UNIX is also the most straightforward: an operating system belongs to the UNIX family because its development can be traced back to the operating system created at Bell Labs. This is UNIX as a source-code lineage. Later systems may differ substantially from early UNIX, but there is still a historical path connecting their development.

That lineage began branching early. UNIX source moved to universities, computer manufacturers, and other organizations, where it was adapted to different hardware and different needs. Changes accumulated, features moved between branches, and vendors eventually developed distinct commercial products. UNIX became less like a single operating system with successive versions and more like a family whose members shared an ancestor.

Source ancestry does not mean that a later system must still contain some particular percentage of the original Bell Labs code. Operating systems are continually maintained and rewritten. Drivers disappear with obsolete hardware, subsystems are replaced, interfaces are redesigned, and old implementations give way to new ones. After decades of development, asking how much original code remains can tell us less about the relationship than asking how the system developed.

A family tree tells us where a system came from; it does not mean that everything in that system came exclusively from one branch.

The branches did not remain isolated either. Commercial UNIX systems could incorporate ideas and technology associated with both AT&T UNIX and BSD. Later standards encouraged common interfaces across systems with increasingly different internals. A family tree tells us where a system came from; it does not mean that everything in that system came exclusively from one branch.

System V and Commercial UNIX

One of the most important lines ran through AT&T’s System V. As AT&T moved UNIX further into the commercial market, System V became a major branch of UNIX development and an important foundation for commercial UNIX systems during the 1980s and 1990s.

Computer manufacturers of this period commonly developed operating systems around their own hardware. UNIX gave vendors an established operating model and software environment while leaving room to optimize the system for particular machines and customers. The result was not one commercial UNIX, but an ecosystem of related products.

Some of the most important commercial UNIX systems included:

• AIX
• SunOS and Solaris
• HP-UX
• IRIX
• Tru64 UNIX
• SCO UNIX and OpenServer

These systems shared UNIX ancestry, but they were not interchangeable releases of the same operating system. Vendors differentiated them through administration tools, filesystems, networking, graphical environments, hardware support, and features aimed at their particular markets. UNIX on a graphics workstation could look quite different from UNIX running business applications on a large enterprise server.

The commercial UNIX market eventually contracted, but its branches did not all meet the same fate. Some continued as specialized enterprise systems. Others passed through acquisitions into new companies or disappeared along with the hardware platforms and companies that had supported them.

AIX

IBM’s AIX became closely associated with IBM’s workstation and enterprise hardware. Rather than disappearing as UNIX declined on general-purpose computers, AIX remained in the enterprise market and eventually became centered on IBM’s POWER systems.

UNIX did not need to dominate the broader operating-system market for AIX to remain useful. Customers with established systems could value stability, compatibility, vendor support, and the ability to continue running existing workloads already built around the platform.

SunOS and Solaris

Sun Microsystems followed a different path. Its early SunOS releases were strongly connected to BSD. Solaris represented Sun’s move toward System V and eventually combined technology and ideas from both sides of the UNIX family.

Solaris became one of the most visible commercial UNIX systems of the workstation and server era. Sun paired the operating system closely with its SPARC hardware while also supporting other architectures, including x86.

Sun was eventually acquired by Oracle, bringing Solaris with it. The Solaris story also continued outside its commercial owner. Open-source work surrounding OpenSolaris contributed to illumos, from which several operating systems continue the Solaris-derived tradition.

Other Commercial UNIX Systems

Not every important commercial UNIX needs its own complete history here. HP-UX, IRIX, and Tru64 UNIX show how closely commercial UNIX could become tied to a manufacturer’s hardware and business.

These included:

• HP-UX
• IRIX
• Tru64 UNIX

Their histories differ, but they shared a problem as the market changed. Proprietary workstation architectures declined and the computer industry consolidated, making separate UNIX implementations harder to justify. Some systems retained specialized customers for years. Others eventually reached the end of active development.

SCO and UNIX on Intel

The Santa Cruz Operation occupied another interesting part of the commercial UNIX market. SCO concentrated heavily on bringing UNIX to comparatively inexpensive Intel-based systems. Businesses could run multiuser UNIX applications without purchasing one of the proprietary workstation or server platforms associated with many other UNIX vendors.

SCO’s UNIX business eventually passed to Caldera, a company already known for selling Linux. Caldera had also experimented with making Linux installation friendlier: one of its graphical installers let you play Tetris while waiting for the installation to finish.

Sometimes computing history includes waiting for Linux to install while playing Tetris.

Caldera later renamed itself The SCO Group. For the UNIX lineage we are following here, that is where we can leave the branch.

UNIX by Standards

Source lineage tells us where an operating system came from. It does not necessarily tell us how software written for that system will behave. As UNIX divided into competing implementations, differences between those systems created a practical problem. Software developers needed a common set of interfaces they could rely upon even when the underlying operating systems came from different branches.

Standards addressed that problem without requiring common source code. They could define the interfaces and behavior an operating system was expected to provide. Different operating systems could then implement those interfaces in their own ways.

UNIX ancestry and UNIX compatibility are not the same thing.

UNIX ancestry and UNIX compatibility are not the same thing. A system descended from Bell Labs UNIX could have genuine UNIX ancestry while differing from later standards. Another system could implement standardized Unix interfaces without containing UNIX source code at all.

POSIX

POSIX, the Portable Operating System Interface, developed as an effort to define a common interface that software could expect across operating systems. Rather than defining how an operating system had to work internally, POSIX concentrated on interfaces visible to programs and users. Software could rely upon defined behavior instead of the peculiarities of a particular vendor’s UNIX.

Among the areas standardized by POSIX are:

• Process management
• Files and directories
• Signals
• Shell behavior
• Command-line utilities
• Programming interfaces

Two operating systems can implement the same POSIX interfaces while using very different code internally. POSIX could therefore improve portability across an increasingly diverse UNIX family without requiring every implementation to descend from UNIX source.

Windows NT provides an interesting example. I remember wondering why Microsoft cared about including POSIX support in Windows NT. I also remember people describing Windows NT as a UNIX because it supported POSIX. That never seemed quite right. The difference between lineage and standards explains why.

Microsoft could implement a POSIX environment without turning Windows NT into a descendant of UNIX. POSIX described interfaces an operating system could provide; it did not prescribe where the operating system’s source code had to come from. Windows NT shows just how far the Unix interface had traveled beyond the UNIX family itself.

Microsoft continued experimenting with ways to support Unix and, later, Linux software on Windows. We will return to that history when we follow the Windows branch. For now, POSIX shows how Unix compatibility could extend beyond the UNIX family.

From POSIX to the Single UNIX Specification

POSIX was part of a broader effort to bring consistency to an increasingly fragmented Unix world. Other standards efforts were also trying to define a common operating environment, and over time those efforts converged.

POSIX and the Single UNIX Specification should not be treated as competing definitions of Unix. Today, the core volumes of the Single UNIX Specification are simultaneously the IEEE POSIX standard and the ISO/IEC 9945 standard. Much of the standardized Unix programming environment is shared between them.

The Single UNIX Specification extends that foundation into the standard used to measure conformance for UNIX systems. It encompasses the base operating-system environment along with the additional requirements needed to provide a consistent UNIX environment.

Source ancestry tells us how an operating system developed. Standards tell us whether the environment it provides meets an established specification.

Source ancestry and standards can now answer different questions. One tells us how an operating system developed. The other tells us whether the environment it provides meets an established specification.

UNIX as a Trademark

UNIX is also a trademark. The Open Group administers the UNIX trademark and operates the certification program associated with the Single UNIX Specification.

Certification is based upon conformance rather than genealogy. A product must demonstrate that it passes the applicable certification tests, and its supplier must agree to the requirements of the certification program. The Open Group can then grant the supplier a license to use the UNIX trademark with that product.

A system can have historical UNIX ancestry without currently being a certified UNIX product. Tracing source code back to Bell Labs is not what certification establishes. Certification tells us that a particular product conforms to a defined UNIX specification.

The word UNIX can describe several related but distinct relationships:

Keeping these meanings separate clears up otherwise confusing descriptions of operating systems. Standards allowed Unix compatibility to extend beyond the original source tree. Certification gave the UNIX name a definition that did not depend solely upon tracing code back to Bell Labs.

Unix-Like Without UNIX Source

Unix interfaces could be described independently of the source code that originally implemented them. An operating system therefore did not have to descend from Bell Labs UNIX to provide a familiar Unix environment. Developers could create their own implementations of the same ideas and interfaces.

The term Unix-like is useful for this broader family. It can describe systems that follow Unix conventions, provide similar tools and interfaces, or deliberately seek compatibility without claiming UNIX source ancestry or certification. The boundary is less precise than either a source lineage or a formal standard, but the term helps separate the influence of Unix from the narrower history of UNIX itself.

Independent implementation also mattered because UNIX source was proprietary. Reproducing Unix behavior without copying that source made it possible to pursue goals that commercial UNIX vendors were not necessarily trying to achieve. One of the most consequential attempts began with the GNU Project.

GNU’s Not Unix

Richard Stallman announced the GNU Project in 1983 with the goal of developing a complete free Unix-compatible operating system. Its name, GNU’s Not Unix, deliberately captured the distinction. GNU was intended to behave like Unix, but it would be independently implemented rather than another version of UNIX.

Unix compatibility gave the project an existing model to work from. Developers did not need to invent an entirely new operating environment simply because they were writing new code. Programs, commands, programming interfaces, and established Unix practices provided a familiar target while GNU’s implementation could remain independent.

The goal also connected compatibility with software freedom. The freedoms to use, study, modify, and redistribute software were central to the GNU Project. A free Unix-compatible operating system could preserve a useful operating model without depending upon the proprietary software that implemented UNIX.

GNU was intended to behave like Unix, but it would be independently implemented rather than another version of UNIX.

GNU was not another branch of the Bell Labs source tree, and its purpose did not depend upon permission to use the UNIX trademark. The goal was to build a new operating system that provided a compatible Unix environment using freely available source code.

That is where we can leave GNU for now. The project had established its goal and shown that a Unix-like system could be built independently. How GNU attempted to complete that operating system is the next part of its story.

Summary

UNIX continued after its early fragmentation as a genuine source-code family. System V and the commercial UNIX systems carried that lineage into workstations, servers, and enterprise computing. Some branches survived in specialized markets, while others disappeared or passed through acquisitions as the commercial UNIX market contracted.

Source ancestry was no longer the only way an operating system could be related to UNIX. POSIX defined interfaces that could be implemented independently. The Single UNIX Specification and UNIX certification provided a standards-based meaning for the UNIX name. A system could share UNIX ancestry, provide standardized Unix interfaces, qualify to use the UNIX trademark, or combine those relationships in different ways.

Unix ideas could also spread without the original source code. A Unix-like system could reproduce familiar interfaces, tools, and conventions through an independent implementation. The GNU Project made that distinction explicit in its own name: GNU’s Not Unix. Its goal was not another proprietary UNIX descendant, but a complete free operating system compatible with Unix.

UNIX had become more than a line of source code descending from Bell Labs. It was a historical family, a standardized environment, a certified name, and a model for independently developed Unix-like systems. Keeping those meanings separate gives us a clearer way to follow the operating-system families that developed from them.

UNIX gives us an opportunity to see those effects across an entire family of operating systems. AT&T licensed UNIX source code to universities and computer companies, allowing different organizations to study, modify, and adapt the system under the terms of those licenses. That helped UNIX spread, but it also helped create distinct branches as licensees developed UNIX for different hardware, customers, and purposes. Licensing continued shaping those branches: Berkeley eventually worked to remove AT&T-controlled code from BSD so that its own work could be distributed more freely. Licensing did not merely determine who could receive UNIX. It helped shape what the UNIX family became.

The code did not travel alone. As the UNIX family grew, ideas and capabilities moved between its branches, and eventually UNIX concepts traveled beyond systems descended from AT&T source. New operating systems could reproduce UNIX interfaces and conventions without containing UNIX code. The ideas had begun to spread farther than the code.

That success created a new problem. If UNIX could refer to descendants of the original source, systems assembled from different UNIX traditions, and independently developed systems that behaved like UNIX, what did it mean for an operating system to be UNIX? Standards such as POSIX emerged as part of the answer, defining common interfaces across an increasingly diverse UNIX and Unix-like world.

UNIX Leaves Bell Labs

UNIX began at Bell Labs, but it did not stay there. During its early development, AT&T operated under restrictions that limited its ability to enter the computer business. Instead of treating UNIX like a conventional commercial software product, AT&T made it available under license to universities, government organizations, and eventually commercial organizations. Many of those licenses provided access to the source code.

That gave UNIX an unusual path outward. Organizations receiving the source did not merely receive an operating system they could run. They could study it, adapt it to their computers, and develop it for their own purposes. As more organizations did so, UNIX was becoming something larger than the system being developed at Bell Labs.

Licensing Lets the Code Travel

Source access became particularly useful because UNIX had already gained another important characteristic: portability. Rewriting much of UNIX in C reduced its dependence on the assembly language of one particular computer. Moving UNIX to another architecture still required work, but it no longer meant rewriting the entire operating system for every new machine.

Licensing and portability solved different parts of the same problem. Portability allowed UNIX to move between computers; licensing allowed its code to move between organizations. Together, they made it possible for UNIX to appear on hardware and in institutions far removed from Bell Labs.

Portability allowed UNIX to move between computers; licensing allowed its code to move between organizations.

Those organizations did not all need the same operating system. Universities could experiment with UNIX and develop new capabilities. Computer manufacturers could adapt it to their own hardware and customers. Other organizations could modify it around their particular requirements. Once those changes began accumulating independently, UNIX no longer had to develop in only one direction.

The licenses that helped UNIX spread also created the conditions for different branches to develop. Organizations could begin with related AT&T code and produce increasingly different systems. UNIX was becoming a family because its source had been allowed to travel.

Berkeley Builds on UNIX

One of the most important destinations was the University of California, Berkeley. Berkeley began working with licensed UNIX in the 1970s and distributed additions and modifications as the Berkeley Software Distribution, or BSD. Over successive releases, those changes became increasingly substantial.

Berkeley contributed tools and operating-system capabilities that would become important well beyond the university. Its networking work became particularly influential as UNIX systems became connected to networks and eventually to the growing Internet. BSD was no longer simply a few local modifications to UNIX; it had become a major branch of UNIX development.

At this stage, however, BSD was still a branch in the literal sense. It had grown from licensed UNIX source, and its distributions contained AT&T-controlled code. Receiving Berkeley’s additions did not erase the licensing requirements attached to the UNIX code underneath them.

That distinction will become increasingly important as we follow the UNIX family. BSD was not merely an operating system designed to resemble UNIX. Its history ran directly through the original UNIX source tree.

Licensing Pushes BSD Toward Independence

The same licensing arrangement that allowed Berkeley to build on UNIX also placed limits on how Berkeley could distribute the resulting system. Berkeley could make its own work available under its own terms, but it could not simply treat AT&T’s portions of the operating system as Berkeley code.

That gave Berkeley a reason to separate the two. Developers progressively replaced AT&T-controlled portions of BSD with implementations that could be distributed under Berkeley’s terms. What had begun as modifications to licensed UNIX gradually moved toward a system that no longer required the original AT&T source to function.

Licensing gave Berkeley access to UNIX code. The restrictions attached to that code later gave Berkeley a reason to replace it.

The process took years and eventually became part of a larger legal dispute over UNIX and BSD code. We will return to that history when we follow the BSD family itself. Here, the important point is the relationship between the two developments: AT&T’s licensing helped create the BSD branch, while the restrictions attached to AT&T code helped give Berkeley a reason to remove that code.

BSD therefore shows why the UNIX family cannot be understood as a simple tree. UNIX source traveled outward and created a new branch, but that branch began replacing parts of the code from which it had grown. Meanwhile, AT&T and commercial vendors continued UNIX development along other paths. The code had spread, and the branches were beginning to take on lives of their own.

AT&T Builds the Commercial UNIX Line

While Berkeley was developing BSD, UNIX continued changing at AT&T. Changes in AT&T’s business environment opened the way for the company to treat UNIX more directly as a commercial product. That created another major path for the code that had begun at Bell Labs.

The result was not simply an AT&T operating system competing with BSD. Computer manufacturers wanted UNIX for their own hardware, and AT&T’s commercial UNIX became a foundation on which vendors could build. The UNIX family expanded across machines ranging from workstations to larger commercial systems.

From Research UNIX to System V

The UNIX developed at Bell Labs had gone through a series of Research UNIX editions, but AT&T increasingly consolidated work intended for commercial use. UNIX System III, released outside Bell Labs in 1982, brought together development from several earlier AT&T UNIX efforts. It was followed in 1983 by UNIX System V.

System V became the principal commercial UNIX line associated with AT&T. It continued through several releases, adding capabilities while providing a common starting point for commercial UNIX implementations. Vendors could license AT&T technology and adapt UNIX to the computers and markets they served.

This produced another kind of UNIX branch. Berkeley had grown from a university research environment, while commercial vendors built systems around particular hardware platforms and customers. The underlying UNIX code could be related even when the resulting operating systems were sold by different companies for very different machines.

IBM Builds AIX

IBM entered the UNIX family with AIX. Like other vendor UNIX systems, AIX was not simply AT&T UNIX with a different name. IBM developed it around its own hardware and enterprise requirements while drawing from established UNIX traditions.

AIX 3 shows how those traditions were already beginning to overlap. Its foundation drew from AT&T System V while incorporating features associated with BSD. IBM could build a commercial UNIX whose source history ran through the AT&T line while also adopting capabilities developed elsewhere in the UNIX family.

AIX also demonstrates how far UNIX had moved into commercial computing. AT&T code could provide the foundation, while a major computer manufacturer developed that foundation into its own long-lived operating system.

Hewlett-Packard Builds HP-UX

Hewlett-Packard followed a similar path with HP-UX. Early HP-UX development drew from AT&T UNIX, including System III and later System V, as Hewlett-Packard adapted UNIX to its own computer systems.

HP-UX also incorporated capabilities associated with BSD, including networking interfaces that had become important in the Berkeley branch. Its history therefore cannot be understood simply by drawing a line from AT&T and ignoring the rest of the UNIX family.

AIX and HP-UX show why the spread of UNIX was different from distributing identical copies of one operating system. Vendors received UNIX technology, adapted it to their hardware, selected capabilities useful to their customers, and continued developing their systems over many years. The AT&T code provided ancestry, but it did not require every descendant to remain the same.

Sun Crosses the Major UNIX Traditions

Sun Microsystems makes the relationship between the major UNIX branches even clearer. Early SunOS was strongly rooted in the BSD tradition. Sun became an important commercial home for technology that had developed through Berkeley rather than primarily through AT&T’s System V line.

Sun later worked with AT&T as the major UNIX traditions began moving back toward one another. Its operating-system line would eventually move from the earlier BSD-derived foundation to one based on System V Release 4.

Sun therefore crossed between two of the most important UNIX traditions. A company whose operating system had been rooted primarily in BSD became directly involved in bringing BSD and System V technology together.

The same pattern was already visible in AIX and HP-UX. UNIX systems had distinct histories, but those histories no longer developed in isolation. The family tree was beginning to acquire connections between its branches.

The UNIX Tree Becomes a Web

A family tree is useful for showing where an operating system came from. AT&T UNIX led to multiple lines of development, Berkeley built BSD from licensed UNIX source, and vendors developed their own commercial systems. If each branch had continued independently, a tree might be enough to describe the UNIX family.

That is not what happened. Once different groups began improving UNIX for their own purposes, useful work could travel between them. The UNIX source had created branches, but the branches began contributing back to the larger UNIX world. Ancestry still mattered, but ancestry alone could no longer explain what was inside a particular UNIX system.

BSD Technology Travels Back Out

Berkeley had received UNIX code through AT&T licensing, but Berkeley did not simply consume what Bell Labs produced. Researchers and developers added their own tools and capabilities, and some of that work became valuable to UNIX users outside Berkeley.

Networking is one of the clearest examples. BSD became an important home for the development and implementation of TCP/IP networking, along with the sockets interface applications could use to communicate over networks. As networking became increasingly important, BSD-derived networking technology appeared in commercial UNIX systems as well.

The direction had reversed. AT&T code traveled outward to Berkeley, where it helped create BSD. Technology developed in the BSD branch then traveled outward again and became part of systems whose primary lineage ran through commercial UNIX.

AIX and HP-UX already gave us examples of that mixture. Both belonged to the commercial UNIX world while incorporating capabilities associated with BSD. A system could have one primary ancestry while containing technology that had traveled through another branch of the family.

A UNIX family tree can show ancestry. It cannot show every movement of technology between the branches.

Xenix Adds Another Path

Microsoft also participated in the early commercial UNIX world. It licensed UNIX from AT&T and developed Xenix, which was adapted to several hardware platforms and eventually became closely associated with the growing market for microcomputers.

Xenix developed along its own commercial path and incorporated technology from more than one UNIX tradition. Microsoft eventually shifted its operating-system attention elsewhere and transferred ownership of Xenix to the Santa Cruz Operation in 1987. Xenix nevertheless remained part of the larger UNIX story because UNIX technology had continued developing there outside AT&T.

That became important when several of these paths met again. Xenix was not a dead branch disconnected from the rest of the UNIX family. Technology associated with it became one of the ingredients considered when AT&T and Sun attempted to bring major UNIX traditions back together.

System V Release 4 Recombines the Family

By the late 1980s, the existence of competing UNIX variants had become a problem as well as a sign of UNIX’s success. Different vendors and development traditions had produced systems with different capabilities and interfaces. Shared ancestry did not guarantee that software or administrative knowledge would transfer cleanly between every member of the UNIX family.

AT&T and Sun collaborated on System V Release 4, released in 1989. SVR4 brought together technology from several important UNIX traditions, including AT&T System V, BSD, and Xenix. Rather than representing another clean split in the family tree, it deliberately recombined work that had developed along different paths.

Sun’s operating-system history makes that crossing particularly visible. Earlier SunOS had been rooted primarily in BSD. The later SunOS 5 foundation used for Solaris 2 was based on SVR4, moving Sun onto a system that combined the AT&T System V tradition with technology that had traveled through BSD and other UNIX branches.

A simple family tree was no longer enough. A tree can still tell us something important about ancestry, but it cannot show every movement of code between related systems. UNIX had become a web: code traveled outward, branches developed independently, and useful work could cross between those branches or be brought together again.

Where Did the Original AT&T UNIX Go?

With UNIX code spreading through so many branches, it is easy to lose track of the line AT&T itself continued developing. That line did not disappear with System V Release 4. Instead, the UNIX business and the rights associated with it began passing between companies.

AT&T placed its UNIX business in Unix System Laboratories, or USL, which continued developing and licensing System V. UnixWare emerged from Univel, a joint venture between USL and Novell, and was built on the System V Release 4 lineage. Novell acquired USL in 1993, bringing both the AT&T commercial UNIX business and UnixWare under Novell.

In 1995, Novell transferred its UnixWare operating-system business to the Santa Cruz Operation, commonly known as SCO. The transaction did not amount to a simple transfer of everything associated with the word UNIX. Novell retained important rights and continued receiving revenue associated with older UNIX System V source licenses, while SCO received the UnixWare business and continued developing and selling UNIX systems. Those distinctions would become important years later when ownership of UNIX copyrights became part of the SCO litigation.

The business changed hands again. The original Santa Cruz Operation sold its server software and services divisions, including UnixWare and OpenServer, to Caldera Systems in 2001. Caldera later adopted the SCO name. After bankruptcy and further transfers, the UnixWare and OpenServer product line eventually reached Xinuos, which continues that commercial operating-system lineage today.

The UNIX name followed a different path. UNIX became increasingly defined through standards rather than ownership of AT&T’s operating-system source, and responsibility for the UNIX trademark passed from Novell to X/Open in the 1990s. X/Open later became part of The Open Group. Ownership of a particular UNIX-derived codebase, historical rights associated with System V code, and the right to certify an operating system under the UNIX trademark are therefore different things.

When following UNIX history, ask which relationship you mean: source ancestry, ownership of a particular codebase, compatibility with a standard, or the right to use the UNIX trademark. They are not the same thing.

AT&T left the UNIX operating-system business without bringing the UNIX story to an end. Its code had already spread throughout the family, its own commercial lineage continued through other companies, and the UNIX name was becoming separated from any single implementation. There was no longer one piece of code we could point to and say that everything called UNIX had to descend from it.

UNIX Ideas Spread Beyond UNIX Code

By the 1980s, UNIX had spread far beyond Bell Labs. AT&T source could be found in university systems, commercial UNIX products, and vendor-specific branches. Code developed in one branch could cross into another, making the UNIX family increasingly difficult to describe as a simple tree.

But source code was no longer the only thing spreading. UNIX had been studied, taught, documented, and used for years. Developers understood many of its interfaces and conventions, and programmers had learned to expect a particular kind of operating environment. It was becoming possible to reproduce the ideas behind UNIX without inheriting the original AT&T code.

That creates a different relationship to UNIX. BSD, System V, AIX, and HP-UX can be followed through source ancestry. Other systems could instead connect to UNIX through compatible interfaces, familiar tools, architectural ideas, documentation, education, or influence.

MINIX Recreates a Unix-like System

Andrew Tanenbaum developed MINIX as a small Unix-like operating system for teaching operating-system concepts. Earlier UNIX source had been used in university operating-systems courses, but AT&T licensing restrictions eventually made that increasingly difficult. Tanenbaum responded by writing a new system from scratch that could provide a Unix-like environment without using AT&T’s UNIX source.

MINIX was therefore fundamentally different from early BSD. Berkeley began with licensed UNIX code and gradually worked toward replacing the portions controlled by AT&T. MINIX was a complete rewrite: neither its kernel nor its utility programs contained AT&T code. Its source could be studied without inheriting the licensing restrictions attached to UNIX source.

The distinction matters because it shows another way UNIX could spread. A developer no longer needed the Bell Labs implementation itself to reproduce important parts of the UNIX operating model. UNIX had become an idea that could be independently implemented.

Similar behavior does not establish source ancestry. A system can reproduce UNIX interfaces and ideas without containing UNIX code.

MINIX also became important for another reason. Its availability on personal computers put a Unix-like operating system in the hands of students and programmers who might never have had access to a commercial UNIX workstation or institutional UNIX system. One of those users was a Finnish computer-science student named Linus Torvalds.

GNU Sets Out to Replace UNIX Without Copying It

MINIX was not the only project demonstrating that UNIX ideas could exist independently of UNIX source. In 1983, several years before MINIX appeared, Richard Stallman announced the GNU Project. His goal was ambitious: build a complete free software system that would be compatible with UNIX without simply being UNIX.

The distinction was deliberate. GNU stands for “GNU’s Not Unix.” Stallman’s original announcement described a system intended to run UNIX programs while remaining its own implementation. Instead of requiring users to depend on proprietary UNIX software, GNU would recreate the operating environment with software that users could run, study, modify, and redistribute.

UNIX compatibility made that goal practical. Developers did not have to invent every interface from scratch or design an entirely new operating environment before separate pieces could work together. UNIX already provided a model for shells, compilers, utilities, libraries, and other components. Compatible replacements could be developed independently while still following expectations established by UNIX.

GNU therefore represents another way UNIX spread without AT&T source. The project was not trying to continue AT&T’s UNIX product line. It was building a different implementation around many of the same interfaces and expectations.

By 1990, GNU had found or written all of the major components it needed except the operating-system kernel. GNU’s operating environment was already well developed, but its own kernel was not yet ready to complete the system. GNU had nearly recreated the UNIX operating environment without inheriting UNIX itself.

From MINIX to Linux

Meanwhile, Linus Torvalds was using MINIX on an Intel 386 computer. He began experimenting with the processor and gradually developed what became an independent operating-system kernel. MINIX provided the environment in which that early work took place, but Torvalds was not modifying MINIX into a new operating system.

The distinction is important: influence is not ancestry. MINIX provided Torvalds with a Unix-like environment, tools, documentation, and a community in which early Linux development could take place. Linux itself was independently written rather than a new branch of the MINIX source tree.

Influence is not ancestry.

On August 25, 1991, Torvalds announced his new operating-system project to the comp.os.minix community. He described a free operating system for 386 and 486 computers and asked MINIX users what features they would like to see. He also made clear that the new system contained no MINIX code. The relationship between MINIX and Linux was real, but it was a relationship of environment and influence rather than inherited source.

Torvalds initially considered the name Freax for the project. When the early files were placed on an FTP server, Ari Lemmke instead used Linux for the directory, and that was the name that survived. The kernel would soon grow far beyond the experiments that produced it, but that belongs to a later part of our story.

For now, GNU and Linux should remain separate. GNU was an established effort to build a complete free Unix-compatible operating system. Linux was a newly written Unix-like kernel emerging from experiments performed in a MINIX environment. Neither needed AT&T UNIX source for UNIX ideas to reach it.

UNIX had first spread because organizations could obtain its code. Now systems could join the broader Unix-like world without inheriting that code at all. The code had created a family; the ideas had escaped the family tree.

What Is UNIX?

By the beginning of the 1990s, the question “What is UNIX?” no longer had a simple answer. Some operating systems descended directly from AT&T source. Others combined code and capabilities from several UNIX branches. Still others, such as MINIX, GNU, and Linux, were being independently developed around UNIX interfaces and ideas without inheriting the original UNIX source.

Shared ancestry was no longer enough to describe the larger UNIX world. Two systems could descend from UNIX and behave differently, while another system could contain no original UNIX code and deliberately provide many of the same interfaces. If software developers wanted their programs to move between these systems, they needed something more useful than a family tree.

They needed agreement about how a Unix-like operating system should behave.

POSIX Defines Common Interfaces

Efforts to standardize UNIX interfaces had already begun while the commercial UNIX branches were developing. One of the most important results was POSIX, the Portable Operating System Interface. The first POSIX.1 standard was published in 1988.

POSIX approached the problem through interfaces rather than ancestry. Instead of requiring an operating system to contain a particular body of UNIX source code, the standard defined interfaces and behavior that software could expect an operating system to provide.

That made POSIX useful beyond systems descended directly from AT&T UNIX. The standard was intended to apply not only to systems derived from original UNIX code, but also to compatible systems developed independently, emulations hosted on other operating systems, and systems running across a broad range of hardware.

POSIX therefore provided a way to describe UNIX compatibility without requiring UNIX ancestry.

That mattered for portability. A programmer targeting standardized interfaces could depend less on the peculiarities of one vendor’s UNIX implementation. Standards could not make every UNIX and Unix-like system identical, but they could establish common ground between systems whose source histories were becoming increasingly different.

UNIX Becomes a Standard as Well as a Lineage

POSIX did not completely answer the question of what could officially be called UNIX. During the 1990s, control of the UNIX trademark became separated from the commercial operating-system code that had descended from AT&T.

As Novell moved away from the UNIX business, the UNIX trademark passed to X/Open, which later became part of The Open Group. In 1994, X/Open introduced the Single UNIX Specification, establishing a common specification against which operating systems could be measured.

This changed what UNIX could mean. An operating system no longer had to descend from a particular AT&T code stream to qualify as UNIX. What mattered for use of the UNIX trademark was conformance with the specification and certification under the UNIX branding program.

The family name had effectively separated from the family tree.

That does not make ancestry irrelevant. System V, BSD, AIX, HP-UX, Solaris, and other systems still have histories that can be traced through actual UNIX code. Source ancestry and the UNIX trademark now answer different questions. One tells us where a system came from; the other tells us whether a product has demonstrated the conformance required to use the UNIX name.

Why GNU and Linux Are Not UNIX

This helps explain something that can otherwise sound contradictory. GNU and Linux are deeply connected to the UNIX tradition, but that does not make either one a descendant of UNIX source.

In 1983, Richard Stallman announced his intention to build a complete Unix-compatible software system called GNU. GNU stands for “GNU’s Not Unix,” a recursive acronym deliberately emphasizing that the project was building a Unix-compatible system rather than continuing UNIX itself.

The distinction was practical as well as linguistic. UNIX was proprietary software, and Stallman’s purpose in creating GNU was to build a system that could be used, studied, modified, and shared without accepting the restrictions attached to proprietary UNIX. GNU could reproduce useful UNIX interfaces, tools, and behavior while implementing them independently. GNU wanted UNIX compatibility without UNIX’s licensing restrictions.

Linux reached a similar technical position by a different route. Torvalds developed Linux in a Unix-like environment and deliberately implemented interfaces associated with UNIX and POSIX, but Linux was independently written rather than derived from AT&T UNIX source. When Linux was combined with GNU tools and other software into complete operating systems, those systems could provide a Unix-like environment without acquiring a commercial UNIX source license.

By then, however, UNIX had also become a certification and trademark. A Linux-based operating system could potentially become an official UNIX system by demonstrating conformance with the Single UNIX Specification and completing The Open Group’s certification process. A small number of Linux-based systems eventually did. Most Linux distributions did not need the UNIX name badly enough to take on the cost and work of certification. Unix-like, Unix-compatible, and POSIX compatibility could describe the relationships that mattered without acquiring the right to market the product as UNIX®.

Linux can therefore follow the UNIX tradition closely without being UNIX in either of the senses we have been discussing. Linux did not inherit AT&T UNIX source, and most Linux distributions have not sought certification for the UNIX trademark. What reached Linux instead were the interfaces, conventions, tools, and ideas of the UNIX environment.

GNU and Linux therefore have a different relationship to UNIX than BSD does. BSD can point backward through source ancestry. GNU and Linux point backward through interfaces, conventions, standards, and ideas. All belong to the broader history of UNIX’s influence, but they arrived there by different paths.

UNIX, POSIX, and Unix-like Are Not the Same Thing

That history leaves several related ideas that are easy to collapse into the single word UNIX.

A system can have UNIX ancestry because its source history ultimately descends from the original UNIX code. That is the family tree we have followed through much of this article.

A system can be POSIX-conformant by implementing standardized interfaces. That relationship does not require the system to contain original UNIX source.

A product can be certified UNIX by demonstrating conformance with the applicable Single UNIX Specification and meeting the requirements for use of the UNIX trademark. UNIX in this formal sense is a certification, not simply a description of ancestry.

Finally, a system can be described more generally as Unix-like because it follows UNIX interfaces, conventions, tools, or design ideas without necessarily being descended from UNIX source or certified to use the UNIX trademark.

UNIX ancestry, POSIX conformance, UNIX certification, and being Unix-like describe different relationships. They can overlap, but they are not interchangeable.

These categories can overlap, but they are not interchangeable. A system’s source can tell us one story, its interfaces another, and its certification status another still. As UNIX spread, the meaning of the word had to expand beyond the history of one body of source code.

UNIX first spread because its code could travel. Its branches then exchanged code and capabilities with one another. Eventually its ideas and interfaces traveled beyond systems containing UNIX code at all. Standards provided a way for those increasingly different systems to share a common operating environment.

The UNIX family had become more than a family tree.

Summary

UNIX did not become a family simply because people liked the operating system and decided to imitate it. Its source code was allowed to travel. AT&T licensing gave universities and computer companies access to UNIX code they could study and adapt, while the portability UNIX gained from C made those adaptations practical across different hardware. The same licensing system also placed limits on what recipients could do with that code. Berkeley demonstrates both sides particularly well: licensing gave Berkeley access to UNIX, while licensing restrictions eventually gave Berkeley a reason to replace the AT&T-controlled portions of BSD.

Once UNIX had spread, its branches did not remain isolated. Berkeley-developed technology moved into commercial UNIX systems, vendors combined AT&T and BSD traditions with their own work, and System V Release 4 deliberately brought together technology from System V, BSD, and Xenix. The UNIX tree became a web. Even as AT&T left the UNIX business and its commercial operating-system lineage passed through other companies, UNIX technology had already spread too widely to belong to one development path.

Eventually, the ideas traveled farther than the code. MINIX demonstrated that a Unix-like system could be independently implemented for teaching. GNU deliberately pursued a free Unix-compatible system without becoming UNIX, and Linux emerged as another independent implementation shaped by the Unix-like environment around it. POSIX and the Single UNIX Specification helped separate compatibility and the UNIX name from any requirement that a system descend from one particular body of source code. UNIX ancestry, POSIX compatibility, UNIX certification, and being Unix-like could now describe related but different relationships.

That leaves us with more than one path through the UNIX tradition. Some systems can trace their history through the original UNIX source tree; others joined that tradition through interfaces, conventions, standards, and ideas instead. Over the next articles, we can follow those paths individually. We will begin with BSD, the branch that started with licensed AT&T UNIX, grew into one of the major centers of UNIX development, and eventually became independent enough to produce a family of operating systems of its own.

Those are not all the same permission. A program might be available without charge but prohibit modification. Another might include its source code but restrict what can be done with it. A company might sell software while allowing its customers to study, modify, and redistribute it. A developer might even encourage people to copy a commercial program as widely as possible while keeping its source code proprietary. Price, source-code availability, copying, modification, redistribution, and commercial use are related, but they describe different things.

Those distinctions are behind terms such as commercial software, shareware, Free Software, Open Source, proprietary software, permissive licensing, and copyleft. They do not describe mutually exclusive categories. Free Software can be sold, Open Source software can use a copyleft license, and shareware can encourage copying while remaining proprietary. Even two Open Source projects can use licenses that affect how easily code can move between them.

Rather than treating those distinctions only as definitions, we are going to follow them through the histories of real software. Doom will take us from proprietary commercial software through shareware and eventually into Open Source. GNU Emacs will bring us into the GNU Project, Free Software, and copyleft. BSD will show what permissive licensing allows code to become downstream. Red Hat and Debian will demonstrate different ways of building systems from freely available software. Finally, StarOffice, OpenOffice.org, and LibreOffice will show what happens when ownership and stewardship change, a community forks the code, and different licenses affect what happens afterward.

What Kind of Software is it?

Software licensing uses several terms that are often treated as though they describe mutually exclusive kinds of software. They do not. A program can be commercial and Open Source, or noncommercial and proprietary. Understanding the differences requires separating the business surrounding software from the rights its license gives to users.

Commercial Software

Commercial software is software developed, distributed, or supported as part of a commercial activity. A company might sell copies of the program, charge for subscriptions or support, bundle it with another product, or use the software as part of a larger business.

The opposite is noncommercial software: software developed or distributed without a commercial purpose. Universities, hobbyists, volunteer communities, and individual programmers have all produced noncommercial software.

Neither term tells us what users are permitted to do with the software. Commercial software does not have to be proprietary, and noncommercial software does not have to be Free or Open Source. Commercial and noncommercial describe the economic activity surrounding software, not the rights granted by its license.

Proprietary Software

Proprietary software is software whose owner retains rights that are not granted to its users. A license might permit someone to run a program while restricting copying, modification, access to source code, redistribution, or some combination of those activities.

Proprietary software is frequently commercial, which is why the two terms are sometimes treated as synonyms. They are nevertheless different concepts. A developer can distribute proprietary software without charging for it, just as a company can make money from software that gives its users much broader rights.

Free Software

Free Software describes software in terms of the freedoms given to its users. The Free Software movement defines those freedoms around the ability to run a program for any purpose, study how it works, modify it, redistribute copies, and distribute modified versions.

The word free refers to freedom, not necessarily price. Free Software can be given away, but it can also be sold. A business can charge for copies, packaging, support, integration, or other services without making the underlying software cease to be Free Software.

Source code is important because some of these freedoms cannot practically exist without it. Studying or modifying a program requires access to the human-readable code from which it was built. Merely making source code visible, however, does not automatically give someone permission to modify or redistribute it.

Open Source Software

Open Source Software overlaps substantially with Free Software. Open Source licenses make source code available and provide rights to use, modify, and redistribute the software under defined conditions. As a result, much of the software we encounter can correctly be described as both Free Software and Open Source Software.

The two terms nevertheless come from different movements and emphasize different ideas. Free Software places the freedoms of software users at the center of the discussion. Open Source places greater emphasis on licensing and the development model that allows source code to be examined, modified, and redistributed. The distinction is often one of philosophy and emphasis rather than two completely separate bodies of software.

We can use Free and Open Source Software, or FOSS, when the distinction between the two movements is not important to what we are discussing. When it does matter, as it will when we reach GNU Emacs, we will use the more precise term.

None of these terms tells us how someone actually receives a copy of the software. A proprietary commercial program might be deliberately passed from user to user, while Free and Open Source Software can be sold as part of a commercial product. How software is distributed is a separate question.

Price, source availability, distribution, and licensing answer different questions about the same software.

How Proprietary Software is Distributed

How much software costs and how it reaches a user are separate from what its license allows the user to do afterward. Software can be sold, given away, or deliberately passed from one user to another while remaining proprietary. Free and Open Source Software can likewise be given away or sold. Several distribution models became particularly important during the personal-computer era.

Paid Distribution

The most familiar model is to obtain software by paying for a copy or a license to use it. During much of the personal-computer era, that often meant buying a boxed package containing disks and documentation. Software later moved increasingly toward electronic distribution, but the basic relationship remained familiar: payment was part of obtaining the software.

Paying for software does not make it proprietary. Commercial Free and Open Source Software can also be sold. The transaction tells us how the software was distributed, not what rights came with it.

Freeware

Freeware is software distributed for use without requiring payment. It became common for developers and companies to make useful programs available at no charge, whether as complete products, promotional tools, companion utilities, or software maintained for other reasons.

The important word here is price. Freeware does not necessarily give users access to source code or permission to modify and redistribute it. A freeware program can remain completely proprietary.

This is one reason freeware and Free Software should not be confused. Freeware means that the software is available without charge. Free Software refers to freedoms granted to its users.

Shareware

Shareware uses copying and evaluation as part of the distribution model. Instead of requiring a potential customer to purchase the software before trying it, developers encouraged users to obtain copies, try the program, and pass copies to other potential users. Payment or registration could then provide additional features, additional software, documentation, support, or continued authorized use, depending on the program.

Bulletin Board Systems made this model particularly powerful. A developer did not have to manufacture and ship every copy. A shareware program could be uploaded to a BBS, downloaded by its users, passed between friends, and uploaded elsewhere. The users themselves became part of the distribution network.

Permission to copy the distributed program did not make shareware Free or Open Source Software. Shareware was commonly proprietary. Its developer could encourage thousands of people to copy a program while still withholding its source code and restricting modification.

That combination will become important when we reach Doom. It was commercial software, it was proprietary, and its shareware release was deliberately designed to be copied. None of those descriptions contradicts the others.

How Free and Open Source Software is Distributed

Free and Open Source Software created a different distribution problem. Giving users permission to copy, modify, and redistribute software made it possible for copies to travel freely, but obtaining one program was only part of the problem. A useful computer system might depend on software produced by hundreds or thousands of independent projects.

Individual Projects

Early Free and Open Source projects could distribute their own software directly. Source code might be obtained from another user, copied from physical media, or downloaded from an FTP server or project site. Because redistribution was permitted, copies did not necessarily have to come from the original developer.

This decentralized distribution was powerful, but it also left users responsible for obtaining, building, configuring, and updating software from many different sources.

Packages and Repositories

Packaging systems made that collection of independent software easier to manage. Instead of every user finding and installing each program directly from its original developer, software could be prepared as packages that described what was being installed and what other software it required.

Repositories took that idea further by collecting packages into maintained sources from which users could install and update software.

Distributions

A software distribution goes beyond simply making copies available. It selects software from many projects, integrates it, packages it, establishes defaults, provides installation and update mechanisms, and presents the result as a usable system.

This becomes especially important with GNU/Linux. Linux is the kernel, but what someone installs as a Linux distribution contains software from many independent projects: the Linux kernel, GNU utilities, libraries, shells, servers, desktop environments, applications, and thousands of other components.

The ability to redistribute Free and Open Source Software makes those larger systems possible, but it does not dictate who must assemble them or why. A volunteer community can build a distribution, and so can a commercial company. Debian and Red Hat will let us see both approaches using much of the same larger pool of software.

Source Code and the Rights That Come With It

So far, we have repeatedly mentioned access to source code, but source code is not always included when software is distributed. Most users receive a compiled program: the machine-executable form produced from source code written by programmers. They can run the program without possessing the original human-readable code used to create it.

With proprietary software, the source code is commonly kept by its developer or owner. Users receive the compiled program and whatever rights its license grants them. Even if they are permitted to copy the program—as they might be with freeware or shareware—that permission does not necessarily include access to its source.

Free and Open Source Software works differently because the ability to study and modify a program requires access to its source code. The source therefore has to be available to users entitled to those rights. This does not mean every copy must arrive with a folder full of source files beside it. A distribution can provide ready-to-run binary packages while making the corresponding source available separately.

A developer can also publish source code without granting the rights required for the software to be Free or Open Source. The code may be source available—people can read it—but its license may restrict modification, redistribution, commercial use, or other activities.

Being able to read the source is not the same thing as having permission to modify or redistribute it.

Permissive Licenses

Making software Free or Open Source does not mean giving up copyright or placing the code into the public domain. The copyright holder instead uses a license to grant other people rights to use, study, modify, and redistribute the software. Different licenses can grant those rights under different conditions.

A permissive license, such as the licenses associated with BSD, grants broad rights with relatively few requirements on what happens to modified or redistributed versions. Copyright and license notices generally have to be preserved, but the code can often be incorporated into software distributed under different terms, including proprietary commercial products.

That flexibility helps explain why BSD code has traveled so widely. A company can take permissively licensed code, modify it, combine it with its own code, and distribute the resulting product without necessarily having to release its modifications under the original BSD license.

Copyleft Licenses

A copyleft license takes a different approach. It also grants broad rights to use, study, modify, and redistribute software, but it places requirements on certain forms of redistribution so that the freedoms granted by the original license are preserved downstream.

The GNU General Public License, or GPL, is the best-known example. If GPL-covered software is modified and a covered derivative work is distributed, the GPL requires the corresponding source to be made available under the GPL’s terms. Someone can modify the software, sell it, and build commercial products with it, but cannot simply take the covered code, distribute a proprietary version of that covered work, and withhold the freedoms the GPL was designed to preserve.

Permissive and copyleft licenses therefore protect different goals. A permissive license emphasizes giving downstream developers broad freedom over what they build from the code. Copyleft emphasizes preserving particular software freedoms as the code moves downstream. Neither approach makes software inherently more or less Open Source; both permissive and copyleft licenses can qualify as Free and Open Source licenses.

Doom: From Shareware to Open Source

When id Software released Doom in December 1993, it was unquestionably a commercial product. id Software intended to make money from the game, and the complete game was proprietary software. Yet the company did something that might sound strange if commercial and proprietary software are assumed to mean tightly controlled distribution: it encouraged people to copy Doom.

What people were encouraged to copy was the shareware version. The first episode, Knee-Deep in the Dead, could spread from one player to another and across Bulletin Board Systems, while the remaining episodes were part of the registered commercial product. Instead of treating every freely copied disk or download as a lost sale, the shareware model turned those copies into advertising. Someone could play a substantial portion of Doom, give it to a friend, and potentially create another customer.

Doom was commercial because id Software was selling a product. It was proprietary because id retained control over the software and its source code. It was shareware because id deliberately permitted and encouraged redistribution of the shareware release. None of those descriptions conflicts with the others.

But Doom did not remain in that state forever.

On December 23, 1997, John Carmack released the source code for the Doom engine. The release used the Linux version rather than the original DOS code because the DOS sound support depended on the third-party DMX sound library, which was not publicly available and therefore could not be included. The game data—the levels, graphics, sounds, and other assets that made Doom the game—also remained copyrighted and were not simply given away with the engine source.

Publishing the source did not initially make Doom Free or Open Source Software in the sense we use those terms today. The original Doom Source Code License released the code for non-profit use and permitted people to examine and modify it, but it prohibited commercial exploitation and did not permit redistribution of the source itself. The source was available, but the rights attached to it were still restricted.

That changed again in October 1999, when id Software rereleased the Doom source under the GNU General Public License. The GPL allowed the engine to be used, modified, and redistributed under a copyleft license. The commercial game released in 1993 had therefore traveled through several different arrangements: proprietary software distributed partly through shareware, source code made publicly available under restrictions, and finally an engine released as Free and Open Source Software.

The results outlived the original computers for which Doom was written. Developers could port the engine to new operating systems and hardware, fix limitations, add features, and create new source ports. The original game assets still had their own copyright restrictions, so an Open Source Doom engine did not mean that the complete commercial game had suddenly become free to redistribute.

One result has become something of a tradition among programmers and hardware hackers: the Doom Test. If a device contains a processor and a display—or sometimes anything that can be persuaded to act like one—someone will eventually try to make it run Doom. The game has appeared on calculators, watches, cameras, printers, and other devices that were never intended to be gaming machines. Some of these ports are serious demonstrations of hardware and software capabilities; others exist largely because getting Doom to run somewhere unexpected is fun. The availability of the engine’s source code helped make that experimentation possible. A commercial game from 1993 became not only something people continued to play, but a familiar challenge for demonstrating what an unusual piece of hardware could be made to do.

Doom gives us a useful first lesson because the software itself changed categories while remaining recognizably the same project. How software is sold, how copies are distributed, whether its source can be seen, and what its license permits are separate properties—and each of them can change over the life of a program.

A program can change its distribution model, source availability, and license without ceasing to be the same software project.

GNU Emacs: An Editor and the Freedom to Modify It

The story of GNU Emacs begins before GNU. Its ancestry reaches back to the MIT Artificial Intelligence Laboratory in the 1970s, where Richard Stallman worked on an extensible editor built around TECO. Rather than treating an editor as a fixed collection of commands, Emacs could be customized and extended. Users could change how the editor behaved and add new capabilities instead of waiting for the original developer to provide them.

That extensibility became one of Emacs’s defining characteristics. GNU Emacs would eventually use Emacs Lisp as its extension language, allowing the editor to become considerably more than a place to type text. Email, calendars, games, development tools, and other applications could live inside Emacs. It even includes M-x doctor, a conversational psychotherapist program in the tradition of ELIZA.

By then, however, Stallman was confronting a larger problem than how a text editor should work. The cooperative software culture he had known at MIT was changing as software increasingly became proprietary and source code became less freely shared. In September 1983, he announced the GNU Project: an effort to create a complete Unix-compatible operating system whose users would be free to use, study, modify, and share its software. Development began in 1984.

GNU needed an editor, and Stallman already knew what kind of editor he wanted. He began writing GNU Emacs in September 1984. By early 1985 it was usable, and other people wanted copies.

That created an interesting distribution problem. People connected to the Internet could obtain GNU Emacs through anonymous FTP, but many potential users were not online. Stallman offered another option: for $150, he would mail GNU Emacs on tape. The software remained Free Software, and recipients remained free to copy it for someone else. What Stallman charged for was the service of providing a physical copy.

GNU Emacs therefore gives us an early example of something our terminology already allows: Free Software could also be commercial software. Charging money for a copy did not determine whether the software was Free. The freedoms accompanying that copy did.

From Sharing to Copyleft

There was still another problem. Giving someone permission to modify and redistribute software did not necessarily guarantee that those freedoms would survive into later versions. A developer could take freely available code, modify it, and distribute the resulting program under proprietary terms if the original license permitted it.

Stallman’s answer was copyleft. Instead of abandoning copyright, copyleft uses copyright and a software license to grant users broad freedoms while placing conditions on redistribution intended to preserve those freedoms downstream. Someone can use the software, study it, modify it, share it, and even sell it, but covered derivative works that are distributed must remain available under the required copyleft terms.

GNU Emacs became an important early application of that idea. Early versions used a program-specific GNU Emacs General Public License, while the licensing work surrounding GNU software eventually developed into the GNU General Public License, or GPL. GPL version 1 appeared in 1989 and provided a reusable copyleft license for GNU software and other projects. Rather than every GNU program needing its own separately written licensing arrangement, the GPL could express the same basic set of downstream requirements across many programs.

This is the central difference between simply releasing source code and using copyleft. Source availability makes it possible to examine code. Permission to modify it makes further development possible. Copyleft adds the requirement that particular freedoms accompany covered code as it continues downstream.

Copyleft is not merely permission to modify code. It is a way of making particular freedoms travel downstream with covered code.

Emacs and vi

GNU Emacs also entered one of computing’s longest-running arguments: Emacs versus vi. The two editors grew from different traditions. vi came from Bill Joy’s work at Berkeley and the BSD world, while GNU Emacs became closely associated with GNU and Free Software. Their different interfaces and philosophies inspired decades of arguments over which editor programmers ought to use.

Plenty of users simply found something that worked for them. I largely avoided the Emacs-versus-vi argument by using Pico. As GNU/Linux distributions became more important, however, Pico’s license became a problem. Debian treated Pine and Pico as non-free, and the license did not permit Debian to distribute modified binaries, so users had to build the software from source and Debian’s patches rather than install it as a normal binary package. I moved to JOE instead.

By the time nano appeared as a GPL-licensed Free Software replacement for Pico, I had already moved on from that family of editors. The appearance of nano nevertheless demonstrates the practical effect of the licensing problem. Pico remained a useful editor, but its license affected whether distributions could package and redistribute it under their rules, and the resulting gap helped create demand for a Free Software replacement.

The editor war is mostly computing culture, but the histories behind the editors bring us back to licensing. GNU Emacs shows one answer to the question of what should happen when freely modifiable software moves from one developer to another: the freedom to modify the code should travel with the code. BSD, coming from the other side of the old editor rivalry, will give us a different answer.

BSD: Code That Was Free to Travel

The other side of the old Emacs-versus-vi rivalry brings us back to Berkeley. vi was created by Bill Joy as part of the software work surrounding the Berkeley Software Distribution, or BSD. As we saw last week, BSD began as modifications and additions to AT&T UNIX at the University of California, Berkeley, and eventually became one of the major branches of the UNIX family.

BSD’s influence spread well beyond the systems that carried its name. Berkeley developed important UNIX tools and, especially with 4.2BSD, helped establish the TCP/IP networking software that became enormously influential. Commercial UNIX systems incorporated Berkeley software, while BSD itself continued developing at the university.

There was a complication, however. BSD had grown from UNIX, and early BSD distributions still contained AT&T-owned UNIX code. Receiving those distributions therefore required an appropriate UNIX source license. Berkeley could distribute the software it had written, but it could not simply give everyone the proprietary AT&T portions of the system.

By the late 1980s and early 1990s, Berkeley’s Computer Systems Research Group began separating its own work from the AT&T code. Networking Release 1 made Berkeley’s networking code separately redistributable, and Networking Release 2 pushed much farther toward a complete system. A legal dispute over portions of Net/2 was settled in 1994, after which Berkeley released 4.4BSD-Lite as an unencumbered codebase. The BSD descendants could then continue developing without depending on proprietary AT&T UNIX code.

The license Berkeley used for its own code took a different approach from the copyleft we just encountered with GNU Emacs. A BSD-style license is permissive. It grants broad permission to use, modify, and redistribute the code while imposing relatively few requirements on what a downstream developer must do with a resulting product.

Copyleft is designed to ensure that particular freedoms continue downstream when covered derivative works are distributed. A permissive BSD license allows a downstream developer considerably more discretion. BSD-licensed code can remain in an Open Source project, but it can also be incorporated into a proprietary product without requiring that all of the resulting proprietary code be released under the BSD license.

The code is not in the public domain. Copyright still exists, and BSD licenses still impose conditions, such as preserving copyright notices and disclaimers. What the license does not generally require is that someone who incorporates the code into a larger product must release that larger product’s source code under the same terms.

That choice helped BSD technology travel into some very different systems.

These are not all the same kind of system. OpenBSD and DragonFly BSD became independent Free and Open Source operating systems. OPNsense uses FreeBSD as the foundation for a specialized firewall and routing platform. Apple’s Darwin combines BSD technology with other components as the foundation beneath macOS, while Force10 used NetBSD as the foundation for a commercial network operating system.

The table only shows the immediate connection. The BSD family has a much larger and more complicated family tree, which deserves its own story. What matters here is what happened to the code after it was released under permissive terms. It could remain within Free and Open Source projects, become the foundation of new operating systems, power specialized appliances, or become part of larger commercial and proprietary products.

This is the other major answer to the downstream question. GNU’s copyleft approach says, in effect, you may build on this code, but the freedoms attached to covered code must continue with it. The permissive BSD approach says, you may build on this code, and you have broad freedom to decide how your own resulting work will be distributed.

Both approaches produce Free and Open Source Software. They differ in what kind of freedom they emphasize downstream. BSD’s history shows one consequence of the permissive choice particularly well: the code was free to travel, even into systems whose developers chose a very different licensing model for what they built around it.

Permissive licensing gives downstream developers broad freedom over what they build. Copyleft puts more emphasis on preserving freedoms as covered code moves downstream.

Debian: Building a System as a Community

The software freedoms we have been following do more than allow an individual program to be modified or redistributed. They also allow people to assemble software from many independent projects into something larger. Debian shows what can happen when a community takes responsibility for doing exactly that.

Ian Murdock founded the Debian Project in August 1993, when the idea of a Linux distribution was still relatively new. Linux provided a kernel, GNU provided many of the tools needed around it, and other Free Software projects supplied still more pieces. Turning all of those pieces into a usable operating system required someone to select them, package them, keep track of their dependencies, integrate them, distribute updates, and decide what belonged in the system.

Debian was intended from the beginning to be developed openly. Instead of belonging to a company producing a Linux product, it grew from a small group of Free Software developers into an organized international community. Individual developers became responsible for packages, while the project developed policies and technical processes for making thousands of independently developed pieces of software behave as one distribution.

That organization matters because a distribution is itself a substantial piece of engineering. Debian does not write every program it distributes. Much of its work happens between the original software project—the upstream project—and the person installing Debian. Debian developers package upstream software, describe dependencies, integrate it with the rest of the system, apply or forward fixes, test combinations of packages, and maintain repositories from which complete systems can be installed and updated.

As Debian grew, its package-management system became increasingly important to that work. Early Debian releases had relatively primitive package handling, but the project developed dpkg and increasingly detailed information about relationships between packages. A user no longer needed to treat every program as an isolated piece of software obtained directly from its developer. The distribution could manage a collection of software as a system.

Defining What Belongs in Debian

Building a Free Software distribution also created a question that compiling and packaging alone could not answer: what counts as Free Software?

In 1997, Debian adopted its Social Contract and the Debian Free Software Guidelines, or DFSG. The Social Contract states commitments the Debian Project makes to the Free Software community, while the DFSG provides criteria Debian can use when deciding whether a software license is sufficiently free for software to be included as part of Debian.

Those guidelines include requirements such as allowing free redistribution, permitting modification and derived works, and not restricting use of the software to particular people, groups, or fields of endeavor. They do not require one particular licensing strategy. Debian explicitly recognizes licenses including the GPL and BSD licenses as examples of Free Software licenses.

Debian can contain software under both copyleft and permissive licenses. The distribution does not require every component to make the same choice about downstream licensing. Instead, each component’s license must provide the freedoms necessary to satisfy Debian’s guidelines.

Software that does not meet those requirements has historically been handled in separate archive areas rather than as part of the Debian system itself. Debian can therefore help users obtain some non-free software without redefining that software as part of Debian’s Free Software distribution.

The DFSG would also have an influence beyond Debian. Bruce Perens, who drafted the Social Contract and DFSG with input from other Debian developers, later removed the Debian-specific language from the guidelines to form the basis of the Open Source Definition. A set of rules created to answer the practical question of what software Debian could include therefore became part of the larger history of the term Open Source.

A Community Can Have Descendants

Because Debian itself can be copied and modified, the distribution can also become an upstream source for another distribution. Someone does not have to begin again with the Linux kernel, GNU utilities, and thousands of unrelated projects. They can begin with Debian’s already integrated system and build something different from it.

That has produced a large extended Debian family. Among its descendants are:

• Ubuntu
• Linux Mint Debian Edition
• Kali Linux

Linux Mint Debian Edition builds a general-purpose desktop system directly on Debian, while Kali Linux specializes that foundation for penetration testing and security work. The same freely redistributable base can therefore support projects intended for very different audiences.

Ubuntu adds another dimension to the story. It is built from Debian but developed with commercial backing from Canonical. Debian itself is a community project, yet the freedoms attached to its software allow a company to take that work downstream, integrate and develop it further, and build a commercially supported distribution around it.

That does not mean a company simply takes Debian and owns what came before it. The individual components retain their respective copyrights and licenses. Copyleft requirements still apply where copylefted components are involved, permissive licenses retain their own conditions, and changes can move between upstream and downstream projects when their licenses and development practices permit it.

Debian therefore gives us a different view of software distribution. A community can take thousands of independently developed Free and Open Source components, integrate them into a complete operating system, and make that integrated system available for still other communities and companies to build upon.

Free and Open Source licensing did not merely make individual programs easier to share. It made it possible for communities to assemble complete systems that could themselves become foundations for whatever came next.

A distribution can become an upstream project too. Debian is not only assembled from other projects; other distributions can begin with Debian.

Red Hat: Building a Business Around Free Software

Debian showed how a community could assemble thousands of independently developed pieces of Free and Open Source Software into a complete operating system. The same freedoms also left room for a company to do much of the same work commercially. Red Hat would demonstrate that selling a Linux distribution did not require turning Linux into proprietary software.

Red Hat’s story began in the early 1990s with Marc Ewing’s Red Hat Linux distribution and Bob Young’s ACC Corporation, which sold Linux and UNIX software and accessories. Young began distributing Ewing’s work, and the two joined forces in 1995 to form Red Hat Software.

There was an apparent contradiction in the business. Much of the software Red Hat distributed could already be copied legally. A customer did not necessarily have to buy Linux from Red Hat to obtain Linux, GNU utilities, or the many other Free and Open Source components included in the system.

That meant the value of the product could not depend entirely on controlling access to the underlying software. Red Hat could instead sell the work required to turn that software into something organizations could reliably use.

One of the less pleasant ways Linux users learned the value of that integration was RPM Hell. RPM made it possible to install, remove, and track packaged software, but obtaining an RPM did not necessarily mean that everything required to run it was already installed. A package might depend on several other packages, each of which introduced dependencies of its own. Users could find themselves searching the Internet for one RPM after another, only to discover that the next package required still another library or a different version of one they already had.

One solution came from a descendant of Red Hat Linux. Yellow Dog Linux was an RPM-based distribution developed primarily for PowerPC computers, including Apple Macintosh systems. Yellow Dog developed YUP, the Yellowdog Updater, to work with software repositories rather than requiring users to locate every RPM individually.

Developers at Duke University built on YUP to create YUM, the Yellowdog Updater, Modified. YUM could use repositories to determine which packages were required to satisfy dependencies and retrieve them as part of an installation. Fedora adopted YUM, and it eventually became familiar to generations of Fedora, Red Hat Enterprise Linux, CentOS, and related-system users. Yellow Dog Linux itself eventually disappeared, but its name survived in yum.

Red Hat Linux helped provide the foundation for Yellow Dog Linux. Yellow Dog’s solution to an RPM problem was expanded by other developers, then flowed back into Fedora and the Red Hat ecosystem.

Packaging a Free and Open Source operating system therefore involves more than collecting freely available programs. Someone still has to decide which versions belong together, describe their dependencies, organize repositories, test combinations, and provide updates. Better tooling can automate much of that work for the user, but only because the distribution has already done the integration work behind it.

That work includes:

• Packaging
• Integration
• Testing
• Documentation
• Technical support
• Security updates
• Long-term maintenance
• Certification

None of those activities requires taking away the freedoms granted by the underlying software. They provide value around software that customers may already have the right to copy, inspect, modify, and redistribute.

This distinction became increasingly important as Linux moved from hobbyist computers and Internet servers into businesses and large organizations. A company might be perfectly capable of downloading source code without being interested in assembling, testing, maintaining, and supporting an operating system itself. What it could purchase from Red Hat was not simply permission to possess Linux, but a maintained product and a relationship with an organization willing to support it.

From Red Hat Linux to an Ecosystem

Red Hat eventually changed how it organized its Linux distributions. Red Hat Enterprise Linux, or RHEL, had been introduced in 2002 as the company’s commercially supported enterprise distribution. The original Red Hat Linux line was discontinued in 2003, and the Fedora Project was introduced for users and developers who wanted a faster-moving community distribution.

The ability to use and redistribute Free and Open Source Software also allowed other projects and companies to develop systems around the Red Hat ecosystem. A few examples show that movement in different directions:

• Fedora
• Rocky Linux
• Oracle Linux

Fedora represents the community side of Red Hat’s own development ecosystem. Newer software and technologies can develop in Fedora before some of that work moves through CentOS Stream and eventually into Red Hat Enterprise Linux. The community project is therefore not merely a free copy of the commercial product; it participates upstream in the development path that can eventually lead toward RHEL.

Rocky Linux demonstrates movement in the other direction. It is a community-developed enterprise Linux distribution designed to be compatible with RHEL. The existence of a commercial enterprise distribution does not prevent a separate community from using the available Free and Open Source code to build its own compatible system.

Oracle Linux takes that possibility into the commercial world again. Oracle is not Red Hat, yet it can offer its own commercially supported Linux distribution designed for compatibility with RHEL. Free and Open Source licensing therefore permits an unusual commercial relationship: one company’s commercial software ecosystem can provide much of the foundation for another company’s competing commercial product.

Fedora shows a community project feeding toward a commercial distribution, Rocky Linux shows a community project appearing downstream from it, and Oracle Linux shows another commercial product appearing downstream. Commercial and community development are not opposite ends of a line. Free and Open Source licensing allows software to move among both.

What Red Hat Sells

Red Hat Enterprise Linux is commercial software, but that does not make the Free and Open Source components from which it is built proprietary. Customers pay Red Hat for an enterprise product assembled from those components and for the services surrounding that product.

The distinction is easier to see if we separate the software from the business built around it. Linux can remain licensed under the GPL. BSD-licensed components can retain their permissive licenses. Thousands of other packages can retain the licenses chosen by their respective projects. Red Hat can still select versions, integrate them, test the resulting system, provide updates, certify hardware and software, maintain releases for years, and sell support for the complete product.

A company can build a commercial product from software that its customers have substantial rights to copy and modify. The company does not necessarily make its money by preventing those freedoms. It can make money by doing work around the software that customers consider valuable.

Debian and Red Hat consequently arrive at complete operating systems through different organizations. Debian demonstrates that a community can integrate Free and Open Source Software into a distribution that later becomes the foundation for both community and commercial descendants. Red Hat demonstrates that a company can take much of the same larger pool of Free and Open Source Software and build a commercial product and support business around it.

Free and Open Source Software does not eliminate commercial software. It changes what a software company can sell and where the value of that commercial product can come from.

When customers already have substantial rights to the software, commercial value can move toward integration, maintenance, support, certification, and trust.

StarOffice, OpenOffice.org, and LibreOffice: Who Controls the Future?

The office suite we now know as LibreOffice began as proprietary commercial software. Its roots reach back to StarWriter, created by Marco Börries in Germany in the 1980s. StarDivision developed the program into a larger suite, and by 1992 it had become StarOffice.

StarOffice was eventually available on several operating systems, including Windows, OS/2, Solaris, and Linux. It was still StarDivision’s product, however. The company controlled its development and distribution in much the same way another software company might control any proprietary office suite.

Then the owner changed.

Sun Microsystems acquired StarDivision in 1999. The following year, Sun did something more significant than simply continue selling StarOffice: it announced OpenOffice.org and released the StarOffice source code for the new project on October 13, 2000. OpenOffice.org 1.0 followed on April 30, 2002. A proprietary commercial software family now had an Open Source branch that other developers could study, modify, and help develop.

Sun did not have to stop selling an office suite in order to do this. StarOffice continued as a commercial product while OpenOffice.org developed as an Open Source project. Once again, commercial and Open Source were not opposites. The same software family could participate in both models.

For several years that arrangement continued with Sun as the principal corporate sponsor of OpenOffice.org. The community could contribute to the project, while Sun remained an important center of its development and stewardship.

Then the owner changed again.

Oracle acquired Sun Microsystems in January 2010. That acquisition meant that OpenOffice.org, along with the other technology Sun had accumulated, now sat under a different corporate owner. Members of the OpenOffice.org community did not have to wait to discover what Oracle would eventually choose to do with the project.

They could fork it.

LibreOffice

On September 28, 2010, members of the OpenOffice.org community announced The Document Foundation, an independent organization intended to provide a community-governed home for the office suite. Unable to obtain the trademarked OpenOffice.org name from Oracle, the new project was called LibreOffice.

LibreOffice was not a rewrite created from nothing. It began as a fork of OpenOffice.org. The developers already had access to the source and, more importantly, the software’s license gave them the rights necessary to take that source in another direction.

That is where the right to fork becomes more than an abstract freedom written into a license. The community did not need to purchase the project from Oracle, persuade Oracle to transfer ownership, or abandon years of existing code and begin again. Developers could take the code they were already working on and continue developing it under different stewardship.

Oracle later stopped developing OpenOffice.org and, in June 2011, contributed the source code and trademarks to the Apache Software Foundation. OpenOffice therefore continued as Apache OpenOffice, while LibreOffice continued independently under The Document Foundation.

One software family had now passed through several very different arrangements:

• StarOffice
• OpenOffice.org
• LibreOffice
• Apache OpenOffice

The names alone do not explain what happened. StarOffice began as proprietary commercial software. Sun opened its source to create OpenOffice.org. The OpenOffice.org community later exercised its right to fork the code and created LibreOffice. Oracle then transferred OpenOffice.org to Apache, producing another independently governed Open Source branch.

The ability to fork did not guarantee which branch would attract developers, users, or institutional support. A software license cannot determine whether a project will succeed. What it can determine is whether people have the legal ability to continue the software when they disagree with the decisions of whoever currently controls a project.

Open Does Not Mean Interchangeable

The split also produced a subtler licensing lesson. Apache OpenOffice and LibreOffice are both Open Source, but they do not use the same licensing model.

Apache OpenOffice uses the permissive Apache License 2.0. LibreOffice is currently distributed primarily under the Mozilla Public License 2.0, with new contributions also licensed under the LGPLv3+ according to the project’s contribution policy. Those differences affect how code can move between the two projects.

Apache-licensed code can be incorporated into LibreOffice under the applicable licensing arrangements, and LibreOffice has incorporated code originating in Apache OpenOffice. The reverse direction is more difficult. Code contributed only under LibreOffice’s copyleft licenses cannot simply be incorporated into Apache OpenOffice and redistributed solely under Apache’s permissive license.

The result is an asymmetric relationship. Apache OpenOffice can develop a feature under a permissive license that LibreOffice may be able to incorporate. If LibreOffice develops a change under licensing terms that impose copyleft requirements, Apache OpenOffice cannot simply take that code and place it into its Apache-licensed codebase.

Open Source does not mean that code can move freely between every Open Source project. Two projects can both provide their source code, both permit modification, and both permit redistribution while still using licenses that place different requirements on what happens when their code is combined or redistributed.

Commercial software can become the source of an Open Source project. Commercial and Open Source versions can coexist. A change in corporate ownership does not necessarily give that corporation complete control over the future of previously released Open Source code. A community with the right to fork can continue development independently. And even after a fork, the licenses chosen by the resulting projects can affect which direction code is able to travel between them.

Open Source does not guarantee who will control a project tomorrow. It gives others rights that can prevent one owner from being the only possible future for the code.

The right to fork does not guarantee that a fork will succeed. It guarantees that continued development does not have to depend on one owner saying yes.

Summary

Software does not fit neatly into a single category. Whether software is commercial, whether someone pays to obtain it, whether its source code is available, how copies are distributed, and what users are permitted to do with those copies are separate questions. Shareware can be proprietary. Freeware can restrict modification. Free Software can be sold commercially. Open Source software can be developed by volunteers, businesses, or both. Understanding software licensing begins by separating those questions rather than assuming that one answer determines all the others.

The histories of Doom, GNU Emacs, and BSD show how much the rights attached to software can differ. Encouraging people to copy Doom did not initially give them its source code, and publishing that source did not immediately make it Open Source. GNU Emacs demonstrated how copyleft could use copyright to preserve particular freedoms as software moved downstream. BSD licenses made a different choice, granting broad freedoms while generally allowing downstream developers to decide how their larger resulting works would be licensed. Both copyleft and permissive licenses can produce Free and Open Source Software, but they do not impose the same obligations on what comes next.

Those permissions become even more significant when individual programs become parts of larger systems. Debian shows how a community can assemble thousands of independently developed components into a complete operating system that can itself become the foundation for other projects. Red Hat shows how much commercial value can be created around software that customers already have substantial rights to use, study, modify, and redistribute. The history from StarOffice through OpenOffice.org and LibreOffice shows why the right to fork matters when ownership or stewardship changes—and why even two Open Source projects may not be able to exchange code equally when their licenses differ.

Licensing is therefore more than a statement about whether software costs money or whether its source code can be downloaded. It establishes permissions and obligations that help determine where code can travel, what can be built from it, and what rights accompany it along the way. Those choices helped UNIX cross organizational boundaries, allowed BSD code to spread into an enormous range of systems, and made it possible to assemble the Free and Open Source components surrounding Linux into complete operating systems. As we continue following the modern UNIX family, those licensing decisions will remain part of the explanation for why BSD and Linux developed into the ecosystems we know today.

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.

That distinction creates a problem for the computer classifications we have been using throughout this series. Mainframe, minicomputer, microcomputer, and supercomputer are useful categories because they describe real differences in architecture, scale, cost, access, and intended use. For much of computing history, those characteristics were also closely connected to what a computer was expected to do.

Networking began to weaken that relationship. A computer could still be classified according to its hardware and architecture, but those characteristics no longer necessarily described its function within a larger system. Two computers built around similar hardware could perform very different jobs depending upon their operating systems, software, configuration, and relationship to other computers.

The older classifications did not disappear. Instead, another way of understanding computers became increasingly important. We could still ask what kind of computer a machine was, but we also needed to ask what role it performed.

When Hardware Suggested Function

The computer classifications discussed earlier in this series developed because hardware, economics, and use were closely related. A computer’s architecture and resources placed practical limits on what it could do, while its cost helped determine who could afford to own and operate it. Those constraints contributed to recognizable classes of computers that tended to be used in recognizable ways.

Knowing that a system was a mainframe, minicomputer, microcomputer, or supercomputer told us more than what hardware it contained. The classification also suggested who used the machine, how it was operated, and what kinds of work it was likely to perform.

Hardware and Use Were Closely Connected

Mainframes were expensive centralized systems designed to support institutional workloads and many users. Minicomputers brought shared computing into departments, laboratories, businesses, and smaller organizations. Microcomputers reduced the scale further, placing relatively inexpensive computing resources directly in front of an individual user. Supercomputers followed a different path by concentrating substantial resources on specialized computational workloads.

These distinctions involved more than raw performance. Each class represented a combination of characteristics that influenced how the machine could reasonably be used:

• processor and memory architecture,
• storage and I/O capabilities,
• number of simultaneous users,
• physical size and supporting infrastructure,
• purchase and operating costs,
• reliability requirements,
• and the workloads for which the system was designed.

A machine’s class also carried expectations about its function. A personal computer was generally expected to serve the person sitting in front of it. A mainframe or minicomputer provided computing resources to multiple users. A supercomputer performed computational work that justified its specialized architecture and expense.

Useful Categories, Not Absolute Boundaries

These classifications were never absolute. Their boundaries changed as technology improved, and individual systems did not always fit neatly within them. A powerful microcomputer could overlap with the capabilities of lower-end minicomputers, while newer generations of smaller machines could outperform older systems from supposedly larger classes.

That overlap did not make the categories useless. Hardware characteristics and operational function remained closely related enough that the classification provided a reasonable starting point for understanding the system.

Networking made that starting point less complete. A computer no longer needed to contain all of the resources used by the person sitting in front of it, and the resources contained within a computer no longer needed to be used only by that person.

The Workstation Complicates the Picture

The workstation illustrates this transition particularly well. It provided substantial computing resources directly to an individual user while commonly operating as part of a larger networked environment. Computing could occur locally without requiring the machine to remain operationally isolated.

The workstation combined characteristics of two earlier computing models. It retained the local independence associated with the microcomputer while taking advantage of shared resources traditionally associated with larger systems.

More Than a Terminal

A traditional terminal primarily provided an interface to computing resources located elsewhere. The processor, programs, storage, and operating environment belonged to the central system. The terminal allowed the user to interact with those resources but did not normally provide an independent general-purpose computing environment of its own.

A workstation did. It contained its own processor, memory, storage, operating system, and applications. A user could perform substantial work without sending every operation to another computer.

In this respect, the workstation shared an important characteristic with the personal computer. Meaningful computation happened locally.

Local and Remote Resources

The workstation, however, was commonly intended to participate in a network. Files might reside locally or on another machine. Printers could be shared. Data could be retrieved from remote systems. Programs could execute locally while relying upon resources provided elsewhere.

The difference can be summarized through four general models:

• Terminal: primarily accesses computing resources located elsewhere.
• Standalone personal computer: primarily uses its own local computing resources.
• Networked workstation: provides substantial local computing resources while also consuming resources and services provided by other systems.
• Server: primarily provides resources and services for use by other computers and users.

The boundaries between these models were not absolute. What mattered was that networking allowed local and shared computing to coexist within the same environment.

These models describe where computing resources are located and how they are used. They do not necessarily describe four different kinds of hardware.

When Workstation Describes Both Machine and Use

Workstations from companies such as Sun, Apollo, DEC, HP, and SGI formed a recognizable market. They often provided hardware and capabilities that distinguished them from ordinary personal computers of the same period, so workstation could legitimately describe a class of computer.

At the same time, the term said something about how the machine was used. A workstation provided an individual computing environment while remaining part of a larger networked system.

As personal-computer hardware became more capable, the distinction became less obvious. PC-compatible machines increasingly performed work that had previously justified specialized workstation hardware. The hardware still mattered, but hardware alone was becoming less useful for determining the machine’s place within the larger system.

Networking Separates the Machine From Its Function

A standalone personal computer primarily provides resources to its local user. Its processor executes that user’s programs, its storage contains the user’s files, and its peripherals exist primarily for that user’s use. The machine can perform many different kinds of work, but its operation remains centered upon the person sitting in front of it.

Networking allows those resources and functions to cross machine boundaries. The physical location of a resource no longer needs to correspond with the physical location of the person using it.

Resources Move Across Machine Boundaries

A file does not necessarily need to reside on the user’s local disk. A printer does not need to be attached directly to the computer sending it a document. Applications and databases can operate on another system. Authentication and other shared functions can be provided centrally.

Functions can be divided among machines:

• one computer can provide shared storage,
• another can provide printing,
• another can host applications or databases,
• while individual computers consume those services and continue performing their own local computation.

The network becomes more than a connection between otherwise independent computers. The machines begin forming a larger computing system in which resources can be provided and consumed across computer boundaries.

Similar Hardware, Different Jobs

A PC-compatible machine might sit on someone’s desk and operate primarily as an individual’s computer. Another machine based upon similar hardware might sit elsewhere and provide files, applications, or other resources to everyone on the network.

The underlying hardware lineage has not necessarily changed. The job assigned to the machine has.

The hardware may remain substantially the same while the machine’s role changes.

The server role discussed in the previous article illustrates the same change from another direction. If server describes a role rather than a fundamental hardware class, knowing the hardware class alone cannot tell us whether a particular machine is acting as a server.

Operational Roles Describe Relationships

Terms such as client, workstation, file server, print server, and database server describe computers according to what they do and how they relate to other computers.

That differs from describing a system as a microcomputer, minicomputer, mainframe, or supercomputer. Those classifications tell us something about the machine itself. Operational roles tell us something about its function within a larger computing environment.

The same computer can be described in both ways. It belongs to a hardware lineage while also performing one or more operational roles.

The Operating System Helps Define the Role

Hardware places limits on what a computer can do, but hardware capability alone does not determine how effectively a machine can perform a particular role. The operating system determines how the processor, memory, storage, processes, users, and network connections are managed. As PC hardware became increasingly capable, the operating environment became an important part of determining how that hardware could be used.

PC operating systems provide a useful example.

DOS and the Standalone Personal Computer

MS-DOS reflected the personal-computer environment from which it emerged. Its operating model assumed one person using one computer, with programs and resources primarily located on that machine.

DOS computers could participate in networks. Network software allowed them to communicate with other systems and access shared resources, and specialized software could make PC hardware provide resources to other machines. Networking itself was not the problem.

DOS had not been designed around the multi-user and multitasking environment traditionally associated with systems providing shared services. A capable PC might possess the processor, memory, storage, and network interface needed for a particular role while its operating environment made that role difficult to implement effectively.

Hardware capability does not guarantee that the operating environment is well suited to every role the hardware could theoretically perform.

Windows Builds on the Personal Computer

The first generations of Microsoft Windows 1.x, 2.x, and 3.x did not replace DOS. They provided a graphical and increasingly capable environment that operated with DOS underneath it. They expanded how the personal computer could be used, but they remained connected to an operating model that originated with the standalone PC.

Windows 95, 98, and Me moved considerably further. Windows increasingly appeared to the user as the operating system itself, while networking, multitasking, hardware support, and resource sharing became normal parts of the environment. These systems could participate effectively in networks and provide some resources to other machines, but they still retained substantial architectural ties to DOS and the earlier Windows lineage.

Windows NT represented a different approach. Rather than continuing the DOS architecture, NT was designed as an independent operating system with preemptive multitasking, protected memory, user accounts, security, networking, background services, and support for workstation and server operation. Its early POSIX subsystem also reflected an effort to support established operating-system standards beyond the DOS and Windows environment.

The distinction became visible even in Microsoft’s product names. Windows NT Workstation and Windows NT Server used closely related operating-system technology on PC-derived hardware while explicitly identifying different intended roles.

Windows NT Workstation and Windows NT Server made the distinction visible in their names: closely related technology could be configured around different operational roles.

UNIX Follows a Different Path

UNIX did not emerge from this development of DOS and Windows. It belonged to the older world of shared computing that we examined earlier in this series.

UNIX developed in the world of shared computing, initially on minicomputer hardware, and spread across larger systems and technical workstations. Multi-user operation, simultaneous processes, permissions, shared resources, and remote access were not additions to a personal-computer model. They were part of an operating tradition that had developed while computing resources were commonly shared among users.

As hardware became smaller, faster, and less expensive, that operating model could move with it. UNIX systems appeared on workstations, BSD-derived systems became available on increasingly accessible hardware, and Linux eventually brought a UNIX-like operating environment directly into the rapidly expanding world of PC-compatible machines.

While Microsoft was developing its own operating-system lineage, UNIX and UNIX-like systems were moving onto increasingly accessible hardware. Different operating traditions could now operate on similar classes of machines.

Microcomputer-derived hardware was moving upward in capability while an operating model developed for shared computing was moving onto smaller and less expensive machines. Networking gave those developments a place to meet.

Why UNIX fit this environment so naturally is a larger question. For now, its movement onto increasingly accessible hardware demonstrates how far the relationship between hardware class and operational function had changed.

Role Becomes Another Layer of Classification

The older computer taxonomy had not disappeared. A mainframe remained different from a PC-compatible computer, and a supercomputer remained different from a workstation. Those classifications continued to describe meaningful architectural and practical differences.

They no longer described the whole system.

Networked computing increasingly required looking at a system in layers. The physical hardware remained one part of the system, while the operating environment determined how that hardware was managed. Above that, applications and services determined what the computer actually provided, while the network defined how those functions became available to other systems. Each layer described something different, but all of them contributed to the behavior of the computer as a whole.

These layers interact. Hardware constrains which operating systems and workloads are practical. The operating system manages capabilities that allow the machine to perform particular roles. Those roles help determine how the computer participates in the network around it.

Hardware describes the machine. The operating environment manages its capabilities. Operational roles describe what it does. Network relationships describe how those functions connect it to other systems.

One Machine Can Perform Multiple Roles

Operational roles do not necessarily correspond one-to-one with physical machines. A computer might provide file storage while also handling authentication, printing, or remote access. Another might function as someone’s workstation while simultaneously making some of its own resources available to other computers.

Calling a machine a server does not necessarily tell us that it performs only one function. It tells us that at least some of its resources or services are being provided for use elsewhere.

The same applies in the other direction. A workstation can consume network services while still providing substantial local computing resources. Client and server describe relationships that can coexist with other descriptions of the same machine.

Different Machines Can Perform Similar Roles

Role does not erase differences between hardware classes. A PC-compatible computer and a mainframe might both provide applications, storage, or other services to users without becoming equivalent systems.

Their architectures, capacities, reliability characteristics, I/O capabilities, and expected scales can remain substantially different. What they share is a function within their respective environments.

Hardware classification and operational role answer different questions. One describes the machine. The other describes what that machine is doing.

Hardware Still Matters

The emergence of operational roles does not make hardware irrelevant. Processor performance, memory capacity, storage, I/O bandwidth, reliability, expandability, and architecture continue to place practical limits on what a system can reasonably accomplish.

A PC providing files to several users does not become equivalent to a mainframe merely because both machines are acting as servers. Likewise, calling two systems workstations does not imply that their capabilities are identical. Operational role describes function, not equivalence.

Hardware tells us what kind of machine we have. The operating environment helps determine what that machine can do. Operational role tells us what it is doing within the larger system.

These descriptions become increasingly useful together because networked computers are no longer understandable solely as isolated physical machines.

Understanding Computers as Parts of Systems

Earlier computer classifications encourage us to begin with the machine. We examine its architecture, resources, scale, and capabilities and use those characteristics to understand what kind of computer it is. That perspective remains useful, but networking requires us to widen the frame.

A networked computer exists in relation to other computers. It may provide resources, consume resources, or do both. Its local hardware matters, but so do its operating system, software, configuration, and connections. Understanding the machine increasingly means understanding its place within the system around it.

We can still ask, What kind of computer is this? But that question is no longer sufficient by itself. We must also ask what the computer does, which resources it provides, which resources it consumes, and how it interacts with the other systems around it.

This is one consequence of the transition from isolated personal computers to networked computing. Mainframes, minicomputers, microcomputers, and supercomputers remain useful classifications, but networking adds another perspective.

The computer is both a machine and a participant in a larger computing system.

Summary

Traditional computer classifications developed because architecture, scale, economics, and expected use were closely related. Mainframes, minicomputers, microcomputers, and supercomputers described more than physical machines; the categories also suggested how those machines would normally be operated and what kinds of work they would perform.

Workstations and networked personal computers began weakening that connection. A computer could possess substantial local resources while also consuming resources from other systems, and increasingly similar hardware could be configured for very different purposes. The machine’s place within the network became another important part of understanding what the computer was doing.

Operational role became an additional way of describing computers rather than a replacement for the older taxonomy. Hardware classification describes characteristics and lineage of the machine, while operational role describes what that machine does within a larger system. The operating system sits between those ideas, helping determine which roles the available hardware can effectively perform.

That relationship brings us to another development in networked computing. If similar hardware can perform very different roles depending partly upon its operating environment, then the design of the operating system becomes increasingly important. UNIX and the systems derived from its model were particularly well suited to this environment, bringing ideas developed for shared multi-user computing into a world increasingly built from networked computers.

Earlier in this series, we looked at mainframes, minicomputers, and microcomputers as distinct approaches to computing. Mainframes provided shared computational resources to large numbers of users, while minicomputers brought many of those capabilities to departments and smaller organizations. The microcomputer changed that arrangement by placing the processor, memory, storage, applications, and peripherals directly in front of an individual user. Computing became increasingly personal and decentralized, but organizations still needed many of the shared resources that mainframes and minicomputers had provided.

Networking gave those functions a way to return on new hardware. Shared files could reside on one computer, printing could be handled by another, and applications or databases could be made available across the network. Instead of concentrating every shared function in one larger computer, a network of microcomputers could divide those responsibilities among several machines. Shared organizational computing was re-emerging, but its functions could now be distributed by role.

This is where the server begins to emerge as a role rather than another class of computer. A machine built from the same basic hardware as the personal computers around it could provide files, applications, databases, or other resources to the network. As those roles became more demanding, the machines performing them would gain more memory, storage, processing power, and eventually hardware designed specifically for reliability and continuous operation. The shared functions once associated with much larger computers had not disappeared. They were beginning to take new forms on descendants of the microcomputer.

The Roles That Never Disappeared

The move toward personal computing changed where computation happened, but it did not eliminate the problems shared computers had been solving. Organizations still needed common data, shared applications, centralized storage, access to expensive peripherals, and ways for multiple users to work with the same resources. Those requirements existed before the microcomputer and continued after computers began appearing on individual desks.

Mainframes and Centralized Resources

Mainframes addressed these needs by concentrating substantial computing resources in a central system shared by many users. Processing, storage, applications, and access to organizational data could all be managed in one place. Administration was concentrated there as well. Users might interact with the computer through terminals, but the important resources remained under the control of the central machine.

Minicomputers Bring the Model Downward

Minicomputers brought a similar model to a smaller scale. A department, laboratory, university group, or smaller organization could operate a shared computer without requiring the scale and expense of a mainframe installation. Multiple users could still share applications, files, processing capacity, and peripherals.

This placed the minicomputer particularly close to territory that network servers would later occupy. The hardware would change considerably, but the need for departmental and organizational resources shared among multiple users would remain.

The Older Systems Did Not Disappear Overnight

The arrival of the microcomputer did not cause organizations to immediately abandon their mainframes and minicomputers. Those systems already held applications and data they depended upon, and they continued to provide capabilities that early personal computers could not easily replace. For many organizations, the first step was connecting the new machines to the larger computers already in use.

A PC could take the place of a dedicated terminal while still accessing applications and data running on a mainframe or minicomputer. Terminal emulation and other connectivity software allowed the personal computer to perform its own local work while providing access to existing shared systems. Mainframes, minicomputers, and PCs could coexist in the same computing environment for years.

I saw this overlap firsthand in 1995, when I worked in a college computer lab. The college had two labs filled with PCs, but in the corner was still a VAX terminal used by the administrators. The PCs had clearly become the everyday computers for the students, but that did not mean every function of the older system had moved with them.

As networking among microcomputers matured, that relationship began to change. Local networks increasingly allowed PCs to share files, printers, applications, and other resources among themselves. Mainframes and minicomputers remained important, but some of the responsibilities that had kept them at the center of organizational computing could now move onto networks of smaller machines.

Mainframes and minicomputers represented recognizable classes of computer, but shared storage, multi-user applications, common data, and centralized administration were functions rather than properties of a particular kind of hardware. Those machines had been the practical way to provide them. As microcomputers and their networks became more capable, the functions could move to new hardware without disappearing.

The Microcomputer Pulls Computing Apart

The microcomputer gave individual users computing resources of their own. Instead of connecting to a larger shared system, a user could have a processor, memory, storage, applications, display, keyboard, and peripherals sitting on a desk. As these machines became more capable, more work could be performed locally without depending on a central computer.

Computing Becomes Personal

This independence was one of the great strengths of personal computing. A program running slowly or failing on one computer did not necessarily affect everyone else. Users could install different software, store their own files, and configure the machine for their own needs. Organizations could also add computers incrementally rather than concentrating all of their computing capacity in a single large system.

For the individual user, this represented a significant change. Processing and storage were no longer resources that had to be requested from a shared system. Much of the computing environment was sitting on the desk and belonged, at least operationally, to the person using it.

Independence Creates New Problems

Putting those resources on individual desks also scattered things that had previously been kept together. As personal computers spread through an organization:

• files could become scattered across many hard drives;
• printers and other peripherals could be attached to individual computers even when several people needed them;
• applications might have to be installed and maintained separately on many machines; and
• transferring information between computers could mean carrying it on floppy disks.

These were consequences of distributing resources that had previously been concentrated within shared systems. Personal computing provided independence, but that independence came with a new kind of isolation.

Local networks provided a way around some of that isolation. Once the machines were connected, resources distributed onto individual desks could begin to be shared again. The microcomputer had pulled computing apart; the network provided a way to put some of those pieces back together without giving up the individual computers themselves.

The Network Puts the Pieces Back Together

Once microcomputers were connected, a resource no longer had to reside on the computer that used it. Files stored on one machine could be accessed from another. A printer connected to one system could serve users throughout an office. Applications, databases, and other resources could likewise be placed on a machine where multiple users could reach them across the network.

This brought shared computing back into an environment built around personal computers. Mainframes and minicomputers had generally concentrated many shared functions within the same computer. A network of microcomputers allowed those functions to be separated.

Sharing Resources Across the Network

As shared resources moved onto networked computers, several recognizable server roles began to emerge:

• File server
• Print server
• Database server
• Application server
• Authentication server

A file server provided a common place to store files that could be accessed from other computers on the network. Instead of documents and other data existing only on individual hard drives, users could work with shared storage available to everyone who had permission to use it.

A print server managed access to one or more printers. This allowed a printer to be shared among many computers while print jobs could be queued and managed in one place.

A database server provided access to common data. Rather than maintaining separate copies on individual computers, applications and users could work with information stored and managed by a shared database system.

An application server moved some of the application workload away from the individual PC. Depending on the software, the server could provide an application itself, perform processing on behalf of clients, or provide services used by applications running on other computers.

An authentication server provided a common place to manage identities and access. Instead of every computer maintaining completely independent user accounts, authentication could become another shared network service.

These roles did not necessarily require five separate computers. A single machine could provide several services, particularly on a smaller network. The functions themselves no longer had to reside together.

Centralizing Functions Without Centralizing Everything

Users retained the processors, memory, applications, and storage available on their own computers while gaining access to resources provided elsewhere on the network. Local and shared computing could coexist.

This allowed organizations to centralize particular resources without centralizing the entire computing environment. Files might reside on a shared machine while processing remained on individual PCs. A database could be available throughout an organization without requiring every application to run on the same computer. Resources could be placed where sharing made sense while other work remained on the user’s machine.

As these shared resources became more important, particular machines could be given particular responsibilities. Instead of a user’s computer merely sharing a directory or printer when needed, an organization could dedicate a machine to providing that resource. Functions once concentrated within larger shared computers were becoming distinct roles distributed across the network.

The Server Becomes a Role

Once resources could be provided across the network, the distinction between a personal computer and a server was not necessarily a distinction between fundamentally different kinds of hardware. A server was defined primarily by what it provided to other systems.

A computer storing files for other machines was acting as a file server. The same computer might also manage printers or authenticate users. Another machine might request files from that server while providing a different service of its own.

Server and Client Describe What a Computer Is Doing

Server and client described roles rather than permanent categories. A computer could act as a client when requesting a resource from another system and as a server when providing a resource to others. A single computer could also perform several server roles at the same time.

This differed from the older mainframe, minicomputer, and microcomputer taxonomy. Those terms described recognizable classes of computer with meaningful differences in scale, construction, cost, and typical use. Calling a computer a server described what that computer was doing within the network.

The Hardware Could Still Be a PC

Early network servers could have a great deal in common with the personal computers around them. They used the same families of processors, memory, storage devices, expansion buses, network adapters, and other components found throughout the growing PC ecosystem.

A machine did not need to belong to a new hardware class before it could become a server. It might simply have a larger hard drive, more memory, a network adapter, and software configured to provide resources to other computers.

I’ve practiced system administration on plenty of “servers” built from discarded PCs over the years. They did not have redundant power supplies, error-correcting memory, hot-swappable drives, or many of the other features associated with dedicated server hardware. Once configured to provide files, web pages, or other network services to other computers, they were servers because of the role they performed.

The distinction was operational before it was necessarily physical.

An ordinary PC could therefore be a perfectly legitimate server. As more users began depending on a particular machine, there were increasingly good reasons to dedicate that computer to the role.

From Shared Role to Dedicated Machine

A computer did not have to be dedicated exclusively to a server role. A workstation could share files or a printer while still being used by the person sitting in front of it, and one machine could provide several services at the same time. For a small network, that might be entirely sufficient.

The situation changed as more people began depending on those services. A shared directory used occasionally by two or three people placed very different demands on a computer than storage used throughout an organization. The consequences of that computer being unavailable also became greater.

When a Shared PC Is No Longer Enough

Using someone’s workstation to provide a network service introduced some obvious problems. If the computer was turned off, the service disappeared with it. Maintenance, software problems, or hardware failures could affect everyone depending on the resource rather than only the person using the computer.

Server workloads could also compete with the person sitting at the machine for:

• processor time;
• memory;
• disk access; and
• network bandwidth.

At some point, dedicating a computer to the service became more practical than asking one machine to serve both as someone’s personal computer and as an important shared resource.

Giving Machines Specific Jobs

A machine could become the file server, while another became the database server or the mail server. Smaller networks might continue combining several roles on one computer, while larger environments could separate them as workloads and requirements increased.

An organization could centralize its files on one machine and its database on another while users continued running applications and performing much of their processing on individual PCs. Shared computing no longer required concentrating everything in one place.

The network was becoming a distributed environment assembled from computers with different responsibilities. Administrators could decide which machines should provide particular services rather than expecting one class of computer to provide all of an organization’s shared computing.

Once a computer supported many users or an important service, those responsibilities began influencing more than its configuration. Performance, capacity, reliability, and availability would increasingly shape the hardware itself.

The Role Begins to Change the Hardware

An ordinary PC could perform a server role, but a machine supporting many users faced different demands from one sitting on an individual desk. More users meant more simultaneous requests for files, applications, or data. Some workloads placed heavy demands on storage and networking, while others needed substantially more memory or processing power.

As those demands increased, the hardware began to change with them.

Capacity and Performance

Different server roles placed pressure on different parts of the system. A file server benefited from fast storage and greater disk capacity. A database server might need considerably more memory and processing power. A heavily used network service could require faster network interfaces and greater I/O capacity.

As workloads increased, servers could be equipped with:

• more memory;
• larger and faster storage;
• greater I/O capacity;
• faster network interfaces; and
• additional processing capacity.

A server could become considerably more powerful than the computers it served while still using processors, memory, storage, and expansion technologies from the same general hardware families. The PC hardware model provided plenty of room to grow before a server needed to look substantially different from the machines around it.

Reliability and Availability

Capacity and performance were not the only concerns. Once people depended on a server, keeping it running became increasingly important.

A failed desktop computer might interrupt one person’s work. A failed file server could prevent an entire department from reaching its files. Hardware features that prevented failures or reduced their consequences became more valuable as the number of people depending on the machine increased.

Server systems increasingly incorporated features such as:

• error-correcting memory;
• redundant disk arrays;
• redundant power supplies;
• improved cooling;
• hot-swappable drives; and
• components intended for continuous operation.

Some of these features helped keep a hardware failure from bringing down the entire system. Others made failed components easier to replace with less disruption to the people depending on the server.

Server Hardware Becomes Recognizable

Manufacturers eventually produced systems specifically designed for server workloads. Larger memory capacities, multiple processors, rackmount cases, remote-management hardware, redundant components, and greater expansion capabilities made these machines visibly different from the PCs sitting on users’ desks.

The relationship still worked in both directions. I once bought an old Pentium III-based server from my college. Later, when my PC died, I installed a desktop environment on the server and used it to do my homework. It had been built and sold as a server, but underneath the features intended for that role was still a computer closely related to the PCs of the same era.

By this point, it was easy to look at specialized server hardware and think of it as a different class of computer. In practical terms, it certainly was built for a different workload. The difference was not as fundamental as the older divisions between mainframes, minicomputers, and microcomputers.

Server hardware had become specialized because its role demanded greater capacity, reliability, and availability. Change the role, and even a purpose-built server could sometimes become a rather unusual desktop PC.

Old Functions on New Hardware

The rise of the microcomputer did more than move computing onto smaller hardware. It separated functions that mainframes and minicomputers had often provided together. Processing moved onto individual PCs. Files moved onto local disks. Applications ran on individual machines, and peripherals could belong to individual users.

LANs allowed those functions to be reorganized. Some remained on the personal computer, while others became shared resources provided across the network:

• processing could remain on individual PCs;
• files could move onto file servers;
• applications could be divided between clients and servers;
• databases could become shared network resources;
• printers could be managed centrally; and
• user accounts and authentication could be shared across many systems.

The functions were familiar, but their organization had changed. They could now be separated and recombined according to the needs of the network rather than being tied together by the class of computer providing them.

Minicomputer Functions Become Server Roles

The correspondence with the minicomputer was particularly easy to see. A minicomputer could provide a department, laboratory, university group, or smaller organization with shared storage, applications, databases, user accounts, peripherals, and processing resources.

A network of PCs and servers could provide many of those same functions, but they no longer had to reside on the same machine. Files might reside on one server, a database on another, and authentication on a third. Smaller organizations could combine several roles on one machine, while larger environments could separate them as workloads increased.

The users’ computers were different as well. Instead of terminals depending on the minicomputer for most of their computation, PCs could perform substantial amounts of work locally and reach across the network when they needed a shared resource.

This makes the minicomputer an especially useful comparison for the dedicated server. Both could provide shared resources to a group of users, but the server existed within an environment where many other functions had already moved elsewhere. What had once been bundled together in the departmental computer could now become several distinct server roles.

Mainframe Functions Become Distributed Services

The same reorganization happened at a larger scale with functions associated with mainframes. Organizational databases, applications, storage, authentication, processing, and other shared resources no longer had to reside within one central computer. Some could move onto separate servers, some could remain on a mainframe, and still others could move onto users’ PCs.

A collection of PC-derived servers was not automatically equivalent to a mainframe. Mainframes continued to serve workloads where their reliability, I/O capabilities, capacity, and architecture remained valuable. The change was that large-scale shared computing no longer required every function to reside within a computer belonging to a particular hardware class.

This also helps explain why the transition was gradual. Organizations could move individual functions without replacing their entire computing environment at once. An established application might remain on a mainframe while file storage moved elsewhere. A minicomputer might continue supporting another application while PCs handled everyday work. New server roles could be added as the need arose.

The mixture of mainframes, minicomputers, PCs, and servers was therefore more than an intermediate stage between generations of hardware. It allowed individual computing functions to migrate at different times.

The Functions Survive the Hardware Classes

By this point, the functions that had once helped define different classes of computer were becoming less closely tied to the hardware that provided them.

Shared storage could come from a server built on PC-derived hardware. Applications and databases could move to their own systems. Processing could remain on individual PCs or be performed elsewhere on the network. Mainframes and minicomputers could continue operating where their particular capabilities were still needed.

The functions survived even as their connection to particular classes of computer began to weaken.

For the network administrator, the practical question was increasingly not what historical class a computer belonged to, but what role it needed to perform.

Summary

The microcomputer changed computing by moving processing, storage, applications, and peripherals away from shared mainframe and minicomputer systems and onto individual machines. The need for shared resources remained. Older systems continued operating alongside PCs, and as networking matured, many of the functions they had provided could move onto microcomputer-derived hardware.

LANs allowed functions once bundled together inside mainframes and minicomputers to become separate network roles. Files could reside on one server, databases on another, and authentication somewhere else, while users continued performing much of their work on their own PCs. Shared computing had returned in a form that could coexist with personal computing.

A server therefore emerged primarily as a role rather than a new class of computer. At first, the hardware performing that role might differ very little from an ordinary PC. As more people and more important services depended on it, the demands of the role encouraged dedicated machines and eventually specialized server hardware designed for greater capacity, reliability, and availability.

The shared functions of the mainframe and minicomputer had survived the transition to personal computing. They had moved among different machines and been reorganized through the network. That leaves an important question for the old mainframe, minicomputer, microcomputer, and supercomputer taxonomy we have used throughout this series: what happens when the functions that once helped define those classes are no longer tied to the hardware that originally provided them?

As personal computers became more common, users naturally began looking for ways to communicate with one another. Bulletin board systems and, later, dial-up Internet services demonstrated that computers no longer had to remain completely isolated. A modem allowed two computers to establish a temporary connection, exchange information, and disconnect when the session was complete. For the first time, computing extended beyond the boundaries of a single machine.

The history of personal computer networking is the story of increasing connectivity—from isolated systems, to temporary communication, and finally to persistent networks.

Temporary communication, however, was only the beginning. If computers could exchange information for a few minutes over a telephone line, what would happen if they remained connected all the time? That question changed personal computing. Instead of treating communication as an occasional event, computers could begin sharing files, printers, storage, and eventually Internet access through persistent local connections.

This week we’ll examine how computing evolved from isolated systems, to temporary point-to-point communication, and finally to persistent networking. Along the way, we’ll explore the competing networking hardware, communication protocols, and operating systems that shaped this transition, why organizations invested in local area networks, how networking eventually entered our homes, and why Ethernet and the TCP/IP protocol suite became the common foundation that modern networks still rely upon today.

From Isolation to Temporary Connectivity

For the first decade of the personal computer revolution, most computers existed in isolation. Programs were loaded from floppy disks, files were stored on local media, and printers connected directly to the computer sitting on the desk. Although multiple people might own the same model of computer, each machine functioned as an independent system with little awareness that other computers even existed.

The introduction of affordable modems began changing that model. By converting digital data into audio signals that could travel across the public telephone network, two computers could exchange information without occupying the same physical location. Bulletin board systems became one of the earliest practical demonstrations of this capability, allowing users to download software, leave messages, participate in discussions, and upload files from their own homes. Later, dial-up Internet service expanded those possibilities even further, connecting personal computers to a growing collection of online resources and services.

Despite these advances, communication remained temporary. A computer established a connection with another system, exchanged information, and disconnected when the session ended. Each connection served a specific purpose, whether retrieving a file, reading messages, or accessing a remote system. Once the telephone call ended, both computers returned to operating independently. Networking had introduced communication, but it had not yet transformed the computer into part of a larger, continuously connected environment.

Temporary communication proved that computers no longer had to remain isolated. The next question was whether they needed to disconnect at all.

Even so, these temporary connections represented an important conceptual shift. Personal computers were no longer confined to the software and information stored locally. Data could move between machines, users could interact across distance, and computing itself began extending beyond the boundaries of a single system. The isolated personal computer had taken its first step toward becoming part of a network.

The next logical question was difficult to ignore. If temporarily connecting two computers could make both of them more useful, what might become possible if computers remained connected all the time? That question would drive the development of local area networks and change how personal computers were deployed in businesses, schools, and eventually homes.

From Temporary Connections to Permanent Networks

Temporary communication demonstrated that computers could exchange information, but it also revealed the limitations of point-to-point connections. Every session required establishing a connection, completing a specific task, and disconnecting when finished. While this model worked well for bulletin board systems, terminal sessions, and early Internet access, it was not an efficient way for multiple computers within the same organization to communicate throughout the day.

A local area network (LAN) introduced a different model. Rather than connecting only when information needed to be exchanged, computers remained connected continuously. Communication was no longer a separate activity—it became part of the normal operation of every computer on the network. Files, printers, and other shared resources could be accessed whenever they were needed, without placing a telephone call or manually transferring disks between systems.

A local area network didn’t simply connect computers. It changed communication from an occasional event into a permanent part of everyday computing.

This persistent connectivity also changed how computers related to one another. A personal computer was no longer simply a standalone machine that occasionally communicated with another system. It became one participant in a larger environment where multiple computers could exchange information, share resources, and cooperate as part of the same network. While each computer continued running its own operating system and applications, it no longer existed in complete isolation.

The transition from temporary communication to persistent networking changed how organizations thought about computing. Instead of purchasing duplicate hardware and maintaining separate collections of files on every workstation, they could share resources across an entire office or campus. Computers were beginning to work together rather than merely communicate with one another.

Once organizations recognized these advantages, local area networks spread rapidly through businesses, schools, and universities. Building those networks, however, was far from straightforward. During the 1980s and early 1990s, there was no universally accepted way to connect computers. Different hardware technologies, communication protocols, and network operating systems all competed to become the standard, creating a diverse and often incompatible networking landscape.

Why Organizations Built Networks

The earliest local area networks were not built because networking was an exciting new technology. Organizations invested in networks because they solved practical business problems. As personal computers became more common in offices, schools, and universities, administrators quickly discovered that managing dozens or even hundreds of completely independent systems was both expensive and inefficient.

Sharing Expensive Hardware

One of the earliest advantages was printer sharing. High-quality laser printers represented a significant investment, often costing far more than an individual workstation. Rather than purchasing a printer for every employee, a single network printer could serve an entire department. This reduced hardware costs while making higher-quality printing available to everyone connected to the network.

Sharing Information

File sharing provided an equally important benefit. Before networking became commonplace, users often exchanged files by copying them to floppy disks and physically carrying them between computers, a practice that eventually became known as sneakernet. Local area networks allowed documents, spreadsheets, and other files to be stored in shared locations where multiple users could access the same information without constantly copying disks from one workstation to another. Collaboration became easier because everyone worked from the same collection of files.

Networking succeeded because it solved practical problems and saved money.

Simplifying Administration

Networks also simplified many routine administrative tasks, including:

• Software deployment
• Centralized backups
• User account management

Instead of maintaining every computer independently, administrators could perform many of these tasks from a central location. As networks grew larger, these operational advantages often became just as valuable as the hardware savings.

By the late 1980s, the advantages of local area networking were becoming difficult to ignore. The challenge was no longer deciding whether computers should be connected, but determining how those connections should be built. A growing number of hardware technologies, communication protocols, and network operating systems competed for adoption, each offering a different solution to the same fundamental problem.

Building a Local Area Network

Once an organization decided to build a local area network, the next challenge was determining how to connect its computers. Today, Ethernet is so common that it is easy to assume networking has always worked the same way. During the 1980s and early 1990s, however, there was no universally accepted approach. Organizations could choose from a variety of competing hardware technologies, each with its own advantages, limitations, and target market.

Physical Network Technologies

Early local area networks used a surprising variety of physical media and network designs. Organizations could choose from technologies such as:

• Serial connections
• Parallel connections
• ARCnet
• Ethernet
• IBM Token Ring
• Apple LocalTalk

Each represented a different philosophy of network design, balancing factors such as cost, performance, reliability, ease of installation, and compatibility with existing systems. The diversity of available options reflected an industry that was still exploring the best way to build a local area network.

During the 1980s, there was no single “correct” way to build a local area network. Every major computing ecosystem had its own approach.

Communication Protocols

Choosing the physical network was only part of the decision. Computers also needed a common language for exchanging information. Each protocol reflected the priorities of the ecosystem that developed it.

• NetBEUI — A simple protocol for small Microsoft Windows local area networks.
• IPX/SPX — Closely associated with Novell NetWare, widely deployed in businesses, and familiar to many home users through multiplayer DOS games.
• AppleTalk — Designed to provide seamless networking for Apple Macintosh systems.
• TCP/IP — Gradually expanded beyond its research and UNIX roots, increasingly connecting different types of computers and networks before eventually becoming the common protocol suite across diverse systems.

Networking Ecosystems

Hardware, communication protocols, and operating systems often evolved together. Choosing a networking solution frequently meant choosing an entire networking ecosystem rather than a single technology. Common ecosystems included:

• Novell NetWare with IPX/SPX
• Apple Macintosh with AppleTalk
• Microsoft Windows with its own networking technologies
• UNIX systems with TCP/IP

Although many of these systems eventually learned to communicate with one another, interoperability was often far more difficult than users expect today.

This diversity encouraged innovation, but it also created fragmentation. As organizations exchanged more information and the Internet continued to grow, the advantages of common standards became increasingly apparent. Over time, Ethernet emerged as the dominant physical networking technology, while the TCP/IP protocol suite became the common language that allowed computers from different manufacturers and operating systems to communicate across the same network.

Why Ethernet and TCP/IP Became the Standards

Competition encouraged rapid innovation throughout the early years of local area networking, but it also created significant complexity. Organizations purchasing networking equipment often committed to an entire ecosystem that included specific network hardware, communication protocols, and network operating systems. As long as computers remained within a single environment, these solutions worked well. The challenge arose when businesses wanted to connect different systems together or exchange information with organizations using different technologies.

Ethernet gradually emerged as the preferred physical networking technology because it combined flexibility with broad industry support. Rather than remaining closely tied to a single manufacturer or operating system, Ethernet evolved as an open standard that hardware vendors across the industry could adopt. As Ethernet equipment became faster, less expensive, and easier to deploy, many organizations concluded that the advantages of a common networking standard outweighed the benefits of competing proprietary solutions.

Open standards allowed computers from different manufacturers and operating systems to communicate more easily, reducing the fragmentation that had defined early networking.

A similar transition occurred with communication protocols. While NetBEUI, IPX/SPX, AppleTalk, and other protocol families continued serving their respective environments, TCP/IP offered a broader vision. Designed to interconnect different types of networks rather than operate within a single proprietary ecosystem, TCP/IP made communication between diverse computer systems far more practical. As universities, businesses, government agencies, and eventually the public Internet expanded, the value of a common protocol suite became increasingly difficult to ignore.

It is also worth remembering that TCP/IP is not a single protocol but a family of related protocols, each designed for a specific purpose. The Transmission Control Protocol (TCP) provides reliable, ordered communication for applications where accuracy is essential, while the User Datagram Protocol (UDP) favors lower overhead and reduced latency for applications that benefit from faster, connectionless communication. Together with the Internet Protocol (IP) and other supporting protocols, they formed a flexible foundation capable of supporting a wide variety of network applications.

By the late 1990s, Ethernet and the TCP/IP protocol suite had become the common language of local area networking. Organizations no longer needed to choose entirely separate networking ecosystems based on their operating systems or hardware vendors. Computers running different operating systems could increasingly communicate across the same physical network using the same protocol suite. The fragmented networking landscape of the previous decade had largely converged into the interoperable foundation that still underpins modern networks today.

Why Networks Came Home

For many years, local area networks remained primarily a business technology. Organizations justified the cost by sharing printers, files, software, and other expensive resources across dozens or even hundreds of computers. Schools and universities also embraced networking, giving many students their first experience with computers that could communicate continuously rather than operating in isolation.

Learning Networking Outside the Home

As networking became more common in professional and educational environments, enthusiasts began recreating those experiences at home. One of the most visible examples was the rise of the LAN party, where friends physically connected their computers to play multiplayer games, exchange files, and explore the capabilities of local networking. Although these gatherings were often centered around entertainment, they introduced an entire generation of computer enthusiasts to network adapters, cables, communication protocols, and the practical challenges of building and troubleshooting a local area network.

Broadband Internet didn’t invent the home network. It gave ordinary households a compelling reason to build one.

Broadband Changes the Equation

Even so, home networks remained relatively uncommon throughout the era of dial-up Internet. Dial-up connections established a temporary link between one computer and one remote system, whether a bulletin board system, an online service, or an Internet service provider. While a home network could certainly be built during this period, most households had little practical reason to do so because only one computer could actively use the telephone line at a time.

Broadband Internet fundamentally changed that equation. Cable, DSL, and later fiber connections remained available continuously, allowing multiple computers to share a single Internet connection without interrupting telephone service. The question was no longer, “How do I connect this computer to another computer?” Instead, it became, “How do I connect every computer in my home to the Internet?” The local area network, once primarily a business tool, became an increasingly common feature of everyday households.

The Connected Home

Over time, home networking expanded well beyond desktop computers. As networks became part of everyday life, an increasing variety of devices joined the home network, including:

• Laptops
• Game consoles
• Network printers
• Smartphones
• Tablets
• Smart televisions
• Network-attached storage (NAS)
• Countless other connected devices

What began as a way for organizations to share expensive resources gradually evolved into the connected home environment that many people now take for granted.

Summary

The history of personal computer networking is the story of increasing connectivity. Early personal computers operated almost entirely in isolation, with programs, files, and peripherals belonging to a single machine. Modems introduced the ability to communicate across telephone lines, allowing temporary point-to-point connections that demonstrated computers no longer had to remain completely independent. Local area networks took the next logical step by making those connections persistent, transforming communication from an occasional activity into part of the normal operation of everyday computing.

Networking did more than connect computers. It transformed isolated machines into participants within larger computing environments.

As organizations recognized the advantages of shared printers, centralized files, and collaborative computing, local area networks spread rapidly through businesses, schools, and universities. During those early years, however, networking was far from standardized. Competing hardware technologies, communication protocols, and network operating systems reflected an industry still searching for the best approach. Over time, Ethernet and the TCP/IP protocol suite emerged as the common foundation that allowed computers from different manufacturers and operating systems to communicate more easily.

Standardization also made networking accessible beyond the workplace. Home enthusiasts experimented with local area networks through multiplayer gaming and file sharing, while broadband Internet gave ordinary households a compelling reason to connect multiple computers to the same network. What had once been specialized business infrastructure gradually became an expected part of everyday life, eventually expanding beyond desktop computers to include countless connected devices throughout the home.

The transition from isolated computers to persistent networks changed the environment in which personal computers operated. Networking became an essential part of modern computing, providing a common foundation upon which increasingly sophisticated systems could be built. In the next article, we’ll examine how this shared networking foundation changed the role of individual computers, allowing them to become specialized participants within larger computing environments.