# Linux Under the Hood: What I Discovered Exploring the File System Like a System Investigator Most people start learning Linux by memorizing commands — `ls`, `cd`, `mkdir`, and so on. I did that too. But at some point, I realized something important: Linux is not about commands. Linux is about **structure**. Everything — networking, users, processes, devices — *is exposed through the file system*. So instead of practicing commands, I decided to *investigate the system itself*. This blog is a collection of the most interesting things I discovered while exploring a real Linux environment. Each section focuses on *what exists, why it exists, and what problem it solves*. ## 1\. `/etc` — The Brain of System Configuration ### What it is `/etc` contains configuration files that control almost every aspect of system behaviour. ### Why it exists Instead of hardcoding system behaviour into binaries, Linux separates configuration from execution. This makes the system flexible and editable. ### What problem it solves * Allows admins to change system behaviour without recompiling software * Centralises configuration for easier debugging and auditing ### What I found interesting Files like: * `/etc/hosts` → local DNS overrides * `/etc/resolv.conf` → DNS server configuration * `/etc/passwd` → user identity mapping This made me realise: Linux doesn’t hide its logic — it exposes it in plain text. ## 2\. DNS Resolution — `/etc/resolv.conf` ### What it is A file that defines which DNS servers your system uses. ### Why it exists When you type a domain (like google.com), your system needs a resolver to translate it into an IP address. ### What problem it solves * Enables domain name resolution * Allows custom DNS configuration (e.g., Google DNS, Cloudflare) ### Insight I noticed that sometimes this file gets overwritten automatically (e.g., by NetworkManager or DHCP). This taught me: > DNS in Linux is not static — it's dynamically managed by networking services. ## 3\. `/proc` — The Live System Mirror ### What it is A virtual filesystem that exposes **real-time system and process information**. ### Why it exists Linux treats everything as a file — even running processes. ### What problem it solves * *Provides introspection* into system state without special tools . * Allows programs to read kernel and process data easily . ### What I found fascinating * `/proc/cpuinfo` → CPU details * `/proc/meminfo` → memory usage * `/proc//` → everything about a running process This changed my mental model completely: > Processes are not abstract — they are *directories with data*. ## 4\. `/dev` — Devices as Files ### What it is A directory containing device files that represent hardware. ### Why it exists Linux uses a unified interface: *everything is treated as a file*, including hardware. ### What problem it solves * Standardises interaction with hardware . * Enables simple read/write operations for devices . ### Examples * `/dev/sda` → disk * `/dev/null` → data sink * `/dev/random` → entropy source ### Insight Instead of using special APIs, programs interact with hardware using file operations. That’s elegant system design. ## 5\. `/var/log` — The System’s Memory ### What it is A directory storing logs generated by the system and services. ### Why it exists Systems need historical data to debug issues and monitor behaviour. ### What problem it solves * Debugging failures * Security auditing * Monitoring system activity ### Interesting files * `/var/log/syslog` or `/var/log/messages` * `/var/log/auth.log` ### Insight Logs are not just for debugging — they are **evidence of system behavior over time**. ## 6\. User Management — `/etc/passwd` & `/etc/shadow` ### What they are * `/etc/passwd` → user metadata * `/etc/shadow` → encrypted passwords ### Why they exist Separates identity from authentication for security. ### What problem they solve * Secure storage of credentials * System-wide user management ### Insight Passwords are not stored in `/etc/passwd` anymore — that’s intentional for security. Also, users are just structured entries — not “accounts” in the abstract sense. ## 7\. Permissions — The Real Security Layer ### What it is Linux uses a permission model based on: * Owner * Group * Others ### Why it exists To enforce access control at the filesystem level. ### What problem it solves * Prevents unauthorised access * Controls execution and modification rights ### Insight Permissions are not optional — they are **core to Linux security**. Even root privileges operate within this model (though with override capability). ## 8\. `/boot` — The System’s Entry Point ### What it is Contains files required to boot the system. ### Why it exists Before the OS runs, the system needs a minimal environment to start the kernel. ### What problem it solves * Initialises the OS * Loads the kernel and bootloader ### Insight Files like: * Kernel images * Bootloader configs (GRUB) This made me realise: > Booting is just a staged file-loading process. ## 9\. System Services — `/etc/systemd` ### What it is Configuration for system services managed by `systemd`. ### Why it exists Modern Linux systems need a structured way to manage background services. ### What problem it solves * Service lifecycle management * Dependency handling * Startup sequencing ### Insight Services are defined declaratively using `.service` files. Linux doesn’t “run things magically” — everything is explicitly defined. ## 10\. Networking Internals — Interfaces & Routing ### What I explored * Network interface configs * Routing tables * Kernel networking data ### Where it lives * `/proc/net/route` → routing table * `/sys/class/net/` → interfaces ### Why it exists Networking must be dynamically configurable and observable. ### What problem it solves * Packet routing * Interface management * Network diagnostics ### Insight Routing is not abstract — it's literally a table the kernel follows. ## Final Realisation After exploring all these components, one idea became very clear: > Linux is not a black box. It is a **transparent system built on files and structure**. * Processes → files * Devices → files * Configuration → files * System state → files Everything is inspectable. ## Why This Matters (Especially for Developers) Understanding the Linux filesystem at this level changes how you think about systems: * Debugging becomes easier * Backend systems make more sense * DevOps concepts feel natural * You stop relying on tools blindly Instead of asking: > “Which command should I use?” You start asking: > “Where in the system is this behavior defined?” That’s a much more powerful mindset. ## Closing Thought This exploration made me realise that Linux is less about commands and more about **philosophy**: > *Expose everything. Keep it simple. Make it inspectable.* And once you see that, you stop using Linux like a user — you start understanding it like a system engineer.