从 Ubuntu Snap 争议到实用主义

Yoimiya2026/5/13大约 70 分钟

省流

本文写作的动机：第五、六、七节

本文想澄清或表达的观点：

事实: Ubuntu 六年来通过 apt 后安装脚本转到 Snap 的包只有 Firefox、Chromium、Thunderbird 三类，不是把全部软件包都变成 Snap。Firefox 和 Thunderbird 由 Mozilla 官方维护，是 Mozilla 和 Canonical 的合作结果，不是 Canonical 私自替换。
工程原因: Ubuntu（无论是否 LTS ）锁定软件大版本以保证服务器稳定性和仓库维护统一性，但浏览器需要持续滚动更新。Debian/RHEL 选择 Firefox ESR，Ubuntu 和 Mozilla 合作选择用 Snap 解耦——具体分析见后文。
Snap 与 Flatpak 各有用武之地: Flatpak 专注桌面 GUI，Wayland、主题、Portal 适配更好，桌面生态更广。Snap 覆盖 CLI（--classic 模式脱离沙箱）、后台服务（Docker、LXD）、系统组件（Ubuntu Core 不可变基础设施），并在 Nvidia 驱动直通和浏览器沙箱兼容性上有优势。两者不是替代关系，是不同场景的不同选择。
不足之处: apt install firefox 静默重定向打破了用户对包管理器的预期，apt remove 无法真正卸载 Snap 的 Firefox；Snap Store 后端闭源、国内无镜像、桌面端部分体验短板——这些都是真实问题，应该批评和改善。
实用主义: 操作系统是拿来干活的。新手需要开箱即用，不是毫无基础先折腾三天。Linux is free if your time is free——发行版的一些决策本质上是在帮用户节省时间成本。开箱即用和折腾不矛盾：低门槛吸引新人 → 友好社区中学习 → 成长为能帮别人的大佬，才是良性循环。
社区层面: Linux 桌面份额不到 5%，不能用纯桌面视角去审判全场景发行版的决策。站队拉踩只会让社区乌烟瘴气，新人望而却步。批评对准具体问题，不喜欢就换——这是 Linux 的自由和核心价值。
生态层面: Linux 桌面走不进大众，本质上是商业和市场问题，不是技术问题。服务器基因导致的"用户即管理员"预设，叠加市场份额小带来的"没人用 → 没人做 → 更没人用"死循环，靠再多发行版也打不破。能打破的是商业力量——Valve 为 Steam Deck 做到了，但只限于游戏。

在 Ubuntu 中运行 apt list | grep snap1 你会发现整个 Ubuntu 只有三类包是默认会重定向到 Snap 的（马上分析原因），即Firefox、Chromium、Thunderbird。其他七万个包，包括各种开发工具，gcc/python3/nginx/rustc 都是 deb 包。社区里争相跟风所谓的"整个 Ubuntu 都是 Snap"是一个不断情绪化放大的标签而不是事实。

时间线

第一个过渡包 Chromium（2019年10月）

Snap 本身的概念最早于 2014 年提出，2016 年随 Ubuntu 16.04 LTS 正式引入系统。但"通过 apt install 静默安装 Snap 版本"的这个过渡包机制，是从更晚的时间点才开始的。

第一个被改动的不是 Firefox，而是 Chromium。2019 年 10 月 10 日，Canonical 正式宣布 Ubuntu 19.10 中的 chromium-browser deb 包变为过渡包，安装时实际拉取 Snap 版本。直接原因非常具体：Chromium 算是一个常用软件，更新频繁、依赖关系复杂、安全补丁密度高的项目。在 Ubuntu 每个稳定版里对 Chromium 做向后移植，几乎要耗尽一个全职维护者的精力。Canonical 选择自己编译 Chromium 来制作 Snap 包（Chromium 不像 Firefox 有 Mozilla 这样的上游主动维护跨发行版的包），这样只需要维护一个通用版本，就可以同时推送到所有支持 Snap 的 Ubuntu 系统。

顺便看看 Debian Stable 是怎么做的：Chromium 的安全更新横跨 oldoldstable（120.x）、oldstable（143.x → 148.x）、stable（145.x → 148.x）到 unstable（148.x），四个分支的大版本更新移植全部由同一位维护者 Andres Salomon 承担，而 Canonical 可以把更多精力放在服务器基础设施等更重要的事情上。

最受关注的过渡包：Firefox（2022 年 4 月）

Firefox 的转换比 Chromium 晚了两年多。2021 年，Canonical 与 Mozilla 达成正式合作协议——这一转换实际上是由 Mozilla 主动推动的，不是 Canonical 的私自决策。Mozilla 希望绕过为每个 Ubuntu 版本单独维护 .deb 的延迟，直接向所有支持 snapd 的发行版推送安全补丁和新功能。在 Snap Store 中，Firefox snap 带有 Verified 标识，确认它由原始开发者（Mozilla）而非第三方直接发布和维护；Canonical 工程师的角色是与 Mozilla 协作优化 snap 在 Ubuntu 上的性能表现和沙箱隔离策略（这与 Flatpak 有所不同，下面分析）。从 Ubuntu 22.04 LTS 开始，新安装系统的用户默认获得 Snap 版 Firefox。也就是说，当用户在终端输入 apt install firefox 时，系统执行的不是安装 deb 包，而是安装由 Mozilla 官方维护的 Firefox Snap。这正是用户开始产生困惑和社区争议的节点，Ubuntu 上的 apt 预期行为被打破了。

Thunderbird 的转换逻辑与 Firefox 相同——同样是 Mozilla 官方维护的 Snap 包、同样是绕过发行版锁定版本的限制、同样是上游主动推动的合作结果，不再赘述。

用 apt install build-essential podman vim 等安装的包都是 deb，Ubuntu 仓库中依然是数万个传统 deb 包，并没有计划全面 Snap 化（桌面版也没有。Ubuntu Core 是面向 IoT 的独立产品，不在此列）。社区里所谓的"整个 Ubuntu 都是 Snap"是情绪化放大的标签，不是事实。

二、工程原因

服务器的理念

Ubuntu LTS（也包括current release）/Debian/Opensuse Leap/RHEL在服务器和关键基础设施上占据主导地位，本质上是锁定了每个软件稳定发行后的大版本，在发行版中这些软件的大版本是冻结的，以后的更新几乎都是回溯安全补丁或者小版本的更新，不引入行为变更，不破坏兼容性。企业可以把系统部署到生产环境，五到十年都不用操心系统安全更新会不会把服务搞崩。这是服务器的硬性要求，同样不是什么 Canonical 故意不更新版本强推 Snap Firefox。

这个可以提前说，Ubuntu 的目标是既作为服务器可以稳定部署的系统，又可以给新人降低门槛开箱即用，并体验到相对新软件的系统。Canonical 显然没有精力既维护服务器锁版本分支，又维护什么 Rolling 分支给桌面（而且对于普通或新人用户而言，稳定性也必须要保证，Rolling 也不太适合）。同一个 base 可以服务与大多数实用情况，如果真的有用户需要追新，也确实有 Arch 和 Fedora 可以选择。这差不多是 Canonical 要做到既要有要的最好结果了。

具体分析浏览器

浏览器是很常用的软件（有些不太常用的 GUI 软件确实也可能没精力维护而在 deb 仓库锁版本了，后面会再分析），Firefox 几乎每四周发行一个大版本，每个版本除了新特性外还有大量安全修复，而且 Mozilla 官方也不一定会支持旧版本（除ESR外）的错误修复，Chromium 差不多是一样的。开源社区精力有限。

Ubuntu 也面向桌面用户，Canonical 考虑用户可以用到最新版本的浏览器，那这就有一个矛盾，如果 Ubuntu 把这么常用的软件锁一个大版本，那 Canonical 就要自己回溯新浏览器的成千上万的补丁。要是不回溯，不说缺特性了，浏览器遇到安全问题找谁呢？Canonical 的人力也有限，看看 Debian 的情况，活跃贡献者从 2012 年的约 3270 人下降到 2025 年的约 1473 人，核心上传者不足千人，维护着超过七万个软件包。而且让 Canonical 把大量精力花在为占比不到 5% 的桌面用户回溯浏览器补丁上，直接意味着服务器领域的维护会受影响。

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

要是不断在仓库推送最新浏览器呢，那会破坏 Ubuntu 的理念。浏览器的依赖也必须同步滚动，一些共享库同步更新，很可能会破坏其他软件包的 ABI 兼容性，生产环境不可接受。要是问为什么不两种依赖都保留，那这也是徒增维护压力。

RHEL 和Debian Stable 选择的是 Firefox ESR，ESR 一年只发布一次大版本，中间只做安全修复，不引入新功能或行为变更。这对服务器来说是完美方案：维护负担小，系统稳定。

ESR 本身是合理的选择，只是目标用户不同。对桌面用户而言，代价是功能特性长期落后。Debian 上的 Firefox ESR 可能落后十个大版本，我体验到的就是 WebGPU 和编码器支持缺失。早在 2012 年，Ubuntu 开发者就指出过：如果因为浏览器版本太旧导致常用网站的新功能在 Ubuntu 上跑不了，对桌面用户来说是灾难性的体验。

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

