DEV Community: Farhad Rahimi Klie

Critical Thinking in Programming: The Skill AI Can't Replace

Farhad Rahimi Klie — Fri, 02 Oct 2026 03:59:39 +0000

AI can write code.

AI can explain code.

AI can find bugs.

AI can even build entire applications from a simple description.

So a natural question for programmers is:

If AI can do so much of the coding, what skill should a programmer develop that AI cannot simply replace?

One of the most important answers is critical thinking.

Programming has never been only about typing code. The difficult part is usually deciding what should be built, why it should be built, what assumptions are being made, and whether the result is actually correct.

AI can generate an implementation.

You still need to decide whether that implementation makes sense.

What Is Critical Thinking?

Critical thinking is the ability to examine information carefully, question assumptions, evaluate evidence, identify problems, and reach a reasoned conclusion.

In programming, this means asking questions such as:

What exactly is the problem?
What are the requirements?
Are the requirements complete?
What assumptions am I making?
Is this solution actually correct?
What happens in unusual cases?
What could fail?
Is there a simpler solution?
What are the security implications?
What are the performance implications?
How do I know this code works?

A programmer who can write 10,000 lines of code but cannot answer these questions can still build the wrong software.

Programming Is Not Just Writing Code

Consider a simple request:

"Create a function that deletes a user."

An AI can quickly generate something like:

void delete_user(int user_id) {
    database_delete_user(user_id);
}

The code may compile.

But critical thinking begins before writing the function.

You should ask:

Should the user really be deleted?
What if the user doesn't exist?
What happens to their files?
What happens to their posts?
What happens to their payments?
Should deletion be permanent?
Should administrators be allowed to delete users?
Should the operation require confirmation?
What happens if the database operation fails halfway through?
Should the action be logged?
Can another user trigger this operation?

The difficult problem wasn't writing:

database_delete_user(user_id);

The difficult problem was understanding what "delete a user" actually means.

That's critical thinking.

AI Is Extremely Good at Generating Solutions

Modern AI systems are remarkably useful for programming.

You can ask AI to:

generate functions
explain APIs
convert code between languages
write tests
find potential bugs
refactor code
generate documentation
explain compiler errors
create project structures
suggest algorithms

This makes AI an extremely powerful programming assistant.

But there is an important distinction:

Generating a solution is different from determining whether the solution is the right one.

For example, imagine asking AI:

Create a filesystem that stores files in a disk image.

AI can generate structures like:

struct FileEntry {
    char name[32];
    int size;
    int start_block;
};

It can generate allocation functions.

It can generate bitmap code.

It can generate file-reading and file-writing functions.

But you still have to decide:

How is free space represented?
Can files grow?
What happens when a file needs another block?
How are directories represented?
What happens when the disk becomes full?
How is corruption detected?
What happens if the program crashes during a write?
How are blocks recovered?
Can two files accidentally reference the same block?

The code is only part of the filesystem.

The architecture and reasoning are much more important.

The Most Important Question: "Why?"

A beginner often asks:

"How do I implement this?"

An experienced programmer often asks:

"Why should I implement it this way?"

That difference is enormous.

Suppose you need to store 1 million records.

Someone suggests:

Use an array.

You might immediately implement it.

But critical thinking asks:

Why an array?

Then:

How often will we search?
How often will we insert?
How often will we delete?
Do we need ordering?
How much memory do we have?
What is the expected dataset size?
What is the access pattern?

Maybe an array is correct.

Maybe a hash table is better.

Maybe a tree is better.

Maybe a database is appropriate.

The programming language doesn't answer these questions.

The algorithm doesn't answer them automatically.

You have to reason about the problem.

Don't Trust Code Just Because It Compiles

One of the most dangerous mistakes in programming is assuming:

It compiles → It works.

That's false.

Consider:

int divide(int a, int b)
{
    return a / b;
}

It compiles.

But what happens when:

divide(10, 0);

Critical thinking means looking beyond the happy path.

You should automatically start thinking about:

Normal input
Empty input
Zero
Negative values
Very large values
Very small values
Invalid input
Unexpected input
Memory limitations
Concurrency
Failure conditions

This habit becomes extremely valuable when working with AI-generated code.

AI Can Be Confidently Wrong

AI-generated code can look professional.

It can have:

beautiful formatting
meaningful variable names
comments
error handling
impressive architecture

And still be wrong.

This is why one of the most valuable programming skills in the AI era is:

The ability to independently verify the output.

If AI gives you 200 lines of code, don't think:

"The AI wrote it, so it must be correct."

Think:

"What assumptions does this code make?"

Then test those assumptions.

Learn to Question Assumptions

Assumptions are everywhere in software.

For example:

char *name = malloc(100);
strcpy(name, input);

Someone might say:

"It allocates 100 bytes, so we're safe."

But critical thinking asks:

How long is input?
Can input contain more than 99 characters?
Is it null terminated?
What happens if allocation fails?
Who frees the memory?

The code itself doesn't tell you all of these answers.

You have to reason about the surrounding system.

Debugging Is Critical Thinking

Many people think debugging means:

Find the line that is broken.

That's only part of debugging.

Real debugging is closer to scientific investigation.

You have:

Observation
    ↓
Hypothesis
    ↓
Experiment
    ↓
Result
    ↓
New hypothesis

Suppose your program crashes.

Don't randomly change code.

Instead ask:

What exactly happened?
Where did it happen?
Can I reproduce it?
What changed?
What does the debugger show?
What assumptions were violated?

For example:

Program crashes
      ↓
Is it always reproducible?
      ↓
Yes
      ↓
Which operation occurs immediately before the crash?
      ↓
Memory access
      ↓
Is the pointer valid?
      ↓
Check pointer
      ↓
Pointer is NULL
      ↓
Where did NULL come from?

That's critical thinking.

Learn to Think in Invariants

One of the strongest techniques in programming is reasoning with invariants.

An invariant is something that should remain true throughout a system.

For example, imagine a filesystem.

You might define:

Every allocated block belongs to exactly one file.

Now consider this:

File A → Block 10
File B → Block 10

Your invariant has been violated.

That immediately tells you something is wrong.

Another filesystem invariant could be:

If a file says it owns N blocks,
then exactly N valid block references must exist.

Thinking in invariants helps you reason about complex systems instead of merely reading individual lines of code.

Critical Thinking Helps You Design Better Systems

Imagine you're building a small operating-system-like project.

You need memory allocation.

You could ask AI:

"Write malloc."

It may produce an implementation.

But before implementation, you need to understand:

What is a block?
How is free memory represented?
How are allocations tracked?
What happens when memory is fragmented?
How is memory returned?
What alignment is required?
What happens when allocation fails?

The implementation comes after the model.

A programmer who understands the model can evaluate AI-generated implementations.

A programmer who doesn't understand the model may simply copy them.

The Difference Between a Coder and an Engineer

This doesn't mean writing code is unimportant.

It means programming has multiple levels.

Level 1 — Syntax

for (...)
{
    ...
}

You know how to write valid code.

Level 2 — Implementation

You can build functions and programs.

Level 3 — Algorithms

You understand:

arrays
linked lists
hash tables
trees
graphs
sorting
searching
memory allocation

Level 4 — Design

You can decide how components should interact.

Level 5 — Reasoning

You can determine:

What problem are we actually solving?
What constraints matter?
What assumptions are dangerous?
What could go wrong?
How can we prove or test correctness?

AI can help with all five levels.

But the higher levels require increasingly strong judgment from the programmer.

Don't Become a "Prompt Programmer"

A new type of programming workflow is emerging:

Human:
"Build this."

AI:
"Here is the code."

Human:
"Fix this."

AI:
"Here is the fix."

Human:
"Add authentication."

AI:
"Done."

Human:
"Deploy it."

AI:
"Done."

This can be productive.

But there is a danger.

You can become dependent on generated code without understanding the system you're building.

Then when something unexpected happens, you don't know how to reason about it.

A better workflow is:

Understand
    ↓
Design
    ↓
Ask AI for assistance
    ↓
Inspect
    ↓
Test
    ↓
Challenge assumptions
    ↓
Modify
    ↓
Verify

AI becomes your tool.

You remain the engineer.

Ask AI Better Questions

Instead of only asking:

"Write this function."

Try asking:

"What are the possible failure cases?"

Or:

"What assumptions does this implementation make?"

Or:

"Give me three possible architectures and explain the trade-offs."

Or:

"What security problems could exist here?"

Or:

"What edge cases should I test?"

Or:

"Find situations where this algorithm produces incorrect results."

These questions force you to think about the problem rather than simply accepting generated code.

Build Things Without AI Sometimes

If you want strong programming fundamentals, occasionally build something yourself.

For example:

Text editor
Calculator
Shell
Memory allocator
HTTP server
Database
Filesystem
Compiler
Interpreter
Version-control system

Start small.

The goal isn't to compete with commercial software.

The goal is to experience the underlying problems.

For example, building a tiny filesystem teaches you about:

Blocks
Metadata
Directories
Allocation
Bitmaps
File offsets
Persistence
Corruption
Data structures

Those experiences create mental models that are difficult to obtain by simply asking an AI to generate the project.

Read Code You Didn't Write

Another powerful exercise is reading unfamiliar code.

Pick a project and ask:

What does this function do?

What assumptions does it make?

What data structure is being used?

Why was this algorithm chosen?

What happens if this input is invalid?

What happens if memory allocation fails?

What happens if the disk is full?

Before running the program, try to predict its behavior.

Then run it.

Compare your prediction with reality.

This trains your reasoning ability.

Learn the Fundamentals

Critical thinking becomes much stronger when you understand the foundations.

For a programmer, that includes topics such as:

Computer architecture

CPU
Registers
Memory
Cache
Instructions
Stack
Heap

Operating systems

Processes
Threads
Virtual memory
Filesystems
System calls
Scheduling

Data structures

Arrays
Linked lists
Trees
Hash tables
Graphs
Heaps

Algorithms

Searching
Sorting
Traversal
Recursion
Dynamic programming
Graph algorithms

Programming languages

Parsing
Compilation
Runtime
Memory management
Type systems

The more you understand these foundations, the easier it becomes to recognize when generated code doesn't make sense.

AI Changes the Value of Programming Skills

AI may reduce the amount of time programmers spend typing repetitive code.

That doesn't necessarily make programming less important.

It can make reasoning more important.

Imagine two programmers.

Programmer A can write code extremely quickly but accepts generated code without questioning it.

Programmer B writes code more deliberately but understands:

requirements
architecture
algorithms
constraints
security
performance
failure modes
testing

As code generation becomes easier, the ability to determine what code should exist in the first place becomes increasingly valuable.

The Programmer's New Superpower

The future programmer doesn't necessarily need to type every line manually.

Instead, they need to be able to:

Understand the problem
        ↓
Break it into smaller problems
        ↓
Design a solution
        ↓
Use AI to accelerate implementation
        ↓
Review the generated code
        ↓
Test it
        ↓
Find hidden assumptions
        ↓
Improve the design
        ↓
Verify the final system

AI can dramatically accelerate the implementation stage.

But the programmer still needs to control the reasoning process.

The Question Isn't "Can AI Write Code?"

That question is becoming less interesting.

A better question is:

Can you understand the code well enough to know when it is wrong?

Because software isn't valuable simply because it exists.

It has to satisfy requirements.

It has to behave correctly.

It has to handle failures.

It has to respect constraints.

It has to be maintainable.

And in many systems, it has to be secure.

Those requirements create problems that cannot be solved merely by generating more code.

Final Thoughts

AI is changing programming.

There is no reason to ignore that.

Use it.

Ask it questions.

Let it explain unfamiliar APIs.

Let it generate boilerplate.

Let it help you debug.

Let it suggest alternatives.

But don't outsource your understanding.

When AI gives you code, ask:

Why does this work?

What assumptions does it make?

When does it fail?

What happens at the boundaries?

Can I test it?

Can I explain it?

Would I design it this way myself?

The strongest programmer in the AI era may not be the person who can type the fastest.

It may be the person who can think most clearly about the problem.

AI can generate code.
Critical thinking determines whether that code deserves to exist.

Flat Assembler (FASM): A Practical Introduction to Low-Level Programming

Farhad Rahimi Klie — Fri, 11 Sep 2026 10:25:35 +0000

If you are interested in operating systems, compilers, reverse engineering, embedded systems, executable formats, or simply understanding how computers work at a low level, learning assembly language can be extremely valuable.

There are many assemblers available today, but one that deserves special attention is Flat Assembler, commonly called FASM.

FASM is a fast, powerful, and flexible assembler that gives you a very direct relationship with the machine code generated by your program.

In this article, we'll look at what FASM is, how it works, why it is interesting, and what you can build with it.

What Is Flat Assembler?

Flat Assembler (FASM) is an assembler for the x86 and x86-64 architectures.

An assembler converts assembly language instructions into machine code that the CPU can execute.

For example:

mov rax, 60

The CPU does not actually understand the text:

mov rax, 60

Instead, FASM translates the instruction into machine-code bytes.

Conceptually:

Assembly source
      |
      v
     FASM
      |
      v
 Machine code
      |
      v
 Executable
      |
      v
     CPU

This is the fundamental job of an assembler.

Why Is FASM Interesting?

FASM has several characteristics that make it different from many other assemblers.

1. It is self-hosting

FASM is written in assembly language.

That alone makes it an interesting project for people who want to study low-level programming.

2. It has a powerful macro system

FASM's macro system allows you to build your own higher-level abstractions while still working with assembly.

For example:

macro exit {
    mov rax, 60
    xor rdi, rdi
    syscall
}

Then:

exit

FASM expands the macro during assembly.

3. It can generate different executable formats

FASM supports multiple output formats.

For example, you can create:

format ELF64 executable

for a Linux x86-64 executable.

You can also work with Windows PE formats and other output types.

4. It gives you direct control

FASM does not try to hide the machine.

You can explicitly work with:

registers
memory
instructions
sections
symbols
addresses
stack frames
calling conventions
system calls
executable formats

This makes it excellent for learning how software actually works.

FASM vs NASM

If you have already learned or seen NASM, you may wonder:

Why learn FASM instead?

Both are excellent assemblers, but their philosophies differ.

A simplified comparison:

Feature	FASM	NASM
x86/x86-64	Yes	Yes
Linux	Yes	Yes
Windows	Yes	Yes
Powerful macros	Yes	Yes
Multiple output formats	Yes	Yes
Direct machine-level control	Yes	Yes
Self-hosting implementation	Yes	No
Minimal syntax	Yes	Yes

The biggest reason to explore FASM is its macro system and overall design philosophy.

FASM tries to provide powerful facilities while keeping the assembler itself relatively small and flexible.

Your First FASM Program

Let's start with a simple Linux x86-64 program.

format ELF64 executable

segment readable executable

entry main

main:
    mov rax, 60
    xor rdi, rdi
    syscall

This program simply exits.

Let's understand it.

`format`

format ELF64 executable

This tells FASM what kind of output we want.

Here:

ELF64

means a 64-bit Linux ELF executable.

And:

executable

means we want an executable file.

So FASM knows how to construct the final executable.

`segment`

segment readable executable

This creates a segment containing executable code.

The permissions indicate that the segment can be:

readable
executable

The CPU will execute instructions from this region.

`entry`

entry main

This tells FASM that main is the entry point of the executable.

In other words, when the operating system starts the program, execution begins at:

main:

Labels

This:

main:

is a label.

A label gives a name to a location in the program.

For example:

main:
    mov rax, 60

The label main represents the address of that instruction.

You can create other labels:

loop_start:
    ...

or:

my_function:
    ...

Labels are extremely important in assembly programming.

Registers

When programming x86-64 assembly, you will work heavily with registers.

Some important registers include:

RAX
RBX
RCX
RDX

