It is your first day as a technician at Tramontana S.L., a small Spanish company that runs Tramontana Bookings, a web application used by agencies and private customers to book rural cottages. Marta Vidal, the operations manager, shows you the rack: a single machine called srv-tramontana where everything lives. You ask her which operating system it runs and she answers: "Ubuntu Server. Linux, basically." And that is where this course begins.

Before you touch a single key it is worth understanding what Linux actually is, because almost everybody uses the word loosely. In this lesson you will see what an operating system does, which part of that job the Linux kernel really covers, how the system is organised in layers, what it means for it to be free software, and why that is not an ideological detail but a technical and economic property that changes what you can do with your servers. We will finish by comparing Linux with Windows and macOS honestly, and by looking at why Tramontana chose Linux.

1. What an operating system is and what role it plays
2. What the Linux kernel actually is
3. What a distribution is (a preview)
4. The layered architecture of a Linux system
5. Free software, open source and the GPL licence
6. Where Linux is used today
7. Linux versus Windows and macOS
8. Tramontana S.L.: why this company chose Linux

A computer, in the raw, is a pile of circuits: a processor that executes instructions, RAM that holds them in the meantime, disks that store data persistently, a network card, a keyboard, a screen. None of that knows how to cooperate on its own.

The operating system is the program that sits between the hardware and your applications, and it takes care of four fundamental things:

• Managing the processor. It decides which program runs at each instant and for how long. Your laptop may have 8 cores, but there are 300 processes under way: somebody has to hand out the turns. That is called scheduling.
• Managing memory. It gives each program the illusion of having all the RAM to itself, stops one program from reading another's memory, and decides what to move out to disk when space runs short.
• Managing devices. It translates "save this file" into the specific orders understood by an NVMe SSD, a spinning hard disk or a network drive. Drivers are the pieces that know each particular piece of hardware.
• Offering a service interface to applications. A browser has no idea how to talk to a Wi-Fi card: it asks the operating system to "open me a connection to this server" and the system takes care of it.

To these you should add a fifth function which, on a server, is the most important of all: isolating and controlling. Deciding who may read which file, who may shut the machine down, who may open a network port. Without an operating system there are no users, no permissions and no multitasking: there is a single program owning the machine.

When you say at Tramontana that "the server is overloaded", you will almost always be talking about one of these four functions pushed to its limit: CPU shared among too many processes, memory exhausted, a slow disk or a congested network.

Here comes the precision that hardly anybody bothers with. Linux, strictly speaking, is not a complete operating system: it is a kernel.

The kernel is the heart of the operating system: the privileged program that starts first, takes control of the hardware and never lets go. It is what actually implements CPU scheduling, memory management, file systems, the network stack and the drivers. Everything else — the command interpreter, the browser, the web server — are ordinary programs that run on top of it and ask it for favours.

That separation is real and it is enforced by the hardware. The processor has at least two execution modes:

A program in user mode that tries to write directly to disk simply cannot: the processor prevents it. It has to make a system call (syscall), which is the official entrance to the kernel. open(), read(), write(), fork() and execve() are some of the best known. There are around 350 of them in Linux, and all the power of the system passes through there.

A few figures help to gauge what we are talking about:

• The Linux kernel today exceeds 40 million lines of code, most of them device drivers.
• It is a modular monolithic kernel: everything runs in the same privileged space (monolithic), but it can load and unload pieces on the fly called modules (for example the driver for one particular network card).
• It has been genuinely multiuser and multitasking from the start, not as a later addition.

And there is something that makes it tangible: the kernel is, literally, a file on your disk. You will be able to see it on srv-tramontana:

Output:

How to read it:

• vmlinuz is the traditional name of the compressed kernel (virtual memory linux gzipped).
• 6.8.0-41-generic is the version, which you will learn to read in the next lesson.
• 14 MB. That is all the space taken by the heart of the operating system that powers most of the internet. Everything else on your server — the gigabytes of programs, libraries and data — lives above it.
• The permissions -rw------- mean that only root can read it; you will study them in lesson 02-07.

Linus Torvalds wrote and released that kernel in 1991. You will see the details in the next lesson. What matters now: the kernel on its own is of no use to you. If you boot a machine with nothing but the Linux kernel, the system stops immediately because it finds no program to run.

To have a usable system you need to bring the kernel together with hundreds of programs: a command interpreter, tools for copying files, a boot system, a package manager, libraries, an SSH server, perhaps a graphical environment. That work of gathering, integrating, testing and maintaining the whole set is what a distribution does.

A distribution is, in one sentence: Linux kernel + a collection of user programs + a package manager + a maintenance policy, wrapped into something you can install.

Ubuntu, Debian, Red Hat Enterprise Linux, Fedora, Arch Linux, Alpine and Android are all Linux distributions in this sense: they share the kernel and differ in everything else. That is why saying "I know Linux" makes sense (the kernel and the foundations are common) while at the same time changing distribution forces you to relearn details.

Lesson 01-03 is devoted entirely to this topic: families, package managers, life cycles and how to choose. Here it is enough to hold on to the relationship: the kernel is one piece; the distribution is the whole box.

This is probably the single most profitable mental image in the whole module. A Linux system is organised in layers, and each layer only talks to its neighbour:

Read it from the bottom up:

• Hardware. The physical machine (or virtual, as it will be in your lab).
• Kernel. The only software with direct access to the hardware. This is where the drivers live.
• System calls. The border. It is the only legal door between your programs and the kernel, and it is also Linux's stable contract: Torvalds upholds the rule that a syscall never breaks compatibility with existing programs. That is why a binary compiled in 2005 still works today.
• Shell and libraries. Very few programs invoke syscalls bare. They use libraries such as glibc, which offers convenient functions (printf, fopen) that make the syscall internally. The shell (Bash, in our case) is both an application and the administrator's main interface: it reads what you type and launches programs.
• Applications. Everything you use and everything you deploy. Tramontana Bookings will live in this layer.

Here is a concrete example of the complete chain. When you type something as trivial as this on srv-tramontana:

Output (fictional extract):

This is what happens, layer by layer:

1. Bash (the shell) parses the line and separates the command cat from the argument /var/log/tramontana/access.log.
2. Bash asks the kernel to create a new process and run the program cat (the fork() and execve() syscalls).
3. cat asks to open the file (open()). The kernel checks permissions, locates the file in the file system and returns an identifier.
4. cat reads blocks (read()); the kernel looks for them in its cache or requests them from the disk driver.
5. cat writes what it has read to standard output (write()), which the kernel directs to your terminal.

You do not need to memorise this, but you do need to internalise it: in Linux, everything that happens ends up being a user process making calls to the kernel. When we diagnose a problem with strace in Module 7, what we will see is literally that list of syscalls.

Linux is not merely free of charge: it is free as in freedom. And that difference has practical daily consequences.

The Free Software Foundation defines four freedoms of free software:

"Open source" is a later term, popularised in 1998, which describes almost the same body of software while putting the emphasis on the collaborative development model rather than on ethics. In daily practice you can treat them as synonyms; the difference is one of discourse.

The Linux kernel is distributed under the GPL version 2 licence (GNU General Public License). Its characteristic clause is copyleft: if you distribute a modified version of a GPL program, you must distribute it under the GPL as well and hand over the source code.

This is what stopped Linux from fragmenting into incompatible proprietary versions, as did happen to Unix. If a router manufacturer uses Linux, it is obliged to publish its kernel modifications, and those improvements come back to the community.

It is worth distinguishing two families of free licences:

One important nuance that avoids legal misunderstandings: the kernel's GPL does not spread to the programs that run on top of it. Tramontana Bookings can be closed proprietary software running on Linux without any problem at all. The boundary is the syscall: crossing it does not create a derived work. Only if you modified the kernel itself would you have obligations.

• No per-machine licence cost. You can build development, test and pre-production environments identical to production.
• No vendor lock-in. If Ubuntu stops convincing you, you migrate to Debian or Rocky Linux with the same knowledge.
• Auditable transparency. In a cybersecurity setting, being able to inspect the code is not a luxury: it is a requirement in many tenders.
• Frictionless automation. You can create and destroy 40 cloud servers from a script (Module 7) without phoning anyone.

The popular perception ("Linux is a geek thing, hardly anyone uses it") is exactly the opposite of reality. On the desktop Linux is a minority; everywhere else, it is dominant.

