Linux Things You NEED To Know

Main ideas / lessons (5 Linux concepts)

• Don’t treat production servers like identical black boxes to your laptop
  • Many developers write on Mac/Windows, but much cloud infrastructure runs Linux.
  • The “biggest lie” is “it works on my machine”—server environments differ, and issues (e.g., memory leaks) can fail quickly in production.

---

1) Everything is a file — Virtual File System (VFS)

Core concept

Linux uses the abstraction “everything is a file.” The kernel represents different things—text files, directories, hardware, sockets, and running processes—through a unified model: streams of bytes.

What VFS is

A Linux kernel subsystem that provides an abstraction layer between:

• User-space applications
• Underlying storage file systems

How applications use it

Applications interact via standard POSIX system calls, such as:

• open
• read
• write

How an entity becomes “a file system” in the kernel’s view

It must implement standard operations on named persistent objects.

Concrete examples

• /dev (device files)

  • Hardware is represented as files so user-space can interact without custom kernel modules.
  • Examples:
    • /dev/sda = primary hard drive
    • /dev/tty1 = terminal/keyboard session
    • /dev/null = black hole (discard data instantly)

• /proc (process files / live kernel view)

  • Virtual directory/files that don’t occupy physical disk space.
  • Acts like a live feed of RAM / kernel state.
  • Examples:
    • /proc/meminfo = current RAM usage
    • /proc/4022/environ = environment settings for a process (example PID 4022)

• /sys (system files / configuration)

  • Similar to /proc, but oriented toward configuration rather than monitoring.
  • Exposes kernel internals (variables) to view/change behavior.
  • Used to inspect/configure things like:
    • kernel parameters
    • power management states

Workflow impact

Because resources are exposed as file-like things, you can use standard CLI tools:

• cat
• grep
• echo

---

2) Process lifecycle — fork, exec, signals, and cleanup

Processes form a hierarchy

Each process has:

• a parent process ID (PPID)
• a process ID (PID)

This hierarchy traces back to PID 1, typically systemd.

Creating new processes

Two key system calls:

• fork

  • Duplicates the running parent:
    • copies file descriptors
    • copies memory footprint into the child

• exec

  • Replaces the child’s memory with a new executable binary
  • Used to run a script or compiled program

Termination and zombie/orphan handling

• When code terminates, it sends an exit code to its parent.
• If the parent crashes or doesn’t collect it:
  • the child becomes a zombie (dead but still occupies a kernel process table slot)
• If the parent disappears:
  • the child becomes an orphan
  • PID 1 adopts it to clean up resources

Managing behavior with signals

• Ctrl+C → SIGINT
  • Apps can catch it to flush buffers and exit gracefully.
• kill -9 → SIGKILL
  • Cannot be caught/ignored.
  • The kernel immediately tears down memory and terminates the process.

---

3) File descriptors & standard streams (0/1/2), plus redirection and piping

File descriptor concept

When a process opens files, sockets, or other I/O channels, the kernel assigns a non-negative integer called a file descriptor.

Default standard streams

• 0 = standard input (reads from here)
• 1 = standard output (normal output)
• 2 = standard error (diagnostic/errors)

Why terminal redirection works

The shell reroutes file descriptors:

• Redirect stdout (fd 1) to output.log
• Redirect stderr (fd 2) to error.log

Why piping works

The pipe connects:

• stdout (fd 1) of the first command
• → stdin (fd 0) of the second command

Practical debugging lesson

A “Too many open files” error in production often indicates:

• leaking network connections or file handles
• hitting kernel-enforced per-process descriptor limits

It’s not typically “disk space” related (despite how subtitles frame it).

---

4) Linux permissions & ownership (user/group/others; chmod octal)

Multi-user security model

Security is enforced at the file system layer. Each file/directory has:

• an owner user
• a group

Permission structure

Permissions are split into three tiers:

• user
• group
• others

Each tier includes flags:

• read (r)
• write (w)
• execute (x)

Octal notation used by chmod

Values:

• read = 4
• write = 2
• execute = 1
• none = 0

Sum gives the permission number per tier.

Example: chmod 755 script.sh

• Owner gets 7 = 4+2+1 → read/write/execute
• Group gets 5 = 4+1 → read/execute only (no modify)
• Others gets 5 = 4+1 → read/execute only (no modify)

Security lesson for services

Running web servers (e.g., Nginx/Apache) as root is described as a critical vulnerability:

• if compromised, the attacker gets root privileges

Mitigation:

• run as a low-privilege user (example: www-data)
• limit access to sensitive files like SSH keys and system binaries

---

5) Namespaces & cgroups (containers aren’t lightweight VMs)

Core claim

Containers aren’t “native container objects” inside the kernel. A container is an isolated process using:

• namespaces
• cgroups

Namespaces = isolation (“what you can see”)

The kernel creates a per-process illusion. Examples:

• PID namespace
  • process believes it is PID 1
  • hides other system processes
• net namespace
  • provides virtual network loopback separate from host adapters
• mount namespace
  • mounts a unique filesystem root (container image)
  • prevents seeing the host storage tree

cgroups = resource limiting (“what you can consume”)

Prevents one container from exhausting host resources. Example:

• cap a process tree to 1 CPU core and 512 MB RAM
• if exceeded, the kernel OOM killer terminates that process

Key outcome

You’re not running a lightweight VM:

• it’s a native Linux process that is:
  • blinded by namespaces
  • bounded by cgroups

---

Additional content in the subtitles (sponsor + promotion)

Sponsor: Gobi

• Positioned as an AI agent platform for deploying autonomous “co-workers”
• Claimed capabilities:
  • operates inside a real browser
  • automates workflows 24/7
  • navigates websites, clicks, fills forms, interacts with JS-heavy apps
• Interaction channels:
  • chat, email, SMS, or API integrations
• Team features:
  • shared workspaces, permissions, audit trails
• Deployment:
  • Gobi Cloud or self-host (open source) for security/control

Self-promotion / ad: CodeCrafters

• Focus: building “hard things” by creating developer tooling from scratch
• Examples mentioned:
  • Redis, Git, Kafka, Docker
  • “modern AI tools like Cloud Code”
• Includes a free newsletter about system design and back-end development, plus a discount link

---

Speakers / sources featured

• Unnamed narrator(s)/host (no specific person identified)
• Gobi (sponsor/company)
• CodeCrafters (promotion/company)
• Referenced system component: systemd (PID 1, mentioned as “usually systemd”)