RSI
RDI
RBP
RSP

R8
R9
R10
R11
R12
R13
R14
R15

Each register is a small, extremely fast storage location inside the CPU.

For example:

mov rax, 123

means:

RAX = 123

You can then use the value:

add rax, 10

Now:

RAX = 133

The `mov` Instruction

One of the most important instructions is:

mov

It copies data.

For example:

mov rax, 10

means:

RAX <- 10

Another example:

mov rbx, rax

means:

RBX <- RAX

It is important to understand that mov is fundamentally a copy operation.

Memory

Registers are very small.

When you need larger amounts of data, you work with memory.

FASM allows memory operands using brackets:

mov rax, [address]

The brackets mean:

Access the memory located at this address.

For example:

mov rax, [rbx]

means:

Use the value in RBX as an address
        |
        v
Memory[RBX]
        |
        v
       RAX

Compare:

mov rax, rbx

with:

mov rax, [rbx]

The first copies the address/value stored in RBX.

The second reads the memory at the address stored in RBX.

This distinction is fundamental in assembly.

Data Definitions

FASM provides directives for creating data.

Some important ones are:

db
dw
dd
dq

They represent different data sizes.

`db`

Define byte:

db 10

`dw`

Define word:

dw 10

`dd`

Define double word:

dd 10

`dq`

Define quad word:

dq 10

You will use these constantly when creating data structures, buffers, strings, tables, and other binary data.

Strings

A string can be defined using:

message db 'Hello, world!', 0

The 0 is important when you want the string to be compatible with C-style null-terminated strings.

Memory might look like:

H e l l o ,   w o r l d !
48 65 6C 6C 6F ...
                     |
                     v
                     00

The zero byte marks the end of the string.

Reserving Memory

FASM also provides declarations for reserving space.

For example:

buffer rb 100

means:

Reserve 100 bytes.

Other declarations include:

rw
rd
rq

These are useful when creating buffers and data structures.

For example:

buffer rb 4096

creates a 4096-byte buffer.

Arithmetic

FASM supports the normal x86 arithmetic instructions.

For example:

mov rax, 20
add rax, 5

Result:

RAX = 25

Subtraction:

sub rax, 10

Increment:

inc rax

Decrement:

dec rax

Negation:

neg rax

You can also perform multiplication and division with:

mul
imul
div
idiv

These instructions require more attention because some of them use implicit registers.

Bitwise Operations

Assembly programming also involves manipulating individual bits.

Important instructions include:

and
or
xor
not
shl
shr

For example:

xor rax, rax

is a very common instruction.

It sets:

RAX = 0

because:

x XOR x = 0

Comparing Values

The cmp instruction is extremely important.

For example:

cmp rax, rbx

Conceptually, the CPU calculates:

RAX - RBX

but does not store the result.

Instead, it updates CPU flags.

Those flags can then be used by conditional jumps.

For example:

cmp rax, rbx
je equal

If the values are equal, execution jumps to:

equal:

Control Flow

Assembly programs need branches and loops.

The basic unconditional jump is:

jmp label

For example:

jmp start

start:
    ...

Conditional jumps include:

je
jne
jg
jge
jl
jle
ja
jb

These are based on CPU flags.

You will eventually learn the important difference between:

signed comparisons

and:

unsigned comparisons

because instructions such as jg and ja do not mean the same thing.

The Stack

The stack is one of the most important concepts in assembly.

The stack is an area of memory used for temporary data and function calls.

Two important registers are:

RSP
RBP

RSP is the stack pointer.

RBP is commonly used as a frame pointer.

You can place a value onto the stack:

push rax

and retrieve it:

pop rax

Function calls also use the stack.

For example:

call my_function

The CPU saves a return address and jumps to:

my_function:

Eventually:

ret

returns to the caller.

Understanding call, ret, push, pop, and rsp is essential for writing functions in assembly.

Functions

A function can be created manually:

my_function:
    mov rax, 123
    ret

You can call it:

call my_function

The general flow is:

caller
  |
  | call
  v
my_function
  |
  | ret
  v
caller

At this level, you begin to understand how higher-level languages implement functions underneath.

Linux System Calls

One of the most interesting parts of Linux assembly programming is using system calls directly.

For x86-64 Linux, the syscall instruction enters the kernel.

For example:

mov rax, 60
mov rdi, 0
syscall

This requests the exit system call.

The general idea is:

Your program
     |
     | syscall
     v
Linux kernel
     |
     v
Operating-system service

System calls allow assembly programs to communicate directly with the operating system without necessarily going through the C standard library.

FASM Macros

One of FASM's most powerful features is its macro system.

Consider:

macro exit {
    mov rax, 60
    xor rdi, rdi
    syscall
}

Now you can write:

exit

instead of repeatedly writing:

mov rax, 60
xor rdi, rdi
syscall

This becomes especially useful for larger assembly projects.

FASM provides several powerful macro-related mechanisms, including:

macro
match
rept
repeat
irp
irps

These allow you to build abstractions and even create small domain-specific languages inside assembly.

Why Learn FASM Macros?

At first, assembly can become repetitive.

For example, imagine repeatedly writing system-call setup code.

Macros allow you to create your own abstractions.

You could eventually create something like:

print_string message, message_length

which expands into the appropriate instructions.

The CPU still receives ordinary machine code.

The macro exists only during assembly.

Conceptually:

Your FASM source
       |
       v
     Macros
       |
       v
 Expanded assembly
       |
       v
 Machine code

This is one of the reasons FASM is so interesting.

FASM Structures

FASM also allows you to define structures.

For example:

struc Person {
    .age dd ?
    .id  dd ?
}

You can then use structure layouts to organize memory.

This becomes particularly useful when working with:

operating-system structures
executable formats
network packets
file formats
hardware structures
custom data structures

Instead of thinking only in individual variables, you can start thinking in terms of memory layouts.

Address Expressions

FASM supports powerful address expressions.

For example:

mov rax, [rbx + rcx*8]

This can be understood as:

address = RBX + RCX * 8

Then:

RAX = Memory[address]

This type of addressing is extremely important for arrays.

Suppose each element is 8 bytes:

array[0] -> address + 0
array[1] -> address + 8
array[2] -> address + 16
array[3] -> address + 24

Then:

mov rax, [rbx + rcx*8]

can access an element based on RCX.

FASM and Executable Formats

One of the fascinating things about assembly programming is that you eventually discover that an executable is not simply "machine code."

An executable contains structures describing:

entry points
sections
memory permissions
imported libraries
relocation information
program headers
metadata

For example, Linux commonly uses:

ELF

while Windows commonly uses:

PE

FASM can construct these executable formats.

This makes FASM useful for learning not only assembly instructions, but also how executable files are structured.

What Can You Build With FASM?

FASM is not limited to tiny examples.

You can use it to build serious low-level projects.

For example:

Small programs

CLI tools
calculators
text utilities
file utilities

Systems programming

bootloaders
kernel components
runtime libraries
system utilities

Binary programming

ELF files
PE files
custom binary formats
binary parsers

Educational projects

CPU experiments
memory allocators
custom data structures
assembly implementations of algorithms

Advanced projects

operating-system components
compilers
virtual machines
debuggers
JIT systems

The difficulty varies enormously, but FASM gives you the low-level control required for these types of projects.

A Good Way to Learn FASM

Don't try to memorize hundreds of instructions immediately.

A better approach is to build your understanding in layers.

Layer 1 — CPU Fundamentals

Learn:

Registers
RAX
RBX
RCX
RDX
RSI
RDI
RSP
RBP
R8-R15
RIP
RFLAGS

Understand the difference between:

64-bit
32-bit
16-bit
8-bit

Layer 2 — Basic Instructions

Learn:

mov
add
sub
inc
dec
neg
mul
imul
div
idiv
and
or
xor
not
shl
shr

Layer 3 — Control Flow

Learn:

cmp
test
jmp
je
jne
jg
jge
jl
jle

Then learn loops.

Layer 4 — Memory

Understand:

addresses
pointers
dereferencing
memory operands
arrays
structures
address expressions

For example:

mov rax, [rbx + rcx*8]

should eventually become completely natural to you.

Layer 5 — Stack and Functions

Learn:

push
pop
call
ret
rsp
rbp
stack frames
calling conventions

This is where assembly begins to connect strongly with C.

Layer 6 — Operating System Interface

On Linux, learn:

syscall
system-call numbers
register conventions
file descriptors
read
write
open
close
exit

Then build programs without relying on a C runtime.

Layer 7 — FASM Features

After understanding the CPU itself, learn FASM-specific features:

format
include
sections/segments
constants
data definitions
structures
macros
match
repeat
rept
irp
irps

This is where you start taking advantage of FASM rather than treating it like a generic assembler.

FASM Is More Than "Writing Assembly"

The most important thing to understand is that learning FASM is not just about memorizing instructions.

You are learning several layers simultaneously:

                Your Program
                     |
                     v
              FASM source code
                     |
                     v
              FASM assembler
                     |
                     v
               Machine code
                     |
                     v
                 CPU / OS
                     |
                     v
                  Hardware

As you become more comfortable, you will start seeing how all these layers connect.

A C program such as:

int x = 10;
x++;

eventually becomes machine instructions.

An operating system eventually interacts with hardware through machine-level mechanisms.

An executable eventually becomes bytes arranged according to a binary format.

Assembly sits very close to that boundary.

Final Thoughts

Flat Assembler is an excellent choice if your goal is to understand computers at a low level.

It teaches you to think about:

registers
memory
addresses
instructions
CPU flags
stacks
functions
calling conventions
system calls
executable formats
machine code

And FASM's macro system gives you something especially interesting: the ability to build powerful abstractions while remaining very close to the machine.

If you are coming from C, FASM can also change the way you understand C itself.

Instead of seeing:

function();

you begin asking:

How is the function called?
Where are the arguments?
Which registers contain them?
What happens to the stack?
Where does the return address go?
How is the return value produced?

That is where assembly becomes truly valuable.

Don't learn assembly just to write assembly. Learn it to understand what your computer is actually doing.

And if you choose FASM, you get a particularly interesting tool for exploring that world.

How to Install a Linux Distro Using WSL on Windows

Farhad Rahimi Klie — Fri, 04 Sep 2026 06:39:00 +0000

If you use Windows but want a Linux development environment, you don't necessarily need dual boot, a virtual machine, or a second computer.

Windows Subsystem for Linux (WSL) lets you run a Linux distribution directly inside Windows.

In this guide, we'll install WSL, choose a Linux distribution, create a Linux user, and verify that everything is working.

What Is WSL?

WSL (Windows Subsystem for Linux) is a Windows feature that allows you to run Linux distributions alongside Windows.

You can use a Linux terminal and tools such as:

Bash
Git
GCC
Python
Rust
Node.js
Vim
SSH
Linux package managers

without installing Linux as a separate operating system.

For developers, WSL is especially useful because you can keep Windows for your normal desktop applications while using Linux tools for development.

Requirements

Before starting, make sure you're running a supported version of Windows.

Open PowerShell and run:

winver

You can also check your Windows version with:

systeminfo

For the easiest installation method, use a modern Windows 10 or Windows 11 system with WSL support.

1. Open PowerShell as Administrator

Press:

Windows + X

Then select:

Windows PowerShell (Admin)

or:

Terminal (Admin)

You should see a terminal window with administrator privileges.

2. Install WSL

The easiest method is:

wsl --install

This command enables the required Windows components, installs the WSL components, and normally installs Ubuntu as the default Linux distribution.

After installation, Windows may ask you to restart your computer.

Restart:

shutdown /r /t 0

After Windows starts again, the Linux distribution setup should continue.

3. Check Available Linux Distributions

You don't have to use Ubuntu.

To see the distributions available through WSL, run:

wsl --list --online

You may see distributions such as:

NAME
Ubuntu
Debian
kali-linux
openSUSE-Tumbleweed
Ubuntu-24.04

The exact list can change over time.

4. Install a Specific Linux Distribution

For example, to install Ubuntu:

wsl --install -d Ubuntu

Or, if you want Debian:

wsl --install -d Debian

You can replace the distribution name with one from:

wsl --list --online

For example:

wsl --install -d Ubuntu-24.04

5. Create Your Linux User

After the distribution starts for the first time, Linux will ask you to create a username.

For example:

Enter new UNIX username:

You might enter:

farhad

Then create a password.

When typing the password, nothing will appear on the screen.

That's normal behavior in Linux terminals.

Type the password and press Enter.

6. Verify the Installation

Inside your Linux terminal, run:

uname -a

Then:

cat /etc/os-release

You should see information about your Linux distribution.

You can also check the current user:

whoami

And check your home directory:

pwd

You should get something similar to:

/home/farhad

Your Linux environment is now running.

7. Check WSL From Windows

Close the Linux terminal and open PowerShell.

Run:

wsl --list --verbose

You should see something similar to:

  NAME      STATE           VERSION
* Ubuntu    Running         2

The important part is:

VERSION
2

That means you're using WSL 2.

WSL 2 uses a lightweight virtualized Linux environment and provides much better Linux compatibility than the original WSL 1 architecture.

8. Start Your Linux Distribution

You can start your default distribution by simply running:

wsl

Or you can specify a distribution:

wsl -d Ubuntu

For Debian:

wsl -d Debian

You can also see installed distributions with:

wsl -l

9. Update Linux

After installing Linux, update its package information.

For Ubuntu or Debian:

sudo apt update

Then upgrade installed packages:

sudo apt upgrade

You can combine them:

sudo apt update && sudo apt upgrade

It's a good idea to do this before installing development tools.

10. Access Windows Files From Linux

One of the useful features of WSL is that you can access your Windows drives.

Your Windows C: drive is normally available at:

/mnt/c

For example:

cd /mnt/c

You can see your Windows files:

ls

Your Windows user directory might be accessible through:

cd /mnt/c/Users

This makes it possible to work between Windows and Linux.

11. Access Linux Files From Windows

WSL also provides a way to access your Linux filesystem from Windows.

From Windows File Explorer, you can enter:

\\wsl$

in the address bar.

You should see your installed WSL distributions.

For example:

\\wsl$\Ubuntu

This allows Windows applications to interact with files inside your Linux environment.

For development projects, however, it's generally best to keep Linux-oriented projects inside the Linux filesystem rather than constantly working across /mnt/c.

12. Install Development Tools

Now you can use Linux normally.

For example, install Git:

sudo apt install git

Install GCC:

sudo apt install build-essential

Check GCC:

gcc --version

Install Vim:

sudo apt install vim

Now you have a basic Linux development environment running inside Windows.

Installing Another Distribution Later

You can install multiple Linux distributions on the same Windows installation.

For example:

wsl --install -d Debian

Then check them:

wsl --list --verbose

You might have:

  NAME      STATE           VERSION
* Ubuntu    Stopped         2
  Debian    Stopped         2

You can start Debian with:

wsl -d Debian

Making a Distribution Your Default

If you have multiple distributions installed, you can choose which one starts when you run:

wsl

For example:

wsl --set-default Debian

Now:

wsl

will start Debian by default.

Useful WSL Commands

Here are some commands you'll use frequently.

List installed distributions

wsl --list --verbose

List available distributions

wsl --list --online

Start WSL

wsl

Start a specific distribution

wsl -d Ubuntu

Shut down WSL

wsl --shutdown

Stop a specific distribution

wsl --terminate Ubuntu

Check WSL version

wsl --version

Update WSL

wsl --update

Set the default distribution

wsl --set-default Ubuntu

Common Problems

`wsl --install` Doesn't Work

First check whether WSL is available:

wsl --status

Then try:

wsl --update

You may also need to enable Windows virtualization features or restart Windows after enabling WSL.

The Distribution Download Fails

If you receive a network-related error while installing a distribution, check your internet connection first.

You can also check the available distributions:

wsl --list --online