可能会有用户说"我用 ESR 落后十个大版本照样看 Bilibili 啊"——落后十个版本也许确实还能用，但二十个呢？新的实用功能特性呢？新的 Web 标准带来的改进呢？发行版的决策不能只考虑某一个用户当下的感受，而是要为大多数用户在未来一段时间内的整体体验负责。你不需要某个新特性，不代表其他用户不需要；你现在感觉不到安全风险，不代表开发者不应该替你防住。

Canonical 最终选择的是和 Mozilla 合作，直接用 Snap 解耦了。Mozilla 官方维护Snap Store 的浏览器，打包和推送更新，Canonical 工程师优化 Snap 本身的性能和沙箱问题。Mozilla 省去了为每个 Ubuntu 版本单独维护 deb 的压力，一次打包就能推送到所有支持 snapd 的发行版。Canonical 不需要为每个 LTS 分支回溯浏览器补丁，可以把精力集中在更关键的基础设施——非上游 LTS 内核维护、安全更新、Ubuntu Pro 长期支持、云服务等——这些才是 Ubuntu 真正的基本盘。

有人会问：Mozilla 明明有官方 apt 源，直接加源装 deb 不就行了，就像 Fedora 那样会询问开不开 rpm fusion 源？而Ubuntu 不默认开启任何第三方软件源，包括 Mozilla 的 apt 源在内，原因还是稳定性承诺。任何非 Canonical 维护的外部源都可能引入不在发行版测试范围内的组件，增加依赖冲突和系统不稳定的风险。Mozilla 的核心精力在浏览器开发上，不会也无力保证其 apt 源在任何 Ubuntu 版本上不破坏系统。一旦用户因为第三方源导致系统崩溃，最终承担骂名的不是 Mozilla 而是 Ubuntu 自己。

Snap 在这种局面下是对双方都更安全的选择：Mozilla 只需维护一个沙箱隔离的 Snap 包，Canonical 不用担心第三方源引入系统级依赖冲突破坏稳定性，用户也拿到了不断更新的浏览器。

为什么不用 Flatpak？（详细分析见下一章）

除了 Canonical 不必要再增实体，还有一个技术层面的原因：Flatpak 的安全模型与浏览器的内置沙箱机制存在冲突，没有优雅的解法。具体分析放在下一章"为什么是 Snap 而不是 Flatpak"中展开。

浏览器之外

锁版本策略的影响不止于浏览器。对桌面用户常用的开发工具和效率软件，Ubuntu 官方源的版本经常落后上游。Neovim 在 Ubuntu 24.04 LTS 的官方源停留在 0.9.x，而最新稳定版已是 0.12.x 以上；PrismLauncher 在 Ubuntu 26.04 LTS 官方源锁在 10.0.5，Snap 版已更新到 11.x。类似情况也出现在 fish、fastfetch、ripgrep 等工具上。

这不能说明 Snap 是唯一出路。解决方案很多：PPA 能拿最新版但可能引入依赖冲突，Flatpak 和 Snap 沙箱隔离不破坏系统，Homebrew on Linux 专门适合命令行工具。用户应该根据自己的场景做选择——想要每个包都是最新版，滚动发行版本身就是合理选择。Ubuntu 做不到在所有维度上满足所有人，这也是多元生态存在的意义。

三、对比 Snap 与 Flatpak

社区对 Snap 的另一大批评是"重复造轮子"——Flatpak 已经存在且做得不错，Canonical 为什么还要另搞一套？这一章从技术细节出发，分析两者的实际差异。

针对浏览器，Flatpak 未必适合

现代浏览器内部有自己的一套安全沙箱机制，将不同标签页、渲染进程、插件互相隔离，防止恶意网页突破浏览器访问系统。这套沙箱依赖 Linux 的非特权 User Namespace——允许普通用户无需 root 就能创建临时的隔离环境来运行渲染器等子进程。这是浏览器安全模型的基础。

Flatpak 的安全模型（基于 Bubblewrap）默认禁用非特权 User Namespace，目的是限制容器内应用逃逸沙箱的能力，本身是合理的安全考量。但这和浏览器的内置沙箱机制产生了直接的、无法调和的冲突。

浏览器在 Flatpak 里只剩下两个选择：要么关掉自己的内置沙箱（削弱对网页攻击的防护，将安全完全外包给 Flatpak 的外层沙箱），要么依赖 zypak 这类非官方的 hack 手段绕过 Flatpak 的限制。两者都不优雅，且安全影响不明确。Flatpak 社区对这个问题是知情的，但目前为止没有公认的解决方案。2025 年 Linux Application Summit 上，Flatpak 核心开发者 Sebastian Wick 也坦言嵌套沙箱在 Flatpak 中"不工作"，相关 issue 存在已久但"没人知道怎么解决"，同时指出 Flatpak 项目的核心开发已处于停滞状态，大量 MR 长期无人 review。

Snap 在这条技术路径上做出了不同的取舍：它不是用一个统一的沙箱去管所有东西，而是通过 AppArmor 为每个 Snap 应用提供外层安全边界，同时允许浏览器在内部自由使用 User Namespace 来运行自己的成熟沙箱隔离。浏览器自身的多进程隔离、站点隔离等安全机制完全保留。这是 Canonical 和 Mozilla 在工程上专门协作的结果，也是 Canonical 选择 Snap 而非 Flatpak 来分发 Firefox 和 Chromium 的核心技术原因，和所谓"造轮子情结"或者"商业绑架"无关。

有人可能会说"我也体会不到有什么沙盒区别"——只能说浏览器和发行版的开发者在这件事上考虑得比你周到。另见上面的注释

下面分析各种情况下二者的对比

Nvidia 闭源驱动的处理差异

对于使用 Nvidia 显卡的桌面用户，图形驱动的处理方式是两者另一个明显的差异点。

Flatpak 的做法是：用户需要额外安装与宿主机版本严格匹配的 org.freedesktop.Platform.GL.nvidia runtime。这带来两个实际问题：系统上会存在两份 500MB 以上的 Nvidia 用户空间驱动（一份宿主系统的、一份 Flatpak runtime 里的）；宿主机驱动更新后，如果 Flatpak runtime 没有及时跟着更新，驱动版本不匹配就会导致软件黑屏或崩溃。

Snap 的做法不同：通过 gpu-2404 content interface，snapd 直接把宿主机的 Nvidia 用户态驱动库直通给 Snap 容器。可以实际验证这一点——lsof 命令能看到 Snap 应用在运行时直接读取了 /var/lib/snapd/hostfs/.../libnvidia-glcore.so.595.71.05，路径中的版本号就是宿主当前安装的驱动版本。实际测试中，宿主机驱动从 595.58 更新到 595.71，Snap 应用不需要做任何 refresh 操作就直接用上了新版驱动。

两种做法的取舍不同——Flatpak 的完全解耦模型在某些场景下更干净，但也引入了版本同步的维护心智成本；Snap 选择直通宿主驱动的方式更省心，更符合"开箱即用"的定位。

Flatpak 的强项：桌面 GUI 生态更好

Flatpak 是专门为桌面 GUI 应用设计的，在这个领域它比 Snap 做得更成熟：

桌面 GUI 应用生态更广：Flathub 上桌面应用的数量和更新活跃度远超 Snap Store 的桌面应用。对于纯 GUI 用户来说，Flatpak 往往是更好的选择
Wayland 原生支持更完善：Flatpak 应用通常能直接以原生 Wayland 运行；Snap 的 VSCode 至今仍只支持 XWayland
主题自动适配更流畅：Flatpak 对不同桌面环境的主题适配做得更好，gtk/qt 主题会自动识别并安装，Snap 除了gtk-common-themes 做的还不够好外还有网络问题可能连主题都下不动。
Portal 集成更成熟：文件选择器、屏幕截图、打印等桌面 Portal 功能，Flatpak 的支持更加完善
权限管理更直观：有 Flatseal 这样的图形化工具可以精细调整每个 Flatpak 应用的沙箱权限。Snap 的 snap connections 虽然也能做到，但操作不如 Flatseal 方便

Snap 的强项：CLI、后台服务、不可变基础设施

Snap 的定位比 Flatpak 更广，从一开始就不是只做桌面 GUI 打包：

--classic 模式对 CLI 和 IDE 友好：Classic snap 不设沙箱隔离，可以直接访问宿主机的 home、usr、编译器、Git、SSH Agent 等。JetBrains 全系 IDE 和 VSCode 都有厂商官方维护的 Snap 包，安装后体验等同于原生 deb。Flatpak 要做到同样的事，需要手动配置 flatpak-spawn --host、安装额外的 SDK Extension、逐个设置环境变量。连 Universal Blue（Bazzite 背后的团队）都明确不建议用户通过 Flatpak 安装 JetBrains IDE 和 VSCode——这些工具天生不适合沙箱
Snapcraft 上甚至有 Opencode 和 Claude Code，当然，也是经典模式发布的
Flatpak 对 CLI 的天然短板：Flatpak 的 CLI 应用启动命令长（flatpak run io.github.sxyazi.yazi），日常频繁调用不友好；沙箱限制导致访问宿主文件系统、系统调用都需要额外配置。这不在说 Flatpak 做得不好——而是它自己的文档也明确写明了定位："总的来说 Flatpak 最适合桌面应用。CLI 应用虽然也能跑，但在某些情况下可能并不合适"，并列举了无法运行 SUID 二进制（如 su、sudo）、不能访问宿主 /proc、seccomp 会拦截子命名空间的创建、不支持内核模块和驱动、无法导出 udev 规则和 systemd 服务等限制
后台服务和系统组件：Docker、LXD、MicroK8s 等后台服务都可以通过 Snap 打包和部署。Flatpak 不支持这类场景——它无法管理守护进程、不能定义 systemd 服务、不适合运行系统级组件

