4 ms·

The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix, This is true, but in some sense

The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix, This is true, but in some sense Nix on Apple Silicon was a missed opportunity. It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix. This would have solved the whole dance needed with volumes and synthetic.conf. I know that there are infrastructure issues (like Hydra using a single Nix store), but it would've made the macOS Nix story so much better. It's a shame that only Apple can make firmlinks, because that would've been another possible solution (/nix could be a firmlink to the actual store location). The same problem occurs on e.g. Fedora SilverBlue, because you can also not make arbitrary root directories. But at least on Linux, you don't want to throw away more than one decade of a x86_64 binary cache.

wmertens 4y ago
Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing. Although it is my hope that rfc 17 eventually makes it through: https://github.com/wmertens/rfcs/blob/master/rfcs/0017-intensional-store.md https://github.com/wmertens/rfcs/blob/master/rfcs/0017-inten...
- microtonal 4y ago
  Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing. Sure. But it's still nice that e.g. on Linux x86_64 you can use a nixpkgs commit from 2015 and get all stuff from the binary cache.
tadfisher 4y ago
> It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix. That breaks caching cross-compiled outputs and x86_64 outputs, which do still run on Apple Silicon.
- microtonal 4y ago
  Which most users don’t really care about. I think it’s optimizing for the wrong use cases. This is the main reason why I don’t use Nix on the Mac anymore, I just don’t want the pile of hacks that is necessary on my system. And I am a former nixpkgs contributor. Many people will just shrug and install Homebrew.

wmertens 4y ago

Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing. Although it is my hope that rfc 17 eventually makes it through: https://github.com/wmertens/rfcs/blob/master/rfcs/0017-intensional-store.md https://github.com/wmertens/rfcs/blob/master/rfcs/0017-inten...

microtonal 4y ago
Actually the cache isn't that important, most binaries get rebuilt quite often due to their dependencies changing. Sure. But it's still nice that e.g. on Linux x86_64 you can use a nixpkgs commit from 2015 and get all stuff from the binary cache.

tadfisher 4y ago

> It started as a blank slate (fresh binary cache) and it would've been a good opportunity to move the store to a writable path like /opt/nix. That breaks caching cross-compiled outputs and x86_64 outputs, which do still run on Apple Silicon.

microtonal 4y ago
Which most users don’t really care about. I think it’s optimizing for the wrong use cases. This is the main reason why I don’t use Nix on the Mac anymore, I just don’t want the pile of hacks that is necessary on my system. And I am a former nixpkgs contributor. Many people will just shrug and install Homebrew.