DEV Community: Ayush Gupta

How Linux Works - Chapter 1: A Concise Summary for Beginners

Ayush Gupta — Fri, 23 Oct 2026 01:23:01 +0000

At first glance, Linux sounds strange and unapproachable, like that one girl you know. She looks at you from the corner of her eye, but you being you, you never managed to gather enough courage to just go talk to her!

I’m sorry, but I unfortunately can’t help you with that particular quagmire. I can promise to make Linux more approachable for you through a chapter-by-chapter deep dive.

I will be using How Linux Works (3rd Edition) by Brian Ward. This book is not only updated to teach how modern Linux works, but also gives you a deep enough dive to understand all layers of abstraction.

Abstraction? Nothing fancy, to be honest. It’s just a word that means you can ignore most of the details that make up the component at hand and focus on what it does and how it works.

Simple example: to drive a car, you do not need to know how the engine works, you just need to know how to drive. But if you are a car mechanic, you must know engines in order to repair them, though you still don’t have to worry about the source of the iron used to make the engine in the first place. So basically, it’s abstraction on top of abstraction.

As for Linux systems, there are three main layers of abstraction.

Hardware layer - This is where all the physical components of your system live. For example, the CPU, keyboard, memory, etc.
Kernel layer - The heart of the Linux system. It is an interface between the user and hardware layers. The kernel is responsible for managing processes (a process is simply a running instance of a program), drivers, the CPU, etc.
User layer - This is where you and I live, along with the programs that we use. Each process running here has its own share of the computer’s hardware and is managed by the kernel.
Show Image

Main Memory and State

Before we go further, a quick word on main memory (RAM), since everything else depends on it. Think of it as a giant row of tiny switches, each one either 0 or 1. These are called bits. Everything your computer is working on right now lives in there, and the CPU reads and changes those bits all day long.

The exact arrangement of those bits at any given moment is called state. A running process is really just its state sitting in memory, nothing more mysterious than that. Keep this in mind, because it comes back later.

Kernel vs User Processes

User programs do not have unrestricted access to memory. What if someone using malicious software tried to modify important files your running program needed? To prevent this, user programs are given their own separate memory space in RAM, and the kernel sets the rules for what each process can touch.

User programs run in user mode and have restrictions, while the kernel runs in unrestricted kernel mode.

Understanding the Kernel

As previously mentioned, the kernel provides an abstraction between the user and the hardware. An OS is more than a kernel, but the kernel is one of its main components. There are many jobs the kernel must perform:

Processes - The kernel keeps track of which process is allowed to use the CPU.
Memory- The kernel needs to keep track of all memory: what is currently in use by a particular process, what might be shared between processes, and what is free.
Device drivers - The kernel acts as a medium between hardware and processes. It’s the kernel’s duty to operate the hardware.
System calls and support - System calls are the primary way for a process to communicate with the kernel.

Now we will briefly touch on each of these responsibilities.

Process Management

Process management means everything from the start to the termination of processes. To be precise: starting, pausing, resuming, scheduling, and terminating them.

On a modern operating system, we tend to see processes running “at the same time”. In reality, each process (talking strictly about a single-core CPU) runs one at a time, but switching from one process to another is so fast that it seems as if they are running simultaneously. Each process runs for a short while, then the kernel stores its state (CPU registers, memory, etc.), pulls in the next process, loads its data, and resumes it. This is known as context switching.

The kernel is responsible for context switching. To understand how it works, suppose a process has been running for its time slice and the time is now up. The kernel prepares to switch from that process to another one waiting to run:

The CPU interrupts the running process based on its internal timer and switches into kernel mode. This gives the kernel total control.
The kernel stores the current state of the process.
The kernel takes care of any pending work, like finishing up an I/O request the process had made.
The kernel analyzes the queue of waiting processes and picks one according to its scheduling policy.
The kernel loads the selected process and its data.
The kernel tells the CPU how long to run the process and switches the CPU to user mode, where the process takes control of the CPU.

Memory Management

Memory is a big deal. The kernel does the supreme job of managing memory, which is a complex task. The following conditions must hold:

The kernel must have a private area in memory that no process can access.
Each user process must also have its own private section in memory.
One user process may not access the private memory of another process.
User processes can share memory.
Some memory in user processes can be read-only.
The system can use more memory than its actual size by using disk space as an auxiliary.

Modern CPU architecture includes an MMU (Memory Management Unit) that helps with address translation. When a process tries to access memory, it does not use the real address. The requested address is a virtual address, which the MMU translates into the actual physical address. This prevents the process from accessing parts of physical memory that are not its own.

