9 ms·

> immutability is still seen as exotic, and I don’t think it should be. Two big problems: 1) Because Linux filesystems still suck. You need efficient copy-on

by bsder 2y ago

> immutability is still seen as exotic, and I don’t think it should be. Two big problems: 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. 2) Because the Linux linker sucks. Take a look at the reasons why Nix has to patch binaries and prepare to feel sick in your stomach. The "UNIX Architecture" is increasingly creaky for the things we want to do on modern machines (see: io_uring because the old select/poll stuff doesn't cut it, for example). We're going to have to sweep a bunch of that underbrush away.

ChocolateGod 2y ago
> 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.

by bsder 2y ago

ChocolateGod 2y ago

> 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.