Programming

13368 readers

2 users here now

All things programming and coding related. Subcommunity of Technology.

This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.

founded 1 year ago

MODERATORS

alyaza@beehaw.org

Hexorg@beehaw.org

remington@beehaw.org

IKEA-Oriented Development (taylor.town)

submitted 1 year ago by rknuu@beehaw.org to c/programming@beehaw.org

8 comments fedilink hide all child comments

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.

you are viewing a single comment's thread
view the rest of the comments

[–] aksdb@feddit.de 4 points 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.