Deduplicate Podman containers by sharing resources with the system?

On Atomic Desktops it seems the perfect way to install packages is to have a separate system running with the same libraries and system packages, just to add the packages there.

I think this is pretty absurd.

This model at least follows a normal dependency model, so you will not install the entire KDE runtime for running kcalc (like with Flatpak), but still.

When using Fedora, it makes sense to also use Fedora in the container. This means the same files will be loaded into RAM twice.


All these compromises may be okay for some. It will still use less RAM than Windows 11, lol. But is this really the point where we want to stop?

I think it is not cool to have all these drawbacks that come with the containerized systems.

  • flatpaks increase network traffic a lot, even though libraries may be deduplicated on disk
  • containers run one or several operating systems in parallel

So… how could this be solved?

Is there a way to link the OS root to the podman container, and have DNF recognize all the existing packages, only taking care of the actually missing ones?

Especially when running KDE apps in a container, on Kinoite, this could reduce duplication a lot.

And how could these dependencies be shared in RAM, to avoid duplication here?

Removed flatpak, kde, kinoite

Maybe discussing how CRI-O, Buildah, Toolbox can work, help in this would be a good proposition? :thinking:

I think much of what you are asking for can be addressed withcomposefs:

As the support for composefs matures in the containers stack, we’ll see containers sharing files based on what is on the disk of the host and in memory, too.

@alexl and @gscrivano having been doing most of the work in this space, so they can speak more concretely about what is and is not possible.

2 Likes

This is a long term goal, follow at: Add shared library/tool for managing backing store files · Issue #125 · containers/composefs · GitHub

However, this is not going to happen overnight.

1 Like

But what affect will this have on let’s say programming embedded systems with my Fedora PC? Currently I can deploy a container for development using 32 bit libraries that don’t exist on my 64 bit system, nor do I want them there. What if I’m working with even more limited hardware, say 16Bit processors or even 8Bit? I like the thought of thinning down my containers, I’m just concerned about practical trade off’s