> On Fri, 9 Aug 2024 18:07:27 -0400 > ma...@mohawksoft.com wrote: > >> There was no failure, it was nothing more than constantly evolving >> technology adjusting to new realities. > > This. > > I've ranted about how ShareLaTeX, now Overleaf(?), abuses containers to > distribute garbage code. Here are some counter-examples that I use > daily.
[snip] Hate the player, not the game :-) The basic container system in Linux is LXC. All the other containers systems spring from it. I don't think docker uses it anymore, but it used to. Docker certainly uses the same kernel facilities that LXC uses. I HATE docker, its a mess. I hate Kubernetes because it is a big bloated management environment for Docker. I have been using "podman" which is a container environment that can use docker containers without the docker process and security vulnerabilities. LXC with name spaces, layered file systems, network isolation, cgroups, user ids, etc. Provide a very good strategy for layering container file systems. An overlay file system is the key to a read-only OS file system. There is a notion of "lower" "upper" and "merged." The "lower" file system is your read-only OS. The "upper" file system is everything you want added or changed to the read-only OS layer, and the "merged" is the overlay. When you open a file, say /usr/shar/fubar. The "upper" file system is searched, then the "upper" file system. The "merged" file system view's the "lower" file system through the "upper" file system. There was/is an option on Raspbian to use an overlay FS on the SD card (as "lower") and have the "upper" a ramdisk. That way you don't write to the SD card and thus extend its life. This is kind of what MacOS is doing. There's no reason why it wouldn't be fairly trivial to do with desktop or server Linux. I think there will be a consolodated "winner" in the app container space. _______________________________________________ Discuss mailing list Discuss@driftwood.blu.org https://driftwood.blu.org/mailman/listinfo/discuss
