Wesley Bertipaglia

Putting It Together: A Small C Program

Tue, 13 Oct 2026 00:00:00 GMT

The series covered each part of C on its own. This last post uses all of it at once to build a small, complete command-line program: it reads numbers from a file, keeps them in a dynamically growing array, and prints the count, sum, average, minimum, and maximum. It is the wc of numbers, and along the way you will see every earlier topic earn its place.

What the program does

$ ./stats numbers.txt
count:   5
sum:     150.00
average: 30.00
min:     10.00
max:     50.00

The design is split into a library (stats.c with a header stats.h) and a thin main (main.c). The library holds all the logic and knows nothing about the terminal; main handles the command line. That split is deliberate: it is what the testing post called keeping the pure middle away from the I/O edges, and it lets us test the logic without running the program.

The header: the contract

The header is where the functions post's "prototype" idea lives for a whole file. It also defines the struct that holds the numbers:

#ifndef STATS_H
#define STATS_H

#include <stddef.h>

typedef struct {
    double *values;      // heap array of the numbers
    size_t count;        // how many are stored
    size_t capacity;     // how many fit before growing
} Numbers;

int    numbers_init(Numbers *n, size_t capacity);
int    numbers_push(Numbers *n, double value);
void   numbers_free(Numbers *n);
int    numbers_read(Numbers *n, const char *path);

double numbers_average(const Numbers *n);
double numbers_min(const Numbers *n);
double numbers_max(const Numbers *n);

#endif

Two things to notice. The #ifndef/#define/#endif guard prevents the header from being included twice, which would otherwise re-declare the struct and fail to compile. And every function that can fail returns int, with 0 for success and -1 for failure, the convention from the error-handling post. The Numbers struct is exactly the "group different fields under one name" idea from the structs post: a pointer to the array, plus how many slots are used and how many exist.

Growing memory

init, push, and free manage the heap array. Growth doubles capacity when full, so the total work stays linear instead of copying on every insert:

#include "stats.h"
#include <stdio.h>
#include <stdlib.h>

int numbers_init(Numbers *n, size_t capacity) {
    n->values = malloc(capacity * sizeof(double));
    if (n->values == NULL) {
        n->count = 0;
        n->capacity = 0;
        return -1;
    }
    n->count = 0;
    n->capacity = capacity;
    return 0;
}

int numbers_push(Numbers *n, double value) {
    if (n->count == n->capacity) {
        size_t next = n->capacity == 0 ? 4 : n->capacity * 2;
        double *grown = realloc(n->values, next * sizeof(double));
        if (grown == NULL) {
            return -1;              // original block is still valid
        }
        n->values = grown;
        n->capacity = next;
    }
    n->values[n->count] = value;
    n->count++;
    return 0;
}

void numbers_free(Numbers *n) {
    free(n->values);
    n->values = NULL;
    n->count = 0;
    n->capacity = 0;
}

Every memory rule from the pointers post is here. malloc counts bytes, so we multiply by sizeof(double). Every allocation is checked against NULL. realloc returns the new block (which may have moved) and must not overwrite the old pointer until it succeeds; that is why we store into grown first. And free sets the pointer back to NULL so a later accidental use is a clean crash, not silent corruption. The struct is always passed as a pointer (Numbers *n), because the functions must modify its fields and a by-value copy would edit a doomed duplicate.

Reading the file

Reading numbers from a file shows pointers, strings, loops, and error handling together:

int numbers_read(Numbers *n, const char *path) {
    FILE *f = fopen(path, "r");
    if (f == NULL) {
        return -1;                  // caller decides how to report it
    }

    double value;
    while (fscanf(f, "%lf", &value) == 1) {
        if (numbers_push(n, value) != 0) {
            fclose(f);              // free the resource before leaving
            return -1;
        }
    }

    fclose(f);
    return 0;
}

fopen returns NULL on failure; the &value passed to fscanf is the address-of operator, because the function writes through it. The loop condition is a fscanf call: it returns 1 for each successfully read number and stops at end of file, which is a compact "read until there is nothing left" pattern. The const char *path parameter means "I read this string, I never modify it", matching the string post. On the one failure path, the open file is closed before returning, so nothing leaks.

The statistics functions

These are the pure functions, taking const Numbers * and returning a double:

double numbers_average(const Numbers *n) {
    if (n->count == 0) {
        return 0.0;
    }
    double total = 0.0;
    for (size_t i = 0; i < n->count; i++) {
        total += n->values[i];
    }
    return total / (double)n->count;
}

double numbers_min(const Numbers *n) {
    if (n->count == 0) return 0.0;
    double best = n->values[0];
    for (size_t i = 1; i < n->count; i++) {
        if (n->values[i] < best) best = n->values[i];
    }
    return best;
}

double numbers_max(const Numbers *n) {
    if (n->count == 0) return 0.0;
    double best = n->values[0];
    for (size_t i = 1; i < n->count; i++) {
        if (n->values[i] > best) best = n->values[i];
    }
    return best;
}

They take a pointer so the whole array is not copied, and const so a bug inside cannot modify it. The empty-input guard is the defensive habit from the error-handling post: handle the boundary case instead of dividing by zero.

The main function

main owns the command-line arguments, wires the pieces, and reports errors to stderr:

#include "stats.h"
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv) {
    if (argc != 2) {
        fprintf(stderr, "usage: %s <file-with-numbers>\n", argv[0]);
        return EXIT_FAILURE;
    }

    Numbers numbers;
    if (numbers_init(&numbers, 8) != 0) {
        fprintf(stderr, "out of memory\n");
        return EXIT_FAILURE;
    }

    if (numbers_read(&numbers, argv[1]) != 0) {
        fprintf(stderr, "could not read %s\n", argv[1]);
        numbers_free(&numbers);
        return EXIT_FAILURE;
    }

    printf("count:   %zu\n", numbers.count);
    printf("sum:     %.2f\n", numbers_average(&numbers) * numbers.count);
    printf("average: %.2f\n", numbers_average(&numbers));
    printf("min:     %.2f\n", numbers_min(&numbers));
    printf("max:     %.2f\n", numbers_max(&numbers));

    numbers_free(&numbers);
    return EXIT_SUCCESS;
}

argc/argv are how every C program reads its command line: argc is the count, and argv is an array of strings, with argv[0] the program name. The first check rejects the wrong number of arguments. Then memory is allocated, the file is read, results are printed, and the memory is freed on the way out. If reading fails, the program frees before returning, the same cleanup-first habit from the error post.

Build it

Compile all the .c files together and link the math library:

gcc -Wall -Wextra -g -fsanitize=address,undefined -o stats stats.c main.c -lm

With a numbers.txt containing 10 20 30 40 50, running ./stats numbers.txt prints the block at the top of this post. -Wall -Wextra raise the warnings, and the sanitizers turn any memory mistake into a named error.

Test it

The header from the library is what makes testing possible: the test file includes stats.h and calls the same functions, no main needed from the program:

#include "stats.h"
#include <math.h>
#include <stdio.h>
#include <stdlib.h>

static int failures = 0;

