DEV Community: Asep Sayyad

How to Search Anything in Linux: The Complete Terminal Survival Guide

Asep Sayyad — Fri, 14 Aug 2026 14:15:41 +0000

Whether you are managing cloud servers, debugging local applications, or building open-source projects, searching is the most essential skill in your terminal toolkit. Linux stores everything as a file, process, or network socket. If you know the right tools, you can search across millions of files, system logs, processes, and active ports in seconds.

Here is a practical, step-by-step guide to searching anything in Linux.

1. Finding Files and Directories by Name, Size, and Date

When you know a file exists but forgot where it lives, file search tools are your first line of defense.

The Classic find Tool

The find utility is built into every Linux distribution. It searches live directory trees based on real-time filesystem checks.

Search for a file by exact name in the current directory:

find . -name "config.yaml"

Search case-insensitively for any file ending in .log:

find /var/log -iname "*.log"

Filter specifically for files or directories only:

find /srv/app -type f -name "*.json"
find /srv/app -type d -name "cache"

Searching by File Size

When disk space runs out, finding large files fast is vital. Use the -size flag to isolate files over a certain threshold:

find /var -type f -size +100M

This command scans /var for regular files larger than 100 megabytes. You can use k for kilobytes, M for megabytes, and G for gigabytes.

Searching by Modification Time

If an incident started twenty minutes ago, look for files created or modified within that window:

find /etc -mmin -30

To search for files modified more than 7 days ago:

find /tmp -mtime +7

Executing Actions on Found Files

Instead of passing file lists manually, find lets you execute actions directly:

find /tmp -type f -name "*.tmp" -delete

Or pass results to another command safely using -exec:

find /var/log -type f -name "*.old" -exec rm -f {} \;

Fast Modern Alternative: fd

While find is universal, its syntax can be verbose. A fast, modern replacement written in Rust is fd.

Install fd on Ubuntu or Debian:

sudo apt update && sudo apt install fd-find

fd simplifies syntax, runs multi-threaded searches, colors output, and ignores hidden files and .gitignore rules by default.

Search for any file containing "nginx" in its name:

fd nginx

Search for a specific extension in a target directory:

fd -e md -e txt . /home/user/docs

Include hidden files and gitignored paths when needed:

fd -H -I "secret"

2. Instant Filesystem-Wide Search with locate and plocate

Running find across the entire root directory / can take time because it hits the disk for every directory traversal. When you need instant results across the whole system, use locate.

How locate Works

locate does not scan your hard drive live. Instead, it reads a pre-built database index file (/var/lib/mlocate/mlocate.db or /var/lib/plocate/plocate.db).

Search for any file or path containing "ssl":

locate nginx.conf

The output returns instantly, even on systems with millions of files.

Updating the Search Database

Because locate reads a database, newly created files won't show up right away. Update the index manually before searching:

sudo updatedb

On modern distributions like Ubuntu 22.04+, plocate has replaced traditional mlocate. plocate uses io_uring and index posting lists, making searches up to 10 times faster while using a much smaller database.

3. Searching Text Inside Files with grep and ripgrep

Finding a file by name is useful, but often you need to search for text inside code, configuration files, or logs.

The Classic grep Command

grep (Global Regular Expression Print) searches text patterns line by line.

Basic search for a string in a file:

grep "DATABASE_URL" /srv/app/.env

Search recursively inside a directory and display line numbers:

grep -rn "error_log" /etc/nginx/

Key flags to remember:

-r or -R: Search directories recursively.
-n: Show line numbers.
-i: Case-insensitive search.
-w: Match whole words only.
-c: Count total matching lines instead of printing them.

Exclude noisy directories like node_modules or .git:

grep -rn --exclude-dir={node_modules,.git,dist} "PORT" ./

Show context lines before and after matches:

grep -C 3 "FATAL" /var/log/syslog

The -C 3 flag shows 3 lines above and 3 lines below each match, giving you immediate context around errors.

Lightning Fast Search: ripgrep (rg)

When searching large source code repositories or massive log folders, standard grep can be slow. ripgrep (command name rg) is the fastest line-oriented search tool available.

Install ripgrep:

sudo apt install ripgrep

Search for a pattern in the current directory:

rg "connectTimeout"

Why ripgrep is superior for developers and sysadmins:

It respects your .gitignore and .ignore files automatically.
It skips binary files and hidden files by default.
It uses multi-threading and SIMD CPU instructions to scan gigabytes per second.

Search inside compressed .gz log files without extracting them first:

rg -z "500 Internal Server Error" /var/log/nginx/access.log*.gz

Real Production Scenario

When I was building AiroShare, a local DLNA media server, I had to search across thousands of lines of JavaScript and Node.js files to find every location where a custom SSDP multicast listener was registered. Running rg "ssdp:discover" instantly gave me every file, function, and line number in under 10 milliseconds without dragging in unwanted build artifacts.

4. Searching System Logs and Kernel Events

When an application crashes, an IP gets blocked, or a service fails on boot, your answers live inside system logs.

Searching systemd Logs with journalctl

Modern Linux distributions use systemd to manage services and record binary logs. The journalctl command lets you search these logs with precision.

View logs for a specific service unit:

sudo journalctl -u nginx.service

Filter log output by priority (errors, warnings, or critical events):

sudo journalctl -u app.service -p err

Priority levels include emerg, alert, crit, err, warning, notice, info, and debug.

Search logs within a specific time window:

sudo journalctl --since "2026-08-14 14:00:00" --until "2026-08-14 15:30:00"

Or view entries from the last two hours:

sudo journalctl --since "2 hours ago"

Search log messages matching a specific keyword:

sudo journalctl -g "out of memory"

Follow live log output as new entries arrive:

sudo journalctl -f -u docker.service

Searching Kernel Messages with dmesg

If a hardware device disconnects, a network interface drops, or the Out-Of-Memory (OOM) killer kills a process, check the kernel ring buffer using dmesg.

Search for kernel OOM events:

sudo dmesg -T | grep -i "oom"

The -T flag converts raw kernel timestamps into human-readable date and time formats.

Searching Rotated Log Files

Older log files in /var/log are often compressed into .gz format by logrotate. Standard text tools cannot read them directly. Use zgrep or zless instead:

zgrep -i "failed password" /var/log/auth.log*.gz

5. Searching Command History Like a Master

How many times have you typed a complex 80-character docker or kubectl command, only to forget it three days later? Stop hitting the Up arrow key fifty times.

Built-in Reverse Search: Ctrl+R

Press Ctrl+R in your terminal and start typing any fragment of the past command:

(reverse-i-search)`ssh`: ssh -i ~/.ssh/prod_key.pem admin@10.0.4.15

Press Ctrl+R repeatedly to cycle backward through matching historical commands. Hit Enter to run it, or Right Arrow to edit it on your prompt.

Searching History with Grep

View your command history and filter it:

history | grep "docker run"

To see exact timestamps alongside history entries, set HISTTIMEFORMAT in your ~/.bashrc:

export HISTTIMEFORMAT="%F %T "

Interactive Fuzzy Search: fzf

fzf is a command-line fuzzy finder that turns search into an interactive experience.

Install fzf:

sudo apt install fzf

Once installed, press Ctrl+R in your shell. fzf opens an interactive dropdown list of your entire command history. As you type letters, it filters candidates in real time.

You can also pipe any command output into fzf. For instance, search for a running container interactively:

docker ps | fzf

Or search for a file and open it in vim with a single keypress:

vim $(fd -type f | fzf)

6. Searching Processes, Open Files, and Listening Ports

Sometimes what you need to find is not text on disk, but an active process or network port in memory.

Searching Running Processes

When a process is consuming CPU or hanging, find its Process ID (PID) using ps or pgrep.

Search processes with ps:

ps aux | grep node

Search processes directly with pgrep to get PIDs and full command lines:

pgrep -a python

To kill a process by searching its name:

pkill -f "test_server.py"

Searching Which Process Holds a File

Have you ever tried to unmount a disk partition or delete a folder, only to get an error saying Device or resource busy?

