3 ms·
Interesting. I wonder if this can also be [ab]used to, say, deliver deltas of programs, so that you can have faster updates, but maybe it doesn't make sense. h
by henvic 5y ago
Interesting. I wonder if this can also be [ab]used to, say, deliver deltas of programs, so that you can have faster updates, but maybe it doesn't make sense.
https://en.wikipedia.org/wiki/Binary_delta_compression https://en.wikipedia.org/wiki/Binary_delta_compression
- peterwaller-arm 5y agoAuthor here, I don't think it would apply well to that scenario. elfshaker is good for manyclangs where we ship 2,000 revisions in one file (pack), so the cost of individual revision is amortized. If one build of llvm+clang costs you some ~400 MiB; a single elfshaker pack containing 2,000 builds has an amortized cost of around 40kiB/build. But this amazing win is only happening because you are shipping 2,000 builds at once. If you wanted to ship a single delta, you can't compress against all the other builds.
- necovek 5y agoHow fast would it be to get a delta between any two of the 2,000 builds in a single elfshaker pack? If that's reasonably fast, perhaps an approach like that could work: server stores the entire pack, but upon user request extracts a delta between user's version and target binary. Still, the devil is in the details of building all revisions of all software a single distribution has.
- peterwaller-arm 5y agoYes you could do that. On the other hand, all revisions for a month is 100MiB, and all revisions we've built spanning 2019-now are a total of 2.8GiB, so we opted to forego implementing any object negotiation and just say 'you have to download the 100MiB for the month to access it'. I think you could a push/pull protocol could be implemented, but at that point probably git might do a reasonable job in that case :)
- henvic 5y agoThank you for the insight!
- tedunangst 5y agoThis is how openbsd binary patches for the kernel work. The changed object files are shipped; the end system relinks a new kernel.