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

381–390 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#381

Post by tomp »

yalogin wrote: post #362
soraminazuki wrote: post #278

Up until the release of Catalina, I've always upgraded to the latest version of macOS within a month or two. But some of the changes this time is really stopping me from upgrading. As of Catalina, there's no sane way to install the Nix package manager without losing functionality because macOS now disallows creating new files in the root directory[1]. Nix stores its packages in the /nix directory and it's not possibl…

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

Re: MacOS Catalina: Slow by Design?

#382

Post by xoa »

skohan wrote: post #307
soraminazuki wrote: post #278

Up until the release of Catalina, I've always upgraded to the latest version of macOS within a month or two. But some of the changes this time is really stopping me from upgrading. As of Catalina, there's no sane way to install the Nix package manager without losing functionality because macOS now disallows creating new files in the root directory[1]. Nix stores its packages in the /nix directory and it's not possibl…

For me it's aperture. I like the interface better than lightroom, and I don't want to pay a monthly fee to have access to my photo library which I only add to once in a while. It's a shame because it's a great piece of software, and even the UI doesn't feel dated, but I just won't be able to run it if I upgrade.

For what it's worth, Aperture, iPhoto and iTunes can be made to run in Catalina. People figured out last year what hacks were needed and there is a tool called Retroactive that will automate the steps:

https://github.com/cormiertyshawn895/Retroactive

Got some discussion on HN [1] about 3 months ago amongst other places, cool bit of sleuthing in the vein of efforts to get versions of macOS running on Macs older than officially supported. Personally I'm somewhat resigned to needing VMs to run certain older software, with a big one for me being Creative Suite CS6. Like you I have no interesting in buying into Adobe's subscription lock-in. But it's nice that some stuff can keep running without that layer for a while longer. Hopefully it'll still be possible in 10.16.

----

1: https://news.ycombinator.com/item?id=22454069

Re: MacOS Catalina: Slow by Design?

#383

Post by cmckn »

I run a pihole at home, which has intermittent issues. When macOS can't resolve a hostname, almost every user-facing UI grinds to a halt. It's truly bizarre. Applications won't launch, menus don't respond, etc. Feels like a decade ago when your spinning disk was going bad. Not cute :(

Re: MacOS Catalina: Slow by Design?

#385

Post by blunte »

adamtulinius wrote: post #349
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

What should the default nix store path have been then?

/usr/local/something

Re: MacOS Catalina: Slow by Design?

#386

Post by ronyfadel »

markdog12 wrote: post #294
ronyfadel wrote: post #35

I hope Apple currently has a team focused on macOS perf. I worked on the team in charge of improving iOS (13) perf at Apple and IIRC there was no dedicated macOS “task force” like the one on iOS. Luckily some iOS changes permeated into macOS thanks to some shared codebases.

What changes permeated into macOS? What did your team do to improve iOS perf?

So many of the frameworks have shared code between macOS and iOS (e.g. MapKit, Foundation, Contacts etc..), so a perf fix in iOS pays dividends on macOS too.

Perf changes are too numerous to mention, I’d recommend watching last year’s WWDC keynote describing the iOS 12 v/s 13 perf advancements.

Re: MacOS Catalina: Slow by Design?

#387

Post by bobbylarrybobby »

noisem4ker wrote: post #325
rhizome wrote: post #206

Earlier quoted context omitted.

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

What would that mean?

It would appear to mean it's a hacky, over-technical solution to a problem that shouldn't exist in the first place, as copying things from one computer to another should just work™. This is one place where macOS used to shine and seems to be increasingly falling behind in.

Re: MacOS Catalina: Slow by Design?

#388

Post by gubikmic »

robenkleene wrote: post #172
pier25 wrote: post #46

Earlier quoted context omitted.

> IIRC there was no dedicated macOS “task force” like the one on iOS It's not surprising. Macs are less than 10% of Apple's revenue. https://www.macrumors.com/2020/04/30/apple-2q-2020-earnings/

Except all of Apple's other devices are built on macOS. Apple's clear de-prioritization of macOS based on revenue numbers is so insane I can barely believe it's happening. If developers, who use Macs in large numbers today, go to another platform, there's very real risk that their entire empire starts to come apart at the seams. And, this may just be me being naive, but it doesn't seem like that much work to keep mac…

100% agree! If more people understood this, I hope this narrative would gain some traction and eventually reach Apple management.

To me, the idea that an OS is mostly finished is completely bananas. There's so much room for improvement and hardly any of that potential was tapped into in what's starting to feel like a decade.

And if Apple had invested into a successor for Cocoa, there might be a larger gap between native apps and (Electron) web apps, leading to some lock-in. Instead most new stuff is not native and for good reasons (and I do dislike the way they don't adhere to Mac conventions, but still).

I think ultimately the problem is Tim Cook. He's too attached to Apple's stock price. I think that's the one metric that he believes rates his performance. But inertia is a bitch. Like in politics, the effects might hit hard only once he's out and it could be too late to fix by then.

If I think about how much this impacts the economy overall (i.e. make millions of knowledge workers a little bit less efficient) then I can only hope that I'll see more sophisticated organizational structures in my lifetime that prevent such erosion.

Re: MacOS Catalina: Slow by Design?

#389

Post by roguas »

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

This is not the case. The problem is that caching is based on the default path which is /nix. So they would have to rebuild all caches.

Re: MacOS Catalina: Slow by Design?

#390

Post by ken »

> With internet enabled, it was reproducible by relaunching the application and triggering the code that called SecKeychainFindGenericPassword.

I have issues with a lot of APIs, but SecKeychain has got to be one of the worst. I don't think it's gotten any love in many, many years. Unlike literally every other Apple API that a Macintosh application might reasonably use, you call its functions (even from Swift) by passing strings as (length:UInt32, data:UnsafePointer?) pairs, and getting results out by passing (length:UnsafeMutablePointer?, data:UnsafeMutablePointer?) pairs, and checking OSStatus return values. Every aspect of it is painful.

In Apple's "Documentation Archive" there's three "Sample Code" downloads related to Keychain. The newest one is for TouchID, and the oldest is for PowerPC. This is an area of the OS that doesn't get much attention.

> This issue has been reported to Apple and assigned FB7679198. Apple has responded that applications should not use this function, though the documentation for SecKeychainFindGenericPassword does not state that it is deprecated

I see that it's now grouped in a section of the docs called "Legacy Password Storage", but not actually "deprecated". Strange. That means you won't get any indication of its non-current status from Xcode, or even reading the release notes.

I like that there's a newer (and presumably less awful) interface. I don't look forward to having to rewrite/retest that corner of my application. Seeing all the CFString/CFDictionary casting and OSStatus checking with the new functions, it still doesn't look all that great.

Post reply on HN