3 ms·
What company decided to use chroot this way? I'm going to guess its Microsoft, but I think thats not either entirely correct or I'm off base
by no_wizard 3y ago
What company decided to use chroot this way? I'm going to guess its Microsoft, but I think thats not either entirely correct or I'm off base
- ilc 3y agoGoogle is famous for statically linking everything.
- no_wizard 3y agoI don't think its only static linking that is the source of this practice right?
- paulgb 3y agoI 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.