The previous lesson made it clear that Linux is a kernel and that the complete box is a distribution. Now it is time to answer a question that looks like general knowledge but is deeply practical: why is Linux the way it is?

When, a few modules from now, you type something like cat access.log | grep ERROR | sort | uniq -c, you will be using a language designed in 1969 in a laboratory in New Jersey. When you wonder why a server's configuration consists of text files rather than a binary registry, the answer lies in that same decade. And when it surprises you that a command that works prints absolutely nothing, that too.

This lesson is not historical decoration: it is the explanation of the design. You are going to see where Unix comes from, what its principles are, how the GNU project and a Finnish student's kernel met by chance in 1991, and how the kernel that runs on srv-tramontana is developed today.

1. Why history matters for understanding today's design
2. Unix at Bell Labs (1969)
3. The Unix philosophy and its principles
4. The fragmentation of Unix and the POSIX standard
5. The GNU project (1983) and the missing piece
6. Linus Torvalds and the 1991 announcement
7. Why people say "GNU/Linux"
8. Timeline: from 1991 to the cloud
9. How the kernel is developed today

An operating system is not a neutral product: it is the crystallisation of the decisions made by the people who built it, under the conditions in which they built it. Unix was born on a computer with 8 KB of memory that had to be shared between several simultaneous users. That brutal scarcity imposed a style: no giant programs, no decorative interfaces, no wasting a single byte.

Three traits you will see every day in Linux are explained only in this way:

That last point is the most important of the three. The fact that /etc/tramontana/app.conf is plain text and not a proprietary binary is what will let you search it with grep, version it with Git, generate it from a script and deploy it with Ansible to 200 machines. The whole of Module 3 and Module 4 of this course exists thanks to that decision taken in 1970.

In the late sixties, AT&T's Bell Labs was taking part, alongside MIT and General Electric, in Multics, an ambitious operating system meant to supply computing service the way you supply electricity. Multics had brilliant ideas, but it grew enormous and slow. In 1969 Bell Labs pulled out of the project.

Two of its engineers, Ken Thompson and Dennis Ritchie, were left with the frustration and with the ideas. Thompson found a disused PDP-7 and in a few weeks wrote a minimal system so he could carry on playing Space Travel, a space simulation program. That system had a hierarchical file system, processes and a command interpreter. Brian Kernighan christened it UNICS (half in jest, as a "castrated Multics"), and it ended up as Unix.

The milestones that changed everything:

• 1969: the first Unix on the PDP-7, written in assembly.
• 1971: the first documented edition; the manual pages (man) appear, and you will still be using them in lesson 02-02.
• 1972: Dennis Ritchie creates the C language.
• 1973: Unix is rewritten in C. This is the decisive moment.

Rewriting an operating system in a high-level language was almost heresy: it cost performance. But it gained something far more valuable: portability. Until then every operating system was tied to one computer model; from that point on, Unix could be moved to another machine by recompiling it. That is the ultimate reason why the same Linux today runs on your laptop, on a server, on a phone and on a supercomputer.

And there was a fortunate accident: AT&T was a regulated telephone monopoly and was forbidden to sell software commercially. So it distributed Unix to universities for a nominal fee, with the source code. Whole generations of students learned operating systems by reading, modifying and improving Unix. Out of that came, among other things, the BSD branch from the University of California at Berkeley, a direct ancestor of today's macOS.

This section is the most important of the lesson. The principles that follow are not history: they are the style guide in which everything you are going to learn is written.

Doug McIlroy, head of the department where Unix was born, summed it up like this:

"Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface."

Let us break down the operating principles.

In Linux there is no big "log manager" program. There is cat (display), grep (filter), sort (order), uniq (count repeats), cut (extract columns), wc (count). Each one does a single task and does it well.

The advantage: learning 30 small tools gives you thousands of useful combinations, whereas learning a monolithic program gives you exactly what its author foresaw.

A document is a file. A directory is a file. Your hard disk is a file (/dev/sda). Your terminal is a file. The processor's information is a file (/proc/cpuinfo). A network socket is a file.

