Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

And macOS! Catalina's read-only system volume has made the installation a bit more difficult. But once you have set it up, you get many of the same benefits (per-project virtual environments, home-manager, etc.).

We use NixOS on three machines around the house, but I use Nix + home-manager on my MacBook, and various Ubuntu servers at work. It's nice that I can largely use the same configuration across all machines. Just a home-manager switch and I am in my native environment.



i was planning to try out Nix on MacOS, because i always wanted to try out Nix and i use MacOS, but then Catalina happened,a and suddenly there were problems with Nix on Catalina.

last time i checked the install-instructions on Catalina, you had to create an unencrypted volume to store the nix-things, which i'd prefer not to do (i understand those files are probably non-personal, so no need to encrypt them, but i don't want to have to remember that half of my hard-drive is unencrypted)

is that still required or is there a simpler approach now?


The separate volume is still required. As far as I understand if you use an encrypted volume, it does not mount early enough in the login process and you have resort to more hacks to make it work.

Ideally the Nix store would be in some non-root location. But that requires a completely new binary cache among other things (since /nix store paths are hardcoded in binaries, scripts, etc).

Also making /nix a symlink doesn't really work in some cases, since realpath reports the actual path and that may break builds/applications.

It used to work so nicely out of the box :(, but I can also understand why Apple wants to enforce read-only system volumes, since it blocks nastier rootkits, etc.


I don't have any OSX boxes, but wouldn't bind-mounting the real the /some/where/nix to /nix solve the realpath problem? No need to write to / either (as you would have to do with the symlink approach).


If it is possible, then I think it should work. I believe this might be the way they are planning to go, because someone mentioned about a separate partition.

Honestly, I think they should just relocate it to a different location that can be persisted and rebuild the packages. I don't think people care about the location as long as they don't have to recompile every single thing. This could also be useful to catch all bugs where /nix was assumed.


Right, sorry, forgot to mention macOS even though I’m using Nix there myself for our commercial project’s dependencies




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: