重新审视长期支持版本

传统上，长期支持的操作系统版本一直是企业部署的中流砥柱。这是 IBM、Oracle、Microsoft、Suse 和 Red Hat 所采用的模式，自数十年前支持服务问世以来，它一直是围绕操作系统的传统思路。

过去，无论是服务器还是桌面操作系统版本，遵循这一模式都很常见，但具体到 Linux 领域，我们开始看到这种格局被打破，那些较为非正式的产品得以自由地尝试更为快速、不受支持或干脆毫无章法的发布方式。在主要的产品领域，openSuse、Fedora 和 Ubuntu 都提供了短期支持版本或快速发布版本。它们没有采用以年计的发布周期和逼近十年的支持周期，而是把发布周期缩短到了以月计，把支持周期缩短到了至多仅有数月或几年。

在桌面领域，更早地获得新功能和新应用程序，而不是像服务器上常见的那样主要专注于稳定性，往往是合情合理的，而且还带来了一项额外的好处：新技术或新方法可以先在发布周期更快的产品上得到测试，然后再被集成进长期支持的服务器产品之中。例如，Fedora 就是各种技术的试验场，这些技术在证明了自身价值之后，便会进入 Red Hat Enterprise Linux 的版本。通过使用 Fedora，最终用户能够更早地获得功能、更早地了解 RHEL 的技术，而 Red Hat 也得以在大规模环境中对产品进行测试，然后再将其部署到关键服务器上。

随着时间的推移，短期版本的稳定性已经得到了显著改善，这些系统也越来越多地被视为服务器系统的可行选择。这些系统能够更早地获得较新的增强、功能和升级，而这往往被认为是有益的。

任何操作系统的一大优势都在于其支持生态系统，其中包括作为基础操作系统一部分而受支持并提供的各种软件包和库。对于长期版本，我们常常会看到关键的软件包在版本的整个生命周期中急剧老化，这在极端情况下可能引发性能、兼容性乃至安全方面的问题。这显然迫使长期版本操作系统的用户在两者之间做出选择：要么继续忍受较旧组件的种种限制，要么自行集成新的组件–而后者往往会破坏长期版本产品的根本价值。

由于长期版本的目标是实现稳定性和集成测试，在产品内部替换组件以“绕开”LTS 的种种限制，就意味着这些组件并没有以 LTS 的方式得到对待，也意味着来自供应商的集成测试极有可能不再进行，即便仍在进行，其程度也大不如前。实际上，最终的结果是，它变成了一个自行搭建的短期版本产品，却带着陈旧的核心组件，并且缺乏足够的监管。

事实上，在大多数方面，这样做都比直接采用短期版本产品更糟糕。使用短期版本或快速发布的产品，可以让供应商维持人们所预期的那种测试与集成，只不过发布与支持周期更快而已，从而使长期版本这一理念的总体价值得以保留，并且操作系统的所有组件（而非仅仅其中少数几个）都会得到更新。这相比于半吊子的 LTS 模式，能够带来更高程度的标准化、行业测试以及知识与集成的共享。

或许，重新审视操作系统长期支持之价值的时候已经到了。在过于漫长的岁月里，这一做法的价值似乎只是被理所当然地默认并加以遵循，它当然曾经具有、如今也仍然具有其可取之处；但自从这一做法最初被引入以来，操作系统的世界已经发生了变化。对更新的需求在增加，而内核和库之类东西的变更速率却已大幅放缓。更强大的服务器把兼容性推向了技术栈中更高的层次，软件不再是针对某个操作系统而编写，而往往是针对某种特定版本的语言、运行时或其他抽象层而编写的。

更短的发布周期意味着系统能够更频繁地从上到下获得各种功能。“大版本”之间的更新更小，影响也更轻。来自更新的变化更具渐进性，从而提供了一条更为自然的学习与适应曲线。而最重要的是，那种需要用第三方提供的版本去替换经过精心测试与集成的系统组件的情况，实际上变得闻所未闻了。

对软件供应商而言，稳定性仍然是长期版本的一项价值所在，并将在今后很长一段时间里使长期版本仍有其使用的必要。但对系统管理员来说，这一做法的价值似乎正在减弱，而且我个人觉得，它在近年来已经迎来了一个拐点。曾几何时，为了等待软件包更新而苦等两三年似乎是意料之中且再正常不过的事，但如今这却让人感到不必要的累赘。一种情形似乎越来越常见：较高层级的组件在构建时要求有更新的底层组件；人们期望操作系统要么更为时新，要么操作系统的某些部分能够独立于其余部分单独更新。

对容器化技术的高度依赖也许会在某些方面扭转这一趋势，但其扭转的方式总是会同时削弱长期版本的价值。容器化降低了对基础操作系统具备广泛能力的需求，从而使更频繁地进行更新变得更容易、更有成效，以获得更好的内核、文件系统、驱动程序和容器支持，同时把库和其他依赖项留在容器之内–这样一来，那些需要长期支持依赖项的应用程序就可以通过这种方式得到满足，而那些能够受益于较新组件的应用程序也可以借此得到解决。

当然，虚拟化也在削弱长期支持模式的价值方面发挥了作用，因为它让系统的快速恢复与复制变得轻而易举。我们一直需要靠长期支持版本来解决的稳定性问题，如今已部分地由虚拟化层加以解决；硬件抽象以非常重要的方式改善了驱动程序的稳定性。同样地，devops 风格的支持模式也降低了对长期支持的需求，并让服务器生态系统变得更加敏捷、更加灵活。系统管理范式中的种种趋势正越来越倾向于更现代的操作系统。

这些趋势是否会沿着目前的方向继续下去，时间会给出答案。就我自己而言，过去这一年是令我大开眼界的一年，它见证了我把自己的工作负载从长达十年对超长期支持产品的坚定拥护，转向了快速发布的产品，而我必须说，我对这一转变非常满意。