Why is this so powerful? Because with one single set of operations (open, read, write, close) you manipulate radically different things, and therefore the same tools work for everything. You will see this in detail in lesson 01-06.

A pipe (the | character) connects the output of one program to the input of the next. It was McIlroy's idea, implemented by Thompson in 1973, and it is probably the best idea in the history of operating systems.

Look at this example with Tramontana's data. Suppose the file /var/log/tramontana/access.log:

Output:

What happened, piece by piece:

• cat /var/log/tramontana/access.log dumps the contents of the file to its output.
• The | character connects that output to the input of the next program. Nothing is saved to disk: the data flows in memory.
• grep ERROR lets through only the lines that contain the text ERROR.
• wc -l counts lines (word count, lines option).
• Result: 17 errors in the access log.

None of the three programs knows the others exist. None of them was written with Tramontana in mind. And yet together they solve a concrete problem. That is composability, and it is why a Linux administrator can answer in 10 seconds questions that on other systems require writing a program.

Do not worry if you have not mastered the syntax right now: pipes are the heart of Module 3. Here you only need to grasp the idea.

If every program speaks plain text line by line, anything can connect to anything. A binary format, however efficient, breaks that chain.

A Unix command that works correctly says nothing. It only speaks when there is a problem. This is disconcerting at first ("did it do it or not?") and later much appreciated: in a script that processes 5,000 files, you do not want 5,000 confirmation messages.

The system gives you tools and does not impose how to use them. There is no "right way" to organise your scripts. That freedom is powerful and also dangerous: the discipline has to come from you.

In 1984, the break-up of AT&T's monopoly finally allowed it to sell Unix commercially. The code stopped circulating freely and each manufacturer developed its own commercial version, incompatible with the rest:

This became known as the Unix wars. A program written for Solaris would not compile on AIX without adjustments. Customers were locked in with their manufacturer. The fragmentation weakened Unix exactly when Windows NT was starting to eat into the corporate market.

The response was POSIX (Portable Operating System Interface), an IEEE standard published from 1988 onwards that defines a common minimum: which system calls must exist, which commands, what shell behaviour, which signals. If you write your software respecting POSIX, it will work on any conformant system.

Linux is not formally certified as POSIX (certification costs money and nobody has found it worth the while), but it is broadly conformant in practice. This has a very concrete consequence for you: when in Module 4 you write scripts that respect POSIX, they will work the same on Ubuntu, on Rocky Linux, on Alpine inside a container and on macOS. It is a transferable skill, not product knowledge.

And a strategic lesson that explains the present: the GPL prevented Linux from suffering what happened to Unix. Since any distributed modification has to be published, there was no way to create a closed, incompatible "IBM Linux". The licence was the glue that held the ecosystem together.

Richard Stallman worked at MIT's artificial intelligence laboratory, in a culture where code was simply shared. In the early eighties that culture collapsed: programs began to be distributed in binary only and under confidentiality agreements. The founding anecdote is famous: Stallman wanted to fix the driver of a Xerox printer that kept jamming jobs, and was refused the source code.

In September 1983 he announced the GNU Project, a recursive acronym for GNU's Not Unix: to build a complete operating system, compatible with Unix, but entirely free. In 1985 he founded the Free Software Foundation and in 1989 he wrote the GPL.

Over the following years, the GNU project produced an arsenal of first-rate software, most of which you still use today without realising it:

By 1991 GNU had practically the whole operating system... except the kernel. Its kernel, GNU Hurd, was betting on a microkernel architecture, technically elegant but fiendishly hard to stabilise. It was years behind schedule. Hurd still exists today and is still not in general use.

There was a complete free operating system waiting for a kernel.

In Helsinki, a 21-year-old student called Linus Torvalds was studying operating systems with Minix, a small teaching Unix written by professor Andrew Tanenbaum. Minix came with available code, but its licence was restrictive and its author deliberately kept it simple so that it stayed teachable.

Torvalds, frustrated by those limitations and with a newly bought 386 PC, started writing his own kernel. On 25 August 1991 he posted to the comp.os.minix newsgroup a message that is now history:

"I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones. [...] I'd like to know what features most people would want."

Two observations about that text, because they teach more than any moral:

• The modesty was sincere and it was wrong. "Just a hobby, won't be big and professional" describes the kernel that today powers most of the internet.
• The closing question is the key to the success. "I'd like to know what features most people would want" was not rhetorical. Torvalds published versions every few days and merged patches from strangers. That model — release early, release often, integrate contributions — was as innovative as the code itself.

In September 1991 version 0.01 appeared: some 10,000 lines, unable to boot on its own. In January 1992, with version 0.12, Torvalds took the most far-reaching decision of all: changing the licence to the GPL. The original licence he had written forbade commercial sale, which would have held back its adoption. Years later he himself described it as "the best thing I ever did".

The fit was immediate. Torvalds's kernel needed user-space tools; GNU had them all. GNU needed a kernel; here was one that worked. The combination Linux kernel + GNU userland was, overnight, a complete and usable free operating system. Version 1.0 arrived in March 1994, with 176,000 lines of code and network support.

Stallman and the FSF argue that calling the complete system "Linux" is unfair: the kernel is an important part, but the compiler, the shell, the libraries and most of the utilities came out of the GNU project, which had been working towards that explicit goal for eight years. Their proposal is GNU/Linux.

Torvalds and a good part of the community prefer the short form for convenience. The argument has been going for thirty years and is not going to be settled.

A practical stance for your professional life:

• Both names are correct and everybody understands them.
• In everyday use and in this course we will say Linux, for brevity.
• Debian and some distributions officially use GNU/Linux.
• What is a genuine technical error is believing that the kernel is the system. That part of Stallman's claim is simply true, and you have had it clear since the previous lesson.

An interesting nuance: today there are Linux systems without GNU. Android uses the Linux kernel with the Bionic library; Alpine Linux (the base of most containers, which you will see in Module 7) uses musl and BusyBox instead of glibc and coreutils. In those cases "GNU/Linux" would be plainly incorrect.

Three moments on that line are worth pausing over:

• 1993-1994, the distributions. The kernel alone was unmanageable for most people. Slackware and Debian first, and Red Hat afterwards, solved the problem of assembling and installing the whole set. That is when Linux stops being a project and starts being a product.

• 1998-2004, entering the enterprise. IBM invested a billion dollars in Linux in 2001. The big software vendors ported their products. Linux went from "student toy" to a platform with commercial support. In parallel, Google built its infrastructure on Linux from the very beginning.

• 2013 onwards, the cloud and containers. The kernel features that make containers possible (namespaces and cgroups, which you will see in Module 7) had been there for years. Docker packaged them in a usable form in 2013 and changed the industry. Today there is no cloud without Linux, and the symbolic finishing touch came in 2018 with Microsoft — the same company that in 2001 called Linux "a cancer" — shipping a Linux kernel inside Windows.

And one final fact that closes the circle: in 2001 Microsoft was the great adversary; today it is one of the largest corporate contributors to the Linux kernel and the owner of GitHub, where a good part of the world's free software lives.

Understanding the process helps you know which kernel version you have on srv-tramontana and what you can expect from it.

Linux has followed a predictable rhythm for more than a decade:

1. Merge window (2 weeks). Torvalds accepts all the new features the maintainers send him. It closes and -rc1 is released.
2. Release candidates (7-8 weeks). Every Sunday an -rc2, -rc3... comes out. Only bug fixes are accepted.
3. Final release. The stable version ships. The next day the following merge window opens.

In total: a new version every 9-10 weeks, roughly. The numbering (5.x, 6.x) is purely cosmetic: Torvalds bumps the first number when the second gets uncomfortably large, not because there are revolutionary changes.

Ordinary versions stop being maintained as soon as the next one comes out. That is why LTS (Long Term Support) kernels exist, receiving security fixes for several years (typically between 2 and 6). They are the ones server distributions use.

Ubuntu Server 24.04 LTS starts from kernel 6.8, with security patches backed by Canonical for the whole life cycle of the distribution. This means something important: you will not see a 6.14 kernel on srv-tramontana even though it exists. In production, stability takes precedence over novelty.

You can check your version at any time with a command we will look at calmly in lesson 01-05:

Output on the Tramontana server:

