MacOS Catalina: Slow by Design?

It only seems that way now because some platforms have begun locking down their root directories. 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.

> Nix, by design, doesn't conform to the FHS way of organizing directories

That's why /opt/ exists. What's wrong with /opt/nix/ ? Or /var/opt/nix/ for read-write files that need not be a fixed part of any package installation (the Unix equivalent of system-wide "Application Data").

> 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.

Nix isn't designed as an application. It's designed as a system package manager.

> 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?

It's also an application, it just happens to manage other applications

Not conforming to the FHS is what makes Nix possible. You won't get Nix's reproducibility without it.

Because 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...)

I'm probably missing something, and please let me know if so and why, but it sounds like a chroot could solve path reproducibility.

Can you explain the reasoning here? I can see it being _easier_ than doing it the right way but have trouble coming up with a scenario where it makes it _impossible_.

To be more clear, it wasn't designed as a third-party package manager. It's supposed to be part of the system.

Nix 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/).

I still don't understand why that can't be solved by putting everything in /opt/nix/store

Or NIX_PATH, or ~/.nix, et c.

I am infinitely tired of this node_modules “we know better than you, it isn’t configurable and will never be configurable so stop asking” hubris. It’s not open source entitlement to say that a maintainer with that attitude is bad and wrong.

My homebrew is installed to ~/Library/Homebrew and while they claim it’s unsupported, it works, and if it stops working, then I’ll stop using Homebrew.

I don’t trust software that demands root when it doesn’t need it.

Packages can not 'accidentally' depend on other packages as the only way to depend on a package is by referring to their full path which your learn by evaluating that package.

If you have an application that calls /usr/bin/nginx but doesn't declare a dependency on nginx; but you had nginx installed already the package works fine and you only find our later

In nix you can't do this as you don't know nginx's path without defining a dependency on it; so you don't gain undeclared dependencies on accident.

By forcing a different path you find these things at build time not at run time.

It’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.

This 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.

But yeh rooting everything under /usr/nix or /opt/nix would've probably been a better choice.

What annoys me more is that a popular nix Fork GNU Guix _did_ change the path; but they made the same mistake again (it's rooted under /gnu) whilst they already has the hindsight that a non-standard directory might be problematic

You can use an alternate path with Nix. When you choose to do that, you will have to build all packages from source instead of installing prebuilt binaries.

/opt/nix is FHS compliant and would work fine.

That makes sense, and is good news. I withdraw my complaint against Nix; in my defense my ignorance was based on the thread on their GitHub about how Catalina makes Nix basically unusable. Turns out those people were both a) wrong and b) speaking authoritatively from ignorance. :/

I’m quite glad I can just install it somewhere else, and finally ditch the Homebrew spyware. Thank you for letting me know!

Easy solution: /nix as its own partition with plenty of space.

Please read https://news.ycombinator.com/newsguidelines.html and note the final two guidelines.

As 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#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.

And 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.

Nothing about that says that the path has to be /nix — it would work just as well with the standard layout under /opt/nix.

It also seems like it doesn't really help with the stated problem since a developer who would hard-code /usr/bin/nginx but not list it as a dependency would almost certainly just use whatever `which nginx` returns. The thing which would solve that is depending on a precise version or hash, and if you're doing that, the path prefix doesn't really matter.

That’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.

But you’re missing the essential point which is that the FHS a set of rules that only apply to the distribution.

> Applications [shipped by the distribution] should not...

> Distributions should not create new directories in the root hierarchy without extremely careful consideration of the consequences including for application portability.

The OS is free to break 3rd party applications that don’t follow their rules but strict adherence to the FHS is not the justification for doing so.

You'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.