I was actually getting a mac mini now that I'm working from home (I thought I'd get better integration with some of the company's wfh infrastructure while still having a unixy environment, so a win/win situation), but I cancelled the purchase after reading this. I get that you can jump some hoops and set some apple specific flags to things so that it works better, but the reason I wanted a mac was to make things easier and not having to look into obscure APIs and features to get simple things working. I was really looking forward to that, but I don't feel that sort of investment will be justified with issues like this in their OS :/
It mentions that anyone with an apple developer ID can notarize a qualifying app and submit this notary to the Apple Notary Service. However, the proof of notarization—the notarization ticket—might not be stapled to the application.
In the case of no stapled ticket, Catalina contacts the notary service to see whether a ticket exists. If so, the app is good to go.
EDIT. More informative link here. It specifically outlines what happens on first run of an app. (and there's a great diagram if you scroll down)
But alas the 1000s of engineers gotta be put to work somehow.
It’s indeed a huge mess, from a privacy standpoint too, not just a performance one. It’s sad also to lose things like AirPlay or iMessage as collateral damage in the process. :/
I just can’t tolerate a machine that hits the network hundreds of times a day when doing normal computing tasks that do not involve the network. They even tolerate this sort of spyware in App Store apps, too.
Is it too much to ask for a polished workstation OS that lets me boot and edit a local text file of notes and save and quit without notifying 4 different parties that I did so?
running just firefox and terminal, ps -ef|wc -l is 198
and many of them have no reason to be on my system.
I think it just skips the checks if internet isn't available. But doesn't that kind of defeats the point of notarization?
EDIT: how to staple: https://developer.apple.com/documentation/xcode/notarizing_m...
It waits 5 seconds while trying to connect, and then it gives up and caches the program as un-notarized, allowing it to run faster on later executions.
Notice that notarization seems to be disabled if the network is disabled from within the OS. To observe the 5 second delay you need to cut the connection outside (e.g., on your router), while the mac still thinks it is connected. I observed it by running catalina inside a virtualbox, and disabling its network.
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<Int8>?) pairs, and getting results out by passing (length:UnsafeMutablePointer<UInt32>?, data:UnsafeMutablePointer<UnsafeMutableRawPointer?>?) 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.
echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && \
chmod a+x /tmp/test.sh && \
time /tmp/test.sh && \
time /tmp/test.sh && \
echo 'echo Hello2' >> /tmp/test.sh && \
f=$(mktemp) && \
echo $'#!/bin/sh\necho Hello' > $f && \
chmod a+x $f && \
time $f && \
time $f && \
echo 'echo Hello2' >> $f && \
Setting Terminal as a Developer Tool in Security&Privacy fixed it
Yes, they have polished the GUI, which makes it easy to navigate by mouse. But, when you need to work in speed mode, then you reach for the keyboard shortcuts.
The problem, is that there are plenty, too much sometimes, and they are often inconsistent between applications.
And yes, the Mac has a keyboard shortcut assignment tool, but it often doesn’t work correctly.
I must give credit to Microsoft here. They at least seemed to have perfected most of the common keyboard shortcuts.
Some good features about Windows shortcuts.
1. Alt-Spacebar to open the windows control menu, to move, minimize, maximize, or close the window.
2. Alt combinations are used to control the active Window application itself.
3. Alt-F4 to close the window. But, I would have preferred Alt-Escape instead, to close the window.
4. Control key for shortcuts inside the application. Like, Ctrl-C for copy. O for open. P for print. Etc.
5. Then the Windows key, to control Operating System level shortcuts. Like Win-M to minimize all windows. Win-L to lock the computer. Win-R to launch a command.
Some feature I would like are to use, Win-Spacebar to open a command search, similar to Win-R, but with the ability to list all possible commands. Similar to activating the command palette on VSCode.
And Ctrl-Spacebar, to activate keyboard commands for the active window. Kinda like Emacs, where I can run macros on it, like highlighting the words that I want, and execute something on it, like changing to uppercase, or converting to comma separated, or whatever else is needed.
I'm currently trying to figure out how to emulate windows from a *nix distribution using qemu. I plan to use this as a "home lab" (k8s cluster or just plain fucking around), but still retain the ability to play an occasional AAA game.
This just makes me wanna start using it for more things besides dev work :(
It'll be interesting to see how much power we developers will let Apple take from us before we jump the garden wall.
I am pretty sure the laptop market has been shrinking generally (as more people have a phone but no laptop). And most developers I know have macs. They probably don't want to make the OS significantly worse for developers...
Definitely agree on this one here - I've noticed a big speed improvement when disabling SIP debugging with "csrutil enable --without debug" while in recovery mode.
I should note that the main reason I disable SIP isn't for speed, but to install the yabai window manager to make Aqua far more useful as a developer. I wrote a recent blog post on this, actually (https://triosdevelopers.com/jason.eckert/blog/Entries/2020/5...).
WTAF. If this is really true, this is a reason for me to leave the platform for good. This is just in-acceptable in so many ways.
Wow, this is extremely infuriating! I just ran the "hello world" test script with the network connection disabled and it took 5 seconds to run!
$ echo $'#!/bin/sh\necho Hello' > /tmp/test.sh && chmod a+x /tmp/test.sh
$ time /tmp/test.sh && time /tmp/test.sh
/tmp/test.sh 0.00s user 0.00s system 0% cpu 4.991 total
/tmp/test.sh 0.00s user 0.00s system 77% cpu 0.005 total
There are a bunch of people who can't reproduce the slowness at all, but nearly all downvoted or you have to wade through 100's of comments to get to them.
The majority of comments are just dumping on Macs, nothing whatsoever to do with the content of the article, and seem to be blindly assuming it's true.
And I can't seem to find any substantive discussion of whether this is actually real or not, or just some weird bug on the author's machine.
I don't see any evidence that Catalina is "slow by design", just a single anecdote from the author. I was definitely hoping for some more substantive critique/discussion...
The down votes are because it seems pretty clear that the people who don't experience have long lived instances of their os and likely have grandfathered or disabled security settings. There are a lot of people saying ita pretty easy to replicate with a new os.
And it is, I just did it. Did you?
I don't know what the bug report said, or what specifically was by design. Surely "the entire machine freeze for 1-2 seconds every 10th minute, not to mention everything just being sluggish" is not by design.
And I was unable to replicate it (I was one of the comments that got downvoted), although I don't have the luxury of trying a fresh OS. I haven't disabled any security settings, and I don't know what would have been grandfathered -- that's not mentioned anywhere in the article as a factor.
So that's what's bothering me -- the assumption that contradictory evidence isn't valid while the original post somehow is, and no discussion around that, or what tradeoffs there might be.
Now, finally, there are actually some substantive comments from people testing it. There wasn't before though, and it's still unclear as to whether this really is bad design, a wise tradeoff, or if the author's machine has something else going on. Because their experience of a frustratingly slow Mac is just not the norm at all.
That's why I wrote this new comment, in the hopes that maybe it would be seen.
It's possible that they have certain security features disabled.
> The majority of comments are just dumping on Macs, nothing whatsoever to do with the content of the article, and seem to be blindly assuming it's true.
Welcome to Hacker News…this is common on any discussion on any topic, especially one that many people can understand in some way.
I recently took the trouble to completely wipe the disk and reinstall macos mojave and it's still happening so it's not due to cruft installed over time in OSX. I dunno. I'll deal with it until it gives up the ghost and probably move to a windows machine with the work they're putting into WSL2
The problem was: Parental Control. Apparently, every request was checked and thus slowed the whole thing down. Needless to say, a couple days at least were wasted in this.
I do wonder if the author has something similar going on, either with a directly attached disk or a network share.
There's a lot of bullshit on Windows too but nothing near OSX levels of wannabe big brother shit.
Can't think of a better long term short right now in the market than Apple (and sister cult Tesla but the electric story is at least in the early days so they may do ok)
They're not implemented in a braindead way that's being discussed here but they're at the same level big brotherness-wise, if not worse.
I run the commands and get:
/tmp/test.sh 0.00s user 0.00s system 8% cpu 0.045 total
/tmp/test.sh 0.00s user 0.00s system 75% cpu 0.005 total
The only delay that's ever noticeable is when running a program I've installed for the first time, which yes usually seems to take a few seconds, before often telling me the application couldn't be verified or something, do I want to run it anyways. Which makes sense if you're running a checksum on a 400 MB application binary. But after that first time, starting an app is always instant.
Can anyone else elucidate what the author is talking about? They're presenting it as a universal, but maybe there's something else going on with their machine? Clearly something's wrong on their end, but possibly it's just some kind of bug. I'd avoid jumping to conclusions that executables taking a second to launch is "by design".
EDIT: switching from zsh to sh gives more granular results:
So it's real.
However, scripts are NOT notarised, so what is it doing?
So after digging the scripts are being "checked" for malware, as part of XProtect.
This is interesting, it seems to be hashing scripts and testing to see if its known malware.
Anyway, easy to disable, but weird stuff.
Still no idea what or why the panics would happen, or why the reinstall solved it.
Catalina has been a very bumpy road for me so far.
Who at apple thought it was a good idea to hop on the internet when invoking an application without any warning? This is loony.
Whatever problem you're having, it's a problem specific to your machine.
A few months ago I installed Rider (an IntelliJ-based IDE) on my Mac without toolbox, and upgrading it was a pain. I don't remember the details, but using JetBrains toolbox makes upgrading as simple as clicking a button and waiting until the download / install is complete.
Why does it need the internet all the time?
Are they checking if the app is dangerous? Are they logging all my activity?
I wonder if that defeats the phone home that this article is highlighting.
I clearly won't switch to their system anytime soon...
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.
Apple is the Father, Apple is the Mother.
After Apple has re-invented or re-written the MSFT playbook of the 90s, nothing surprises me anymore.
Yet I cling to these machines, that take away the freedom to do with my hardware as I please. It's odd.
The first computers I ran OS X on were a Pismo Powerbook and one of the first iMacs. Both with upgraded hard drives and maxed out RAM. They were almost unusable, and we'd put classic OS back on them, a new release of OS X would come out, and repeat.
I later got a chance to use a shiny new G5. I couldn't believe how slow it felt. Same goes for the PowerBook G4. The first Intel MacBook Pro didn't feel any faster.
Somewhere around the i5, Mac OS started to feel 'okay'. But I'd always still feel blown away at how fast a similar machine felt running Windows or Linux.
But I've stuck with it ever since 2010. I remember talking about my 16", saying "It's really fast...for a Mac."
Yes these features could be better implemented, but I'm happy they're there. It's very important to be able to opt out of them, but I like that they're the default.
Notarization needs a cleanup pass and the rest of it seems like it needs an optimization pass.
P.S. The rationale for notarization is to not distribute and thus advertise the filters and detection mechanisms Apple uses to detect malware. If these things were distributed then malware authors could analyze and evade them. Security through obscurity does make a certain amount of sense here as the Church-Turing thesis means there are an infinite number of ways to implement any given thing including malware and there is no single filter or analytical step that can detect all possible malware permutations.
That's true (or else there are 0 ways), but it's not what the Church–Turing thesis says.