I don't think Nix solves this use case, the linked binaries would still have dependencies stored at /nix/store/... and is hardly a solution for obtaining binaries that work anywhere.
It's not about obtaining binaries that work anywhere, it's about being able to ask for a predictable environment to run in. You don't have to care about the target environment if you can control the derivation that is built to run your program.
I think we also need to separate "Nix" from "The General Approach that is implemented by Nix (and Guix etc.)". I think the "The Nix Approach" (as I'm now going to call it) is fantastic and really is the solution to a lot of problems that we have. I think that the actual implementation of Nix isn't great and painful to use in real life.
> You don't have to care about the target environment if you can control the derivation that is built to run your program.
This is not always possible, since people may have workflows based on different containers or OSes. I (and the author of the article) want to have tools that work across different environments.
> The General Approach that is implemented by Nix (and Guix etc.)
"Reproducible builds" or "hermetic environments" are commonly used adjectives for this, although they are not limited to these two tools either; Bazel from Google does it too, for example.
I think Snap/Flatpak could probably be extended to cover most of the nix use cases.
But some kind of repeatable environment is needed, traditional package management is just pure insanity where everything only works on one specific version.
I don't really see anything broken about them besides the lack of a FOSS snap backend, and the fact that the security isolation still breaks apps sometimes.
They don't have very good deduplication but that's a fixable issue.
What's the problem with storing dependencies in /nix/store? Nix removes the downside of having dependencies. Manually finding and installing them, conflicting dependencies, multiple versions of the same software/libraries, dependencies that are no longer needed but you don't know it, different installation method and instructions for different platforms, temporary installation - all are solved problems with Nix. Every package in nixpkgs, world's largest software collection, is a `nix-shell -p <package-name>` away.
Dependency may not be available on target system and cannot be installed because:
1) no external network access
2) not enough privileges to install
3) different architecture that doesn't have nix dependency available
4) target does not / cannot trust nix external dependencies
There is no such thing as a "nix dependency", Nix builds everything from scratch. You yourself control the whole software supply chain.
[It's still not a completely fixed problem - Nix needs to finish their content-addressable scheme, and for that you need reproducible builds; this is a detail, though.]
> the proper way to address this situation would be to compile static binaries
Nix is the proper way to address this. We'll get there eventually anyways, might as well bite the bullet now.