不可变基础设施与统一分发

跳出桌面看，Snap 在 Ubuntu 生态中的角色远不止"另一种桌面包管理器"。

全行业的基础设施领域正在汇聚到同一个方向：不可变系统、原子更新、自动回滚。Red Hat 推出了基于 OCI 容器镜像的 bootc（Image Mode），Fedora 有基于 rpm-ostree 的 Silverblue/Kinoite，SUSE 有 MicroOS（事务性更新）。Ubuntu 的对应方案是 Ubuntu Core——整个操作系统由独立的 Snap 组件构建，每个部分原子更新、出问题一键回滚。

这解释了为什么 Snap 要做沙箱隔离、只读挂载、独立依赖——这些被桌面用户吐槽"启动慢了点"的设计，在服务器和 IoT 场景里是实在的优势。snap install lxd 或者 snap install microk8s，依赖全打包、版本统一、回滚原子化，apt install 做不到这些。Snap 在 Ubuntu 生态里是一条全场景基础设施方案的载体。

Ubuntu LTS 的 Livepatch 服务是这套统一交付体系下的一个具体应用。RHEL 的 kpatch 和 SUSE 的 kGraft 功能上虽然一样能做内核热补丁——差异不在能否热更新，而在于 Snap 的组件化交付让 Canonical 可以用同一套机制同时覆盖服务器集群的管理（配合 Landscape 做灰度推送、隔离环境、统一分发）和个人用户的免费使用（Ubuntu Pro 提供免费 5 台设备）。

当然，Livepatch 只修内核高危漏洞，不能替代常规重启。如果你的机房混跑着多种发行版，还是需要 KernelCare Enterprise 这类跨发行版的第三方方案。

一览对比

	Snap	Flatpak
设计定位	全场景（GUI / CLI / 服务 / 系统组件）	桌面 GUI 应用
沙箱机制	AppArmor + 允许内部 User Namespace	Bubblewrap + 禁用嵌套 User Namespace
浏览器沙箱兼容	✅ 浏览器内置沙箱完整保留	❌ 内置沙箱削弱，依赖 zypak 等 hack
Nvidia 驱动	直通宿主用户态驱动，自动跟随更新	需额外安装匹配版 runtime，不同步会黑屏
CLI 支持	✅ 原生支持，`--classic` 模式免沙箱	❌ 启动命令长，沙箱阻力大，社区不鼓励 CLI 提交
IDE 支持	✅ 厂商官方维护，`--classic` 直接访问宿主编译器/Git/SSH	❌ 需手动配 `flatpak-spawn --host`、SDK Extension
后台服务	✅ LXD、Docker、MicroK8s 等	❌ 不支持守护进程和 systemd 服务
不可变基础设施	✅ Ubuntu Core	❌ 不在设计范围内
桌面 GUI 生态	❌ 较弱，桌面应用少于 Flathub	✅ 更强，Flathub 应用数量和活跃度领先
Wayland 支持	❌ 较弱，VSCode 仍走 XWayland	✅ 更完善
主题/Portal 适配	❌ 较弱	✅ 更流畅
权限管理	`snap connections` 命令行为主	✅ Flatseal 图形化工具，更直观
Store 后端	❌ 闭源，Canonical 控制	开源，Flathub 社区维护
国内网络	❌ 无镜像，靠 Cloudflare CDN 看运气	✅ 有中科大等镜像站可换源

总结：各有用武之地

Flatpak 和 Snap 不是互相替代的关系。Flatpak 专注桌面 GUI，在这个领域更成熟、生态更广。Snap 的覆盖面更全，从 CLI 到后台服务到系统组件再到不可变基础设施，并在 Nvidia 驱动直通和浏览器沙箱兼容性上解决了 Flatpak 模型中难以优雅处理的问题。

用户完全可以根据自己的需求混用：GUI 应用优先 Flatpak，IDE 和 CLI 工具可以选 Snap，后端服务用 Snap 部署——两者都有各自适合的场景。把任何一个贬为"垃圾"或者"多余的轮子"，都忽略了真实的工程差异和背后的场景多样性。

四、不足之处

前面分析了 Snap 的工程逻辑和技术定位，但这不代表 Snap 或 Canonical 的做法没有问题。以下问题是真实存在的，应该被批评和改善。

`apt` 静默重定向：破坏了用户对包管理器的预期

这是 Snap 争议中最核心、也最正当的批评。

apt 是 Debian/Ubuntu 生态的基石。用户在终端输入 apt install firefox，心理预期是安装一个 deb 包——这是十几年来的默认行为。但实际发生的事情是：系统静默地安装了 Snap 版本的 Firefox，整个过程没有任何提示告知用户"这不是 deb"。

更糟的是卸载行为的不一致。用户有需求，执行 apt remove firefox 想要卸载，但这个命令并不会真正移除 Firefox 的 Snap——因为 Snap 装在 snap 下而不是 apt 的追踪范围里。用户只会看到浏览器还好好地待在系统里，然后感到困惑，伤害了用户对系统的信任。

需要补充的是：Ubuntu 桌面版在安装完成后就已经自带了 Firefox 浏览器。对绝大多数新手用户来说，他们开机就能用，不需要碰命令行，底层是 deb 还是 snap 根本不重要——Firefox 图标在 Dock 上，点击就开。问题不出在"新手找不到浏览器"，而是出在当用户主动想管理自己的软件时，apt 的行为和预期完全脱节。

Canonical 在这件事上的实现方式和沟通都做得不好。更合理的做法是在 postinst 脚本中给出明确的 echo 提示，告诉用户"此命令实际安装的是 Mozilla 官方维护的 Snap 版本，如需传统 deb 包请使用其他方法"。技术上完全可行，但 Canonical 没有这么做。

Canonical 可能的考量是保持开箱即用——用户不应该在安装浏览器之后还需要再输入第二条命令来确认

Snap Store 后端闭源与中心化

另一个绕不开的争议是 Snap Store 本身。

snapd 客户端是开源的，但 Snap Store 的后端服务完全由 Canonical 控制，代码也不开放。对于习惯了传统 Linux 包管理去中心化模型的用户来说，这和一个由单一商业公司控制的 App Store 没有本质区别。用户无法自己搭建 Snap Store 的镜像服务器，无法审计后端做了什么，无法脱离 Canonical 的基础设施独立使用 Snap 生态。

中心化也并非全无好处——Canonical 对 Snap Store 上发布的软件有审核机制，从降低恶意软件风险的角度看，比任何人都能上传 PKGBUILD 的 AUR 更有保障

这种控制权集中引发的担忧是完全合理的。这是 Canonical 作为商业公司的决策，此处不替它辩护。需要指出的是 snapd 本身是开源的，社区在客户端层面仍有贡献和改进的空间——但 Store 后端的闭源确实是一个客观存在的限制。

桌面端体验短板

与专注于桌面 GUI 的 Flatpak 相比，Snap 在桌面端确实有实实在在的不足：

VSCode Snap 版至今只支持 XWayland，无法原生运行在 Wayland 下，输入法体验很糟糕。
非 Yaru 主题的适配不完善。虽然 gtk-common-themes 让大多数应用能自动适配，但第三方主题的支持仍不如 Flatpak 流畅。加上网络问题，有时候主题 snap 都下载不下来
部分 Intel Xe 核显的 VA-API 硬件解码存在问题
Firefox Snap 过去确实有很多问题：插件兼容性、中文输入法无法调用、冷启动速度、主题异常、密码管理器集成等都是实在问题。虽然如今已大幅改善，但早期体验给用户留下的负面印象是真实的

国内用户的实际困难

对国内用户来说，Snap 还有一个无法回避的痛点：网络。

Snap 的后端走 Cloudflare CDN，但 Canonical 没有启用中国大陆的节点。下载速度完全看运气——IPv6 偶尔能跑满千兆，更多时候龟速到令人崩溃。Flatpak 好歹可以通过中科大等镜像站换源，Snap 换不了源，只能硬扛。移动宽带用户尤其难受，开透明代理能缓解，但这就已经是门槛了。

如果 Canonical 能启用 Cloudflare CDN 的国内节点，这个问题就能大幅改善。但目前来看，这是一个长期存在的体验障碍。

五、实用主义——工具是拿来解决问题的

任何操作系统、任何软件，最终目的是帮人完成工作。这话说出来像是废话，但在 Linux 社区的很多争论里，这个基本前提经常被忘掉。本章主要分析 Ubuntu 系发行版的实用性。

基于 Ubuntu 的发行版，如 Linux Mint 大部分适用

