@justsoup

This is exactly why I prefer them to #Nix or #Guix i.e. stick to Linux-native solutions like OCI containers

@alxlg #nix is fundamentally a build system with the largest package repository and a fully declarative linux distro attached in its standard library

You can absolutely build oci containers with it and they end up way smaller than those built with #dockerfiles as they only include the necessary programs instead of an entire package manager from whatever distro t hey were based on

@docRekd

Thank you, I already know it, I even mentioned it in my thesis to explain that Dockerfiles are the weak point of the OCI ecosystem, but this is not really related to Nix and Guix approach to deployment. Bootable containers are about deployment, while the way to build the images is another matter and building source code another one.

@alxlg to build a package you need to deply its build tools and dependencies tho
Also the nix store allows more deduplication than oci containers

@docRekd

Again, I am talking about deployment, not building. I like the OCI containers also because they let you choose whatever you want to build the images and, of course, to build the source code, including Nix and Guix.

With OSTree we already have file-grained deduplication in Flatpak and Fedora Atomic hosts. With ComposeFS, the evolution of OSTree, we will have it for OCI images stored by Podman. With Bootc + ComposeFS the host and OCI images files will be shared too.

@docRekd

To be clear, getting the dependencies to build source code is not the deployment phase but the building phase. After the building phase there is the deployment phase and after that the software is consumed. I am talking about how to deploy software to be consumed.