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

791–800 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#791

Post by m463 »

pietrovismara wrote: post #726
amatecha wrote: post #687

Earlier quoted context omitted.

Yeah, this is the future I've been foreseeing for years. Every new OS update just ever so slightly decreases your ability to control what software is on your device, and how you can use it. For example, you used to be able to back up your purchased iOS apps to your computer, and restore them from your computer. In one iOS update (9 IIRC?), they removed the ability to back up the apps from your phone. In a later iOS/i…

If I may ask, why do you still persist with apple products then? Sounds like masochism from here...

this is sort of an ecosystem pattern.

First xbox was offline, subsequent xboxes were more intrusive

first windows pcs were offline, now they have become spy ("telemetry") machines

Apple has reigned itself in (a bit), but they just as stubbornly put business decisions above user wants.

Re: MacOS Catalina: Slow by Design?

#792

Post by saagarjha »

ridiculous_fish wrote: post #787
saagarjha wrote: post #773

Earlier quoted context omitted.

…with everything to do with the sandbox left out.

Fair point. These tarballs may be, err, editorialized. If exec is blocking in the kernel on IPC to some daemon, that should be observable (e.g. Instruments with kernel traces enabled).

Yeah, I'm sure a good spindump would be able to find what the code is blocked on. Sadly I run with SIP disabled so I can attach to things, so I probably cannot reproduce the issue…

Re: MacOS Catalina: Slow by Design?

#793

Post by kevinh456 »

rurban wrote: post #757
usmannk wrote: post #484

It seems like there is a lot of confusion here as to whether this is real or not. I've been able to confirm the behavior in the post by: - Using a new, random executable. Even echo $rand_int will work. Edit: What I mean here is generate your rand int beforehand and statically include it in your script. - Using a fresh filename too. Just throw a rand int at the end there. e.g. /tmp/test4329.sh I MITMd myself while rec…

It's called lockdown for a reason. Apple was just the very first to implement centralized binary blacklisting, revocation. They call it notarization. Problem is, that they did it unannounced. There must be really some weird stuff going on in those managers heads. How can they possibly think to go away with that?

There was nothing "unannounced" about it. Notarization was introduced at WWDC 2018 and announced as required at WWDC 2019. Every macOS developer should have been aware of this requirement. It was a special project for my apps.

Re: MacOS Catalina: Slow by Design?

#794

Post by cycomanic »

goatinaboat wrote: post #136
armatav wrote: post #117

Earlier quoted context omitted.

How does that even make sense? It’s an OS, go grab a Desktop Environment and download nvim, VSCode or whatever.

How does that even make sense? Because that was the experience on those old machines. Switch it on, straight to BASIC prompt in a second or so. If you want to program it’s frictionless. And you can’t break it because BASIC is in ROM.

If you want that today get a BBC microbit, switch on and you're directly in a python environment

Re: MacOS Catalina: Slow by Design?

#795

Post by Karliss »

ccmcarey wrote: post #199
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…

It doesn't work when there's no network connection, wonder if it would be possible to filter out and automatically block notarization traffic, or if it's all encrypted with cert pinning to prevent this type of MITM+filter.

Dropping packets when there is an otherwise working connection could potentially make the delay even worse depending on timeout or retry strategy used by Apple code. I assume that in the fast case without network connection it checks the network status flag and doesn't try to do any network connection at all.

Re: MacOS Catalina: Slow by Design?

#796

Post by kevinh456 »

userbinator wrote: post #643
throwaway851 wrote: post #590

Earlier quoted context omitted.

Another way to look at it is that Apple is making it harder to run the system in an insecure fashion. You may not agree with that decision, but I certainly appreciate how Apple is looking out for the safety and security of the user. Tangent: as much as some developers hate that the only way to distribute apps for the iPhone is through the App Store, as a user I consider that walled garden of apps to be a real securit…

