3 ms·

It's not really processing power so much as storage and RAM that used to be seen as the disadvantages of static binaries. The advantages of the static binary mo

It's not really processing power so much as storage and RAM that used to be seen as the disadvantages of static binaries. The advantages of the static binary model are that it avoids "DLL hell" and makes sourcing dependencies a bit better, which are indeed laudable aims. But nowadays it has terrible security (and to some extent reliability) trade-offs - if everything is a static binary and there's a security issue in a library, you need to upgrade every single binary depending on it, which is much less reliable and more prone to error/oversight. As security and reliability have increased in importance, so the "cost" of the static binary route has actually gone up significantly in my view compared to 20-30 years ago. So it's a bit odd to me to see this model (and closely related ideas like flatpak etc) gaining currency. There must be better ways to manage the "DLL hell" issues than that.

jungler 8y ago
From the POV of folks working around massive server farms, all the servers are disposable, so having one binary is convenient, and the short lifespans mean they avoid the downsides. The concern has more relevance to client applications, but then the cost becomes related to update strategy, and if every app is tied to an update manager process(whether it's an app store type of thing or a custom one) then the thinking becomes similar to the cloud server setup: Why bother, I'm going to blow it all away in the next update. When the dependency management is exposed to users, there's a much bigger surface area for troubleshooting and support. It makes sense that devs favor static if they expect the whole environment to be disposable. It isn't like it was in the 90's, where patching was occasional but major new versions were essentially new products.
ecnahc515 8y ago
You can also see it as a security gain because you now can upgrade things independently without fear of how that may propagate to other applications. Being able to upgrade rapidly is the single best way to improve security. With DLLs people take a lot more time to upgrade because the risk is so high, meaning systems sit with older less-secure versions for longer.
TimJYoung 8y ago
Most compilers that produce native, static binaries for a platform also use static type systems that can be used to determine exactly where and how any given piece of code is used, including libraries. Also, if one can't get their internal builds correct, then they've got problems that go beyond security concerns. Also, if you're talking about native, highly-distributed desktop/server applications, then the problem with using shared libraries is even worse. The only exception is system-level libraries that are updated automatically by the OS/distribution. Finally, on Windows, with static binaries you can be sure that the binary is a particular version/build and is signed (this ensures that the binary version/build is valid). You don't get much better peace of mind than that. We've been distributing our installations and other binaries like that for over a decade, and it works great.

jungler 8y ago

From the POV of folks working around massive server farms, all the servers are disposable, so having one binary is convenient, and the short lifespans mean they avoid the downsides. The concern has more relevance to client applications, but then the cost becomes related to update strategy, and if every app is tied to an update manager process(whether it's an app store type of thing or a custom one) then the thinking becomes similar to the cloud server setup: Why bother, I'm going to blow it all away in the next update. When the dependency management is exposed to users, there's a much bigger surface area for troubleshooting and support. It makes sense that devs favor static if they expect the whole environment to be disposable. It isn't like it was in the 90's, where patching was occasional but major new versions were essentially new products.

ecnahc515 8y ago

You can also see it as a security gain because you now can upgrade things independently without fear of how that may propagate to other applications. Being able to upgrade rapidly is the single best way to improve security. With DLLs people take a lot more time to upgrade because the risk is so high, meaning systems sit with older less-secure versions for longer.

TimJYoung 8y ago

Most compilers that produce native, static binaries for a platform also use static type systems that can be used to determine exactly where and how any given piece of code is used, including libraries. Also, if one can't get their internal builds correct, then they've got problems that go beyond security concerns. Also, if you're talking about native, highly-distributed desktop/server applications, then the problem with using shared libraries is even worse. The only exception is system-level libraries that are updated automatically by the OS/distribution. Finally, on Windows, with static binaries you can be sure that the binary is a particular version/build and is signed (this ensures that the binary version/build is valid). You don't get much better peace of mind than that. We've been distributing our installations and other binaries like that for over a decade, and it works great.