DEV Community: Naval Kishor Upadhyay

Archiving & Compression in Linux — From `.tar` to `.gz` and Beyond

Naval Kishor Upadhyay — Tue, 16 Sep 2025 14:22:25 +0000

When working with files in Linux, two words often come up: archiving and compression. Many people confuse them, but they’re not the same. Archiving is about grouping files, while compression is about shrinking size. Tools like tar, gzip, bzip2, and xz often get combined to give us familiar formats like .tar.gz.

This article explains the differences, how Linux handles packaging, and why sometimes “smaller” isn’t always better.

1. Archiving vs Compressing

Archiving = putting multiple files into one container.

Think of it like putting many documents into one folder.
No size is saved, but organization improves.
Tool in Linux: tar (short for tape archive).
Output: .tar file (all files combined, but still full size).

Compressing = making a file smaller using algorithms.

Think of it like squeezing the air out of a bag of clothes.
Reduces disk space, faster transfers.
Tools in Linux: gzip, bzip2, xz.
Output: .gz, .bz2, .xz.

📌 That’s why you often see combined extensions:

.tar.gz → first archived, then compressed with gzip.
.tar.bz2 → archived, then compressed with bzip2.

👉 Without tar, you’d need to compress files one by one. With tar, you can compress whole directories at once.

2. Lossless vs Lossy Compression

Not all compression works the same way.

Lossless compression:
- No data is lost.
- When decompressed, you get the original file exactly.
- Used for text, logs, executables, source code.
- Examples: gzip, bzip2, xz.
Lossy compression:
- Some data is thrown away to make files much smaller.
- The original cannot be perfectly reconstructed.
- Used for multimedia where some quality loss is acceptable.
- Examples: JPEG (images), MP3 (audio), MP4 (video).

📌 Linux archiving tools almost always use lossless compression, because system files and source code must remain intact.

3. Tarballs and Beyond

A tarball is simply a .tar archive, often with compression added.

Examples:

.tar.gz (also .tgz) → tar archive + gzip
.tar.bz2 → tar archive + bzip2
.tar.xz → tar archive + xz

What makes tarballs powerful?

They preserve metadata:
- File names, directory structure
- Permissions and ownership
- Timestamps
This makes them perfect for:
- Backups
- Source code distribution
- Software packaging

👉 That’s why most open-source projects ship their code as tarballs.

4. The Trade-Offs of Compression

Compression saves space — but it isn’t free. It uses CPU and time. Different algorithms have different trade-offs:

gzip:
- Fast, widely supported
- Moderate compression ratio
- Great for general use
bzip2:
- Slower than gzip
- Better compression
- Often used for source code archives
xz:
- Very high compression
- Much slower
- Good when space matters more than speed

📌 Choosing the right tool depends on the situation:

Sending files quickly → gzip
Archiving source code → bzip2
Packing large backups for long-term storage → xz

👉 The smaller the file, the more CPU time and memory it usually costs to compress and decompress.

6. Key Takeaways

Archiving (tar) = grouping files, no size reduction.
Compression (gzip, bzip2, xz) = shrinking files.
Combined formats like .tar.gz do both.
Lossless compression keeps data exact; lossy permanently drops details.
Tarballs preserve directory structure, metadata, and permissions — ideal for Linux backups and source code.
Choosing gzip, bzip2, or xz is a balance of speed vs size.

Linux Filesystem Explained — From `/` to `/home` (and Everything Between)

Naval Kishor Upadhyay — Mon, 15 Sep 2025 08:25:11 +0000

When you first explore a Linux system, the directories may seem cryptic:

/bin, /etc, /usr, /var … what do they mean, and why are they there?

The truth is: the Linux filesystem is not random. It’s carefully structured, following the Filesystem Hierarchy Standard (FHS). Once you see the logic, it becomes predictable and powerful.

This guide takes you step by step through the Linux directory tree, explaining what each folder contains, why it exists, and how to explore it.

1. The Root `/` — the Starting Point

At the very top is the root directory (/).
Every file and folder in Linux grows from this one root, like branches of a tree.

📂 Example:

/home/alex/report.txt

/ → root (the trunk)
home → branch
alex → smaller branch
report.txt → the leaf (file)

Unlike Windows, Linux does not use C:\ or D:\. Disks and USB drives are mounted into this tree.

Try this:

ls /

2. System Essentials

These directories allow Linux to start and run, even before you log in.

`/bin` — Basic Commands

Stores essential tools always available.
Examples: ls, cp, mv, cat.

ls /bin | head

`/sbin` — System Commands

Utilities for system administration.
Examples: ip, mount, shutdown.

`/lib` — Shared Libraries

Libraries needed by /bin and /sbin programs.
Without these, commands won’t work.

`/boot` — Startup Files

Holds files needed to boot Linux:
- Kernel (vmlinuz)
- Bootloader (GRUB)

`/etc` — System Configuration

Contains configuration files.
Examples:
- /etc/passwd → user accounts
- /etc/hosts → hostname mappings

cat /etc/hostname

3. Programs and Applications

`/usr` — Program Files

Houses the bulk of installed software.
Key subdirectories:
- /usr/bin → executables
- /usr/share → docs, icons, locales

`/usr/local` — Locally Installed Software

For software compiled or installed by the administrator.
Keeps it separate from system-installed programs.

`/opt` — Optional Applications

Self-contained third-party software.
Example: /opt/google/chrome.

4. User Data

`/home` — User Directories

Each user has their own space.
Example: /home/alex/ → personal files and configs.

`/root` — Administrator’s Home

The root user’s home directory.
Kept separate from /home so it’s always accessible.

5. Variable Data

`/var` — Logs and State

Contains files that change during operation.
Examples:
- /var/log/ → log files
- /var/lib/ → databases
- /var/cache/ → cached files

ls /var/log

`/tmp` — Temporary Files

Used by programs for short-lived data.
Cleared on reboot.

`/var/tmp` — Longer Temporary Storage

Similar to /tmp, but files may survive reboots.

6. Devices and System Information

`/dev` — Devices as Files

Hardware appears as files.
Examples:
- /dev/sda → first hard disk
- /dev/tty → terminal
- /dev/null → discards data

ls /dev | head

`/proc` — Process and Kernel Info

Virtual files representing system state.
Examples:
- /proc/cpuinfo → CPU info
- /proc/meminfo → memory usage

cat /proc/cpuinfo | head

`/sys` — Device and Kernel Settings

Exposes kernel and device details.
Example: /sys/class/net/ shows network interfaces.

7. Mount Points

`/mnt` — Manual Mounts

Used for temporary, admin-controlled mounts.

sudo mount /dev/sdb1 /mnt

`/media` — Removable Media

Where USBs and external drives appear automatically.
Example: /media/alex/MyUSB/.

8. Other Directories

/srv → Data for services (web, FTP, etc.)
/run → Runtime info about processes and sockets (cleared at reboot)
/lost+found → Recovered files after filesystem checks
/snap, /flatpak → Application packaging (distro-specific)

9. Key Takeaways

/ is the single starting point of the filesystem.
System essentials live in /bin, /sbin, /lib, /boot.
Configurations are in /etc.
Applications go into /usr, /usr/local, /opt.
User files are stored in /home/<username>.
Logs and caches go into /var, while temp data is in /tmp.
Hardware and system info appear in /dev, /proc, /sys.
Mount points for external storage are /media and /mnt.

Once you know this structure, navigating Linux feels much more natural, and you’ll always know where to look for programs, configurations, logs, or personal data.

System Calls and Interactions in Linux

Naval Kishor Upadhyay — Mon, 15 Sep 2025 08:03:46 +0000

Linux systems rely on a clean separation between applications (user space) and the kernel (kernel space). To bridge the two, the operating system uses system calls — controlled gateways that allow programs to request kernel services safely.

Alongside system calls, Linux also has mechanisms like ring buffers for logging and the distinction between internal and external commands that affect how user actions are handled.

1. System Calls: How Programs Ask the Kernel for Help

What They Are

A system call is a special function that allows user programs to request services from the kernel.
Since user space cannot directly access hardware, system calls are the only safe pathway into kernel space.

Examples of Services

File operations: open, read, write, close.
Process control: fork, exec, exit, wait.
Memory management: mmap, brk (allocate/free memory).
Networking: socket, bind, send, recv.

How It Works (Step-by-Step)

A user program calls a standard library function (e.g., printf).
The library translates this into the appropriate system call (write in this case).
A software interrupt / trap transfers control to the kernel.
The kernel executes the request in kernel space.
The result is passed back to user space.

Diagram

2. Ring Buffers and `dmesg`: How Linux Logs What Happens Inside

Ring Buffer Concept

A ring buffer is a fixed-size, circular data structure.
When it fills up, new messages overwrite the oldest ones.
Used by the kernel to log events efficiently without growing indefinitely.

Kernel Logging

The Linux kernel uses a ring buffer to store messages about:
- Hardware detection during boot.
- Driver initialization.
- Errors and warnings.
- Debug information.

Accessing Logs

The dmesg command displays the kernel ring buffer.
Examples:
- dmesg | grep usb → check USB device detection.
- dmesg -T → show timestamps in human-readable format.

Diagram

3. Internal vs External Commands: What Really Runs When You Type

Internal Commands

Built into the shell itself (e.g., cd, echo, pwd).
Execute directly in the shell process.
No system call to start a new process is required.
Faster, but limited to shell-provided functionality.

External Commands

Separate executable programs stored on disk (e.g., /bin/ls, /usr/bin/grep).
The shell uses a system call (fork + exec) to create a new process that runs the program.
More flexible, but slightly slower because of process creation.

Why It Matters

Understanding the difference helps in scripting and debugging.
For example:
- type cd → shows it’s a shell builtin.
- type ls → shows the path to the external binary.

Final Takeaway

Linux interactions revolve around three core ideas:

System Calls provide the controlled gateway between user applications and the kernel.
Ring Buffers give the kernel an efficient way to log events, accessible with dmesg.
Internal vs External Commands determine whether a command runs instantly inside the shell or launches a separate process.

Together, these mechanisms ensure Linux stays efficient, secure, and transparent, giving both developers and users insight into how the system really works.

Linux System Architecture

Naval Kishor Upadhyay — Mon, 15 Sep 2025 07:57:35 +0000

Linux is often praised for being powerful, efficient, and flexible. Much of this comes from its underlying system architecture — how the kernel is designed, how it separates work between kernel space and user space, and how it manages core resources like processes, memory, and devices.

1. Monolithic vs Modular Kernels

Monolithic Kernel

Definition: In a monolithic kernel, nearly all operating system services run directly in kernel space.
Advantages:
- Very fast because all components can directly call each other.
- Efficient internal communication and execution.
Disadvantages:
- Large codebase, harder to maintain.
- A bug in a driver can crash the whole system.

Modular Kernel

Definition: A modular kernel allows functionality to be added or removed at runtime using loadable kernel modules (LKMs).
Advantages:
- Flexible: load only the needed drivers.
- Easier updates: replace a module without rebooting.
Disadvantages:
- Slightly slower due to extra indirection.
- Dependency management adds complexity.

2. Kernel Space vs User Space

Linux divides memory into two regions: kernel space and user space.

Kernel Space

Privileged memory area where the kernel runs.
Full access to CPU, RAM, and devices.
Manages processes, memory, and devices.

User Space

Where applications and user processes run.
Cannot directly access hardware.
Relies on system calls to request kernel services.

Interaction

Applications in user space communicate with the kernel through system calls.

3. The Kernel’s Three Big Jobs

Process Management

Creates, schedules, and terminates processes.
Ensures fair CPU time allocation.
Coordinates communication between processes.

Memory Management

Allocates and frees memory.
Provides virtual memory using disk swap.
Ensures isolation between processes.

Device Management

Provides a consistent interface to hardware via device drivers.
Manages input/output operations.
Abstracts hardware details for applications.

Final Takeaway

Linux system architecture is built on three key pillars:

Kernel design: Monolithic (fast, but less flexible) vs Modular (flexible, but slightly complex).
Memory separation: Kernel space and user space ensure stability and protection.
Core responsibilities: Process, memory, and device management keep the OS stable and efficient.

Understanding these concepts is essential for developers, sysadmins, and anyone curious about how Linux works under the hood.

Linux Boot Process: From Power-On to Login

Naval Kishor Upadhyay — Mon, 15 Sep 2025 07:51:05 +0000

Booting a Linux system is a chain of handoffs: firmware initializes hardware, a bootloader loads the kernel, the kernel prepares the system, and systemd brings user space to life.

High-Level Overview

1) Power-On, POST, and Firmware (BIOS/UEFI)

POST (Power-On Self-Test) verifies CPU, RAM, basic chipset, storage controllers, and peripherals.
Hardware initialization configures controllers (SATA/NVMe/USB, GPU, timers) so code can be read from disks/USB/Net.
Boot selection uses a firmware-defined order to choose a bootable device (SSD/HDD/USB/Network).

2) Primary vs Secondary Boot Loader

Primary boot loader (BIOS/MBR): ~446 bytes of code at disk sector 0; too small for menus/filesystems—just finds and loads next stage.
UEFI: loads an EFI executable (e.g., \EFI\GRUB\grubx64.efi, \EFI\systemd\systemd-bootx64.efi) from the EFI System Partition (ESP).
Secondary boot loader (e.g., GRUB, systemd-boot): shows a menu, accepts kernel parameters, loads kernel and initramfs.

Common kernel parameters (set by the bootloader):

root= (e.g., root=/dev/nvme0n1p2 or root=UUID=...) – tells the kernel where the real root filesystem is.
ro/rw – mount root initially read-only or read-write.
quiet/verbose – control console verbosity.
single or systemd.unit=rescue.target – maintenance boot modes.
init= – override PID 1 (rare, for rescue/debug).

3) Kernel Initialization (Early Userspace with initramfs)

Kernel decompression & start: kernel unpacks in RAM and begins execution.
Hardware bring-up: CPU & SMP, memory manager & page tables, device buses (PCI/USB), interrupts & timers.
Driver loading: built-in drivers + modules from initramfs to access storage, crypto, filesystems, etc.
Root filesystem discovery: initramfs scripts discover and mount the real root FS, then pivot_root/switch_root to it.
PID 1 start: kernel executes the first userspace process (normally /sbin/init → systemd).

4) systemd Takes Over (PID 1)

Unit files describe services, sockets, timers, mounts, targets (goal states).
Parallel startup honors dependencies (After=, Wants=, Requires=) to speed boot.
Targets replace SysV runlevels:
- rescue.target (single-user), multi-user.target (server/text), graphical.target (desktop).
Key tools: systemctl (control units), journalctl (logs), systemd-analyze (boot timing).

Example service dependencies:

network-online.target before services needing network (e.g., docker.service).
local-fs.target ensures local filesystems are mounted before dependent services.

5) Login Stage

Server consoles: systemd spawns agetty@ttyX.service for virtual TTYs (Ctrl+Alt+F1..F6).
Desktops: a Display Manager (GDM, SDDM, LightDM) provides GUI login and launches the session (GNOME/KDE/etc.).
After authentication, shell or desktop session starts and userland completes initialization (user services, autostart apps).

6) Common Failure Points & Recovery Hints

Firmware/Boot order: ensure the correct disk/ESP entry is first.
GRUB issues: from live media, chroot and reinstall grub, regenerate configs (grub-mkconfig).
Kernel panic (root FS): verify root=UUID=..., rebuild initramfs (e.g., dracut, update-initramfs), confirm modules for storage controller.
Emergency/Rescue: boot with systemd.unit=rescue.target, inspect logs journalctl -b -p err, disable problematic services with systemctl disable --now ....

Quick Reference: Useful Commands

Firmware/ESP: efibootmgr -v (UEFI entries), lsblk -f (filesystems & UUIDs)
Bootloader: grub-install, grub-mkconfig -o /boot/grub/grub.cfg
Kernel/initramfs: uname -a, lsinitramfs / lsinitrd, update-initramfs -u / dracut -f
systemd: systemd-analyze blame/critical-chain, systemctl list-dependencies, journalctl -b

Final Takeaway

From POST to login, Linux traverses predictable stages. Knowing where you are—firmware, bootloader, kernel, or systemd—turns a mysterious “it won’t boot” into a solvable problem with concrete tools and checkpoints.

Udev and Device Events: What Happens When You Plug In a USB

Naval Kishor Upadhyay — Mon, 15 Sep 2025 07:15:48 +0000

When you connect a USB stick or external drive to a Linux system, the response feels almost magical: the system recognizes the device, mounts it, and sometimes even opens a file manager window.

Behind the scenes, however, there is a well-orchestrated chain of kernel events, daemons, and device nodes working together. The central actor here is udev — the Linux device manager.

1) Kernel Detection

Event trigger: The moment you insert the USB stick, the USB controller hardware signals the kernel that a new device has been attached.
Driver binding: The kernel checks its list of drivers to see if it has a suitable one for the device. If not, it may try to load a module dynamically.
Kernel role: This entire step happens in kernel space, where hardware is directly managed.

2) Uevent Generation

Once the kernel has recognized the device, it generates a uevent (short for user event).
The uevent contains important information, including:
- Vendor and product IDs.
- The type of device (e.g., storage, input).
- The device’s connection path.
This event is the kernel’s way of telling user space: “A new device is here.”

3) Udev Daemon (udevd)

In user space, the udevd daemon constantly listens for these uevents.
Its responsibilities include:
- Parsing the uevent details.
- Applying any preconfigured udev rules.
- Creating or removing the appropriate device nodes under /dev.
Example: When a USB drive is plugged in, udev creates entries such as /dev/sdb and /dev/sdb1.

4) Device Node Creation in `/dev`

Device nodes are special files that act as communication channels to the hardware.
For a USB stick, these nodes typically appear as:
- /dev/sdb → the whole device.
- /dev/sdb1 → the first partition on that device.
Applications can now interact with the USB device just like they would with a normal file.

5) Higher-Level User Space Actions

After device nodes are created, higher-level processes may take over.
On desktop systems:
- Automount services (e.g., udisks2) can mount the device automatically.
- A file manager may open to show the new USB contents.
On servers without a GUI:
- Manual mounting is common:
```
sudo mount /dev/sdb1 /mnt/usb
```

6) Monitoring Device Events

You can observe these steps in real time using:

  udevadm monitor

This shows:
- Kernel uevents as they are generated.
- Udev’s actions in response (such as creating device nodes).
This is a powerful way to troubleshoot if a device does not appear as expected.

7) Why This Matters

Consistency: Every device follows the same flow — kernel detects, uevent is sent, udev processes it, and /dev entries are created.
Flexibility: System administrators can write udev rules to automate tasks, such as running a backup script when a specific USB drive is inserted.
Automation: Users don’t have to configure devices manually; the system handles the process in real time.

Final Takeaway

When you plug in a USB device, Linux follows a structured sequence:

The kernel detects the hardware.
A uevent is generated with device details.
The udev daemon listens and creates device nodes.
Higher-level processes mount the device or launch user-friendly actions.

This flow demonstrates the elegance of Linux: the kernel manages detection, while udev manages user-space handling, giving us a consistent and automated hardware experience.

Special Files in Linux: The Hidden Power Behind “Everything is a File”

Naval Kishor Upadhyay — Sun, 14 Sep 2025 18:11:58 +0000

Special Files in Linux: The Hidden Power Behind “Everything is a File”

Linux follows the philosophy that “everything is a file.” This means that hardware devices, inter-process communication, and even shortcuts to files are all represented using a consistent file interface. The practical enablers of this philosophy are special files, which act as gateways to devices, processes, and links.

This article focuses on special files only. It uses point-based explanations for readability while keeping complete descriptive detail.

1) Block Files

What they are: Interfaces to devices that manage data in fixed-size chunks (blocks)—commonly 512 bytes or larger—so the system can read or write a whole block at once.
Access pattern: Support random access, which lets the kernel jump directly to any block on the device without scanning earlier data—like flipping straight to page 100 in a book.
Where they live: Exposed under /dev, for example /dev/sda (first SATA/SCSI disk) or /dev/nvme0n1 (NVMe SSD).
Why they matter: Filesystems (ext4, xfs, btrfs, etc.) rely on the random-access nature of block devices to place and retrieve metadata and file content efficiently.
Common commands:
- lsblk — enumerate block devices in a tree view with sizes, types, and mount points.
- fdisk -l — inspect partition tables and partitions on attached disks.
Mental model: A block device is a book: pages (blocks) can be opened directly in any order.

2) Character Files

What they are: Interfaces to devices that send/receive data as a continuous stream of characters rather than addressable blocks.
Access pattern: Sequential by nature; data flows in order and cannot be randomly jumped like pages in a book—more like water from a tap.
Where they live: Also under /dev, with common examples like /dev/tty (terminal/keyboard) and /dev/null (a sink that discards all input).
Why they matter: Ideal for real-time I/O with human interfaces (keyboards, serial ports) and virtual devices that don’t store data but still need a uniform interface.
Demonstration:
- cat /dev/tty — read characters typed into the terminal device.
- echo "noise" > /dev/null — write and discard output with zero storage.
Mental model: A character device is a tap: the stream arrives in sequence and you consume it as it flows.

3) Socket Files (Unix Domain Sockets)

What they are: IPC endpoints represented as filesystem entries (usually in /run or /var/run) that let processes on the same host exchange messages bidirectionally.
How they work: One process listens on a socket path; other processes connect to it and exchange request/response data—akin to a private telephone line that stays inside the machine.
Example: /var/run/docker.sock enables docker CLI commands to communicate with the Docker daemon without exposing a TCP port.
Why they matter: Provide low-latency, secure communication channels for daemons and clients (database servers, system services, container runtimes) without temporary files.
Inspection: ss -x lists active Unix domain sockets; combine with lsof to see which processes own them.
Mental model: A socket is a phone line between programs, not a file of stored bytes.

4) Named Pipes (FIFOs)

What they are: Special files created with mkfifo that implement first-in, first-out byte streams between unrelated processes via the filesystem.
Behavior: One process writes; another reads in the same order. Data does not persist: once read, it’s gone. Writers block until a reader opens the FIFO (and vice versa) unless opened non-blocking.
Why they matter: Enable streaming handoffs and decoupled pipelines without intermediate on-disk files—useful for glueing tools that weren’t started in the same shell pipeline.
Minimal example:

  mkfifo mypipe
  echo "Hello World" > mypipe      # Writer blocks until a reader connects
  cat < mypipe                     # Reader receives "Hello World"

Mental model: A FIFO is a tube between programs; what goes in first comes out first.

5) Links (Hard and Symbolic)

What they are: Alternative names or references that let you access the same file content (hard links) or target path (symbolic links) through different directory entries.
Hard links: Create another directory entry pointing to the same inode and data blocks. Deleting one name does not delete the underlying content while any hard link remains.
Symbolic (soft) links: Create a small file that stores the target path. If the target is moved or deleted, the symlink becomes dangling and fails to resolve.
Use cases: Hard links are for redundancy within the same filesystem; symlinks are for flexible redirection, cross-filesystem pointers, and versioned paths (like current -> v2.3.1).
Commands:
- ln original.txt hard.txt — new hard link sharing inode with original.txt.
- ln -s original.txt soft.txt — symlink that resolves to original.txt’s path.
Mental model: A hard link is another door to the same room; a symlink is a signpost pointing to a room by address.

6) Identifying File Types Quickly

ls -l reveals the file type via the first character of the mode string:
- - regular file, d directory, b block device, c character device, s socket, p FIFO, l symlink.
stat provides detailed metadata including inode, device numbers, and link counts, which is especially helpful for distinguishing hard links (same inode) from different files.

Symbol	File Type	Example
`-`	Regular file	`notes.txt`
`d`	Directory	`/home/user/`
`b`	Block device	`/dev/sda`
`c`	Character device	`/dev/tty`
`s`	Socket	`/var/run/docker.sock`
`p`	Named Pipe (FIFO)	`/tmp/mypipe`
`l`	Link (symlink)	`shortcut → file.txt`

7) Why Special Files Matter (Unified Power)

API unification: The same syscalls—open, read, write, ioctl, close—work across devices, IPC endpoints, and regular files, which simplifies user-space programming and tooling.
Transparency & portability: Scripts and applications don’t need device-specific code paths; they interact with everything as if it were a file, improving composability and portability.
Performance & ergonomics: Block devices enable filesystems and fast random I/O; character devices support live streams; sockets and FIFOs enable efficient zero-temp-file pipelines between services.
Operational clarity: With ls -l, stat, lsblk, ss -x, and lsof, you can discover, inspect, and debug device access and IPC links using familiar file-centric tooling.

Final Takeaway

Special files turn a complex operating system into a cohesive, scriptable environment. Whether you are saving data to a disk, capturing keystrokes, streaming data across processes, or wiring services together, Linux keeps it elegant by making it all file operations—consistently discoverable, inspectable, and automatable.

VM Networking Demystified: NAT, Bridged, Host-Only, Port Forwarding, and Multi-VM Private Networks

Naval Kishor Upadhyay — Sun, 07 Sep 2025 11:28:50 +0000

