MacOS Catalina: Slow by Design?

Brew never had this problem because they chose a sane path without corrupting the system directory. It’s a bad design on part of NixOS and one can even say the changes in the macOS were designed to encourage good/sane design.

Exactly. What's more, if we're talking about user hostility, how hostile is when a software doesn't provide a configurable install dir? It's literally a single damn variable!!

This is not the case. The problem is that caching is based on the default path which is /nix. So they would have to rebuild all caches.

Maybe they shouldn't have built it that way then. In my experience nix is nothing but a huge pain in the ass if you don't buy fully into the system, weird design decisions and all

> doesn't provide a configurable install dir

This is completely false. You can change the installation directory at the cost of losing binary packages. When you change it, packages would be built from source instead. This is what Homebrew does too.

What's more, I don't think many package managers provide this option. Not apt, not yum.

Writing file to /nix shouldn't corrupt the system directory either. What exactly do you mean by "bad design"?

Nix living at a predefined path is integral to how it works. An executable does not dynamically link to a generic "ncurses" but (via rpath) links to a specific compiled version of ncurses (such as /nix/store/81rb87agmp9cbsvg2xm2n4kp9c6309lv-ncurses-6.2). This is the root of all the benefits of Nix such as being able to install things side-by-side that use different versions of things or upgrade and rollback without problems.

That predefined path being the same (/nix) across all users of nixpkgs is required to be able to share binary packages (you could perhaps build everything from source, but that's a lot of time, more time even than something like gentoo because package updates require all dependencies to be rebuilt as well).

You can call it an insane choice or bad design, but there aren't a whole lot of options here. Could Nix move to a different path? Maybe, but is there a path that all operating systems could abide? If the new path stops working in some future OS, will it still be insane and bad design? Again, maybe, but I happen to love Nix and I use is on macos because it makes my life easier (and I'm on macos for work reasons). I'm willing to bend and do a lot of legwork to be able use Nix, and I'm upset with the Catalina situation.

Can follow some discussion here https://github.com/NixOS/nix/issues/2925

> Brew never had this problem because they chose a sane path

How so? Taking over /usr/local as Homebrew does is guaranteed to cause conflict. Using a dedicated file hierarchy as Nix does is quite reasonable and there's nothing magical about rooting it at /.

> Brew never had this problem because they chose a sane path without corrupting the system directory.

Ha, no. They did the absolute worst thing they could have done and now that they are popular they think they "own" /usr/local. (They used to camp out in /usr, but Apple rightfully put a stop to that real quick when SIP came out.)

Homebrew itself recommends you not do this, and while it is getting better at working in this case you will still run into issues if you try to do certain things.

This is why, of the two, I prefer Macports.

Happy MacPorts user of just over a year as well, for a variety of reasons I won't get into here but that being one of them.

[Spack](https://spack.io) uses patchelf and additional tooling to relocate it's binary packages to other paths. It generally works, although one has to special case things that burn their install directory into their builds (e.g. Perl).

Unix OS variants have pretty standard paths like /opt or /usr.

Going with /nix was basically the best way to run into trouble.

It's not really a desirable feature, but a limitation of the tools it has to work with, where e.g. specifying an rpath of $NIXROOT/store is not possible.

it's a single variable which many parts of the system need to have knowledge about, some parts which have basically no way to feed in a variable. You can change the root directory in nix, but that invalidates all binary packages, in part because rpath is not at all configurable.

Very satisfied MacPorts user since 16 years. I really don’t get why brew is a thing...

Because 10 years ago when I first started installing software from the command line on my mac, a large number of the packages I wanted to install were very outdated on MacPorts, and {CURRENT_VERSION} on homebrew.

Also `brew cask` is nice.

EDIT: also that Macbook had a 128GB HDD, so space was kinda precious, and MacPorts installing its own version of libs that were already on the system was literally taking up GBs of space.

How does it "take over" /usr/local? You can still `./configure --prefix=/usr/local` on your own software and things continue to work as long as you're not installing the same thing that brew is.

> Brew never had this problem because they chose a sane path without corrupting the system directory.

That's a hilarious assertion. Back in the days brew's takeover of /usr/local caused OSX upgrades to get stuck for hours on end (some folks reported more than 12h).

> How does it "take over" /usr/local?

Because it shoves all its shit there without asking.

Macports actually did it correctly and IME never had any issue.

Installing several versions of the same piece of software is central to Nix.

While locking all needed versions for a specific application provides stability, I can't believe it doesn't come without a large increase of complexity, especially in connection security upgrades which triggers other libraries to need an update as well.

In addition to outdated ports, several times I had issues with macports mucking with or otherwise interfering with the system-bundled copies of things which was a real headache.

Seems like the ideal setup would be something like Homebrew, except it "lives" in the ~/Library/Brews/ folder or something to that effect.

Homebrew does this far more often. MacPorts is off in its own world in /opt/local, which is actually mildly inconvenient sometimes because a lot of things won't pick it up when you want them to.

I think part of it is that they just advertised a lot more. When Homebrew came out, I seem to recall them advertising MacPorts as basically being old and busted. (Not literally those words, probably, but that was the general gist.)

Five or so years ago I evaluated between brew and macports, macports package were much more out of date while I needed fairly recent packages and brew had more of what I needed at the time.

Also, Macports never phoned home to Google without asking permission or notification, unlike Homebrew.

It could have been /opt/nix and been compliant with FHS, and kept all the benefits you mention.

Hindsight is 20/20. It wasn't /opt/nix for reasons I do not know. In the context of NixOS, there's little reason to consider FHS. Only when using Nixpkgs outside of NixOS does the /nix choice look poor. I don't know which came first.

That's an interesting point. But it's not just rpaths, there are many references to things within the nix store. I suspect it would quite difficult to make them bound at runtime or something, but would be nice if possible.

ports are for old beards, brew for cool hipsters.

The Nix abides.

Tiny typo that confused me, I think you mean:

> a lot of things won't pick it up when you want them to.

Thanks! I fixed it to limit confusion.

I'm much happier with their stance on it, too: https://lists.macports.org/pipermail/macports-dev/2019-March...

Completely off-topic, but do you somehow get notifications about replies to your comments? You often manage to respond within a couple minutes. :)

Not sure about five years ago, but these days it's usually not to bad for popular packages.