Hey, Everyone! After I published my second blog, I spent some time reflecting on where to go next.

I had finally made sense of what DevOps really meant—beyond the tools and buzzwords. I began to see it not just as a stack of technologies, but as a way of working—collaboration, automation, shared responsibility. That clarity felt good… for a while.

But then came the inevitable question:

“Now what?”

Because even though DevOps isn’t only about tools—you still need to learn them. But which ones? Jenkins? Docker? Terraform? Kubernetes? There were so many, and I didn’t know where to begin.

So I did what most people do—I followed roadmaps, watched tutorials, skimmed through blog posts. And no matter which path I looked at, one name kept showing up at the very beginning:

At one point, I didn’t even know what Linux was. I just remembered a friend once telling me that he had wiped his entire Windows OS and installed Linux instead. I didn’t ask why. I didn’t know what Linux did. But something about that move left an impression. It sounded cool in a way I didn’t fully understand.

Fast-forward a bit, and there I was—watching DevOps tutorials, reading blogs, trying out tools—and Linux was everywhere.
Servers ran on it. Tools were built for it. Documentation assumed you already knew it.

So, before diving headfirst into containers or automation, I knew I had to build a solid foundation in Linux. Not just how to use it — but how it worked. And that’s what this blog is all about.

💡 Disclaimer: This blog is going to be a bit longer than usual. But if you’ve ever felt overwhelmed learning Linux from random tutorials, stick with me. I’ve written this for people like me—curious, self-taught, maybe even a little intimidated. My goal is to walk you through Linux like you’re walking beside me.You might not become an expert in one sitting, but you’ll walk away understanding things. And that matters.

This blog is the start of a foundational journey into Linux. While most tutorials drop you in the middle with commands and cheat sheets, this blog aims to build your understanding step by step. Here's what we’ll explore:

1. Why Operating Systems Exist – starting from scratch

2. How Linux Came to Be – a brief, honest history

3. What Linux Is Made Of – its layered architecture

4. What Are Linux Distributions (Distros) – and why they matter

5. How Software Is Installed – understanding package managers

6. How Linux Organizes Itself – a look into the Linux filesystem

7. User and Group Management – why “root” isn’t always the answer

8. Process Management, Monitoring, and Networking

9. File Permissions - why should you care?

All nine linux fundamentals in one single blog, so you don't have to keep jumping between tabs.

Except in this case, it's nine Linux fundamentals—and you're Frodo. Let's begin.

And if Shell Scripting is something you’re planning to dive into soon—this blog will help lay the foundation for that. That’s where all this Linux knowledge really starts to come alive.

Why Do We Even Need an Operating System?

Before we even get to Linux, I had to understand one basic question:

Why does an Operating System even exist?

Let’s start from the ground up.

At its core, every computer is made up of hardware—things like CPU, memory (RAM), disk storage, and network cards.

Now, there are two main “actors” trying to use this hardware:

• Users like you and me, who want to store files, open browsers, play music.

• Applications like browsers, code editors, and games, which need CPU, memory, and disk to run.

But here's the thing—neither the user nor the application can directly talk to hardware.

Imagine you write a “Hello World” program in Python. Did you mention how much CPU to use? Or how to allocate memory? Of course not.

The application has no idea how to manage hardware.

Even users—when we type on a terminal or click on a folder—we’re not magically talking to a hard disk. We’re using interfaces like CLI (Command Line Interface) or GUI (Graphical User Interface)—and those interfaces don’t come from hardware.

So, who’s making the magic happen?

That’s where the Operating System comes in.

An operating system is a powerful piece of software that sits between you and your machine.

• It takes your actions and translates them into instructions the hardware can follow.

• It handles processes, memory, network traffic, devices, and much more.

• It’s the reason your Python program runs.

• It’s the reason your files save.

Whether it’s Windows, macOS, or Linux, the core idea is the same: the OS is the translator between software and hardware.

But in the world of servers, cloud infrastructure, and DevOps, one OS rules the space:

A Brief History of Linux

Once I knew I needed to learn Linux, the next obvious question was—what even is it?

