Learning note / Updated July 2026
The useful skill is not memorizing a command. It is defining the question, connecting process, file, and network evidence, and knowing what to verify next.
01 / Foundation
I began using Linux through live boots, full installations, and eventually daily use. Package failures, drivers, permissions, boot problems, networking, and desktop configuration forced me to become comfortable when the system did not behave as expected.
Different distributions served different purposes. Mint was stable enough for daily work, Kali provided a controlled environment for security tools, and Arch made more of the operating system’s construction visible.
02 / Questions
Use top, ps, and pstree to identify resource use, ownership, and parent-child relationships.
Use ss -tulpn to connect listening TCP or UDP ports with the processes behind them.
Use /proc, readlink, and lsof to trace what a process runs and which files it has open.
Ask which identity owns the resource, how it starts, and why access differs from the expected state.
03 / Method
04 / Boundaries
This is foundational systems and security practice, not professional incident response or penetration-testing experience. Nmap and Metasploit remain introductory lab tools; the stronger evidence here is the ability to trace processes, sockets, files, services, and permissions carefully.
Do not test systems you do not own or have explicit permission to assess. Keep experiments inside defined labs, document changes, and treat unexpected access as a reason to stop.
05 / Outcome
The lasting value is comfort with unfamiliar systems and broken states. Security, support, implementation, and software roles all benefit from the same habit: stay precise long enough to find the real failure instead of reacting to the first visible symptom.