The What, Why and How of Containers

Containers vs dynamic/static linking & packaging

• Several comments see containers as a “big hammer” for dependency management and dynamic linking: instead of sharing system libraries, each image ships its own stack.
• Others argue containers are more than static linking-in-tarballs: layered images allow deduplication of libraries across containers (on disk and often in RAM), especially when base OS and library layers are shared.
• Nix is contrasted as a different approach: binaries are built with absolute paths into a content‑addressed store; dynamic “discovery” is mostly resolved at build time.
• Some suggest filesystems with deduplication or content-addressed storage can mitigate the space argument for shared libraries, but comments note that dynamic linking still simplifies reuse and patching compared to deduping arbitrary static binaries.

Distribution, updates, and distros

• Containers are widely viewed as a distribution mechanism: ship one image and avoid per‑distro packaging pain, especially for complex stacks (Ruby, Node, etc.).
• Tension noted between distro maintainers and upstreams who only want to ship Flatpaks/AppImages/containers and control versions, “App Store” style.
• Dynamic linking allows “one upgrade patches many apps,” while static binaries and per‑app images require rebuilding each artifact. Commenters note real-world container workflows often recreate this problem, with extra vulnerability scanners and weak tooling to propagate base image fixes.

Isolation, resources, and security

• Containers are built from kernel primitives: namespaces, cgroups, chroot/pivot_root, plus capabilities, seccomp, LSMs (AppArmor/SELinux), masked paths, and often NoNewPrivs.
• Some stress that you can use cgroups/namespaces directly without Docker; Docker mainly standardizes the interface and ecosystem.
• There’s disagreement whether containers should be seen as a security mechanism vs primarily a deployment vehicle. Security benefits exist but escapes and misconfiguration (e.g., liberal firewall changes) are concerns.

Orchestration, VMs, and alternatives

• Kubernetes is defended as a way to express policies (affinity, resource quotas, node selection) over many nodes; critics would prefer “Kubernetes but with VMs” for stronger isolation.
• It’s noted Kubernetes can run VM-based runtimes, and many production systems use containerd, CRI-O, Podman, systemd-nspawn, or LXC instead of Docker.
• Historical/alternative models mentioned: Solaris Zones, HP-UX vaults, AIX LPARs, microkernels, unikernels, Qubes OS, and capability-based security.

Tooling, UX, and learning

• Low-level APIs for cgroups/namespaces are described as ugly and piecemeal; container engines hide this but add their own complexity.
• Debugging inside containerized stacks is often seen as harder.
• Multiple “containers from scratch” tutorials and talks are recommended for those wanting to understand the primitives directly.