Hacker News Reader

Comment by tadfisher | Hacker News Reader

> What is the reason for all this machinery?

> new Unix group

This is used for the daemon, so it doesn't run as root and expose your system to Nix build code.

> adds a separate APFS volume

I think this is required because of macOS security restrictions preventing direct modification of the root directory. The Nix store has to be housed in /nix because all references to runtime dependencies in the store are absolute paths in /nix, and that can't really change per system because it would break caching and reproducibility. The separate volume is added to /etc/synthetic.conf so it can live in /nix.

> installs a daemon

For multi-user installs, this allows non-privileged users to add build outputs to the Nix store, which ultimately allows these users to share build outputs. More info here: https://nixos.org/manual/nix/stable/installation/multi-user....

View on HN

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.

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-inten...

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.

> 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.

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.

Reply on news.ycombinator.com