And to answer that, I had to trace things back to understand why Linux is everywhere today.

The 1960s: Unix is Born

Back in the 1960s, computing was exclusive—massive mainframes, limited users, and very specific software. That’s when Unix was created. It was a powerful operating system designed to manage multiple users and programs efficiently.

It introduced concepts that we still use in Linux today: the file system, the idea of users and permissions, and the philosophy of “do one thing well” for commands and tools.

Unix wasn’t open source. It was owned, licensed, and limited.

But it planted the seed.

The 1970s–80s: Copies and Clones

Over the years, many people wanted something like Unix but free and more flexible.

A professor named Andrew Tanenbaum created a Unix-like OS called Minix—mainly for teaching purposes. It wasn’t open source either, but it inspired someone crucial to our story:

Linus Torvalds.

In the early 1990s, Linus—then a student—wanted a better version of Minix. Something that he and others could experiment with freely.

So, he built his own kernel (the core of an OS) from scratch and released it online for free. He named it Linux.

The 1990s–2000s: Linux Takes Off

Once Linux was released as open-source, something amazing happened: a community formed around it.

People from around the world started contributing—fixing bugs, adding features, making it more secure.

There was no single company behind it, no marketing budget, no corporate strategy—just people building something useful. Together.

And that made Linux stable, free, and secure—three qualities that are hard to find in commercial software.

It soon started running servers, powering websites, forming the base for tools like Docker, Kubernetes, and even Android.

Today, over 90% of production workloads on the internet run on Linux. That’s not hype—it’s reality.

So, no, Linux didn’t come out of a company boardroom or a product pitch. It came from curiosity, necessity, and collaboration.

And that’s why people care so much about it.

What Is Linux Made Of? (Understanding the Layers)

Once I understood that Linux was everywhere, I figured the next step was to understand what it’s made of. I used to think of an operating system as just a screen where icons live and I click stuff. But Linux? It had no icons when I first opened it. Just a blinking cursor. And all I could do was give it a hard stare.

So I asked the most basic question:

What’s going on under the hood?

Turns out, Linux isn’t just one giant thing. It’s layered, almost like a club sandwich—each layer having a specific job, and working together to make the system tick.

Let’s break it down.

At the Core: The Linux Kernel

At the very bottom, there’s the Linux Kernel.

Think of it as the brain of the OS. It manages everything you don’t see but rely on—like how memory is shared, how CPU time is divided between tasks, how your data is read from the disk.

If you think of a car, the kernel is the engine. You don’t usually mess with it directly, but without it, nothing moves.

On Top: System Libraries & Utilities

Above the kernel, you’ve got System Libraries and System Utilities.

• System Libraries are like interpreters—they help your programs “speak” to the kernel.

• Utilities are those classic Linux commands you’ll soon fall in love with: ls, grep, systemctl, etc.

These are like the tools and wiring inside the car—making sure everything communicates and functions properly.

Closer to You: The Shell

Above that sits the Shell—your main interface.

Whether you use Bash, Zsh, or Fish, the shell is the command-line tool that lets you talk to Linux. It takes your command and passes it along the line, eventually reaching the kernel through all the layers.

If the kernel is the engine, then the shell is the steering wheel and dashboard.

On Top: User Applications

And finally, there are User Applications. These are tools you install and run—like Apache, Nginx, Vim, Docker, etc.

So the structure looks something like this:

+---------------------------------------------+
| User Applications (Vim, Docker, Nginx...)   |
+---------------------------------------------+
| Shell (Bash, Zsh, etc.)                     |
+---------------------------------------------+
| System Libraries & Utilities                |
+---------------------------------------------+
| Linux Kernel                                |
+---------------------------------------------+
| Hardware (CPU, RAM, Disk, etc.)             |
+---------------------------------------------+

Understanding this gave me the clarity which I needed.

Why Are There So Many Versions of Linux? (Understanding Distros)

Once I got a handle on what Linux is made of, I started noticing something strange. Every tutorial or blog I came across mentioned a different “flavor” of Linux:

Ubuntu.
CentOS.
Fedora.
Debian.
Arch.
OpenSUSE.
Alpine...

