Hacker News Reader

Comment by icedchai | Hacker News Reader

Does anyone know why macOS updates seemingly take forever? Even on the fastest Macs available, they are slow.

IIRC you're replacing the whole OS inage on every update now.

Also, their edge caches are awefully throttled on large downloads if your ISP has one installed. The Akamai CDN performs a lot better. I ended up switching DNS servers just for this.

http://test.edge.apple/debug/

If you have more than one Mac or iOS device I'd suggest setting up one of your Mac with content cache enabled.

The actual download is never a problem for me. It maxes out my downstream every time.

The install itself always takes 20 to 30 minutes or so.

APFS can't do incremental updates, they need to always replace the whole snapshot

I won't give exact technical reasons, but each update since APFS was made default is few GBs

From a purely anecdotal perspective, I've noticed a vast decrease in the performance of the macOS updaters/installers since the point when they switched to using what is essentially the iOS mechanism for them, with the MobileAsset UpdateBrain stuff, and .ipsw files, and chunked pbzx archives nested inside zip archives nested inside xar archives. I don't remember the details of the previous system, but I remember it seeming a lot simpler, a lot less buggy, and certainly a lot faster on my hardware.

The "brain" to which it refers (on x64 machines) basically is an iOS device (running a variant called bridgeOS) on an ARM coprocessor (T2) inside your computer. Same secure boot, same TSS signatures, etc.

It has to update two OSes now, not just one.

Even the new studio display is an iOS device and also takes forever to update.

I recently got a Studio Display and its updates seem relatively fast (at least compared to the Mac itself!)

I’m still kind of confused why they don’t have a a/b update system for macOS now that Sealed System Volume is a thing. I feel like one of the major benefits of that would be that you can swap /System out and not worry about losing any user state, so why can’t they just download a new System volume, put it somewhere else (while you’re using your computer), then on reboot boot from the new one and throw away the old one? If you disable SSV then they can use the slow update process.

(Unless there’s too many system files that are updated a lot and not sealed?)

I'm trying to think how you could reliably, securely hash one volume while running a potentially untrusted system from another volume. I imagine this can be done, but I'd be guessing as to how. For now, I suspect Apple has thought this through and has determined that booting the system into a known-cryptographically-clean state is the best method at hand for reducing the risk of a compromise/failure in the process of signing the system volume.

FWIW, APFS snapshots do at least provide an instant rollback mechanism, whereby a failure to install and sign the updates to the new temporary snapshot do not destroy the previous system. So what you describe seems reasonable and potentially feasible.

It is not just macOS update either.

It is an unpopular opinion on HN but I have been saying this for quite some time. The old days we were optimising for file size and transfer speed. Making sure you get a smaller download size ( compressed ). That was when Bandwidth were expensive, both in Datacentre and in consumer last mile. Nowadays we have abundance of capacity and we get 100Mbos if not 1Gbps internet, the actual download happens in the background. We should be optimising for total installation time over bandwidth savings.

I wish they optimized for a 2.5 years old computer not being slow as hell. I remember getting my first MacBook in 2013 and it was snappy. I bet they assume a given size of L2 cache and every non-top-notch processor must paginate like crazy.

macOS is sluggish, now, even on day #1 of a purchase.

I agree, but at this point, if it's not Apple Silicon, it's obsolete.

Incremental updates does not work on macOS, that's why

Reply on news.ycombinator.com