跳至主要內容

Snap、Flatpak 与 Nix：Linux 软件分发的过去、现在与可持续的未来

Yoimiya2026/5/13大约 120 分钟Linux Daily UseLinuxUbuntuSnapFlatpakNixOCIbootcImmutableSoftware Distribution

导读：从 apt install firefox 说起

在近几年的 Ubuntu 桌面上打开终端，输入：

sudo apt install firefox

安装顺利完成，Firefox 出现在应用列表里，表面上与过去十年的使用经验没有区别。但这条命令装入的已经不是 deb 包：从 22.04 LTS 起，Ubuntu 默认交付的是 Snap 版 Firefox——由 Mozilla 官方发布、经 Canonical 的 Snap Store 分发、由 snapd 独立更新[1]。apt 在这里只是一个转发入口。

如果用户接着执行 sudo apt remove firefox，浏览器不会被卸载：Snap 包需要另一条命令卸载，并走另一条更新通道。安装来源、卸载方式、更新机制，三者都发生了变化。

这个安装动作涉及三个方面的矛盾：

  • 用户预期与实际行为：用户认为自己在使用 deb 包管理器，安装结果却发生了重定向；安装前没有提示，snap 的调用要等到安装过程中才出现，卸载时也需要改用另一套命令。
  • 系统稳定承诺与应用更新节奏：LTS 需要长期维持可预测的系统基线，浏览器却需要频繁更新。Canonical 和 Mozilla 希望让浏览器独立于 LTS 的更新周期，以减轻多版本维护的压力。
  • 维护责任转移与支持边界：软件的更新义务从发行版仓库转到上游厂商与 Snap Store，原有的分工随之改变，需要重新说明谁发布、谁审核、出问题由谁提供支持。

围绕它的争论几乎没有停过，其中有两个流传甚广的说法："整个 Ubuntu 都变成了 Snap"，以及"Canonical 私自把 Firefox 换成了 Snap"。公开记录不支持这两种概括。默认发生重定向的只是少数几类高频更新的软件，数以万计的包依然是 deb；Firefox 的转换则由 Mozilla 主动联系 Canonical 推动，Firefox Snap 也由 Mozilla 官方发布[1:1]。转换范围和发布责任的具体记录见 1.1 节。

分歧的来源

讨论这些矛盾时，需要避免三种混淆：

  1. 事实混淆：把少数软件的过渡包当成整个系统的全面替换，或把 Mozilla 与 Canonical 的合作说成 Canonical 单方面替换 Firefox，会让争论从失实的前提开始。
  2. 技术混淆：Snap、Flatpak、deb/RPM、bootc 和 Nix 负责的交付层次并不相同。如果不先说明各自解决什么问题，就容易把不同职责当作同一功能来比较。
  3. 评价混淆：工程原因说明一项决策为什么存在，不能代替对具体实现的评价。Mozilla 与 Canonical 的合作解释了转换由谁推动，却不能替 apt 的静默重定向辩护。

Linux 软件交付的三个层次

为了明确比较范围，可以先按职责把 Linux 软件交付分为三个层次：

层次典型方案主要职责
发行版组件deb、RPM组成经过集成测试的系统基座
独立应用Snap、Flatpak、AppImage、如意玲珑让应用拥有独立依赖和更新周期
系统镜像bootc、rpm-ostree、Ubuntu Core提供原子更新、回滚和可复现状态

三层分别回答不同的问题：deb/RPM 决定系统由哪些组件组成，独立应用格式决定应用如何独立运行和更新，镜像机制决定整个系统如何更新和恢复。Nix 横跨包、开发环境和操作系统配置，难以归入其中任何一层；第 5 部分还将用它讨论项目治理与长期维护。

本文要回答的问题

Snap 是贯穿全文的主要案例，但并非唯一讨论对象。文章从它出发，依次回答三个问题：

  1. 技术可行性：Snap、Flatpak、bootc、Nix 等方案分别解决什么问题，边界在哪里？
  2. 行业趋同性：Canonical、Red Hat、Universal Blue、deepin 等项目，为何在互不相同的技术路线上作出了相似的分层选择？
  3. 组织可持续性：技术路线成立之后，谁来长期承担打包、审核、更新、支持、产品整合和社区治理的成本？

文章关注稳定性、更新速度、用户控制、生态规模和长期维护之间的成本如何分配。这些成本可能由发行版、上游、商店或用户承担。

1 入口与技术方案：Snap 解决了什么问题？

第 1 部分先核实 Snap 在 Ubuntu 中的实际范围，再解释稳定系统与快速应用之间的工程冲突，最后比较 Snap 和 Flatpak 的适用场景与具体代价。

1.1 事实边界：Ubuntu 到底把什么换成了 Snap

先限定争议范围

关于 Ubuntu 与 Snap 的争论，需要先核实两个问题：发生转换的软件范围有多大，以及每个 Snap 由谁推动和发布。前一个问题要求区分三个概念：默认安装、仓库中存在、通过过渡包重定向。

  • 默认安装：指系统安装时预置的软件；
  • 仓库中存在：指某个软件在 apt 仓库里有对应条目；
  • 通过过渡包重定向：指仓库中的某个包名只是一个过渡包，安装它时实际拉取 Snap 版本，deb 包本身不含软件主体。

在 Ubuntu 26.04 的 apt 仓库中执行 apt list | grep snap1，匹配到的过渡包只有三组：Firefox、Chromium、Thunderbird，连同它们各自的 locale 子包[2]。这些过渡包的版本号都带有 1snap1 标记，软件主体在 Snap 端。除此之外，仓库中的其余包——数以万计的库、工具和开发环境——仍以 deb 形式分发，gcc、python3、nginx、rustc 都是 deb 包[2:1]。

软件转换时间deb 包状态Snap 发布者主要原因
Chromium2019-10过渡包Canonical多分支构建与高频安全更新成本
Firefox2022-04过渡包Mozilla上游直接发布并统一更新
Thunderbird后续转换过渡包Canonical + Thunderbird与 Firefox 类似的维护逻辑

Chromium：第一个过渡包

Snap 的前身 Snappy 于 2014 年 12 月首次发布，2016 年随 Ubuntu 16.04 LTS 以 snap 应用格式进入桌面与服务器[3]。而"通过 apt install 安装却实际拉取 Snap 版本"的过渡包机制，要到更晚的时间点才出现。

第一个被转为过渡包的应用是 Chromium。2019 年 10 月 10 日，Canonical 宣布 Ubuntu 19.10 中的 chromium-browser deb 包转为过渡包，安装时实际拉取 Snap 版本[4]。当时 Chromium 大约每六周发布一个大版本，中间还会发布修复安全漏洞的小版本；每个新版都要为多个受支持的 Ubuntu 版本和硬件架构分别构建，旧版 Ubuntu 的编译工具链还可能缺少上游使用的新特性。Chromium 项目提供源代码，但没有像 Mozilla 发布 Firefox 那样为 Ubuntu 直接发布 Chromium；Google 发布的则是基于 Chromium 构建的 Chrome，不是本文讨论的 Chromium 包。因此，Canonical 需要自行编译和发布 Chromium Snap。Snap 每个架构只需构建一次，便可推送到所有支持 snapd 的系统[4:1][5]。

Debian Stable 提供了这份工作量的对照：Debian 中 Chromium 的安全更新横跨 oldoldstable（120.x）、oldstable（143.x → 148.x）、stable（145.x → 148.x）到 unstable（148.x）四个分支，这些大版本更新的移植一度由同一位维护者 Andres Salomon 承担[6]。这个案例只说明单个软件在多分支维护上的具体代价，不能代表 Debian 整体的维护状态。

Firefox 与 Thunderbird：上游厂商直接发布

Firefox 的转换比 Chromium 晚两年多，发布责任也不同。2021 年，Mozilla 主动联系 Canonical，希望把 Mozilla 官方的 Firefox Snap 设为 Ubuntu Desktop 的默认版本；Canonical Desktop、Snap 团队和 Mozilla 开发者共同推进转换，并计划在 22.04 开发周期内完成[1:2]。因此，把这次转换概括为"Canonical 私自替换 Firefox"并不符合公开记录。Mozilla 希望绕过为每个 Ubuntu 版本单独维护 deb 的延迟，直接向所有支持 snapd 的发行版推送安全补丁和新功能。在 Snap Store 中，Firefox Snap 带有 Verified 标识，由 Mozilla 官方直接发布和维护；Canonical 工程师则与 Mozilla 协作，优化 Snap 在 Ubuntu 上的性能表现和沙箱隔离策略。从 Ubuntu 22.04 LTS 起，新安装系统的用户默认获得 Snap 版 Firefox：输入 apt install firefox，安装的是 Mozilla 官方维护的 Firefox Snap。

Thunderbird 的转换逻辑与 Firefox 相似：同样是绕过发行版版本锁定的 Snap 交付，同样由 Snap Store 统一更新。区别在于维护主体：Thunderbird snap 由 Canonical 与 Thunderbird 项目共同维护[7]。

争议主要来自 apt 的行为与用户预期不一致：输入一条 deb 管理器的命令，得到的是另一套分发渠道。这个问题将在 1.4 节展开。

1.2 结构性矛盾：稳定 OS 与快速应用

稳定发行版如何维持兼容基线

Ubuntu LTS、Debian Stable、RHEL 与 openSUSE Leap 都需要在一个发行版的生命周期内维持可预测的接口、依赖关系和运行行为。维护者会继续回溯安全补丁与重要错误修复，同时避免常规更新破坏已有应用、配置和服务[8]。锁定大版本可以缩小每次更新需要重新验证的范围。

旧版本本身不会带来稳定性。发行版要通过打包规范、依赖管理、构建和测试，把一组软件整理成能够协同工作的系统；发布后还要控制改动，并持续提供必要修复。附录 A 以 Debian、Arch、Gentoo 和 openSUSE Tumbleweed 为例，比较固定发行版与滚动发行版如何组织这些工作。

这套工作需要大量人力。维护者除了初次打包，还要处理安全修复、构建失败和依赖变化。软件更新越频繁、内部耦合越复杂，后续维护越重。Debian 的人员规模和维护压力见 2.2 节。

浏览器为什么不适合跟随传统发行周期

浏览器是这套稳定承诺下最别扭的存在。Firefox 大约每四周发布一个大版本，Chromium 的发布节奏更快，每个版本除了新功能还包含大量安全修复。浏览器同时是日常使用最频繁的应用和高风险的安全边界：它持续解析来自不可信网络的 HTML、JavaScript、媒体与加密数据，内存破坏类漏洞可被远程利用。

发行版仍要及时修补浏览器，但浏览器的安全修复经常伴随代码重构、工具链更新和组件升级。维护旧基线时，发行版要筛选需要回溯的修改，解决旧环境中的构建问题，再为每个受支持的分支分别验证。Canonical 在解释 LTS 时也指出，软件缺少持续的安全更新会逐渐带来风险[9]。

ESR（Extended Support Release）是合理的折中。Debian Stable 提供 Firefox ESR，在一个延长支持的主版本上持续接收安全与稳定性修复，减少频繁升级带来的维护压力[10]。代价是新功能进入得更慢。作者在 Debian 上使用 Firefox ESR 时发现，它会落后普通 Firefox 多个大版本，因而缺少 WebGPU 与部分编码器等较新的能力（作者体验，截至 2026-08）。

2012 年 10 月，Mozilla 发现 Firefox 16 存在漏洞后移除了受影响的安装包，次日发布 16.0.1 并向用户推送自动更新[11]。浏览器需要按数周节奏交付整个应用，系统基座却希望多年维持可预测的接口和依赖。发行版可以为普通系统库维护固定基线并回溯必要补丁，面对高速迭代、内部高度耦合的浏览器时，这种做法往往会形成一条长期下游分支。

四种可能方案及其成本

面对"稳定基座"与"快速应用"的矛盾，发行版有四种选择，每种都有代价：

方案优点主要成本
为每个稳定版回溯补丁保持 ABI、依赖和行为边界稳定大量维护人力，容易形成关键人物依赖
在发行版仓库持续推送新版用户获得最新功能需要处理依赖变化、ABI/API transition 与回归测试，扩大系统变化面
默认接入上游第三方源上游直接发布超出发行版完整测试和支持边界
使用独立应用格式应用与系统依赖解耦引入沙箱、商店、磁盘占用和治理问题

Ubuntu 选择了第四种（Snap）。继续为每个 LTS 回溯浏览器补丁需要长期投入维护人力，直接在仓库中推送新版又会增加依赖变化和回归测试。接入 Mozilla 官方 apt 源可以把发布工作交给上游，但这些软件包不在 Ubuntu 的完整测试边界内。Ubuntu 默认也不开启第三方软件源[12]。Snap 将浏览器及其大部分应用依赖与系统基座分开，Mozilla 可以按自己的节奏发布，Canonical 不必在系统仓库中反复适配多个 LTS 基线。

deb/RPM 负责把大量组件组织成一套经过集成验证的系统。Snap 和 Flatpak 则让更新更快的应用脱离系统的依赖和发布节奏。这种解耦减少了系统仓库的维护压力，同时引入了沙箱集成、更新控制、商店治理和磁盘占用等问题。

Ubuntu 保留了同时服务服务器和桌面的稳定 base，再用 Snap 等独立渠道补足桌面应用的更新速度。软件交付因此不再全部经过同一条渠道，但 Canonical 也不用维护两套不同节奏的完整系统。

RHEL 在同一矛盾下做了同向选择，只是技术路线是 Flatpak：RHEL 10.0 已将 Firefox/Thunderbird 的 RPM 包标记为 deprecated，RHEL 10.2 起在 GNOME 安装场景默认预装 Flatpak 版本，同时在 RHEL 10 生命周期内继续在 AppStream 提供 RPM 包作为离线与策略受限场景的后备[13]。Red Hat 的动机与 Canonical 一致，即操作系统提供稳定平台，快速迭代的应用独立分发。两家公司选择了不同的应用格式，但都在拆分系统与应用的更新周期[13:1]。

为什么滚动发行版不是普遍答案

滚动发行版也要处理共享库 ABI、配置格式和默认行为的变化，只是它持续验证并交付新的系统状态，不长期维护固定的发布基线。用户需要及时关注重要公告、处理配置更新，并避免不受支持的部分升级。发行版减少了向旧基线反复回溯补丁的工作，用户则要更快适应系统变化。

这类模式适合希望持续使用新软件的个人用户。服务器和企业环境通常还需要固定支持周期、认证环境、可预测行为和 SLA，因此更常采用 Stable 或 LTS。两种模式都需要发行工程，区别在于更新频率、验证窗口和成本分配。附录 A 展开比较 Arch、Gentoo 与 openSUSE Tumbleweed 的做法。

浏览器之外

锁版本的影响不止于浏览器。对桌面用户常用的开发工具，Ubuntu 官方源的版本经常落后上游：Neovim 在 Ubuntu 24.04 LTS 官方源停留在 0.9.x，而最新稳定版已是 0.12.x 以上；PrismLauncher 在官方源锁在 10.0.5、Snap 版已更新到 11.x；fish、fastfetch、ripgrep 等工具同样存在版本落差[14]。

系统仓库优先维持经过整体测试的发布基线，因此这类版本差距符合它的维护目标。需要新版本的用户可以选用 PPA、Flatpak、Snap 或 Homebrew，也可以使用滚动发行版。各渠道承担的依赖管理和维护责任不同，选择取决于具体软件和使用场景。

1.3 Snap 与 Flatpak：不同场景的技术取舍

两者解决的问题不同

Flatpak 与 Snap 常被当作直接竞争的同类物来比较。但它们的目标范围不同：Flatpak 主要面向桌面 GUI 应用；Snap 同时覆盖桌面应用、CLI、IDE、后台服务、IoT 与系统组件。商店应用数量或启动速度这类单一指标不能衡量两者的全貌。更合理的比较方式是：针对具体的软件类型，看每个方案如何处理沙箱、驱动、宿主访问与分发治理。

浏览器沙箱与嵌套隔离

现代浏览器内部自带一套多进程沙箱：渲染进程、GPU 进程、插件彼此隔离，防止恶意网页突破浏览器触及系统。这套机制依赖 Linux 的非特权 user namespace，普通用户无需 root 即可创建隔离命名空间来运行渲染器。Chromium 的沙箱实现中，namespace sandbox 明确基于 unprivileged user namespaces，自 M-43 起在内核支持时取代 setuid sandbox[15]。这是浏览器安全模型的基础。

Flatpak 的沙箱基于 Bubblewrap，其 seccomp 过滤器阻止沙箱内应用创建子命名空间。官方文档明确写道 "Flatpak won't allow spawning sub-namespaces in the sandbox"[16]。这项限制本身是合理的逃逸防护，但它与浏览器的内置沙箱直接冲突。浏览器在 Flatpak 里只能二选一：关闭自己的内置沙箱、把安全外包给 Flatpak 外层；或依赖 zypak 这类兼容层绕过限制。两条路径都不完整。

