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.
MacOS Catalina: Slow by Design?
611–620 of 1001 posts
Re: MacOS Catalina: Slow by Design?
#612It 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…
Re: MacOS Catalina: Slow by Design?
#613The 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?
#614Earlier 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...
Re: MacOS Catalina: Slow by Design?
#615Earlier 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…
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?
#616Earlier 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?
Re: MacOS Catalina: Slow by Design?
#617Earlier 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.
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?
#618Earlier 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...
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?
#619Earlier 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.