Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MacOS Catalina: Slow by Design?

sigpipe.macromates.com

Post reply on HN
Print view View original

521–530 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#521

Post by masklinn »

yalogin wrote: post #362
soraminazuki wrote: post #278

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 possibl…

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.

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

Re: MacOS Catalina: Slow by Design?

#522

Post by [deleted] »

yalogin wrote: post #362
soraminazuki wrote: post #278

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 possibl…

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.

[deleted]

Re: MacOS Catalina: Slow by Design?

#523

Post by saagarjha »

cerberusss wrote: post #492
saagarjha wrote: post #431

Earlier quoted context omitted.

> There are a bunch of people who can't reproduce the slowness at all, but nearly all downvoted or you have to wade through 100's of comments to get to them. It's possible that they have certain security features disabled. > The majority of comments are just dumping on Macs, nothing whatsoever to do with the content of the article, and seem to be blindly assuming it's true. Welcome to Hacker News…this is common on an…

I've noticed the negativity on macOS. There may be reasons for it, I don't know. I'm pretty happy with it and I've started skipping some discussions because of the amount of comments that lack any curiosity, or worthy discussion.

It's not just macOS. What you really want is a topic that most commenters have no background knowledge or preconceptions about, and you have to make sure that you can't link to one in any way whatsoever. The latter is a little hard to do, because people will cling to the most tenuous of relationships in order to be able to provide their input: you could be talking about a Windows API and someone will bring up EEE through some convoluted path and from there the conversation will go downhill. The best comments are the ones on articles about dolphin psychology or whatever and someone might ask a simple question and a real expert will chime in with something like "I have worked with dolphins for 17 years and also I wrote my doctoral thesis in cetacean-human interactions" and it's just a page of an interesting viewpoint that you just never knew about.

Re: MacOS Catalina: Slow by Design?

#524

Post by masklinn »

ryanianian wrote: post #514
pulisse wrote: post #424

Earlier quoted context omitted.

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

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.

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

Re: MacOS Catalina: Slow by Design?

#525

Post by sneak »

zozbot234 wrote: post #360
soraminazuki wrote: post #346

Earlier quoted context omitted.

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

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.

Re: MacOS Catalina: Slow by Design?

#526

Post by arianvanp »

acdha wrote: post #441
soraminazuki wrote: post #418

Earlier quoted context omitted.

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.

Re: MacOS Catalina: Slow by Design?

#527

Post by ashtonkem »

mixedCase wrote: post #429
matheusmoreira wrote: post #404

Earlier quoted context omitted.

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

Because 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 dow…

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.

Re: MacOS Catalina: Slow by Design?

#528

Post by joosters »

soraminazuki wrote: post #278

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 possibl…

You can create permanent symlinks inside / by creating a file called /etc/synthetic.conf - 'man synthetic.conf' has the full documentation. This sounds like it would solve the issue?

Re: MacOS Catalina: Slow by Design?

#529

Post by xyproto »

ryanianian wrote: post #514
pulisse wrote: post #424

Earlier quoted context omitted.

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

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.

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.

Re: MacOS Catalina: Slow by Design?

#530

Post by Spivak »

mixedCase wrote: post #429
matheusmoreira wrote: post #404

Earlier quoted context omitted.

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

Because 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 dow…

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.

Post reply on HN