这个冲突的现状不是"已经解决"。2025 年 Linux Application Summit 上，Flatpak 核心开发者 Sebastian Wick 的表述是：嵌套沙箱在 Flatpak 中 "does not work"，相关问题 "存在已久，但没人知道如何解决"[17]。他同时指出 Flatpak 核心开发放缓，大量功能合并请求无人认领 review[17:1]。这些是 Wick 的会议发言，不是本文作者的定论；但作为 Flatpak 核心开发者的一手陈述，它说明嵌套隔离问题至今没有公认解法。Wick 在同一演讲中也提到，user namespace 如今已是 "well-tested and a much-used interface"，Flatpak 用 seccomp 阻止其暴露的限制有历史原因，如今已没有太多反对的理由[17:2]。也就是说，这个冲突存在缓和空间，但截至 2026-08 尚未在 Flatpak 中落地。

Snap 在这条路径上的取舍不同。它的 strict confinement 用 AppArmor、seccomp 与 namespaces 提供外层边界[18]，但官方对其定位是"叠加在浏览器自身沙箱之上的额外安全层"：Canonical 解释 Firefox snap 时写道，浏览器沙箱保护浏览器免受恶意代码侵害，snap confinement 则保护用户免受浏览器越界行为侵害[19]。浏览器内部的多进程隔离与 user namespace 沙箱因此得以保留。这是 Canonical 与 Mozilla 协作的结果，也是 Canonical 选择 Snap 而非 Flatpak 分发 Firefox 与 Chromium 的核心技术原因。

Nvidia 闭源驱动

对 Nvidia 显卡用户，图形驱动的处理是两者另一个差异点。

Flatpak 需要用户额外安装与宿主机版本严格匹配的 org.freedesktop.Platform.GL.nvidia runtime。结果是系统上同时存在两份 Nvidia 用户态驱动——宿主机一份、Flatpak runtime 一份；宿主机驱动更新后若 runtime 未及时跟进，版本不匹配可能导致黑屏或崩溃[20]。

Snap 通过 gpu-2404 content interface 把宿主机的 GPU 用户态驱动库直通给 snap 容器[21]。作者在本机实测：lsof 显示 Snap 应用运行时直接读取 /var/lib/snapd/hostfs/.../libnvidia-glcore.so.595.71.05，路径中的版本号即宿主当前驱动版本；宿主机驱动从 595.58 升到 595.71 后，Snap 应用无需 refresh 即用上新驱动。

两者在解耦与同步之间作了不同取舍：Flatpak 单独分发驱动运行时，需要留意它与宿主驱动的版本是否一致；Snap 直接使用宿主驱动，减少了两份驱动之间的同步工作，但隔离边界也更依赖宿主驱动的状态。

Flatpak 的强项

Flatpak 为桌面 GUI 应用设计，在这一领域更成熟：

  • 桌面 GUI 生态：Flathub 上桌面应用的数量与更新活跃度高于 Snap Store（截至 2026-08 的对比）[22]；
  • Wayland 原生支持：Flatpak 应用通常以原生 Wayland 运行，而 VSCode 的 Snap 仍走 XWayland[23]；
  • Portal 集成：文件选择器、屏幕截图、打印等桌面 Portal 功能的支持更完善；
  • 权限管理：Flatseal 提供图形化界面精细调整每个应用的沙箱权限；Snap 的 snap connections 也能做到，但操作不如 Flatseal 直观。

Snap 的强项

Snap 的定位更广，覆盖 Flatpak 之外的多类场景：

  • classic 模式对 CLI 与 IDE 友好：classic snap 不设沙箱隔离，直接访问宿主的 home、usr、编译器、Git、SSH agent。JetBrains 全系 IDE 与 VSCode 有厂商官方维护的 Snap（classic），安装后体验接近原生。Flatpak 要做同样的事，需要 flatpak-spawn --host、额外的 SDK Extension、逐个环境变量。
  • 后台服务与系统组件：Docker、LXD、MicroK8s 等后台服务可通过 Snap 打包部署。例如，MicroK8s 官方给出的 Linux 安装命令就是 sudo snap install microk8s --classic，安装后相关服务会持续运行并在重启后自动启动[24]；Flatpak 无法管理守护进程、不能定义 systemd 服务。
  • Flatpak 对 CLI 的天然短板：Flatpak 应用通常要用完整的应用 ID 启动，例如 flatpak run io.github.sxyazi.yazi；对需要在 shell 中频繁调用的 CLI 工具，这比直接输入 yazi 多了一层。用户可以设置 alias 或包装脚本缩短命令，但这仍是需要逐个配置的 workaround，没有让应用获得原生包那样直接的命令入口。Flatpak 官方文档也明确写道 "Flatpak is best suited for desktop applications. While command-line applications also work, Flatpak may not be suitable in some cases"，随后列举：无法运行 SUID 二进制（su、sudo、pkexec）、不能访问宿主 /proc、seccomp 拦截子命名空间创建、内核模块与驱动不适用、不导出 udev 规则与 systemd 服务[25]。

对 IDE 这条路径，Universal Blue 的 Bluefin DX 变体给出了明确立场：官方文档推荐用 ujust jetbrains-toolbox 安装 JetBrains Toolbox，由它统一管理 JetBrains 全系 IDE 的安装、移除与升级，整个过程在用户主目录内完成、独立于系统镜像；文档同时明确写道，不推荐使用 JetBrains 的 Flatpak 包（"We do not recommend using the JetBrains flatpaks"）[26]。VS Code 则被 Bluefin DX 直接作为镜像默认 IDE 预装[26:1]。IDE 的部分工作流需要直接访问宿主文件系统、工具链和凭据，这会增加沙箱配置的复杂度。

在服务器管理层，Canonical 还把 Livepatch 与 Landscape 放进 Ubuntu Pro 的支持体系。Livepatch 客户端本身以 canonical-livepatch Snap 发布，负责在维护窗口之外处理可实时修补的 High 与 Critical 级内核漏洞；Landscape 则可集中监控和管理 Ubuntu 主机、更新以及 Snap。Livepatch 延后的是非计划重启，并不取代常规内核更新和后续维护窗口中的重启。这组产品安排说明，Canonical 把 Snap 应用、内核补丁和集中管理放进了同一套交付与支持体系。Snap 在这里承担的已经不只是桌面应用分发[27]。

场景化对比

场景更值得优先考虑的方向判断依据
普通桌面 GUI 应用Flatpak桌面生态、Portal、权限工具更成熟
浏览器逐包评估内外沙箱、上游维护者与发行版集成方式
IDE 与宿主开发环境深度交互Snap classic 或原生包需要访问宿主工具链与凭据
CLI 工具原生包、Homebrew 或 Snap命令入口与宿主文件访问更自然
后台服务与 IoTSnap服务生命周期与系统组件能力
不可变 Fedora 桌面Flatpak + 容器化开发环境与系统镜像分层方式一致

1.4 Snap 实现中的具体问题

前文说明了解耦的工程动机与 Snap 的技术定位，但工程动机成立，不代表具体实现没有问题。下面分别讨论安装透明度、治理结构、桌面实现和网络可达性。

apt 静默重定向

apt 是 Debian/Ubuntu 生态的基础工具，用户在终端输入 apt install firefox 时，预期是安装一个 deb 包——这是十几年的默认行为。实际发生的是系统静默安装 Snap 版 Firefox，安装前没有任何提示说明这一点，snap 的调用要等到安装过程中才出现。卸载行为同样不一致：apt remove firefox 不会真正移除 Firefox 的 Snap，因为 Snap 由 snapd 独立管理，不在 apt 追踪的 deb 包清单里。用户看到浏览器仍在系统中，自然对系统的行为产生困惑。

不过，这个问题主要出现在用户主动管理软件时。Ubuntu 桌面版安装完成后自带 Firefox，对从不接触命令行的新手，浏览器在 Dock 上、点击即用，底层是 deb 还是 snap 并不重要；用户开始用 apt 安装或卸载 Firefox 后，实际行为才会与原有预期脱节。"默认开箱即用"的产品取向与"用户可预期地管理系统"之间存在冲突。

过渡包完全可以在 postinst 脚本中给出明确提示，说明此命令实际安装的是 Snap 版本，以及如何改回传统 deb。Canonical 没有这样做。将 Firefox 改为 Snap 有工程上的理由，但过渡包在透明度和沟通上仍有改进空间。

Snap Store 闭源与中心化

另一个争议点是 Snap Store 本身。snapd 客户端是开源的，源码托管在 GitHub 的 canonical/snapd 仓库，社区可以审计与贡献[28]。但 Snap Store 的服务端由 Canonical 独家运营，服务端代码未开放；用户无法审计后端做了什么，也无法运行一个完全独立于 Canonical 的 Snap Store。

"用户无法自建 Snap Store 镜像"这一说法不够准确。Canonical 提供 Snap Store Proxy（现更名 Enterprise Store），企业可以在内网自托管一个缓存代理，支持本地缓存、版本锁定和离线模式[29]。但它是一个本地边缘代理，仍依赖 Canonical 的签名与公共 Store 基础设施，离线模式也需要先从联网系统导出再导入。Store 后端依旧闭源，无法 fork 一个替代 Store，平台依赖仍集中在 Canonical 一家；代理解决的是分发与缓存，不改变这个治理结构。

中心化本身也有功能上的理由。Canonical 对 Snap Store 上架的软件有审核机制，从降低恶意软件风险的角度看，比任何人都能上传 PKGBUILD 的 AUR 更有保障[30]。Canonical 也依靠这套中心化结构持续投入分发基础设施。不过，审核和持续投入带来的收益没有消除控制权集中的问题。

桌面体验短板

与专注桌面 GUI 的 Flatpak 相比，Snap 在桌面端有具体不足，需区分历史问题与现状：

  • VSCode Snap 至今只支持 XWayland，无法原生运行在 Wayland 下，输入法体验受影响（见 1.3 节）；
  • 第三方主题适配不如 Flatpak 流畅，非 Yaru 主题下的外观一致性依赖 gtk-common-themes；
  • 部分 Intel Xe 核显的 VA-API 硬件解码存在问题[31]；
  • Firefox Snap 早期问题：插件兼容、中文输入法调用、冷启动速度、主题异常、密码管理器集成，多数已随版本迭代改善，但早期体验留下的负面印象是真实的[32]。

这些是体验层面的短板，多数可修复，属于可改善的实现问题；同时它们是用户日常感知最直接的部分。

国内网络与可达性

对国内用户，Snap 有一个额外的障碍：网络。据社区反馈，Snap Store 走 Cloudflare CDN 但未启用中国大陆节点，下载速度不稳定；Flatpak 可以通过中科大等镜像站换源，Snap 无法以同样方式换源[33]。移动宽带用户受影响更大，代理能缓解但本身是门槛。中心化基础设施放大了地区网络差异：单一分发源让网络质量直接决定可用性。

中文社区也在开发类似方案。deepin 自研的如意玲珑（Linyaps）同样通过沙箱隔离应用与系统，项目已于 2024 年捐赠给开放原子开源基金会[34]。它目前主要在 deepin 与国产系统生态内流转，跨发行版的实际体验尚缺第三方验证；详细对照见 2.4 节。

1.5 小结

Ubuntu 中只有三类软件通过过渡包转为 Snap 版本，因此不能据此断言"整个系统都在转向 Snap"。这三类转换反映了一个更具体的问题：发行版需要为更新节奏不同的软件重新分配维护责任。Snap 可以承担独立分发，但静默重定向、商店中心化、桌面集成和网络可达性仍需单独评价。下一部分将考察 Canonical 之外的项目是否也在作类似调整。

2 行业对照：Canonical 之外的解耦路线

如果解耦只是 Canonical 一家的选择，前面的论证就只对 Ubuntu 成立。下面比较 RHEL、Debian、Universal Blue 和如意玲珑，看看其他项目如何处理稳定系统、快速应用、更新回滚和长期维护。各项目的实现路径和治理方式并不相同。

2.1 RHEL：六年渐进式解耦

Red Hat 把 Firefox、Thunderbird 的默认交付从 RPM 改为 Flatpak，这个过程从 2020 年持续到 2026 年，并非一步到位。按时间顺序排列，可以看到一条渐进预览、默认切换、后备并存的路径。

时间线

时间动作
2020（RHEL 8.2）引入 Red Hat Flatpak Runtime，与 RHEL 生命周期对齐，承诺 10 年安全更新[35]
2021（RHEL 8.3.1）Firefox、Thunderbird、GIMP、Inkscape 首批 Flatpak 镜像上线 Red Hat Container Catalog[36]
2023（RHEL 9.2）LibreOffice 的 RPM 包标记 deprecated，改由 Flatpak 交付[37]
2025（RHEL 10.0）Firefox、Thunderbird 的 RPM 包正式 deprecated[13:2]
2026（RHEL 10.2）Anaconda 安装器默认预装 Flatpak 版，RPM 保留 AppStream 作后备，Kickstart 可回退[13:3]

早在 RHEL 10.0 Beta 阶段，发行说明就已写明 Firefox、Thunderbird 在 RHEL 10 中仅以 Flatpak 提供[38]。RHEL 10.0 正式将 Firefox 和 Thunderbird 的 RPM 标记为 deprecated，10.2 再把 Flatpak 设为默认。Red Hat 官方博客的表述是 "RPMs for Firefox and Thunderbird were deprecated in RHEL 10.0, and RHEL 10.2 completes the transition by making Flatpaks the default"[13:4]。

Red Hat 选择 Flatpak 的原因

Red Hat 给出的理由与 Ubuntu 选择 Snap 的理由相似：桌面应用有独立的依赖与更新周期，跟随发行版的 minor release 节奏会拖慢安全修复与功能更新；把桌面应用从系统基座解耦后，发行版工程师可以把资源集中到 Wayland、HDR、颜色管理等底层平台方向。Red Hat 停止随 RHEL 提供 LibreOffice 的 RPM 包，改由 Flatpak 交付，就是这种分工的一个例子。Red Hat Display Systems 团队在 Fedora 邮件列表里说明，团队将工程重点放在"Wayland、HDR 等 Workstation 用户需要的方向"[37:1]。

同时，Red Hat 保留了受控的后备路径。企业离线环境、合规策略、长期支持仍要求 RPM 可用：整个 RHEL 10 生命周期内，Firefox、Thunderbird 的 RPM 包都保留在 AppStream，Kickstart 可以强制回退[13:5]。这是"默认解耦"，并非"废除 RPM"。

与 Ubuntu 的差异

同样是解耦，Red Hat 的路径比 Ubuntu 更渐进：从 runtime 铺垫（8.2），到首批镜像（8.3.1），到单个应用 deprecation（9.2 的 LibreOffice），再到浏览器 deprecation（10.0）与默认切换（10.2），每一步都有明确的发行说明与回退路径。Ubuntu 的过渡包机制更直接：apt install firefox 静默拉 Snap，沟通与用户选择都更弱（1.4 节已述）。两条技术路线不同，面对的是同一个发布节奏矛盾。

下游 Rocky Linux 10.2 同步跟进，把 Firefox、Thunderbird 的默认交付也改为 Flatpak，同样保留 AppStream 的 RPM 与 Kickstart 回退[39]。

2.2 Debian：传统打包模式的人力成本

Red Hat 用商业投入承担打包和维护工作；Debian 主要依靠志愿者，同样的工作更容易表现为人力缺口。Debian 采用传统打包模式，每个软件包都由志愿者按照发行版节奏打包、测试和回溯安全修复。

维护规模与贡献者变化

Debian 13（trixie）共有 69,830 个软件包[40]。正式开发者（Debian Developer）的人数长期稳定在约一千人：2012 年 948 人，2025 年 1030 人[41]。人数没有下降，维护对象却在持续增长。

2020 年 DebConf20 上，时任 Debian 项目领导人 Jonathan Carter 给出的数字更直接：项目账上有超过 90 万美元，但只有约 975 名上传开发者和 223 名维护者，要维护超过 6.1 万个 amd64 二进制包；他估算要达到目标又不增加现有开发者的压力，大约需要三倍人力[42]。Carter 的结论很明确：Debian 缺的主要是人手，不是账面资金。

浏览器与多稳定分支维护

稳定发行版的多分支回溯在 Debian 上有一个具体案例：Chromium 的安全更新横跨四个 stable 分支，这些大版本更新的移植一度由同一名维护者 Andres Salomon 承担[6:1]。这是 1.2 节讨论的"稳定系统与快速应用不可同步"在 Debian 侧的表现：稳定发行版要同时维护多个稳定分支，每个分支都要回溯安全修复，工作量随分支数量增长。Firefox 在 Debian 稳定版中以 ESR 形式提供[10:1]，这一选择降低了维护频率，代价是用户拿不到最新功能。

关键团队、审核和新人入口

人力缺口不只在单个软件包，也在关键基础设施团队。管理 Debian 软件仓库超过 20 年的 FTPmaster 团队，2025 年 10 月宣布解散，职责拆分为两个新团队，以便各自聚焦、降低新成员加入的门槛；长期人手不足是这一调整的背景[43]。2026 年初，处理 GDPR 相关事务的数据保护团队，三名委派成员全部退出，委派被正式撤销[44]。

审核也会占用有限的人力。NEW 队列负责新包进入归档前的合规审核，个别包会滞留数月，有开发者提交后长时间等待审核、工作因此搁置[45]。不过，这些个案不能代表整个队列：2025 年 3 月的公开分析显示，NEW 队列的中位处理时间不到 48 小时，只有约 2% 的包会滞留数月以上[45:1]。长时间等待主要集中在少数复杂或需要改名的包上，队列整体吞吐正常。

