Live data from Hacker News

MacOS Catalina: Slow by Design?

sigpipe.macromates.com

311–320 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#311

I hope Apple currently has a team focused on macOS perf. I worked on the team in charge of improving iOS (13) perf at Apple and IIRC there was no dedicated macOS “task force” like the one on iOS. Luckily some iOS changes permeated into macOS thanks to some shared codebases.

I agree. This kind of behavior certainly smells like teams doing their development work on high-capacity low-latency networks without much performance oversight.

Re: MacOS Catalina: Slow by Design?

#312
post #32

> a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server. The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg), i.e. "/usr/bin/stapler staple ." Otherwise, Gatekeeper will fetch the ticket and staple it for the user on the first run. (I'm the author of xcnotary [1], a tool to make notariz…

I mean, when I’m developing in a compiled language with the workflow edit code -> compile -> run (with forced stapling), changing it to edit code -> compile -> staple -> run doesn’t make it any less slow...

An update: flat out denying network access to syspolicyd using Little Snitch could cut down on the delay. (Yes, syspolicyd does send a network request to apple-cloudkit.com for every single new executable. Denying its access to apple-cloudkit.com only isn't sufficient either since it falls back to IP address directly.) Note that this might not be a great idea, and it still has nonzero cost — a network request has to be made and denied by Little Snitch.

Here's my benchmarking script:

  #!/bin/zsh
  tmpfile=$(mktemp)
  cat >$tmpfile 
If your local terminal emulator is immune with "Developer Tools" access (interestingly, toggling it off doesn't bring back the delay for some reason), you should be able to reproduce the delay over ssh.

Re: MacOS Catalina: Slow by Design?

#313
I used to use Mac pretty heavily for design and audio work, but around 10.14 because of Apple switching the way they do things, I've now entirely switched to Windows for that, and Linux for everything else. I just don't want to deal with the nonsense described in this post, among several other things.

Re: MacOS Catalina: Slow by Design?

#314

> a degraded user experience, as the first time a user runs a new executable, Apple delays execution while waiting for a reply from their server. The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg), i.e. "/usr/bin/stapler staple ." Otherwise, Gatekeeper will fetch the ticket and staple it for the user on the first run. (I'm the author of xcnotary [1], a tool to make notariz…

Xcode (the UI) is able to bypass GateKeeper checks for things it builds. The "Developer Tool" pane in System Prefs, Security, Privacy is the same power. Drag anything into that list you'd like to grant the same privilege (such as xcodebuild). This is inherited by child processes as well. The point of this is to avoid malware packing bits of Xcode with itself and silently compiling itself on the target machine, thus b…

This is life-changing. Thank you!

Re: MacOS Catalina: Slow by Design?

#315

I am using Ubuntu 20.04 on a Thinkpad X1 Extreme Gen2 and you would be surprised how "normal" it feels as a development machine. Sure there some little annoyances, the touchpad behaves a little worse than on windows, sound is a little worse. But the most important things, Keyboard and Screen are excellent. The system in general does not feel like the horror stories that people keep telling about linux on desktop(note…

Yup. Ubuntu 20 is the first desktop linux OS that just worked. Every other Linux desktop before it has had suspend/resume issues, wifi issues, sound issues, 3d issues, ratchet settings (things that can be set but never unset without some arcane magic), weird desktop behaviors, buggy software that crashes all the time, etc etc. Yes, I've tried ALL of them, including pop os and deepin. This year marks the first year th…

These things are highly hardware-dependent. Typically it takes a few years until support for new hardware devices, features or platforms stabilizes. But it can even take way more than that, and some less common and lower-quality hardware may fail to get support altogether.

Re: MacOS Catalina: Slow by Design?

#316
post #38

Earlier quoted context omitted.

Linux was always a disaster in terms of user experience and isn't improving. Curious: what have you tried? People who use "Linux" as a catch-all in terms of UX usually have only tried a single distribution with a single desktop environment.

Interesting. I regularly use RHEL (server/CLI only) but have not tried desktop Linux in a while. I get a fair bit of weekly exposure to Windows 10 and well, it's not like heaps of fun, UX wise. I'm reluctant to drop Apple mainly because I'm so 'tied up' with the rest of the ecosystem, iphone, Apple Music, iCloud etc.. They are not irreplaceable (for sure) but it always feels like moving away will cost way too much ef…

> I'm reluctant to drop Apple mainly because I'm so 'tied up' with the rest of the ecosystem, iphone, Apple Music, iCloud etc.. They are not irreplaceable (for sure) but it always feels like moving away will cost way too much effort and be a pain... Well played, Apple.

This is why I don't want anything by Apple.

Re: MacOS Catalina: Slow by Design?

#317

I am using Ubuntu 20.04 on a Thinkpad X1 Extreme Gen2 and you would be surprised how "normal" it feels as a development machine. Sure there some little annoyances, the touchpad behaves a little worse than on windows, sound is a little worse. But the most important things, Keyboard and Screen are excellent. The system in general does not feel like the horror stories that people keep telling about linux on desktop(note…

Yup. Ubuntu 20 is the first desktop linux OS that just worked. Every other Linux desktop before it has had suspend/resume issues, wifi issues, sound issues, 3d issues, ratchet settings (things that can be set but never unset without some arcane magic), weird desktop behaviors, buggy software that crashes all the time, etc etc. Yes, I've tried ALL of them, including pop os and deepin. This year marks the first year th…

Been putting off upgrading from 16.04 finally got it working a while back and was afraid to touch it.

Might give 20 a shot

Re: MacOS Catalina: Slow by Design?

#318
post #177

Earlier quoted context omitted.

IIRC the big thing that changed with 10.15 for CLI applications is that BSD-userland processes (i.e. ones that don't go through all the macOS Frameworks, but just call libc syscall wrappers like fopen(2)) now also deal with sandboxing, since the BSD syscall ABI is now reimplemented in terms of macOS security capabilities. Certain BSD-syscall-ABI operations like fopen(2) and readdir(2) are now not-so-fast by default,…

> IIRC the big thing that changed with 10.15 for CLI applications is that BSD-userland processes (i.e. ones that don't go through all the macOS Frameworks, but just call libc syscall wrappers like fopen(2)) now also deal with sandboxing, since the BSD syscall ABI is now reimplemented in terms of macOS security capabilities. Is this actually new in macOS 10.15? I seem to recall this being a thing ever since sandboxing…

> I seem to recall this being a thing ever since sandboxing was a thing, even all the way back to when it was called Seatbelt.

Maybe you're right; I'm not sure when they actually put the Seatbelt/TrustedBSD interpreter inline in the BSD syscall code-path. What I do know is that, until 10.15, Apple tried to ensure that the BSD-userland libc-syscall codepath retained mostly the same behavioral guarantees as it did before they updated it, in terms of worst-case time-complexities of syscalls. Not sure whether that was using a short-circuit path that went around Seatbelt or used a "mini-Seatbelt" fast path; or whether it was by hard-coding a pre-compiled MAC ruleset for libc calls that only relied upon the filesystem flag-bits, and so never had to do anything blocking during evaluation.

Certainly, even as of 10.12, BSD-userland processes weren't immune to being exec(2)-blocked by the quarantine xattr. But that may have been a partial implementation (e.g. exec(2) going through the MAC system while other syscalls don't.) It's kind of opaque from the outside. It was at least "more than nothing", though I'm not sure if it was "everything."

One thing that is clear is that, until 10.15, BSD processes with no capabilities manifest, still had the pretty much exactly the same default set of privileges that they had before capabilities, which means "almost everything" (and therefore they almost never needed to actually hit up the security system for more grants.) I guess all Apple really needed to have done in 10.15 to "break BSD", was to introduce some more capabilities, and then not put them in the default/implicit manifest.

I suppose what actually happened in 10.15 can be determined easily-enough from the OSS code that's been released. :)

> Is this not implemented in the kernel as an extension? // I am fairly sure you can just embed a profile in a section of your app's binary and call the sandboxing Mach call with that…

Yeah, sorry, you're right; updated my assertions above. I'm not a kernel dev; I've just picked up my understanding of this stuff from running head-first into it while trying to do other things!

Re: MacOS Catalina: Slow by Design?

#319
post #40

The funny thing is its not transitive. No slowdown if you invoke bash specifically with a new shell. % rm /tmp/test.sh ; echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh % time bash /tmp/test.sh && time bash /tmp/test.sh Hello bash /tmp/test.sh 0.00s user 0.00s system 83% cpu 0.004 total Hello bash /tmp/test.sh 0.00s user 0.00s system 77% cpu 0.003 total vs the one from the article: % rm /tmp/te…

[deleted]

Re: MacOS Catalina: Slow by Design?

#320

I am using Ubuntu 20.04 on a Thinkpad X1 Extreme Gen2 and you would be surprised how "normal" it feels as a development machine. Sure there some little annoyances, the touchpad behaves a little worse than on windows, sound is a little worse. But the most important things, Keyboard and Screen are excellent. The system in general does not feel like the horror stories that people keep telling about linux on desktop(note…

I've been seeing the trajectory of Windows (pre-2012 or so) -> Mac (2012 - ~2019 or so) -> Linux (~2018 - now) play out with quite a few people without any issues. And I don't mean developers. They're all pretty educated people but it's taken me by surprise. They come to me in frustration over Mac, they don't want to return to Windows and they really, really, really want linux. I've been using linux since about 1997…

Not associated at all but due to loving it, I wanted to share PhotoPea as you mentioned Gimp.

https://www.photopea.com

Post reply on HN