5 ms·

Why would they transfer the entire 1.5g binary each time, and not a delta? Surely it doesn't change that much between releases.

monatron 15y ago
further on in the article they explain that facebook is developing a hip hop virtual machine that allows them to run custom bytecode in their own runtime environment which would allow them to push deltas. im fairly certain that pushing deltas of compiled c++ code on this scale is impossible.
shabble 15y ago
I wonder whether they've considered (something similar to) Google Courgette[1], for distributing compiled binaries with many similarities, but translating into abstract basic blocks and rewriting pointers to match. Although, both the generation of the diff-set, and it's application on each individual server might end up eating more resources than just using torrents. [1] http://dev.chromium.org/developers/design-documents/software-updates-courgette http://dev.chromium.org/developers/design-documents/software...
tedunangst 15y ago
"bsdiff is quite memory-hungry. It requires max(17n,9n+m)+O(1) bytes of memory, where n is the size of the old file and m is the size of the new file." http://www.daemonology.net/bsdiff/ http://www.daemonology.net/bsdiff/
jrockway 15y ago
Because the continuous integration runs tests for all components at HEAD, not at every random possible combination that could end up on a machine. The key to releases is repeatability and consistency. Copying one big blob to every machine is repeatable and consistent. Installing a bunch of libraries and updating things piecemeal is much more difficult to do right. Internal bandwidth is cheap, so this is almost a no-brainer. Even without an internal bittorrent distribution mechanism, it's still easy. The reason why people tend to gravitate to incremental deployments for web applications is because the typical tools encourage it; modules get installed in separate directories, each part of the app is a separate file (back in the CGI days), etc. When you compile everything into one file, though, then you just copy that file around to deploy. It's easier. (Ask a PHP programmer how to change one file, and it will probably be "change that one file". Ask a Java programmer, and it will be "fix the file, build a WAR, and replace the WAR". Tools dictate process, and the "scripting language" default is to work on a file level instead of an application level.) I've always wanted one-file deployment for my personal applications, but I never saw anyone doing it so I assumed I was wrong. But nope, it turns out that everyone else was wrong :)
- sciurus 15y ago
  jpeterson didn't suggest "installing a bunch of libraries and updating things piecemeal". Instead of transferring the entire binary for every release they could generate a (likely much smaller) patch, transfer just it, then apply it. I expect they're not doing this because it's computationally intensive compared to transferring the entire binary.

monatron 15y ago

further on in the article they explain that facebook is developing a hip hop virtual machine that allows them to run custom bytecode in their own runtime environment which would allow them to push deltas. im fairly certain that pushing deltas of compiled c++ code on this scale is impossible.

shabble 15y ago

I wonder whether they've considered (something similar to) Google Courgette[1], for distributing compiled binaries with many similarities, but translating into abstract basic blocks and rewriting pointers to match. Although, both the generation of the diff-set, and it's application on each individual server might end up eating more resources than just using torrents. [1] http://dev.chromium.org/developers/design-documents/software-updates-courgette http://dev.chromium.org/developers/design-documents/software...

tedunangst 15y ago

"bsdiff is quite memory-hungry. It requires max(17n,9n+m)+O(1) bytes of memory, where n is the size of the old file and m is the size of the new file." http://www.daemonology.net/bsdiff/ http://www.daemonology.net/bsdiff/

jrockway 15y ago

Because the continuous integration runs tests for all components at HEAD, not at every random possible combination that could end up on a machine. The key to releases is repeatability and consistency. Copying one big blob to every machine is repeatable and consistent. Installing a bunch of libraries and updating things piecemeal is much more difficult to do right. Internal bandwidth is cheap, so this is almost a no-brainer. Even without an internal bittorrent distribution mechanism, it's still easy. The reason why people tend to gravitate to incremental deployments for web applications is because the typical tools encourage it; modules get installed in separate directories, each part of the app is a separate file (back in the CGI days), etc. When you compile everything into one file, though, then you just copy that file around to deploy. It's easier. (Ask a PHP programmer how to change one file, and it will probably be "change that one file". Ask a Java programmer, and it will be "fix the file, build a WAR, and replace the WAR". Tools dictate process, and the "scripting language" default is to work on a file level instead of an application level.) I've always wanted one-file deployment for my personal applications, but I never saw anyone doing it so I assumed I was wrong. But nope, it turns out that everyone else was wrong :)

sciurus 15y ago
jpeterson didn't suggest "installing a bunch of libraries and updating things piecemeal". Instead of transferring the entire binary for every release they could generate a (likely much smaller) patch, transfer just it, then apply it. I expect they're not doing this because it's computationally intensive compared to transferring the entire binary.