I'm curious if anybody has used this for their own systems and if the savings were substantial. Fedora used something seemingly equivalent (deltarpms) by default in dnf until last year[1] and the rationale for removing it seemed to be based at least in part on the idea that the savings were not substantial enough.
Well, like everything else: Is bandwidth your primary problem, or is CPU? Whenever I run apt now, download time is nearly nil but installation time is forever. Increasing installation time (and complexity, and disk space and cacheability on the mirrors) for saving some download time is unlikely to be a good tradeoff. Of course, if you are stuck with severely metered 2G somewhere in the woods, you may very well think differently. :-)
Similarly, I've turned off pdiffs everywhere; it just isn't worth it.
It plays well with the Debian reproducible builds stuff to weed out as much non-essential variation as possible.
For certain packages, I'm guessing the byte-savings could be near-infinite. Already programs are encouraged to ship `foo` (potentially arch dependent) and `foo-data`, but imagine updating "just one font" in a blob of fonts, and not having to re-download _all_ other fonts in the package.
For some interpreted-language packages, these deltas would be nearly as efficient as `git` diffs. `M-somefile.js`, A-new file.js` and just modify the build timestamps on the rest...
The answer to your question should be relatively straightforward: just run it on a base/default major version upgrade and see how many MB of files have the same `md5` between releases?
It could have really nice observability properties if the delta is transparent and you can see what is flowing by. In this regard, the space savings would be a nice side effect.
I've used this, I think it depends on what speed the connection to your Debian mirror is. It and the apt meta-data diffs definitely helped when I had slower Internet.
IIRC Google does something similar for Chrome browser updates.
I'm curious if anybody has used this for their own systems and if the savings were substantial. Fedora used something seemingly equivalent (deltarpms) by default in dnf until last year[1] and the rationale for removing it seemed to be based at least in part on the idea that the savings were not substantial enough.
[1] https://fedoraproject.org/wiki/Changes/Drop_Delta_RPMs
Well, like everything else: Is bandwidth your primary problem, or is CPU? Whenever I run apt now, download time is nearly nil but installation time is forever. Increasing installation time (and complexity, and disk space and cacheability on the mirrors) for saving some download time is unlikely to be a good tradeoff. Of course, if you are stuck with severely metered 2G somewhere in the woods, you may very well think differently. :-)
Similarly, I've turned off pdiffs everywhere; it just isn't worth it.
It plays well with the Debian reproducible builds stuff to weed out as much non-essential variation as possible.
For certain packages, I'm guessing the byte-savings could be near-infinite. Already programs are encouraged to ship `foo` (potentially arch dependent) and `foo-data`, but imagine updating "just one font" in a blob of fonts, and not having to re-download _all_ other fonts in the package.
For some interpreted-language packages, these deltas would be nearly as efficient as `git` diffs. `M-somefile.js`, A-new file.js` and just modify the build timestamps on the rest...
The answer to your question should be relatively straightforward: just run it on a base/default major version upgrade and see how many MB of files have the same `md5` between releases?
It could have really nice observability properties if the delta is transparent and you can see what is flowing by. In this regard, the space savings would be a nice side effect.
I've used this, I think it depends on what speed the connection to your Debian mirror is. It and the apt meta-data diffs definitely helped when I had slower Internet.
IIRC Google does something similar for Chrome browser updates.