Linux and the Operating System
The question: what are you actually running?
Section titled “The question: what are you actually running?”You installed Ubuntu, this module is called Linux Foundations, and the desktop is full of programs. None of those labels name the same thing, though people talk as though they do.
The distinction matters because each layer answers a different kind of question. If a command starts behaving differently after an update, the distribution and its packaged software probably changed underneath you. If every program on the box loses access to a device at once, the kernel or its configuration is a much better place to look. And if exactly one terminal session is acting strange, you may be dealing with a single shell process. Calling all of that “Linux” is convenient right up until somebody asks what actually broke.
Start from a working model
Section titled “Start from a working model”Here’s the model we’ll use. The kernel is the privileged core of the whole arrangement, and it manages access to the hardware and shared system resources. A distribution bundles that kernel together with libraries, tools, an installer, and a set of update policies, into something you can actually install on a computer. Programs ask the kernel for protected services rather than driving the hardware themselves, and a running copy of a program is a process.
That model leaves out plenty of detail, but it is still enough to hang evidence on. So we’re going to put four questions to the running VM, one per layer: the kernel it runs, the distribution wrapped around it, the user making the requests, and the shell process alive right now.
Open Terminal in the course VM, and before you run anything, consider this question:
Will the command that identifies Linux also identify Ubuntu? Why or why not?
Don’t go back and correct the prediction yet.
Ask the running system for evidence
Section titled “Ask the running system for evidence”Run these commands one at a time:
uname -scat /etc/os-releasewhoamips -o pid,comm -p $$The first command should print:
LinuxThe operating-system release file should include lines shaped like these:
NAME="Ubuntu"ID=ubuntuThe version fields depend on the course image, and your username depends on whatever you picked during setup. The last command should print a heading and a single shell process:
PID COMMAND 2481 bashYour PID will almost certainly be different, and bash may show up as another shell if you changed it on purpose.
Notice that all four commands went to different places for their answers. uname asks the kernel directly, and /etc/os-release is a text file maintained by the distribution. whoami reports the effective user identity attached to your current process, and ps asks about running processes. Each command identifies a different part of the system, so keep its output attached to the question it answers.
Check the uname manual when you need a different system property. Its options answer separate questions, even when one machine happens to give similar-looking answers.
Turn output into bounded claims
Section titled “Turn output into bounded claims”Use each command for one job:
| Evidence | Observation | Supported conclusion |
|---|---|---|
uname -s prints Linux |
The running kernel identifies itself as Linux. | Linux is the kernel used by this system. |
/etc/os-release names Ubuntu |
The installed distribution identifies itself as Ubuntu. | Ubuntu packages the Linux kernel with user-space software and defaults. |
whoami prints your username |
The shell is acting as one named user. | Linux can apply access decisions to that identity. |
ps shows a PID and command |
A shell program is currently running as a process. | A program on disk and a running process are related but not identical. |
None of those commands proves very much about the system as a whole. They answer four narrow questions with evidence you can actually point at, and that’s a different and more useful thing.
Kernel, distribution, program, and process
Section titled “Kernel, distribution, program, and process”The Linux kernel manages hardware access, memory, processes, filesystems, and the boundary between running programs and privileged operations.
Ordinary programs run in user space, where the processor and the kernel together limit what any of them is allowed to do on its own initiative. When a program wants to read a file, grab itself some more memory, or put text on your terminal, it has to go and ask the kernel for that service. Later lessons make those requests visible as system calls. For now the point is just that the kernel isn’t a pile of ordinary commands. It’s the layer letting those commands run at all, and stopping them from casually trampling everything else on the machine.
An Ubuntu distribution combines that kernel with installers, libraries, command-line tools, a desktop, a package manager, and release policies.
Ubuntu can swap out a packaged command without touching the kernel underneath. Two distributions can run the very same Linux kernel and still ship completely different defaults. That’s why a useful bug report cites the kernel evidence and the distribution evidence separately instead of treating the two words as the same word.
A program is a set of executable instructions and supporting data, sitting in a file and doing nothing at all until something starts it. A process is one running instance of it, with its own process ID and its own current state.
The Terminal window is a program giving you a text interface, and the shell inside it is another program, reading command lines and launching still more programs. While both are running, Linux tracks each of them as a separate process. Closing a process doesn’t normally delete its program file.
bash · ls · cat — inert until startedThe process is not part of what Ubuntu shipped. It exists only while it runs.
Verify one variable at a time
Section titled “Verify one variable at a time”Open a second Terminal window, leaving the first one open. Before running the command, consider:
Will the command name stay the same, the PID, both, or neither?
Now run this in each of them:
ps -o pid,comm -p $$You’ll usually see the same command name against two different PIDs. Compare the names and PIDs in your own two rows. The result supports one specific statement:
Two processes can run the same program while keeping distinct process identities.
Close only the second Terminal when you’re done with it.
Common failures and recovery
Section titled “Common failures and recovery”cat: /etc/os-release: No such file or directory: check that you’re inside the Ubuntu VM and not a terminal on your host (host and guest terminals can look similar).- The
psrow names a different shell: use the shell name it actually shows. If you didn’t change the shell on purpose, reopen the standard Terminal. - You typed part of the prompt by accident: type only the text inside the code block, and never the
$or anything around it. - The terminal is in some unknown state: close it, open a fresh Terminal, and run the four evidence commands again one at a time.
Check your result
Section titled “Check your result”Look at the two terminal results. The kernel, distribution and user should match; the shell PIDs should differ. A new shell is another process on the same operating system. If a different value changed, check which command produced it.