@w568w #9 还是会绕不开统一分发的问题，比如 A 程序依赖 B/C 两个库，但是 B 是编译链接到 2024 版本的 stdlib 但是 C 是链接到 2025 版本的 stdlib ，这么下来依旧会出问题 结果就是整套动态库都得有多个版本。

因为一旦错失了时间窗口, 再想统一已经不现实了

没见过 VC++ runtime redist ？ C/C++ 生态是碎片化的，不像另外几个话语权完全在一两个组织手里。标准库用什么形式分发都可以，只是大家习惯了现在主流的方式。

另外你说的另外几种语言，运行时基本也都依赖 libc 的，有人帮它们负重前行。

@pursuer @unused #12 我也越来越觉得这个更是 Linux 的问题了。就像包管理和 init 的选择，永恒的碎片化…… @unused #13 是的，但作为最终用户和开发者其实都不用考虑这些，相当于有人做兼容了。而且只要有一个人做好兼容，其他用户都能获益。

打包运行时只是方便了开发者。对于用户来说可是深恶痛绝。谁也不想自己电脑里同时跑十几个不同版本的运行时把？

@fcten 比现状好吧，现状是「只允许同时用一个运行时，兼容性问题用户自己想办法」。在「让用户装多个运行时」和「让用户自己学习编译知识从头编译，或者为了你的软件升级整个系统」，我觉得还是前者方便点。

C/C++ 静态链接 musl-libc 和其他依赖， 不就达到 0 依赖了？ java 不会向前兼容， 老版本的 jre ，不能运行新版本 jdk 编译的 class

@bli22ard #17 理论上是这样，但实际上有很多依赖根本无法静态链接（作者写 Makefile 就没考虑到，比如 GNUStep ），或者依赖极其繁杂（例如 libcurl ），或者使用了 musl-libc 不支持的扩展（例如 onnx ）。感觉一切的坏头都是 glibc 起的……

@w568w #18 所以 linux 上的软件分发要依靠包管理器， 你要发行到哪个发行版的具体版本都是一定的。不然动态链接的软件，基本等于不能用。这依赖确实挺烦的。我搞 rust ， 就遇到过动态链接，要访问 https api ，依赖 openssl 搞的编译焦头烂额