3 ms·

> The collective developer mind can now neatly wrap up the idea of an application into an execution environment that can be easily shared and distributed. I th

> The collective developer mind can now neatly wrap up the idea of an application into an execution environment that can be easily shared and distributed. I think we used to call that a 'binary', but I'm old.

rashkov 6y ago
Isn't the reliance on dynamic linking what got us into this mess in the first place? System-wide dependencies are a bad idea. apt-get / brew / yum should not be your software's packaging / dependency system, but that's what a large portion of C/C++ software does. Docker is a strong solution to the problem of dependency conflicts between different software packages. It's what allows me to run software that only works with gcc 7 while my system is on gcc 8.
- stingraycharles 6y ago
  That’s just one part of Docker. The other part is the security aspects; you cannot “escape” the container (easily). This cannot be achieved with plain static linking, but you’ll need cgroups etc for that. Docker just combined these concepts elegantly in a way that “clicked” with many people, and was fairly pragmatic. The only major complaint I have about docker is its client/server model, it just makes so many things more complicated. It seems podman is doing great work in this area though.
- ansible 6y ago
  > Isn't the reliance on dynamic linking what got us into this mess in the first place? Dynamic linking was a terrific solution to code size issues... 30 years ago. Back at the dawn of 32-bit computing, it was typical to see a multi-user machine with 1MB of RAM, for everyone to share. Also, back then, systems weren't so well connected, and library releases happened once a year or so. Security wasn't as big a concern. I can't help but think that if we (as an industry) had moved towards a Nix-like package system, we might not have gone down the container route. You just specify which exact versions of which libraries your application depends on, that's it.
  - rashkov 6y ago
    Agreed, but also curious: what's to stop software packages from statically linking everything? Does it require re-writing or redesigning code, or is it just a matter of flipping a compiler flag?
- maple3142 6y ago
  This is what I think too. Linux ecosystem mostly depends on dynamic linking, in a way that statically compiling all the dependencies is not easy. The flag "-static" isn't magic, so building a static binary from a project without official static linking support is hard. Recently, I just tried to build a php binary for a system I don't have root access. Since that system don't have many things that are required to build php, I decided to build a static binary on my computer. Then, its dependencies are really complicated to compile with static linking, so I still can't get it work.
c22 6y ago
You are old! We have a lot more than two developers now.
jayd16 6y ago
Sure but now you can compose multiple binaries across many runtimes into a portable unit.

rashkov 6y ago

Isn't the reliance on dynamic linking what got us into this mess in the first place? System-wide dependencies are a bad idea. apt-get / brew / yum should not be your software's packaging / dependency system, but that's what a large portion of C/C++ software does. Docker is a strong solution to the problem of dependency conflicts between different software packages. It's what allows me to run software that only works with gcc 7 while my system is on gcc 8.

stingraycharles 6y ago
That’s just one part of Docker. The other part is the security aspects; you cannot “escape” the container (easily). This cannot be achieved with plain static linking, but you’ll need cgroups etc for that. Docker just combined these concepts elegantly in a way that “clicked” with many people, and was fairly pragmatic. The only major complaint I have about docker is its client/server model, it just makes so many things more complicated. It seems podman is doing great work in this area though.
ansible 6y ago
> Isn't the reliance on dynamic linking what got us into this mess in the first place? Dynamic linking was a terrific solution to code size issues... 30 years ago. Back at the dawn of 32-bit computing, it was typical to see a multi-user machine with 1MB of RAM, for everyone to share. Also, back then, systems weren't so well connected, and library releases happened once a year or so. Security wasn't as big a concern. I can't help but think that if we (as an industry) had moved towards a Nix-like package system, we might not have gone down the container route. You just specify which exact versions of which libraries your application depends on, that's it.
- rashkov 6y ago
  Agreed, but also curious: what's to stop software packages from statically linking everything? Does it require re-writing or redesigning code, or is it just a matter of flipping a compiler flag?
maple3142 6y ago
This is what I think too. Linux ecosystem mostly depends on dynamic linking, in a way that statically compiling all the dependencies is not easy. The flag "-static" isn't magic, so building a static binary from a project without official static linking support is hard. Recently, I just tried to build a php binary for a system I don't have root access. Since that system don't have many things that are required to build php, I decided to build a static binary on my computer. Then, its dependencies are really complicated to compile with static linking, so I still can't get it work.

c22 6y ago

You are old! We have a lot more than two developers now.

jayd16 6y ago

Sure but now you can compose multiple binaries across many runtimes into a portable unit.