Maybe containers can be the norm for all systems. Not just specialized server OSes. Need to install a video editing suite that has many packages? - use the container, etc.
I can't help but think what a failure of the Linux user land this is - we're essentially saying the only thing we can count on being there is the kernel?
Despite the plethora of Docker articles here on HN, I haven't paid much attention to containers. Reading this article, I get the impression that they occupy a niche somewhere between a chroot jail and a VM.
The question is, how to deploy an application in this kind of environment? Maybe I build a minimal container and find that a DBMS works fine until it does something like dlopen("/usr/lib/libxml2.so"). Oops, rebuild the container with another library and try again.
After fixing one of the broken links in the blog post, I found this article, which describes an Oracle container:
Yeah, it's called testing. But it's no different from, say, building a server and finding that the DBMS works fine until it doesn't. The only difference is that when you fix it, you can be sure(er) that you've actually fixed it, compared to a classic server, where there is a lot of state that can obscure the real problem.
I'm not sure how the systemd btrfs volume scheme actually solves this issue. The only ones who seem to have solved the problem are Nix through the use of isolated environment builds, associating packages via hashes and building anew for every discrepancy (new version, different configuration switch) while associating it in a store.
I see it as Red Hat's attempt to mitigate the long life cycles of its releases. Balancing the stability of a consistent OS without have to deal with an out of date (prehistoric) tool set.
Maybe something similar to how apple have "application packages" now?
each program is confined to it's own directory by default and has everything it needs to run.. if it depends on something in the OS, it's aware it's there because of the release version and distro..
this could be done easily in a manifest file (you can ask yum for instance what's installed).
maybe I'm overthinking it, maybe it's a horrible idea.
Apple are in the position of having full control over their platform and thus they're able to seamlessly work out separation of base system and applications with regards to the various quirks (API/ABI stability, symbol versioning, etc.) that are inherent in contemporary dynamic linking.
Some distributions have tried a similar approach. PC-BSD has the PBI format. Slax uses compressed file system images for packages. There's solutions like 0install (and tons of predecessors) that have tried to do it. None have really caught on.
