Have to say, I wasn’t expecting this in my feed. It is a bit novel of a concept, but if you think about what it takes to build and ship a product, a lot of this makes sense, and modern languages are starting to follow the batteries included mentality (golang, rust).

There’s even an ironic naming ecosystem that just lends itself to this personification: flatpak and containers.

  • Phroon@beehaw.org
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    1 year ago

    My MarioKart 64 cartridge probably won’t inform me that Python2.7 was deprecated.

    It also won’t tell you if the OpenSSL library it uses has a vulnerability or not. I program mainly as a hobby and I still wonder how containers deal with that issue.

    • aksdb@feddit.de
      link
      fedilink
      English
      arrow-up
      4
      ·
      1 year ago

      I still wonder how containers deal with that issue

      They don’t. And neither do statically linked binaries. Those are valid concerns against both patterns.

      In the end you have to try to keep dependencies to a minimum and update those you have as often as feasible. That could mean that you have to rebuild your container images regularly, even if you didn’t change any code. Or that you rebuild your static binaries with newer libraries and toolchains from time to time.

      The main advantage you still get (from both) is that you can at least be sure, that the stuff that propagates between your stages into the production system doesn’t suddenly change, because one of the system libraries is a different version.

      Containers also allow your to sandbox your application to a larger degree so that when something goes wrong, it is atleast confined to cause the minimum harm. But the more complex your application, the bigger that “minimum” gets. Each dependency could end up being the key for an attacker to spread.