Then retry the installation:

wsl --install -d Debian

Check Whether Virtualization Is Enabled

Open Task Manager:

Ctrl + Shift + Esc

Go to:

Performance → CPU

Look for:

Virtualization: Enabled

If virtualization is disabled, you may need to enable the appropriate virtualization setting in your computer's UEFI/BIOS.

WSL vs Dual Boot

WSL and dual boot solve different problems.

With dual boot, you install Windows and Linux as separate operating systems and choose one when the computer starts.

With WSL, Linux runs alongside Windows.

For development, WSL can be much more convenient because you don't need to reboot your computer every time you want to use Linux.

A simple setup might look like:

Windows
   │
   └── WSL 2
        │
        ├── Ubuntu
        ├── Debian
        └── Other Linux distributions

Conclusion

Installing Linux with WSL is one of the easiest ways to get a Linux development environment on Windows.

The basic workflow is:

wsl --install

Then:

wsl --list --online

Choose a distribution:

wsl --install -d Ubuntu

Start it:

wsl

And verify it:

uname -a

Once it's installed, you can use Linux tools, package managers, compilers, Git, editors, programming languages, and other development tools directly from Windows.

Windows doesn't have to mean giving up the Linux development environment. With WSL, you can have both.

The Philosophy of Rust Programming Language

Farhad Rahimi Klie — Wed, 26 Aug 2026 10:57:52 +0000

Rust is often introduced as a fast, memory-safe systems programming language. That description is correct, but it does not explain what makes Rust fundamentally different.

Rust is built around a powerful idea:

What if we could write low-level, high-performance software while preventing many of the most dangerous programming mistakes before the program even runs?

That question defines much of Rust's philosophy.

Rust is not simply “C with modern syntax,” and it is not trying to replace every programming language. It takes a different approach to systems programming: use the compiler and type system to enforce important correctness guarantees while still giving programmers control over memory, performance, and the machine.

Let's explore the philosophy behind Rust.

1. Memory Safety Without a Garbage Collector

Traditional systems programming languages such as C give programmers direct control over memory.

For example:

int *ptr = malloc(sizeof(int));

*ptr = 42;

free(ptr);

This level of control is powerful, but it also creates responsibility. A programmer can accidentally:

Access memory after it has been freed
Free the same memory twice
Use an invalid pointer
Forget to free allocated memory
Create memory corruption

For example:

int *ptr = malloc(sizeof(int));

free(ptr);

printf("%d\n", *ptr);

A C compiler may allow this code to compile even though using ptr after free() is invalid.

Rust takes a different approach.

Rust wants to prevent many of these problems before the program runs, without requiring a garbage collector.

The core mechanism behind this is Rust's ownership system.

let value = Box::new(42);

When value goes out of scope, Rust automatically cleans up the memory.

The important part is that this cleanup is determined through Rust's ownership rules rather than a background garbage collector.

Rust's philosophy is:

Memory safety should not require sacrificing systems-level performance.

2. Ownership: Every Resource Should Have Clear Responsibility

One of Rust's most important ideas is ownership.

In languages like C, ownership is often a convention.

Consider a function:

char *create_name(void);

Who is responsible for freeing the returned memory?

The caller?

The function?

Another part of the program?

Usually, the answer must be documented and remembered by the programmer.

Rust makes ownership part of the language.

let name = String::from("Rust");

The variable name owns the String.

Ownership can also move:

let name1 = String::from("Rust");

let name2 = name1;

After this move, name1 can no longer be used.

This may initially feel restrictive to programmers coming from C or C++, but there is a reason.

Rust prevents multiple parts of a program from incorrectly believing that they own the same resource.

The philosophy is simple:

If a resource has a clear owner, its lifetime becomes easier to reason about.

Ownership allows Rust to automatically manage resources while preventing many categories of memory errors.

3. Borrowing: Access Without Ownership

Not every function needs to take ownership of data.

Sometimes a function only needs temporary access.

Rust solves this with borrowing.

fn print_name(name: &String) {
    println!("{name}");
}

The function borrows the String.

It can access the data without becoming its owner.

Rust distinguishes between immutable and mutable borrowing.

For example:

let name = String::from("Rust");

let reference = &name;

This creates an immutable reference.

For mutable access:

let mut name = String::from("Rust");

let reference = &mut name;

Rust carefully controls how references can coexist.

These rules may seem strict at first, but they exist to prevent problems such as invalid references and conflicting memory access.

The deeper philosophy is:

Access to data should be explicit and constrained by rules that the compiler can verify.

4. Make Invalid States Difficult to Represent

Rust encourages programmers to model their programs using types.

Suppose you are building a filesystem.

In C, you might create something like this:

struct Node {
    int type;
    char *name;
    void *data;
};

Perhaps:

0 = File
1 = Directory

But technically, the value could also be:

That represents an invalid state.

Rust encourages you to model the possible states directly:

enum Node {
    File {
        name: String,
        size: u64,
    },

    Directory {
        name: String,
    },
}

Now a Node can only be one of the states defined by the enum.

This is an important Rust design philosophy:

Represent the rules of your program in the type system.

Instead of checking for invalid states everywhere at runtime, Rust encourages you to design your data structures so that invalid states are difficult—or sometimes impossible—to construct.

This becomes extremely valuable in large systems.

5. Absence Should Be Explicit

Many programming languages use null to represent the absence of a value.

For example:

int *ptr = NULL;

The danger is that the programmer may later forget to check whether the pointer is valid.

Rust approaches this differently with Option<T>.

let value: Option<i32> = Some(42);

Or:

let value: Option<i32> = None;

Conceptually:

enum Option<T> {
    Some(T),
    None,
}

The possibility that a value does not exist becomes part of its type.

The programmer must handle that possibility.

match value {
    Some(number) => println!("{number}"),
    None => println!("No value"),
}

Rust's philosophy is:

If something might not exist, represent that possibility explicitly.

6. Errors Are Part of Normal Program Flow

Rust treats recoverable errors as values.

A function that might fail can return:

Result<T, E>

Conceptually:

enum Result<T, E> {
    Ok(T),
    Err(E),
}

For example:

fn open_file() -> Result<File, Error> {
    // ...
}

The function signature itself communicates something important:

This operation may succeed or fail.

The caller must then decide how to handle both outcomes.

match open_file() {
    Ok(file) => {
        println!("File opened");
    }

    Err(error) => {
        println!("Error: {error}");
    }
}

Rust encourages programmers to think about failure during API design rather than treating errors as an afterthought.

The philosophy is:

Failure is part of the program's model, so make it visible in the types.

7. Zero-Cost Abstractions

Rust is a systems programming language, so performance matters.

At the same time, Rust provides modern abstractions:

Iterators
Generics
Traits
Closures
Pattern matching
Enums

Rust's goal is to allow expressive code without automatically adding unnecessary runtime overhead.

This idea is often called:

Zero-cost abstractions

The basic philosophy is:

High-level abstractions should not necessarily mean low performance.

For example:

for number in numbers.iter() {
    println!("{number}");
}

This is much more expressive than manually managing an index or pointer.

Rust aims to compile abstractions efficiently so that programmers can write clean, expressive code while maintaining systems-level performance.

Of course, "zero-cost" does not mean every abstraction is magically free. It means Rust's abstractions are designed so that their cost should be predictable and should not impose unnecessary overhead when optimized.

8. Safe by Default, Unsafe by Explicit Choice

Rust does not prevent you from performing low-level operations.

In systems programming, sometimes you need:

Raw pointers
Manual memory manipulation
Operating system interfaces
Hardware access
Foreign Function Interfaces
Custom allocators

Rust provides these capabilities through unsafe.

unsafe {
    // Operations requiring additional safety guarantees
}

The existence of unsafe is important.

Rust does not say:

"Low-level programming is forbidden."

Instead, Rust says:

Dangerous operations should be explicit and isolated.

A well-designed Rust program might look conceptually like this:

┌──────────────────────────────┐
│          Safe Rust           │
│                              │
│ Application logic            │
│ Data structures              │
│ Algorithms                   │
│ Business logic               │
│                              │
└───────────────┬──────────────┘
                │
                │ Explicit boundary
                ▼
┌──────────────────────────────┐
│         Unsafe Rust          │
│                              │
│ Raw pointers                 │
│ Memory manipulation          │
│ Hardware access              │
│ OS interfaces                │
│ C interoperability           │
│                              │
└──────────────────────────────┘

The goal is to keep the unsafe boundary small.

If a small, carefully reviewed section of code performs dangerous operations correctly, the rest of the program can benefit from stronger safety guarantees.

9. Fearless Concurrency

Concurrency is one of the hardest parts of systems programming.

When multiple threads access shared memory, programmers must carefully control:

Ownership
Mutability
Synchronization
Lifetime
Shared access

A mistake can result in a data race or unpredictable behavior.

Rust's type system helps enforce important rules about how data can be transferred and shared between threads.

Two important traits are:

Send

and:

Sync

In simplified terms:

Send means a type can safely be transferred between threads.
Sync means a type can safely be shared between threads under Rust's rules.

Rust cannot eliminate every concurrency bug. Deadlocks and incorrect algorithms are still possible.

However, Rust can prevent many unsafe memory access patterns at compile time.

This is why Rust is often associated with the phrase:

Fearless concurrency.

The idea is not that concurrency becomes easy.

The idea is that programmers can build concurrent systems while the compiler checks many important safety constraints.

10. The Compiler Is More Than a Translator

In C, a compiler is often thought of primarily as something that transforms source code into machine code.

Rust's compiler also acts as a correctness tool.

A Rust compiler error might indicate that:

Ownership is unclear
A reference might outlive the data it references
Multiple parts of the program have conflicting access
A value has been moved
A potentially invalid operation exists

At first, this can feel frustrating.

You may write code that makes perfect sense to you and receive several compiler errors.

But over time, the Rust mindset changes.

Instead of thinking:

"The compiler is stopping me from writing my program."

You begin thinking:

"The compiler found a problem in my assumptions about the program."

Rust pushes some debugging work earlier in the development process.

Instead of:

Write code
    ↓
Compile
    ↓
Run
    ↓
Crash
    ↓
Debug

Rust tries to move more problems here:

Design
    ↓
Write code
    ↓
Compiler checks rules and invariants
    ↓
Fix design problems
    ↓
Run

This does not mean Rust programs cannot contain bugs.

They absolutely can.

But Rust attempts to eliminate entire categories of memory-related bugs before the program executes.

11. Performance and Correctness Are Not Opposites

Historically, programmers sometimes had to choose between:

High-level language
        ↓
More convenience
Less control

or:

Low-level language
        ↓
More control
More responsibility

Rust attempts to challenge this tradeoff.

Rust wants:

High Performance
       +
Memory Safety
       +
Modern Abstractions
       +
Low-Level Control

This is the core reason Rust is interesting for systems programming.

You can work with:

Filesystems
Databases
Networking
Embedded systems
Operating systems
Compilers
Game engines
Command-line tools
High-performance servers

while still using a language designed to catch many common mistakes.

Rust vs C: A Philosophical Comparison

Topic	C	Rust
Memory management	Manual	Ownership-based
Memory safety	Programmer responsibility	Compiler-enforced in safe code
Null values	Pointers can be `NULL`	`Option<T>` models absence
Error handling	Error codes and conventions	`Result<T, E>`
Ownership	Documentation and discipline	Language-level rules
Concurrency	Programmer manages safety	Type system checks important constraints
Abstraction	Often manually implemented	Modern zero-cost abstractions
Dangerous operations	Can appear throughout code	Explicit `unsafe` boundaries
Performance	Direct and predictable control	Systems-level performance with abstractions

C gives the programmer enormous freedom.

Rust asks the programmer to follow stricter rules in exchange for stronger guarantees.

The Biggest Mindset Change for C Programmers

If you come from C, your first questions might be:

Where is this allocated?

Who calls malloc?

Who calls free?

What pointer points to this memory?

Can I modify these bytes directly?

In Rust, you often start with different questions:

Who owns this data?

Who needs temporary access?

Can multiple parts modify it?

How long should this reference live?

Should ownership move?

Can this invalid state exist?

This is the fundamental mental shift.

Rust does not remove low-level programming.

You can still work with:

Memory layouts
Raw pointers
System calls
File descriptors
Hardware
Binary data
FFI
Allocators

But Rust asks you to make the safety boundaries explicit.

Conclusion

The philosophy of Rust can be summarized in one sentence:

Use the type system and compiler to enforce as many important correctness guarantees as possible before the program runs.

Rust is built on several major ideas:

Memory safety without garbage collection
Clear ownership of resources
Controlled access through borrowing
Explicit representation of absence and failure
Strong type-driven design
Zero-cost abstractions
Concurrency with stronger safety guarantees
Explicit boundaries around dangerous operations

Rust does not assume that programmers are careless.

Instead, it recognizes that even experienced programmers make mistakes, especially when building large, complex, concurrent systems.

Its answer is not to remove control from the programmer.

Its answer is to combine control with stronger guarantees.

For a systems programmer, Rust can be understood like this:

C:
Maximum freedom
        +
Maximum responsibility
        +
Potential undefined behavior

Rust:

Low-level control
        +
Strong compiler guarantees
        +
Explicit unsafe boundaries

Rust's syntax is not the hardest thing to learn.

The real challenge is learning to think in terms of ownership, borrowing, lifetimes, and types as tools for designing correct systems.

Once that mindset becomes natural, Rust stops feeling like a restrictive language.

It starts feeling like a language that helps you build complex software with a different kind of confidence.

Terminal: The Interface That Makes You Understand Your Computer

Farhad Rahimi Klie — Mon, 24 Aug 2026 03:46:47 +0000

Most developers start their programming journey with a graphical interface: an IDE, buttons, menus, file explorers, and colorful dashboards.

Then, sooner or later, they encounter something that looks much more intimidating:

The Terminal.

For beginners, the terminal can feel old, difficult, and unnecessary. Why type commands when you can click buttons?

But as you become a developer, you begin to realize something important:

The terminal is not an outdated way of using a computer. It is one of the most direct ways to communicate with it.

In this article, we'll explore what the terminal is, why developers use it, how it works, and why learning it can fundamentally change the way you understand software.

What Is a Terminal?

A terminal is a text-based interface that allows you to interact with your operating system by typing commands.

Instead of this:

Open File Explorer
↓
Click a folder
↓
Find a file
↓
Right-click
↓
Choose an action

You can do this:

cd projects

or:

mkdir my_project

or:

rm old_file.txt

The terminal accepts your commands, sends them to the operating system, and displays the result.

A simplified model looks like this:

You
 │
 │ Type command
 ▼
┌─────────────┐
│  Terminal   │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│    Shell    │
└──────┬──────┘
       │
       ▼
┌─────────────┐
│ Operating   │
│   System    │
└─────────────┘

There are actually several different components involved.

Terminal vs Shell vs Command Line

These terms are often used interchangeably, but they are not exactly the same.

Terminal

The terminal is the application or environment where you type commands.

Examples include:

Windows Terminal
GNOME Terminal
iTerm
Alacritty

The terminal provides the interface.

Shell

The shell is the program that reads and interprets your commands.

For example:

ls

The shell reads that command and decides what program or operation should be executed.

Popular shells include:

Bash
Zsh
Fish
PowerShell

The relationship looks like this:

┌──────────────────┐
│     Terminal     │
│                  │
│   You type here  │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│      Shell       │
│                  │
│ Interprets input │
└────────┬─────────┘
         │
         ▼
┌──────────────────┐
│ Operating System │
└──────────────────┘

So technically:

The terminal displays the interface. The shell interprets your commands.

Your First Terminal Commands

Let's imagine you are using Linux or macOS.

When you open a terminal, you might see something like:

farhad@computer:~$

This is called the prompt.

It means:

The shell is ready and waiting for your command.

Let's try a few commands.

Where Am I?

pwd

pwd means:

Print Working Directory

Example output:

/home/farhad

Your working directory is simply the folder you are currently inside.

List Files

ls

Example:

Documents
Downloads
Projects
Pictures

This command asks the operating system:

Show me the files and directories here.

You can also use:

ls -l

Which provides more information:

drwxr-xr-x Projects
-rw-r--r-- notes.txt
-rwxr-xr-x program

Now you are not just seeing file names. You are seeing information about files.

Moving Through the Filesystem

Suppose your computer contains:

home
└── farhad
    ├── Documents
    ├── Downloads
    └── Projects
        └── database

If you are currently here:

/home/farhad

You can enter the Projects directory:

cd Projects

Now:

pwd

might return:

/home/farhad/Projects

Then:

cd database

Now you are here:

/home
└── farhad
    └── Projects
        └── database ← You are here

To go back one directory:

cd ..

The .. means:

Parent directory.

To go directly to your home directory:

cd

These commands may seem simple, but they introduce one of the most important concepts in computing:

Everything has a location.

Creating Files and Directories

Create a directory:

mkdir my_project

Now:

current_directory
└── my_project

Move into it:

cd my_project

Create a file:

touch main.c

Now:

my_project
└── main.c

You just created a project structure without opening a graphical file manager.

For example:

mkdir database
cd database

mkdir src
mkdir include
mkdir tests

touch src/main.c
touch include/database.h

The result:

database
├── src
│   └── main.c
│
├── include
│   └── database.h
│
└── tests

This is one reason developers love the terminal.

You can describe a sequence of actions precisely.

The Terminal Is Built Around Programs

One important thing to understand is this:

ls

is not magic.

Usually, when you type a command, the shell searches for a program with that name and executes it.

For example:

gcc

starts the C compiler.

You might write:

gcc main.c -o app

Conceptually:

You
 │
 │ gcc main.c -o app
 ▼
Shell
 │
 │ Find gcc
 ▼
C Compiler
 │
 │ Compile main.c
 ▼
app

Then you can run your program:

./app

The terminal becomes the place where your entire development workflow happens.

Why Developers Prefer the Terminal

The biggest advantage is not that the terminal looks cool.

The real advantage is control.

With a GUI, you often perform actions manually.

For example:

Click
↓
Click
↓
Select
↓
Right-click
↓
Choose option

With the terminal:

command argument option

A command can be repeated exactly.

For example:

gcc main.c -o program

You can run the same command:

gcc main.c -o program

Again.

And again.

The instructions do not change.

This makes the terminal extremely useful for:

Programming
Building software
Managing files
Running servers
Compiling code
Debugging
Automation
Git
Docker
Databases
System administration

Commands Can Be Combined

This is where the terminal becomes especially powerful.

Suppose you want to see all files ending in .c.

You can use:

ls

But you can also combine commands and filters.

For example:

ls | grep ".c"

The | symbol is called a pipe.

It connects programs together.

Conceptually:

┌──────┐
│  ls  │
└───┬──┘
    │
    │ Output
    ▼
┌────────┐
│  grep  │
└───┬────┘
    │
    ▼
 Result

This is one of the core ideas behind Unix-like systems:

Small programs can be combined to perform larger tasks.

Instead of building one giant program that does everything:

GIANT_PROGRAM

Unix philosophy encourages:

Small Tool
     │
     ▼
Small Tool
     │
     ▼
Small Tool
     │
     ▼
Result

The terminal makes this composition natural.

Input, Output, and Redirection

Programs usually have three important streams:

Standard Input
Standard Output
Standard Error

You can think of them like this:

Keyboard
   │
   ▼
stdin
   │
┌──────────┐
│ Program  │
└────┬─────┘
     │
     ├──── stdout ────► Screen
     │
     └──── stderr ────► Error Message

The terminal allows you to redirect these streams.

For example:

echo "Hello" > output.txt

Normally:

echo "Hello"

prints:

Hello

But this:

echo "Hello" > output.txt

sends the output into a file.

The result:

output.txt

contains:

Hello

You can also append:

echo "Another line" >> output.txt

This simple concept is the foundation of many automation workflows.

The Terminal and Programming

If you are a C programmer, the terminal becomes especially important.

Imagine you have:

project
└── main.c

You compile it:

gcc main.c -o program

Now:

project
├── main.c
└── program

Run it:

./program

If you modify your source code:

main.c

You compile again:

gcc main.c -o program

Then run:

./program

This gives you a direct understanding of the software pipeline:

Source Code
     │
     ▼
┌───────────┐
│ Compiler  │
└─────┬─────┘
      ▼
Machine Code
      │
      ▼
Executable
      │
      ▼
Operating System
      │
      ▼
Running Program

An IDE can hide this process behind a button called:

Run

But the terminal forces you to see what is actually happening.

That is valuable when you want to understand systems programming.

The Terminal Is Excellent for Automation

Imagine you have 1,000 files.

You want to perform the same operation on every file.

Doing this manually would be painful.

But with scripting:

for file in *.txt
do
    echo "$file"
done

You can automate repetitive work.

A simple script might:

Compile your program.
Run tests.
Create a backup.
Generate logs.
Deploy your application.

For example:

#!/bin/bash

gcc main.c -o app

./app

Instead of manually typing multiple commands, you can execute:

./build.sh

This is why terminals are closely connected to:

Automation
+
Programming
+
Reproducibility

The Terminal and Git

Modern software development would be difficult without version control.

A typical Git workflow looks like this:

git status

See what changed.

git add .

Stage changes.

git commit -m "Add database page implementation"

Create a commit.

git push

Send your changes to a remote repository.

Conceptually:

Your Files
    │
    ▼
git add
    │
    ▼
Staging Area
    │
    ▼
git commit
    │
    ▼
Local Repository
    │
    ▼
git push
    │
    ▼
Remote Repository

The terminal gives you direct access to these tools.

The Terminal Is Not Just for Linux

Many people associate terminals with Linux.

But command-line environments exist everywhere.

Linux

Common shell:

Bash

or:

Zsh

macOS

Common shells include:

Zsh

and Bash.

Windows

You can use:

Command Prompt
PowerShell
Windows Terminal
WSL

With WSL, Windows users can run a Linux environment directly alongside Windows.

The important thing is not the specific terminal application.

The important skill is learning how to think in commands.

The Terminal Changes How You Think

This is the part beginners often don't realize.

A graphical interface usually asks:

Where is the button?

The terminal asks:

What operation do I want to perform?

For example, instead of thinking:

Where is the button to create a directory?

You think:

I want to create a directory.

Then:

mkdir project

This is a more direct relationship between your intention and the operation.

The terminal encourages you to think in:

Input
↓
Process
↓
Output

That same model appears everywhere in programming.

A Practical Developer Workflow

Imagine starting a new C project.

You might do:

mkdir my_database

Then:

cd my_database

Create directories:

mkdir src
mkdir include
mkdir build
mkdir tests

Create files:

touch src/main.c
touch include/database.h

Compile:

gcc src/main.c -Iinclude -o build/database

Run:

./build/database

Check Git:

git status

Commit:

git add .
git commit -m "Create initial project structure"

In just a few commands, you have:

my_database
│
├── src
│   └── main.c
│
├── include
│   └── database.h
│
├── build
│   └── database
│
└── tests

The terminal becomes your development control center.

Is the Terminal Difficult?

At first, yes.

You need to remember commands.

You need to understand paths.

You need to understand files and permissions.

You will make mistakes.

But you do not need to memorize hundreds of commands.

Start with these:

pwd
ls
cd
mkdir
touch
cp
mv
rm
cat
clear

Then gradually learn:

grep
find
chmod
ps
kill
curl
ssh

Then developer tools:

git
gcc
make
cmake
python
docker

You learn the terminal the same way you learn programming:

One command at a time.

The Real Power of the Terminal

The terminal is powerful because it gives you a programmable interface to your computer.

A graphical interface is usually designed around predefined actions.

The terminal allows you to combine actions.

For example:

Program A
    │
    ▼
Program B
    │
    ▼
Program C
    │
    ▼
File

You can create workflows that are:

Repeatable
Scriptable
Automatable
Precise
Fast

That is why the terminal remains essential even in a world filled with advanced graphical tools.

Final Thoughts

The terminal might look simple:

But behind that small prompt is access to an enormous ecosystem of programs and system capabilities.

You can:

Navigate your filesystem.
Create and manage projects.
Compile programs.
Run applications.
Debug software.
Control Git repositories.
Connect to remote servers.
Automate repetitive tasks.
Build complete development pipelines.

The terminal is not something you need to master in one week.

Start small.

Learn how to move:

cd

Learn how to inspect:

ls

Learn how to create:

mkdir

Then slowly connect those commands together.

Eventually, you may stop seeing the terminal as a black screen with confusing text.

You will see it for what it really is:

A direct interface between your ideas, your programs, and your computer.

And once you become comfortable with it, the terminal stops feeling like an obstacle.

It becomes one of the most powerful tools in your development workflow.

Linus Torvalds: The Programmer Who Changed the World With Linux and Git

Farhad Rahimi Klie — Wed, 19 Aug 2026 01:52:52 +0000

From a personal computer project to Linux, Git, and the foundations of modern computing.

When we talk about the people who shaped modern software development, one name stands out: Linus Torvalds.

He is best known as the creator of the Linux kernel, the core software that powers Linux operating systems and countless servers, smartphones, embedded devices, cloud systems, and supercomputers.

But Torvalds created something else that programmers use every day: Git, the distributed version-control system.

His story is interesting because it demonstrates an important lesson in software engineering:

You don't always need to begin with a giant plan. Sometimes, a small technical project can grow into something much bigger than you imagined.

Who Is Linus Torvalds?

Linus Torvalds is a Finnish-American software engineer and programmer, born on December 28, 1969, in Helsinki, Finland.

He became interested in computers at a young age and eventually studied computer science at the University of Helsinki.

In the early 1990s, personal computers were becoming increasingly popular, but the operating systems and development environments available to students were limited.

Torvalds was interested in operating-system technology and began experimenting with a computer running MINIX, an operating system created by Andrew S. Tanenbaum for educational purposes.

That experimentation eventually led to Linux.

The Beginning of Linux

In 1991, Torvalds started developing an operating-system kernel as a personal project.

At first, Linux was not intended to become the foundation of a massive global ecosystem.

It was simply a project for learning and experimentation.

The original announcement was famously modest. Torvalds described what he was working on and invited other people to try it.

That small project eventually became the Linux kernel.

The important distinction is:

Linux is technically a kernel, not a complete operating system by itself.

The kernel manages fundamental resources such as:

CPU scheduling
Memory
Processes
Devices
Filesystems
Networking
System calls
Hardware interaction

A complete Linux-based operating system combines the kernel with many other components.

For example:

Linux-based operating system
│
├── Linux Kernel
│   ├── CPU management
│   ├── Memory management
│   ├── Process management
│   ├── Networking
│   ├── Device drivers
│   └── Filesystems
│
├── System libraries
├── Shell
├── Utilities
├── Desktop environment
└── Applications

This architecture is one reason Linux became extremely flexible.

Why Was Linux Important?

Linux was released as an open-source project.

That meant programmers around the world could study the source code, modify it, improve it, and contribute changes.

This created a powerful development model.

Instead of one company controlling the entire operating system, thousands of developers and organizations could participate.

Over time, Linux became important in many areas of computing.

Today, Linux is widely used in:

Web servers
Cloud infrastructure
Supercomputers
Embedded systems
Networking equipment
Development environments
Containers
Android's kernel foundation
Routers
Internet infrastructure

A huge amount of modern computing infrastructure depends on Linux.

The Linux Development Model

One of the most interesting parts of Torvalds' work isn't simply the code.

It is the development process.

The Linux kernel is developed collaboratively by a large global community.

A simplified version of the process looks like this:

Developer
   │
   ▼
Writes a change
   │
   ▼
Creates a patch
   │
   ▼
Patch is reviewed
   │
   ▼
Maintainer reviews it
   │
   ▼
Changes move through subsystem maintainers
   │
   ▼
Linux kernel integration
   │
   ▼
Testing
   │
   ▼
Release

This model allows thousands of contributors to work on an enormous codebase while maintaining a structured hierarchy of review and maintenance.

What Is the Linux Kernel Actually Doing?

Imagine you write this C program:

#include <stdio.h>

int main(void)
{
    printf("Hello, world!\n");
    return 0;
}

Your program doesn't directly control the hardware.

There are layers between your application and the physical machine.

A simplified model looks like this:

Your C Program
      │
      ▼
C Library
      │
      ▼
System Calls
      │
      ▼
Linux Kernel
      │
      ▼
Hardware

For example, when a program needs to read a file, it eventually asks the operating system to perform that operation.

The kernel handles the interaction with the storage device.

This is one of the fundamental responsibilities of an operating-system kernel:

providing controlled access to hardware and system resources.

Linux and C

If you're learning C and interested in operating systems, Linux is particularly important.

Much of the Linux kernel is written in C, along with some architecture-specific assembly code.

This makes Linux an excellent real-world example for understanding systems programming.

You can encounter concepts such as:

Pointers
Structures
Memory management
Processes
Threads
Interrupts
System calls
File descriptors
Virtual memory
Scheduling
Device drivers
Networking
Synchronization
Concurrency

For someone who wants to understand how computers work underneath high-level applications, studying Linux can be extremely valuable.

Torvalds Didn't Stop at Linux

Linux is the project most people associate with Linus Torvalds.

But he also created another extremely important piece of software:

Git.

Git is a distributed version-control system.

It was created in 2005 during a difficult period in Linux kernel development.

The Linux kernel project needed a powerful way to manage contributions from many developers.

Torvalds decided to build a new version-control system.

That system became Git.

What Is Git?

Suppose you are developing a project.

You might have:

project/
├── main.c
├── database.c
├── database.h
└── README.md

You make changes today.

Tomorrow, you change something else.

Then you realize:

"The project worked yesterday. What did I change?"

Without version control, this can become painful.

Git solves this problem by recording the history of your project.

A simplified Git workflow looks like:

Working Directory
       │
       ▼
     git add
       │
       ▼
   Staging Area
       │
       ▼
   git commit
       │
       ▼
 Git Repository

You can then inspect previous versions of your project.

Why Git Became So Important

Git has several powerful properties.

1. Distributed

Every Git clone can contain the complete repository history.

That means developers don't necessarily need to depend on one central server for the repository's history.

2. Fast

Git was designed to handle very large development projects efficiently.

This was particularly important for the Linux kernel.

3. Branching

Developers can create branches for different features or experiments.

For example:

main
 │
 ├── feature-login
 │
 ├── feature-database
 │
 └── bugfix-memory

Different developers can work on different branches and later merge their work.

4. History

Git records commits.

For example:

A → B → C → D → E

Each commit represents a point in the project's development history.

This makes it possible to understand how a project evolved.

GitHub and Git Are Not the Same Thing

This distinction is important for beginners.

Git is a version-control system.

GitHub is a platform that hosts Git repositories and provides collaboration features.

You can use Git without GitHub.

You can also use Git with other hosting platforms or your own servers.

Think of it this way:

Git
│
└── Version control

GitHub
│
├── Repository hosting
├── Pull requests
├── Issues
├── Collaboration
└── Other development tools

Git itself was created by Linus Torvalds.

Torvalds' Programming Philosophy

One reason Torvalds is influential is his strong focus on practical engineering.

Operating-system development requires thinking about:

Performance
Memory
Hardware
Concurrency
Reliability
Compatibility
Maintainability
Scalability

A small mistake in low-level software can affect an enormous number of systems.

That makes kernel development very different from writing a small application.

Why Linux Is Difficult to Build

If you're learning C and thinking:

