You already used Linux today, probably several times, and almost certainly without noticing. The search that brought you to this page ran on it. The phone in your pocket most likely boots it. The servers holding your bank balance run it with near certainty. Linux is the most widely deployed operating system on the planet, and its defining trait is that it stays out of sight.

That invisibility is the reason to start here. Before you type a single command, it helps to see where this thing actually lives and why the command line you are about to learn is the way professionals drive it. Ask any Linux machine what it is and it answers plainly:

Linux is a free operating system kernel. Bundled with tools into a distribution, it runs most of the world servers, all of the top 500 supercomputers, and, through Android, most of the phones on Earth. You learn it on the command line because that is how the machines that matter are actually run. This part is the map. The rest of the series is the hands-on driving.

Start with the number that ends the argument. Every one of the 500 fastest supercomputers in the world runs Linux, and has done so without exception since November 2017. Not most of them. All of them. When a lab spends hundreds of millions of dollars on a machine to model the climate or fold proteins, the operating system it picks is Linux, every single time.

The web tells the same story. Of the websites where the underlying operating system can be identified, the Unix family accounts for more than 90 percent, and Linux is by far the largest slice of that. The cloud you keep hearing about is, underneath the branding, mostly fleets of Linux virtual machines. And the most popular consumer operating system in history, Android, is built on the Linux kernel, which puts a Linux core in billions of pockets.

Here is the part worth sitting with, because it is the answer to the why. Linux did not win by being the friendliest to install or the prettiest on a laptop. It won on the machines nobody sees. Three properties made that happen. It is free to copy, so running ten thousand servers costs nothing in per-seat licensing. Its source is open, so a company running a huge fleet can read the code, patch a kernel bug itself, and not wait on a vendor. And it stays up. Uptime measured in years is normal, not remarkable. For anyone operating infrastructure at scale, those three add up to a decision that makes itself.

New learners trip on this in week one, so clear it up now. Strictly speaking, Linux is only the kernel. The kernel is the core program that talks to the hardware. It manages memory, schedules which program gets the processor, and handles reading from disks and sending packets over the network. Linus Torvalds released the first version in 1991, and that kernel is still the piece named Linux.

A kernel on its own does nothing you can use. You cannot log in, list a folder, or install software with just a kernel. To get a usable system, someone wraps the kernel together with a shell, the GNU command line tools, a package manager, an installer, and default configuration. That bundle is a distribution, and it is what you actually download and run. Ubuntu, Debian, Fedora, and Rocky Linux are distributions. They share the same engine and differ in the bodywork around it.

The engine and car comparison holds up well. The kernel is the engine. Every distribution bolts it into a different chassis with different dashboards and different tools in the trunk, but the thing turning the wheels is the same across all of them. Learn to drive one and you can drive the rest.

In casual use, Linux means the whole system, distribution and all. In precise use, it means only the kernel, which is why some people insist on the longer name GNU slash Linux to credit the GNU tools that fill out the rest. You do not need to take a side in that debate. Just understand that when a job listing says Linux, it means the whole working system, and when a kernel developer says Linux, they mean the one program in the middle of that stack.

The first thing to do on an unfamiliar server is find out what it is. Three commands answer that. Run them in order. The output below is what a typical cloud server prints.

$ uname -a
Linux server01 6.8.0-generic #40-Ubuntu SMP x86_64 GNU/Linux

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
ID=ubuntu
ID_LIKE=debian

$ hostnamectl
   Static hostname: server01
 Operating System: Ubuntu 24.04 LTS
           Kernel: Linux 6.8.0-generic
     Architecture: x86-64

Read it top to bottom. uname -a gives the kernel version and the CPU architecture. cat /etc/os-release names the distribution and its version, and the ID_LIKE=debian line tells you which family it belongs to, which decides your package commands. hostnamectl prints a tidy summary of all of it.

The failure mode: hostnamectl only exists on systems running systemd, so on a stripped down container or an older box it may be missing and you get command not found. The file /etc/os-release is the portable one. It is present on essentially every modern distribution, which is why scripts read it instead of trusting any single command.

There are hundreds of distributions, but for work you mostly meet two families. Knowing which family a server belongs to tells you how to install software, where config files tend to live, and which guides on the internet apply to you.

