3 ms·

> The programming field often feels like it's in a giant loop constantly re-discovering what went before. It might feel that way, but this is driven by economi

> The programming field often feels like it's in a giant loop constantly re-discovering what went before. It might feel that way, but this is driven by economics. Basically disk, memory, and bandwidth is far cheaper than it used to be so who cares if you waste a GB or so copying the same libraries all over if you don't have to solve for dependency hell?

Koshkin 8y ago
> disk is far cheaper Not in the cloud.
- weberc2 8y ago
  To be clear, you're asserting that the price of disk in the cloud is comparable to what it was decades ago?
  - Koshkin 8y ago
    Things are more complicated than that. (Depending on the pricing scheme, you might end up paying per gigabyte per hour, for example; which may or may not include transfer/storage of actual data; a faster "drive" could be much more expensive than a slower one, etc.)
    - weberc2 8y ago
      Sorry, I'm not following. Granted pricing schemes have changed, but adjusting for that, are you claiming that disk is not dramatically cheaper than it was ~20 years ago? Not trying to be a dick, just not following your point.
      - Koshkin 8y ago
        Point is, "disk" in the cloud is not the same thing as the disk in your PC.
        ecnahc515 8y ago
        No, the point is it doesn't matter where the disk is, the overall price has gone down.
        weberc2 8y ago
        Of course it's not, but the cost of both has declined.
- GordonS 8y ago
  Disagree, cloud storage is cheap - bandwidth is expensive.
- solarkraft 8y ago
  1) It is 2) Application space on the server is vanishingly tiny compared to the data you're processing, so it is a far more generous trade-off.
eeZah7Ux 8y ago
Vendorizing libraries and static linking has become a security hell. Just an example: https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...
- weberc2 8y ago
  Your link cites "little thought to the inclusion of dependencies", _not_ static linkage, as the cause of this "hell".
  - wahern 8y ago
    The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system. If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fixed by a simple `apt-get upgrade` or `yum update`.
    - jjnoakes 8y ago
      Is this always true? If the shared library you linked to uses symbol versions and the bug fix requires a new version of a symbol, the application has to be relinked anyway. Same as static linking, except now it is not obvious you need to relink to get the bug fix.
      - rkeene2 8y ago
        Only if the fix involves breaking the old semantics entirely. It's possible in some cases to support old semantics in a safe way at the cost of performance, or in the case that it's not you can disable that call in such a way that the program aborts if it is called, thus indicating that the user should relink that program. This is why integration projects such as Linux distributions are hard, and useful.
    - 8y ago
shaan7 8y ago
> so who cares if you waste a GB or so I wonder if that sounds arrogant to just me. As a user I DO CARE. Its frustrating to find applications shipping their own copy of libraries wasting precious disk space. When I was using a Mac, I had at least 4 applications shipping their own copy of Qt5.4 ... aaaarrgh Back on the Linux desktop, package managers handle this beautifully. And for the cases where you need to skip the distro, Flatpak still lets you use system dependencies. Everyone wins. And for whoever claims storage is cheap, please link me the magical place you're buying yours from. Thanks.
- AnIdiotOnTheNet 8y ago
  Package managers come with their own limitations. You can't have multiple versions of the same application, packages are often out of date, packages sometimes conflict, you can't choose where applications are installed, etc. And storage is ridiculously cheap. You can get an 8TB HDD for $150[0]. Or a 1TB SSD for the same price[1]. [0]https://www.amazon.com/Seagate-Expansion-Desktop-External-STEB8000100/dp/B01HAPGEIE https://www.amazon.com/Seagate-Expansion-Desktop-External-ST... [1]https://www.amazon.com/Blue-NAND-1TB-SSD-WDS100T2B0A/dp/B073SBQMCX https://www.amazon.com/Blue-NAND-1TB-SSD-WDS100T2B0A/dp/B073...
  - rkeene2 8y ago
    > You can't have multiple versions of the same application In many package managers you can have multiple versions of the same application without a big deal -- in most cases you don't want to SUPPORT multiple versions of the same application, so there's always a trade-off.
    - AnIdiotOnTheNet 8y ago
      > In many package managers you can have multiple versions of the same application without a big deal In my experience, only if the distro has specifically set things up to allow that (Python2/3), or you find a PPA maintained by someone. Otherwise, time to compile from source I guess.

Koshkin 8y ago