And I was like—hold on, aren't we all talking about Linux?

Why so many versions?

That’s when I learned about Linux distributions, or as the cool kids call them—distros.

What Is a Distro?

A Linux distro is like a custom version of Linux.

Remember how we talked about Linux being open source? That means anyone can take the Linux kernel, mix it with different system utilities, add their own tools, themes, settings, and release it as their own version of Linux.

So the core engine (the kernel) remains the same, but the experience, look, feel, and toolset can vary wildly.

Think of it like pizzas.

Everyone starts with dough, cheese, and sauce (the kernel + basic utilities). But then some add olives, some go heavy on the jalapeños, and some make it pineapple-friendly. The result? Distinct pizzas. Or in our case—distinct Linux distros.

Some Popular Distros and What They're Known For:

In my DevOps journey, I stuck with Ubuntu. It had great community support, lots of tutorials, and—let’s be real—it didn’t feel like it wanted to punish me for being a beginner.

But here’s the catch: even though distros differ in packaging and UI, the core concepts stay the same. So if you learn one properly (like Ubuntu), you can easily jump into others.

Now that I had Linux installed and chose a distro to work with, the next thing I hit was this:

“How do I install software in Linux? Is there an App Store?”

Installing Software on Linux? Meet the Package Manager.

After I had Ubuntu up and running, the next obvious step was to install things. You know—tools, servers, editors, browsers, whatever I needed to experiment and build stuff.

But this wasn’t like Windows where you go to a website, click “Download,” then “Next → Next → Finish.”

Instead, I was introduced to something called a package manager.

At first, the idea sounded… intimidating. I mean, "package manager" sounds like something you’d find in a logistics warehouse, not on your laptop. But once I understood it, it turned out to be one of the most powerful things about using Linux.

What is a Package Manager, Really?

Imagine your Linux system is a LEGO base. Every tool or software you want to use is a LEGO piece.

A package manager is like your personal LEGO store—it:

• Finds the piece you want,

• Checks if you need any other pieces (dependencies),

• Downloads them for you,

• Puts them all together, in the right spot, in the right way.

No mess. No missing parts. No clicking around.

Repositories: Your Software Supermarket

Where does it fetch all this software from?
From a centralized location called a repository.

Repositories (or repos) are like verified software warehouses. Each distro has its own default repos. For Ubuntu, it's usually archive.ubuntu.com.

When you install something using a package manager, it checks the repo, finds the software, and pulls it down with all the bits it needs to run.

Some Popular Package Managers (Depending on the Distro)

So in Ubuntu, I’d use apt.

By now, I was feeling pretty confident. I had a distro. I could install tools. I even knew how the OS was layered beneath me.

But then I started noticing something weird...

Whenever I typed ls or cd or cat, it worked. But… where were these commands even coming from?

That question led me into one of the most fascinating parts of Linux:
Its file structure.

What’s Inside a Linux System? Exploring the File Structure

The first time I opened a Linux terminal and ran:

ls /

I was hit with a bunch of folder names that made no sense:

bin  boot  dev  etc  home  lib  media  mnt  opt  proc  root  run  sbin  srv  sys  tmp  usr  var

And honestly, looking at some of those folder names, I couldn’t help but think:

The good news is once you understand the logic behind this structure, it all clicks.

Everything Starts from /

Unlike Windows, where you have C:\, D:\, and maybe even an E:\, Linux has one single root:

/

This is the root of everything. Every file, folder, and subdirectory stems from here.

Think of / like the trunk of a tree—everything else branches out from it.

Why Is the Structure So... Weird?

Because Linux is built for order and predictability. It separates things based on purpose and access level, not random preference.

Let me walk you through the most important folders.

Key Directories You’ll Run Into

Let’s break down a few interesting ones.

/bin vs /sbin

Both store essential commands. So what’s the difference?

• /bin is for everyone (commands like ls, mkdir, cp, etc.)

• /sbin is for system-level tools (commands like shutdown, useradd, iptables)

