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

401–410 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#401

Post by grishka »

xenadu02 wrote: post #103
davidvartan wrote: post #5

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

So since these permissions apply to process trees, what happens if you put launchd in there?

Re: MacOS Catalina: Slow by Design?

#402

Post by wux »

unown wrote: post #139

As someone living in China, this is my result when I connected to my VPN (this is my normal life, thus I can visit sites like HN): > Hello > /tmp/test.sh 0.00s user 0.00s system 0% cpu 5.746 total > Hello > /tmp/test.sh 0.00s user 0.00s system 79% cpu 0.006 total And even if I didn't connect to my VPN: > Hello > /tmp/test2.sh 0.00s user 0.00s system 0% cpu 1.936 total > Hello > /tmp/test2.sh 0.00s user 0.00s system 7…

I'm curious what your results would be with the stock Terminal. Do you have the settings that others have talked about under "Security > Privacy > Developer Tools" with Terminal.app listed? If so, and the results are better with Terminal, then it'd be interesting to see if the issue is fixed when you add iTerm2 to the list of exempted apps as well.

Re: MacOS Catalina: Slow by Design?

#403

Post by soraminazuki »

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

Nix isn't designed as an application. It's designed as a system package manager.

Re: MacOS Catalina: Slow by Design?

#404

Post by matheusmoreira »

danudey wrote: post #376
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 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…

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

Re: MacOS Catalina: Slow by Design?

#405

Post by chadlavi »

> You can test this by running the following two lines in a terminal:

>

> echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh

> time /tmp/test.sh && time /tmp/test.sh

Am I missing something here?

I just did this, and the timing between the first and second run was barely noticeable -- in fact, the first run was slightly quicker:

> echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh time /tmp/test.sh && time /tmp/test.sh

> Hello

> /tmp/test.sh 0.00s user 0.00s system 55% cpu 0.006 total

> Hello

> /tmp/test.sh 0.00s user 0.00s system 41% cpu 0.010 total

This is on macOS 10.15.4.

Re: MacOS Catalina: Slow by Design?

#406

Post by karatestomp »

saagarjha wrote: post #305
dvfjsdhgfv wrote: post #216

Earlier quoted context omitted.

This is upsetting for me, too. And for a few others. But actually very few people care because they just don't see it. The people who designed it this way take care that users at large have no idea what is going on.

It's really very sad, because users have no idea what is going on and there is no incentive for bad programs to improve (actually, there is generally incentive in the opposite direction , because it's work to write well-behaving apps). Users just know that they need to keep buying new computers and that their battery life is worse, but they can't figure out why so they point fingers at everyone but who they should ac…

Remember when shitty user-hostile spying wasn't a library you included that assured you in its readme it was "made with [heart] in California"? Ah, the days when only criminals and bigcos casually engaged in shady crap.

Re: MacOS Catalina: Slow by Design?

#407

Post by withinboredom »

cosmojg wrote: post #308
rhizome wrote: post #206

Earlier quoted context omitted.

That might be the Windows-iest feature of OSX I've ever heard of.

It seems macOS is going downhill fast these days.

No, it’s just that they’re becoming more popular. When you become a popular desktop OS, governments and militaries want to start using it which comes with some strange requirements. It also means that you can’t rely on “obscurity” to provide any sort of security, where before you could overlook some things.

Re: MacOS Catalina: Slow by Design?

#408

Post by chipotle_coyote »

ehutch79 wrote: post #375
chipotle_coyote wrote: post #211

Okay, I've tried this test on my MacBook Air 2020 several times, first by saving the "echo Hello" shell script in an editor and then, because I wasn't getting the results the author experienced, trying again exactly as he wrote it. Essentially the same result: airyote% echo $'#!/bin/sh\necho Hello' > /tmp/test.sh airyote% chmod a+x /tmp/test.sh airyote% time /tmp/test.sh && time /tmp/test.sh Hello /tmp/test.sh 0.00s…

10 to one says this is because you've run something calling /bin/sh before. if he switched the /bin/sh out to /bin/zsh or /bin/bash which ever his default shell was, he wouldn't have seen the first delay.

That's plausible -- but I'd be (mildly?) surprised if Apple hadn't pre-okayed binaries they supply with the OS. Even if you flip the Super Paranoia switches in privacy settings, you don't need to give macOS explicit permission to launch Apple-supplied binaries from the Finder.

Re: MacOS Catalina: Slow by Design?

#409

Post by soraminazuki »

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

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

Re: MacOS Catalina: Slow by Design?

#410

Post by reuben_scratton »

davidvartan wrote: post #141
scottlamb wrote: post #123

Earlier quoted context omitted.

> The way to avoid this behavior is to staple the notarization ticket to your bundle (or dmg/pkg) Maybe in some cases, but the article says "even if you write a one line shell script and run it in a terminal, you will get a delay!" Shell scripts don't come in bundles. I don't think this kind of stapling is possible for them? I don't think it'd be reasonable to expect users to do this anyway.

The Gatekeeper behavior is specific to running things from Finder (not Terminal), and only if you downloaded it via a browser that sets the com.apple.quarantine xattr. Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail. https://forums.developer.apple.com/thread/127709 https://forums.developer.apple.com/thread/127694

Quinn The Eskimo at Apple's forums is a 10x support engineer, his posts have helped me fix dozens of problems.
Post reply on HN