众所周知，一个非常基本的软件工程原理是松耦合。但我们知道，类 UNIX 操作系统中的程序是高度耦合的。如何解释/证明这一点？
我的意思是，程序之间的耦合度很高，有很多依赖关系，即使您想安装一个简单的应用程序，您也必须考虑很多依赖关系（正如您在应用程序管理器中看到的那样），有时甚至您无法更新程序，因为它会破坏一些依赖程序。确实，独立软件在Linux的美丽世界中很少见（与其他操作系统相比）。
答案1
这是合理的，因为总体而言，另一种选择是付出更多的努力而获得更少的收益。
几乎所有计算系统（可以说：所有系统，时期）都是分层构建的。每个平台都会对其下面的内容做出假设。ls假设会有一个 C 标准库。假设会有一个内核。假设会有计算硬件。假设会有稳定的电压等。
通过做出这些假设：我可以更快地编写代码。我可以做更多。我不关心捆绑 C 库、zip 库或加密库：其他人会这样做。当其他人决定改进或升级这些组件时，我会明显受益。所有其他共享该代码的程序也是如此。在一个连贯的系统中，它更快、更干净、更小、更好。
但是，正如您所注意到的，它更具依赖性。如果加密以不兼容的方式升级，我就会崩溃，包管理就会变得困难。为了真正解耦使包管理变得困难的依赖类型，组件需要内联它们的依赖。他们需要包含更多位于其下方的堆栈。而这正是问题的关键：为了创建一个具有较少依赖性的程序，我们需要一个能够理解更多内容的构建系统。这不是开发人员想要（或应该）花时间的地方。
您将当前的困境描述为“极度耦合”。人们已经尝试过让一切变得独立：结帐斯塔利，一个旨在保持所有二进制文件静态链接的 Linux 发行版。但极端的解耦也会带来同样的影响：想象一下每个程序都有一个虚拟机。
我们行业的惊人增长很大程度上归功于我们在以往基础上快速发展的能力。从字面上和隐喻上来说，我们都站在巨人的肩膀上。也许在未来，我们会吞掉一个巨人，作为让巨人变得更高的第一步。不过，就目前而言，妥协似乎大致正确：让我们继续攀登，并确保我们下面的巨人表现出色。
答案2
耦合性强吗？实际上，我认为“做好一件事”原则以及使用管道等来构建工作应用程序表明了松散耦合。当您运行时，例如 ps axf | grep vim，那么 ps 和 grep 的耦合性非常松散。
答案3
与 Unix 和类 Unix 操作系统不存在“极端耦合”。
极端解耦（即独立软件）是 Unix 诞生之初的常态，当时一切都在 CLI 上。
唯一值得注意的耦合代码是 shell 脚本本身，因为它们需要它们调用的命令可用。大多数这些命令都是默认安装的一部分，所以这不是问题。
引入大型库（如用于图形环境的库，X11、小部件工具包等）表明，将所有必需的库嵌入单个可执行文件中在存储空间（磁盘空间稀疏时可执行文件很大）和内存使用（相同代码大量重复，而 RAM 也很稀疏时）方面效率低下。然后引入了共享对象来克服这些限制。
我们现在面临的情况是，应用程序的依赖关系树可能非常复杂，通常是因为所需的库和类似文件。这个想法是让开发人员专注于他们的核心应用程序，并将其余的应用程序用于现有的东西，即不要重新发明轮子。
除了新版本破坏与旧版本的兼容性以及命名冲突（不包括在同一台计算机上一起安装的软件）引起的问题之外，这不会造成太大问题。这两个问题都可以（应该）通过良好的设计和标准来避免。