3 ms·
Packaging your software into a container-image accomplishes almost exactly the same thing, without the need to be using a stack that can create standalone stati
by derefr 5y ago
Packaging your software into a container-image accomplishes almost exactly the same thing, without the need to be using a stack that can create standalone static binaries.
I would point out, though, that even when you can just continue to use a single pinned version of a Docker image forever (because the program itself is stable, or is part of a stable system that only uses the program in precise ways), people still value regular releases, and see non-upgrading images as “rotting” — because they can contain vendored deps, and those deps can have security vulnerabilities discovered in them over time.
- hsn915 5y agoI haven't worked a lot with Docker or similar containerization tools, but my impression is they require you to have an internet connection to download stuff. At least with Docker, when you write or download a docker file for the first time, it's just a description of stuff that needs to be downloaded and maybe commands that need to be executed. This kind of thing is qualitatively much worse than a statically linked executable binary in terms. > a stack that can create standalone static binaries. Yea, a language that has the notion of a compiler is a MUST if you actually care about this kind of thing.
- 0xCMP 5y agothey're specifically talking about the resulting image built using whatever dockerfile you had. they can be exported to a file or pushed to repos to be reused elsewhere.
- dehrmann 5y agoDocker is especially bad for this. A jar file that runs today will probably run fine in 10 years on future Java. The container might, but it almost certainly has a huge number of security vulnerabilities, and maybe no one uses AMD64 and ARM anymore.