针对维护者悄然流失的问题，现任 DPL Andreas Tille 在 2026 年初提出用六阶段自动化 MIA（Missing in Action）流程追踪长期不活跃的维护者[46]。目前这是提案层面的机制设计，尚未落地。

小众方向的结局更直接：Debian GNU/kFreeBSD 端口（FreeBSD 内核 + GNU 用户态）在 Debian 8 之后不再进入正式发布，2023 年 7 月因缺乏维护者与兴趣正式终止开发[47]。缺乏维护者的小众方向不会自动存活。

钱为何不是唯一答案

账上资金不能直接转化为愿意长期维护项目的人力。Debian 有 90 万美元，Carter 仍把主要问题归结为缺人[42:1]。2006 年的 Dunc-Tank 实验提供了一个历史对照：有人尝试向 etch 的发布经理支付报酬来推进发布，在社区引发争议，说明在志愿者协作中引入付费安排可能改变协作关系[48]。

维护者精力耗尽也并非 Debian 独有。2022 年 Linux 存储与文件系统峰会上，Josef Bacik 主持的关于维护者压力的讨论，标题就是 "Maintainers don't scale"[49]。2023 年，内核社区宣布把长期支持（LTS）周期从六年缩短到约两年，理由是旧的 LTS 内核实际使用率低、维护成本高[50]。2026 年 1 月，内核项目合并了一份连续性文档，规定当顶层仓库维护者无法继续工作时如何在一周内启动继任讨论，回应的正是核心维护者单点故障的风险[51]。

2.3 Universal Blue：不可变桌面的另一种实现

Universal Blue（简称 ublue）是一组基于 Fedora Atomic Desktops 构建、持续交付的系统镜像，并非独立的发行版[52]。它把云原生工程里的镜像构建与持续交付做法搬到桌面：用 bootc 构建不可变系统，产品定位是 Chromebook 级别的可靠性与传统 Linux 桌面的完整能力。

基本模型

Universal Blue 与叠加式包管理的传统发行版在模型上不同。传统发行版在基础系统上用包管理器一层层安装软件，每台机器经过不同的操作历史，系统状态各不相同。Universal Blue 的模型是：

  • 基础系统由只读的 OCI 容器镜像定义，用 Containerfile 声明式描述，在 GitHub Actions 上构建。镜像托管在 ghcr.io，并用 sigstore 签名[52:1]。
  • 系统更新是原子操作：后台下载完整的新镜像，重启后切换到新版本，出问题可以回退[52:2]。
  • 桌面应用以 Flatpak 为主，与系统层隔离。
  • CLI 工具与开发环境通过 Homebrew 或 Distrobox、Toolbx 等容器工具获得，容器内可以是任意发行版的用户空间，不修改宿主系统。

原子更新与回滚

bootc 是这套模型的关键组件，它的核心做法是把整个操作系统打包成 OCI 容器镜像，与 Docker 镜像同一套标准。bootc 的定位是 "Transactional, in-place operating system updates using OCI/Docker container images"：用标准容器镜像作为基础系统的交付格式，镜像本身包含用于引导的内核[53]。

这种更新方式与 Android 的 A/B 思路相似：新版本先在后台准备好，重启时切换，出问题回到上一版本。区别在实现，bootc 基于 ostree 在同一系统内维护多个可切换的文件树部署，而非在两个物理系统分区之间切换。Universal Blue 的镜像在 ghcr.io 上保留九十天，用户可以把系统切回这段时间内的任意版本[52:3]。

产品化价值

Universal Blue 在构建镜像时就配置好驱动、编解码器和 Secure Boot 等组件，让普通用户安装后可以直接使用：

  • Nvidia 驱动内置在镜像里，不需要手动配置源安装[54]。
  • 视频编解码的硬件加速开箱可用[54:1]。
  • Secure Boot 支持开箱即用[54:2]。
  • 系统自动更新，更新后上一版本仍保留在机器上，可随时切回[54:3]。

四个主要变体面向不同用户：Bluefin 面向 GNOME 桌面的开发者和普通用户，预配置容器化开发工具；Aurora 是 Bluefin 的 KDE Plasma 版；Bazzite 面向游戏与 HTPC，预装 Steam、Lutris 和模拟器；uCore 基于 Fedora CoreOS，提供面向服务器的轻量镜像[52:4]。

局限

  • 基础系统只读，不能直接 dnf install，安装软件的方式随之改变。
  • 桌面应用依赖 Flatpak；某个应用只有 Snap 或 deb 时无法直接安装，Distrobox 可以运行但体验打折扣。
  • 镜像构建与分发依赖 GitHub 与 ghcr.io，上游基础设施宕机会影响更新[52:5]。
  • 社区维护，没有商业公司的长期支持保障。

2.4 deepin 与如意玲珑：本土生态的回答

前两节说明应用与系统解耦在 Red Hat 和 Universal Blue 的落地；同一判断也出现在中文社区。deepin 自研的如意玲珑（Linyaps）走沙箱解耦路线，deepin 25 的磐石系统走不可变路线。这一节把两者放在一起，说明本土生态如何回答同一个问题。

要解决的问题

如意玲珑要解决的核心问题与 Snap、Flatpak 相同：应用依赖与系统依赖解耦。它的针对性更强，国产应用要在多个 Linux 发行版之间构建和交付，逐一适配 deb、RPM、AppImage 等格式成本高。玲珑用一套容器化格式，主张一次构建、跨发行版运行，支持 deepin、UOS、openEuler 以及 Ubuntu、Debian 等主流发行版[34:1]。

对国内用户还有一层网络层面的理由。1.4 节已述，Snap Store 的国内可达性差，Flatpak 需要换镜像。据社区反馈，玲珑商店在国内网络下开箱即用，并上架了腾讯会议等一批国产常用软件的 Linux 版，这正是 Snap Store 和 Flathub 长期缺失的部分。

deepin 25 的磐石系统对应系统层：核心目录只读挂载，更新走原子化增量，更新失败或无法启动时自动回滚到上次备份[55]。如意玲珑负责应用层，磐石负责系统层，两者是同一套分层思路在中文生态的落地。

技术与治理

如意玲珑的沙箱基于 User Namespace 与 CGroup：每个应用有独立的用户与组 ID 视图，容器内的 root 映射到宿主机非特权用户，配合文件系统隔离与权限声明，实现应用与系统、应用之间的隔离[56]。存储采用写时复制，多个应用共享只读的运行时层与基础层，只在修改时复制，官方称相比传统打包可节省约 60% 存储空间[56:1]。

治理上，玲珑于 2024 年 5 月 24 日正式捐赠给开放原子开源基金会，代码托管在 GitHub 的 OpenAtom-Linyaps 仓库，不属于单一商业公司[34:2]。生态集成方面，xdg-desktop-portal 在 1.21.0 版本（2026 年 1 月发布）加入了对玲珑应用的支持，应用信息模块新增 linyaps 子类[57]。如意玲珑官网的"发展历程"把 XDG 正式支持归入 2025 年度，可精确查证的落地时间是 1.21.0 的发布[57:1]。

成熟度边界

已发布、可复现的能力是明确的：如意玲珑已完成 x86_64、ARM64、LoongArch 等架构适配，支持 10 余个主流发行版，上架应用规模在数千款（官网称 6000+，deepin 25 发行注记发布时为 5000+）[56:2][55:1]。deepin 25 的磐石系统已随发行版交付只读、原子更新、回滚能力[55:2]。

官网主张的跨发行版能力与实际覆盖范围仍有差距。玲珑主要围绕 deepin、UOS、openEuler 等国产发行版，在 Ubuntu、Debian 等发行版上的第三方验证还较少；一次构建跨发行版运行是目标，落地程度取决于各发行版对玲珑运行时的集成。官网列出的外设适配、权限细化和商业软件适配仍是未来规划，尚未成为已发布功能。

2.5 四条路线的汇聚与边界

第 2 部分比较了四条路线：Ubuntu、RHEL、Universal Blue、deepin。它们都要处理稳定系统与快速应用更新节奏不同的问题，也都面对不断增长的打包和维护成本，但选择了不同的技术路线与治理方式。

四条路线的对照

维度UbuntuRHELUniversal Bluedeepin
应用层deb + SnapRPM + FlatpakFlatpak + Homebrewdeb + 如意玲珑
系统层deb；Ubuntu Core 全 Snap[58]RPM；Image Mode 基于 bootc[59]OCI/bootc（底层 ostree）磐石系统路线
更新重点跨场景统一分发企业生命周期与渐进解耦镜像原子更新和回滚本土桌面与应用生态
治理主体CanonicalRed Hat社区项目企业、社区与基金会
主要代价商店中心化与桌面体验企业策略和生态范围上游及镜像基础设施依赖跨发行版成熟度仍需验证

可以归纳的共同趋势

四条路线在应用层、系统层、更新机制和治理上各有选择，但共享几个方向：

  • 系统基座与快速应用逐步分层。
  • 应用发布者承担更多直接更新责任。
  • 系统更新向原子化、可回滚和声明式靠拢。
  • 评价软件分发不能只看文件格式，还要看维护责任与治理方式。

不能混为一谈的差异

共同趋势不意味着这些方案可以互相替代：

  • 应用沙箱不等于系统不可变。Snap 与 Flatpak 解决应用层解耦，bootc 与磐石解决系统层不可变，两层可以独立选择。
  • Flatpak 的成功不能直接证明 Snap Store 的中心化合理。应用格式的可行性与其治理结构是两回事。
  • bootc 镜像与 Ubuntu Core 的组件模型是两种实现。前者是 OCI 容器镜像，后者是全 Snap 组件化，更新与交付机制不同。
  • 技术方向相似不代表目标用户、治理和商业模式相同。

2.6 小结

技术架构只能说明这些方案如何工作。评价它们对用户的影响，还要看谁负责更新、审核和支持，谁掌握控制权，以及这些安排实际为用户节省了多少时间。

3 用户与产品：技术选择最终替谁节省时间？

3.1 Ubuntu 为什么强调开箱即用

Ubuntu 同时服务服务器与桌面

Ubuntu 的定位是用同一套 base 同时覆盖服务器与桌面。服务器端，LTS 的长期支持与 Ubuntu Pro 的延长维护是基本盘；桌面端，用户需要驱动、编解码器、应用商店、升级与恢复的完整体验。Canonical 没有资源维护一个独立的滚动桌面分支，因此把桌面做成 LTS base 之上的默认体验，是它的现实选择。

产品整合的具体内容

对刚从 Windows 或 macOS 转来的用户，开箱即用的标准不是先理解 deb、Snap 或 User Namespace，而是能开机上网、安装应用、使用显卡、完成更新，遇到问题时也有明确的排错入口。用户不应该为了安装浏览器先研究包格式，也不应该在安装 Nvidia 驱动前先查显卡分支和 Secure Boot 的 MOK 配置。

Ubuntu 把开箱即用落实到四组默认能力：

下面关于桌面默认值和操作细节的描述，来自作者在 Ubuntu 24.04/26.04 上的实际使用；官方功能和文档另附对应来源。

  1. 安装：图形安装器完成硬件检测、分区与 Secure Boot 配置，安装时可勾选第三方驱动与闭源编解码器。Secure Boot 上微软信任 Canonical 的签名，从 UEFI 到桌面无需手动注册 MOK 密钥[60]。

  2. 软件：仓库、商店、驱动与编解码器入口齐全。Nvidia 驱动以预编译模块提供，ubuntu-drivers install 一条命令装齐，无需配 DKMS，图灵架构以前的显卡仍能从仓库装 580 版驱动[61]。

    Snap Store 提供 Steam、PyCharm、Telegram 等 GUI 软件，用户可以直接从商店安装[62]。开发工具方面，JetBrains 全系与 VSCode 有厂商官方维护的 classic Snap，直接访问宿主工具链，体验接近原生；Flatpak 的沙箱隔离与开发工具对宿主文件系统的深度访问相冲突，这也是 Bluefin DX 明确不建议 JetBrains Flatpak 的原因（见 1.3 节）[26:2]。NVIDIA 的开源软件 OpenShell 也由 NVIDIA 认证发布者直接发布 Snap[63]。

    仓库侧，26.04 起 CUDA Toolkit 进入官方仓库[64]，闭源编解码器经 ubuntu-restricted-addons 安装，元包（如 kubuntu-desktop）补齐桌面与常见依赖。默认安装推荐依赖的行为也比 Debian 更克制，例如安装 sddm 不会顺带拉入整个 KDE，安装 nvidia-cuda-dev 不会拉入整个 NVIDIA 内核驱动。

  3. 使用：Ubuntu 预置了一些低层但高频的默认设置。Ubuntu 的 GNOME 自带了打开终端的快捷键。通过 Language Support（语言支持）图形界面可以下载语言包，系统会自动下载对应字体；界面还可以选择 fcitx5 或 ibus，并自动配置所需的环境变量。Ubuntu 的 GNOME 会话因此省去了不少输入法和语言、字体的手动配置。这里说的是 Ubuntu 的集成体验，不代表其他 GNOME 发行版也有相同默认值。

    更细的默认值还有不少。.bashrc 预置 readline、补全与 alias，Nautilus 支持右键打开终端。Copyous 扩展会把剪贴板中的代码显示为 DejaVu 等宽字体，避免用户另行配置；作为对照，Arch 默认的 monospace 使用 Noto Mono。XWayland 实验性缩放入口加入了设置。Shift+Delete 的删除确认逻辑默认是取消而不是确认。Gradia 截图标注工具也可以直接从应用商店安装。这些细节单独看不起眼，但能减少用户反复查资料的次数。

    Canonical 通过 Ubuntu Certified 在数百款设备上做兼容性测试，并用 HWE 栈为 LTS 持续回溯新内核与图形驱动[65]。相比 Debian Wiki，我也更喜欢 Ubuntu 官方文档的呈现方式。

  4. 恢复：LTS 升级路径、Grub 菜单预装 memtest86+ 做内存诊断；Ubuntu Pro 为个人用户免费提供最多 5 台设备的延长安全更新[66]。

默认值与选择自由

默认配置的价值是减少新用户的决策负担，而非剥夺选择。有经验的用户仍可以替换桌面、包格式与应用来源。需要区分两件事：替用户做合理的默认决定（比如默认装好驱动与编解码器），与不给用户知情选择（比如 1.4 节讨论的 apt install firefox 静默重定向）。前者是产品化，后者是透明度问题。

这些默认值能降低常见门槛，却不能消除硬件、桌面环境和应用生态中的所有问题。LTT 的 Linux 挑战说明，用户遇到问题时仍可能无法判断责任属于桌面、驱动、应用还是发行版，下一节从这些具体案例开始。

3.2 LTT：普通用户不想把修系统当爱好

案例经过

Linus Tech Tips 的 2026 Linux 挑战视频是一个观察窗口：Linus 只是想剪视频、打游戏、看网页，过程中却遇到一连串问题[67]。五个具体案例：

  • Pop!_OS 的 Cosmic 桌面：下载页标注 LTS，但 Cosmic 桌面实际处于公开 beta 阶段。新手不会想到要先确认"这个桌面环境是否 beta"，装完遇到各种不稳定。
  • Bazzite 上的 DaVinci Resolve：Bazzite 是不可变系统（基于 Fedora Atomic，与 Universal Blue 同族），核心系统只读。Linus 像装 Windows 软件一样下载 Resolve 直接运行，失败；最终靠一个 6 分钟的视频教程才找到正确的安装命令。装上后又遇到 H.264/H.265 编解码器缺失，部分文件无法播放或导出。
  • Kubuntu 安装后黑屏：装完第一天黑屏几小时，第二天才莫名恢复（特定硬件问题）。
  • NTFS 游戏盘配合 Proton：把 Windows 的 NTFS 游戏盘直接挂到 Steam 库，部分游戏 glitch 或打不开；Linux 7.1 合入了新的 NTFS 驱动，但 Proton 对 NTFS 的兼容性仍不足[68]。
  • OBS 屏幕捕获：deb 版 OBS 无法选择要录制的显示器，换 Flatpak 版后 KWin 的隐私设置又阻止了屏幕捕获，论坛里有五种不同解法，新手无法判断哪个有效。这个案例不能直接概括为所有 Linux 桌面都会如此，具体表现可能取决于桌面环境、显示协议和权限配置；作者在 Ubuntu 26.04 LTS 上未复现这一问题。

这五个问题分属不同层次：Cosmic 是桌面环境成熟度问题，Resolve 是不可变系统的安装方式问题，黑屏是硬件兼容问题，NTFS 是文件系统兼容问题，OBS 是权限与桌面集成问题。普通用户面对的是同一种困惑，即不知道该把问题归给谁。

搜索与责任边界

Linus 还提到 Linux 的搜索逻辑有时"为了和 Windows 不同而不同"：在搜索框输入 sleep 想调整睡眠设置、习惯性按回车，系统却直接休眠了。Luke 则分不清故障来自哪一层：在 Windows 上游戏崩溃，他知道是游戏的问题；在 Linux 的 Proton 兼容层上遇到报错，他分不清"是因为我在用 Linux，还是游戏本身有 Bug"[67:1]。

