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

471–480 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#471

Post by hartzell »

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.

[Spack](https://spack.io) uses patchelf and additional tooling to relocate it's binary packages to other paths. It generally works, although one has to special case things that burn their install directory into their builds (e.g. Perl).

Re: MacOS Catalina: Slow by Design?

#472

Post by saagarjha »

BruceEel wrote: post #43
Nextgrid wrote: post #19

I've been forced to update to this pile of shit because latest iOS requires latest Xcode which in turn requires Catalina. It's a nightmare. First off the new apps (music, podcasts, etc) are terrible. They killed off iTunes but replaced it with much worse. These apps don't behave like standard macOS apps, the UI is full of inconsistencies and is just so empty. This website has nice examples of the failures of modern M…

> I've been forced to update to this pile of shit because latest iOS requires latest Xcode which in turn requires Catalina. It's a nightmare. I'm literally halfway there as I type this, Xcode 'installing components'. Having to upgrade essentially everything just to get the right dev tools for the current iOS is madness, feels like buying a new house to fit the new coffeemaker...

I install new versions of Xcode about every two weeks on average. The amount of time it takes to have a new Xcode running is at least an hour: first you download a massive XIP, then the system "verifies" it forever when you try to open it, then it takes forever to unarchive because it's huge, then you need to copy it from ~/Downloads to /Applications which takes another couple of minutes. Then you hit the component installation part… (I think this step has something to do with installing new MobileDevice frameworks?)

Re: MacOS Catalina: Slow by Design?

#473

Post by staticfloat »

JadeNB wrote: post #215
davidvartan wrote: post #141

Earlier quoted context omitted.

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

> 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. The article says the described problem isn't limited in this way: > This is not just for files downloaded from the internet, nor is it only when you launch them via Finder, this is everything. So even if you write a one line shell script and run it i…

If you read the comments of the article and do your own testing, you will find that reality appears to be more complicated than the article suggests. Users have shown using both timing and wireshark that the shell scripts do not appear to be triggering notarization checks.

Re: MacOS Catalina: Slow by Design?

#474

Post by indemnity »

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…

Reminds me of the AV exception folder our corporate IT created for developers. Soon absolutely everything developers needed or created was installed into that folder. Applications, IDEs, you name it.

Re: MacOS Catalina: Slow by Design?

#475

Post by bad_user »

pmahoney wrote: post #416
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.

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.

Re: MacOS Catalina: Slow by Design?

#476

Post by defnotashton2 »

chipotle_coyote wrote: post #262
Sangeppato wrote: post #238

Earlier quoted context omitted.

I don't experience a delay in Terminal.app either, but I've tried running the script with a fresh install of iTerm2 while capturing with Wireshark and it does look like the script triggers a connection to an Apple server

Obviously I can't say that's impossible, it would just be... very weird, and would seem to contradict what Apple Developer Relations was saying on Apple's devrel forums as recently as this year.

So its an actual fact documented that it happens. I agree that overall Mac os x still has a very nice ux and I'll never go back to windows.. But it's very clear apple is platforming their os to the degree they will ios. It's not weird it's happening, it's real life...

Re: MacOS Catalina: Slow by Design?

#477

Post by acdha »

shripadk wrote: post #275

I would give anything to have my Mac be fast again. I have no idea what changed but even 10.14 feels a whole lot slower than it was earlier. Haven't upgraded to 10.15 seeing all the negative reviews it is getting when it comes to perf. Apple needs to seriously give perf a priority for Mac. Do they really expect developers to use a Mac to develop Apps when it is slow as molasses? I shudder to think what will happen to…

Remember, people don’t write blog posts saying nothing changes. The negative reviews tend to be one of two things: spotlight reindexing shortly afterwards, or attribution error where every new thing is blamed on the OS upgrade and similar old behavior is mentally discounted. App development didn’t suddenly get “slow as molasses” and for most users the install was a reboot and back to work.

Re: MacOS Catalina: Slow by Design?

#478

Post by saagarjha »

mrits wrote: post #393
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…

Most vendors have separate engines for detecting malicious scripts. I'd assume notarizing is more about executables, in which case it would be checking the signatures around the shell binary. Also worth noting "echo" doesn't spawn a process but is a routine in the shell itself. If you replaced echo with something that does spawn a process "like scp" it would be interesting to see the results. And if that's doesn't in…

> Also worth noting "echo" doesn't spawn a process but is a routine in the shell itself.

In Bash echo is a builtin but /bin/echo also exists if you do actually want to spawn a process.

Re: MacOS Catalina: Slow by Design?

#479

Post by rcxdude »

pmahoney wrote: post #416
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.

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…

It's not really a desirable feature, but a limitation of the tools it has to work with, where e.g. specifying an rpath of $NIXROOT/store is not possible.

Re: MacOS Catalina: Slow by Design?

#480

Post by azinman2 »

kristopolous wrote: post #213
halotrope wrote: post #97

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…

I recently _really_ tried adopting Linux on a hobby development machine that I built back in 2016 (hardly new hardware -- and desktop not laptop). Sleep never worked, graphics sometimes borked, UI felt janky and inconsistent, icons are super fugly and often too theme-y to the point of being undifferentiated at a glance, HiDPI support is a giant mixed bag (in 2020), machine would randomly freeze (mostly elementOS; Ubuntu didn't freeze as much), Hauppage drivers rarely worked consistently and often required reboots, I hated the mouse acceleration curves and was horrified to learn they were effectively hardcoded in X (I'm not talking just speed which is tweakable), gstreamer was nightmare to develop for, the Ubuntu & elementaryOS stores are a joke, and the mix of apt/snap/nix was very frustrating and the opposite of user-friendly.

I switched back to my 2012 MBP and it's predictably gone well since, plus I get iMessage integration with my iPhone.

YMMV

Post reply on HN