> And you have to replace that whole binary everywhere it is installed. Not if your package manager supports binary diffs [1]. Which for many platforms is alre

> And you have to replace that whole binary everywhere it is installed. Not if your package manager supports binary diffs [1]. Which for many platforms is already the case, and other package managers would likely implement the feature if downloading large binaries becomes a problem. Right now, I’d however call it a premature optimization as the bandwidth of most people is dominated not by downloading updates but by streaming. But it is a solved problem since e.g. Fedora has supported package diffs for a decade. Regarding the heartbleed, that is a valid and often repeated argument, but I think it is also overblown. One could e.g. have a static binary with embedded or bundled info about what library versions it was statically compiled with, and a way to automatically flag which binaries are thus vulnerable. Such a system would make it possible to push out new builds of high-priority targets like Firefox and Chromium without testing every other libssl-based app for compatibility first, thus cutting down on the response time for patching the most vulnerable apps. But the flagging would make it clear that the other apps need updating too. (Or in the case of automated builds, that the other apps need testing.) I’m not saying that the whole OS should be statically linked, but for end-user apps I think it makes a lot of sense, and it’d remove a lot of friction where a library update can break a previously working app (that happens). [1]: https://en.m.wikipedia.org/wiki/Delta_update https://en.m.wikipedia.org/wiki/Delta_update