这些案例暴露出一个共同问题：普通用户无法判断问题属于 Proton、Steam、驱动、桌面还是发行版。Linux 生态的高度可替换性（组件可换、发行版众多、同一软件有 deb、Snap、Flatpak 多种来源）在给有经验用户自由的同时，增加了普通用户的故障路径与搜索噪声。技术上"有解决办法"（论坛里有五种 OBS 解法）不等于产品上"问题已解决"（新手无法判断该用哪个）。

案例的边界

LTT 挑战并非严格实验，也不代表所有 Linux 用户；部分问题与特定硬件组合有关（如黑屏），部分源自视频作者的操作习惯。它展示了用户愿意投入的时间与实际排错负担之间的差距：Linus 的原话是"普通人不想把修操作系统当爱好"[67:2]。喜欢排错的人可能把这些问题视为挑战；只想完成日常任务的人，则可能因此放弃使用，并向他人表达负面评价。

3.3 Linux 免费，但用户时间并不免费

开箱即用与折腾不矛盾

"Linux is only free if your time has no value"这句话在技术社区流传已久，出自 Jamie Zawinski[69]。开源软件不收钱，但配置、维护、排错需要投入时间。对喜欢折腾的人，这种投入是乐趣；对只想用电脑干活的人，这种投入是门槛。第 3 部分的价值判断由此而来：衡量产品化是否成功，看它替用户减少了多少非自愿维护工作。

开箱即用与折腾并不冲突。折腾应当是可选的能力，而非必须的入门成本。一个健康的循环是：新人被低门槛吸引进来，系统开箱能用，在社区里慢慢了解 Linux 的工作方式，有兴趣再深入，最终成为能帮别人的老手。

Display Manager 可以说明这种区别。社区里有声音认为，tty 登录然后 exec sway 就够了，DM 臃肿多余。但 DM 在 Wayland 时代的角色远不止一个登录画面：它通过 PAM 完成 session 注册、初始化 D-Bus session bus、注入 XDG_SESSION_TYPE 等关键环境变量、自动解锁 Keyring，这些是桌面组件正常协作的前提。KDE 用户可以从 tty 直接 startplasma-wayland，但不代表图形化登录体验是多余的，让 Windows 用户感到熟悉的登录界面是桌面操作系统不该省掉的基本功能。自由的价值在于拥有选择，而不是要求所有人先付出学习成本。

软件分发如何改变时间成本

软件分发的不同选择，直接改变用户的时间成本：

  • 自动更新减少了手动维护，但可能削弱用户对更新时间点的控制；
  • 沙箱减少了依赖冲突，但引入了权限申请与宿主集成的额外步骤；
  • 统一商店降低了发现成本，但把治理权力集中到商店运营方。

第三点有直接的对照。Elijah 在 LTT 总结视频里的感叹是：Bazzite 内置的软件商店体验超过 Windows，没有 Edge 弹窗、没有 OneDrive 订阅推销、不需要每个新应用都重新验证一次 2FA[70]。对许多普通用户来说，能否顺利安装和自动更新软件，比底层是否采用沙箱更直接。发行版把这条默认路径做好，也就减少了用户转向其他系统的理由。

维护责任是否清晰

评价软件分发方式时，需要考察用户是否清楚软件由谁发布、从哪里更新、如何回退，应用、发行版和商店之间是否有明确的故障支持边界，以及默认路径能否在自动工作的同时允许用户接管控制。

这是评价 Snap、Flatpak、原生包和不可变系统的统一标准：减少多少非自愿维护时间，而非只比较功能数量。前面各节的判断都可以回到这个尺度上复核。

3.4 Windows + WSL 的务实位置

适合的用户

对依赖 Windows 专有软件、又需要 Linux 命令行与开发环境的人，Windows + WSL 通常比双系统更省事。WSL 2 提供完整的 Linux 内核、systemd 支持、GPU 直通与 GUI 应用（WSLg）[71]。VS Code 可以直接打开 WSL 环境，Docker 能在 WSL 内运行，CUDA 经 GPU-PV 可用，Linux 编译工具链也可以通过 apt install build-essential 安装[71:1]。

Windows 侧仍保留完整的消费级体验：Office、Adobe 全家桶、企业办公软件、游戏，这些是 Linux 桌面难以完整覆盖的部分。相比双系统，WSL 免去了分区、桌面环境配置（驱动、输入法、字体渲染）和反复重启切换的负担[71:2]。文件互操作也方便：WSL 终端里 explorer.exe . 在资源管理器打开当前 Linux 目录，WSL 自动挂载 Windows 盘符（/mnt/c），不想自动挂载可在 /etc/wsl.conf 关闭[71:3]。

不能替代原生 Linux 的场景

WSL 不替代原生 Linux。Linux 桌面开发、底层系统调试、特定硬件与内核功能、需要完整图形栈或原生部署一致性的工作，仍要原生环境。WSL 2 对编译、容器、小模型训练这类任务的性能损失可忽略，但极低延迟的裸金属操作（高频交易、实时音视频）仍需原生机[71:4]。这类用户清楚自己的需求，不在此讨论范围内。

评论区提供了另一组用户选择的样本[72]：有人说"现在越来越没有精力尝试那些发行版了，终极还是选择了 wsl+windows"，有人说"linux 最大众的用法：macos/win 系统 + ssh 远程连接"。这些用户把 Linux 用作后端或开发环境，但不把它作为日常桌面。

与全文的关系

WSL 说明很多用户真正需要的是 Linux 能力，而非必须把 Linux 当作桌面身份。工具选择应服从任务，不服从阵营。WSL 默认安装的发行版就是 Ubuntu，这本身也是 Canonical 务实策略的一部分。WSL 出问题重启即可，最坏 wsl --unregister 重装一个发行版只要几分钟，宿主系统不受影响。这恰好是"开箱即用"与"折腾"之间的一条中间路径。

3.5 Arch、Ubuntu 与 Mint：选择的是责任模型

Arch

Arch 是滚动发布，软件新、配置显式、文档（Arch Wiki）完整。它的 KISS 原则是对懂系统的人简单，并非对所有人简单。选择 Arch，意味着用户承担了更多维护责任：

  • 滚动更新需要关注 Arch News，上游包改配置格式、换依赖、需要手动干预时，没看到公告直接全量更新可能出问题；Ubuntu 在一个 release 周期内基本只推安全补丁[73]。
  • 不支持部分升级：新库推送到仓库后，只升级一个包可能连带升级依赖库，破坏其他依赖旧库的包；因此不能 pacman -Sy，装新包前必须先 pacman -Syu 全系统更新[73:1]。
  • 更新需手动处理 pacnew 配置文件[73:2]。
  • AUR 是用户提交的仓库，没有统一质量审查，需要自己审阅 PKGBUILD。2026 年 6 月 12 日，攻击者曾接管无人维护的孤儿包并植入恶意代码[74][75]。

这些维护要求体现了 Arch 的设计取向：用户理解自己的系统、自己做决定，也承担相应的维护责任。EndeavourOS、CachyOS 用 GUI 安装器降低了安装门槛，但没有改变这套分工，用户仍然要关注新闻、管理 AUR、对自己的系统负责。

这份责任还包括引导和安全启动配置。使用 GRUB 时，安装或移除内核后需要用户重新生成 grub.cfg；Secure Boot 的密钥也要按所选方案创建、签名和注册[76]。

更一般地说，以 root 权限执行的一次性命令如果没有记录，机器的实际状态会逐渐难以复现，之后也很难追溯某项设置从何而来。这正是声明式系统试图减少的配置漂移：把系统状态写进配置并纳入版本管理（见 5.4 节）。

Ubuntu

Ubuntu 由发行版统一承担更多默认集成和维护工作：预装驱动、编解码、商店与桌面，一个 release 周期内主要推安全补丁。跨版本升级由 do-release-upgrade 管理，它会处理第三方软件包和软件源，降低升级期间的冲突风险[77]。代价是软件版本可能落后，部分应用通过 Snap、Flatpak 等独立渠道更新。适合希望系统长期可预测、不想跟进每个上游变动的用户。

Mint

Mint 在 Ubuntu 基础上提供更传统的桌面默认值：当前 Mint 22.x 以 Cinnamon 版为主，操作逻辑更接近 Windows[78]。它对 Snap 做了不同的产品选择，通过 /etc/apt/preferences.d/nosnap.pref 默认屏蔽 snapd[79]。Mint 团队在公告里把 Ubuntu 20.04 的 Chromium 过渡包描述为"acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store"[79:1]。这一选择也带来代价：Mint 用户想用只有 Snap 的软件时，需要先手动解除屏蔽。

反过来，Ubuntu 用户如果不想使用 Firefox Snap，也可以按 Mozilla 的官方文档切换到其 APT 仓库提供的 DEB 包，或安装 Flatpak 版[80]。Mint 用户需要手动启用 Snap，Ubuntu 用户则需要手动换掉 Snap 默认值；两边都允许用户改变发行版的默认选择。

Mint 的优势主要来自桌面体验偏好，基础系统仍是 Ubuntu LTS：它只基于 Ubuntu LTS 发布，且通常在 LTS 点版本之后数月才推出[78:1]。以最近的周期为例，Ubuntu 26.04 于 2026 年 4 月发布，Mint 官方计划在 2026 年圣诞节发布以它为软件包基础的下一版本；在此之前，Mint 仍基于 Ubuntu 24.04。在不使用 Snap、Flatpak、Homebrew 这类独立渠道时，多数基础软件的大版本会在接近三年的时间里保持在 Ubuntu 24.04 基线上。Ubuntu 仍会提供安全修复，HWE 栈也会回溯更新内核与图形驱动，但多数软件包不会在同一基础版本中追随上游大版本[78:2][9:1]。

当前 Mint 22.x 默认使用 Xorg，Ubuntu 26.04 的 GNOME 会话默认使用 Wayland。Wayland 提供更好的分数缩放、HDR 和多屏支持；Xorg 对部分闭源办公软件和屏幕共享工作流仍更省事。新硬件更适合优先考虑 Ubuntu 最新 release，需要传统桌面逻辑或 Xorg 兼容性的用户则更适合 Mint。

选择问题

与其问"哪个发行版最强"，不如先问：谁负责更新，谁负责排错，自己愿意承担多少系统维护工作？想深入理解系统、愿意自行维护的人可以选 Arch，希望系统长期可预测的人可以选 Ubuntu，偏好传统桌面的人可以选 Mint。

3.6 SteamOS 的产品条件与边界

SteamOS 的成功条件

Steam Deck 把 Linux 桌面封装成接近消费电子产品的使用体验：系统不可变并支持原子更新，用户主要通过 Steam 和 Discover（Flatpak）安装软件，游戏模式可以直接使用，不需要了解底层的 Arch Linux[81]。

Steam Deck 把硬件范围、游戏场景和默认工作流固定下来，Valve 因此可以替用户承担驱动、Proton 兼容性和系统维护。不可变系统、回滚和自动更新减少了系统维护，Steam 和 Discover 也把软件来源收进了有限的入口。这个体验依赖的不只是技术，还依赖 Valve 持续投入资金和人力维护整个系统栈。

SteamOS 的适用范围

SteamOS 的硬件范围由 Valve 控制，任务范围主要是游戏，远小于普通 PC。Steam Deck 用户通常不需要在上面写代码、接打印机、使用网银 U 盾或参加腾讯会议。通用桌面既要兼容更多硬件、软件和工作流，又要让不了解底层细节的用户自由安装软件，发行版至今仍很难同时满足这些要求。

SteamOS 说明 Linux 可以在边界明确的产品中提供接近家电的体验，但这个结果不能直接推广到通用桌面。

3.7 小结

对普通用户，技术方案的价值取决于安装、更新和排错需要投入多少时间，责任边界是否清楚，以及用户需要时能否接管控制。发行版没有解决的问题，往往需要用户到社区求助，并增加整个生态的支持成本。

4 社区与生态：技术成立为何仍难以大众化？

4.1 批评、解释与选择

批评要对准事实

对 Snap 有说服力的批评，应当针对具体机制：apt 静默重定向、商店闭源与中心化、国内网络可达性、桌面集成，这些是 1.4 节展开的问题。相比之下，"整个 Ubuntu 都变成 Snap"这类标签是失真的：默认重定向到 Snap 的只有 Firefox、Chromium、Thunderbird 三类，其余软件仍是 deb，服务器、边缘设备、IoT 的 Ubuntu 实例不受这一决策影响[2:2]。把批评对准具体机制，问题可以定位、可以修复；把批评放大成"Canonical 要消灭 deb"这种不实标签，只会挤占有建设性批评的讨论空间。

批评还需要把不同性质的问题分开：技术问题（沙箱、桌面集成）、产品问题（透明度、默认选择）、治理问题（商店闭源）、地区网络问题（国内可达性）。混在一起讨论，无法判断哪个该由谁负责、哪个能修、哪个是取舍。

区分工程原因与产品评价

解释一项决策的原因，常被误读为替它辩护。一个典型例子是 GNOME 的托盘：社区里有声音说"GNOME 连托盘都要装扩展才有"。事实是 GNOME 3.26（2017 年）默认不再显示基于 XEmbed 的旧式 status icon，这类图标在 Wayland 下不能原生工作、在 HiDPI 下表现不佳，官方有 Status Icon Migration 计划说明迁移路径；GNOME 47 把搁置已久的官方 Status Icons 扩展收进扩展包，但专注于兼容旧式图标，维护者明确没有支持 AppIndicator 的计划；GNOME 44（2023 年）引入的"后台应用"入口，是面向通过 Portal 声明后台活动应用的轻量面板，而非传统意义上的完整托盘[82]。

陈述这些事实，不等于说"GNOME 移除托盘是对的"。说清"他们为什么这么做"和判断"他们这么做是对的"是两件事。了解原因本身对用户有价值：知道移除的是 legacy status icon，才知道该装 AppIndicator 兼容扩展，而非满世界找"托盘开关"。工程约束可以解释决策，但用户仍要承担这些设计带来的不便。对依赖 OBS、Steam 或常驻后台通讯软件托盘功能的人，托盘就是刚需，用得不舒服该批评就批评。

这个模式在各社区反复上演：解释 GNOME 为什么不支持 wlr-layer-shell，被当作洗地；解释 Ubuntu 为什么推 Snap，被当作洗地。先站队，讨论就只剩立场对立。

不喜欢就换

Linux 允许用户更换发行版，这也是反馈项目决策的一种方式。但更换方案不需要把其他用户描述成无知或被绑架：你遇到的问题可能来自特定硬件组合或配置冲突，换一个发行版也可能遇到。脱离具体使用场景，单独断言一个工具好不好用，往往得不出有意义的结论。

Canonical 也犯过错：Mir 显示服务器在 Wayland 成为共识后退场，Upstart 在 systemd 胜出后放弃，Unity 桌面最终让位于 GNOME[83]。这些尝试造成过分裂，社区的不信任由此积累。Canonical 后来终止或调整了这些项目：Mir 的技术积累转向 Wayland 合成器底层，Unity 的部分设计延续在 Ubuntu 的 GNOME 定制里。批评应该对准今天的具体做法，而不是对着公司名字做条件反射；技术选择也不该成为社交身份的优越感，这个问题在 4.2 节展开。

4.2 守门人文化与身份标签

新用户面对的隐性门槛

新用户面对的不只是技术门槛，还有一种隐性的守门人文化。当新人提问时，收到的回应可能是"先读文档""自己编译""换发行版"。这些回应在特定场景下合理：问的问题确实在文档里写清楚了，或确实需要用户自己动手。但在另一些场景中，这类回应只是把发行版或软件原本可以减少的使用困难，解释成用户必须承担的"学习义务"。

经验用户掌握的知识不能直接当作普通用户的前置条件。一个用过多年 Linux 的人觉得"改一下 .bashrc 就行"是常识，但对一个刚装上系统的用户，这条路径本身就是门槛。守门人式的回应要求普通用户先掌握经验用户的知识，再自行处理原本可以由产品设计降低的使用成本。

技术身份如何放大争议

Snap、systemd、GNOME、Wayland 这些技术名词容易被当作阵营标签。一旦贴上标签，讨论就从"这个权衡是否合理"变成"你站在哪一边"，具体的技术取舍也被简化成忠诚或背叛。

社区原声能说明这种气氛。Arch 争议视频的评论区里，一条高赞评论写道："当一个社区的规模扩展到一定程度，原本作为工具的技术往往就会开始异化为一种身份图腾……掌握更多技术知识的人通常也就掌握了更大的话语权……将傲慢和缺乏同理心包装成'极客'的严谨性。"[72:1]

另一条评论点出了"传教"和"引导"的区别："你炫耀没问题，但你炫耀了，又不教，简直无耻……社区的精神应该是'带'而不是'拉'。拉入 Arch 有什么了不起，了不起的是你能带他走完你走过的坑！"[72:2]

LTT 总结视频里 Elijah 的遭遇更直接：他抱怨新游戏 Marathon 因内核级反作弊无法在 Linux 运行，收到的却是"你本来就不该玩这个游戏"的指责，甚至私信攻击他"故意抹黑 Linux"；最终他放弃论坛求助，转而全程用 LLM 解决问题[70:1]。以"保卫 Linux"为名攻击用户，会让求助者离开社区支持渠道。