服务器的地位毋庸置疑

Ubuntu 在云和服务器领域的市场份额不需要多说。直接查 AWS、Azure、GCP 上跑着的 Ubuntu 实例数量，没人会因为服务器用 Ubuntu 而质疑什么。服务器的需求很明确：稳定、安全、可预测、长期支持。Ubuntu LTS 在这个领域做得足够好，争议很少。

但 Ubuntu 不止做服务器。Canonical 的目标是用同一套 base 同时覆盖两类用户——这也是前面工程原因部分反复提到的"既要又要"。服务器端已经证明了这套逻辑可行，这里想多说桌面端。

桌面端的新手需要什么

一个刚从 Windows 或 macOS(?) 转过来的用户，第一次面对 Linux 时，他需要的到底是什么？

是开机就能用，装软件不报错，浏览器能打开网页，Steam 里的游戏能跑起来，系统小更新几乎不需要操心公告，是遇到问题去论坛问不会被嘲讽。

他不需要知道 deb 和 snap 的区别。不需要理解 User Namespace 是什么。不需要在装 Nvidia 驱动之前先去 Wiki 查清楚自己的显卡用哪个版本、要不要手动签 MOK。他甚至不需要知道什么是包管理器——应用商店里搜一下，点安装，就完事了。

Ubuntu 做了什么

Ubuntu 在这些基础的事上做了不少务实的工作：

桌面体验。Ubuntu 的 Gnome 是自定义了许多，除了优化性能，还预装了一些常用插件（且不会随着版本更新而失效，因为是统一开发的），预装了输入法（而且Ubuntu 的 Gnome桌面不需要 Kimpanel 插件就能用 fcitx5 输入法）等等。虽然我不在这里提 Gnome 和 KDE 开箱即用的区别，但针对 Ubuntu 的做法是可以说的
预编译 Nvidia 驱动模块。不用手动装，不用配 DKMS，直接在安装界面选中"安装第三方驱动"即可。命令行的话，虽然并不能保证新人查得到文档，但我这里也给出来，也是非常简单的，sudo ubuntu-drivers install，如果具体点就是类似于 sudo apt install linux-modules-nvidia-595-open-generic nvidia-driver-595-open，大部分用户不需要考虑用自定义内核，这种方法就够了。
硬件兼容性认证与 HWE 内核。Canonical 与 Dell、Lenovo、HP 等厂商合作，通过 Ubuntu Certified 项目在数百款设备上做兼容性测试，确保睡眠唤醒、指纹识别、Fn 快捷键等细节开箱即用。同时通过 Hardware Enablement（HWE）栈为 LTS 版本持续回溯新版内核和图形驱动——买新硬件不用等下一个大版本。（缓解了 Linux Mint 硬件适配问题）
Secure Boot 开箱即用。微软信任 Canonical 的签名，从 UEFI 到桌面一路顺畅，不需要手动注册 MOK 密钥。同样有预编译驱动的 Arch 和 openSUSE，用户还得自己签
从 26.04 开始新打包了 CUDA Toolkit。做 AI/ML 的用户装完系统就能开始干活
闭源编解码器。同样在安装过程可以选，命令行的话就是 ubuntu-restricted-addons 包
元包丰富。Ubuntu 相比于 Debian 打包了更多的元包，在桌面或各种环境下遇到依赖或功能缺失问题好解决，基本不需要背大量包名，如 kubuntu-desktop、ubuntu-standard等等
其他开箱体验的方方面面。可以自己体验一下，如预装的各种软件，稳定的自动更新，便捷的应用商店（通过自带的 snap 安装telegram-desktop、Steam）等等

很多极客鄙视应用商店，喜欢敲命令行。但对普通用户而言，一个干净、隔离、体验一致的发行版软件源（比如 Snap Store 或 Flatpak/Flathub）是巨大加分项。

正如 Elijah 在 LTT 播客中所感叹的，当他使用 Bazzite 内置的软件商店时，体验远超 Windows：没有烦人的 Edge 弹窗，没有强制的 OneDrive 订阅推销，也不需要每打开一个新应用就重新验证一次 2FA。不需要关心底层是不是沙盒，只要能安静、无感地获取软件并自动更新，这就是普通用户最想要的。这也侧面证明了，发行版如果能把软件分发（甚至是跨发型版的包管理）做到开箱即用，用户是绝对是买单的。

同样的逻辑也适用于 DM（Display Manager）。社区里有一种声音——"tty 登录然后 exec sway 就够了，DM 臃肿且多余"。但 DM 在 Wayland 时代的角色远不止一个登录画面：它在验证密码时通过 PAM 完成 session 注册、初始化D-Bus session bus、注入 XDG_SESSION_TYPE 等关键环境变量、自动解锁Keyring——这些是桌面组件正常协作的前提。KDE 用户确实可以从tty 直接 startplasma-wayland 启动，但这不代表 Plasma Login Manager 是多余的——KDE 社区投入资源开发它，恰恰因为一个图形化的、让 Windows 用户感到宾至如归的登录体验，是桌面操作系统不该省掉的体面。

GDM 被认为是 Display Manager 的黄金标准，参考 https://www.phoronix.com/news/KDE-New-Login-Manager-Over-SDDM

这些不是什么高深的技术创新。它们就是把别人需要折腾的事情提前做掉了，让用户不用操心。你说它替你做了选择，就是产品化的意义。下载 Ubuntu ISO、走完安装向导、重启，就能看到一个能用的桌面。听起来简单，但在 Linux 世界做到这一点并不容易（但是，见附录一）。

有人确实不喜欢别人替他们做主，YMMV，有 archlinux 等选择

这是 Ubuntu Server 的文档，质量挺高，包括上面的 Nvidia 驱动安装指南 https://ubuntu.com/server/docs/

可惜到了 26.04 还有人跟着 CSDN 的过时教程手动装 CUDA，然后说"Linux 用 Nvidia 好麻烦"。

Fedora 需要额外的源才能装闭源编解码器和树外驱动，之后说的 Universal Blue更省心

LTT 视频里的反面教材

尽管大部分情况下这些发行版开箱即用，但并不能保证所有硬件都能很好工作，更全面的兼容性也是 Linux 桌面领域需要解决的问题

Linus Tech Tips 的 2026 Linux 挑战视频是一个很好的观察窗口。Linus 只是想剪视频、打游戏、看网页——这是普通用户的日常需求。他们在挑战中遇到的具体问题包括：

Pop OS 的 Cosmic 桌面：Pop OS 下载页面标着 LTS，但 Cosmic 桌面环境实际上处于公开 beta 阶段。一个新手根本不可能知道要先问"这个桌面环境是不是 beta"。装完之后各种不稳定。
Bazzite 上的 DaVinci Resolve：Bazzite 是不可变系统（基于 Fedora Atomic，和 Universal Blue 同族），核心系统文件只读。Linus 像装 Windows 软件一样下载 Resolve 直接运行，结果当然不行——不可变系统不允许安装程序随意修改系统文件。最终靠一个 6 分钟的视频教程才找到正确的安装命令。装上之后又遇到 H.264/H.265 视频编解码器缺失的问题，部分文件无法播放或导出。（事实上 ublue 应该是自带这些编解码器的，这里就不知道为什么了）
Kubuntu 安装后黑屏：装完 Kubuntu 第一天就黑屏了几个小时，第二天早上才莫名恢复正常。（特定硬件问题）
NTFS 游戏盘配合 Proton：把 Windows 下用的 NTFS 格式游戏盘直接挂到 Linux 的 Steam 库里用，部分游戏 glitches 或打不开。Proton 对 NTFS 的兼容性仍然不够好。（Linux 原生 NTFS 驱动在 7.1 版本可用）
OBS 屏幕捕获：在 Kubuntu 上装 OBS 录屏，发现 deb 版本无法选择要录制的显示器。解决方案是换 Flatpak 版，但 KWin 的隐私设置又阻止了屏幕捕获，论坛里有五种不同的解决方法，不知道哪个才有效。（可能是特定硬件或桌面，我这里的 Ubuntu 26.04 LTS 是正常的）

除此之外，他们在日常交互中也频频遇到“非标准逻辑”的摩擦。例如 Linus 提到，Linux 的搜索逻辑有时“为了和 Windows 不同而不同”：当他在搜索框输入“sleep”想要调整睡眠设置并习惯性按下回车时，系统却直接休眠了。

Luke 则点出了 Linux 桌面排错的终极困境：身份边界的模糊。当他在 Windows 上游戏崩溃时，他知道这是游戏的问题；但在 Linux 的 Proton 兼容层上遇到报错时，他往往陷入迷茫：“我根本不知道这个错误是因为我在用 Linux，还是游戏本身就有 Bug？”这种不确定性，极大地增加了普通用户的心理负担。

Linus 在视频里说了一句很实在的话："普通人不想把修操作系统当爱好。"

遇到问题，极客会觉得有意思、有挑战、能学到东西。但普通用户只会觉得挫败——"我明明什么都没干，为什么就是不行？"然后回到 Windows，然后告诉其他朋友"Linux 太难用了别试"。

这是 Linux 桌面一直走不出小众圈子的核心原因之一。

"Linux is free if your time has no value/if your time is free"

