The Container Question: What LFS Builders Gain (and Lose) When They Dockerize Their Own Work

There is a particular irony familiar to anyone who has spent a weekend compiling Glibc from source: the same engineer who insists on building every package by hand will, on Monday morning, type docker run without a second thought. Is that hypocrisy, pragmatism, or something more interesting?

We put the question to builders in the Linux From Scratch community who operate hand-compiled systems as the foundation for containerized workloads. Their answers reveal less a contradiction than a deliberate division of labor — with a few genuine tensions worth naming.

Abstraction Is Only a Mystery If You Let It Be

Marcus Delgado, a platform engineer at a mid-sized logistics firm outside Denver, built his first LFS system in 2019 and still maintains a hand-rolled host for his home lab. For him, the relationship between LFS and containers is pedagogical.

"Docker is a black box to most engineers," he told us. "It isn't to me, because I've sat inside the box. I know what a container image actually is — a root filesystem, some namespaces, a cgroup or two. I know because I've built root filesystems from scratch with nothing but a compiler and a book."

That knowledge pays practical dividends. When an image fails to start, when a syscall is blocked by a seccomp profile, when a volume mount misbehaves because of a kernel version mismatch, engineers with from-source experience tend to diagnose the problem at the right layer instead of guessing. Delgado's advice to junior colleagues is consistent: you don't need to build LFS to use Docker, but the exercise permanently changes how you reason about it.

The Host Still Matters

There is a tempting fiction in the container world that the host operating system is irrelevant — a mere bootloader for the container runtime. LFS builders know better.

A hand-built host gives you exact visibility into the kernel configuration, the enabled syscalls, the cgroup version, and the security posture of the machine underneath your containers. On a stock distribution, those details arrive as someone else's decisions. On an LFS system, they are yours, documented in your own .config file and build logs.

This matters in concrete ways. Containers running on an LFS host with a deliberately minimal kernel expose a smaller attack surface than the same containers on a general-purpose distro. Teams running GPU workloads, eBPF tooling, or real-time requirements often find that understanding the host kernel — because they configured it — saves days of troubleshooting that container abstraction would otherwise obscure.

Where the Philosophies Genuinely Collide

Honesty requires acknowledging the friction. The LFS ethos is maximal control; the container ethos is disposable infrastructure. Rebuilding a base image weekly sits comfortably with docker build, less comfortably with a workflow where a toolchain upgrade means scheduling an afternoon of compilation and testing.

There is also the reproducibility gap. Two engineers building the same LFS book on different hardware can produce subtly different systems; container images, at least in principle, are bit-for-bit identical wherever they run. Builders who care about verifiable builds have increasingly turned their LFS discipline toward creating minimal, auditable base images — a kind of bridge between the two worlds, though one that demands real effort to maintain.

And time is not free. A veteran builder in Austin, who asked to be identified only as "a person with strong opinions about binutils," put it bluntly: "If your job is shipping product, LFS as a daily driver is a hobby. If your job is understanding systems, it's the best professional development money can't buy."

A Practical Middle Path

For builders weighing the question, a pattern emerges from those who run both:

• Use LFS as the host, containers as the workload. A hand-built base with a container runtime on top gives you a minimal, fully understood substrate and modern deployment ergonomics above it.
• Treat image builds like package builds. Apply the same rigor — pinned sources, recorded build flags, changelogs — to your Dockerfiles that you apply to your LFS toolchain.
• Keep one machine pure. Nearly every builder we spoke with maintains at least one hand-built system with no containers at all, as a reference and a reminder of what the abstractions are abstracting.
• Don't evangelize either direction. The engineer who insists everything must be compiled from source is making the mirror-image mistake of the one who insists the host doesn't matter.

The Verdict

Wrapping a hand-built system in containers is neither surrender nor salvation. It is a choice about which layers of the stack deserve your attention today. The LFS builder who understands what docker run actually does — because they once did it manually — is arguably better positioned to use containers well than anyone who has only ever known the abstraction.

Build what you need to understand. Containerize what you need to ship. The two are not enemies; one simply knows too much to be fooled by the other.