By the end of these four weeks, students should be able to explain what an operating system is, navigate the Linux filesystem confidently from both a file manager and the terminal, understand the permission model, and recover from basic mistakes using built-in documentation. More importantly: the fear of "doing something wrong" should be gone.
The philosophy for this phase is demystification. Nothing in these sessions should feel like magic or coincidence. Every concept has a reason. Your job is not to teach facts — it is to teach the habit of asking "why does this work this way?" and then finding out.
Every session ends with a preview of the next one. Every week ends with students teaching each other. This is not a kindness feature — it is diagnostic. When a student cannot explain something, that is the gap you address at the start of the following session, not later.
This is not a definition lesson. The goal is to install a mental model that will support everything else in the course. Students come in thinking of "the computer" as a single thing. By the end of this session they will see it as a stack of layers, each with a distinct job, each ignorant of the layers above it. That shift alone will make the next 15 sessions easier to understand.
Do not rush to the computer today. The whiteboard is the main tool. The computer is for verification only.
Whiteboard or large paper. Marker in two colours if possible. A printed list of 15 items for the classification exercise (see below). The computers should be off or sleeping — this session happens away from the screens.
Before anyone sits down, ask this question out loud: "What do you think actually happens between pressing the power button and seeing the desktop?" Give them 2 minutes to write down their answer individually — no discussion yet. Then ask 3 or 4 students to share. You are not correcting anyone. You are collecting the room's intuitions. Most answers will be vague: "it loads" or "it starts up." That vagueness is the thing you are going to fix.
Write their answers on one side of the board. You will come back to them at the end of the session to show them how much further they can now describe the same process.
Draw the following diagram on the board slowly, one layer at a time. Explain each layer before drawing the next. Do not draw all four at once — the sequence of revealing matters.
Layer 1 — Hardware. Draw this first. Hardware is the physical world. The CPU is a chip that executes instructions. RAM is memory that only exists while powered. The disk stores data permanently. The screen, the keyboard, the Wi-Fi antenna — all hardware. The crucial point: hardware on its own does nothing. A CPU sitting on a table cannot add two numbers together without being told how, by whom, and in what format.
Layer 2 — Firmware / BIOS. This layer surprises most students because they have never seen it. Firmware is software that lives permanently on a small chip on the motherboard — not on the hard drive. It is the first code that runs the instant power is applied. Its job: check that hardware is present and working, then find something to boot from (usually the hard drive), and hand control over. On most machines you can access this layer by pressing F2 or Delete during boot. We will actually do this in Phase 4 when we install an operating system from scratch. For now: know it exists, know it runs before everything else, and know that without it the OS could never start.
Layer 3 — Operating System. The OS is the translator and the referee. It translates requests from applications ("I want to write to this file") into instructions the hardware understands ("write these bytes to this sector of the disk"). It also referees: it decides which application gets CPU time, which process can access which file, which user is allowed to do what. The Linux kernel is the core of this layer — roughly 30 million lines of code that manage every hardware resource on the machine. On top of the kernel sit system services: things that run in the background managing networks, logging events, starting applications at boot.
Layer 4 — Applications. Everything the user actually runs. The browser, the terminal, LibreOffice, GIMP, a game. Applications do not talk to the hardware directly — they ask the OS, and the OS handles it. This is why the same application can often run on different hardware: it does not care what GPU or CPU is underneath, as long as the OS speaks its language.
A note on the bootloader: between firmware and the OS there is one more component called a bootloader — on Linux this is usually GRUB. Its job is to find the OS on disk and load it into RAM. We are not going deep on this today. Mention it exists, then move on. Students often ask about it — the correct answer is: "that's a great question and we will actually use it in week 14."
Return to the whiteboard after drawing all four layers and ask: "So when you press the power button, what happens now?" Have a student walk through the sequence using the diagram. Firmware runs → firmware finds the bootloader → bootloader loads the kernel → kernel starts system services → desktop appears → you open the browser. That sequence, understood properly, is a major conceptual achievement for day one.
Hand out the classification sheet. Students work individually, then compare with a partner before a group discussion.
Classification task. Place each item below into one of the four layers: Hardware / Firmware / Operating System / Application. If you think something belongs to more than one layer, write it in both and explain why.
After finishing: which item was hardest to classify? Why?
Return to the warm-up answers on the board. Ask: can someone now describe what happens between pressing power and seeing the desktop, using the layers? Pick a student who seemed uncertain earlier. If they can do it, that is the session's success. If they cannot, that is tomorrow's opening.
Preview session 2: "Now that we know what these layers are, next session we look at the OS layer specifically. Where did it come from, who made it, and why does it matter that the code is free for anyone to read?"
The classification exercise will produce disagreements and that is intentional. A Wi-Fi driver, bash, and systemd are all legitimately between layers. Students who argue that something belongs in two places are thinking correctly — do not shut that down. The goal is the mental model, not a clean taxonomy.
The BIOS layer often surprises students who have used computers for years without knowing it exists. Lean into that surprise. "You have used computers your whole life and never seen this layer" is a good moment to introduce the course's core idea: most people use computers as black boxes. This course is about opening the box.
Do not spend more than 2 minutes on the bootloader today. It will confuse more than it clarifies if you go deep now. The payoff is in Phase 4 — plant the seed and move on.
Real history, told honestly. Not a hero story and not a political manifesto. One person was annoyed, made a decision, and that decision changed what software means. Students need to understand open source not as an ideology but as a development model — and understand why it produced something that now powers most of the world's infrastructure.
One student draws the four-layer diagram from session 1 on the board from memory. The rest of the class can help if needed, but the student at the board does the drawing. This is not a test — it is a retrieval exercise. Gaps in the drawing become the brief recap before moving forward.
Start with context. 1991. The internet exists but is not yet public. Unix is the dominant OS for serious computing — universities, research labs, companies — but it is expensive and its source code is proprietary: you can use it, but you cannot read how it works, modify it, or redistribute it. A 21-year-old computer science student in Helsinki named Linus Torvalds wants to run Unix on his personal computer but cannot afford it. He decides to write his own kernel.
In August 1991, he posts a now-famous message to a newsgroup: "I'm doing a (free) operating system... just a hobby, won't be anything big and professional." This is the thing to emphasise: he was not trying to change the world. He was solving a personal problem. The important decision came after: he released the source code publicly, under a licence that required anyone who modified and distributed it to also release their modifications. That licence is called the GPL — General Public Licence.
What happens next is the consequence of that one decision. Developers around the world could read the code, find bugs, fix them, add features, and send the improvements back. The project grew faster than any proprietary team could have grown it. By the early 2000s, Linux was running most of the world's web servers. By the 2010s, it was running every Android phone. Today it runs roughly 90% of the world's cloud infrastructure, most supercomputers, most of the internet's routing equipment, and the International Space Station.
Now address "free" directly, because it confuses students. In English, "free software" means free as in freedom, not free as in no cost. The Linux kernel can cost money — Red Hat sells it. What you cannot do is take the source code, modify it, and keep your modifications secret. The freedom is about access and transparency, not price.
Why does open source produce better software for infrastructure? Because a bug that affects millions of users will be found and fixed by someone, somewhere, who has both the technical ability and the motivation to fix it. A proprietary company depends on its own employees noticing the bug. Open source depends on everyone who is affected by it. For security-critical infrastructure, that second model is provably better.
Close the concept section with a question: "If you wrote something useful and could either keep it private or share it with the world, which would spread further? Which would become more reliable over time?" Let 2–3 students answer. There is no single right answer — the point is to think about the model, not reach a conclusion.
Research task (internet allowed for this session only in this phase). Find 5 real devices or services — not personal computers — that run Linux. For each one, write:
Share with the group after 15 minutes of research. Try to find things others won't — the obvious answers (Android phones, web servers) will be taken quickly.
Suggested directions if students get stuck: SpaceX rockets, car infotainment systems, stock exchange trading platforms, smart fridges, submarine sonar systems, particle accelerators at CERN, ATMs, traffic light controllers.
One sentence from each student: "Open source means ___." Collect the answers and note which ones are most accurate — use those formulations in future sessions when the concept comes up again.
Preview: "We know what Linux is and where it came from. Next session: why does Linux come in 600 different versions? And which one are we using and why?"
Avoid making this session a Linux advocacy speech. The honest version is more compelling: Linux succeeded in infrastructure because it turned out to be a better model for building reliable software at scale. It did not succeed on the desktop — Windows and macOS still dominate there. Acknowledging that honestly builds more credibility than claiming Linux is better at everything.
The research exercise will produce some interesting finds. A student who discovers that the Tokyo Stock Exchange runs Linux and once had a catastrophic failure because of a configuration error — that's a real story worth following. Let the research go where students' curiosity takes it. The goal is genuine engagement with the idea that Linux is everywhere, not a curated list of impressive examples.
The kernel is shared. Everything above it is a choice. A distro is a curated set of those choices — packager, desktop environment, default apps, release schedule, philosophy. This session explains why there are so many, why that is not a problem, and why we chose Kubuntu specifically.
Quick check: two students answer — what does a kernel do? If the answer is vague, spend 2 extra minutes here before moving on. A weak understanding of the kernel will make the distro concept harder to grasp.
Start with the recipe analogy. The Linux kernel is a base ingredient that everyone shares. A distro is a complete recipe that uses that ingredient. Two recipes can use the same flour and produce completely different bread. The flour does not determine the bread — the choices around it do.
What choices does a distro make? At minimum: which package manager (how software is installed and updated), which desktop environment (what the interface looks and feels like), which default applications (what comes pre-installed), and which release model (stable and slow vs. cutting-edge and frequent). These choices make Fedora feel completely different from Debian even though both run the Linux kernel.
Walk through the families. Debian prioritises stability — packages are tested for months before release. It powers servers that run for years without updates. Ubuntu is built on Debian but adds a large community, corporate support from Canonical, and a 6-month release cycle. Kubuntu takes Ubuntu and swaps the default desktop from GNOME to KDE Plasma. That is the only meaningful difference — same package manager, same repositories, same Ubuntu base.
Fedora is Red Hat's community project. It ships the newest software — sometimes too new, which means occasional rough edges. It uses dnf instead of apt. It is what professional Linux developers often run because it is close to what enterprise servers run.
Arch is a different philosophy: you install the base system and then choose everything yourself. No default desktop, no default apps. It is for people who want to understand and control every component. It is not for this course, but worth knowing it exists.
Why Kubuntu for this course? Ubuntu base means every guide, every Stack Overflow answer, every tutorial on the internet is likely to work. LTS (Long Term Support) means the system will not require major updates for two years — stability matters in a classroom. KDE Plasma is modern, configurable, and interesting enough to be worth exploring. That is the honest answer.
Part 1 — Family tree (15 min). Students receive a list of 12 distros: Ubuntu, Fedora, Arch, Debian, Kubuntu, Manjaro, CentOS, openSUSE, Linux Mint, Pop!_OS, AlmaLinux, Xubuntu. Map them into families. Draw the relationships. Mark which ones share a package manager.
Part 2 — Choice justification (15 min). Four scenarios. For each one, which distro would you choose and why?
No single correct answer — justification is what matters. Share with the group.
Direct question to the class: "Why are we using Kubuntu specifically for this course?" They should now be able to give a real answer — not "because you said so" but because they understand what Kubuntu is and what its properties mean for a 6-month classroom course.
Preview: "Next session we boot Kubuntu for the first time. No commands, no clicking around — just observation."
Students will ask which distro is "the best." The correct answer is: the best distro is the one that matches your use case. A hospital server and a developer's workstation have different requirements. There is no universal ranking. If you push back on the "which is best" question every time it comes up, students will start thinking in terms of fit and trade-offs — which is exactly the problem-solving mindset the course is trying to build.
Some students will have heard of Kali Linux (used by security professionals) or Ubuntu (very common name). Acknowledge them if they come up. Kali is a specialised security distro — not for general use. Ubuntu is the parent of Kubuntu, which is a valid follow-up question about why we're not just using Ubuntu.
No lecture today. The machine is the lesson. This session deliberately removes instruction and replaces it with observation. Students who have only ever used Windows or macOS will encounter something that looks partially familiar and partially alien. That cognitive dissonance is productive — it creates genuine questions that will carry them through the next three weeks.
Your role today is to ask questions, not answer them.
Before powering on anything: ask each student to write 3 specific predictions. Not "it will look different" — specific ones. "I think there will be a taskbar at the bottom." "I think the file manager will look like Windows Explorer." "I think there will be a settings icon somewhere." This primes them to actively compare rather than passively observe.
Boot Kubuntu. Observe for the full session.
Individual written task (20 min) — do not discuss yet:
Pair comparison (10 min): Compare your lists with a partner. What did they notice that you missed? Add anything new to your list.
One volunteer navigates (15 min): One student takes the mouse and navigates while the class narrates. Open the file manager (Dolphin). Open System Settings. Open the terminal (Konsole). The class calls out what they think is happening at each step. Do not correct — record their observations on the board.
Collect the individual question lists — every student hands in their 3 questions. Read through them quickly. Sort them into categories on the board: filesystem questions, interface questions, software questions, permission/security questions. Tell the class: "These are the questions we will answer over the next three weeks. Keep track of when you get the answer to yours."
Preview: "Next week we go into the filesystem — where files actually live on this machine, and why it looks nothing like the C: drive."
Resist the urge to explain things as they point at them. This is the hardest part of this session. When a student says "what is that icon?" the correct response is "what do you think it does?" When they say "this is weird," the correct response is "what specifically is weird about it?" The observation muscle — the habit of looking carefully before assuming — is more valuable right now than any individual answer.
Keep the question lists. They are genuinely useful: they tell you what the students actually care about, which is often different from what the curriculum expects. If half the class wrote "can I install games?" — that is information. Use it. If someone asked about privacy or surveillance, address it. Their questions should shape how you frame the next sessions.
If a student tries to click around extensively or starts opening settings — let them, and narrate what is happening to the whole class. Curiosity at this stage is exactly what you want. The "touch nothing" instruction is about not running commands or making changes, not about suppressing exploration.
The single biggest conceptual difference from Windows. In Windows, drives are separate trees (C:\, D:\). In Linux, there is one tree. Everything — files, devices, network connections, running processes — is a node in that tree. Understanding this makes the rest of the filesystem layout obvious rather than arbitrary.
Draw a Windows filesystem on the board: C:\Users\, C:\Program Files\, D:\, E:\. Ask: "What happens when you plug in a USB drive on Windows?" They appear as a new drive letter. "What happens on Linux?" That is what this session answers. Erase the Windows diagram. Start fresh.
Draw a single tree starting from /. Explain: this is called the root of the filesystem. Not the root user — the root directory. Every single file on a Linux system, regardless of which physical disk it is on, exists somewhere inside this tree. A USB drive plugged in does not appear as E:\ — it appears as a folder, usually somewhere like /media/username/drivename. It is mounted into the tree.
The phrase "everything is a file" in Linux means more than it sounds. Not just documents and images — hardware devices like your keyboard, your hard drive, and your screen are represented as files in /dev. Running processes appear as directories in /proc. If you can read a file, you can inspect the state of the hardware. That is a powerful idea that runs through the whole system.
Open the terminal. Run pwd — print working directory. This tells you where you are right now in the tree. Run ls to see what is here. Navigate to / with cd / and run ls again. The top-level directories on the screen match the diagram on the board. This is not a metaphor — this is the actual structure.
Side-by-side navigation. Open Dolphin (file manager) and Konsole (terminal) on screen at the same time — half screen each.
cd /home/yourname then pwd. Find the same location in Dolphin. What is identical? What is different?/etc in both. Terminal: cd /etc then ls. Dolphin: click to /etc. How many items does ls count? How many does Dolphin show? Why might they differ?/var/log in both. What is inside? Can you open any of the files?~ character: type cd ~ then pwd. What does ~ expand to?The Dolphin vs. terminal discrepancy in step 2 is intentional. Dolphin hides files starting with a dot by default. The terminal with ls also hides them. Only ls -a shows everything. Let this discrepancy surface naturally — it is the perfect setup for session 8 on hidden files. If a student notices and asks "why does ls show fewer files than I expected?", that question is worth 5 minutes of your time right now.
Some students will try flags they don't know yet — ls -l, ls -la, ls --help. Let them. Explain the flags briefly if they ask. Curiosity about flags is a sign the terminal is becoming interesting, not intimidating.
The Linux filesystem layout is not arbitrary — it follows a standard called the FHS (Filesystem Hierarchy Standard). Every major directory has a defined purpose. Teaching this removes mystery from the whole system and gives students a mental map they can rely on.
Ask: "If you wanted to change a system-wide setting — say, the computer's hostname — where would you look?" Take 3 guesses. Do not answer yet. "If you wanted to see why an application crashed yesterday, where would you look?" Take 3 more guesses. The answers are in /etc and /var/log respectively. This warm-up creates the need that the concept section will fill.
Walk through each directory with real examples open on screen as you explain. Do not just read the purpose — open the actual folder and show something inside it.
/home — Every user on the system has a subdirectory here. Your files, your settings, your documents all live in /home/yourname. No other user (except root) can read your /home directory by default. Open it and show the structure — you will already have a few hidden dotfiles from the system.
/etc — System-wide configuration as plain text files. Open /etc/hostname — it is one line containing the machine's name. Open /etc/apt/sources.list — this is the list of repositories where software comes from. Open /etc/passwd — it lists every user account on the system. Everything here is readable text that a human can understand and edit. This is by design: the OS is transparent about its own configuration.
/var — Variable data: things that change while the system runs. Logs are in /var/log. Open /var/log/syslog and scroll through — this is the system's diary. Every event that the OS considers worth noting is here. Package cache is in /var/cache/apt. Databases often live in /var/lib.
/usr — User system resources. Installed programs live in /usr/bin. Libraries they depend on are in /usr/lib. Documentation is in /usr/share/doc. When you install software with apt, most of it ends up here.
/tmp — Temporary files. Anything written here may be deleted on reboot. Programs use it for scratch space. Never put anything here that you want to keep.
Point out the pattern: the OS makes its own configuration and behaviour completely visible as readable files. You do not need a special tool to read system configuration — you need cat or a text editor. That transparency is a design principle, not an accident.
Scavenger hunt. Find and open each of the following using the terminal. For each one, write one sentence describing what you found inside.
/etc/hostname/var/log//etc/passwd — read it and figure out what each field means (fields are separated by colons)/etc/apt/sources.list/usr/bin//usr/share/ — your choice, justify why it is interesting/tmp/ — if the directory is empty, explain why/etc/passwd is reliably surprising. Students expect a file called "passwd" to contain passwords. It does not — passwords moved to /etc/shadow (which they cannot read without sudo). /etc/passwd contains usernames, UIDs, home directories, and default shells. The fields separated by colons are: username, password placeholder (x), UID, GID, description, home directory, shell. Walking through one line together takes 3 minutes and teaches UID, GID, and shell — all concepts that will reappear in week 3.
A path is an address. The distinction between absolute and relative paths is one of the most practically important concepts in the entire course — it comes up every time a student runs a command that refers to a file. Getting this right now saves significant confusion later.
Write on the board: "Go to room 3." Then write: "Go to Building A, Floor 2, Room 3." Ask: which instruction works if you are anywhere in the world? Which one only works if you are already on Floor 2? The second is an absolute address. The first is a relative one. A path in Linux works exactly the same way.
Absolute paths always start with /. They describe the full route from the root of the tree to the target. /home/username/documents/notes.txt works no matter where you currently are in the filesystem — because it starts from the very beginning of the tree. Like a complete postal address: country, city, street, number.
Relative paths start from where you currently are. If you are inside /home/username, then documents/notes.txt gets you to the same file. But that relative path would fail if you were in /etc, because there is no documents folder there. Like directions that only work if you're already in the right city.
Special shortcuts: . (a single dot) always means "the directory I am currently in." .. (two dots) always means "the directory one level up from where I am." These are not just shortcuts — they are part of every directory in the filesystem. Run ls -a anywhere and you will see . and .. listed. cd .. moves you up one level. cd ../documents moves up one level and then into a folder called documents.
Have the students type each command themselves and run pwd after each one to verify where they ended up. The physical experience of moving through the tree is more instructive than watching you do it.
Part 1 — Printed map (15 min). Students receive a printed fictional filesystem map. Eight path-writing tasks:
readme.txt in user anna's home folder./home/anna/documents. Write a relative path to get to /home/anna/pictures./etc. Write a relative path to get to /var/log./usr/bin. Write a relative path to get to the root directory /.cd ../../home/anna does if you start in /usr/local/bin.Part 2 — Terminal verification (10 min). Test 4 of your answers on the real machine. For each: run the cd command, then run pwd, and write whether your prediction was correct.
Introduce ~ (tilde) explicitly today if you have not already. cd ~ always takes you to your home directory regardless of where you are. Students will use this constantly from this point forward. It is a small thing that builds a lot of confidence — there is always a way back home.
The most common error on the printed map exercise is confusing relative paths that go up levels. Students often write ../log when they need ../../var/log. Let them make the error and discover it when they test on the terminal. The self-correction is more memorable than being told the right answer.
Two Linux filesystem behaviours that reliably surprise people coming from Windows: hidden files are not hidden for security, they are hidden to reduce visual clutter; and filenames are completely case-sensitive. Both have clear reasons. Dotfiles are also the first preview of system configuration — students will edit their own .bashrc in week 12.
Ask: "Where does your terminal store its settings? When you customise something in a program, where does it save those preferences?" Most students will not know. That is the setup for the dotfile concept. "By the end of this session you will know exactly where every application stores its personal settings for your account."
Hidden files. Any file or directory whose name begins with a dot is hidden by default. Not hidden for security — hidden because showing configuration files alongside your documents would be cluttered and confusing. Your home folder contains dozens of hidden files and directories managing the settings for every application you use. Run ls in your home folder — relatively few items. Run ls -a — significantly more. Run ls -la — all of them with full details. In Dolphin, press Ctrl+H to toggle the display of hidden files.
Common dotfiles students will encounter: .bashrc — the configuration file for the bash shell, runs every time you open a terminal. .config/ — a directory containing configuration for many modern applications. .ssh/ — SSH keys and configuration (we'll use this in Phase 5). .local/ — user-specific application data. These files are why your terminal settings, your application themes, and your preferences survive across reboots — they are all stored as plain text files in your home directory.
Case sensitivity. Linux filesystems are case-sensitive. notes.txt, Notes.txt, and NOTES.TXT are three completely different files that can coexist in the same folder. Windows is not case-sensitive — it treats these as the same file. This matters when you type commands (the command ls works; LS does not), when you navigate paths, and when you write scripts. Get into the habit of being precise about capitalisation from the start.
Part 1 — Dotfile exploration (15 min).
ls -la. Count how many hidden items exist..bashrc with cat ~/.bashrc. Read through it. What do you notice? Write down 3 things you can identify even without understanding all of it..config/ directory with ls ~/.config. What applications have stored configuration here?ls -la in the terminal. Are they showing the same things?Part 2 — Case sensitivity (15 min).
touch test.txt Test.txt TEST.TXTls to confirm all three exist as separate files.cat Test.txt. Then try cat test.txt. Different files, different contents possible.LS instead of ls. Read the error message carefully. What does it tell you?touch "my notes.txt". Then try to access it without quotes: cat my notes.txt. What happens? Now try with quotes. Why does this matter?When students open .bashrc, they will not understand most of it — and that is fine. Tell them: "This file is the first of many we will come back to. By week 12 you will be editing this file to customise your own terminal environment." Planting this seed now makes week 12 feel like returning to something familiar rather than encountering something new.
The file-with-spaces exercise is practically important. Filenames with spaces are common on files that come from Windows or macOS (downloaded files, shared documents). Students need to know how to handle them in the terminal before they encounter one in a context that matters. Quoting and escaping are concepts they will use constantly.
Linux was designed from the start as a multi-user system. Every action is tied to an identity. Understanding your identity on the machine — your username, your UID, your groups — is the foundation for understanding why permissions work the way they do.
Pose the scenario: "This machine has 5 users. Carlos, Ana, Luis, Maria, and a web server process called www-data. Each has their own files. How does the OS know which files belong to whom? And how does it stop Carlos from reading Ana's private documents?" Let the group propose solutions for 5 minutes. Their instincts — passwords, separate drives, access lists — are all partially right. The system uses all of these ideas in combination. This session explains how.
Every user on a Linux system has a numeric identity called a UID (User ID). Your username is a human-readable label, but the kernel only works with UIDs internally. UID 0 is always root — the superuser. Regular users start at UID 1000 on most modern systems. System processes and services have UIDs in the range 1–999.
Every user also belongs to one or more groups. A group is a collection of users that share access to something. Groups let you say "these three users should all be able to read this directory" without making it world-readable. Your primary group usually has the same name as your username. You can belong to many secondary groups — on a desktop Linux system, your user account typically belongs to groups like sudo (can run admin commands), audio (can use sound), video (can use the GPU), and several others.
Run whoami — your username. Run id — your full identity. The output looks like: uid=1000(username) gid=1000(username) groups=1000(username),27(sudo),44(video).... Parse this together: uid is your user ID number, gid is your primary group ID, groups lists every group you belong to with its name and number.
Ownership is enforced at the kernel level, not by the interface. It is not a visual feature that can be clicked around. When you try to read a file that does not belong to you and that you have no permission to access, the kernel itself says no — not the application, not the desktop environment.
whoami. Write down the output.id. For each field in the output, write what it means: uid, gid, groups. How many groups do you belong to?ls -la /home. What do you see? Who owns each home directory? What does the ownership pattern tell you about who can access what?ls -la /. Who owns the top-level directories? What pattern do you notice?cd /root. What happens? Read the error message. What exactly does it say?The server analogy is essential for students who have only ever used single-user computers. A web server that serves a school website should not be able to read the database configuration for student records — even if they run on the same physical machine. Linux achieves this through users and groups. The web server runs as a user (www-data) that only has access to the files it needs. This is the same principle that protects Carlos's files from Ana: ownership, not a password prompt.
Root is not just an administrator account with more access. It is an identity that bypasses the permission system entirely. Understanding this distinction — and understanding why sudo exists as a safer alternative — is one of the most practically important things a Linux user can learn. This session also contains the single most important safety habit of the entire course.
Ask: "If you could run any command on this machine with absolutely no restrictions — no permission denied, no password, no limits — what would you do?" Let a few students answer. Then: "What could go wrong?" Take the worst-case answers seriously. "Exactly. That is why you do not run as root every day."
Root (UID 0) does not just have more permissions than regular users — it bypasses the permission check entirely. When the kernel evaluates whether a process can access a file, it checks the UID of the process. If the UID is 0, the check is skipped. No file is off-limits. No system call is denied. This means root can read any file, write to any location, kill any process, and delete any directory on the system — including the directories that make the system work.
This is why you do not log in as root for daily work. One typo in a command — rm -rf /etc instead of rm -rf ./etc — and the system configuration is gone, permanently, with no recycle bin. Root gives you this power with no safety net whatsoever. There is no "are you sure?" There is no undo.
sudo is the answer to this problem. Sudo stands for "substitute user do" — it runs a single command as root (or another user), then returns your normal permissions immediately. It also logs every sudo command to /var/log/auth.log — who ran it, when, and what command. That accountability is the key difference between logging in as root (anonymous, permanent) and using sudo (logged, temporary, deliberate).
Live demo — run these in order and read every output:
cat /etc/shadow # permission denied - you cannot read this sudo cat /etc/shadow # works - root can read anything # /etc/shadow contains hashed passwords - that is why access is restricted
Now the most important safety rule of the entire course. Say this explicitly and reference it again in future sessions:
If a guide on the internet tells you to run a sudo command that you do not understand — stop. Read the command first. Understand what every part of it does before you run it. sudo rm -rf / will delete your entire system in seconds, and there is no recovery. The terminal does not warn you. It trusts that you know what you are asking. That trust is the source of its power and the source of its danger.
Two-column task. For each item below, predict whether it requires sudo or not. Then try it and write the exact result — success or the exact error message.
ls ~/cat /etc/shadowtouch ~/myfile.txttouch /etc/mytestcat /etc/hostnameecho "test" | sudo tee /etc/hostname (do not do this — write "would need sudo" and explain why)cd /rootapt install tree then sudo apt install treeAfter the table: for each error message you received, write one sentence explaining what it actually means — not "permission denied" but what specifically was denied and why.
Item 8 in the exercise — apt install tree failing without sudo — is a natural bridge to the package manager content in Phase 2. Let it land as a preview: "We'll spend a full session on apt in a few weeks, but now you understand why it needs sudo — it installs software system-wide, which requires root access." The tree command will come back in session 13.
Some students will ask if they can disable the sudo password. The correct answer is: yes, you technically can, and no, you should not. The password prompt is a friction point that makes you pause before doing something permanent with elevated privileges. That pause has saved countless systems.
The permission string on every file is a complete access policy. It has been visible in every ls -la output since session 5. This session decodes it fully. The ability to read a permission string is a foundational skill — it comes up constantly in system administration, in troubleshooting, and whenever a command fails with "permission denied."
Run ls -la ~ and put the output on a shared screen or projector. Point at the leftmost column — the string of characters like -rw-r--r-- or drwxr-xr-x. Ask: "You have been seeing this column for two weeks. What do you think it means?" Take all guesses. Write them on the board. Do not evaluate them yet — you are collecting the room's intuitions before the explanation.
Decode the permission string character by character. Take -rwxr-xr-x as the working example and annotate it on the board:
The first character is the file type. - means a regular file. d means a directory. l means a symbolic link (a pointer to another file). Then three groups of three characters follow: owner permissions, group permissions, others permissions. Each group has three positions: r (read), w (write), x (execute). A dash in any position means that permission is not set.
What do r, w, x mean? For a file: r means you can read the contents, w means you can modify or delete it, x means you can run it as a program. For a directory: r means you can list the contents (see what is inside), w means you can create or delete files inside it, x means you can enter the directory with cd. This last point is important and often misunderstood: you can have read permission on a directory (can see the list) but not execute (cannot cd into it). Both are required for useful access.
Work through several real examples from the system live. Show /etc/passwd (readable by everyone, writeable only by root), /etc/shadow (not readable by regular users at all), a script file (executable), and a home directory (accessible only to owner).
Permission decoder. For each permission string, answer: is it a file or directory? What can the owner do? What can group members do? What can everyone else do?
drwxr-xr-x-rw-r--r---rwx------drwx--x--x-rw-rw-r--lrwxrwxrwx----------drwxrwxrwx — this one is a security problem. Explain why.After completing on paper, find real files on the system with at least 4 of these permission patterns and verify your answers against ls -la.
Item 4 in the decoder — drwx--x--x — is deliberately tricky. The owner can do everything. Group members and others can execute (enter) the directory but cannot read (list) its contents. This means they can access a specific file inside if they know its exact name, but they cannot browse the directory. This is a real pattern used for shared directories where you want to allow access to specific files without revealing what else is there. Students who figure this out without prompting are thinking at a sophisticated level — call it out.
Execute on a directory being different from execute on a file is the concept that most often trips people up in this session. Make sure every student can articulate the difference before moving to session 12.
Permissions are not fixed at creation. chmod changes what the machine enforces. This session introduces symbolic mode fully and numeric mode as reference. The practical payoff is immediate: students will use chmod +x every time they write a script for the rest of the course.
Scenario: "You wrote your first script. You try to run it. Nothing happens, or you get 'permission denied'. The file exists. The path is correct. What is missing?" Let the class answer using what they learned in session 11. They should arrive at "the execute bit" independently. If they get there, session 12 opens as a solution to a problem they have already identified.
Symbolic mode is the most readable way to use chmod. The syntax is: chmod [who][operation][permission] file. Who: u (user/owner), g (group), o (others), a (all three). Operation: + (add), - (remove), = (set exactly, removing all others). Permission: r, w, x.
Numeric mode uses a three-digit number where each digit represents one of the three permission groups (owner, group, others). Each digit is the sum of: 4 (read), 2 (write), 1 (execute). So 7 = 4+2+1 = rwx. 6 = 4+2 = rw-. 5 = 4+1 = r-x. 4 = r--. 0 = ---. Common patterns to memorise: 755 — owner can do everything, others can read and execute (common for scripts and programs). 644 — owner can read and write, others can only read (common for config files and documents). 600 — owner only, no one else (common for private keys and sensitive files). 777 — everyone can do everything (almost always wrong — we will discuss why).
Why is 777 almost always wrong? It gives every user on the system full write access to a file or directory. On a single-user home machine this is low risk. On any shared system, a service or another user could modify or delete your file. The principle of least privilege says: give access only to what is actually needed, and nothing more. 755 and 644 follow this principle. 777 ignores it.
myscript.sh in your home folder.echo "this machine does what I tell it"./myscript.sh. Read the error. Write what it says.ls -l myscript.sh. What are the current permissions?chmod +x myscript.sh. Run it again. It should work now.ls -l myscript.sh again. What changed in the permission string?chmod o-r myscript.sh. Verify with ls -l.chmod 700 myscript.sh. Verify.The 777 discussion is practically important because students will encounter guides online that use it as a quick fix for permission errors. "Just chmod 777 it" is a common and lazy solution that works in the short term and creates security problems in the long term. Building the habit of thinking about who actually needs access — and giving only that — is one of the most transferable professional skills in this course. It applies to Linux permissions, to database user accounts, to API keys, to everything.
First session that is entirely practical. No new theory. Everything from weeks 1–3 applied together to build something real. Students create a personal folder structure, set permissions correctly, and use the package manager for the first time in a natural, unforced context.
Short instruction: "Today you will build your working environment for the rest of the course. No Dolphin — terminal only. Use everything you have learned. Ask if you get stuck. There is no single right answer for structure, but the permissions must be correct."
Required structure. Build all of this using only the terminal:
~/ ├── projects/ │ └── linux-course/ │ ├── week01/ (and week02 through week04) │ ├── notes/ │ └── exercises/ ├── scripts/ └── sandbox/
Commands to use: mkdir -p (creates nested directories in one command), cd, ls, pwd, echo, touch, chmod.
Requirements:
mkdir -p ~/projects/linux-course/week01 creates the full path.echo "Week 01 — the OS" > ~/projects/linux-course/week01/READMEscripts/ should be 755. sandbox/ should be 700 (private). projects/ should be 755.ls -la on each directory.sudo apt install tree. Then run tree ~ to see your full structure. If it looks right, you are done..notes in your home folder and verify it only appears with ls -a.Run tree ~ on the projector for 2 or 3 volunteers. What is different between their structures? Which permission choices made sense and why? Any mistakes found and fixed?
Note: sudo apt install tree is their first real package manager use. Do not turn it into a lesson — let it happen naturally. The full apt session is in Phase 2. Today it is just a tool they needed.
Students who finish early: ask them to write a one-page explanation of the permission choices they made and why. This deepens the decision rather than just executing it. Students who get stuck: the most common issue is forgetting the -p flag on mkdir (which creates parent directories). Let them hit the error first, then point them to man mkdir to find the flag themselves.
Intentional mistakes in a safe environment. The goal is to change the emotional response to errors: from panic and confusion to curiosity and diagnosis. Error messages are information. Reading them carefully is a skill that can be learned.
Ask the class: "What do you normally do when something doesn't work on a computer?" Collect the answers — most will involve restarting, Googling, or giving up. "Today we do something different. When something breaks, we read what it says, and we figure out what it is telling us." This session is entirely in ~/sandbox. Nothing done today can damage the system.
Every Linux error message has a structure. It tells you: what command failed, what it was trying to do, and why it failed. "Permission denied" tells you the access model stopped you — not that the command is wrong. "No such file or directory" tells you the path does not exist — check spelling, check case, check you are in the right directory. "Command not found" tells you the program is not installed or not in your PATH. Reading the error before doing anything else is the first habit of a good systems administrator.
The most important thing to understand about rm: when you delete a file with rm, it is gone. There is no recycle bin, no trash folder, no undo. The file is removed from the filesystem index and the space is marked as available. Recovery is sometimes possible with specialised tools — but not reliably, and not easily. This is not a flaw. It is a design decision: the system trusts that you mean what you say. The consequence is that you think before you delete.
All work in ~/sandbox. For each mistake: run the command, copy the exact error message, and write what it actually means — not just "error" but what specifically the system is telling you.
touch /etc/mytest.txt. Read the error. Now try with sudo. What changed?cd /root. Read the error.echo "hello" > ~/sandbox/myfile.txt. Delete it: rm ~/sandbox/myfile.txt. Try to get it back. What happens?echo "echo hi" > test.sh. Try to run it: ./test.sh. Read the error. Fix it. Run it again.cat /etc/shadow. Read the error. What is the system protecting?touch my file.txt. What happened? Now do it correctly with quotes. Try to remove it without quotes — read the error. Remove it correctly.For each mistake: write (a) the error message, (b) what it means in plain language, (c) what the correct approach would be.
Ask: "Which error message gave you the most information? Which was the most cryptic?" These two questions identify which error conventions are intuitive and which need more work in future sessions.
The rm moment is the one students remember. Some will be alarmed that the file is gone — good. Let them sit with that for a moment before moving on. Then: "This is why you think before you type. The machine trusts you. That trust is what makes it powerful and what makes carelessness dangerous." A version of this message should appear in the final synthesis session as something students can recall and articulate.
If a student accidentally deletes something important (outside sandbox), stop the session and help them recover if possible. Document what happened and use it as a real case study — with their permission — for the class. Real mistakes are better teaching moments than simulated ones.
When something breaks, the answer is often already on the machine. Man pages are the built-in documentation for every command. This session builds the habit of consulting them first — before Google, before asking someone else. That habit has a specific and important quality: it means students can work offline, on unfamiliar systems, in situations where no external resource is available.
Scenario: "Your internet is down. Your machine has a problem — a directory you cannot enter, a script that won't run, a file you cannot find. You have the terminal and nothing else. What do you do?" Today's answer is: man.
man commandname opens the manual page for any installed command. Every standard Linux command has one. Man pages have a consistent structure: NAME (what the command is), SYNOPSIS (how to call it — brackets mean optional, uppercase means your input), DESCRIPTION (full explanation), OPTIONS (every flag and what it does), EXAMPLES (when the author is helpful), and SEE ALSO (related commands). Navigate with arrow keys or Page Up/Page Down. Search within the page by typing /searchterm and pressing n to find the next match. Quit with q.
man -k keyword searches all man page titles and descriptions for a keyword — useful when you know what you want to do but not the command name. Example: man -k "list files" will suggest ls and related commands. This is the "I know what I want but not how" escape hatch.
Rescue scenario. Internet access is disabled for this exercise. Man pages and lesson notes only. Solve each problem:
locked/ exists in sandbox with permissions d---------. You cannot enter it or list it. Use man pages to find a command that can change this. Fix it without being told which command to use.mystery.sh exists and should be a runnable script, but running it does nothing. The file contains valid commands. Diagnose and fix using only what the man page for chmod tells you./etc that ends in .conf. You do not know which command does this. Use man -k to find the right command, then use it./var/log is so large that cat scrolls past everything instantly. Find a better tool for reading it using man -k "pager" or similar. Read the last 20 lines of the file.passwd file format (not the command). Hint: man pages are organised into sections — section 5 is file formats. Read the format description for /etc/passwd and verify it matches what you saw in session 6.Disabling the internet is the point of this session. The goal is not that they should never use the internet — they should and they will constantly. The goal is to build confidence that the answer is often already on the machine, and that they can find it without external help. That confidence has a different quality: it is available on any system they ever sit down at, with or without network access, with or without a phone signal. It is a durable skill, not a search skill.
Problem 3 — find — is the intended answer. Students who arrive at it through man -k without being told are demonstrating exactly the research process you want to reinforce.
No new content. No lecture. The measure of understanding is whether you can explain something to someone who does not know it. This session is diagnostic as much as it is educational — gaps in explanation reveal gaps in understanding, and those gaps inform the opening of Phase 2.
Round 1 — Pairs (20 min). Each student explains 2 concepts to their partner. The partner can interrupt and ask questions. Suggested pairs of concepts to explain:
After 10 minutes, switch: the other student explains 2 different concepts. Rotate pairs once.
Round 2 — Group (20 min). Every student stands and answers 3 questions:
Round 3 — Vocabulary relay (10 min). Go around the room. Each student defines one term from the Phase 1 glossary without notes. If stuck: they can ask the class for help (not a penalty). Continue until the glossary is covered or time runs out.
Hand out the Phase 1 vocabulary checklist. Students mark which terms they are confident with and which they are not. Collect the "not confident" answers — these open Phase 2.
Preview of Phase 2: "Starting next week, the GUI becomes optional. You will navigate, find files, install software, and manage the system entirely from the terminal. The mouse is still there — you just will not need it as much. The terminal is not a punishment. It is the most direct way to tell the machine exactly what to do. And it is faster, once you know it."
Pay close attention to which concepts students struggle to explain in Round 1. The most commonly incomplete explanations in Phase 1 tend to be: the exact difference between root (the directory) and root (the user), what execute permission means on a directory, and why sudo is preferable to logging in as root. These are the three concepts to revisit at the start of Phase 2, before introducing new material.
Do not correct during peer explanation unless something is factually dangerous or will cause concrete problems in Phase 2. Small imprecisions in understanding are normal at this stage and will self-correct as students use the concepts in practice. The act of explaining — even imperfectly — is the learning.
The vocabulary relay often reveals that students know the concept but not the term, or know the term but cannot connect it to the concept. Both are useful to know. The goal is that both improve over the next five phases, not that they are perfect today.
Phase 1 of 6 · Linux seminar · Kubuntu LTS · Ages 15–18
Phase 2 — Talking to it — begins next session