这句话在技术社区里流传已久，最早可以追溯到 Jamie Zawinski。字面意思是"Linux 是免费的——如果你的时间也是免费的话"。

开源软件不收钱，但配置、维护、排错需要投入实实在在的时间。对于喜欢折腾的人，这种投入是乐趣——他们享受理解系统、定制环境、解决问题的过程。这完全没有问题，这也是 Linux 社区活力的重要来源。但对于只想用电脑干活的人，这种投入就是门槛。如果装个浏览器都要先学会配源、解依赖、查 Wiki、在论坛里翻五条不同的答案然后逐个试，那这个"免费"的代价就是劝退。

商业发行版那些决策，有些甚至引起（精英主义技术社区）争议的，可用说本质上就是在帮用户节省这部分时间成本。

这不是"背叛开源精神"。这是让更多人用上 Linux 的务实方式。

开箱即用和折腾不矛盾

这里必须说清楚：我从来没有否定折腾的价值。我自己也折腾过 Gentoo、配过 Hyprland、编译过内核。折腾本身是好玩的，是学习 Linux 的最佳途径之一。

关键在于——折腾应该是可选的，不是必须的。

一个健康的 Linux 桌面生态应该是这样的：新人被低门槛吸引进来 → 系统开箱就能用 → 在友好的社区氛围里慢慢了解 Linux 的工作方式 → 有兴趣有时间就去深入折腾 → 变成能帮别人的老手。这才是良性循环。

反过来，新人一来就被依赖冲突、驱动黑屏、论坛嘲讽这"三板斧"打中，直接回到 Windows——除了应有的门槛外，这种氛围也是让新人望而却步。

推荐 Arch 给想深入学习的人完全没问题，Arch 是好发行版。但如果新人只是问怎么装浏览器，你回一句"Ubuntu 垃圾，来装 Arch"——这就不是在帮人了。关于社区里这种站队拉踩的风气，下一章会展开说。

目前开箱即用做得最好的发行版系列，我个人体感是 Universal Blue 系和 Ubuntu 系。但放到"同一套工具链同时覆盖服务器和桌面"的维度上，只有 Ubuntu 系列能做到。Ubuntu Pro 个人免费 5 台设备，服务器和桌面用同一套 base，Current Release 最旧的包也落后不到半年（真这么旧差不多也可以更新到新 release 了）——这是 Canonical"既要又要"策略的切实成果。

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

LTT 遇到的问题有一部分和特定的硬件组合有关（比如某些 Nvidia 配置下的黑屏），也有一部分是 Linux 桌面生态长期存在的真实短板（比如视频编解码器授权、NTFS 兼容性、软件分发方式混乱）。开箱即用不是"100% 不出问题"，而是"大多数情况下不需要折腾"。LTT 的遭遇恰恰说明 Linux 桌面在兼容性和用户体验一致性上还有很长的路要走——但这不妨碍一些发行版在"降低折腾概率"这件事上已经比大多数发行版做得好。承认问题的存在，和认可已有的进步，两者不矛盾。

六、社区氛围——多元共存，不拉踩

以下讨论不针对整个社区，仅针对那些让新人望而却步的具体行为。

不能用桌面视角审判一切

Linux 桌面市场份额长期不到 5%。先承认一个基本事实：Snap 的静默重定向只影响桌面软件包——Firefox、Chromium、Thunderbird——服务器用户不受影响。桌面用户是这个决策唯一被改变体验的群体，他们因此发声，这本身完全合理，不是"声音太大"的问题。问题在于这些声音中的一部分走向了另一个方向：不是批评静默操作本身（那完全正当，第四章已经展开），而是将其放大为"整个 Ubuntu 都变成了 Snap"、"Canonical 要消灭 deb"、"Ubuntu 用 Snap 打包音频服务"等与事实不符的标签。这些以讹传讹在社区中被反复转发，形成了远超其合理性的声量——而真正有建设性的具体批评（冷启动慢、国内无镜像、Wayland 适配差）反而被淹没在站队中。本文反对的是后者，不是前者。

前面提到过，Ubuntu 的大部分实例跑在云服务器、边缘设备、IoT 环境里。对服务器管理员来说，浏览器版本新不新不重要，系统能不能原子更新、能不能在生产环境里稳定跑五年才是关键。对物联网工程师来说，沙箱隔离、依赖自包含、失败可回滚这些设计是安全底线，不是"启动慢了点"的体验问题。

桌面体验很重要——日益完善的桌面体验正是吸引新用户的关键。前面一整章都在说这个。但不能只从桌面出发，把所有不符合自己使用习惯的东西都定性为"愚蠢"或者"邪恶"。理解不了发行版维护者面对的约束条件没关系——不是每个人都有义务去研究这些。但如果不了解这些约束，还要坚持用"我就是用户"的身份去否定每一个自己没见过的决策，这种批评本身就失去了基础。

批评要对准具体问题

社区里有时候能看到这样的毫无上下文的发言："xx 就是垃圾"。

这类发言的背后除了站队心态，还有一种自利归因的心理倾向——系统出了问题，还没排查出来，先找个最显眼的靶子（又如Microsoft）来承担全部责任比承认"可能是我自己的环境有问题"要舒服得多。但这不是正常的讨论，对解决问题没有任何帮助。什么硬件或者硬件加速存在问题？什么软件的 Wayland 和输入法配置不好？把问题说清楚，该提 issue 提 issue，该在论坛里讨论就讨论。具体的问题可以定位、可以修复、可以改善。但"xx 是垃圾"这种话除了制造对立之外没有任何作用。

反过来也一样。如果有人对某个技术有具体的批评，不应该用"你不懂架构"或者"你行你上"去堵嘴。普通用户有批评和表达不满的权利，没有写代码的义务。用户不喜欢一个东西，直接换掉，本身就是对生态的反馈。把用户的合理不满归结为"你不愿意学习"，既傲慢也无助于改进。

Canonical 犯过错，也认过错

社区对 Canonical 的不信任不是完全没有来由。回顾历史，Mir 显示服务器在 Wayland 成为行业共识后退场，Upstart 初始化系统在 systemd 胜出后放弃，Unity 桌面环境最终让位于 GNOME。这些尝试在当时确实造成了分裂和困惑，社区的不信任由此积累。

这也说明 Canonical 不是那种一条路走到黑的公司。它试过、争过、输了之后也认了。Mir 的技术积累后来转向了为 Wayland 合成器提供底层支持，Unity 的设计遗产在 Ubuntu 的 GNOME 定制中延续。Google 关掉的产品不比谁少，Microsoft 推过的 Windows Phone、Zune、WSA 也早就进了历史，RedHat 对 CentOS 的决策也引起不小争议。拿十几年前的 Mir 和 Unity 来否定今天 Canonical 做的每一件事，对推动改进没有任何帮助。

批评应该对准今天的具体问题和具体做法，不是对着公司名字做条件反射。

别把 Linux 当社交货币

"我用的是 Arch btw"——这句话本身没什么。喜欢自己的发行版、为自己折腾出来的系统感到骄傲，都是正常的。讨厌的是那种"你用的不是 Arch 所以你不行"、"想不到 Snap 这种破玩意有什么用"的居高临下。

前面 LTT 的视频提到过，新人去论坛求助，收到的不是解决方案而是对他选择的发行版的嘲讽。这种敌意是 Linux 社区最不该有的东西。一个人在别人的平台上来这么一句，后面可能就有一群人跟风复读同样的话。新人看到这种氛围不会觉得"我要努力学"，只会觉得自己进错了地方，然后默默回到 Win/MacOS。

在 LTT 2026 年的 Linux 挑战总结视频中，Elijah 讲了一个非常典型的案例：他抱怨由于内核级反作弊，新游戏 Marathon 无法在 Linux 上运行。结果收到的不是同情或解决方案，而是社区的指责——许多人告诉他"你本来就不该玩这个游戏"，甚至私信攻击他是为了"故意抹黑 Linux"。

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

这种以"保卫 Linux"为名攻击用户的部落主义，恰恰是把新人推走的罪魁祸首。如果连想玩一个小众游戏都会被扣上"仇恨 Linux"的帽子，那普通人为什么要留在这里？

不喜欢就换，换了也没必要踩

Linux 最核心的价值之一是选择权，无论是发行版还是包管理器之间，用脚投票本身就是对生态最直接的反馈。

但换了之后，没有必要无脑丢一句"xxx 太烂了"或者"xxx 太难用了"。你遇到的问题可能是特定的硬件组合、特定的配置冲突，换一个发行版可能也会遇到。脱离使用场景和需求去断言一个工具"好不好用"——无论是发行版、包管理器还是桌面环境——本身就是一个不成立的命题：螺丝刀不能钉钉子，不是螺丝刀的错。把具体的问题描述出来，别人能参考、能帮上忙，社区能变好。一句没头没尾的差评，除了让讨论区变得更乌烟瘴气之外没有其他效果。

一个健康的社区，应该能同时容纳批评和理解——批评具体实现中的不足，理解工程约束下的取舍，尊重不同人、不同场景的不同选择。没人会因为站队拉踩而留下来，但很多人会因为善意的帮助和开放的氛围而留下。

