Linux is an open source operating system family built around the Linux kernel. In simple terms, it is the software layer that helps your computer talk to hardware, manage files, run programs, and control memory, networking, and users.
Many people say âLinuxâ when they really mean a complete operating system such as Ubuntu or CentOS. That is common in everyday conversation, but it helps to separate the main pieces.
The kernel is the core of the operating system. It handles low-level jobs such as CPU scheduling, memory allocation, device drivers, and process management.
A distribution or distro is a complete Linux operating system built around the kernel. It bundles package managers, default tools, system services, documentation, and a release model. Ubuntu, CentOS Stream, and Alpine are all distros.
A shell is the command-line interface you use to interact with the system. Popular shells include bash, zsh, and sh. When you type commands like ls or cd, the shell reads your input and launches the right program.
Tip: A useful mental model is: kernel = engine, distro = complete car, shell = steering wheel.
Most modern infrastructure runs on Linux. Cloud virtual machines, Kubernetes worker nodes, containers, CI runners, load balancers, and monitoring tools often use Linux under the hood.
DevOps engineers use Linux because it is:
If you know Linux, you can move more confidently between local development, staging, and production systems.
Imagine a team deploying a web application to AWS. Their EC2 instances run Ubuntu, their Docker containers use Alpine as a base image, and their Kubernetes control tools run on Linux in CI. Even if the developers use macOS or Windows locally, the production path still depends heavily on Linux skills.
Different distros target different goals.
Ubuntu is one of the most beginner-friendly Linux distributions. It is common on cloud servers, tutorials, and developer workstations. It uses the apt package manager and has a large community.
Example package install:
sudo apt update
sudo apt install nginxCentOS Stream is closely related to Red Hat Enterprise Linux. It is often seen in enterprise environments and is useful when learning Linux administration in business settings. Red Hat style systems typically use dnf or yum.
sudo dnf install nginxAlpine Linux is very small and security-focused. It is especially popular in containers because of its lightweight footprint.
apk add curlNote: Alpine uses
muslinstead ofglibc, so a few binaries behave differently compared to Ubuntu or CentOS-based systems.
Linux is not just for laptops. You will meet it in several forms:
In containers, Linux becomes even more important because containers rely on Linux kernel features such as namespaces and cgroups.
Linux can run desktop environments with graphical interfaces, but in DevOps you often work mainly in the terminal. That is because servers are commonly accessed over SSH and automated with scripts.
A GUI is helpful for beginners, but command-line skills scale better when managing many systems.
For example, updating ten servers through a GUI would be slow. Running one script over SSH is much faster.
ssh devops@server1
uname -a
cat /etc/os-releaseThese commands help you quickly learn what kernel and distro you are using.
Linux is open source, which means its source code can be inspected, modified, and redistributed under open source licenses. For DevOps teams, this matters because:
Open source does not automatically mean easy, but it does mean the platform is flexible and widely shared.
Linux is the foundation of much of modern infrastructure. The kernel is the core engine, a distribution packages the full operating system, and the shell gives you a command-line way to control it.
As a DevOps engineer, Linux knowledge helps you troubleshoot servers, automate tasks, manage containers, and understand what production systems are actually doing.
If you remember only one thing from this lesson, remember this: learning Linux is not just learning commands. It is learning how modern systems are operated.
Scenario: A teammate says Ubuntu, Bash, and the Linux kernel are all the same thing.
Question: Which statement correctly separates those three concepts?
<MCQExercise exercise={{
id: 'introduction-to-linux-q1',
title: 'Exercise 1: Core Linux layers',
description: 'Identify the difference between the Linux kernel, a distribution, and a shell.',
options: [
{ id: 'a', text: 'The shell is the hardware layer, and the kernel is the command line.' },
{ id: 'b', text: 'The kernel manages core system functions, a distribution packages a complete OS, and a shell is the interface for running commands.' },
{ id: 'c', text: 'A distribution is only a package manager, while the kernel is a desktop environment.' },
{ id: 'd', text: 'The kernel, distribution, and shell are three names for the same component.' },
],
correctId: 'b',
explanation: 'The lesson separates Linux into layers: the kernel handles low-level system work, a distro bundles the full operating system experience, and the shell is how you interact with it from the command line. Keeping those roles distinct makes Linux concepts much easier to understand.',
wrongExplanations: {
a: 'The shell is not a hardware layer. It reads your commands, while the kernel talks to hardware and manages processes and memory.',
c: 'A distribution is much more than a package manager, and the kernel is not a desktop environment. Distros bundle tools, defaults, services, and documentation around the kernel.',
d: 'They are related, but they are not interchangeable terms. The tutorial explicitly distinguishes the kernel, the distro, and the shell.',
},
}} />
Scenario: Your company runs CI runners, Docker containers, and cloud VMs.
Question: Why is Linux especially common in that kind of environment?
<MCQExercise exercise={{
id: 'introduction-to-linux-q2',
title: 'Exercise 2: Linux in infrastructure',
description: 'Choose the reason Linux is widely used across servers, containers, and automation.',
options: [
{ id: 'a', text: 'Because Linux avoids logs and hides system behavior from operators.' },
{ id: 'b', text: 'Because Linux only works on developer laptops and not in production.' },
{ id: 'c', text: 'Because Linux is stable, scriptable, lightweight, and widely supported in modern infrastructure.' },
{ id: 'd', text: 'Because Linux removes the need for automation tools and shell scripts.' },
],
correctId: 'c',
explanation: 'The tutorial highlights Linux as a strong fit for DevOps because it is stable for long-running services, transparent through text-based configs and logs, and easy to automate. Those traits make it a natural platform for cloud systems, containers, and CI pipelines.',
wrongExplanations: {
a: 'Linux does not avoid logs. In fact, one reason it is powerful in operations is that behavior is exposed through logs and text files.',
b: 'This is the opposite of the lesson. Linux is heavily used in production systems such as VMs, containers, and Kubernetes nodes.',
d: 'Linux encourages automation rather than replacing it. Shells, scripts, and automation tools are part of why it is so useful.',
},
}} />
Question: Which distribution from the lesson is especially popular as a lightweight container base image?
<MCQExercise exercise={{
id: 'introduction-to-linux-q3',
title: 'Exercise 3: Container-friendly distro',
description: 'Pick the distribution the tutorial describes as small and common in containers.',
options: [
{ id: 'a', text: 'Alpine Linux' },
{ id: 'b', text: 'CentOS Stream because it is the only distro that can run containers' },
{ id: 'c', text: 'Ubuntu because it does not include a package manager' },
{ id: 'd', text: 'A shell such as Bash, because shells are distributions' },
],
correctId: 'a',
explanation: 'The lesson calls out Alpine as small and security-focused, which is why it appears so often in container images. Its lightweight footprint makes it attractive when image size matters.',
wrongExplanations: {
b: 'CentOS Stream can be used in many contexts, but the tutorial specifically identified Alpine as the lightweight container favorite.',
c: 'Ubuntu does include a package manager, and the lesson did not describe it as the especially lightweight container base here.',
d: 'Bash is a shell, not a distribution. The tutorial clearly separates shells from distros.',
},
}} />
Ubuntu, because it is the default on most cloud providers, has the largest body of documentation, and the apt commands you learn transfer to Debian. Add familiarity with a RHEL-family system, Rocky, Alma or CentOS Stream, since regulated and enterprise environments use them and dnf, SELinux and firewalld behave differently enough to matter. Alpine is worth knowing specifically because it dominates container base images, where musl instead of glibc causes real surprises.
The command line, without much qualification. Servers are administered over SSH with no desktop installed, container images contain no GUI, and every automation tool, Ansible, CI pipelines, shell scripts, expresses work as commands. Beyond necessity it is also the only form that is reproducible: a command can be committed to a repository, reviewed and re-run, while a sequence of clicks cannot. A graphical environment is a convenience on your own machine and absent everywhere you will actually work.
Three reasons compound. It is free to run at scale with no per-instance licensing. It is efficient. A minimal install uses a fraction of the memory a Windows Server needs, which directly changes cloud cost. And containers are a Linux kernel feature: namespaces and cgroups are what make them possible, which is why Docker on Windows and macOS runs a Linux virtual machine underneath. The ecosystem followed, so nearly all infrastructure tooling targets Linux first.
The terminal is the window, the shell is the program running inside it that interprets what you type. bash is the long-standing default, zsh ships as standard on macOS, and sh is the minimal POSIX shell that Alpine and most container images provide via ash or dash. The distinction matters in practice: a script starting #!/bin/bash fails on an image with no bash, and features such as [[ ]] and arrays are bash extensions that plain sh does not support.
Enough to be comfortable rather than expert: navigating the filesystem, reading and editing files, permissions and ownership, processes and signals, and following logs. Those map directly onto container work. A container is a Linux process, docker exec drops you into a shell, and most failures are permissions, a missing file or a process not listening where you expected. People who skip this find container debugging opaque, because the concepts underneath were never learned.
Find and fix Linux disk problems: why df and du disagree, deleted-but-open files, inode exhaustion, persistent mounts by UUID in fstab and tar versus zip.
Write bash scripts that fail loudly, not silently: use set -euo pipefail, quote variables, prefer [[ ]] over [ ], clean up with trap and lint with shellcheck.
Install software on any distro: apt versus apt-get, remove versus purge, fixing dpkg lock errors, dnf and rpm on Red Hat systems, and when snap is worth it.