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

481–490 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#481

Post by rcxdude »

tomp wrote: post #381
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.

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

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.

Re: MacOS Catalina: Slow by Design?

#482

Post by SSLy »

xoa wrote: post #382
skohan wrote: post #307

Earlier quoted context omitted.

For me it's aperture. I like the interface better than lightroom, and I don't want to pay a monthly fee to have access to my photo library which I only add to once in a while. It's a shame because it's a great piece of software, and even the UI doesn't feel dated, but I just won't be able to run it if I upgrade.

For what it's worth, Aperture, iPhoto and iTunes can be made to run in Catalina. People figured out last year what hacks were needed and there is a tool called Retroactive that will automate the steps: https://github.com/cormiertyshawn895/Retroactive Got some discussion on HN [1] about 3 months ago amongst other places, cool bit of sleuthing in the vein of efforts to get versions of macOS running on Macs older than o…

For a modern, subscription-less alternative to CS6 look at serif's affinity suite (no direct lightroom equivalent there though)

Re: MacOS Catalina: Slow by Design?

#483

Post by soraminazuki »

mixedCase wrote: post #432
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.

I'm probably missing something, and please let me know if so and why, but it sounds like a chroot could solve path reproducibility.

Nix requires that each package only writes to a dedicated directory in /nix/store. For example, files for Firefox 33.1 package would go into /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1. By not dumping files from every package in a common directory such as /usr, it requires each package to be explicit with its dependencies. This allows for many nice things explained elsewhere (e.g., https://nixos.org/nix/).

Re: MacOS Catalina: Slow by Design?

#484

Post by usmannk »

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 recording the network traffic and, sure enough, there is a request to ocsp.apple.com with a hash in the URL path and a bunch of binary data in the response body. Unsure what it is yet but the URL suggests it is generating a cert for the binary and checking it. See: https://en.wikipedia.org/wiki/Online_Certificate_Status_Prot...

Here's the URL I saw:

http://ocsp.apple.com/ocsp-devid01/ME4wTKADAgEAMEUwQzBBMAkGB...

Edit2: Anyone know what this hash format is? It's not quite base64, nor is it multiple base64 strings separated with '+'s but it seems similar...

Edit3: Here is the exact filename and file I used: https://gist.github.com/UsmannK/abb4b239c98ee45bdfcc5b284bf0...

Edit4 (final one probably...): On subsequent attempts I'm only seeing a request to https://api.apple-cloudkit.com and not the OCSP one anymore. Curiously, there's no headers at all. It is just checking for connectivity.

Re: MacOS Catalina: Slow by Design?

#485

Post by defnotashton2 »

crazygringo wrote: post #417

I'm so confused about the comments here. 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. 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. And I can't seem to find any substantive discussion of whether this is…

Op linked validated bug reports.. One of which Apple responded with "by design" of which op derived the title.

The down votes are because it seems pretty clear that the people who don't experience have long lived instances of their os and likely have grandfathered or disabled security settings. There are a lot of people saying ita pretty easy to replicate with a new os.

And it is, I just did it. Did you?

Re: MacOS Catalina: Slow by Design?

#486

Post by [deleted] »

soraminazuki wrote: post #409
tomp wrote: post #381

Earlier quoted context omitted.

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

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

[deleted]

Re: MacOS Catalina: Slow by Design?

#487

Post by saagarjha »

qppo wrote: post #171
saagarjha wrote: post #137

Earlier quoted context omitted.

Apple uses the same tools you do. They just might not be using it like you are; you can find a lot of features that clearly have no reason to exist outside of Apple nonetheless shipping with their software.

That's kind of my point - it's surprising to me that they're shipping slow hardware and software, when they're used to develop that same hardware and software. Developer time is expensive.

I would actually be quite happy if the engineers were forced to work on four-year-old MacBook Pros and develop against Display Zoomed iPhone 7 and the second generation Apple Watch, using the toolchain and software they push to their developers.

Re: MacOS Catalina: Slow by Design?

#488

Post by etoulas »

saagarjha wrote: post #452
Wowfunhappy wrote: post #446

Earlier quoted context omitted.

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.

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

Re: MacOS Catalina: Slow by Design?

#489

Post by [deleted] »

bad_user wrote: post #475
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…

Unix OS variants have pretty standard paths like /opt or /usr. Going with /nix was basically the best way to run into trouble.

[deleted]

Re: MacOS Catalina: Slow by Design?

#490

Post by kccqzy »

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.
Post reply on HN