七、生态层面——为什么 Linux 桌面仍然走不进大众

前六章的讨论和之后三个附录，分别从技术、体验和发行版选择的角度做了分析。这一章尝试回答一个更深层的问题：为什么 Linux 桌面在 2026 年仍然无法真正走入大众？

在进入分析之前，必须先把一个前提说清楚：Linux 桌面从 0 做到 4%，本身是开源社区和商业公司共同努力的巨大成就。 九十年代末，在桌面跑 Linux 还是一项需要极大勇气的行为——没有图形化安装程序、没有即插即用的硬件支持、没有像样的中文输入法。今天能坐在这里讨论"为什么只有 4%"，恰恰说明过去二十多年无数志愿者和受薪开发者做了海量的工作。从 GNOME 和 KDE 的持续迭代，到 Ubuntu 把安装流程简化到"下一步 → 下一步 → 完成"，到 Valve 用 Proton 让几千款 Windows 游戏能在 Linux 上运行——这些都不是天上掉下来的。Linux 桌面今天的可用性，是社区和商业力量共同堆出来的。

但成就归成就，追问也同样是必要的：为什么到了 4%，再往上走就变得极其困难？ 这才是这一章想探讨的问题。肯定已有的成绩和分析增长的瓶颈，两者不矛盾。

核心困境：Linux 的基因是服务器，不是桌面

Linux 在服务器和云基础设施领域是绝对的主导者。但服务器领域的成功，恰恰是桌面领域困境的根源——这既不是社区的错，也不是商业公司的错，而是一个历史路径依赖问题。Linux 从服务器起家，它的设计哲学天然服务于此，桌面的需求本质上是在"逆天改命"，而社区和商业公司已经在这条路上走了很远。

服务器和桌面对操作系统的要求（SLA）有本质区别：

	服务器	桌面
用户身份	专业系统管理员	普通消费者
更新策略	稳定 > 新功能，锁大版本	自动无感，不能破坏体验
软件分发	包管理器统一管理	应用商店、下载即用
硬件	标准化服务器硬件	成千上万种消费级组合
排错方式	日志、监控、SRE 团队	重启、搜索、找客服
出了问题	这是管理员的工作	这是厂商的问题（也不绝对）

Linux 的整个设计哲学——用户是系统管理员——在服务器上是完全正确的。你雇一个运维团队来管理服务器，他们需要的就是这种完全的控制权、清晰的日志、可预测的更新周期。

但这个模型原封不动搬到桌面上，就变成了前文反复提到的"三板斧"困境。Linux 桌面社区几十年来一直在往"消费级体验"的方向努力，而且取得了切实的进步——从 0 到 4% 就是证据。 但桌面操作系统需要的系统性工程——硬件兼容性认证、统一的 QA 测试、消费级软件分发渠道、面向普通用户的客服体系——这些超出纯志愿者模式承载上限的事情，才是真正的瓶颈所在。这不是谁的错——这是历史路径依赖，也是资源配置的现实。

生态死循环：没人用 → 没人做 → 更没人用

这是 Linux 桌面面临的最根本的结构性问题，比任何技术缺陷都更难打破。Linux 桌面市场份额长期在 3%–4% 左右徘徊（桌面端整体不到 5%，去掉 ChromeOS 后更低）。

需要强调的是，这个死循环描述的是"纯靠志愿者、缺乏商业力量介入"的场景下，增长的自然天花板——不是在否定社区已有的贡献，而是在说明为什么社区的努力到了一定程度后会撞上一堵需要另一种力量才能推倒的墙：

每一步都在加固下一步：

硬件厂商不做驱动。Nvidia 虽然提供 Linux 驱动，但控制面板功能远不如 Windows 版完整。外设厂商更是大面积缺席——游戏鼠标的宏配置软件、打印机的扫描驱动、网银 U 盾的安全控件，绝大多数没有 Linux 版。厂商的逻辑非常简单，也很冷酷："不到 5% 的用户，不值得专门投入。"
软件厂商不做客户端。Adobe 全家桶、Microsoft Office、Autodesk 系列、国内的企业办公软件、税务申报软件——用户需要这些来干活，但它们几乎没有 Linux 版。Wine/Proton 能跑一部分，但兼容性没有保证，出了问题用户自己判断是谁的锅（前文 Luke 的困境）。反过来也要看到，在商业软件缺席的领域，开源社区自己填补了大量空白——Blender 在 3D 创作领域的地位、Krita 在数字绘画上的能力、Kdenlive 和 OBS 在视频制作上的可用性，都是社区贡献者一砖一瓦垒出来的。但有些专业领域（如 Adobe 系、Autodesk 系、国内企业办公和税务软件）的替代品生态尚未成熟，这并非开源社区"不努力"，而是这些领域的替代需要时间积累，且面对的是商业软件的护城河。
用户因此离开。一个人试了 Linux，发现打不开工作需要的软件，或者新买的外设不工作，自然会回到 Windows。他没有义务留下来——操作系统是工具，不是信仰。这不是用户的错，也不应该被指责。
份额难以持续扩大 → 厂商更没有投入动力。循环闭合。

关键在于：要打破这个循环，靠"再多做一个发行版"或者"优化包管理器"是不够的。 开源社区的力量在从 0 做到 4% 的过程中发挥了不可替代的作用，但继续往上走，面对的是硬件厂商的商业决策、软件厂商的市场评估、以及普通用户对"出了问题找谁"的预期——这些都是商业和市场层面的问题，不是技术问题，也不是"志愿者更努力一点"就能解决的。

"为爱发电"的天然局限——为什么纯社区模式推不动桌面到下一个量级

承认生态死循环是商业问题之后，一个自然的追问是：既然社区有这么多人，为什么不能靠自己打破这个循环？ 答案必须先做两个限定：第一，社区已经做到了惊人的事情——没有志愿者的付出，Linux 桌面根本就不存在，更不用说 4%；第二，这里讨论的是进一步走向大众市场（比如 10%+） 所需要的条件，这和"维持并稳步改进现有水平"是两回事。

在走向大众这件事上，志愿者模式与桌面操作系统所需的系统性工程之间存在根本性的错配——不能说是志愿者的"失败"，而是系统性工程本身的客观要求。

关键人物依赖：一个人离开，项目就可能停摆

社区项目往往依赖少数核心维护者，这种模式极其脆弱。Ubuntu Unity 的维护者曾是一名青少年，因大学考试无法投入时间，项目一度面临生存危机。Ubuntu MATE 创始人 Martin Wimpress 在 2026 年 3 月宣布因失去热情而希望移交项目。Linux XFS 文件系统的社区维护者也公开表示"精疲力竭"，并警示自己不想在 2030 年还处于这种状态。

这不是个例，是志愿者模式的系统性风险——依赖少数人的热情和业余时间，项目抗风险能力极低。 需要强调的是，这些维护者已经付出了远超常人的努力，没有人有资格指责他们"不够坚持"——问题是这种依赖本身不可持续，而不是人的问题。

只有程序员，没有产品经理

桌面操作系统不仅是技术的堆砌，更是设计、体验和管理的集合。社区最不缺程序员，最缺 UI/UX 设计师、无障碍专家、图形设计师、市场人员。深度科技（deepin）的王勇曾指出："桌面要集合设计、用户心理研究、产品细节……而 Linux 社区只有技术架构。"结果是 Linux 桌面在技术上强大，在体验上常常不够直观——"会写代码"不等于"能做好产品"。不批评程序员——程序员在自己的领域已经做得够多了——而是说一个消费级桌面操作系统所需要的技能组合，单纯靠志愿者贡献很难凑齐。

碎片化：23+ 种桌面环境，力量分散

Linux 桌面的多样性是优势，但也带来了严重的内耗。目前存在超过 23 种风格类似的桌面环境，开发者倾向于创建新项目而非合力改进现有项目。碎片化也增加了应用的适配成本——开发者需要为不同的发行版、包格式、显示服务器（X11/Wayland）逐一适配，资源被重复消耗。

这是开源自由的双刃剑：每个人都有权按照自己的想法做东西，这种自由本身就是 Linux 最宝贵的资产，也很难也不应该被消解。但在讨论"大众化"这个具体目标时，碎片化确实意味着力量的分散。

资金困境：顶级项目也在亏钱

金钱不是万能的，但没钱是万万不能的。KDE 在 2022 年和 2023 年分别亏损了约 9.9 万欧元和 10.7 万欧元。GNOME 同样面临"连续赤字"的困境。即使是这些最顶级的开源桌面项目，也常年挣扎在财务边缘。

对比之下，Linux 内核的成功恰恰证明了商业支持不可或缺——超过 80% 的 Linux 内核代码由受薪开发者贡献，纯粹无偿志愿者贡献的代码占比可能低至 8%。这不是道德问题，而是复杂软件工程天然需要稳定、持续的投入。内核如此，桌面亦然。

用户增长 ≠ 贡献者增长

一个常见的乐观假设是"用户多了，贡献者自然就多"，但来自 openSUSE 社区的数据表明：他们的贡献者数量最多的时候，反而是用户最少的时候；用户增长期反而伴随着贡献者数量的停滞或下降。用户和贡献者之间并非简单的正比关系。这不是"用户不感恩"——大多数用户只是想来用电脑，他们本来就没有贡献的义务。把用户转化成贡献者需要社区建设、mentorship 和良好的新人体验，而这些本身就是需要资源投入的事情。

