有没有专注于二进制向后兼容性的 Linux 发行版？

Question

如果您构建一个可在当前版本的 Windows 上运行的可执行文件，则该可执行文件可能会在较新版本的 Windows 上运行很多年。 Microsoft 非常努力地确保这一点。

对于 Linux，您期望拥有正在使用的软件的源代码，因此只要保持源兼容性，破坏二进制兼容性就可以。这导致发行版逐步淘汰旧的库版本，并定期破坏曾经有效的东西。

对于使用 Linux 作为游戏平台的人来说，这是一个问题，因为游戏往往仅以二进制形式分发。当 Linux 端口出现故障时，它会显得很糟糕，但我有一种感觉，尝试从总体上解决这个问题，而不是期望每个人都更新他们的端口，会更有成效。

是否有任何发行版试图保持二进制兼容性，不一定要保留所有旧版本，但至少要保留旧的 sonames，这样适用于版本 n 的二进制文件也应该适用于版本 n+1？

我能找到的最接近的东西是 Valve 的“Steam Runtime”，它是一个二进制兼容层，仅适用于通过 Steam 分发的程序。

Answer 1

基本上这可以归结为：你无法保持二进制兼容性并引入新功能，因为这些事情在大多数方面都是直接相互对立的。如果你最终引入了主要的新功能必须更改 ABI（通常在 API 更改后不久）。现在，您可以拥有版本化符号（就像 Glibc 那样），但这会使库的大小增加（并且在将二进制文件加载到内存中时也可能会产生一些性能损失），并且开发人员通常不希望保留它库（遗留代码包含没有人有兴趣修复的错误）。

在分发方面解决这个问题的通常方法有两个：

1. 不要更改版本 - 这是典型的企业级发行版，例如（按字母顺序排列）RedHat 和 SUSE，以及其他一些发行版（Debian、Slackware、Ubunty LTS 以及可能是它们的克隆版本）。

2. 允许同时安装不同版本的库。

在应用程序分发器上，处理方式与在 Windows 上相同：将所需的所有内容填充到分发包中。是的，这就是 Windows 上经常采用的方式 - 这也是典型 Windows 系统的磁盘空间要求通常比具有相同功能的 Linux 高几倍的原因之一 - 应用程序之间仅共享很少的内容，并且在某处有自己的副本。您可以将其视为每个 GTK/Qt 应用程序都带有自己的 GTK/Qt 堆栈。它可以有一些优点，但缺点也很多。例如，从安全角度来看，Technicolor ^TM就是一场噩梦。如果二进制文件是静态链接的，甚至是全高清的。