"Cut the fuss with Determinate Nix?" is misleading

[andrewhamon]

trafficstars

My nix builds were stuck, the last log I saw mentioned post-build.

I checked my nix.conf, and I noticed post-build-hook = /nix/var/determinate/post-build-hook.sh

After removing this, my builds work again. But now I am wondering, what even is this? Why has the determinate installer added a post-build-hook?

Looking a bit further, I am somewhat horrified to find that an additional daemon called "Nixd", and extra trusted keys and substituters for flakehub installed. Wtf?!

So I re-ran the installer. The very first question is:

Cut the fuss with Determinate Nix?

Proceed? ([Y]es/[n]o/[e]xplain):

So this must be where I "chose" to take on all these extras that I don't want. This strikes me as rather misleading, and a bit gross. Same vibe as sketchy windows installers which "helpfully" opt you in to installing browser toolbars. I've been using the determinate installer for some time, and thought it was a great benefit to the community, but now I feel like my trust has been rather violated.

[grahamc]

Hey @andrewhamon, thanks for the report. I'm sorry that felt misleading to you, I'm not trying to trick anyone into anything. Is the issue here the brevity of the text, or something else?

--

Regarding the post-build-hook, it is part of the event API: https://docs.determinate.systems/guides/post-build-events

Can you share details about your system (os/distro/version) so we can diagnose why it is blocking?

[andrewhamon]

I find this problematic for a few reasons:

• I've been using the detsys installer for a while now. In the past, when I accepted the defaults, I didn't get these surprising extras. Now, i get them by default.
  • These extras don't seem to benefit me in any way, as far as I can tell. I/my employer are not currently flakehub customers.
• Yes, the brevity of the text. It isn't obvious that "Determinate Nix" is something entirely distinct and extra on top of the installer. It feels like saying "No" will exit the installer (it doesn't).
• It is opt-out instead of opt-in

[andrewhamon]

Can you share details about your system (os/distro/version) so we can diagnose why it is blocking?

This is on macOS 15.3.1, following a macOS update and reboot.

I've already re-installed nix, so I can't reproduce anymore, but worth noting that this was not a normal install. At my company, we run nix in single-user mode, even on mac, where this is expressly not supported by Nix. But, it solves a number of problems for us, mainly remote cache authentication in a way that isn't totally awful. So it may have been a permission issue, though I would expect that to fail fast rather than block indefinitely.

Also worth noting, this only impacts me, everyone else at my company is still pinned to an older version of the det-sys installer. But since I maintain Nix here, i try to run more bleeding edge than everyone else to catch problems early.

[grahamc]

Gotcha, thank you for sharing. I'll take your feedback to the team in the morning. The fastest thing we can do is iterate on the text and make it more explicit.

In case it is useful for me to share my thoughts on this:

• Determinate Nix isn't just for customers or FlakeHub users, and FlakeHub Cache should not actually be in your list of active substituters until you log in with determinate-nixd login.
• a lot of folks struggle around certificates, cache authentication, and general system maintenance like garbage collection around Nix. This is especially the case on macOS, and a big priority for us is making it less painful for macOS users.
• An important principle for us when adding this prompt is that people using DNI in automation wouldn't get anything different, only users who were given a chance to actually see the prompt, and then the follow-up confirmation about what is going to happen.

This last point leaves me a bit surprised that it feels "tricky," because we really did put thought into not making it tricky. I can see where you're coming from, re: the Y/n/e having it feel like a default to Determinate. To be honest, it shipped that way initially not by any specific design or intent but because that is just how our existing prompt function did it.

--

I am quite certain, then, that using Determinate Nix in a single-user capacity is in fact causing the problems. Our installer doesn't formally support single user installs, so we never imagined adding that to our test matrix. How did you go about actually implementing that?

[andrewhamon]

How did you go about actually implementing that?

Just a simple chown of /nix immediately following install. This results in builds, store operations, nix db modifications, etc. happening directly rather than mediated via the daemon.

I am quite certain, then, that using Determinate Nix in a single-user capacity is in fact causing the problems

I am not so certain, since I've been running with this post-install hook for about a week now. But I might not have ever rebooted until now, delaying any noticeable issues with Nixd.

[grahamc]

Just a simple chown of /nix immediately following install. This results in builds, store operations, nix db modifications, etc. happening directly rather than mediated via the daemon.

Nice :).

I am not so certain, since I've been running with this post-install hook for about a week now.

...hm. Ok, thanks :). I'll have to try and replicate, then. I think it is possible that determinate-nixd daemon was never started, and therefor never listening on that fifo, because it was never socket-activated through either the nix-daemon.socket or /nix/var/determinate/determinate-nixd.socket. If the daemon isn't up, that fifo will block forever. Which obviously sucks.

Another tick in the "don't do it this way" box...

[andrewhamon]

Yeah, just to be clear I am not asking for single-user support. It works for us now, and once it stops working for us, well, thats what I get paid for :)

If the daemon isn't up, that fifo will block forever.

Gotcha, okay yea I think my best theory then is that my chown meant that the nixd daemon couldn't come up following reboot, resulting in the blocked fifo. But I think that chowing the fifo while nixd was already running was fine, which is why I didn't notice until I rebooted.

[andrewhamon]

Back on the larger issue at hand:

The fastest thing we can do is iterate on the text and make it more explicit.

I can see where you're coming from, re: the Y/n/e having it feel like a default to Determinate. To be honest, it shipped that way initially not by any specific design or intent but because that is just how our existing prompt function did it.

I think some copy change and changing the prompt default to (N) instead of (Y) combined would put me totally at ease.

I hear you that Nixd may have benefits for non-customers. I would suggest making some dedicated documentation that outlines what this extra daemon does, why its beneficial, and disambiguate it from the Installer in general. Its not very clear to me, and I am a nix power user.

FYI, i went looking and did find some other folks a little spooked by this as well: https://discourse.nixos.org/t/determinate-systems-installer-adds-flakehub-to-trusted-substituters-unconditionally/58930

[grahamc]

Thanks for that link. Note that FlakeHub Cache has no public caches and it isn't enabled by default, so users must be authenticated for it to work. Caches can only be shared to a user if they have been invited to an organization, and then also accepted that invitation.

I'm heading out for the night, but will check into the rest. Thank you again!

[grahamc]

Hey, just updating to share we updated the message to more explicitly communicate that there is a choice, and that no will install Nix from NixOS.

[Enzime]

Can you also update the README, it implies that by default that vanilla Nix rather than Determinate Nix will be installed by default:

https://github.com/DeterminateSystems/nix-installer/blob/main/README.md?plain=1#L16-L17

https://github.com/DeterminateSystems/nix-installer/blob/main/README.md?plain=1#L30-L37

https://github.com/DeterminateSystems/nix-installer/blob/main/README.md?plain=1#L49-L56

[grahamc]

@Enzime You bet, thank you for those references. A first round of improvements is merged: #1478