Learning Linux for Real This Time

I can SSH into a machine, run Docker commands, edit a config file, and restart a service. I have been doing this for years across numerous Raspberry Pi, and a homelab full of Linux boxes. But if you asked me to explain what happens when I type systemctl restart grafana, or why one file has permissions 755 and another has 644, I would give you a confident-sounding answer that is probably only half right.

That is getting by. I want to actually know it.

The gap

Here is what “getting by” looks like in practice:

• Editing files — I used to grab nano, make a change, Ctrl+O, Ctrl+X. I have never properly learned vi/vim. Previously I would search how to quit, then something changed. I took a few minutes to think about the simplicity and history of vi, which was included in BSD Unix releases from the late 1970s-1980s and POSIX requires a vi-compatible editor although systems like macOS launch Vim in “vi-compatible mode” with the vi command.
• Permissions — I chmod 777 things when they do not work and feel vaguely guilty about it. I know this is wrong. I do not fully understand why it is wrong beyond “it is too open.”
• Shell scripting — I can cobble together a bash script that works, but I do not understand half the syntax I am using. What is set -euo pipefail actually doing? I copied it from a blog post.
• Process management — I know ps and kill. I do not know what signals are or why kill -9 is different from kill.
• Networking — I can find the ip address of an interface and use netstat with grep to filter. I could not explain what iptables is doing or troubleshoot a routing problem from first principles.
• Package management — I run apt update && apt upgrade and hope for the best. I do not know what a PPA is or how to pin a package version.

None of this has stopped me from building things. But it limits what I can debug, what I can optimize, and how confidently I can make changes.

The plan

I am not going back to school for this. I am going to learn by doing — but deliberately, instead of reactively.

Phase 1: The editor. Learn vim properly. Not just enough to exit, but enough to use it as my default editor over SSH. Motions, modes, registers, the basics. If I am going to spend time in terminals, the editor should not be a bottleneck.

Phase 2: Permissions and users. Actually understand the Unix permission model. Users, groups, file modes, sticky bits, setuid. Why 755 makes sense for directories. Why 777 is a security problem, not just a bad habit. How to figure out which user a service runs as and what it needs access to.

Phase 3: Shell fundamentals. Read a bash reference instead of just Stack Overflow snippets. Understand pipes, redirects, subshells, exit codes, and signal handling. Write scripts that are not held together by optimism.

Phase 4: Systemd and process management. Understand how services start, stop, and restart. What a unit file does. How to read journalctl output. What happens during boot. How to troubleshoot a service that fails to start without just rebooting.

Phase 5: Networking from the ground up. Interfaces, routes, DNS resolution, firewall rules. Not just enough to set a static IP, but enough to diagnose why two machines on the same network cannot talk to each other.

Why now

I have been leaning on AI tools and copy-pasted commands to fill the gaps. That works until it does not. When something breaks in a way that does not match a Stack Overflow answer, I need to be able to reason about the system from first principles.

The homelab is the perfect learning environment. I have real machines, real services, and real problems. I just need to stop reaching for the quick fix and start understanding why the fix works.

How I will track this

I plan to write TIL posts as I go — short notes about specific things I learn. Not tutorials (plenty of those exist), but honest notes from someone filling in gaps they should have filled years ago. If that is useful to someone else in the same boat, great.

First up: learning vim well enough to stop being afraid of it.