OS Architecture, Kernel, Shell & File System

Source: Dev.to

🐧 Linux for DevOps — Session 2: Understanding the Kernel, Shell, OS Architecture & File System

📓 Learning in public — These are my personal notes from my Linux for DevOps & Cloud journey. I’m sharing them in a way that’s easy to revisit later and hopefully useful for anyone else starting out. In the previous session, I got comfortable with Linux basics and terminal access. This session focused on understanding what actually happens behind the scenes when we run commands, how Linux is structured internally, and how files are organized on the system. These concepts might sound theoretical at first, but they’re the foundation of everything you’ll do in DevOps—from managing EC2 instances and Docker containers to troubleshooting production servers. The kernel is the most important component of Linux. Think of it as a translator sitting between software and hardware. Applications can’t directly talk to the CPU, RAM, disks, or network interfaces. Instead, every request goes through the kernel. When you run a command, open a browser, start a Docker container, or deploy an application, the kernel is responsible for making it happen. Its main responsibilities include:

Responsibility Purpose

Resource Management Decides which process gets CPU time

Memory Management Allocates and releases RAM

Process Management Creates, schedules, and terminates processes

Device Management Communicates with hardware through drivers

Without the kernel, Linux would simply be a collection of files with no way to interact with hardware. Not every operating system uses the same kernel design. Monolithic Kernel (Linux) keeps most operating system services inside a single kernel space. This approach is extremely fast because components communicate directly. Microkernel keeps only essential functionality in kernel space and moves other services outside. This improves isolation and stability but introduces additional overhead. Hybrid Kernel combines elements of both approaches. Windows NT follows this model. One reason Linux dominates cloud computing is that its monolithic architecture delivers excellent performance for server workloads. ☁️ DevOps Context When you launch an AWS EC2 instance, you’re ultimately running on a Linux kernel. Understanding kernel behavior becomes important when diagnosing CPU bottlenecks, memory pressure, or process scheduling issues in production environments. Linux follows a layered architecture. User ↓ User Space ↓ Shell & Libraries ↓ Kernel ↓ Hardware

Every action travels through these layers before reaching the physical machine. At the top is User Space, where applications such as browsers, terminals, and editors operate. The Shell acts as an interpreter that converts your commands into instructions the operating system understands. Libraries provide reusable functionality that applications rely on rather than implementing everything from scratch. The kernel then translates those requests into hardware operations involving the CPU, memory, storage, and network devices. This distinction appears in interviews constantly. A program is simply a file containing instructions stored on disk. A process is a program that has been loaded into memory and is actively executing. For example: nginx installed on disk = Program Running nginx service = Process Every process running on a Linux machine has its own Process ID (PID). 🐳 DevOps Context Docker containers are essentially isolated Linux processes that share the host’s kernel. Unlike virtual machines, containers don’t require a separate operating system, which is why they start quickly and consume fewer resources. The shell acts as a bridge between users and the kernel. When you type a command like: ls -la

the shell interprets it and forwards the appropriate system calls to the kernel. Several shell types exist, but one dominates the DevOps world:

Shell Common Usage

sh Original Unix shell

bash Default Linux shell and DevOps standard

zsh Interactive shell with productivity features

fish Beginner-friendly shell

nologin Prevents interactive logins

Bash is everywhere. CI/CD pipelines, provisioning scripts, automation jobs, EC2 user-data scripts, and infrastructure deployments often rely on Bash. If you’re working with: GitHub Actions Jenkins GitLab CI/CD Terraform bootstrapping Linux automation you’ll almost certainly encounter Bash scripting. That’s why becoming comfortable with Bash early pays off enormously. One thing that initially confused me coming from Windows was Linux’s file system structure. Windows separates storage into drives: C: D: E:

Linux takes a completely different approach. Everything begins from a single root directory: /

Every file, directory, process, and device exists somewhere beneath this root. Some directories are especially important for DevOps work:

Directory Purpose

/home User home directories

/root Root user’s home directory

/etc Configuration files

/var Logs and application data

/tmp Temporary files

/proc Kernel and process information

/bin Essential commands

/sbin Administrative commands

If you’re troubleshooting Linux servers, you’ll spend a surprising amount of time inside /etc and /var. An absolute path starts from root and works from anywhere: /home/tejas/projects/deploy.sh

A relative path depends on your current location: projects/deploy.sh

For personal use, both are fine. For scripts, automation, and CI/CD pipelines, absolute paths are generally safer and more predictable. Once you understand the filesystem, navigation becomes straightforward. pwd # show current directory cd ~ # go to home directory cd / # go to root directory cd .. # move one level up whoami # current user history # command history

The command I probably use most often is: pwd

It’s a simple way to verify where I am before making changes. Creating directories is easy: mkdir test_dir

However, in real-world automation you’ll almost always prefer: mkdir -p project/src/app

The -p flag creates missing parent directories automatically and doesn’t fail if directories already exist. That’s exactly the behavior you want inside deployment scripts. Creating files is equally straightforward: touch notes.txt

To edit files, Linux commonly uses: vi file.txt

or nano file.txt

Most servers ship with vi, so learning a few basic commands is worthwhile. i → Insert mode Esc → Normal mode :wq → Save and quit :q! → Quit without saving

Several commands exist for viewing file contents. For small files: cat file.txt

For large files: less file.txt

I quickly learned that less is usually better than more because it supports searching and backward navigation. Useful commands include: head -n 5 file.txt tail -n 5 file.txt

These are perfect when you’re only interested in the beginning or end of a file. One command shows up constantly in production environments: tail -f /var/log/nginx/error.log

The -f flag follows the file and displays new lines in real time. When applications fail, logs are usually the first place to investigate. A common pattern is: tail -f app.log | grep ERROR

This streams only error messages as they occur. This session helped connect several important Linux concepts together: The kernel manages resources and interacts with hardware. Linux uses a layered architecture from user space down to hardware. Bash is the standard shell for DevOps automation. Linux organizes everything under a single root directory. /etc and /var are critical directories for system administration. mkdir -p is safer for scripts than plain mkdir. less is usually more useful than more. tail -f is one of the most valuable troubleshooting commands in production. The more I learn Linux, the more I realize that nearly every DevOps tool—Docker, Kubernetes, Terraform, Jenkins, Ansible, and cloud platforms—ultimately builds on these fundamentals. Mastering Linux isn’t a separate DevOps skill. It’s the foundation underneath all of it.