#define CHECK(expr)                                                        \
    do {                                                                   \
        if (!(expr)) {                                                     \
            printf("FAIL %s:%d: %s\n", __FILE__, __LINE__, #expr);         \
            failures++;                                                    \
        }                                                                  \
    } while (0)

static int approx(double a, double b) {
    return fabs(a - b) < 1e-9;
}

int main(void) {
    Numbers n;
    CHECK(numbers_init(&n, 2) == 0);

    CHECK(numbers_push(&n, 10.0) == 0);
    CHECK(numbers_push(&n, 20.0) == 0);
    CHECK(numbers_push(&n, 30.0) == 0);        // forces a realloc
    CHECK(n.count == 3);

    CHECK(approx(numbers_average(&n), 20.0));
    CHECK(approx(numbers_min(&n), 10.0));
    CHECK(approx(numbers_max(&n), 30.0));

    numbers_free(&n);
    CHECK(n.values == NULL);

    Numbers empty;
    CHECK(numbers_init(&empty, 4) == 0);
    CHECK(approx(numbers_average(&empty), 0.0));   // boundary case
    numbers_free(&empty);

    if (failures > 0) {
        printf("%d test(s) failed\n", failures);
        return EXIT_FAILURE;
    }
    printf("all tests passed\n");
    return EXIT_SUCCESS;
}

gcc -Wall -Wextra -g -fsanitize=address,undefined -o test_stats stats.c test_stats.c -lm
./test_stats

Because the test runs under AddressSanitizer, the realloc path is verified for leaks and invalid access at the same time the results are checked. Every memory rule from the whole series is enforced by the tooling.

The big picture

This tiny program is the series in miniature. The Numbers struct groups fields and is passed by pointer so it can change. malloc/realloc/free manage a runtime-sized array. Strings reach the file functions as const char *. Loops and conditionals do the work; functions package it into named, testable units; error codes and if (f == NULL) handle the failures; sanitizers and a CHECK harness prove it correct. Nothing here is larger than the parts you already learned.

That is C[^1]: a small language whose pieces connect directly to the machine. You now have the whole toolkit, from int main(void) to manual memory and tests. The reward is the one property no other language hands you for free: you always know what your program is doing.

[^1]: C (programming language) - Wikipedia

Testing C Code

Mon, 12 Oct 2026 00:00:00 GMT

C gives you no test runner, no test annotations, and no package manager. What it gives you is a language you already understand and an exit code. That is enough to build a real test suite, and understanding the bare mechanism is the fastest way to use the frameworks later. This post builds a small harness from scratch, then shows the tools professionals add on top.

The idea of a unit test

A unit test[^1] checks one piece of behavior in isolation: build a function with known inputs, compare the result to what you expect, and fail loudly if they differ. Tests live in their own .c file, call your functions, and report pass or fail. The main function returns 0 only if everything passed, which is exactly what continuous integration and make test expect.

A tiny harness, no dependencies

Start with a function to test, in math_utils.c:

int add(int a, int b) {
    return a + b;
}

double average(const int *values, int n) {
    int total = 0;
    for (int i = 0; i < n; i++) {
        total += values[i];
    }
    return (double)total / n;
}

Now a test file, test_math_utils.c, that counts failures:

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int add(int a, int b);
double average(const int *values, int n);

static int failures = 0;

#define CHECK(expr)                                        \
    do {                                                   \
        if (!(expr)) {                                     \
            printf("FAIL %s:%d: %s\n", __FILE__, __LINE__, #expr); \
            failures++;                                    \
        } else {                                           \
            printf("ok   %s\n", #expr);                    \
        }                                                  \
    } while (0)

int main(void) {
    CHECK(add(2, 3) == 5);
    CHECK(add(-1, 1) == 0);
    CHECK(add(0, 0) == 0);

    int values[] = {2, 4, 6};
    CHECK(fabs(average(values, 3) - 4.0) < 1e-9);

    if (failures > 0) {
        printf("\n%d test(s) failed\n", failures);
        return EXIT_FAILURE;
    }
    printf("\nall tests passed\n");
    return EXIT_SUCCESS;
}

The CHECK macro is the whole framework: it evaluates an expression, prints ok or FAIL with the file and line, and increments a counter. #expr turns the expression into its own text so the output explains itself. Running main returns a non-zero exit code when anything failed, which is all a build pipeline needs.

Compile and run both files together:

gcc -Wall -Wextra -o test_math math_utils.c test_math_utils.c -lm
./test_math

Note -lm: the math library (fabs) needs to be linked explicitly on many systems. Comparing floats with a tolerance (< 1e-9) instead of == follows the rule from the data types post: decimal arithmetic is never exact.

Table-driven tests

When a function has many input/output pairs, write them as data and loop. This keeps one piece of test logic and dozens of cases:

typedef struct {
    int a;
    int b;
    int expected;
} AddCase;

int main(void) {
    AddCase cases[] = {
        {2, 3, 5},
        {-1, 1, 0},
        {0, 0, 0},
        {100, 200, 300},
    };

    for (int i = 0; i < 4; i++) {
        int got = add(cases[i].a, cases[i].b);
        if (got != cases[i].expected) {
            printf("FAIL add(%d, %d): expected %d, got %d\n",
                   cases[i].a, cases[i].b, cases[i].expected, got);
            return EXIT_FAILURE;
        }
    }
    printf("all %d cases passed\n", 4);
    return EXIT_SUCCESS;
}

Adding a case is one line, and structs plus arrays (from the earlier posts) pay off immediately here.

Test what is easy to test

The functions above are pure: same inputs, same output, no side effects. They are trivial to test. Functions that print, read input, allocate, or touch files are harder, so experienced C programmers isolate the pure logic from the I/O:

// hard to test: mixes parsing and printing
void print_upper(const char *s);

// easy to test
int to_upper(char *dst, const char *src, size_t cap);

Push printf, scanf, and fopen to the edges of the program; keep the middle in pure functions that take values and return values. This is the single biggest factor in whether a C project is testable.

Catching memory bugs with sanitizers

Tests prove behavior; sanitizers find undefined behavior. Compile the test binary with the address and undefined-behavior sanitizers and the tool runtime checks every memory access and arithmetic operation, reporting file and line on failure:

gcc -Wall -Wextra -g -fsanitize=address,undefined \
    -o test_math math_utils.c test_math_utils.c -lm
./test_math

AddressSanitizer[^2] catches buffer overflows, use-after-free, and double frees; UndefinedBehaviorSanitizer catches integer overflow, invalid shifts, and null dereferences. Run the whole test suite under them in CI; they turn silent corruption into a named error. For leaks specifically, valgrind is the classic tool:

valgrind --leak-check=full ./test_math

Neither is a substitute for tests, and tests are not a substitute for them. Use both.

A real framework, when the harness grows

The hand-rolled CHECK harness is fine for a small project. When you want test discovery, setup/teardown, and nicer reports, the lightweight C frameworks all follow the same shape:

Unity - tiny, popular in embedded, one .c and one .h.
CMocka - supports mocks and setup/teardown.
Criterion - compiles tests into separate processes, so a crash in one test does not kill the run.
Check - the older, unit-test classic.

Because they are just C libraries, you add the files, link them into your test binary, and run it. Nothing about your understanding of the harness changes; the framework only saves typing.

One test, one behavior

A few habits make the difference between a suite you trust and one you ignore:

Test the boundaries: zero, one, negative, the maximum, and the empty case.
Test the error paths too, not only the happy path. Feed malloc a size it can refuse, pass a NULL pointer, an out-of-range value.
Keep tests fast and independent. A test that depends on another test's leftovers is worse than no test.
Run the tests automatically on every change. A test you have to remember to run is a test you will forget.

The big picture

Testing C needs no magic: a separate test file, a CHECK macro, a failure counter, and an exit code. Table-driven cases keep many inputs cheap; pure functions keep testing easy; sanitizers and valgrind catch the memory crimes that tests cannot see; and real frameworks only automate this same loop. In the final post we put the whole series together and build one small program from scratch, tests included.

[^1]: Unit testing - Wikipedia

[^2]: AddressSanitizer - Wikipedia

Error Handling in C

Sun, 11 Oct 2026 00:00:00 GMT

Most modern languages throw exceptions: an error interrupts the normal flow and a handler far away catches it. C has no exceptions at all. Instead, every function that can fail tells you so through its return value, and you decide whether and how to handle it. That sounds primitive, and it is, but it is also why C code can be reasoned about precisely: nothing jumps out of nowhere.

The golden rule of C error handling[^1]: check the return value of every function that can fail, and handle it immediately or pass it up.

Error codes as return values

The main function already showed the idea: return 0 means success and a non-zero value means failure, and that convention propagates everywhere. Many functions return an int status where 0 is success and negative values name the specific failure:

typedef enum {
    OK = 0,
    ERR_OPEN,
    ERR_READ,
    ERR_NOMEM
} Status;

Status load(const char *path) {
    FILE *f = fopen(path, "r");
    if (f == NULL) {
        return ERR_OPEN;
    }
    // ... use f ...
    fclose(f);
    return OK;
}

Callers test the result and decide:

Status s = load("data.txt");
if (s != OK) {
    fprintf(stderr, "load failed with code %d\n", s);
    return 1;
}

Two conventions to recognize in the wild: return 0 for success (borrowed from Unix) and -1/NULL for failure; or return a boolean-like 1/0. The enum version above scales best because each error has a name.

Pointers as failure signals

Functions that return a pointer signal failure with NULL. fopen, malloc, and strchr all do this, which is why the pointers post insisted on the != NULL check. NULL is the closest thing C has to "no result":

FILE *f = fopen("notes.txt", "r");
if (f == NULL) {
    perror("fopen");
    return 1;
}

errno, perror, and strerror

When a system function like fopen, read, or malloc fails, it also records why in the global errno variable, declared in <errno.h>. Two helpers turn that number into a message:

perror("fopen") prints fopen: <message> to stderr, based on the current errno.
strerror(errno) returns the message string so you can format it yourself.

#include <errno.h>
#include <string.h>

FILE *f = fopen("missing.txt", "r");
if (f == NULL) {
    fprintf(stderr, "could not open file: %s\n", strerror(errno));
    return 1;
}

Print errors to stderr, not stdout. stderr is the standard error stream, and printing there keeps diagnostics out of the program's normal output (so they still appear when output is redirected to a file). errno is set only when a function documents that it sets it, and only on failure, so set it to 0 before a call if you want to be sure the value you see came from that call.

assert: bugs vs errors

Some conditions are programming mistakes that should never happen, like malloc returning NULL in a teaching program or an index going negative. assert from <assert.h> checks such "this must be true" claims and aborts loudly if they are false:

#include <assert.h>

int divide(int a, int b) {
    assert(b != 0);   // a caller bug, not a runtime user error
    return a / b;
}

When the assertion fails, the program prints the file and line and stops. Assertions are for invariants that separate a broken program from valid input. They are compiled out when you define NDEBUG, so never put code with side effects inside assert, and never use them for things a user can trigger (like bad input) because not all builds check them.

exit and atexit

exit(status) ends the whole program immediately, running cleanup handlers registered with atexit on the way out:

#include <stdlib.h>

FILE *f = fopen("out.txt", "w");
if (f == NULL) {
    fprintf(stderr, "cannot write output\n");
    exit(EXIT_FAILURE);   // 1
}
// ...
exit(EXIT_SUCCESS);        // 0

EXIT_SUCCESS and EXIT_FAILURE are the portable values for return 0 and return 1. Prefer returning from main when you can, and reach for exit only when the error is unrecoverable deep inside nested calls. atexit(fn) registers a function to run when the program exits, useful for flushing files or freeing global resources.

setjmp and longjmp

C does have a low-level escape hatch that mimics a non-local jump. setjmp saves the current point, and longjmp jumps back to it from anywhere, which some libraries use to simulate exceptions:

#include <setjmp.h>

jmp_buf env;

void deep(void) {
    longjmp(env, 1);   // jump back to where setjmp was called
}

int main(void) {
    if (setjmp(env) == 0) {
        deep();
    } else {
        printf("recovered\n");
    }
    return 0;
}

Reach for it only when you understand it fully: longjmp skips stack cleanup, so any local automatic variables and unfinished cleanup in the frames it skips are lost, and resources leak. It is powerful and sharp; most code should not use it.

Cleaning up: the goto idiom

Because you must free and close things by hand, code that grows progressively and then fails leaves a trail of resources to release. The idiomatic C solution is a single cleanup path at the bottom and goto to reach it:

int process(const char *path) {
    int result = -1;
    FILE *f = NULL;
    char *buffer = NULL;

    f = fopen(path, "r");
    if (f == NULL) {
        goto cleanup;
    }

    buffer = malloc(1024);
    if (buffer == NULL) {
        goto cleanup;
    }

    // ... read and process ...

    result = 0;

cleanup:
    free(buffer);
    if (f != NULL) {
        fclose(f);
    }
    return result;
}

Each failure jumps to the one place that releases everything; free(NULL) and skipping the close when f is NULL are both safe, so the cleanup path needs no error tracking of its own. This backward goto is one of the few uses the C community universally approves.

Defensive programming

The mindset matters more than any single function: assume input is hostile, assume calls can fail, and handle the first error at the point it happens. Validate arguments at the top of a function, check every allocation, close every file, and never ignore a return value. Compile with -Wall -Wextra and fix warnings, because the compiler catches a surprising number of error-handling mistakes, such as a return value that is discarded.

The big picture

C turns error handling into explicit control flow. Functions return status codes or NULL; errno/perror/strerror explain system failures; assert catches programmer bugs while exit handles the unrecoverable; setjmp/longjmp exist but are rarely the right tool; and a shared cleanup: path with goto keeps resources from leaking on failure. Every one of these choices can be wrong, which is exactly why the next post exists: testing, so you find the failures before your users do.

[^1]: C error handling - Wikipedia

Pointers in C

Sat, 10 Oct 2026 00:00:00 GMT

Throughout the series a variable was described as "a named box in memory". A pointer is the C feature that deals with those boxes directly: it is a variable that stores the address of another variable. Pointers are why you can write scanf("%d", &age) and why arrays seem to turn into pointers when passed to functions. They are also, honestly, the hardest mental step in C, and that is mostly because programmers are not told what they are for. This post takes it slowly: what an address is, what pointers do, and the two places they earn their keep (changing caller variables, and dynamic memory).

Addresses

Every variable lives at a memory address, like a house on a street. The address is just a number. The & operator (address-of) gives you a variable's address:

int x = 42;
printf("%p\n", (void *)&x);   // prints something like 0x7ffee4a3b8c0

%p is the format specifier for an address. The address is not random: it is where x sits in memory, decided by the system at runtime. Notice the &x in scanf: that is why scanf("%d", &age) works. The function must write to your age box, so you hand it the box's address instead of a copy of its value.

Declaring and using pointers

A pointer variable is declared with * after the base type; it declares that the variable holds an address of something of that type:

int x = 42;
int *p = &x;    // p holds the address of x

Read int *p as "p is a pointer to an int". The address is stored, but to reach the value through the address you dereference with *:

printf("%d\n", *p);   // 42: the int that p points to
*p = 99;              // writes THROUGH p, changing x
printf("%d\n", x);    // 99

Spelling matters: in a declaration, int *p declares a pointer; in an expression, *p means "the thing p points to". The & and * are inverse operations: & produces an address from a variable, * produces the variable from an address, and applying one after the other gets you back where you started.

NULL: the empty pointer

Every pointer should either point at something real or at the special value NULL. Dereferencing NULL crashes your program, so check before use:

int *p = NULL;
if (p != NULL) {
    printf("%d\n", *p);   // only runs if p is real
}

NULL exists so pointers can say "nothing here" instead of holding a garbage address. The check p != NULL (or the shorthand if (p) when treating presence as truth) is the single most common defensive pattern in C, and it is where the error-handling post takes over later.

Pointers as function parameters

Recall from the functions post that C is pass-by-value: a function gets a copy and cannot change the caller's variable. Pass a pointer and it can, because a copy of an address still names the original box:

void swap(int *a, int *b) {
    int tmp = *a;
    *a = *b;
    *b = tmp;
}

int main(void) {
    int x = 1, y = 2;
    swap(&x, &y);
    printf("%d %d\n", x, y);   // 2 1
    return 0;
}

swap never touches x and y by name; it writes through their addresses. Any function that must return a modified argument uses this pattern. It is the same reason scanf("%d", &age) asks for the address: it needs to write into your variable, not into a copy.

Pointers and arrays

C arrays and pointers are close relatives. The name of an array, used in an expression, is a pointer to its first element:

int scores[] = {92, 85, 88};
int *p = scores;        // p points to scores[0]
printf("%d\n", *p);     // 92

That is why the arrays post warned that passing an array to a function passes a pointer, and why sizeof inside the function fails: the compiler only sees a pointer there. Array indexing is defined in terms of pointers: scores[i] is just syntax for "the element at address scores + i".

Pointer arithmetic

Adding an integer to a pointer moves by whole elements, not bytes. p + 1 points to the next element of the array:

printf("%d\n", *(p + 1));   // 85
printf("%d\n", p[1]);       // same thing: 85

p[k] and *(p + k) are interchangeable. This is the whole secret behind array indexing, and it means you can walk an array with a pointer:

int total = 0;
int *p = scores;
for (int i = 0; i < 3; i++) {
    total += *p;   // read current element
    p++;           // move to the next one
}

Strings rely on the same idea: strlen is just "count characters while the current byte is not '\0'". A char * pointing into a string and stepping one byte at a time until zero is the loop behind every string function.

Pointers to structs

The structs post showed ->, and now it makes sense. If s is a pointer to a struct, s->field is (*s).field; both dereference and pick the field:

typedef struct { int x; int y; } Point;

void move(Point *p, int dx, int dy) {
    p->x += dx;
    p->y += dy;
}

int main(void) {
    Point p = {1, 1};
    move(&p, 3, 2);
    printf("(%d, %d)\n", p.x, p.y);   // (4, 3)
    return 0;
}

Pointer to pointer and const pointers

Pointers are variables, so they too have addresses, producing a pointer to a pointer: int ** ("pointer to pointer to int"). You rarely need one early on, but you will meet it when a function must return a pointer through a parameter, like the allocator functions below.

const in front of a pointer means "the data it points at cannot change through this pointer":

void print(const int *p) {
    // *p = 1;   // error: read-only
    printf("%d\n", *p);
}

Putting const after the star means the pointer itself cannot be reassigned: int *const p. The first form, const int *, is the common one for function parameters, and it is how the string helpers say "I will read this, never modify it". The string literals you pass have type const char *, which is why printf("...", ...) and friends expect const char * parameters.

Function pointers

Because functions live in memory too, you can store a pointer to a function and call through it. The syntax is ugly and worth learning by pattern, not by heart:

int add(int a, int b) { return a + b; }
int mul(int a, int b) { return a * b; }

int apply(int (*op)(int, int), int a, int b) {
    return op(a, b);
}

int main(void) {
    printf("%d\n", apply(add, 3, 4));   // 7
    printf("%d\n", apply(mul, 3, 4));   // 12
    return 0;
}

int (*op)(int, int) declares op: a pointer to a function taking two ints and returning an int. Passing a function selected at runtime is how you write callbacks and tables of operations. If you see typedef int (*Operation)(int, int); in real code, it is this idea given a readable name.

Dynamic memory

Everything so far lived on the stack, sized at compile time. Real programs need memory whose size is only known at runtime, or that outlives the current function. That memory comes from the heap, and C hands it out with malloc:

int *p = malloc(10 * sizeof(int));   // 10 ints, on the heap
if (p == NULL) {
    // the request failed; handle it
}
for (int i = 0; i < 10; i++) {
    p[i] = i * i;
}
free(p);   // give the memory back

The three function names to know, all from <stdlib.h>:

malloc(n) - returns a pointer to n bytes of uninitialized memory.
calloc(count, size) - like malloc but zero-initialized, and takes count and element size separately.
realloc(p, newSize) - grows or shrinks a previously allocated block, moving it if needed.
free(p) - returns the block to the system.

malloc returns void *, a pointer with no element type; C converts it to your pointer type automatically, so in C you do not need to cast the result. Always multiply by sizeof, because malloc counts bytes and int is not 1 byte.

The rules that keep memory sane

Dynamic memory has no garbage collector, so you are responsible for every byte:

Check the result. malloc returns NULL when out of memory. Treat p == NULL as the error check above.
Free exactly what you allocated, once. A memory leak is memory you allocated and never freed; the program slowly eats RAM. A double free is calling free(p) twice, which corrupts the allocator's bookkeeping. A use-after-free is reading *p after free(p); the bytes may be reused for something else. Leaks, double frees, and use-after-free are the classic C bugs, and the error-handling and testing posts will show how to catch them.
Never use freed memory. A pointer that was freed and then used is called a dangling pointer[^1]:

char *p = malloc(16);
free(p);
strcpy(p, "boom");   // use-after-free: undefined behavior

A useful discipline: set a freed pointer to NULL so a later accidental dereference crashes loudly in debuggers instead of silently corrupting data:

free(p);
p = NULL;

Lifetime, in one rule

Stack memory belongs to the function that declared it and vanishes when it returns. Heap memory belongs to you until free. If a function must return data that survives the call, the memory must be heap-allocated (or a pointer to something the caller owns). The stack vs heap distinction is reasoned about concretely in the Computers Explained series; here the practical rule is: stack sizes are known at compile time, heap sizes can be decided at runtime, and every heap byte must be freed exactly once.

The big picture

A pointer is a variable holding an address. & produces addresses, * dereferences them, NULL marks "points at nothing", p[k] and *(p+k) are the same thing, passing pointers lets functions modify caller variables and avoid copying big structs, const tames what a pointer may change, and function pointers store whole functions in variables. malloc/free at the end bring the heap into play, with the lifetime rules that keep memory safe. Pointers connect everything in C, and every later post in this series builds on them. With pointers mastered, the next stop is what happens when all of this goes wrong: error handling.

[^1]: Dangling pointer - Wikipedia

Structs, Unions, and Enums in C

Fri, 09 Oct 2026 00:00:00 GMT

Arrays hold many values of one type. This post covers the other three built-in structures the language gives you: structs[^1] group values of different types under one name, unions[^2] let different types share the same memory, and enums[^3] give readable names to integers.

Structs

A struct is a group of named fields, possibly of different types, stored back to back in memory. Define the shape once, then make variables of that shape:

struct Student {
    char name[50];
    int age;
    double grade;
};

That defines a type. Now declare variables of it, with struct Student spelling out the full type name:

struct Student s1;

s1.age = 20;
s1.grade = 8.5;
strncpy(s1.name, "Ada", 49);

Each field is set and read with a dot:

printf("%s is %d years old.\n", s1.name, s1.age);

You can initialize a struct at declaration with brace syntax, filling fields in order:

struct Student s2 = {"Grace", 22, 9.0};

typedef: giving the type a short name

Writing struct Student everywhere is verbose. typedef creates an alias, so a single word names the type:

typedef struct {
    char name[50];
    int age;
    double grade;
} Student;

Student s1 = {"Ada", 20, 8.5};

Now Student is a complete type name. Reading other people's C, you will see both styles; typedef is the convention for avoiding repetition.

Arrays of structs

A struct is a type like any other, so Student students[3] is an array of students:

Student students[] = {
    {"Ada", 20, 8.5},
    {"Grace", 22, 9.0},
    {"Alan", 21, 7.5},
};

double total = 0;
for (int i = 0; i < 3; i++) {
    total += students[i].grade;
}
printf("average: %.2f\n", total / 3);

Access follows the rule you already know: students[i] is a Student, and .grade picks its field. Combining arrays and structs is how you model real collections of related data.

Nested structs

A struct can contain other structs:

typedef struct {
    int day;
    int month;
    int year;
} Date;

typedef struct {
    char name[50];
    Date birth;
} Person;

Person p = {"Ada", {10, 12, 1815}};
printf("%d\n", p.birth.year);   // 1815

Chains of dots peel off one level at a time.

Passing structs to functions

A struct passed to a function is passed by value, exactly like an int: the function gets a full copy, and changes stay inside. For a small struct that is cheap and fine; for a big one the copy costs time and memory:

void celebrate(Student s) {
    s.age++;            // only the copy changes
    printf("Happy birthday, %s!\n", s.name);
}

When the struct is large, or the function must modify the original, C uses pointers instead. The arrow operator -> is just a dot through a pointer, and passed dereferencing by hand is a shortcut. The full explanation is the next post's job; here is the shape you will see all over real C:

void grantBonus(Student *s) {
    s->grade = 10.0;    // modifies the original
}

-> means "the field of the struct this pointer points to". If s is a pointer, s->grade equals (*s).grade.

Unions

A union declares several fields that all share the same memory. Only one field is meaningful at a time, because writing any of them overwrites the others. Its size is the size of its largest member:

union Value {
    int    i;
    double d;
    char   c;
};

union Value v;
v.d = 3.14;   // writing the double
printf("%f\n", v.d);
v.i = 7;      // now the int; the double is gone
printf("%d\n", v.i);

Unions exist to squeeze memory when only one interpretation applies at a time, and to reinterpret bytes, which is what reading raw hardware or network data asks for. They are usually paired with a separate field or enum that records which member is active, a pattern sometimes called a "tagged union". Use them deliberately; a union used by accident is a source of subtle bugs.

Padding and alignment

A struct's size is not simply the sum of its fields. The compiler inserts padding after some fields so that each one lands on a memory address the CPU reads efficiently, a property called alignment[^4]. In practice for this series: an int usually must sit on a 4-byte boundary, a double on an 8-byte one, so fields can be spaced out:

printf("%zu\n", sizeof(Student));   // usually bigger than 50 + 4 + 8

Getting the exact padding rules right matters only for binary file formats and networking, where a struct's layout gets written to disk or the wire; for everything else, trust sizeof.

Enums

An enum names a set of integer constants. It exists so your code reads as words, not magic numbers:

enum Color { RED, GREEN, BLUE };

By default RED is 0, GREEN is 1, BLUE is 2. You assign explicit values if the numbers matter:

enum Color { RED = 1, GREEN = 2, BLUE = 3 };
enum Color c = GREEN;

Print it as the underlying integer:

printf("%d\n", c);   // 2

You have already used enums indirectly: switch cases prefer them, and they are the idiomatic way to represent a small set of options like states or error codes. A function that returns a status often typedefs an enum so callers can test readable names instead of bare numbers:

typedef enum { OK = 0, TOO_SMALL, TOO_BIG } Status;

That pattern leads directly into error handling later in the series.

The big picture

struct bundles different types into one meaningful record, union lets several types share one block of memory, and enum turns integers into readable names. Combined with arrays they model real data: a list of students, a grid of points, a packet of fields. Structs also mark the moment where "copy the value" and "point to the original" diverge, which is exactly where the next post lives: pointers, the subject C is most famous and most feared for.

[^1]: Struct (C programming language) - Wikipedia

[^2]: Union type - Wikipedia

[^3]: Enumerated type - Wikipedia

[^4]: Data structure alignment - Wikipedia

Arrays and Strings in C

Thu, 08 Oct 2026 00:00:00 GMT

So far every variable held exactly one value. Real programs deal in lists: grades, names, coordinates. C's built-in structures for a sequence of the same type are arrays, and a string is just an array of characters. This is the first of two posts on the data structures the language gives you ready-made; structs, unions, and enums are the second.

Arrays

An array is a contiguous run of values of one type, each with an index. Declare it with the element type, the name, and the size in square brackets:

int scores[5];          // 5 ints, indices 0..4

Indexing starts at zero, so the first element is scores[0] and the last is scores[4]:

scores[0] = 92;
scores[1] = 85;
scores[2] = 88;
printf("%d\n", scores[2]);   // 88

You usually initialize at declaration and skip the size, letting the compiler count:

int scores[] = {92, 85, 88, 70, 91};

The size is the number of elements, not the byte size. sizeof(scores) gives total bytes; divide by the element size to get the count:

int n = sizeof(scores) / sizeof(scores[0]);   // 5

Iterating

The for loop from the loops post is the standard companion; index variables and arrays were made for each other:

int total = 0;
for (int i = 0; i < 5; i++) {
    total += scores[i];
}
printf("average: %d\n", total / 5);

A common beginner error is looping one too far and reading past the last element. That is legal to write but undefined behavior: C does not check array bounds. scores[5] is a memory error, not an exception. There are no error messages, just garbage values or a crash, and compilers warn about obvious cases only with extra flags. The array size is your responsibility, so the sizeof-based count above is worth keeping in a variable.

Multidimensional arrays

An array of arrays is written with two sizes. int grid[3][4] means "3 rows, 4 columns":

int grid[3][4] = {
    {1, 2, 3, 4},
    {5, 6, 7, 8},
    {9, 1, 2, 3},
};
printf("%d\n", grid[1][2]);   // row 1, column 2 -> 7

The nested loops from the loops post walk rows and columns. Underneath it is still one contiguous block of memory, laid out row by row.

Strings

A string in C has no type of its own. It is a char array whose characters end with a null terminator: the byte '\0' (value zero). Every string function reads until it finds that byte, so the rule is: the buffer holds the visible characters plus one for '\0'.

char name[] = "Ada";   // actually 4 chars: 'A','d','a','\0'

sizeof(name) is 4, even though "Ada" has three letters. A string literal like "hello" is stored by the compiler as h e l l o \0. When you declare an array large enough, you can copy a string into it:

char buffer[32];
printf("What is your name? ");
fgets(buffer, sizeof(buffer), stdin);
printf("Hello, %s\n", buffer);

fgets(buffer, size, stdin) reads a line and respects the buffer size, stopping at the newline or filling the buffer and always null-terminating. Prefer it over scanf("%s", ...), which reads without a size limit and overflows any buffer you hand it. fgets leaves the trailing newline in the buffer, so you will often strip it:

buffer[strcspn(buffer, "\n")] = '\0';

strcspn (from string.h) returns the index of the first newline, and this line replaces it with the terminator.

The string.h toolbox

The <string.h> header provides the string functions. The ones to know first, with their footguns:

strlen(s) - returns the number of characters up to \0 (the "length", not counting the terminator).
strcpy(dst, src) - copies src into dst, no size check: classic overflow source. Prefer the bounded strncpy(dst, src, size) (and remember to ensure dst ends in '\0' yourself) or snprintf.
strcat(dst, src) - appends src to dst; same overflow risk. Build with snprintf instead when safety matters.
strcmp(a, b) - compares and returns 0 if equal, negative/positive by order. Use == on strings and you are comparing addresses, not text (an easy trap; addresses become first-class in the pointers post).
strchr(s, c) - finds the first occurrence of a character, returning a pointer or NULL.

#include <string.h>

char combined[64];
snprintf(combined, sizeof(combined), "%s-%s", "Ada", "Lovelace");
printf("%s\n", combined);            // Ada-Lovelace
printf("len: %zu\n", strlen(combined));   // 12

snprintf(dst, size, format, ...) is the safe workhorse: it writes at most size characters including the terminator. Prefer it anytime you build text.

The array-to-parameter surprise

When you pass an array to a function, it does not arrive as a copy. Arrays are passed as a pointer to their first element, and inside the function sizeof no longer gives the array size. Functions that take an array therefore also take its length:

int sum(int arr[], int n) {
    int total = 0;
    for (int i = 0; i < n; i++) {
        total += arr[i];
    }
    return total;
}

int main(void) {
    int scores[] = {92, 85, 88};
    printf("%d\n", sum(scores, 3));   // 265
    return 0;
}

The full story behind "arrays decay to pointers" is one of the main events of the pointers post. For now, remember the two rules stated above: pass the length, and do not trust sizeof on a parameter.

The big picture

Arrays are contiguous runs of one type, indexed from zero, sized by you, with no bounds checking. Strings are char arrays terminated by '\0', and every string function follows that contract. fgets and snprintf read and build text safely; strlen, strcmp, and friends do the rest; and when an array crosses into a function it becomes a pointer to its first element. That pointer connection is where the next two posts go: structs and enums first, then pointers themselves.

Functions in C

Wed, 07 Oct 2026 00:00:00 GMT

A function is a named block of code you can call from anywhere else. It takes inputs, returns an output, and lets you write a piece of logic once and reuse it. main is itself a function, so you have been writing functions since the first post; this one teaches the full picture.

Anatomy of a function

A function definition has a return type, a name, a parameter list in parentheses, and a body in braces:

int add(int a, int b) {
    return a + b;
}

Read it as: "function add takes two ints, returns an int, and its body returns their sum." To use it, call it with matching arguments:

int result = add(3, 4);   // result is 7

The pieces, in order:

int - the type of the value returned. A function that returns nothing uses void.
add - the identifier.
(int a, int b) - parameters: the inputs, each a type plus a name. A function with no inputs writes void inside: int main(void).
{ return a + b; } - the body, with return sending a value back to the caller.
The caller's values are arguments; the function's names for them are parameters. The two often use different names; only positions matter.

Prototypes: declaring before using

In C you cannot call a function before the compiler has seen its definition, because the compiler needs to know its signature to type-check the call. If add is defined after main, this fails:

int main(void) {
    int r = add(3, 4);    // error: 'add' was not declared
    return 0;
}

int add(int a, int b) {
    return a + b;
}

The fix is a prototype (also called forward declaration): the signature with a ; instead of a body, placed before the call. Real programs put these in header files, but for now, top of the file works:

int add(int a, int b);    // prototype

int main(void) {
    int r = add(3, 4);
    return 0;
}

int add(int a, int b) {   // definition
    return a + b;
}

In a strict C99 project the function must be declared before every use, which is why headers exist: the prototype lives in a .h file shared by every .c file that calls the function.

Pass by value

C passes arguments by value: the parameter is a copy of the argument. Changes inside the function never touch the caller's variable:

void change(int x) {
    x = 99;
}

int main(void) {
    int n = 5;
    change(n);
    printf("%d\n", n);   // still 5
    return 0;
}

This is the single most important rule about functions in C, and it explains why the next post's arrays and the pointers post's & operator are indispensable: to let a function modify a caller's variable, you must pass a pointer to it, because a copy of an address still names the original.

return and void

return exits the function and hands back a value of the declared return type:

double average(double a, double b) {
    return (a + b) / 2.0;
}

Ending the function without a return when the type is not void is undefined behavior in most cases; the compiler may help you catch it only sometimes. void functions return no value; use a bare return; to leave early, or none at all:

void greet(const char *name) {
    if (name == NULL) {   // guard clause
        return;
    }
    printf("Hello, %s\n", name);
}

Scope and lifetime

Where a variable exists is its scope, and how long it survives is its lifetime. The blocks from the syntax post are the boundaries:

A variable declared inside a function is local: visible only inside its block, and destroyed when the block ends.
The parameters are local to the function body.
A variable declared outside any function is global: visible everywhere after its declaration, and alive for the whole program.
A block {} can open its own scope for a temporary variable.

int global = 10;                 // global, lives forever

void f(void) {
    int local = 5;               // local to f
    {
        int temp = local + 1;    // block scope: only inside these braces
    }
    // temp does not exist here
}

Prefer local variables. Globals make functions hard to reason about, because any part of the program can change them.

Storage classes

Four keywords control storage class: where a variable lives and how long it lasts.

auto - the default for locals; you practically never write it.
register - a hint to keep the value in a CPU register; the compiler largely ignores it today.
static - on a local: the variable keeps its value between calls (and is initialized only once). On a global or function: it becomes visible only within its own file, hiding it from other files.
extern - declares that the variable or function is defined in another file, letting you use it across files.

The static local is the useful one:

int nextId(void) {
    static int id = 1000;   // keeps its value across calls
    return id++;
}

Each call returns 1000, then 1001, and so on, because the variable survives between calls even though it is local. const (from the syntax post) is not a storage class but is often grouped with these: it marks a value read-only.

Recursion

A function can call itself; that is recursion[^1]. Its natural home is problems that break into smaller versions of themselves. The classic is factorial: n! = n * (n - 1)!, with 0! = 1:

int factorial(int n) {
    if (n <= 1) {
        return 1;
    }
    return n * factorial(n - 1);
}

factorial(4)
  -> 4 * factorial(3)
    -> 3 * factorial(2)
      -> 2 * factorial(1)
        -> 1

Every recursive function needs a base case (the n <= 1 branch) that stops the chain; without it, the calls never end and the program crashes with a stack overflow (the recursion story connects to the pointers/memory post later). Compared to loops, recursion shines on nested data like trees; use a loop for plain counting.

The big picture

A function is a named, reusable block: a return type, parameters passed by value, a body, and return to send results back. Prototypes let later definitions be called earlier; void means "returns nothing"; scope rules decide what each name means; storage classes tune lifetime and visibility; and recursion handles problems that fold into themselves. Functions combine with conditionals and loops to express any logic, and the next post applies them to the first built-in data structure: arrays and strings.

[^1]: Recursion (computer science) - Wikipedia

Loops in C

Tue, 06 Oct 2026 00:00:00 GMT

A loop runs the same block of code repeatedly, as long as a condition stays true. It is the feature that makes programs useful, because most real work is repeating an operation a certain number of times or until a goal is reached. C has three loops: while, do/while, and for. All three run a block; they differ only in when the condition is checked.

while

The while loop checks its condition before each run. If the condition is false at the start, the body never runs:

int n = 3;
while (n > 0) {
    printf("%d\n", n);
    n = n - 1;
}

3
2
1

The same truthiness rule from conditionals applies: any non-zero value loops, zero stops.

The infinite loop and how to escape

If the condition never becomes false, the loop never ends. That is the infinite loop. Sometimes it is intentional and broken with break; usually it is a bug. The most common causes: forgetting to update the counter, and comparing with = instead of ==.

int n = 3;
while (n > 0) {   // bug: n never changes
    printf("%d\n", n);
}

This prints 3 forever and never terminates. If your program hangs, look for a loop whose condition never flips. break exits the innermost loop immediately; continue skips straight to the next condition check:

int i = 0;
while (1) {              // intentional infinite loop
    i++;
    if (i == 3) continue;   // skip printing 3
    if (i > 5) break;       // leave the loop at 6
    printf("%d\n", i);
}

A while (1) or for (;;) loop paired with break is the standard way to write "loop forever until something special happens", common when reading input until the end is reached.

do / while

The do/while loop runs the body first and checks the condition after. It always executes at least once:

int n = 0;
do {
    printf("n = %d\n", n);
    n++;
} while (n < 3);

n = 0
n = 1
n = 2

The body runs with n = 0, then tests 0 < 3, runs again, and stops when n is 3. Use do/while when the body must run once before any condition makes sense, like asking for input at least once, or processing one menu choice before checking whether to continue. Note the ; after the while (n < 3) line; a do/while is the one loop that ends with a semicolon.

for

The for loop packs counting into one line: an initialization, a condition, and an update, separated by semicolons:

for (int i = 0; i < 5; i++) {
    printf("%d\n", i);
}

Reading order matters: int i = 0 runs once before the loop; the condition i < 5 is checked before each run, like a while; i++ runs at the end of each iteration before the next check. The same loop in while form shows the relationship:

int i = 0;
while (i < 5) {
    printf("%d\n", i);
    i++;
}

Use for when you know the number of iterations, because the count is visible in one line: start, stop, step. It is the natural tool for iterating over arrays, which the arrays post will use constantly.

The three parts are individually optional. for (;;) is an infinite loop. You can declare the counter inside the heading (int i = 0), in which case it only exists inside the loop, or declare it before and let the loop update it:

int i;
for (i = 0; i < 10; i++) {
    // ...
}
// i is still usable here, holding 10

Count down and step by more than one

The update step is any expression, so the loop is flexible:

for (int i = 10; i > 0; i--) { ... }     // 10, 9, ..., 1
for (int i = 0; i < 10; i += 2) { ... }  // 0, 2, 4, 6, 8

Nested loops

A loop body can contain another loop. Nested loops run "all of the inner loop for each step of the outer loop":

for (int row = 1; row <= 3; row++) {
    for (int col = 1; col <= 3; col++) {
        printf("%d%d ", row, col);
    }
    printf("\n");
}

11 12 13
21 22 23
31 32 33

The inner loop completes fully before the outer loop advances. This is the shape you will use later to walk rows and columns of matrices.

Accumulating a result

A loop plus a variable that changes each iteration is the workhorse of programming. The accumulator starts at a neutral value and absorbs each iteration:

int total = 0;
for (int i = 1; i <= 10; i++) {
    total += i;
}
printf("sum of 1..10 = %d\n", total);   // 55

Zero for sums, one for products. Counters, sums, and best-so-far values all follow this pattern.

The big picture

while checks before running, do/while checks after running, and for collects the count into one heading for the common "start at A, go to B, step by C" case. break leaves a loop early, continue skips one iteration, and infinite loops are either intentional (with break) or a bug from a condition that never flips. With conditionals and loops you can now control any program; the next post packages code into reusable units: functions.

Conditionals in C

Mon, 05 Oct 2026 00:00:00 GMT

Up to now every statement in a program ran in order, top to bottom. Real programs need branches: run this code only if something is true. That is what conditionals do. This post covers if/else, the else if chain, switch, and the truthiness rule that underpins all of them.

Truthiness in C

A condition is any expression whose value decides the branch. C does not require a real boolean here: any non-zero value is true, and zero is false. That means comparisons, which produce 1 or 0, work naturally, and so do plain numbers:

if (5) { ... }      // always true
if (0) { ... }      // never true
if (-1) { ... }     // true! (-1 is non-zero)

This rule is everywhere in C: in if, while, for, and even in return values. A function that returns 0 for "all good" is describing failure, because in C zero means false.

if / else

The if statement runs its block when the condition is true. An optional else runs when it is not:

int temperature = 35;

if (temperature > 30) {
    printf("It is hot.\n");
}

int score = 55;

if (score >= 60) {
    printf("Passed.\n");
} else {
    printf("Did not pass.\n");
}

For a single statement, the braces are optional:

if (score >= 60)
    printf("Passed.\n");

But always use braces anyway; adding one line later without braces silently changes the logic. Braces are how you say "this whole block belongs to the branch".

else if: multiple options

Chain as many alternatives as you need:

int grade = 85;

if (grade >= 90) {
    printf("A\n");
} else if (grade >= 80) {
    printf("B\n");
} else if (grade >= 70) {
    printf("C\n");
} else {
    printf("Below C\n");
}

Only one branch runs: C tests each condition in order and stops at the first true one. The final else runs if none matched; it is optional.

Guard clauses are the other common pattern: check for the bad cases first and return early, leaving the main logic un-nested:

if (items <= 0) {
    return 0;
}
// ... main logic ...

Nested conditionals

An if can contain another if. Nesting is sometimes unavoidable, but deep nesting is hard to read. Prefer early returns and combining conditions:

if (age >= 18) {
    if (hasID) {
        printf("Welcome in.\n");
    }
}

The same logic reads better as:

if (age >= 18 && hasID) {
    printf("Welcome in.\n");
}

The dangling else

When you write else after nested ifs without braces, the else binds to the nearest unmatched if. That is the "dangling else" rule, and it trips everyone at least once:

if (a)
    if (b)
        printf("both\n");
else
    printf("a only\n");   // misleading: this else belongs to the inner if

Braces fix it. This is a general rule of the language: never be clever with optional braces.

switch: choosing from a list

When you compare one integer value against many possible constants, switch is cleaner than a long else if chain:

int day = 3;

switch (day) {
    case 1:
        printf("Monday\n");
        break;
    case 2:
        printf("Tuesday\n");
        break;
    case 3:
        printf("Wednesday\n");
        break;
    default:
        printf("Unknown day\n");
}

How it works: the expression selects a matching case, and execution starts there. The break is what stops execution from continuing into the next case. If you forget it, execution falls through to the next case, which is usually a bug but occasionally useful for sharing code between cases:

switch (month) {
    case 4:
    case 6:
    case 9:
    case 11:
        printf("30 days\n");
        break;
    case 2:
        printf("28 or 29 days\n");
        break;
    default:
        printf("31 days\n");
}

The default case catches anything unmatched, like else. switch works with int, char, and enum values, one of the places the upcoming structs post will mention again.

The assignment trap

The operators post warned about = vs ==. Inside a condition it turns from a bug into a trap with no compiler complaint:

if (x = 5) { ... }   // assigns 5 to x, then tests if 5 is non-zero: always true!
if (x == 5) { ... }  // what you meant

Compile with -Wall and GCC warns about most of these (-Wparentheses). Some codebases write if (5 == x) to make a mistaken = a compile error, because you cannot assign to a literal. If you ever see constants on the left, that is why.

The big picture

if/else branches on a condition, else if chains alternatives, switch picks from a list of constants, and the truthiness rule (zero is false, everything else is true) connects it all to the operators from the previous post. Braces keep branches honest, and break keeps switch cases separate. Now that the program can decide, the next step is repeating: loops.

Operators in C

Sun, 04 Oct 2026 00:00:00 GMT

An operator is a symbol that computes a new value from one or more values. C has a small set of them, and once you know them you can express almost any calculation. This post goes through them group by group. The conditionals and loops that use these comparisons have their own posts, so they are not repeated here.

Arithmetic operators

The five basic ones should look familiar from math:

int sum  = 10 + 5;    // 15  addition
int diff = 10 - 5;    // 5   subtraction
int prod = 10 * 5;    // 50  multiplication
int quot = 10 / 3;    // 3   division (integers cut the fraction)
int rem  = 10 % 3;    // 1   remainder (modulo)

Remember from the data types post: / on two integers is integer division and % needs integers. If at least one operand is a decimal, / does floating-point division.

Assignment operators

The plain = assigns a value. C also provides compound operators that combine assignment with arithmetic. a += 5 means "add 5 to a":

int a = 10;
a += 5;   // a is 15
a -= 3;   // a is 12
a *= 2;   // a is 24
a /= 4;   // a is 6
a %= 4;   // a is 2

There are matching versions for every binary operator, including the bitwise ones below. Read a += 5 as shorthand for a = a + 5; the value is stored back into the same variable.

Increment and decrement

++ adds one, -- subtracts one. Where you put it matters:

int x = 5;
x++;          // x is now 6 (post-increment: returns old value)
++x;          // x is now 7 (pre-increment: returns new value)

int x = 5;
int a = x++;  // a = 5, x = 6
int b = ++x;  // x = 7, b = 7

x++ gives you the value before the increment; ++x gives the value after. When the result is not used (a standalone x++; line) the two are identical. C programmers use them heavily in loops.

Relational (comparison) operators

These compare two values and produce 1 (true) or 0 (false):

10 > 5    // 1  greater than
10 < 5    // 0  less than
10 >= 5   // 1  greater or equal
10 <= 5   // 0  less or equal
10 == 5   // 0  equal (two equals signs!)
10 != 5   // 1  not equal

The classic beginner bug is writing = when you mean ==. = assigns and == compares, and the compiler may not catch the mix-up in an if. If you wonder why C lets you put an assignment inside a condition, you are not alone; that is one of the language's darker corners, covered in the conditionals post.

Logical operators

These combine true/false values:

flag1 && flag2   // AND: 1 only if both are true
flag1 || flag2   // OR:  1 if at least one is true
!flag            // NOT: flips the value

int age = 25;
age >= 18 && age <= 65   // 1: adult and of working age
age < 18 || age > 65     // 0: neither child nor senior

&& and || are short-circuit: C evaluates the left side first and only evaluates the right side if needed. With &&, if the left is false the right is never evaluated; with ||, if the left is true the right is skipped. That is safe for the common guard pattern like ptr != NULL && *ptr == 5, which would crash if evaluated left-to-right without short-circuiting.

Bitwise operators

These work on the individual bits of the value. You rarely need them in application code, but they are what make C the language of low-level programming:

~a     // NOT: flips every bit
a & b  // AND: 1 only where both bits are 1
a | b  // OR:  1 where at least one bit is 1
a ^ b  // XOR: 1 where the bits differ
a << n // shift all bits left by n (like multiplying by 2^n)
a >> n // shift all bits right by n (like dividing by 2^n)

int flags = 0b00001100;       // 12
flags = flags << 1;           // 0b00011000 (24)
int masked = 12 & 0b00001010; // 0b00001000 (8)

Common uses: packing flags into a single byte, reading hardware registers, and fast multiply/divide by powers of two.

The conditional (ternary) operator

C has one three-part operator, a compact if/else that evaluates to a value:

int max = (a > b) ? a : b;

Read it as "if the condition is true, take the first value, otherwise the second." It is just a shortcut; anything you write with it can be written with a full if/else, which you will meet in the next post.

The comma operator and sizeof

The comma operator evaluates several expressions in order and keeps the last value, usually inside for loops to update multiple variables:

int i, j;
for (i = 0, j = 10; i < j; i++, j--) {
    // ...
}

sizeof is technically an operator, not a function: it returns the size in bytes of a type or value:

printf("%zu\n", sizeof(int));   // most often 4
printf("%zu\n", sizeof(3.14));  // 8, because the literal is a double

Precedence and associativity

When an expression mixes operators, C needs a rule to know what binds tighter. That rule is operator precedence[^1]: high-precedence operators group before low-precedence ones. 2 + 3 * 4 is 2 + (3 * 4) = 14, not 20, because * binds tighter than +.

The practical guidance is short: you cannot reliably memorize the full table, and neither can most working C programmers. Write parentheses to say what you mean:

int x = (a + b) * c;     // clear
int y = a + b * c;       // correct, but you have to think about it

When operands of the same precedence appear together, order is decided by associativity (left-to-right for arithmetic). The one surprising case is assignment, which is right-to-left: a = b = 5 assigns 5 to b and then to a.

Two more notes worth engraving. Integer division and remainder follow their own rules covered in the data types post. And dangerous-looking expressions like x++ + x++ are undefined behavior: C does not promise any result when you read and modify the same variable more than once in an expression, so never write them.

The big picture

Arithmetic does math, assignment stores results (with handy +=-style shorthand), relational operators produce true/false, logical operators combine them with short-circuiting, bitwise operators touch raw bits, and the ternary operator is a one-line branch. Precedence decides grouping, and parentheses are free insurance. With these, you can write any calculation; the next two posts show how to decide which calculation runs. That is conditionals.

[^1]: Operator precedence - Wikipedia

Data Types in C

Sat, 03 Oct 2026 00:00:00 GMT

A data type tells the compiler two things: how many bytes a value occupies in memory, and how those bytes should be interpreted. Because those two facts are fixed, the type also decides the range of values a variable can hold. This post covers the basic types C gives you: integers, characters, floating-point numbers, and booleans.

The basic types

C has five fundamental types:

char - one byte (usually 8 bits), used for a single character like 'A'.
int - an integer, typically 4 bytes.
float - a single-precision decimal number, 4 bytes.
double - a double-precision decimal number, 8 bytes. Prefer it over float for general math.
void - "no type". It cannot hold a value; it is used to mean "returns nothing" or "no parameters", and later for generic pointers.

char letter = 'A';
int count = 42;
float pi = 3.14f;       // the f marks a float literal
double precise = 3.14159;

Sizes and ranges

The list above says "usually" because C does not fix the sizes; it guarantees only minimum widths. On modern desktop machines, the de-facto sizes are:

type       size    range (signed)
char       1 byte  -128 to 127
int        4 bytes -2,147,483,648 to 2,147,483,647
float      4 bytes ±3.4e38 (about 7 significant digits)
double     8 bytes ±1.8e308 (about 15 significant digits)

You can ask the compiler instead of guessing, with the sizeof operator:

#include <stdio.h>

int main(void) {
    printf("int:    %zu bytes\n", sizeof(int));
    printf("double: %zu bytes\n", sizeof(double));
    return 0;
}

sizeof returns bytes, and %zu is the specifier for that kind of value.

Modifiers: signed, unsigned, short, long

You can modify the basic types:

signed accepts negatives; unsigned only zero and positives, doubling the upper range because the sign bit is freed for value.
short makes an integer smaller (usually 2 bytes); long makes it bigger (usually 8 bytes).

unsigned int score = 4294967295U;  // 0 to ~4.29 billion
short small = 32767;               // usually 2 bytes
long big = 3000000000L;            // usually 8 bytes
long long huge = 9000000000000LL;  // at least 8 bytes

A char can also be signed or unsigned, which matters when you read raw bytes. The combined rules are easy to check mentally: an unsigned 8-bit value goes 0..255, a signed 8-bit value goes -128..127.

Overflow: what happens when you go past the range

If arithmetic produces a number too big for the type, the bits wrap around. With int you get undefined behavior in C, so the program may do anything; with unsigned the result wraps deterministically like an odometer:

unsigned char x = 255;
x = x + 1;
printf("%u\n", x);   // prints 0

This is a feature on purpose for low-level code, and a footgun everywhere else. If your values could approach the edge of the range, use a wider type.

Booleans

C historically had no boolean type; any non-zero value is true and zero is false. That rule still applies everywhere in C. Since C99 there is a real _Bool, normally used through stdbool.h, which defines bool, true, and false:

#include <stdbool.h>

bool active = true;
bool done = false;

Exactly two values, and a bool printed with %d shows 1 or 0.

Converting between types

C converts types automatically in many situations, called implicit conversion. Assigning an int value into a double variable promotes it losslessly; going the other way truncates:

double d = 7;    // 7 becomes 7.0
int i = 2.99;    // becomes 2 (the fraction is dropped, not rounded)

When you mix types in arithmetic, the smaller type is promoted so both operands share a type; this is called usual arithmetic conversions[^1]. The integer types get promoted to int or unsigned int, then to the floating-point type if one operand is a float.

You can also force a conversion explicitly with a cast:

int total = 7;
int items = 2;
double average = (double)total / items;   // 3.5, not 3

Without the cast, 7 / 2 is integer division and yields 3, because both operands are int. The cast makes one operand a double, so the division becomes floating-point. This single cast fixes one of the most common beginner bugs in C.

Integer division deserves attention

For integers, / cuts off the fraction entirely (7 / 2 == 3), and % gives the remainder (7 % 2 == 1). The remainder keeps the sign of the dividend. Mixing an integer and a float promotes the integer, so 7.0 / 2 is 3.5.

The big picture

Types are the contract between your program and memory: char for single bytes, int and its modified forms for whole numbers, float/double for decimals, bool for flags, and void for "nothing". The compiler checks types at build time, so getting them right catches a huge class of bugs before your program ever runs. Next, the tools for combining these values: operators.

[^1]: Type conversion - Wikipedia

C Syntax

Fri, 02 Oct 2026 00:00:00 GMT

Syntax is the shape of the language: what you are allowed to write and where. C's syntax is tiny compared to most languages, and this post shows the pieces you will see in every file: comments, statements, blocks, variables, constants, and how to print text and read input. Conditionals and loops have their own posts later, so they are intentionally not covered here.

Comments

Comments are notes for humans; the compiler ignores them entirely. There are two forms:

// A single-line comment, from the // to the end of the line.

/*
   A multi-line comment.
   Everything between /* and */ is ignored.
*/

Use them to explain why the code does something. Code says what it does; a comment should say why.

Statements and blocks

A statement is one instruction, and it always ends with a semicolon:

int x = 5;
printf("hi\n");

A block is a group of statements wrapped in braces { ... }. Blocks group code, and they also define where variables are visible. Every main function body is a block:

int main(void) {
    int x = 5;
    printf("hi\n");
    return 0;
}

Braces always come in pairs, and semicolons end statements, not braces. Forgetting a semicolon is the most common compile error a beginner hits.

Identifiers

An identifier is a name you invent: variable names, function names. Rules are simple:

Letters, digits, and the underscore _ are allowed.
Must start with a letter or _, not a digit.
No spaces, no dashes, no punctuation.
Case matters: count, Count, and COUNT are three different names.

int studentCount = 3;   // valid
int 2ndPlace = 1;       // INVALID: starts with a digit
int total_amount = 10;  // valid

Some words are reserved by the language and cannot be used as names, like int, return, if, and while. They are the keywords of the language, and your editor will color them differently.

Variables

A variable is a named box in memory that holds a value. You must declare it before using it. A declaration states the type and the name:

int age;          // declares an int named age
double price;     // declares a double named price
int a, b, c;      // declares three ints in one line

You can give it a value at declaration time. That is called initialization:

int age = 30;
double price = 19.99;

Or assign later with the = operator. Assigning is an action, so it is a statement and needs its semicolon:

age = 31;

The rule is simple: declare before you use, initialize before you read. An uninitialized variable holds whatever garbage was already in memory, and reading it is a bug.

Constants

A constant is a value that never changes. The const keyword marks a variable as read-only after initialization:

const int maxUsers = 100;
maxUsers = 200;   // compile error: cannot assign to a const

The language also has a preprocessor directive, #define, that names a value, though const is the safer modern choice. You will see both in real code:

#define MAX 100

The preprocessor replaces every MAX in the file with 100 before the compiler runs. Note that #define lines do not end with a semicolon.

Printing and reading input

Printing uses printf, and the % symbols inside the string are replaced by the values you pass. Each %? is a format specifier describing how to print one value.

#include <stdio.h>

int main(void) {
    int age = 30;
    double grade = 9.5;
    printf("I am %d years old.\n", age);
    printf("My grade is %.2f.\n", grade);
    printf("age=%d grade=%.2f\n", age, grade);
    return 0;
}

The common specifiers: %d prints an int, %f prints a double (and %.2f prints it with two decimal places), %c prints a single char, %s prints a string, and %p prints an address (used later with pointers). The \n inside a string is an escape sequence, a way to write a character that is hard to type directly. The ones you will use constantly:

\n   newline      \t   tab
\"   double quote \\   backslash
%    percent      \0   null terminator (used with strings)

To print a literal percent sign, write %%.

Reading input uses scanf, the mirror image of printf. Give it a specifier and the address of the variable to fill in. The & operator means "the address of"; you will understand it deeply in the pointers post, but for now know that scanf("%d", &age) stores what the user typed into age:

#include <stdio.h>

int main(void) {
    int age;
    printf("How old are you? ");
    scanf("%d", &age);
    printf("You are %d years old. Good to know!\n", age);
    return 0;
}

The risky part of scanf: string input with %s does not limit length and can overflow the buffer, so prefer fgets for reading text. Numbers via %d and %f are fine for learning.

Include and define live outside the code

Lines starting with # are preprocessor directives[^1], not C statements. #include <stdio.h> copies the contents of the standard header into your file so the compiler knows the names of functions like printf. Every program that prints or reads needs that one line at the top.

The big picture

Every C file is built from the same alphabet: comments to explain, statements ended with ;, blocks wrapped in {}, names that follow simple rules, variables you declare and initialize, and printf/scanf to talk to the user. That is the grammar you will type hundreds of times. The next post fills in the kinds of values those variables can hold: the data types.

[^1]: C preprocessor - Wikipedia

Getting Started with C

Thu, 01 Oct 2026 00:00:00 GMT

C is one of the oldest programming languages still in daily use, and it has never dropped out of the top of the language rankings. It was created in the early 1970s by Dennis Ritchie[^1] to write the Unix operating system, and it remains the language used to write operating systems, embedded devices, compilers, and the core of almost every other language. If you want to know what a computer really does when your code runs, C is the shortest path there: the language is small, and almost everything it does maps directly to what the hardware can do.

This post sets you up: what you need installed, your first program, and the path your source code takes from your editor to a running executable.

What you need

C has no official IDE, no package manager, and no runtime you install. To write C you need exactly three things:

A compiler. The compiler[^2] translates your C source code into machine code the CPU can run. The two most common are gcc (GNU Compiler Collection) and clang (part of LLVM). Both are free and work on Linux, macOS, and Windows. On macOS you often get clang for free with the Command Line Tools; on Linux install gcc with your package manager; on Windows gcc comes inside MinGW, MSYS2, or WSL.
A text editor. Any editor works because a .c file is just text. VS Code, Neovim, Vim, or a plain notepad all work. There is no special project format; you just type and save.
A terminal. You will type a single command to build your program and another to run it.

That is everything. Check that your compiler exists by asking it its version:

gcc --version
# or
clang --version

If the terminal prints a version, you are ready.

Your first program

Create a file called hello.c and write this into it:

#include <stdio.h>

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

That is a complete C program. It has three parts, and you will see the same skeleton in every C program you write:

#include <stdio.h> brings in the declaration of printf, the function used to print text. stdio.h is the standard header for standard input/output.
int main(void) defines the main function, the entry point. Every C program starts here. When you run the program, the operating system calls main.
printf("Hello, world!\n"); prints the text. \n is an escape sequence meaning "new line", so the cursor moves to the next line after printing. The line ends with ;, because every statement in C ends with a semicolon.
return 0; tells the operating system the program finished successfully. A non-zero value signals an error.

The order inside main is the order of execution: print the line, then return 0.

Build and run

Open a terminal in the folder that contains hello.c and run:

gcc hello.c -o hello

Breaking that down: gcc is the compiler, hello.c is the input file, and -o hello says "put the result in a file named hello". If the code is correct, this produces no output, just a new executable file. Now run it:

./hello

The ./ says "run the file in this directory". You should see:

Hello, world!

That is the whole workflow: edit a .c file, compile it with gcc, run the executable. Every example in this series follows the same pattern.

What the compiler actually does

gcc hello.c looks like one step, but under the surface four steps happen in order[^3]:

hello.c (source)
   ↓ 1. preprocessor: handles #include and #define
   ↓ 2. compiler: C → assembly
   ↓ 3. assembler: assembly → machine code (object file)
   ↓ 4. linker: object files + libraries → hello (executable)

Preprocessing. Lines starting with # are handled first. #include <stdio.h> literally copies the contents of stdio.h into your file, so the compiler knows what printf looks like.
Compiling. The C code is translated into assembly, the human-readable form of the CPU's instructions.
Assembling. The assembly is translated into machine code and saved as an object file. In the step above the object file is temporary and deleted, but you can keep it with the -c flag (gcc -c hello.c).
Linking. Your object file is combined with pre-compiled libraries (like the code that actually knows how to talk to your terminal) into a single executable. This is the hello file you run.

You do not need to remember the details, only that source code passes through these stages and that each one can report its own error. Oh, and there is no fifth "runtime" step: the executable you build is a finished piece of machine code. The same compiler command produces it on any platform, which is why C is called portable: move the source to another machine, compile there, and it runs natively.

Compiling with warnings

Real C projects always compile with extra warnings enabled, because the compiler notices a lot of mistakes before your program runs:

gcc -Wall -Wextra hello.c -o hello

-Wall and -Wextra turn on a useful set of warnings. Treat every warning as a bug and fix it. The compiler is your first and fastest test suite.

The big picture

C is just three things to start: a compiler (gcc or clang), a text file ending in .c, and a build command (gcc file.c -o program). Your first program prints a line and returns zero. From here the series takes each piece of the language one at a time, starting with the syntax you will use in every single program you ever write.

The rest of the series uses the same commands everywhere, so this post is your reference whenever an example needs to be compiled.

[^1]: Dennis Ritchie - Wikipedia

[^2]: Compiler - Wikipedia

[^3]: Compiler - Wikipedia

What Happens When You Type google.com?

Tue, 29 Sep 2026 00:00:00 GMT

This series built a network one layer at a time: what a network is for, the seven-layer model, the real stack, signals, frames, packets, connections, HTTP, and TLS. Every post assumed the network already worked. This one stops assuming and follows a single request from the moment a key is pressed to the moment a page appears, watching all nine posts happen at once.

Step 0: the key press

You type google.com and press enter. Before a single packet moves, your browser decides four things:

What kind of request this is. No scheme typed means the browser applies its default, and for any domain it recognizes, that default is now https.
Whether it already knows the answer. If you have visited this site before, the address may be in the DNS cache and even in the TLS session store, and parts of this whole journey are skipped.
Where to look first. The browser checks its own cache, then the operating system's cache, then the hosts file, then the resolver's cache, and only then asks the network.
What to do with the response. How to render it, and which parts of the page it will need next.

This is worth pausing on: a large fraction of page loads never touch the network at all. Everything below describes the slow path, the one that happens when nothing is cached.

Step 1: a name becomes an address

Your program cannot send anything to google.com. It can only send to an address, so the first question is DNS[^1].

browser: any cached address for google.com?
   └─ no

OS resolver: hosts file? cache?
   └─ no

ask the resolver (your provider):
   ├─ cache still valid? (TTL not expired) → return 142.250.78.100
   └─ not cached → walk the hierarchy:
        root       "where does .com live?"        → the .com servers
        .com       "where does google.com live?" → the authoritative servers
        google     "ask me"                      → 142.250.78.100

Each answer in that chain comes back with a TTL, and every machine along the way caches it. When you visit the site an hour later, the answer comes from a cache in microseconds and no question is asked anywhere.

DNS answers with more than an address. It may return several, choose between IPv4 and IPv6, and record other things about the domain, like which servers handle email.

Step 2: local or remote

Your machine now holds an address. The next decision is the one from the link layer post and the network layer post: is that address on my network?

your machine: 192.168.0.15, netmask /24  → 192.168.0.0/24 is "mine"
destination:  142.250.78.100               → not in 192.168.0.0/24

→ longest match in my routing table is the default route
→ the next hop is my gateway, 192.168.0.1

The IP layer now knows a fact it could not know before: the frame leaving this machine is not addressed to the destination. It is addressed to the router, because the router is the only machine on this wire that can help.

Step 3: the local address question, again

To send that frame, your machine needs the router's MAC address, and IP addresses do not tell it. So the same question from the ARP[^2] section returns:

"who has 192.168.0.1? tell aa:bb:cc:dd:ee:ff"
   ◀── everyone on the LAN hears it (broadcast)
       the router replies, and your machine caches the answer

This is the only broadcast in the whole journey, and it never leaves your local network. From this moment on, every frame of this request is addressed to the router's MAC and carries the destination IP inside its payload.

Step 4: opening the connection

The transport layer does its handshake[^3], one round trip of three packets:

client ── SYN      seq 1000 ─────────────▶ server
client ◀── SYN ACK  seq 5000, ack 1001 ── server
client ── ACK      ack 5001 ────────────▶ server

Each packet is wrapped on the way down: TCP header inside an IP header inside an Ethernet frame inside signal changes on the wire. The client's kernel assigns an ephemeral source port, say 54321, and the server's is 443, so the four-tuple identifies this conversation uniquely. The kernel now knows the server will not lose data, reorder it, or duplicate it. It still has not encrypted anything.

Step 5: making it private

Then the TLS handshake[^4], another round trip, and the reason nobody reads your traffic:

client ── ClientHello: TLS 1.3, cipher suites, server name: google.com ──▶

client ◀── ServerHello + certificate + key share ──

      client verifies the chain up to a root it trusts,
      runs the key exchange, derives the shared secret

client ── Finished ─────────────────────────────────────────────────────▶

      from here, every byte is encrypted

Three things just happened in about one round trip: the server proved its identity by presenting a certificate your browser can chain to a trusted root, both sides derived a key nobody watching could compute, and the channel became authenticated, so nobody can sit in the middle and relay it. In HTTP/3 this happens over QUIC on UDP, in one round trip total, with the transport rebuilt in the browser rather than in the kernel.

Step 6: the request

Now the top layer finally speaks, and the actual request is about 500 bytes of plain text:

GET / HTTP/2
Host: google.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Cookie: ...

HTTP/2 200 OK
content-type: text/html; charset=utf-8
content-encoding: br
set-cookie: ...

Somewhere on the far side, a machine that was waiting on port 443 accepts the connection, decrypts it, reads the request, and hands it to a web server. The web server may find the answer in a cache a few kilometers away, or ask a database, or construct the page. Whatever happens there is application logic. From this network's point of view, the server simply answers.

The answer comes back, and the browser starts rendering while the rest is still arriving.

Step 7: the journey back, layer by layer

The response is the same machinery in reverse, and this is where the layering becomes visible in one place:

encapsulation, sending side:

  [ HTTP 200 ]                         application
  [ TCP | port 443 | ack | HTTP 200 ]  transport   ← reliable, ordered
  [ IP | 142.250.78.100 | TCP | ... ] network    ← addressed to the server
  [ Eth | router's MAC | IP | ... ]   link        ← addressed to the next door
  10110010 0011...                     physical     ← volts, light, or waves

at each hop, in the middle of the network:

  router takes in a frame
    ├─ reads the destination MAC: not me? → forward
    ├─ reads the destination IP: not mine? → look up the routing table
    ├─ longest prefix match says "next hop is this neighbour"
    ├─ rewrite the IP header: my address becomes the source, next hop's the destination
    ├─ decrement the TTL
    ├─ rebuild the frame with the next neighbour's MAC address
    └─ push it out the next port

Watch the two identity swaps on every single hop, because they are the elegant part of the whole design. The IP addresses stay the same from source to destination, end to end, carrying the identity of the conversation. The MAC addresses change every time, because each link is a separate physical world with its own neighbours. The payload is never opened. The router does not know or care whether the bytes are a video, a bank transfer, or a page; it is moving an envelope forward.

And somewhere on this path, a packet is lost. Nothing notices yet: the loss only exists as the absence of an acknowledgment. The receiver's acknowledgment for that range stops advancing, the sender sees it, resends the segment, and the receiver recognizes the number as one it already has and silently discards the duplicate. From your side, the page simply takes a few milliseconds longer.

Step 8: what it all cost

The interesting question is not what happened but where the time went, because the answer is mostly not the network moving data.

around a server 30 ms away:

  DNS lookup                5-30 ms   one round trip to a resolver
  TCP handshake             30 ms     1 RTT
  TLS handshake             30 ms     1 RTT (HTTP/3 saves this one)
  request + first bytes    ~30 ms     1 RTT, plus the server's work
                           ───────
  first paint             ~100-150 ms

moving the megabytes that follow is mostly bandwidth, not latency

The same page from another continent adds about 100 ms to every single round trip, which is exactly why protocols moved to one-round-trip handshakes and why streaming starts rendering before the page is complete. This is the concrete payoff of the numbers in the physical layer post: distance is measured in hops and milliseconds, not in kilometers, and no amount of bandwidth changes it.

Then the browser asks for the stylesheet, the logo, and the script. Each one is another request over the same connection in HTTP/2 or HTTP/3, multiplexed so a slow script never delays the logo, and cached so a second visit asks for almost nothing at all.

The big picture

One typed string, and every post in this series happens in the space of a few hundred milliseconds: a name resolved through a distributed caching hierarchy, a local decision about which machine to hand the frame to, an ARP broadcast to learn a hardware address, a three-message handshake to open a reliable connection, a certificate and a key exchange to make it private, a five-hundred-byte text request, and a response that travels back through nineteen hops[^5], each rewriting its envelope and forwarding by longest prefix match, while a lost packet is noticed only as a missing acknowledgment.

you type google.com
  │
  ├─ DNS: name → address              (a cached hierarchy)
  ├─ routing table: not local → gateway
  ├─ ARP: gateway's MAC address        (the one broadcast)
  ├─ TCP: SYN, SYN-ACK, ACK           (reliable, ordered, byte stream)
  ├─ TLS: certificate + key exchange   (private, authenticated)
  ├─ HTTP: GET /  →  200 OK           (meaning, finally)
  │
  ▼
the same machinery in reverse, plus a renderer

Three series now sit on one shelf. The Computers Explained series built the machine that runs your browser: bits, logic, a processor, memory, storage, and I/O. The Operating Systems Explained series explained how that machine stays yours while a hundred programs share it, and how it boots from a cold press of power. This series took the last step: how that machine talks to other machines it knows nothing about, and how a string of characters typed into a browser becomes a page by agreeing, layer by layer, on what a bit, a frame, a packet, a connection, a request, and a private conversation are.

The protocols will keep changing. HTTP/4 will eventually replace HTTP/3, and something will replace TCP. But the questions will not: who is this for, where is it going, how do I know it arrived, and can I trust the answer? Those four questions are the network, and they are older than the machines carrying them.

[^1]: Domain Name System - Wikipedia

[^2]: Address Resolution Protocol - Wikipedia

[^3]: Three-way handshake - Wikipedia

[^4]: Transport Layer Security - Wikipedia

[^5]: Border Gateway Protocol - Wikipedia

Network Security & TLS

Mon, 28 Sep 2026 00:00:00 GMT

Everything in this series so far has been in the clear. Your packets were described as frames, segments, and headers, and every one of those words means a machine you do not control could read them. The application post left that open: the network is a public road with strangers on it, and HTTP is printed in the clear. This post closes the loop. What an attacker can do, the one piece of arithmetic that makes private conversations possible on a public network, who is trusted to say whose name is whose, and what all of it still fails to protect.

Assume the road is watched

Three things can go wrong on a network, and it is worth naming them precisely because every defense maps to one of them.

Eavesdropping. Someone reads what you send. Every router on the path, every provider along the way, and anyone on the same Wi-Fi can read plaintext HTTP.

Tampering. Someone changes what you send in flight. Without protection, a machine in the middle can rewrite a payment amount or inject a script into a page, and neither end notices.

Impersonation. Someone pretends to be the other end. If nobody vouches for names, the machine answering your request could be anyone at all.

In cryptography, the rule of thumb is that the network is hostile. Design assuming every packet is being read and written, and confidentiality becomes a property of the message instead of a property of the road.

Real example: on an open Wi-Fi network, a device that only forwards traffic can sit between you and a website, read unencrypted requests, and serve its own pages instead. With HTTPS, that device sees which host you are talking to and nothing about what you are saying.

Two kinds of lock

Cryptography offers two families, and the difference between them is the reason the internet works.

Symmetric encryption[^1] uses one shared key for both encrypting and decrypting. It is fast, simple, and strong. Its only problem is distribution: to talk to a server you must already possess a secret it also possesses, and there is no way to send the first secret securely without already having one.

Asymmetric encryption[^2] comes as a pair: a public key you give to the world and a private key you keep. What one can do, the other can undo. Encrypt with the public key and only the private key can decrypt. This solves distribution: an open, unauthenticated channel can carry a public key safely, because an attacker who substitutes his own key is the problem the next section addresses.

symmetric:     one shared secret           fast, both directions

asymmetric:    public key (share it)       slow, solves the chicken-and-egg
               private key (never share)   problem of getting the secret there

Neither is usable alone. Asymmetric cryptography is roughly a hundred times slower than symmetric and cannot encrypt a large document efficiently. Symmetric is fast but cannot start the conversation. Real security uses both, in a pattern called hybrid encryption:

1. asymmetric  prove identity, agree on a shared secret
2. symmetric   encrypt the actual data with that secret
3. symmetric   the data is encrypted separately in each direction

The bulk of the traffic is cheap symmetric encryption. Expensive asymmetric math happens once, at the start, to establish a secret that the fast layer then uses. Every encrypted connection on earth is this pattern.

Certificates: someone has to vouch

Asymmetric keys solve the transport of a secret. They do not solve the harder problem of identity, and this is the part people skip. If a machine in the middle sends you its own public key and claims to be your bank, the cryptography works perfectly and you have just been robbed.

The answer is a third party everyone already trusts: the certificate authority[^3]. A public key certificate[^4] is a public key plus a statement about who owns it, signed by an authority. It is the digital equivalent of a notarized stamp: not that the claim is certainly true, but that someone paid to check.

your browser
   │  certificate: "example.com's key is correct"
   │  signed by: Let's Encrypt Authority X
   │  signed by: an authority in the browser's built-in root list
   ▼
the browser checks the signatures back up to a root it trusts

The browser ships a list of root certificates it was built with. If a chain of signatures leads from the server's certificate to one of those roots, the browser accepts the identity. That entire trust system is public key infrastructure[^5], and the trust decisions were made long before your connection, baked into the browsers and operating systems you installed.

certificate chain:

root (trusted by your browser, pre-installed)
  └── intermediate (vouches for the next one)
        └── leaf: example.com's public key

Two consequences follow from this design. First, certificates expire, because a certificate with no end date could never be revoked quietly. Second, automated issuance exists: services like Let's Encrypt issue certificates automatically to anyone who proves control of a domain, which is why enabling HTTPS went from an annual project to a single command.

The TLS handshake

TLS[^6] is the protocol that runs this pattern on every HTTPS connection. It happens in milliseconds, before any of your actual request, and it is the moment where the previous four sections all meet.

client                                   server
  │ ClientHello                            │
  │  - supported versions                  │
  │  - supported cipher suites             │
  │  - "I want TLS 1.3"                    │
  │  - server name: example.com            │
  │───────────────────────────────────────▶│
  │                          ServerHello    │
  │                          certificate   │
  │                          its key       │
  │◀───────────────────────────────────────│
  │                          Finished      │
  │◀───────────────────────────────────────│
  │ Finished                               │
  │───────────────────────────────────────▶│
  │                                         │
  ▼  both now share a secret                ▼  real data, encrypted

Step by step, because each step answers one problem:

ClientHello lists what the client supports and, in the server name indication[^7] field, which host it wants. This is why one IP address can serve thousands of sites and why that field, sent in the clear, leaks which site you are visiting.
ServerHello picks one version and cipher, and sends the certificate plus the server's public key.
The client verifies the certificate back to a root it trusts. This is the step that makes impersonation fail: a fake certificate does not chain to a trusted root.
Both sides run a key exchange[^8] over those public keys to derive the same secret without ever putting it on the wire. In TLS 1.3 the client also sends its own contribution, so a middle machine cannot negotiate a secret and silently relay it. The channel is authenticated, not just encrypted.
Finished messages prove each side actually derived the same keys, which closes the last gap: an attacker who only forwards traffic is detected.
From here the connection is encrypted and every HTTP request rides inside it.

1 RTT: handshake with a session ticket from a previous connection
0 RTT: resumption using a ticket, data sent immediately
      (safe only for operations that tolerate replay)

The ephemeral part of the key exchange is what gives forward secrecy[^9]. Because the key used for a session is thrown away when the session ends, someone who records traffic for months and later obtains the server's private key still cannot read the old conversation. The certificate's key proves identity; the throwaway key does the work.

What TLS does not do

Honest limits, because overclaiming here causes real damage.

It protects data in transit, not endpoints. A server that logs your messages in plaintext hands over everything anyway. TLS moves the trust boundary; it does not remove it.
It does not hide metadata. The addresses, ports, sizes, and timings are still visible, and so is the hostname in the server name indication. Someone watching knows who you talked to, not what you said.
It does not protect against a compromised authority. Whoever controls a trusted root can issue a certificate for any name. This is the entire weakness of the system, and the reason some people pin certificates or distrust authorities entirely.
It does not cover everything else. Plain HTTP is still everywhere, from internal tools to old APIs, and plain protocols like DNS and email remain largely unprotected by default.

Firewalls and NAT

Two network features get confused with security constantly, so here is what each actually is.

A firewall[^10] filters traffic. Rules decide which connections are allowed in and out, and a stateful firewall remembers which connections it has seen permitted, so replies come back automatically. A firewall protects a boundary: it does not read traffic, and it cannot help once traffic is allowed through.

NAT[^11], from the network layer post, is address translation, and it exists because of the shortage of IPv4 addresses, not for security. Inside a network, many machines share one public address; the router rewrites addresses on the way out and keeps a table of who asked for what.

NAT has one genuine security side effect: a machine behind NAT has no publicly reachable address, so unsolicited connections cannot reach it. That is a side effect of address translation, not a design goal, and it is why a home router looks protected in ways a corporate network does not. It is not a security control, and it should never be used as one.

Real example: the difference shows up the moment you add a port forwarding, or a hole punched for a call. Opening one path to a machine behind NAT removes the accidental protection of that address hiding, and the machine is exposed to the internet directly.

The big picture

A public network means eavesdropping, tampering, and impersonation are all on the table, so security has to be a property of the message, not of the road. Symmetric encryption is fast but needs a secret already shared; asymmetric keys can carry a secret across a public channel but are slow, so real protocols use both. Certificates and a chain of trusted authorities turn a public key into a proven identity, and the TLS handshake combines verification, key exchange, and proof into a private channel in one round trip. Firewalls filter; NAT translates addresses and only incidentally hides machines. And all of it protects data in transit only.

client ─── ClientHello ───────────────────▶ server
         ◀── certificate + ephemeral key ──
         verify chain → derive secret → Finished
         ▼
      encrypted HTTP, unreadable to every router in between

One post left, and it is the one this series was building toward. The final post takes everything above and follows it in real time: one machine, one address bar, and the full journey of a single request across all the layers, from the first letter typed to the first byte rendered.

[^1]: Symmetric-key cryptography - Wikipedia

[^2]: Public-key cryptography - Wikipedia

[^3]: Certificate authority - Wikipedia

[^4]: Public key certificate - Wikipedia

[^5]: Public key infrastructure - Wikipedia

[^6]: Transport Layer Security - Wikipedia

[^7]: Server Name Indication - Wikipedia

[^8]: Key exchange - Wikipedia

[^9]: Forward secrecy - Wikipedia

[^10]: Firewall (computing) - Wikipedia

[^11]: Network address translation - Wikipedia

The Application Layer & HTTP

Sun, 27 Sep 2026 00:00:00 GMT

The transport layer post left you holding a stream of bytes you can trust. Trustworthy bytes are still meaningless noise until someone agrees what they say. That agreement is the application layer: the top floor, the only one your program sees, and the place where the internet turned into something people actually use. This post opens it: who talks to whom, how names become addresses, and how one protocol designed in the 1990s grew into the most-deployed application on earth.

Client and server

The simplest division in computing: one program waits, the other asks.

A server opens a port and waits for incoming connections. A client opens a connection and starts the conversation. The roles belong to the endpoints, not to the machines: your browser is a server when your colleague loads a page from the little app you wrote.

client                                         server
   │  "send me the page"        ───────────────▶ │
   │                                              │
   │  "here it is"              ◀─────────────── │
   │                                              │
   ▼  connection closed                          ▼  waits for the next

This request-response shape is called client-server, and it is one of two patterns in wide use. The other is peer-to-peer, where every machine both asks and offers, which is what file sharing and some video calling use.

The word "application" covers a wide range of things, including two things that are not really applications at all: DNS, which turns names into addresses, and TLS, which encrypts the conversation. Neither shows up in your code as a function call, and that is exactly the end-to-end idea in practice: the network moves bytes, and everything meaningful happens at the ends.

URLs: naming a thing on the web

Before any request, you need to name the thing. The URL[^1] is that name, and its anatomy explains more about the web than any design document.

https://example.com:443/docs/page?q=networking#requests
│     │             │   │        │        │        │
│     │             │   │        │        │        └ fragment: never sent
│     │             │   │        │        └────────── query: parameters
│     │             │   │        └─────────────────── path: which resource
│     │             │   └──────────────────────────── port: usually implicit
│     │             └──────────────────────────────── host: which machine
│     └────────────────────────────────────────────── scheme: which protocol
└─────────────────────────────────────────────────── everything

Each part answers a question at a different layer, which is why a URL feels layered even though it is one string. The scheme says which application protocol to speak, the host says which machine, the port says which program on it, and the path says which resource that program should produce. The fragment is a detail for your browser only; it is not sent to the server at all.

Real example: a browser given https://example.com:443/docs sends GET /docs to port 443, because the scheme already implies HTTPS and 443 is its default port. A URL carries more information than it appears to, and the parts it omits are the parts it assumes.

DNS: names into addresses

Machines have IP addresses. Humans have names. DNS[^2] is the system that connects them, and it is one of the oldest, strangest, and most consequential pieces of the internet.

It is distributed on purpose. The whole system answers one question, what IP address does this name have?, and it answers it by asking strangers in a fixed order, caching aggressively so nobody has to ask often.

your machine does not know the answer
   │
   ▼ asks the resolver (your provider, usually a small program near you)
   │
   ├─ cached? → answer immediately             (this is most of the time)
   │
   ▼ not cached, ask the root server: "where does .com live?"
   │  → "ask the .com server"
   ▼ ask the .com server: "where does example.com live?"
   │  → "ask this server"
   ▼ ask the authoritative server: "192.0.2.1, and here are its records"

The hierarchy mirrors how knowledge is distributed: root knows the top-level domains, the top-level domain knows the authoritative servers, the authoritative server knows one zone and is the only one allowed to give the final answer. Everyone above can point downward without knowing the details, which is what makes the system scale to a few hundred million names.

Caching is what makes it usable. Every answer comes with a TTL[^3], a lifetime in seconds. The resolver, the browser, and the operating system each keep answers until their TTL expires, so a popular name is asked about almost never again. This is also the property that causes pain: for up to a few hours after a record changes, part of the internet is still answering with the old address.

DNS answers more than addresses. Records[^4] come in types, and the type says what the answer is: an A record is an IPv4 address, AAAA is IPv6, a CNAME is another name, an MX record says where email for this domain should be delivered, an NS record says which server is authoritative. That is why changing an email provider and changing a website are both DNS edits, and why the two feel unrelated to users.

Real example: dig and nslookup ask DNS questions directly, so when people say "DNS is broken" it usually means either a name does not resolve or it resolves to the wrong place. The last mile of the web is famously a DNS problem more often than a server problem.

HTTP: the request and the response

With a name and an address, two programs can talk. HTTP[^5] is the protocol that decides what to say, and it is a text protocol: readable lines, human-inspectable, about as simple as a protocol can be.

GET /docs/page?q=networking HTTP/1.1     ← the request

Host: example.com
User-Agent: Mozilla/5.0 ...
Accept: text/html
Connection: keep-alive

HTTP/1.1 200 OK                          ← the response

Content-Type: text/html; charset=utf-8
Content-Length: 4821
Cache-Control: max-age=3600

<html>...

A request has a method, a path, and headers, which carry control information rather than content. A response has a status code, headers, and a body. The methods are the whole vocabulary of the web in five words:

GET: fetch something. Should not change anything on the server.
POST: submit something, or ask for an action.
PUT and PATCH: replace or modify something that exists.
DELETE: remove something.

The rule underneath is that GET should be safe to repeat. Your browser retries failed GETs, prefetches links, and crawls pages. If GET could charge a card, the web could not work.

Status codes are grouped by their first digit, which is enough to know what kind of problem you have: 2xx worked, 3xx look elsewhere, 4xx you asked wrong, 5xx the server failed. Distinguishing them is a real skill, because "404" means the resource is missing while "502" means a gateway in front of your server is broken. Both look like failure to a user and mean completely different things to whoever fixes it.

Real example: curl -v https://example.com prints the exact conversation above, headers and all, in order. Reading HTTP with curl is the fastest way to see that a web framework is just a library that builds this text and parses the reply.

Stateless, and where state comes from

HTTP is stateless[^6]: the server does not remember your previous request. Each request stands alone, and the client carries everything needed to identify itself.

That is a deliberate design, and it is the reason the web scaled to enormous traffic. Any server in a pool can answer any request. A machine can crash and another takes over instantly. There is no shared session, no sticky routing, no single point of failure.

The cost is that servers cannot remember anything by themselves, so state has to travel with every request. Cookies[^7] are that mechanism: small pieces of data the server sets, the browser stores, and sends back on every subsequent request to that domain.

server → Set-Cookie: session=abc123
client → stores it
client → GET /cart      Cookie: session=abc123
client → GET /checkout  Cookie: session=abc123

The server looks up abc123 in its own store, so the reference travels while the state stays put. When you clear cookies, the server loses its pointer to you. That is statelessness working exactly as designed, with the state living somewhere else.

Three versions of HTTP

The protocol is old and the transport under it changed under its feet, so HTTP evolved in steps, each fixing the previous version's worst problem.

HTTP/1.0 opened a fresh connection per request. Simple, and expensive: every request paid for a full handshake.

HTTP/1.1 added keep-alive, so one connection carries many requests. It also allowed pipelining: send request 2 before request 1's response arrives. Both sound like wins and were both nightmares, for the same reason. HTTP/1.1 processes responses strictly in order, so if request 1 is slow, every response behind it waits, even if their data is already sitting there. This is head-of-line blocking again, this time at the application layer, and it is why real HTTP/1.1 sites open six connections per browser tab and shard their domain across hostnames.

HTTP/2[^8] fixed that by changing the format while keeping the semantics:

Multiplexing: many requests in flight on one connection, each with its own id, so a slow response no longer blocks the others.
Binary framing: a compact binary header instead of text, which is faster to parse and smaller on the wire.
Header compression: HPACK[^9] removes headers you already sent on the same connection, since browsers repeat the same ones constantly.
Server push, later deprecated, for sending resources before they were asked for.

HTTP/3[^10] moved HTTP onto QUIC[^11], which runs on UDP and does its own reliability. The gain is not speed, it is independence: HTTP/3 no longer depends on the transport protocol that lives in the operating system kernel. A connection can be migrated to a new network path, several requests lose packets without stalling each other, and encryption is not an optional add-on bolted on top but part of how the connection is established.

HTTP/1.1   many connections · requests in order · blocking
HTTP/2     one connection · requests multiplexed · still TCP underneath
HTTP/3     one connection per origin · multiplexed · QUIC · built-in encryption

Each version of HTTP was waiting for the transport layer to catch up. HTTP/2 waited years for the operating system's TCP. HTTP/3 stopped waiting and built its own.

Beyond request and response

Two extensions are worth knowing because they explain how modern web applications feel.

WebSockets[^12] start as an ordinary HTTP request and then keep the connection open, turning it into a full-duplex channel. Both sides can push messages at any time, with no polling and no request per update. That is what makes a chat app live, a dashboard update, or a collaborative document work without the server knowing in advance what you will ask for.

REST[^13] is not a protocol feature but a style of using HTTP that the web settled on: address your resources with URLs, let the method say the action, keep responses cacheable, and let the server store nothing about the conversation. Most of the design guidance for HTTP APIs is a restatement of these ideas.

The big picture

Layer four got bytes to a program. The top layer decides what those bytes mean. A server waits, a client asks, and a URL names the thing being asked for across all the layers at once. DNS turns the human name into an address through a distributed hierarchy that caches aggressively enough to work at internet scale. HTTP is a text request and response with five methods, a handful of status classes, and no memory between requests, which is exactly why it scales and why state has to travel in cookies. HTTP/2 multiplexed to escape head-of-line blocking; HTTP/3 built its own transport to stop depending on the kernel's. WebSockets turn a request into a live channel, and REST is the shape most of the web settled on.

a URL names it:  scheme · host · port · path
DNS resolves it: name → address, cached until the TTL
HTTP asks for it: method · path · headers → status · body
state travels:    cookies carry a reference, the server holds the state

One layer left, and it is the one that keeps being skipped. The next post opens network security: what happens when the network is shared with strangers, why every byte above is currently readable by anyone on the path, and how a handshake nobody can fake turns a public road into a private conversation.

[^1]: URL - Wikipedia

[^2]: Domain Name System - Wikipedia

[^3]: Time to live - Wikipedia

[^4]: Domain Name System record types - Wikipedia

[^5]: Hypertext Transfer Protocol - Wikipedia

[^6]: Stateless protocol - Wikipedia

[^7]: HTTP cookie - Wikipedia

[^8]: HTTP/2 - Wikipedia

[^9]: HPACK - Wikipedia

[^10]: HTTP/3 - Wikipedia

[^11]: QUIC - Wikipedia

[^12]: WebSocket - Wikipedia

[^13]: Representational state transfer - Wikipedia

The Transport Layer: TCP & UDP

Sat, 26 Sep 2026 00:00:00 GMT

The network layer post ended with two unanswered questions: did my packet arrive, and did they arrive in order? It also quietly admitted something more awkward. Its addresses are per machine, so on a machine running two hundred programs, IP alone cannot say which program a packet is for. This post opens the layer that fixes both: TCP and UDP, the two protocols that turn a lossy, unordered packet delivery into something a program can actually build on.

What the transport layer is for

The network layer got the data to the right computer. The transport layer gets it to the right program on that computer, and decides what promises to make along the way.

192.168.0.15  = your laptop
                    ├─ 443   the browser
                    ├─ 5432  the database client
                    └─ 7000  the game

Those numbers are ports[^1]. A port is a 16-bit number identifying one program listening on a machine, and the transport layer header carries it. Add the IP addresses and you get the four-tuple[^2]: source address, source port, destination address, destination port. Five different connections to the same server look completely different to it, because their source ports differ.

Ports come in two flavors. Well-known ports below 1024 are reserved for standard services, so 53 is DNS, 80 is HTTP, 443 is HTTPS. Ephemeral ports are assigned to whatever a program needs at that moment, usually from a large pool, and there are thousands of them, which is what lets one web server host tens of thousands of simultaneous connections.

A socket[^3] is the object your program actually holds: an address plus a port, plus state. In the operating system series terms, creating a socket is a syscall asking the kernel to own an endpoint for you. When two machines talk, there are two sockets, one on each side, and the packets between them belong to that conversation only.

Now the two choices. Everything below is the difference between them.

UDP: send and forget

UDP[^4] is the simplest useful thing this layer can do. It adds almost nothing: ports, a checksum, and four fields.

┌──────────────┬──────────────┬──────┬──────┬────────┬─────┐
│ source port  │ dest port    │ len  │csum │payload │     │
└──────────────┴──────────────┴──────┴──────┴────────┴─────┘

No setup, no acknowledgment, no resending, no ordering, no idea whether the other side exists. You send a datagram and continue working immediately.

What UDP gives you is message boundaries. One send is one datagram, and the receiver either gets that whole datagram or does not get it. Boundaries survive the journey.

Real example: a video game sends your position thirty times a second and a voice app sends a chunk every 20 milliseconds. If a packet of state is late, it is worthless, because the next one is already on the way. Retransmitting it would deliver old information about where you are now standing. UDP is exactly right here: the best use of the network is to send the next thing.

UDP is also what a programmer chooses when the layer above will do the work. DNS is a famously tiny exchange over UDP. A video call sends its own loss concealment, its own pacing, its own encryption on top. And QUIC, from the next post, implements a full reliable transport on top of UDP inside the kernel's application space.

TCP: a reliable conversation

TCP[^5] makes the opposite deal. It delivers every byte, in order, exactly once, or it fails loudly trying. In exchange you pay for setup, for state on both ends, for headers on every packet, and for waiting when things go wrong.

The first surprise is that TCP is a byte stream, not a message service. If you write 100 bytes and then 200 bytes, the other side may read 150 and then 150. There are no message boundaries, because TCP's promise is about the order of bytes, not about your write calls. Every programmer who has ever been surprised by a JSON parser choking on half a message learned this the hard way.

what you sent:      [ "hello" ][ "world" ]
what TCP delivers:  [ h ][ e ][ l ][ l ][ o ][ w ][ o ][ r ][ l ][ d ]
                    one continuous stream - the receiver decides the chunks

The second surprise is that TCP is end-to-end. The guarantees are provided by the two machines at the ends, not by the routers between them. The network keeps doing exactly what the previous post described: forward, forget, drop, reorder. TCP builds reliability from that on top, at the endpoints. This is the end-to-end principle from the TCP/IP post in action.

The handshake

Before any data moves, both sides agree to talk. The three-way handshake[^6] does it in three packets:

client                                server
  │  SYN          "I want to talk"        │
  │──────────────────────────────────────▶│
  │  SYN + ACK     "Sure, I acknowledge"  │
  │◀──────────────────────────────────────│
  │  ACK           "Great, I agree too"    │
  │──────────────────────────────────────▶│
  │                                        │
  ▼  data starts flowing                  ▼

Each message serves a purpose. The first carries the client's starting sequence number and options. The second acknowledges that number, proving the server received it, and returns the server's own starting number. The third acknowledges the server's number, proving the client received that. Only after this does either side send data.

The handshake exists because of one hard fact about networks: a message can arrive late, duplicated, or out of order. Two open connections with no handshake can be confused with a retransmission of an old one. Three messages give both sides proof that each heard the other, and give the operating system a definite moment to create a socket and let the process layer schedule it.

Real example: the half-open connection is why opening 10,000 connections at once can exhaust a server's backlog. Every one of them is a socket in the middle of a handshake, holding memory, waiting for a third message that will never come.

Sequence numbers and acknowledgments

Once open, TCP numbers the bytes. The sequence number is the index of the first byte in the segment, and the receiver sends back an acknowledgment with the next number it expects.

sender:      [seq 1001, 500 bytes]──▶
receiver:    ACK 1501  ──▶          "I have everything up to 1500"

sender:      [seq 1501, 500 bytes]──▶   (this one is lost)

sender:      [seq 2001, 200 bytes]──▶

receiver:    ACK 1501  ──▶          "still waiting for 1501"

sender: resends [seq 1501]  ──▶      duplicate arrives later,
receiver: ignores it, ACKs again     because the numbers say so

Everything TCP does to be reliable is in that picture:

Numbers give ordering. Out-of-order segments wait in a buffer until the missing one shows up.
Acknowledgments give proof of receipt. Nothing is assumed to have arrived.
A repeated acknowledgment is a signal. When the receiver keeps saying "still 1501", the sender concludes its segment was lost and resends. It does not need an error message; the absence of progress is the evidence.
Numbers deduplicate. A retransmitted segment carries the same number as the original, so the receiver recognizes it and does not deliver it twice.

Real example: this is why typing in a terminal over SSH is fast. Keystrokes are small, arrive almost immediately, and the acknowledgment for each comes back piggybacked on the next packet instead of costing its own trip.

Flow control: don't overwhelm the receiver

Acknowledgments solve loss. Two more problems remain, and they are the pair that separates a working connection from a fast one.

Flow control protects the receiver. A fast sender can bury a slow receiver in data it has no room to store, so the receiver advertises its free buffer space, the receive window, and the sender may never have more unacknowledged bytes in flight than that window.

receiver: "I have 64 KB free, send at most that much"
sender:   "understood, filling 64 KB before waiting for ACKs"

This is a sliding window: the sender keeps sending until the window is full, then slides it forward as acknowledgments arrive. Bandwidth-delay product, from the physical layer post, is what sets the ideal window size - on a 100 ms round trip to another continent, a 64 KB window caps your throughput no matter how fast the link is. This single fact is why window scaling exists and why "my connection is fast but my download is slow" has a boring explanation.

Congestion control protects the network, and it is the more delicate of the two because the sender cannot see the network. It infers congestion from the only signal available: if acknowledgments stop arriving or arrive slower than expected, something between is full, and the sender's queue somewhere overflowed.

The algorithm behind it is remarkably simple, and roughly:

Slow start. Begin with a tiny window and double it every round trip until something hurts. The network is mostly empty at the start of a connection, so grow fast.
Congestion avoidance. Stop doubling. Add one segment per round trip instead, so growth becomes linear and gentle.
Loss detected. When a segment is missing, halve the window and back off. The network is full; being timid is correct.
A few losses are normal. One lost segment in a large batch usually means a queue overflowed briefly, not that the network is dying, so modern stacks react much more gently to a single loss than older ones did.

The sender is guessing about the whole internet from one signal: how fast acknowledgments come back. That guess is good enough to run the internet.

Two windows, two jobs. The congestion window is the sender's guess about the network. The receive window is the receiver's honest statement about itself. The sender is limited by the smaller of the two.

Head-of-line blocking

TCP delivers bytes in order, so a lost segment holds up everything behind it, even if those later segments arrived perfectly and are sitting in the receiver's buffer. This is head-of-line blocking[^7].

packet 100 lost ··· packets 101-105 arrived

receiver cannot deliver 101 until 100 shows up
the application waits, even though the data is already there

On a long, variable-latency path this is the worst property of TCP: one lost packet out of a window can stall the whole stream, and the cost grows with distance. This single problem, plus the fact that encryption needs key material before the payload can be read, is what motivated QUIC: a transport protocol that runs on UDP, keeps its own state in userspace, tracks many independent streams, and never lets a lost packet for one stream block the others.

QUIC also changes where things live. TCP is implemented in the operating system kernel, which is why it took decades to add new options and why middleboxes broke when it changed. QUIC is a library in your process, so it ships with the browser and updates when the browser updates. The layer did not move; the implementation did.

Closing a connection

Data can end unilaterally. An endpoint sends FIN meaning "no more data from me"; the other replies with its own FIN plus an acknowledgment. Both sides then linger in a wait state before the socket can be reused, so that any straggler segments in the network do not confuse a future connection that reuses the same ports.

Real example: a program can close only its sending half and keep receiving. This is why killing a client process does not necessarily close the socket: any data already on the network still arrives, and something else has to read it. Programs that exit while the kernel still has unread data are why closing a socket properly is its own small ceremony.

The big picture

Layer three got packets to a machine. Layer four gets them to a program, identified by ports, with the four-tuple telling conversations apart. UDP promises nothing, keeps message boundaries, and is the right choice when stale data is worse than missing data. TCP promises every byte, in order, exactly once, by numbering bytes, acknowledging receipt, and resending whatever acknowledgment stops advancing: at the cost of a handshake, stream semantics, and waiting. Flow control protects the receiver with a sliding window; congestion control guesses the network's state from acknowledgment timing and grows carefully. TCP does all of it in the kernel, end to end, which is both its strength and the reason QUIC now does it in userspace.

network:  packets, maybe lost, maybe reordered
   ↓ transport adds ordering, dedup, retransmission
   ↓ and two windows: the receiver's, and the sender's guess
program:  a stream of bytes it can trust

The next post opens the top floor: how two programs agree on what the bytes mean, how names become addresses, and how the web became the most-deployed protocol in human history.

[^1]: Port (computer networking) - Wikipedia

[^2]: Socket address - Wikipedia

[^3]: Network socket - Wikipedia

[^4]: User Datagram Protocol - Wikipedia

[^5]: Transmission Control Protocol - Wikipedia

[^6]: Three-way handshake - Wikipedia

[^7]: Head-of-line blocking - Wikipedia

The Network Layer & IP Routing

Fri, 25 Sep 2026 00:00:00 GMT

The link layer post delivered a frame to the machine on the other end of one cable. That is a small promise for a world-sized problem: the destination is usually in another building, another city, another continent, on a network whose owner has never heard of you. This post opens the layer built for that: the one that gives every machine on earth an address, and that moves data one stranger at a time until it arrives.

What the network layer is for

Two jobs, both simple to state.

Addressing. Every host gets a globally unique address, so any machine anywhere can name any other. That is the layer's whole reason to exist. A local link can get away with small numbers because it only ever has a dozen machines; the network layer needs an address space big enough for the planet, and it needs addresses that contain a bit of structure, because routers will need to group hosts together to forward at scale.

Routing. Data is not sent to the destination; it is sent one hop at a time to whichever neighbor is closer. Each machine decides, locally, "for each destination I care about, who is the next step?" No router knows the whole path. The path emerges from a chain of local decisions.

Layer two asks "who is next door?". Layer three asks "who is next door in the direction of Japan", and answers it with whatever the neighbour says.

The network layer also has to carry the previous post's assumption into a world where the wire is unreliable. It does not fix anything. It forwards, counts hops, and reports errors.

IP addresses

The network layer's protocol is the Internet Protocol (IP)[^1], and its address is the IP address[^2]. Two versions exist in the world, and both are still in daily use.

IPv4 is 32 bits, written as four decimal numbers:

93.184.216.34
└ each octet: 0-255        2^32 ≈ 4.3 billion addresses

IPv6 is 128 bits, written as eight groups of hexadecimal digits:

2606:2800:220:1:248:1893:25c8:1946
└ 8 groups of 16 bits       2^128 addresses

The scale difference is the whole story. IPv4 was designed for a research network and ran out around the time smartphones arrived; IPv6 was created because of that shortage and is being deployed slowly, one network at a time, mostly because the two can coexist.

Not every address is public. Private address ranges[^3] are reserved for internal networks and are never routed on the internet:

10.0.0.0/8        192.168.0.0/16       172.16.0.0/12
(one big block)   (home networks)       (most offices)

That is why your laptop is 192.168.0.x at home and why your provider gives you an address no website can look up. Something must translate between the two, and that something is NAT, which the security post opens properly.

Real example: a public site cannot distinguish your laptop from a million other laptops behind a million routers by IP address alone. They all share one address. NAT is why "your IP address" is much weaker evidence than it sounds.

Subnets, prefixes, and CIDR

An address is not just an address. It is a prefix plus a host part, and that split is what makes routing possible at all.

The old scheme carved addresses into three fixed classes: class A for enormous networks, class B for large, class C for small. It was exhausted almost immediately, because "medium-sized network" was not a size anyone had.

CIDR[^4], classless inter-domain routing, replaced it with one idea: write the prefix length explicitly.

192.168.1.0/24

│            └── 24 bits of prefix = the network
└───────────────── 32 bits total

the /24 means the first 24 bits identify the network,
the last 8 bits identify hosts (up to 254 usable)

The prefix length is the only concept you need. And because a prefix describes a whole range, a router can advertise a million addresses as one line.

A subnet is not a special kind of address. It is an address plus a ruler saying how much of it is the network.

The IP packet header

The unit layer three moves is the packet[^5], and it is the first place we meet the idea from the representation post applied to real wire formats: a fixed layout of fields, each with a known offset.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version |  IHL  |    DSCP     |      total length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           identification         | flags      |fragment offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      time to live      |  protocol |       header checksum      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        source address                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      destination address                     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                    options (if IHL > 5)                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The fields you will actually reason about:

Source and destination address. The whole point of the packet.
Protocol. What is inside: 6 for TCP, 17 for UDP, 1 for ICMP. This is the pointer that lets the receiving host hand the payload to the right module.
Time to live. A counter that starts at some value, like 64, and is decremented by every router. This is the field that stops packets from circulating forever.
Header checksum. Only the header is checked, and it is recomputed at every hop, because the header changes at every hop.
Total length and IHL. How big the packet is, and how big the header is, since options make the header variable.

Note the asymmetry: the header changes at every hop, the payload does not. The payload survives the journey untouched; only the envelope is re-addressed.

TTL and why tracert works

The time to live[^6] field is a distance counter, not a timer. A router that receives a packet with TTL 1 decrements it to 0, sends back a message saying "I had to throw this away", and drops the packet. Any packet with a TTL high enough to cross a continent still counts its hops.

That single field produces the best network tool most people know:

traceroute to a server in Amsterdam:

 1  192.168.0.1        0.9 ms   your router
 2  10.x.x.x           8.1 ms   your provider
 3  ...               14.2 ms   backbone
 ...
 7  ...              121.4 ms   the destination, or near it

Each line is one network refusing to carry the packet any further and saying so. The tool asks again with TTL 2, again with 3, and the sequence of refusals is the path.

This also retires a myth from the physical layer post. People often blame satellite latency on light being slow. It is: the count of hops is what distance means on a network, and the light is not the villain. The number of intermediate machines is.

Routing, hop by hop

Every host and every router has a routing table[^7]: a list of destinations and next hops. When a packet arrives, the router looks at the destination and picks a row. The match is not exact, and this is the elegant part: the router picks the longest matching prefix.

routing table:

192.168.1.0/24      →  port 3          (my own network)
10.0.0.0/8          →  port 5
172.16.5.0/24       →  router A       (someone else's network)
0.0.0.0/0           →  default route  (everything else)

packet to 172.16.5.9   →  longest match is 172.16.5.0/24 → router A
packet to 8.8.8.8      →  only the /0 matches           → default route

The default route[^8], written 0.0.0.0/0, is the catch-all that lets a small network reach the internet with one entry. It is the same trick as a phone's "call anywhere" entry, and it is why routers do not need an entry for every host on earth.

Longest prefix match is what makes prefixes useful rather than decorative. A host can have one entry for its own street and still inherit everything else from the default route, and a big provider can announce one line covering a million addresses and let every router downstream pick the most specific one that applies.

Who builds these tables

Two machines disagreeing about routes is the normal state of the internet, and fixing it is a whole field. The dividing line is ownership.

Inside one organization's network, machines run an interior gateway protocol to compute routes automatically. OSPF[^9] is the common one: routers describe their links to each other, everyone builds a full map of that network, and the shortest path wins. Here, topology is shared data, and everyone can know everything.

Between organizations, that is impossible and undesirable. A provider has no interest in a competitor knowing its internal topology, and the shortest path is often the wrong path for policy reasons: peering agreements, transit fees, and who you are willing to carry traffic for. So the border protocol is different in kind. BGP[^10] is how networks, called autonomous systems[^11], announce to each other which prefixes they can reach.

inside one network:      OSPF - "here are my links, compute the best paths"
between networks:        BGP  - "I can reach these prefixes", plus policy

BGP does not compute shortest paths.
It decides who to tell what, in an order operators agree on.

Two properties of BGP explain a lot of the internet's behavior. It does not tell anyone about everything, so some traffic takes odd detours. And because it runs in logical time, seconds or minutes, a misconfigured announcement can misdirect traffic for real stretches of time. BGP is a set of agreements between strangers, maintained by trust and contracts, not by mathematics.

ICMP: the network layer talking back

Routing is one thing; telling someone their packet failed is another. That is ICMP[^12], the protocol next to IP.

Echo request and echo reply are what ping sends: a tiny packet asking "are you there?", answered with "yes, and here is the time". That is how ping measures the latency from the physical layer post, because it measures a round trip through the whole chain.
Destination unreachable is how a router refuses to deliver. When you see "no route to host", that message is why.
Time exceeded is how a router reports "your TTL ran out", which is what traceroute reads.
Fragmentation needed tells the sender its packet was too large.

ICMP is the network's error reporting, and it is genuinely useful, which is also why attackers love it: forged ICMP messages can be used to discover hosts, redirect traffic, or amplify traffic into a flood. Good networks answer ICMP carefully rather than blocking it, and that is why "blocked ping" is not the security win it sounds like.

The big picture

Layer three gives every host a globally meaningful address, carves it into a prefix plus host part so billions of addresses can be advertised in single lines, and moves packets one hop at a time by longest prefix match, default route in hand. It never fixes anything: it forwards, decrements a TTL that doubles as tracert, and reports trouble through ICMP. Inside a network, OSPF computes paths from a full picture. Between networks, BGP exchanges which prefixes are reachable under policy, because strangers do not share maps. And every packet's header is rewritten at every hop while its payload survives untouched.

"send this to 93.184.216.34"

your machine:  not mine → default route
your router:   not mine → provider's router
provider:      not mine → transit backbone
... nineteen hops of "not mine, but I know who" ...
destination:   that is mine → hand to the host

Nobody knows the whole route. Everybody knows enough. The next post adds the layer that finally asks for something: not "how do I get there" but "did it arrive, and in what order".

[^1]: Internet Protocol - Wikipedia

[^2]: IP address - Wikipedia

[^3]: Private IP address - Wikipedia

[^4]: Classless inter-domain routing - Wikipedia

[^5]: IP packet - Wikipedia

[^6]: Time to live - Wikipedia

[^7]: Routing table - Wikipedia

[^8]: Default route - Wikipedia

[^9]: Open Shortest Path First - Wikipedia

[^10]: Border Gateway Protocol - Wikipedia

[^11]: Autonomous system (Internet) - Wikipedia

[^12]: Internet Control Message Protocol - Wikipedia

The Link Layer & Local Networks

Thu, 24 Sep 2026 00:00:00 GMT

The physical layer post ended at the bottom: bits, and nothing that knows what they mean. This post adds the first thing that does. Layer one moves bits to the neighbor. Layer two gives those bits an address, a frame around them, and a device smart enough to deliver them to exactly one machine out of everyone plugged into the same cable. This is the layer that turns loose signals into a local network, and it is the first place the addressing idea appears.

What the link layer is for

The OSI post summarized the job in one sentence: deliver bytes to the neighbor. That is worth unpacking, because the neighbor is the whole point.

A router connecting two networks receives a packet and forwards it to a different cable. It never looks inside for a local machine. The link layer is what happens on a single cable, between machines sharing that cable, and it answers three questions:

Who is this for? There may be a dozen machines on this wire.
Where does it start and end? The physical layer delivers a soup of bits. Somebody must mark the message boundaries.
Did it survive the trip? Signals get damaged, and someone should detect that before passing garbage upward.

Note what the link layer does not do. It knows nothing about hosts across the world, nothing about programs, and nothing about whether a message will be answered. It moves frames one hop, on this wire, to this machine.

MAC addresses: identity on the wire

The link layer's address is the MAC address[^1]: 48 bits, usually written as six hex bytes, and permanently burned into the network interface at the factory.

a4:83:e7:2f:19:0b

first 3 bytes (a4:83:e7)  who made the card (the OUI vendor prefix)
last 3 bytes (2f:19:0b)    which card (assigned by the manufacturer)

The structure matters because it is the one place where the internet's "everything is flat" idea is broken. IP addresses are allocated top-down and therefore tell you where a machine is roughly. MAC addresses are assigned by hardware makers and tell you nothing about geography at all: the card in your laptop and the card in a server in Seoul share only a vendor prefix.

Real example: your laptop and your neighbor's laptop, on the same café Wi-Fi, can have MAC addresses from the same manufacturer batch. There is no "where" in a MAC address.

A note on modern hardware: many interfaces now use a locally administered address, with a bit flipped to signal "this is a random number, not the vendor's", because tracking devices by permanent hardware identity turned into a privacy problem. The format stayed the same; the promise of global uniqueness got weaker on purpose.

The Ethernet frame

Layer two does not send bare bytes. It sends a frame[^2]: the payload from above, wrapped in a header and a trailer that only nearby machines care about.

┌────────┬────────┬──────┬──────────────┬─────┬─────────┐
│ dest   │ source │ type │   payload    │ pad │  FCS    │
│ MAC    │ MAC    │      │  46-1500 B   │     │  4 B    │
│ 6 B    │ 6 B    │ 2 B  │              │     │         │
└────────┴────────┴──────┴──────────────┴─────┴─────────┘
    └ header ─────────────┘                  └ trailer ──┘

Field by field:

Destination and source MAC: who this frame is for, and who sent it. These two fields are the entire local addressing system.
Type: what is inside, meaning an IP packet, an ARP message, or something else. This is the EtherType pointer that lets a machine hand the frame to the right layer.
Payload: up to 1500 bytes of layer 3 data. A 1500-byte payload is the MTU[^3], the maximum transmission unit, the standard ceiling for a frame on ordinary Ethernet.
FCS: a frame check sequence[^4], a checksum over the whole frame.

Two details in there surprise people. First, the minimum: a frame must be at least 64 bytes, so tiny payloads get padded. Second, the trailer: the frame does not end when the payload does, which means a receiver knows to keep reading after a short message instead of mistaking the gap for the end.

Real example: when your machine sends 20 bytes of a DNS query, the Ethernet frame is still 64 bytes minimum, padded to 60 with zeros. Small packets on a real link are mostly padding and headers, which is one reason protocols prefer fewer, larger messages.

The FCS is the link layer's only reliability claim, and it is modest: it detects errors, and a corrupt frame is silently dropped. Detection is not recovery. Layer two never retransmits, because it has no idea whether the frame was lost in transit or arrived while the receiver was busy, and re-sending blindly would flood a busy link with duplicates. The transport layer is where retransmission actually happens.

Switches: the box that learned who is where

Now the hardware. A hub is the old answer: an electrical box that repeats every signal to every port. Every machine hears everything, and only one may speak at a time, or the signals collide into noise. A hub is one big collision domain[^5]: everybody shares one conversation slot.

A switch[^6] is the modern answer. It forwards each frame only out the port where the destination actually is, and it learns that mapping by watching:

laptop sends frame  ──▶  switch notes: A4:83:E7:2F:19:0B is on port 3
                        and stores it (the CAM table)

later, a frame for A4:83:E7:2F:19:0B arrives
   ├─ destination known  → forward out port 3 only
   └─ destination unknown → flood out every other port
                            (the first sighting must find someone)

This learning is the whole trick, and it has a name that sounds corporate and is simple: source learning. Every frame that arrives tells the switch whose machine is on which port. The switch never asks.

hub:    port1 ─┐
        port2 ─┼─ repeat everything everywhere
        port3 ─┘      one collision domain

switch: port1 ─┐   each port is its own collision domain;
        port2 ─┼─ frames go only where they need to go
        port3 ─┘   full duplex: send and receive simultaneously

That last property matters more than it sounds. Because a switch gives every machine its own private wire, a machine can send and receive at the same time. Hubs could not: they were half duplex, and the whole network took turns. Moving from hubs to switches is the single change that made office networks feel ten times faster, without any cable being replaced.

Real example: when you run a speed test on Wi-Fi and get half the advertised speed, one common reason is that the wireless medium is shared, unlike the wired network. Full-duplex switches are why a gigabit cable port really does reach close to a gigabit.

ARP: bridging the two address worlds

Here is a gap in the story. Layer 3 identifies machines with IP addresses[^7], which are what applications use and what routing depends on. Layer 2 delivers frames using MAC addresses. To send anything, a host needs to know which MAC belongs to which IP.

Inside your own network, that question is answered by broadcast, because broadcasting is cheap there. The Address Resolution Protocol[^8] asks it directly:

host A wants to send to 192.168.1.50, and does not know the MAC

A ──▶ everyone on the LAN: "who has 192.168.1.50? tell a4:83:e7:11:22:33"
50 ──▶ A: "that's me"
A   records the answer in its ARP cache, and sends the frame

The result is cached, so the question is asked once per address rather than once per packet. That cache is the reason ARP is invisible in normal use and briefly visible when you open a terminal and run arp -a.

Two things worth knowing about this design. If the destination is not on your own network, A does not resolve the destination at all: it resolves the default gateway[^9], the machine that forwards traffic off the local network, which is why the first ARP request after you open a browser is always about your router. And because ARP replies are unauthenticated, a machine on the same network can answer for anyone, forging MACs. This is one of the oldest tricks on the internet, and it is one reason the security post exists.

IPv6 does not use ARP. Neighbors are discovered with a protocol built on multicast, so a machine can ask only the machines that could plausibly be the answer, and nobody on the network has to see the question.

Wi-Fi is a link layer too

Everything above applies to wireless, with one structural difference that explains everyday Wi-Fi behavior: there is no cable, so there is no dedicated wire per machine and no switch. Every device on a Wi-Fi network shares one radio channel[^10].

Sharing a medium means collisions, and collisions cannot be detected by listening while transmitting, because a radio cannot hear itself clearly. So Wi-Fi cannot use the wired approach of detecting a collision after the fact. It avoids them instead, using carrier sense multiple access with collision avoidance: listen before speaking, wait a randomized amount, transmit, and if you did not hear an acknowledgement, assume it collided and back off exponentially. Acknowledging every single frame is the price of a shared, invisible medium.

A wired switch gives each machine a private lane. A Wi-Fi access point gives everyone the same lane, so the protocol has to behave politely.

VLANs: networks inside the network

A single physical switch can host several logical networks. VLANs[^11] tag frames with a small identifier so the switch keeps the groups apart, so a port for accounting machines and a port for guest Wi-Fi can sit in the same switch and never talk.

one physical switch
   ├── VLAN 10: employees
   ├── VLAN 20: servers
   └── VLAN 30: guest Wi-Fi      (isolated by tag, not by cable)

This is the "virtual" in virtual local area network. It also previews the next post's world: once you can carve a switch into logical networks, you start wanting a layer that does the same across an entire globe, and the machine that does that is a router.

The big picture

Layer two delivers frames to the neighbor, and only the neighbor. It addresses machines with flat, meaningless 48-bit MAC addresses, wraps the payload in a frame with type, padding, and a checksum that detects errors without ever repairing them, and moves frames with a switch that learns which port belongs to which machine from the frames it already sees, giving each machine its own collision domain and full duplex. ARP bridges the IP world to the MAC world by asking the whole local network and caching the answer. Wi-Fi runs the same layer over a shared radio, which is why it avoids collisions instead of detecting them.

layer 3: "192.168.1.50"          the address that means something
   ↓ ARP: who owns that IP?      the local question
layer 2: "a4:83:e7:11:22:33"     the address on this wire
   ↓ switch forwards, physical signals
destination machine

One hop, one address, one wire. The next post takes the packet that link layer carries and asks the hard question: how does it get from that machine to one on another continent?

[^1]: MAC address - Wikipedia

[^2]: Ethernet frame - Wikipedia

[^3]: Maximum transmission unit - Wikipedia

[^4]: Frame check sequence - Wikipedia

[^5]: Collision domain - Wikipedia

[^6]: Network switch - Wikipedia

[^7]: IP address - Wikipedia

[^8]: Address Resolution Protocol - Wikipedia

[^9]: Default gateway - Wikipedia

[^10]: Wireless network - Wikipedia

[^11]: Virtual LAN - Wikipedia

The Physical Layer & Signals

Wed, 23 Sep 2026 00:00:00 GMT

The TCP/IP post ended with a promise to drop to layer one. So here we are at the bottom: no addresses, no packets, no protocols, no error handling, no idea what the bits mean. A voltage is high or low, a light pulses or does not, a radio wave is at one frequency or another. Everything the internet is, down here is just physics, and physics has rules. This post opens them: what a bit becomes on a wire, what the media can and cannot carry, the two numbers that describe a road, and why moving a single bit is harder than it looks.

A bit is not a number, it is a signal

A bit is an abstraction. On the wire it is never a number, only a physical difference that the receiver has to interpret.

logical bit:      1        0        1        1        0
on copper:       +2.5V   -2.5V   +2.5V    +2.5V   -2.5V
on fiber:         light    dark    light    light    dark
on radio:         shift   no shift  shift   shift   no shift

Two machines agree beforehand on what counts as a 1. That agreement is the only reason the same bytes mean the same thing everywhere. Change the encoding and the bytes change meaning, which is why older Ethernet standards had to stop transmitting preamble bytes when they changed the signaling scheme: to old receivers those bytes would have looked like data.

A bit on the wire is a promise that the receiver will read it back the same way. Everything above layer one is bookkeeping on top of that promise.

The crucial thing to internalize: a bit is analog. The voltage drifts, the light dims, the wave picks up noise. The receiver does not read a bit; it decides, with a threshold and a guess, that a bit was there. It sometimes guesses wrong. Layer one offers no guarantee whatsoever, and that is exactly why layer two exists.

Guided media: signals inside something

Guided media[^1] carry signals inside a physical path: the signal has nowhere to go but forward.

Twisted pair[^2] is the reason your house has ethernet ports. Two insulated copper wires carry opposite signals and twist around each other. The twist looks decorative and is not: each twist makes the interference each wire receives at a slightly different time, so the noise partially cancels out, the same idea as noise-canceling headphones. Copper categories differ mainly in how tightly the pair is twisted and how well shielded the cable is, which is why "Cat 6" is not just marketing.

Limits come from physics, not standards:

Distance: the signal weakens with every meter, and eventually the receiver cannot tell a 1 from a 0. That is why copper runs stop at 100 meters.
Crosstalk: a fast-changing signal leaks into neighboring pairs. Better twisting and shielding reduce it; higher frequencies leak more, which is why high-speed standards are fussier about cable quality.
Interference: motors, fluorescent lights, and other cables all add noise.

Coaxial cable[^3] puts one conductor inside another with insulation between them. The shielding makes it far less noisy than twisted pair, which is why it survived for cable television and early Ethernet, and why it still dominates long cable runs in some countries.

Fiber-optic cable[^4] carries light through a glass strand thinner than a human hair. The interesting part is why the light stays inside the fiber at all. The core and the cladding have slightly different refractive indices, and light hitting the boundary at a steep angle reflects back inside, a phenomenon called total internal reflection[^5]. The fiber acts as a light pipe, bouncing light along internally.

copper:  electricity  →  needs a wire, limited by noise and distance
fiber:   light        →  no electricity in the path, immune to
                         electrical interference, tiny loss over
                         kilometers

Fiber's practical consequence is scale. It carries data for tens of kilometers before any regeneration, uses far less power than electrical repeaters, and supports wavelengths beyond visible light so many independent channels share one strand, each carrying more than a hundred gigabits per second. This is why undersea cables carry almost all intercontinental traffic, and why "the cloud" has a physical shape: long glass lines drawn across ocean floors, landing in a handful of coastal buildings.

Real example: between two cities, a fiber backbone may carry hundreds of thousands of concurrent video calls, while the copper from your home to your provider's cabinet may manage a few hundred megabits. Same internet, different material, different physics.

Unguided media: signals through the air

Unguided media[^6] have no path. The signal radiates and arrives wherever it arrives, which buys mobility and costs control.

Everything wireless is a slice of the radio spectrum[^7], a limited range of frequencies handed out by regulators because radio waves from different users interfere if they overlap. Within a slice, the trade is always the same: higher frequency carries more data but travels less far and is stopped by walls more easily.

Wi-Fi[^8]: short range, high speed, walls are enemies. It powers local networks.
Cellular: the same idea in cells that hand phones from tower to tower as they move, tuned by frequency: low bands reach far, high bands go fast and stop at the next building.
Microwave and satellite: line-of-sight beams and orbital relays for distances where cable is impossible. A satellite link is famous for a property that will appear in the next post: about 300,000 km round trip, and a speed of light that refuses to negotiate.

Wireless is not "slower internet". It is the same bits through air, and air is a harder medium than glass.

Two numbers that decide everything

Two words describe a road, and confusing them makes conversations about internet speed pointless.

Bandwidth[^9] is how much data fits per second, measured in bits per second or multiples of it. It is the width of the pipe.

Latency[^10] is how long one piece of data takes to arrive, measured in milliseconds. It is the length of the pipe.

a fat, short pipe      → fast throughput, quick answers
a thin, long pipe      → slow throughput, slow answers
a fat, long pipe       → fast throughput, slow answers
                        (this is the common real-world surprise)

Fiber and long distances are why the first two rows are not the two things you get. Seattle to São Paulo is one of the shortest intercontinental routes and still costs about 120 ms each way, and no amount of bandwidth improves it, because the light is already taking as long as it takes. That delay is why video calls feel awkward and why players on other continents are tough.

The two combine into a number that decides how much you can have "in flight" at once. The bandwidth-delay product[^11] is bandwidth times round-trip time, and it is the amount of data that fits in the pipe between a request and its answer.

100 Mbps × 100 ms = 10 Mbit ≈ 1.25 MB in flight at once

that is why throughput feels capped when latency is high,
even on a very fast connection

Modulation: putting bits on a wave

Sending a stream of 1s and 0s is one option. Real links do something more efficient: they let bits change properties of a wave, a technique called modulation[^12].

amplitude:  change the strength of the wave
frequency:  change how fast it oscillates
phase:      shift where the wave starts

Early schemes changed one property per bit: on-off, a shift in frequency, a shift in phase. QAM, used everywhere from cable modems to Wi-Fi, changes amplitude and phase together, so one symbol carries several bits. The efficiency is not free: denser constellations need cleaner signal, so higher-order modulation works close to the transmitter and falls apart with noise and distance.

Digital links have a second problem: the receiver must know where each bit starts. A long run of identical bits gives nothing to synchronize against. Line encodings solve it by adding structure: Manchester encoding[^13] guarantees a transition in every bit period, using it to mean both the value and the clock.

NRZ:        1 1 1 1 0 0 0        ← long runs, no way to resync
Manchester: ↑↓ ↑↓ ↑↓ ↑↓   ↑↓      ← a transition every bit

Layer one is the only layer where physics dictates the vocabulary. Everything above can be renamed by a committee. Voltages and frequencies cannot.

Attenuation, noise, and the end of the road

Every signal on every medium gets worse as it travels, through two named effects.

Attenuation[^14] is loss of strength with distance: the wave simply weakens. Noise[^15] is anything else added along the way that was not part of the message, from electrical interference to thermal jitter to another radio station.

Both are cumulative, which is why physical limits exist and why cables are sold in categories. Three techniques push the limit rather than eliminate it:

Amplification boosts the signal, and also boosts the noise along with it. It works a few times, then the noise dominates.
Regeneration (repeaters, and later regenerators) reads the signal, decides what it was, and transmits a clean fresh copy. This is the only technique that truly resets the damage, and it is why copper links have repeaters every hundred meters and fiber has none for tens of kilometers.
Coding and equalization spend extra bits to undo predictable damage. This is why a modern copper or radio link can move more data through a worse channel than an old one did.

The big picture

A bit is a signal, not a number: a voltage, a pulse of light, or a shift in a wave, all of them analog and all of them read by a receiver making a threshold guess. Guided media (twisted pair, coaxial, fiber) move that signal inside a path, limited by attenuation, crosstalk, and distance; unguided media (radio, microwaves, satellite) radiate it, trading reach for speed. Bandwidth and latency are different numbers, and a fat long pipe gives you both a fast download and slow answers. Modulation puts many bits in each symbol, line encodings keep the receiver in sync, and regeneration is the only thing that truly undoes accumulated damage.

sender: bits → symbols → modulation → signal
                                    ↓  copper · glass · air
receiver: signal → threshold decision → bits
                    (sometimes wrong)

Nothing down here knows what your data is. The next post adds the first thing that does: addresses for the machine on the other end of this cable, and the switch that delivers a frame to exactly that machine.

[^1]: Guided media - Wikipedia

[^2]: Twisted pair - Wikipedia

[^3]: Coaxial cable - Wikipedia

[^4]: Fiber-optic communication - Wikipedia

[^5]: Total internal reflection - Wikipedia

[^6]: Unguided media - Wikipedia

[^7]: Radio spectrum - Wikipedia

[^8]: Wi-Fi - Wikipedia

[^9]: Bandwidth (computing) - Wikipedia

[^10]: Latency (engineering) - Wikipedia

[^11]: Bandwidth-delay product - Wikipedia

[^12]: Modulation - Wikipedia

[^13]: Manchester code - Wikipedia

[^14]: Attenuation (electrical networks) - Wikipedia

[^15]: Noise (electronics) - Wikipedia

The TCP/IP Stack Explained

Tue, 22 Sep 2026 00:00:00 GMT

The OSI post ended with a promise: the model is a map, but there is a machine actually making the journey. That machine is TCP/IP, and it is a strange piece of history: the seven-floor design that lost became the most successful networking architecture ever built, because the four-floor design that won shipped first. This post opens the real stack: the four layers your bytes travel through, how layers point at each other, the idea of an internet as a network of independent networks, and the two decisions that explain everything else.

The stack that actually runs

Where the previous post had seven floors, TCP/IP has four. The two OSI floors that turned out to be unnecessary are gone, and the rest are renamed after what they actually do.

4  Application     your program's language       HTTP, DNS, TLS, QUIC
3  Transport       deliver to the right program  TCP, UDP
2  Internet        address and route across      IP, ICMP, routers
1  Link            address and deliver nearby   Ethernet, Wi-Fi, ARP

Mapping the two models onto each other explains most of the disagreements you will hear about:

OSI                TCP/IP
Application   7  ┐
Session       5  ├─ Application    4   (HTTP, DNS, plus
Presentation  6  ┘                  │    TLS and QUIC)
Transport     4     ─────────────── 3   (TCP, UDP)
Network       3     ─────────────── 2   (IP, ICMP)
Data link     2     ─────────────── 1   (Ethernet, Wi-Fi)
Physical     1     ─────────────── 1   (folded into the link layer)

Session and presentation disappeared because nobody could agree on what belonged in them, and every real implementation ended up doing the same job somewhere else. Encoding, compression, and encryption live inside libraries and protocols now, not in a layer of their own.

Physical folded into the link layer because on any real machine, the driver that talks to the network card handles both. You do not choose a "physical layer" separately from the driver that programs the card. Layer 1 is the wire; layer 2 is the code that puts frames on it.

QUIC complicates the picture. HTTP/3 runs its own reliability on top of UDP inside what looks like the transport layer, which is why some diagrams draw five layers. This series keeps the four-floor picture and treats QUIC as what it is: an exception that proves the rule.

How layers point at each other

The encapsulation post showed headers being added, but not how a receiver knows which header to read. Each layer tags its data with an identifier so the layer below can tell what is inside. There are three of these identifiers, and they are why everything interoperates.

EtherType[^1]: a number in the Ethernet header saying "the payload is IPv4", "IPv6", or "ARP".
Protocol number[^2]: a byte in the IP header saying "the payload is TCP", "UDP", or "ICMP".
Port number[^3]: a 16-bit number in the transport header saying "this belongs to the web server, 443".

frame  →  EtherType 0x0800   →  IP
packet →  protocol 6          →  TCP
segment→  port 443            →  the web server

Every packet carries the whole chain, because the receiving host receives one layer at a time, unwraps, and needs to know what to unwrap next. A host can read a header, recognize what is inside, and only then decide which of its own modules should handle it. This is why you can add a new protocol on the application layer and old machines still deliver your packets correctly: they read "TCP" in the IP header, deliver to TCP, and let TCP deliver to your new port.

An internet, not a network

The word matters. A network connects machines under one owner. An internet connects networks, each owned by someone else, and promises only to cooperate.

your laptop ── home network ── ISP network ── IXP ── Google network ── server
              (owned by you)  (owned by     (a         (owned by      (owned by
                                your ISP)    switch)    Google)        Google)

No machine in this drawing is in charge. Routers do not know the whole path to your destination, and they do not need to: each router only needs to know which next hop is closer to the destination than it is. That is called hop-by-hop forwarding, and it is the difference between a network that needs a map and an internet that needs a neighbor.

The internet does not know where anything is. Every router knows only which road to take next. The route emerges from millions of partial answers.

This also means the internet has no natural owner, no address of record, and no place where a message "arrives at the internet". There is no such machine. There are only cooperating networks, each making a locally reasonable forwarding decision, exactly the way the operating system makes locally reasonable scheduling decisions about a hundred processes.

Rules that let strangers cooperate

For networks owned by strangers to interoperate, the rules cannot be invented per network. They are written down, publicly, and numbered. That is the request for comments (RFC)[^4] system: documents that begin as proposals, gather review from anyone, and become the standards that everyone implements. The internet's rules live in the RFC series, and a famous early one, RFC 791, defines IP.

The culture around those documents became famous too, from the rules of RFC 817[^5] for writing them: it required a section on consistency with other RFCs and documentation of the rationale, and in the same spirit of practicality, its authors declared that "no kings, no presidents, no voting" and that trivial objections should be dismissed with "we reject: your reasoning is bad". Standards get written by the people who have to implement them.

Real-time systems have standards written by vendors. The internet has standards written by users. That difference is not trivia; it is why the internet won.

The end-to-end principle

The second decision that explains everything is a rule about where functions live, usually called the end-to-end principle[^6]: put a function at the ends of the network whenever you can, and keep the middle dumb.

The argument: the middle of the network only knows how to move packets. It cannot know whether those packets carry a video, a bank transfer, or a text message, and any function placed there can only be correct for some applications and wrong for the rest. So the middle moves bytes, and the meaning lives in software at the endpoints, which both ends control.

This is why the web needed almost nothing from the network. The network delivers unreliable packets; HTTP and TCP at the ends turn that into a page. It is also why a new service can be invented, like video calls, without asking anyone's permission: the network did not change at all.

It also predicts where new ideas land. Peer-to-peer file sharing needed a hole puncher in the middle and the logic at the ends. Encrypted traffic needed the endpoints to agree on keys and little help from the middle. Every time the ends can solve it, the solution goes in the ends.

Why TCP/IP won

OSI was, by its own designers' account, a better design: it separated concerns more finely and defined interfaces more precisely. TCP/IP was cruder: four layers, session and presentation dropped, and the "interface" between layers left to each operating system to implement as it saw fit.

TCP/IP still won, for reasons that have little to do with elegance:

It shipped first. Real implementations existed while the OSI debate was still running.
It was minimal and permissive. A host that ignored a layer could still interoperate, which is unusual generosity for a standard.
The end-to-end rule made it extensible. New applications needed no network changes, so the stack stayed put while everything above it exploded.
Adoption followed use. Everyone implemented it because everyone was implementing it, and the internet reached critical mass decades before a competing stack could.

The OSI model survives as vocabulary, which is the best ending a losing design can get.

The big picture

TCP/IP is four layers: application, transport, internet, link. Ethernet types, protocol numbers, and port numbers let each layer hand off to the next, so new protocols can be added without touching the ones below. An internet is a network of independently owned networks connected by routers that know only the next hop, which is why nobody needs a map of the whole world. RFCs write the rules that strangers follow, and the end-to-end principle keeps the middle dumb and the meaning at the ends.

your program
  ↓ application: HTTP, DNS, TLS
  ↓ transport:   TCP, UDP (reliability, ports)
  ↓ internet:    IP (addresses, hop-by-hop routing)
  ↓ link:        Ethernet, Wi-Fi (neighbors, frames)
  ↓ the wire

Everything above is a promise about what happens after the bits are gone. The next post drops to layer one: what a bit actually is on a copper pair, a fiber strand, or a radio wave, and why moving a bit is harder than it sounds.

[^1]: EtherType - Wikipedia

[^2]: List of IP numbers - Wikipedia

[^3]: Port (computer networking) - Wikipedia

[^4]: Request for Comments - Wikipedia

[^5]: RFC 817 - Wikipedia

[^6]: End-to-end principle - Wikipedia

The OSI Model & Encapsulation

Mon, 21 Sep 2026 00:00:00 GMT

The networks overview ended with a stack of layers and a promise: each layer adds one guarantee, from volts to web pages. But that drawing was a sketch. Somebody chose those layers, counted them, named them, and wrote them down. This post opens that document. The seven-layer model everyone half-remembers from school, what each floor is actually responsible for, and the single mechanism that makes layering work: wrapping data in headers on the way down and unwrapping it on the way up.

The model came before the network

In 1979, before the internet existed as a public network, the International Organization for Standardization published a reference model for how a network should be divided into layers: the OSI model[^1]. Its authors were not describing the existing world. They were arguing about how it ought to be built, and they argued about it for years, mostly about how many floors a building should have.

OSI was a design document, not a description. The interesting part is not that it failed. It is that the diagram outlived every attempt to build it exactly.

The model's purpose was to let two teams write different layers independently and still fit together, the same way a CPU ISA lets hardware teams and software teams work apart. It is a logical model: an agreed way to name responsibilities, not a list of products.

What a layer is

A layer is one job, with three obligations:

Service. It offers a capability to the layer above. "I will deliver these bytes to a machine on my local network."
Interface. It tells the layer above how to request that service. Not "what I do inside", just "how to ask".
Layer below. It gets its work done using the layer below, and stays ignorant of how.

The rule that makes this cheap: a layer never needs to know how the layer below works, and never needs to know why the layer above called it.

Think of an envelope inside an envelope inside an envelope. You write a letter, put it in an envelope addressed to a building, put that in a bag addressed to a city, and hand it to the postal service. Nobody in the chain needs to read the letter to move it one step.

The seven layers

7  Application    what the program wants          HTTP, DNS, SMTP
6  Presentation   format, encrypt, compress       TLS, JPEG, encoding
5  Session        start, keep, end conversations  sessions, RPC
4  Transport      deliver to the right program    TCP, UDP, ports
3  Network        find a path across networks     IP, ICMP, routers
2  Data link      deliver to the neighbor          Ethernet, MAC, switches
1  Physical       move bits as signals            cables, radio, fiber

The numbering counts from the bottom because layer 1 is closest to the wire. Here is each floor in one honest sentence, before this series opens them one by one.

7 Application. The layer your program actually talks to. You call a function like "send this HTTP request" and the network world takes it from there. No other layer is ever visible to your code.

6 Presentation. Translation between what the program means and what the wire can carry: character encodings, compression, and encryption. TLS usually lives here in textbooks, which is why TLS placement causes arguments. In practice encryption can sit in several places, and HTTP/3 puts it below the application inside QUIC.

5 Session. Opening, maintaining, and closing a conversation between two programs, plus the dialog rules that keep it orderly. Half of this layer was quietly absorbed into the transport layer, and authentication services moved here.

4 Transport. End-to-end delivery between two programs, identified by port numbers. This is where reliability, ordering, and flow control live, and where TCP and UDP sit.

3 Network. Addressing across the whole world and choosing a route, hop by hop, through machines you do not control. This is where IP and routers live.

2 Data link. Reliable delivery across a single hop, to the machine on the other end of this cable, using hardware addresses. This is where Ethernet frames and switches live.

1 Physical. Bits as electricity, light, or radio waves, plus the media that carry them and the noise they fight.

Real example: when your code calls an HTTP library, layers 7 down to 1 become one continuous pipeline. You never see them, but every byte you send passed through all seven, and every byte you receive passed back up through all seven.

Encapsulation: the wrapping

Here is the mechanism the whole model rests on. As data moves down the stack on the sending side, each layer adds its own small header, called a header[^2], and passes the result to the layer below. The payload of the layer above becomes the data of the layer below.

sending side, going down:

[ HTTP GET /index.html ]                  layer 7: data
[ TCP | port 443, seq 1 | HTTP GET ... ]  layer 4: segment
[ IP | to 93.184.216.34 | TCP | ... ]     layer 3: packet
[ Ethernet | to aa:bb:cc... | IP | ... ]  layer 2: frame
1 0 1 1 0 0 1 0 0 1 1 0 0 0 0 0 0         layer 1: bits

Each header answers a question the layer below cannot ask the sender. The IP header says where the packet is going. The Ethernet header says which machine on this cable should take it. The TCP header says which program on that machine should get the bytes, and whether they arrived. That is encapsulation[^3].

On the receiving side the process runs in reverse. Each layer reads its own header, uses it, and strips it before handing the rest up, which is decapsulation. The application at the top never learns that a frame ever existed.

receiving side, going up:

1 0 1 1 0 ...                    layer 1: bits
[ Ethernet | IP | TCP | HTTP ]    layer 2: read MAC, drop header
[ IP | TCP | HTTP ]              layer 3: right host? drop header
[ TCP | HTTP ]                   layer 4: right port? reassemble, drop header
[ HTTP GET /index.html ]         layer 7: the request, reassembled

Encapsulation is why you can swap Wi-Fi for a fiber link without changing a single line of your program: the layers above never looked inside.

PDUs: what each layer's data is called

The data at each level has its own name, called a protocol data unit[^4] (PDU). The names are not important to memorize, but the pattern is: the more a layer knows about the journey, the more meaningful its unit becomes.

Layer	PDU name	Carries
7-6	Data / message	what the program means
5	Data	an open conversation
4	Segment (TCP)	bytes for one program
4	Datagram (UDP)	one independent message
3	Packet	bytes for one host, across hops
2	Frame	bytes for one neighbor
1	Bits	1s and 0s

Why the model won even though the plan lost

No product ever implemented all seven layers as separate pieces of hardware and software. TCP/IP, which the next post opens, does the same job in four floors, folds session and presentation into the application layer, and never heard of the OSI model except to argue with it.

Yet nobody deletes the diagram. Three reasons:

It names responsibilities. When something breaks, "is this a link problem or a transport problem?" is a real, useful question, and the model supplies the vocabulary to ask it.
It keeps layers honest. Every layer must add something, or it should not exist. Applying that test is how you find designs that pretend to be layered.
It travels. The model outlived every piece of 1980s networking hardware and is still the fastest shared vocabulary in the industry.

The layers in this series follow the real four-floor stack, because that is what your bytes actually travel through. Where OSI is useful, this series names it, and it does not spend a post on floors that turned out to be empty.

The big picture

A layer is one job with a service, an interface, and no curiosity about its neighbors. OSI proposed seven such layers, from moving bits to speaking a program's language. Encapsulation is what holds them together: going down, each layer wraps the data above in a header answering one more question; coming up, each layer reads and removes its own header. Each layer's output is the next layer's input, which is why the layers can be built by different teams, replaced one at a time, and still fit.

program's data
  ↓ wrap    ┌─ transport: for which program?
  ↓ wrap    ┌─ network: for which host, across the world?
  ↓ wrap    ┌─ link: for which machine on this cable?
  ↓ wrap    └─ physical: as signals
bits → signals → frame → packet → segment → data

The model is a map. The next post opens the machine that actually runs the journey: the four layers of TCP/IP, the standard that won, and the philosophy that let a network of networks exist at all.

[^1]: OSI model - Wikipedia

[^2]: Header (computing) - Wikipedia

[^3]: Encapsulation (networking) - Wikipedia

[^4]: Protocol data unit - Wikipedia

Networks Explained

Sun, 20 Sep 2026 00:00:00 GMT

The input and output post named the network card as a device that is input and output at the same time, and left it there. The operating system post showed the kernel talking to that card like it talks to a keyboard or a disk. Neither post asked the obvious question: who is on the other end? This post opens the world outside the machine. What a network actually is, why machines share a road instead of owning it, and the problem that every layer of the next nine posts exists to solve.

What a network is

A computer network[^1] is two or more machines connected together, able to exchange information. That is the whole definition, and it sounds trivial until you count what it hides.

A node is any machine with a network address: your laptop, a phone, a printer, a router, a server in a data center. A link is the road between two nodes: a cable, a radio wave, a fiber strand, a satellite hop. A protocol[^2] is the agreement on how bits turn into meaning on that road. Two machines speaking different protocols on the same wire hear only noise.

A network is not the cable. The cable is just copper or glass. The network is the agreement plus the addressing plus the machinery that delivers bytes to the right machine.

node ──── link ──── node
 │                      │
 └── same protocol ─────┘

The machine inside your laptop is already a full computer with its own memory and CPU. A network does not merge those machines into one super-computer. It gives each one a way to say "send these bytes over there" and to receive bytes meant for it. Isolation stays; communication is added.

Real example: when you print a document, your laptop does not become part of the printer. It sends bytes to the printer's address, and the printer pulls them out of its own memory buffer. Two computers, two memories, one agreed road.

Why not connect every machine to every machine

The naive way to link five machines is a dedicated cable between each pair: 5 × 4 ÷ 2 = 10 cables. Twenty machines need 190. A thousand machines need half a million. Every port and every cable is a cost, a failure point, and a configuration headache. No network ever shipped this way.

The fix is the same idea as a street system: do not build a private road between every pair of houses. Build shared roads, give every house an address, and let the roads carry everyone's traffic.

naive:      A ─ B   A ─ C   A ─ D   B ─ C   B ─ D   C ─ D
shared:     A ─┐
                ├─ shared road ─┬─ B
             C ─┘               └─ D

Now the number of links grows with the number of machines, not with its square. Somebody still has to do the work of reading the destination address and forwarding each message: that somebody is a router[^3], and the machine that gives your laptop its first step onto the road is a switch. The rest of this series is about the layers of machinery that make one shared road serve millions of machines at once, reliably.

Two ways to share a road

When many senders want one road, there are two classic answers.

Circuit switching[^4] reserves the road for one conversation at a time. You get a dedicated path for the whole call, nobody else can use it, and the order of your data is guaranteed. The telephone network worked this way for a century. The cost is obvious once you notice it: the reserved parts sit idle whenever you are not talking. A voice call uses maybe 20% of a reserved circuit in each direction, and the other 80% is wasted capacity that no one else is allowed to touch.

Packet switching[^5] shares the road by chopping the data into small pieces called packets[^6]. Each packet carries its destination address and travels independently. Many senders interleave their packets on the same road, and the receiver reassembles them in order.

circuit switching:
sender ────────────────► receiver      (the whole road, reserved)

packet switching:
A: [p1][p2][p3]   B: [q1][q2]   C: [r1]
   [p1] [q1] [p2] [r1] [p3] [q2]      (one road, many senders)

Packet switching wins because it never reserves anything. The road carries whatever anyone has to send, and idle capacity is used by the next packet. It also lets packets from the same sender take different routes across the internet, a property that turns out to be a feature rather than a bug.

But the freedom has a price, and this price is the reason the internet needed most of this series:

Packets can be lost. Memory and queues are finite; a burst of traffic overruns a router and something has to be dropped.
Packets can arrive out of order. Two packets take two paths or two turns in a queue.
Packets can be duplicated. A router unsure whether a packet arrived may send it again.
Packets can be corrupted. Noise on the wire flips bits.

So the network itself is best effort: it makes no promises. It carries what it can and shrugs at the rest. Every layer above it exists to build the guarantees that best effort refuses to give.

The internet is not a reliable network that sometimes fails. It is an unreliable network that applications have learned to make reliable.

Topology: how machines are wired together

Network topology[^7] is the shape of the connections: who is wired to whom. A few shapes recur.

bus:         A ─ B ─ C ─ D        (everyone shares one cable)
star:        A ─┐
                 ├─ (hub/switch)
              B ─┘
mesh:        A ─── B
             │  ╲ │  ╱
             │    ╳
             │  ╱ │  ╲
             C ─── D

The bus was the first cheap answer: one cable, every machine taps it, everyone hears everything. It collapses when a cable breaks or two machines transmit at once, because signals collide. The star fixes that with a central box, and it won. Modern home and office networks are stars: every machine has its own cable to a switch, which is a box that learns addresses and forwards each frame only where it is needed. The mesh survives any single failure because there is no single point of failure, which is why it shows up between routers and data centers rather than between laptops.

Note what the star really is: one shared medium, split into private lanes. Each machine gets a dedicated cable into the switch, and the switch makes sure no two machines speak at the same time on the wire. Contention does not disappear in a star; it moves inside the box, where it can be managed.

The core problem networks solve

Every network, from two laptops with one cable to the entire internet, is solving the same set of problems. It is worth naming them now, because each later post is the answer to one of these lines.

Naming and addressing: who is the machine I want to talk to, and how does my data carry that answer?
Delivery: given an address, how does the data travel across a road that may not lead there, over hops that belong to other people?
Reliability: the road loses and reorders packets. Who notices, and who sends them again?
Sharing: one road, many senders, and a way to take turns without anyone starving.
Governance: no one owns the internet. Millions of independent networks agree to carry each other's traffic and to be polite about it.
Security: strangers share the same road. How do you keep them from reading or changing what is not theirs?

That last set is why a network is not just fast wires. Speed is the easy part.

Why a network is not one big machine

There is one more design decision before the layers, and it is the one this series is really about.

One plausible design: a single protocol that does everything. Name resolution, routing, reliability, encryption, the web. One code path, one place to debug.

It does not work. Every use is different: a video game cannot wait for lost packets, a file transfer must, a printer needs a language nobody else speaks. One protocol for all of them forces every case to pay for every feature.

So networks are built in layers. Each layer offers a service to the layer above and uses the layer below without knowing how it works. The link layer delivers bytes to the neighbor. The network layer finds a path across the world. The transport layer makes delivery reliable for one program. The application layer speaks the language your program actually wants.

your program:      "get me this page"
   ↓
application:       HTTP request
   ↓
transport:         reliable bytes to one program
   ↓
network:           packets across every hop
   ↓
link:              frames to the next machine
   ↓
physical:          volts on a wire

Each layer gets to be simple because it trusts the layer below. And each one can be replaced, improved, or ignored without rewriting the others, which is exactly why the internet kept working while everything got replaced.

The physical layer is not at the bottom of importance, only at the bottom of the stack. It still decides whether your video works.

Real example: when Wi-Fi got faster, the link changed and almost nothing above it did. When TCP was replaced by QUIC in HTTP/3, the physical layer never heard about it. Layering is not bureaucracy; it is what let the internet survive five decades of replacing every part.

The big picture

A network is machines plus roads plus agreements. Wiring every pair directly does not scale, so machines share roads with addresses, and routers do the forwarding. Sharing a road means chopping data into packets that may be lost, reordered, duplicated, or corrupted, so the network itself promises nothing. On top of that best effort, layers each add one guarantee, from "these bits reach the neighbor" up to "here is your web page".

nodes + links + protocol
  ↓
shared roads, addressed (routers forward)
  ↓
packets: lossy, out of order, duplicated
  ↓
layers, each adding one guarantee
  ↓
programs that can rely on something

The next post opens the model that organizes those layers, the famous seven-floor list everyone half-remembers from school, and what actually happens to your data each time it crosses one.

[^1]: Computer network - Wikipedia

[^2]: Network protocol - Wikipedia

[^3]: Router (computing) - Wikipedia

[^4]: Circuit switching - Wikipedia

[^5]: Packet switching - Wikipedia

[^6]: Network packet - Wikipedia

[^7]: Network topology - Wikipedia

From Power-On to main()

Thu, 17 Sep 2026 00:00:00 GMT

Every post in this series assumed a running kernel: processes scheduled, pages translated, files mounted, devices humming. The I/O post named the missing piece explicitly: RAM is empty at power-on and no kernel exists anywhere. This capstone closes that gap and the two series with it. We will follow one press of the power button through firmware, bootloader, kernel startup, the first user process, the program loader, and the handoff to main, meeting every earlier post's machinery as it comes online.

Firmware: the first instructions

At power-on the CPU resets to a known state: caches cold, RAM empty and untested, devices uninitialized. It fetches from a hardwired address pointing at firmware[^1] in non-volatile memory (BIOS[^2] on old machines, UEFI[^3] on modern ones). Firmware runs before anything else exists: it tests RAM, enumerates devices, initializes DRAM controllers and clocks, and finds something bootable.

power ──▶ CPU reset vector ──▶ firmware (ROM/flash)
                                   │ POST, init RAM, enumerate
                                   ▼
                              find boot device

Firmware's last job is loading the next stage and jumping to it. The chain has begun: each stage just smart enough to load a smarter one.

Bootloader: the kernel's delivery service

The bootloader[^4] (GRUB, systemd-boot, phone bootloaders) bridges firmware and kernel. Firmware loads it; it understands filesystems (unlike firmware, which reads raw sectors or simple partitions), finds the kernel image and initial RAM disk, sets up the boot parameters and memory map, and transfers control. The two-stage trick exists because firmware stays small and dumb while the bootloader, living on disk it can update, carries the complexity.

On UEFI systems the path is standardized: firmware reads the EFI partition, executes the bootloader application, which calls back into UEFI services for disk and display until the kernel takes over and those services are abandoned (ExitBootServices). The machine is still single-tasked; no processes, no virtual memory, just code running on bare metal toward one goal.

Kernel startup: building the world

The kernel entry point runs the most delicate code in the system: no stack worth speaking of, no heap, no scheduler, no memory management yet. Startup builds every subsystem this series described, in dependency order:

entry ──▶ early page tables ──▶ memory allocator ──▶ interrupts & timer
              │                       │                      │
              ▼                       ▼                      ▼
        virtual memory on      kmalloc works          preemption possible
              │                       │                      │
              └───────────┬───────────┘                      │
                          ▼                                  ▼
                    scheduler + drivers + VFS ──▶ mount root ──▶ spawn init

Early page tables turn on virtual memory (the paging machinery now active for the kernel itself); the page allocator and slab allocator follow; interrupt descriptors and the timer IRQ enable preemption (the scheduler can now exist); drivers probe buses; the virtual filesystem layer mounts the root filesystem (the filesystems world now reachable). Each layer assumes only what came before, which is why the order is fixed.

Init: the first process

With the kernel alive, it becomes a process factory and manufactures process number one. On Unix the kernel spawns init[^5] (pid 1, systemd on most Linux systems); orphaned processes get adopted by it, which is why the processes post's reaping promise holds. Init mounts filesystems, starts services, and brings up login: the machine graduates from one kernel thread to a managed multi-process system. Everything you think of as "the OS running" is init's descendants, scheduled, isolated, and page-tabled exactly as earlier posts described.

Loader: from file to process

Starting your program replays process birth at full detail. The shell forks; the child calls exec on your binary; the kernel's loader takes over: parse the ELF[^6] headers, map code and data segments into a fresh address space, map shared libraries (or the dynamic linker that maps them), zero the BSS, allocate the stack with arguments and environment, set the entry point, and mark the process ready.

fork ──▶ exec("./app") ──▶ parse ELF ──▶ map segments + libraries
                                              │
                                              ▼
                              stack (argv, env) ──▶ jump to _start

_start is not your main. It is the C runtime's entry: set up the standard library, run global constructors, collect the exit code afterward. Its last act is calling your code:

_start: ──▶ __libc_start_main ──▶ main(argc, argv, envp) ──▶ exit(status)

Eight posts of machinery narrow to one function call. main returns, the runtime calls exit, the kernel reaps, the parent is notified. Birth to death, syscalls at both ends.

The big picture

Two series, one arc. The Computers Explained series built the machine: representation, logic, CPU, memory, storage, I/O, interconnects, and the stored-program idea that makes one machine every machine. The Operating Systems Explained series taught that machine to share: kernel and syscalls, processes, threads, scheduling, virtual memory, filesystems, I/O paths, and now the boot that starts it all. Press power and firmware wakes, the bootloader delivers, the kernel builds its world layer by layer, init fathers every process, the loader maps your bytes, and _start calls main.

Whatever you build on top, from Fibonacci to distributed systems, runs on this stack. The details will keep evolving: new firmware, new schedulers, new filesystems. The shape, stages loading stages until a program believes the machine is its own, will keep rhyming.

[^1]: Firmware - Wikipedia

[^2]: BIOS - Wikipedia

[^3]: UEFI - Wikipedia

[^4]: Bootloader - Wikipedia

[^5]: Init - Wikipedia

[^6]: Executable and Linkable Format - Wikipedia

[^7]: Booting - Wikipedia

[^8]: Power-on self-test - Wikipedia

[^9]: Initial RAM disk - Wikipedia

[^10]: _start - Wikipedia

I/O & Syscalls Explained

Wed, 16 Sep 2026 00:00:00 GMT

The filesystems post ended with an open thread: files live on disk, but programs read keyboards, screens, and sockets through the same syscalls. The hardware I/O post showed the device side (controllers, interrupts, DMA); this post shows the OS side. We will look at how syscalls cross into the kernel in practice, what blocking really means, the non-blocking and multiplexed alternatives, the layers of buffering along the way, and the full path of one read from program to platter and back.

Syscalls in practice: the cost of crossing

A system call crosses privilege levels: trap instruction, argument validation, mode switch, work, copy results back, return. The crossing costs hundreds of nanoseconds to microseconds, trivial once, significant a million times per second. Three techniques keep the bill down.

First, batching: the C library buffers. printf accumulates in userspace and issues one write for thousands of characters; malloc subdivides kernel pages so most allocations never trap. Second, vector I/O (readv, writev): one crossing moves many scattered buffers. Third, avoidance: vDSO maps a few read-only kernel results (time, CPU number) into userspace so gettimeofday often never traps at all.

program              libc                  kernel
printf("hi") ──▶  buffer it          ──▶  (nothing yet)
printf("ho") ──▶  buffer it          ──▶  (nothing yet)
fflush()     ──▶  one write(fd,"hiho")──▶  validate, copy, queue to device

Strace from the overview post shows the seam: every line is one crossing, with arguments, return value, and time spent. Reading strace output is reading the program's conversation with the OS, syscall by syscall.

Blocking I/O: sleep until ready

Blocking I/O[^1] is the default: a read on an empty socket suspends the thread until data arrives. The kernel parks the thread in the blocked state, schedules someone else, and wakes the sleeper when the device interrupts or the data lands. The thread pays nothing while waiting; the CPU stays busy elsewhere. Simple to program (code reads top to bottom), efficient under light concurrency, awkward at scale: ten thousand connections need ten thousand threads, each with its own stack and scheduling cost.

thread calls read(fd) ──▶ no data → BLOCKED, scheduler runs others
device interrupts ──▶ kernel copies data ──▶ thread READY → RUNNING, read returns

Blocking is honest waiting: the thread declared it cannot proceed, and the kernel believed it.

Non-blocking and multiplexed I/O: ask, don't sleep

Non-blocking I/O flips the contract: the call returns immediately, with data or with EAGAIN ("not ready, try later"). The thread never sleeps, but somebody must retry, which naive polling turns into a CPU-burning loop. The answer is I/O multiplexing[^2]: one syscall watches many descriptors and sleeps until at least one is ready.

// wait until some fds are readable, then handle only those
struct pollfd fds[] = {{fd1, POLLIN}, {fd2, POLLIN}};
poll(fds, 2, -1);
for (int i = 0; i < 2; i++)
    if (fds[i].revents & POLLIN)
        handle(fds[i].fd);

select and poll scan the whole set per call; epoll (Linux) and kqueue (BSD/macOS) keep the interest set in the kernel and report only changes, scaling to tens of thousands of connections. This is the engine inside nginx, Node.js, and every event loop: one thread, many sockets, wakeups only where work waits. Asynchronous I/O (io_uring on Linux) pushes further: submit operations through shared queues and harvest completions, batching submissions and avoiding per-operation syscalls entirely.

Buffers everywhere: the data sits still so it can move fast

Between program and device sit layers of staging memory, each hiding a speed mismatch:

Userspace buffers (stdio, language runtimes): coalesce tiny writes into few syscalls.
Page cache: the kernel keeps file data in RAM; reads hit cache instead of disk, writes land in cache and flush lazily (write-back). Most "disk" I/O never reaches any disk.
Device queues: the I/O scheduler orders pending requests (merge adjacent sectors, prioritize deadlines, keep the device streaming).

printf ──▶ stdio buffer ──▶ write() ──▶ page cache ──▶ I/O scheduler ──▶ device
           (userspace)        (kernel memory)            (queue)          (DMA)

Each layer answers the same question with more patience than the one above: wait a little, batch a lot, touch slow hardware rarely.

One read, end to end

Trace read(fd, buf, 4096) on a disk file, cache cold:

1. trap: validate fd, check permissions, find file offset
2. page cache lookup: miss → allocate page, queue device read
3. driver programs DMA: device copies blocks straight to RAM, CPU free
4. interrupt: transfer done → wake blocked thread
5. copy_to_user: page → program buffer, advance offset, return 4096

Five crossings of boundaries (user/kernel, cache/device, interrupt/thread), most of them invisible to the program, which slept through steps 2–4 and woke with bytes ready. Sockets differ in details (protocol stack instead of filesystem, network card instead of disk) but keep the shape: validate, buffer, queue, interrupt, wake, copy.

The big picture

Syscalls cost crossings, so libraries batch and vectors widen; blocking I/O sleeps honestly and scales poorly; non-blocking plus multiplexing (poll, epoll, io_uring) scales one thread to thousands of descriptors; buffers at every level trade patience for throughput; and one read descends through cache, driver, DMA, and interrupt before returning with bytes.

Every layer so far assumed a running kernel: processes scheduled, pages translated, files mounted, devices humming. None of it explains how the machine gets there from a dead power-on, with RAM empty and no kernel anywhere. Booting into the first process, and main(), is the capstone's subject.

[^1]: Blocking (computing) - Wikipedia

[^2]: I/O multiplexing - Wikipedia

[^3]: System call - Wikipedia

[^4]: Page cache - Wikipedia

[^5]: Direct memory access - Wikipedia

[^6]: Epoll - Wikipedia

[^7]: Kqueue - Wikipedia

[^8]: Io uring - Wikipedia

[^9]: Interrupt - Wikipedia

[^10]: Device driver - Wikipedia

Filesystems Explained

Tue, 15 Sep 2026 00:00:00 GMT

The virtual memory post ended with a boundary: RAM forgets and swap is scratch, so anything worth keeping needs a durable home. Disks hold blocks; humans want files with names, folders, and permissions that survive power loss. The bridge is the file system[^1]. This post opens it up. We will look at what a file really is, how directories map names to files, how the system survives crashes mid-write, who is allowed to do what, and the path a single open takes from name to bytes.

Files and inodes: names point at metadata

A file is two things: a name users see, and numbered blocks holding bytes. Between them sits the inode[^2] (index node): one record per file holding everything except the name itself (size, owner, permissions, timestamps, and pointers to the data blocks). Directory entries map names to inode numbers; the inode maps onward to blocks.

directory entry              inode 4217                 data blocks
/home/you/notes.txt ──▶  no. 4217 ──▶ size, owner, ──▶ block 91
                                         mode, times,     block 92
                                         pointers…        block 118

Separating names from metadata buys two features for free. Hard links are two names pointing at one inode: same file, two doors, edits visible through both, blocks freed only when the last name (and open handle) goes away. And renaming is cheap: it rewrites a directory entry, never moves bytes.

Large files need many pointers, so inodes layer them: a few direct pointers for small files, then indirect blocks (a block full of pointers), double-indirect, triple-indirect for the enormous. Small files cost one inode; huge files scale without changing the record's size.

Directories: tables all the way down

A directory[^3] is a file with a special format: a table mapping names to inode numbers. Opening /home/you/notes.txt walks the path component by component, starting from the root inode: look up home in /, get its inode, look up you in it, get that inode, look up notes.txt, arrive at inode 4217. Each step is a lookup in a table; the kernel caches recent translations (the dentry cache) so repeated walks stay fast.

/ (inode 2)         /home (inode 88)      /home/you (inode 301)
home → 88     ──▶   you → 301       ──▶   notes.txt → 4217

Mounting grafts one filesystem's tree onto another's directory: the mounted root covers the mount point, and paths cross the boundary invisibly. Your program sees one tree; the kernel sees a table of mounted filesystems stitched together.

Crash consistency: the write that was half done

Power can die between any two disk writes, leaving structures half-updated: a file's size bumped but its blocks unrecorded, an inode allocated but unlinked. The classic answer is journaling[^4]: write the intention to a sequential log first, then apply to the real structures, then mark the log entry done. After a crash, the kernel replays completed intentions and discards partial ones: every operation either happened or did not, never half.

1. journal: "create notes.txt → inode 4217, blocks 91–92"  (sequential, fast)
2. apply:   write inode, directory entry, bitmaps           (in place)
3. journal: mark done, reclaim log space
   ── crash anywhere ──▶ replay redoes step 2 or drops it

Alternatives trade differently. Copy-on-write filesystems never overwrite live data: they write new versions elsewhere and flip one pointer atomically, so the old tree is always intact (snapshots fall out naturally). fsck-style consistency checking scans and repairs after the fact instead of preventing damage. All three serve one contract: a crash may lose the last seconds, but never the filesystem's coherence.

Permissions: who may do what

Every inode carries an owner, a group, and mode bits[^5]: read, write, execute for user, group, and others (rwxr-xr-- reads as owner-all, group-read-execute, other-read). Directories reuse the bits with shifted meaning: read lists entries, write creates and deletes, execute traverses through. The kernel checks on every open: match the process's user and groups against the bits, allow or deny with EACCES.

-rw-r--r--  you  devs   notes.txt   (owner rw, group r, other r)
drwxr-x---  you  devs   project/    (group members enter, others barred)

Setuid, the set-group-ID bit, and the sticky bit extend the scheme (run-as-owner executables, shared-directory protections), and modern systems layer access-control lists for per-user entries beyond the three classes. Permissions are checked at open time against names; open file descriptors keep working even if the name is later unlinked, which is how safe temporary files and atomic replacement (write temp, rename over) work.

The big picture

Blocks become files through inodes (metadata without names), names resolve through directories (tables mapping to inodes, walked component by component), journaling makes updates atomic across crashes, and mode bits gate every open by user and group. One open call walks, checks, and translates; reads and writes then stream through the page cache to disk in the background.

But files are only half of I/O. Keyboards, screens, and sockets are not files on disk, yet programs read and write them through the same syscalls, blocking, waking, and moving bytes down to hardware that answers in interrupts. Unifying that path, and the syscalls that drive it, is the next post's subject.

[^1]: File system - Wikipedia

[^2]: Inode - Wikipedia

[^3]: Directory (computing) - Wikipedia

[^4]: Journaling file system - Wikipedia

[^5]: File-system permissions - Wikipedia

[^6]: Hard link - Wikipedia

[^7]: Directory entry - Wikipedia

[^8]: Copy-on-write - Wikipedia

[^9]: Fsck - Wikipedia

[^10]: Access-control list - Wikipedia

Virtual Memory Explained

Mon, 14 Sep 2026 00:00:00 GMT

The scheduling post decided who runs; this post decides what each runner sees. Every process believes it owns gigabytes of private, contiguous memory, yet there is one RAM shared among all tenants. The fiction is virtual memory[^1], and it also closes a loop opened two series ago: the CPU post waved at malloc as library bookkeeping over brk and mmap without explaining either. We will look at address spaces, paging and page tables, the TLB that makes translation affordable, page faults and swap, and finally how mmap, brk, and malloc fit together.

Address spaces: every process gets its own universe

An address space is the set of virtual addresses a process may use: its code, heap, stacks, shared libraries, and kernel mappings, each at fixed conventional places. The addresses are virtual: they name slots in the process's private universe, not bytes in RAM. The memory hardware translates every virtual address to a physical one on each access, consulting the current process's page table, and refuses translations the table forbids.

process A addresses        RAM                process B addresses
0x400000: code      ──▶  frame 91              0x400000: code ──▶ frame 12
0x7fff00: stack     ──▶  frame 7               0x7fff00: stack ──▶ frame 44
0x900000: (unmapped)──▶  fault                 (same numbers, other frames)

Same numbers, different frames, enforced by hardware. That is the whole isolation trick from the processes post, stated as mechanism: separate tables, separate worlds.

Paging: memory in fixed-size sheets

Paging[^2] divides virtual memory into fixed-size pages (commonly 4 KiB) and RAM into same-size frames. Each page maps to some frame, or to nothing, or to storage. The page table[^3] records the mapping plus permission bits (read, write, execute, user-accessible) checked on every access.

A virtual address splits into two halves: the page number selects the table entry, the offset selects the byte within the frame:

virtual address (64-bit, 4 KiB pages)
┌──────────────────────────────┬──────────────┐
│ page number (52 bits)         │ offset (12)  │
└──────────────┬───────────────┴──────┬───────┘
               ▼                      │
        page table lookup             │
        page 7 → frame 42, rw         │
               ▼                      ▼
        physical address = frame 42 + offset

Real tables are multi-level (four levels on x86-64): unmapped regions cost no table memory because whole subtrees are simply absent. Permissions ride along for free: mark code pages execute-but-not-write, mark kernel pages supervisor-only, and entire bug classes (overwriting code, user code reading kernel memory) die in hardware with a fault instead of silent corruption.

The TLB: making translation affordable

Translating every access through four table levels in RAM would multiply memory traffic severalfold. The translation lookaside buffer (TLB)[^4] avoids it: a tiny cache inside the memory unit holding recent translations. Common case, the translation hits the TLB and costs roughly nothing; rare case, the hardware walks the table, caches the result, and continues. Locality saves the day again: programs reuse pages, so a few dozen TLB entries cover most accesses.

The TLB explains two costs from earlier posts. Process switches must invalidate (or retag) TLB entries, since translations belong to one address space: part of the hidden price of a context switch. And huge working sets that thrash the TLB pay a walk per access, one reason large pages (2 MiB, 1 GiB) exist: fewer, bigger translations covering the same memory with fewer entries.

Page faults and swap: memory larger than RAM

A page fault[^5] fires when translation fails: the page is unmapped, protected, or not currently resident. Faults are not always errors. The kernel deliberately leaves pages non-resident and fills them on demand: the first touch of fresh memory, a page swapped out to disk, a file mapping not yet read, a copy-on-write page shared since fork. The fault handler finds a frame (evicting some victim page, writing it to swap space[^6] if dirty), loads the contents, updates the table, and resumes the faulting instruction as if nothing happened.

program touches page ──▶ TLB miss, table says "on disk"
                          │
                          ▼
                     fault handler: evict victim frame,
                     read page from swap/file, map it,
                     resume instruction

Eviction policy decides which victim to sacrifice: approximations of least-recently-used (clock algorithms) track usage bits the hardware sets, sweeping hands around a circular list. The catastrophic failure has a name: thrashing, when the working set exceeds RAM and every access faults, so the machine spends its time paging instead of computing. The cure is fewer tenants or more RAM; no algorithm outruns arithmetic.

mmap, brk, and malloc: where heap memory comes from

Now the loop closes. The kernel hands out memory in pages through two syscalls. brk (and sbrk) moves the top of the data segment, growing one contiguous heap region upward. mmap[^7] maps pages anywhere: files into memory, anonymous zeroed pages for fresh heap, shared regions between processes. Modern allocators use both: small allocations extend the brk heap, large ones get dedicated mmap regions (easy to return whole).

And malloc[^8] itself is not a syscall at all. It is library code managing those kernel pages: carving them into blocks, tracking free lists, splitting and coalescing, and calling brk or mmap only when its pools run dry. free usually returns blocks to the pool without telling the kernel, which is why process memory rarely shrinks after a spike. The CPU post's one-liner is now a full picture: conventions in userspace, pages from the kernel, translation in hardware.

The big picture

Virtual addresses name a private universe; paging maps it page by page with hardware-checked permissions; the TLB caches translations so the common case stays fast; faults fetch the missing pieces from swap or files on demand; and mmap plus brk supply the raw pages that malloc subdivides. Isolation, oversubscription, and on-demand loading all fall out of one table per process.

But RAM forgets and swap is scratch: neither keeps anything worth keeping. Programs that must survive power loss need names, folders, permissions, and crash-safe updates on persistent storage. That durable world, blocks into files, is the next post's subject.

[^1]: Virtual memory - Wikipedia

[^2]: Paging - Wikipedia

[^3]: Page table - Wikipedia

[^4]: Translation lookaside buffer - Wikipedia

[^5]: Page fault - Wikipedia

[^6]: Paging - Wikipedia

[^7]: mmap - Wikipedia

[^8]: C dynamic memory allocation - Wikipedia

[^9]: Memory management unit - Wikipedia

[^10]: Thrashing (computer science) - Wikipedia

Scheduling Explained

Sun, 13 Sep 2026 00:00:00 GMT

The threads post left one question open: with more threads than cores, who runs next, on which core, and for how long? The answer is the scheduler[^1]: the kernel subsystem that multiplexes CPUs among runnable work. This post opens it up. We will look at what a context switch really costs, the goals every policy balances, the classic policies from simplest to fairest, how priorities and multicore complicate the picture, and why your editor feels instant on a loaded machine.

The context switch: the price of sharing

A context switch[^2] swaps the running thread: save registers and program counter into the old PCB, switch page tables if the address space changes, load the new thread's state, resume. The direct cost is small (hundreds of nanoseconds to microseconds), but the hidden cost dominates: the new thread finds cold caches and a cold TLB, so its first instructions stall while the memory hierarchy refills. Switching address spaces (process switch) pays the full price; switching threads in one process pays less, since the page table and TLB entries survive.

thread A runs … timer fires … kernel saves A, picks B, restores B … B runs
              ↑                                              ↑
        registers → PCB(A)                        PCB(B) → registers
        (plus cache/TLB pollution nobody bills for)

Two conclusions follow. Switches must be frequent enough for responsiveness but rare enough that useful work dominates overhead: the classic time slice (quantum) of a few milliseconds balances the two. And voluntary switches are free wins: when a thread blocks on I/O, the kernel schedules someone else instead of idling, which is why I/O-heavy machines stay busy.

Goals: what "good" scheduling means

Every policy optimizes some mix of competing goals:

Throughput: jobs completed per second. Batch systems live here.
Turnaround time: submission to completion. Short jobs hate waiting behind long ones.
Response time: time to first reaction. Interactive systems live here.
Fairness: every runnable thread gets a reasonable share; nobody starves.
Predictability: similar jobs behave similarly; deadlines get met.

No policy maximizes all five. Throughput favors long uninterrupted runs; response time favors frequent switching; fairness costs overhead. The rest of the post is how classic policies pick their tradeoff.

Classic policies: from naive to fair

First-in, first-out (FIFO) runs each job to completion in arrival order. Simple, no starvation, disastrous for response time: one long compile ahead of your keystroke stalls everything (the convoy effect).

Shortest job first (SJF) runs the quickest job next, minimizing average turnaround. Optimal on paper, unusable directly: the kernel cannot know job lengths in advance (it can only estimate from recent behavior, which exponential averaging approximates).

Round-robin gives each runnable thread a fixed quantum in turn, preempting at the timer. Response time becomes predictable (n threads, quantum q: worst wait ≈ n × q), at the cost of a switch per slice and no regard for importance or job length. Timesharing was built on this.

round-robin, quantum = 10 ms, threads A B C ready
A(10) → B(10) → C(10) → A(10) → …

Priority scheduling assigns each thread a level and always runs the highest ready one. Real-time and interactive work preempts background work, which is the point, but low-priority threads can starve indefinitely under load. The standard cure is aging: raise a waiter's priority the longer it waits, guaranteeing eventual service.

Modern general-purpose schedulers (Linux CFS[^3], for example) aim at fairness: track each thread's virtual runtime and always run the one owed the most CPU, weighted by niceness. The effect approximates an ideal fluid sharing where everyone advances together, with priorities expressed as weights rather than strict ranks. Interactive feel comes free: a thread that slept on I/O accrued little runtime, so it jumps ahead when it wakes.

Priorities, preemption, multicore

Three complications complete the picture.

Priorities and inversion. Strict priorities create priority inversion: a high-priority thread blocks on a lock held by a low-priority thread, which cannot run because a medium-priority thread hogs the CPU. The chain defeats the ranking. The classic fix is priority inheritance: the lock holder temporarily borrows the waiter's priority until it releases, unblocking the chain.

Preemptive vs cooperative. Preemptive kernels (the norm) can switch on timer, I/O, or wakeup at nearly any point, which keeps response time tight at the cost of locking everywhere inside the kernel. Cooperative designs switch only at explicit yield points: simpler, but one greedy thread stalls the machine, the same lesson the OS overview drew for user programs.

Multicore. With many cores the scheduler also places work: keep threads on their warm core (affinity) to preserve caches, balance load across cores, and pack or spread depending on power goals. Migration is a tradeoff between hot caches and idle silicon, re-decided constantly.

The big picture

Sharing CPUs means switching contexts (cheap directly, expensive in caches), choosing a policy among throughput, turnaround, response, fairness, and predictability, climbing from FIFO through round-robin and priorities to fair-share, and handling inversion, preemption, and placement on real hardware. Responsiveness is not magic: short quanta, I/O threads owed runtime, and preemption that never asks permission.

But scheduling decides who runs; memory decides what each runner sees. Every process believes it owns gigabytes of private, contiguous memory on a machine with one RAM and many tenants. Maintaining that fiction, page by page, is the next post's subject.

[^1]: Scheduling (computing) - Wikipedia

[^2]: Context switch - Wikipedia

[^3]: Completely Fair Scheduler - Wikipedia

[^4]: Round-robin scheduling - Wikipedia

[^5]: Priority inversion - Wikipedia

[^6]: Starvation (computer science) - Wikipedia

[^7]: Shortest job next - Wikipedia

[^8]: Convoy effect - Wikipedia

[^9]: Processor affinity - Wikipedia

[^10]: Preemption (computing) - Wikipedia

Threads & Concurrency Explained

Sat, 12 Sep 2026 00:00:00 GMT

The processes post ended with a complaint: a process is a heavy tenant, with its own address space and page table, expensive to create and switch. Programs that need many parallel activities reach for something lighter: the thread[^1]. This post opens that lighter thing up. We will look at what a thread shares and what it keeps private, why shared memory breeds race conditions, the locks that restore order, how locks can freeze each other in deadlock, and the discipline that keeps concurrent programs alive.

Threads vs processes: tenants vs roommates

A process isolates; a thread shares. Threads in the same process run in the same address space: same code, same heap, same open files. What each thread keeps private is only what it needs to pause and resume independently: a program counter, a stack, and registers. Everything else is communal.

process (isolated)              threads (sharing)
──────────────────              ──────────────────
own address space               shared address space,
own page table                  shared heap and files
own files                       ─────────────
                                per thread: stack,
                                registers, program counter

The payoff is speed and easy communication. Creating a thread skips the page table and address-space setup; switching threads can skip the memory-unit reconfiguration; and threads exchange data by writing to shared memory instead of piping bytes through the kernel. The price is exactly that sharing: no isolation means every thread can corrupt every other thread's data, accidentally, at full speed. Processes protect you from each other by default; threads offer no protection at all.

Races: when sharing goes wrong

A race condition[^2] happens when the result depends on the timing of uncontrollable events: two threads touching the same data with at least one writing, and no ordering enforced between them. Consider the simplest shared counter:

// shared: int balance = 100;
void deposit(int amount) {
    int t = balance;      // read
    t = t + amount;       // modify
    balance = t;          // write
}

Run one deposit alone and 100 becomes 150. Run two deposits of 50 concurrently and the answer can be 150 instead of 200: both threads read 100, both add 50, both write 150. The three steps each run correctly; the interleaving is wrong. This read-modify-write pattern is the classic race, and it hides everywhere counters, lists, and caches are shared.

Worse, races are intermittent. The same program passes a thousand tests, then fails in production under load, because the failing interleaving needs a timer interrupt at exactly the wrong instruction. Programs that "usually work" are the signature of a race, and testing alone cannot catch them: the space of interleavings is far larger than any test suite.

Mutual exclusion: taking turns

The fix for a race is mutual exclusion[^3]: guarantee that only one thread at a time executes the critical section touching shared data. The standard tool is the mutex[^4] (mutual-exclusion lock): lock before entering, unlock after leaving. The OS (or threading library) parks waiters instead of spinning them, so a blocked thread costs no CPU while it waits.

pthread_mutex_t m = PTHREAD_MUTEX_INITIALIZER;
int balance = 100;

void deposit(int amount) {
    pthread_mutex_lock(&m);    // wait your turn
    balance = balance + amount;
    pthread_mutex_unlock(&m);  // next, please
}

A semaphore[^5] generalizes the idea to a counted resource: it holds N permits, waiters take one, leavers return one. A mutex is the N = 1 case (binary semaphore, plus ownership rules). Semaphores shine for producer-consumer queues and connection pools: N slots, N permits, no counting by hand.

Two rules keep locks honest. Hold them briefly (a lock serializes everything waiting on it, so long sections destroy the parallelism threads were bought for), and always pair lock with unlock on every path, including error returns, or the next thread waits forever.

Deadlock: everyone waits for everyone

Locks compose badly. A deadlock[^6] is a circle of waiting: thread A holds lock 1 and wants lock 2, thread B holds lock 2 and wants lock 1, and neither ever yields. Both sleep forever, holding what the other needs.

thread A                  thread B
────────                  ────────
lock(1) ✓                 lock(2) ✓
          ... time passes ...
want lock(2) ✗            want lock(1) ✗
  (held by B)               (held by A)
     ↓                         ↓
  waits forever             waits forever

Four conditions must all hold for deadlock (the Coffman conditions): mutual exclusion (resources need exclusive access), hold-and-wait (threads hold resources while requesting more), no preemption (nobody can forcibly take a held lock away), and circular wait (the chain of "waits for" loops back). Break any one and deadlock becomes impossible. The practical fix targets the last: impose a global lock order (always take lock 1 before lock 2, everywhere) so circles cannot form. Alternatives include lock timeouts with backoff, or designs that need only one lock at a time.

Preventing, detecting, recovering

Three strategies answer deadlock, and they differ in when they do the work:

Prevention rules it out by design, so at least one Coffman condition can never hold (the global lock order is exactly this). The cost is conservatism: some programs genuinely need one lock held while acquiring another, and the rule forbidding that also forbids the program.
Avoidance grants a request only when doing so keeps the system in a safe state, one where every thread can still finish[^7]. That verdict needs each thread to declare its maximum demand up front (the Banker's algorithm), which few real programs can supply.
Detection bets that deadlock will happen and looks for it: the kernel keeps a wait-for graph, an edge from each waiter to whoever holds what it wants, and a cycle means deadlock. Recovery then breaks it by killing a victim thread, preempting a resource it holds, or rolling it back to a checkpoint.

Most systems take the last road and react late: the deadlock surfaces as a frozen application, a supervisor kills and restarts the culprit, and the machine carries on.

Deadlock's cousins deserve a mention. Livelock is motion without progress (two threads keep yielding to each other, forever polite, never done). Starvation is indefinite postponement (a low-priority thread never wins the lock against greedy rivals). Fairness, priorities, and bounded waiting are the scheduling post's territory; the mechanism is noted here so the symptom is recognized.

The big picture

Threads trade isolation for speed: shared address space, private stacks, cheap creation, instant communication, and zero protection. Sharing without discipline produces races, intermittent and untestable; mutexes and semaphores restore order by serializing critical sections; and locks in combination demand a global order, or circles of waiting freeze the program solid, met at last by prevention, detection, or a kill.

But who decides which thread runs next, on which core, for how long, and at what priority? Threads made concurrency possible; the scheduler decides what it costs. That is the next post's subject.

[^1]: Thread (computing) - Wikipedia

[^2]: Race condition - Wikipedia

[^3]: Mutual exclusion - Wikipedia

[^4]: Lock (computer science) - Wikipedia

[^5]: Semaphore (programming) - Wikipedia

[^6]: Deadlock - Wikipedia

[^7]: Banker's algorithm - Wikipedia

[^11]: Pthreads - Wikipedia

[^12]: Livelock - Wikipedia

[^13]: Starvation (computer science) - Wikipedia

[^14]: Critical section - Wikipedia

Processes Explained

Fri, 11 Sep 2026 00:00:00 GMT

The OS overview promised an illusion: dozens of programs sharing one machine, each believing it owns the hardware. The mechanism behind that illusion is the process[^1]. This post opens it up. We will look at what separates a program from a process, the record the kernel keeps for each one, the states a process moves through, how processes are born and reaped, the isolation that keeps one crash from taking down the machine, and how processes walled off from each other still find a way to talk.

Programs vs processes: recipe vs cooking

A program is inert: bytes on disk, a recipe sitting in a drawer. A process is that program in motion: code loaded into memory, with an address space, open files, and a position in its execution. The same program can run as many processes at once (open two terminals, run the same shell twice); each gets its own memory and its own state, and neither knows about the other.

What turns the recipe into cooking is state. A process is its code plus everything needed to pause it and resume it later: register values, the program counter, the stack pointer, the page table describing its memory, the list of open files, and accounting (who owns it, how much CPU it has used). Stop saving that state exactly and the illusion of many machines collapses into one.

The PCB: the kernel's index card

For every process the kernel keeps a process control block[^2] (PCB, often called the process descriptor or task struct): one record holding everything the OS needs to manage that process. The exact fields vary by system, but the shape is universal:

PCB for pid 4217 ("editor")
─────────────────────────────
pid, parent pid, owner (uid)
state: ready / running / blocked
CPU context: rip, rsp, general registers
memory: pointer to page table
files: table of open file descriptors
accounting: CPU time used, priority
signals and exit status

The process identifier (pid)[^3] names the process; 0, 1, and small numbers traditionally belong to the kernel and the first user process. The CPU context is the pause button: when the timer interrupt fires, the kernel copies the registers into the PCB; when the process runs again, it restores them. Switching that context is literally what a context switch is: save one PCB's registers, load another's, switch page tables, resume.

States: running, ready, blocked

A process is always in one state[^4], and the kernel moves it between states as events happen:

          created
             │
             ▼
         ┌───────┐  dispatch   ┌─────────┐
         │ ready │ ──────────▶ │ running │ ───▶ terminated
         └───────┘             └─────────┘         ▲
             ▲                   │ wait for I/O    │ exit
             │ I/O completes     ▼                 │
             │              ┌─────────┐            │
             └──────────────│ blocked │ ───────────┘
                            └─────────┘   (via zombie,
                                          parent reaps)

Three states carry the whole story. Running means on a CPU right now (at most one process per core). Ready means runnable but waiting for a CPU. Blocked (waiting) means stuck on something else: disk read, network packet, keyboard input. A blocked process cannot use a CPU even if one is free, so the kernel parks it and runs someone ready instead. That single decision, never idle a CPU while work is ready, is why your machine stays busy during a slow download.

Two more states round out the picture. Created (new) covers the brief setup before a process is ready. Terminated covers death: on Unix a dead process lingers as a zombie until its parent collects the exit status with wait, a small bookkeeping debt the next section explains.

Born and reaped: fork, exec, exit, wait

On Unix, processes are born by cloning. The fork[^5] system call duplicates the calling process: parent and child emerge running the same code, differing only in the return value (0 for the child, the child's pid for the parent). The child then typically calls exec[^6] to replace itself with a new program. Shells do exactly this dance for every command you type: fork, exec the command in the child, wait for it in the parent.

pid_t pid = fork();
if (pid == 0) {
    // child: become the new program
    execl("/bin/ls", "ls", NULL);
    _exit(1); // exec only returns on failure
} else {
    // parent: wait for the child to finish
    int status;
    waitpid(pid, &status, 0);
}

Death is symmetric. exit tears the process down (closing files, freeing user memory, keeping the exit status), and the parent's wait collects that status and finally frees the PCB. A parent that never waits accumulates zombies; a child whose parent died first gets adopted by the first process (pid 1), which reaps dutifully. None of this is hardware. It is kernel bookkeeping, conventions enforced in C.

Isolation: why one crash kills one program

Sharing a machine is only half the job; the other half is keeping tenants apart. Isolation rests on two mechanisms from earlier posts.

First, virtual memory: each process gets its own page table, hence its own private address space. Process A cannot name process B's memory because its addresses translate elsewhere (or to nothing, producing a segmentation fault instead of corruption). The memory post described the hardware; the process is its customer.

Second, privilege levels: user code cannot touch devices, reconfigure memory, or meddle with other PCBs. Anything dangerous requires a syscall, where the kernel validates first. A wild pointer in an editor kills the editor; the kernel, running isolated in its own mappings, survives to clean up.

process A              kernel              process B
private mappings  →  own mappings,   ←  private mappings
page table A         full hardware        page table B
                     access, guards
                     every crossing

Files and permissions complete the fence: every process runs as a user, every file carries an owner and mode bits, and the kernel checks on every open. Isolation is not one trick. It is address spaces plus privilege plus permissions, layered so that each covers the others' gaps.

Talking across the fence: inter-process communication

But a fence keeps things out in both directions. A process cannot read another's memory, cannot poke its variables, cannot even learn where that memory lives. The same wall that keeps one crash from taking down the machine keeps two cooperating programs from touching. Something has to carry data between them, and the only party that can see both sides is the kernel. That broker is inter-process communication[^7] (IPC), and the wall is what turns it into a category of its own.

The cheapest channel is the pipe[^8]: a kernel buffer with two ends, one file descriptor to write into, another to read from. Fork hands both ends to parent and child, which is why a pipeline is three lines of plumbing:

int fd[2];
pipe(fd);                  // fd[0] = read end, fd[1] = write end
if (fork() == 0) {
    close(fd[1]);         // child keeps the read end
    execl("/usr/bin/wc", "wc", "-l", NULL);
} else {
    close(fd[0]);         // parent keeps the write end
    execl("/usr/bin/ls", "ls", NULL);
}

Neither program knows the other exists, and the two halves need not even run at the same time: the buffer lives in kernel memory and absorbs the speed mismatch. The waiting is the blocked state from earlier. Writing to a full pipe parks the writer, reading an empty one parks the reader, and whichever side still has work is the side the scheduler picks. What moves is a byte stream with no message boundaries and only one direction; want an answer back, build a second pipe pointing the other way. Two pipes are how a client talks to a server without either one holding an object the other can reach.

When two processes share no parent and must find each other by name, the same idea changes shape. A named pipe (FIFO)[^9] is a pipe with an entry in the filesystem, so unrelated programs agree on a path and open it. A message queue[^10] carries records instead of bytes: each write is a discrete message with its own length, delivered in order, so a receiver can take one message without parsing the stream around it. A socket goes furthest, becoming a bidirectional channel that works between two processes on the machine and, with a network address instead of a name, between two machines. A Unix domain socket[^11] is a TCP conversation with the network removed, and the same code serves both.

Shared memory[^12] is the exception that proves the rule. Rather than moving bytes through a kernel buffer, two processes map the same physical pages into their separate address spaces: the virtual memory post's machinery, aimed at a shared target. No copies, no syscall per byte, and for bulk payloads dramatically faster than a pipe. But the kernel steps out of the loop entirely: it never sees the individual loads and stores, so it cannot stop one process from scribbling over the other's data. Ordering has to come back explicitly, through semaphores, mutexes, or atomic instructions: the same bill the threads post charges for sharing memory inside a single process. Shared memory buys its speed with precisely the safety isolation was selling, which is the trade every IPC mechanism makes.

The big picture

A program is bytes; a process is a program plus the state to pause and resume it. The kernel tracks each one in a PCB, moves it between ready, running, and blocked, creates it with fork and exec, reaps it with exit and wait, and isolates it with private address spaces and privilege checks. Cut off from each other's memory, those processes still trade data through the kernel: pipes, message queues, sockets, or pages mapped in common, each channel paying in copies, in ordering, or in safety. One executor, a hundred tenants, each convinced the machine is theirs.

But a process is a heavy tenant: its own address space, its own page table, expensive to create and switch. Programs that need many parallel activities inside one tenant reach for something lighter, and that lighter thing shares memory instead of isolating it, with all the danger that implies. That is the next post's subject.

[^1]: Process (computing) - Wikipedia

[^2]: Process control block - Wikipedia

[^3]: Process identifier - Wikipedia

[^4]: Process state - Wikipedia

[^5]: Fork (system call) - Wikipedia

[^6]: Exec (system call) - Wikipedia

[^7]: Inter-process communication - Wikipedia

[^8]: Pipe (Unix) - Wikipedia

[^9]: Named pipe - Wikipedia

[^10]: Message queue - Wikipedia

[^11]: Unix domain socket - Wikipedia

[^12]: Shared memory - Wikipedia

[^13]: Zombie process - Wikipedia

[^14]: Context switch - Wikipedia

[^15]: Virtual memory - Wikipedia

[^16]: Memory protection - Wikipedia

The OS Explained

Thu, 10 Sep 2026 00:00:00 GMT

Everything you do on a computer runs through software you never see. You open a file or press play, and something quietly decides which program gets the processor, how much memory it can use, and whether it's allowed to touch the disk. That invisible layer is the operating system[^1], the manager of the machine's physical resources. It is the software sitting on top of everything covered in the Computers Explained series.

This post is the panoramic view of that job: what the OS is for, why the machine has two levels of trust and two separate halves, how programs ask for help, the four core resources it manages, and how it stays in complete control of a machine it is barely running.

What the OS is for

An operating system does two things, and every feature it offers serves one of them.

The first is making the hardware usable. The disk knows nothing about files or folders; the processor knows nothing about documents or windows. A program should not have to know which disk sectors hold its data or how to make the controller read them. The OS takes care of that part: the program asks to open a file, read some bytes, or write them back, and the OS works out the machine steps. You ask for the result instead of the machinery.

The second is sharing the machine. There is one processor, one block of memory, one disk, but many programs that all want them at once. The OS decides who runs next, who gets how much memory, and what happens when two programs want the same thing. Sharing fairly between competing programs is the harder of the two jobs, and it is what most of this series is about.

Both jobs have standard names: the OS as an extended machine, the hardware hidden behind cleaner interfaces, and as a resource manager, the one doing the sharing. Same thing seen from two sides.

Kernel mode and user mode: the two levels of trust

Not all programs can be trusted equally, so the processor itself draws a line. Every modern processor runs in one of two modes[^2]:

Kernel mode, also called supervisor mode: nothing is forbidden. The program can touch any memory, change any setting, and command any device.
User mode: restricted. The processor refuses instructions that would affect the machine as a whole, and refuses memory that does not belong to the program asking.

That rule lives in the hardware, not in the OS. No program, however buggy or malicious, can talk its way past it. A user program that reaches for something forbidden does not fail politely: the processor halts it on the spot, and whatever it was doing stops with it.

Kernel and user space: the two halves of the machine

Someone has to run in kernel mode, or nothing would get decided. That someone is the kernel[^3], the part of the OS that sits there. Everything else, your browser, your editor, your games, runs in user space[^4].

The split exists so that mistakes stay small. A music player with a bug should stop the music, not the whole machine. Because a user-mode program is stopped by the hardware whenever it reaches for something that is not its own, a crash stays inside that program.

user mode                      kernel mode
─────────                      ───────────
browser, editor, games    →    kernel: processes, memory,
shell, compiler                  files, devices, network

   │ restricted: cannot touch  │ privileged: full access to
   │ the hardware directly      │ the hardware, enforces the line
   └───────── asks through ─────┘
              syscalls

Anything a user program cannot do on its own, it asks the kernel to do. That request is the only channel between the two halves.

There are different ways to place that channel inside the OS. A monolithic kernel[^11], like Linux, keeps most services in kernel mode, where they are fast. A microkernel[^10] keeps the kernel small and moves drivers and filesystems into ordinary user-mode programs, where a failure is easier to contain. The tradeoff is the familiar one: a single large piece is fast, but one bug takes down everything, while many small pieces isolate failures better and cost more work crossing between them.

Syscalls: the boundary you program against

A system call[^5] is the only bridge between user space and the kernel. An ordinary program has no permission to touch the hardware directly, neither the disk nor the screen, so it has to make a formal request to the kernel and wait.

In practice, this synchronous dialogue happens in three steps.

The request: The program needs to save a file or display some text, so it makes a system call, pauses its own execution, and hands control to the kernel, which takes over in kernel mode.
The check: The kernel takes the command, verifies the program is allowed to perform that action, and does the work with full privileges.
The return: The kernel sends the answer back, and the program wakes up exactly where it stopped, with the result in hand.

All of that back and forth happens millions of times per second, keeping the machine safe without you ever noticing a hitch.

What the OS manages

Four kinds of resource take up nearly all of an OS's attention.

Process

A process[^6] is a running program along with the metadata the OS must maintain: its compiled code, memory allocations, open file descriptors, and its current execution pointer. The OS manages the lifecycle of each process, starting, pausing, resuming, and cleaning them up, in order to give each program exclusive virtual access to the hardware.

Memory

The OS implements virtual memory[^7] to give each program a private, isolated address space, even though the underlying physical RAM is shared. It translates virtual addresses to physical locations on the fly to prevent programs from colliding or accessing each other's data, and transparently pages data between RAM and secondary storage as needed.

Storage

The OS provides a file system[^8] to bridge the gap between raw hardware blocks and human concepts. It abstracts unnamed, unorganized blocks of bytes into structured files and folders, manages access permissions, tracks metadata, and ensures data integrity during write operations and power failures.

Devices

The OS uses Device drivers[^12] to standardize communication with heterogeneous hardware, such as keyboards, displays, disks, and network cards. It translates uniform system requests into device-specific commands and manages input/output queues to optimize throughput and minimize processor idle time.

How the OS stays in control while barely running

Here is the puzzle: most of the time the OS is not running. Your editor is. So if the OS is in charge, who actually is?

The answer is that the machine keeps handing control back on its own. Three events can pull the OS in, whether the running program likes it or not:

The program asks for something, through a system call. This one is voluntary.
A device needs attention, because a key was pressed, a disk finished reading, or a network packet arrived. The hardware raises an interrupt[^9] by itself.
A timer runs out, many times per second. Nothing on the machine can prevent it.

The third is what holds everything together. When the timer fires, the OS takes the processor back, decides which program should run next, and hands it over for a short slice. That happens whether the program being interrupted agrees or not, so the OS does not need to be running to stay in charge. It only needs to be woken up often enough.

program A runs … timer fires … OS decides … program B runs …
              ↑              ↑                 ↑
          interrupt      saves A, picks     A waits, B
            (forced)       who runs next     starts fresh

Early systems asked programs to be polite: yield the processor when you finish, and everyone else gets a turn. This is called cooperative[^13] sharing, and it fails in an obvious way. One program that forgets to yield, or crashes while holding the processor, freezes every other program on the machine. Modern systems are preemptive[^14]: the OS takes the processor back on its own schedule and gives it to someone else. Which program that is, for how long, and at what priority is the subject of scheduling, which gets its own post.

The big picture

An operating system is software that manages the machine's hardware on behalf of every program on it. It keeps the hardware details to itself and answers simple requests instead. It splits the machine into a trusted half, where the kernel may do anything, and a restricted half, where everything else runs and can only ask. Behind that single door it manages processes, memory, files, and devices. And a timer that nobody can ignore brings it back into control over and over, no matter what any program would prefer.

What is actually inside a running program, how one gets started, and what it takes to keep a hundred of them believing they are alone on the machine: that is the next post, where we pop the hood on a single process and read the OS's bookkeeping for it line by line.

[^1]: Operating system - Wikipedia

[^2]: Protection ring - Wikipedia

[^3]: Kernel (operating system) - Wikipedia

[^4]: User space and kernel space - Wikipedia

[^5]: System call - Wikipedia

[^6]: Process (computing) - Wikipedia

[^7]: Virtual memory - Wikipedia

[^8]: File system - Wikipedia

[^9]: Interrupt - Wikipedia

[^10]: Microkernel - Wikipedia

[^11]: Monolithic kernel - Wikipedia

[^12]: Device driver - Wikipedia

[^13]: Cooperative multitasking - Wikipedia

[^14]: Preemptive multitasking - Wikipedia

The Most Flexible Machine Ever Built

Wed, 09 Sep 2026 00:00:00 GMT

Across this series we took a computer apart: the computers, representation, CPU, digital logic, memory, storage, I/O, and interconnects. No new layer today. This final post steps back to ask why this machine matters so much.

One machine, every job

Most machines do one thing. A toaster toasts. A calculator adds. A computer[^1] is different because its behavior is not fixed in hardware. Thanks to the stored-program concept[^2], instructions live in memory like data, and the processor fetches them as part of normal work. Load different bytes, get a different machine.

Your watch, your phone, and a supercomputer differ in size, not in essence. All three fetch stored instructions and all three can run an enormous range of tasks.

Real example: the same laptop edits video in the morning, joins calls at noon, and plays chess at night. Nothing changed inside except the bytes loaded from SSD into RAM.

The same handful of ideas, everywhere

Look back and notice how rarely ideas change. Small and fast on top, big and slow below: that is memory, storage, and caches. Agree on the interface, change behind it: that is ISA, USB, and PCIe. Keep recent work close: that is locality and caching. Let helpers do bulk work: that is controllers and DMA. Fast, big, cheap: pick two, everywhere.

Learning specs expires with the chip. Learning patterns transfers to every machine you meet.

Real example: once you understand why a cache helps RAM, you also understand why a browser cache helps the network and why a CDN helps video. Same locality idea, new clothes.

Why fundamentals outlive fashions

Tools churn yearly. The ground barely moves. Bits are still bits. Addition still ripples carries. Processors still fetch, decode, execute. Hierarchies still trade speed for size. The posts here describe ideas many programmers never touch directly yet use daily.

Going deeper makes knowledge more stable, not less. Chasing each new tool keeps you running. Learning how the machine works lets the landscape settle around you.

Real example: a framework from 2020 already feels old. Addresses, caches, and fetch decode execute from decades ago still describe your new phone.

The lever under everything

The flexible machine became a lever under science, medicine, and art. Genomes read by matching letters. Black hole images built from scattered radio samples. Grandparents meeting as pixels and sound. All of it ends as switches changing state in patterns we wrote, billions of times per second.

Older machines extended muscle and reach. This one extends what we can calculate, model, and automate. Any process described precisely enough can run on it. That is why software keeps eating the world, one precise description at a time.

Real example: a vaccine search compares millions of letter strings. A video call compresses light and sound into packets. Both are just loops, addresses, and arithmetic on the same humble parts.

The big picture

switches + wires + agreements on meaning
  ↓
gates -> adders, muxes, registers
  ↓
CPU + memory + storage + I/O + roads
  ↓
one universal machine, any job by loading bytes

The series started with a map and ends with a moral. Details will keep changing: denser chips, faster roads, new materials. Ideas will keep rhyming.

We have seen the machine. Next is what software can make it do.

[^1]: Computer - Wikipedia

[^2]: Stored-program computer - Wikipedia

Computer Buses & Interconnects Explained

Tue, 08 Sep 2026 00:00:00 GMT

Every past post assumed one thing: parts can reach each other. Registers feed the ALU, the CPU reads memory, controllers deliver device data, all across wires. This post explains those wires. Not a PCIe manual, just what each road is for and what it costs.

Three buses: what, where, and when

A bus[^1] is a set of wires between parts. The classic model splits it in three:

CPU -------- address bus (WHERE: which place?) ------> elsewhere
CPU <------> data bus (WHAT: the bytes) <------------> elsewhere
CPU -------- control lines (WHEN: read? write?) -----> elsewhere

The address bus[^2] names the target: a memory spot or a device register. Its width sets reach: 32 bits name 4 GiB. The data bus carries the payload both ways: 64 bits move 8 bytes per trip. Control lines coordinate: read or write, size, clock, plus ready signals meaning data is valid now.

Where, what, when. That is the whole model.

Real example: mov rax, [0x2000] puts 0x2000 on the address bus, raises read on control, and grabs 8 bytes from the data bus.

CPU to memory: the fastest road

The CPU to memory path is the busiest road: every instruction and most data cross it, but caches save most trips. The talk is simple: put address out, signal read, collect bytes. Writes go in reverse.

Old machines shared one bus. New machines use dedicated point-to-point memory interconnects[^3]: memory channels plus links like Infinity Fabric or Intel UPI in big servers, each moving tens of GB/s. Caches exist to avoid this travel: hits stay on chip, only misses pay for DRAM.

Real example: loop over a 1 MB array with a 12 MB cache and almost nothing leaves the chip. Jump across gigabytes at random and every miss waits tens of nanoseconds for DRAM.

CPU to devices: the I/O road

CPU to devices uses the same idea with slower timing. The CPU talks to controller registers with memory-mapped I/O[^4], where device registers just live at special addresses next to RAM. It writes a command like start read, the controller does the slow work alone, then signals done with an interrupt or a DMA copy into memory.

Speeds differ wildly. A keyboard needs almost nothing. A GPU or fast SSD needs gigabytes. Separate roads let each run at its own price.

Real example: type a letter and one interrupt carries one byte. Start a disk read and the controller moves megabytes by DMA while the CPU does other work.

PCIe: the general highway

PCI Express[^5] is the main I/O road inside modern boxes. It links processor to GPU, SSD, and network card with fast serial lanes. Each lane sends both ways at once. A x16 graphics slot has sixteen lanes, roughly sixteen times one lane. An NVMe SSD often uses four.

Two ideas matter without internals. Generations: each generation roughly doubles speed per lane, so ceiling depends on lane count times generation. Packets: unlike simple address plus data, PCIe wraps traffic in packets with headers and error checks, like tiny network messages inside the box. That lets one fabric serve GPU, storage, and network alike.

Real example: plug an NVMe SSD into a 4-lane slot. Sequential reads hit several GB/s because four lanes in parallel feed it. Move it to a 1-lane slot of an old generation and the same drive crawls.

SATA is the older storage road, capped near 0.5 GB/s. Computers keep it because HDDs use it: they are large mechanical drives with SATA plugs and cables, not cards that fit PCIe slots, and they remain the cheapest terabytes for backups and archives. Many SATA SSDs reuse the same plugs and cables.

USB: the road to the outside

If PCIe is the highway inside, Universal Serial Bus[^6] is the road out. It joins keyboards, mice, disks, and phones, carrying data plus power so small devices just work. Devices join a host controlled bus: the host schedules everything, peripherals stay simple.

History is generations keeping compatibility: megabits on USB 2.0, gigabits on USB 3.x, tens of gigabits on USB4. Plugs changed (Type-A, Micro, Type-C) but the flow stayed: plug in, identify, exchange packets. The port on the case is where an internal road changes medium.

Real example: plug a keyboard into USB-C. It reports it is a keyboard, the host polls it on schedule, key presses arrive as small packets. Same port, plug a disk, and bulk packets carry files plus charging power.

Bandwidth and latency: the cost of every road

Every road has two numbers. Bandwidth is flow per second: tens of GB/s per memory channel, GB/s on multi-lane PCIe, megabits to tens of gigabits on USB. Wider and faster raises it, sharing lowers each share.

Latency is trip time: single nanoseconds on chip, tens of nanoseconds to DRAM, microseconds across PCIe to a device, more over USB cables. Each border crossed adds delay, so urgent traffic stays on the shortest roads.

Bulk wants bandwidth. Start wants latency. DMA moves bulk without the CPU. Interrupts signal done without polling. Those two tricks from the I/O post are answers to these costs.

Real example: copy a 10 GB file and bandwidth rules. Click a mouse and latency rules: even tiny delay feels laggy.

The big picture

need: parts must reach each other
  ↓
model: address (where) + data (what) + control (when)
  ↓
CPU <-> memory (fastest, caches avoid trips)
CPU <-> devices (mapped addresses + interrupts + DMA)
  ↓
PCIe (inside highway, lanes and packets)
USB (outside road, host schedules, power plus data)
  ↓
price every road with bandwidth and latency

Every link answers where, what, and when. Old buses show it as wires, new links pack it into packets. The physical machine is now complete. The last post steps back to see the whole.

[^1]: Bus (computing) - Wikipedia

[^2]: Address bus - Wikipedia

[^3]: Computer bus - Wikipedia

[^4]: Memory-mapped I/O - Wikipedia

[^5]: PCI Express - Wikipedia

[^6]: USB - Wikipedia

Input and Output Explained

Mon, 07 Sep 2026 00:00:00 GMT

The last posts built a machine that can compute, remember, and persist, yet one that is deaf, mute, and blind. With no way in and no way out it would be useless. This post covers input/output (I/O)[^1]: devices that cross the machine boundary, plus the two tricks (interrupts and DMA) that let a fast CPU work with slow devices. Drivers and filesystems belong to a future OS series. Here we stay in hardware.

Input devices: bringing the world in

Input devices[^2] turn the outside world into bits. A keyboard[^3] is a grid of switches. A controller scans rows and columns many times per second, finds which crossing closed, and reports a position code. Which letter that means (q, upper or lower case) is decided later by software.

An optical mouse[^4] reports movement, not position. Its sensor photographs the desk thousands of times per second and sends how far the image moved. The machine adds those steps into cursor position. Touch, microphones, and cameras do the same at higher rates: sample the world on a schedule, send numbers.

Real example: press A. The keyboard sends position code 30. Your OS layout turns it into a or A depending on Shift. The hardware never knew letters.

Output devices: carrying bits back out

Output devices[^5] run the reverse way. A display[^6] is a grid of pixels. The machine writes color values into a memory region called the framebuffer. The display controller reads it 60 or more times per second and turns each value into light. What you see is memory made visible, refreshed faster than eyes follow.

Audio[^7] does the same in time. Values for air pressure sit in a buffer, and the audio controller feeds them to a converter tens of thousands of times per second. Miss the schedule and you hear a click. Video forgives a late frame, audio never forgives a late sample.

Real example: move a window and you write new pixels into the framebuffer. The next 60 Hz refresh shows them. Play a song and 44100 samples per second must leave on time or you hear gaps.

Storage and network devices: I/O in disguise

Storage disks from the last post are I/O devices to the CPU. The processor never touches platters or flash directly. It sends commands like "read blocks 100 to 107" and waits for done.

Network devices[^8] are both directions at once. The same card sends and receives packets. That is why a machine with only Wi-Fi stays fully useful. The network is a universal I/O channel to other machines.

Real example: open a file and the OS sends a read command to the SSD. Load a page and the Wi-Fi card brings packets in while it sends requests out.

Controllers: translators at the border

No CPU speaks keyboard or display natively. A controller[^9] sits between: it speaks device language on one side and machine language on the other. Keyboard controller scans the matrix. Display controller keeps the refresh rhythm. Storage controller turns commands into seeks or flash writes. Network controller frames bits for wires or radio.

Controllers also offload boring timing work. The CPU says "fetch these sectors" and goes away. The controller does the millisecond by millisecond dance alone.

Real example: your CPU does not blink each pixel 60 times per second. It draws once into the framebuffer. The display controller repaints the screen alone from there.

Buses and ports: the roads and doors

Devices plug in through shared links. A classic bus[^10] carries address, data, and control between parts. Modern machines use fast point-to-point links like PCIe for speed, but the job is the same: roads with traffic rules.

A port[^11] is where the road meets the outside: USB-C, HDMI, Ethernet, audio jack. Standards like USB or HDMI define the electric talk so makers interoperate. Plug in a mouse and you join a small network with its own schedule.

Real example: plug a USB drive in. It identifies itself, the host schedules its packets, and files appear. Unplug HDMI and the display controller simply has nowhere to send pixels.

Interrupts: devices that raise their hand

The CPU runs billions of cycles per second. A keystroke arrives a few times per second. Asking every device in a loop ("anything new?") wastes all attention on silence. That loop is called polling.

An interrupt[^12] flips it. The device taps the CPU shoulder instead of waiting to be asked.

program running
  ↓ (interrupt: key pressed)
save registers + rip
  ↓
jump to handler, read key code
  ↓
restore registers + rip
  ↓
program continues, never noticed

Real example: press a key while a game runs. The keyboard raises an interrupt, the CPU grabs code 30 in microseconds, queues it, and the game keeps rendering. No polling, no missed press.

DMA: moving data without the CPU

Interrupts fix notification, but bulk is still heavy. Dragging every disk byte through CPU registers wastes the processor. Direct memory access[^13] fixes it: hardware moves data between device and RAM alone.

The CPU sets source, destination, and size, then does other work. The DMA engine copies in bursts. When done it raises one interrupt: data is there.

Real example: play a 4K video. The SSD streams frames into RAM by DMA while the CPU decodes the last frame. Without DMA the CPU would copy every byte itself and stall.

The big picture

in              (keyboard, mouse, mic, camera)
  ↓
controllers     (translate device talk to machine talk)
  ↓
CPU <-> memory  (asks, computes)
  ↓
out             (display framebuffer, audio buffer)
  +
bulk            (storage and network by commands + DMA)
  +
signals         (interrupts tap the CPU shoulder)

Input samples the world into bits. Output renders bits into light and sound. Controllers translate at the border. Interrupts save polling. DMA saves copying. One boundary remains: the wires between machines.

[^1]: Input/output - Wikipedia

[^2]: Input device - Wikipedia

[^3]: Computer keyboard - Wikipedia

[^4]: Computer mouse - Wikipedia

[^5]: Output device - Wikipedia

[^6]: Computer monitor - Wikipedia

[^7]: Sound card - Wikipedia

[^8]: Network interface controller - Wikipedia

[^9]: Controller (computing) - Wikipedia

[^10]: Bus (computing) - Wikipedia

[^11]: Computer port (hardware) - Wikipedia

[^12]: Interrupt - Wikipedia

[^13]: Direct memory access - Wikipedia

Storage Explained

Sun, 06 Sep 2026 00:00:00 GMT

The memory post ended at the bottom of the hierarchy: the world where data rests for years. This post stays there. Filesystems (how bytes become files and folders) belong to a future series, not this one.

Persistent storage: memory that survives power loss

Computer data storage[^1] keeps information without power, for years, at a price per byte far below RAM. The trade is speed and a different contract: the CPU never touches storage byte by byte. It talks in fixed chunks through a controller.

Programs rest on storage. Running means copying into memory first. Boot, launch an app, open a document: each step moves up from the slow persistent world into the fast volatile one.

Real example: open a game and it starts loading content from SSD into RAM as needed, like asset streaming. Pull the plug and RAM empties, SSD keeps everything.

HDD: bits as magnetism

A hard disk drive[^2] stores bits as magnetic patterns on spinning platters. An arm with read heads floats nanometers above the surface and reads those patterns.

Moving parts bring three effects:

Position takes time: the arm must seek the right track, then wait for rotation to bring the sector under the head. That is several milliseconds before any byte flows.
Capacity is cheap: platters are simple surfaces, so terabytes cost little.
It is fragile and hungry: it spins, vibrates, and dislikes drops.

Real example: a 4 TB external drive for backups. Huge and cheap, but you hear it spin and you feel every random read stall.

SSD: bits as trapped charge

A solid-state drive[^3] has no moving parts. It stores bits as charge trapped in NAND flash[^4] cells, transistors with an isolated pocket where charge stays put for years without power.

No arm to move means silent, shock resistant, and far quicker to the first byte. But it is not just fast memory. Flash has its own rules below, and an SSD hides them with a controller, firmware, DRAM cache, and flash chips working together.

The same flash lives in many shapes: a 2.5 inch SATA SSD, a stick-like M.2 NVMe drive, or a tiny microSD card in your phone. Same bits as trapped charge, different package and speed.

Real example: swap a laptop HDD for a SATA SSD and the same machine boots in 15 seconds instead of 2 minutes. Same files, no mechanics.

NAND flash: cells, pages, blocks

A flash cell stores charge levels, not just on or off. Manufacturers name each density by how many bits it stores per cell. Common densities trade precision for capacity:

SLC (Single-Level Cell): 1 bit per cell, 2 levels. Fastest, toughest, priciest.
MLC (Multi-Level Cell): 2 bits per cell, 4 levels. Balanced.
TLC (Triple-Level Cell): 3 bits per cell, 8 levels. Dense, common in laptops.
QLC (Quad-Level Cell): 4 bits per cell, 16 levels. Densest, slowest, wears fastest.

More bits per cell means cheaper gigabytes but thinner margins, so slower writes and more error correction. No free density.

Cells form pages (4 to 16 KiB), the unit for read and write, grouped into blocks (hundreds of pages), the unit for erase. Flash has one hard rule: you can write a page only when it is erased, and erasing wipes a whole block at once.

So overwrite means write elsewhere and mark the old page invalid. Later the drive moves valid pages away and erases the block. That extra copying is write amplification. Blocks also wear out after thousands of erases, so firmware spreads writes evenly (wear leveling).

Real example: save a 4 KiB text file again. The SSD writes a fresh page elsewhere, marks the old one dead, and cleans it later. You never see this, the controller does.

Sectors and blocks: the language of drives

Drives speak in chunks. A disk sector[^5] (classically 512 bytes, today often 4 KiB) is the smallest piece the OS reads or writes. Flash pages and blocks are the matching units inside SSDs.

Byte access like RAM is gone here. Everything is parcels. That is why small scattered writes cost more than their size: seeks on disks, mapping and cleanup inside SSDs. Systems align their structures to these sizes for a reason.

Real example: a database writes in 4 KiB or 16 KiB pages to match the drive, not byte by byte. One aligned write, one parcel, no extra tax.

Sequential vs random access: the pattern decides the speed

The same drive shows two speeds depending on how you ask. Sequential access reads one long run. Random access jumps between scattered spots.

On HDD the gap is huge: sequential is fast once positioned, random is very slow because each jump pays a fresh seek.
On SSD the gap is smaller: sequential fills the link, random is slower but still thousands of times faster than disk.

Layout matters. Logs, video, and backups are kind because they are sequential. Much of systems work (caches, prefetching, log designs) turns random into sequential before it hits the drive.

Real example: copy a 5 GB movie file: fast. Copy 5 GB made of ten thousand tiny files: slow on the same drive. Same bytes, different pattern.

Three numbers: latency, throughput, capacity

Three numbers describe any drive:

Latency: wait before the first byte. HDD answers in milliseconds (mechanics). SSD answers in tens of microseconds[^3], thousands of times quicker than a disk, yet thousands of times slower than RAM. Latency is what makes a system feel snappy.
Throughput: flow once started. Disks hold near 100 MB/s sequential. SATA SSDs near 0.5 GB/s. NVMe drives reach several GB/s[^6]. The cable sets the ceiling: SATA, then PCIe generations carrying NVMe.
Capacity: how much rests there. Terabytes are normal on disks and common on SSDs, far beyond RAM at a fraction of the price per byte.

Each level down the hierarchy gets larger, slower, and cheaper per byte.

Real example: opening 50 browser tabs wants capacity. Launching an app fast wants low latency. Copying 4K video wants throughput.

The big picture

need: keep data without power, cheap per byte
  ↓
HDD                     (magnetism + moving arm, vast and cheap, seeks hurt)
SSD                     (trapped charge, silent and quick, pages and blocks rule)
  ↓
talk in parcels         (sectors, pages, blocks)
  ↓
pattern decides speed   (sequential fast, random slow)
  ↓
describe with latency / throughput / capacity

Storage trades speed for persistence. The machine is now almost complete: processor, memory, and storage in place. What remains is how it talks to the outside world.

[^1]: Computer data storage - Wikipedia

[^2]: Hard disk drive - Wikipedia

[^3]: Solid-state drive - Wikipedia

[^4]: Flash memory - Wikipedia

[^5]: Disk sector - Wikipedia

[^6]: NVM Express - Wikipedia

Memory Explained

Sat, 05 Sep 2026 00:00:00 GMT

The CPU post gave programs a place to run but nowhere to live: registers hold a few dozen values, and that is all. The digital logic post showed how a flip-flop holds one bit. This post scales that bit up to gigabytes.

Memory cells: holding one bit

Computer memory[^1] starts from tiny structures that store bits, called memory cells. The machine needs billions of them, so one small design repeated billions of times decides everything.

There are two classic designs:

SRAM (Static RAM)[^2]: a small loop that holds its bit steady while power is on. It uses about six transistors per bit, so it is fast and simple but large.
DRAM (Dynamic RAM)[^3]: one transistor plus one tiny capacitor where the bit lives as charge. It is far smaller and cheaper, but the charge leaks in milliseconds, so the memory must refresh it again and again just to remember.

Think whiteboard versus leaky bucket. The whiteboard keeps your writing until you erase it. The bucket needs constant refilling.

Neither type wins on everything, so machines use both:

              SRAM                  DRAM
cell          loop, ~6              1 transistor +
              transistors           1 capacitor
size          large                 tiny
speed         very fast             slower
refresh       none needed           constant refresh
cost          expensive             cheap
used for      caches                main memory

SRAM buys speed with silicon area. DRAM buys density with refresh work. Architects put SRAM where speed matters most and DRAM where capacity matters most.

Real example: a few megabytes of SRAM cache sit next to the CPU. Gigabytes of DRAM sit further away as main memory.

Addresses: every byte has a number

A pile of cells is useless without names. That name is the memory address[^4], a number for each location, like a house number on a street. Modern memory is byte-addressable: each address names one byte, and bigger values use consecutive addresses.

With n address bits you can name 2^n places. 32 bits name 4 GiB. 64 bits could name far more than any machine holds, so real chips use fewer bits in practice.

Real example: a pointer in C like 0x7fff1000 is just such a house number. rsp from the CPU post is another address, pointing at the top of the stack.

RAM: the workbench

Random-access memory[^5] holds running programs and their data: code, heap, stack. Random access means any address can be read in about the same time. A tape must wind past everything before it, RAM just jumps straight there.

RAM is the CPU main partner: large enough for gigabytes of work, fast enough with caches helping, but forgetful. In its usual DRAM form it loses everything when power goes out.

Real example: unsaved work vanishes in a blackout for this reason. Every boot copies the operating system from storage into RAM again before anything can run.

ROM: memory that remembers

Read-only memory[^6] is the mirror image: it keeps its contents without power instead of being fast to rewrite. Its classic job is firmware, the first instructions on power-up, which must already be there before anything can load.

Pure read-only chips are history. Modern firmware lives in rewritable non-volatile memory[^7] like flash memory[^8]. It keeps bits without power but can still be reprogrammed slowly in large blocks.

Real example: press the power button and the CPU starts running firmware from flash before your SSD or RAM is even ready. That code then starts the boot.

Three numbers: capacity, latency, bandwidth

Three numbers compare any memory:

Capacity: how much it holds. Registers hold bytes, caches hold kilobytes to megabytes, main memory holds gigabytes.
Latency: how long one access takes. Registers respond in a fraction of a nanosecond, fast caches in about a nanosecond, main memory in tens of nanoseconds[^9]. Latency is the wait before the first byte arrives.
Bandwidth: how much arrives per second once flowing, in gigabytes per second. One memory channel moves tens of gigabytes per second. Bandwidth is the width of the pipe, latency is its length.

A sports car delivers one passenger quickly (low latency). A train delivers hundreds slowly (high bandwidth).

Real example: chasing a linked list pointer by pointer needs low latency. Streaming a video frame needs high bandwidth.

The memory bus: talking to RAM

Registers live inside the CPU, but main memory sits outside, so the processor reaches it through shared wires called the bus[^10]:

CPU -------- address bus (which location?) -------> memory
CPU <------> data bus (the bytes themselves) <----> memory
CPU -------- control lines (read? write? when?) --> memory

To read, the CPU puts an address out, raises read, waits, and collects the bytes. A 64-bit data path moves 8 bytes per transfer. Modern DDR memory (DDR4, DDR5) transfers on both clock edges to double transfers per tick, but the talk stays the same: ask by address, answer with data.

Real example: mov rax, [0x1000] puts 0x1000 on the address bus, signals read, and rax receives the 8 bytes that come back on the data bus.

The memory hierarchy: fast, big, cheap, pick two

No single memory is fastest, largest, and cheapest at once, so machines stack them into a memory hierarchy[^11]:

registers     (bytes, fastest, program manages)
    ↓
caches        (KB to MB, ~1 ns, SRAM, hardware manages)
    ↓
main memory   (GB, tens of ns, DRAM)
    ↓
storage       (TB, microseconds to ms, non-volatile)

This works because of locality. Programs reuse the same data (temporal locality) and touch neighbors together (spatial locality). So hardware keeps copies of recent and nearby data in caches[^12], where most accesses hit. A miss pays a trip down the ladder. Caches move whole 64-byte lines at once and track which copies are valid, all invisibly to your code.

Real example: a loop over an array for (i = 0; i < n; i++) sum += a[i] flies because each 64-byte cache line brings 16 integers at once and the next 15 are already there.

The big picture

cells       (SRAM / DRAM)
  ↓
addresses   (names for bytes)
  ↓
RAM         (work in progress) + ROM (remembers through power loss)
  ↓
bus         (ask by address, answer with data)
  ↓
hierarchy   (registers -> caches -> memory -> storage)

Cells hold bits, addresses name bytes, RAM hosts current work while ROM survives power loss, the bus carries the talk, and the hierarchy keeps what locality predicts the CPU will want next close by.

What the hierarchy pushes down is the next subject: the non-volatile world where data rests for years.

[^1]: Computer memory - Wikipedia

[^2]: Static random-access memory - Wikipedia

[^3]: Dynamic random-access memory - Wikipedia

[^4]: Memory address - Wikipedia

[^5]: Random-access memory - Wikipedia

[^6]: Read-only memory - Wikipedia

[^7]: Non-volatile memory - Wikipedia

[^8]: Flash memory - Wikipedia

[^9]: CAS latency - Wikipedia

[^10]: Bus (computing) - Wikipedia

[^11]: Memory hierarchy - Wikipedia

[^12]: Cache (computing) - Wikipedia

The CPU Explained

Fri, 04 Sep 2026 00:00:00 GMT

The computer overview gave the CPU[^1] one paragraph: it fetches instructions and executes them, billions of times per second. This post opens that black box. We will look at the contract a CPU offers to software, the parts inside it, the exact loop it runs, and how lofty ideas like "function calls" and "the heap" reduce to bytes and registers.

The ISA: the contract between software and silicon

A processor does not understand Python, JavaScript, or even C. It only understands its own machine language. The instruction set architecture (ISA)[^2] is the contract that defines that language: which instructions exist, what registers are available, and how programs talk to the machine.

Each CPU family speaks one ISA. The most common in daily life are:

x86[^3]: very common in laptops and desktops.
ARM[^4]: present in most phones.
RISC-V[^5]: an open ISA growing in embedded hardware.

A program compiled for one ISA cannot run on another. That is why your phone cannot run laptop binaries, and why Apple spent years translating x86 apps to ARM. Same code, different contract, no execution.

Everything below uses x86 with ARM notes where they differ, since the concepts transfer.

Registers: the CPU's workbench

The CPU cannot work directly on RAM for most instructions. Memory is too slow and too far. So it keeps a few slots on the chip itself called processor registers[^6]. They are the fastest storage the CPU has, its hands and its desk.

Think of registers as named boxes, each holding one number. x86 has 16 general boxes (like rax, rbx, rcx) and a few with special jobs:

rip: holds the address of the next instruction to run.
rsp: points to the top of the stack.
rflags: stores small yes or no notes about the last calculation.

You do not need to memorize these names because what matters here is understanding what they are and what they are for.

Real example: when you write int a = 5, the value 5 waits in RAM. RAM can hold millions of values, but the CPU cannot calculate directly on RAM. So to use it, the CPU copies 5 into a register like eax, does the work there, then copies the result back to RAM.

Think of RAM as the pantry where all ingredients are stored, and the register as the cutting board holding only the one ingredient you are using right now.

Caches: data close by

Waiting for RAM costs hundreds of clock cycles. So between RAM and registers the CPU keeps two middle layers, called L1 and L2 caches[^7].

They have different jobs. Registers hold the few values the CPU is using right now, with names like rax. Caches hold copies of RAM data the CPU will probably need soon, with no names, managed automatically. On a miss it waits for RAM and saves a copy for next time.

RAM (big, slow)
  ↓
L2 cache (smaller, closer)
  ↓
L1 cache (even smaller, even closer)
  ↓
registers (the values in use now)

The ALU: where the math happens

The ALU[^8] does the actual calculation. It takes two numbers plus an operation (add, subtract, AND, OR) and returns a result.

The ALU is built from the circuits of the previous post:

Adder does addition, and subtraction reuses the same adder by flipping the number to its two's complement form.
Logic gates do AND, OR, and XOR.
A multiplexer at the end picks which result to keep.

Many instructions also leave small notes in rflags as a side effect:

ZF: result was zero.
SF: result was negative.
CF / OF: number overflowed.

Real example: read add rax, rbx as a short order with three parts: what to do (add), where to save the answer (rax), and which ingredient to use (rbx).

rax holds 10, rbx holds 7.
Command: add rax, rbx
Result: rax now holds 17, and rbx still holds 7.

The cmp rax, rbx instruction saves no new number. Internally it does rax - rbx and throws the result away, keeping only the notes in the flags. The next instruction doesn't look at rax or rbx again; it reads only those notes to decide whether to jump or keep going straight.

rax and rbx both hold 10 -> note says "equal", so je jumps
rax holds 10, rbx holds 7 -> note says "not equal", so je stays

The control unit: the conductor

It turns a passive byte pattern in memory into coordinated action. Registers are the workbench and the ALU is the tool, but someone must decide what to do each moment.

The control unit[^9] reads the current instruction, decodes its bits (with a decoder, from the previous post), and sends control wires to the rest of the chip: send these two registers into the ALU, select addition, write the result back there, move to the next instruction.

Simple RISC CPUs do this with direct hardwired logic. Big x86 chips first break complex instructions into smaller RISC-like steps called micro-operations, then schedule those. Either way the job is the same.

Real example: for add rax, rbx (with rax = 10 and rbx = 7), the control unit says: connect box rax and box rbx to the ALU inputs, select ADD, write the ALU output (17) back into box rax, advance rip to the next instruction.

State machines: how the CPU remembers what it is doing

The control unit has a problem that combinational logic alone cannot solve. A decoder or a mux forgets everything instantly. But running an instruction takes several steps, so the CPU must remember which step it is on.

It solves this with a finite state machine[^10]. That is a fancy name for a simple idea: a current state stored in flip-flops, plus combinational logic that decides the next state. The CPU lives in one state at a time and moves on each clock tick.

Real example: a traffic light is a state machine with three states: red, green, yellow. Red always goes to green, green always goes to yellow, yellow always goes to red. The CPU control unit works the same way. That stored state is what lets a pile of forgetful gates behave like a cook following a recipe step by step.

The instruction cycle: fetch, decode, execute

It runs one instruction after another, forever. This loop is the instruction cycle[^11]. It is the state machine above in action:

FETCH -> DECODE -> EXECUTE -> FETCH -> DECODE -> ...

Fetch. Copy the bytes at the address in rip into the CPU, and move rip past them.
Decode. Look at those bytes: which operation, which registers, which memory address.
Execute. Move data through the ALU or memory, write results back, update flags, and either keep going forward or jump rip somewhere new. After EXECUTE the machine returns to FETCH, unless a jump changed rip.

A 3 GHz clock ticks three billion times per second, but that does not mean three billion instructions per second. Modern CPUs finish several instructions per tick or take several ticks per instruction. The fetch, decode, execute contract stays the same.

Instruction anatomy

All instructions share the same basic structure:

Opcode: what to do.
Operands: what to do it with.

x86 instructions range from 1 to 15 bytes to keep common cases tiny. ARM64 instructions are typically a fixed 4 bytes, which makes decoding simpler. Operands come in three flavors:

Immediate: the value is written right in the instruction. add rax, 5 means rax = rax + 5.
Register: the value is in another box. add rax, rbx means rax = rax + rbx.
Memory: the value is in RAM. Square brackets mean "go to RAM". mov rax, [rbx+16] takes the number in rbx, adds 16 to find an address, reads the 8 bytes stored there, and copies them into rax. This is how arrays (array[i]) and structs (object.field) work underneath.

Calling conventions and the stack

Caller and callee must agree on where arguments go. That agreement is the calling convention[^12].

On Linux and macOS, integer arguments go in specific registers (rdi, rsi, rdx and so on), and the answer always comes back in rax.

So a function knows where to return after it finishes, we use the stack[^13]. It is just space in RAM controlled by the rsp register (remember it?).

Think of it like a pile of plates: push puts a plate on top, pop takes one off. The call instruction pushes the return address and jumps. The ret instruction pops it and goes back to where it was.

The heap: memory on request

The heap gets memory while the program runs, when you do not know the size in advance.

The heap is a region of memory managed by library code like malloc, which asks the operating system for large chunks (on Linux with brk and mmap) and then splits them into pieces. malloc and free are not CPU features. They are bookkeeping lists of free blocks.

At machine level there are no variables, no objects, no heap. There are only addresses, values, and conventions. malloc(64) just finds 64 free bytes somewhere and returns the address.

Doing more at once: pipeline and cores

So far we described one executor running one instruction at a time. Modern CPUs go faster with two simple tricks.

Pipeline[^14]: Instead of finishing fetch, decode, execute for one instruction before starting the next, the CPU overlaps them like an assembly line. While one instruction executes, the next decodes and the one after fetches. That overlap is why a CPU can finish more than one instruction per clock tick.

Cores[^15]: Almost every processor today has several independent executors, called cores, each running its own fetch, decode, execute loop. One core is still the lonely executor from this post, but four or eight cores run four or eight loops in parallel.

The big picture

A CPU is a contract (the ISA), a workbench (registers), a calculator (the ALU), a conductor (the control unit), and a state machine running fetch, decode, execute on loop:

ISA (contract)
  ↓
registers (workbench)
  ↓
ALU (calculator)
  ↓
control unit (conductor)
  ↓
FETCH -> DECODE -> EXECUTE (state machine loop)

Stack, heap, and function calls are conventions built on addresses, values, and control flow. How an operating system turns this lonely executor into a machine running a hundred programs at once is another post.

[^1]: Central processing unit - Wikipedia

[^2]: Instruction set architecture - Wikipedia

[^3]: x86 - Wikipedia

[^4]: ARM architecture - Wikipedia

[^5]: RISC-V - Wikipedia

[^6]: Processor register - Wikipedia

[^7]: CPU cache - Wikipedia

[^8]: Arithmetic logic unit - Wikipedia

[^9]: Control unit - Wikipedia

[^10]: Finite-state machine - Wikipedia

[^11]: Instruction cycle - Wikipedia

[^12]: x86 calling conventions - Wikipedia

[^13]: Call stack - Wikipedia

[^14]: Instruction pipelining - Wikipedia

[^15]: Multi-core processor - Wikipedia

Digital Logic Explained

Thu, 03 Sep 2026 00:00:00 GMT

The CPU post treated the ALU and the control unit as given: boxes that add, compare, and orchestrate. This post opens those boxes. We will build upward from the humblest component, a switch, through the mathematics of true and false, the gates that embody it, the circuits that compute and remember, and finally the ladder that reaches back up to the processor.

The transistor: a switch, nothing more

At the bottom there is no Boolean logic, only physics. A transistor[^1] is an electrically controlled switch: a small voltage on one terminal decides whether current flows between the other two. On means current can flow; off means it is largely blocked.

Everything else in this post is a consequence of that one behavior plus a convention from the previous post: interpret a high voltage as 1 and a low voltage as 0. Billions of such switches, etched into silicon and wired together, become a machine that computes. You do not need the semiconductor physics to continue. Only the mental model of a switch being controlled billions of times per second matters.

Boolean logic: the math of true and false

Switches need a mathematics, and it is Boolean algebra[^2]: a system with only two values, 0 (false) and 1 (true), and three fundamental operations:

AND (A · B): 1 only if both inputs are 1.
OR (A + B): 1 if at least one input is 1.
NOT (¬A): flips the value (¬0 = 1, ¬1 = 0).

Two derived operations appear so often they earned their own names: XOR (exclusive OR, 1 when the inputs differ) and the negated pair NAND (NOT AND) and NOR (NOT OR). NAND is special because any Boolean function can be built from NAND gates alone. NOR shares this property. Chip designers love that, because mastering one gate type means being able to build everything.

The gates: logic made physical

A logic gate[^3] is the physical embodiment of a Boolean operation: a handful of transistors wired so the output voltage follows the operation's rule. Each gate is fully described by its truth table[^4]: every input combination and the resulting output.

AND, OR, and NOT:

AND          OR           NOT
A B | Q      A B | Q      A | Q
0 0 | 0      0 0 | 0      0 | 1
0 1 | 0      0 1 | 1      1 | 0
1 0 | 0      1 0 | 1
1 1 | 1      1 1 | 1

XOR[^5], NAND, and NOR[^6]:

XOR          NAND         NOR
A B | Q      A B | Q      A B | Q
0 0 | 0      0 0 | 1      0 0 | 1
0 1 | 1      0 1 | 1      0 1 | 0
1 0 | 1      1 0 | 1      1 0 | 0
1 1 | 0      1 1 | 0      1 1 | 0

Read XOR as "are they different?" and NAND as "not both." Once you can read these tables, you have the basic vocabulary for reading digital circuits: gates wired together.

Combinational logic: turning gates into useful machines

A combinational circuit is a circuit whose output is purely a function of the current inputs. No memory, no feedback loops: same inputs, same output, every time.

Three circuits cover most of what the CPU does.

1. The adder: the math engine

Adds binary numbers. The machine never sees 2, only 0 and 1, so an adder works on binary representations, never on real or floating point numbers. It does the same "carry the one" addition you learned in school, one column at a time.

Example: 01 + 01 = 10.

  01  (1)
+ 01  (1)
----
  10  (2)

Right column: 1 + 1 does not fit in a bit, so write 0 and carry 1. Left column: 0 + 0 + 1 = 1.

Inside, the smallest adder is the half adder: it adds two bits, with sum A XOR B and carry A AND B. A full adder adds the carry-in as well, and chaining eight of them gives a ripple-carry adder[^7] that adds two bytes.

Real example: 2 + 3 becomes 010 + 011 = 101 (5). The same circuit increments the program counter to fetch the next instruction.

2. The multiplexer (mux): the selector switch

A multiplexer[^8] is a digital selector switch: it routes one of several inputs to a single output, chosen by the select lines. A 2-to-1 mux:

S | Q
0 | D0
1 | D1

Real example: result = s ? b : a is a mux in code. The CPU uses muxes to pick which register feeds the ALU, or which result to keep.

3. The decoder: the address router

A decoder[^9] takes an n-bit binary code and activates exactly one of its 2^n output lines. A 2-to-4 decoder:

A1 A0 | Y0 Y1 Y2 Y3
0  0  | 1  0  0  0
0  1  | 0  1  0  0
1  0  | 0  0  1  0
1  1  | 0  0  0  1

Real example: to write into register 2, the CPU sends 10 and only that register's wire turns on.

Sequential logic: circuits that remember

A sequential circuit[^10] is a circuit whose output depends on both the current inputs and the previous state. To keep that state, the output is fed back into the input: a feedback loop.

Three components carry the state.

1. The flip-flop: one bit that stays put

A flip-flop[^11] is a 1-bit bistable storage element: it holds a 0 or a 1 even after the input goes away, and it only updates at the edge of the clock signal.

tick 1, D = 1         -> Q becomes 1 and holds 1
between ticks, D = *  -> Q still holds 1, whatever D does
tick 2, D = 0         -> Q becomes 0 and holds 0

Real example: a boolean flag like is_logged_in = true is a single flip-flop, holding its value while the CPU does other work.

2. The register: bits in formation

A register[^12] is an array of n flip-flops grouped together to store an n-bit binary word. Eight flip-flops sharing one clock is an 8-bit register.

store 5:  00000101 (each bit lives in one flip-flop)
tick:     all 8 bits are captured together
later:    00000101 is still there

Real example: when you write int a = 5, those eight bits sit in a register inside the CPU, the workbench where the processor keeps the values it is using right now. Add a mux to pick which register to read and a decoder to pick which one to write, and you get a register file.

3. The clock: everyone marches together

The clock signal[^13] is an oscillating square wave that synchronizes when state transitions happen across all flip-flops. It computes nothing: it only decides the moment everything updates.

Real example: if the clock ticks before the slowest adder has settled, a register captures the wrong value. That is why clock speed in gigahertz has a physical limit.

The big picture

The full ladder, bottom to top:

transistors
    ↓
logic gates
    ↓
circuits
    ↓
CPU

Transistors switch. Gates compute truth functions. Wiring gates together builds circuits: adders, multiplexers, and decoders compute without remembering, while registers remember, all synchronized by the clock. The ALU is just a circuit that combines arithmetic and logic. Add registers and control logic to it and you have a CPU, stepping through fetch-decode-execute on every clock edge.

We have now reached the processor: the next posts will move upward through memory, storage, and I/O, completing the picture of the machine before we leave hardware behind.

[^1]: Transistor - Wikipedia

[^2]: Boolean algebra - Wikipedia

[^3]: Logic gate - Wikipedia

[^4]: Truth table - Wikipedia

[^5]: XOR gate - Wikipedia

[^6]: NAND logic - Wikipedia

[^7]: Adder (electronics) - Wikipedia

[^8]: Multiplexer - Wikipedia

[^9]: Decoder - Wikipedia

[^10]: Sequential logic - Wikipedia

[^11]: Flip-flop (electronics) - Wikipedia

[^12]: Processor register - Wikipedia

[^13]: Clock signal - Wikipedia

Binary, Decimal, and Hex Conversions 101

Wed, 02 Sep 2026 00:00:00 GMT

Computers store everything as bits, but humans think in decimal and write shorthand in hexadecimal. The good news: decimal, binary, and hexadecimal are just three spellings of the same value.

This is the practical companion to Information Representation Explained. No theory of signed integers or floats here, just how to read and convert numbers confidently.

Bits and bytes first

Before bases, you need two words:

Bit: one binary digit, 0 or 1 (off or on). It is the smallest unit of information.
Byte: a set of 8 bits. It is the smallest addressable memory unit on modern computers, when you read 1 byte from memory, you always get 8 bits together.

With n bits you get 2^n values, so one byte gives 2^8 = 256 values (0-255). Half a byte (4 bits) is called a nibble, which matters for hex later.

The three bases in 30 seconds

Decimal (base 10): digits 0-9. Human-readable. Positions are (..., 10^2, 10^1, 10^0) or (..., 100, 10, 1).
```
342 = 3×100 + 4×10 + 2×1
```
Binary (base 2): digits 0-1. Machine-readable, this is what hardware stores. Positions are (..., 2^2, 2^1, 2^0) or (..., 4, 2, 1).
```
101 = (right to left) 1×1 + 0×2 + 1×4 = 5
```
Hexadecimal (base 16): digits 0-9 plus A-F for values 10-15. Binary shorthand. Positions are (..., 16^2, 16^1, 16^0) or (..., 256, 16, 1). One hex digit equals exactly 4 bits (a nibble, half a byte).
```
0x8DA = 8×256 + 13(D)×16 + 10(A)×1 = 2048 + 208 + 10 = 2266
```

1. Binary → decimal: add the weights

Read right to left with weights ..., 256, 128, 64, 32, 16, 8, 4, 2, 1. Use as many as you need, 8 bits is just common because it is 1 byte, numbers can be larger.

Multiply each bit by its weight and add, going right to left so the math flows from 1 upward:

0011 0100 = 0*1 + 0*2 + 1*4 + 0*8 + 1*16 + 1*32 + 0*64 + 0*128
         = 4+16+32 = 52

Same with the running example:

11010100 = 0*1 + 0*2 + 1*4 + 0*8 + 1*16 + 0*32 + 1*64 + 1*128
         = 4+16+64+128 = 212

So 0b11010100 = 212. Zeros add nothing, you can skip them once it clicks.

Quick check: 0b1011 = 1*1 + 1*2 + 0*4 + 1*8 = 1+2+8 = 11.

2. Decimal → binary: subtract the biggest weight that fits

Go left to right through the weights. If the weight fits, write 1 and subtract it. If not, write 0. Example with 212:

212 - 128 = 84  -> 1
84  - 64  = 20  -> 1
20  - 32  = no  -> 0
20  - 16  = 4   -> 1
4   - 8   = no  -> 0
4   - 4   = 0   -> 1
0   - 2   = no  -> 0
0   - 1   = no  -> 0

result: 11010100

Another one, 13:

13 - 8 = 5 -> 1 (skip 128,64,32,16)
5  - 4 = 1 -> 1
1  - 2 = no -> 0
1  - 1 = 0 -> 1

result: 1101 (or 00001101 as a full byte)

Pad with leading zeros to fill a full byte when you want: 13 = 00001101.

3. Binary → hex: group by 4, then add

One hex digit = 4 bits with weights 8 4 2 1. Add the weights, write 10-15 as A-F. No table to memorize.

Split the bits into groups of 4 from the right, then calculate each group by hand:

binary 1110 0011 to hexadecimal:

1110 = 0*1 + 1*2 + 1*4 + 1*8 = 2+4+8 = 14 = E
0011 = 1*1 + 1*2 + 0*4 + 0*8 = 1+2 = 3

result = 0xE3

Same idea with the running example: 1101 = 1*1 + 0*2 + 1*4 + 1*8 = 1+4+8 = 13 = D, 0100 = 0*1 + 0*2 + 1*4 + 0*8 = 4, so 11010100 -> 0xD4.

Pad the left with zeros if the length is not a multiple of 4:

0b10111 -> 0001 0111 -> 0x17
0b11111111 -> 1111 1111 -> 0xFF (255)

That is why hex is popular: 0xFF is much easier to read than 11111111.

4. Hex → binary: calculate each digit to 4 bits

Do the reverse. For each hex digit, subtract the biggest weight that fits (8, 4, 2, 1) and pad with zeros to 4 bits:

hexadecimal 0x3F to binary:

3 =
3 - 2 = 1 -> 1
1 - 1 = 0 -> 1
0011 (pad left with 00 to make the nibble)

F (15) =
15 - 8 = 7 -> 1
7 - 4 = 3 -> 1
3 - 2 = 1 -> 1
1 - 1 = 0 -> 1
1111

result = 00111111

More, same mechanics:

0xD4 -> D (13) = 8+4+0+1 = 1101, 4 = 0100 -> 11010100
0x2F -> 2 = 0010, F = 1111 -> 00101111 (47 in decimal)

Color codes work the same way: #FF5733 is three bytes 0xFF 0x57 0x33, meaning red=255, green=87, blue=51.

For longer hex, stick to the binary middle step, it's less error-prone.

Quick full loop

255 -> 11111111 -> 1111 1111 -> 0xFF

and back:

0xFF -> 11111111 -> 1+2+4+8+16+32+64+128 = 255.

Common beginner mistakes:

Reading 0x10 as ten. It is 16 (1×16 + 0).
Forgetting to group from the right. 0b10111 is 0x17, not 0xB7.
Trying to convert long hex to decimal directly. Expand to binary first (direct weights are fine only for 1-2 digits).

Once this feels easy, go back to Information Representation Explained to see how the same bits become signed integers, floats, text, and files.

Information Representation Explained

Wed, 02 Sep 2026 00:00:00 GMT

At the lowest level, a computer knows only two things: on and off. Every photo, song, spreadsheet, and video call is, underneath it all, a long sequence of ones and zeros. But a pile of bits means nothing by itself. What gives bits meaning is representation: the agreed-upon conventions that map bit patterns to numbers, text, and richer data structures.

This post walks through those conventions from the ground up: binary and hexadecimal[^1], unsigned and signed integers, the elegant trick of two's complement[^2], floating-point numbers[^3], characters and Unicode[^4], and finally how all of it composes into the data structures programs actually use.

Bits, binary, and hexadecimal

A bit is a single binary digit: 0 or 1. Eight bits form a byte, which is the smallest addressable unit of memory on most modern machines. With n bits you can represent 2^n distinct values: 1 bit gives 2 values, 8 bits give 256, 32 bits give about 4.3 billion.

Humans rarely read raw bits, so we group them. Binary[^1] is base 2, where each position is a power of two:

1 1 0 1 0 1 0 0
128 + 64 + 0 + 16 + 0 + 4 + 0 + 0 = 212

Hexadecimal[^5] (base 16) exists for one practical reason: a single hex digit maps to exactly four bits (a nibble), so it compresses binary without the mental gymnastics of decimal conversion:

binary:  1101 0100
hex:     D    4        -> 0xD4 (212 in decimal)

That is why you see hex everywhere in computing: memory addresses (0x7ffee4a3b8c0), color codes (#FF5733), and byte dumps. The 0x prefix (and 0b for binary, as in 0b11010100) is just a notational convention popularized by C and adopted by many later languages. Whenever you see hex, read it as shorthand for bits, not as a different kind of number.

New to number base conversions? See the dedicated step-by-step guide: Binary, Decimal, and Hex Conversions 101.

How numbers are stored

Numbers are stored as fixed-width bit patterns. The width (uint8, uint16, uint32…) decides the range. Three cases: never negative, possibly negative, and fractional.

Unsigned integers

Same binary as above. Use it for values that can never be negative: counts, sizes, pixel brightness. Range is 0 to 2^n - 1 (uint8: 0-255, uint32: 0-4,294,967,295).

It wraps like an odometer: uint8 255 + 1 = 0. Hardware does arithmetic modulo 2^n; languages differ in how they expose overflow.

Signed integers

For values that can be negative: temperature, balance, offsets. Use two's complement[^2]: to negate, invert every bit and add one.

+4  = 0000 0100
flip: 1111 1011

Add one, bit by bit from the right. A bit only holds 0 or 1, so 1 + 1 = 2 does not fit, write 0 and carry 1 to the left:

  1111 1011
+ 0000 0001
----------
  1111 1100 = -4

Right to left:

-> 1 + 1 = 2 -> 0, carry 1
-> 1 + 0 + carry 1 = 2 -> 0, carry 1
-> 0 + 0 + carry 1 = 1
-> 1 + 0 = 1
-> 1 + 0 = 1
-> 1 + 0 = 1
-> 1 + 0 = 1
-> 1 + 0 = 1

Adding them gives 0000 0100 + 1111 1100 = 1 0000 0000, the 9th bit vanishes, leaving 0. Same adder works for signed and unsigned. Side effects: 8-bit range is -128 to +127 (asymmetric), single zero, top bit reads as sign (1 = negative).

Floating point: IEEE 754

Computers can't store a floating number in a single block of memory, so they split it into 3 parts:

sign (1 bit)
exponent (8 bits)
fraction (23 bits)

So how do we transform a number like 5.75 into binary? We must write it in scientific notation in base 2:

1. Decimal to binary

Split integer and fractional parts:

5.75
- 5 -> stay 5 = 101 (binary)
- 0.75 -> 0.75 * 2 = 1.5 -> stay 1 = 1 (binary), carry 0.5
- 0.5 -> 0.5 * 2 = 1 -> stay 1 = 1 (binary)

=> 101.11 (binary)

2. Normalize to `1.xxx * 2^exp`

Simply move the point until there is only a single 1 on the left.
The exponent is how many positions we had to move it. Here 2 positions to the left:

101.11 = 1.0111 * 2^2, so exponent = 2

3. Fill the 3 fields

1. Sign (1 bit) -> The Sign Bit

Look at the whole number itself (+5.75). Is it positive or negative?

Positive -> 0 (if it were -5.75, this bit would be 1).

2. Exponent (8 bits) -> The Exponent Field

You already mastered this! Shift count = 2. Add bias: 2 + 127 = 129. In binary, grouped in nibbles:

129 = 1000 0001

3. Fraction (23 bits) -> The Mantissa Field

Look at the normalized binary string: 1.0111. Break that string at the dot:

The 1. before the dot: this is the implicit part. It is NOT written into memory.
The 0111 after the dot: this is the actual fraction. You take these exact 4 bits and copy them directly into the fraction field: 0111. Then fill the remaining empty slots with zeros to reach 23 bits, grouped in nibbles:

0111 0000 0000 0000 0000 000

Putting it together side-by-side:

Normalized: (+) 1.  0111          * 2^2
             │  │    │                │
             ▼  ▼    ▼                ▼
Field:      Sign[ ] Exponent (+127) Fraction
Stored:      0      1000 0001       01110000000000000000000
                ▲
         (Implicit 1. is dropped!)

Final 32 bits, grouped in nibbles:

bits: 0100 0000 1011 1000 0000 0000 0000 0000 = 0x40B80000

Special patterns & practical lessons

Special values (IEEE 754 reserves):[^3]

Exponent all zeros (0000 0000): signed zero (+0.0 / -0.0) or subnormals, extremely small values near zero where the implicit leading bit becomes 0. instead of 1..
Exponent all ones (1111 1111):
- Fraction all zeros -> Infinity (+inf or -inf).
- Fraction non-zero -> NaN (Not a Number, e.g. 0.0 / 0.0 or sqrt(-1)). NaN compares unequal to everything, including itself.

Two golden rules for developers:[^6]

Never compare floats with ==. Most decimal fractions (like 0.1) repeat infinitely in binary. 0.1 + 0.2 becomes 0.30000000000000004, so exact equality checks fail due to small rounding differences.
Floats are for measurements, not money. Rounding error accumulates. Financial systems use integer cents or dedicated decimal types to avoid losing money to floating-point drift. A 64-bit double (1 sign + 11 exponent + 52 fraction bits) helps, but does not eliminate rounding error.

How other data is stored

Beyond numbers, everything is patterns agreed by convention, like ASCII mapping numbers to letters.

Characters and Unicode

Text is stored as numbers for letters: the industry agrees which number means which letter.

ASCII[^7] (1963) assigned the English alphabet, digits, and control codes to 7-bit numbers 0–127: A is 65, a is 97. One byte per character, beautifully simple yet useless for the rest of the world's writing systems. The following decades produced a chaos of incompatible 8-bit extensions ("code pages") where the same byte meant é in one country and Ω in another.

Unicode[^4] fixed this by separating two concerns: a universal catalog assigning a permanent number to each entry (a code point, written U+00E9 for é), and encodings that map code points to bytes. The dominant encoding is UTF-8[^8], and its design is a small masterpiece:

U+0000–U+007F:  0xxxxxxx                              (ASCII, 1 byte)
U+0080–U+07FF:  110xxxxx 10xxxxxx                     (2 bytes)
U+0800–U+FFFF:  1110xxxx 10xxxxxx 10xxxxxx            (3 bytes)
U+10000–U+10FFFF: 11110xxx 10xxxxxx 10xxxxxx 10xxxxxx (4 bytes)

The x bits carry the code point; the leading bits announce the length. Example: é is U+00E9 = 1110 1001 in binary, which fits the 2-byte template as 110_00011 10_101001 = bytes 0xC3 0xA9. The euro sign € (U+20AC) needs three bytes: 0xE2 0x82 0xAC.

Three properties made UTF-8 win: ASCII text is valid UTF-8 unchanged (backward compatible), no ASCII byte can appear as part of a multi-byte sequence, making ASCII delimiters and control bytes easy to recognize, and you can resynchronize mid-stream after corruption.

(UTF-16[^9] code units are used by Java and JavaScript, and Windows APIs use UTF-16 extensively; it encodes text in 2-byte units with surrogate pairs for characters beyond U+FFFF, which is why "😀".length is 2 in JavaScript.)

Why did systems like Java, JavaScript, and Windows adopt UTF-16?

In the early 1990s, Unicode was originally designed as a fixed 16-bit encoding (UCS-2) supporting 65,536 characters (U+0000 to U+FFFF). Engineers believed 16 bits would be enough for all human writing systems forever, offering fast, constant-time indexing.

When Unicode later expanded beyond 65,536 characters, UCS-2 evolved into UTF-16 using surrogate pairs, but by then, these major platforms were already locked into 16-bit core runtimes.

Classic text bugs all trace back to this layer: mojibake (decoding bytes with the wrong encoding), confusing character count with byte count, and assuming one visible glyph equals one code point (accents and emoji can combine several).

Representing data: from bytes to meaning

Lists, records, images and sound are compositions of the above, plus endianness[^10]: the agreed order in which the bytes of a multi-byte value like 0x12345678 are stored in memory. Getting it wrong silently garbles every number, which is why formats like PNG and network byte order conventions specify byte order explicitly.

Little-endian: least-significant-byte-first. The value 0x12345678 is stored as 78 56 34 12. This is what your personal computer uses: x86 (Intel/AMD) and ARM chips in little-endian mode store multi-byte integers this way in RAM. It is the "host byte order" for most desktops, laptops, and phones.
Big-endian: most-significant-byte-first. The same value is stored as 12 34 56 78, in the order humans naturally read hex. This is the standard for network protocols and many file formats: TCP/IP declares big-endian as "network byte order", so every port number, length field, and address traveling over the wire uses it.

What happens when you send a message right now? When you type on your little-endian laptop and click send, your bytes must be translated twice:

[ Your Device ]                 [ Network Wire ]                [ Server / Target ]
Little-Endian                   Big-Endian                      Little-Endian
(x86 / ARM)                     (Network Byte Order)            (x86 / ARM)

RAM/CPU                         Network Interface Card          RAM/CPU
0x78 0x56 0x34 0x12 ---htons()--> 0x12 0x34 0x56 0x78 ---ntohs()--> 0x78 0x56 0x34 0x12

Local processing (your device): your CPU builds packet headers (length, port numbers) in little-endian in RAM.
Translation (htons() / htonl()): before handing data to the network card, software calls htons() (host-to-network-short) or htonl() (host-to-network-long). These flip multi-byte integers from little-endian to big-endian.
Transmission over the wire: the data travels across the internet in big-endian network byte order.
Reception and decoding: the receiving server calls ntohs() (network-to-host-short) to flip the bytes back into little-endian so its own x86 or ARM CPU can read the numbers correctly.

Common building blocks:

Booleans and enums: often a single byte holding 0/1 (sometimes packed into bits or using larger units depending on the language and ABI); enums map names to small integers.
Arrays: elements laid out back-to-back; indexing is just base_address + index * element_size.
Structs/records: fields concatenated, often with padding bytes inserted so each field lands on an aligned address the CPU can read efficiently. A struct's size is not always the sum of its fields.
Strings: either length-prefixed (Pascal style: length first, then bytes) or null-terminated (C style: bytes ending in 0x00), the latter being a classic source of buffer overflows.
Media: a pixel is commonly three bytes (red, green, blue) in basic RGB; audio is thousands of amplitude samples per second; video is images plus math that exploits what eyes won't notice. JPEGs and MP3s are just very clever agreements about which details to throw away.

And the deepest lesson of all: a type is an interpretation, not a property of the bits. The 32 bits 0x40490FDB are the float 3.1415927 and simultaneously the unsigned integer 1078530011. The bits never changed; only the lens did. Every cast, every reinterpret, every debugger "view as" command is a reminder that meaning lives in the convention, agreed upon by whoever wrote the bytes and whoever reads them.

[^1]: Binary number - Wikipedia

[^2]: Two's complement - Wikipedia

[^3]: IEEE 754 - Wikipedia

[^4]: Unicode - Wikipedia

[^5]: Hexadecimal - Wikipedia

[^6]: Floating-point arithmetic - Wikipedia

[^7]: ASCII - Wikipedia

[^8]: UTF-8 - Wikipedia

[^9]: UTF-16 - Wikipedia

[^10]: Endianness - Wikipedia

The Computer Explained

Tue, 01 Sep 2026 00:00:00 GMT

A computer is a machine that follows instructions incredibly fast. That is the entire idea. Everything else, from gigahertz and gigabytes to operating systems and apps, is detail piled on top of that one concept. This post stays at the panoramic level: what computation is, what the main parts are, how hardware evolved, and how they cooperate to run a program.

What is computation?

Strictly speaking, computation[^1] is any type of arithmetic or non-arithmetic calculation that follows a well-defined model or set of steps. Anything or anyone that performs computations, whether mechanical devices, electronic systems, or human beings, is known as a computer[^2]. A problem is considered computable if it is well-defined enough to be solved by an algorithmic process.

Computers are everywhere

Computers are not just laptops and smartphones. Strictly speaking, a computer is any machine that takes inputs, processes them by following instructions, and produces outputs. A simple calculator, a TV remote, or even a microSD card with its own tiny controller chip inside, all of them take inputs, run stored instructions, and produce outputs. They are computers too, just smaller and single-minded.

They form the core of general-purpose devices and are the invisible engine that powers the modern internet and global infrastructure.

The evolutionary journey

Before computers, machines did one fixed job: a loom wove one pattern, a calculator added. The idea of a general, programmable machine predates electronics by a century.

In the 1830s Charles Babbage[^3], widely regarded as the father of computing, designed the Analytical Engine[^4], a mechanical, program-driven computer with a "store" for data and a "mill" for processing, the direct ancestors of memory and CPU.

In 1936 Alan Turing[^5] gave that intuition a rigorous foundation with the universal machine[^6], showing that a single device reading different instructions could compute anything computable, the theoretical blueprint of the modern computer.

In 1937 Claude Shannon[^7] closed the gap between logic and hardware by showing that Boolean algebra[^8] could be implemented directly with electronic switching circuits. Logic was no longer just mathematics on paper: it could be built.

The breakthrough that turned this theory into working machines is the stored-program concept[^9], formalized as the von Neumann architecture[^10] by John von Neumann[^11] in 1945: one shared memory holding both programs and data, with a processor that fetches instructions from it and executes them. Because a program is stored like data, the same machine can run a spreadsheet, a game, or a web browser, just load different instructions. Simple and general, it remains the blueprint of your laptop and phone.

From there, the hardware evolved in clear steps: primitive tools to mechanical machines, then vacuum tubes to transistors to integrated circuits, down to today's systems-on-a-chip (SoCs)[^12], where CPU, memory, graphics, and radio live on a single piece of silicon.

The core anatomy of a computer

At the architecture level, a computer relies on a synchronized division of labor. Here are the parts, one by one.

The processor (CPU)

The central processing unit[^13] is the part that executes instructions. At a conceptual level, its work can be described as fetch, decode, execute: grab the next instruction from memory, figure out what it says, do it, then move to the next one, billions of times per second. Real modern cores blur this simple picture with pipelines, superscalar and out-of-order execution, and layers of cache, but the fetch-decode-execute cycle remains a useful conceptual model underneath them.

Inside, a CPU has a small set of ultra-fast slots called registers for the values it is working on right now, an arithmetic-logic unit (ALU) that does the actual math and comparisons, and a control unit conducting the whole dance. Modern CPUs pack multiple cores (independent workers) and layers of cache (tiny, blazing-fast memory sitting next to the cores) to keep that loop fed. Clock speed, measured in gigahertz, is how many clock cycles occur per second, one factor among many in determining performance.

RAM

Random-access memory[^14] is the computer's workbench: fast, temporary storage where running programs and their data live. Memory is addressable, so the CPU can access locations directly, hence "random access." Direct does not mean instantaneous, though: every access takes time (latency), and that delay is one reason machines surround the CPU with caches.

Two traits define RAM: it is fast (much faster than persistent storage) and volatile (it forgets everything when the power goes out). That is why unsaved work vanishes in a blackout and why machines with more RAM juggle more apps at once. There is simply a bigger workbench.

Storage

Storage[^15] is the filing cabinet: slower than RAM but persistent, since it remembers without power. Hard drives keep bits as magnetic patterns on spinning platters; SSDs[^16] store data in NAND flash memory, using electrical charge to represent information. With no moving parts, they are typically faster and quieter.

The classic tradeoff of computing lives here: registers are among the fastest and tiniest, followed by cache, RAM, and persistent storage such as SSDs and hard drives, each step slower, bigger, and cheaper per byte. Remote storage adds another dimension: network latency. The whole art of performance is keeping the data the CPU needs right now as high up that ladder as possible.

Input and output

A computer with no senses and no voice would be useless. Input devices[^17] (keyboard, mouse, touchscreen, microphone, camera, network card) bring information into the computer; output devices[^18] (screen, speakers, printer, network card again) carry information back out. The network card is both at once, allowing a machine to communicate without any physical cable connected to it.

Software: the machine's soul

Hardware without instructions is an expensive paperweight. System software[^19], above all the operating system[^20] (Linux, Windows, macOS, Android), manages the hardware on everyone else's behalf: deciding which program gets CPU time, handing out memory, talking to disks and screens through drivers. Application software, like your browser, editor, and games, runs on top, asking the OS for everything instead of touching hardware directly.

Specialized processors (GPU)

Not every job suits the CPU. Graphics, machine learning, and scientific simulation all share a shape: the same simple operation applied to enormous amounts of data at once. The graphics processing unit[^21] is built for exactly that, with thousands of small, simple cores optimized for throughput, while CPUs are generally optimized for low-latency, general-purpose work and complex control flow.

GPUs were born to draw triangles and shade pixels, work that is embarrassingly parallel. Programmers then realized the same hardware accelerates anything with that shape, a practice called general-purpose GPU computing[^22]. Today the CPU routinely offloads suitable work to the GPU (and increasingly to NPUs for AI), an arrangement called heterogeneous computing: each processor doing what it does best.

From power button to program

Press power and the machine wakes up with RAM empty, since RAM is volatile. Firmware stored on the machine runs first, initializes the hardware, finds a bootable device, and loads the operating system's kernel into memory. The OS starts its services, shows you a login screen, and waits.

Launch an app and the OS loads its code from storage into memory, points the CPU at its first instruction, and the fetch-decode-execute loop takes over. The app asks the OS to draw windows and read files; the OS talks to the hardware; results flow back as pixels and sound. Billions of instruction cycles per second, all to move a cursor or play a song, and it feels instant.

The big picture

CPU executes, memory hosts the work in progress, storage remembers, input and output connect to the world, specialized processors accelerate parallel work, and software tells everyone what to do. Change any one of them and the machine changes character, but the division of labor stays the same, from a smartwatch to a supercomputer.

[^1]: Computation - Wikipedia

[^2]: Computer - Wikipedia

[^3]: Charles Babbage - Wikipedia

[^4]: Analytical Engine - Wikipedia

[^5]: Alan Turing - Wikipedia

[^6]: Universal Turing machine - Wikipedia

[^7]: Claude Shannon - Wikipedia

[^8]: Boolean algebra - Wikipedia

[^9]: Stored-program computer - Wikipedia

[^10]: Von Neumann architecture - Wikipedia

[^11]: John von Neumann - Wikipedia

[^12]: System on a chip - Wikipedia

[^13]: Central processing unit - Wikipedia

[^14]: Random-access memory - Wikipedia

[^15]: Computer data storage - Wikipedia

[^16]: Solid-state drive - Wikipedia

[^17]: Input device - Wikipedia

[^18]: Output device - Wikipedia

[^19]: System software - Wikipedia

[^20]: Operating system - Wikipedia

[^21]: Graphics processing unit - Wikipedia

[^22]: General-purpose computing on graphics processing units - Wikipedia

The Stellar Heritage: From Supernova to Consciousness

Thu, 23 Oct 2025 00:00:00 GMT

Approximately 4.6 billion years ago, the cosmos was a vast stage of darkness and primordial hydrogen. But the silence was about to be broken by creative violence.

In a vacuum, the death of a colossal star older than our solar system reached its climax. The supernova explosion was not an end, but a distribution of cosmic wealth.[^1]

When the stellar echo faded, only its ashes remained: a cloud of dust and gas enriched with heavy elements such as silicon, iron, carbon, and nickel. These were the building blocks of matter, forged under extreme pressure and temperature in the core of the dying star. We are, quite literally, stardust.[^2]

These fragments floated, disorganized, until the silent, omnipresent force of gravity began to organize them. Slowly, grain by grain, the material began to attract, collide, and clump together.

Most of the mass collapsed to ignite a new star, the Sun.[^3] Around it, the remaining material flattened into a rotating protoplanetary disk, a vast workshop of planetary creation.[^4][^5]

Within this swirling disk, rocks clashed and fused. Some worlds became distant gas giants, but one, at just the right distance, found the perfect balance of mass, energy, and elements. And we call this world Earth.[^6]

For hundreds of millions of years, its surface was a brewing inferno. Volcanic storms, meteorite impacts, and relentless heat shaped a wild and violent landscape. Yet beneath this fury, chemistry began to experiment.

Simple molecules, in primitive broths, began to interact in complex ways. They repeated themselves, persisted... Until, in a sublime and almost unimaginable moment, matter reached a threshold: it learned to self copy. What was inert became alive.[^7][^8]

This small blue planet, suspended in the vastness of the cosmos, now held an unprecedented promise. The possibility of beings capable not only of surviving, but of evolving to the point of looking up at the night sky and asking the most profound question: Why do we exist?

It is this lineage, this heritage of the stars, that culminates in human curiosity. We are fragments of that ancient supernova which, after 4.6 billion years of journeying, finally gained the ability to look back and understand its own stellar origin.

Disclaimer

This text is a work of scientific dissemination and poetic appreciation.

The events narrated here (the formation of the Sun, the Earth, and the origin of life) are based on the most widely accepted scientific models and theories in Astrophysics, Geology, and Biology.

For narrative and emotional impact, the time and scale of events have been condensed. Science is a continuous process of discovery, and the exact details of our origins remain the subject of intense research. Our goal is to inspire curiosity and wonder about the cosmic journey we are part of.

[^1]: Supernova - Wikipedia

[^2]: Stellar nucleosynthesis - Wikipedia

[^3]: Sun - Wikipedia

[^4]: Protoplanetary disk - Wikipedia

[^5]: Formation and evolution of the Solar System - Wikipedia

[^6]: Earth - Wikipedia

[^7]: Abiogenesis - Wikipedia

[^8]: Origin of life - Wikipedia

What I Would Do If I Were Starting My Software Engineering Journey Today

Fri, 19 Sep 2025 00:00:00 GMT

If I could go back in time and restart my coding journey, I'd do things a little differently. Not because I messed up before, but because I’ve since figured out a more chill, yet super effective, way to become a killer software engineer, even if you're starting from zero.

My old self would get all hyped up about the latest trendy languages and frameworks, jumping straight into the deep end. My new, wiser self would skip all that noise and build a rock solid foundation first. Think of it like this: I’d rather learn to be a master chef than just a pro at using one specific brand of microwave.

Forget the Fads, Learn the Fundamentals

When you're first starting, the temptation is real. You want to learn React, Java Spring Boot, or some other cool, shiny tool. I get it. But that's like trying to build a skyscraper without knowing how to lay a single brick. I'd do the opposite. I'd get my hands dirty with the stuff that happens "under the hood."

C and C++ Are Your Funky New Friends

Don't let these languages scare you. They're not just about weird syntax; they're about boot camp for your brain. They force you to learn low level stuff like memory management and pointers. Why? Because understanding how a computer handles its memory is a superpower. It helps you write lightning fast code and debug problems that would make most developers want to cry.

Python for Data Structures & Algorithms (DSA)

A lot of new coders run screaming from DSA, but it's the secret sauce of all great engineers. I'd use Python because its simple syntax lets you focus on the most important part: the logic.

Think of it like learning to play the guitar. You’re not just training for a future gig; you're building the finger strength and rhythm that will let you play anything. When you get good at DSA, you start seeing the skeleton of every problem, and that’s when you level up from a "coder" to a true engineer.

A coder knows how to follow a recipe. An engineer understands why the ingredients work together and can invent their own dishes.

Do it Yourself

Formal education is great, but it's not the only way to the top. All you really need is discipline and a good dose of curiosity, just get your hands dirty and start building things. The best way to learn is by doing, so dive into projects that challenge you, frustrate you, and ultimately teach you something new, and also have fun while doing it.

Be careful not to fall into the trap of just building crud project after crud project. Instead, focus on projects that push your boundaries and make you think critically.

Also, don't just copy code from tutorials. Try to understand it, tweak it, and make it your own. This is how you truly learn.

Pick Your Courses Wisely

Don't just collect online courses like trading cards. Find one that teaches you how to think, not just what to type. A fantastic example is @Harvard's CS50. It won't hold your hand and teach you a single language. Instead, it throws you into the deep end and forces you to think like a computer scientist.

But if you are looking for some courses recommendations, here are a few websites where you can find high-quality courses:

edX (free)
freeCodeCamp (free)
MIT OpenCourseWare (free)
Coursera (free and paid)
Udacity (free and paid)
Udemy (free and paid)
Khan Academy (free)

And heres a few websites where you can learn and practice your skills:

GeeksforGeeks (free)
LeetCode (free)
HackerRank (free)
Codewars (free)
CodeChef (free)

Build Projects That Actually Solve a Problem

My biggest rookie mistake was building generic "portfolio projects" that nobody needed. The smart way to do it is to solve a real problem for yourself or someone you know.

Need to organize your mess of downloads? Write a script for it. Can't find the best deals online? Build a price tracker. The project doesn't have to be a masterpiece. The real magic is in the messy process: planning, building, failing, yelling at your screen, and then finally getting it to work.

Reading about swimming is one thing. Actually jumping in the pool is what gets you wet (and makes you a swimmer).

Your Portfolio Is Your Story

Your GitHub profile shouldn't just be a graveyard of old projects; it should be a comic book of your journey, showing all your battles and victories.

Use Your README.md Like a Storybook

For every project, write a solid README.md. Explain the problem you were solving, the choices you made, and the challenges you faced. This isn't just showing off your code; it's showing off your brain. It tells a potential employer you're not just a code monkey; you're a thinker.

Try to Contribute to Open Source

Instead of just building things from scratch, find an open-source project and contribute. It's like joining a band instead of just playing in your bedroom. You learn how to work with a team, navigate real-world codebases, and follow professional quality standards.

A great portfolio doesn't just show that you can code; it shows you can think like an engineer.

How to Get Your First Gig Without Losing Your Mind

Everyone thinks they need to be 100% ready before they start applying for jobs. That's a myth. The job hunt itself is one of the best ways to learn.

Hunt for Learning Opportunities, Not Just Paychecks

Skip the "dream job" fantasy for now. Instead, focus on internships and trainee programs. These positions are designed for you to grow. The mentorship and hands-on experience are worth way more than a high starting salary.

Learn to Be Your Own Hero

In the age of AI, the most valuable skill you can have is the ability to figure things out on your own. Before you run to Stack Overflow or ChatGPT for help, try to debug the problem yourself. This doesn't mean you have to work in isolation; it means you're training your brain to be resourceful and independent.

Final Thoughts (The Pep Talk)

Every mistake is a lesson. Every interview is a practice round. Every line of code you write is a step forward.

Think about the trade-offs of every decision you make. Why did you use that data structure? Why did you choose that API architecture? Thinking about these choices early on is what forges an engineering mind.

If you’re just starting, remember this: the path to becoming a great software engineer isn't a race. It's more like growing a tree. You don't get fruit overnight, but if you keep watering it, it’ll grow strong roots that will support you for your entire career.

Who I Am & Why This Blog Exists

Thu, 18 Sep 2025 00:00:00 GMT

Hello! First of all, thank you for your time and curiosity. This post marks the restart of a blog I began a few years ago, and my goal is to share the journey, the mistakes, and the lessons that brought me here.

From the beginning, I’ve identified as a generalist programmer. My focus has always been on computational thinking rather than a specific language, which allowed me to learn new technologies quickly. I was driven by curiosity, how do computers really work? Who gives the orders? How does a machine know what to do when you press a button? These questions pushed me to truly understand.

I started my journey by learning C and naturally moved on to C++, which gave me a solid foundation to understand pointers, garbage collection, and how high-level languages work "under the hood." Later, learning Java or Python became much easier. However, at some point, I got lost in the avalanche of technologies and frameworks. In the rush to deliver quick solutions and attract recruiters, I skipped fundamental steps, building monolithic CRUD applications using MVC architecture. It was fun, but it left significant gaps in my knowledge.

Without professional experience, entering the job market was tough. So I decided to pursue a three-year Information Technology degree, highly rated by the Brazilian Ministry of Education, with 90% employability and conveniently located near my home. The course felt like it was made for me and it was truly transformative. Subjects like calculus, algorithms, computer architecture, and networks gave me the depth I was missing. I built a home lab with an Ubuntu server to test and apply everything I learned in practice. From databases to Python applications, everything ran on my mini cloud.

It was in this academic environment that a fundamental lesson shaped my path. I had an extraordinary and visionary professor who taught me more than just code or math, he taught me to question concepts, to seek the "whys" behind things, and to challenge what I thought I knew. That mindset changed the way I study, code, and face challenges. Digging into the fundamentals became my main tool.

When I started applying for internships, this foundation proved essential. The market demanded technologies I didn’t yet master, like .NET, Spring Boot, and Node.js. I dove into studying, built projects to demonstrate my potential, and eventually landed a position as a C# developer. My solid foundation allowed me to learn quickly, deliver results, and earn my team's trust. It was proof that understanding the core concepts makes any technology accessible.

Despite the progress, I acknowledge that for a long time I spread myself too thin trying to learn a bit of everything without enough depth. That cost me some great opportunities during college, where I went through more than 20 technical interviews that could have changed my life. Unfortunately, I wasn’t at the level they required. Today, this restart is a commitment: to study in depth, to understand trade-offs, and to stop skipping steps. Decisions like whether to use a relational database or not, or whether to choose an event-driven architecture, are what shape a software engineer's career.

If you’re just starting out, here are some pieces of advice I consider valuable:

Learn C and C++: The foundation these languages provide is unmatched.
Master Data Structures and Algorithms (DSA): Use Python to speed up the implementation of your solutions.
Invest in formal education: If possible, a degree in Computer Science or a related field makes a huge difference.
Pursue internships early: Apply to companies you admire. Send lots of applications and take advantage of opportunities as soon as you can.
Don’t give up: The journey is tough, but the rewards are immense.

Remember: your career is a marathon, not a 100 meter sprint. There will be moments of doubt and frustration, and the temptation to take shortcuts will be constant. In those moments, return to the fundamentals and reconnect with the curiosity that made you start. Every challenge you overcome not only adds a line to your résumé, but also strengthens the engineer you are becoming.

This is my restart, and I hope that by sharing my journey, we can learn and grow together. Let’s move forward.