Thank you for the detailed and informative answer. Sorry for my cocky style, I am by no means knowledgeable on flatpak and I passed judgement prematurely.
Nonetheless, I have some questions, comments:
> Nix doesn’t guarantee binary reproducibility
Yeah, it’s true, but no general build tool can, since language build tools themselves are usually non-deterministic.
> For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot
That latter is only true of NixOS; for an ordinary package you can just start up actually both the old and updated version at the same time without any trouble. And in the OS config case, it is more of a linux deficiency - it does restart services when possible, but that is orthogonal to this discussion as I believe flatpak doesn’t do anything similar.
> Evaluating Nix expressions is quite inefficient
You are right, but the results can be cached. With the experimental flakes it is quite fast.
> Worse is the cascading rebuilds that come with the Nix approach
Well, it is sort of a tradeoff of reproducibility. Also, there is work in progress to minimize rebuilds to only truly necessary changes.
> Also, Nix’s languages lacks domain abstractions for building packages
The language lacks them. The repo has a great deal of abstractions for many use cases, and so a trivial to build package will look almost the same as a JSON. And as you note, it is a tradeoff, but there are plenty of hard to package apps that benefit greatly from the more expressive language. Also, there is plenty of auto-updaters that can automatically create PRs for eg new python packages, since it is more often then not just a version and hash change away, so package description manipulation is possible this way as well.
> OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free
Correct me if I’m wrong, but it is necessary because flatpak uses the docker-like model, in that the same shared dependency is “theoretically” copied in each package, even if it is the same version. So in a way they solve a self-created problem. nix on the other hand simply links the same shared library, no duplicated data.
You can optionally deduplicate when you install multiple versions of eg. libc. Nix can’t really prove whether the two “versions” are the same, and sometimes they may be identical, or identical in part (eg the man pages are the same, but the exe is not), in which case imo really elegantly, it can hard-link one to the other.
But the base state with only one version of a nix channel installed, you simply have no need for deduplication as opposed to the flatpak model, because you only get every package once.
One last point, a nix package may have less overhead, although it is I believe negligible in most cases since vms are quite light nowadays.
So I agree with you on the tradeoffs part, and I again apologize for dismissing the project - I really dislike the same uninformed attitude towards for example systemd or wayland. But I still believe that nix is the one doing something revolutionary.
Nonetheless, I have some questions, comments:
> Nix doesn’t guarantee binary reproducibility
Yeah, it’s true, but no general build tool can, since language build tools themselves are usually non-deterministic.
> For example, Flatpak guarantees atomic updates with restarting merely the updated application. NixOS only guarantees atomic updates with a reboot
That latter is only true of NixOS; for an ordinary package you can just start up actually both the old and updated version at the same time without any trouble. And in the OS config case, it is more of a linux deficiency - it does restart services when possible, but that is orthogonal to this discussion as I believe flatpak doesn’t do anything similar.
> Evaluating Nix expressions is quite inefficient
You are right, but the results can be cached. With the experimental flakes it is quite fast.
> Worse is the cascading rebuilds that come with the Nix approach
Well, it is sort of a tradeoff of reproducibility. Also, there is work in progress to minimize rebuilds to only truly necessary changes.
> Also, Nix’s languages lacks domain abstractions for building packages
The language lacks them. The repo has a great deal of abstractions for many use cases, and so a trivial to build package will look almost the same as a JSON. And as you note, it is a tradeoff, but there are plenty of hard to package apps that benefit greatly from the more expressive language. Also, there is plenty of auto-updaters that can automatically create PRs for eg new python packages, since it is more often then not just a version and hash change away, so package description manipulation is possible this way as well.
> OSTree uses a content-addressable store for all files, giving Flatpak deduplication for free
Correct me if I’m wrong, but it is necessary because flatpak uses the docker-like model, in that the same shared dependency is “theoretically” copied in each package, even if it is the same version. So in a way they solve a self-created problem. nix on the other hand simply links the same shared library, no duplicated data. You can optionally deduplicate when you install multiple versions of eg. libc. Nix can’t really prove whether the two “versions” are the same, and sometimes they may be identical, or identical in part (eg the man pages are the same, but the exe is not), in which case imo really elegantly, it can hard-link one to the other. But the base state with only one version of a nix channel installed, you simply have no need for deduplication as opposed to the flatpak model, because you only get every package once.
One last point, a nix package may have less overhead, although it is I believe negligible in most cases since vms are quite light nowadays.
So I agree with you on the tradeoffs part, and I again apologize for dismissing the project - I really dislike the same uninformed attitude towards for example systemd or wayland. But I still believe that nix is the one doing something revolutionary.
(Also, maybe not-possible but nix could perhaps be used as a tool to create flatpak images similarly to how it can create smaller docker images: https://yann.hodique.info/blog/using-nix-to-build-docker-ima... )