Use lsof (List Open Files) or fuser to find the process locking the file:

sudo lsof /mnt/storage

Or use fuser to see PIDs and kill them directly:

sudo fuser -v /var/log/app.log
sudo fuser -k /var/log/app.log

Searching Network Ports and Sockets

When starting a web server or backend service, a common error is address already in use. You need to find which process is bound to that port.

Find what is listening on port 8080 using lsof:

sudo lsof -i :8080

Output:

COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
node    14209 asep    23u  IPv4  89201      0t0  TCP *:8080 (LISTEN)

Find open ports using ss (Socket Statistics):

sudo ss -tulpn | grep 8080

Flags explained:

-t: TCP sockets.
-u: UDP sockets.
-l: Listening sockets.
-p: Show process name and PID.
-n: Display numeric port numbers instead of service names.

Real Production Scenario

When I was developing AiroShare, a high-performance local media streaming engine, pre-launch port conflict resolution was a critical requirement. If port 9900 (DLNA HTTP media server) or port 2121 (FTP media engine) was already taken by another background service, AiroShare automatically scanned socket states using lightweight port checks to locate available ports before binding. Understanding how Linux exposes socket states made building that auto-resolution feature smooth and reliable.

7. Searching Executables, Libraries, and Package Owners

When you type a command in your shell, how do you find where the binary file is actually located?

Finding Command Paths

Locate the absolute path of an executable using which:

which python3

Locate binaries, manual pages, and source files using whereis:

whereis nginx

Identify how shell commands are interpreted using type:

type ll
type cd
type grep

type tells you whether a command is a shell built-in (cd), an alias (ll), a function, or a disk binary (grep).

Finding Which Installed Package Owns a File

If you find a random binary or configuration file on a server and want to know which software package installed it, query your package manager.

On Ubuntu or Debian (dpkg):

dpkg -S /etc/ssh/sshd_config

On RHEL, CentOS, or Fedora (rpm):

rpm -qf /etc/ssh/sshd_config

If a binary is missing and you want to find which package provides it before installing:

sudo apt install apt-file
sudo apt-file update
apt-file search bin/netstat

8. Searching Kernel Parameters and Hardware Information

Linux exposes live kernel variables and attributes through pseudo-filesystems like /proc and /sys.

Searching Active Kernel Variables with sysctl

Search all active kernel settings for network or memory parameters:

sysctl -a | grep "ip_forward"
sysctl -a | grep "swappiness"

You can change these values temporarily at runtime or lock them permanently inside /etc/sysctl.conf.

Searching Hardware Attributes in /proc

Search system CPU information:

grep "model name" /proc/cpuinfo

Search system memory details:

grep -i "memtotal" /proc/meminfo

Search network traffic statistics per interface:

cat /proc/net/dev

9. An Interesting Historical Fact About Linux Search

Did you know where the name grep came from?

Back in the early 1970s at Bell Labs, Unix co-creator Ken Thompson was working on the ed line editor. When users wanted to search an entire file for a regular expression and print matching lines, they typed a specific editor command:

g/re/p

This stood for global / regular expression / print.

Ken Thompson realized that searching text files was such a frequent necessity that he wrote a small, standalone command-line tool over a single night to do it outside the editor. He named that tool grep. More than fifty years later, grep remains one of the most widely used commands in software engineering.

10. Summary Cheat Sheet

Here is a quick reference guide for your daily terminal search needs:

Find files by name: find . -name "*.conf" or fd conf
Find files by size: find /var -type f -size +100M
Search text in files: grep -rn "pattern" ./ or rg "pattern"
Search text in gz logs: rg -z "pattern" /var/log/*.gz
Search systemd logs: journalctl -u app -p err --since "1 hour ago"
Search command history: Ctrl+R or history | grep "command"
Search listening ports: sudo lsof -i :8080 or sudo ss -tulpn | grep 8080
Search running processes: pgrep -a process_name
Search package owner: dpkg -S /path/to/file

What Is Your Go-To Search Tool?

When a production incident hits or a build breaks, which command do you reach for first? Are you sticking with classic tools like find and grep, or have modern tools like fd, ripgrep, and fzf completely replaced them in your workflow? Let me know in the comments below!

About the Author

Asep Sayyad is a Linux and DevOps engineer passionate about Linux administration, automation, cloud technologies, containers, and open-source software. He enjoys solving real-world infrastructure challenges and sharing practical knowledge through in-depth technical articles, tutorials, and hands-on guides.

His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.

Connect with Me

Portfolio: https://asepsayyad007.in
GitHub: https://github.com/asepsayyad007
LinkedIn: https://www.linkedin.com/in/asepsayyad
Medium: https://asepsayyad007.medium.com

Enjoyed this article?

If you found this guide helpful, consider:

Starring my open-source projects on GitHub.
Sharing this article with fellow Linux and DevOps engineers.

You can also follow me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source. Thanks for reading, and enjoy your learning!

8 Linux Myths Even Senior Engineers Still Fall For (And How They Hurt Production)

Asep Sayyad — Wed, 12 Aug 2026 16:39:23 +0000

Think years of experience make you immune to Linux misconceptions? Here are the bad habits, outdated knowledge, and deep technical myths that trap seasoned sysadmins and DevOps engineers.

Back in 2021, I worked alongside a systems engineer with over fifteen years of Unix and Linux experience. He could write complex AWK one-liners from memory and managed dozens of bare-metal database servers.

One Friday afternoon, our monitoring alerts triggered. A primary database node showed only 300 MB of free memory in the dashboard.

Without checking what that memory was doing, he logged into the server and ran a command to drop cached memory directly in production:

echo 3 > /proc/sys/vm/drop_caches

Within milliseconds, disk read activity hit 100 percent. Active database queries that normally took 2 milliseconds began timing out after 30 seconds. The entire web application stalled for five minutes while the kernel frantically re-read essential files from disk back into RAM.

That event taught me something important. Experience alone does not prevent bad assumptions. Linux has changed heavily over the past two decades. Memory management, process scheduling, cgroup limits, and container isolation work very differently today than they did years ago.

Over my 3+ years of working directly with Linux administration, cloud infrastructure, and building open-source server tools, I have seen these same misconceptions pop up across many teams.

Here are eight dangerous Linux myths that experienced engineers still believe, along with the actual kernel mechanics behind them.

1. Low Free RAM Means Your Server Is Running Out of Memory

This is one of the most common myths in systems administration. An engineer opens top or runs free -h, sees 400 MB in the free column on a machine with 64 GB of RAM, and assumes the server is about to crash.

               total        used        free      shared  buff/cache   available
Mem:            62Gi        48Gi       412Mi       1.2Gi        13Gi        12Gi
Swap:          8.0Gi       120Mi       7.9Gi

Why This Myth Exists

In simple desktop operating systems from thirty years ago, unused RAM was viewed as a safe buffer. Many people still think empty RAM is good RAM.

The Kernel Reality

Unused RAM is wasted RAM. The Linux kernel uses idle memory for the Page Cache and file buffers. When your application reads a file from disk, the kernel keeps a copy of those disk blocks in RAM. If the application asks for that same data again, Linux serves it directly from memory at sub-millisecond speed instead of reading slow disk storage.

The key column to watch in modern Linux systems is available, not free:

Free RAM: Memory that contains absolutely nothing.
Available RAM: An estimate of how much memory can be given to new applications without causing system slowdowns. This includes free RAM plus cached memory that can be reclaimed instantly.

How It Breaks Production

When engineers panic and manually run echo 3 > /proc/sys/vm/drop_caches, they wipe out the filesystem cache. The kernel is forced to fetch every binary, library, and data file back from disk storage. This triggers massive disk I/O spikes, increases CPU wait times, and causes database queries to time out.

The Better Approach

Never judge system memory health by the free metric. Monitor the available metric and check for active swapping activity using tools like vmstat 1 or sar -B.

2. Setting Swappiness to 0 Disables Swap Completely

Many deployment scripts and performance tuning guides recommend setting vm.swappiness = 0 in /etc/sysctl.conf to prevent servers from using swap space.

sudo sysctl vm.swappiness=0

Why This Myth Exists

On older Linux kernels (before version 3.5), setting swappiness to 0 told the system to avoid swapping until absolutely necessary. Engineers assumed 0 meant "never swap under any circumstance."

The Kernel Reality

Since Linux kernel 3.5, setting vm.swappiness = 0 does not disable swap. Instead, it instructs the memory manager to avoid swapping anonymous memory (like process heap and stack) unless the system is on the verge of an Out-Of-Memory (OOM) event.

However, the kernel will still evict file-backed pages (page cache) to keep memory free.

If your system runs out of memory and has no swap configured, Linux cannot swap out inactive memory blocks. It has only one choice left: invoke the OOM Killer (mm/oom_kill.c) to terminate heavy processes like PostgreSQL, MySQL, or Java applications.

How It Breaks Production

Disabling swap entirely or relying on swappiness = 0 removes an early warning buffer. Without swap, your system moves straight from normal memory usage to instant OOM process terminations without giving monitoring tools time to alert you.

The Better Approach

Set vm.swappiness to a low value like 10 or 1 rather than completely turning off swap. Keep a small swap file (1 GB to 2 GB) even on large cloud instances so the kernel can move stale, unread memory pages out of RAM safely.

3. High Load Average Always Means High CPU Usage

You get a high-priority alert: Server Load Average is 42.0 on an 8-core CPU! You quickly log in, open top, and find that CPU utilization is sitting at only 5 percent.

top - 14:22:10 up 45 days,  3:12,  2 users,  load average: 42.10, 38.45, 30.12
%Cpu(s):  2.3 us,  1.1 sy,  0.0 ni, 12.4 id, 84.2 wa,  0.0 hi,  0.0 si,  0.0 st

Why This Myth Exists

On traditional Unix systems (like BSD), load average counted only processes currently running on a CPU or waiting for CPU time. Many engineers assume Linux handles load average the exact same way.

The Kernel Reality

In 1993, Linux kernel creator Linus Torvalds modified load average calculations. In Linux, load average counts both:

Processes in Task Runnable (R) state: Using CPU or waiting in the CPU queue.
Processes in Uninterruptible Sleep (D) state: Waiting for disk I/O, network storage locks, NFS responses, or kernel locks.

If your storage array slows down or a network mount hangs, dozens of threads block while waiting for disk operations. They enter the D state. The CPU itself is completely idle, but the load average rises sharply.

Notice the 84.2 wa in the top output above. That wa stands for I/O Wait. The CPU is not busy processing calculations; it is doing nothing while waiting for slow disk operations to complete.

How It Breaks Production

Engineers who mistake high load for high CPU usage often upgrade to bigger CPU instances or restart application services. Neither fix works because the root bottleneck is slow disk storage, a failing drive, or network latency.

The Better Approach

Check process states using ps aux | grep ' D ' or inspect disk latency using iostat -xz 1 to find out whether high load comes from CPU demand or storage delays.

4. `kill -9` Is the Normal Way to Stop Frozen Processes

When a process does not close immediately, many developers and admins jump straight to forcefully killing it:

kill -9 <PID>

Why This Myth Exists

kill -9 sends the SIGKILL signal, which instantly stops the target process. It feels effective because the process disappears from the system right away.

The Kernel Reality

Linux process signals are designed for graceful shutdown:

SIGTERM (Signal 15): Asks the process to shut down cleanly. The application catches this signal, closes open file handles, flushes database write buffers, finishes current requests, and removes temporary lock files.
SIGKILL (Signal 9): Handled directly by the kernel, skipping the process entirely. The application is given zero milliseconds to clean up state.

When building AiroShare, my open-source local file server engine, clean process handling was crucial. If an application server is forcefully killed with SIGKILL while listening on HTTP or FTP ports (like port 9900 or 2121), socket bindings can remain stuck in TIME_WAIT state, preventing clean application restarts until port locks time out.

How It Breaks Production

Using SIGKILL on databases or file servers causes data corruption, half-written log entries, and orphan lock files. When the process starts up again, it may crash or take a long time attempting crash recovery.

The Better Approach

Always send SIGTERM (kill <PID>) first. Give the process several seconds to complete clean teardown. Only use SIGKILL as a last resort when a process is unresponsive to standard termination signals.

5. Root Inside a Docker Container Cannot Harm the Host Machine

A common assumption in cloud deployments is that containerization works like hardware virtualization. People assume running as root inside a container is safe because it is isolated inside its own environment.

Why This Myth Exists

Containers feel like lightweight virtual machines. Because containers have separate filesystems and process lists, developers assume the container boundary acts as a hard security wall.

The Kernel Reality

Containers are not virtual machines. A container is simply a standard Linux process running directly on the host kernel, restricted by Linux kernel features:

Namespaces: Restrict what a process can see (process tree, network interfaces, mount points).
Control Groups (cgroups): Restrict how much resource a process can use (CPU, RAM, disk I/O).

By default, UID 0 inside a container maps directly to UID 0 (root) on the host kernel unless User Namespaces (userns-remap) are explicitly enabled.

If an attacker finds an exploit in your web application and breaks out of container namespace boundaries (via kernel exploits, mounted Docker sockets, or exposed /proc paths), they gain full root privileges on the underlying host server.

How It Breaks Production

Running containerized microservices as root creates severe security risks. A single vulnerability in a web dependency can compromise your entire host operating system.

The Better Approach

Always set a non-root user in your Dockerfile:

USER 10001:10001

Drop unneeded kernel capabilities:

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - ALL

Enable user namespace remapping in your container runtime configuration.

6. `chmod 777` Is a Quick and Safe Fix for Permission Errors

When a developer runs into permission errors while setting up web servers, file uploads, or scripts, they often run:

chmod -R 777 /var/www/html

Why This Myth Exists

Permission errors can be frustrating. chmod 777 grants read, write, and execute access to everyone on the system (User, Group, Others), instantly clearing permission error messages.

The Kernel Reality

Setting 777 allows any local user or service account to read, modify, overwrite, or execute your files.

Furthermore, several critical Linux services actively reject files with loose permissions:

OpenSSH: Will refuse to authenticate if ~/.ssh/authorized_keys has permissions wider than 600.
Systemd: Ignores unit files if file permissions are set too loosely.
Cron: Skips scheduled cron jobs if permission settings are unsafe.

How It Breaks Production

If an attacker exploits a minor file upload vulnerability in a web application hosted inside a 777 directory, they can upload malicious scripts and execute them immediately with full write access to the application tree.

The Better Approach

Fix ownership using chown rather than loosening permissions with chmod 777:

Set ownership to the correct service user:

sudo chown -R www-data:www-data /var/www/html

Apply secure file and folder permissions:

find /var/www/html -type d -exec chmod 755 {} +
find /var/www/html -type f -exec chmod 644 {} +

7. A System Reboot Is Required After Upgrading Linux Packages

Coming from a desktop Windows background, many administrators believe that after running system updates, you must reboot the server to apply changes.

Why This Myth Exists

Legacy operating systems often lock system files during runtime, requiring a complete reboot after security updates.

The Kernel Reality

Linux allows you to update libraries, software packages, and system utilities while the system is running. When you update a package using apt or dnf, the old files on disk are unlinked and replaced with new binaries immediately.

However, processes that were already running in memory continue executing the old version from RAM until those services are restarted.

Rebooting the entire server is required only when updating the Linux kernel itself (unless you use live patching utilities like kpatch or Canonical Livepatch).

For standard library updates (like OpenSSL or system packages), you only need to restart the affected service:

sudo systemctl restart nginx

How It Breaks Production

Rebooting servers unnecessarily causes avoidable service downtime, disrupts active network connections, and lowers system availability metrics.

The Better Approach

Use automated tools like needrestart (on Debian/Ubuntu) or dnf needs-restarting (on RHEL/Fedora) to identify which running services need a restart after updates without rebooting the server:

sudo needrestart -v

8. Setting Low `nice` Values Guarantees CPU Allocation

When an important background process needs to run faster, engineers often adjust its nice priority value:

nice -n -20 /usr/bin/heavy-data-processing

Why This Myth Exists

The nice command scale ranges from -20 (highest priority) to 19 (lowest priority). People assume setting -20 forces the CPU to give all its processing power to that specific process.

The Kernel Reality

The Linux Completely Fair Scheduler (CFS) calculates CPU time shares using relative weights based on nice values.

However, two major factors limit the impact of nice:

CPU Contention Required: If the CPU is not fully saturated, nice values have zero noticeable impact because the CPU has enough headroom to handle all tasks.
Control Groups Override nice Settings: On modern Linux systems managed by systemd and cgroups v2, CPU limits configured inside cgroup unit files (CPUWeight=, CPUShares=) override process-level nice settings.

If a process is placed inside a restricted cgroup slice, setting nice -20 inside that process will not allow it to bypass its cgroup CPU limits.

How It Breaks Production

Relying on nice values to prioritize background batch processing fails in containerized environments (Docker, Kubernetes) because container CPU limits are enforced at the cgroup level.

The Better Approach

Manage process CPU allocation using cgroups or systemd slice configurations:

[Service]
Slice=custom-workload.slice
CPUWeight=200

💡 Surprising Linux Fact

Did you know that the /proc filesystem on Linux consumes 0 bytes of disk space?

/proc is not a physical directory on your hard drive. It is a virtual filesystem created dynamically in memory by the Linux kernel. When you view files like /proc/meminfo or /proc/cpuinfo, the kernel generates that text content on the fly directly from internal kernel data structures!

Conclusion

Linux is an remarkably reliable operating system, but many common practices passed down through blog posts and old tutorials are outdated. Understanding how the kernel manages memory, calculates load average, isolates container processes, and handles system signals will help you build faster, more secure production environments.

Which of these Linux myths have you encountered on your engineering team? Have you seen system issues caused by dropping caches or setting swappiness = 0 in production? Share your thoughts and experiences in the comments below!

About the Author

His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.

Connect with Me

Portfolio: https://asepsayyad007.in
GitHub: https://github.com/asepsayyad007
LinkedIn: https://www.linkedin.com/in/asepsayyad

Enjoyed this article?

If you found this guide helpful, consider:

Starring my open-source projects on GitHub.
Sharing this article with fellow Linux and DevOps engineers.

You can also follow me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source. Thanks for reading, and enjoy your learning!

The Biggest Linux Myths Beginners Still Fall For

Asep Sayyad — Wed, 12 Aug 2026 13:32:31 +0000

Let's be honest, when I first heard about Linux, I thought it was this scary hacker thing where you type green text on a black screen all day.

Turns out, I was dead wrong.

If you're new to Linux, chances are you've heard some version of these myths too. Maybe a friend told you Linux is "only for nerds." Maybe you saw some Reddit thread that made it sound like you'll blow up your laptop with one bad command.

I believed some of this stuff too. And I wasted months avoiding Linux because of it.

Most of these myths are either outdated, exaggerated, or just flat-out wrong. So let's go through them one by one.

Myth 1: Linux Is Only for Experts

This one drives me nuts because it stops so many people from even trying.

Look, you don't need to be a programmer. You don't need a computer science degree. You definitely don't need to understand how the kernel works before you can open a web browser.

Modern Linux distros like Ubuntu, Linux Mint, or Zorin OS give you a desktop that looks and feels pretty similar to Windows or macOS. You get a file manager, a web browser, a settings app, even a software store. It's all point-and-click if you want it to be.

Just pick a beginner-friendly distro. Don't jump straight into Arch Linux on day one (unless you really enjoy pain).

You didn't need to become a mechanic before you started driving a car, right? Same idea here.

Myth 2: You Must Know Hundreds of Commands

Okay yes, Linux has thousands of commands. That sounds terrifying.

But nobody tells you this part: you only need like 7 of them to get started.

I'm serious. pwd tells you where you are. ls shows what's in a folder. cd moves you around. mkdir makes a new folder. cp copies stuff, mv moves or renames stuff, and rm deletes stuff.

That carried me through my first few months. I looked up everything else as I needed it. Google, man pages, Stack Overflow, whatever. Nobody actually memorizes all of them. Not even the people who've been using Linux for 20 years.

The pressure to "know everything first" is fake. Just start using it.

Myth 3: Linux Has No Graphical Interface

This one cracks me up every time.

I think it comes from people seeing screenshots of Linux servers, which yeah, those are usually just a terminal. But desktop Linux? Full graphical environments. Some of them look gorgeous.

You can browse files with a mouse, drag and drop things, connect to Wi-Fi from a menu, change your wallpaper, watch YouTube. All the normal stuff. No terminal needed.

KDE Plasma and GNOME honestly look better than Windows in my opinion. But that's a debate for another day.

Myth 4: Linux Is Completely Virus-Proof

This one's actually dangerous because it gives people a false sense of security.

Is Linux more secure than Windows out of the box? Yeah, generally. But "more secure" doesn't mean "bulletproof."

Linux systems can still get hit by security vulnerabilities, misconfigured services, compromised user accounts, and even malware. Yes, Linux malware exists. It's not common, but it's real.

I've seen people in forums say "I run Linux so I don't need to worry about security." That mindset will bite you eventually.

You should still keep your system updated, use strong passwords, avoid sketchy software sources, be careful with file permissions, and stop throwing sudo on every command like it's seasoning. Also back up your important files. I learned that one the hard way after a botched partition resize wiped my home directory. Fun times.

Myth 5: You Always Need the Terminal

The terminal is awesome. I love it.

But no, you don't need it for everything. Most beginner-friendly distros have a file manager, a graphical settings app, and a software store you can click through. You could use Linux for weeks without ever opening a terminal if you wanted to.

Where the terminal really shines is automation, remote server management, troubleshooting weird issues, and doing things faster once you've learned the commands. It's a power tool, not a requirement.

Myth 6: Installing Software Is Always Difficult

This used to be kinda true, I'll admit. Back in the day, installing software on Linux could be a real headache. Dependency hell was a thing. Compiling from source was a thing.

But now? On Ubuntu or Debian, you type sudo apt install followed by whatever you want, hit enter, and it's done. The package manager figures out all the dependencies for you. No hunting for .exe files on random websites. No "Next Next Next Finish" installers.

Different distros use different package managers (dnf for Fedora, pacman for Arch), but the concept is the same everywhere.

One warning though. Don't blindly copy-paste commands from the internet, especially if they use sudo. Take 10 seconds to understand what you're about to run. Your future self will thank you.

Myth 7: Linux Software Support Is Terrible

I won't lie, there are some apps you can't get on Linux. Adobe Creative Suite? Nope. Some AAA games? Maybe not natively.

But calling Linux software support "terrible" is a stretch. You've got GIMP, Blender, LibreOffice, VS Code, Spotify, Slack, Discord (either native or web apps), Docker, and most developer tools are actually built for Linux first. Flatpak and Snap are closing the gap on everything else.

If you're a developer, Linux is honestly a dream. I switched my dev machine to Ubuntu two years ago and I've never looked back. Most tools just work without extra setup.

Before you make the switch though, check if the specific apps you depend on daily have Linux versions or solid alternatives. For most people they do. For some workflows (video editing, audio production), it depends.

Myth 8: Linux Is Always Completely Free

"Free" in the Linux world is a loaded word.

Can you download and use most Linux distros without paying anything? Yes. That part's true.

But "free" in open source usually means freedom, not price. The freedom to use, study, modify, and share the software. Companies like Red Hat still charge for enterprise support, management tools, and consulting. That costs real money.

And honestly, that's fine. It's how a lot of open-source projects stay funded and keep improving.

Myth 9: Linux Is Only for Servers

Linux dominates servers, sure. Cloud, containers, infrastructure, it's Linux all the way down.

But it's also running on your Android phone right now. It's in smart TVs, routers, Raspberry Pis, cars, medical devices, and actual spacecraft. NASA runs Linux on the ISS. Your Wi-Fi router probably runs Linux.

Calling Linux "server only" is like saying wheels are only for trucks.

If you're getting into DevOps, learning Linux on a desktop is actually a smart move. Most production servers you'll manage are running some flavor of Linux anyway, so the commands and concepts transfer directly.

Myth 10: You Can Easily Break Linux With One Command

This is the one that scares beginners the most.

Yes, Linux gives you a lot of power. And yes, rm -rf / is a real thing that can wreck your system. But you're not going to accidentally type that. Nobody does.

The actual rule is simple: read the command before you run it. That's really all there is to it.

When you find a command online, spend 5 seconds asking yourself what it does and why it needs sudo. If you can't answer that, look it up before hitting enter.

And if you're nervous about experimenting, spin up a virtual machine. VirtualBox is free. Break the VM a hundred times, your real system stays completely fine. That's how I learned most of what I know, by breaking things in VMs and figuring out how to fix them.

Try This Right Now

Enough talking, let's do something. Takes 30 seconds.

Open a terminal and make a practice folder with mkdir linux-practice. Jump into it with cd linux-practice. Create a file with touch notes.txt. Run ls to check that it's there.

Four commands. You just created a directory, navigated into it, made a file, and confirmed it exists. That's real Linux usage right there.

If mkdir complains the folder already exists, you ran it before. If cd says it can't find it, run pwd to see where you are, then ls to see what's around you.

That's how Linux learning works. You try stuff, see what happens, fix the small things, and move on.

Habits I Wish I'd Started With

Stop copy-pasting blindly

I know it's tempting. You find a command on Stack Overflow and just slap it in. But please, take 5 seconds to read it first. Especially anything with sudo. I once pasted a "cleanup" command I found on a blog that nuked half my config files. Don't be me.

Learn a few commands at a time

Don't try to learn everything in one weekend. Pick up pwd, ls, cd, mkdir, touch, cp, and mv. Use them every day. They'll become second nature within a week.

Man pages are your friend

Curious about what a command can do? Type man followed by the command name. Every option, every flag, all documented. It's dry reading, but it's accurate.

Respect sudo

Sudo gives you admin power. Great when you need it, dangerous when you don't. Don't add it to commands just because a tutorial said so. Understand why it's needed.

Use a virtual machine for experiments

Nervous about breaking things? VirtualBox is free. Trash the VM as many times as you want. Zero consequences.

Update your system

Yeah, updates are annoying. But they fix security holes and bugs. Just do it. Set a reminder if you have to.

Mistakes You'll Probably Make (And That's Fine)

Thinking you need to know everything first

You don't. Nobody does. I've been using Linux for years and I still google basic stuff sometimes.

Being scared of the terminal

It looks intimidating with all that text. I know. But after a week of using it, you'll wonder what you were so worried about.

Running commands without reading them

Break this habit on day one. Seriously. Everything else gets easier once you stop doing this.

Assuming Linux can't be hacked

It's secure. It's not invincible. Good security habits matter regardless of your OS.

Installing random .deb files from the internet

Stick to your distro's package manager or trusted sources like Flathub. Downloading random packages from unknown websites is the Linux equivalent of clicking "Free_Movie_Player.exe" on Windows.

Comparing Linux to Windows constantly

They're different tools for different jobs. Instead of asking "which is better," ask "which one does what I need?"

Fun Fact

Linux runs the International Space Station. It runs most of the world's top supercomputers. It runs Android. It probably runs your router, your smart TV, and your car's infotainment system.

So when someone tells you Linux is "niche," you can let them know it's literally running the world. Just quietly.

Wrapping Up

Most Linux myths fall apart the moment you actually sit down and try it.

You don't need to be an expert. You don't need to memorize a dictionary of commands. You don't have to live in the terminal. And no, Linux won't magically protect you from every security threat.

The best way to learn is just to start. Open a terminal. Type something. See what happens. Make a mistake. Fix it. That's the whole process.

I started exactly like that, confused, a little nervous, and way too cautious. Now I run Linux as my daily driver and I honestly can't imagine going back.

If you're learning Linux for dev work, sysadmin stuff, or DevOps, every small step counts. You don't need to know everything about Linux to start using it. Nobody does. Not even the people writing blog posts about it.

Drop a Comment

What Linux myth did you fall for before you actually tried it?

I bet someone reading this is worried about the exact same thing right now. Sharing it might be the push they need to finally give Linux a shot.

About the Author

His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.

Connect with Me

Portfolio: https://asepsayyad007.in
GitHub: https://github.com/asepsayyad007
LinkedIn: https://www.linkedin.com/in/asepsayyad
Medium: asepsayyad007.medium.com

Enjoyed this article?
If you found this guide helpful, consider:

Starring my open-source projects on GitHub.
Sharing this article with fellow Linux and DevOps engineers.
You can also follow me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source. Thanks for reading, and enjoy your learning!

Before You Panic: Git Commands That Can Save Your Project.

Asep Sayyad — Thu, 06 Aug 2026 08:18:52 +0000

If you've been using Git for a while, chances are you've had at least
one moment where your heart skipped a beat.

Maybe you reset the wrong commit, deleted a branch, or switched branches
without saving your work. Your first thought is usually, "I just lost
everything."

I've been there too.

The good news is that Git is much more forgiving than it looks. Most of
the time, your work is still there---you just need to know which command
to use.

In this article, I'll share the Git commands I rely on whenever
something goes wrong. They aren't magic tricks; they're practical tools
that have saved me more than once.

1. Check what's happening first

Before trying to fix anything, see the current state of your repository.

git status

I run this command almost every time before committing. It quickly tells
me which files have changed, which ones are staged, and whether I've
forgotten anything.

2. Review your changes

Before creating a commit, take a quick look at what actually changed.

git diff

If you've already staged files:

git diff --staged

This simple habit has saved me from committing debug code and accidental
edits more times than I'd like to admit.

3. Read your commit history

When you're trying to understand how your project reached its current
state, a clean commit history is incredibly useful.

git log --oneline --graph --decorate

The graph view makes it much easier to understand branches and merges.

4. The lifesaver: `git reflog`

If you only remember one command from this article, make it this one.

git reflog

Even after a reset or an accidental checkout, Git usually keeps a record
of where your HEAD has been.

Found the commit you need?

git checkout <commit-id>

or restore it completely:

git reset --hard <commit-id>

Many "lost" commits aren't actually lost.

5. Undo a commit without losing your work

Forgot to include a file?

git reset --soft HEAD~1

The commit disappears, but all your changes stay exactly where they are,
ready for another commit.

6. Remove a commit completely

Sometimes you really do want to go back.

git reset --hard HEAD~1

Use this carefully. It removes both the commit and your local changes.

7. Pause your work with `git stash`

Imagine you're halfway through a feature when someone asks you to fix an
urgent production bug.

Instead of making a messy temporary commit, simply stash your work.

git stash

When you're ready to continue:

git stash pop

See every saved stash:

git stash list

8. Restore a deleted file

Deleted a tracked file by mistake?

git restore app.py

Need an older version?

git restore --source <commit-id> app.py

9. Find who changed a line

Ever wondered who introduced a particular line of code?

git blame app.py

This command shows who last modified each line and in which commit.

10. Search your history

Looking for the commit that fixed authentication?

git log --grep="authentication"

Looking for where a function was added?

git log -S "loginUser"

These searches save a lot of scrolling.

11. Clean untracked files

First, preview what Git will remove.

git clean -n

If everything looks correct:

git clean -fd

Always preview before deleting.

12. Visit an older version

Sometimes you just want to test an older commit.

git switch --detach <commit-id>

This lets you explore older versions without affecting your current
branch.

Check git status before every commit.
Review your changes with git diff.
Write meaningful commit messages.
Work on feature branches instead of main.
Push your work regularly.
Learn git reflog before you actually need it.

Final Thoughts

Every developer makes Git mistakes. I still do.

The difference is that, over time, you realize most mistakes are
recoverable. Once you're comfortable with commands like git reflog,
git stash, and git restore, those "I think I broke everything"
moments become much less stressful.

I hope this guide gives you a few commands you'll remember the next time
Git surprises you.

If there's a Git command that has saved your day, I'd love to hear about
it in the comments.

The Linux Skills That Separate Junior and Senior DevOps Engineers: A Practical Comparison

Asep Sayyad — Sat, 01 Aug 2026 11:15:02 +0000

Introduction

Many people believe that becoming a senior DevOps engineer means
learning Kubernetes, Terraform, or cloud platforms. While those skills
matter, the real difference often comes down to Linux.

A junior engineer usually knows commands. A senior engineer understands
the operating system, investigates problems methodically, and thinks
about reliability, security, and automation.

This article compares the mindset and daily practices of junior and
senior DevOps engineers.

1. Linux Fundamentals

Junior Engineer

Memorizes commands
Copies solutions
Learns tools

Senior Engineer

Understands how Linux works
Investigates root causes
Learns concepts

2. Filesystem Knowledge

Junior

Knows basic directories
Searches randomly for configuration files

Senior

Understands the Filesystem Hierarchy Standard
Knows where logs, binaries, configuration files, and temporary files belong
Understands mount points and storage layouts

3. File Permissions

Junior

chmod -R 777 project/

Senior

Checks ownership
Reviews groups
Uses least privilege
Understands ACLs, SUID, SGID, and Sticky Bit

4. Managing Services

Junior

systemctl restart nginx

Senior

systemctl status nginx
journalctl -u nginx
ss -tulpn

The goal is to identify the root cause before restarting services.

5. Reading Logs

Junior

"I'll restart the application."

Senior

"Let's read the logs first."

Useful tools:

journalctl
grep
tail
less
awk

6. Networking

Junior

Checks if ping works

Senior

Verifies DNS
Checks routing
Reviews firewall rules
Confirms listening ports
Tests application connectivity

7. Storage Management

Junior

Deletes random files when disk space is low.

Senior

Uses df -h
Uses du -sh
Checks inode usage
Finds large files
Identifies why storage is growing

8. Performance Troubleshooting

Junior

"The server is slow."

Senior

Measures before acting.

Checks:

CPU
Memory
Disk I/O
Swap
Load Average
Network utilization

9. Shell Scripting

Junior

Creates scripts that solve a single problem.

Senior

Creates reusable scripts with:

Functions
Logging
Error handling
Validation
Comments

10. Security

Junior

Uses the root account for everything.

Senior

Uses SSH keys
Applies least privilege
Configures firewalls
Audits systems
Performs regular updates

11. Automation

Junior

Runs repetitive commands manually.

Senior

Automates:

Backups
Monitoring
User provisioning
Deployments
Health checks

12. Troubleshooting Mindset

Junior

Restart services
Hope the problem disappears

Senior

Observe
Collect evidence
Read logs
Reproduce the issue
Fix the root cause
Document the solution

13. Production Scenario

Issue

Nginx returns 502 Bad Gateway.

Junior Approach

Restart Nginx
Restart backend service

Senior Approach

Review Nginx logs
Check backend health
Verify ports
Test upstream connectivity
Review recent deployments
Fix the actual issue instead of masking it

Final Thoughts

The difference between a junior and a senior DevOps engineer isn't the
number of Linux commands they know---it's how they think.

Senior engineers understand systems, troubleshoot calmly, automate
repetitive work, prioritize security, and prevent problems instead of
repeatedly fixing them.

Master Linux concepts first, and every other DevOps technology becomes
easier to learn.

About the Author

Asep Sayyad is a Linux and DevOps engineer passionate about Linux administration, automation, cloud technologies, containers, and open-source software. He enjoys solving real-world infrastructure challenges and sharing practical knowledge through in-depth technical articles, tutorials, and hands-on guides.

His goal is to help aspiring and experienced engineers build stronger Linux and DevOps skills with content focused on real production scenarios rather than theory alone.

Connect with Me

🌐 Portfolio: https://asepsayyad007.in
💻 GitHub: https://github.com/asepsayyad007
🔗 LinkedIn: https://www.linkedin.com/in/asepsayyad007 (Update if different)
📝 Medium: https://medium.com/@asepsayyad007 (Update if different)

Enjoyed this article?

If you found this guide helpful, consider:

⭐ Starring my open-source projects on GitHub.
🔄 Sharing this article with fellow Linux and DevOps engineers.
📚 Following me for more practical content on Linux, DevOps, Cloud, Containers, Automation, and Open Source.

Thanks for reading, and happy learning! 🚀

Hidden Linux Gems: 15 Lesser-Known Commands That Deserve More Attention

Asep Sayyad — Mon, 27 Jul 2026 14:38:38 +0000

There are no "secret" Linux commands hidden from experienced users.
However, there are many excellent commands that are surprisingly
underused. These can make you more productive and deepen your
understanding of Linux.

1. `tldr` --- Simpler Than `man`

tldr tar

Most people know man, but tldr provides practical examples instead
of long documentation.

Install:

sudo apt install tldr

2. `ss` --- Better Than `netstat`

ss -tulnp

Shows: - Listening ports - Process IDs - Active TCP/UDP sockets

Why use it?

ss is faster and is the modern replacement for netstat.

3. Find the Largest Files

du -ah / | sort -rh | head -20

Explanation:

du -ah → Calculate file sizes
sort -rh → Sort by largest first
head -20 → Show only the top 20

Useful when a server suddenly runs out of disk space.

4. Watch a Command Continuously

watch -n 2 free -h

Runs free -h every 2 seconds.

Great for monitoring: - Memory - Disk usage - Processes

5. Discover Binary Dependencies

ldd /bin/ls

Shows which shared libraries a program depends on.

Very useful when debugging missing library errors.

6. Trace What a Program Is Doing

strace ls

You'll see every system call the program makes.

This is one of the best debugging tools available.

7. See Open Files

lsof -i :80

Find which process is using port 80.

Another example:

lsof /var/log/syslog

Shows which process currently has the file open.

8. Inspect Binary Strings

strings binary_file

Extracts readable text from compiled binaries.

Useful for: - Reverse engineering - Malware analysis - Debugging

9. Hex Dump Any File

xxd file.txt

Displays hexadecimal representation.

Restore:

xxd -r dump.hex restored.bin

10. View ELF Information

readelf -h /bin/bash

Shows:

Architecture
Entry point
ELF headers

Very useful for Linux internals.

11. Find Slow DNS Lookups

dig openai.com

Instead of relying on ping, use dig to troubleshoot DNS.

12. Show Process Tree

pstree -p

Displays parent and child processes in a tree.

Much easier than reading ps.

13. Follow Multiple Logs

multitail /var/log/syslog /var/log/auth.log

Unlike tail -f, this lets you watch several log files simultaneously.

14. Recover Deleted Terminal Output

Accidentally cleared your terminal?

Instead of reopening it:

reset

clear

reset completely reinitializes the terminal if it becomes corrupted.

15. Explore Without Installing Anything

python3 -m http.server 8000

Instantly creates a web server in the current directory.

Perfect for: - Sharing files - Testing websites - Development

Bonus Commands Worth Learning

timeout 5 ping google.com

Automatically stops a command after 5 seconds.

yes "Hello"

Outputs text continuously until stopped.

Useful for testing scripts.

column -t file.txt

Formats messy text into neat columns.

script session.log

Records your entire terminal session.

history | grep docker

Search your shell history instantly.

Final Thoughts

None of these commands are "secret." They are simply underused. Learning
them won't replace Linux fundamentals, but they'll make you a more
capable troubleshooter and system administrator.

Linux Isn't Hard—You're Learning It the Wrong Way

Asep Sayyad — Sun, 26 Jul 2026 16:55:43 +0000

Stop memorizing commands. Start understanding concepts.

Many people believe Linux is difficult because they begin by trying to
memorize dozens of terminal commands. After a few days, they forget most
of them and feel discouraged.

The truth is simple: Linux isn't hard---you're probably learning it
the wrong way.

Whether you want to become a Linux administrator, DevOps engineer, cloud
engineer, or simply feel comfortable using Linux, the right learning
approach makes all the difference.

Stop Memorizing Commands

A common mistake is trying to remember hundreds of commands like:

ls
pwd
cd
mkdir
touch
cp
mv
rm
chmod

Commands are tools, not vocabulary. You don't need to memorize every
tool before building something.

Instead, learn commands when you actually need them.

Learn by Solving Real Problems

Rather than memorizing cp, ask yourself:

"How do I copy my project folder?"

Then learn:

cp -r project backup

Because the command solved a real problem, you'll remember it much
longer.

Linux Is Mostly Four Things

Understanding these concepts will make nearly every command easier:

Files
Directories
Permissions
Processes

Once these become familiar, Linux starts feeling much more logical.

Don't Depend on Huge Cheat Sheets

Cheat sheets are helpful, but avoid trying to study hundreds of commands
at once.

Focus on only the commands you need today.

Small progress every day beats information overload.

Build Small Projects

Projects teach far better than tutorials.

Try building:

A personal website
A simple backup script
A Docker container
An Nginx web server
SSH remote access
A scheduled cron backup

Each project teaches multiple Linux concepts naturally.

Read Error Messages

When Linux says:

Permission denied

Don't panic.

Ask:

Do I own this file?
Are the permissions correct?
Am I using the correct path?

Linux often tells you exactly what went wrong.

Understand Before Copying Commands

Never blindly run commands like:

sudo chmod -R 777 /

Instead understand:

What does chmod do?
What does -R mean?
What does 777 mean?
What does / represent?

Understanding protects your system.

Practice Every Day

Even 10--15 minutes daily makes a huge difference.

Practice:

Creating folders
Navigating directories
Editing files
Searching files
Checking running processes

Consistency beats marathon study sessions.

Ask Better Questions

Instead of searching:

"Linux is broken"

Search:

"Permission denied while copying a file"

Specific questions usually produce specific solutions.

You Don't Need to Know Everything

Experienced Linux administrators still search documentation.

Professionals remember concepts and know where to find details when
needed.

You don't have to memorize every command to become good at Linux.

Key Takeaways

Learn concepts before commands.
Solve real problems.
Build projects.
Read error messages carefully.
Practice consistently.
Understand commands before using them.

Interesting Fact 💡

Linux powers more than 90% of the world's top 500 supercomputers,
making it one of the most important operating systems in computing.

Question for Readers

What was the hardest part when you started learning Linux? Share your
experience in the comments!

What Really Happens When You Press Enter in the Linux Terminal? A Deep Dive Using the `ls` Command

Asep Sayyad — Sat, 25 Jul 2026 14:14:23 +0000

Reading Time: 10 minutes

You type ls, press Enter, and the result appears almost
instantly. But what actually happens during those few milliseconds?
This article follows the complete journey of a single Linux
command---from your keyboard to the kernel and back to your screen.

Introduction
Meet the Players
Step 1: Typing ls
Step 2: Pressing Enter
Step 3: The Shell Takes Over
Step 4: Finding the Command
Step 5: Creating a Process
Step 6: Loading into Memory
Step 7: CPU Execution
Step 8: Kernel Interaction
Step 9: Reading the File System
Step 10: Printing the Output
Complete Flow Diagram
Practical Example
Best Practices
Common Mistakes
Interesting Fact
Conclusion
Reader Question
SEO Metadata

Introduction

Every Linux user starts by running simple commands like ls, pwd, or
cd. They look simple, but Linux performs an impressive amount of work
before you see the output.

In this article, we'll use one command---ls---to understand how
the terminal, shell, kernel, CPU, RAM, and file system work together.

Meet the Players

Component Role

Terminal Collects keyboard input and displays output
Shell Interprets your command
PATH Helps locate executable programs
Kernel Core of Linux that manages hardware and system resources
CPU Executes machine instructions
RAM Holds running programs
File System Stores files and directories

Step 1: Typing `ls`

ls

The terminal receives each keystroke and echoes it to the screen.
Nothing has been executed yet.

Step 2: Pressing Enter

Pressing Enter tells the terminal that the command line is complete.

The terminal forwards:

ls

to the shell.

Step 3: The Shell Takes Over

The shell (usually Bash) examines the command.

It asks:

Is this an alias?
Is this a shell built-in?
Is this an executable program?

Since ls is an executable, it begins searching for it.

Step 4: Finding the Command

The shell checks directories listed in PATH.

echo $PATH

Example:

/usr/local/bin:/usr/bin:/bin

Eventually it finds:

/usr/bin/ls

You can verify this yourself:

which ls

Expected output:

/usr/bin/ls

Step 5: Creating a Process

The shell creates a new process.

Bash
 └── ls

The shell pauses while ls executes.

Step 6: Loading into Memory

Linux copies the executable from storage into RAM, prepares memory, and
sets up everything the program needs to run.

Step 7: CPU Execution

The CPU starts executing instructions inside ls.

Since no directory was specified, it assumes the current working
directory.

Step 8: Talking to the Kernel

Programs cannot directly access hardware or disks.

ls requests the Linux kernel to read the directory contents.

The kernel verifies permissions and safely retrieves the information.

Step 9: Reading the File System

The kernel reads metadata describing files and directories and returns
it to ls.

Step 10: Printing the Output

ls formats the information and writes it to stdout.

Example:

Documents
Downloads
Pictures
notes.txt

The terminal receives this text and displays it.

Finally, ls exits, Linux frees its resources, and Bash shows a new
prompt.

Complete Flow Diagram

Keyboard
   │
   ▼
Terminal
   │
   ▼
Shell (Bash)
   │
   ▼
Search PATH
   │
   ▼
Find /usr/bin/ls
   │
   ▼
Create Process
   │
   ▼
Load into RAM
   │
   ▼
CPU Executes
   │
   ▼
Kernel
   │
   ▼
File System
   │
   ▼
ls Formats Output
   │
   ▼
Terminal Displays Results

Practical Example

Run:

mkdir demo
touch demo/file1.txt demo/file2.txt
cd demo
ls

Expected output:

file1.txt
file2.txt

Everything described in this article happens every time you run ls,
even for this tiny example.

Best Practices

Use which to locate executables.
Explore echo $PATH to understand command lookup.
Learn the difference between the terminal, shell, and kernel.
Read command manuals using man ls.

Common Mistakes

Thinking the terminal executes commands.
Confusing Bash with the Linux kernel.
Assuming every command is built into the shell.
Forgetting that external commands run as separate processes.

Interesting Fact

Did you know? A modern Linux system can execute thousands of
short-lived processes every second, making simple commands like ls
appear almost instantaneous.

Conclusion

Although ls looks like a tiny command, it triggers an entire chain of
events involving the terminal, shell, process management, memory
allocation, CPU execution, the Linux kernel, and the file system.
Understanding this workflow builds a strong foundation for learning
Linux, system administration, and DevOps.

A Question

Which Linux command would you like to explore next---cd, pwd,
grep, or cat? Let me know in the comments!

Setting Up Docker for Multiple Applications

Asep Sayyad — Sat, 25 Jul 2026 13:00:30 +0000

After getting my free Oracle Cloud server ready, the next challenge was
running more than one application.

At first, I installed everything directly on the server. It worked, but
as I added more projects, managing everything became difficult.

That's when I started using Docker.

What Is Docker?

Docker lets you package an application with everything it needs to run.

Each application runs inside its own container, so one project doesn't
interfere with another.

Think of it as giving every application its own small workspace.

Why I Chose Docker

Docker made my server easier to manage.

It helped me:

Run multiple applications
Keep projects separated
Update applications safely
Create backups easily
Move applications to another server
Keep the server organized

My Setup

Today, my server runs different services in separate containers.

Examples include:

Personal portfolio
API services
Reverse proxy
Databases
Monitoring tools

This makes troubleshooting much easier.

Challenges I Faced

Learning Docker wasn't perfect.

Some common problems I faced were:

Port conflicts
Wrong volume mappings
Restart loops
Low memory
Network issues

Every mistake helped me understand Docker better.

Tips for Beginners

Start small.

Learn these concepts first:

Images
Containers
Volumes
Networks
Docker Compose

Once you understand these basics, everything becomes much easier.

Why Every DevOps Beginner Should Learn Docker

Docker is widely used in modern software development.

By practicing on a free cloud server, you gain real hands-on experience
instead of only watching tutorials.

That practical experience is valuable when starting a career in DevOps.

What's Next?

In the next article, I'll show how I use Nginx Proxy Manager to host
multiple domains on a single server.

Final Thoughts

Docker completely changed how I manage my server.

If you're starting your DevOps journey, learning Docker is one of the
best investments you can make.

Question for Readers

What was the first application you deployed with Docker? I'd love to
hear your experience in the comments!

Why I Chose Oracle Cloud Always Free for My Production Server

Asep Sayyad — Fri, 24 Jul 2026 14:23:29 +0000

When I wanted to host my own applications, I had one big problem---I
didn't want to pay every month for a VPS.

I was still learning Linux, Docker, and DevOps, so I wanted a place
where I could make mistakes, learn, and build real projects without
worrying about monthly costs.

That's when I found Oracle Cloud Always Free.

At first, I thought, "There must be a catch." A cloud server that stays
free forever sounded too good to be true.

After using it for my own projects, I realized it was exactly what I
needed.

Why I Didn't Choose Other Free Hosting

There are many free hosting services, but most of them have limits.

GitHub Pages is great for static websites.
Vercel is excellent for frontend applications.
Some free VPS providers only stay free for a limited time.
Many platforms don't give full control over the server.

I wanted a real Linux server where I could install anything, run Docker
containers, manage my own networking, and learn how production systems
work.

Oracle Cloud Always Free gave me that freedom.

What Oracle Cloud Always Free Gives You

With the Always Free tier, I could get:

A Linux virtual machine
SSH access
A public IP address
Block storage
Full root access
The freedom to install any software I wanted

It felt like having my own server in the cloud.

Why It Was Perfect for Learning DevOps

One of the biggest reasons I chose Oracle Cloud was the experience it
gave me.

Instead of only reading tutorials, I was able to work with real tools
like:

Linux
Docker
Reverse proxies
DNS
SSL certificates
Cloudflare
GitHub Actions
Server monitoring

These are the same technologies used by many companies.

If you're new to DevOps, building your own infrastructure is one of the
best ways to gain practical experience and confidence.

The Challenges I Faced

It wasn't always easy.

I made plenty of mistakes along the way.

Some of the challenges included:

Running everything on just 1 GB RAM
Learning Docker networking
Fixing DNS problems
Setting up SSL certificates
Configuring firewalls
Recovering from server issues

Every problem taught me something new.

Looking back, those challenges helped me learn much faster than simply
following tutorials.

Why I Still Use It

Even today, Oracle Cloud Always Free is still a great platform for:

Hosting personal projects
Learning Linux
Practicing DevOps
Building Docker applications
Running multiple websites
Experimenting without monthly costs

It may not replace a large production server, but it is more than enough
for learning and small real-world projects.

What This Series Will Cover

In this series, I'll share everything I learned while building my own
production infrastructure.

Upcoming articles include:

Building Production Infrastructure on Just 1 GB RAM
Setting Up Docker for Multiple Applications
Managing Multiple Domains with Nginx Proxy Manager
SSL Certificates with Let's Encrypt
Cloudflare Setup for Better Security
Monitoring a Low-Resource Server
Backups and Disaster Recovery
Common Problems I Faced and How I Fixed Them
What I'd Do Differently If I Started Again

Final Thoughts

Oracle Cloud Always Free gave me much more than a free server.

It gave me a place to learn, experiment, break things, fix them, and
gain real DevOps experience.

If you're just starting your DevOps journey, I highly recommend building
your own projects instead of only watching tutorials.

You'll learn much more by doing.

Next Article: Building Production Infrastructure on Just 1 GB RAM

Question for You

If you could build one project on a free cloud server today, what
would it be? Let me know in the comments!

Hello DEV! I'm Asep

Asep Sayyad — Fri, 24 Jul 2026 14:04:21 +0000

I'm Asep, a Linux and DevOps enthusiast from India.

I enjoy working with Linux servers, Docker, networking, Cloudflare, Oracle Cloud, and self-hosted applications. I like building projects, solving technical problems, and sharing what I learn along the way.

This blog is where I'll write about my real experiences, including things that worked, things that failed, and the lessons I learned from both.

Here are some topics you can expect:

Linux administration
Docker and containers
Oracle Cloud Always Free
Self-hosting applications
Networking, DNS, and reverse proxies
AI tools and automation
Open-source projects
Troubleshooting guides

I believe the best way to learn is by building real projects and solving real problems. Every challenge teaches something new, and I want to document that journey so others can learn from it too.

I'll also share updates about my open-source projects, how I build them, the problems I face, and the solutions that work.

If you're interested in Linux, DevOps, self-hosting, or automation, I hope you'll find these posts useful.

Thank you for reading, and I look forward to connecting with the DEV Community.

If you'd like to see what I'm working on, you can find me here:

Portfolio: asepsayyad007.in
GitHub: asepsayyad007 on GitHub

I'm always open to feedback, suggestions, and discussions. Feel free to connect!

What's the best self-hosted tool or service you've discovered recently?

DEV Community: Asep Sayyad

How to Search Anything in Linux: The Complete Terminal Survival Guide

1. Finding Files and Directories by Name, Size, and Date

The Classic find Tool

Searching by File Size

Searching by Modification Time

Executing Actions on Found Files

Fast Modern Alternative: fd

2. Instant Filesystem-Wide Search with locate and plocate

How locate Works

Updating the Search Database

3. Searching Text Inside Files with grep and ripgrep

The Classic grep Command

Lightning Fast Search: ripgrep (rg)

Real Production Scenario

4. Searching System Logs and Kernel Events

Searching systemd Logs with journalctl

Searching Kernel Messages with dmesg

Searching Rotated Log Files

5. Searching Command History Like a Master

Built-in Reverse Search: Ctrl+R

Searching History with Grep

Interactive Fuzzy Search: fzf

6. Searching Processes, Open Files, and Listening Ports

Searching Running Processes

Searching Which Process Holds a File

Searching Network Ports and Sockets

Real Production Scenario

7. Searching Executables, Libraries, and Package Owners

Finding Command Paths

Finding Which Installed Package Owns a File

8. Searching Kernel Parameters and Hardware Information

Searching Active Kernel Variables with sysctl

Searching Hardware Attributes in /proc

9. An Interesting Historical Fact About Linux Search

10. Summary Cheat Sheet

What Is Your Go-To Search Tool?

About the Author

Connect with Me

Enjoyed this article?

8 Linux Myths Even Senior Engineers Still Fall For (And How They Hurt Production)

Think years of experience make you immune to Linux misconceptions? Here are the bad habits, outdated knowledge, and deep technical myths that trap seasoned sysadmins and DevOps engineers.

1. Low Free RAM Means Your Server Is Running Out of Memory

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

2. Setting Swappiness to 0 Disables Swap Completely

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

3. High Load Average Always Means High CPU Usage

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

4. kill -9 Is the Normal Way to Stop Frozen Processes

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

5. Root Inside a Docker Container Cannot Harm the Host Machine

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

6. chmod 777 Is a Quick and Safe Fix for Permission Errors

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

7. A System Reboot Is Required After Upgrading Linux Packages

Why This Myth Exists

The Kernel Reality

How It Breaks Production

The Better Approach

8. Setting Low nice Values Guarantees CPU Allocation

Why This Myth Exists

The Kernel Reality

4. `kill -9` Is the Normal Way to Stop Frozen Processes

6. `chmod 777` Is a Quick and Safe Fix for Permission Errors

8. Setting Low `nice` Values Guarantees CPU Allocation

4. The lifesaver: `git reflog`

7. Pause your work with `git stash`