Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Binary patching hasn't been a thing for years unfortunately.

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.



> binary diffs aren't worth the complexities they introduce anymore

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.


Yep, and they use Courgette for all of their Chrome/Chromium updates. It's why no one ever sees long "Downloading update..." progress bars in that browser anymore. 100KB binary diffs are typical. Blink (no pun intended) and you'd miss the download.


Result! Thank you.

Skimmed the landing page, original paper. Courgette infers program's structure for smarter diffing. My half-baked notion is somewhere in between.


Check out IntelliJ's binary patching - it might be closer to what you want? It's based on bsdiff.

The actual binary patching magic happens here: https://github.com/JetBrains/intellij-community/tree/master/...


Not a noob question... I don't know, but was assuming they were not worth the hassle from experience of using them, having lived through an era of binary diffs for old games where applying them seemed to be very computationally expensive at the time - sometimes to the point that it seemed faster to download a whole release, I assumed it was even more expensive to generate them - Those experiences may not be valid anymore in light of faster hardware or better algorithms, but the gains may also be too minimal when compared to highly granular packaging systems that various Linux distributions use these days.

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.


Definitely frustrating for anyone not on broadband. There are more of us than you'd think. It's a giant 'fuck you' from the software industry, real world efficiency be damned.


Totally agree. Updated to Catalina recently and on top of the huge patch size the update client doesn't seem to have any retry mechanism built in. Connection drops 9.9G into a 10G download? Too bad, start over. Just a simple wget -c would do. Incredible.


I wonder how many real word resources are wasted over this. It costs money to serve that data, it costs money to download that data, it congests the network wherever that data is being routed, it consumes energy however that is generated in the region.

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.


My personal monthly usage is in the 100G region; this particular failed update has cost me 20G of burned bandwidth. Where I live around 2% of the country doesn't have access to decent broadband. Since these updates are released every 2 months or so in a very back-of-the-envelope fashion failed updates amount to 0.2% of the country's total bandwidth usage. I might be an order of magnitude off but that is still an incredible waste.

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.


JetBrains still do updates with binary patching for many (all?) of their products, and the experience is really nice.


Yeah, it's awesome having regular < 100mb updates for their IDEs and Android Studio compared to 7+ GB Xcode downloads :(




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: