Most Linux tutorials start the same way. ls to list files. cd to change directories. mkdir to make a folder. And then you close the tab feeling like you learned something but the next day you're still Googling "how to check RAM on Linux."

That's because those tutorials teach you commands, not Linux.

This assignment asked us to explore the Linux file system like a detective not run commands, but actually investigate what's happening under the hood. So I opened a terminal, started poking around, and honestly? I couldn't stop. Here's everything interesting I found.

Finding 1: /proc Isn't Actually a Real Folder .

The first thing that broke my brain /proc exists on every Linux system, but it takes zero bytes of disk space.

How? Because it's a virtual filesystem it doesn't live on your hard drive at all. The kernel generates it live in memory, on demand, every time you read from it.

cat /proc/version
# Linux version 4.4.0 #1 SMP Sun Jan 10 15:06:54 PST 2016

cat /proc/uptime
# 14.12  0.00
# ↑ seconds running  ↑ idle time

cat /proc/loadavg
# 0.00 0.00 0.00
# ↑ CPU load: 1min, 5min, 15min averages

What it does: Exposes the kernel's live internal state as readable files — CPU info, memory, running processes, network connections, everything.

Why it exists: Tools like top, htop, and ps don't have some secret connection to the kernel they just read files from /proc. If those tools aren't installed, you can still get the same data directly.

The insight that got me: Nothing in /proc is ever written to disk. Every single "file" is generated fresh the moment you read it. It's less of a folder and more of a window into the kernel's brain.

Finding 2: /proc/self — A Process Reading Its Own Mind

/proc/self is a symlink that always points to the directory of whatever process is currently reading it. So when you run cat /proc/self/status, the cat process is literally reading information about itself. That's kind of wild.

Here's what I actually got back from a live system:

Name:     cat
State:    R (running)
Pid:      40
PPid:     18          ← parent process (the shell)
Uid:      0 0 0 0    ← real, effective, saved, filesystem UID
VmSize:   10888 kB   ← virtual memory claimed
VmRSS:    3000 kB    ← RAM actually in use right now
Seccomp:  0
CapEff:   00000000a82c35fb

What it does: Every running process gets its own /proc/[PID]/ directory. Inside it is that process's complete state memory usage, open files, signal masks, security capabilities, and more.

Why it exists: Debuggers, monitoring tools, and the kernel itself use this to inspect processes without needing any special system calls.

The insight that got me: Look at VmSize (10888 kB) vs VmRSS (3000 kB). The process claimed 10 MB of virtual memory but is only using 3 MB of actual RAM. This is why memory usage on Linux always looks confusing virtual and physical memory are two very different things. Also, CapEff: 00000000a82c35fb that's a bitmask of Linux capabilities. Being root doesn't mean "do anything" on modern Linux. Capabilities are granular. A process can have filesystem read access without having network bind access.

Finding 3: /proc