5 ms·

Being able to ship a self contained binary of your application is a very powerful concept, on which many seem to agree. The way I see it, pip and virtualenv ar

Being able to ship a self contained binary of your application is a very powerful concept, on which many seem to agree. The way I see it, pip and virtualenv are not practical for deployment or distribution. You shouldn't have to download and install things during a production deployment. I even created a tool (https://github.com/objectified/vdist https://github.com/objectified/vdist) to mitigate this problem, but it will always be a hack when doing it this way.

_yy 11y ago
Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.
- falcolas 11y ago
  > update the shared library, restart affected services ... look for programs to break at runtime because of some unrelated API change in the shared library.
  - _yy 11y ago
    That's why Debian Stable and RHEL exist. Security patches don't break the API.
    - falcolas 11y ago
      > Security patches don't break the API. shouldn't When the patched library is not part of Debian Stable or RHEL's repositories (for example, if you require features from a release less than a year old) all bets of API stability are off. OpenSSL and libc are not the only libraries which are patched for security that people use.
      - jvoorhis 11y ago
        And heaven help you if RedHat decides not to backport a critical bugfix. OpenSSL on CentOS 6 has 99 patch files, a script named "hobble-openssl" and non-trivial changes to the build system that affect linkage, making DIY backports less than trivial.
    - marssaxman 11y ago
      I am willing to believe that they come closer to the ideal than others, but nobody is perfect, and I'd rather discover incompatibilities myself, when I'm getting a new version of my app ready, before shipping, instead of trying to understand why random users are incoherently reporting impossible app failures.
- zwischenzug 11y ago
  Which only needs to happen once.
  - _yy 11y ago
    Yes but still. If you have a procedure in place to recompile and redeploy everything, you could just deploy the libraries as well.
    - protomyth 11y ago
      Plus, the system admin doesn't just have to wait on the new security-patched library to be ready, they have to wait for everyone who used Go to recompile and distribute their programs.
    - jakub_h 11y ago
      So you're redeploying one binary instead of another binary. You still need to deploy something. In fact, what about just switching connections to freshly launched VMs?
  - deleted 11y ago
    [deleted]
- IshKebab 11y ago
  Yeah that's the usual refrain, but the only situation where you have shared libraries is on Linux with a package manager. In that case it is trivial to recompile all packages that depend on the insecure library anyway. On Windows you have to package most shared libraries with your app anyway so you have to get a new version of it anyway.
  - _yy 11y ago
    Sure but that's one of the reasons I use Linux.
- jerf 11y ago
  Yeah, but... that's not really the "usual procedure" though. Nobody who knows what they are doing literally downloads openssl manually, compiles the new shared library, manually installs it, and manually restarts the affected services, on the grounds that if you do that you have just proved you don't know what you are doing. (Most charitably, you're doing a "Linux From Scratch" for educational purposes, but that's just about the only valid reason.) Once you have introduced package management and/or system management tools, it doesn't seem like a significantly different problem anymore, and likely to be utterly swamped by the other bigger problems that appear at scale.
  - _yy 11y ago
    No, you update the shared library using your distribution's package manager and then restart the affected services using one of the small scripts for that purpose. What's the issue with that?
ChrisArgyle 11y ago
> The way I see it, pip and virtualenv are not practical for deployment or distribution. You shouldn't have to download and install things during a production deployment. I even created a tool (https://github.com/objectified/vdist https://github.com/objectified/vdist) to mitigate this problem, but it will always be a hack when doing it this way. Please excuse my newbness but doesn't python wheel do most of this (besides compiling to a single package)?
- sametmax 11y ago
  Not under linux, but it's coming. Alhough they have no way to include big dependancies like QT and the like.
im_down_w_otp 11y ago
Why not just follow the Erlang/OTP practice of creating a "release" which contains everything you need, including the runtime system, deps, and your code into a self-contained tarball?

_yy 11y ago

Remember that critical Go security update? Usual procedure - update the shared library, restart affected services. Go - recompile everything.

falcolas 11y ago
> update the shared library, restart affected services ... look for programs to break at runtime because of some unrelated API change in the shared library.
- _yy 11y ago
  That's why Debian Stable and RHEL exist. Security patches don't break the API.
  - falcolas 11y ago
    > Security patches don't break the API. shouldn't When the patched library is not part of Debian Stable or RHEL's repositories (for example, if you require features from a release less than a year old) all bets of API stability are off. OpenSSL and libc are not the only libraries which are patched for security that people use.
    - jvoorhis 11y ago
      And heaven help you if RedHat decides not to backport a critical bugfix. OpenSSL on CentOS 6 has 99 patch files, a script named "hobble-openssl" and non-trivial changes to the build system that affect linkage, making DIY backports less than trivial.
  - marssaxman 11y ago
    I am willing to believe that they come closer to the ideal than others, but nobody is perfect, and I'd rather discover incompatibilities myself, when I'm getting a new version of my app ready, before shipping, instead of trying to understand why random users are incoherently reporting impossible app failures.
zwischenzug 11y ago
Which only needs to happen once.
- _yy 11y ago
  Yes but still. If you have a procedure in place to recompile and redeploy everything, you could just deploy the libraries as well.
  - protomyth 11y ago
    Plus, the system admin doesn't just have to wait on the new security-patched library to be ready, they have to wait for everyone who used Go to recompile and distribute their programs.
  - jakub_h 11y ago
    So you're redeploying one binary instead of another binary. You still need to deploy something. In fact, what about just switching connections to freshly launched VMs?
- deleted 11y ago
  [deleted]
IshKebab 11y ago
Yeah that's the usual refrain, but the only situation where you have shared libraries is on Linux with a package manager. In that case it is trivial to recompile all packages that depend on the insecure library anyway. On Windows you have to package most shared libraries with your app anyway so you have to get a new version of it anyway.
- _yy 11y ago
  Sure but that's one of the reasons I use Linux.
jerf 11y ago
Yeah, but... that's not really the "usual procedure" though. Nobody who knows what they are doing literally downloads openssl manually, compiles the new shared library, manually installs it, and manually restarts the affected services, on the grounds that if you do that you have just proved you don't know what you are doing. (Most charitably, you're doing a "Linux From Scratch" for educational purposes, but that's just about the only valid reason.) Once you have introduced package management and/or system management tools, it doesn't seem like a significantly different problem anymore, and likely to be utterly swamped by the other bigger problems that appear at scale.
- _yy 11y ago
  No, you update the shared library using your distribution's package manager and then restart the affected services using one of the small scripts for that purpose. What's the issue with that?

ChrisArgyle 11y ago

> The way I see it, pip and virtualenv are not practical for deployment or distribution. You shouldn't have to download and install things during a production deployment. I even created a tool (https://github.com/objectified/vdist https://github.com/objectified/vdist) to mitigate this problem, but it will always be a hack when doing it this way. Please excuse my newbness but doesn't python wheel do most of this (besides compiling to a single package)?

sametmax 11y ago
Not under linux, but it's coming. Alhough they have no way to include big dependancies like QT and the like.

im_down_w_otp 11y ago

Why not just follow the Erlang/OTP practice of creating a "release" which contains everything you need, including the runtime system, deps, and your code into a self-contained tarball?