So if I give you access to /bin, you can explore files.
If I give you /sbin, you could literally bring the system down. Hence, it’s usually reserved for root or sudo users.

/home and /root

All users get their personal folder under /home.

So if you create a user called arnab, their space is /home/arnab.

But the superuser, root, gets a special VIP room: /root

/etc – The Control Room

This is one of the most important folders in Linux. Why?

Because it holds configuration files.

Need to change network settings? It's in /etc.

Want to tweak how services start? Look in /etc.

Some famous files here:

• /etc/passwd – Stores user account info

• /etc/hosts – Maps IPs to domain names locally

• /etc/os-release – Shows what OS/distro you’re using

But... How Does Linux Even Find ls?

Let’s say I type:

ls

How does Linux know where that command lives?

There's a special environment variable called $PATH—a list of folders that Linux automatically checks when you type a command.

If ls is in one of those folders (like /usr/bin/ls), it just runs it.

You can see your own $PATH using:

echo $PATH

This is Linux’s way of saying:

“Hey, when you ask me to run something, I’ll check these places first.”

Understanding this structure helped me see Linux not as a black box, but as a logical, organized system that treats you like a responsible adult.

And once I understood the file system, I began wondering:

"Wait—who decides who gets access to what?"

That question led me to another foundational concept:

Why Do We Even Need User and Group Management?

When you buy a personal laptop, you usually set up just one user—you. That user can install apps, delete files, and do pretty much anything.

But Linux servers are not personal laptops. They’re shared spaces, often used by dozens or hundreds of people. Think developers, testers, DevOps engineers, even automation scripts—all accessing the same machine.

Without user separation, imagine the chaos:

One person deletes a system file by mistake.
Another one changes server settings they shouldn’t touch.
No accountability. No safety. Just one wrong rm (command to delete somthing in linux) away from disaster.

That’s why Linux introduces users and groups, along with strict permissions.

Creating a User

Let’s say we’re creating a new user named arnab.

You could do it two ways:

Option 1: The basic way

useradd arnab

This creates the user but doesn’t give them a password or a proper home directory. It’s quick—but not super useful for day-to-day access.

Option 2: The practical way

adduser arnab

This one’s better. It sets up:

• A home directory at /home/arnab

• Basic user info

• Prompts you to set a password

You can now switch to that user:

su - arnab

And check who you are:

whoami

Permissions in Action

Now here’s where it gets interesting.

Let’s say you're logged in as arnab and you try to delete a critical system folder like /sbin.

rm -rf /sbin

You’ll hit:

Permission denied

Linux stops you. Because arnab doesn’t have superuser privileges.

This is user-level protection at work. You only get access to what you need, nothing more.

What About Groups?

Managing 5 users is easy.

Managing 500? Not so much.

Let’s say your organization has:

• 200 developers

• 150 testers

• 50 DevOps engineers

Now imagine you need to change a permission on a folder—but only for the DevOps team. Are you going to update it 50 times manually?

That’s where groups come in.

You can:

1. Create a group called devops

    groupadd devops
   

2. Add users to that group

    usermod -aG devops arnab
   

Now, instead of managing users one by one, you control access group-wise.

View All Users and Groups

• View users:

    cat /etc/passwd
  

• View groups:

    cat /etc/group
  

• View encrypted passwords:

    cat /etc/shadow
  

But no, you can’t decrypt Linux passwords. They’re hashed and one-way encrypted. Even as an admin, you can only reset them—not recover them.

This system of users and groups gave me a newfound respect for how Linux balances power and control. It's not just secure—it’s elegant.

But here's the twist...

Once multiple users start running programs, Linux also needs a way to keep track of all those running things—to decide which gets CPU time, which is hogging memory, and which needs to be killed.That takes us to our next stop:

Process Management, Monitoring and Networking

What Exactly Is a Process?

A process is just a running instance of a program.

That could be:

• A Python app doing data crunching

• A Jenkins job running a pipeline

• A background service like cron

And every time you run a command in Linux—even ls—you’re creating a tiny process.

But here’s the thing:

Your Linux server isn’t running just one process.
It’s running hundreds—all demanding CPU, memory, disk, and network.