When you spin up a virtual machine (VM) in VirtualBox, VMware, or Vagrant, one of the first decisions you face is: How should this VM connect to the network?

Do you want it to access the internet? Should your host computer see it? Should two VMs talk to each other? Should others on your LAN be able to reach it like a normal PC?

This is where VM networking modes — NAT, NAT Network, Bridged, and Host-Only — come into play. And when you mix in port forwarding and multi-VM setups, things can get confusing fast.

This article will cut through that confusion and explain, in simple but thorough terms, how each mode works, when to use it, and how to combine them.

1. Why VM Networking Matters

A virtual machine is like a computer inside your computer. But unlike physical computers, it doesn’t automatically have a network connection.

Depending on your needs, you might want your VM to:

Download software updates from the internet.
Act like a server that’s reachable from other devices on your LAN.
Stay isolated, but still be accessible from your host machine.
Communicate with other VMs in a private lab environment.

The right networking mode ensures you get exactly what you need — no more, no less.

2. The Core Networking Modes Explained

Let’s go through the four main networking options you’ll encounter in most virtualization tools.

2.1 NAT (Network Address Translation)

How it works:

The VM “hides” behind your host’s IP address.
From the outside world, it looks like the traffic is coming from the host.

Capabilities:

Internet Access: ✅ Yes (via host’s connection).
Inbound Connections: ❌ No (blocked unless you configure port forwarding).
VM ↔ VM Communication: ❌ No (each VM gets isolated behind NAT).

Best Use Case:

Quick internet access for downloading packages or running updates, when you don’t need external access to the VM.

2.2 NAT Network

How it works:

Similar to NAT, but all VMs connected to the same NAT network share a private subnet.
They can talk to each other while still having internet access.

Capabilities:

Internet Access: ✅ Yes.
Inbound Connections: ❌ No (unless port forwarding).
VM ↔ VM Communication: ✅ Yes (within the NAT network).

Best Use Case:

When you’re simulating multi-VM environments (like app server + database) that still need to access the internet.

2.3 Bridged Adapter

How it works:

The VM connects directly to your physical network, just like another laptop or phone.
Your router gives it its own IP address.

Capabilities:

Internet Access: ✅ Yes.
Inbound Connections: ✅ Yes (VM has its own IP on LAN).
VM ↔ VM Communication: ✅ Yes (they’re all peers on the LAN).

Best Use Case:

When you want your VM to act like a real physical machine on your network — for example, testing a web server accessible to other devices.

2.4 Host-Only Network

How it works:

Creates a completely private network between the host and VMs.
No connection to the outside world.

Capabilities:

Internet Access: ❌ No (unless paired with another adapter).
Inbound Connections: ✅ Yes, from host.
VM ↔ VM Communication: ✅ Yes (inside the private network).

Best Use Case:

For isolated test labs where you don’t want VMs exposed to the internet. Perfect for experimenting without risk.

Diagram:

3. Port Forwarding: Accessing VMs Without Public IPs

With NAT and NAT Network, your VM doesn’t have a public-facing IP. That means you can’t just ssh user@vm_ip from your host or another computer.

This is where port forwarding comes in. It’s like a tunnel through the host machine:

Set up forwarding: Map a host port (e.g., 2222) to the VM’s port (e.g., 22 for SSH).
Client connects: From your laptop, run ssh -p 2222 user@host_ip.
Host forwards: The host takes traffic from port 2222 and forwards it to the VM’s internal IP on port 22.
VM responds: You’re inside the VM as if it had a public IP.

Diagram:

Why it matters:

Lets you connect securely to VMs without exposing them directly to your network.
Essential for NAT and NAT Network setups.

4. Connecting Multiple VMs Together

Sometimes, one VM isn’t enough. Maybe you want a web server talking to a database server, or a load balancer managing multiple app servers.

Here’s how you can do it:

NAT Network → Best option if you want VMs to communicate and reach the internet.
Host-Only Network → Good for completely isolated labs, where internet access is not required.
Bridged Network → Works if you want your VMs to behave like independent physical devices on your LAN.

Example Scenario:

VM1 = Web Server
VM2 = Database Server
Both attached to a NAT Network.
VM1 can query VM2, VM2 can respond, and both can still download updates from the internet.

5. Quick Comparison Table

Here’s the cheat sheet you’ll want to bookmark:

Mode	Internet Access	VM ↔ VM	VM ↔ Host	Reachable from LAN	Best Use Case
NAT	✅ Yes	❌ No	⚠️ Only via Port Forwarding	❌ No	Single VM with safe internet
NAT Network	✅ Yes	✅ Yes	✅ Yes (with setup)	❌ No	Multi-VM labs + internet
Bridged	✅ Yes	✅ Yes	✅ Yes	✅ Yes	Realistic server testing
Host-Only	❌ No	✅ Yes	✅ Yes	❌ No	Isolated test setups

6. Wrapping It All Up

NAT → Great for single VMs needing internet.
NAT Network → Perfect for multi-VM setups with internet.
Bridged → Best when your VM should act like a real device on your LAN.
Host-Only → Ideal for isolated environments.
Port Forwarding → The secret sauce to access NAT’d VMs.
Private Networks → Enable complex multi-VM topologies without exposing them.

Once you understand these modes, you can build powerful virtual labs on your laptop that mimic real-world networks — whether you’re learning DevOps, testing servers, or simulating production environments.

Certificates and Digital Trust: Why the Web Believes a Website

Naval Kishor Upadhyay — Sun, 07 Sep 2025 11:08:22 +0000

Every time you see the little padlock icon in your browser, you’re relying on one of the most important building blocks of the internet: digital certificates. They are what convince your browser that a website really is who it claims to be, and not an impostor.

Let’s unpack how they work, why they matter, and what could go wrong without them.

1. The problem: who do you trust on the internet?

Imagine you want to log in to your bank’s website. You type the familiar address:

https://mybank.com

But how do you know the site you’re connecting to is actually your bank, and not a clever attacker pretending to be it?

The problem: anyone can set up a server and claim to be “mybank.com.” Without a trust system, your browser couldn’t tell the difference.

2. Enter certificates

A digital certificate is like an official ID card for a website.

It says “this public key belongs to this domain (e.g., mybank.com).”
It is issued and signed by a trusted authority (like an internet notary).
Your browser checks this certificate before it allows the secure connection.

Without certificates, HTTPS (the “S” in the padlock) would be meaningless — because anyone could pretend to be anyone.

