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

551–560 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#551

Post by catalogia »

kempbellt wrote: post #512
catalogia wrote: post #468

Earlier quoted context omitted.

If you have to `mkdir /nix` , what's wrong with `mkdir -p /opt/nix` ? I don't see how one is "more stable" than the other. The big difference between the two is the later conforms to convention while the former doesn't.

`mkdir -p /opt/nix` assumes that there is a convention, and that this is the correct convention - which may not be the case for every situation, and would result in creating unnecessary nested directories. You could make a more sophisticated installation script that attempts to install Nix into conventional locations depending on the specific operating system - or user input - but if you want a simple catch-all, simp…

> `mkdir -p /opt/nix` assumes that there is a convention

A correct assumption on virtually all relevant extant systems...

> which may not be the case for every situation

In the supposed scenario where the assumption isn't correct, the downside of /opt/nix vs /nix is basically insignificant. What's the overhead of one level of directory nesting, a single extra inode? Big whoop.

Re: MacOS Catalina: Slow by Design?

#552

Post by wl »

Wowfunhappy wrote: post #446
saagarjha wrote: post #433

Earlier quoted context omitted.

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

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

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

Re: MacOS Catalina: Slow by Design?

#553

Post by VonGuard »

kccqzy wrote: post #490
usmannk wrote: post #484

It seems like there is a lot of confusion here as to whether this is real or not. I've been able to confirm the behavior in the post by: - Using a new, random executable. Even echo $rand_int will work. Edit: What I mean here is generate your rand int beforehand and statically include it in your script. - Using a fresh filename too. Just throw a rand int at the end there. e.g. /tmp/test4329.sh I MITMd myself while rec…

OCSP is Online Certificate Status Protocol, generally used for checking the revocation status of certificates. You used to be able to turn it off in keychain access, but that ability went away in recent macOS releases.

Ah, Apple. When you can no longer innovate, just start removing features and call it simplicity...

Re: MacOS Catalina: Slow by Design?

#554

Post by jeremyjh »

pmahoney wrote: post #416
yalogin wrote: post #362

Earlier quoted context omitted.

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.

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

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

Re: MacOS Catalina: Slow by Design?

#555

Post by tsukurimashou »

BruceEel wrote: post #289
tsukurimashou wrote: post #207

Earlier quoted context omitted.

not him but same experience, from my previous comment: I would recommend: Ubuntu, Linux Mint, Elementary OS, Pop!_OS if you want: nice experience out of the box I would recommend: Arch, Gentoo, Debian Net inst, Void if you want a base system and install things you want on top of it

Thank you @all for the suggestions! I'm going to set aside some time to experiment with these and see how far I get.

Nice, I would like to hear your experience with it once you do that

Re: MacOS Catalina: Slow by Design?

#556

Post by jeremyjh »

sneak wrote: post #525
zozbot234 wrote: post #360

Earlier quoted context omitted.

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

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.

Re: MacOS Catalina: Slow by Design?

#557

Post by pmahoney »

jeremyjh wrote: post #554
pmahoney wrote: post #416

Earlier quoted context omitted.

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

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.

Re: MacOS Catalina: Slow by Design?

#558

Post by jeremyjh »

soraminazuki wrote: post #418
danudey wrote: post #376

Earlier quoted context omitted.

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

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

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

Re: MacOS Catalina: Slow by Design?

#559

Post by pmahoney »

rcxdude wrote: post #479
pmahoney wrote: post #416

Earlier quoted context omitted.

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

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.

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.

Re: MacOS Catalina: Slow by Design?

#560

Post by julianeon »

cerberusss wrote: post #494
julianeon wrote: post #380

Earlier quoted context omitted.

Longtime Linux user (Manjaro) and I never thought I'd see the day when I could pitch it as noticeably superior to MacOS, considering Apple's once-legendary attention to user interfaces. It seems like those days are behind us, now. Linux as an actually better experience, without gigantic embarrassing flubs like this, is looking better by the day.

A slowdown when you run an app for the first time, for security reasons -- I wouldn't categorize that as a "gigantic embarrassing flub". I haven't noticed it, actually. But I don't run new apps every day.

I think you're misunderstanding the problem, respectfully. This is not a problem for end users. This is a problem for developers - and a gigantic, embarrassing flub is justified for something as bad as this.

Think that's hyperbole? Look at this, from the link:

> The first time a user runs a new executable, Apple delays execution while waiting for a reply from their server. This check for me takes close to a second.

> This is not just for files downloaded from the internet... this is everything. So even if you write a one line shell script and run it in a terminal, you will get a delay!

Consider a developer in this situation.

If your job involves lots of scripting - not unusual, for a dev - and you create dozens of scripts a day, or more - every single one will take about a second, and up to 7 seconds (!) to run, that first time you run it. And that could easily happen upwards of a dozen times a day, because it will happen for each script you create.

That's pretty terrible, for a developer. I don't think you can normalize startup times, for some hacky script, of 1 second as pretty okay or not noticeable. Certainly not if you're talking about a high end work machine.

Times that bad are associated with some junk laptop that's 15 years old - that's not supposed to be Apple.

Even if you build apps (I do), you might have the need to create scripts now and then, possibly even a lot of them (I do, for testing). I don't consider it acceptable to wait 1 sec+ each time I run one. It really does suggest that Apple has gotten extremely careless about their developer audience.

So, yeah - compared to that, Linux performs way better, and looks like a premium work machine by comparison.

Post reply on HN