5 ms·

I can't reproduce the exact test specified in the article: $ echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh $ time /tmp/test.sh &&

I can't reproduce the exact test specified in the article: $ echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh $ time /tmp/test.sh && time /tmp/test.sh Hello real 0m0.016s user 0m0.002s sys 0m0.010s Hello real 0m0.006s user 0m0.002s sys 0m0.004s I don't believe the 0.01s difference is long enough, and could easily explained by filesystem caching. The article says: > Some people try to explain away the delay, e.g., "I would put the 300 vs 5 ms down to filesystem caching", but such hand waving doesn't stand up to further scrutiny. ...but does not provide any "further scrutiny", so for me, occam's razor applies.

alexeldeib 6y ago
> You can verify that there's an online check by taking packet traces
boardwaalk 6y ago
It is real; browse the previous thread on this topic: https://news.ycombinator.com/item?id=23273247 https://news.ycombinator.com/item?id=23273247 It pushed me to buy Little Snitch to block it, so I guess somebody won out.
abathur 6y ago
A few ideas: 1. confirm the checks are enabled: spctl --status 2. Make sure your terminal/shell/etc aren't already exempted System Preferences > Security & Privacy > Developer Tools. 3. If you already ran something that could generate a check in the last minute, the connection is still open. Most of the overhead people are recording is negotiation/handshake. If you're fairly close to the server, it seems plausible your observed time could be enough for the communication minus the negotiation. You can open Console.app and search `process:syspolicyd` in the device log to see the entries for the negotiation; wait for it to terminate. 4. Try removing and re-creating a new file as in the test you did before and check it a little more directly: spctl --assess -v --ignore-cache --no-cache /tmp/test.sh If it's working, you should see a log entry with the text "summary for task success" in it with a detailed breakdown of the request (times taken per phase, bytes sent/received, etc).
- userbinator 6y ago
  I don't have a system to check this on, but Apple seriously named an option "asses"?
  - abathur 6y ago
    Ha, no. I'm the ass, here. Fixed :)
_qulr 6y ago
There's no such "filesystem caching" phenomenon on macOS Mojave and earlier, so that theory falls apart rather quickly. There's also the consistent difference between timing results with internet connection enabled vs disabled. I'm not sure why you couldn't reproduce the delay. There are several possibilities I can imagine, but these could only be proved or disproved by more testing. In any case, many people have reproduced the delay, on close to "factory default" Mac installs.

alexeldeib 6y ago

> You can verify that there's an online check by taking packet traces

boardwaalk 6y ago

It is real; browse the previous thread on this topic: https://news.ycombinator.com/item?id=23273247 https://news.ycombinator.com/item?id=23273247 It pushed me to buy Little Snitch to block it, so I guess somebody won out.

abathur 6y ago

A few ideas: 1. confirm the checks are enabled: spctl --status 2. Make sure your terminal/shell/etc aren't already exempted System Preferences > Security & Privacy > Developer Tools. 3. If you already ran something that could generate a check in the last minute, the connection is still open. Most of the overhead people are recording is negotiation/handshake. If you're fairly close to the server, it seems plausible your observed time could be enough for the communication minus the negotiation. You can open Console.app and search `process:syspolicyd` in the device log to see the entries for the negotiation; wait for it to terminate. 4. Try removing and re-creating a new file as in the test you did before and check it a little more directly: spctl --assess -v --ignore-cache --no-cache /tmp/test.sh If it's working, you should see a log entry with the text "summary for task success" in it with a detailed breakdown of the request (times taken per phase, bytes sent/received, etc).

userbinator 6y ago
I don't have a system to check this on, but Apple seriously named an option "asses"?
- abathur 6y ago
  Ha, no. I'm the ass, here. Fixed :)

_qulr 6y ago

There's no such "filesystem caching" phenomenon on macOS Mojave and earlier, so that theory falls apart rather quickly. There's also the consistent difference between timing results with internet connection enabled vs disabled. I'm not sure why you couldn't reproduce the delay. There are several possibilities I can imagine, but these could only be proved or disproved by more testing. In any case, many people have reproduced the delay, on close to "factory default" Mac installs.