3. The role of Certificate Authorities (CAs)

Certificates are issued by organizations called Certificate Authorities (CAs).

A CA verifies the identity of the website owner (using different levels of checks).
It then issues a certificate binding the website’s domain name to its public key.
This certificate is digitally signed by the CA’s private key.

Your browser comes preloaded with a list of “trusted CAs.” If a website’s certificate is signed by one of those CAs, the browser trusts it.

This creates a chain of trust

4. How your browser builds trust in a website

When you type https://mybank.com, a lot happens before the padlock appears. The browser doesn’t just take the server’s word for it — it carefully checks and challenges the certificate before declaring the connection secure.

Step 1: Website presents its certificate

The server sends your browser its digital certificate. This document includes:

the website’s domain name (mybank.com),
the website’s public key,
validity dates,
and the signature of the Certificate Authority (CA) that issued it.

At this point, the browser has the certificate, but it still needs to decide whether to trust it.

Step 2: Browser validates the certificate

The browser runs several checks:

Signature check
- Every certificate is signed by the CA’s private key.
- The browser uses the CA’s public key (already pre-installed and trusted) to verify this signature.
- If the signature matches, it proves the certificate was really issued by that CA and hasn’t been altered.
Chain of trust
- Certificates are often issued by an Intermediate CA, which itself was signed by a Root CA.
- The browser follows the chain step by step:
  - Website certificate → signed by Intermediate CA.
  - Intermediate CA certificate → signed by Root CA.
  - Root CA → already trusted in the browser.
- At each step, the parent’s public key is used to verify the child’s signature.
Domain and validity
- The certificate must list the exact domain you typed (mybank.com, not evilbank.com).
- It must be within its valid date range and not revoked by the CA.

Only if all these checks pass does the browser trust the certificate.

Step 3: Server proves it owns the private key

Now the browser knows the certificate is genuine, but there’s still one crucial question:

Does this server actually own the private key that matches the public key in the certificate?

To confirm:

The browser sends a small piece of test data (or challenge).
Only the real server, with the matching private key, can respond correctly by signing or decrypting it.
If the response checks out, the browser is sure it’s talking to the true holder of the certificate, not an impostor who copied it.

This step prevents attackers from simply stealing a certificate file and using it on their own servers. Without the private key, the certificate is useless.

Step 4: Browser and server agree on a session key

With trust established, the final step is to set up a shared session key for the actual conversation.

The browser generates a random, one-time session key.
It encrypts this session key with the website’s public key (from the certificate).
The server uses its private key to decrypt it.

Now both sides know the session key, but no one else does.

From this point on:

All communication (pages, logins, payments) is protected with symmetric encryption using that session key.
Symmetric encryption is much faster, making it ideal for ongoing data transfer.

End result: trusted, encrypted session

By combining these steps — validating the certificate, confirming the server’s private key, and agreeing on a session key — your browser can finally show the padlock. This signals:

You’re connected to the right website.
The connection is private and secure.
All further traffic will be encrypted efficiently.

5. Levels of trust in certificates

DV (Domain Validation) → Confirms domain control.
OV (Organization Validation) → Confirms legal entity.
EV (Extended Validation) → Strongest checks, often used by banks.

6. What happens if certificates didn’t exist?

Without certificates, you could be tricked into encrypting traffic with an attacker’s key. Encryption alone would not protect you — you’d be secure with the wrong person.

Certificates close this gap by binding the website’s domain to its public key, and by requiring the server to prove ownership of the matching private key.

7. Weak points in the system

Compromised CA → Fake certificates could be issued.
Expired certificates → Users see warnings until renewed.
User ignoring warnings → Clicking “Proceed anyway” breaks the trust model.

8. Everyday impact

Online banking
Shopping
Messaging apps and APIs

All rely on certificate validation and the website’s public key to prove authenticity and protect data.

9. Key takeaways

Certificates = digital ID cards for websites.
CAs = trusted notaries that issue them.
Browsers validate certificates by checking signatures with CA public keys and walking the chain of trust.
The website must also prove it controls the matching private key.
A session key is then agreed and used for fast symmetric encryption.
Without this process, HTTPS would not provide real trust.

How SSH Authentication Really Works

Naval Kishor Upadhyay — Fri, 05 Sep 2025 15:40:38 +0000

SSH (Secure Shell) is the tool that engineers use to log into servers safely. It solves two big problems:

Privacy — everything you type and receive is encrypted so outsiders can’t read it.
Identity — the server knows it’s really you, and you know it’s really the server.

Let’s walk through how SSH makes this possible, step by step.

1. The problem SSH solves

Without protection, your password or commands would travel across the network in plain text. Anyone listening could steal them. SSH was built to prevent this.

It guarantees:

Encryption so the session can’t be spied on.
Authentication so access is only granted to the right person.

2. Your digital identity: SSH keys

SSH avoids sending passwords by using a pair of keys:

Private key → stored on your laptop, never shared.
Public key → copied to the server.

3. How the login actually works

Here’s what happens when you type ssh user@server:

Connection starts

Client and server set up a secure channel so no one can listen in.
Server identity check

The server shows its own “host key.” Your computer checks it against saved records to ensure you’re not talking to an impostor.
Authentication
- The server finds your public key in its records.
- It sends you a random challenge: “Prove you own the private key.”
- Your computer signs this challenge with your private key.
- The server uses your public key to verify the signature.
- If it matches, you are authenticated — without ever sending a password.

4. Deep dive: verifying the signature

This is the heart of SSH authentication — how the server proves you really have the private key.

The server already has:

the public key you uploaded earlier
the fresh challenge it just generated

Your laptop produces a signature of that challenge using your private key.

Example:

   Signature: MEQCIF6QwG1W84yF8Lk98K1F5...aYFJ2kAbQIgJj4H

The server takes the challenge, your signature, and your public key, and runs a check:

If the signature correctly matches the challenge with that public key → ✅ you must own the private key.
If not → ❌ login is denied.

Why this works:

Only the correct private key can produce a valid signature for that challenge.
The challenge is random each time, so an old signature can’t be replayed.
The private key never leaves your laptop, so there’s nothing to steal in transit.

5. Why this is secure

No password is sent over the network — nothing reusable to steal.
The private key stays with you — only a mathematical proof (signature) is shared.
Replay attacks are blocked — each login uses a fresh challenge.
The server itself is verified — SSH warns you if a server’s identity suddenly changes.

