I firmly believe that Nix (and/or Guix) are the future. I am going to use Nix as the keyword below, but Guix and Nix are so very similar that everything is also true for Guix.

Snap, Flatpak, Docker, AppImage, etc are all very complex solutions that are actually quite painful to interact with. Nix on the other hand solves the problem extremely well. You can have different complex applications running side by side with very different dependencies trees and they will not cross paths.

Every time I see a package being distributed as a Snap, I wonder why. These containered solutions are very complex, trying very hard to emulate FHS with mount namespaces, binding mounting tons of sockets around, and almost always end up mounting all of /home in the container. The don't provide much security, and quite difficult to deal with, and require a daemon.

Nix on the other hand has zero containerization requirements. It simply works by ensuring the programs are looking in the right place for the libraries they need. It would be great if more vendors just shipped a Nix derivation (or store path) that was their application stack. It would end version incompatibilities for ever, in a way that isn't a burden for the user.

Nix + bubblewrap add all the benefits of snap and flatpak as well. But again, there is no benefit to bubblewrap is if you are just going to blanket allow read-write everywhere anyway. At least with raw bubblewrap you can make these policies actually protect something.

Similarly, Nix is easily installed on any existing system. So you can use nix packages on Debian, Ubuntu, Centos, Fedora, DSL, or any other linux distribution because it runs entirely out of /nix. I use nix packages on Archlinux at home, and Debian systems as work.

Cross distro development works 100% of the time because Nix doesn't use anything from the distro.

Nix (and Guix) are really what the Linux community should be moving towards IMHO. I personally prefer Nix's syntax, but the underlying technologies are so similar I consider them the same. Guix started as a fork of Nix, and one day I hope they decide to end up becoming compatible with each other again.

Nix and Guix have too steep of a learning curve. Maybe someday I'll be willing to invest the time to understand what's going on, but the CLI and docs just aren't good enough to go from "I know nothing" to "ah, I can install the latest ". It really isn't clear to me how to switch a running system's package manager to either or even if either is fit to be the system's main package manager.

I watched a video of a seasoned linux user trying to install nix and abandoning the procedure because of the lack of docs. I even downloaded a virtualbox image of NixOS and tried to update everything to the latest version: 30 minutes later only firefox was installed but it wasn't in PATH thus couldn't be executed. Never found out how to install the KDE desktop.

Guix was another beast that I tried installing as a non-root user (insisted on using `curl | bash`, which I loathe). It was never up to date and I couldn't find the package I wanted to install (so fancy new chromium wrapper.. next-browser or something).

Maybe now things are better, but back then (1-2 years ago), neither were anywhere close to modern GUI distros. Until they make it easy to use, it's going to stay niche.

To learn more about Nix, I'd recommend grepping the nixpkgs [3] repository once you grasp the basics of the Nix language (Nix Pills [4] would be a good start for that). Since everything in the Nix official repository belongs in nixpkgs, it's easy to search for the information I want. I just wish CentOS and Debian had a way of searching across the entire codebase this easily when I couldn't figure out something from the docs.

[1]: https://nixos.org/manual/nixos/stable/#sec-x11 [2]: https://nixos.org/manual/nix/stable/#idm140737322634320 [3]: https://github.com/NixOS/nixpkgs [4]: https://nixos.org/guides/nix-pills/