"I want to build my own operating system."

Linux demonstrates just how large that problem can become.

A modern operating system requires many subsystems.

For example:

Operating System
│
├── Boot process
├── Kernel
│   ├── Process management
│   ├── Memory management
│   ├── Scheduling
│   ├── System calls
│   ├── Virtual memory
│   ├── Networking
│   ├── Filesystems
│   └── Device drivers
│
├── User-space libraries
├── Shell
├── Utilities
└── Applications

You don't need to build everything at once.

A beginner can start much smaller.

For example:

Step 1 → Boot a tiny program
Step 2 → Print text
Step 3 → Handle interrupts
Step 4 → Manage memory
Step 5 → Implement processes
Step 6 → Add system calls
Step 7 → Build a filesystem
Step 8 → Add networking

This incremental approach is much more realistic.

What Can We Learn From Linus Torvalds?

There are several lessons programmers can take from his career.

1. Start With a Real Project

Linux began as a personal project.

You don't need to wait until you know everything before building something.

Build.

Then discover what you don't know.

2. Learn How Computers Actually Work

If you only learn high-level programming, you can build useful applications.

But learning lower-level concepts gives you a different understanding of computers.

Study:

C
 ↓
Assembly
 ↓
CPU
 ↓
Memory
 ↓
Operating System
 ↓
System Calls
 ↓
Hardware

You don't have to become an expert in every layer immediately.

But understanding the layers is extremely useful.

3. Read Other People's Code

Linux is one of the largest examples of real-world systems software.

Reading mature code teaches you things tutorials often don't.

You can learn:

How large projects are organized
How abstractions are designed
How errors are handled
How data structures are used
How concurrency is implemented
How performance matters
How APIs evolve

However, don't start by trying to understand the entire Linux kernel.

That's an inefficient approach.

Start with smaller subsystems and concepts.

4. Understand Version Control

If you are serious about programming, Git is not merely another tool to memorize.

You should understand:

repository
commit
branch
merge
rebase
remote
diff
tag

These concepts become essential when working on real software projects.

5. Build Things That Are Difficult

Torvalds' work demonstrates the value of tackling technically challenging projects.

You could build smaller versions of systems such as:

Text Editor
      ↓
Shell
      ↓
Filesystem
      ↓
Database
      ↓
Network Server
      ↓
Compiler
      ↓
Operating System Kernel

You don't need to build a production-quality version.

The goal is understanding.

For example, building a small database in C can teach you:

Disk layout
Pages
Buffer pools
Indexes
Serialization
File I/O
Memory management
Concurrency

Building a filesystem can teach you:

Blocks
Inodes
Directories
Bitmaps
Allocation
Metadata
File descriptors

These projects make abstract concepts concrete.

Linux Is Bigger Than Linus Torvalds

An important point is that modern Linux is not the work of one person.

Torvalds started the project and remains its creator and principal maintainer, but Linux has grown through contributions from a massive international community.

Companies, universities, independent developers, and organizations have contributed to its development.

This is one of the most impressive aspects of open-source software.

A project can begin with one programmer and eventually become a global engineering effort.

A Simplified Timeline

1969
 │
 └── Linus Torvalds is born
       │
1980s
 │
 └── Develops an interest in computers
       │
1991
 │
 └── Begins developing Linux
       │
1990s
 │
 └── Linux community grows
       │
2005
 │
 └── Torvalds creates Git
       │
2000s–2020s
 │
 └── Linux becomes fundamental
     infrastructure for modern computing

The Bigger Lesson

The most interesting part of Linus Torvalds' story isn't simply that he created Linux.

It's that a relatively small technical project can become enormously important when:

The problem is interesting.
The implementation is useful.
The project is shared with others.
Developers can contribute.
The software continues to evolve.

Linux demonstrates the power of collaborative engineering.

Git demonstrates the importance of tools that make collaboration possible.

Together, they have had an enormous influence on modern software development.

If You Want to Follow a Similar Learning Path

You don't need to try to become "the next Linus Torvalds."

Instead, focus on becoming a strong programmer.

A practical path could look like this:

C Programming
      ↓
Data Structures
      ↓
Algorithms
      ↓
Linux
      ↓
Systems Programming
      ↓
Computer Architecture
      ↓
Operating Systems
      ↓
Networking
      ↓
Filesystems
      ↓
Databases
      ↓
Large Software Projects

Then build projects.

For example:

Project 1 → Shell
Project 2 → Text Editor
Project 3 → HTTP Server
Project 4 → Database
Project 5 → Filesystem
Project 6 → Compiler
Project 7 → Small Operating System

Each project forces you to learn another part of computer science.

Final Thoughts

Linus Torvalds' career is a remarkable example of how software can grow from a personal experiment into infrastructure used around the world.

Linux changed operating systems.

Git changed how developers manage source code.

But perhaps the most valuable lesson is simpler:

Build things.

Don't wait until you understand everything.

Start with a manageable problem.

Write the code.

Break it.

Debug it.

Read documentation.

Study other implementations.

Improve it.

Then build something harder.

That's how small programming projects turn into serious engineering experience.

And that's one of the most important lessons we can take from the story of Linus Torvalds, Linux, and Git.

How to Build Your Own SQLite Database From Scratch

Farhad Rahimi Klie — Sun, 16 Aug 2026 05:31:33 +0000

Have you ever wondered what actually happens when you run a SQL query like:

SELECT name FROM users WHERE id = 10;

Where is the data stored?

How does the database find the correct row?

How are tables represented on disk?

How does the database survive after the program exits?

And how does a database engine turn SQL into operations on bytes, pages, indexes, and files?

Instead of only using a database, let's build a small SQLite-like database engine from scratch in C.

We won't try to recreate all of SQLite. That would be an enormous project. Instead, we'll build a small educational database engine that teaches the fundamental architecture behind relational databases.

By the end, we'll understand how the pieces fit together:

                 SQL Query
                    │
                    ▼
             ┌─────────────┐
             │ SQL Parser  │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │ Query Plan  │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │   Executor  │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │    B-Tree   │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │ Buffer Pool │
             └──────┬──────┘
                    │
                    ▼
             ┌─────────────┐
             │ Disk / File │
             └─────────────┘

Let's build it step by step.

1. What Are We Actually Building?

Our goal is a small database executable:

$ ./mydb database.db

Then we can interact with it:

db > CREATE TABLE users;
db > INSERT INTO users VALUES (1, "Farhad");
db > INSERT INTO users VALUES (2, "Ali");
db > SELECT * FROM users;

And eventually:

1 | Farhad
2 | Ali

The important part is that the data should remain after the program exits.

If we run:

$ ./mydb database.db

again, the database should still contain:

1 | Farhad
2 | Ali

That means we need persistent storage.

2. Why C?

C is an excellent language for learning how databases work internally because it gives us direct control over:

memory
pointers
structs
files
byte arrays
serialization
memory allocation
system calls
data structures

A database engine ultimately deals with a lot of low-level concepts.

For example, a database page might simply be:

unsigned char page[4096];

Those 4096 bytes could contain:

+----------------------------------+
| Page Header                      |
+----------------------------------+
| Slot Array                       |
+----------------------------------+
|                                  |
| Records                          |
|                                  |
+----------------------------------+
| Free Space                       |
+----------------------------------+

At this level, there is no magic.

It's bytes.

Our job is to give those bytes meaning.

3. The Architecture

Before writing code, we need an architecture.

A simplified database can be divided into several layers:

┌───────────────────────────────┐
│          SQL Layer            │
│ Lexer / Parser / Statements   │
├───────────────────────────────┤
│        Query Executor         │
├───────────────────────────────┤
│       Access Methods          │
│       Table / B-Tree          │
├───────────────────────────────┤
│         Buffer Pool           │
├───────────────────────────────┤
│          Page Cache           │
├───────────────────────────────┤
│        Storage Manager        │
├───────────────────────────────┤
│        Database File          │
└───────────────────────────────┘

We'll implement these components incrementally.

4. Step 1 — The Database File

The simplest database can start as a normal file.

For example:

database.db

We can open it with:

FILE *file = fopen("database.db", "r+b");

Or create it if it doesn't exist:

FILE *file = fopen("database.db", "w+b");

But simply writing random structures into a file isn't enough.

We need a storage format.

5. Step 2 — Pages

Databases generally don't treat the disk as one giant byte array.

Instead, we divide the database file into fixed-size pages.

For our educational database:

#define PAGE_SIZE 4096

A database file might look like:

database.db

┌──────────────┐
│ Page 0       │
│ 4096 bytes   │
├──────────────┤
│ Page 1       │
│ 4096 bytes   │
├──────────────┤
│ Page 2       │
│ 4096 bytes   │
├──────────────┤
│ Page 3       │
│ 4096 bytes   │
├──────────────┤
│ ...          │
└──────────────┘

If the database has 100 pages:

100 × 4096 = 409,600 bytes

A page gives us a fixed unit for storage and caching.

6. Why Pages?

Suppose we need record number 500.

We don't want to read the entire database file.

Instead, we determine which page contains the record:

record
   │
   ▼
page number
   │
   ▼
database file offset

The offset is:

offset = page_number * PAGE_SIZE;

For example:

page = 10

offset = 10 × 4096
       = 40960

So page 10 begins at byte 40960.

7. Step 3 — The Pager

Now we create one of the most important components:

the pager.

The pager is responsible for moving pages between the database file and memory.

Conceptually:

             RAM
       ┌──────────────┐
       │ Page 0       │
       │ Page 4       │
       │ Page 7       │
       └───────┬──────┘
               │
               │
          ┌────▼────┐
          │  Pager  │
          └────┬────┘
               │
               ▼
       ┌──────────────┐
       │ database.db  │
       └──────────────┘

A basic pager structure might look like:

#define TABLE_MAX_PAGES 100

typedef struct {
    int file_descriptor;
    uint32_t file_length;
    void *pages[TABLE_MAX_PAGES];
} Pager;

The pages array stores pointers to pages currently loaded in memory.

8. Loading a Page

Suppose we request page 5.

The pager checks:

if (pager->pages[5] == NULL)

If it isn't loaded, allocate memory:

pager->pages[5] = malloc(PAGE_SIZE);

Then read the page from disk.

Conceptually:

database.db
     │
     │ read page 5
     ▼
┌─────────────┐
│ Page 5      │
└─────────────┘
     │
     ▼
RAM

This is the beginning of a buffer pool/cache.

9. Step 4 — Rows

Now we need to decide how a table row is represented.

For a simple database, let's define:

typedef struct {
    uint32_t id;
    char username[32];
    char email[64];
} Row;

A row might contain:

id       = 1
username = "Farhad"
email    = "farhad@example.com"

But we cannot simply assume that a C struct's memory layout is our database format.

We should explicitly serialize the row.

10. Serialization

Serialization means converting a C structure into bytes.

For example:

C structure

Row
┌───────────────┐
│ id            │
├───────────────┤
│ username      │
├───────────────┤
│ email         │
└───────────────┘
       │
       ▼
   serialize
       │
       ▼
Bytes on disk

We can write:

void serialize_row(Row *source, void *destination)
{
    memcpy(destination, &source->id, sizeof(source->id));

    memcpy(destination + 4,
           source->username,
           sizeof(source->username));

    memcpy(destination + 36,
           source->email,
           sizeof(source->email));
}

And later deserialize it.

This is important because the database file needs a well-defined format.

11. Step 5 — The Table

Now we can store rows inside pages.

Initially, we could use a very simple layout:

Page
┌──────────────────────────────┐
│ Row 0                        │
├──────────────────────────────┤
│ Row 1                        │
├──────────────────────────────┤
│ Row 2                        │
├──────────────────────────────┤
│ Row 3                        │
├──────────────────────────────┤
│ ...                          │
└──────────────────────────────┘

For example:

#define ROW_SIZE 100

#define ROWS_PER_PAGE \
    (PAGE_SIZE / ROW_SIZE)

Then:

page_number = row_number / ROWS_PER_PAGE;
row_offset  = row_number % ROWS_PER_PAGE;

This gives us a simple way to locate rows.

12. Step 6 — The REPL

Now let's create an interface.

A REPL means:

Read → Evaluate → Print → Loop

Our program could display:

db >

The user enters:

db > insert 1 Farhad

Our program reads the input:

char input[1024];

while (1) {
    printf("db > ");

    if (!fgets(input, sizeof(input), stdin))
        break;

    // process input
}

At first, don't implement SQL.

Start with commands like:

insert
select
.exit

This makes development much easier.

13. Step 7 — INSERT

Suppose the user enters:

insert 1 Farhad

The database needs to:

Input
 │
 ▼
Parse command
 │
 ▼
Create Row
 │
 ▼
Serialize Row
 │
 ▼
Find page
 │
 ▼
Write Row
 │
 ▼
Mark page dirty

Conceptually:

Row row;

row.id = 1;
strcpy(row.username, "Farhad");

execute_insert(&row);

14. Step 8 — SELECT

Now:

select

should read all rows.

The executor might:

for each page
    load page

    for each row
        deserialize row

        print row

Conceptually:

database
   │
   ▼
Page 0
   │
   ├── Row 0
   ├── Row 1
   └── Row 2

Page 1
   │
   ├── Row 3
   ├── Row 4
   └── Row 5

This is essentially a table scan.

15. Step 9 — From Commands to SQL

Once the storage engine works, we can start implementing SQL.

Instead of:

insert 1 Farhad

we want:

INSERT INTO users VALUES (1, 'Farhad');

And:

SELECT * FROM users;

Now we need a lexer and parser.

16. The SQL Lexer

The lexer converts characters into tokens.

For:

SELECT * FROM users;

we might produce:

SELECT
ASTERISK
FROM
IDENTIFIER(users)
SEMICOLON

The input:

SELECT * FROM users;

becomes:

┌────────┐
│ SELECT │
├────────┤
│   *    │
├────────┤
│  FROM  │
├────────┤
│ users  │
├────────┤
│   ;    │
└────────┘

17. The Parser

The parser takes those tokens and builds a representation of the query.

For example:

SELECT * FROM users;

could become:

SelectStatement
├── columns: *
└── table: users

For:

INSERT INTO users VALUES (1, 'Farhad');

we could create:

InsertStatement
├── table: users
└── values
    ├── 1
    └── Farhad

18. Step 10 — The Query Executor

The parser tells us what the user wants.

The executor determines how to perform it.

For example:

SELECT * FROM users;

might become:

Parser
   │
   ▼
SELECT statement
   │
   ▼
Executor
   │
   ▼
Table scan
   │
   ▼
Read pages
   │
   ▼
Read rows
   │
   ▼
Return results

This separation is extremely important.

19. Step 11 — Slotted Pages

Our first page layout was very simple.

A real database needs a more flexible structure.

This is where slotted pages become useful.

A page might look like:

┌─────────────────────────────┐
│ Page Header                 │
├─────────────────────────────┤
│ Slot 0                      │
├─────────────────────────────┤
│ Slot 1                      │
├─────────────────────────────┤
│ Slot 2                      │
├─────────────────────────────┤
│                             │
│ Free Space                  │
│                             │
├─────────────────────────────┤
│ Record 2                    │
├─────────────────────────────┤
│ Record 1                    │
├─────────────────────────────┤
│ Record 0                    │
└─────────────────────────────┘

The slot array tells us where records are located.

This allows records to have variable sizes and move around within a page without changing their logical identifiers.

20. Step 12 — Record IDs

Instead of identifying a record simply by its memory address, we can use a logical identifier.

For example:

RID
├── page_id
└── slot_id

So:

RID = (12, 4)

means:

Page 12
Slot 4

This gives us a stable way to refer to records.

21. Step 13 — Free Space Management

Eventually pages become full.

We need to know:

Which pages have free space?

A simple free-space map could track this:

Page 0 → full
Page 1 → 1200 bytes free
Page 2 → full
Page 3 → 3000 bytes free

When inserting a record, the storage manager searches for a page with enough free space.

This is one of the fundamental responsibilities of a storage engine.

22. Step 14 — B-Tree Indexes

A table scan works:

SELECT * FROM users WHERE id = 1000000;

But it can be very slow.

If there are one million rows, scanning every row is expensive.

We need an index.

A common database index structure is a B-tree or B+ tree.

Conceptually:

                  [50]
                /      \
              /          \
         [10,20,30]     [60,70,80]

The index lets us navigate toward the desired key instead of scanning every row.

For:

WHERE id = 70

we navigate:

23. Why B-Trees?

B-trees are particularly useful for storage systems because they reduce the number of disk/page accesses required to locate records.

Instead of:

Page 0
Page 1
Page 2
Page 3
...
Page 1,000,000

we can navigate through a tree:

             Root
              │
       ┌──────┴──────┐
       ▼             ▼
    Internal       Internal
       │             │
       ▼             ▼
     Leaves         Leaves
       │
       ▼
     Record

The database doesn't have to inspect every row.

24. Step 15 — Buffer Pool

Disk is much slower than RAM.

Therefore, databases keep frequently used pages in memory.

A buffer pool might look like:

RAM

┌───────────────┐
│ Frame 0       │ → Page 17
├───────────────┤
│ Frame 1       │ → Page 4
├───────────────┤
│ Frame 2       │ → Page 31
├───────────────┤
│ Frame 3       │ → Page 9
└───────────────┘

When the database requests page 17:

Request Page 17
      │
      ▼
Is it in buffer?
      │
   ┌──┴──┐
  yes    no
   │      │
   ▼      ▼
 return  read disk
          │
          ▼
       buffer

This dramatically reduces disk I/O.

25. Dirty Pages

Suppose we load a page:

Disk → RAM

Then modify it:

RAM
Page 5
  │
  └── modified

The page is now dirty.

Eventually we need:

RAM → Disk

So a buffer frame might have:

typedef struct {
    void *data;
    uint32_t page_id;
    int dirty;
} Frame;

If:

frame->dirty = 1;

we know the page must eventually be written back.

26. Step 16 — Transactions

Now we reach a much more serious database feature.

What happens if the program crashes halfway through a write?

For example:

Transaction:

1. Update row A
2. Update row B
3. Program crashes

We don't want the database to end up in an inconsistent state.

Transactions provide atomicity.

Conceptually:

BEGIN
   │
   ├── operation 1
   ├── operation 2
   ├── operation 3
   │
COMMIT

Or:

BEGIN
   │
   ├── operation 1
   ├── operation 2
   │
ROLLBACK

27. Step 17 — Write-Ahead Logging

A common technique is Write-Ahead Logging (WAL).

Before modifying the actual database page, record the change in a log.

             Transaction
                  │
                  ▼
             Write Log
                  │
                  ▼
             Modify Page
                  │
                  ▼
               Commit

If the database crashes, the log can be used during recovery.

This is one of the major steps from a toy database toward a real database engine.

28. Step 18 — Database Catalog

Once we support multiple tables, the database needs metadata.

For example:

CREATE TABLE users (...);
CREATE TABLE products (...);

The database needs to know:

users
 ├── columns
 ├── types
 └── root page

products
 ├── columns
 ├── types
 └── root page

This metadata is often called the system catalog.

Our catalog could contain information such as:

Table name
Column name
Column type
Column position
Index information
Root page

29. Step 19 — Data Types

Eventually our SQL engine should understand:

INTEGER
TEXT
REAL
BOOLEAN

For example:

CREATE TABLE users (
    id INTEGER,
    name TEXT,
    age INTEGER
);

Internally, a row might be serialized as:

┌──────────┬────────────┬──────────┐
│ id       │ name       │ age      │
│ INTEGER  │ TEXT       │ INTEGER  │
└──────────┴────────────┴──────────┘

The serialization layer needs to understand each type.

30. Step 20 — Query Execution

Eventually we want queries such as:

SELECT name
FROM users
WHERE age > 18;

The execution pipeline becomes:

SQL
 │
 ▼
Lexer
 │
 ▼
Parser
 │
 ▼
AST
 │
 ▼
Query Planner
 │
 ▼
Execution Plan
 │
 ▼
Executor
 │
 ▼
Index / Table Scan
 │
 ▼
Pages
 │
 ▼
Rows
 │
 ▼
Result

This is where our database starts becoming a real database engine rather than a file-based storage program.

31. A Practical Development Roadmap

Don't try to build everything at once.

Build the database in stages.

Stage 1 — File Storage

Implement:

database file
page size
read page
write page

Stage 2 — Pager

Implement:

Pager
page cache
page loading
page flushing

Stage 3 — Rows

Implement:

Row
serialize
deserialize

Stage 4 — Table

Implement:

insert
select
table scan

Stage 5 — REPL

Implement:

db >

with commands such as:

.insert
.select
.exit

Stage 6 — SQL Lexer

Implement tokens:

SELECT
INSERT
CREATE
FROM
WHERE
INTEGER
TEXT
IDENTIFIER
NUMBER
STRING

Stage 7 — SQL Parser

Build an AST for SQL statements.

Stage 8 — Slotted Pages

Implement:

page header
slot directory
records
free space

Stage 9 — B-Tree

Implement:

leaf nodes
internal nodes
search
insert
split

Stage 10 — Catalog

Implement:

tables
columns
types
indexes

Stage 11 — Query Execution

Implement:

table scan
index scan
filter
projection

Stage 12 — Transactions

Implement:

BEGIN
COMMIT
ROLLBACK

Stage 13 — WAL and Recovery

Implement:

log
checkpoint
recovery

Stage 14 — Concurrency

Eventually:

locks
latches
transactions
isolation

32. Suggested Project Structure

A clean project might eventually look like:

mydb/
│
├── src/
│   ├── main.c
│   ├── repl.c
│   ├── lexer.c
│   ├── parser.c
│   ├── executor.c
│   ├── catalog.c
│   ├── table.c
│   ├── row.c
│   ├── page.c
│   ├── pager.c
│   ├── buffer_pool.c
│   ├── btree.c
│   ├── transaction.c
│   ├── wal.c
│   └── recovery.c
│
├── include/
│   ├── repl.h
│   ├── lexer.h
│   ├── parser.h
│   ├── executor.h
│   ├── catalog.h
│   ├── table.h
│   ├── row.h
│   ├── page.h
│   ├── pager.h
│   ├── buffer_pool.h
│   ├── btree.h
│   ├── transaction.h
│   ├── wal.h
│   └── recovery.h
│
├── tests/
│   ├── test_pager.c
│   ├── test_page.c
│   ├── test_btree.c
│   └── test_sql.c
│
├── Makefile
└── database.db

You don't need all of these files on day one.

Start small and grow the architecture as the database becomes more capable.

33. The Most Important Concept

The biggest lesson from building a database from scratch is this:

A database is not just SQL.

SQL is only the interface.

Underneath SQL are many layers:

SQL
 ↓
Parser
 ↓
Query Planner
 ↓
Executor
 ↓
Indexes
 ↓
Tables
 ↓
Records
 ↓
Pages
 ↓
Buffer Pool
 ↓
Storage Manager
 ↓
Operating System
 ↓
Disk

And underneath all of that:

bytes

Understanding those layers gives you a completely different perspective on databases.

34. What We Should Not Build Initially

A common mistake is trying to implement everything immediately.

Don't start with:

SQL
Transactions
WAL
Concurrency
B-Trees
Joins
Indexes
Networking
Replication

all at once.

Instead:

file
 ↓
pages
 ↓
pager
 ↓
rows
 ↓
table
 ↓
insert/select
 ↓
B-tree
 ↓
SQL
 ↓
transactions
 ↓
WAL

Each stage should work before moving to the next.

35. Final Architecture

Our final educational database could look like this:

                    USER
                     │
                     ▼
              ┌─────────────┐
              │     SQL     │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │    Lexer    │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │    Parser   │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │Query Planner│
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │   Executor  │
              └──────┬──────┘
                     ▼
           ┌─────────┴─────────┐
           │                   │
           ▼                   ▼
      Table Scan            B-Tree
           │                   │
           └─────────┬─────────┘
                     ▼
              ┌─────────────┐
              │ Buffer Pool │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │    Pager    │
              └──────┬──────┘
                     ▼
              ┌─────────────┐
              │ Database DB │
              │    File     │
              └─────────────┘

Conclusion

Building a SQLite-like database from scratch is one of the best projects for learning systems programming.

You will learn far more than SQL.

You'll learn:

C programming
memory management
binary data
file I/O
serialization
page layouts
storage engines
buffer pools
indexing
B-trees
parsing
query execution
transactions
logging
crash recovery
operating-system I/O

The important thing is to build it incrementally.

Don't begin by asking:

"How do I build SQLite?"

Start by asking:

"How do I store one page?"

Then:

"How do I store one row?"

Then:

"How do I find that row?"

Then:

"How do I find millions of rows efficiently?"

Then:

"How do I make the operation safe if the program crashes?"

That's how a database engine grows—from a few thousand bytes of C code into a complete storage system.

And the best part is that every layer you implement gives you a deeper understanding of what databases are actually doing underneath the SQL interface.

GitHub Doesn't Get “Hacked” the Way You Think

Farhad Rahimi Klie — Mon, 10 Aug 2026 03:59:05 +0000

There is a dangerous misconception in software security:

“If someone hacked GitHub, they must have broken through GitHub's login page.”

Usually, that's not how modern attacks work.

The most interesting attacks don't necessarily defeat the strongest lock.

They find a different door.

A stolen OAuth token.

A compromised developer account.

A leaked secret.

A malicious dependency.

A vulnerable production service.

A trusted third-party integration.

A phishing attack.

A forgotten permission.

And once an attacker obtains a legitimate credential, the attack can look like completely normal activity.

That's what makes these attacks dangerous.

GitHub Is a Giant Trust System

Think about what a modern GitHub account can connect to:

Developer
    |
    +---- GitHub account
    |
    +---- Organizations
    |
    +---- Private repositories
    |
    +---- GitHub Actions
    |
    +---- OAuth applications
    |
    +---- Personal access tokens
    |
    +---- SSH keys
    |
    +---- Cloud credentials
    |
    +---- Package registries
    |
    +---- Deployment systems

GitHub isn't isolated.

It sits inside a much larger software ecosystem.

That means an attacker doesn't always need to attack GitHub directly.

They may attack something that already has permission to talk to GitHub.

And that distinction changes everything.

Attack #1: Steal the Key Instead of Breaking the Lock

One of the clearest examples happened in 2022.

GitHub disclosed an attack campaign involving stolen OAuth user tokens issued to third-party integrations, specifically Heroku and Travis CI.

The attacker used those stolen tokens to access GitHub APIs and selectively identify organizations and private repositories.

GitHub said it did not believe the attacker obtained those tokens by compromising GitHub itself.

Think about the architecture:

                 ┌──────────────┐
                 │   GitHub     │
                 └──────┬───────┘
                        │
                  OAuth trust
                        │
             ┌──────────┴──────────┐
             │                     │
        Third-party App       Third-party App
             │                     │
          Heroku              Travis CI

The attacker didn't necessarily need:

GitHub password
        ↓
GitHub login
        ↓
GitHub account

Instead, the attack path was conceptually:

Compromised integration
        ↓
Stolen OAuth token
        ↓
GitHub API authentication
        ↓
Authorized permissions
        ↓
Private repository access

That's a completely different security model.

The server sees a valid credential.

The credential has permission.

The request can therefore look legitimate.

The Most Dangerous Credential Is the One That Looks Legitimate

This is a fundamental security lesson.

Imagine a server receives:

Authorization: valid-token

The server doesn't automatically know:

"An attacker stole this token yesterday."

It sees:

valid credential
+
valid permission
+
valid API request

That is why credential theft can be so powerful.

You don't necessarily need to defeat authentication.

You can sometimes become the authenticated user.

Attack #2: Phishing the Developer

Another attack path is much simpler:

Attacker
   |
   | fake login page
   v
Developer
   |
   | enters credentials
   v
Attacker

GitHub documented a phishing campaign in which attackers created convincing login pages.

The important part was that even some accounts using TOTP-based two-factor authentication could be targeted because the phishing site relayed authentication information in real time.

GitHub noted that hardware security keys were not vulnerable to that particular attack technique.

This demonstrates an important distinction:

Authentication ≠ phishing resistance

A security mechanism can be strong while still being vulnerable to a particular social-engineering technique.

That's one reason phishing-resistant authentication matters.

Attack #3: Steal a Token After Taking the Account

Here's where attacks become interesting.

Suppose an attacker compromises a developer account.

The attacker doesn't necessarily stop there.

They may look for additional ways to maintain access.

GitHub documented attackers attempting to create personal access tokens, authorize OAuth applications, or add SSH keys after obtaining account credentials.

Conceptually:

Account compromise
        |
        +---- Password
        |
        +---- PAT
        |
        +---- OAuth application
        |
        +---- SSH key
        |
        +---- Repository permissions

Why?

Because attackers want persistence.

If the original password is changed, another credential may still provide access.

This is why security teams don't ask only:

“Was the password changed?”

They ask:

“What other credentials or trust relationships were created?”

Attack #4: The Secret You Accidentally Pushed

This is probably one of the most common developer mistakes.

Imagine writing:

const char *api_key =
    "SUPER_SECRET_VALUE";

Then committing:

git add .
git commit -m "add API integration"
git push

Now the secret may exist in Git history.

Deleting the line later doesn't necessarily erase the historical commit.

Conceptually:

Commit 1
   |
   +-- source code

Commit 2
   |
   +-- API_KEY = SECRET

Commit 3
   |
   +-- API_KEY removed

The developer sees:

Current code:
SECRET = gone

But the repository history may still contain:

Commit 2:
SECRET = still present

That's why:

Removing a secret from the latest version is not the same as revoking the secret.

If a real credential is exposed, the important response is generally to revoke/rotate it, then clean up the repository history where appropriate.

The Scale Is Bigger Than Most Developers Realize

GitHub reported that more than 39 million secrets were leaked across GitHub in 2024.

That's an enormous number.

And this explains why secret scanning and push protection exist.

GitHub has also described push protection as a mechanism that can block commits when supported secrets are detected before they enter public repositories.

The lesson isn't:

“GitHub is insecure.”

The lesson is:

Developers are part of the security boundary.

Your repository can be perfectly protected while you accidentally publish a cloud credential.

Attack #5: Attack the Supply Chain

Here's where things become much more complicated.

Your repository might be secure.

Your password might be secure.

Your server might be secure.

But what about your dependencies?

Consider:

Your application
      |
      +---- dependency A
      |
      +---- dependency B
      |
      +---- dependency C

And:

dependency C
      |
      +---- dependency D

Now your application depends on software you didn't write.

This creates a software supply-chain attack surface.

GitHub has specifically documented repo-jacking as a supply-chain risk. A repository that has been renamed or transferred can potentially create problems for projects that reference it incorrectly. GitHub recommends pinning dependencies to specific commit IDs in relevant scenarios.

The important idea is:

Trust
  ↓
Repository
  ↓
Dependency
  ↓
Build system
  ↓
Production

Every link matters.

Attack #6: A Vulnerability in the Platform

Sometimes the target really is the platform itself.

In December 2023, GitHub received a bug-bounty report describing a vulnerability that could allow access to environment variables from a production container.

GitHub patched the issue the same day and said its investigation found no evidence that the vulnerability had previously been discovered or exploited.

And in March 2026, GitHub disclosed a critical remote-code-execution vulnerability affecting multiple GitHub environments.

GitHub said it validated the report, deployed a fix to GitHub.com in under two hours, and concluded its investigation with no evidence of exploitation.

