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

461–470 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#461

Post by oefrha »

saagarjha wrote: post #448
oefrha wrote: post #377

Earlier quoted context omitted.

No, SIP is fully enabled on both the machine with the Developer Tools category and the one without. Interestingly, I rebooted the machine without after some benchmarking and experimentation with syspolicyd (see https://news.ycombinator.com/item?id=23274903 ), and after the reboot the category has mysteriously surfaced... Not sure what triggered it. Launching Xcode? Xcode and CLT were both installed on the machine, bu…

> In the worst case scenario, you can probably insert into the TCC database Does this not require disabling SIP?

Yes. I got mine to appear through mysterious yet fully SIP-enabled means, but if all else fails for you you can temporarily disable SIP to change this.

Re: MacOS Catalina: Slow by Design?

#462

Post by ihiulll »

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…

I'm confused. does macbook send executable to apple servers or just the hash?

Re: MacOS Catalina: Slow by Design?

#463

Post by downerending »

kar1181 wrote: post #27

I completely understand why things are going the way they are as our computing environment has become ever more hostile. But I am very nostalgic for the time where I would power up a Vic-20 and within seconds be able to get to work. Teaching my daughter to program on a modern computer, we spend more time bootstrapping and in process, than we do in actual development.

On the plus side, emacs now starts far faster than most computers.

Re: MacOS Catalina: Slow by Design?

#464

Post by grishka »

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…

> and if there was a big switch that I could click to disable it all, I probably would

First, disable SIP to allow yourself to modify the system. Then, disable AMFI, the component responsible for code signature checking, entitlement enforcement and all that very useful stuff, with a kernel argument:

    nvram boot-args="amfi_get_out_of_my_way=0x1"
Then you should be done.

Re: MacOS Catalina: Slow by Design?

#465

Post by sergeykish »

inimino wrote: post #106
m463 wrote: post #94

Earlier quoted context omitted.

After you've gotten used to Linux, you might want to try Arch. It is lightweight, since you choose everything that is installed, sort of opt-in. It has all the latest software. It has "rolling releases" which means there is never a giant lost-weekend distribution upgrade. It has the AUR (arch user repository) for just about any software ever.

I used Arch on a server once (still running) but found the experience on Debian was more to my taste, and somehow never liked pacman. Maybe it's time to take another look. I never tried it on the desktop.

Interesting, I have opposite experience. Pacman looks so much simpler than aptitude, apt-get, apt-cache, dpkg. And makepkg - it just works. I have not managed to create packages on Ubuntu.

No outdated packages, no ppa. No upgrade. Install is rough but it nails how simple the system is.

Ubuntu is a good starting point. But there is so much more.

Re: MacOS Catalina: Slow by Design?

#466

Post by saagarjha »

soraminazuki wrote: post #458
saagarjha wrote: post #442

Earlier quoted context omitted.

I believe Nix actually picks a volume so that it can be encrypted, and it uses one of the many ways to run a script before login (some of which still happen to work) to decrypt it?

It's still problematic because that can only happen late in the login process.

I read that thread a couple weeks back (was doing some firmlink research and stumbled upon it) and I seem to recall someone there finding something that ran pretty early. Perhaps I'm misremembering? I am sure there is at least one way to get this done, but I'll have to go look into what it is.

Re: MacOS Catalina: Slow by Design?

#468

Post by catalogia »

kempbellt wrote: post #378
glofish wrote: post #334

Earlier quoted context omitted.

IMHO the original choice of the path seems incredibly ill-advised and the main burden lies with the original developers. sometimes old errors and mistakes come back and bite

If you truly want to be "cross-platform" with long-term future proofing in mind, `/nix` is (edit: was) probably the most stable choice. I get it, people are sensitive about the root directory. "But it's where ALL the stuff lives!". So yeah, try not to ever run 'rm -rf /' (even though this is blocked in most cases now). But why make it completely inaccessible for creating files/directories in? So much hand-holding for…

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.

Re: MacOS Catalina: Slow by Design?

#469

Post by xyst »

herova wrote: post #467

Windows + VSCode + WSL2 + Terminal + PowerToys = Just one love, never looked back.

The only problem I have with that is "Windows"

I'm currently trying to figure out how to emulate windows from a *nix distribution using qemu. I plan to use this as a "home lab" (k8s cluster or just plain fucking around), but still retain the ability to play an occasional AAA game.

Post reply on HN