Hacker News Reader

Comment by Cu3PO42 | Hacker News Reader

Which breakages does this fix exactly? The fact that macOS upgrades may overwrite /etc/zshrc, etc? Other than that I haven't encountered any breakages whatsoever.

View on HN

Your hunch is exactly right. macOS upgrades typically do precisely that and it's quite annoying. I work at Determinate Systems as a full-time macOS user and it's one of those things I kind of quietly tolerated and didn't give much thought, but having this fixed removes a real headache.

Right! It's great to see that tackled for potentially all Nix installations! I have a workaround for that particular issue in my nix-darwin and Home-Manager configurations, but I've always disliked that I needed one in the first place.

While we're speaking of things I need workarounds for: having my login shell be Nix-installed currently has a race condition on systems with FileVault. I have, for example, iTerm2 configured to resume on reboot and it will start before the Nix partition is mounted, thus complaining that it cannot exec my shell. My workaround entails placing a thin wrapper on the main partition that simply waits for /nix to be mounted and then `exec`ing the right shell binary depending on the invoking user.

I should probably open an issue about this, but I'm not sure it can be solved at all while `/nix` needs to be on a seperate volume.

Hmmm... would you mind opening an issue over here[1]? We have seen some related issues that might dovetail nicely.

1. https://github.com/determinateSystems/nix-installer

I will do tomorrow! In the meantime, on the offchance anyone stumbles across this who has the same problem, my workaround is available here [0]. (Also exported as `darwinModules.chsh` from my Flake)

[0] https://github.com/Cu3PO42/gleaming-glacier/blob/master/modu...

Ah fabulous, thanks! I'll make a note internally. It'd still be great if you could open an issue.

I absolutely will! It’ s just … 8.40PM in this part of the world and I want to take the time to write a proper bug report and dig up my prior research on the issue.

Can someone ELI5 why someone would want to do this system-wide installation? Are there that many developers who log in to do their development as multiple different users? Also, is this mandatory for Nix to work?

Personally I prefer to even store regular Mac apps I download in ~/Applications, and anything I can install without disturbing system-global stuff, I prefer to do that way. It means I can migrate things completely by copying one directory, rather than using an "Installer" in the Windows tradition.

Nix packages refer to each other using absolute paths. The convention is to put them in /nix/store, but technically this base path (the "nix store") be changed to whatever you want. However, changing it requires all (non-leaf) packages to be rebuilt to refer to the new path. That also means that you won't be able to use the central package cache anymore, and you effectively get The Gentoo Experience.

The default path could be changed too, of course, but putting it under your home directory would mean that you could only share cached packages with other people that share your username. It would also break NixOS, since that uses Nix to manage the entire system.

> It means I can migrate things completely by copying one directory, rather than using an "Installer" in the Windows tradition.

Nix ships with a specific tool for copying packages (including dependency trees) between computers, nix-copy-closure. But this also assumes that the store path is the same.

> However, changing it requires all (non-leaf) packages to be rebuilt to refer to the new path.

Do you know whether Nix has a proposal to fix that big ease-of-relocation issue via path rewriting? Afaik Spack package manager builds with padded paths so those can then be rewritten to practically any install path

I haven't kept up actively with core proposals, so I don't know. But I'd doubt it since there's no way to do this generically.. even if you rewrite all paths referring to /foo to instead refer to /bar, that wouldn't cover hashed strings, and would be difficult to do in a way that would make binary formats happy (even if you pad it, `/foo\0\0\0` and `/foo` aren't universally equivalent).

Yeah seems like a nightmare since so much of the auto-magic that nix does to fix binaries (shebang rewriting and ELF .so patching) does so by injecting absolute paths (to /nix/store). So all of those would need to be reshimmed for your entire system

EDIT: theres also work being done to move to content-addressed nix store, in which case changing these things would invalidate the content hash

In Spack we rewrite strings in binaries, strings in text files (including shebangs), and RPATH/RUNPATH values. It's not hard to find store prefixes in binaries -- they have hashes in them so they're easy to identify. It's hard to lengthen them -- things in text files and in ELF fields can be made longer, but to make strings longer you need to find all references to them, which is impractical. So we build with long paths.

Relocating is really only a matter of relocating prefixes.

I am not sure how it would affect a content-addressed nix store, but I'm also not 100% sure why you want a content-addressed nix store. Addressing by the derivation hash (which is also what Spack does) lets you find valid build substitutes... would you index that separately for a content-addressed store?

Is the goal to allow multiple versions of non-reproducible builds in the same store?

I'm not 100% sure, but I know one benefit of content-addressed derivations is that they are secure by default. i.e. if the hash matches the build is trusted vs the traditional need to have separate "trusted signatures" and signing workflow to whitelist particular builders.

How do you reliably modify length-prefixed strings? Terminated strings? Delimited strings? Partial strings? Checksummed strings?

I also prefer to put my Mac apps in ~/Applications (I thought I was the only one!). I was resistant with Nix defaults for this reason when I set up my newest Mac, but I still wanted all of the other benefits of Nix. Ultimately what persuaded me was that it was basically so trivial to remove Nix and anything it installs… that I actually did remove everything, multiple times, whenever I ran into bumps getting my Nix setup going in the right direction. I got to take the Nix happy path to avoid self-inflicted pain, with the reassurance that it’s far less intrusive than anything else I’ve accepted that installs system-wide.

Reply on news.ycombinator.com