←back to thread

MacOS Catalina: Slow by Design?

(sigpipe.macromates.com)
2031 points jrk | 10 comments | 22 May 20 15:39 UTC | HN request time: 0.002s | source | bottom
Show context
soraminazuki ◴[22 May 20 17:36 UTC] No.23274749[source]▶
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%...

replies(7): >>23274866 #>>23274876 #>>23275063 #>>23275095 #>>23275183 #>>23276409 #>>23276458 #
glofish ◴[22 May 20 18:03 UTC] No.23275063[source]▶
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

replies(6): >>23275118 #>>23275134 #>>23275147 #>>23275200 #>>23275256 #>>23277290 #
soraminazuki ◴[22 May 20 18:09 UTC] No.23275118[source]▶
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.
replies(2): >>23275179 #>>23275246 #
danudey ◴[22 May 20 18:21 UTC] No.23275246[source]▶
> 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.

replies(2): >>23275377 #>>23275532 #
1. matheusmoreira ◴[22 May 20 18:33 UTC] No.23275377[source]▶
> 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?

replies(2): >>23275575 #>>23275598 #
2. cesarb ◴[22 May 20 18:54 UTC] No.23275575[source]▶
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...)

replies(1): >>23277358 #
3. ashtonkem ◴[22 May 20 20:11 UTC] No.23276399[source]▶
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.
replies(1): >>23277762 #
4. Spivak ◴[22 May 20 20:13 UTC] No.23276415[source]▶
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.

replies(1): >>23277733 #
5. chungy ◴[22 May 20 21:40 UTC] No.23277358[source]▶
Easy solution: /nix as its own partition with plenty of space.
6. dang ◴[22 May 20 22:21 UTC] No.23277725[source]▶
Please read https://news.ycombinator.com/newsguidelines.html and note the final two guidelines.
7. mixedCase ◴[22 May 20 22:22 UTC] No.23277733{3}[source]▶
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.

replies(1): >>23279227 #
8. mixedCase ◴[22 May 20 22:25 UTC] No.23277762{3}[source]▶
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.
replies(1): >>23277880 #
9. ashtonkem ◴[22 May 20 22:39 UTC] No.23277880{4}[source]▶
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.

10. Spivak ◴[23 May 20 02:14 UTC] No.23279227{4}[source]▶
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.