Linux

Linux 是一系列自由开源的类 Unix 操作系统，以 Linux 内核为核心。内核是管理硬件、内存、进程和文件的核心程序。严格来说，内核只是其中的一个组成部分：一个完整的系统还需要把它与用户空间工具、函数库、初始化系统以及应用软件结合起来，通常以发行版的形式打包发布。由于其用户空间的大部分组件来自 GNU 计划，一些人更倾向于将其称为 GNU/Linux，这一命名选择至今仍存在争议。

Linux 之所以重要，是因为它已成为历史上部署最广泛的软件平台之一。它运行着大多数公共网站服务器和云基础设施，几乎所有超级计算机，以及大多数智能手机所使用的 Android 操作系统。它的开发模式是一个基于开源软件许可的大型分布式协作项目，这种模式也深刻影响了现代软件的编写、共享和资金筹集方式。

本词条将追溯 Linux 的起源：20 世纪 90 年代初，Linus Torvalds 因不满 MINIX 以及更广泛的 Unix 传统的局限，着手开展内核项目；随后梳理 GNU 计划以及许可决策如何使该内核发展为一个完整的自由系统。接着考察内核的技术架构、用户空间与启动过程，以及将变更从贡献者推进到主线版本的开发周期。后续章节涵盖许可与商标安排、发行版的多样性、图形栈，以及主要应用领域，包括服务器与云计算、超级计算，以及嵌入式和移动设备。词条最后讨论安全实践、引入 Rust 等技术演进、基于商业公司与基金会的生态系统、采用情况的衡量，以及仍然存在的批评与未解决的问题。

定义：内核、操作系统与发行版

严格来说，"Linux"仅指内核，即直接运行在硬件之上、调解每个程序访问硬件的核心程序。单独的内核并不能构成一台可用的计算机。完整的操作系统是将内核与用户空间软件组合在一起的产物，用户空间软件包括C标准库、命令行 shell、核心实用工具、初始化系统、编译器和各类库。发行版则更进一步，它是对内核版本、用户空间、安装程序、默认配置、软件包管理器以及发布与支持政策进行精心挑选和打包后的整体。Debian、Fedora 和 Arch 都是发行版，它们各自对这些层次作出了不同的选择。

各层的分工有所不同。内核运行在特权处理器模式下，负责只有它才能执行的任务。用户空间程序运行在非特权模式下，通过系统调用请求服务。发行版决定选用这些组件的哪些版本、如何安装和更新，以及提供多长时间的支持。由于各层可以相互分离，同一个内核可以支撑差异很大的系统，从服务器、路由器到手机都有它的身影。

内核的职责

内核的首要职责是调度：决定哪个可运行的任务占用哪个 CPU 核心，以及占用多长时间。这是一种分时系统的形式，同时也协调着并发计算的工作。主线 Linux 从 2.6.23 版本（2007 年）起采用完全公平调度器（CFS），并在 6.6 版本（2023 年）改用 EEVDF。

在内存管理方面，内核为每个进程提供独立的虚拟地址空间，并通过页表将其映射到物理内存（RAM）上。当内存不足时，内核会将页面换入换出到存储设备，并决定内存耗尽时如何处理。虚拟文件系统层为 ext4、XFS、Btrfs 等多种磁盘格式提供统一的接口，因此程序无需知道其文件位于哪种文件系统上。

设备驱动程序负责把通用请求转换为特定硬件的操作，它们在内核源代码中所占的比例最大。包括 TCP/IP协议族 和包过滤在内的网络协议栈同样运行在内核中。最后，进程隔离使各个程序彼此分开。每个进程都有自己的地址空间，用户和组标识符限制对文件和资源的访问，硬件特权级别则阻止普通代码执行特权指令。命名空间及相关机制进一步扩展了这种隔离，并为后来的容器技术提供了支撑。良好的隔离是网络安全的核心。

命名之争

自由软件基金会与理查德·斯托曼（Richard Stallman）主张，完整的系统应当称为 GNU/Linux。他们的理由是：到 20 世纪 90 年代初，GNU 计划已经开发出了围绕内核的大部分编译器、库和实用工具，因此不应只把全部功劳归于内核。许多发行版、大多数新闻工作者以及 Linux 基金会则用"Linux"指代整个系统，大多数用户也是如此。这一术语之所以重要，是因为命名决定了哪些项目和贡献者能够获得认可，而这一问题也与后来关于许可证和商标的讨论相关。

作为"家族"的 Linux

在日常用语中，"Linux"泛指任何基于 Linux 内核构建的系统，包括 Android 和嵌入式路由器固件。严格来说，这些系统是共享同一内核、却在用户空间、初始化系统、软件打包和治理方式上各不相同的独立操作系统。像 FreeBSD 和 OpenBSD 这样拥有独立内核的类 Unix操作系统 则根本不是 Linux，尽管它们遵循相似的设计惯例。区分内核、操作系统和发行版，可以避免同一个名称被用于三者时产生的混淆。

Unix 与 MINIX 的起源（1980 年代至 1991 年）

Unix 的谱系与 MINIX 的限制

Unix 最初由 Ken Thompson 于 1969 年在贝尔实验室编写，1973 年改用 C 语言重写。一项反垄断法院命令要求 AT&T 将其非电话技术授权给任何提出请求的人，因此许多大学开始在课程中使用 UNIX。随着 AT&T 逐渐将 Unix 视为商业产品，授权情况也随之改变。第 7 版发行时附带的许可证禁止课程研究其源代码，以此将其作为商业机密加以保护。

Andrew S. Tanenbaum 编写 MINIX 正是为了回应这一限制。MINIX 于 1987 年发布，是一个供学术用途的类 Unix 系统，用来说明他的操作系统教科书中的原理。它的局限对托瓦兹而言十分重要。尽管源代码可以获取，但修改和再分发受到限制；此外，MINIX 的 16 位设计并不适合价格低廉、广受欢迎的 Intel 386 所具备的 32 位特性。

托瓦兹的 386 电脑与 1991 年 8 月的公告

Linus Torvalds 当时是赫尔辛基大学的学生，正在一台基于 Intel 80386 的个人电脑上工作。他对 MINIX 不满意，于是着手编写自己的内核。1991 年 8 月 25 日，他在 Usenet 新闻组 comp.os.minix 上发帖，介绍了一个面向 386（486）AT 兼容机的（免费）操作系统，并称这只是一个爱好，不会像 GNU 那样庞大而专业。他说这项工作自 4 月起就已在酝酿，并询问读者不喜欢 MINIX 的哪些地方，因为出于实际考虑，他的系统在某种程度上与 MINIX 相似，甚至采用了相同的物理文件系统布局。此时他已经移植了 bash 和 gcc，一切似乎运转良好。

这篇帖子同时也说明了其限制。代码不可移植，因为它使用了 386 的任务切换功能，而且很可能永远不会支持 AT 硬盘以外的设备。托瓦兹强调，代码中不含任何 minix 代码。

0.01 版（1991 年 9 月）

1991 年 9 月 17 日，托瓦兹将 0.01 版放到了芬兰大学网络 FUNET 的 FTP 服务器上，此次发布并未公开宣布。这个首版远非可用的系统。它甚至无法直接执行，因为其代码仍需借助 Minix 才能编译和测试。源代码规模不大：0.01 版共 88 个文件、10239 行代码。其功能也很有限，包括基本的内存管理、任务切换以及对 i386 处理器架构的支持，但缺少图形界面和许多驱动程序。托瓦兹后来将这一发布描述为对当时感兴趣者的一种象征性表示。下一版 0.02 于 1991 年 10 月 5 日发布，其公告称它已能运行 bash、gcc、gnu-make、gnu-sed、compress 等程序。

类 Unix 设计，但不含 Unix 代码

Linux 借鉴了 Unix 的模型，但并未复用 Unix 的源代码。内核是从零开始编写的，但它实现了相同的核心抽象：进程作为执行单位，文件和目录组织在同一棵树中，文件具有用户和组权限，并通过一组系统调用作为程序向内核请求服务的方式。托瓦兹在此期间正在研究 POSIX 标准，这表明与 Unix 接口保持兼容是一个有意为之的目标。早期的 Linux 开发随后扩展了这些接口，以对应 BSD UNIX 和 System V UNIX 的功能。

GNU 计划、GPL 与第一个完整的自由系统

GNU 计划是这段历史的前半部分。GNU 于 1983 年 9 月 27 日宣布成立，1984 年 1 月开始开发。理查德·斯托曼（Richard Stallman）发起该计划，旨在开发一个完整的操作系统，让用户能够研究、修改和再分发。"GNU" 是一个递归缩写，意为"GNU 不是 Unix"。其设计沿袭了 Unix，原因在于 Unix 已经广泛流行，并且运行在比当时 CP/M 和 MS-DOS 系统更强大的机器上。斯托曼的动机一方面是麻省理工学院人工智能实验室中程序员之间的共享文化正在瓦解，另一方面是他坚信，不仅应用软件，操作系统本身也必须是自由软件。

该项目完成了系统中大部分的用户空间部分。其程序员编写了编译器（GCC）、C 语言库（glibc）、构建系统（make）、命令行解释器（Bash）、编辑器（Emacs）等。到 20 世纪 90 年代初，剩下的缺口是内核。GNU 尝试过多种设计，包括 TRIX，随后又尝试了 Mach 微内核，并于 1990 年开始在 GNU Mach 之上开发 Hurd。Hurd 始终未能达到可用于生产环境的水平。当 Linux 内核被证明是一个可行的解决方案后，GNU Hurd 的开发便放缓了。

授权问题起到了决定性作用。GNU 通用公共许可证是一种 copyleft 许可证：任何人再分发受该许可证保护的程序，无论是否修改，都必须遵循相同的条款并提供源代码。Linux 0.01 并未采用该许可证。最初，托瓦兹以禁止任何商业用途的许可证发布 Linux。这一限制后来成为问题：在贸易展会上以软盘分发内核的用户询问，能否收取少量费用以弥补成本。托瓦兹认为，源代码的免费获取并不要求禁止这种行为。自 1992 年 1 月发布 Linux 0.12 起，托瓦兹为内核采用了 GPL。发布说明中写明，GNU copyleft 将于 1992 年 2 月 1 日生效。一些二手资料将这一转变的时间定在 1992 年 12 月，对应 0.99 版本的发布；但 0.12 版本的公告是更早且记录更完善的事件。

这一点之所以重要，是因为 GPL 允许公司销售和分发 Linux，从而促进了商业发行版的出现，同时又防止任何厂商将内核据为私有。贡献者可以放心，他们的改进将持续向所有人开放。加上 GNU 工具链，内核构成了一个整体上完全自由的系统。1992 年，Linux 内核以 0.12 版本首次采用 GPLv2 发布，从此可以运行一个完全由自由软件组成的操作系统。Linux 从来不只是狭义上替代 GNU 缺失的内核。第一个版本就依赖于 GNU 软件：Linux 内核的首个版本 Linux 0.01 就包含了 GNU Bash 命令行解释器的二进制文件。托瓦兹自己的说明也提醒，仅有内核是没有用的。要得到一个可以工作的系统，还需要命令行解释器、编译器、库等。

二者的结合迅速走向成熟。0.01 版本有 88 个文件、10,239 行代码，并且无法编译自身。到 1991 年 12 月，0.11 版本已能够自我编译（self-hosting）；0.12 版本又增加了作业控制和磁盘分页（虚拟内存）。有一种历史叙述认为，正是从这时起，非内核开发者的普通用户开始安装它。1992 年，内核获得了运行 X 窗口系统的能力，使 GNU/Linux 系统上可以拥有图形桌面。

1.0 版本于 1994 年 3 月 14 日发布，其原始源代码约为 176,250 行。这个版本标志着该项目性质的转变。正如版本号所示，它是第一个被认为适合用于生产环境的版本。周边生态也随之变化：1993 年出现了 Slackware 和 Debian 发行版，1994 年 Red Hat 加入其中。不过，是否适合生产环境取决于具体的工作负载和硬件，1.x 和 2.x 系列仍在不断增加对新架构、网络和多处理器的支持。关于完整系统应称为"Linux"还是"GNU/Linux"的命名争议，将在单独的小节中讨论，但其根源正是在这一时期：内核与 GNU 用户空间合并为一个实际可用的系统。

内核架构：宏内核设计与核心子系统

Linux 是一个宏内核。在这种设计中，核心操作系统服务（调度、内存管理、文件系统、设备驱动和网络）都运行在同一个特权内核地址空间中，彼此之间直接以普通函数调用的方式交互。另一种方案是微内核，它只在特权模式下保留最小的核心，把大部分服务放到独立的用户空间进程中，通过消息传递进行通信。Linux 在 20 世纪 90 年代初选择了宏内核模型，这一选择塑造了它的性能特征、驱动模型以及对稳定性的处理方式。

宏内核设计与可加载模块

在宏内核中，所有核心服务共享同一个地址空间，并以完整的硬件特权级别运行。其优势在于速度：一个请求从文件层进入块层，只是一次直接调用，而不需要进程间消息传递以及随之而来的上下文切换。其代价是，内核任一部分出现故障都可能破坏共享状态，进而导致整台机器崩溃。

Linux 通过可加载内核模块（LKM）缓解了这种模型的僵化问题。如果没有模块机制，要增加对某个新设备或文件系统的支持，就必须重新链接内核并重启。模块是一个可以在运行时由内核插入的目标文件，insmod 和 modprobe 等工具用于加载和卸载模块，lsmod 则列出当前已加载的模块。模块最常用于设备驱动和文件系统，这使得发行版可以提供一个通用的内核包，只加载某台机器所需的驱动。内核的配置选项有三种：某个功能可以直接编译进内核映像、编译为模块，或者完全不包含。启动早期需要访问根文件系统的代码，可能被编译进内核，也可能通过初始内存文件系统（initramfs）提供。

然而，模块化是一种打包层面的特性，而不是隔离层面的特性。模块一旦加载，就会以内核权限运行在内核空间中，并且可以直接访问内核数据结构。模块中的严重缺陷可能导致系统崩溃或被攻破，其后果与内置代码中的缺陷并无二致。

主要子系统

内核的各个主要子系统相互依赖，其中进程调度器处于核心位置：当进程等待硬件操作时，其他子系统会将其挂起，待操作完成后再恢复运行。

• 进程调度器。 它决定哪个可运行的任务获得 CPU，以及运行多长时间，需要在公平性、吞吐量和延迟之间取得平衡。多年来，默认策略是完全公平调度器（CFS）；从 Linux 6.6 开始，普通任务改由 EEVDF 取代，而实时调度策略仍然独立存在。调度器还负责抢占管理，使长时间运行的任务能够被中断。
• 内存管理。 每个进程都拥有自己的虚拟地址空间，内核通过内存管理单元所查询的页表，将其映射到物理内存上。该子系统负责分页、换出到磁盘、用于文件数据的页缓存，以及内核自身小对象的 slab 分配。它还负责进程之间的隔离，并在多路处理器机器上支持 NUMA 感知的内存分配。
• 虚拟文件系统（VFS）。 VFS 为程序提供了一套统一的操作，如 open、read、write 和 stat，具体工作则交由文件系统驱动完成。Ext4、XFS 和 Btrfs 位于其下层，NFS 和 SMB 等网络文件系统同样如此。正是这一层使程序无需关心文件位于本地磁盘还是远程服务器上。
• 设备驱动。 按代码体量计算，设备驱动占内核源代码树的最大比例。它们涵盖存储控制器、网卡、图形设备、USB 以及许多其他总线，其中很多以模块形式发布。
• 网络协议栈。 内核实现了 TCP/IP 协议、套接字接口、路由和数据包过滤。防火墙框架（netfilter，iptables 和 nftables 等工具都基于它）位于网络数据路径之中。
• 安全框架。 Linux 安全模块（LSM）钩子允许挂接 SELinux 和 AppArmor 等访问控制系统，内核还提供能力（capabilities）和命名空间（namespaces）机制。这些内容将在安全一节中详细讨论。

进程间通信（管道、信号、System V 和 POSIX 消息队列、共享内存）是内核的另一项服务；而在多处理器机器上，中断处理和加锁原语则为上述所有功能提供支撑。

系统调用边界与特权级

在 x86 及大多数其他架构上，处理器会强制实施特权级。内核代码运行在最高特权模式下，通常称为 0 环（ring 0），而用户程序运行在特权较低的 3 环（ring 3）。用户程序不能直接访问硬件、页表或其他进程的内存。它必须通过系统调用接口来请求这些操作，该接口是进入内核的受控入口。

系统调用通常由一条特殊指令触发，该指令将处理器切换到特权模式，并跳转到固定的内核入口点。内核会检查参数（参数可能指向用户内存，使用前必须进行校验），执行所请求的操作，然后返回用户模式。glibc 等库会将这些调用封装为普通的 C 函数，因此大多数应用代码并不直接发出系统调用。由于所有特权操作都必须经过这一狭窄而单一的接口，内核便能一致地实施权限和资源限制。

与微内核的权衡及 1992 年的争论

与微内核的对比是 Linux 历史上最核心的架构争论。在 Mach、QNX 或 seL4 等微内核中，驱动和文件服务器作为独立的用户空间进程运行。驱动崩溃后可以在不重启系统的情况下重新启动，而隔离边界由硬件强制实施。代价是每一次跨服务交互都要变成一条消息，这会带来额外开销，而且这种设计也更难高效实现。

这场争论于 1992 年 1 月公开化。MINIX 的作者 Andrew Tanenbaum 在 comp.os.minix 新闻组上发表了一篇批评文章，标题为“LINUX is obsolete”（意为“Linux 已经过时”），认为宏内核设计较为低劣，并且对 x86 架构的依赖是短视之举。Linus Torvalds 回复说，性能在实际中很重要；微内核并没有让可移植性或驱动开发变得更容易；而他所构建的设计正运行在人们真正拥有的硬件上。他承认，微内核在某些方面确实更加优雅。这一争论在 2006 年被再次提起，那时多数系统中的性能差距已经在不同程度上缩小，但基本的权衡依然存在。

宏内核设计在几个方面塑造了 Linux 的开发实践。由于驱动运行在内核中，开发工作的很大一部分投入到驱动审查、测试和静态分析上，并努力让驱动合并进主线代码树，而不是在树外单独维护。内核不承诺为驱动提供稳定的内部编程接口，这促使硬件厂商向上游贡献代码。Oops 和 panic 报告、类似 lockdep 的加锁检查以及各类消毒器（sanitizer）等机制，很大程度上都是为了捕捉那些微内核会自动隔离的故障而存在。近年来，内核加固工作和更新的编程语言致力于减少此类故障的数量，同时又不放弃共享地址空间所带来的性能优势。

用户空间、启动过程与初始化系统

从开机到第一个用户空间进程

Linux 系统的启动是一连串固定的接力过程，每个阶段都为下一阶段准备运行环境。第一阶段是机器的固件（BIOS 或 UEFI），它负责初始化基本硬件并选择启动设备。随后固件启动引导程序，最常见的是 GRUB 2 或 systemd-boot。引导程序读取自身配置，将内核映像和初始内存文件系统（initramfs）载入内存，并把一条内核命令行传给内核，其中包含根文件系统所在位置等参数。

接下来由内核接管。内核先解压自身，设置内存管理，探测总线和设备，并加载已编译进内核或所需的驱动模块。由于根文件系统可能位于某个驱动本身就存储在该文件系统上的硬件中，内核并不总能直接挂载真正的根文件系统。这就是 initramfs 存在的原因：它是一个小型 cpio 归档，内核会将其解压到一个内存盘中。其中包含最基本的工具和驱动，并且必须提供一个名为 <code>init</code> 的可执行程序。该程序会加载存储设备所需的任何模块，定位并检查真正的根文件系统，然后将其挂载。随后这个临时环境被丢弃，根文件系统上真正的 init 程序以进程 ID 1（PID 1）的身份执行。这个第一个用户空间进程是系统中所有其他进程的祖先，它负责启动服务、挂载其余文件系统、配置网络，并最终通过 getty 或图形化显示管理器提供登录界面。

每当内核或相关驱动发生变化时，发行版都会使用 dracut、mkinitcpio 或 update-initramfs 等工具重新生成 initramfs。系统无法启动，往往说明该映像缺少磁盘控制器或文件系统的驱动。

初始化系统

初始化系统是内核之后第一个启动的程序，它决定了用户空间的其余部分如何启动。它的职责包括：按合适的顺序启动守护进程，监督这些进程以便在服务失败时重启，处理挂载点和套接字，收集日志，并提供启动、停止和检查服务的命令接口。

systemd 是大多数主流发行版的默认初始化系统，包括 Debian、Ubuntu、Fedora、RHEL 系列以及 Arch Linux。它使用声明式的单元文件，显式建模单元之间的依赖关系，支持套接字激活和总线激活，并集成了日志和许多其他系统功能。其功能范围很广，这也是偏好更小型 init 的人最主要的批评点。其他替代方案体现了不同的设计取向。OpenRC 是 Gentoo 的默认选择，也用于 Alpine，它将服务保存为 <code>/etc/init.d</code> 下的 shell 脚本，在脚本中声明依赖，并通过运行级别组织启动过程。runit 则采取相反的思路：一个服务就是一个包含 run 脚本的目录，监督由小型进程完成，没有内置的依赖图，因此启动顺序需要手动管理。s6 是一套带有依赖数据库的监督套件，dinit 则将监督器与依赖处理结合在一起。SysV 风格的 init 曾经是标准，如今仍存在于一些发行版中，也仍有若干系统在使用。

因此，选择初始化系统改变的不只是服务的启动方式。它还会影响发行版必须附带哪些服务文件、如何处理用户级服务、有多少代码以 PID 1 的身份运行，以及最小化安装会占用多少资源。

用户空间的基础

Linux 系统上几乎每个程序都依赖 C 标准库，它把普通的库函数调用转换为内核提供的系统调用。两种最常见的实现是 glibc 和 musl。glibc 即 GNU C 库，首次发布于 1988 年，是 Debian、Ubuntu 和 Red Hat Enterprise Linux 的默认选择。它以 LGPL 许可证发布，兼容性广，提供大量 GNU 扩展和成熟的性能调优，代价是二进制文件和内存占用较大。musl 首次发布于 2011 年，采用 MIT 许可证。它力求严格遵循 ISO C 和 POSIX 标准，体积小巧，常见于极简容器和 Alpine Linux 中。由于它的行为有所不同，例如动态库卸载的处理方式以及一些非标准的 printf 格式，针对 glibc 编写的软件在 musl 上运行时有时需要打补丁或重新编译。

C 库之上是 shell，通常为 Bash、dash 或其他兼容 POSIX 的 shell，它们负责运行启动脚本和交互式会话。GNU 核心工具集，如 coreutils、findutils、grep、sed 和 tar，提供了脚本和管理员所使用的基本命令。许多发行版在 initramfs 映像和极小型系统中会改用 BusyBox，这是一个将这些工具的精简版本打包在一起的单一可执行文件。

软件包、配置与启动层

启动层和服务层依赖于由包管理器放置和维护的文件。安装内核软件包会将内核映像和模块添加到 <code>/lib/modules</code> 下，并由一个钩子脚本重新生成 initramfs 和引导程序配置。安装 SSH 服务器等服务软件包会添加一个单元文件或初始化脚本，随后管理员将其启用，使初始化系统在开机时启动它。包管理器还会记录每个配置文件归属于哪个软件包，从而使升级时能够区分默认文件与本地修改过的文件。

配置分散在多个位置，启动过程会按顺序读取它们。引导程序的设置存放在 <code>/etc/default/grub</code> 等文件中，或存放在 <code>/boot</code> 下符合引导加载器规范（Boot Loader Specification）的条目中。<code>/etc/fstab</code> 文件告诉早期启动和初始化阶段需要以何种选项挂载哪些文件系统。网络、主机名和区域设置由在用户空间早期阶段启动的服务读取。上述任何文件出错，或已安装的内核与其 initramfs 不匹配，都可能导致系统无法进入登录界面，这也是恢复模式、救援 shell 和启动时内核参数至今仍是 Linux 系统管理标准组成部分的原因。

开发流程：邮件列表、维护者与发布周期

Linux 的开发采用分层体系，包括子系统负责人、公开的邮件列表审阅以及固定的发布日程。内核源代码树被划分为网络、内存管理、体系结构支持、视频等子系统。大多数子系统都有指定的维护者，负责该部分代码，并通常决定某个补丁能否进入主线内核。维护者记录在源代码树的 MAINTAINERS 文件中，该文件列出各领域的负责人、邮件列表和 Git 仓库。大型子系统之下往往还有子维护者，因此一项变更可能要经过多棵树，才能到达顶层。这种结构是该项目能够吸纳海量开源工作、却不依赖单一企业所有者的原因之一。

维护者、邮件列表与补丁审阅

贡献者将修改整理为补丁，在本地测试后，发送邮件到受影响子系统的邮件列表，并抄送名单中的维护者。审阅是公开进行的：审阅者逐行评论、要求修改，作者则发布修订后的补丁系列。维护者各自掌管自己的树，并将补丁接收进来。子系统准备就绪后，其维护者会请求上一级拉取这些工作，因此被接受的变更会沿着一连串的树逐级向上推进。

处于这一链条顶端的是 Linus Torvalds，他维护主线树并担任最终整合者。他并不亲自审阅每一个补丁，而是从数量相对较少的顶层维护者那里拉取代码，对这些拉取请求中单个变更的关注程度各不相同。在子系统树与主线之间，还有一棵集成树 linux-next，它合并众多维护者的待处理工作，以便在下一个合并窗口之前暴露冲突。

发布周期：合并窗口、候选版本与正式发布

主线开发按照固定的时间节奏进行。Torvalds 发布一个版本后，会开启约两周的合并窗口。在此期间，维护者发送带签名的 Git 拉取请求，携带已就绪的功能和修复，大量变更在短时间内进入代码树。窗口关闭时，Torvalds 标记第一个候选版本 rc1，开发周期随之切换为仅修复缺陷的模式。

此后，候选版本大约每周发布一次，编号依次为 rc2、rc3 等。这一阶段不再接受新功能，工作集中于回归问题以及撤销有问题的变更。错过合并窗口的工作必须等待下一个周期，这一规则保证了日程的可预测性。内核被判定为足够稳定后，便发布正式版本，下一个合并窗口随即开始。整体节奏大约为每个版本九周，因此人们常说内核版本大约每两到三个月发布一次。

版本号与稳定分支

内核版本号记录的是先后顺序，而非变更的规模。自 3.x 版本起，次版本号大致保持在二十以内，以免读者误以为次版本号较大就意味着改动较大。主版本号本身没有内在的技术含义，因为项目承诺主版本号变化时接口依然保持稳定。因此，2026 年从 6.x 跳到 7.0 是一个命名上的决定，并不意味着内核被重写。

主线版本发布之后会有稳定分支，这些分支只接收缺陷和安全修复。修复先提交到主线，再挑选合入较旧的分支；这一回移植步骤需要在周边代码不同的地方调整补丁，经过测试后作为小版本发布。Greg Kroah-Hartman 长期领导这项稳定版维护工作。部分分支被指定为长期支持（LTS）版本，会获得数年的修复；某些 LTS 分支还由外部项目进行更长时间的维护。

Git 与分布式开发

整个工作流程以 Git 为基础。Torvalds 于 2005 年创建了 Git，因为内核项目需要一个分布式版本控制系统，而内核的开发模式至今仍依赖它。每位维护者都保存一份完整的历史副本，发布自己的分支，并请求上游拉取已签名的提交。官方主线仓库和稳定版代码树托管在 kernel.org 上，这使数以千计的贡献者能够并行工作，同时保证最终代码树可追溯。同样的模式也解释了为什么合并被记录为提交，而不是非正式的文件传递，以及为什么各个独立的代码树能够在集成测试中被自动协调。

许可证、版权与商标

GPL-2.0许可证与系统调用例外

内核依据GNU通用公共许可证第2版（仅限GPL-2.0）授权，并附加了一项例外。该例外写在单独的文件Linux-syscall-note中，其中规定版权不涵盖通过常规系统调用使用内核服务的用户程序。换句话说，普通的内核调用不会使程序变成衍生作品。这一例外对用户空间API头文件最为重要，程序必须包含这些头文件才能与内核通信。这些头文件必须能够被包含到任何用于创建在Linux内核上运行的可执行文件的源代码中，因此它们带有一个特殊的许可证表达式GPL-2.0 WITH Linux-syscall-note，以标明它们可以被非GPL代码使用。

"仅限第2版"的措辞是有意为之的。Torvalds在内核COPYING文件中的说明指出，除非某个文件另有明确声明，内核唯一有效的GPL版本就是这个确切的第2版，而不是2.2版、第3版或之后的版本。因此，内核代码不能简单地与GPL-3.0代码合并，这一限制影响了哪些项目可以与内核共享代码。

Copyleft与衍生作品

GPL是一种copyleft许可证：任何分发修改版或衍生版本的人都必须传递相同的自由。其实际适用范围取决于代码所处的位置。根据该例外，在用户空间运行、仅通过系统调用接口与内核交互的程序被视为内核的普通用户，而非衍生作品。内核模块则不同。每个模块都通过标签（MODULE_LICENSE）声明其许可证，这使内核能够标记已加载的模块是自由的还是专有的；而设计为在内核地址空间内运行的模块通常被视为衍生作品。由此形成了内核空间与用户空间代码之间的界线，企业在发布产品时必须对此加以跟踪。

分散的版权

内核没有单一的版权所有者。COPYING说明将GPL的版权归于自由软件基金会，而它所指的代码实例（Linux内核）的版权则归我和其他实际编写了代码的人所有。因此，每位贡献者都保留其自身补丁的版权，项目并不要求将版权转让给某个中央机构。贡献者的代码则通过开发者原创声明（Developer's Certificate of Origin）下的签署（sign-off）流程进行认证。

这种模式直接影响重新授权。若要更改内核的许可证，就必须获得仍保留在代码树中的每一位版权持有者的同意，或删除、重写其代码。执法也是共同承担的：版权持有者已集体请求外部组织代表他们行事。例如，GPL合规项目（GPL Compliance Project）由Linux内核中的版权持有者组成，他们依据GPLv2为Linux作出了贡献。

商标

"Linux"一词的管理与代码分开进行。在美国，Linux商标归Linus Torvalds所有，Linux Mark Institute代表Linus Torvalds管理该商标，适用于包括Linux内核在内的计算机软件。Linux基金会（Linux Foundation）持有该商标的独占分授权（sublicense）权利，Torvalds先生已将相关权利转让给它，其明确目的是持有并行使该商标的独占分授权权利。

目前的安排源于20世纪90年代末的一场争议。Torvalds在开始开发其操作系统时，并未打算为"Linux"一词争取商标保护，但到1996年，他开始希望自己当初这样做了。此后，对早先一项注册的异议得以和解，商标转归Torvalds所有，并由Linux International负责管理。Torvalds曾表示，执法是必要的：他说，"停止侵权或获取商标分授权"的函件是维持商标权的必要条件。分授权被描述为：免费——获批的分授权持有者无需支付费用；永久——分授权仅在违反协议或其所在组织停止使用该商标时终止；全球通用。被分授权者可以检查并监督自身的使用情况，但不得暗示Linux基金会或Torvalds对其产品作出了认证（）。商标并不涵盖代码本身，这也是名称与GPL通过各自独立的机制运作的原因。

合规与执法

GPL要求，所分发的产品必须附带完整且对应的源代码，或应请求提供。执法有着悠久的历史。在德国，2004年的Welte诉Sitecom案认定GPL可依德国法律执行。在美国，Verizon被指控在无线路由器中分发BusyBox，却未提供对应的源代码；2008年3月宣布的和解中包括一项遵守GPL的协议。2009年，软件自由保护协会（Software Freedom Conservancy）提起的诉讼点名了14家公司，到2013年9月，除一家之外，其余公司均同意和解。

近期最引人注目的案件是SFC诉Vizio案。2021年10月，软件自由保护协会（SFC）起诉Vizio公司，指控其在某些Vizio智能电视所含软件中违反了GNU通用公共许可证。不同寻常的是，这家非营利组织是以客户而非版权持有者的身份提起诉讼的。SFC主张，它是GPLv2的第三方受益人。关于该案进展的报道并不完全一致：Torvalds在2025年12月的一篇帖子中庆祝了该案的一项裁决，而SFC的案件页面则列出了2026年底的开庭日期；2026年5月的一篇报道则称，裁决将在庭审结束后三至六个月内作出，而庭审目前定于8月10日。截至本文撰写时，我无法确认庭审的结果。

相关争议也显示了这些规则如何跨越国界运作。在汉堡，一名版权持有者针对VMware提起的诉讼因程序性理由被驳回；在VMware出于无关原因移除了争议中的copyleft材料后，原告未再上诉。

发行版：家族、包管理与发布模式

发行版（常简称为 "distro"）将 Linux 内核与用户空间软件组合在一起，这些软件包括 C 库、命令行解释器、核心工具集、初始化系统、图形组件、安装程序、包管理器以及支持政策。由于内核基本相同，各发行版之间实际的差异主要体现在这些层面。

主要家族

大多数发行版源自少数历史悠久的项目。Slackware 1.00 发布于 1993 年 7 月 16 日，该项目至今仍在维护，是现存最古老的 Linux 发行版。Debian 同样始于 1993 年，是一个社区项目，其稳定版、测试版和不稳定版分支为众多衍生版本提供基础。Ubuntu 基于 Debian，在开发周期中会从 Debian 不稳定版导入大量源码包；Linux Mint 和 Pop!_OS 则又以 Ubuntu 为基础构建。

Red Hat 家族以商业产品 Red Hat Enterprise Linux（RHEL）为核心。CentOS Linux 曾基于 RHEL 的源代码构建，而 Rocky Linux、AlmaLinux 等重新构建项目则致力于与 RHEL 保持二进制兼容；Fedora 则作为上游的社区测试平台。SUSE 家族包括 openSUSE Leap、openSUSE Tumbleweed 和 SUSE Linux Enterprise。Arch 家族包括 Arch Linux 及其衍生版，如 Manjaro 和 EndeavourOS。Alpine Linux 是一个独立的极简发行版：它替换了大部分常规用户空间组件，使用 musl 取代 GNU C 库，使用 BusyBox 取代 GNU 核心工具，使用 OpenRC 取代 systemd，并以 apk 作为包管理器。Gentoo、Void 和 Solus 也是独立项目，各自拥有独特的工具体系。

包管理器与依赖模型

每个家族都将一种包格式与两层工具搭配使用。底层工具负责安装单个包文件：dpkg 用于 Debian 的 .deb 格式，rpm 用于 Red Hat 的 .rpm 格式。它们不会自动去获取缺失的依赖；如果交给 rpm 一个依赖未满足的包，它只会直接拒绝安装。高层工具位于其之上：APT、DNF、Zypper 和 pacman 会读取软件仓库的元数据，计算出所需的完整包集合，检查冲突，下载所需文件，然后按正确顺序调用底层工具。

主要组合如下：

• Debian 与 Ubuntu：.deb 包，由 APT 运行于 dpkg 之上。软件仓库被划分为 main、contrib 和 non-free 等组件。
• Red Hat、Fedora 及 Rocky/Alma：.rpm 包，由 DNF 管理。DNF 取代了 YUM，采用了现代的依赖求解器。
• openSUSE 与 SUSE：.rpm 包，由 Zypper 管理。
• Arch：压缩格式的 .pkg.tar.zst 包，由 pacman 管理。pacman 是一个同时负责安装和依赖解析的单一工具。
• Alpine：.apk 包，由 apk 管理。

这些包管理器通常不能互换，因为每个包都是针对某一家族的库版本和文件布局构建的。依赖解析是一个难题，不同管理器之间的实际差异主要体现在冲突处理、回滚支持和软件仓库的广度上。

固定发布与滚动发布模式

滚动发布系统会随着软件包进入其软件仓库而持续向前更新。固定发布系统则发布明确的版本，在规定期限内维护每个版本，最终要求升级到更新的发行版。介于两者之间的是半滚动模式：核心系统保持冻结，而第三方软件和安全修复则持续推进。Tumbleweed 是与固定发布的 Leap 分支相对应的滚动版本；Debian Stable 则是与 Debian 不稳定树并列的固定分支。

滚动发布并不等同于不稳定。滚动发布的发行版通常会让软件包经过测试阶段再进入正式版本，而固定发布的版本在其整个生命周期内仍会提供安全补丁。真正的权衡在于平台变化的频率，以及管理员需要投入多少升级规划工作。

支持政策：LTS 与短周期

短周期发行版与长期支持（LTS）版本代表了不同的取舍。例如，Ubuntu 每六个月发布一个新版本，每两年发布一个长期支持版本。不同项目的支持时长差异很大。在一项公开发布的对比中，Alpine 3.x 获得约两年的标准支持，Debian 13 获得三年标准支持加五年扩展支持，Ubuntu 26.04 LTS 则获得五年标准支持加十年扩展支持。企业厂商还会在这些周期之上提供付费的生命周期延长服务。

目标市场

发行版通常面向特定用户群体：

• 桌面端：Ubuntu、Fedora、Linux Mint 和 openSUSE Tumbleweed 注重较新的桌面技术栈、硬件支持和安装的便捷性。
• 企业服务器：RHEL 和 SUSE Linux Enterprise 提供长生命周期、认证以及商业补丁交付服务；与 RHEL 兼容的重新构建版本则为希望使用相同工具链、又不想订阅付费服务的用户提供了选择。
• 极简容器：Alpine 之所以流行，是因为其基础镜像层的体积只占 Debian 或 Ubuntu 基础镜像的一小部分，因此成为容器化工作负载中常见的镜像基础。
• 嵌入式与设备应用：精简的小型系统运行于路由器、网络附加存储及其他设备中，这些场景更看重占用空间和快速启动，而非图形桌面。

具体选择哪一种，取决于所需的稳定性周期、可用的软件包，以及运维人员愿意承担的维护工作量。

图形栈：X11、Wayland 与桌面环境

X11 及其架构

X 窗口系统（X11）诞生于 1984 年麻省理工学院（MIT）的一项工作，几十年来，它一直是图形化 Linux 桌面绘制窗口、读取输入的默认方式。从 1984 年在 MIT 起源，到 2008 年 Wayland 出现，Linux 图形栈经历了一次根本性的架构转变。在 X11 中，X 服务器掌管显示硬件，应用程序作为客户端与之连接；窗口管理器和合成器则是独立的程序，负责窗口的摆放和视觉效果。这种设计使图形在抵达屏幕之前，要先经过好几个彼此独立的程序。

这种分离也带来了局限。由于服务器调度一切，X11 允许任何应用监视发送给其他应用的按键，客户端之间也没有真正的隔离。它对多显示器的支持同样薄弱：X.org 可以让多个不同分辨率的显示器同时工作，但无法为每块屏幕设置不同的像素密度，像素密度仍然是全局的单一设置。此后，开发已经停止。X.Org 随后转为仅维护模式，进一步推动了业界向 Wayland 转移。

Wayland 与合成器模型

Wayland 是显示服务器与其客户端之间的一种协议，并由一个 C 语言库来实现。使用 Wayland 协议的显示服务器被称为 Wayland 合成器，因为它还要承担合成型窗口管理器的任务。这一模型去掉了独立的 X 服务器：Wayland 使用单一的统一合成器，直接在 GPU 上渲染帧，并内置应用隔离。这种取舍是实实在在的。X11 曾提供的网络透明性基本消失了；远程显示不再能通过 ssh -X 实现，取而代之的是 RDP 或 VNC。屏幕共享最初也很困难，后来通过 PipeWire 和 XDG 门户栈得以解决。旧有的 X11 程序则通过 Xwayland 运行，它在 Wayland 会话中处理几乎所有的 X11 应用。

过渡进度因发行版和桌面环境而异。Ubuntu 26.04 的全新安装仅提供 Wayland 会话。GNOME 在 49 版（2025 年）中移除了其 X11 会话代码，不过有些资料称最终移除要到 GNOME 50 才完成。对于 KDE，官方的 X11 支持预计会在 Plasma 6.7 停止维护后终止，时间应为 2027 年初。其他桌面进展较慢：XFCE、Cinnamon 和 MATE 仍在完成向 Wayland 的过渡。各资料对日期的说法也不一致，因此具体时间表应以各项目的发行说明为准。

桌面环境

桌面环境的区别主要在于设计侧重点不同。GNOME 最以 Wayland 为中心，是对 Wayland 立场最鲜明的桌面。KDE Plasma 功能丰富，以 KWin 作为其合成器，到 2026 年，Wayland 路径已成为 Plasma 的默认选项。Xfce、MATE 和 Cinnamon 通常受到那些希望硬件要求较低、界面布局较为传统的用户青睐；这些环境仍在完成向 Wayland 的过渡。资源占用高度依赖于配置，而我未能找到能够一致地比较所有这些桌面的基准测试。有一次对单个 KDE Wayland 会话的测量记录显示，kwin_wayland 进程占用约 281 MB 内存，这只是一个数据点，不足以构成普遍性的比较。

图形驱动与 Mesa

在 Linux 上，图形加速主要来自 Mesa，它是 OpenGL、OpenGL ES、Vulkan 及其他图形 API 规范的开源实现。AMD 将 Mesa 中的 RadeonSI 和 RADV 驱动作为其官方 Linux GPU 驱动予以支持，而英特尔在 Linux 上一直只支持 Mesa 驱动。Nvidia 是主要的例外。搭载 Nvidia 显卡的系统通常使用闭源的 Nvidia GeForce 驱动，不过名为 Nouveau 和 NVK 的开源项目也在推进中。Nouveau 是通过对 Nvidia 闭源 Linux 驱动进行逆向工程而开发的。截至 2026 年，NVK 通常仍比闭源驱动慢，但差距在持续缩小。

驱动的选择会影响桌面体验。闭源驱动会取代整个 Mesa，自行提供图形 API 的实现。Nvidia 转向开源内核模块改变了这一局面。随着 R515 驱动的发布，Nvidia 以 GPL 与 MIT 双重许可证，将一组 Linux GPU 内核模块开源。开源内核驱动并不涵盖 OpenGL、Vulkan、OpenCL 和 CUDA 的用户空间驱动，这些仍然是闭源的。硬件世代也很重要：对于图灵（Turing）、安培（Ampere）、Ada Lovelace 或 Hopper 架构的较新 GPU，Nvidia 建议改用开源内核模块；而对于较老的 Maxwell、Pascal 或 Volta 架构 GPU，开源模块并不兼容，因此用户应继续使用闭源驱动。历史上，从 21.04 版本开始，Ubuntu 仅在非 NVIDIA 系统上默认使用 Wayland。

服务器、云、容器与网络

服务器是 Linux 占有范围最大、也最显眼的领域。不同方法得出的网络测量结果有所差异，但都一致将 Linux 排在首位。2026 年，第三方统计网站转载了一项被广泛引用的 W3Techs 数据，显示在能够识别操作系统的网站中，Linux 约占 60%，远超 Windows。市场研究机构对服务器和云端份额的估计差异则大得多，因此这些数字应理解为量级上的参考，而非精确值。

Web 服务器与 LAMP 技术栈

在 20 世纪 90 年代和 21 世纪头十年的大部分时间里，动态网站的默认平台是 LAMP 技术栈：操作系统为 Linux，Web 服务器为 Apache HTTP Server，关系型数据库为 MySQL 或 MariaDB 等，脚本语言为 PHP（或 Perl、Python）。每一层都是自由软件，而 Linux 提供了进程模型、文件系统和网络功能，其他组件都运行在这些基础之上。Apache 至今仍被广泛部署，但高流量网站越来越多地使用 Nginx。Nginx 是一款事件驱动的 Web 服务器，设计目标是以很少的资源处理大量并发连接。两者主要都运行在 Linux 上，因此即便应用技术栈不断变化，网络基础设施仍然依赖内核。

云平台

Linux 是公有云计算默认的客户机操作系统。主要云服务商提供大量 Linux 镜像，其自有的托管服务，如负载均衡器、托管数据库和容器平台，通常也构建在 Linux 主机之上。云服务商还将 Linux 用作虚拟化管理程序层：KVM 模块使内核成为虚拟机监视器，从而让一台物理服务器运行多个相互隔离的虚拟机。Linux 在云端虚拟机中所占的份额估计差异很大，从约 60% 到 90% 以上不等，取决于服务商和调查方法。私有数据中心很少被计入公开统计。

容器

容器不是虚拟机。它是一个普通的进程或进程组，与宿主机共享内核，但其看到的系统视图受到限制，可使用的资源也受到约束。两项内核功能使这一点得以实现。命名空间（namespaces）控制进程能看到什么，包括独立的进程 ID、挂载点、网络协议栈、主机名以及进程间通信资源。控制组（cgroups）控制进程能使用什么，通过限制并统计 CPU、内存、I/O 和进程数量来实现。第一种命名空间于 2002 年出现，cgroups 于 2007 年并入内核，从 2013 年起被重新设计为第二版。Docker 于 2013 年发布，它将这些内核功能与命令行界面和镜像格式打包在一起，使普通开发者也能便捷地使用容器。由于容器共享同一个内核，内核漏洞会影响宿主机上的每一个容器。因此，容器安全还依赖能力（capabilities）、seccomp 过滤器和强制访问控制等额外机制。

编排系统依赖这些底层原语。Kubernetes 在一组 Linux 节点上调度容器，依靠 cgroup 限制来安排工作负载，并使用为每个 Pod 创建命名空间的容器运行时。其网络模型建立在 Linux 网桥、路由和数据包过滤之上。

网络与防火墙

TCP/IP 协议栈在内核中实现，负责数据包传输、路由表、套接字管理和连接跟踪。数据包过滤由 Netfilter 提供，这是一个在网络路径中设置多个钩子点的框架。内核模块在这些钩子上注册回调函数，每个经过的数据包都会触发这些回调，从而实现过滤、网络地址转换和端口转换。用户空间工具用于配置 Netfilter：iptables 长期以来是主要工具，而 nftables 于 2014 年随 Linux 3.13 引入，是其继任者，提供统一的 IPv4 和 IPv6 语法。firewalld 等前端管理工具现在默认使用 nftables 后端。路由与转发通过 sysctl 设置进行控制，例如 IP 转发和反向路径过滤，这使 Linux 机器能够充当不同网络之间的路由器。

由于内核网络、过滤与路由功能的这一组合，Linux 被广泛用于网络设备。许多商用路由器、防火墙和负载均衡器都基于 Linux 构建，OpenWrt 等开源路由器固件也可以运行在消费级硬件上。使用通用内核使厂商能够复用成熟的网络协议栈，并通过与其他内核子系统相同的上游开发流程进行更新。

运维与自动化

Linux 成为默认服务器平台，部分原因在于其管理工具可以脚本化，且配置存放在文本文件中。Ansible、Puppet、Chef 和 Salt 等配置管理系统以代码形式描述主机的期望状态并反复应用，Terraform 等基础设施即代码工具则负责配置机器本身。服务通常由 systemd 等初始化系统管理，部署往往构建为不可变镜像，通过重建而非原地打补丁来更新。日志、监控和追踪工具一般通过 proc 和 sysfs 文件系统暴露的内核接口读取数据，较新的可观测性工具则使用 eBPF 实现开销更低的插桩。这些实践共同使 Linux 成为大多数服务器软件（从数据库到编排平台）首先被编写和测试所依据的基准平台。

超级计算机与科学计算

TOP500项目自1993年起每年两次对公开已知的最强大计算机进行排名，其中的操作系统记录清晰地显示了Linux历史上最明显的一次转变。20世纪90年代末，IRIX、AIX、Solaris和UNICOS等商用Unix变体在榜单上占据主导地位。Linux于1998年首次出现在榜单上，只有一个条目。此后其份额稳步增长：2002年11月有71个系统运行Linux，2009年11月达到448个（约占90%），到2014年6月占据榜单的97%。最后一批非Linux系统于2017年11月退出榜单，此后每期榜单都显示全部500个系统均运行Linux。2025年11月的版本延续了这一结果。

这种普及有多方面的结构性原因。内核的开源代码使厂商和站点技术人员能够针对定制互连、加速器和内存架构对其进行修改，而这对于专有Unix内核来说要困难得多。Linux也不收取每个节点的授权费用，这对拥有数万个节点的机器而言是一大优势。它可以运行在通用的x86和ARM处理器以及GPU平台上，而科学家所依赖的工具，如编译器、调试器和消息传递库，通常都是首先在Linux上开发的。实际上，顶级机器上的"Linux"往往是经过厂商定制的软件栈。Fugaku运行基于Linux的定制内核，JUPITER使用Red Hat Enterprise Linux，而Jaguar等Cray系统则使用Cray Linux Environment。由于TOP500按操作系统家族对系统进行分类，因此100%这一数字描述的是操作系统家族，而不是软件的统一性。

典型的科研集群由一组计算节点组成，这些节点通过InfiniBand或HPE的Slingshot等高速网络相连，每个节点上运行Linux。并行程序通过消息传递在各节点之间分配任务，最常用的是MPI标准，由Open MPI和MPICH等库实现。MPI依赖内核对远程直接内存访问（RDMA）和内核旁路网络的支持，使得数据在节点之间传输时，每条消息几乎不需要各节点操作系统的参与。作业调度由工作负载管理器负责。Slurm（Simple Linux Utility for Resource Management）是一款采用GPL-2.0许可证的免费调度器，用C语言编写，被世界上许多超级计算机和集群所采用。用户申请核心数、内存和运行时间；调度器对作业排队并分配节点，既可以在一个节点上同时启动多个作业，也可以让一个作业跨越多个节点运行。

科学与工程软件建立在这一基础之上。GCC、基于LLVM的工具链以及厂商编译器可以为各种架构生成优化的二进制程序。数值库（包括BLAS和LAPACK的实现）、用于傅里叶变换的FFTW，以及PETSc等求解器框架，提供了模拟计算所需的核心数学运算。Spack等包管理器在高性能计算领域被广泛采用，可以并行安装同一库的多个版本，而模块或容器则使环境在不同集群之间保持可复现。这些软件大多假定运行在POSIX风格的环境中，因此Linux对Unix接口的兼容性与其原始性能同样重要。

并行负载也推动了内核内部的改进。一个核心问题是"操作系统噪声"：周期性的定时器中断、内核线程和后台守护进程，可能拖慢紧密同步的程序中的某个进程，而其他所有进程随之等待。因此，高性能计算站点会采用无时钟滴答（tickless）运行方式，隔离CPU核心专供应用线程使用，将线程绑定到特定核心和内存区域，并应用基于cgroup的资源控制。在内存方面，大页可以减少大工作集的地址转换开销，而NUMA感知的数据放置则使数据靠近使用它的处理器。透明大页和自动NUMA平衡在生产集群上常被禁用或调优，因为它们的后台活动可能导致延迟尖峰。加速器、Lustre等并行文件系统以及高速网络适配器都依赖内核驱动程序，这也是高性能计算工作推动Linux驱动和内存管理子系统不断扩展的原因。

嵌入式系统、移动设备与 Android

Linux 是嵌入式计算领域部署最广泛的内核之一。它的吸引力来自成熟的驱动程序生态、宽松的许可证组合（允许厂商在部分层级中使用闭源组件），以及从几兆字节闪存到大型应用处理器都能适配的伸缩性。典型的嵌入式应用包括家用路由器和无线接入点、智能电视和机顶盒、可编程逻辑控制器和工业网关、车载信息娱乐和远程信息处理单元，以及大量物联网（IoT）传感器和家电。在许多此类产品中，最终用户从未见过桌面或命令行环境，内核只是运行着厂商组装好的一套单一应用栈。

路由器就是这一模式的典型例子。一款普通消费级路由器通常将片上系统（SoC）与 Linux 内核、小型 C 标准库、精简的工具集和一个网页管理服务搭配在一起。OpenWrt 等开源固件项目展示了同一套基础系统如何针对不同硬件进行改造。电视平台也遵循类似思路：Linux 内核负责承载硬件驱动，其上再叠加厂商专有的中间件层。工业控制器和汽车电子单元则有另一项要求：必须在有界的时间内做出响应。这促使开发者采用实时配置，相关内容见下文。

Android：拥有独立用户空间的 Linux 内核

Android 是 Linux 最显眼的嵌入式应用，但它常被人误解。Android 使用 Linux 内核负责进程调度、内存管理、安全策略执行和设备驱动，但内核之上的几乎所有部分都与桌面发行版不同。Google 的运行时、系统库、框架服务和应用模型都建立在内核之上，而非基于 GNU 用户空间工具。其 C 库是 Bionic，而非 glibc；窗口和图形栈也不是 X11。因此，要在发行版的意义上称一台设备为"Linux 设备"，仅有 Linux 内核是必要但不充分的。

Android 最重要的专有增补之一是 Binder，这是一种在内核中实现、并向用户空间开放的进程间通信机制。Binder 使框架能够跨进程边界调用服务，并且可以在每次调用时检查权限，这是 Android 应用沙箱机制的核心。Android 还在框架与驱动之间设置了一层硬件抽象层（HAL）。HAL 是一组标准化的用户空间接口，以库和服务的形式实现，由厂商填入针对自家芯片的代码。由于框架只与 HAL 交互，硬件厂商无需修改框架即可更新其实现，闭源模块也可以置于开源框架之外。

随着时间推移，Android 逐步把内核层面的差异收拢到可控的组件中。自 Treble 架构引入以来，厂商相关的部分已与框架分离；而在后续的 Android 版本中，通用内核镜像（GKI）方案旨在直接使用上游源码提供统一的内核，再在其上加载厂商模块。这些措施降低了让数以百万计的设备保持更新的成本，不过许多手机获得内核更新的速度仍慢于上游项目的发布速度。Android 对内核的修改，例如其电源管理策略、低内存杀进程机制的演进脉络以及安全补丁，也是 Android 内核有别于主线代码树的原因之一。

实时扩展与 PREEMPT_RT

通用内核的设计目标是最大化吞吐量，这可能使最坏情况下的响应时间难以预测。实时系统则需要有界的延迟，几十年来，有此需求的开发者一直是将 PREEMPT_RT 补丁集应用到主线内核上。该项工作始于 2005 年，最初是一个树外项目。此后的数年里，其中的部分代码逐步合并进主线，包括线程化中断处理程序、优先级继承互斥锁和高精度定时器等。最后的障碍是内核的日志函数 printk：在原子上下文中向速度较慢的控制台写入数据，可能会破坏延迟保证。printk 经过重新设计后，剩余代码才得以整合。

PREEMPT_RT 于 2024 年 9 月完全并入主线代码树，并随 2024 年 11 月发布的 Linux 6.12 一同发布，支持 x86、x86-64、ARM64 和 RISC-V 等多种架构。此后，用户只需通过配置选项即可启用它，而无需为每个内核版本单独应用匹配的补丁。这一变化对嵌入式厂商意义重大，因为版本匹配的补丁此前一直是反复出现的维护负担。实时能力仍取决于硬件、驱动程序和应用设计，而且在要求最为严苛的认证体系中，带有 PREEMPT_RT 的 Linux 通常不被视为安全关键型实时操作系统（RTOS）的替代品。

资源受限的变体与构建工具

嵌入式开发者很少直接使用标准的桌面发行版。他们通常只组装所需组件来构建根文件系统。一个精简的系统可能会使用 BusyBox（将众多 Unix 工具合并为一个小型可执行文件），并以 musl 或 uClibc-ng 等紧凑的 C 库代替 glibc。内核本身也可以通过配置去除未使用的子系统和驱动程序。启动链通常还包括 U-Boot 等引导加载程序，以及向内核描述硬件布局的设备树。

为了可重复地生成此类系统镜像，团队会使用构建系统。Buildroot 是基于 Makefile 的工具，专注于快速生成紧凑的根文件系统、引导加载程序和内核，并生成不含运行时包管理器的静态镜像。由 Linux 基金会支持的 Yocto Project 则采用 OpenEmbedded 构建系统、BitBake 任务引擎以及基于层（layer）的元数据模型。Yocto 更为灵活，适合生命周期较长、需要 SDK 并要求精细控制的产品，但其学习曲线更陡，首次构建也更耗时。两者的选择通常取决于产品生命周期、团队经验以及设备所需的定制程度。

综合来看，这些实践说明，嵌入式 Linux 与其说是单一产品，不如说是一系列工程选择的集合。内核提供共同的核心，而周边的库、服务、更新机制和构建工具则根据每台设备进行定制。

安全模型与漏洞管理

自主访问控制

Linux 继承了 Unix 的权限模型。每个文件都有所有者和所属组，并为所有者、所属组及其他所有用户分别设置读、写、执行位。setuid 和 setgid 位则允许程序以其文件所有者的权限运行。由于资源能否被访问由所有者决定，这种机制被归为自主访问控制（DAC）。DAC 的弱点在于，以 root（UID 0）运行的进程能绕过大部分检查。Linux 的解决方法是把 root 的权力拆分为 POSIX 能力（capabilities），每项能力只授予一种特定权限，例如绑定特权网络端口或更改文件所有权，使服务无需完整的超级用户权限即可持有某项特定特权。操作系统层面和网络安全领域都把这种权限分离视为基本设计目标。

强制访问控制与 LSM 框架

强制访问控制（MAC）增加了一套普通用户和进程无法放宽的策略。Linux 通过 Linux 安全模块（LSM）框架实现这一机制，该框架在内核中对安全敏感的位置设置钩子。从概念上讲，LSM 框架就是内核安全敏感位置上的一组钩子，某个操作（例如打开文件）只有在钩子函数返回肯定结果时才能成功。内核文档列出 SELinux、Smack、Tomoyo 和 AppArmor 为使用该接口的主要 MAC 模块。这些模块可在编译时通过 CONFIG_DEFAULT_SECURITY 选择，也可在启动时通过内核命令行参数 "security=..." 覆盖，其中能力模块始终处于启用状态。

SELinux 是其中最早、粒度最细的一个。它于 1998 年首次发布，是主流 Linux 上最早的 MAC 实现。它为进程、文件和其他对象添加标签，其策略可以严格到足以将一个被攻陷的服务限制在受控范围内。AppArmor 则采取不同的思路：它基于路径为各个程序应用配置文件，因此更易编写和管理。AppArmor 最初由 Immunix 开发，现由 Canonical 维护，它通过配置文件定义程序允许执行的操作。两者的选择在很大程度上取决于发行版：RHEL、Rocky Linux、AlmaLinux、CentOS Stream 和 Fedora 都使用 SELinux，而 Ubuntu、Debian、SUSE Linux Enterprise Server、openSUSE 以及几乎所有基于 Ubuntu/Debian 的衍生版都使用 AppArmor。一个反复出现的运维问题是，较复杂的策略语言有时会促使管理员将其关闭，这可能使系统的防护能力低于预期。

内核自我保护与加固

加固有两个目标：让漏洞更难被利用，以及减少攻击者能够触及的入口。地址空间布局随机化就是一个核心例子。内核在启动时随机化其物理和虚拟基地址（CONFIG_RANDOMIZE_BASE），使需要定位内核代码的攻击难以得逞。这并不是完备的防御，因为信息泄露可能暴露偏移量，因此通常还要配合限制内核指针泄露的措施，例如 kptr_restrict 系统参数，它可防止 /proc/kallsyms 等接口暴露真实的内核地址。

栈保护是逐步加入的。2.6.30 版本加入了 GCC 的 -fstack-protector 选项，3.14 版本又加入了 -fstack-protector-strong。初始化后只读（read-only-after-init）数据也是内核采用的另一项技术，它使结构在启动完成后不可再修改。减少攻击面主要依靠 seccomp：seccomp 是一项面向用户空间开放的可选功能，可以减少正在运行的进程能够使用的内核入口点数量。NX、SMEP 和 SMAP 等硬件特性与这些软件措施并用。内核针对 CPU 侧信道攻击（如 Meltdown，通过页表隔离加以缓解）所做的防护，则体现了软硬件防御的结合。

漏洞报告、CVE 与稳定版修复

内核的漏洞报告流程有意保持简单。疑似安全漏洞通过纯文本邮件发送给内核安全团队。许多被报告的问题并不属于安全问题，因此报告者会被告知将缺陷报告发送到相应的邮件列表，并与那里的开发者公开协作解决。修复合并之后，项目更重视速度而非公告：Linux 内核安全团队致力于尽快修复已报告的问题，并将修复合并到公共代码树中，且不会在任何地方发布公告。相比之下，较早的重大漏洞指导方针则描述了协调披露的做法，即设置短暂的禁披露期（embargo），使各发行版能够先行打补丁。该指导建议设置 7 天的禁披露期。这两种做法反映了不同时期的实践，而当前的说明更强调已合并的修复，而非禁披露期内的修复。

CVE 编号由另一个团队负责分配。Linux 内核开发团队确实有权为潜在的 Linux 内核安全问题分配 CVE。分配通常与已进入发布代码树的代码相关：对于尚未修复的 Linux 内核安全问题，不会自动分配 CVE；只有在修复可用并已应用到稳定内核代码树之后，才会自动分配，并以原始修复的 git 提交编号进行追踪。由于团队的覆盖面很广，分配的数量相当大。项目本身也指出，分配团队刻意保持谨慎，因为在修复内核漏洞时，其可利用性往往并不明确。因此，Linux 内核问题上的 CVE 编号本身并不能说明紧急程度；各发行版随后会将修复回移植（backport）到自己的内核软件包中，并发布更新。

安全社区与重要漏洞类别

内核的大部分安全工作由志愿者和维护者完成，而非某一家厂商。Linux 内核安全团队与 CVE 团队是不同的群体，他们都是基于个人声望开展这项工作，并不隶属于任何公司。自动化模糊测试已成为一条主要的漏洞发现途径。内核自身的文档要求，使用 syzkaller 模糊测试工具发现漏洞的报告者应在提交信息中注明。oss-security 和 linux-distros 等公开邮件列表也负责协调各发行版之间的披露工作。

影响最大的漏洞大多集中在几类反复出现的问题上。内存安全缺陷，包括缓冲区溢出、释放后使用和重复释放，一直是内核漏洞的最大来源；2024 年的一个例子是 netfilter 中的重复释放漏洞（CVE-2024-1086）。内存管理中的竞争条件导致了 Dirty COW（CVE-2016-5195），使非特权用户能够写入只读映射。共享缓冲区中的逻辑错误导致了 Dirty Pipe（CVE-2022-0847），允许覆写只读文件中的数据。io_uring 子系统也曾多次出现本地权限提升漏洞的报告。2018 年披露的 Spectre 和 Meltdown 等推测执行侧信道漏洞，需要在受影响的硬件上通过内核层面的缓解措施加以应对，至今仍是持续进行的工作领域。

Rust、eBPF 与技术演进

进入 2020 年代以来，内核的变化已超出了驱动程序的渐进式增补。其中两个发展尤为突出：Rust 被接纳为第二种内核实现语言，以及 eBPF 发展成为通用的内核内编程设施。其他值得注意的变化还包括新的文件系统、异步 I/O 以及对新硬件的支持。

作为第二种内核语言的 Rust

Rust-for-Linux 项目始于 2020 年，最初是一项实验，旨在探究 Rust 能否用于内核代码。其主要动机是内存安全。内核中许多最严重的漏洞都是 C 语言中的内存错误，例如越界访问和释放后使用（use-after-free），而 Rust 的所有权和借用规则正是为了在编译期拒绝这类代码而设计的。Rust 支持最早出现在主线内核的 6.x 系列中。各方资料对确切的起始时间说法不一：一种认为首次合并进入的是 6.0（2022 年 10 月），另一种则将其定在 6.1 周期（2022 年 12 月），当时首个简单的 Rust 平台驱动程序加入了内核。

此后，Rust 的采用分阶段推进。在 6.18 版本（2025 年末），谷歌用 Rust 重写的 Android Binder 进程间通信驱动程序与旧的 C 版本一同进入主线；内核还新增了一个用于 Arm Mali GPU 的 Rust 驱动，以及一个用于 USB 驱动绑定的初始框架。Rust 版 Binder 驱动还产生了分配给内核 Rust 代码的第一个 CVE 编号，这提醒人们 Rust 并不能消除所有缺陷。在 2025 年东京维护者峰会上，维护者们一致认为 Rust 已不再是实验性的，而是内核中与 C 和汇编并列的永久组成部分。然而，Rust-for-Linux 的负责人米格尔·奥赫达（Miguel Ojeda）强调，这并不意味着每种配置、每种架构或每种工具链都获得了完整支持。2026 年的报道显示，计划在 Linux 7.4 中移除 C 版 Binder 驱动，这将使 Rust 版 Binder 成为唯一实现，不过这只是规划层面的信号，尚未成为定局。Rust 也正在内核之外扩散：Debian 宣布，Rust 将成为其 APT 包管理器的必需依赖。

eBPF

eBPF（扩展伯克利包过滤器）由最初用于过滤网络数据包的机制 BPF 发展而来。2014 年，Alexei Starovoitov 将其重新设计为一种通用执行引擎，并在 3.18 版本中进入主线。其核心思想是：用户程序提供小型字节码例程，内核在特定事件发生时运行这些例程，这些事件包括系统调用、网络事件或调度器决策。程序加载前，内核内的验证器会检查其能否终止、是否始终在边界之内、是否会破坏内存。通过验证的程序随后会被解释执行或经 JIT 编译为本机代码。由于这些程序是单独校验和加载的，eBPF 在可加载内核模块的风险与直接修改内核源码的缓慢节奏之间提供了一条中间路径。它的用途包括数据包处理（例如 XDP）、跟踪与性能剖析、安全策略，以及 Kubernetes 等编排系统中的容器级网络。BCC 和 bpftrace 等工具让运维人员也能便捷地使用它。

其他技术变化

另有若干变化塑造了近期的版本。io_uring 接口在用户空间与内核之间提供共享的提交与完成环形队列，从而降低了异步 I/O 的开销。调度器扩展 sched_ext 于 6.6 版本合并，允许 BPF 程序实现自定义的调度策略。6.18 版本带来了重新设计的内存分配器（slub sheaves）、用于持久内存缓存的 dm-pcache，以及对 Apple M2 级设备树和 Arm Mali GPU 等新硬件的支持。同一版本还将 bcachefs 文件系统从代码树中移除，表明一项技术能否进入主线，既取决于技术价值，也取决于维护者的支持。

围绕 Rust 的争议

Rust 的接纳过程并不顺利。支持者认为，它能减少几十年来困扰 C 代码的若干类缺陷；而一些资深维护者则担忧，同时维护两种语言会带来额外负担，两者之间的接口也令人担心。Rust-for-Linux 项目出现过多位维护者辞职，以及邮件列表上的公开分歧。东京峰会上的维护者表示，对这一决定本身几乎没有反对意见，但观察人士指出，工作量以及对个别维护者的成本依然很高。较可能的结局是 C 与 Rust 长期并存：新驱动程序常以 Rust 编写，而核心子系统在很长时间内仍将保留 C 语言实现。

商业生态、基金会与治理

作为分发者与贡献者的公司

没有哪家公司拥有 Linux，但少数几家公司承担了大部分可见的工作，包括打包、支持和资助。红帽（Red Hat）是最典型的例子。截至2007年2月结束的财政年度，其企业产品的订阅收入已增至约3.41亿美元，一年内增长近一半：订阅收入增长48.1%，即1.108亿美元，达到3.412亿美元。其合同通常为期一年，包括维护、配置支持以及更新访问权限。这些安排通常为一年的订阅期。基础订阅一般让最终用户享有一年的维护服务。IBM于2019年同意以340亿美元收购该公司，这是有记录以来规模最大的软件收购。IBM确认以每股190美元的现金收购这家 Linux 企业级开源服务提供商，该价格使其成为历史上规模最大的软件收购。IBM 的兴趣主要在于其经常性收入，它希望借此加强云和企业业务。第三方统计网站估计，红帽企业版 Linux 每年的收入已超过65亿美元，但该数字未经审计。

SUSE 位于德国，Canonical 是 Ubuntu 背后的公司。两者大致遵循相似的模式：免费的社区发行版（openSUSE 和 Ubuntu）与付费的企业或订阅等级并存，后者捆绑长期支持、安全补丁和认证服务。多年来，公司对内核开发的参与保持稳定。Linux 基金会2017年的报告列出 Intel、Red Hat、Linaro、IBM、三星、SUSE 和 Google 为内核工作的主要赞助者。自上次报告以来，赞助 Linux 内核开发的前十名组织包括 Intel、Red Hat、Linaro、三星、SUSE、Google、AMD、Renesas 和 Mellanox。一项2025年的统计显示，活跃的内核贡献者约1.1万人，来自约1780个组织，其中公司贡献了大部分提交。截至2025年，Linux 内核拥有11,089名活跃贡献者，分属全球1,780个组织，企业贡献占全部提交的84.3%。志愿者的工作所占比例有所下降：2016年的报告发现，无偿贡献的比例已从2014年的11.8%降至7.7%。

Linux 基金会

Linux 基金会是一家非营利组织，负责协调资金、活动和共享基础设施，同时还托管内核之外的许多项目。其活动包括开源峰会和 Linux 内核开发者峰会。基金会还在 Linux 社区内举办年度教育活动，包括 Linux 内核开发者峰会和开源峰会。它的大部分资金来自会员，而非内核本身。2025年，基金会报告的总收入约为3.11亿美元，其中会费和捐款约1.33亿美元，是最大的收入来源。其2025年的账目中有一项专门的 Linux 内核项目支出，约840万美元。大部分支出用于其他托管项目，因此相对于基金会的收入，内核的直接预算很少。基金会还雇用了一些核心开发者：稳定分支维护者 Greg Kroah-Hartman 担任 Linux 基金会研究员。该报告由 Linux 内核开发者、LWN.net 编辑 Jonathan Corbet，与 Linux 内核维护者、Linux 基金会研究员 Greg Kroah-Hartman 共同撰写。

kernel.org 与基于维护者的决策

kernel.org 是分发 Linux 内核源代码的主要站点，但并非唯一权威的代码副本。其代码仓库服务于开发者和发行版维护者，也托管其他项目并提供镜像。由于 Git 是分布式的，每位活跃开发者都保有完整的本地副本，这使得在中央服务器上的秘密篡改更容易被发现。所有内核开发者，以及许多非内核开发者，都在某处至少保存着一份仓库副本。如果攻击者破坏了 kernel.org 的仓库，其他开发者在下次更新个人仓库时就会注意到。

2011年的入侵暴露了基础设施的弱点。入侵者获得了 root 权限，并在启动脚本中植入木马。此后，服务器被重新安装，项目也从由少数志愿者运营的机器，转变为由有薪管理员运营、并获得 Linux 基金会支持的系统。数百名开发者的 shell 账户被撤销。自2014年8月起，kernel.org 对托管 Git 仓库的提交强制要求双因素认证，以提供额外的安全保障。

内核的权力是分散的，而非归属于某家公司。子系统维护者审查并收集各自领域的补丁，Linus Torvalds 将结果整合进主线树。没有任何公司在这一过程中持有控股权，也没有董事会决定哪些功能进入内核。信任建立在签名标签和维护者既有的声誉之上，2011年的入侵事件推动这一模式变得更加严格。2011年 kernel.org 被攻陷之后，人们才真正把这个问题放在心上。

商业模式与共享的公共资源

围绕 Linux 的大部分商业收入来自销售服务，而非软件本身，因为 GPL 允许任何人复制软件。主要模式包括：捆绑支持、安全更新和经认证硬件兼容性的订阅；支持合同；培训与认证；以及咨询服务。培训需求是红帽的一条重要业务线，该公司自行开展工程师认证培训。由于对红帽认证工程师、技术员和架构师的持续需求，其培训收入增长了12.9%，即410万美元。

内核的经济属性类似于公共物品：一旦发布，任何人都可以使用代码，包括从未做出贡献的公司。这就产生了搭便车问题，企业通过付费雇用工程师来维护其自身依赖的驱动程序和子系统，以此解决这一问题。与各公司各自进行内部维护相比，共同分担维护成本也更低，这是联合维护中规模经济的典型例子。一些分析人士将这类订阅收入描述为稳定且可预测的，并将其比作年金。该收购被比作一种年金，可带来稳定的订阅式回报。

采用情况、市场份额与统计方法

Linux 的市场地位取决于统计的口径：统计的是已安装的机器、正在运行的服务器、网页浏览量，还是自愿参与调查的受访者。按其中大多数口径来看，Linux 是服务器和超级计算机领域的主导平台，通过 Android 在移动设备中拥有庞大的装机基础，而在桌面端仍是少数派，但份额在增长。

各细分市场的地位

服务器领域是 Linux 地位最强的地方。据 W3Techs 统计，截至 2026 年 5 月，在能够识别底层操作系统的网站中，有 61.1% 运行 Linux。云服务商的数据也呈现类似的格局。微软自家的产品页面称，Azure 中超过 60% 的客户核心运行的是 Linux 工作负载。在容器编排方面，CNCF 的 2025 年云原生调查显示，在受访的生产环境 Kubernetes 集群中，有 96% 运行 Linux。

在超级计算领域，自 2017 年 11 月起，TOP500 榜单报告的系统 100% 运行 Linux。2026 年 6 月的榜单改变了头条新闻：此前未上榜、安装在中国的系统 LineShine 首次上榜即排名第一，按 HPL 基准测试取代了 El Capitan，成为性能最强的超级计算机。该系统使用麒麟操作系统，有评论指出，榜单的讨论已不再只关乎操作系统。

在移动设备领域，相关数据是 Android 的份额，而且统计的是内核而非某个 Linux 发行版。基于 Linux 内核的 Android 在 StatCounter 2026 年 4 月的数据中占全球移动操作系统网页流量的 67.35%。是否应将其计入“Linux 份额”，取决于如何定义。

在桌面端，数据差异很大。StatCounter 记录 2026 年 4 月 Linux 占全球桌面操作系统份额的 2.99%，Windows 为 66.6%。之后一次统计显示，6 月 Linux 占全球桌面使用量的 4.36%。就北美而言，StatCounter 报告 2026 年 6 月 Linux 占 5.52%，7 月则升至 10.65%，一个月内几乎翻倍。相比之下，Steam 的自愿参与调查显示，2026 年 7 月 Linux 占 4.01%。

装机量与使用份额

装机量统计的是有多少台机器运行某个系统；使用份额统计的则是某个系统产生的活动在所有观测活动中所占的比例。两者可能相差悬殊。运行 Linux 的一台服务器可能承载的流量远多于一台运行 Linux 的桌面电脑，而一部 Android 手机虽然只是一台设备，在追踪数据中却可能是一个独立的网页流量来源。因此，公开数据回答的是不同的问题，没有哪一个来源是权威定论。Linux 的市场份额目前也没有任何单一来源能给出确定的结论。

桌面份额为何难以衡量

主要的桌面统计机构观察到的活动范围各不相同。StatCounter 通过分析浏览其分析服务所覆盖网站的浏览器页面浏览量来估算市场份额，因此它并不是一份计算机上安装的全部操作系统清单。相比之下，Steam 依赖的是自愿加入可选硬件和软件调查的 Steam 用户样本。发行版则有自己的遥测数据，统计的是在升级期间联系更新服务器的唯一 IP 地址。

若干偏差使比较变得复杂。“未知”类别占比很大：2026 年 6 月，StatCounter 的“未知”类别吸收了全球桌面网页浏览量的 21.45%。有评论者认为，该类别偏向 Linux 用户，因为它包含了 VPN 和加固浏览器的流量。机器人流量是另一个隐忧：有分析人士指出，这些数字可能因机器人流量而被夸大。调查还会漏掉屏蔽追踪的用户、双系统用户，以及在该设备上很少上网的用户。由于自由软件不通过可统计的渠道销售，销量无法追踪，这也去掉了衡量市场份额时最常见的参考指标。

从历史上看，倡导者曾认为网络统计低估了 Linux。桌面环境项目 KDE 估计，全球至少有 8% 的桌面运行 Linux 发行版，甚至可能达到 10%–12%。这一估计是早期的倡导性数字，并非测量方法得出的结果。

为何 Linux 对普通消费者不够显眼

Linux 对普通用户不够显眼，原因在于结构性因素。Linux 在桌面端仍是少数派操作系统，但作为计算基础设施，它却无处不在。大多数消费级个人电脑预装的是 Windows 或 macOS，因此 Linux 通常只有在用户或 IT 部门主动安装时才会出现。Linux 还运行在路由器、电视、机顶盒和工业控制器中，其操作系统被产品品牌所掩盖。在手机上，Android 的界面盖过了其内核，而云端客户很少看到支撑其服务的操作系统。以上解释属于一般性分析，并非来自某项特定研究的结论。

教育、公共部门与地区案例

公共部门和教育领域的部署表明，采用情况取决于政策和本地支持。西班牙埃斯特雷马杜拉地区政府自 2002 年起开发了基于 Linux 的系统 gnuLinex，并在学校和行政机构中使用。慕尼黑的 LiMux 项目曾将市政桌面迁移到 Linux，但该项目于 2017 年被逆转，该市大约在 2020 年前完成了重新转向微软软件的工作。中国采用麒麟等国产系统，如今也出现在 TOP500 榜首，这表明政府采购和国家技术战略会影响所部署的基于 Linux 的系统。关于当前经过核实的教育和公共部门 Linux 使用数据，检索未能找到可靠来源，因此本小节中的数字在依赖之前，应对照官方政府报告进行核实。

批评、碎片化与尚未解决的问题

硬件支持、驱动程序与商业软件

针对个人电脑上 Linux 的最常见批评与硬件有关。支持者指出，Linux 也支持许多冷门硬件和特殊架构，但这种广度并不一定涵盖普通消费者使用的无线网卡、笔记本电脑和显卡。批评通常集中在安装之后的阶段：无线网络或蓝牙可能无法使用，或者因显卡驱动有缺陷，三维应用可能无法运行。即使设备能够工作，驱动程序的功能也可能不及硬件本身的能力。批评者认为，许多现有的 Linux 驱动并不完整，即没有暴露设备的全部功能；就驱动的质量和完备程度而言，在与 Windows 和 macOS 的比较中，Linux 通常处于劣势。

造成这种状况的原因一部分来自结构性因素。硬件厂商传统上只为 Windows 编写驱动程序，因此 Linux 开发者几乎只能自己编写所有驱动，而厂商提供的支持往往非常有限。由于桌面用户群体较小，资助此类工作的动力也很弱：为硬件开发驱动既昂贵又困难，如果只有一小部分客户使用 Linux，那么为某个设备维护驱动的理由就更难成立。商业软件也面临相关问题。闭源应用通常以二进制形式发布，而确保其与众多 Linux 发行版和各个版本兼容的负担完全落在开发者身上。内核的内部驱动接口也没有长期的稳定性保证，这是一种有意的设计选择，而非疏忽，但它提高了树外驱动的维护成本。

发行版、桌面环境与软件包的碎片化

碎片化是第二大批评方向。其最明显的表现是发行版数量众多，每个发行版都有自己的安装程序、发布周期、默认设置和软件包格式。发行版的碎片化、依赖共享库而非将库与应用捆绑在一起，以及对保持 API 一致性和向后兼容性的重视不足，常被视为第三方开发者面临的障碍。对新手而言，结果是困惑：由 Ubuntu 社区维护的一份类似调查的常见问题解答中，“Linux 版本太多”被列为潜在用户最常提出的反对意见之一。

软件打包最能说明这一问题。Debian 的 .deb 和 Red Hat 的 .rpm 等原生格式与特定的包管理器绑定，因此为 Ubuntu 打包的应用在 Fedora 上可能无法运行，反之亦然。与发行版无关的通用格式正是为弥合这一差距而出现的。原生格式通过使用系统共享库与发行版紧密集成，而 Flatpak、Snap 和 AppImage 等通用格式则将依赖项打包在一起，以避免兼容性问题，代价是占用更多磁盘空间。这些通用格式之间now也相互竞争，其治理问题也引发了争议。一些发行版出于理念原因选择排除特定格式：例如 Linux Mint 就明确禁用了 Snap 支持，理由是 Snap Store 受商业控制。

碎片化有两面性，批评者与支持者常以不同方式描述同一现象。Linux 常因其多样性和灵活性而受到赞誉，但同样的多样性也增加了开发者的测试负担，他们必须针对多种包管理系统、库版本和桌面环境进行适配，同时也使用户更难评估这一平台。

可持续性与维护者的工作负担

Linux 生态系统的大部分依赖于志愿者，以及少数负担沉重的维护者。Linux 基金会在 2023 年对开源维护者进行的一项研究指出，如果没有维护者和贡献者，开源软件将迅速过时且不安全，而关键项目的负担更为沉重。这种压力并非假设。2025 年初，支持苹果硅芯片的 Asahi Linux 项目负责人突然辞职，原因包括开发者职业倦怠以及用户的过高要求等。内核各子系统中也存在类似问题，少数维护者需要审查大量补丁。

由于最广泛使用的基础设施往往资金最少，其安全影响十分严重。核心基础设施倡议是 Linux 基金会的一个项目，于 2014 年宣布成立，旨在资助对互联网正常运行至关重要的开源项目，其背景是心脏出血漏洞（Heartbleed）事件——这是 OpenSSL 中一个影响数百万网站的严重安全漏洞。该倡议的职能后来并入了 OpenSSF。2026 年，内核维护者 Greg Kroah-Hartman 指出，仅靠资助无法解决当前 AI 工具给开源安全团队带来的问题，因为维护者正被大量自动生成的漏洞报告淹没，而这些报告都必须逐一分类处理。

内核项目也在这种压力下调整了自身的支持承诺。2023 年，它将新指定的长期稳定版本的支持期从六年缩短为两年，这一决定被广泛讨论，被视为对稳定分支维护者工作负担的回应。内核的大部分开发仍由受雇于企业的工程师完成，但在驱动程序、子系统和旧分支上未获报酬或资金很少的工作，依然是一个长期存在的薄弱环节。

尚未解决的问题

几个悬而未决的问题贯穿于上述批评之中。第一个是桌面端的长期发展路径。Linux 已成为大多数服务器的默认系统，并在移动和嵌入式设备中占据相当大的份额，但在桌面端仍是少数派平台。它能否成为主流消费级选择，取决于内核之外的因素：预装硬件、厂商的驱动支持、应用程序的可用性，以及统一、一致的用户体验所带来的便利。

第二个问题涉及如何将较新的编程语言整合进主要以 C 语言编写的代码库。向内核中加入 Rust 的努力引发了关于工具链、审查能力，以及资深维护者是否愿意接受第二种实现语言的讨论，这些内容将在单独的章节中讨论。

第三个问题或许是最根本的，即稳定性与快速变化之间的平衡。内核严格规定变更不得破坏现有的用户空间程序，这一规则数十年来保障了兼容性；但与此同时，该项目也在不断替换内部 API、驱动程序和子系统，以支持新硬件和更好的设计。用户和企业重视可预测性，而开发者和硬件厂商则需要灵活性。该项目以及基于它构建的发行版如何调和这些诉求，将决定其可靠性以及适应变化的能力。

参考来源

1. MINIX Definitionlinfo.org
2. A Commentary on the UNIX Operating Systemen.wikipedia.org
3. History of Linuxen.wikipedia.org
4. Linux kernelen.wikipedia.org
5. Linux Announced (1991): Torvalds' Hobby Project — IT Historyhistory.itlibra.com
6. Linux 0.01 (1991): The Kernel That Escaped Helsinkihistorysnacks.io
7. Linux turns 34 years old, here's how it got started - Neowinneowin.net
8. Linux 0.01 - Computernewb Wikicomputernewb.com
9. Linux 0.01: The Story of the Kernel That Began as a Hobbylinuxgratis.com
10. Why August 25th? — ATUL CHITNISatulchitnis.net
11. Back in the Day: UNIX, Minix and Linuxlinuxjournal.com
12. GNU Turns 43: Why It Still Matters to Linux Userslinuxpanda.com
13. GNU Project - HandWikihandwiki.org
14. The Hurd: GNU's quest for the perfect kernel [LWN.net]lwn.net
15. graphsearch.epfl.chgraphsearch.epfl.ch
16. Linux kernelen-academic.com
17. A Brief History of Free and Open Source Software Licensingchannelfutures.com
18. 0% found this document useful (0 votes)scribd.com
19. Linux kernel version historyen.wikipedia.org
20. History of Linuxpld.cs.luc.edu
21. Linux kernel version 1.0.0 released - Web Developers Noteswebdevelopersnotes.com
22. GNU Projecten.wikipedia.org
23. GNU - Wikiwandwikiwand.com
24. Exploring GNU/Hurdlinux-magazine.com
25. The History of Linux: A Finnish Student's 'Hobby' Operating Systemdanielcosenza.com
26. Loadable Kernel Modulesdl.acm.org
27. Monolithic kernelen.wikipedia.org
28. Why Is Linux a Monolithic Kernel?baeldung.com
29. Chapter 1. Working with kernel modulesdocs.redhat.com
30. Monolithic, Micro, and Hybrid Kernelsalgomaster.io
31. Monolithic Kernel with Loadable Modules (Red Hat)dispersednet.com
32. Linux Kernel Architecture: Monolithic vs Microkernelembisyslabs.com
33. Linux Kernel Architecture Overviewmedium.com
34. Linux Kernel Internalskernel-internals.org
35. Linux Operating System Architecture Explained in 2026youstable.com
36. Linux Kernel Architecture Explainedthelinuxvault.net
37. Conceptual Architecture of the Linux Kernel - Huihoodocs.huihoo.com
38. Tanenbaum%E2%80%93Torvalds debateen.wikipedia.org
39. Tanenbaum–Torvalds debate - Infogalactic: the planetary knowledge coreinfogalactic.com
40. Linus Torvalds Clashes Dr. Tanenbaum in a 1992 Linux Debateponderwall.com
41. Tanenbaum vs Torvalds: the War of Kernels and the Birth of Pragmatic Chaosblog.heybruce.dev
42. Tanenbaum-Torvalds debateen-academic.com
43. Arch boot process - ArchWikiwiki.archlinux.org
44. Introduction to the Boot Processdoc.opensuse.org
45. Reference - The Linux Boot Process - Novell Docnovell.com
46. Linux Boot Process: UEFI, GRUB, initramfs & systemdgolinuxcloud.com
47. How Linux Actually Boots: From Firmware to the Login Screenfreecodecamp.org
48. Linux Boot Process: GRUB, Initramfs, and Systemd Initialization Deep Dive -timesofcloud.com
49. Comparison of init systems - Gentoo wikiwiki.gentoo.org
50. Self-Hosted Linux Init Systems: OpenRC vs s6 vs runit for Server Management (2026)pistack.xyz
51. A concise comparison of OpenRC, runit, s6, dinit, and SysVinit, plus non-systemd Linux distributions including Artix, Void, Chimera, Devuan, Gentoo, and KaOS. Covers architecture, compatibility, strengths, weaknesses, and recommendations for users migrating from systemd. · GitHubgist.github.com
52. musl vs glibc: Pros, Cons, and Key Differencestuxcare.com
53. musl libc - Functional differences from glibcwiki.musl-libc.org
54. glibc vs. musl — Chainguard Academyedu.chainguard.dev
55. glibc and musl support in Docker Hardened Imagesdocs.docker.com
56. 2. How the development process works — The Linux Kernel documentationdocs.kernel.org
57. How Linux is built with Greg Kroah-Hartmannewsletter.pragmaticengineer.com
58. Linux Kernel Development Model. Linux Kernelshashwotrisal.medium.com
59. Learning about Linux Kernel developmentgithub.com
60. How a Linux Kernel Release is Born-Linux Kernel Development Course Online - embeddedpathashala.comembeddedpathashala.com
61. l19 linux slidescourses.cs.washington.edu
62. Linux Kernel Release Frequency Statistics 2026commandlinux.com
63. Linux kernel licensing rules — The Linux Kernel documentationkernel.org
64. License exception for `GPL-2.0 WITH Linux-syscall-note` file in containerd/btrfs · Issue #174 · cncf/foundationgithub.com
65. This article is more than 1 year oldtheregister.com
66. Linux Mark Instituteen.wikipedia.org
67. Sublicense Agreementlinuxfoundation.org
68. Linus gets tough on Linux trademarkinfoworld.com
69. Torvalds Weighs in on Linux Trademark Rowosnews.com
70. Linux Mark Institute - Wikiwandwikiwand.com
71. SFC v. VIZIO: who can enforce the GPL? [LWN.net]lwn.net
72. The GPL Enforcement Landscape: Lessons from Recent Lawsuits - TermsFeedtermsfeed.com
73. Open source license litigationen.wikipedia.org
74. Vizio sued for breach of copyleft open-source software license - Lexologylexology.com
75. TV maker Vizio sued by customer for alleged open source violationsthestack.technology
76. Software Freedom Conservancy v. Vizio Inc.sfconservancy.org
77. Yearslong Fight Over Users' Right To Tweak Smart TV Software Heads To Trial - Slashdotyro.slashdot.org
78. Software Freedom Conservancyen.wikipedia.org
79. linux/LICENSES/exceptions/Linux-syscall-note at master · torvalds/linuxgithub.com
80. Mark Bolzernen.wikipedia.org
81. Tux Machines — Licensing / Legal: LWN on GPL Enforcementnews.tuxmachines.org
82. A history of Linux distributions · SSD Nodesssdnodes.com
83. Linux vs Unix vs Distro: Ubuntu, Debian, RHEL, Fedora and Arch Explainedgolinuxcloud.com
84. 39 popular Linux distributions and OS [List]stackscale.com
85. Linux Package Managers: Why So Many? Easy 2026 Guidelinuxteck.com
86. Rolling Release vs Fixed Release Linux: Stability, Updates and Which to Choosegolinuxcloud.com
87. Linux Fixed Release vs. Rolling Release Distributions: Which One is Right for You? - Hamradio.myhamradio.my
88. Favorite Derived Linux Distributions (Built on Debian, Arch, etc.) - General Discussions - LinuxCommunity.iolinuxcommunity.io
89. Understanding Linux Families: The Major Types Explained - Coding Architect Devcodingarchitect.dev
90. Linux versions: distros, families, and recommended usespchardwarepro.com
91. graphsearch.epfl.chgraphsearch.epfl.ch
92. Fixed vs. Rolling vs. Semi-Rolling Release in Linux (Explained)linuxtldr.com
93. Rolling vs. Fixed release Linux Distros? Which one is Best for You?averagelinuxuser.com
94. 5 Reasons to Use a Rolling-Release Linux Distributionmedium.com
95. Linux Package Managers Compared: APT, DNF, Pacman and Zypperlinuxblog.io
96. Package Managers • CMPS 2650 • CSUB Facultycs.csub.edu
97. Linux Package Managers: Apt, Yum, DNF, Pacman, and Apkcycle.io
98. APT vs. DNF vs. Pacman: Understanding Linux Package Managers and How to Use Themxtom.com
99. Linux Package Managers: apt, dnf, pacman, Snap, Flatpakalbertoreineri.it
100. X11 to Wayland: Why Linux Desktops Are Moving On in 2026 · Programmers' United Development Networkpudn.club
101. X11 vs Wayland in 2026: Key Differences, Performance & Future Explainedlinuxteck.com
102. How to Install X11 on Ubuntu 26.04linuxconfig.org
103. GNOME dev proposes removing the X11 sessiontheregister.com
104. graphsearch.epfl.chgraphsearch.epfl.ch
105. Why Linux Desktops Are Abandoning X11 for Wayland in 2…besthub.dev
106. KDE to drop X11 session in KDE Plasma 6.8osnews.com
107. Wayland vs Xorg Adoption Trends Statistics 2026commandlinux.com
108. Wayland Linux Gaming in 2026: COSMIC, KDE, GNOME Comparedfosslinux.com
109. Mesa (computer graphics)en.wikipedia.org
110. graphsearch.epfl.chgraphsearch.epfl.ch
111. Simulation / Modeling / Designdeveloper.nvidia.com
112. Nvidia takes first step toward open source Linux GPU driverstagteam.harvard.edu
113. x11 vs Wayland - What are they and which is better? - Peq42peq42.com
114. Wayland vs X11: 2026 Comparison - DEV Communitydev.to
115. Wayland is Taking Over... Will 2026 Be The Death of X11? - TechHuttechhut.tv
116. Ubuntu 25.10 and Fedora 43 to drop X11 in GNOME editionstheregister.com
117. An update on the X11 GNOME Session Removalblogs.gnome.org
118. nouveau · freedesktop.orgnouveau.freedesktop.org
119. Mesa 25.1 to Replace Nouveau Driver with Zink/NVK by Default for NVIDIA GPUs - 9to5Linux9to5linux.com
120. Netfilteren.wikipedia.org
121. Firewallden.wikipedia.org
122. Iptablesen.wikipedia.org
123. nftables - Ubuntu security documentationdocumentation.ubuntu.com
124. Chapter 2. Getting started with nftablesdocs.redhat.com
125. Inside Linux Packet Filtering: Netfilter and nftablesblogs.oracle.com
126. Demystifying Containers - Part I: Kernel Spacemedium.com
127. cgroups and Namespaces — The Linux Kernel's Building Blocks Behind Containers - DEV Communitydev.to
128. Differences Between cgroups and Namespaces in Linuxbaeldung.com
129. Linux Statistics 2026: Desktop, Server, Cloud and Community by the Numberssqmagazine.co.uk
130. Linux Cloud Infrastructure Market Share Statistics 2026commandlinux.com
131. Server OS Market Share Statistics 2026 [Windows VS Linux VS BSD]commandlinux.com
132. Linux Market Share Statistics 2026: Desktop, Server And Enterprise Adoption Trendsfosspost.org
133. Usage share of operating systemsen.wikipedia.org
134. Linux Nears Total Domination of the Top500 Supercomputers - Linux.comlinux.com
135. Linux In TOP 500 Supercomputers Statistics 2026commandlinux.com
136. Linux Is The OS Of Choice For All Top 500 ...easternmirrornagaland.com
137. November 2025top500.org
138. Highlights - November 2025top500.org
139. Fugaku (supercomputer)en.wikipedia.org
140. Jaguar (supercomputer)en.wikipedia.org
141. Slurm Workload Manageren.wikipedia.org
142. NYU High Performance Computing - Slurm Tutorialsites.google.com
143. Slurm — utility for HPC workload managementdocumentation.suse.com
144. Real-Time "PREEMPT_RT" Support Merged For Linux 6.12 - Phoronixphoronix.com
145. PREEMPT RTen.wikipedia.org
146. Getting Started with PREEMPT_RT Guiderealtime-linux.org
147. What Is PREEMPT_RT in Linux? - embeddedpathashala.comembeddedpathashala.com
148. Infrastructure Middleware (Part 1): Hardware Abstraction Layer (HAL)dre.vanderbilt.edu
149. Relocate and Emulate: Re-Hosting Android's Application Layerarxiv.org
150. Capturing Information Flows inside Android and Qemu Environmentsarxiv.org
151. TREBLE: Fast Software Updates by Creating an Equilibrium in an Active Software Ecosystem of Globally Distributed Stakeholdersarxiv.org
152. Yocto vs. Buildroot: Comparing the Two Platformsezurio.com
153. Yocto vs Buildroot: Which Embedded Linux Build System Should You Choose?embien.com
154. Yocto vs Buildroot: Choosing the Right Embedded Linux Build System - Metadesk Globalmetadeskglobal.com
155. Managing AppArmor and SELinux on Ubuntu: Introduction to Linux Security Modulesdolpa.me
156. Characterizing SEAndroid Policies in the Wildarxiv.org
157. Linux Security Module Usage — The Linux Kernel documentationdocs.kernel.org
158. Linux Security Modules Overview: SELinux, AppArmor, and TOMOYO Comparisonlinuxsecurity.com
159. Compare two Linux security modules: SELinux vs. AppArmortechtarget.com
160. Kernel Self-Protection — The Linux Kernel documentationkernel.org
161. Hardening Linux Kernels against Privilege Escalation Exploitscyberask.co.uk
162. State of the Kernel Self Protection Project [LWN.net]lwn.net
163. Kernel Self-Protection — The Linux Kernel documentationdocs.kernel.org
164. Linux kernel security work -kroah.com
165. Reporting Linux kernel bugsandroid.googlesource.com
166. CVEs — The Linux Kernel documentationdocs.kernel.org
167. Linux CVE Hub: Kernel Bugs, Local Privilege Escalation, and Safe Validation Workflowspenligent.ai
168. Securing Linux with SELinux (or AppArmor)linuxblog.io
169. GitHub - mc493/kshield: Zero-Downtime Linux Kernel Attack Surface Hardening, Seccomp Sandboxing & Cryptographic Dual-Witness WORM Defense · GitHubgithub.com
170. Rust in Linux's Kernel 'is No Longer Experimental' - Slashdotlinux.slashdot.org
171. Rust Goes Mainstream in the Linux Kernel - The New Stackthenewstack.io
172. Rust boosted by permanent adoption for Linux kernel codedevclass.com
173. Rust Officially Mainstream in Linux Kernel: Tokyo Summit Ends Years of Controversycanartuc.medium.com
174. Rust in Linux's Kernel 'is No Longer Experimental' - General - Gnoppix Forumforum.gnoppix.org
175. Rust in the Linux Kernel: An Embedded Engineer's Viewtechveda.live
176. đŚ Rust Is Officially Part of Linux Mainlineweeklyrust.substack.com
177. Latest Linux 6.19 Code Fixes Rust Binder Driver, Adds Intel Nova Lake Point S To MEI - Phoronixphoronix.com
178. Linux 6.18 Expected To Land Google's Rust Binder Driver - Phoronixphoronix.com
179. Linux 6.18 Lands Initial Framework For USB Driver Rust Bindings - Phoronixphoronix.com
180. Kernel 6.18: Tyr advances Rust in Linux - Collaboracollabora.com
181. Linux 6.18 LTS: The Latest Long-Term Support Kernelfosslinux.com
182. Android Binder Driver - Rust for Linuxrust-for-linux.com
183. Kernel & Embedded News: Binder Goes Rust-Only in 7.4techveda.live
184. Socket transferring for HPC networks using kernel tracingimage-ppubs.uspto.gov
185. Kernel Tracing using eBPFevents.linuxfoundation.org
186. eBPF Explained: Use Cases, Concepts, and Architecturetigera.io
187. eBPF Observability: How Kernel Tracing Works - Tech Buzz Onlinetechbuzzonline.com
188. What is eBPF (Extended Berkeley Packet Filter)?sentinelone.com
189. What is eBPF? How it Works & Use Casesdatadoghq.com
190. Linux Kernel Driver DataBase: CONFIG_IO_URING: Enable IO uring supportcateee.net
191. RED HAT INC - Form 10-K - FY2007sec.gov
192. RED HAT INC - Form 10-K - FY2004sec.gov
193. IBM buys Red Hat for $34 billionfastcompany.com
194. Red Hat Enterprise Linux Revenue Statisticscommandlinux.com
195. The Linux Foundation Releases Annual Kernel Development Report - Linux Foundationlinuxfoundation.org
196. Linux Foundation Growth Statisticscommandlinux.com
197. The Linux Foundation Releases Development Report Highlighting Contributions to the Linux Kernel Ahead of 25th Anniversary of Linux - Linux Foundationlinuxfoundation.org
198. Linux Foundationen.wikipedia.org
199. The Linux Foundation Spent $8.4 Million on the Linux Kernel Project in 2025linuxiac.com
200. graphsearch.epfl.chgraphsearch.epfl.ch
201. The Cracking of Kernel.org - Linux Foundationlinuxfoundation.org
202. Maintaining the kernel's web of trust [LWN.net]lwn.net
203. Software giant Red Hat gives owner IBM lift to shed its stodgy identitytechxplore.com
204. graphsearch.epfl.chgraphsearch.epfl.ch
205. Linux vs Windowswebsouls.com
206. Home -top500.org
207. The World’s Most Powerful Supercomputers in 2026: LineShine Takes the Leadstackscale.com
208. Linux is small on desktops and huge everywhere elsewebiano.digital
209. Linux Desktop Market Share 2026fosspost.org
210. Linux Desktop Market Share Surpasses 10% in North Americalinuxiac.com
211. Linux Share Tops 10% on US Desktop PCs, Sudden Shift From Windows Raises Questions — BigGo Financefinance.biggo.com
212. Linux Market Share Statistics [March 2026 Report]xtom.com
213. Linux Desktop Share Reportedly Crosses 10%—But There Is a Catchlinuxpanda.com
214. Linux Desktop Market Share: Monthly Trends (2026)linuxpanda.com
215. Historically and globally on desktop, Windows is still largest by far at ~66-72%, macOS is next at ~16-20%, and Linux sits around 3-6%. Linux dominates servers and cloud at 96%+, but desktop share is small even though it’s free. IT folks often pick Mac for the Unix base + battery life + less driver hassle, not market share.threads.com
216. Linux Desktop Market Share Statistics 2026aboutchromebooks.com
217. Linux adoptionen.wikipedia.org
218. Linux Desktop Usage Tops 10% in North America for First Timeyoopya.com
219. Interesting "Market Share" Survey across the computing/phone marketgroups.google.com
220. Linux Driver Support Still Leaves A Lot To Desire - Phoronixphoronix.com
221. Linux desktop hardware support is still broken, and that's why adoption keeps failinghowtogeek.com
222. Linux Doesn’t Lack Drivers, it Lacks Complete Driversapreche.net
223. CriticismFAQ - Ubuntu Wikiwiki.ubuntu.com
224. Criticism of Linuxen.wikipedia.org
225. Snapd vs Flatpak vs AppImage: Cons and Pros Reviewdotlinux.net
226. Linux Packaging Formats: Deb, RPM, Flatpak, Snap & AppImagedaily.dev
227. Comparing snap, Flatpak, and AppImage for universal packages - Linux Bashlinuxbash.sh
228. Alex Salkever, Linux Foundation Researchlinuxfoundation.org
229. This article is more than 1 year oldtheregister.com
230. Core Infrastructure Initiativeen.wikipedia.org
231. Linux Foundation Announces $12.5 Million in Grant Funding from Leading Organizations to Advance Open Source Securitylinuxfoundation.org
232. Linux for Everyone: Can Standardization Drive Mainstream Adoption?arxiv.org