不过，这些原声只能展示态度样本，不能证明整个社区都如此。评论区里也有人建议"Arch 确实不适合新手，新手推荐 Mint/Ubuntu"，还有人认为"Arch 嘲笑 Windows、NixOS 嘲笑 Ubuntu，这种现象在任何发行版都存在"[72:3]。这些评论同样不能证明某种行为有多普遍，但具体的守门行为仍然需要批评和纠正。承认行为存在，不等于用它定义整个社区。

这些案例中的用户会放弃求助、缩小自己的使用范围，甚至离开 Linux。社区支持越难获得，留下来的用户就越集中在少数熟悉规则的人群中，项目收到的反馈也越窄。社区支持方式会影响用户留存和项目反馈，下一节继续分析这种关系。

4.3 用户规模与软件支持的循环

循环结构

经过社区和商业力量长期投入，Linux 桌面体验已经比早期成熟许多，也积累了约 3% 至 4% 的桌面份额。要继续扩大用户规模，还需要硬件认证、统一测试、商业软件支持和面向用户的服务。

Linux 桌面的用户规模与软件支持之间存在一个会自我强化的循环。Linux 桌面份额长期在 3% 上下（Statcounter 含 Unknown 口径），远低于 Windows 的六成以上[84]：

每一步都在加固下一步：用户少，硬件厂商不做 Linux 驱动、软件厂商不做 Linux 客户端；支持不足，用户遇到硬件不兼容、软件缺失或体验差；体验差，用户回到 Windows；用户离开，份额更难扩大，厂商更没有投入动力。具体缺口包括游戏鼠标配置软件、某些打印机驱动，以及 Adobe、Microsoft Office、Autodesk 和部分国内企业办公、税务软件。Wine、Proton 或 Web 替代方案能覆盖其中一部分，但无法保证工作流稳定一致。

继续扩大用户规模需要硬件认证、产品设计、应用适配、统一测试、文档和面向用户的支持，新的包管理器或桌面组件只能解决其中一部分问题。这些工作分属不同团队和组织，无法由单个志愿者项目自动补齐。

不过，商业软件仍有缺口，并不意味着开源社区没有成果。Blender、Krita、Kdenlive 和 OBS 已经覆盖了 3D 创作、数字绘画和视频制作等部分工作流；Adobe、Autodesk、国内企业办公和税务软件等领域则仍缺少稳定的一致替代品。前者说明 Linux 已经能够支撑一部分专业创作，后者解释了为什么某些用户仍然无法迁移。

为什么服务器成功不能自动转化为桌面成功

Linux 广泛用于服务器和云环境，但这些场景的条件不能直接复制到桌面。服务器目标明确、环境受控、维护者是专业管理员，企业也愿意为支持付费；桌面的硬件、应用、外设和用户能力高度分散，用户通常预期低价甚至免费。服务器上的不可变系统由 CI/CD、镜像仓库和受薪 SRE 团队管理，桌面用户通常没有对应的运维支持。deepin 因此为磐石系统保留了关闭系统保护的选项[55:3]，让用户在系统保护与手动修改之间作出选择。

服务器通常通过命令行和远程管理工具维护，面对的硬件与工作负载也更容易标准化；桌面则要处理显示服务器、主题、Portal、托盘、屏幕共享、输入法和消费级硬件长尾。不可变系统给运维者带来声明式部署和回滚等直接收益，普通用户更容易先注意到"不能直接修改系统"的限制，减少故障的收益反而不那么直观。

社区氛围如何影响生态

社区氛围不会单独决定生态规模，却会影响用户是否愿意留下。对新人不友好的支持方式会让用户离开；只强调"选择"却不给出推荐路径，也会让新用户无从下手。面对六种包格式和几十种发行版，不想研究这些差别的人很难形成稳定的工作流。缺少明确的推荐和支持路径，会进一步增加这种负担。

4.4 小结

产品没有说明由谁负责支持时，用户往往只能到社区求助，并自行判断问题出在哪。守门行为、搜索噪声和过多选择会让求助更费时间，也更容易让用户离开。要改善这种处境，发行版、桌面项目和应用维护者需要明确各自负责什么，并让整合、支持和社区治理工作能够持续下去。

5 组织可持续性：谁来承担长期成本？

5.1 志愿者模式的结构性边界

前面的用户和生态问题最终都需要有人处理：谁来长期负责打包、审核、更新、支持、产品整合和社区治理？

关键人物依赖

社区项目往往依赖少数核心维护者。Ubuntu Unity 的项目负责人 Rudra B. Rudra 因大学考试无法投入时间，项目一度面临生存危机[85]；Ubuntu MATE 创始人 Martin Wimpress 在 2026 年 3 月宣布因失去热情而希望移交项目[86]；Linux XFS 文件系统的维护者 Darrick Wong 公开表示"精疲力竭"，并警示自己不想在 2030 年还处于这种状态[87]。这些案例说明，项目依赖少数人的热情和业余时间时，人员变动会直接影响维护工作的连续性。这里要讨论的是项目对少数人的依赖，并非维护者个人是否尽责。

只有工程能力还不够

桌面操作系统除了代码，还需要设计、测试、文档、发布、支持和项目管理。deepin 的王勇曾指出："桌面要集合设计、用户心理研究、产品细节……而 Linux 社区只有技术架构。"[88] 他说的不只是写代码，还包括 UI/UX、无障碍、图形设计和用户沟通等长期工作。功能能够实现，只说明技术路径可行；普通用户能否稳定使用，还取决于这些工作的持续投入。

聘用设计人员之后，项目还需要明确他们能作出哪些决定。OSCHINA 的一篇评论转述了前 Ubuntu 设计师 David Siegel 的回忆：设计团队既受到创始人 Mark Shuttleworth 个人设计要求的限制，也需要面对长期软件包维护者在设计决策中的话语权[89]。这份回忆提出了投入之外的授权问题：承担设计工作的人，是否有与职责相应的决策空间？它不能证明集体决策必然损害设计，也不能证明个人主导就能做好产品。工程贡献值得尊重，但维护资历不能代替对具体设计方案的判断；设计、工程与产品负责人之间仍需明确各自的权限，以及发生分歧时如何作出决定。

碎片化的双重效果

Linux 桌面的多样性给用户和开发者提供了选择，也增加了适配成本。目前存在超过 23 种风格类似的桌面环境[90]，开发者倾向于创建新项目而非合力改进现有项目。应用开发者还要为不同的发行版、包格式和显示服务器逐一适配。在讨论"大众化"这个具体目标时，这些分支会分散测试、文档、应用适配和支持资源。

维护工作也不只是写新代码。上游与下游之间的责任协调、重复问题的筛选、回归测试、Bug triage 和文档维护，往往同样消耗大量时间，却不如新功能显眼。志愿者模式的问题不仅是"有没有人写代码"，还包括这些长期、低可见度的工作是否有人持续承担。

资金困境与稳定投入

资金困境也存在于顶级项目。KDE 在 2022 年和 2023 年分别亏损约 9.9 万欧元和 10.7 万欧元[91]，GNOME 同样面临连续赤字。对比之下，Linux 内核超过 80% 的代码由受薪开发者贡献，纯粹无偿志愿者的贡献占比约一成[92]。复杂软件工程需要稳定、持续的投入。KDE 的 2024 年度目标写得很克制：在不大幅扩张的情况下保持现有的活动水平[93]。这反映了社区当时可投入资源的上限，不能据此判断社区的工程能力。

用户增长不等于贡献者增长

资金充足也不等于有人愿意长期承担维护工作。openSUSE 社区的数据表明，贡献者数量最多的时候反而是用户最少的时候，用户增长期反而伴随着贡献者数量的停滞或下降[94]。大多数用户只是想来用电脑，没有贡献的义务；把用户转化成贡献者需要社区建设、mentorship 和良好的新人体验，而这些本身也需要资源投入。付费开发、企业赞助和志愿贡献之间，需要清晰的权责关系。

如何评价项目与维护者

用户当然可以批评项目，也没有贡献代码的义务。不过，从"我用着不顺手"直接推到"这个项目是失败品"，会跳过具体问题，也会忽略项目的目标和规模。拿 niri 和 COSMIC 对比就是一个例子：前者是合成器，后者是完整桌面环境，两者要覆盖的功能面、要处理的兼容性、要维护的代码量都不在一个量级，用合成器的进度去衡量桌面环境的完成度并不公允。

志愿者可以启动项目，也能长期维护项目，但很难独自负责打包、测试、文档、支持和产品整合。没有人持续负责这些工作时，用户会在更新、排错和安装软件时付出更多时间。接下来讨论这些负担在桌面端的具体表现，以及谁有能力长期承担。

5.2 服务器导向带来的三种桌面摩擦

Linux 桌面继承了许多为服务器和开发环境形成的工具与工作方式。同一套机制用于普通桌面时，会在三种场景下增加用户负担。这些问题来自使用场景不同，不能简单归结为技术设计错误。

第 4.3 节已经说明，服务器上的不可变系统依赖受薪运维团队、标准化硬件和受控环境，不能直接复制到桌面。这里继续讨论这些限制怎样影响桌面端的更新、排错和软件分发。

更新后的维护责任

在 Windows、macOS、Android 上，系统更新通常在后台下载、重启时自动应用，用户不需要知道这次更新改了什么，普通人不读 changelog 也不想读。多数 Linux 桌面很难提供完全相同的统一更新体验，因为内核、驱动、显示服务器、桌面环境、音频系统、包管理器和沙箱运行时来自不同上游，每个组件的更新节奏也由不同团队决定。不可变发行版已经能完成原子更新和回滚，但整个桌面栈的集成测试与后续支持仍由多个项目分担。

自动更新和自动回滚可以减少更新失败造成的影响，但更新后如果某个硬件不工作或软件行为改变，用户仍要判断问题出在哪、去哪个上游报 bug。原子更新解决了更新切换和故障回退的问题，不会自动解决后续排错与支持。

排错时的责任归属

Luke 无法判断故障来源的经历（见 3.2 节）还涉及支持责任。Windows 用户遇到问题时，硬件可以找 OEM 售后，软件可以找厂商；Linux 桌面问题可能来自内核、驱动、显示服务器、桌面环境、包管理器或沙箱运行时。没有明确的支持入口时，用户需要先判断该向哪个项目求助，而相关日志和文档也未必面向普通用户。

Windows 同样有 bug，但用户通常更容易找到已有解决方案，或向 OEM 和软件厂商寻求支持。Ubuntu Pro 的付费支持、Red Hat 的企业级服务也在提供这类兜底，不过它们主要面向企业，而非普通桌面消费者[66:1]。

软件分发选择

Windows、macOS 上常见的安装路径是下载安装包并运行，用户通常不必先了解包格式和依赖关系。Linux 用户在发行版默认渠道之外寻找软件时，还可能需要选择分发格式：deb 版本可能较旧；Snap 提供沙箱机制，但国内网络可达性可能影响使用；Flatpak 适合 GUI，却未必适合某些工具；AppImage 可以免安装运行，但更新方式要看应用；AUR 提供了许多额外软件包，用户需要自行审阅 PKGBUILD；直接编译便于自行配置，也需要承担构建和维护工作。

选择的丰富提高了覆盖率，也增加了发现、信任和支持的成本。普通人不该需要理解六种包格式的区别才能装一个软件。Valve 在 SteamOS 中限制软件入口，以此降低用户的选择成本（见 3.6 节）；通用桌面需要支持更广的用途，很难照搬这种做法。

这三种情况说明，自动更新、回滚和统一分发可以减少一部分用户负担；要继续降低排错成本，还需要明确由谁负责整合和支持。接下来需要回答：谁有资源长期承担这些工作，谁愿意为产品决策负责。

5.3 商业力量能解决什么，不能解决什么

志愿者项目很难长期覆盖全部工作，桌面用户又会直接承担更新和排错成本。要扩大桌面用户规模，项目需要稳定的资金、明确的产品责任和长期基础设施。Canonical、Red Hat 和 Valve 都投入了这些资源，但解决的范围不同。

Canonical

Canonical 同时维护 LTS、云服务、硬件认证、桌面集成和 Snap 基础设施，把安装、驱动、编解码器、应用商店和升级路径整合到同一个产品中（见 3.1 节）。这让 Ubuntu 能为普通用户承担一部分系统维护工作，也把商店控制权和产品策略集中到 Canonical 手中，因此产生了 1.4 节讨论的透明度和治理争议。

Red Hat

Red Hat 用企业生命周期、桌面 runtime 和底层图形技术支撑另一种分工：经过六年过渡，RHEL 把 Firefox、Thunderbird 等桌面应用逐步交给 Flatpak，同时把工程资源集中到 Wayland、HDR 等平台工作（见 2.1 节）。它的支持范围和迁移节奏由企业客户决定，RHEL 桌面服务的是企业产品战略，并不等同于面向所有消费者的通用桌面方案。

Valve

Valve 把硬件、Steam 和 Proton 放在同一个产品里，自己承担游戏兼容性、驱动协作和系统维护成本（见 3.6 节）。Steam Deck 因此可以提供接近家电的体验，但它依赖固定硬件和明确的游戏场景。通用桌面需要兼容更多硬件、软件和工作流，不能直接复制 SteamOS 的限制条件。

商业与社区的合理关系

本文考察的案例中，商业公司承担资金、产品责任和长期基础设施，社区则提供开放协作、监督、移植和替代能力。两者协作需要清楚的责任边界：用户知道谁负责支持，贡献者知道谁能作决定，社区也保留 fork 和替代的可能。

5.4 Nix 的技术能力与治理问题

技术路线与治理问题

Nix/NixOS 把不可变、声明式和可复现的系统做得很彻底。一份 configuration.nix 可以声明整个系统状态，构建结果可复现，generation 之间可以原子切换和回滚。Snap 与 Flatpak 主要解耦应用，Nix 则把同一套思路扩展到了整个操作系统。

Nix 已经实现了这套技术，但权责分配、维护和决策仍是另一类问题。接下来的治理经历把两者的区别表现得很清楚。

flakes 的事实标准僵局

flakes 于 2021 年随 Nix 2.4 引入，至今仍是 experimental 特性，也没有稳定时间表。nix.dev 官方文档承认它存在架构问题和实现缺陷[95]。这个僵局有三个原因：

  • RFC 49 在没有被接受的情况下就由原作者主导合入主干，只是藏在 experimental 开关后面，后续争议一直没有消失[96]；
  • RFC 136 设定的渐进稳定路线进展缓慢，缺少明确的完成时间；flakes 的纯评估限制、输出属性缺少类型检查等问题也没有解决[97]；
  • flakes 的采用率已经高到成为事实标准。现在转正会固化缺陷，大改又会伤害现有用户，所以项目一直停在"准稳定"的状态。

Determinate Systems 由 Eelco 共同创办，多年来持续宣传"flakes 已经稳定"。这让技术问题、治理信任和商业利益纠缠在了一起[98]。

治理危机

治理危机有一条清晰的时间线：

  • 2023 年 9 月，NixCon 接受军事科技公司 Anduril 的赞助引发抗议，基金会撤下赞助[99]；
  • 2024 年 4 月，《Save Nix Together》公开信征集到上百个签名，指控创始人 Eelco Dolstra 反复推翻社区团队决策，行使章程未授予的 BDFL 权力[99:1]；
  • 2024 年 5 月，Eelco 退出 NixOS Foundation 董事会，一批维护者离开，Lix 从 CppNix 2.18 fork 出去[99:2]；
  • 2024 年下半年，选举产生的 Steering Committee 上任，首次选举有 450 名贡献者投票[99:3]；
  • 2025 年 9 月，Moderation Team 五名成员集体辞职，抗议 SC 干预 moderation 决策；同月 Nixpkgs core team 成立，被视为新治理的正面信号[99:4]；
  • 2026 年 8 月 7 日，core team 宣布解散：公开招募补员只收到 1 份申请，剩余两名成员因 burnout 退出，并在公告中批评 SC"缺乏宪法所设想的授权本能"、对已下放的决策微观管理[100]。

core team 在仅有的 10 个月里完成了不少工作：改革 committer 委托流程，新增 19 名 committer，扩展 merge bot，谈下 GitHub Enterprise 赞助，并建立了初步的 AI 贡献政策[100:1]。这些工作没有改变它缺少决策权的处境。SC 既没有把权力交给下层团队，也没有形成稳定的决策机制。12 个月内，moderation team 和 core team 先后因为同一种权责冲突崩溃。

Nixpkgs 收录了 12 万以上软件包，core team 公开招募补员时却只收到 1 份申请[101][100:2]。软件规模可以持续增长，不代表愿意承担项目级维护和治理责任的人也会增加。

这与 5.1 节讨论的志愿者边界直接相连：即使项目有成熟的代码和明确的技术目标，维护者承担责任却不能作出决定，仍可能选择离开。Hacker News 上有一条评论："Nix 包管理器：正确解决了你整个操作系统的依赖地狱。Nix 治理：还没解决人类的依赖地狱。"[102]

决策权与维护责任

