Containers are not virtual machines. They are not even a single Linux feature. They are ordinary processes wearing a disguise stitched together from namespaces, cgroups, chroot, networking isolation, and security policies. The author of this blog post decided to build a container runtime from scratch and immediately started tripping over the seams that Docker's polished interface hides from you. The resulting notes are brief, punchy, and genuinely useful for anyone who has typed docker run without thinking about what happens underneath. The most clarifying insight is the simplest: images are just folders. When you docker run ubuntu, Docker downloads a filesystem tree, drops it somewhere on disk, and calls chroot or pivotroot to make that folder the new root for your process. That's it. No magic binary format, no hypervisor, no hardware partitioning. Once you see this, Docker's entire abstraction layer becomes transparent in a way that changes how you think about containers permanently. The Go critique is the piece with the most teeth. Docker's runtime, runc, is written in Go, and Go's runtime is natively multi-threaded — a cool feature for application servers, a headache for a container runtime that needs to make single-threaded Linux syscalls before the Go scheduler spins up. The workaround is a C module that runs before Go's runtime initializes. Go also lacks fork, which is exactly what a container runtime wants: fork, set up restrictions, exec the target process. Runc approximates fork by re-executing itself via /proc/self/exe with a special flag. These are real engineering hacks solving real impedance mismatches, and they are fascinating. The root-privilege situation is another quiet revelation. Many of the kernel APIs containers depend on require root, so the Docker daemon typically runs as root. Rootless container runtimes exist but have to reimplement the entire networking stack in userspace to deliver the same features. Container security engineers have the author's sympathy and ours. This is a blog post, not a book or a course. It is short, deliberately incomplete, and written in the voice of someone learning in public. It does not pretend to be comprehensive. What it does well is select exactly the right five or six surprises that reframe your mental model of containers, deliver them without filler, and make you want to go read the Linux man pages yourself. That is a specific and underrated skill in technical writing. The format — a personal learning journal with technical specifics — sits in a tradition that includes Julia Evans' zines and blog posts, Jessie Frazelle's container deep-dives, and the "build your own X" genre that treats reimplementation as pedagogy. The author is early in the project and knows it, which gives the piece an honesty that more polished explainers often lack. You are watching someone think, not watching someone perform expertise.
