💾 Archived View for tilde.pink › ~kaction › log › 2020-01-22.1.gmi captured on 2023-09-28 at 16:13:52. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-01-29)
-=-=-=-=-=-=-
Nix^1is awesome. Compared to traditional package managers, like `yum`, `portage` or `apt`, it is quality of life improvement. And it is easy to install in parallel to existing system, using this^2 script. This script creates single-user installation, where all files are owned by your regular user.
Such setup is fine as long you only want to install pre-built software that is part of Nixpkgs collection, but once you decide to go deeper and write your own package definitions (so called derivations), I strongly recommend to switch to client-server setup.
Once wonderful property of Nix is that built packages are never modified, which makes rollbacks to previous version easy. But in case of single-user setup, there is nothing to stop you (or, more likely, your build script) from accidentally modifying files that are supposed to be read-only. Been there, done that, never again.
By the way, if you already have corrupted your Nix installation, here is remedy:
$ nix-store --verify --check-contents --repair
Client-server setup provides safety net for such accidents: every build process is run as separate non-privileged user. Assuming that you already have single-user setup, switching to client-server is simple:
1. Change owner of /nix to root:
# chown -R root:root /nix
2. Create build group and build users:
# addgroup nixbld > # adduser -S nixbld1 nixbld > # adduser -S nixbld2 nixbld Nix daemon uses users of `nixbld` group to perform parallel build of different derivation. Ten users should be more than enough.
3. Make sure you have `NIX_REMOTE` environment variable set to value `daemon`. Following line in `~/.profile` would suffice:
export NIX_REMOTE=daemon
4. Start Nix daemon somehow. If your distribution uses `runit`, runscipt for Nix daemon is simple:
If your distribution uses `openrc` init system, init script is very similar:
It is *essential* to make sure that Nix daemon does not inherit `NIX_REMOTE` variable from your environment, otherwise it will try to connect to itself instead of actually doing work.
If you see that Nix daemon endlessly spawns more processes, that is probably the cause. I am not sure whether it is bug in Nix or in concept of init.d scripts.