3 ms·

I disagree. While there are bloated images and runtimes, at least they are separate. Unfortunately most applications are developed in a way that they believe t

I disagree. While there are bloated images and runtimes, at least they are separate. Unfortunately most applications are developed in a way that they believe they are the only one on the system. Ruby gets called, and they expect 2.7. And there is another one which is using Ruby 3.2. And it's incompatible with 2.7. Now what? Do you want to spend time - maintaining 2 versions of ruby on a system - keeping them separate - ensuring they don't mix up OR Shove them in a container, run them in parallel and all they surface is a port. I'll take the container.

thriftwy 4y ago
Dockerized delivery starts easy unless you realize you need a new container for every small thing you need to run, and you end up with a pile of containers a short while later. Docker containers, in my experience, have not figured out auto updates yet. You may be running containers with critical system vulnerabilities and is not bothered to check. So the basic premise of Dockerization 1.0, "I have exactly one thing which I will put in a single container with all of its dependencies, reproducibly built" is wrong.
- WirelessGigabit 4y ago
  But the update problem is also present on direct installs. It's is less bad on Docker. Example: 2 containers which rely ffmpeg, and there's a vulnerability in ffmpeg. But container A can't update cause ffmpeg's update breaks something else... At least with Docker you can update container B, and maybe isolate A. On a direct install ffmpeg is a shared component. So now both apps are locked to a vulnerable version. Not to mention that shared components are often outdated for the sake of stability. So App A is restricted to the same version as App B, even though App A would like version 9, and B is on 8.
  - thriftwy 4y ago
    Direct installs have auto update, though, so they may update A and B separately and will often update them along with bundled dependencies. In the Docker scenario, it's quite often that neither A nor B will be updated for a long time, since there's no mechanism to do so.
mgaunard 4y ago
Well you need to do that anyway if you are indeed building those applications.

thriftwy 4y ago

Dockerized delivery starts easy unless you realize you need a new container for every small thing you need to run, and you end up with a pile of containers a short while later. Docker containers, in my experience, have not figured out auto updates yet. You may be running containers with critical system vulnerabilities and is not bothered to check. So the basic premise of Dockerization 1.0, "I have exactly one thing which I will put in a single container with all of its dependencies, reproducibly built" is wrong.

WirelessGigabit 4y ago
But the update problem is also present on direct installs. It's is less bad on Docker. Example: 2 containers which rely ffmpeg, and there's a vulnerability in ffmpeg. But container A can't update cause ffmpeg's update breaks something else... At least with Docker you can update container B, and maybe isolate A. On a direct install ffmpeg is a shared component. So now both apps are locked to a vulnerable version. Not to mention that shared components are often outdated for the sake of stability. So App A is restricted to the same version as App B, even though App A would like version 9, and B is on 8.
- thriftwy 4y ago
  Direct installs have auto update, though, so they may update A and B separately and will often update them along with bundled dependencies. In the Docker scenario, it's quite often that neither A nor B will be updated for a long time, since there's no mechanism to do so.

mgaunard 4y ago

Well you need to do that anyway if you are indeed building those applications.