Device Drivers and Management

Device drivers are typically part of the kernel. They translate generic system calls like read(), open(), etc. into actual machine signals. They run in privileged kernel space, where they have access to raw hardware.

System Calls and Support

System calls allow a user process to do tasks that it cannot do on its own. Examples of system calls include read(), write(), open(), and fork().

A quick note: you might see malloc() mentioned alongside these, but it isn’t a system call itself. It’s a C library function that sits on top of system calls like brk() and mmap() to ask the kernel for memory.

To start a process, we need to understand two system calls in particular:

*fork() *- The process creates a 1:1 copy of itself. The copy inherits all the state of the parent process.
*exec() *- It comes in many forms, but essentially it replaces the current process with the one specified (exec(program)).

Other than init (PID 1, the very first process the kernel starts), every process is started by another process. When you type “ls” in the terminal, the following happens:

In plain words: your shell (the program you’re typing into) calls fork() to make a copy of itself. That copy, called the child, then calls exec(“ls”), which swaps it out for the ls program. Meanwhile, the original shell (the parent) just waits until ls is done, then hands you your prompt back.

User Space

User space is where all the real work happens, since each process is just a state in memory. User space refers to the entire collection of memory used by running processes.

From the kernel’s point of view, all programs running in user space are technically equal. Some processes make use of others for specific functions. The processes close to the user expose many features, but as we move away from the user, we get to processes that perform one task and do it well. For example, a program like vim exposes a full text editor with advanced features, while a program like grep (which is also very powerful) helps you find text in a file blazing fast.

Users

One last thing before we wrap up. Every process in Linux is owned by a user. That is how the kernel decides who is allowed to do what. A regular user can play around with their own files and processes, but not with anyone else’s.

Then there is root, also known as the superuser. Root can do anything, no questions asked, think of it as the master key to the whole system. Great power and all that, so be careful: one wrong command as root and you can break your entire system.

TL;DR

Linux has three layers of abstraction: hardware, kernel, and user.
A running process is just state (a pattern of bits) sitting in memory.
The kernel manages processes, memory, device drivers, and system calls.
Processes take turns on the CPU so fast it looks simultaneous. This is context switching.
The MMU translates virtual addresses to physical ones, keeping processes out of each other’s memory.
New processes are born through fork() (copy yourself) and exec() (become something else).
Every process belongs to a user, and root is the all-powerful one.

Conclusion

I hope you enjoyed my concise but complete overview of chapter 1 of “How Linux Works”. Please like and follow me so I can keep making educational content, improve myself, and provide you all with greater value.

Thank you very much for reading. I’ll see you in the next one!

Finally: GO channels explained

Ayush Gupta — Thu, 11 Dec 2025 21:18:39 +0000

Learning Go was going just fine until I met you—channel. You pipe-looking snitch. This guy can't hold a secret! Always ready to gossip.

Go channels sit right at the center of Go multi-threading. They make data transfer between goroutines as simple as bread and butter.

Now let's get serious... like really serious about Go channels and how they function. But before we start exploring them, I have to promise you something: By the end of this blog post, you will have a basic understanding—even much more than that—about channels. And on this unshakeable foundation, you will be able to build your building of further, more advanced topics. This blog is not written "bookishly"—loosely translated as not being ordered in such a way that it feels boring by going too much into theory. Let's get our hands dirty from the start!

Creating our first channel

package main

import (
    "fmt"
    "time"
)

func PrintValue(channel chan string) {
    fmt.Println(<-channel)
}

func main() {
    channel := make(chan string)
    go PrintValue(channel)
    channel <- "hello"
    time.Sleep(time.Second * 2)
}

Here is our channel! It sends a string from the main thread to a goroutine. The goroutine, on receiving data from the main thread, prints the value.

Why did I use time.Sleep() here?

It is just for the purpose of demonstration. In real-world scenarios, we are better off using WaitGroups. time.Sleep() pauses the main thread from exiting and ending the program before the other goroutine finishes execution.

By default, channels are unbuffered, meaning the sender and the receiver must be ready at the same time in order to transfer data.

What does "being ready at the same time" mean?

Unbuffered channels are blocking, which means they pause execution until the receiver end is ready to receive the data.

What do you think will happen here?

func main() {
    channel := make(chan string)
    channel <- "hello"
    fmt.Println(<-channel)
}

It looks like it will work, but let me break it to you—it didn't. The reason? We are:

Sending data into the channel in the main thread
The channel is blocked until the receiver end is ready
The receiver end is also in the main thread
Deadlock!

