NixOS have a lot of problems with proprietary software, developing running unpatched binaries. That’s all because NixOS doesn’t follow FHS. So why not just move all symlinks for current system to root?
1 Like
In the past I think it was because nix build processes could accidentally make use of system-wide software installed by the user this way, which would make them impure (I believe this is still an issue on single-user darwin installations?). These days, Nix does sandboxing when it can chroot, so this is much less of an issue. But it’s still a good design for NixOS because it prevents people from thinking they’ve successfully packaged some software only for others to find that it doesn’t work because they don’t have the same system software installed (plus the software will be unusable as a build input to other sandboxed nix builds). The buildFHSUserEnv stuff we do for e.g. Steam prevents “works on my machine” type issues even for unpatched binaries.
4 Likes
I think the fundamental issue is, that, if something is correctly built and configured, it won’t need to be in the root directory. If it needs to be in the root directories to run properly, then it is not built and configured in a way that is reproducible. If a user needs to install software that can’t be fixed for Nix, I think it should be left up to them to make it work. I’ve had to do this for a few programs myself, and it wasn’t much of an issue, but I worry that if it was a built-in feature, Nix would lose some of it’s benefits.
Historically this was done because nix didn’t have any sandboxing. But it might be a good idea to re-visit that.
Having to patchelf all of the things makes it much more difficult to run arbitrary software that hasn’t been packages in the nix way on NixOS.
2 Likes
Historically this was done because nix didn’t have any sandboxing. But it might be a good idea to re-visit that.
Note that testing whether the package output is usable is done without sandboxing anyway. While it is unlikely that upstream has references to /run/current-system/sw/bin, missed dependencies from /usr/bin and /bin are quite possible.
Maybe we should provide some FHS userenv wrapper?
2 Likes
We have buildFHSUserEnv, but it’s a pain to extract all dependencies
Historically this was done because nix didn’t have any sandboxing. But it might be a good idea to re-visit that.
Isn’t another benefit of the current approach that you can flip the switch more or less atomically? If symlinks were made in / and nixos-rebuild --switch would be cancelled while creating symlinks, you’d be left with an incomplete /. Whereas with the current approach, you’d just be left with the current generation.
Isn’t another benefit of the current approach that you can flip the switch more or less atomically? If symlinks were made in
/andnixos-rebuild --switchwould be cancelled while creating symlinks, you’d be left with an incomplete/. Whereas with the current approach, you’d just be left with the current generation.
NixOS does atomicity worse than it could do it; but generally, these links should not affect atomicity: they all have to lead to /run/current-system/global-links/…, and they should be updated before switching the main link.
1 Like