The Debian family: Ubuntu and friends

Debian is one of the oldest distributions, and Ubuntu is the Debian based system most beginners and cloud servers run. This family installs software with apt and packages end in .deb. If a tutorial tells you to run sudo apt install something, it is written for this family. Ubuntu Long Term Support releases are the default on most clouds, which is why you meet them first.

The Red Hat family: RHEL, Rocky, Fedora

Red Hat Enterprise Linux, usually shortened to RHEL, is what a large share of corporate and banking infrastructure runs on. Rocky Linux and AlmaLinux are free rebuilds that behave the same, and Fedora is the community edition that feeds into RHEL. This family installs software with dnf and packages end in .rpm. When a guide says sudo dnf install, it is aimed here.

A guide tells you to check a distribution version with lsb_release -a. You paste it into a fresh Ubuntu container and get this:

$ lsb_release -a
bash: lsb_release: command not found

The command is not broken. The lsb-release package simply is not installed on minimal images, and containers strip it out to save space. This bites people writing scripts that assume it is there. The fix is to read the file that is always present instead. Run cat /etc/os-release, or in a script pull one field cleanly with . /etc/os-release; echo "$ID $VERSION_ID", which prints something like ubuntu 24.04. Depend on the file, not the helper command.

Here is where I part ways with a lot of beginner advice online. New learners are told the distribution they pick is a huge decision, that they should agonize over Ubuntu against Mint against Arch, and that running Arch from scratch is how you truly learn Linux. I think that is mostly wasted worry, and it stalls people for weeks before they type a single useful command.

The skills that get you hired live in the layer that is identical everywhere. The shell, files and permissions, processes, users, systemd, logs, networking, SSH, and scripting behave the same on Ubuntu and on Rocky. The package command differs, and this series will always show you both, but that is a footnote. Distribution hopping feels like progress and is usually procrastination.

So the verdict, plainly. If you want a job, install Ubuntu LTS or Rocky Linux, because those are what employers run, and get to work on the command line. Build the muscle memory once and it transfers to every server you will ever touch. If your interest is the cloud those servers live in, the Cloud for Beginners series covers that ground, and if you want to run these systems as virtual machines on your own hardware, VMware for Beginners pairs well with this one.

Nobody hands a junior admin a fresh datacenter to design. You get handed access to servers that already exist, built by people who left, running a distribution you did not choose. The engineer who is useful on day one is the one who can log in, run three commands to learn what the box is, and know from ID_LIKE=debian that they reach for apt and not dnf. That small reflex, orienting before touching anything, is what separates confidence from guessing.

Is Linux really free? Yes, in both senses. Most distributions cost nothing to download and run, and the source code is open for anyone to read and change. Some companies, Red Hat being the clearest example, sell paid support and a certified build, which is what enterprises pay for. The software itself is free. The support contract is the product.

Do I have to give up Windows or my Mac to learn this? No. You have three easy paths. Run a Linux virtual machine on your current computer, use Windows Subsystem for Linux to get a real Ubuntu shell inside Windows, or spin up a cheap or free cloud server. Any of the three gives you a genuine Linux prompt to practice on. A later part builds a proper home lab.

Which distribution should I actually install first? Ubuntu LTS if you want the gentlest on-ramp and the most tutorials, or Rocky Linux if you are aiming at enterprise and RHEL shops. Either is a fine first choice, and the command line skills carry straight across.

Is the command line still necessary when everything has a GUI now? On servers, yes, without exception. The machines that run production usually have no graphical desktop at all. You reach them over SSH and get a text prompt, nothing else. The command line is not the old way of using Linux. It is the normal way to run the systems that matter.

Android runs the Linux kernel, so do my skills work on my phone? The kernel is shared, but the tools around it are not. Android replaces the GNU userland and the shell with its own stack, so the commands you learn here do not map onto a phone. Your skills transfer to servers, cloud instances, and Linux desktops, not to Android as a user.

You now know where Linux runs, why it won the machines that matter, and how to tell the kernel from a distribution. That is the map. Next we open the hood and walk the ground everything else sits on.

Coming up in Part 2: The Linux filesystem, what every top level directory is for, and why there is no C drive.