> disk is far cheaper Not in the cloud.

weberc2 8y ago
To be clear, you're asserting that the price of disk in the cloud is comparable to what it was decades ago?
- Koshkin 8y ago
  Things are more complicated than that. (Depending on the pricing scheme, you might end up paying per gigabyte per hour, for example; which may or may not include transfer/storage of actual data; a faster "drive" could be much more expensive than a slower one, etc.)
  - weberc2 8y ago
    Sorry, I'm not following. Granted pricing schemes have changed, but adjusting for that, are you claiming that disk is not dramatically cheaper than it was ~20 years ago? Not trying to be a dick, just not following your point.
    - Koshkin 8y ago
      Point is, "disk" in the cloud is not the same thing as the disk in your PC.
      - ecnahc515 8y ago
        No, the point is it doesn't matter where the disk is, the overall price has gone down.
      - weberc2 8y ago
        Of course it's not, but the cost of both has declined.
GordonS 8y ago
Disagree, cloud storage is cheap - bandwidth is expensive.
solarkraft 8y ago
1) It is 2) Application space on the server is vanishingly tiny compared to the data you're processing, so it is a far more generous trade-off.

eeZah7Ux 8y ago

Vendorizing libraries and static linking has become a security hell. Just an example: https://blog.acolyer.org/2017/04/03/a-study-of-security-vulnerabilities-on-docker-hub/ https://blog.acolyer.org/2017/04/03/a-study-of-security-vuln...

weberc2 8y ago
Your link cites "little thought to the inclusion of dependencies", _not_ static linkage, as the cause of this "hell".
- wahern 8y ago
  The implication is that statically linked binaries make it easier to throw in dependencies because you neither need to worry about how to ship them nor bother with re-using the shared libraries on the system. If there's a bug in Go's TLS implementation, you need to identify, recompile, and redistribute every Go application you use. Whereas if it were using the system's OpenSSL library everything would magically be fixed by a simple `apt-get upgrade` or `yum update`.
  - jjnoakes 8y ago
    Is this always true? If the shared library you linked to uses symbol versions and the bug fix requires a new version of a symbol, the application has to be relinked anyway. Same as static linking, except now it is not obvious you need to relink to get the bug fix.
    - rkeene2 8y ago
      Only if the fix involves breaking the old semantics entirely. It's possible in some cases to support old semantics in a safe way at the cost of performance, or in the case that it's not you can disable that call in such a way that the program aborts if it is called, thus indicating that the user should relink that program. This is why integration projects such as Linux distributions are hard, and useful.
  - 8y ago

shaan7 8y ago

> so who cares if you waste a GB or so I wonder if that sounds arrogant to just me. As a user I DO CARE. Its frustrating to find applications shipping their own copy of libraries wasting precious disk space. When I was using a Mac, I had at least 4 applications shipping their own copy of Qt5.4 ... aaaarrgh Back on the Linux desktop, package managers handle this beautifully. And for the cases where you need to skip the distro, Flatpak still lets you use system dependencies. Everyone wins. And for whoever claims storage is cheap, please link me the magical place you're buying yours from. Thanks.

AnIdiotOnTheNet 8y ago
Package managers come with their own limitations. You can't have multiple versions of the same application, packages are often out of date, packages sometimes conflict, you can't choose where applications are installed, etc. And storage is ridiculously cheap. You can get an 8TB HDD for $150[0]. Or a 1TB SSD for the same price[1]. [0]https://www.amazon.com/Seagate-Expansion-Desktop-External-STEB8000100/dp/B01HAPGEIE https://www.amazon.com/Seagate-Expansion-Desktop-External-ST... [1]https://www.amazon.com/Blue-NAND-1TB-SSD-WDS100T2B0A/dp/B073SBQMCX https://www.amazon.com/Blue-NAND-1TB-SSD-WDS100T2B0A/dp/B073...
- rkeene2 8y ago
  > You can't have multiple versions of the same application In many package managers you can have multiple versions of the same application without a big deal -- in most cases you don't want to SUPPORT multiple versions of the same application, so there's always a trade-off.
  - AnIdiotOnTheNet 8y ago
    > In many package managers you can have multiple versions of the same application without a big deal In my experience, only if the distro has specifically set things up to allow that (Python2/3), or you find a PPA maintained by someone. Otherwise, time to compile from source I guess.