| > debugging weird behavior because of a different version of some shared library I previously didn't know existed. Containers don't solve that issue, they simply allow you to ignore it. Not having to struggle to keep up with dependencies is the other side of the "containers are a security nightmare" coin. I once returned to a company after several years of being away. Of course nobody had bothered to update the dependencies in the old build. When I was working to fix and update the old build somebody informed me that the problem had already been "solved" by another team, and directed to me speak with that team's lead. They managed to get a new build with slightly updated dependencies working inside a container. They showed me the new build inside the Docker container. I asked some questions, they fumbled around to do a demonstration. It was clear that they hadn't solved anything. Instead of one problem, we now had two problems, as the new build environment couldn't be updated any easier than the old one. But it simply can't be denied that productivity will usually win over X, where X is security, technical debt minimization, etc. And the improved productivity comes from unlinking dependencies, particularly process dependencies more than actual software dependencies. I still prefer to package and bundle my projects, open source or internally, using RPM and Deb, or just the classic `make install prefix=/usr/local/foo` (support for the latter, with traditional GNU Make targets[1] and variables[2], makes building RPM and Deb infinitely easier). I know people will end up installing my projects into containers, but it's necessary all the same to ensure it's easier to keep those containers up-to-date. [1] https://www.gnu.org/software/make/manual/html_node/Standard-... [2] https://www.gnu.org/software/make/manual/html_node/Directory... |