How to read each part:

• 6 : major version.
• 8 : minor version (kernel 6.8, the base of Ubuntu 24.04 LTS).
• 0 : patch level of the stable branch.
• 41 : Ubuntu build number. This is where Canonical adds its backported fixes.
• generic : kernel flavour. Others exist, such as aws, azure or lowlatency, optimised for particular environments.

The image of altruistic volunteers no longer describes reality:

• More than 2,000 developers from around 200 companies contribute to each version.
• Around 85-90 % of the contributions come from people paid by their employer to do it: Intel, Red Hat, Google, AMD, Huawei, Meta, Oracle, Linaro, Microsoft.
• Something in the order of 10 to 15 patches per hour are merged, every day of the year.

The decision structure is a hierarchy of trust: developers send patches to subsystem maintainers (network, file systems, graphics drivers...), those maintainers review and group them, and the person who finally merges into the main branch is Linus Torvalds, with Greg Kroah-Hartman heading the stable branches. It is a meritocratic and notoriously demanding model: patches are often rejected and reviews can be harsh.

• Believing that Torvalds wrote the whole of Linux. He wrote the initial kernel and still leads the project, but today his contribution in lines of code is minimal: his job is to integrate and arbitrate. Linux is the work of tens of thousands of people.
• Confusing Unix, Linux and "Unix-like". Unix is AT&T's original system and its certified commercial descendants. Linux contains no Unix code: it was written from scratch imitating its behaviour. That is why it is called Unix-like. This detail is not trivial: it was at the heart of SCO's lawsuit against IBM (2003-2010), which SCO lost without finding any Unix code in Linux.
• Thinking history has no practical use. The Unix philosophy is the yardstick you will use to judge your own scripts in Module 4: does it do one thing? can it be chained? does it speak text?
• Treating the choice of licence as a minor detail. The move to the GPL in 1992 is the reason a unified Linux ecosystem exists instead of twenty incompatible variants. Licences have technical consequences.
• Tip. If you want to go deeper, read "The Art of Unix Programming" by Eric S. Raymond (freely available online). It is the best development of the Unix philosophy that exists and it reads like an essay, not like a manual.
• Immediate practical tip. When you start writing scripts, always ask yourself: "could I solve this by chaining tools that already exist?". In Linux, the answer is yes far more often than you think.

Match each feature of today's Linux with the historical fact that explains it. Justify each pairing in two or three sentences:

1. Commands have very short names (ls, cp, mv).
2. System configuration consists of text files in /etc.
3. There is a standard called POSIX.
4. The same Linux runs on a phone and on a supercomputer.
5. There are no proprietary, mutually incompatible versions of Linux.

Luis Ferrer has written for Tramontana a program called tramontana-analyser that reads the file /var/log/tramontana/access.log, filters the errors, sorts them, counts them, generates a chart and sends an email to Marta. All in a single binary, with a configuration file in a proprietary binary format.

Assess the design against the Unix philosophy: state which principles it breaks and propose a concrete alternative that respects that philosophy. Reason about what the team gains from the redesign.

On srv-tramontana you run uname -r and get 6.8.0-41-generic. Marta has read that kernel 6.14 exists and asks you why the server is "out of date and probably insecure". Write the answer you would give her, explaining the numbering and the concept of LTS.

Solution to Exercise 1

1. Short command names. Unix was born in 1969-1970 on teletypes: terminals that printed on paper at speeds of tens of characters per second. Typing was slow and noisy, and every character saved was real time gained. That economy became fossilised in the command set and was never changed, because by then there were already millions of scripts and people using them. Today they survive out of compatibility, not necessity.

2. Configuration in plain text. This follows directly from the principle "text is the universal interface". If configuration is text, any generic tool can manipulate it: grep to search, sed to modify, Git to version, Ansible to deploy. A binary format would force a specific tool for each file and would break the whole composition chain.

3. POSIX. It is the reaction to the Unix wars of the eighties. Once Unix was commercialised, each manufacturer created its incompatible variant (AIX, HP-UX, Solaris, IRIX...) and programs stopped being portable. POSIX defines the lowest common denominator of calls, commands and shell behaviour so that software written once works on any conformant system.