6. Benefits in practice

Safer than passwords — prevents brute-force guessing and credential theft.
Easy to manage — add/remove public keys to control access.
Automation-friendly — scripts and systems can log in without storing passwords.
Scales to teams — each engineer gets their own key; revoking access is as simple as removing one line.

7. What can go wrong

If your private key file is stolen and not protected by a passphrase, an attacker can impersonate you.
If you ignore SSH’s warning about a changed server identity, you may connect to an impostor.
If teams share keys, you lose accountability — you can’t tell who did what.

Key takeaways

SSH doesn’t rely on sending passwords — it proves identity with keys and signatures.
The server challenges you, and your private key signs the challenge.
If the server can verify the signature with your public key, it knows it’s really you.
After login, all communication is encrypted with a fast shared key.
The system is secure because the private key never leaves your device.

Symmetric vs Asymmetric Encryption — Explained Clearly

Naval Kishor Upadhyay — Thu, 04 Sep 2025 14:27:43 +0000

Symmetric vs Asymmetric Encryption — Explained Clearly

Encryption is like putting your information into a locked box before sending it. Only the person with the right key can open the box and read what’s inside. This is how we protect private data when it travels over the internet or sits on your computer.

But not all locks and keys work the same way. There are two major types of encryption:

Symmetric encryption — one key does both the locking and unlocking.
Asymmetric encryption — two different but related keys work together: one locks, the other unlocks.

Both are essential to digital security. Let’s break them down step by step.

1. Symmetric encryption: one key, two uses

Think of a safe with a single key.

If you want to lock something inside, you use that key.
If your friend wants to open it, they need the exact same key.

That’s symmetric encryption: the same key is used to scramble (encrypt) and unscramble (decrypt) information.

Why it’s useful

Fast and efficient → great for protecting large amounts of data.
Simple to understand → one shared secret does the job.

The big challenge: key distribution

Both people need the same key. But how do you give someone that key without anyone else seeing it?

If you send it by email → a hacker reading your email now has the key.
If you tell it over the phone → someone listening in now has the key.
If the key is leaked even once, all the information protected by it can be read.

This is called the key distribution problem. It’s the main weakness of symmetric encryption.

2. Asymmetric encryption: two keys, two roles

Symmetric encryption struggles with sharing the key. That’s where asymmetric encryption comes in. It uses a key pair:

A public key → can be shared with everyone.
A private key → kept secret, only the owner should have it.

The magic is:

If you lock something with the public key, only the matching private key can unlock it.
And if you “lock” (sign) something with the private key, anyone with the public key can check it really came from you.

Why it’s useful

No need to secretly send the key → you can publish your public key, and people can still send you secrets safely.
Can prove identity → by using private key signatures, you can prove identity and ensure integrity.

Weakness

Slower → not efficient for encrypting large amounts of data.
Trust issue → people need to be sure that the public key they got is really yours, not an attacker’s.

3. Digital signatures: proving identity and integrity

One of the most powerful things you can do with asymmetric keys is create a digital signature.

Think of it like signing a contract:

Only you can produce your handwritten signature.
Others can check the signature matches yours.
If the contract is altered, the signature no longer matches.

In the digital world:

You use your private key to sign data.
Anyone with your public key can verify the signature.

This proves:

Authenticity → the data really came from you.
Integrity → the data hasn’t been tampered with.

⚠️ Important: a signature does not hide the message — it only proves who sent it and that it hasn’t changed. If you also want secrecy, you combine with encryption.

4. How the two worlds work together

Modern systems don’t pick one or the other — they combine both:

Asymmetric encryption (public/private keys) is used to safely share a secret key and to prove identity with signatures.
Symmetric encryption then takes over to encrypt the actual data, because it’s much faster.

Example: HTTPS (the padlock in your browser).

Step 1: Your browser checks the website’s certificate (which contains a public key).
Step 2: The website proves it owns the private key by using signatures.
Step 3: Browser and server agree on a shared session key.
Step 4: All data (your login, credit card number, etc.) is now encrypted with symmetric encryption for speed.

5. Strengths side by side

Aspect	Symmetric Encryption	Asymmetric Encryption
Keys	One shared secret key	Key pair: public (share) & private (keep)
Speed	Very fast	Slower
Key exchange	Hard to do securely	Easy: just share public key
Identity & authenticity	Not built-in	Possible with digital signatures
Best use case	Bulk data encryption	Safe key exchange & identity proof

6. Key takeaways

Symmetric encryption = one shared key, fast, but hard to share securely.
Asymmetric encryption = public/private key pair, slower, but solves key sharing and enables digital signatures.
Digital signatures = use the private key to prove identity and protect integrity.
Real-world security = combine both: asymmetric for trust and key exchange, symmetric for speed and protecting actual data.

Web Servers and Hosting Fundamentals: From Static Pages to Dynamic Applications

Naval Kishor Upadhyay — Thu, 04 Sep 2025 13:44:59 +0000

When you open a browser and type in a web address, a whole chain of events takes place behind the scenes before a page finally appears on your screen. At the heart of this process are web servers, application servers, frameworks, and the models that govern how websites deliver content. Understanding these building blocks is essential for anyone who wants to grasp how the modern web actually works.

What Exactly is a Web Server?

At its core, a web server is a piece of software that listens for requests from clients (usually browsers) and responds with content. This content might be something as simple as an HTML file or as complex as a dynamically generated dashboard.

There are two ways to think about web servers: software and hardware. A software web server is a program like Apache HTTP Server, Nginx, or Microsoft IIS. These programs handle requests, process headers, serve files, and manage logging. A hardware web server, on the other hand, refers to the physical machine that runs this software.

While modern cloud environments blur this distinction — since your “server” might be a virtual machine or even a container — the logic remains the same: a web server listens, interprets, and responds.

Static vs Dynamic Websites

To understand how servers deliver content, it helps to look at the difference between static and dynamic websites.

A static website is the simpler of the two. Each page is pre-built and stored as a file on the server. When a client requests the page, the server simply delivers the file as-is. Nothing changes unless the developer edits and redeploys the files. This makes static sites extremely fast and reliable, but limited in functionality. They are great for personal portfolios, documentation, or informational company pages.

A dynamic website, in contrast, generates content on demand. Instead of serving pre-written files, the server executes code — written in languages like PHP, Python, or Ruby — to build the page on the fly. If you log into an e-commerce store and see your personal order history, that content is being generated dynamically. The server retrieves your data from a database, injects it into a template, and delivers a personalized page.