BDFL 退位、委员会经选举产生之后，Nix 项目仍然遇到了权责冲突。治理结构的变化没有自动带来稳定的授权机制，决策速度和责任追踪仍是需要处理的问题。

Universal Blue 采取了不同的治理选择：它不把自己做成独立发行版，不设 BDFL，也不 fork Fedora，而是维护 Fedora 之上的定制层，使命宣言是"We target the 96%, not the 4%"[103]。这种做法减少了项目内部出现同类权责冲突的机会，但不能保证 ublue 未来一定成功。它至少说明，项目需要像设计技术架构一样设计治理结构，让维护者知道自己能作出哪些决定、又要承担哪些责任。

Lix 选择在保持兼容的前提下改进实现。它保持现有 flakes 和 NixOS 配置的兼容性，把工作重点放在清理语言中的历史 footguns、强化沙箱和重写错误信息上，并在 2025 年底宣布 flakes 进入 freeze 期，计划把它从核心抽离为默认随附的插件[104]。这给现有用户留下了迁移之外的选择，但 fork 也意味着社区需要额外承担一套实现和治理成本。

对普通用户来说，core team 解散不会立刻改变 nixpkgs 或 nixos-rebuild 的日常使用。长期影响取决于 SC 如何向维护团队授权、Nix 社区能否形成稳定的权责划分，以及 Lix 与 CppNix 能否保持兼容。

5.5 小结

判断项目能否持续，既要看资金和贡献模式，也要看整合、分发、支持和治理工作由谁长期承担。承担责任的人还需要有相应的决策权。否则，即使技术路线可行，项目也可能因为缺人、授权不足或责任不清而停滞。

结语：回到 apt install firefox

apt install firefox 没有证明 Ubuntu 正在用 Snap 取代整个 deb 系统。它引出的是发行版如何管理变化。稳定发行版并不是因为软件版本旧而稳定；稳定来自对变更的控制、持续维护和集成验证。锁定大版本是其中一种控制办法，可以缩小每次更新需要重新验证的范围。浏览器等快速迭代的应用很难长期遵循同一节奏，发行版因此需要重新划分系统与应用的维护责任。

RHEL、Universal Blue 和 deepin 的实践表明，分层交付与可恢复更新已经出现在多条技术路线中。它们没有共同选择 Snap，也没有形成统一的商店和治理模式。这些项目面对的难题相似，也都选择把系统基座与更新更快的应用分开，但具体实现仍要分别评价。

Snap 为 Ubuntu 提供了一种解耦方案，也把分发基础设施和部分控制权集中到 Canonical。它确实减轻了多版本分发和维护的压力；与此同时，apt 静默重定向、桌面集成和网络可达性等具体问题仍然存在。换用 Flatpak、原生包或滚动发行版可以避开其中一部分问题，但更新、审核和支持工作不会因此消失。评价这些选择时，需要看它解决了什么问题、由谁长期维护，以及它给用户增加或减少了多少负担。

附录 A：发行版如何管理变化

正文指出，锁定大版本是稳定发行版控制变更的一种办法。本附录进一步讨论发行版怎样形成可预测的系统，并比较几种不同的实现。

比较发行版变化管理的六个维度

发行版接收的上游软件始终在变化。维护者需要检查依赖关系、处理 ABI 变化、完成构建与测试，再决定何时把新的软件集合交给用户。发布后的修复规则、升级路径和故障恢复也属于这套工作。

版本年龄不能单独说明系统是否可靠。失去维护的旧软件会积累漏洞和兼容问题；发行版也可以通过集成验证，让较新的软件共同工作。固定发行版和滚动发行版描述的是变化如何进入系统，软件质量还要看具体的维护与验证。

比较不同发行版时，可以检查以下六项：

维度要回答的问题
版本新鲜度软件与上游版本相差多远
维护状态软件是否仍接收安全更新和重要错误修复
变化频率用户多久接收一次系统状态变化
集成验证发行版在交付前检查哪些依赖和回归
恢复能力更新失败后能否回滚或快速恢复
兼容周期一个接口和系统基线承诺维持多久

固定发行版通常降低变化频率，并延长兼容承诺。滚动发行版缩短交付间隔，持续产生新的系统状态。具体项目还会通过测试仓库、自动化测试、快照或回滚工具控制风险。

Debian：先形成发布基线，再限制变化

Debian 的软件先在 unstable 和 testing 中演进。发布团队检查构建结果、依赖关系和测试回归，协调大型库升级，让软件包逐步形成可以共同发布的状态。Stable 发布后，允许进入系统的改动显著减少，维护者主要提供安全更新和必要修正。

Debian Stable 中较旧的软件版本来自这个发布模型。项目选择长期维持已经验证的兼容关系，因此不会持续把所有上游版本送入同一个 Stable 版本。安全修复和兼容维护仍然继续，版本号只是这套策略留下的结果。

Debian 的 ABI、Testing 与 transition

Debian 使用共享库元数据记录兼容关系。ELF 程序会记录所需共享库的 SONAME。库包通过 shlibs 或更精细的 symbols 文件描述 ABI 依赖，dpkg-shlibdeps 再根据程序实际使用的库和符号生成包依赖。ABI 兼容时，库可以更新，已有二进制程序仍可继续运行。ABI 不兼容时，维护者通常需要改变 SONAME，并重新构建受影响的软件包[105]。

新包通常先进入 unstable，再由 britney 判断它能否迁移到 testing。britney 会检查构建结果和依赖关系，并确认迁移后不会产生新的不可安装包。对于配置了 autopkgtest 的软件，测试还可以覆盖候选包的反向依赖；一旦出现相对于当前 testing 的回归，迁移就会被阻止或延迟。Testing 是持续接受集成检查的候选系统，软件包在 Sid 中停留的时间只是迁移条件之一[106]。

Debian 把大型库升级作为 transition 管理。共享库改变 SONAME 后，构建基础设施可以通过 binNMU 批量重建只需重新链接的软件包；需要修改源码的包仍由维护者修复。Release Team 使用 transition tracker 跟踪相关反向依赖的迁移状态[107]。

这些机制先让不断变化的软件包形成一套经过验证、能够协同工作的系统，发布后再严格控制改动。维护者仍需长期提供安全修复并维持兼容关系。

Arch：持续维护仓库的一致状态

Arch 持续接收上游版本。官方包经过构建和签名，需要公开测试的版本会进入 testing；大型共享库或工具链升级则先在 staging 中完成相关软件包的重建[108]。Arch 维护着一条不断前移的仓库基线。

用户需要完整升级系统、阅读重要公告，并在必要时处理配置迁移。官方维护文档明确不支持 partial upgrade[73:3]。Arch 减少了长期维护旧基线的工作，也要求用户及时跟进新的系统状态。正文 3.5 节讨论的是这套模式交给用户的日常维护责任。

Gentoo：滚动系统中的软件包稳定化

Gentoo 的 keyword 机制按软件版本和架构标记稳定状态。以 amd64 为例，amd64 表示该版本已经广泛测试，没有已知的严重问题；~amd64 表示该版本尚未稳定化，仍需更多测试[109]。同一个滚动发行版中，不同版本和架构可以处于不同的稳定化阶段。

Gentoo 还用 slot、sub-slot 与 preserve-libs 处理可并存版本和共享库更新。sub-slot 变化可以触发依赖包重建；preserve-libs 会暂时保留仍有程序依赖的旧共享库，直到相关软件完成重建[110][111]。因此，Gentoo 的滚动系统仍然保留了明确的软件包测试与稳定化阶段。

openSUSE Tumbleweed：连续发布经过测试的快照

openSUSE Tumbleweed 将一批更新组成 snapshot，并用 openQA 检查单个软件包和整组更新能否共同工作。通过测试的快照再交付给用户[112]。用户持续从一个经过验证的仓库状态移动到下一个状态。

Tumbleweed 默认使用 Btrfs 与 Snapper，在包管理器操作前后创建快照并支持回滚[113]。openQA 降低更新失败的概率，文件系统快照则缩短故障后的恢复过程。版本新、更新频繁和系统可恢复可以同时存在。

四种路线的差别

项目如何组织变化用户承担的主要责任
Debian Stable形成发布基线后长期限制改动接收维护更新，跨版本升级时处理迁移
Arch持续推动整个仓库向前完整升级并及时处理迁移事项
Gentoo按版本和架构完成软件包稳定化选择 keyword、USE 配置与更新节奏
Tumbleweed连续发布经过 openQA 测试的快照持续更新，并在需要时使用快照恢复

这些项目都在管理变化，只是验证窗口、交付频率和用户责任不同。操作系统需要长期维持兼容基线，浏览器却按数周周期发布。Snap 和 Flatpak 将此类应用从系统基座中拆出，减少发行版的多分支维护工作，同时增加沙箱集成、商店治理、更新控制和磁盘占用方面的成本。

附录 B：社区与用户原声

本附录收录视频、评论区与论坛中的用户观点（等级 C），只用于展示体验和态度样本，不作为技术和统计事实。每组材料附有来源、上下文和适用范围。

LTT 挑战与 Linux 桌面体验

正文 3.2 节记录了五个案例的经过与归因，并保留了 Linus 的"普通人不想把修操作系统当爱好"这一句。这里补全 Elijah 案例的完整原话（LTT wrap-up 视频）[70:2]：

完整引语：Marathon 反作弊与社区反应

Elijah 抱怨由于内核级反作弊，新游戏 Marathon 无法在 Linux 上运行。他收到的不是同情或解决方案，而是社区的指责，许多人告诉他"你本来就不该玩这个游戏"，甚至私信攻击他是为了"故意抹黑 Linux"。

更讽刺的是，由于每次去 Reddit 求助看到的都是"400 多条互相攻击、争论哪个发行版更好的跟帖"（正如 Linus 所说，无论遇到什么问题，总有半打人跑出来自信地宣称"用我的这个发行版就不会有这问题"），Elijah 最终被逼得完全放弃了在社区论坛求助，转而全程使用 LLM 来解决问题。

这段原声只能说明，社区中确实存在把用户的具体诉求转成立场攻击的行为，并因此把用户推离求助渠道；它不能代表整个 Linux 社区。正文 4.2 节已说明这一限制。

WSL 与原生 Linux 的选择

正文 3.4 节引用了两条最有代表性的评论（"终极还是选择了 wsl+windows"、"linux 最大众的用法"）。这里保留 Arch 争议视频评论区的完整原声[72:4]：

完整引语：关于 WSL 与发行版选择的六条评论

"现在越来越没有精力尝试那些发行版了，终极还是选择了 wsl+windows"

"我一般用 wsl2 或者直接 ssh Ubuntu 的 server，难道我会天天抱着个 home 目录里一遍又一遍地刷新看 logo 吗，我用 Ubuntu 是因为 linux 里面方便写 machine learning，仅此而已。"

"个人观点，没有特殊需求，日常使用 Windows 完全够用，任何对非熟练计算用户的 Linux 传教都是不合适的。"

"不是程序编码相关行业的没必要去用 Linux……除非你明确知道在 Linux 下你能完全替代 Win 下的工作流，你再选 Linux 才是正确的。"

"我用 Arch 纯粹就是乐意折腾……有的时候掉链子是真的会想换 Windows 和 WSL"

"linux 正确用法就应该是无头服务器跑服务。我自己是台式机 windows 打游戏，笔记本 arch 玩本地 ai 还有开发，家庭服务器 ubuntu server"

这些评论显示，有一批用户把 Linux 定位为后端、服务器或开发环境，而不是桌面身份，并据此选择 WSL 或远程连接作为务实方案。这是一部分用户的取向，不代表全体，正文 3.4 节已说明这一点。

守门人文化与新用户门槛

正文 4.2 节保留了"技术异化为身份图腾"的高赞评论和"社区的精神是'带'不是'拉'"这一句。这里补全完整长引语[72:5]：

完整引语：关于守门人文化的五条评论

"当一个社区的规模扩展到一定程度，原本作为工具的技术往往就会开始异化为一种身份图腾。其原因在于在这些社区中，知识即地位，掌握更多技术知识的人通常也就掌握了更大的话语权。在这样的箱庭中，人们就会开始将技术知识储备作为衡量个人能力、甚至人格的绝对标准；将傲慢和缺乏同理心包装成'极客'的严谨性。"

"Arch 信徒们根本不是想要拉小白触碰他们神圣的 Arch，而是通过'简单'之类的言语诱导小白进来，然后在小白一脸懵逼地倒在 install 阶段的时候跳出来嘲讽'这么简单都不会'，以此获得虚妄的满足感罢了。"

"你炫耀没问题，但你炫耀了，又不教，简直无耻。你让人家用 Arch，你就应该知道这玩意难，社区的精神应该是'带'而不是'拉'。拉入 Arch 有什么了不起，了不起的是你能带他走完你走过的坑！"

"用你的需要来强行决定，说别人也必须需要，这本身就是一种变态。而更变态的是，在说服别人之后，还要对别人提出的问题开口嘲笑。"

"嘉豪们又会说，这些又不难，学一下就行了呗，这在暗中秀自己智商'高人一等'的同时，也犯下了傲慢之罪：并不是每个人都想知道技术细节与底层原理，也没有义务为了你设计的缺陷而额外付出精力和时间来学习一个全新的东西。……更何况，还有一群假装传教士的守门人以自己的方式阻止新人进入生态，毕竟，用的人多了，怎么体现自己的优越性呢？"

以上五条说明社区中确实存在守门人式回应，但不能代表整个社区的态度。正文 4.2 节已说明这一限制。

Snap、Ubuntu、Arch 与 Mint 的用户观点

以下三条评论分别讨论按需求选择发行版、自定义体验和学习经历，可与正文 4.2 节中的态度样本对照[72:6]：

完整引语：发行版选择与使用经历

"吹 Arch 和反 Arch 的都是嘉豪。我现在主要用 debian……但总有人喜欢 arch 的 wiki 氛围、够新的软件源、方便但有风险的 aur。也总有人喜欢 ubuntu 开箱即用的傻瓜方便和更高的硬件兼容性。各取所需，各走一条路就行。因为自己不喜欢另外一条路，所以专门发个檄文讨伐走另外一条路的人，我觉得这行为挺嘉豪的。"

"使用大多数发行版都不妨碍用户自定义，Debian 不但尊重我的自定义，而且让我自定义得很轻松。"

"我计算机出身的，从 win 再到 ubuntu/debian 再到 arch，最后回到 ubuntu 的怀抱。在研究 arch 的过程当中我真心学到了很多 Linux 底层的设计，这对我日后开发高性能服务程序提供了非常大的帮助。所以技术不分好坏，需要根据需求来决定。改车本质上就是小众文化，arch 社区忽悠小白上手 arch 本质上，就是跟不懂车的人说买辆二手车回来改一样抽象。"

与守门人文化并存的，还有一批用户明确主张各取所需，反对以发行版划分阵营。两组原声放在一起，说明社区态度并非单一。

Nix 治理评论

正文 5.4 节已引用 Hacker News 的这条评论，这里归档完整原话与来源[102:1]：

"Nix 包管理器：正确解决了你整个操作系统的依赖地狱。Nix 治理：还没解决人类的依赖地狱。"

这条评论只能作为治理观点的样本，不能单独证明 Nix 社区对治理状态存在统一判断。它仍是观点材料（等级 C），不是官方定性。

附录 C：旁注与补充材料

本附录保留不适合进入正文主线的作者旁注、预判反驳与延伸观察。以下内容均不属于正文论证，按对应章节分类。

第 1 部分旁注

补充材料：关于 ESR 的预判反驳

浏览器更新需要同时考虑功能和安全。仍在支持期内的 ESR 即使落后多个大版本，也会继续获得安全修复，并可能满足部分用户当前的功能需求。但某项新功能或 Web 标准不在一个用户的工作流中，不代表其他用户不需要；安全补丁修复的往往是只在特定输入或攻击路径下触发的漏洞，正常浏览时通常感觉不到修复前后的区别。因此，"我感觉没什么区别"只能说明当前常用功能没有明显变化，不能用来判断新功能是否普遍无用，也不能证明旧版本没有安全风险。发行版还要根据支持周期、网站兼容性和安全维护状态决定交付哪个版本。

补充材料：关于浏览器自动更新与 LTS 的旁注

大多数用户手机或者 Windows 上的浏览器都是自动更新的，用户几乎体验不到新旧这个过程，大部分用户并不会自己故意不更新浏览器。Canonical 和 Mozilla 能让用户用上最新浏览器而且也是自动更新，这个选择我觉得没有什么问题。

Arch 和 Fedora 不承诺 LTS 级别的长期稳定锁定，因此可以直接在仓库中推送最新版本的浏览器，维护压力小得多。

第 2 部分旁注

补充材料：关于 RHEL 的旁注

Red Hat 将部分应用改为独立分发后，可以把更多工程资源用于 Wayland 等底层平台工作，具体分工见 2.1 节。

第 3 部分旁注

补充材料：关于 WSL 性能的预判反驳

WSL 2 可以承担编译、运行容器、小模型训练和本地测试等常见开发任务。需要直接访问特定硬件、内核功能或严格控制延迟的工作仍应使用原生 Linux；具体性能差异取决于任务、存储路径和硬件配置。

补充材料：关于 Arch 的旁注