So as DevOps engineers or Linux admins, we need to:

1. List and inspect these processes

2. Kill or pause the ones misbehaving

3. Prioritize the important ones

4. Monitor the overall system health

1. Checking Running Processes

Start with the basics:

ps

But this barely shows anything.

For a complete list, use:

ps aux

This shows:

• The user who started the process

• CPU & memory usage

• Start time

• Command that triggered it

• And most importantly, the PID (Process ID)

If you want a cleaner look at all processes:

ps aux | less

Or even just count them:

ps aux | wc -l

You can also search for a specific process. Let’s say you're hunting a rogue Java app:

ps aux | grep java

2. Killing a Process

Sometimes a process consumes way too many resources or just hangs.

To kill it, you need its PID. Then:

kill 1234

If that doesn’t work:

kill -9 1234

The -9 forces termination. But be careful—use it only if normal kill doesn’t work.

Want to pause a process instead?

kill -STOP 1234

And to resume it:

kill -CONT 1234

Prioritizing Processes with renice

Linux lets you tell the CPU which processes are more or less important using a concept called niceness (yes, that’s the actual name).

renice -n 10 -p 1234

• A lower number means higher priority

• A higher number means lower priority

Be very careful with this—don’t reprioritize system processes unless you’re absolutely sure what you're doing.

Real-Time Monitoring

Want to keep an eye on what’s happening right now?

Use:

top

This updates in real-time and shows:

• CPU usage

• Memory consumption

• Uptime

• Top processes by resource usage

If you want a more user-friendly version of top, try:

htop

(You might need to install it first: sudo apt install htop)

Disk and Memory Monitoring

Some other helpful monitoring commands:

• Memory info:

    free -h
  

• CPU count:

    nproc
  

• Disk usage:

    df -h
  

• Disk usage per folder:

    du -sh *
  

What About Services?

Here’s a new twist: not all processes are started manually.

Some start automatically when the system boots. These are called services.

For example: cron, nginx, ssh, etc.

You can list all services:

systemctl list-units --type=service

To start a service:

sudo systemctl start nginx

To stop it:

sudo systemctl stop nginx

Why does this matter?

Because as a DevOps engineer, you’ll often deploy or maintain services—not just one-off scripts. You’ll need to make sure your web server or CI/CD tool runs automatically after reboot, as a background service.

Process vs Service

Once I learned to monitor and manage processes like this, it made my Linux experience feel a lot more in control. No more mystery lags. No more guessing why a system was slow.

But processes don’t just float in isolation.
They rely on storage (disk management) and connectivity (networking).

And before we wrap up, let's touch those too—lightly but meaningfully.
User and Group Management — Let’s move to that next.

Disk Management in Linux

So far, we've talked a lot about running commands and managing processes. But eventually, you’ll need to manage storage—adding more space, attaching volumes, or checking disk usage.

Let’s start with this:

How to Check Disk Usage?

Run this:

df -h

• df = Disk Free

• -h = Human-readable (MB/GB)

This shows you how much space is used, how much is available, and where your storage is mounted (like /, /home, etc).

Want to see which folder is taking up the most space?

du -sh *

This gives you a summary (-s) of each item in the current directory, in human-readable format.

Adding New Storage to a Linux Server

In the cloud or on physical machines, you might attach a new volume for extra space.

But here’s what most people don’t know:

Just attaching the disk doesn’t mean Linux can use it.

You have to:

1. Format the volume (usually to ext4 or xfs)

2. Mount it to a folder like /mnt

3. Optionally add it to /etc/fstab so it auto-mounts at reboot

The full workflow looks like:

lsblk                            # Check the new block device
sudo mkfs.ext4 /dev/xvdf         # Format it
sudo mkdir /mnt/data             # Create mount point
sudo mount /dev/xvdf /mnt/data   # Mount it

Now /mnt/data has your new disk.

In most DevOps jobs, you won’t be doing this daily—but knowing how it works is important for managing infrastructure and automation scripts.

Networking Basics in Linux

Networking deserves its own blog series—but you need just a few basics to feel comfortable at this stage.

