5 ms·

If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF?

If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?

dailykoder 2y ago
Because static libraries ain't a big thing anymore. Maybe they will become popular again. This would make it easier to have reproduceable build without a container. But I think containers are the new static libs now
- indymike 2y ago
  Interpreted languages and their associated dependencies are more of an issue than static linking with compiled languages.
shawabawa3 2y ago
people would absolutely love to do that, but it's difficult, and the UX sucks so people use containers instead (even if the container literally only contains a single statically linked binary)
Cthulhu_ 2y ago
That's exactly the summary of this. That said, it makes sense from a developer POV; if, during development, you don't need the isolation you can run multiple containers (with on paper fast boot times and minimal overhead) on your development box. There's plenty of cases to imagine where you need the containerization but not necessarily the isolation.
- jbverschoor 2y ago
  That what I do. I use https://github.com/jrz/container-shell https://github.com/jrz/container-shell so my projects are contained, and I'm a little bit protected against supply chain attacks
  - DEADMINCE 2y ago
    Why not use bubblelwrap or selinux or something? Docker is overkill for this.
    - jbverschoor 2y ago
      Haven’t heard about bubblewrap, and I’m on my macOS. But I’ll look into it for inspiration
otabdeveloper4 2y ago
Yes, indeed, and that is golang's main reason for existing.
Repulsion9513 2y ago
Programmers discover the benefits of static linking, and then programmers discover the benefits of dynamic linking, and then programmers discover the benefits of static linking, and then... Anyway containers go quite a bit further than just static linking, most people aren't out there linking all the binaries that their shell script uses together?
jcelerier 2y ago
Well yes, but try turning some random python, java or ruby service into a single binary .. now do that 12 times. Or try with a native app that leverages both the GPU and libLLVM, and enjoy finding out the kind of precautions you have to take for LLVM to not blow up on a computer where your GPU driver was built with a different LLVM version.
TDiblik 2y ago
First thing that comes to mind is the need to link against libraries across platforms. Imagine that my app depends on opencv, if I wanted to statically link everything on my Windows machine, I need to compile opencv for Linux on my windows machine (or use pre-compiled binaries). Also, if you link against libraries dynamicaly, it's likely you can compile them on the host machine (or in a container) with more optimizations enabled. And the last thing is probably the ability to "freeze" the whole "system" environment (like folders, permissions, versions of system libraries). Personally, I use containers to quickly spin-up different database servers for development or as an easy way of deployment to a cloud service...
dooglius 2y ago
glibc doesn't work statically linked and lots of stuff depends on glibc
andix 2y ago
What if you application is not just one binary. What if it's a pipeline of complex tasks, calls some python scripts, uses a patched version of some obscure library, ... It's not possible to package half a Linux distribution into a single binary. That's why we have containers.

If this were true, then wouldn't folks just need an application binary that statically links all of its required libraries and resources into a giant, say, ELF? Why even bother with a container?

dailykoder 2y ago

Because static libraries ain't a big thing anymore. Maybe they will become popular again. This would make it easier to have reproduceable build without a container. But I think containers are the new static libs now

indymike 2y ago
Interpreted languages and their associated dependencies are more of an issue than static linking with compiled languages.

shawabawa3 2y ago

people would absolutely love to do that, but it's difficult, and the UX sucks so people use containers instead (even if the container literally only contains a single statically linked binary)

Cthulhu_ 2y ago

That's exactly the summary of this. That said, it makes sense from a developer POV; if, during development, you don't need the isolation you can run multiple containers (with on paper fast boot times and minimal overhead) on your development box. There's plenty of cases to imagine where you need the containerization but not necessarily the isolation.

jbverschoor 2y ago
That what I do. I use https://github.com/jrz/container-shell https://github.com/jrz/container-shell so my projects are contained, and I'm a little bit protected against supply chain attacks
- DEADMINCE 2y ago
  Why not use bubblelwrap or selinux or something? Docker is overkill for this.
  - jbverschoor 2y ago
    Haven’t heard about bubblewrap, and I’m on my macOS. But I’ll look into it for inspiration

otabdeveloper4 2y ago

Yes, indeed, and that is golang's main reason for existing.

Repulsion9513 2y ago

Programmers discover the benefits of static linking, and then programmers discover the benefits of dynamic linking, and then programmers discover the benefits of static linking, and then... Anyway containers go quite a bit further than just static linking, most people aren't out there linking all the binaries that their shell script uses together?

jcelerier 2y ago

Well yes, but try turning some random python, java or ruby service into a single binary .. now do that 12 times. Or try with a native app that leverages both the GPU and libLLVM, and enjoy finding out the kind of precautions you have to take for LLVM to not blow up on a computer where your GPU driver was built with a different LLVM version.

TDiblik 2y ago

First thing that comes to mind is the need to link against libraries across platforms. Imagine that my app depends on opencv, if I wanted to statically link everything on my Windows machine, I need to compile opencv for Linux on my windows machine (or use pre-compiled binaries). Also, if you link against libraries dynamicaly, it's likely you can compile them on the host machine (or in a container) with more optimizations enabled. And the last thing is probably the ability to "freeze" the whole "system" environment (like folders, permissions, versions of system libraries). Personally, I use containers to quickly spin-up different database servers for development or as an easy way of deployment to a cloud service...

dooglius 2y ago

glibc doesn't work statically linked and lots of stuff depends on glibc

andix 2y ago

What if you application is not just one binary. What if it's a pipeline of complex tasks, calls some python scripts, uses a patched version of some obscure library, ... It's not possible to package half a Linux distribution into a single binary. That's why we have containers.