> So the end goal is to not make any modifications to the host image.
IMO the goal should not be to have a immutable host image, but to have a immutable rootfs of each process. Immutable host base images might contain libraries or software that is not required by the application, they are more difficult to update, because they need to be updated as a unit, and probably require a reboot.
To make this stable, you need to hack around with A/B partitions for a fallback. IMO this would not be necessary if we had every package just installed under its checksum under `/pkgs` or what ever, an then use overlayfs to create a file system customized for every process. All that is required here to revert back is the old 'profile' and then start the old packages from the `/pkgs`. Like NixOS does it.
However NixOS doesn't use overlayfs, they use symlinks and patching of the paths in the sources to archive it.
Using overlayfs would also allow changing the package path (`/pkgs` here, or nixos package store `/nix/store`) at runtime, because the software would not require patches, so people could install an additional store in their home directory for instance.
Sounds like you're leaning more towards the Qubes OS model, even though I'm sure you don't want to go that extreme.
Either way I'm very happy with Atomic Linux, it's a huge improvement. I'm sure there will be more improvements that will offer separate rootfs for each process. Isn't that already handled by running flatpaks in their own container root?
> Sounds like you're leaning more towards the Qubes OS model, even though I'm sure you don't want to go that extreme.
Qubes OS is full virtualization. I don't want to boot a separate kernel for every process I want to start. That is not very useful.
> Either way I'm very happy with Atomic Linux, it's a huge improvement. I'm sure there will be more improvements that will offer separate rootfs for each process. Isn't that already handled by running flatpaks in their own container root?
As the article here says, not all apps can be used as flatpak.
Currently flatpak is mostly for GUI desktop apps, most common cli tools are missing. For instance there is no gcc flatpak.
Also the layers under a flatpak are not separated by individual packages but by broader runtime environments, thus they contain more stuff than each individual application requires. I want a system that could even be deployed on a small embedded device, because it is so generic.
I have containers for everything CLI. Like I'll have one specialized for build tools, one for manipulating qemu images, one for Terraform/ansible and so forth.
I even build cargo packages in a container, install the binary, and then run it outside the container.
> As the article here says, not all apps can be used as flatpak. Currently flatpak is mostly for GUI desktop apps, most common cli tools are missing. For instance there is no gcc flatpak.
IMO the goal should not be to have a immutable host image, but to have a immutable rootfs of each process. Immutable host base images might contain libraries or software that is not required by the application, they are more difficult to update, because they need to be updated as a unit, and probably require a reboot.
To make this stable, you need to hack around with A/B partitions for a fallback. IMO this would not be necessary if we had every package just installed under its checksum under `/pkgs` or what ever, an then use overlayfs to create a file system customized for every process. All that is required here to revert back is the old 'profile' and then start the old packages from the `/pkgs`. Like NixOS does it.
However NixOS doesn't use overlayfs, they use symlinks and patching of the paths in the sources to archive it.
Using overlayfs would also allow changing the package path (`/pkgs` here, or nixos package store `/nix/store`) at runtime, because the software would not require patches, so people could install an additional store in their home directory for instance.