Web Server vs Application Server: The Key Difference

Although the terms are often used interchangeably, web servers and application servers are not the same thing. They serve different but complementary roles.

A web server is optimized for delivering static files quickly. It is like a skilled librarian who instantly finds and hands you a book from the shelf. Web servers are excellent at sending HTML, CSS, JavaScript, or image files without modification. They are lightweight and extremely fast.

An application server, on the other hand, is designed to run your business logic. It is more like a chef in a restaurant: you give an order (the request), and the chef prepares the dish fresh based on ingredients (the data in your database). Application servers execute code, connect to databases, and build dynamic responses before handing them back to the client.

A Practical Example

Imagine an online bookstore:

When a customer visits the homepage, the banner image, stylesheet, and JavaScript files are all static content. These are best served directly by a web server like Nginx. The server simply grabs the files from disk and sends them to the browser.
When the same customer searches for “science fiction,” things change. The request must go deeper: the application needs to query a database for matching titles, calculate availability, and maybe even personalize results based on past purchases. This is handled by the application server. In a Python-based system, this might be Gunicorn; in a Java system, it could be Tomcat.
In a production setup, both usually work together. The web server sits in front, handling static files and passing dynamic requests to the application server. This division of labor keeps the system efficient: the librarian handles quick lookups, while the chef focuses on preparing custom orders.

The Role of Web Frameworks

Developers rarely write web applications from scratch. Instead, they rely on web frameworks, which provide pre-built tools and libraries to handle common tasks like routing, authentication, and rendering templates.

Some frameworks cover everything from the front-end to the back-end, and are known as full-stack frameworks. Django in Python or Ruby on Rails in Ruby are prime examples. They allow you to build an entire application quickly by providing batteries-included functionality.

Other frameworks are deliberately small and lightweight, focusing only on the essentials. These are called microframeworks, and Flask in Python or Express.js in Node.js are widely used examples. They are ideal when you want maximum flexibility or when building smaller services such as APIs.

On the client side, frontend frameworks like React, Angular, and Vue.js help structure the user interface. They manage the state of your application, handle user interactions, and make single-page applications possible. The choice between these frameworks depends on the complexity of your project, your performance needs, and your team’s expertise.

Performance Considerations

When it comes to performance, the distinction between web servers and application servers becomes even more important. A web server serving static files is extremely fast because it simply streams files to the client. An application server, however, consumes far more resources because it must run code and often query databases.

This is why modern architectures often use a reverse proxy setup, where a web server sits in front, handling static traffic and only forwarding dynamic requests to the application server. This keeps the system efficient and scalable, preventing the heavier application layer from becoming a bottleneck.

Conclusion

Understanding the difference between web servers and application servers is more than just a technical curiosity. It is the foundation of how modern websites and applications are built. The web server is the quick, reliable librarian that retrieves pre-written files, while the application server is the chef that prepares fresh, dynamic responses. Together, they create the seamless experience we often take for granted when browsing the internet.

By grasping these fundamentals — and seeing them in action through examples like an online bookstore — you gain the clarity needed to design, troubleshoot, and scale real-world applications.

DEV Community: Naval Kishor Upadhyay

Archiving & Compression in Linux — From `.tar` to `.gz` and Beyond

1. Archiving vs Compressing

2. Lossless vs Lossy Compression

3. Tarballs and Beyond

4. The Trade-Offs of Compression

6. Key Takeaways

Linux Filesystem Explained — From `/` to `/home` (and Everything Between)

1. The Root / — the Starting Point

2. System Essentials

/bin — Basic Commands

/sbin — System Commands

/lib — Shared Libraries

/boot — Startup Files

/etc — System Configuration

3. Programs and Applications

/usr — Program Files

/usr/local — Locally Installed Software

/opt — Optional Applications

4. User Data

/home — User Directories

/root — Administrator’s Home

5. Variable Data

/var — Logs and State

/tmp — Temporary Files

/var/tmp — Longer Temporary Storage

6. Devices and System Information

/dev — Devices as Files

/proc — Process and Kernel Info

/sys — Device and Kernel Settings

7. Mount Points

/mnt — Manual Mounts

/media — Removable Media

8. Other Directories

9. Key Takeaways

System Calls and Interactions in Linux

1. System Calls: How Programs Ask the Kernel for Help

What They Are

Examples of Services

How It Works (Step-by-Step)

Diagram

2. Ring Buffers and dmesg: How Linux Logs What Happens Inside

Ring Buffer Concept

Kernel Logging

Accessing Logs

Diagram

3. Internal vs External Commands: What Really Runs When You Type

Internal Commands

External Commands

Why It Matters

Final Takeaway

Linux System Architecture

1. Monolithic vs Modular Kernels

Monolithic Kernel

Modular Kernel

2. Kernel Space vs User Space

Kernel Space

User Space

Interaction

3. The Kernel’s Three Big Jobs

Process Management

Memory Management

Device Management

Final Takeaway

Linux Boot Process: From Power-On to Login

High-Level Overview

1) Power-On, POST, and Firmware (BIOS/UEFI)

2) Primary vs Secondary Boot Loader

3) Kernel Initialization (Early Userspace with initramfs)

4) systemd Takes Over (PID 1)

5) Login Stage

6) Common Failure Points & Recovery Hints

Quick Reference: Useful Commands

Final Takeaway

Udev and Device Events: What Happens When You Plug In a USB

1) Kernel Detection

2) Uevent Generation

3) Udev Daemon (udevd)

4) Device Node Creation in /dev

5) Higher-Level User Space Actions

1. The Root `/` — the Starting Point

`/bin` — Basic Commands

`/sbin` — System Commands

`/lib` — Shared Libraries

`/boot` — Startup Files

`/etc` — System Configuration

`/usr` — Program Files

`/usr/local` — Locally Installed Software

`/opt` — Optional Applications

`/home` — User Directories

`/root` — Administrator’s Home

`/var` — Logs and State

`/tmp` — Temporary Files

`/var/tmp` — Longer Temporary Storage

`/dev` — Devices as Files

`/proc` — Process and Kernel Info

`/sys` — Device and Kernel Settings

`/mnt` — Manual Mounts

`/media` — Removable Media

2. Ring Buffers and `dmesg`: How Linux Logs What Happens Inside

4) Device Node Creation in `/dev`