作者： Linux内核历史：哪些决策真正影响服务器
从0.01到7.x，梳理Linux改用GPLv2、坚持单体内核、诞生Git及采用LTS模式的经过，并说明这些选择如何影响服务器、驱动和专有软件。
Linux 内核历史简述
Linux 内核的发展历程从 1991 年 9 月的 0.01 版本延续至今，7.x 系列已经可以在服务器上启动。版本发布列表并不是其中最值得关注的部分。少数几个决策决定了 Linux 的基本形态，而且每个决策至今仍会影响您今天租用的服务器。要理解 1991 年为什么需要一个新的内核，请参阅Unix、AT&T 许可协议以及导致 BSD 发展停滞的诉讼这一更长的历史。
本文中的日期和版本号来自 kernel.org 及其发布的版本历史。截至 2026 年 8 月，7.0 已于 2026 年 4 月 12 日发布，7.1 已于 2026 年 6 月 14 日发布，7.2 正处于候选发布阶段。
为何 1992 年选择 GPL 至今仍然重要
0.01 版于 1991 年 9 月 17 日发布，使用的是 Torvalds 自行编写的许可证。该许可证要求分发源代码，并加入了一条更为关键的规定：“不得收取费用分发本软件，即使是‘处理’费用也不行。”1991 年，软件通过软盘发布，而复制和邮寄软盘都需要成本。这一条款使商业 Linux 发行版无法实现。
他随后修改了许可证。转向 GNU General Public License（GPL）的消息发布在 1992 年 1 月的 0.12 版发行说明中，并于 1992 年 2 月 1 日生效。1992 年 3 月的 0.95 版是首个根据该许可证发布的版本。后来建立在 Linux 之上的每项业务，都以这次变更为基础。
内核仅采用 GPL version 2，从未转向 version 3。Torvalds 在 2007 年拒绝了这一转变，主要原因是 GPLv3 中的反 tivoisation 条款。该条款要求，搭载 GPL 代码的设备也必须接受该代码的修改版本。他认为锁定硬件属于制造商自己的业务。2017 年，内核开发者发布了 Kernel Enforcement Statement，其中仍借用了 GPLv3 的一项规定：收到违规通知后修复违规行为的人可以保留其许可证，而不是在首次违规时永久失去许可证。
这会在服务器上产生两个后果。你启动的内核二进制文件附带获取对应源代码的权利，因此任何人都不能向你提供一个你无法检查或重新构建的 Linux 内核。内核中的版权声明还说明，该许可证不涵盖通过普通系统调用使用内核服务的用户程序。因此，专有数据库和监控代理可以为 Linux 发布，而不会造成许可证冲突。宽松型许可证会产生相反的约束。在选择平台前，理解这一差异很有价值：参见 Linux 和 FreeBSD 作为服务器平台。
实践中单体内核为何胜出
1992年1月29日，Andrew Tanenbaum 在 comp.os.minix 新闻组发布了一条标题为 “LINUX is obsolete” 的消息。他提出了两项主张。单体内核将驱动程序和文件系统运行在同一个特权地址空间中，是20世纪70年代的设计；微内核则让这些组件作为普通进程运行，代表未来。另一个主张是，Linux 与 Intel 386 紧密绑定，因此永远无法移植到其他平台。
移植工作回应了可移植性方面的质疑。1995年3月发布的 Version 1.2 增加了 Alpha、SPARC 和 MIPS 支持。1996年6月发布的 Version 2.0 增加了64位 Alpha 移植版本。
一个折中方案回应了设计方面的质疑。Linux 从未变成微内核。它采用了可加载内核模块：可以插入正在运行的内核、也可以再次移除的目标文件。因此，驱动程序可以独立于内核二进制文件发布。
lsmod | head
modinfo virtio_net | head -5lsmod 列出当前已加载的内容。modinfo 打印模块来源文件及其接受的参数。在虚拟服务器上，磁盘和网络路径中的大部分功能都是模块，因此同一个内核映像可以在此前从未接触过的硬件上启动。内核只负责报告新硬件，用户空间守护进程则决定加载哪个模块以及如何命名设备。设备管理因此逐渐纳入 init 系统，这也是 systemd 变得难以回避的原因之一。
模块带来了这种灵活性，同时避免了微内核设计的开销。将驱动程序隔离到独立进程中后，每次调用都需要进行上下文切换并传递消息，而在1992年，这种开销很大。
Linux 保留的代价才是需要重点规划的问题：模块拥有完整的内核权限，因此有问题的模块会导致整台机器宕机，而不是只影响一个进程。外部模块最容易出现这种问题。不在主线内核中的厂商驱动程序，必须针对每个新内核重新构建。升级期间，DKMS 就负责执行这项工作；如果构建失败，设备在重启后就会直接缺失。
SMP 用了 15 年才完成
1996 年 6 月发布的 Linux 2.0 首次支持对称多处理（SMP），即多个 CPU 运行同一个内核。最初的实现使用单个锁，即大内核锁（BKL），因此同一时间只能有一个处理器进入内核代码。这样，第二个 CPU 可以帮助主要在用户空间执行计算的工作负载，但对系统调用工作负载帮助很小，因为这些调用都要在同一把锁后排队。
移除这把锁用了 15 年。剩余的使用点改为细粒度锁，主要由 Arnd Bergmann 完成；BKL 最终在 2.6.39 中删除，该版本于 2011 年 5 月 18 日发布。调度器也经历了同样缓慢的演进：2.6.0 引入 O(1) 调度器，2007 年发布的 2.6.23 引入完全公平调度器（CFS），2023 年 10 月发布的 6.6 则使用 EEVDF 取代了 CFS。
正因为这些工作，现在选择 4 vCPU 的方案已很常见。但其中有一个限制值得了解。在共享虚拟服务器上，内核负责调度您的线程，而 hypervisor 负责调度您的内核。运行 top，然后读取 %st 字段。steal time 表示您的内核已准备使用、但主机分配给其他 guest 的 CPU 时间，因此无法通过调整内核来恢复这部分时间。
2.6 系列为何改变了内核的构建方式
在 2.6 之前，版本号由两个部分组成。第二个数字为偶数时表示稳定系列（2.4），为奇数时表示开发系列（2.5）。2.4 于 2001 年 1 月 4 日发布，2.6 于 2003 年 12 月 17 日发布，因此用户需要等待将近 3 年才能使用下一个稳定系列。发行版无法等待这么久，因此会回移补丁。两个都标为“2.4”的厂商版本，所包含的内核补丁可能相差数千个。
2.6 之后，稳定系列与开发系列的划分被取消。现在，主线会开放大约 2 周的合并窗口，接收新的工作，然后持续发布候选版本，直到代码趋于稳定；随后每 9 到 10 周发布一个版本，这也是 kernel.org 目前记录的节奏。该模型的另一部分于 2005 年 3 月 4 日形成：稳定树首次发布。它是针对 2.6.11 的仅修复更新，由 Greg Kroah-Hartman 和 Chris Wright 维护。稳定树接收修复，但拒绝新功能。
这一变化带来的一个影响是：版本号不再代表某种承诺。3.0、4.0、5.0 和 7.0 都不是重写版本。当第二个数字大到让 Torvalds 感到不便时，他会提高第一个数字。这就是 7.0 在 2026 年 4 月紧随 6.19 发布的原因。对于服务器而言，重要的是发行版跟踪哪个分支，以及该分支是否仍能获得修复。
BitKeeper 事件如何在 2005 年 4 月催生 git
从 2002 年 2 月起，内核从 2.5 系列开始使用 Larry McVoy 的公司 BitMover 开发的专有分布式版本控制系统 BitKeeper。BitMover 向内核开发者免费提供许可证，但附带条件：不得开发竞争性的版本控制工具，也不得对 BitKeeper 进行逆向工程。许多开发者不愿使用一个禁止他们阅读其代码的工具来开发自由内核。
2005 年 4 月，Andrew Tridgell 演示了一个可以与 BitKeeper 仓库通信的程序，事件由此爆发。BitMover 认定这属于逆向工程，并收回了免费许可证。内核在一个开发周期中途失去了版本控制系统。
git 于 2005 年 4 月 3 日开始开发。Torvalds 于 4 月 6 日宣布了 git。4 月 7 日，git 已能自托管，也就是说，git 自身的历史已经存储在 git 中。4 月 18 日，git 完成了首次多分支合并。2005 年 6 月，git 管理了 2.6.12 的发布。此后不久，Torvalds 将维护工作交给 Junio Hamano，自己回到内核开发。
这个设计直接源于当时的问题：数千名贡献者，以及需要在无人信任的网络上相互拉取代码的维护者。每个对象都以其内容的哈希命名，因此修改旧历史中的一个字节，就会改变其后每个提交的名称。这就是为什么克隆是证据，而不是声明。每条部署流水线、每个配置仓库、大多数团队推送代码的代码托管平台以及可以自行运行的 git 服务器，都源于一场围绕内核展开的许可证争议。
LTS 模型承诺什么，以及不承诺什么
Mainline 不是实际运行的版本。Mainline 版本会在 9 到 10 周后被后续版本取代。每次发布后，stable 分支还会持续接收几周的修复。Longterm 分支通常称为 LTS，会持续接收数年的修复，发行版正是基于这些分支构建的。
2.6.32 于 2009 年 12 月发布，它证明了这一模型可行。RHEL 6、Debian 6、SUSE Linux Enterprise 11 SP1 和 Ubuntu 10.04 LTS 都发布了基于该版本的系统；这个分支一直维护到 2016 年 2 月，也就是发布后超过 6 年。Red Hat 走得更远：它通过自行维护的 backport 持续维护基于 2.6.32 的内核，直到 RHEL 6 于 2020 年终止支持；免费复现这段长达 10 年的支持，正是 CentOS 存在以及 Rocky Linux 和 AlmaLinux 取代它的原因。
这项承诺已经不止一次调整。最初是 2 年，后来部分分支延长到 6 年。2023 年，stable 维护者将默认期限缩短回 2 年，因为向旧分支回移植修复会占用维护者时间，而旧分支几乎没有实际测试。2026 年 2 月 25 日，Greg Kroah-Hartman 与依赖这些分支的公司讨论后，再次公布了更长的预计期限；当前框架的支持周期为 3 到 6 年。
The data behind this chart
[
{
"kernel": "5.10",
"released": "2020-12-13",
"eol_projected": "Dec 2026",
"maintained_for": 6.0
},
{
"kernel": "5.15",
"released": "2021-10-31",
"eol_projected": "Dec 2026",
"maintained_for": 5.1
},
{
"kernel": "6.1",
"released": "2022-12-11",
"eol_projected": "Dec 2027",
"maintained_for": 5.0
},
{
"kernel": "6.6",
"released": "2023-10-29",
"eol_projected": "Dec 2027",
"maintained_for": 4.2
},
{
"kernel": "6.12",
"released": "2024-11-17",
"eol_projected": "Dec 2028",
"maintained_for": 4.1
},
{
"kernel": "6.18",
"released": "2025-11-30",
"eol_projected": "Dec 2028",
"maintained_for": 3.1
}
]截至 2026 年 8 月，kernel.org 列出了 6 个 longterm 分支。最旧的分支 5.10 终止支持时，将已持续提供 6.0 年的修复，预计终止时间为 Dec 2026。最新的分支 6.18 预计维护到 Dec 2028，也就是提供 3.1 年的修复。
应将这些日期视为最低期限，而不是合同承诺。6.6 和 6.12 的预计支持期限都在 2026 年 2 月延长过；如果某个分支无人使用，也可能提前停止维护。通常由发行版替您做出选择：Debian 13 使用 6.12，Ubuntu 26.04 LTS 使用 7.0。服务器上选择 LTS 还是 interim release 的问题的实际含义就在于此；当您将 Ubuntu 24.04 升级到 26.04时，底层真正发生变化的也是这一点。
由此还会产生一个误区。在 Ubuntu 24.04 上，uname -r 会输出类似 6.8.0-51-generic 的内容。这表示上游基础版本加上发行版自己的 backport，因此版本号只能说明该分支从哪里开始，不能说明其中包含哪些修复。扫描器仅根据内核版本字符串判断时，会因此将发行版内核误报为存在问题。
内核当前正在争论什么
目前有两项争论，核心都是由谁来完成工作。
Rust 于 2022 年 12 月在 6.1 中作为基础设施引入。到了 7.0，实验性标签被移除，因此内核的核心语言包括 C、assembly 和 Rust，构建也不再需要 nightly compiler。争论焦点在于维护工作。C 维护者修改接口时，可能会破坏自己并不查看的 Rust 绑定，双方争论的是由谁负责修复这些绑定。
第二项争论涉及 AI 贡献。随着机器辅助补丁数量不断增加，Sasha Levin 于 2025 年 7 月提出了一项政策。该文档于 2025 年 12 月 23 日提交，如今位于内核自己的流程文档中：docs.kernel.org/process/coding-assistants.html。AI agent 不得添加 Signed-off-by 标签，因为该行用于证明 Developer Certificate of Origin (DCO)，而只有人可以作出此证明。使用 AI 辅助应通过 Assisted-by: 标签声明；该标签在审查期间由 Co-developed-by: 修改而来，因为工具不是作者。生成的代码必须兼容 GPL-2.0-only。提交补丁的人必须审查补丁，并对其承担责任。
推动这项政策的压力来自审查时间。生成补丁只需几秒，而审查一个补丁可能占用维护者整个下午。标签无法消除这种不平衡，但可以保留来源信息：历史记录会继续记录每项变更由谁签署，这正是 DCO 于 2004 年推出时要保护的属性。
这段历史对您租用的服务器意味着什么
- 许可证使您能够阅读和重新构建服务商启动的内核，也使专有软件仍能在其上运行。
- 单体内核设计意味着一个驱动程序错误就可能重启整台机器，也意味着每次内核升级都必须重新构建树外模块。
- 发布模式意味着版本号提供的信息很少，而分支及其生命周期结束日期几乎决定了全部信息。
- 虚拟化类型决定了您能否执行相关操作：在 KVM 上，您可以启动自己的内核并加载模块；而在共享宿主机内核的容器虚拟化环境中，
uname -r显示宿主机的版本，modprobe会失败，并且多个 sysctl 参数为只读。
FAQ
Linux 内核为什么仍然采用 GPLv2，而不是 GPLv3？
Torvalds 在 2007 年决定不采用 GPLv3，主要原因是 GPLv3 的反 Tivoisation 条款。该条款要求发布 GPL 代码的设备同时允许用户运行这份代码的修改版本。Torvalds 认为锁定硬件属于制造商的业务选择。实际上，重新授权也几乎不可能，因为内核的版权由数千名贡献者持有，而且没有可供依赖的版权转让协议。Linux 内核采用 GPL-2.0-only，因此仅以 GPLv3 提供的代码不能合并。
Linux 内核是单体内核还是微内核？
Linux 是带有可加载模块的单体内核。驱动和文件系统运行在内核地址空间中，lsmod 会显示当前已加载的模块。这带来两方面影响：一方面速度更快，另一方面故障影响范围更大。错误模块可能导致整台机器内核崩溃，而微内核通常只会丢失一个进程。自 1992 年以来，这种差异有所缓和，因为 FUSE 文件系统可以运行在用户空间中，eBPF 程序也会在运行前由内核验证。
mainline、stable 和 longterm 内核有什么区别？
mainline 是 Torvalds 的代码树，每 9 到 10 周发布一次，新功能会首先进入其中。stable 基于最近的 mainline 版本，并在数周内接收错误修复。longterm 分支会持续数年接收修复，发行版通常基于这些分支构建内核。kernel.org 会列出当前的 longterm 分支，并为每个分支提供预计的生命周期结束日期。
Linux 内核接受 AI 编写的代码吗？
接受，但须遵守 2025 年 12 月确定的政策。必须在 Assisted-by: 标签中注明所使用的工具，AI agent 不得添加 Signed-off-by 行，生成的代码必须兼容 GPL-2.0-only。提交者需要进行签署确认，表示其已审查补丁，并依据 Developer Certificate of Origin 对补丁负责。
服务器应该运行哪个内核版本？
几乎所有情况下，都应运行发行版维护的版本。发行版内核由 longterm 分支、回移的修复和厂商测试组成，云服务商提供的镜像及支持服务也都以此为基础。只有在需要特定驱动或功能时，才应构建更新的 mainline 内核。迁移到某个分支前，应先检查其生命周期结束日期，再决定是否采用。