Treat these figures as orders of magnitude, not as exact data: they vary by source and by year. It is the message that counts.

There is a direct professional consequence, and it is the reason you are taking this course: if you work with the cloud, with containers, with DevOps or with cybersecurity, you do not work with Linux "sometimes": you work with Linux always. Kubernetes, Docker, Terraform, Ansible, most databases and practically every CI/CD pipeline assume Linux underneath.

An honest comparison, without fanaticism. All three are good systems for different purposes.

Where each one shines, put plainly:

• Linux wins clearly on servers, cloud, containers, automation, embedded systems and anything that has to run for months untouched.
• Windows wins on the corporate desktop, with Active Directory, Office and third-party software compatibility.
• macOS is an excellent development desktop: being Unix underneath, almost everything you learn here will also serve you on a Mac.

And a reassuring note: the concepts in this course (processes, permissions, shell, file system) are almost identical on macOS and highly transferable to WSL2 on Windows. You are not learning a product: you are learning the Unix tradition.

Let us close by grounding all of this in the case that will accompany us across eight modules.

Tramontana S.L. has six people on the payroll. Marta Vidal runs operations and agency relations; Luis Ferrer is the developer who maintains Tramontana Bookings, a web application where rural cottages are browsed, nights are booked and invoices are issued. You come in as a systems technician: your job will be to keep the infrastructure working, secure and recoverable.

The infrastructure is deliberately modest:

• Your work laptop: Ubuntu Desktop 24.04 LTS, with the user student.
• The server: srv-tramontana, Ubuntu Server 24.04 LTS, with the administrative user operator and the group tramontana for the technical team.

And a path convention that you and Luis agree on from the outset, which in lesson 01-06 you will discover is not arbitrary but pure FHS standard:

Why Linux and not Windows Server? These are the reasons Marta sums up for you over a five-minute coffee:

1. Cost. With six people and tight margins, zero euros in licences per server and per test environment is real money.
2. Application requirements. Tramontana Bookings is deployed with the usual tools of the web ecosystem (Python, nginx, PostgreSQL, containers later on). All of that is native territory on Linux.
3. Resources. A server with no desktop leaves practically all the RAM and CPU for the application.
4. Stability and life cycle. Ubuntu 24.04 LTS has security support until 2029: five years with no forced migrations.
5. Continuity towards the cloud. The two-year plan is to move part of the infrastructure to the cloud and containers. What you learn on srv-tramontana transfers as it is.
6. Talent and documentation. Whatever problem you hit, somebody has hit it and documented it before.

There is also a negative reason, and it is healthy to acknowledge it: if Tramontana depended on Active Directory, on Windows desktop applications or on an ERP that only runs on SQL Server, the decision would have been a different one. Choosing technology means choosing according to real constraints, not according to taste.

• Confusing the kernel with the whole system. Saying "I installed Linux" is a convenient simplification; what you installed is a distribution. When somebody asks you "which Linux do you use?", the useful answer is "Ubuntu Server 24.04", not "Linux".
• Believing that free means free of charge. Free in English is ambiguous. There is free software you pay for (Red Hat Enterprise Linux is sold with support) and free-of-charge software that is not free (plenty of apps with no source code). What defines free software is the four freedoms, not the price.
• Fearing that the GPL will "contaminate" your application. Running your software on Linux obliges you to nothing. Only modifying and distributing GPL code creates obligations.
• Thinking Linux is hard because it is different. The entry curve is steeper because the system does not hide what it is doing. That very transparency is what later lets you diagnose problems that are black boxes on other systems.
• Expecting Linux to be a Windows clone. It is not and it does not aim to be. Looking for "the Control Panel" is starting off on the wrong foot: here the configuration is text files in /etc and commands, and that is an advantage the moment you want to automate.
• Practical tip. When you read documentation, always check which distribution and version it was written for. A CentOS 7 tutorial can be misleading on Ubuntu 24.04. We will come back to this in 01-03.

Classify each item according to the layer it belongs to in the architecture you have seen (hardware, kernel, syscalls, shell/libraries, applications) and justify each answer in one sentence:

1. The driver for the server's network card.
2. The write() function.
3. Bash.
4. The Tramontana Bookings application.
5. The scheduler that hands out CPU time.
6. The glibc library.

Luis Ferrer puts three statements to you. Say whether each one is true or false and correct it if it is false:

1. "Since Tramontana Bookings runs on Linux, which is GPL, we are obliged to publish the source code of our application."
2. "Android has nothing to do with Linux, it is a Google system."
3. "We can set up three identical environments (development, test and production) with no licence cost."

Marta asks you for a half-page argument to justify to management that srv-tramontana should stay on Linux instead of migrating to Windows Server. Write three arguments in favour and, to be honest about it, one scenario in which the right decision would be Windows Server.

Solution to Exercise 1

Key idea: only two of the six items are in kernel mode. Everything else, including the shell you will use every day, is just another user program.

Solution to Exercise 2

1. False. The GPL's copyleft applies to works derived from the GPL program itself. Running an application on top of the kernel, communicating through system calls, does not create a derived work: the syscall interface is explicitly excluded in the kernel's licence note. Tramontana Bookings can be closed. What would require publishing code is modifying the kernel, or a statically linked GPL library, and distributing it.

2. False. Android uses the Linux kernel as its base, with Google's own modifications, a good part of which have been merged into the official kernel over time. What it does not use is the usual GNU userland (it uses Bionic instead of glibc, plus its own runtime). That makes Android a very atypical Linux distribution, but Linux nonetheless. It is, in fact, the main reason Linux is on 70 % of the world's phones.

3. True. Freedom 0 (running the program for any purpose, with no limit on installations) is precisely what allows it. You can clone srv-tramontana as many times as you like without paying or notifying anyone. You would only pay if you took out commercial support, and that would be optional. This is one of the strongest practical arguments in favour of Linux in a small company.

Solution to Exercise 3

Arguments in favour of keeping Linux on srv-tramontana:

1. Total cost. Zero euros in operating system licences, both in production and in the development and test environments. In a six-person company, that budget line goes somewhere else. On top of that, there are no CALs to manage and no licence audits.

2. Alignment with the technology stack and with the future. Tramontana Bookings relies on web ecosystem tools (nginx, PostgreSQL, Python) that are first-class citizens on Linux. And the plan to move part of the infrastructure to the cloud and to containers within two years demands Linux: Docker and Kubernetes are native Linux technology. Migrating to Windows now would mean paying twice.

3. Operational efficiency and stability. A server with no graphical environment devotes practically all its memory and CPU to the application, and Ubuntu 24.04 LTS offers five years of security updates with no forced migration. Reboots for updates are far less frequent, which translates into fewer late-night maintenance windows.

A scenario in which Windows Server would be the right decision:

If Tramontana acquired a hotel management ERP that only exists for Windows and requires SQL Server, and the payroll grew to the point of needing centralised identity and device management with Active Directory and group policies, the rational choice would be Windows Server (or a mixed environment). Forcing Linux in that case would mean emulation, compatibility layers and non-existent vendor support: more cost and more risk, not less. Technology is chosen according to business constraints, not personal preference.

You now have the conceptual foundations on which everything else rests:

• An operating system manages CPU, memory, devices and services, and it also isolates and controls users.
• Linux is a kernel, not a complete system: the privileged piece that talks to the hardware. Everything else is user programs.
• The layered architecture — hardware, kernel, syscalls, shell and libraries, applications — explains how each part communicates, and system calls are the exact border between your programs and the kernel.
• Free software and the GPL are not an ideological detail: they determine that you can deploy without licences, audit the code and avoid depending on a vendor.
• Linux is dominant on servers, cloud, containers, mobile and supercomputing, though a minority on the desktop.
• Tramontana S.L. has chosen Linux for cost, technical fit, efficiency and continuity towards the cloud. srv-tramontana will be your workplace throughout the course.

Many of the design decisions you will meet from now on — why configuration is text files, why there are so many small commands instead of a few large programs, why "everything is a file" — make no sense unless you know where they come from. In the next lesson, History of Linux, we will travel the road from Unix at Bell Labs in 1969 to the kernel developed today by thousands of contributors, and we will state the Unix philosophy: the principles that explain practically everything you will see across the eight modules of this course.