对于个人用户而言，Arch Linux 同样可以用于服务器和桌面场景，靠自己的技术来维护。但大部分生产环境下是没得选的。

第 4 部分旁注

补充材料：关于 GNOME 托盘与 KDE 借鉴的延伸观察

GNOME 不再默认展示旧式 status icon/legacy tray 本身没有问题，有利于 Wayland 的发展。但它没有原生提供一个与传统系统托盘等价的体验，而是更倾向于把应用迁移到新的后台应用机制；因此社区才发展出了 AppIndicator and KStatusNotifierItem Support 这类兼容扩展。把这件事说成"GNOME 移除托盘图标"会过度简化。

GNOME 44 引入了"后台应用"机制。KDE Plasma 6.7（2026 年 6 月）的官方发布公告也说明，System Tray 增加了对新"Background Apps"系统的支持，这类机制在 Flatpak 应用中更常见。KDE 还在 Plasma 6.6 推出了 Plasma Login Manager（SDDM 的分支），为 Plasma 提供自己的显示管理器。这些变化说明两个桌面项目会分别吸收已有机制并补充缺少的组件。

参考 https://kde.org/announcements/plasma/6/6.7.0/

补充材料：关于 Arch 高手的讽刺观察

评论区里，一些长期用户会明确说明 Arch 不适合所有新手，并推荐 Mint 或 Ubuntu。相比之下，脱离用户需求宣称"Arch 最简单"，会忽略安装、更新和故障处理所要求的维护经验。熟悉系统的用户觉得这些操作简单，不代表新用户也具备相同的前置知识。

第 5 部分旁注

补充材料：关于 deepin 实践王勇判断的延伸观察

