3 ms·

I’m curious to know why these updates have to be so large. There must be some clever way to send only the parts that need to updated, based on the users current

I’m curious to know why these updates have to be so large. There must be some clever way to send only the parts that need to updated, based on the users current version, no?

systoll 5y ago
They do somewhat do that. 2.93GB is for the delta update from 11.5.1. The full version, which doesn’t try to include only the parts that are needed, is 11.6GB. My understanding, however, is that it’s done on a per-file basis, and any update to a system library invalidates the dyld shared cache… which is a 2gB file all by itself.
- Lammy 5y ago
  It's quaint to think back on the Tiger days when the final 10.4.11 combo update weighed in at a "whopping" 180MB: https://support.apple.com/kb/DL170 https://support.apple.com/kb/DL170
- tinus_hn 5y ago
  But do you need to ship that?
- nly 5y ago
  Isn't that cache generated locally though, making it irrelevant to update size?
  - lucideer 5y ago
    It was in previous macOS versions but from Big Sur I believe much of the file's contents no longer exist locally as separate files
0xdeadb00f 5y ago
There _is_ a way to do it like that. In fact I swear MacOS used to actually do it that way. Microsoft definitely does.
- kccqzy 5y ago
  Yeah Apple used to use bsdiff by cperciva.
nickm12 5y ago
Ginormous update sizes are definitely a regression. There has been some reporting on this recently and I can't remember the details, but I believe it is due to a wanting a combination of: cryptographically verifiable updates; atomic updates (avoid the risk of a partial update); and shipping the dyld shared cache directly. These aren't insurmountable limitations, but it seems like Apple chose the path of implementing these in a simple way (at the expense of bandwidth and storage). One would assume they would want to then go ahead and figure out how to implement this with a slimmer delta update, but who knows.

I’m curious to know why these updates have to be so large. There must be some clever way to send only the parts that need to updated, based on the users current version, no?

systoll 5y ago

They do somewhat do that. 2.93GB is for the delta update from 11.5.1. The full version, which doesn’t try to include only the parts that are needed, is 11.6GB. My understanding, however, is that it’s done on a per-file basis, and any update to a system library invalidates the dyld shared cache… which is a 2gB file all by itself.

Lammy 5y ago
It's quaint to think back on the Tiger days when the final 10.4.11 combo update weighed in at a "whopping" 180MB: https://support.apple.com/kb/DL170 https://support.apple.com/kb/DL170
tinus_hn 5y ago
But do you need to ship that?
nly 5y ago
Isn't that cache generated locally though, making it irrelevant to update size?
- lucideer 5y ago
  It was in previous macOS versions but from Big Sur I believe much of the file's contents no longer exist locally as separate files

0xdeadb00f 5y ago

There _is_ a way to do it like that. In fact I swear MacOS used to actually do it that way. Microsoft definitely does.

kccqzy 5y ago
Yeah Apple used to use bsdiff by cperciva.

nickm12 5y ago

Ginormous update sizes are definitely a regression. There has been some reporting on this recently and I can't remember the details, but I believe it is due to a wanting a combination of: cryptographically verifiable updates; atomic updates (avoid the risk of a partial update); and shipping the dyld shared cache directly. These aren't insurmountable limitations, but it seems like Apple chose the path of implementing these in a simple way (at the expense of bandwidth and storage). One would assume they would want to then go ahead and figure out how to implement this with a slimmer delta update, but who knows.