Hacker News new | ask | show | jobs
by abathur 1856 days ago
I'm not sure exactly where your focus is, so I'll just give you a mix of thoughts and see if I accidentally help :)

- Building takes space, but the build takes place in a temporary directory that is discarded afterwards, and only the output artifacts are kept.

- ~Normal software is usually served pre-built from a cache, which short-circuits the above as long as the package is available from the cache.

- One of the nicer things about the process Nix uses here is that it's also tracking what's ~in-use (via "GC roots"), and you can trivially garbage-collect everything in /nix/store that isn't.

- On macOS I use Nix for just about everything that isn't a desktop app. My /nix mount had 9.7G used when you asked this question, and 3.6G after I garbage-collected, and 7.1G after I re-built the dev environment for a server project.

- The ~3.4G I mentioned above is a really big fraction of my total, but as a reference point, Nix is natively replacing, in ~3.4G, the Vagrant/virtualbox VM I used to need for this development.

- In my experience, the only time I'd describe the storage load as "a lot" is when I've been iterating on something that is fairly large. This can add up as the store accumulates slightly-different copies, but these can be readily GCed.

- Multiple versions of something (say, multiple different pythons or rubies or llvms) will consume more space, but the ~Nix way also makes it possible to avoid vendoring. At system scale I would _guess_ these are a wash?

- At least when you're using Nixpkgs, "multiple versions" generally just means a few major/minor version variants of common dependencies (i.e., at a single commit, most things in Nixpkgs that use Python 3.7 reference the same build).

1 comments

That’s a really comprehensive answer, thank you! I don’t have a particular focus, just wondering what the trade offs are.