3 ms·

> 1) Because Linux filesystems still suck. You need efficient copy-on-write overlays (and the ability to handle lots of them!) with some level of deduplication

> 1) Because Linux filesystems still suck. You need efficient copy-on-write overlays (and the ability to handle lots of them!) with some level of deduplication to make immutable operating systems not suck. OStree copied Git and used hardlinks with a content addressable object store for years and it didn't "suck". This method is reliable enough that it ended up in a shipped Red Hat product. It recently gained support for something known as composefs, which is kinda like mounting a manifest of hard links, but the system just needs the one, not "lots of them".

bsder 2y ago
That's okay for the base OS that doesn't change all that often. However, that falls apart when you start trying to have lots of "toolbox"/"containers"/"docker" things that people want to use for development. The DNFs you need inside the container pile up very quickly when trying to do development. Those want to be deduplicated between containers. There is a reason why Nix gets grief about how large its store becomes. In addition, lots of people also want to containerize their working/home directory. That requires really good overlay support, and nobody has this right now. There are LOTS of issues filed against "toolbox" for this, for example: https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/1470 https://github.com/containers/toolbox/issues/1470 This is something that should be straightforward to implement. However, because the filesystem support sucks, it is not.
- ChocolateGod 2y ago
  There was work on making docker/podman use an object store which would deduplicate things and improve performance (far more likely a file the same between images is in memory already) but I haven't checked to see what the status was of late. Flatpak already does this, if two Flatpak apps ship the same file, it's deduped by default I do agree the layering part of OCI images is horrible and a waste of disk space, but I don't think this is the fault of immutable distros.

bsder 2y ago

That's okay for the base OS that doesn't change all that often. However, that falls apart when you start trying to have lots of "toolbox"/"containers"/"docker" things that people want to use for development. The DNFs you need inside the container pile up very quickly when trying to do development. Those want to be deduplicated between containers. There is a reason why Nix gets grief about how large its store becomes. In addition, lots of people also want to containerize their working/home directory. That requires really good overlay support, and nobody has this right now. There are LOTS of issues filed against "toolbox" for this, for example: https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/183 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/348 https://github.com/containers/toolbox/issues/1470 https://github.com/containers/toolbox/issues/1470 This is something that should be straightforward to implement. However, because the filesystem support sucks, it is not.

ChocolateGod 2y ago
There was work on making docker/podman use an object store which would deduplicate things and improve performance (far more likely a file the same between images is in memory already) but I haven't checked to see what the status was of late. Flatpak already does this, if two Flatpak apps ship the same file, it's deduped by default I do agree the layering part of OCI images is horrible and a waste of disk space, but I don't think this is the fault of immutable distros.