维护工作的隐形负担

志愿者的工作远不止写代码。上下游责任推诿（上游开发者与下游发行版维护者之间的扯皮）、处理海量无效反馈（用户越过发行版直接向上游报告已修复或重复的问题）、维护工作不被重视（社区更看重"写新代码"，而测试、Bug triage、文档编写等脏活累活少人问津）——这些隐形负担持续消耗着志愿者的精力。能坚持做这些工作的人，已经值得最大的尊重。

服务器基因在桌面上的三个具体表现

除了生态死循环和社区自身的结构性局限，Linux 服务器的基因在桌面体验上留下了三个根深蒂固的印记。这些不是"设计错误"，而是服务器场景的优势在桌面场景中变成的摩擦点——社区一直在努力消解这些摩擦，但它们的根源在底层架构中。

1. 更新即责任

在 Windows/macOS/Android 上，系统更新在后台默默下载，重启时自动应用，用户不需要知道"这次更新改了什么"。普通人根本不读 changelog，也不想读。

Linux 桌面做不到这一点，不是因为技术实现不了——不可变发行版的原子更新机制在工程上已经很成熟——而是因为 Linux 生态的组件来自几百个独立上游。内核、驱动、显示服务器、桌面环境、音频系统、包管理器、沙箱运行时……每个组件的更新节奏由不同团队决定，没有一家公司能像微软或苹果那样对整个栈做集成测试和统一推送。

自动更新 + 自动回滚是目前最接近的解法，但它仍然不能消除一个根本问题：更新后某个硬件不工作了、某个软件行为变了，用户还是得自己判断问题出在哪、去哪个上游报 bug。普通人不具备这种判断力，也没有义务具备。

2. 排错即孤岛

如正文第五章所述，Luke 在 LTT 挑战中指出：在 Windows 上游戏崩溃，他知道这是游戏的问题；但在 Linux 的 Proton 兼容层上报错，他根本不知道该归因于 Linux、Proton、还是游戏本身。

Linux 桌面排错的终极困境是责任归属的缺失。一个普通 Windows 用户遇到问题，很可能重启就能解决；解决不了，硬件问题找 OEM 售后，软件问题基本上更容易在网上找到解答。Linux 用户的排错链是立体的：问题可能在内核、在驱动、在显示服务器、在桌面环境、在包管理器、在沙箱运行时、在三个月前随手敲的一条命令……没有兜底，每一步都需要管理员级别的判断力。极客觉得这是有趣的挑战，普通人只会觉得挫败然后离开。

这不是技术问题——Windows 也不是 bug free。区别在于 Windows 用户要么更容易找到解决方案要么有其他兜底，Linux 桌面用户只有自己。而这恰恰是商业公司可以填补的空白：Ubuntu Pro 的付费支持、Red Hat 的企业级服务，都试图提供这种兜底——只是它们面向的不是普通桌面消费者。

3. 软件分发的选择

在 Windows/macOS 上装软件：下载 → 双击 → 装完。软件从哪来、怎么打包的、依赖是什么——用户不需要知道。

在 Linux 上装软件：你需要根据具体发行版选择合理的格式。deb？版本可能很旧。Snap？沙箱隔离好但国内没镜像。Flatpak？GUI 应用首选但有些工具不适合。AppImage？免安装但不自动更新。AUR？什么都有但要自己审计 PKGBUILD，警惕投毒。直接编译？最自由也最折腾。

普通人不应该需要理解六种包格式的区别才能装一个软件。 SteamOS 在 SteamDeck 上之所以体验好，恰恰是因为 Valve 替你锁死了选择——你只能通过 Steam 和 Discover（Flatpak）装软件。减少选择本身就是降低管理员心智负担的手段。但这个策略在通用桌面上很难照搬，因为不同用户需要不同来源的软件，Flathub/Flatpak 现在还没解决所有问题。

这也解释了正文的观点：Flatpak 和 Snap 的共存不是"分裂"，是不同场景需要不同工具。但这种多样性带来的认知负担，对普通用户来说确实是客观存在的。社区提供的丰富选项本身是好事——问题在于对于"不想做选择"的普通用户而言，这种丰富性反而成了门槛。

SteamOS：打破死循环的 proof of concept——也是 proof of limitation

Universal Blue 这些也算在朝这个方向走

安卓已经 PoC 了

Steam Deck 是目前最接近「Linux 家电」的产品。不可变系统、原子更新、用户只能通过 Steam 和 Discover 装软件、游戏模式无缝切换。买来就能玩，不需要知道底层是 Arch Linux。

Steam Deck 之所以能打破死循环，靠的不是技术，是商业力量：Valve 投入了足够的钱和人力来保证 Proton 兼容性、和 AMD 合作优化驱动、自己维护整个系统栈。用户不需要操心——因为 Valve 替你操心了。这和正文反复说的"Ubuntu 替你做了选择"是同一个逻辑，只是 Valve 做得更激进：它直接替你锁死了选择。

但它成功的代价是放弃了通用计算。Steam Deck 是一台游戏机，不是一台电脑。你不在上面写代码、不接打印机、不用网银 U 盾、不参加腾讯会议。把同样的模型搬到通用桌面——让用户既能「什么都不懂」又能「什么都能干」——这个矛盾目前没有任何发行版真正解决。

SteamOS 证明了 Linux 可以做成家电。但它没有证明 Linux 桌面可以做成家电。

有时间讨论 Steam Machine

这不是 Linux 的失败——但需要认清问题的性质

说 Linux 桌面走不进大众，不等于说 Linux 桌面做得不好。恰恰相反——正文花了大量篇幅论证 Canonical 和社区在「降低折腾概率」这件事上已经做了很多务实的工作。预编译 Nvidia 驱动、Secure Boot 开箱即用、硬件兼容性认证、不可变发行版的原子更新——这些都在正确的方向上。Linux 桌面从 0 到 4%，是无数志愿者和受薪开发者二十多年持续努力的成果，这是实实在在的成就，不应该被任何讨论忽视。

但必须承认：Linux 桌面继续走向大众面临的问题，本质上是商业和市场问题，不是技术问题。 再多一个包管理器、再多一个 Wayland 合成器、再多一个桌面环境，都不会改变硬件厂商不写驱动、软件厂商不做客户端、用户出了问题找不到客服的局面。这些不是开源社区"不够努力"——社区在自己的能力边界内已经做到了极致——而是剩下的问题需要不同的力量来推动。KDE 的 2024 年度目标写得很克制——"在不大幅扩张的情况下保持现有的活动水平"——这恰恰反映了社区驱动模式下资源的天花板，而不是能力的上限。

打破生态死循环需要的不是更好的技术，是更大的商业投入——一个或者几个公司有足够强的动机，像 Valve 为 Steam Deck 做的那样，把整个栈的集成和体验统一担起来。在那之前，Linux 桌面会一直是"能用，但不省心"的状态——对愿意折腾的人来说足够好，对普通用户来说不够好。这并不是社区的失败，而是这个目标本身的体量决定了它需要超出志愿者模式承载上限的资源投入。社区已经把 Linux 桌面推到了 4%——剩下的路，需要商业力量来接棒，或者社区与商业力量协作推进。

这也是为什么正文的核心观点是多元共存：不同发行版为不同人群服务。想当管理员的人有 Arch 和 Gentoo，不想当管理员的人有 Ubuntu 和 Universal Blue，想玩游戏的人有 Bazzite 和 SteamOS。没有一个版本能让所有人都满意——但这恰恰是 Linux 生态的价值。

选择适合你当下场景的发行版，开始干活。不喜欢就换——这是 Linux 给你的自由，也是它最值得珍惜的东西。

附录一：Arch 系与 Ubuntu 的"开箱即用"有何不同

我们都知道 EndeavourOS、CachyOS 这些 Arch 系的发行版也有 GUI 安装器，也预装了桌面环境。那它们和 Ubuntu 的"开箱即用"区别在哪？

两者的"开箱即用"不在一个层面。

EndeavourOS / CachyOS 降低了安装门槛。你不用对着 Wiki 敲 pacstrap，装完就能看到桌面，常用工具也预配好了，CachyOS 甚至带了优化过的内核。它们把 Arch 的入口变得友好。

Ubuntu 降低的是长期维护的心理负担。不只安装那半小时的事，还有接下来用一年、用三年的体验差异。

Arch 的设计哲学本身就不是面向新手的。Arch 的 KISS（Keep It Simple, Stupid）原则指的是对懂系统的人简单，不是对所有人简单：