This is a completely different category:

Attacker
   |
   v
Vulnerability
   |
   v
Application
   |
   v
Execution
   |
   v
Potential privilege escalation

This is what people often imagine when they hear:

“GitHub got hacked.”

But finding and exploiting a vulnerability is only one possible attack path.

The Most Important Security Concept: Trust Boundaries

Let's simplify the whole problem.

Imagine GitHub as:

                    INTERNET
                       |
                       v
              ┌─────────────────┐
              │     GitHub      │
              └─────────────────┘
                 /     |      \
                /      |       \
               v       v        v
          Developers  OAuth   Actions
                      Apps

Every arrow represents a trust relationship.

And every trust relationship is an attack surface.

For example:

Developer
   |
   | credentials
   v
GitHub
   |
   | token
   v
OAuth application
   |
   | permissions
   v
Repository

If any link is compromised, the attacker may gain access to the next layer.

This is why modern security engineering focuses heavily on:

least privilege
credential rotation
short-lived credentials
strong authentication
audit logs
secret scanning
dependency pinning
network isolation
continuous monitoring

Why “Just Use 2FA” Isn't the Whole Answer

2FA is important.

But security isn't a single checkbox.

Consider:

Password
    +
2FA
    +
OAuth token
    +
SSH key
    +
GitHub Actions
    +
Cloud credentials

An account can have strong login protection while another credential remains compromised.

Security therefore becomes a lifecycle:

IDENTITY
   ↓
AUTHENTICATION
   ↓
AUTHORIZATION
   ↓
CREDENTIALS
   ↓
ACTIVITY
   ↓
MONITORING
   ↓
REVOCATION

Every stage matters.

Least Privilege Changes the Game

Suppose an application only needs to read one repository.

Bad design:

Application
    |
    +---- full organization access

Better design:

Application
    |
    +---- read-only
    |
    +---- specific repository

If that credential is stolen, the blast radius is smaller.

This is the principle of:

Least privilege

GitHub introduced fine-grained personal access tokens specifically to provide more precise permissions and reduce the risk associated with compromised tokens.

The question shouldn't be:

“Can this application access the repository?”

It should be:

“What is the minimum access this application needs?”

Think Like a Security Engineer

When you build software, don't ask only:

Does it work?

Ask:

What happens if this credential leaks?

What happens if this user is compromised?

What happens if this dependency becomes malicious?

What happens if this OAuth token is stolen?

What happens if this server is compromised?

What happens if an attacker gets read access?

What happens if an attacker gets write access?

How do we detect it?

How do we revoke access?

How do we recover?

Those questions are far more valuable than simply asking:

“Is my application secure?”

A Realistic Attack Chain

Put everything together.

A modern software attack could conceptually look like:

        PHISHING
           |
           v
    Developer account
           |
           v
     OAuth / PAT / SSH
           |
           v
     Private repository
           |
           v
       Secret found
           |
           v
     Cloud environment
           |
           v
     Production system

Notice something important.

The attacker didn't necessarily:

break GitHub

They abused trust.

That's the deeper lesson.

So, Was GitHub “Hacked”?

The answer depends on what you mean by hacked.

There have been:

account-targeting attacks
stolen-token campaigns
phishing campaigns
security vulnerabilities
service incidents
supply-chain risks
credential exposure incidents
attacks against GitHub Enterprise environments

But these are not all the same thing.

For example, in the 2022 OAuth-token incident, GitHub explicitly said it did not believe GitHub itself was compromised in the way people might normally imagine; attackers abused stolen tokens issued by third-party OAuth integrations.

And in the 2026 RCE disclosure, GitHub reported that it fixed the vulnerability and found no evidence of exploitation.

Precision matters.

“GitHub was hacked” can hide the actual security lesson.

The Real Lesson

The most dangerous misconception in cybersecurity is:

“Attackers break systems.”

Often, attackers don't need to.

They abuse what systems already trust.

A stolen credential.

A valid token.

A compromised account.

A vulnerable dependency.

A leaked secret.

An overly powerful service account.

A trusted integration.

That's modern security.

The strongest system isn't necessarily the system with the biggest lock.

It's the system where:

credentials are limited
        +
permissions are limited
        +
secrets are protected
        +
dependencies are controlled
        +
activity is monitored
        +
compromise is detected
        +
access can be revoked
        +
systems can recover

And that's the real reason GitHub security is interesting.

GitHub isn't just a website where developers store code.

It's a massive trust network connecting developers, identities, repositories, CI/CD systems, dependencies, cloud infrastructure, and production environments.

Attack the trust network—

and you may not need to attack the website at all.

Final Thought

The next time you run:

git push

remember:

You're not just uploading code.

You're participating in a security system.

Your repository has identities.

Your identities have permissions.

Your permissions have credentials.

Your credentials have blast radius.

And somewhere in that chain is the thing an attacker is looking for.

Security isn't about making one door impossible to break.

It's about making sure that opening one door doesn't open the entire building.

How to Build Your Own Filesystem From Scratch in C

Farhad Rahimi Klie — Mon, 03 Aug 2026 11:51:09 +0000

Stop treating filesystems as magic. Build one yourself and understand how operating systems actually store data.

Most programmers use a filesystem every day.

FILE *fp = fopen("notes.txt", "r");

int fd = open("file.txt", O_RDONLY);

But very few programmers know what happens after those function calls.

Where is the file actually stored?

How does the operating system know where its data begins?

How does deleting a file free disk space?

How does a filesystem survive a power failure?

These questions are answered by one piece of software:

The filesystem.

In this article, we'll build one from scratch—not a toy with a single array in memory, but a real userspace filesystem stored inside a disk.img file. By the end, you'll understand many of the same concepts used by Linux filesystems like ext2, ext3, and ext4.

Why Build a Filesystem?

Building a filesystem teaches far more than file storage.

You'll learn about:

Disk layouts
Binary file formats
Metadata
Block allocation
Bitmaps
Direct and indirect pointers
File growth
Directory structures
Crash consistency
C programming
Systems programming

It's one of the best projects for becoming a systems programmer.

What Is a Filesystem?

A filesystem is software that organizes raw bytes on a storage device.

Imagine you have a completely empty disk.

+------------------------------------------------+
|                                                |
|             1 GB of Random Bytes               |
|                                                |
+------------------------------------------------+

Without a filesystem, the operating system sees only bytes.

It doesn't know:

where files begin
where files end
which space is free
what filenames exist

The filesystem provides all of that information.

The Basic Idea

Instead of treating the disk as one giant byte array, we divide it into blocks.

Disk

+------+------+------+------+------+------+
|Blk 0 |Blk 1 |Blk 2 |Blk 3 |Blk 4 | ... |
+------+------+------+------+------+------+

A block is the smallest storage unit.

Typical sizes are:

512 bytes
1024 bytes
2048 bytes
4096 bytes

Linux commonly uses 4096-byte blocks.

Our Project

We'll build everything ourselves.

disk.img

+-------------------------+
| Superblock              |
+-------------------------+
| Bitmap                  |
+-------------------------+
| Inode Table             |
+-------------------------+
| Data Blocks             |
+-------------------------+

Every modern filesystem has something similar.

Step 1 — Create a Virtual Disk

Instead of modifying a real hard drive, we'll use a normal file.

disk.img

Think of it as pretending this file is an SSD.

disk.img

+------------------------------------------+
|                                          |
|             Raw Bytes                    |
|                                          |
+------------------------------------------+

We can open it using normal C functions.

FILE *disk = fopen("disk.img", "rb+");

int fd = open("disk.img", O_RDWR);

Every read and write will modify the virtual disk.

Step 2 — Design the Disk Layout

Before writing code, always design the filesystem.

Never start coding first.

Example layout:

Block 0
----------------
Superblock

Blocks 1-8
----------------
Bitmap

Blocks 9-40
----------------
Inode Table

Blocks 41+
----------------
File Data

Everything begins with a good layout.

Step 3 — Superblock

The superblock is the brain of the filesystem.

It stores global information.

Superblock

Magic Number
Version
Block Size
Total Blocks
Free Blocks
Inode Count
Free Inodes
Bitmap Start
Inode Start
Data Start

Whenever the filesystem mounts, it reads the superblock first.

Without it, nothing else can be understood.

Step 4 — Blocks

Instead of storing files continuously, we store them in blocks.

Example:

File

Hello World!

Stored as

Block 90

A larger file:

Block 90
Block 91
Block 92
Block 93

Large files simply occupy more blocks.

Step 5 — Free Space Management

How does the filesystem know which blocks are free?

Using a bitmap.

Example:

Block Number

0 1 2 3 4 5 6 7

Bitmap

1 1 0 0 1 0 0 0

Meaning:

1 = Used
0 = Free

Finding free space becomes easy.

Search bitmap

↓

00100000

↓

Found!

Allocate Block 2

This technique is used in ext2, ext3, ext4, FAT, and many other filesystems.

Step 6 — Inodes

The inode is the heart of every Unix filesystem.

It stores metadata—not the filename.

Example:

inode

File Size

Permissions

Owner

Creation Time

Modified Time

Block Pointers

Notice something missing?

The filename.

Linux stores filenames separately inside directories.

Step 7 — Direct Block Pointers

Small files are easy.

inode

Block 91

Block 92

Block 93

Block 94

Each pointer references one data block.

Reading the file is straightforward.

Read inode

↓

Read block pointers

↓

Read data

Step 8 — File Growth

Eventually a file becomes larger.

Before

inode

91

92

93

94

Now write more data.

Filesystem

↓

Find Free Block

↓

Allocate

↓

Update Bitmap

↓

Update Inode

↓

Increase File Size

Growing a file is simply allocating additional blocks and updating metadata.

Step 9 — Indirect Pointers

Direct pointers eventually run out.

Linux solves this with indirect blocks.

inode

Direct

Direct

Direct

Indirect
        |
        v

+--------------------+
|101|102|103|104|...|
+--------------------+

Instead of pointing to data, the inode points to another block containing many more block numbers.

This allows files to grow into gigabytes or even terabytes.

Step 10 — Directories

A directory is just another file.

Instead of storing text, it stores mappings.

Filename

↓

Inode Number

Example:

notes.txt

↓

inode 15

photo.png

↓

inode 42

movie.mp4

↓

inode 80

The operating system first finds the inode, then reads the file.

Step 11 — Reading a File

The process is surprisingly simple.

Open File

↓

Find Directory Entry

↓

Get Inode Number

↓

Read Inode

↓

Read Block Pointers

↓

Read Data Blocks

↓

Return Bytes

This sequence happens every time you open a file.

Step 12 — Deleting a File

Deleting does not erase the data immediately.

Instead:

Remove Directory Entry

↓

Free Blocks in Bitmap

↓

Free Inode

↓

Mark Space Available

The old bytes often remain until overwritten.

Step 13 — Formatting the Filesystem

Before using the disk, it must be formatted.

Formatting means:

Create the superblock
Initialize the bitmap
Create empty inode table
Reserve metadata blocks
Mark remaining blocks as free

After formatting, the filesystem is ready.

Step 14 — Features to Add Later

Once the core filesystem works, you can implement advanced features.

Symbolic Links

myfile

↓

inode

↓

Target Path

Hard Links

Multiple filenames pointing to the same inode.

fileA

↓

inode 12

↑

fileB

Journaling

Protects against crashes.

Write Journal

↓

Write Real Data

↓

Commit

If the system crashes, unfinished operations can be replayed safely.

Permissions

Store Unix permissions.

rwxr-xr-x

Timestamps

Maintain:

Creation time
Modification time
Access time

Nested Directories

Support structures like:

/

home/

home/user/

home/user/docs/

home/user/docs/file.txt

Suggested Development Order

Don't try to build everything at once.

Follow this roadmap:

Create disk.img
Define block size
Implement disk read/write functions
Create the superblock
Implement bitmap-based free space management
Build the inode table
Create files
Read files
Write files
Delete files
Implement file growth
Add directories
Support nested directories
Add indirect pointers
Add journaling
Add caching
Optimize performance

Each milestone builds on the previous one, making debugging much easier.

Final Thoughts

Building a filesystem is one of the most rewarding systems programming projects you can undertake. It combines low-level C programming, binary data structures, memory management, and operating system concepts into a single, practical project.

You'll stop thinking of files as mysterious objects managed by the OS and start seeing them for what they really are: carefully organized blocks of bytes, tracked by metadata and allocation structures.

If you can build a filesystem from scratch, you'll gain a much deeper understanding of how Linux works internally—and you'll develop the skills needed for advanced areas like kernel development, storage engines, databases, embedded systems, and operating system design.

Every byte on a disk has a purpose. Your job as a filesystem developer is to decide what that purpose should be.

How to Become a System Programmer in 2026

Farhad Rahimi Klie — Sun, 02 Aug 2026 10:57:47 +0000

Stop chasing frameworks. Start understanding the machine.

Most developers spend years learning frameworks, libraries, and APIs. Yet very few understand what actually happens after they press Compile or Run.

System programmers are different.

They build operating systems, databases, compilers, virtual machines, device drivers, networking software, embedded systems, hypervisors, game engines, and high-performance applications. They work closer to the hardware than almost any other software engineer.

In 2026, as AI generates more application code than ever before, developers who understand computers at the lowest levels are becoming increasingly valuable.

This article provides a practical roadmap to becoming a system programmer.

What Is System Programming?

System programming is the art of writing software that interacts directly with the operating system or hardware.

Instead of building websites or mobile apps, system programmers create software such as:

Operating systems
Kernels
Device drivers
File systems
Compilers
Linkers
Assemblers
Database engines
Virtual machines
Hypervisors
Networking software
Embedded firmware
Performance-critical libraries

These programs manage computer resources and provide services that application software depends on.

Why System Programming Matters More Than Ever

Many developers worry that AI will replace programmers.

AI can generate CRUD applications.

AI can build websites.

AI can write boilerplate code.

But AI still struggles with:

Operating system internals
CPU architecture
Memory management
Performance optimization
Lock-free algorithms
Kernel development
Compiler optimization
Hardware communication

These require deep understanding rather than memorization.

The closer you are to the hardware, the harder you are to replace.

Step 1 — Master the C Language

If system programming has a native language, it is C.

Learn:

Variables
Pointers
Arrays
Structures
Memory layout
Bitwise operators
Function pointers
Dynamic memory allocation
Header files
Build systems

Don't just memorize syntax.

Understand what every line becomes in memory.

You should know exactly why this works:

int *ptr = malloc(sizeof(int));

Not just that it works.

Step 2 — Learn Computer Architecture

A system programmer must understand the machine.

Study:

CPU execution
Registers
Cache hierarchy
Virtual memory
Paging
Stack vs Heap
Calling conventions
Assembly language
Interrupts
Pipelines

Books worth reading:

Computer Systems: A Programmer's Perspective
Computer Organization and Design
Modern Operating Systems

Step 3 — Become a Linux Power User

Windows is fine.

Linux is essential.

Spend every day inside Linux.

Learn:

Shell scripting
Bash
File permissions
Processes
Signals
Pipes
Redirection
ELF binaries
Package managers
System services

Use the terminal constantly.

If you can solve a problem without opening a GUI, do it.

Step 4 — Learn POSIX System Calls

Applications eventually communicate with the kernel through system calls.

Start with:

open()
close()
read()
write()
lseek()
mmap()
fork()
execve()
wait()
pipe()
dup()
socket()

Understand:

File descriptors
Buffers
Kernel transitions
User space vs Kernel space

Step 5 — Understand Memory

Memory separates beginner programmers from professionals.

Study:

Stack
Heap
Static memory
Memory alignment
Fragmentation
malloc()
calloc()
realloc()
free()
Memory leaks
Buffer overflows

Tools to master:

Valgrind
AddressSanitizer
GDB

Step 6 — Learn Data Structures From Scratch

Don't rely on library implementations.

Implement yourself:

Dynamic Arrays
Linked Lists
Stacks
Queues
Hash Tables
Binary Trees
AVL Trees
Red-Black Trees
Heaps
Tries
Skip Lists
Graphs

Then optimize them.

Measure their performance.

Step 7 — Study Operating System Internals

Every system programmer should know how an operating system works.

Topics include:

Process scheduling
Context switching
Virtual memory
File systems
Kernel architecture
Synchronization
Deadlocks
IPC
Threads
Scheduling algorithms

Read source code.

Linux is one of the greatest learning resources available.

Step 8 — Learn Networking

Computers rarely work alone.

Study:

TCP/IP
UDP
DNS
HTTP
HTTPS
Routing
Sockets
Epoll
Poll
Select

Build:

HTTP server
Chat server
File server

Step 9 — Learn Debugging

Professional programmers spend less time writing code than debugging it.

Master:

GDB
strace
ltrace
perf
objdump
nm
readelf

Learn to inspect:

Memory
Registers
Stack frames
Assembly
Core dumps

Step 10 — Read Source Code Every Day

The fastest way to improve is reading production-quality code.

Great projects include:

Linux Kernel
Git
SQLite
Redis
musl libc
BusyBox
Vim
Nginx
PostgreSQL

Professional programmers read code more often than they write it.

Step 11 — Build Real Projects

Projects teach lessons tutorials cannot.

Ideas:

Mini Shell
Memory Allocator
Text Editor
HTTP Server
File System
Thread Pool
Skip List Library
JSON Parser
Compiler
Virtual Machine
Toy Operating System
Custom malloc()

Each project exposes new challenges.

Step 12 — Learn Performance Engineering

Fast software wins.

Understand:

Cache locality
Branch prediction
SIMD
Compiler optimization
False sharing
Memory bandwidth
CPU profiling

Benchmark everything.

Never assume.

Measure.

Step 13 — Learn Assembly

You don't need to become an assembly expert.

But you should be able to read it.

Learn:

x86-64
ARM64
Calling conventions
Stack frames
Registers

Compile C programs with:

gcc -S program.c

Then compare your C code with the generated assembly.

Step 14 — Learn How Compilers Work

Compilers transform human-readable code into machine instructions.

Study:

Lexical analysis
Parsing
AST
Semantic analysis
Intermediate Representation (IR)
Optimization
Code generation

Building a tiny compiler will change the way you write code forever.

Step 15 — Never Stop Building

Knowledge without projects fades quickly.

Build something every month.

Examples:

Shell
Database
Cache
Compiler
Kernel module
TCP server
Memory allocator
Scheduler simulator

Experience compounds.

A Recommended Learning Roadmap

Beginner (0–3 Months)

C
Linux
Git
Bash
Makefiles

Intermediate (3–9 Months)

Data Structures
Pointers
Memory
System Calls
Debugging

Advanced (9–18 Months)

Operating Systems
Networking
Compilers
Concurrency
Performance Optimization

Expert (18+ Months)

Kernel Development
Database Internals
Distributed Systems
Virtual Machines
Embedded Systems

Final Thoughts

System programming isn't the easiest path—but it's one of the most rewarding.

It teaches you how computers actually work, not just how to use them. Every layer you master—from pointers and memory management to kernels and compilers—makes you a stronger engineer.

Frameworks will evolve. Languages will rise and fall. AI will continue to automate routine coding.

But developers who understand operating systems, hardware, performance, and low-level software will continue to solve the hardest engineering problems.

Don't aim to become someone who can simply write code.

Aim to become someone who understands the machine.

That's what separates a programmer from a system programmer.

How to Read Linux Man Pages Like a Professional Developer

Farhad Rahimi Klie — Fri, 17 Jul 2026 11:02:29 +0000

Stop searching Google for every Linux command. Learn how to read the official documentation that Linux developers use every day.

If you've ever typed:

man ls

and immediately closed it because it looked confusing...

You're not alone.

Many beginners think Linux man pages are difficult, outdated, or only for advanced developers.

The truth is completely different.

Professional Linux developers, system administrators, DevOps engineers, and C programmers read man pages every single day.

Learning to read them properly is one of the best skills you can develop.

After reading this guide you'll know:

What a man page actually is
Why man pages exist
How they're organized
How to navigate efficiently
How to search inside them
How to understand the syntax
How professionals read documentation quickly

Let's begin.

What Is a Linux Man Page?

Man stands for Manual.

A man page is the official documentation for a Linux command, system call, library function, configuration file, or programming interface.

Instead of searching random websites, Linux provides documentation directly on your computer.

For example:

man cp

opens the complete manual for the cp command.

Think of it as an offline encyclopedia built into Linux.

Why Were Man Pages Created?

Linux contains thousands of commands.

Nobody can remember every option.

Instead of memorizing everything, developers simply read the documentation whenever they need it.

Man pages are:

Official
Accurate
Installed locally
Available without Internet
Updated with software packages

This makes them one of the most reliable documentation sources available.

What Can You Find in Man Pages?

Man pages aren't only for commands.

They also document:

Linux commands
C library functions
System calls
Configuration files
Device files
File formats
Games
Administration commands

Examples:

man ls

Documentation for ls

man printf

Documentation for the shell version of printf

man 3 printf

Documentation for the C library function.

Understanding Man Sections

Linux organizes documentation into sections.

Section	Description
1	User Commands
2	System Calls
3	Library Functions (C)
4	Device Files
5	File Formats
6	Games
7	Miscellaneous
8	System Administration

Example:

man 2 open

Shows the Linux system call.

While

man 3 open

may show a library function if one exists.

This distinction is especially important for C programmers.

Opening a Man Page

Simply type:

man command

Example:

man grep

Linux opens the manual using a pager called less.

The Basic Structure of Every Man Page

Although every page is different, most follow the same structure.

NAME

The command name and a short description.

Example:

grep - print lines matching patterns

Always read this first.

SYNOPSIS

Shows the command syntax.

Example:

grep [OPTION]... PATTERN [FILE]...

This line tells you how to use the command.

Let's decode it.

Square Brackets

[OPTION]

Means optional.

You may include it or not.

Three Dots (...)

[FILE]...

Means multiple values are allowed.

Example:

grep hello file1 file2 file3

Uppercase Words

FILE
PATTERN

These are placeholders.

Replace them with your own values.

Vertical Bar

Sometimes you'll see

A | B

Choose one.

Not both.

DESCRIPTION

This explains what the command actually does.

Don't skip it.

Professionals usually read this section before anything else.

OPTIONS

This is where you'll spend most of your time.

Example:

-i

Ignore case.

-r

Recursive search.

-v

Invert match.

Example:

grep -ri hello project/

Read each option carefully.

EXAMPLES

Some man pages include examples.

Unfortunately many don't.

That's why understanding the syntax is important.

EXIT STATUS

Commands return an exit code.

Usually:

Success.

General failure.

Specific error.

This is very useful when writing shell scripts.

FILES

Shows which files the command uses.

Example:

Configuration files.

Cache files.

Database files.

Runtime files.

ENVIRONMENT

Lists environment variables that affect the command.

Example:

PATH
HOME
LANG

How to Navigate Inside a Man Page

Once opened, use these keys.

Key	Action
Space	Next page
b	Previous page
Enter	Next line
g	Top of document
G	Bottom of document
q	Quit
h	Help

These few shortcuts are enough for daily use.

Searching Inside a Man Page

Searching is one of the most useful features.

Press:

Then type a word.

Example:

/recursive

Press:

Enter

Go to the next match:

Previous match:

This saves a huge amount of time.

Searching for Man Pages

Don't know the command name?

Use:

man -k copy

Output:

cp
install
dd
rsync

Linux searches manual descriptions.

What If Multiple Man Pages Exist?

Use:

man -a printf

Linux will show every available manual page.

Viewing the File Location

Want to know where the documentation lives?

man -w ls

Example output:

/usr/share/man/man1/ls.1.gz

Reading C Programming Documentation

If you're a C programmer, this is one of the most important skills.

Instead of searching online for a function:

malloc()

Read its manual:

man 3 malloc

You'll learn:

Parameters
Return value
Errors
Examples
Standards
Thread safety

Other useful examples:

man 2 read
man 2 write
man 2 open
man 2 close
man 3 fopen
man 3 printf
man 3 pthread_create

A Professional Reading Workflow

Experienced developers rarely read an entire man page from top to bottom.

Instead, they follow a focused workflow:

Read NAME to understand the command's purpose.
Check SYNOPSIS to learn the required syntax.
Read DESCRIPTION for behavior and limitations.
Jump to OPTIONS and review only the flags you need.
Use / to search for keywords related to your task.
Look at SEE ALSO to discover related commands or APIs.

This approach is much faster than reading every section sequentially.

Common Beginner Mistakes

Reading Every Line

Most man pages are reference documents, not tutorials.

Read only the sections relevant to your current task.

Ignoring SYNOPSIS

The syntax line explains how to use the command correctly.

Always study it before trying examples.

Not Using Search

Searching with / is significantly faster than scrolling through long pages.

Ignoring SEE ALSO

Many useful Linux tools are discovered through this section.

Depending Only on Google

Search engines often lead to outdated or incomplete information.

The man page installed on your system matches the software version you're using.

Best Commands to Practice Reading

Start with these commands:

man ls
man cp
man mv
man rm
man cat
man pwd
man cd
man grep
man sed
man awk
man find
man chmod
man chown
man tar
man gzip

If you're learning C on Linux:

man 2 open
man 2 read
man 2 write
man 2 mmap
man 2 fork
man 2 execve
man 3 malloc
man 3 free
man 3 printf
man 3 fopen

Final Thoughts

Learning Linux isn't about memorizing every command or every option. It's about knowing where to find reliable information when you need it.

The man command gives you direct access to the official documentation for your system. Once you're comfortable reading the NAME, SYNOPSIS, DESCRIPTION, and OPTIONS sections—and using search effectively—you'll spend less time hunting for answers online and more time understanding how Linux actually works.

Whether you're a Linux beginner, a system administrator, a DevOps engineer, or a C programmer building low-level software, mastering man pages is a skill that will continue to pay off throughout your career.

50 Most Used Linux Commands for Programmers

Farhad Rahimi Klie — Sun, 05 Jul 2026 03:33:42 +0000

Linux is the backbone of modern development environments—from backend servers to DevOps pipelines and cloud systems. Whether you’re writing code, debugging applications, or managing servers, mastering Linux commands significantly boosts productivity.

Below are 50 essential Linux commands every programmer should know, grouped by purpose for easier learning.

1. File and Directory Navigation

These commands help you move around the filesystem quickly and efficiently.

1. pwd
Prints the current working directory. Useful when you’re lost in nested folders.

2. ls
Lists files and directories. Add -l for detailed view or -a to show hidden files.

3. cd
Changes directory. Example: cd /var/www.

4. tree
Displays directory structure in a tree format (may need installation).

5. find
Searches for files and directories based on conditions like name or type.

2. File Operations

These are used constantly in development workflows.

6. touch
Creates an empty file or updates timestamp.

7. cp
Copies files or directories.

8. mv
Moves or renames files.

9. rm
Deletes files or directories. Use carefully.

10. mkdir
Creates a new directory.

11. rmdir
Removes empty directories.

3. File Viewing and Text Processing

Crucial for reading logs, configs, and code files.

12. cat
Displays file content.

13. less
View large files page by page.

14. head
Shows first 10 lines of a file.

15. tail
Shows last 10 lines (useful for logs).

16. nano
Simple terminal text editor.

17. vim
Powerful advanced text editor widely used by developers.

4. Permissions and Ownership

Important for security and server management.

18. chmod
Changes file permissions.

19. chown
Changes file owner and group.

20. umask
Sets default permissions for new files.

5. Process Management

Used for monitoring and controlling running applications.

21. ps
Displays running processes.

22. top
Real-time system process monitoring.

23. htop
Improved version of top (interactive UI).

24. kill
Terminates a process by PID.

25. pkill
Kills process by name.

26. jobs
Shows background jobs.

27. fg
Brings background job to foreground.

28. bg
Resumes a stopped job in background.

6. Networking Commands

Essential for APIs, servers, and debugging network issues.

29. ping
Checks connectivity to a host.

30. curl
Transfers data from/to servers via HTTP.

31. wget
Downloads files from the web.

32. netstat
Shows network connections and ports.

33. ss
Modern replacement for netstat.

34. ifconfig
Displays network interfaces (deprecated but still used).

35. ip
Modern tool for network configuration.

7. Disk and Storage

For managing space and file systems.

36. df
Shows disk space usage.

37. du
Shows directory size.

38. lsblk
Lists block devices (disks, partitions).

39. mount
Mounts file systems.

40. umount
Unmounts file systems.

8. Compression and Archiving

Useful for backups and deployments.

41. tar
Creates and extracts archives.

42. zip
Compresses files into .zip format.

43. unzip
Extracts zip files.

44. gzip
Compresses files using gzip.

45. gunzip
Decompresses gzip files.

9. System Information

Helpful for understanding system state.

46. uname
Displays system information.

47. uptime
Shows how long system has been running.

48. whoami
Displays current user.

49. history
Shows previously executed commands.

50. alias
Creates shortcuts for long commands.

Final Thoughts

These 50 Linux commands form a strong foundation for any programmer working in Linux environments. You don’t need to memorize everything at once—start with navigation, file operations, and process management, then gradually expand into networking and system tools.

With regular use, these commands become muscle memory and significantly improve your speed, debugging ability, and overall workflow efficiency.

DEV Community: Farhad Rahimi Klie

Critical Thinking in Programming: The Skill AI Can't Replace

What Is Critical Thinking?

Programming Is Not Just Writing Code

AI Is Extremely Good at Generating Solutions

The Most Important Question: "Why?"

Don't Trust Code Just Because It Compiles

AI Can Be Confidently Wrong

Learn to Question Assumptions

Debugging Is Critical Thinking

Learn to Think in Invariants

Critical Thinking Helps You Design Better Systems

The Difference Between a Coder and an Engineer

Level 1 — Syntax

Level 2 — Implementation

Level 3 — Algorithms

Level 4 — Design

Level 5 — Reasoning

Don't Become a "Prompt Programmer"

Ask AI Better Questions

Build Things Without AI Sometimes

Read Code You Didn't Write

Learn the Fundamentals

Computer architecture

Operating systems

Data structures

Algorithms

Programming languages

AI Changes the Value of Programming Skills

The Programmer's New Superpower

The Question Isn't "Can AI Write Code?"

Final Thoughts

Flat Assembler (FASM): A Practical Introduction to Low-Level Programming

What Is Flat Assembler?

Why Is FASM Interesting?

1. It is self-hosting

2. It has a powerful macro system

3. It can generate different executable formats

4. It gives you direct control

FASM vs NASM

Your First FASM Program

format

segment

entry

Labels

Registers

The mov Instruction

Memory

Data Definitions

db

dw

dd

dq

Strings

Reserving Memory

Arithmetic

Bitwise Operations

Comparing Values

Control Flow

The Stack

Functions

Linux System Calls

FASM Macros

Why Learn FASM Macros?

FASM Structures

Address Expressions

FASM and Executable Formats

What Can You Build With FASM?

Small programs

Systems programming

Binary programming

Educational projects

Advanced projects

A Good Way to Learn FASM

Layer 1 — CPU Fundamentals

Layer 2 — Basic Instructions

Layer 3 — Control Flow

Layer 4 — Memory

Layer 5 — Stack and Functions

Layer 6 — Operating System Interface

`format`

`segment`

`entry`

The `mov` Instruction

`db`

`dw`

`dd`

`dq`

`wsl --install` Doesn't Work