MacOS Catalina: Slow by Design?

Up until the release of Catalina, I've always upgraded to the latest version of macOS within a month or two. But some of the changes this time is really stopping me from upgrading.

As of Catalina, there's no sane way to install the Nix package manager without losing functionality because macOS now disallows creating new files in the root directory[1]. Nix stores its packages in the /nix directory and it's not possible to migrate without causing major disruptions for existing NixOS and other Linux users. This is too bad, since apart from Nix being a nice package manager, it also provides a sane binary package for Emacs. The Homebrew core/cask versions only provides a limited feature set[2][3].

[1]: https://github.com/NixOS/nix/issues/2925

[2]: https://github.com/Homebrew/homebrew-core/issues/31510

[3]: https://github.com/caldwell/build-emacs/search?q=support+is%...

IMHO the original choice of the path seems incredibly ill-advised and the main burden lies with the original developers.

sometimes old errors and mistakes come back and bite

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

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

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

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.