4 ms·
> Nix, by design, doesn't conform to the FHS way of organizing directories so it made perfect sense to use /nix when the decision was originally made. Refusing
by danudey 6y ago
> Nix, by design, doesn't conform to the FHS way of organizing directories so it made perfect sense to use /nix when the decision was originally made.
Refusing to conform to the FHS doesn't mean their decision made sense; refusing to conform to the FHS means they made a bad decision in the past and everything progressed from there.
It doesn't 'seem that way now because some platforms have begun locking down their root directories'; it seems that way because creating arbitrary directories in / is a terrible idea, and has been at least since I started using UNIX/Linux systems in the 90's.
Fact is, they made a bad design choice, and now it's come back to bite them (and their users) in the ass.
- matheusmoreira 6y ago> creating arbitrary directories in / is a terrible idea, and has been at least since I started using UNIX/Linux systems in the 90's Why?
- cesarb 6y agoBecause the root directory might be on a very small partition (perhaps only a few hundred megabytes), while other mount points like /usr might have more space; the only things which should be in / are the things which are necessary to mount the other filesystems (perhaps through the network using NFS). (Yes, nowadays hard disks are much larger, we have things like initrd, and we now make /bin and /sbin symlinks to within /usr, but the parent comment did mention the 90s...)
- chungy 6y agoEasy solution: /nix as its own partition with plenty of space.
- mixedCase 6y agoBecause the filesystem root is the domain of the OS, if tomorrow they decide they are going to create a symlink of /dev/null in /nix because they thought it sounded cooler as a way to "nix" stuff, there goes the Nix package manager. The OS gives you places to put your files, use them so that you prevent breakage. We have the FHS, so you even have some degree of certainty of where to do it across Unixes. EDIT: Two downvoted comments answering a "why" but no rebuttal to either. HN is slowly but surely becoming Reddit.
- ashtonkem 6y agoIt’s because Nix was designed to be part of the OS, as integral as apt is for Debian installations. The ability for it to live side by side with another packaging system is just a side-effect of how it was designed, not part of the original goals.
- mixedCase 6y agoAnd NixOS is a great idea, but Nix advertises itself as "a powerful package manager for Linux and other Unix systems" in its the official site's description. Yet by not abiding to the FHS, they opened themselves up for breakage.
- ashtonkem 6y agoThat’s an after the fact feature; my understanding is that the original design was intended to be the sole package manager on the system. This is backed up by the fact that NixOS and Nix appear to have both been created at the same time; 2003.
- Spivak 6y agoThis is wrong. Everything not specified in the FHS is the domain of the administrator and is a contract with the OS about what directories it wont touch. Nix, operating outside of the FHS, did the literal correct thing because there is no guarantee that the OS won’t install something in /opt/nix but there is a guarantee that it won’t touch /nix.
- mixedCase 6y agoAs a sysadmin you can do anything you want and are free to deal with the breakage you cause yourself. But the FHS pretty clearly establishes what behavior an application such as Nix should have: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03.html#purpose2 https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03.html#p... Quote: "Applications must never create or require special files or subdirectories in the root directory. Other locations in the FHS hierarchy provide more than enough flexibility for any package." They can choose not to abide the FHS, and that's fine if the users are happy with that tradeoff. But OSes observing the FHS are free to break Nix's expectations because they don't align with the FHS.
- soraminazuki 6y agoNot conforming to the FHS is what makes Nix possible. You won't get Nix's reproducibility without it.
- mixedCase 6y agoI'm probably missing something, and please let me know if so and why, but it sounds like a chroot could solve path reproducibility.
- soraminazuki 6y agoNix requires that each package only writes to a dedicated directory in /nix/store. For example, files for Firefox 33.1 package would go into /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1. By not dumping files from every package in a common directory such as /usr, it requires each package to be explicit with its dependencies. This allows for many nice things explained elsewhere (e.g., https://nixos.org/nix/ https://nixos.org/nix/).
- cauthon 6y agoI still don't understand why that can't be solved by putting everything in /opt/nix/store
- soraminazuki 6y agoYou've got to keep it mind that Nix was designed as a system package manager and its primary target is NixOS. As such, I'd imagine that it wasn't all that unreasonable for Nix to assume ownership over /nix when the decision was made back then. Since Nix doesn't organize files according to FHS recommendations, it's never going to be FHS compliant. If so, what benefits would there be for Nix to choose /opt/nix over /nix? After all, /opt is where third-party packages reside and hardly the right choice anyways. The fact that Nix can be used as a third-party package manager outside of NixOS was a nice side-effect of its design choices. If Nix was designed from the start as a third-party package manager, it might have placed itself in /opt/nix. However, Nix was made years before some platforms started to lock down the root directory. It worked perfectly well with /nix before this happened. So instead of asking why Nix is placing itself in /nix instead of following some guidelines for traditional unix distributions, I think we should be asking why platforms are disallowing this. If a platform is going to make this big a breaking change, it'd better have a very good reason to do so. I fail to see the reason beside subjective aesthetics.