4 ms·
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
by solatic 3y ago
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?
- anon291 3y agoJust set nix garbage collect to run every thirty minutes.
- pasc1878 3y agoThe point being asked was how do you do the gc using flex, as the aim is to not have to go inti nix
- emptysea 3y agoWe have the same problem with bazel at work, after a few months your machine is running out of disk space
- dieortin 3y agoLuckily a feature to limit the disk cache size is in development: https://github.com/bazelbuild/bazel/issues/5139 https://github.com/bazelbuild/bazel/issues/5139
- tomberek 3y agoSupporting 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.
- colordrops 3y agoNix 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.
- xyzzy_plugh 3y agoAs 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.
- aidenn0 3y agoThe 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.
- Cyph0n 3y agoTrue, 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=50&sort=relevance&type=packages&query=nix.gc https://search.nixos.org/options?channel=23.11&from=0&size=5...
- OJFord 3y agoCan't you just pin pkgs to particular commit, so everything will have the version it did as of that commit?