回到我使用 Windows 的时代，应用程序都是以独立的方式安装的。这给最终用户/系统管理员留下了很大的自由来决定升级什么、在哪里升级、修补什么以及何时修补，而不会干扰其他应用程序。
在 *NIX 中，纠缠的依赖关系是令人头痛的。 PC-BSD 试图克服这个问题聚苯醚，通过创建独立的应用程序。 AFAIK，这现在似乎已被弃用，他们返回到包管理方式（PBI 现在是端口的包装器），并且所有 Linux 发行版都以相同的方向运行：数百个依赖项到最后，甚至桌面环境预计将依赖于系统管理守护进程。
基于数百个依赖项构建应用程序使程序员的生活更轻松，但给最终用户和系统管理员带来了令人震惊的问题。例如，我无法再在 Debian Jessie 中运行古老的 Debian Etch 版本的应用程序。我知道很多人都会带着安全、补丁和最新系统的故事而来，但开源意味着可以自由地决定更新内容、更新时间和地点。有非常充分的理由不更新系统或其一部分，或者至少不按照典型的 *NIX 包管理器引导用户的方式进行更新（即离线工作的机器、旧硬件、与需要更新的旧数据的兼容性）。保留以确保合规性，...）。其他时候，为了安全起见，系统管理员更喜欢分几个步骤进行。
就我个人而言，我认为我作为系统管理员应该决定更新什么、何时更新，并承担风险。以目前的情况来看，这是不可能的。 （即 Debian 中有新版本的 libc6，到处都有依赖项）。如果我决定保留两个或更多存储库来解决这个问题，我就会产生另一个噩梦。
我知道某些依赖项（即安装了 MySQL）是可以接受的，因为这是一个主要依赖项，但我无法理解为什么像库这样的微小依赖项不简单地嵌入到代码中。盘很便宜。许多移植到 Windows 的 Linux 应用程序都实现了这一点。
编辑：确保它不仅仅是基于意见
在 *NIX（为简单起见，我们将其称为 Debian/FreeBSD）中安装软件的选项有哪些，以便：
保持软件的单个特定版本运行多年而无需升级，并确保无论后续基础操作系统和库升级如何，都可以保持不变，等等易于保持但永远。
决定升级/降级而不与其他软件/库发生冲突。
安装该软件的两个或多个版本。
Jails/chroot/VM 不是选项，尽管它们是明显的解决方法。还，
- 是什么导致 PBI 未能实现返回端口/包管理的独立目标？
答案1
我无法回答为什么 PBI 不成功，但我可以回答为什么共享库在 Linux 中受到青睐。
主要论点是安全性，如果常用的库中存在漏洞，则只需更新该库，而不是使用该库的所有应用程序（由于 ABI 兼容性）。这也意味着（如果您主要坚持主要存储库和 PPA（对于 Ubuntu）），您不必安装 4 个不同版本的库，仅仅因为您的应用程序是针对这些版本编译的（例如 Windows ，您可能会在其中安装不同版本的 .NET 库，或者安装不同版本的 Visual C++ 运行时）。
尽管如此，在某些情况下，应用程序可能不会被迫使用系统版本的库，而是可以使用自己的版本。例如，Chromium 依赖于大多数发行版存储库中存在的许多库。在正常情况下，应用程序将被编译，以便它们使用的库是发行版编译的库。然而，在 Ubuntu 中（至少），Chromium 是使用自己版本的库进行编译的，因为：
- 使用系统版本的库意味着 Chromium 必须针对每个 Ubuntu 版本进行测试。
- Chromium 在很大程度上已经使用最新版本的库，这意味着存在漏洞的可能性要低得多。
至于磁盘空间的争论，您可能会说安装debootstrapDebian Jessie 的 ed 版本需要不到 1 GB 的磁盘空间，这对于较小的 SD 卡来说非常适合。另一方面，Windows 需要至少几千兆字节的磁盘空间。
对于较旧的软件，您可以静态编译应用程序，并使大部分依赖项都是独立的。但是，由于您的发行版可能没有可用的静态版本的库（Debian 和 Ubuntu 在大多数情况下没有），因此您需要自己编译这些库才能获取这些库的静态版本。
最后，Unix 的原则之一是每个应用程序只做一件事，并且擅长做这件事。如果应用程序和库是静态链接的，那么它们可能被认为（间接）做很多事情。