……就是在那个时候，我开始为位于不同大洲数据中心的大量服务器编写软件。出于必要，我不得不让我的软件更加健壮且易于管理。它必须与其他我无法控制的大量东西共存。它必须是静态链接的，我所需要的一切都必须放在一个地方，这样就可以轻松地安装和卸载。（当我开始用Java编写软件时，最终变成了所有功能都在一个JAR文件中）。而且，我不能对软件运行的环境做出太多假设。UNIX本应该重新思考如何处理软件，但这种情况从未发生。我认为一个重要原因是，当你让人们重新想象某样东西时，它会变得更为复杂。我们就是无法控制自己。看看我们是如何重新设计服务管理的，比如systemd。是的，现在它已经成熟了一些，人们也逐渐习惯了，它并不糟糕。但它也并不好。其中没有任何部分是简单的，也没有任何部分是优雅的。就连命令行工具都很别扭。……
源讨论为什么会出现容器？原帖 280 条评论 · 导入时统计这基本上是对的。但更普遍的问题是，工程师们已经失去了将应用程序及其依赖项简洁地打包成易于分发和运行的包的能力。大约在同一时期，Java让.jar文件变得主流（只是把所有东西都压缩成一个zip文件并加上清单），而其他领域却完全忘记了如何像静态链接库那样做，而我们现在运行的是高度调度的多线程操作系统。 长期以来的“解决方案”是为每个应用程序启动单独的虚拟机，这是一种沉重的方式来解决问题，这减少了应用程序可用的整体系统资源，使它们成为低效的解决方案。现代云技术就是在这一阶段发明的，这就是为什么所有当前云系统的基本组件之一是虚拟机。 容器解决了依赖分发问题，…
完整原文把你的经验，加入这段讨论。
我同意你的观点，问题在于打包。而且让开发者尝试打包软件是问题所在。他们往往会设计出最复杂的构建系统来处理所有情况，最终结果是脆弱且难以处理的。 还有就是过于严格的依赖列表，因为每个依赖项本身也乐于每6个月就打破它的API。
完整原文> UNIX本来可以重新思考一下如何处理软件，但这种情况从未发生。 我认为它确实重新思考过，但Unix世界存在一种根深蒂固的“非我发明”综合症，以及一种深层次的文化抗拒，不愿承认其他系统（操作系统、语言等）在某些方面做得更好。 NeXTstep在1980年代中期到晚期解决了很多问题。它抛弃了X，用Display Postscript替代。它抛弃了一些传统的文件系统布局，用.app包替代：每个应用程序都有自己的目录结构，以及所有依赖项。隔离和依赖打包合二为一。 （NeXT意识到这一点很重要，但它必须是可读且用户友好的。它用更易读的东西替换了传统的文件系统。15年后，Nix意识到了同样的教训，但忘记了第二点，所以它抛弃了传统的FHS，用一个非常复杂的系统替代了它。…
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。