Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).
NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.
I don’t get why more people aren’t using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I’m also scared that there is a downside to them I dont know about.
It is a whole ecosystem:
To start out it’s completely fine to just install Nix the package manager on a regular distro or on MacOS and use the nix-env command to install some packages. It will automatically use nixpkgs and use working dependencies for each package, whilst also checking if the depency is already installed to avoid installing the same one twice. This is pretty much the same thing as using Flatpak
Flakes explanation:
The Nix package manager has channels to manage package repos. It works like package managers on other distros where you simply have a list of urls to pull packages from, with Nix it would just be the nixpkgs release either a version number for stable or unstable for the unstable rolling release. Any time you install through the package manager or the config in NixOS, it will get the packages from the channel.
The problem is that the channels aren’t very reproducible. The repos get updates regularly, especially unstable which updates even faster than Arch. Channels don’t provide an easy way to specify a single commit of the repo, except for entering a url with the commit version in it. For stuff like a shell.nix, you’d need to either import nixpkgs from the system’s channel or import the url of nixpkgs with a specific commit ID.
Flakes is a feature that for some reason is still experimental after years, but many are already using it. It works like manifest.json and package.lock in a JavaScript project. You have a directory or git repo with a flake.nix file in which you specify your external dependencies like the nixpkgs release in the “inputs” section and your outputs in the “outputs” section, like a NixOS/Home Manager configuration, a shell or a package. Then when you use an output, Nix pulls the inputs and builds the output, it then generates a flake.lock file that contains all the inputs with their specific commit and hash. Now if you use an output again later with the same flake.lock, it will still use the exact same version as last time and should generate the exact same outputs. You just run nix flake update to generate a new flake.lock with new dependencies. You can’t use flakes with nix-env simply because installing packages imperatively without a config file defeats the point of reproducibility with flakes.
Flake example with Home Manager:
My Flake Repo/ ├── flake.nix - nixpkgs input and home manager configuration output ├── flake.lock - generated by nix └── home.nix - home manager config import from flake.nixHere the home.nix file contains the config with the list of packages to install as well as configuration options for those programs. The flake.nix contains the nixpkgs input and a homeManagerConfigurations output that import the home.nix. You can run
home manager switch --flake ./My Flake Repoto use that config from the flake. To update runnix flake update.I appreciate the breakdown, but you’ve basically made my point for me.
The above, with its many advantages, versus:
Sudo apt install X Y Z G F P -y
Simple, clean, gets it done for near anyone.
Debian 12 came out last June. In December the version of docker that’s shipped by Debian stopped being supported, and is now like 4 major releases behind nix. Debian won’t update it for at least a year and a half unless there’s some major security patch.
Besides that, when Debian 13 gets released and I reinstall, I can just clone my dotfiles and use a single line to reinstall all of the packages I need. All of the packages are in a single list, and so there’s no more need to run health checks because I forgot to reinstall some random editor dependency for a language I use once a year. If I added it to the list it’s going to be on every machine running that list.
Like most complex things in life, if you devout time to it and engage with it deeply you gain an advantage over a simplier version of the same thing. The question we all have to ask ourselves is “is this worth it?”
I’d say in your specific “docker centric while using debain” use case, sure. Most people who use linux as a daily driver? Maybe not.
What are you talking about?
Sure, it’s slightly more complex than clicking a button in Discover, but it’s not rocket science.
I’d say you’ve never seriously used a stable distro if you don’t realize how common issues like that are.
I’m pretty certain the current hype for stable distros is fueled primarily by the growth of tools like flatpak. So, since linux users require an additional PM, the real question is: Are you using linux only for browsing and the occasional text editing?
Not to mention that the most common problems it solves can be solved by installing packages from source in a prefix like /opt or ~/.apps and symlinking them from a central place like /opt/.system or ~/.apps/.system or whatever.
I had a bash script 15 years ago that automated most of this. (Which gradually fell out of use when Arch and makepkg came along, but I digress.)
I can’t help but feel like nix is a solution looking for a problem and solving it in a way that appeals to a certain kind of hobbyist but not so much to any practical purposes. Otherwise it would have been adopted more widely by now.