Learning Log #01: Getting Back to the Linux Basics

#devops #linux #learning

I've been spending a lot of time using AI in my daily development workflow.

Whether it's writing code, setting up an environment, deploying a project, or debugging an issue, AI has become one of my go-to tools. It saves me a lot of time, and honestly, it's pretty hard to imagine going back to working without it.

But there's one thing I've been thinking about lately.

Sometimes, I can get a problem fixed without really understanding why it happened in the first place.

I might ask AI for a command, run it, and move on once everything works. That's convenient, but I don't want to end up in a situation where I have no idea what to do when the suggested solution doesn't work.

So today, I started going back to the basics. Linux is where I'm starting.

What I worked on today

Nothing too fancy. Just the fundamentals.

I spent some time practicing file operations, user permissions, process management, and basic networking.

A few commands I worked with:

ls, cd, cp, mv, rm for navigating and managing files
whoami, id, groups, chmod, chown for users and permissions
ps, top, kill for working with processes
systemctl, journalctl for checking services and logs
ip a, netstat, ping, curl for basic networking

I've used some of these commands before, but there's a difference between knowing what to type and understanding what the output actually tells you.

For example, a service being active doesn't necessarily mean the application is working correctly. And just because a port is listening doesn't mean the service is reachable from outside the machine.

These are simple things, but they're worth understanding properly.

A small issue I ran into

I was using an online Linux terminal to practice checking services and logs. At some point, a few commands started behaving differently from what I expected.

Initially, I thought I was doing something wrong. After comparing the outputs, though, I suspected that the environment was simulating some Linux functionality.

That meant I couldn't simply treat every result as if it came from a real Linux server.

I haven't verified every detail yet, so I'll need to test some of this in a proper Linux environment later.

Still, it was a useful reminder: sometimes the problem isn't your command. It might be the environment you're working in.

Why I'm doing this

I've already worked on projects involving frontend development, backend development, databases, and Git. But building a project and being able to independently deploy, maintain, and debug it are two different things.

I don't want AI to become a substitute for understanding the tools I use every day.

I'll keep using it, of course. I just want to get better at understanding its suggestions, checking whether they make sense, and figuring things out when they don't work.

For now, I'll keep working through Linux, networking, Docker, and deployment, then apply what I learn to my own projects.

No rush to master everything overnight. I'd rather understand a few things properly than blindly memorize a hundred commands.

One step at a time.

Keep learning, keep building = w =.