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

511–520 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#511

Post by catalogia »

kick wrote: post #358
zozbot234 wrote: post #196

Earlier quoted context omitted.

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.)

Debian is not just as quick (significantly slower and higher resource usage), but Arch isn't all that fast nowadays, either.

> Debian is not just as quick (significantly slower and higher resource usage)

In which respects? Are you talking about apt vs pacman or something? Default DEs?

Re: MacOS Catalina: Slow by Design?

#512

Post by kempbellt »

catalogia wrote: post #468
kempbellt wrote: post #378

Earlier quoted context omitted.

If you truly want to be "cross-platform" with long-term future proofing in mind, `/nix` is (edit: was) probably the most stable choice. I get it, people are sensitive about the root directory. "But it's where ALL the stuff lives!". So yeah, try not to ever run 'rm -rf /' (even though this is blocked in most cases now). But why make it completely inaccessible for creating files/directories in? So much hand-holding for…

If you have to `mkdir /nix` , what's wrong with `mkdir -p /opt/nix` ? I don't see how one is "more stable" than the other. The big difference between the two is the later conforms to convention while the former doesn't.

`mkdir -p /opt/nix` assumes that there is a convention, and that this is the correct convention - which may not be the case for every situation, and would result in creating unnecessary nested directories.

You could make a more sophisticated installation script that attempts to install Nix into conventional locations depending on the specific operating system - or user input - but if you want a simple catch-all, simple installation script `/nix` was a perfect cross-platform installation location, until now.

Re: MacOS Catalina: Slow by Design?

#513

Post by blondin »

kar1181 wrote: post #27

I completely understand why things are going the way they are as our computing environment has become ever more hostile. But I am very nostalgic for the time where I would power up a Vic-20 and within seconds be able to get to work. Teaching my daughter to program on a modern computer, we spend more time bootstrapping and in process, than we do in actual development.

> I completely understand why things are going the way they are as our computing environment has become ever more hostile.

care to elaborate a bit? what did you understand?

i just can't get my head around this idea that most non-mobile OSes have become such hostile environments...

yes, the population at large only uses their phones and tablets and doesn't care much. but they would be left without any entertainment if it wasn't for those of us who still need decent non-mobile environments.

Re: MacOS Catalina: Slow by Design?

#514

Post by ryanianian »

pulisse wrote: post #424
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.

> Brew never had this problem because they chose a sane path How so? Taking over /usr/local as Homebrew does is guaranteed to cause conflict. Using a dedicated file hierarchy as Nix does is quite reasonable and there's nothing magical about rooting it at /.

How does it "take over" /usr/local? You can still `./configure --prefix=/usr/local` on your own software and things continue to work as long as you're not installing the same thing that brew is.

Re: MacOS Catalina: Slow by Design?

#515

Post by sergeykish »

konart wrote: post #235
PKop wrote: post #192

Earlier quoted context omitted.

Switched from macOS this year having used it for about 8 years to first PoP_OS and now Manjaro. Both were great (GNOME environments) and very productive for both development and general use. I really like the streamlined, "get out of your way" UI. I would say go for it, I'm glad to not be dealing with any of this nonsense, while paying a premium for it.

I've seen both of them, but the "get out of your way" UI is a limited feature. Apps are still do not respect the rest of it. You install this new distro (like Elementary if it's still alive) and fall in love with the new Finder clone. But then you install twitter client, torrent client and a dozen of other everyday apps. And they all look terrible. And feel even worse. People still don't care. As much as I hate certa…

Yes, UI consistent mostly in terminal and chromeless applications. Really shows how bad alternative OSes are.

Seriously though with i3, beautiful fonts, so much in the browser it's not bad.

Re: MacOS Catalina: Slow by Design?

#517

Post by cauthon »

soraminazuki wrote: post #483
mixedCase wrote: post #432

Earlier quoted context omitted.

I'm probably missing something, and please let me know if so and why, but it sounds like a chroot could solve path reproducibility.

Nix requires that each package only writes to a dedicated directory in /nix/store. For example, files for Firefox 33.1 package would go into /nix/store/b6gvzjyb2pg0kjfwrjmg1vfhh54ad73z-firefox-33.1. By not dumping files from every package in a common directory such as /usr, it requires each package to be explicit with its dependencies. This allows for many nice things explained elsewhere (e.g., https://nixos.org/nix/…

I still don't understand why that can't be solved by putting everything in /opt/nix/store

Re: MacOS Catalina: Slow by Design?

#518

Post by twhb »

I tested whether running a script you just wrote really contacts Apple to “notarize” it. It does.

I first used the author’s timing method. First runs are consistently about 300 ms, subsequent runs consistently about 3 ms. Something is happening at first run.

Some in the comments are saying it’s “local stuff”, so I tested timing again with internet off. First runs go to about 30 ms, subsequent remain the same. So there is “local stuff”, but it doesn’t explain the delay.

Just to be entirely sure, I installed Little Snitch and got clear confirmation: running a script you just wrote results in syspolicyd connecting to api.apple-cloudkit.com. syspolicyd is the Gatekeeper daemon.

I don’t know what exactly is being sent. Maybe somebody else can do a proper packet analysis.

Re: MacOS Catalina: Slow by Design?

#519

Post by sneak »

LeoPanthera wrote: post #392
xenadu02 wrote: post #103

Earlier quoted context omitted.

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…

Putting Terminal (and your favorite text editor) in this category and in "Full Disk Access" will change your life.

Yes, falling victim to ransomware is definitely lifechanging if you don’t have good backups.

Re: MacOS Catalina: Slow by Design?

#520

Post by lostgame »

lol768 wrote: post #9
marcinzm wrote: post #3

If Microsoft wasn't doing ever worse privacy things with Windows I'd seriously look into switching away from Mac OS given the ever growing issues it's been having with every release.

The set of possible operating systems to consider does not contain two items.

Without WINE, and it’s associated instability, which operating system, other than MacOS or Windows, would run Ableton, Logic Pro, Adobe Premiere, or Final Cut Pro, all applications I depend on for my income and, due to the fact that my clients use this software, for which an FOSS equivalent or alternative doesn’t exist?

Now imagine the millions of other people in my situation and rethink your comment.

Post reply on HN