[ilovecaching]

The problem is that system libraries DO solve a problem that docker recreates - the kernel can efficiently map in a virtual address range for shared libraries and then add the map to all of the tasks that are using the same library, and the disk space is minimal because you only have maybe a few copies of the same lib. For some pieces like glibc, that's huge savings system wide.

With container images you're bundling your app with exactly the libraries it needs at the exact versions you want. This means that the kernel is loading all of this auxiliary pieces for you, distinct copies, that then have to reside in their own mappings, so you get no saving there (it's actually slower in terms of program startup), and then you also are wasting tons of disk space to have all of these duplicate dependencies lying around.

Really, the idea of duplicating an entire os tree for containers is just a bad idea, and it leads to lots of super vulnerable images and destroys the whole concept of sharing a system base for performance and storage wins.

[nikau]

Containers have never been about system efficiency, rather admin/developer efficiency - lower skilled staff can pump out a working product cheaper.

Need to run 2 separate apps that both need to use the same userid/filesystem path/network listener port? No problems.

Need to have different library versions? No worries.

Sure you can workaround all this stuff with ld preloads and other things, but that requires more skill than copying a base dockerfile from a google search and putting in a bunch of RUN commands.