In the previous article, we followed Berkeley UNIX from its origins at the University of California, Berkeley into the modern BSD family. FreeBSD, NetBSD, OpenBSD, and the other BSD systems remain connected to historical UNIX through a real line of descent. The source has changed enormously, but the family tree leads backward toward UNIX.

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.