3 ms·
I read it as a reference to Docker. The idea being that instead of actually static linking our dependencies, we use dynamic linking to bundle them together as a
by paulgb 3y ago
I read it as a reference to Docker. The idea being that instead of actually static linking our dependencies, we use dynamic linking to bundle them together as a big blob, use chroot/overlayfs to make it a filesystem, and then dynamically link them at runtime. It's kind of weird when you think about it.
- throwway120385 3y agoThat's exactly what I'm referring to. The original design for cgroups wasn't to do this type of configuration management but rather to provide process isolation and control access to system resources at the base level. That's one of the reasons you're able to set per-container CPU and memory limits. Docker is basically abusing this system for configuration management and providing some process isolation as a byproduct, because it turns out configuration management is a much more widespread problem than resource control.
- mike_hearn 3y agoIt does makes sense. glibc depends heavily on dynamic linking partly because it's pluggable. For instance DNS resolution supports plugins. Ditto for many other useful bits of software. If you think of a container as a frozen combination of apps and plugins, then the value becomes clearer: the software in the container can be recombined in many ways without recompilation or re(static)linking, the container itself is static.