Live data from Hacker News

MacOS Catalina: Slow by Design?

sigpipe.macromates.com

611–620 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#611
My 2011 era MacBook Pro has run Linux most of its life. It runs super fast compared to its performance under MacOS even a year into its existence.

I've heard people ask me "why bother with Linux when MacOS is Unix?". Well technically it is from its heritage, but it gets less unixy by the day.

Re: MacOS Catalina: Slow by Design?

#612

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…

I can't edit anymore but it seems like the OCSP link could potentially be a red herring just checking the cert for the next request to https://api.apple-cloudkit.com/. It's worth looking further!

Re: MacOS Catalina: Slow by Design?

#613
Adding network calls to syscalls like exec() is utterly insane. This road can lead to bricked laptops where you can't run anything to fix it (imagine an unexpected network error that the code doesn't handle properly). And crackers will just use ways to overwrite running instruction text to avoid the exec().

The comments on the article are annoying: it good that there's a mini way to reproduce, but please, use some further debugging like tcpdump (it still exists on osx, right?). Last time I summarized osx debugging was https://www.slideshare.net/brendangregg/analyzing-os-x-syste...

I'd also stress test it: generate scripts in a loop that include random numbers and execute them.

Re: MacOS Catalina: Slow by Design?

#614
post #592

Earlier quoted context omitted.

Honestly I'm trying to think of a reason you would WANT to disable OCSP, I'm having enough problems thinking of more than 2 developers I know who can actually articulate how it works enough to evaluate this. Not that it's complicated—it's just mostly invisible. Even when OCSP is a problem, generally you're more worried about issuing a new certificate than an immediate workaround. What are you going to do, ask all you…

How about it's totally ineffective? OCSP is pointless if you "soft fail" when the OCSP server can't be reached. [1] This is why Chrome disabled OSCP by default all the way back in 2012-2013 era. Not to mention the performance cost of making all HTTPS connections wait for an OCSP lookup. [2] [1]: https://www.imperialviolet.org/2012/02/05/crlsets.html [2]: https://arstechnica.com/information-technology/2012/02/googl...

That's why there's OCSP stapling and OCSP must staple. Ever seen an nginx server fail HTTPS connection exactly once after rotating the certificate? That's nginx lazily fetching the OCSP response from upstream for stapling purposes.

Re: MacOS Catalina: Slow by Design?

#615

Earlier quoted context omitted.

Ah, Apple. When you can no longer innovate, just start removing features and call it simplicity...

Honestly I'm trying to think of a reason you would WANT to disable OCSP, I'm having enough problems thinking of more than 2 developers I know who can actually articulate how it works enough to evaluate this. Not that it's complicated—it's just mostly invisible. Even when OCSP is a problem, generally you're more worried about issuing a new certificate than an immediate workaround. What are you going to do, ask all you…

Well, security starts from the user. If you're not mindful of what websites you visit, or what files/apps you download and run, there's no OCSP or anything else there to save you.

OCSP enabled or not, you're still one website click away from being pwned to oblivion, giving full control to the hacker – which, of course, is inevitable to an extent, since bugs always find their way into software.

So why not make it easy to disable?

Re: MacOS Catalina: Slow by Design?

#616

Earlier quoted context omitted.

I call this 'Outsourcing the cost of development to the user'... Getting knowledgeable people costs money so we build more abstractions that lower the cost of development and pass the costs of development from the company to the user in the form of requiring more hardware to do the same thing. How come I need 16Gb of RAM these days when 8Gb did it yesterday? How come my phone needs 4Gb of RAM while my 2012 tablet had…

What’s the point of cheaper disk and ram, and faster systems if not for supporting higher level abstractions?

To watch more, higher-def cat videos faster. No need to get lost in the weeds of higher level abstractions to do that.

Re: MacOS Catalina: Slow by Design?

#617

Earlier quoted context omitted.

It’s because Nix was designed to be part of the OS, as integral as apt is for Debian installations. The ability for it to live side by side with another packaging system is just a side-effect of how it was designed, not part of the original goals.

And NixOS is a great idea, but Nix advertises itself as "a powerful package manager for Linux and other Unix systems" in its the official site's description. Yet by not abiding to the FHS, they opened themselves up for breakage.

That’s an after the fact feature; my understanding is that the original design was intended to be the sole package manager on the system.

This is backed up by the fact that NixOS and Nix appear to have both been created at the same time; 2003.

Re: MacOS Catalina: Slow by Design?

#618

Earlier quoted context omitted.

I feel like people still have in mind what Linux desktop was 15 / 20 years ago. It improved a lot in the past years, battery life improved on laptops, Ubuntu that was already very stable and feature complete also got a lot of things with previous releases and I've personally been running Arch on my main computers now for 5+ years and haven't got any major issues while upgrading.

Try using the latest version of software that has a more frequent release cycle than arch. If you have an incompatibility there goes your install. Have yet to see a distro do multi monitor hi dipi that results in readable fonts out of the box.. This gets updated yearly - https://itvision.altervista.org/why.linux.is.not.ready.for.t...

This list is quite comprehensive, but also quite boring. It's just a list of bugs and things that are suboptimal on Linux. You could write one about any operating system. Some of the items like 'such-and-such needs to be configured using a text file' are also not even real problems.

What do you mean by 'there goes your install'? There are multiple ways you could run bleeding-edge software before it's packaged for Arch. See for example every 'xxx-git' package in the AUR. Or Flatpak.

Re: MacOS Catalina: Slow by Design?

#619
post #593

Earlier quoted context omitted.

Apple uses the same tools you do. They just might not be using it like you are; you can find a lot of features that clearly have no reason to exist outside of Apple nonetheless shipping with their software.

> Apple uses the same tools you do. No. A special directory can be created at the root of the file system called /AppleInternal. Then, if you work at Apple, you can put some special files there that do stuff. I've read somewhere that they are able to easily disable all of this privacy protection crap and other annoying stuff.

There's nothing really special about /AppleInternal, it's just a fairly normal directory that a couple of tools change in order to do things like offer more detailed diagnostics or the option to create a Radar. On a normal internal install there are some internal utilities, many of which are listed here: https://www.theiphonewiki.com/wiki/Category:Apple_Internal_A.... But their code is all Xcode projects and stuff, it's not like they're really using special tools for themselves except in certain cases. There are a couple of internal tools that possess entitlements to bypass security, but more often than not engineers just run with the security features disabled, which you can do yourself.
Post reply on HN