RizTech Academy logo
RizTech Academy
Linux FundamentalsLesson 1 of 715 min

Why servers run Linux

Almost every server you will ever deploy to, every container you will ever build, and every cloud instance you will ever spin up runs Linux. If you are going into DevOps, infrastructure, or backend work, Linux is not one skill among many — it is the ground you stand on. This first lesson is about why that is, so the commands in the rest of the module feel like tools for a real job rather than trivia to memorise. It is also where you meet the shell for the first time.

Why servers run Linux

Your laptop probably runs Windows or macOS, but the machines that run the internet overwhelmingly run Linux — web servers, databases, containers, Kubernetes nodes, CI runners, almost all of AWS, Google Cloud and Azure's Linux fleet. A few reasons this happened, and they are worth knowing because they explain how Linux behaves:

  • It is free and open source. No per-server licence cost, and anyone can inspect, modify and redistribute it. At the scale of thousands of servers, that matters enormously.
  • It is stable and runs for a long time. A Linux server can run for months without a reboot. Servers are meant to stay up, and Linux is built for that.
  • It is designed to be run without a screen. You operate a server over the network, by typing commands — there is usually no desktop, no mouse, just a shell. This is the single biggest adjustment for someone coming from a graphical OS, and it is the whole reason this module exists.
  • It is scriptable and automatable. Everything is a command, so everything can be put in a script and automated — which is the essence of DevOps. You cannot automate clicking a button; you can automate a command.

So learning Linux is not learning a niche operating system — it is learning the environment your software actually runs in, and the one you will spend your career operating.

The shell: talking to the machine by typing

When you connect to a Linux server, you get a shell — a program that reads commands you type and runs them. The most common shell is Bash. It shows a prompt and waits:

user@server:~$

You type a command, press Enter, it runs, and you get the output. That loop — type, run, read — is how you operate a server. There is no clicking; the command line is the interface. This feels alien at first and becomes fast and precise with practice, which is exactly why it won: a command can be typed, scripted, logged, and repeated exactly, and a mouse click cannot.

A first command, which prints text:

echo "hello from the shell"

And two you will use constantly to know where you are and who you are:

pwd     # print working directory — where am I in the filesystem?
whoami  # which user am I logged in as?

The # and the text after it is a comment — the shell ignores it. We use comments to explain commands throughout this course.

You do not need a Linux machine to learn Linux

A practical worry: "I am on Windows/macOS, how do I practise?" You have easy options, and you should pick one now so you can run every command in this module:

  • macOS — the built-in Terminal app runs a Unix shell (zsh/bash); almost every command in this course works there directly.
  • Windows — install WSL (Windows Subsystem for Linux), which gives you a real Ubuntu Linux inside Windows. This is the standard way developers run Linux on Windows now.
  • Anywhere — a cheap cloud server (the SSH lesson), or run Linux in a container (the containers module).

Whichever you choose, open a terminal now. Everything from here is meant to be typed and run, not just read — Linux is a practical skill, and it only sticks by doing.

Getting help when you are stuck (and you will be)

You will constantly forget a command's exact options — everyone does, for their whole career. Linux has help built in, and knowing how to find it is more valuable than memorising commands:

  • man <command> — the manual page for a command, e.g. man ls. Press q to quit. Manual pages are dense but complete; learn to skim them.
  • <command> --help — a shorter usage summary most commands support, e.g. ls --help.
  • which <command> — where a command actually lives on disk, e.g. which bash.

Nobody remembers every flag. The skill is not memorisation; it is knowing how to look things up quickly and reading output carefully. Get comfortable reaching for man and --help from day one, and the size of Linux stops being intimidating.

Check your work

Why Linux runs servers: free/open source (no per-server licence, at scale that matters), stable (runs for months, built to stay up), designed to run without a screen (operated over the network by typing — the big adjustment), and scriptable/automatable (everything is a command, so everything can be automated — the essence of DevOps). You are learning the environment your software actually runs in.

The shell reads commands you type at a prompt and runs them (type → run → read); the common one is Bash. The command line is the interface — no clicking — which is why it won (commands can be scripted, logged, repeated exactly). echo prints; pwd shows where you are; whoami shows who you are; # starts a comment.

To practise: macOS Terminal, Windows WSL (real Ubuntu in Windows), or a cloud server/container. Open a terminal and type the commands — Linux sticks only by doing.

Getting help: man <command> (full manual, q to quit), <command> --help (short usage), which <command> (where it lives). Nobody memorises every flag — the skill is looking things up and reading output.

Practice

  1. Open a terminal (macOS Terminal, Windows WSL, or a cloud shell) and run echo "hello", pwd and whoami; read what each prints.
  2. Run man ls, skim it, and quit with q; then run ls --help and compare.
  3. Use which bash and which echo to see where those commands live.
  4. In your own words, give two reasons servers run Linux and why each matters for automation.
  5. Explain why "operated without a screen, by typing" is the key difference from your laptop's OS, and why it enables DevOps.
  6. Find the manual page for pwd and note one thing it says that you did not know.

Official documentation

Next: the filesystem, and navigating it.

Stuck on this lesson?

Being stuck is part of it — but being stuck alone for three days is not. Our internship programme pairs this curriculum with code review and one-to-one help from working developers, and it is free.

About the internship