Linux Container Internals
I have some small critiques of some of the hyperbole in the article:<p><i>&quot;Package managers failed us due to shared libraries version differences causing dependency issues&quot;</i><p>Incorrect. The software administrators (read: The Users) failed to understand that installing duplicate incompatible software does not work, was never intended to happen, and shouldn&#x27;t even be possible. But users are stubborn and will force a conflict if at all possible.<p>Containers allow users to <i>side-step package management</i>. It doesn&#x27;t replace it or help it at all, because it completely ignores all the work gone into the package. Imagine putting on tennis shoes, and then trying to put on snow boots. Containers give users a second pair of feet.<p>And this is not a container innovation. Chroot environments have been providing the exact same functionality (installing side-by-side conflicting packaged software in a simple manner) for decades. You don&#x27;t even need any extra software to use it.<p><i>&quot;Docker provides a self-contained image that is exactly that same image running on your laptop vs in the cloud while i.e. Puppet&#x2F;Chef are procedural scripts that need to rerun to converge your cluster machines. This enables approaches also know as Immutable Infrastructure or Phoenix Deploys.&quot;</i><p>Unless you designed your software to be immutable, it probably isn&#x27;t. Software changes as it runs, and different hardware changes software differently, so at the best this claim is disingenuous. Different networks and systems interacting in different locations add complications. If you tested it on your laptop, <i>do not expect it to run the same in production, period.</i><p><i>&quot;Before Docker, LXC would create a full copy of FileSystem when creating a container. This would be slow and take up a lot of space.&quot;</i><p>Loop and COW filesystems (Unionfs, Aufs, Overlayfs, etc) on Linux pre-date Docker by a long time, and were used with containers and container alternatives.<p>--<p>I thought i&#x27;d see more about <i>linux container internals</i>, not a description of how Docker works, but I guess the host name should have been a dead giveaway. Don&#x27;t read this if you want to know about the kernel.