4. Extreme portability. It is a consequence of the rewrite of Unix in C in 1973. Since it no longer depended on the assembly language of one particular machine, porting the system to a new processor became a matter of recompiling and adapting the hardware-dependent parts. Linux inherited that design and today supports more than twenty architectures.

5. The absence of proprietary forks. It is the effect of the GPL licence adopted in 1992. Copyleft requires that any modified version that is distributed be distributed under the GPL as well, and with the source code. No manufacturer has been able to create a closed Linux, and improvements flow back into the common trunk. It is exactly the mechanism Unix lacked.

Solution to Exercise 2

Principles broken by Luis's design:

An alternative that respects the Unix philosophy:

Break it down into pieces that already exist and chain them together, leaving in a script only what is specific to Tramontana:

Step-by-step explanation:

• grep ERROR ... filters the error lines. It replaces the filtering module.
• sort orders them so that identical ones end up together, a requirement of uniq.
• uniq -c collapses repeated lines and prefixes the number of repetitions.
• sort -rn reorders by that number, from highest to lowest (-n numeric, -r reverse): the most frequent errors on top.
• > redirects the result to a file (you will see this in Module 3).
• mail sends that file by email. Only this part is "Tramontana-specific".

And the configuration would become a text file in /etc/tramontana/.

What the team gains:

• Less in-house code to maintain: five tools tested by millions of users replace five modules written at home.
• Flexibility: if Marta asks to filter by date as well, you add another grep to the pipeline without touching anything else.
• Reuse: the same sort | uniq -c works for analysing bookings.csv.
• Debuggability: you can run the pipeline step by step and see the intermediate output of each stage. With the monolithic binary, if the result looks odd you do not know which component failed.
• Automation: being text and commands, all of this can be scheduled with cron (Module 3) and deployed with Ansible (Module 7).

Solution to Exercise 3

An answer for Marta:

"The number does not work like in a phone app, where the highest is always the best. In 6.8.0-41-generic, the 6.8 is the kernel baseline that Ubuntu 24.04 LTS chose when it was released, and the -41 is the important bit: it is Ubuntu's build number, and it goes up every time Canonical adds security fixes to that baseline.

The Linux kernel releases a new version every 9 or 10 weeks. No server distribution chases that rhythm, because every new version brings new features and, with them, the risk of regressions in the drivers and in performance. What you do in production is fix a stable baseline and apply only the security fixes to it, a practice called backporting.

That is the point of an LTS (Long Term Support) distribution: Ubuntu 24.04 LTS is maintained with security patches until 2029. When a serious vulnerability appears, Canonical fixes it on 6.8 and publishes a -42, a -43, and so on. We get the protection without getting the functional changes.

So the server is not out of date in what matters: it is on a maintained line and receives security fixes promptly. We can verify it with apt list --upgradable and with the update history. Installing 6.14 would give us features we do not need, would take us outside Canonical's official support and would expose us to unforeseen hardware faults in production. On a server, boring is a compliment."

The essentials of this lesson:

• Unix was born at Bell Labs in 1969 and was rewritten in C in 1973, which gave it the portability Linux inherits today.
• The Unix philosophy — small programs that do one thing well, everything is a file, composing with pipes, text as the universal interface, silence on success — is the design yardstick that explains practically everything you will see in this course.
• The commercial fragmentation of Unix led to the POSIX standard, which is what makes your knowledge and your scripts transferable between systems.
• The GNU project (1983) built the whole free operating system except the kernel; Torvalds's kernel (1991) turned up just in time, and the move to the GPL in 1992 stopped Linux from fragmenting like Unix.
• The kernel is developed today with a 9-10 week cycle, LTS versions for production and thousands of developers paid by companies.

With the genealogy clear, you can now understand why there are so many different "Linuxes" and how they really differ. In the next lesson, Linux Distributions, we will look at what exactly makes up a distribution, the three big families (Debian/Ubuntu, Red Hat/Fedora and Arch), what LTS means as opposed to rolling release, and we will take with professional judgement the decision Tramontana has already taken: Ubuntu Server 24.04 LTS for srv-tramontana.