滚动更新需要你关注 Arch News。上游某个包改了配置格式、换了依赖、需要手动干预，你没看到公告直接 yay -Syu，炸了是你自己的事。Ubuntu 在一个 release 周期内基本只推送安全补丁，不需要你操心上游今天改了哪个 API。而半年一次的 do-release-upgrade，这个命令考虑非常周到，会引导你临时卸载第三方包、禁用第三方仓库，为最大稳定性和平滑升级着想。
事实上任何更新都关注新闻最好。
不支持部分升级。装一个新包之前必须先全系统更新，不能只 pacman -Sy，Arch 打包软件习惯不写最低版本依赖，如果你不更新而直接刷新软件源安装了新软件，旧依赖不会自动升级，和新软件就可能造成 ABI 不兼容等问题。而不止 Ubuntu，deb和rpm 的打包，包括 Gentoo 都指定了依赖最低版本，不会有部分升级的风险，依赖会自动随着更新。
pacman -Syyu 和 pacman -Sy 都会炸系统
AUR 是社区上传的 PKGBUILD，不是官方打包，没有统一的质量审查，参差不齐甚至还会有恶意软件包。用 AUR 默认你自己会看 PKGBUILD 内容、排查依赖、承担风险——这是 Arch Wiki 自己写的。Ubuntu 如果你自己开 PPA 或第三方仓库，或者使用 Snap Store/Flathub 上未经验证开发者的包，也要承担一定风险。在这种情况下，AUR 方差更大。 不过前面讨论过，Ubuntu 的策略是不开启任何第三方源（哪怕是 Mozilla 的 apt 源），因为发行版要为自己仓库的稳定性负责。
你自己是管理员。系统出问题 Wiki 是第一站而社区默认你已经查过了。这不是 Arch "没做完"——这是它的设计意图：用户应该理解自己的系统，自己做决定。

Arch 的 KISS 意味着很多东西需要用户（以 root 身份）手动干预执行，如上面说过的安全启动，MOK 配置；以及安装内核不会自动发生 update-grub 之类的事情；Arch Wiki 上很多类似的像是临时/永久一次性运行的命令，自己没有意识记录的话容易导致配置漂移（附录二声明式配置！），用久了也会让系统变成黑箱。而其他发行版可能更多替你做选择。当然，这里没有对错问题，有人喜欢自由有人更愿意省心。

Debian 系这种决策甚至减少了些自由度，读者去配配 systemd-boot/refind 或 UKI 或去折腾 xbootldr 就知道了

不可变发行版（减少了一些自由度，但也不像安卓那种程度的限制）和声明式配置（用于构建底层镜像），我觉得更像是 Linux Desktop 的未来（包括吸引新人）

2026 年 6 月 12 日，AUR 发生孤儿包被投毒事件。AUR 的"自由"的另一面是任何人都能上传 PKGBUILD 且无需审查，风险不是理论上的，是真实且持续存在的。

Ubuntu等发行版 "替你做了选择"，因为目标用户群不同。Ubuntu 面向的是需要干活的人，不是想学习修复 Bootloader 原理的人。

这不是谁更好的问题。Arch 哲学不推崇开箱即用，这是设计意图，不是缺陷。EndeavourOS 和 CachyOS 把 Arch 的安装门槛降低了，但它们没有改变 Arch 的哲学——你仍然需要关注新闻、管理 AUR、对自己的系统负责。Ubuntu 的哲学是让你不需要懂这些就能干活。"不用操心"本身就是它的产品定位。

两者是为不同人群设计的不同工具，这也是正文的核心观点：技术选择背后是场景的差异，多元共存才是 Linux 生态的价值。

附录二：Universal Blue 是什么

正文在实用主义部分提到，目前开箱即用做得最好的发行版系列，个人体感是Universal Blue 系和 Ubuntu 系。这里简单介绍 Universal Blue。

Universal Blue（简称 ublue）不是独立的发行版，而是一组基于 FedoraAtomic Desktops（Silverblue/Kinoite）构建的、高度优化的系统镜像。它用云原生的容器技术（bootc）构建不可变桌面，追求 "Chromebook 级的可靠 + 传统 Linux 桌面的完整能力"。构建过程在 GitHub 上完全公开。

和传统发行版的根本区别

传统发行版（Ubuntu、Fedora Workstation、Arch）是包管理器叠加式的：在基础系统上用 apt/dnf/pacman 一层层装软件，系统状态随时间变化，每台机器经过不同的操作历史最终变得各不相同。

Universal Blue 是基于镜像的不可变系统：

基础系统是只读的 OCI 容器镜像，用 Containerfile 管理，不是逐个 dnf install 叠加的
更新是原子操作：后台下载完整新镜像 → 重启 → 切到新版本 → 出问题一键回滚
更新是自动而无感的，类似 Chromebook
桌面应用几乎全靠 Flatpak，与系统层隔离
CLI 工具和环境通过 Homebrew 或 Distrobox/Toolbx 容器获取（容器内可以是 Arch、Ubuntu 等任意发行版的用户空间，不破坏宿主）

bootc：把操作系统当成容器来管

Universal Blue 的关键技术是 bootc（bootable container）。简单说就是把整个操作系统打包成 OCI 容器镜像——和 Docker 镜像同一套标准。系统更新不再是"装这个包、改那个配置"的命令式操作，而是声明镜像里应该有什么（驱动版本、预装包、系统配置），通过 GitHub Actions 自动构建，用户侧收到的就是一个已经配好、可直接部署的系统镜像。

这和正文第三章提到的 Ubuntu Core（全 Snap 组件化）是同一个方向：让系统状态可预测、可重现、可回滚。只是技术路线不同——Universal Blue 走 OCI 容器镜像 + ostree，Ubuntu Core 走全 Snap 组件化。

使用 bootc 的发行版更新机制非常类似于安卓的 A/B 分区

开箱体验

无论选哪个变体，装完就是一个直接可用的桌面：

Nvidia 驱动内置（尤其是 Bazzite），不需要手动配源安装
视频编解码器、字体、Flathub 源全部预配，多媒体播放开箱即用
Secure Boot 相对开箱即用，开机直接引导 MOK 注册流程，比手动 mokutil 方便
系统完全自动更新，后台静默下载新镜像，某一次重启就进入新系统

主要变体

Bluefin（GNOME）：不仅面向普通用户，变基到 dev 镜像也面向开发者和云原生工程师，预配 devcontainer 等容器化开发工具，定位是"写代码的不可变桌面"
Aurora（KDE Plasma）：Bluefin 的 KDE 版，面向对象和上面一样但提供更高可定制性的 Plasma 桌面
Bazzite：面向游戏和 HTPC，预装 Steam、Lutris、各种模拟器，Nvidia 驱动内置在镜像里。LTT 2026 挑战视频里 Linus 用的就是它
uCore：面向服务器的极简版

和 Ubuntu 的主要区别

	Universal Blue	Ubuntu
基础系统	Fedora Atomic（rpm-ostree）	传统 deb 包管理
不可变性	强制不可变，系统只读	桌面版非强制（Ubuntu Core 面向 IoT）
系统交付方式	OCI 容器镜像，声明式构建	ISO 安装 + `apt upgrade`
桌面应用	以 Flatpak 为主	deb + Snap + Flatpak 混用
CLI 工具	Homebrew / Distrobox 容器	直接 `apt/snap install`
更新方式	镜像原子更新 + 回滚	`apt upgrade`（非原子）
目标场景	桌面 / 游戏 / 开发	服务器到桌面的全场景
维护方	社区维护	Canonical 商业公司支持

局限

基础系统只读，不能直接 dnf install。不过和安卓一样，这是整体的安全与稳定考量
大量依赖 Flatpak，如果某个应用只有 Snap 或 deb 就没办法直接装（Distrobox可以跑但体验打折扣）
镜像构建依赖 GitHub（ghcr.io），GitHub 宕机将影响系统更新
社区维护，没有商业公司的长期支持保障

Universal Blue 是在不可变系统路线上做"开箱即用"的代表。它和 Ubuntu 的路线不同：Universal Blue 严格走"不可变镜像 + Flatpak"，专注桌面和开发；Ubuntu 用同一套 deb + Snap 工具链覆盖从服务器到桌面的全场景。两条路线各有取舍，正是正文的核心观点：没有完美方案，只有适合不同场景的选择。

附录三：Linux Mint 与 Ubuntu 的选择——不是谁更好，是哪个更适合你

正文多次提到"用脚投票"，Mint 常被作为 Ubuntu 替代方案的首选。这里简单对比两者的实际差异，帮助新手根据自己的情况做判断。

Linux Mint 的初衷是用 Ubuntu、解码器、大量其他组件打造一个优雅的桌面操作系统，Ubuntu 当底座纯粹是工程妥协与效率选择，后面才有紧跟 LTS 节奏、拒绝 Snap、预装 Flatpak、自研 Cinnamon、一系列 Mint 工具，而且并非与 Ubuntu 对立。

硬件新旧：新硬件优先选 Ubuntu 最新 release；旧硬件两个都行
时间因素：如果你在 Ubuntu 新 LTS 发布后不久装系统，Mint 可能还在用旧 base
桌面偏好：习惯 Windows 操作逻辑、或需要 Xorg 兼容性的场景，Mint 的 Cinnamon 可能更顺手
软件需求：如果你需要某些只有 Snap 的软件，Ubuntu 开箱就支持；如果你偏好 Flatpak，两个都可以

没有理由上来就无脑推荐或xx任何一个。先看清楚自己的硬件、使用场景和时间节点，哪个更适合就用哪个，或者花一个下午两个都体验一下。这和正文的核心观点一致：选择权在用户手里。