3 ms·
It seems like they're conflating the need to run a specific software stack with the need to do configuration management in general. Configuration management doe
by throwway120385 3y ago
It seems like they're conflating the need to run a specific software stack with the need to do configuration management in general. Configuration management doesn't go away with WebAssembly as they're describing. You're just making fatter statically-linked processes that boil down to interpreters plus source code. People are already statically linking with EG GoLang or .NET Core anyway.
So I would guess that the future is static linkage with control groups moreso than it is a specific JavaScript/TypeScript software stack running in a specific runtime. Frankly the way we're shipping dependencies in what are basically checksummed tarball blobs is an echo back to static linkage at a time when most OS platforms have gone very deeply down the dynamic linkage rabbit hole to the degree where everyone is shipping dynamic libs instead of statically linking those libs into their executable.
Control Groups are supposed to provide process isolation but are being used to solve this configuration management issue as well because a particular company decided to use chroot in this way.
- photonbeam 3y ago“Namespaces” in linux provide a lot of the isolation that people associate with containers With a mount namespace you can pivot root
- no_wizard 3y agoWhat 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.