What is SSH?

SSH (Secure Shell) is how we connect to remote Linux servers.

If you’ve seen this before:

ssh ubuntu@your-server-ip

That’s an SSH login.

Linux servers run an SSH daemon (sshd) in the background, listening on port 22.

On your local machine, you’re using an SSH client to securely connect to that server.

Checking Network Info on Linux

Want to see your server’s IP address?

ip a

Want to test if a remote host is reachable?

ping google.com

Want to know which ports are open and which services are using them?

sudo netstat -tulnp

(You may need to install net-tools for this.)

By the time I got a grip on managing processes, monitoring services, and even peeking into memory or network usage, Linux felt less like a black box and more like a machine I could talk to.

But then something strange kept happening.

Sometimes I’d try to edit a file—Access Denied.
Try to delete a script—Permission Denied.
Or run a command from a script I just wrote—Command not found or Permission denied again.

At first, I thought I was doing something wrong.

But it wasn’t me.

Linux doesn't just give you free rein over everything—even if you’re logged into the system. It has strong guardrails. And a big part of those guardrails are:

Understanding File Permissions in Linux

This section might look like a matrix of letters and numbers at first, but once you crack it, permissions will stop being scary and start making sense.

Whether I was trying to edit a file or delete something I had just created under a different user, Linux stood firm. That’s when I realized—I needed to understand how Linux controls access to files and folders. And this is where file permissions and ownership come into play.

They’re not just rules. They’re how Linux keeps control—over who can see what, who can change what, and who owns what.

There was a time when I tried switching users in Linux and suddenly couldn’t delete or edit a file I just created moments ago. It wasn’t a mistake. It was Linux doing what it was designed to do—protect its files.

But unless you understand why it does that and how it works, this behavior feels like hitting invisible walls.

Let me walk you through it the way I wish someone had explained it to me from the very beginning.

Who’s Who? The Three Faces of File Access

Every file and folder in Linux comes with a built-in security layer. It doesn’t matter whether you create a file manually or a program generates it—Linux immediately assigns ownership and sets up who can access it.

There are three “types” of people Linux cares about when it comes to any file:

1. User (u)

This is the creator of the file. If you're logged in as developer and you create a file called helloworld.sh, then you are the user owner of that file.

2. Group (g)

Every user belongs to a group. Think of it like teams: devs, testers, admins. When a file is created, it also gets a group owner—usually the group that the user belongs to. So if the developer user is part of a group called developer, then the file will be assigned to that group.

3. Others (o)

Everyone else on the system. These are users who are not the creator and are not part of the file’s group. So if there's another user on your system named qe, and they're not in the developer group, they are treated as “others” for the file created by developer.

That’s it—User, Group, Others.
Three categories. And Linux uses them to decide who can read, write, or run a file.

A Simple Practical Example

Let’s try something basic to see this in action:

Step 1: Create Two Users

sudo adduser developer
sudo adduser qe

Set passwords when prompted. Leave the other details blank.

Now, open two terminal tabs—one as developer, one as qe.

Step 2: In the developer tab

cd /tmp
vim helloworld.sh

Inside the file, write:

#!/bin/bash
echo "Hello from Developer"

Save and exit.

Step 3: In the qe tab

Try the following:

cd /tmp
cat helloworld.sh        # ✅ You can read it
vim helloworld.sh        # ❌ You'll see: "Can't open file for writing"
rm helloworld.sh         # ❌ You'll see: "Operation not permitted"

Even though both users are on the same machine, qe cannot modify or delete the file created by developer.

Why?

Because of default Linux file permissions.

Let’s Decode File Permissions

Run this command under either user:

ls -l helloworld.sh

You’ll see something like:

-rw-r--r-- 1 developer developer  43 Jun 27 22:12 helloworld.sh

Let’s break that down.

Section 1: -rw-r--r--

This part is key. It’s made up of 10 characters:

So in plain English:

• The user (developer) can read and edit the file

• The group can read, but not write or execute

• Everyone else (like qe) can only read

No wonder qe couldn’t modify or delete the file—they didn’t have write permission.

