6 ms·

TBH, containers are the wrong way of doing things, but they are the least bad solution of shipping software that we currently have.

ycombinatrix 3y ago
scratch containers aren't so bad
zer00eyz 3y ago
This is the truth. Containers as a bag that you put shitty software in to isolate it from the rest of your system and its peers... The whole downstream, vs upstream, who should package what and where do you get software is showing us what the real problem is. Software, should be easy to instal. Containers are a terrible way to do that.
- stavros 3y ago
  What's easier than containers? It sounds to me like you let your hate of the problem carry over to hating the solution. I have a Python web app, what's a better way to distribute it than containers?
  - apitman 3y ago
    I basically agree with you, but it would be nice if containers were a bit simpler. Apptainer does some really nice things for example.
  - watermelon0 3y ago
    As much as I like scripting languages, the fact that you cannot build a single statically-built executable is the main problem when it comes to distribution. Go/Rust are miles ahead in that regard, and the only reason to use containers with them is the sandbox aspect. (There are ways to create a self-contained executable including Python interpreter, code, and all dependencies, but it's far from ideal, and just going with Docker is a lot less problematic.)
    - stavros 3y ago
      Sure, but I have a Python web app.
  - deleted 3y ago
    [deleted]
  - zer00eyz 3y ago
    I like python, I write python. I think python is the high fructose corn surup of programing, its in everything, embedded, web, ML, data science .... >> What's easier than containers? Easy is the wrong metric. It is easy to not scoop your dogs poop when you take him on a walk. It is easy to drop your trash on the ground and not take it to a can... Easy is a BAD METRIC. Python is one of the problems. your code + Runtime + random libs + venv. thats a lot of nonsense that could be a binary blob. Part of this is the fault of python (or js, or ruby or...) a lot of it is on us as software devs. And micro services had a hand in this... Your N services dont run on N*X pieces of hardware. They run on far less and end up on virtual networks taking to each other over https when they could be using direct communication. It's even more laughable if they go out to a load balancer first. Software packaging and delivery is a problem. We should figure out a few good ways to fix that.
    - psd1 3y ago
      You've conflated "easy" with "littering". The easiness of littering is an argument for littering, not against easiness.
    - allarm 3y ago
      So, there’s no better way.
    - jrm4 3y ago
      Easy is the correct metric if, like me, you believe the solutions to our major problems in the software space involve not "trying to get the few companies to behave better," but "trying to get MORE PEOPLE to understand -- and put in practice -- that this doesn't have to be in the hands of a few companies."
KronisLV 3y ago
> TBH, containers are the wrong way of doing things And yet, people still use VMs because the majority of software isn't perfect and pollutes whatever system it's running on to some degree. Just earlier today I saw a friend look at an install script for some software, which was set on freely installing apt packages, replacing the installed Node version, purging the apt repositories on the system (literally "rm -rf /etc/apt/sources.list.d/*", wtf) and a lot of things that no decently written piece of software should do on its own, at least not without explicit confirmation, but you still sometimes see out in the wild. The friend was reviewing the script after running it and wondering why their system was trashed. You often need some separation between what is your host system that needs to be pretty stable and the flaming mess that is whatever software that you'll install on it for productivity/entertainment/profit reasons, especially with easily configurable resource limits, custom port mappings, custom storage directories without access to the host system by default and eventually even horizontal scaling. Containers just happen to have really good DX around all of that and feel like the right way of doing things, in a flawed world.
- watermelon0 3y ago
  Dependency hell and polluting the system IS the problem. Ideally, we would have statically built self-contained executables, and OS would offer sandboxing (process, network, filesystem) out of the box. Containers at the moment are just lightweight VMs, and a better workaround to the problem (better especially in regard to UX; VMs isolation is still superior to cgroups/namespaces on Linux).
  - nurple 3y ago
    The Linux OS literally provides sandboxing, we call the set of technologies that provide this "containers". "Containers" are not lightweight VMs; VMs are a virtualized computer, containers are a virtualized kernel. Statically linked everything is ridiculous and will never be the future of software deployment.
- jmbwell 3y ago
  In some cases, running docker containers using the vendor-provided docker compose file, inside a VM that you yourself provision according to your own needs using your own tooling (ansible etc), is the best approach, which at this point is ridiculous, but here we are.

ycombinatrix 3y ago

scratch containers aren't so bad

zer00eyz 3y ago

This is the truth. Containers as a bag that you put shitty software in to isolate it from the rest of your system and its peers... The whole downstream, vs upstream, who should package what and where do you get software is showing us what the real problem is. Software, should be easy to instal. Containers are a terrible way to do that.

stavros 3y ago
What's easier than containers? It sounds to me like you let your hate of the problem carry over to hating the solution. I have a Python web app, what's a better way to distribute it than containers?
- apitman 3y ago
  I basically agree with you, but it would be nice if containers were a bit simpler. Apptainer does some really nice things for example.
- watermelon0 3y ago
  As much as I like scripting languages, the fact that you cannot build a single statically-built executable is the main problem when it comes to distribution. Go/Rust are miles ahead in that regard, and the only reason to use containers with them is the sandbox aspect. (There are ways to create a self-contained executable including Python interpreter, code, and all dependencies, but it's far from ideal, and just going with Docker is a lot less problematic.)
  - stavros 3y ago
    Sure, but I have a Python web app.
- deleted 3y ago
  [deleted]
- zer00eyz 3y ago
  I like python, I write python. I think python is the high fructose corn surup of programing, its in everything, embedded, web, ML, data science .... >> What's easier than containers? Easy is the wrong metric. It is easy to not scoop your dogs poop when you take him on a walk. It is easy to drop your trash on the ground and not take it to a can... Easy is a BAD METRIC. Python is one of the problems. your code + Runtime + random libs + venv. thats a lot of nonsense that could be a binary blob. Part of this is the fault of python (or js, or ruby or...) a lot of it is on us as software devs. And micro services had a hand in this... Your N services dont run on N*X pieces of hardware. They run on far less and end up on virtual networks taking to each other over https when they could be using direct communication. It's even more laughable if they go out to a load balancer first. Software packaging and delivery is a problem. We should figure out a few good ways to fix that.
  - psd1 3y ago
    You've conflated "easy" with "littering". The easiness of littering is an argument for littering, not against easiness.
  - allarm 3y ago
    So, there’s no better way.
  - jrm4 3y ago
    Easy is the correct metric if, like me, you believe the solutions to our major problems in the software space involve not "trying to get the few companies to behave better," but "trying to get MORE PEOPLE to understand -- and put in practice -- that this doesn't have to be in the hands of a few companies."

KronisLV 3y ago

> TBH, containers are the wrong way of doing things And yet, people still use VMs because the majority of software isn't perfect and pollutes whatever system it's running on to some degree. Just earlier today I saw a friend look at an install script for some software, which was set on freely installing apt packages, replacing the installed Node version, purging the apt repositories on the system (literally "rm -rf /etc/apt/sources.list.d/*", wtf) and a lot of things that no decently written piece of software should do on its own, at least not without explicit confirmation, but you still sometimes see out in the wild. The friend was reviewing the script after running it and wondering why their system was trashed. You often need some separation between what is your host system that needs to be pretty stable and the flaming mess that is whatever software that you'll install on it for productivity/entertainment/profit reasons, especially with easily configurable resource limits, custom port mappings, custom storage directories without access to the host system by default and eventually even horizontal scaling. Containers just happen to have really good DX around all of that and feel like the right way of doing things, in a flawed world.

watermelon0 3y ago
Dependency hell and polluting the system IS the problem. Ideally, we would have statically built self-contained executables, and OS would offer sandboxing (process, network, filesystem) out of the box. Containers at the moment are just lightweight VMs, and a better workaround to the problem (better especially in regard to UX; VMs isolation is still superior to cgroups/namespaces on Linux).
- nurple 3y ago
  The Linux OS literally provides sandboxing, we call the set of technologies that provide this "containers". "Containers" are not lightweight VMs; VMs are a virtualized computer, containers are a virtualized kernel. Statically linked everything is ridiculous and will never be the future of software deployment.
jmbwell 3y ago
In some cases, running docker containers using the vendor-provided docker compose file, inside a VM that you yourself provision according to your own needs using your own tooling (ansible etc), is the best approach, which at this point is ridiculous, but here we are.