4 ms·

You can ship a list of your dependencies too. In my experience, VM centric deployment processes lead to extremely brittle programs. But I mean, ye, if you got

You can ship a list of your dependencies too. In my experience, VM centric deployment processes lead to extremely brittle programs. But I mean, ye, if you got a brittle mess, you better use VMs for deployment. I am not against using that method, as long as I gotta admit I've made a mess.

lnenad 3y ago
What are you talking about? A list of dependencies is less brittle than having a fully fledged env that is ready to go? In what world? Even if you use hard locked versions of deps there is a whole multiverse of problems you can encounter when compared to having everything ready to go that is identical to your expectations.
- nerdponx 3y ago
  Because unless your entire environment set up procedure is reproducible from top to bottom, something can break along the way. Whereas if you are already shipping a VM (or a container image, which on Linux is much lighter than a VM) you are really only relying on the VM runtime, everything else will work automatically if the VM runtime is working. It's only one thing that can break, only one thing you need to figure out how to fix in order to get the system working, instead of 1000 unknown and unknowable things. And if you're using some kind of hosted solution, you're literally paying for a working VM runtime.
- rightbyte 3y ago
  > A list of dependencies is less brittle than having a fully fledged env that is ready to go? In what world? The program is being made less brittle because it is tested in different environments and the practical max amount of dependencies are lower than shipping a custom distro for your program. I am not arguing that for a given program, it is less likely to execute properly in a shipped and tested VM image, than on a Sparc workstation running Solaris.
  - lnenad 3y ago
    So you're arguing something else entirely, gotcha. > The program is being made less brittle because it is tested in different environments and the practical max amount of dependencies are lower than shipping a custom distro for your program. If we're talking about web (which is my assumption since images don't make a lot of sense otherwise) there is exactly 0 benefits to testing apps in different environments since they're only going to be deployed in one, right? And either way if that changes you can specifically test for any other envs you want to run your app in, and not let your developers take that pain onto them by fighting deps/configurations along the way. Either way it's painfully obvious why one is better than the other.
- x86x87 3y ago
  How did people ever got anything done before the era of vms and curling bash scripts from the internet?
  - okdood64 3y ago
    Slowly and with frustration.
stavros 3y ago
The problem is that my dependencies depend on OS libraries, which then depend on my OS, which means I have to ship my OS, which... is what I'm doing.
drowsspa 3y ago
Binary dependencies are the issue. I find it pretty silly that C has 50 years and the deployment story is such a mess that we have multi billion dollar businesses basically just to tame it

lnenad 3y ago

What are you talking about? A list of dependencies is less brittle than having a fully fledged env that is ready to go? In what world? Even if you use hard locked versions of deps there is a whole multiverse of problems you can encounter when compared to having everything ready to go that is identical to your expectations.

nerdponx 3y ago
Because unless your entire environment set up procedure is reproducible from top to bottom, something can break along the way. Whereas if you are already shipping a VM (or a container image, which on Linux is much lighter than a VM) you are really only relying on the VM runtime, everything else will work automatically if the VM runtime is working. It's only one thing that can break, only one thing you need to figure out how to fix in order to get the system working, instead of 1000 unknown and unknowable things. And if you're using some kind of hosted solution, you're literally paying for a working VM runtime.
rightbyte 3y ago
> A list of dependencies is less brittle than having a fully fledged env that is ready to go? In what world? The program is being made less brittle because it is tested in different environments and the practical max amount of dependencies are lower than shipping a custom distro for your program. I am not arguing that for a given program, it is less likely to execute properly in a shipped and tested VM image, than on a Sparc workstation running Solaris.
- lnenad 3y ago
  So you're arguing something else entirely, gotcha. > The program is being made less brittle because it is tested in different environments and the practical max amount of dependencies are lower than shipping a custom distro for your program. If we're talking about web (which is my assumption since images don't make a lot of sense otherwise) there is exactly 0 benefits to testing apps in different environments since they're only going to be deployed in one, right? And either way if that changes you can specifically test for any other envs you want to run your app in, and not let your developers take that pain onto them by fighting deps/configurations along the way. Either way it's painfully obvious why one is better than the other.
x86x87 3y ago
How did people ever got anything done before the era of vms and curling bash scripts from the internet?
- okdood64 3y ago
  Slowly and with frustration.

stavros 3y ago

The problem is that my dependencies depend on OS libraries, which then depend on my OS, which means I have to ship my OS, which... is what I'm doing.

drowsspa 3y ago

Binary dependencies are the issue. I find it pretty silly that C has 50 years and the deployment story is such a mess that we have multi billion dollar businesses basically just to tame it