We can just make this upgrade in the next release of GCC, or some massive event like that.
2 Likes
And I just realized, that if the store lives in /var/lib/nix, and the metadata is local per user, and then with PackageKit support we’d have a very compelling alternative to flatpak. Distros would only have to add the backend and the entire NixPkgs catalog would be installable from a GUI.
Ideally we’d also have a sandboxing wrapper though, like flatpak has.
3 Likes
ARM is now a certainty:
1 Like
I was referring to Apple playing nice with always letting you write to / via synthetic.conf and them adding firm links.
Their move to ARM I was already expecting last year, they’re late 
1 Like
Ack. The synthetic.conf man page on macOS 11 (Big Sur) does not describe any new options (besides making top-level directories or symlinks). But it seems that they did add /etc/synthetic.d, so that you don’t have to fiddle with /etc/synthetic.conf, but you can put your application-specific configuration in that directory. (Haven’t tried that yet though.)
1 Like
Hello everyone,
I believe, I’m part of the user group you are trying to address here. I’m a long-time macos user managing most of my software with brew. It, for sure, has its pros and cons - its index being stored and managed with git is probably one of them.
Even though I recommend nix as part of my lecture, for me, the location of /nix has been a deal-breaker so far. Yes, I’m aware of the available workarounds, but I think reasonable arguments have been brought up here and across the internet.
I’m all the more exited to see this topic getting some serious traction. I would really love to see the proposal become reality. So, my questions is, what can we do to move forward with this?
2 Likes
We need a build of nix that uses the new path and test that the basic things work and didn’t hard-code /nix/store.
I just read through the workarounds again. Section 4.3.2, “Use a separate encrypted volume” mentions that you “can hard-code the password in the clear, so that your store volume can be decrypted before Keychain is available.”
If you were to store this passphrase on the FileVault encrypted boot volume, and use it to decrypt the Nix store volume. Would that work? How do I “hard-code the password in the clear”?
This is in reply to what? I’m a bit confused
(side note: this is relevant, even if it’s a terrible idea Idea for very minimally changing Nix & cache.nixos.org to allow custom store paths without rebuilding the world)
Yes, that would work. Pick a location on the read-write volume, such as /var/root/mount_nix_password. Security of the file doesn’t really matter since the Nix volume will be mounted always, but feel free to lock it down as much as you want, just make it executable. At this location, write a shell script that runs the appropriate diskutil ap unlock command to mount the volume, hardcoding the passphrase. This would look something like /usr/sbin/diskutil ap unlock DEVICE -passphrase PASSPHRASE -mountpoint /nix, except replace DEVICE with the Nix volume’s device identifier (e.g. mine is disk2s5) and replace PASSPHRASE with the passphrase you used to encrypt the volume. Note: please test this command, I haven’t actually executed it on my machine.
Once you have this script and it works, run sudo defaults write com.apple.loginwindow LoginHook /var/root/mount_nix_password. This will set up that script as the login hook. Note that if you already have a login hook this will replace it, though I doubt you do.
CAVEAT: The login hook documentation says it’s run for every user. Please verify that the script does not error out if the volume is already mounted. I don’t actually know what diskutil ap unlock does if the volume is mounted. If this command cannot be run with a mounted volume, then set up whatever appropriate probe you want first.
CAVEAT 2: Since this is a login hook, it runs when a user logs in. This means the volume will not be available prior to login. I’m documenting this approach because it was claimed to work in the past.
An alternative approach that I don’t have proof that works is to do basically the same thing, except instead of setting up a login hook, set up a /Library/LaunchDaemons launchd plist to run the script at boot. This should actually be better than the login hook approach, but I don’t have proof it works. This approach also does not require ensuring that the script works with the volume already mounted, because it will only be run once per boot.
Substitutions from different store dirs by matthewbauer · Pull Request #3689 · NixOS/nix · GitHub this makes it so we can fetch fixed output stuff across store dirs. I don’t see any reason why we can’t just have cache.nixos.org have binaries for multiple store dirs, and iterate on this stuff a bit.
Well since does not work for non-fixed input derivations though, I am not quite sure how this would help with store path migration?
We discussed in the thread how it ought to be possible to generalize that PR’s technique, and combine with Nixpkgs tricks, to cover more cases, see Substitutions from different store dirs by matthewbauer · Pull Request #3689 · NixOS/nix · GitHub . There’s no auto-magical “all builds are automatically relocatable” moment, but with enough elbo grease we might be able to get to “everything we build in practice can be relocated cheaper than doing a rebuild from scratch”.
Related: I’d like to explore how we could do late binding in Nix while retaining the specificity of absolute links.
I’m thinking that builds could get custom trees of dependencies, and they’re built against those.
This would be much like building against /usr, but the “installed” derivation would not be part of this “/usr”.
Then, they get either a wrapper with LD_LIBRARY_PATH or an rpath to their depency tree.
Then, you have a derivation that you can easily change the dependencies of. With the wrapper, you would ideally only have self references, and you could make the wrapper a separate derivation.
You’d have to know when it’s ok to switch dependencies though.
Added bonus is that if the derivation is rewritten for intensional store, it can be verified to remain the same on “light” dependency updates (so no guessing), with just a new wrapper pointing to a different dependency tree and subsequent dependent rebuilds would likely also just need a dependency tree update.
Not sure if the above makes sense. So if a non-late binding build B1 gets updates and becomes build B2, a late binding build L1+W1 might become L1+W2.
The biggest problem are hard-coded strings in binary formats. There is no tooling for that yet.
Right - by doing late binding though, there’s less chance of the strings being hard-coded in the first place.
How do you plan to handle late binding for non-libraries? E.g. paths to other commands, configuration files, data files, etc. that are hardcoded in binaries?
There is definitely no one-size-fits-all possible.
Most software is written with the possibility of being installed at some prefix, so if a package cannot be convinced to look at the dependency tree + the own installed path, there’s most likely the option of creating a dependency tree including the package. This is a circular reference so it would mean copying the package and rewriting the references, not ideal but it should work?
Another thing to consider is when porting it to other OSes like Haiku.