> I can't even begin to imagine what can weigh in at 845 MB for a bug/security release

Changing a few compiler flags, say to enable a hardened stack, or a compiler update that fixes a bug in such a feature probably could do that.

It could mean lots of tiny changes sprinkled throughout the code that the patching algorithm can’t compress efficiently.

Back in the macOS classic days, I would use ResCompare to make patches to my app. The resulting exe was a few kB ("It's one patch Michael, how many megabytes could it be?")

I can't even begin to understand what's going on these days, but I'm sure there's an explanation.

I think the OS is written to some kind of read only partition, and so they are having to write the whole thing each change? It's also why safari updates need reboots these days, isn't it?

How do you write it if it’s readonly?

Whether or not the system partition is mounted readonly for daily use doesn't have anything to do with the update size.

It's protected by T2, the reboot disables the system security protection (SSP) temporarily in the T2, which then allows the OS partition to be written to, then it re-enables SSP and reboots. Only 'special' signed code can enable the update mode.

The usual explanation is "the engineers don't care and want to get on with the next ticket or lunch".

See the person above you showing that attitude.

Come on dude. You got a scrolling desktop background. What more do you want in life?

I‘m guessing they completely re-shipped Safari and related components in that update. That’s where an actively exploited 0-day has been fixed. Wouldn‘t surprise me for Safari and some system components to be that size.

Well it seems to have made the Finder worse for me, so there's that. And, yeah, it's not particularly quick to install (M2 Pro, 512GB SSD).

I hope Apple can stop faffing about with new whiz bang features for a few iterations and instead focus on working down the ridiculous list of bugs in Sonoma. Somehow they've managed to utterly fuck up application switching, the mind boggles.

Edit since I'm being throttled:

I wholeheartedly agree (and I'm sure I've commented to this effect on HN before): this is probably the nicest Apple laptop I've laid my hands on and nearly the worst version of MacOS I've seen in three decades. I really like the 14" pro form factor. Thankfully I have until January to decide if I want to keep the laptop.

Keyboard focus does not reliably follow you to the new foreground application. I saw this mentioned in the comments in the Ars review but it seems to be worse for me than that guy.

Finder does not reliably display a progress indicator when copying big files, and quick look is as unreliable as ever.

AFP support is completely broken. Apple should just rip that code out instead of letting it rot like that. It's particularly frustrating because Apple dropped support for the version of SMB where Samba "properly" supported unix-y permissions.

SMB support worked for a while in the Finder, but would corrupt metadata from the command line. With 14.1.2 it seems like creating/modifying files on an SMB share from the Finder is as unreliable as the command line.

AFP not working was bothering me after updating to 14.1(.1). I have a Mavericks machine around (I know, it's old) that I was reliably copying files to/from until that update -- along with Apple Remote Desktop -- broke and I just couldn't see the Sonoma machine from any other Mac (Mojave couldn't see it either).

I figured out that by turning off File Sharing / Remote Management / etc on the Sonoma machine and turning them back on, it fixed it. Hope this helps.

So the AFP failure mode I saw was that I could list a directory or two and then the finder would hang and eventually the connection would just drop. Apple's been nudging people to SMB for a while now so I'm kinda tempted to stay with Samba.

Except for the whole SMB data corruption thing that's apparently been a problem since Ventura.

"Apple Inc. hit pause on development of next year’s software updates for the iPhone, iPad, Mac and other devices so that it could root out glitches in the code." [1]

[1]: https://www.bloomberg.com/news/articles/2023-11-07/apple-del...

It was a one-week pause because the state of the new features wasn't good enough to pass a milestone. It does not signal a change of policy.

I wish they could spend time to figure out how to build software at a sustainable pace instead of stopping every few years to fix everything.

One week is not enough time to fix anything significant.

The keyboard focus. I thought my keyboard went bad or something was stealing my keyboard inputs when switching apps. Has there been any explanation why this is happening? Could you please link the Ars article?

Fully agree. I started to install the newest iOS & MacOS releases just before the next major version is being released. I'm always one version behind but kinda works well this way.

plus the fact that exFAT read/write is cripplingly slow, a MacOS bug for years and years now.

Its just funny that Macs have some of the best hardware in laptops out there (for now), but utterly crippled by the locked down OS.

Apparently, and I can't remember where I read this, they're working on cleaning up the bugs now. There are a few nasty ones but I seem to be the guy who manages to walk through the field of landmines at the moment and not step on any.

They are not working on that. There was big news going around that they paused work on new features to work on bugs for all of ... 1 week.

Like what? Haven't seen anything fishy in either Finder or application switching.

Apple is historically pretty bad at managing differential updates (including apps) so it's probably mostly a few files changed and the re-download a good portion of the OS.