5 ms·

the optimization you describe here is not valuable enough to offset the value provided by statically linked applications the computational model of a fleet of

the optimization you describe here is not valuable enough to offset the value provided by statically linked applications the computational model of a fleet of long-lived servers, which receive host/OS updates at one cadence, and serve applications that are deployed at a different cadence, is at this point a niche use case, basically anachronistic, and going away applications are the things that matter, they provide the value, the OS and even shared libraries are really optimizations, details, that don't really make sense any more the unit of maintenance is not a host, or a specific library, it's an application vulnerabilities affect applications, if there is a vulnerability in some library that's used by a bunch of my applications then it's expected that i will need to re-deploy updated versions of those applications, this is not difficult, i am re-deploying updated versions of my applications all the time, because that is my deployment model

rektide 4y ago
Free software has a use beyond industrial software containers. I don't think most folks developing on Linux laptops agree with your narrow conception of software. Beyond app delivery there's dozens of different utils folks rely on in their day to day. The new statically compiled world requiring each of these to be well maintained & promptly updated feels like an obvious regression.
- howinteresting 4y ago
  Again, there is no alternative. Dynamic linking is an artifact of an antiquated 70s-era programming language. It simply does not and cannot work with modern language features like monomorphization. Linux distros are thankfully moving towards embracing static linking, rather than putting their heads in the sand and pretending that dynamic linking isn't on its last legs.
  - PaulDavisThe1st 4y ago
    Whoa, strong opinions. Dynamic linking on *nix has nothing to do with 70s era programming languages. Did you consider the possibility that the incompatibility between monomorphization (possibly the dumbest term in all of programming) and dynamic linking should perhaps saying something about monomorphization, instead?
    - howinteresting 4y ago
      > Dynamic linking on *nix has nothing to do with 70s era programming languages. Given that dynamic linking as a concept came out of the C world, it has everything to do with them. > Did you consider the possibility that the incompatibility between monomorphization (possibly the dumbest term in all of programming) and dynamic linking should perhaps saying something about monomorphization, instead? Yes, I considered that possibility.
      - PaulDavisThe1st 4y ago
        The design of dynamic linking on most *nix-ish systems today comes from SunOS in 1988, and doesn't have much to do with C at all other than requiring both the compiler and assembler to know about position-independent code. What elements of dynamic linking do you see as being connected to "70s era programming languages"? > Yes, I considered that possibility. Then I would urge you to reconsider.
        preseinger 4y ago
        dynamic linking is an optimization that is no longer necessary there is no practical downside to a program including all of its dependencies, when evaluated against the alternative of those dependencies being determined at runtime and based on arbitrary state of the host system monomorphization is good, not bad the contents of /usr/lib/whatever should not impact the success or failure of executing a given program
        PaulDavisThe1st 4y ago
        Dynamic linking wasn't an optimization (or at least, it certainly wasn't just an optimization). It allows for things like smaller executable sizes, more shared code in memory, and synchronized security updates. You can, if you want, try the approach of "if you have 384GB of RAM, you don't need to care about these things", and in that sense you're on quicksand with the "just an optimization". Yes, the benefits of sharing library code in memory are reduced by increasing system RAM, but we're seeing from a growing chorus of both developers and users, the "oh, forget all that stupid stuff, we've got bigger faster computers now" isn't going so well. There's also the problem that dynamic loading relies on almost all the same mechanisms as dynamic linking, so you can't get rid of those mechanisms just because your main build process used static linking.
- preseinger 4y ago
  > Free software has a use beyond industrial software containers. I don't think most folks developing on Linux laptops agree with your narrow conception of software. the overwhelming majority of software that would ever be built by a system like buck2 is written and deployed in an industrial context the share of software consumers that would use this class of software on personal linux laptops is statistically zero really, the overwhelming majority of installations of distros like fedora or debian or whatever are also in industrial contexts, the model of software lifecycles that their maintainers seem to assume is wildly outdated
lokar 4y ago
Indeed. I view Linux servers/vms as ELF execution appliances with a network stack. And more and more the network stack lives in the NIC and the app, not Linux.
- preseinger 4y ago
  100% yes

rektide 4y ago

Free software has a use beyond industrial software containers. I don't think most folks developing on Linux laptops agree with your narrow conception of software. Beyond app delivery there's dozens of different utils folks rely on in their day to day. The new statically compiled world requiring each of these to be well maintained & promptly updated feels like an obvious regression.

howinteresting 4y ago
Again, there is no alternative. Dynamic linking is an artifact of an antiquated 70s-era programming language. It simply does not and cannot work with modern language features like monomorphization. Linux distros are thankfully moving towards embracing static linking, rather than putting their heads in the sand and pretending that dynamic linking isn't on its last legs.
- PaulDavisThe1st 4y ago
  Whoa, strong opinions. Dynamic linking on *nix has nothing to do with 70s era programming languages. Did you consider the possibility that the incompatibility between monomorphization (possibly the dumbest term in all of programming) and dynamic linking should perhaps saying something about monomorphization, instead?
  - howinteresting 4y ago
    > Dynamic linking on *nix has nothing to do with 70s era programming languages. Given that dynamic linking as a concept came out of the C world, it has everything to do with them. > Did you consider the possibility that the incompatibility between monomorphization (possibly the dumbest term in all of programming) and dynamic linking should perhaps saying something about monomorphization, instead? Yes, I considered that possibility.
    - PaulDavisThe1st 4y ago
      The design of dynamic linking on most *nix-ish systems today comes from SunOS in 1988, and doesn't have much to do with C at all other than requiring both the compiler and assembler to know about position-independent code. What elements of dynamic linking do you see as being connected to "70s era programming languages"? > Yes, I considered that possibility. Then I would urge you to reconsider.
      - preseinger 4y ago
        dynamic linking is an optimization that is no longer necessary there is no practical downside to a program including all of its dependencies, when evaluated against the alternative of those dependencies being determined at runtime and based on arbitrary state of the host system monomorphization is good, not bad the contents of /usr/lib/whatever should not impact the success or failure of executing a given program
        PaulDavisThe1st 4y ago
        Dynamic linking wasn't an optimization (or at least, it certainly wasn't just an optimization). It allows for things like smaller executable sizes, more shared code in memory, and synchronized security updates. You can, if you want, try the approach of "if you have 384GB of RAM, you don't need to care about these things", and in that sense you're on quicksand with the "just an optimization". Yes, the benefits of sharing library code in memory are reduced by increasing system RAM, but we're seeing from a growing chorus of both developers and users, the "oh, forget all that stupid stuff, we've got bigger faster computers now" isn't going so well. There's also the problem that dynamic loading relies on almost all the same mechanisms as dynamic linking, so you can't get rid of those mechanisms just because your main build process used static linking.
preseinger 4y ago
> Free software has a use beyond industrial software containers. I don't think most folks developing on Linux laptops agree with your narrow conception of software. the overwhelming majority of software that would ever be built by a system like buck2 is written and deployed in an industrial context the share of software consumers that would use this class of software on personal linux laptops is statistically zero really, the overwhelming majority of installations of distros like fedora or debian or whatever are also in industrial contexts, the model of software lifecycles that their maintainers seem to assume is wildly outdated

lokar 4y ago

Indeed. I view Linux servers/vms as ELF execution appliances with a network stack. And more and more the network stack lives in the NIC and the app, not Linux.

preseinger 4y ago
100% yes