Another way to look at it is that Apple is making it harder to run the system in an insecure fashion. You may not agree with that decision, but I certainly appreciate how Apple is looking out for the safety and security of the user. "Those who give up freedom for security deserve neither." (Yes, I know the original intent was slightly different, but that old saying has gotten a lot more vivid recently, as companies a…

So keep a Linux box if you want. Don't shit on people for using a mac.

I can use macOS, Windows 10, and any distribution Linux I want without having to pick one. That's freedom. I have choices. I choose all of the above in my personal setup. I'll fight to keep my free software but, at the same time, you can pry logic on the mac from my cold dead hands. I've been using it for 15 years and I am not going to stop now. Use the best/preferred tool for the job you have to do.

Re: MacOS Catalina: Slow by Design?

#797

Post by m463 »

zozbot234 wrote: post #196
m463 wrote: post #73

Earlier quoted context omitted.

People who have used ubuntu might want to just once try arch linux. I had an ubuntu machine that took a while to boot even with an SSD. Later I installed arch linux on the same machine and boom! it would be to the desktop in seconds. It was night and day.

Debian is just as quick, and does not have the problematic "rolling" updates of Arch. (It does have the "testing" and "unstable" channels which are roughly comparable, but the Debian folks won't tell you to use them in production.)

> problematic "rolling" updates

Rolling updates for me have not been problematic.

I've had a few updates that gave an error message, and they were easily fixed in one minute after searching the arch website.

I think one was a key expired - I had to manually update it and redo the update process.

The other I can recall was a package that had become obsolete/conflicting and a question had to be answered.

In general rolling updates are a tiny blip every few months.

In comparison, the several debian based distributions I've run have been a "lost weekend" type of upgrade for major updates.

Re: MacOS Catalina: Slow by Design?

#798

Post by m463 »

zozbot234 wrote: post #230
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've never lost a weekend to a Debian dist-upgrade. Just read the release notes carefully beforehand, take a full backup of your data (which you should be doing anyway), make a note of any non-Debian applications you're using on that machine (that's the stuff that will need the most extensive testing post-upgrade) and it should simply work.

I have. debian, raspbian, ubuntu. A few times it has gone well, only to find there was cruft left over from previous installs.

"it should simply work" is not a given on any linux.

I'm not denigrating those distributions, there are lots of reasons to have a stable release without a lot of things changing (especially development).

It's just that changing lots of assumptions at once is fragile.

Re: MacOS Catalina: Slow by Design?

#799

Post by rurban »

dagmx wrote: post #790
rurban wrote: post #757

Earlier quoted context omitted.

It's called lockdown for a reason. Apple was just the very first to implement centralized binary blacklisting, revocation. They call it notarization. Problem is, that they did it unannounced. There must be really some weird stuff going on in those managers heads. How can they possibly think to go away with that?

There were announcements about notarization around WWDC last year. They didn't seem to get a lot of media traction however, but there were specific pages detailing what's required from a developer and some basic details on how it would work From April 10, 2019: https://developer.apple.com/news/?id=04102019a https://developer.apple.com/documentation/xcode/notarizing_m...

For each and every shell or perl script that I create and use privately? No, certainly not.

Re: MacOS Catalina: Slow by Design?

#800

Post by inimino »

lgl wrote: post #222
inimino wrote: post #153

Earlier quoted context omitted.

Debian still feels like home. Unless I try a BSD or something without systemd I think this is probably where I'll end up.

Well, Debian does use systemd by default now unless you want to go through some hoops to remove it (which I believe is still possible but not sure). I personally have really no issues with systemd and now even go as far as completely removing the ifupdown, isc-dhcp-client, resolvconf and ntpd packages in favor of having my entire network stack configured by systemd-networkd, systemd-resolved and systemd-timesyncd ins…

> there is a good deal of functionality and flexibility on that thing.

That's also what seems worst about it. Unfortunately there seem to be few other choices these days.

Post reply on HN