3 ms·

I understood some of those words. But I've been using Atomic Fedora for the last 2 years and my whole work flow has shifted to using containers for everything

I understood some of those words. But I've been using Atomic Fedora for the last 2 years and my whole work flow has shifted to using containers for everything CLI, I can have specific container images for work on qemu images, or terraform for example. And everything else like Steam games, VLC, Firefox all run in Flatpaks. So the end goal is to not make any modifications to the host image.

chme 3y ago
> 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.
- INTPenis 3y ago
  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?
  - chme 3y ago
    > 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.
    - logicprog 3y ago
      > 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. That's why we have distrobox/toolbx!
    - INTPenis 3y ago
      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.

chme 3y ago

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

INTPenis 3y ago
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?
- chme 3y ago
  > 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.
  - logicprog 3y ago
    > 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. That's why we have distrobox/toolbx!
  - INTPenis 3y ago
    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.