Section 2: developer developer

The first developer is the user owner.

The second developer is the group owner.

So this file is owned entirely by the developer user and their group.

Changing Permissions with chmod

Now let’s say you want to give full permissions to the file owner.

You can do this:

chmod u=rwx helloworld.sh

That means:

• u → you’re modifying the user's permissions

• rwx → read, write, execute access

The Numeric Shortcut to Permissions

Linux has a number system to represent permissions:

You add the values to get desired permissions:

• rwx → 4+2+1 = 7

• rw- → 4+2 = 6

• r-- → 4

So if you want:

• User: Full access → 7

• Group: Read/write → 6

• Others: Read-only → 4

You can do:

chmod 764 helloworld.sh

That’s the same as:

chmod u=rwx,g=rw,o=r helloworld.sh

Now helloworld.sh will be writable and executable by its creator, writable by the group, and readable by others.

What If You Want to Hand Over Ownership?

Permissions are one thing. But what if you want to completely transfer ownership of a file to another user?

Say developer created a file but now wants qe to fully own and manage it.

That’s when you use the chown command.

Changing Ownership with chown

Let’s try this:

sudo chown qe:qe helloworld.sh

This does two things:

• Changes the user owner to qe

• Changes the group owner to the group qe

Now if you run ls -l again:

-rw-r--r-- 1 qe qe 43 Jun 27 22:12 helloworld.sh

qe is now in charge. They can edit it, delete it, or update permissions.

Note: Only the root user (or someone with sudo) can change file ownership. If you try this as a regular user, Linux will stop you with “Operation not permitted“ error.

Why This Matters

In DevOps, you’ll often deal with files created by automation scripts, services, or users from different teams.

Understanding who can access what, and how to change those rules, is critical for security and reliability.

It’s not just about memorizing commands—it’s about knowing what’s going on under the hood.

Funny how something as small as a permission flag can break an entire deployment, isn't it?

You Now Understand the Foundation

Let’s take a moment to pause.

You now know:

• Why Operating Systems exist

• How Linux emerged and why it matters

• Linux’s structure and architecture

• The role of distributions and package managers

• The file system and important folders

• How users, groups, and permissions work

• How to manage and monitor processes

• Basics of disk and network management

• Understanding File Permissions in Linux

That’s a lot—and if you made it this far, I hope you’re not just informed but also feeling more confident.

Also, a quick shoutout: A big part of this clarity came from watching Abhishek Veeramalla’s Linux video on YouTube. His breakdown helped me finally connect a lot of dots, and I’d definitely recommend checking it out if you want another solid explanation from someone who just gets it.

Final Thoughts

Learning Linux as a beginner can feel like being dropped into a dark forest with no map. My goal with this blog was to light a few paths, help you make sense of the terrain, and most importantly—show you that it’s not as scary as it seems.

You don’t need to know everything at once.
You just need to keep exploring.

And now, you have a solid foundation to stand on.

A Personal Note Before You Leave

Dear reader, I’ve tried my best to explain Linux in the simplest way I could.
But here’s the truth:

If I—the beginner version of myself who had just heard the word “Linux” for the first time—somehow stumbled upon this blog written by future me, I would still feel underconfident.

I know what that feels like.

I used to mix up the most basic commands. I used to wonder "Am I even cut out for this?" And I still do sometimes. Learning Linux, or anything new in tech, is rarely a straight line.

You might even feel like, “Wait, not every command was explained here,” or “Some parts still feel fuzzy.”

That’s okay.

Here’s what’s helped me more than anything:
Make Googling (and maybe ChatGPT-ing, if that’s a word :P) your best friend.

If something doesn’t make sense, pause.
Google it. Explore it.
Read multiple answers. Try the commands. Break things (safely). Go down rabbit holes. Get curious.

This is the one thing that only comes with experience. And that experience starts by not being afraid to feel confused.

So if you’re reading this and feel like some parts didn’t click—don’t worry.
You’re not behind. You’re just getting started. You’re exactly where you need to be. And that’s more than enough.

You’ve got this.

(Every Linux journey starts at /root, after all ;))