Let's move on to our next topic: buffered channels. These types of channels have some buffer area. They have a certain amount of storage they can fill before blocking.

Declaring a buffered channel is quite similar to an unbuffered channel but with a capacity:

channel := make(chan string, 3)

Here we have a channel of type string with a capacity of 3.

That means we can send up to 3 complete strings before it blocks the execution.

channel <- "Hello"
channel <- "Hi"
channel <- "Namaste"
channel <- "Salut" // this will not work until and unless the
                   // receiver receives previous values and frees the channel

Now let us fix our earlier deadlock using a buffered channel:

func main() {
    channel := make(chan string, 1)
    channel <- "hello"
    fmt.Println(<-channel)
}

Now this will work! The channel has a capacity of 1, which means it can store one string before blocking the execution. But does this also mean the following will work?

func main() {
    channel := make(chan string, 1)
    fmt.Println(<-channel)
    channel <- "hello"
}

No matter how much capacity you increase, there will always be a deadlock.

The reason is simple:the receiver end is always blocking. If some part of the program is trying to receive from a channel, it will block execution. Hence, deadlock.

Moving on, now that we have a rudimentary understanding of the types of channels, we can start exploring certain use cases without introducing much complexity.

Sending data from main thread to worker thread

Here we create 10 worker threads using a for-loop and send some integer data to them using an unbuffered channel.

package main

import (
    "fmt"
    "time"
)

func worker(channel chan int) {
    time.Sleep(time.Second / 2)
    fmt.Println("Completed Task:", <-channel)
}

func main() {
    channel := make(chan int)
    for i := 0; i < 10; i++ {
        go worker(channel)
        channel <- i + 1
    }

    time.Sleep(time.Second * 6)
}

Here is how the execution happens:

First, the main thread creates a worker thread and passes the channel to it.
After creation, it sends data to the channel and waits for the other end to receive while pausing further execution.
The worker thread does some work (simulated by 0.5 seconds of delay) and receives the data.
The main thread continues execution.

Note: This gives us one advantage. All goroutines are supposed to run simultaneously, but here they are pausing.

Fix using buffered channel

package main

import (
    "fmt"
    "time"
)

func worker(channel chan int) {
    time.Sleep(time.Second / 2)
    fmt.Println("Completed Task:", <-channel)
}

func main() {
    channel := make(chan int, 10)
    for i := 0; i < 10; i++ {
        go worker(channel)
        channel <- i + 1
    }

    time.Sleep(time.Second * 2)
}

Here is how the execution happens:

First, the main thread creates worker threads and passes the channel to them.
After creation, it sends data to the channel and continues execution without pausing because the channel has capacity for more data.
The worker thread does some work (simulated by 0.5 seconds of delay) and receives the data.

Just by adding storage to our channel, we make our program 10x faster!

Minimum time (just considering sleep time) before buffered channel = 0.5 * 10 = 5 seconds

Minimum time after buffered channel = 0.5 seconds (every thread running simultaneously)

Note: It is not guaranteed how the threads will be processed. You might see output that is not always ordered the way you expect (1 to 10).

Directional Channels

Let us talk about our final topic for this blog, and that is Directional Channels.

Directional channels let you specify what end of the channel the function will be using. They are restricted to only sending or only receiving data. This prevents a function from accidentally performing the wrong operation on a channel.

Send-only channel: This informs the function that the only thing it is allowed to do with the channel is send data.

func sendData(ch chan<- int) {
    ch <- 10
}

Receive-only channel: This informs the function that it will just be receiving on this channel and nothing more.

func receiveData(ch <-chan int) {
    fmt.Println(<-ch)
}

Here is a very simple example to illustrate directions:

package main

import "fmt"

func sendData(ch chan<- string) {
    ch <- "Hello from sender!"
}

func receiveData(ch <-chan string) {
    fmt.Println(<-ch)
}

func main() {
    ch := make(chan string)
    go sendData(ch)
    receiveData(ch)
}

In this example, sendData can only send values into the channel, and receiveData can only read from it. This restriction enforces clear communication direction—one function writes, the other reads—preventing accidental misuse of the channel (like trying to read in a sender function or vice versa). It's a clean, safe way to structure concurrent communication in Go.

There's a lot to cover, but I think this article explained the core problems that someone might deal with when picking up channels. Strong foundation.

There are more things that I want to cover, but I will give you some time to digest:

ranging over channels
WaitGroups
select statement
and many more...

That's it for channels Part 1! Practice these examples, and you'll never fear the pipe-looking snitch again. Next time: range, select, and real-world patterns.

Have a nice day!😊