I enjoyed this explanation of how Google updates Chrome faster than ever by cleverly only updating the elements that have changed. The problem is that software in executable form usually uses spots in memory that are hard-coded into it: Instead of saying “Take the number_of_miles_traveled and divide it by number_of_gallons_used…”, it says “Take the number stored at memory address #1876023…” (I’m obviously simplifying it.) If you insert or delete code from the program, the memory addresses will probably change, so that the program is now looking in the wrong spot for the numbers of miles traveled, and for instructions about what to do next. You can only hope that the crash will be fast and while in the presence of those who love you.

So, I enjoyed the Chrome article for a few reasons.

First, it was written clearly enough that even I could follow it, pretty much.

Second, the technique they use is not only clever, it bounces between levels of abstraction. The compiled code that runs on your computer generally is at a low level of abstraction: What the programmer thinks of as a symbol (a variable) such as number_of_miles_traveled gets turned into a memory address. The Chrome update system reintroduces a useful level of abstraction.

Third, I like what this says about the nature of information. I don’t think Courgette (the update system) counts as a compression algorithm, because it does not enable fewer bits to encode more information, but it does enable fewer bits to have more effect. Or maybe it does count as compression if we consider Chrome to be not a piece of software that runs on client computers but to be a system of clients connected to a central server that is spread out across both space and time. In either case, information is weird.

Categories: infohistory, tech dw