Even bigger wreck on consoles these days, where an update can be 50+ gigabytes...
Even bigger wreck on consoles these days, where an update can be 50+ gigabytes...
https://www.chromium.org/developers/design-documents/softwar...
True, and it's fair to say binary diffs aren't worth the complexities they introduce anymore, yet the concept of only pulling updates for individual packages has been a thing for over two decades in the *nix world. It seems like a poor choice for Apple to not bother making updates more discerning while also removing binary diffs... certainly a shitty move for anyone without a 99th percentile internet connection - then again everyone outside of that group probably can't afford Apple products anyway.
For some perspective: 3.6 GiB is significantly larger than the downloads required to install my entire OS from scratch, and 36 times larger than my average weekly run of apt.
From my now outdated experience on Mac OS i'm aware they do divide things into installer packages with some kind of receipt for version info that software update probably probes. So I guess it must be that these packages are not very granular.
Windows Update does this too, if the transfer fails it starts from zero. Multiply this by... what, a couple million times for each update?
I assume they run the numbers and it's cheaper to just dump all the data and run things inefficiently, compared to having teams deploy it correctly. It's just a waste though, and it pisses off your customers.
Maybe they did run the numbers, but the amount of engineering effort required to fix it is absolutely minimal (couple of lines...). A significantly worse outcome for society as a whole at the cost of a try-catch block.
Noob question: Why are binary diffs impractical?
Is it because the (compiled) object code layout dances around too much? If true, isn't that fixable? Meaning: make the order more stable, to minimize the size of the diffs?
I recall a recent story/post about boosting runtime performance by optimizing object code layout. Sorry, I can't refind that article.
If true, couldn't the internals of released code be "sorted" to better enable binary diffings? Maybe the layout optimizer step would minimize the variability enough without requiring a resort.
A fun experiment would be to take a series of releases, run that layout optimizer, and then try the binary diffing again.
--
Didn't Google publish some research, maybe 10 years back, about better binary diffing for publishing updates? Apologies, but I sorta assumed it had become the norm.
Skimmed the landing page, original paper. Courgette infers program's structure for smarter diffing. My half-baked notion is somewhere in between.
The actual binary patching magic happens here: https://github.com/JetBrains/intellij-community/tree/master/...
Sibling comment RE chrome is an interesting one, I can imagine in the specific case of very large and frequently updated binaries like chrome it would still be beneficial to use binary patching.
PS4 updates are notably bad, since they do a full copy & write (vs write-in-place) on patches. It's good if there's an issue on updating, since you can delete the partially-updated copy and start over, but bad because it requires more than 2x the disk space for the patch.
Patching all of that is difficult to it is probably easier to replace the content streams in one go.