Hacker News Reader

Comment by solatic | Hacker News Reader

One critical issue with "power of Nix without the learning curve" kind of products is that you still have Nix behind the scenes, including the /nix/store, which is intentionally not cleaned up by Nix automatically. So when users try out something that hides Nix from them, their drives inevitably fill up, which is super user-friendly because they have no idea how to reduce the amount of storage used. It's different when users understand that they're installing Nix, and go through the learning curve, because that learning curve helps them to build the mental model of what /nix/store is and how to maintain it.

What's your strategy for dealing with the underlying complexities?

View on HN

Supporting rollback and history means disks can fill up. With Nix, this is usually due to a bunch of GC roots pointing to profiles and packages that then cannot be cleaned up. Our environments are not just symlinks, but have a declarative format (under the hood, flakes) so one can remove them, but also reproduce them as needed. So GC'ing them is less destructive than with using `nix-env`/`nix profile`. This allows us to be more aggressive in cleaning up old generations.

So the strategy is to ensure there is always a declarative+reproducible way to recover the things you clean up, then we can apply various heuristics to avoid disks from filling up; free space, age, least-recently-used, least-frequently-used - are all being considered.

As opposed to Docker, or Bazel?

Conversely I have never had this problem with Nix. It tells you plainly how to clean up garbage. It's easy to interrogate to find out what's hanging around, and why. The reason it's not on by default is that, like any garbage collector, it can be disruptive -- there is no "one size fits all" policy.

Ultimately if you have too many gc roots you have to make some decisions.

The problem (especially pre-flakes) with nix (and Docker too; haven't used Bazel) is that if you GC, you can't recreate your previous environment (which version of nixpkgs were you using when you built it/which day did you run apt-get update in your Dockerfile).

It appears that Flox uses flakes and versions the flake.lock file, so it should be possible to readily reproduce anything that hasn't completely disappeared from the internet.

True, but with Flakes, as long as you didn’t upddate your lock file, you should always be able to rollback to your previous environment.

On NixOS, you can then configure background GC to clean up the Nix store periodically: https://search.nixos.org/options?channel=23.11&from=0&size=5...

Can't you just pin pkgs to particular commit, so everything will have the version it did as of that commit?

Right, but traditional nix doesn't make that easy (which is why niv and flakes exist).

I suppose you're just saying it's easier than this with flakes, but this isn't a flake is it? (Honestly so confused about it all, looking at trying out nix again after toying with it briefly years ago.)

https://nix.dev/guides/recipes/sharing-dependencies#complete...

That is not with flakes, nor does it pin nixpkgs.

It tracks nixpkgs-23.11

Now at the bottom it links to an example of pinning without using flakes, but the page you linked directly does not pin nixpkgs.

Flakes pin by default, and defaults matter. Using flakes, anything that isn't explicitly listed with a hash to ensure it's unchanged must be explicitly listed as an input, and a lock file for the inputs is automatically generated.

Nix supports garbage collection.

Also there are literally thousands of insanely complex things happening behind the scenes every time you use your computer. Not sure why Nix is considered special when abstracting over it.

We have the same problem with bazel at work, after a few months your machine is running out of disk space

Luckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139

Just set nix garbage collect to run every thirty minutes.

The point being asked was how do you do the gc using flex, as the aim is to not have to go inti nix

Reply on news.ycombinator.com