Live data from Hacker News

MacOS Catalina: Slow by Design?

sigpipe.macromates.com

421–430 of 1001 posts

Re: MacOS Catalina: Slow by Design?

#421

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 is special about /nix that would make it better suited elsewhere? Aesthetic? Clutter? I don't think there are any technical reasons why the root of the filesystem is important. The /nix folder is just another folder with some ACLs/Permissions (however OSX works, idk)

Historically / has been reserved for the use of the Unix system (the distribution that packaged it, not the computer you're running on). Local programs were installed to /usr/local. Packages installing themselves in /packagename are making your root directory like Windows' Start Menu. Furthermore, if your, say, Physics department has 20 machines, your sysadmin would install everything on an NFS share, which probably got mounted at /opt. Your sysadmin definitely did not want to mount /this, /that, /theother.

So while /nix is no problem from the filesystem driver, it is completely flaunting established Unix norms.

Re: MacOS Catalina: Slow by Design?

#422
I don't think they do the notarization for shell scripts and program you build from source. I've been doing large scale software development on my Catalina for quite some time and I observed zero performance degradation compared to previous OS X version.

Re: MacOS Catalina: Slow by Design?

#423
post #307

Earlier quoted context omitted.

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.

Might want to look at Capture1 at this point.

The UI is way worse than either Aperture or Lightroom, but the editing is powerful, and you can download the full version for free if you have a Fuji or Sony camera, IIRC.

Re: MacOS Catalina: Slow by Design?

#424

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.

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

Re: MacOS Catalina: Slow by Design?

#425

Earlier quoted context omitted.

The Gatekeeper behavior is specific to running things from Finder (not Terminal), and only if you downloaded it via a browser that sets the com.apple.quarantine xattr. Two posts from Apple dev support (Cmd+F "eskimo") describe this in more detail. https://forums.developer.apple.com/thread/127709 https://forums.developer.apple.com/thread/127694

Quinn The Eskimo at Apple's forums is a 10x support engineer, his posts have helped me fix dozens of problems.

He needs to be, because Apple Developer Technical Support is chronically understaffed.

Re: MacOS Catalina: Slow by Design?

#426

Earlier quoted context omitted.

> Nix, by design, doesn't conform to the FHS way of organizing directories so it made perfect sense to use /nix when the decision was originally made. Refusing to conform to the FHS doesn't mean their decision made sense; refusing to conform to the FHS means they made a bad decision in the past and everything progressed from there. It doesn't 'seem that way now because some platforms have begun locking down their roo…

> creating arbitrary directories in / is a terrible idea, and has been at least since I started using UNIX/Linux systems in the 90's Why?

Because the root directory might be on a very small partition (perhaps only a few hundred megabytes), while other mount points like /usr might have more space; the only things which should be in / are the things which are necessary to mount the other filesystems (perhaps through the network using NFS).

(Yes, nowadays hard disks are much larger, we have things like initrd, and we now make /bin and /sbin symlinks to within /usr, but the parent comment did mention the 90s...)

Re: MacOS Catalina: Slow by Design?

#427

Earlier quoted context omitted.

Sometimes, but sometimes security measures lead to less privacy. Say, if executing local programs sends information to a remote server.

If that information can’t be used to identify anyone then it retains privacy while being secure. Being slow would still be an issue.

But you can't be 100% sure that the server where the information is sent is not putting in a database your IP, the app you run and whatever else. As a power user I would prefer a prompt before anything is sent.

Re: MacOS Catalina: Slow by Design?

#428
post #352

Earlier quoted context omitted.

There's just so many problems with that approach: 1. You have to create a separate volume just to install a package manager, which is a poor user experience 2. A separate volume means FileVault won't work out of the box 3. The volume can be mounted only after GUI apps are brought up 4. Restoring after sleep might fail because of 3 All of these are mentioned in the Github issue, but it might be hard to find because it…

1 — Sure. But Nix isn't exactly the most friendly package manager to begin with. I wouldn't recommend it if you're not comfortable creating volumes. 2 — Could you explain? Mine is on and working, I didn't need to do anything else. 3 — Is this if you have login items that need nix to be available? I don't have this so I haven't noticed. 4 — I've never run into this, but again I might just not use Nix for the kind of t…

It's not that installing Nix is impossible on macOS, it's just that it has some hard-to-ignore limitations now.

1. Having to create a volume when a plain old directory should suffice is insane. It's creating a hassle for no good reason for users.

2. /nix would be unencrypted by default if kept in a separate volume. There's also the problem of how to unlock it upon boot.

3. Login items is a very common use case so not supporting it would be problematic for many users.

4. Unreliable sleep is an even bigger problem.

Re: MacOS Catalina: Slow by Design?

#429

Earlier quoted context omitted.

> Nix, by design, doesn't conform to the FHS way of organizing directories so it made perfect sense to use /nix when the decision was originally made. Refusing to conform to the FHS doesn't mean their decision made sense; refusing to conform to the FHS means they made a bad decision in the past and everything progressed from there. It doesn't 'seem that way now because some platforms have begun locking down their roo…

> creating arbitrary directories in / is a terrible idea, and has been at least since I started using UNIX/Linux systems in the 90's Why?

Because the filesystem root is the domain of the OS, if tomorrow they decide they are going to create a symlink of /dev/null in /nix because they thought it sounded cooler as a way to "nix" stuff, there goes the Nix package manager.

The OS gives you places to put your files, use them so that you prevent breakage. We have the FHS, so you even have some degree of certainty of where to do it across Unixes.

EDIT: Two downvoted comments answering a "why" but no rebuttal to either. HN is slowly but surely becoming Reddit.

Re: MacOS Catalina: Slow by Design?

#430

Earlier quoted context omitted.

> I am so glad I decided years ago to leave closed operating systems behind. The problem is, there's nothing else out there. Everything is going to shit in one way or another. Windows is now a disaster, Linux was always a disaster in terms of user experience and isn't improving. Mac OS was the last bastion of somewhat good, thoughtful design, user experience and attention to detail and now they've gone to shit too.

If you add "unfixable" to "disaster" the problem becomes more clear. Windows is a unfixable disaster, you can't fix it sorry. Mac OS is now an unfixable disaster, you also can't fix it sorry. Linux may be a UX disaster, but you can, uniquely, modify it. You can change your UI. You can attempt to fix the problem, and have a real shot at doing so. Linux is the only one where you can do something about the problem - whi…

Not only can you modify Linux in theory, it is actually getting _easy_ to do so.

The biggest reason I enjoy elementary OS as a distro is that everything lives on GitHub, package releases happen through GitHub Actions, etc. Fixing a bug can be faster than merely filing a radar in the Apple ecosystem.

Post reply on HN