What Is Linux?

Linux is an open-source Unix-like operating system built around the Linux kernel. The kernel manages hardware — CPU scheduling, memory, disks, network interfaces, and device drivers — while userspace programs (shells, web servers, databases) run on top of it through system calls.

Unlike Windows or macOS, Linux is not a single product. Distributions (Ubuntu, Fedora, Debian, Rocky) bundle the kernel with a package manager, default tools, desktop or server profiles, and support policies.

  # Kernel version and architecture
uname -r
uname -m

# Full system info
uname -a

# Distribution details
cat /etc/os-release

Kernel vs. Userspace

Layer Role Examples
Kernel Hardware abstraction, scheduling, security enforcement Process scheduler, VFS, TCP/IP stack
Userspace Applications, libraries, init system Bash, nginx, PostgreSQL, systemd
Hardware Physical or virtual devices CPU, RAM, NVMe, NIC

When you run ls, the shell (bash) asks the kernel to open a directory via the open() system call. The kernel checks permissions, reads inode data from disk, and returns file entries.

  # Trace system calls (requires strace)
strace -e openat ls /etc 2>&1 | head -20

Why Learn Linux?

  • Servers and cloud — Over 90% of public cloud VMs run Linux; AWS, GCP, and Azure default images are Linux-based
  • DevOps and SRE — CI/CD pipelines, Kubernetes nodes, and infrastructure automation assume Linux fluency
  • Containers — Docker and Kubernetes run Linux containers; understanding the OS is essential for debugging
  • Transparency — Logs, configs, and tools are inspectable and scriptable without proprietary lock-in
  • Cost — No licensing fees; runs on old hardware, ARM boards, and embedded systems

Key Design Principles

Everything is a file. Devices (/dev/sda), process info (/proc/1234/status), and kernel parameters (/sys/...) appear as files. Sockets and pipes follow the same read/write model.

Multi-user by design. Each user has a UID; the superuser (root, UID 0) bypasses most permission checks. Services run as dedicated users for isolation.

CLI-first administration. Graphical desktops exist, but production administration is done efficiently in the terminal — SSH, scripts, and automation.

Process isolation. Each process has its own virtual memory space. The kernel enforces boundaries through permissions and cgroups.

Your First Commands 

  # Identity and location
whoami
id
pwd
hostname

# What's running?
ps aux | head
uptime

# List files with details
ls -la

# Read manual pages
man ls
man 5 passwd          # section 5 = file formats

The Filesystem at a Glance

Path Purpose
/ Root of the entire tree
/home User home directories
/etc System configuration
/var Variable data (logs, caches, mail spool)
/proc Live kernel and process information
/dev Device files

Typical Learning Path

  1. Install a distribution and log in (local VM or cloud)
  2. Navigate the filesystem and manage permissions
  3. Install packages and manage services with systemd
  4. Configure networking, SSH, and basic hardening
  5. Automate tasks with shell scripts and cron/systemd timers

Best Practices

Practice Reason
Use a non-root daily account Limits damage from mistakes and malware
Read man pages before flags Prevents destructive options (rm -rf /)
Keep systems patched Security fixes ship through package managers
Learn one distro deeply first Concepts transfer; package names differ

Common Mistakes

Mistake Consequence
Running everything as root One typo can destroy the system
Ignoring exit codes in scripts Silent failures cascade in automation
Copy-pasting commands without understanding curl | bash from untrusted sources
Skipping backups before changes No rollback when configs break

Troubleshooting Mindset

When something breaks on Linux, evidence is usually nearby:

  # Recent system messages
journalctl -p err -b --no-pager | tail -20

# Did a service fail?
systemctl --failed

# Disk full?
df -h

Linux rewards curiosity: logs, man pages, and /proc usually point to the fix instead of requiring a reboot.

Production Scenario

A new engineer joins an SRE team managing 200 Ubuntu servers. Before touching production, they:

  1. Spin up a local VM matching production (22.04 LTS)
  2. Practice SSH key auth, systemctl, and journalctl
  3. Read /etc/os-release and uname -a on a staging host to confirm environment parity
  4. Document the runbook commands they use daily

Matching the production OS version locally prevents “works on my machine” surprises when scripts rely on specific tool versions.

Linux is the foundation of modern infrastructure — understanding kernel vs. userspace, permissions, and the CLI unlocks everything that follows in this learning path.