deepin 25 默认使用"磐石"系统，核心目录只读，并支持原子更新和快照回滚；应用分发则加入了玲珑沙箱格式。这些设计与 Android、ChromeOS 的系统保护和独立应用分发方式有相似之处。deepin 的案例说明，商业公司可以投入资源整合系统更新、应用分发和桌面体验。

  1. Feature Freeze Exception: Seeding the official Firefox snap in Ubuntu Desktop，Ubuntu Desktop Team 官方公告（Ubuntu Discourse），2021-09-16，访问于 2026-08-21。原文明确说明：Mozilla 主动联系 Canonical，Firefox 种子包由 deb 替换为"Mozilla-official Firefox snap"，过渡在 22.04 开发周期内完成。 ↩︎ ↩︎ ↩︎

  2. 可复现实验：Ubuntu 26.04（Resolute），2026-08-21，执行 apt list | grep snap1。匹配到的过渡包仅 chromium-browser、firefox、thunderbird 三组（版本号均含 1snap1 标记）及其 locale 子包，无其他软件。 ↩︎ ↩︎ ↩︎

  3. Snap 的前身是 2014 年 12 月 9 日 Canonical 发布的 Snappy Ubuntu Core，见 Announcing Ubuntu Core, with snappy transactional updates!（Mark Shuttleworth，Canonical 博客）；2016 年随 Ubuntu 16.04 LTS 以"snap"应用格式进入桌面与服务器，见 Ubuntu 16.04 发行注记（XenialXerus/ReleaseNotes）。访问于 2026-08-21。 ↩︎

  4. Chromium in Ubuntu: deb to snap transition（Alan Pope，Snapcraft 官方博客），2019-10-10，访问于 2026-08-23。原文说明：Chromium 当时大约每六周发布一个大版本，中间还有修复安全漏洞的小版本；每个新版都要为多个受支持的 Ubuntu 版本和 amd64、i386、armhf、arm64 架构构建，旧版 Ubuntu 的编译工具链还可能不支持上游使用的新特性。Snap 每个架构只需构建一次，可以覆盖所有支持 snapd 的系统。 ↩︎ ↩︎

  5. Chromium（Snapcraft Store），访问于 2026-08-21。 ↩︎

  6. Debian 包追踪页：chromium，访问于 2026-08-21。 ↩︎ ↩︎

  7. Installing Thunderbird on Linux（Mozilla 官方支持文档），访问于 2026-08-21。原文说明 Thunderbird snap 由"Canonical and Thunderbird"共同维护。 ↩︎

  8. Ubuntu release cycle；Debian LTS（Debian Wiki）。访问于 2026-08-21。 ↩︎

  9. What is an Ubuntu LTS release?（Rhys Davies，Canonical 博客），2020-04-17，访问于 2026-08-21。原文："Without long term support, software can become a security risk. Vulnerabilities develop over time and without mechanisms to patch or update them, systems become exposed and perform worse the longer they remain out-of-date." ↩︎ ↩︎

  10. firefox-esr（Debian 包页）；Firefox ESR（Mozilla）。访问于 2026-08-21。 ↩︎ ↩︎

  11. Security Vulnerability in Firefox 16（Mozilla Security Blog），2012-10-10，访问于 2026-08-21。Firefox 16 被发现漏洞后，Mozilla 次日发布 16.0.1 并通过自动更新推送给所有用户。 ↩︎

  12. Manage software repositories（Ubuntu Server Docs），访问于 2026-08-21。 ↩︎

  13. Firefox and Thunderbird as RHEL Flatpaks: What it means for you（Scott McCarty，Red Hat 博客），2026-07-30，访问于 2026-08-21。原文："RPMs for Firefox and Thunderbird were deprecated in RHEL 10.0, and RHEL 10.2 completes the transition by making Flatpaks the default." ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  14. 作者在 Ubuntu 上的使用观察（可复现实验，截至 2026-08）：Neovim 官方源版本落后于上游最新稳定版；PrismLauncher 官方源锁定在 10.0.5、Snap 版为 11.x；fish、fastfetch、ripgrep 等工具官方源版本同样落后。 ↩︎

  15. The Linux Sandbox（Chromium 官方文档），访问于 2026-08-21。原文：namespace sandbox "based on (unprivileged) user namespaces in the Linux kernel"，自 M-43 起在内核支持时取代 setuid sandbox。 ↩︎

  16. Introduction to Flatpak（Flatpak 官方文档），访问于 2026-08-21。原文列举 CLI 限制时写明："Flatpak won't allow spawning sub-namespaces in the sandbox." ↩︎

  17. Flatpak and the future of the Linux desktop（Joe Brockmeier，LWN），2025，访问于 2026-08-21。记录 Flatpak 核心开发者 Sebastian Wick 在 Linux Application Summit 2025 的发言，原话："nested sandboxing does not work in Flatpak"、"There have been issues with this approach for quite a while ... but no one knows quite how to solve them"、"you will notice that it's not being actively developed anymore"、user namespace "well-tested and a much-used interface"。 ↩︎ ↩︎ ↩︎

  18. Snap confinement（Snapcraft 官方文档），访问于 2026-08-21。原文："Strict confinement uses security features of the Linux kernel, including AppArmor, seccomp and namespaces." ↩︎

  19. How are we improving Firefox snap performance? Part 1（Snapcraft 官方博客），访问于 2026-08-21。原文："snaps add an extra security layer on top of the browser's already-robust sandboxing mechanism." ↩︎

  20. org.freedesktop.Platform.GL.nvidia（GitHub，Flathub 源仓库），访问于 2026-08-21。 ↩︎

  21. Run CUDA workloads on Ubuntu Core（Ubuntu 官方文档），访问于 2026-08-21。gpu-2404 content interface 把宿主 GPU 用户态驱动库（含 Nvidia）直通给 snap。 ↩︎

  22. Flathub Statistics，访问于 2026-08-21。 ↩︎

  23. Visual Studio Code Snapcraft 配置（GitHub），访问于 2026-08-21。 ↩︎

  24. Get started（MicroK8s 官方文档）；MicroK8s（Canonical 官方页面），访问于 2026-09-01。官方页面给出的通用安装命令为 sudo snap install microk8s --classic；入门文档说明 MicroK8s 会持续运行，并在系统重启后自动启动。 ↩︎

  25. Introduction to Flatpak（Flatpak 官方文档），访问于 2026-08-21。原文："Flatpak is best suited for desktop applications. While command-line applications also work, Flatpak may not be suitable in some cases"；随后列举 SUID 二进制、宿主 /proc、seccomp 子命名空间、内核模块、udev/systemd 等限制。 ↩︎

  26. Bluefin DX 官方文档（JetBrains 小节），访问于 2026-08-21。原文推荐 ujust jetbrains-toolbox 安装 JetBrains Toolbox 以统一管理 JetBrains 全系产品，并明确写道 "We do not recommend using the JetBrains flatpaks."；VS Code 作为镜像默认 IDE 预装（"included in the image as the default IDE"）。 ↩︎ ↩︎ ↩︎

  27. canonical-livepatch（Snapcraft 官方商店）；What is included in Ubuntu Pro?（Ubuntu Pro 官方文档）；Landscape（Ubuntu 官方页面），访问于 2026-09-01。Snapcraft 页面显示 canonical-livepatch 由 Canonical Verified 账号发布；Ubuntu Pro 文档说明 Livepatch 面向 High 与 Critical 级内核 CVE，且仍需使用常规更新工具安装全部标准内核更新；Landscape 可集中管理 Ubuntu 主机、更新和 Snap。 ↩︎

  28. canonical/snapd（GitHub），访问于 2026-08-21。snapd 客户端为开源软件，源码公开、支持社区贡献。 ↩︎

  29. Managing software in complex network environments: the Snap Store Proxy（Snapcraft 官方博客），访问于 2026-08-21。原文：Snap Store Proxy 是 "an on-premise edge proxy to the global Snap Store"，支持本地缓存、版本 override、离线（air-gapped）模式。 ↩︎

  30. Listing your snap for review（Snapcraft 官方文档），访问于 2026-08-21。 ↩︎

  31. 部分 Intel Xe 核显 VA-API 硬件解码问题，作者观察，在 Ubuntu 26.04 LTS 仍然存在。 ↩︎

  32. canonical/firefox-snap（GitHub），访问于 2026-08-21。历史 issue 记录早期插件/输入法/冷启动/主题/密码管理器问题，多数已改善。 ↩︎

  33. 据社区反馈（等级 C）：Snap Store 走 Cloudflare CDN 未启用大陆节点；Flatpak 可换中科大等镜像。 ↩︎

  34. 如意玲珑（Linyaps）社区官网；了解如意玲珑（发展历程），访问于 2026-08-21。原文：2024-05-24 项目正式捐赠给开放原子开源基金会；基于 User Namespace 等内核隔离实现应用与系统解耦，"一次构建、全发行版分发"。 ↩︎ ↩︎ ↩︎

  35. Introducing the Red Hat Flatpak runtime for desktop containers（Red Hat Developer 博客），2020-08-12，访问于 2026-08-21。原文：runtime "follows the Red Hat Enterprise Linux lifecycle"，"We intend to continue providing security fixes for 10 years from RHEL 8's May 2019 release date." ↩︎

  36. RHEL 8.3.1 release notes（Red Hat 文档），访问于 2026-08-21。"Flatpak packages for several desktop applications" 一节列出 Firefox、GIMP、Inkscape、Thunderbird 四个 Flatpak 容器镜像，上线 Red Hat Container Catalog。 ↩︎

  37. RHEL 9.2 Release Notes, Deprecated functionality（Red Hat 文档），访问于 2026-08-21。原文："The LibreOffice RPM packages are now deprecated and will be removed in a future major RHEL release." 另见 Matthias Clasen 在 Fedora devel 邮件列表的说明（2023-06-01，https://lists.fedoraproject.org/archives/list/[email protected]/thread/46ZZ6GZ2W3G4OJYX3BIWTAW75H37TVW6/ ）：Red Hat Display Systems 团队调整工程优先级，聚焦 Wayland、HDR 等方向，停止随 RHEL 交付 LibreOffice。 ↩︎ ↩︎

  38. Red Hat 官方 issue SAT-30947（https://issues.redhat.com/browse/SAT-30947 ）记录：RHEL 10.0 Beta 发行说明写明 "In RHEL 10, Firefox and Thunderbird are available exclusively as Flatpaks"。Beta 发行说明原文页已随版本下线，此表述由该官方 issue 存档。 ↩︎

  39. Rocky Linux 10.2 Available Now（Rocky Linux 官方公告），2026-05-28，访问于 2026-08-21。原文："Flatpaks are now the default delivery method for Mozilla Firefox and Mozilla Thunderbird. The Anaconda installer preinstalls these Flatpaks automatically... RPM packages remain available in AppStream for the lifetime of Rocky Linux 10, and users who prefer them can override the default in Kickstart configurations." ↩︎

  40. Debian 13 "trixie" released（Debian 官方公告），2025-08-09。原文：软件包总数为 69,830 个。 ↩︎

  41. Debian 正式开发者（Debian Developer）人数来自 Debian 投票信息（Debian Voting Information）历年统计：2012 年 948 人，2025 年 1030 人；活跃贡献者口径见 contributors.debian.org（过去 12 个月约 1397 人）。访问于 2026-08-21。 ↩︎

  42. DPL: Debian project has plenty of money but not enough developers（The Register，经 einnews 转载），2020 年（DebConf20 演讲报道），访问于 2026-08-21。原文：项目账上 "over $900,000"；"there are 975 uploading developers and 223 maintainers"；Bullseye 展望 "over 61,000 amd64 binary packages"；"at three times we could probably achieve all our goals"。 ↩︎ ↩︎

  43. Debian splits ftpmaster team（Joe Brockmeier，LWN），2025-10-29，访问于 2026-08-21。原文：FTPmaster 团队 "responsible for ... maintaining Debian's package archive for more than two decades"；截至 2025-10-26 "the team is no more"，职责拆分为 Archive Operations Team 与 DFSG, Licensing & New Packages Team；新包等待审核的原因之一是 "too few hands to do the work"。 ↩︎

  44. There Is No One Left On Debian's Data Protection Team（Michael Larabel，Phoronix），2026-01-05，访问于 2026-08-21。原文：该团队 2018 年成立以处理 GDPR 事务，"all three delegated members of the team recently stepped back"；DPL Andreas Tille 在 Bits from the DPL 中说明 "Debian currently has no active Data Protection Team. All previous delegates have stepped back, and the delegation has therefore been revoked." ↩︎

  45. Processing times for the NEW queue（Debian 邮件列表），2025-03，访问于 2026-08-21。Matthias Urlichs 指出 NEW 队列当时约 135 个包、最老的包已滞留约九个月；Timo Röhling 的分析则显示中位处理时间不到 48 小时、约 2% 的包滞留数月以上。另见 LWN 关于 ftpmaster 拆分的报道中 Otto Kekäläinen 举的开发者等待审核数月的例子。 ↩︎ ↩︎

  46. Debian 的 MIA 流程（LWN），2026-01，访问于 2026-08-21。原文记录的是 DebConf25 上提出的六阶段 MIA（Missing in Action）自动化流程提案，尚处于"提出/鼓励"阶段，未实施。 ↩︎

  47. Debian GNU/kFreeBSD（Debian Wiki），访问于 2026-08-21。原文：该端口在 Debian 6.0/7.0 以技术预览/正式 port 发布，"Since Debian 8 (Jessie) it is no more included in official releases"；"The development of Debian GNU/kFreeBSD has officially terminated as of July 2023 due to the lack of interest and volunteers." ↩︎

  48. Dunc-Tank（Debian Wiki）；Debian + Dunc-Tank.org = dissent（LWN），访问于 2026-08-21。2006 年由时任 Debian 领导人 Anthony Towns 发起的筹款实验，募集约 6000 美元，支付给两位 release manager（Steve Langasek、Andreas Barth）各一个月全职工作的报酬，试图让 etch 按时发布；此举引发社区强烈反对，担心付费让 Debian 变成两级系统，部分开发者因此减少投入，etch 反而推迟到 2007 年 4 月才发布。 ↩︎

  49. Maintainers don't scale（LWN），2022，访问于 2026-08-21。2022 年 Linux 存储、文件系统、内存管理与 BPF 峰会（LSFMM）上，Josef Bacik 主持的关于维护者压力与 burnout 的讨论（原计划由 Darrick Wong 主持），标题即 "Maintainers don't scale"。 ↩︎

  50. Long-term support for Linux kernels is about to get a lot shorter（Liam Proven，The Register），2023-09-26，访问于 2026-08-21。原文：LWN 编辑 Jonathan Corbet 在 Open Source Summit 宣布六年更新政策将取消，"We're likely to go back to a long-term stable kernel maintained for about two years." ↩︎

  51. Succession: Linux kernel community gets continuity plan for post-Linus era（Joe Fay，The Register），2026-01-27，访问于 2026-08-21。原文：Dan Williams 起草的 "Linux project continuity document" 已合并进内核文档（Documentation/process/conclave.rst），规定当顶层仓库维护者无法继续工作时，由 $ORGANIZER 在 72 小时内启动与最近一届 Maintainers Summit 参与者的继任讨论。 ↩︎

  52. Universal Blue 主页，访问于 2026-08-21。原文："It's not a distribution, but a new way to consume existing distributions"；"Not a new distribution, a layer of customization on Fedora that can be cleanly removed"；"Reliable, atomic updates with built in rollback"；"Hosted on ghcr.io"；"Ninety (90) days of image archives allowing for flexible rollback options"。镜像可通过 "a Containerfile and our GitHub build actions" 派生，并用 sigstore 工具签名；四个变体为 Bluefin、Aurora、Bazzite、uCore，其中 uCore 基于 Fedora CoreOS。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  53. bootc 项目 README，访问于 2026-08-21。原文："Transactional, in-place operating system updates using OCI/Docker container images"；"using standard OCI/Docker containers as a transport and delivery format for base operating system updates"；"The container image includes a Linux kernel ... which is used to boot." bootc 底层使用 ostree。 ↩︎

  54. Bazzite 官网，访问于 2026-08-21。原文："built in Nvidia drivers"；"full support for accelerated video encoding and decoding"；"Secure Boot support"；"Bazzite is image based, meaning that after every update the previous version of the operating system is retained on your machine." 镜像经 GitHub Actions 与 Fedora Copr webhooks 自动更新。 ↩︎ ↩︎ ↩︎ ↩︎

  55. deepin 25 发行注记，访问于 2026-08-21。原文：磐石系统"核心文件挂载为'只读'权限"、"支持原子化更新，通过数据增量的方式更新"、"支持系统更新失败或者系统无法启动时，自动回滚到上一次自动备份的数据"、"支持软件及驱动以系统扩展的形式进行安装"；如意玲珑"支持 Debian、Ubuntu、Arch、Fedora、openEuler 等多个主流发行版"、"累计已完成 5000+ 款软件上架"。 ↩︎ ↩︎ ↩︎ ↩︎

  56. 如意玲珑社区官网"了解如意玲珑"，访问于 2026-08-21。原文：四层架构（应用层/运行时层/基础层/沙箱视图）；"通过 User Namespace 和 CGroup 实现隔离"；"写时复制技术"；"支持 10+ 主流 Linux 发行版"；"6000+ 应用"；架构覆盖 x86_64/ARM64/LoongArch64/RISC-V/MIPS64/SW64。存储"节省 60% 以上"为官网宣传数据。 ↩︎ ↩︎ ↩︎

  57. xdg-desktop-portal 1.21.0 发布说明，2026-01-21 发布，访问于 2026-08-21。原文 New Features 含 "Support linyaps applications (#1846)"。如意玲珑官网"发展历程"将 XDG 正式支持归入 2025 年度分组；精确落地为 1.21.0（2026-01）的发布。 ↩︎ ↩︎

  58. Ubuntu Core（Canonical 官网），访问于 2026-08-21。原文：Ubuntu Core 是 "The immutable embedded Linux OS"、"Ubuntu Core is immutable and strictly confined"、"Ubuntu Core architecture is built on snaps"，面向 IoT 与边缘设备。 ↩︎

  59. Introducing image mode for RHEL（Red Hat 文档），访问于 2026-08-21。原文："RHEL Image mode is a deployment method that uses container technology to manage the operating system as an Open Container Initiative (OCI) container image"；"Image mode for RHEL is available by using the registry.redhat.io/rhel10/rhel-bootc bootc image"；"Immutable updates ... roll back when needed in the same way that you use rpm-ostree systems"；bootc "is intended to supersede rpm-ostree"。 ↩︎

  60. UEFI/SecureBoot（Ubuntu Wiki），访问于 2026-08-21。微软信任 Canonical 的签名，Ubuntu 从 UEFI 到桌面开箱即用，无需手动注册 MOK 密钥；对比之下 Arch/openSUSE 需自行签名。 ↩︎

  61. NVIDIA drivers installation（Ubuntu 文档），访问于 2026-08-21。sudo ubuntu-drivers install 自动安装推荐驱动；仓库提供预编译多版本驱动模块，图灵架构以前的显卡仍可从官方仓库安装 580 版驱动。 ↩︎

  62. Snapcraft 商店，访问于 2026-08-21。Steam、PyCharm、Telegram 等闭源软件在 Snap Store 提供官方 Snap 包，可一键安装。 ↩︎

  63. OpenShell（Snapcraft 商店），访问于 2026-08-21。NVIDIA 的 OpenShell 是运行自主 AI agent 的开源沙箱运行时（Apache-2.0），由 NVIDIA 认证发布者（nvidia-snap-publisher）发布 Snap；简介为 "OpenShell provides safe, sandboxed runtimes for autonomous AI agents."（另见 https://docs.nvidia.com/openshell/ ）。AUR 截至 2026-08-21 仍未打包。 ↩︎

  64. Ubuntu 26.04 LTS 发行注记（Summary for LTS users），访问于 2026-08-21。原文："The NVIDIA CUDA toolkit is now available. Added in version 26.04"，应用开发者与系统管理员 "can now install the NVIDIA CUDA parallel computing platform from the Ubuntu Archives"，安装命令为 sudo apt install cuda-toolkit。 ↩︎

  65. Ubuntu Certified hardware（Canonical 官网）；LTS Enablement Stack（Ubuntu Wiki），访问于 2026-08-21。Canonical 与 Dell、Lenovo、HP 等厂商合作在认证设备上做兼容性测试；HWE 栈为 LTS 持续回溯新内核与图形驱动。 ↩︎

  66. Ubuntu Pro（Canonical 官网），访问于 2026-08-21。Ubuntu Pro 为个人用户免费提供最多 5 台设备的延长安全维护。 ↩︎ ↩︎

  67. LTT 2026 Linux 挑战视频（B站）。本节所述案例与引语（Linus 的"普通人不想把修操作系统当爱好"、Luke 无法判断故障来源的困惑、sleep 搜索逻辑等）作为展示普通用户体验的观察材料（等级 C）。 ↩︎ ↩︎ ↩︎

  68. Linux 7.1 will have an optional new NTFS driver（Liam Proven，The Register），2026-04-20，访问于 2026-08-21。Linux 7.1 合入了 Namjae Jeon 开发的新 NTFS 驱动（开发名 NTFSPLUS，合入后命名为 ntfs），是对早期只读驱动的重制，加入了完整写支持。 ↩︎

  69. Mouthing off about Linux（Jamie Zawinski），访问于 2026-08-21。原文："Linux is only free if your time has no value." ↩︎

  70. LTT 2026 Linux challenge wrap-up（YouTube）。Elijah 关于 Bazzite 软件商店体验超过 Windows 的评价（等级 C）。 ↩︎ ↩︎ ↩︎

  71. Windows Subsystem for Linux（微软文档），访问于 2026-08-21。WSL 2 提供完整 Linux 内核、systemd、GPU 直通、WSLg；CUDA 经 GPU-PV 可用；explorer.exe . 与 /mnt/c 自动挂载、/etc/wsl.conf 配置见微软 WSL 文档。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  72. Arch 争议视频（B站）。评论区原声（等级 C），作为展示实际用户选择的观察材料。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  73. System maintenance（Arch Wiki），访问于 2026-08-21。原文："Partial upgrades are unsupported"、"Do not use pacman -Sy package... Always upgrade (with pacman -Syu) before installing a package"；pacnew/pacsave 需手动处理；滚动更新需关注 Arch Linux News（https://archlinux.org/news/）。 ↩︎ ↩︎ ↩︎ ↩︎

  74. Arch User Repository（Arch Wiki），访问于 2026-08-21。AUR 由用户提交，无统一质量审查，PKGBUILD 需自行审阅。 ↩︎

  75. CSA 研究报告（Sonatype-2026-003775，CVSS 8.7）；Infosec.ge 报道，访问于 2026-08-21。2026 年 6 月 12 日，AUR 孤儿包被投毒，攻击者通过接管无人维护的包植入恶意代码。 ↩︎

  76. GRUB（Arch Wiki）；Secure Boot（Arch Wiki），访问于 2026-09-01。Arch Wiki 要求 GRUB 用户在安装或移除内核后重新运行 grub-mkconfig，并分别说明了 Secure Boot 密钥的创建、签名和注册流程。 ↩︎

  77. Debian 升级文档，访问于 2026-08-21。Debian 跨版本升级需手动改源再 apt full-upgrade；Ubuntu 的 do-release-upgrade 会引导临时卸载第三方包、禁用第三方仓库。 ↩︎

  78. Linux Mint 官网；Monthly News，October 2023；Monthly News，April 2026，访问于 2026-09-01。Mint 官方曾说明 22.x 不会用 Wayland 取代默认的 Xorg 会话；2026 年 4 月的月报称下一版本计划在 2026 年圣诞节发布，并以 Ubuntu 26.04 LTS 为软件包基础。 ↩︎ ↩︎ ↩︎

  79. How to Enable Snap Applications Support in Linux Mint（It's FOSS），访问于 2026-08-21。Mint 通过 /etc/apt/preferences.d/nosnap.pref 默认屏蔽 snapd；Mint 团队对 Ubuntu 20.04 Chromium 过渡包的表述："acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store"。 ↩︎ ↩︎

  80. Install Firefox on Linux（Mozilla Support），访问于 2026-09-01。Mozilla 的文档提供了用官方 APT 仓库中的 DEB 包替换 Ubuntu Firefox Snap 的步骤，也给出了 Flatpak 安装方式。 ↩︎

  81. SteamOS（Valve 官方页面），访问于 2026-08-21。Steam Deck 为不可变系统、原子更新，用户通过 Steam 与 Discover（Flatpak）安装软件。 ↩︎

  82. Introducing GNOME 3.26（GNOME 发布说明），2017-09，访问于 2026-08-21。原文："GNOME 3.26 no longer shows status icons in the bottom-left of the screen... they can be restored using the TopIcons extension"；另见 Status Icon Migration FAQ、GNOME 44 for Developers（background apps）、GNOME 官方 Status Icons 扩展（omgubuntu）。 ↩︎

  83. Mir (software)（Wikipedia）；Upstart (software)（Wikipedia），访问于 2026-08-21。Canonical 曾主导 Mir 显示服务器、Upstart 初始化系统与 Unity 桌面，均在后来的技术路线竞争中让位（Mir 退场、Upstart 让位 systemd、Unity 让位 GNOME）。 ↩︎

  84. Desktop Operating System Market Share（Statcounter），访问于 2026-08-21。含 "Unknown" 桶口径下，Linux 桌面份额长期约 3%（2026-04 为 2.99%、2026-05 为 3.09%）；2026 年 7 月起 Statcounter 去掉 "Unknown" 桶后显示约 7.5%，前后口径不同、不可直接比较。无论哪种口径，Linux 桌面都远低于 Windows 的六成以上。 ↩︎

  85. Ubuntu Unity 维护者因学业无法投入（IT之家，转载 NeoWin 2025-10-28），访问于 2026-08-21。项目负责人 Rudra B. Rudra 忙于大学考试，项目一度濒临关停。 ↩︎

  86. Ubuntu MATE Needs a Leader（Phoronix），2026-03，访问于 2026-08-21。创始人 Martin Wimpress 宣布失去热情、希望移交项目。 ↩︎

  87. Darrick Wong 关于 XFS 维护的邮件（LKML），2023-08，访问于 2026-08-21。公开表示"精疲力竭"，警示不想在 2030 年仍处于这种状态。 ↩︎

  88. 王勇原话（deepin 论坛原帖）；王勇 twitter 回答整理，访问于 2026-08-21。原文："桌面要集合设计、用户心理研究、产品细节……而 Linux 社区只有技术架构。" ↩︎

  89. Ubuntu 设计团队往事：品味是如何死在投票箱里的？（OSCHINA），2026-09-10，访问于 2026-09-11。评论转述 David Siegel 的当事人回忆；本文仅将其作为设计人员对决策过程的观点材料（等级 C），不据此认定具体历史争议的全部原因，也不沿用评论对集体决策和桌面 Linux 的整体判断。 ↩︎

  90. Desktop environment（Wikipedia），访问于 2026-08-21。该词条的 Gallery 部分列出超过 23 种风格类似的桌面环境。 ↩︎

  91. KDE e.V. 年报；KDE 2023 报告（Phoronix），访问于 2026-08-21。KDE 2022 年亏损约 9.9 万欧元、2023 年亏损约 10.7 万欧元。 ↩︎

  92. Linux Kernel Report（Linux Foundation），访问于 2026-08-21。超过 80% 内核代码由受薪开发者贡献；纯志愿者占比约一成（历次报告约 10-12%）。 ↩︎

  93. KDE e.V. 2023 年报，访问于 2026-08-21。KDE 2024 年度目标写得很克制："在不大幅扩张的情况下保持现有的活动水平"。 ↩︎

  94. Richard Brown 关于 openSUSE 贡献者与用户的邮件（LWN 存档），访问于 2026-08-21。贡献者最多时用户最少，用户增长期贡献者停滞或下降。 ↩︎

  95. Nix flakes（nix.dev 官方文档）；Nix 手册 flakes（nixos.org），访问于 2026-08-21。flakes 2021 年随 Nix 2.4 引入，至今 experimental；nix.dev 承认 flakes 存在根本性的架构问题与实现缺陷。 ↩︎

  96. RFC 49: Flakes（Nix RFC 仓库），访问于 2026-08-21。RFC 49 由 Eelco Dolstra 主导，在未被接受的情况下即合入主干，藏在 experimental 开关后面。 ↩︎

  97. Nix RFC 仓库，访问于 2026-08-21。RFC 136 确立增量稳定路线（先稳定 CLI，再动 flakes 本体），进展缓慢、无截止日期。 ↩︎

  98. nix-drama-explained（社区分析）；Determinate Systems，访问于 2026-08-21。Determinate Systems（Eelco 联合创办）持续营销"flakes 已经稳定"，社区对其商业动机保持警惕。 ↩︎

  99. NixCon 2023 赞助情况（NixOS Foundation 官方声明）；Save Nix Together 公开信；SC 选举结果公告；Moderation Team 辞职声明，访问于 2026-08-21。时间线各事件均按官方公告确认。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎

  100. The Nixpkgs core team has disbanded（NixOS 官方公告），2026-08-07，访问于 2026-08-21。core team 招募补员只收到 1 份申请，剩余两名成员 burnout 退出，公告批评 SC"缺乏宪法所设想的授权本能"；10 个月成绩含改革 committer 流程、新增 19 名 committer、GitHub Enterprise 赞助等。 ↩︎ ↩︎ ↩︎

  101. nixpkgs 仓库，访问于 2026-08-21。nixpkgs 收录 12 万以上软件包。 ↩︎

  102. Hacker News 讨论（Nix core team 解散），访问于 2026-08-21。评论原话："Nix 包管理器：正确解决了你整个操作系统的依赖地狱。Nix 治理：还没解决人类的依赖地狱。"（等级 C，仅作观点材料） ↩︎ ↩︎

  103. Universal Blue – Mission，访问于 2026-08-21。原文："We target the 96%, not the 4%"；"no BDFL-like structures"；"more like 'My expert linux friend set up my Fedora for me' than a fork or derivative"。 ↩︎

  104. Lix Wiki: Flakes feature freeze，访问于 2026-08-21。Lix 2025 年底宣布 flakes 进入 freeze 期，计划从核心抽离为默认随附的插件。 ↩︎

  105. Debian Policy Manual：Shared libraries，访问于 2026-08-24。Debian 使用 shlibs 或 symbols 文件提供共享库 ABI 依赖信息，构建时由 dpkg-shlibdeps 计算二进制包依赖；不向后兼容的 ABI 变化通常需要改变 SONAME，并重新构建使用该库的软件包。 ↩︎

  106. Britney2：A short introduction to migrations；Britney2：Solutions to common policy decisions，访问于 2026-08-24。britney 以不引入新的质量与可安装性回归为主要迁移原则，autopkgtest 结果可以阻止或延迟候选版本进入 Testing。 ↩︎

  107. Debian Wiki：Teams/ReleaseTeam/Transitions，访问于 2026-08-24。需要反向依赖重新构建或修改的 ABI/API 更新由 Release Team 作为 transition 跟踪；只需重新链接的软件包可通过 binNMU 重建。 ↩︎

  108. Official repositories（ArchWiki），访问于 2026-08-24。Arch 使用 testing 仓库测试即将进入稳定仓库的软件包；staging 用于需要协调重建的软件包，不面向一般用户。 ↩︎

  109. Gentoo Development Guide：Keywording concepts and policy，访问于 2026-08-24。稳定 keyword 表示软件版本和 ebuild 已经过广泛测试，在对应平台没有已知严重问题；~arch 表示仍需更多测试。 ↩︎

  110. Gentoo Development Guide：Slotting，访问于 2026-08-24。slot 允许同一软件的多个版本并存；依赖包可以在 sub-slot 变化时自动重新构建。 ↩︎

  111. Gentoo Wiki：preserve-libs，访问于 2026-08-24。preserve-libs 会保留被替换但仍有程序依赖的共享库，直到相关消费者完成重建或卸载。 ↩︎

  112. Updating, upgrading, snapshots and best practices（openSUSE 文档），访问于 2026-08-24。Tumbleweed snapshot 是一批经过 openQA 测试的更新，测试覆盖单个包及同一快照中更新之间的兼容性。 ↩︎

  113. Snapper and Btrfs（openSUSE 文档），访问于 2026-08-24。Tumbleweed 默认在根分区使用 Btrfs 并启用快照，可撤销 YaST、zypper 造成的系统变化或回滚整个系统。 ↩︎

最近更新:
贡献者: Rukkhadevata123
I use Gentoo BTW
Copyright © 2026 Yoimiya