> instead of Apple’s irresponsible “you need a 3GB OS update even if the only fix is 3 lines of code in Safari..."
Your comment seems to be implying that Apple could simply ship the delta in the source code: i.e. something like `git diff --minimal --word-diff=porcelain head^1`. Would this not require iOS to be compiled on the device, and store its own source code, à la `.git`? How would you address the issue of the compiler itself needing to be updated as part of this process?
Or are you suggesting they would ship the diff for the binary? For one, I don't think the delta in the resulting binary would be as small as the delta in the source, due to addresses changing, etc. There are tools like bsdiff which can 'intelligently' handle this, but I believe they aren't widely used for operating system updates, as opposed to standard userspace binaries.
In addition to this, the diff shipped would be relative to whatever version the device is currently using, which would necessitate storing a very large number of diffs, especially for binaries, or else computing it on the fly (which simply shifts the burden from disk space to CPU cycles).
They're suggesting a patch in the classical sense of the term. A whole hog OS update does not qualify. These complications were addressed 20+ years ago when whole hog OS updates were unreasonable. It requires a certain amount of cleverness, but that may be too much to ask of the fruit company.
I understand the change would be a patch, but that's separate from the question of how you encode and ship it, surely? How are you suggesting a small patch would be shipped?
Yeah, I mentioned bsdiff in my original comment. I don't think Android uses it for operating system updates, though, as far as I can tell. I believe that page is describing APK updates (i.e. app updates).
In the simplest way, not unlike Windows Update: snapshot filesystem, start filesystem transaction, unzip changed binary files, check new files integrity, end transaction.
Indeed, Apple used to distribute patches this way in the past.
You also could ship a list of updated system files hashes, compare to the installed files and just download the changed ones, like rsync.
Better than shipping a whole new disk image every small update they do.
Yeah, I'm sure it's theoretically doable, but it's one of those things which would almost certainly require substantial work given the massively complex edifice of iOS. (And the iOS IPSW format, or even iOS DMGs/ADIs, are very different from the OS X patches you mentioned.)
It's cheaper to make things that aren't maintainable. We optimize for the dev, not the platform or the user.
It's the same lazy dev culture that gives us Electron apps, or the lazy sysadmin culture that gives us docker.
It's cheaper to create massive incomprehensible and unmaintainable edifice that requires massive storage / processor / network inefficiency to maintain versus well thought-out and "clever" systems that work efficiently.
Personally, I wish the days of optimizing for low-resource machines, slow network connections, and expensive storage weren't gone. As an end-user I think the results of moving away from a culture of optimization haven't been good. I think the ship has sailed, though.
Those are solved problems. Chrome has being doing binary diffs for years.
The reason Apple doesn’t is because they like to ship updates as bootable disk images. This makes it easier to roll back from than an in—place update, since you can just boot the old image if the update fails.
Your comment seems to be implying that Apple could simply ship the delta in the source code: i.e. something like `git diff --minimal --word-diff=porcelain head^1`. Would this not require iOS to be compiled on the device, and store its own source code, à la `.git`? How would you address the issue of the compiler itself needing to be updated as part of this process?
Or are you suggesting they would ship the diff for the binary? For one, I don't think the delta in the resulting binary would be as small as the delta in the source, due to addresses changing, etc. There are tools like bsdiff which can 'intelligently' handle this, but I believe they aren't widely used for operating system updates, as opposed to standard userspace binaries.
In addition to this, the diff shipped would be relative to whatever version the device is currently using, which would necessitate storing a very large number of diffs, especially for binaries, or else computing it on the fly (which simply shifts the burden from disk space to CPU cycles).
Or have I misunderstood you entirely?