浅谈 Ubuntu、Snap 与 Firefox
本文经 DeepSeek V4 Pro润色
下面的观点，你不支持不理解就是你对，触发关键词的可以划走了
引言：一个被情绪放大的标签
在 Linux 社区，只要涉及 Firefox 或 Snap，评论区几乎自动填充同一套说辞：”Ubuntu 强行推 Snap””Canonical 在破坏生态””又一个 deb 包被偷偷替换了”。这些批评重复的时间已经足够长，长到很多人不再去核实它们与事实之间的距离。
如果你真的翻一遍 Ubuntu 官方仓库中通过 postinst 脚本把 apt 请求重定向到 Snap 的过渡包清单，会发现，从 2019 年底至今，整个 Ubuntu 发行版中被这样处理的软件包只有三个：Firefox、Chromium、Thunderbird（准确的说，还包括他们的数据文件或本地化语言包，命令自查 apt list | grep snap1 | grep -iv thunderbird | grep -iv firefox | grep -iv chromium ）。其他七万个包，包括你每天都在用的 gcc、python3、docker.io、nginx、rustc，依然是传统 deb 包。所谓”Ubuntu 要把所有东西都塞进 Snap”，本质上是一个被情绪不断放大的标签，而不是事实。
本文旨在把这些散落的事实和逻辑串联起来，不是为 Canonical 辩护，而是希望把讨论拉回到事实和成本的层面。该批评的地方就应该批评，该理解的地方也应该给理解留出空间。
一、到底哪些包被替换了？历史时间线
1.1 第一个过渡包：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 系统。
1.2 最受关注的过渡包：Firefox（2022 年 4 月）
Firefox 的转换比 Chromium 晚了两年多。2021 年，Canonical 与 Mozilla 达成正式合作协议——这一转换实际上是由 Mozilla 主动推动的，Mozilla 希望绕过为每个 Ubuntu 版本单独维护 .deb 的延迟，直接向所有支持 snapd 的发行版推送安全补丁和新功能。在 Snap Store 中，Firefox snap 带有 Verified 标识，确认它由原始开发者（Mozilla）而非第三方直接发布和维护；Canonical 工程师的角色是与 Mozilla 协作优化 snap 在 Ubuntu 上的性能表现和沙箱隔离策略。从 Ubuntu 22.04 LTS 开始，新安装系统的用户默认获得 Snap 版 Firefox。也就是说，当用户在终端输入 apt install firefox 时，系统执行的不是安装 deb 包，而是安装由 Mozilla 官方维护的 Firefox Snap。这正是大量用户开始产生困惑和争议的节点——因为它触碰了桌面用户对”浏览器安装”这个行为的直觉预期。
1.3 第三个过渡包：Thunderbird
Thunderbird 同样是由 Mozilla 官方打包的 Snap。逻辑与 Firefox 一致：Mozilla 直接负责构建和维护，Canonical 不再需要为每个 Ubuntu 版本单独维护 Thunderbird 的 deb 包。
1.4 六年，三个（类）包
除此之外，没有第四类。这个数字本身就足以让”全面 Snap 化”的说法站不住脚。你需要用 gcc 编译代码，apt install gcc 装的是 deb。你需要 Podman，apt install podman 装的也是 deb。Ubuntu 官方仓库中依然提供数万个传统 deb 包，并且没有任何计划把它们全部替换成 Snap。
把这三个包的情况夸张成”Ubuntu 正在把所有东西都换成 Snap”，不是事实，是对事实的情绪化扭曲。
二、真正的矛盾不在 Snap，而在发行版模型本身
要理解为什么偏偏是这三个包被改成了 Snap，必须先理解 Ubuntu 这类”锁版本”发行版的根本运作逻辑。
2.1 锁版本发行版的生存法则
Ubuntu LTS（事实上Current Release也是锁版本的）、Debian Stable、RHEL，它们在服务器和关键基础设施领域占据主导地位，靠的就是一份核心承诺：每个大版本发布后，软件版本基本冻结，只向后移植安全补丁，不引入行为变更，不破坏兼容性。这个承诺让企业可以把系统部署到生产线，然后五年甚至十年不用操心”系统更新会不会把业务搞崩”。这是锁版本发行版存在的基本理由。这不是 Canonical 的”恶意”或技术保守，而是在生产环境中保障业务连续性的硬需求——服务器管理员宁愿软件旧一点，也不愿半夜被一个自动更新叫起来修系统。
2.2 浏览器的反叛：滚动更新与稳定冻结的正面冲突
但常用软件浏览器完全不是这种模型（后面会分析其他软件锁版本的情况）。Firefox 每四周一个大版本，每个版本包含几十甚至上百个安全修复（Firefox 150版本一口气修复了上百个漏洞，你用 149 版本出了问题 Mozilla 大概率是不会理你的）。Mozilla 官方只对最新的版本和下面提到的 ESR 提供完整安全支持，不承诺为旧版本做维护。Chromium 的更新节奏同样密集。
这就产生了一个结构性矛盾。如果 Ubuntu 把 Firefox/Chromium 锁定在某个旧版本，那么 Canonical 就要自己去向后移植成百上千个安全补丁，这个工作量的规模不是一个团队可以承受的。如果 Ubuntu 像滚动发行版那样不断推送最新版浏览器，那就破坏了锁版本发行版”行为不变”的承诺。浏览器不仅是独立应用，它依赖的一大套共享库也需要同步更新，而这些库又可能被系统中其他软件包所依赖——一旦动了依赖链上的任何一环，就可能引发级联的 ABI 不兼容和依赖冲突，在生产环境里完全不可接受。
有人会问，为什么不保留多套版本的依赖库？这恰好回到了同一个矛盾：系统中同时存在库的旧版本和需要持续滚动的新版本，本质上已经违反了锁版本一套行为的原则，系统的可预测性也随之瓦解。
那能不能像 Fedora 那样在 GNOME Welcome 界面询问用户是否开启第三方源？Ubuntu 不这么做，原因同样来自稳定性需求：任何非 Canonical 维护的外部源都会引入不在发行版测试范围内的组件，增加依赖冲突和系统不稳定的风险。发行版不会为非官方源的稳定性背书——即使是 Mozilla 的 apt 源也不例外。Mozilla 的核心精力在浏览器开发上，它不会也无力保证其 apt 源在任何 Ubuntu 版本上不破坏系统。Snap 在这里是对双方都更安全的选择：Mozilla 只需维护一个沙箱隔离的 Snap 包，Canonical 不用担心第三方源破坏系统，用户也拿到了不断更新的浏览器。
2.3 RHEL 和 Debian 的做法：选择 ESR，承担代价
面对这个矛盾，RHEL 和 Debian Stable 做出了另一种选择：使用 Firefox ESR（Extended Support Release），也就是延长支持版。ESR 一年只发布一次大版本，中间的更新主要是安全修复，不会引入新功能或行为变更。这当然减轻了发行版的维护负担，但代价也相当明显：桌面用户一年甚至更久接触不到新的 Web API、新的 CSS 特性或新的开发者工具，浏览器版本落后于主流（说的就是落后十个大版本的 Firefox 140，Debian 上这个包甚至没有编译编码器支持）。对服务器来说这无关紧要，对桌面用户来说则是切实的体验痛点。早在 2012 年，Ubuntu 的开发者就明确指出过：如果因为浏览器版本太旧导致 Google+ 或 Facebook 的新功能在 Ubuntu 上跑不了，那对桌面用户体验是灾难性的。（参考文献自己查）
2.4 Ubuntu 的选择：用 Snap 解耦浏览器
Ubuntu 没有走 ESR 这条路，因为它的桌面定位要求浏览器必须跟得上 Web 标准的演进。它也不能违背锁版本的承诺去强制推送新版 deb，那样会破坏整个系统的稳定性契约。
如果还问为什么不用 apt 源，说明没认真看上面
Snap 在这个局面下提供了一条出路：把浏览器从系统核心解耦。Firefox Snap 运行在沙箱里，独立于发行版生命周期滚动更新，行为变更被限制在容器内部，不影响系统其他部分。这本质上是一个多方共同受益的工程方案：Canonical 免去了为每个 LTS 分支回溯浏览器补丁的人力压力，可以把有限的精力集中在更关键的基础设施上——内核维护、安全更新、Ubuntu Pro 的长期支持、云镜像优化、AI/ML 与物联网平台的建设——这些才是 Ubuntu 真正的基本盘（桌面用户在整个 Linux 生态中占比不到 5%）。Mozilla 获得了统一的跨发行版分发渠道，Ubuntu 用户拿到了与上游同步的最新浏览器。如果你确实无法接受这种取舍，Arch、Fedora 等滚动发行版打包最新浏览器的维护压力要小得多，它们的存在本身就是 Linux 多元生态的价值体现。这个方案不是”更好”或者”更纯粹”，而是”在给定的约束下可行”。
2.5 浏览器之外：锁版本对桌面工具的广泛影响
Firefox 和 Chromium 只是最显眼的例子，锁版本策略的影响远不止于此。对于桌面用户常用的开发工具和效率软件，Ubuntu 官方源的版本经常落后上游一大截。比如 PrismLauncher，Ubuntu 26.04 LTS 官方源还锁在 10.0.5，而 Snap 版已经更新到了 11.x（如 11.0.2）；Neovim 在 Ubuntu 24.04 LTS 官方源停留在 0.9.x，最新稳定版早已是 0.12.x 以上，Lua 配置生态的巨大版本差让用户非常难受。类似的情况也出现在 fish、fastfetch、ripgrep 等工具上——上游迭代飞快，官方源纹丝不动。
解决方案是多样化的，但各有利弊：PPA 能拿到最新甚至开发版，但可能引入依赖冲突；Snap 和 Flatpak 沙箱隔离不破坏系统，但有额外开销（特别是 flatpak 对 CLI 支持不友好）；Homebrew on Linux 专为用户空间设计、不侵入系统目录，特别适合命令行工具（如 brew install neovim ripgrep eza）；对于 Hyprland、Niri、Quickshell 这类更新极度频繁的窗口管理器和桌面组件，往往只能自己编译或使用社区维护的 PPA。
Canonical 没有精力去维护一个”服务器分支”和一个”桌面分支”——它的核心价值在于用同一套 base 服务所有场景，让绝大多数使用情况受益。如果你追求每一个包都是最新版本，换到 Arch、Fedora 等滚动发行版本身就是合理的选择。没有一个发行版能在所有维度上”既要又要”，多元并存的生态本身就是用户用脚投票的自由。
三、为什么不是 Flatpak？Snap 的目标本就不止桌面
3.1 设计目标的根本差异
对 Snap 的另一大常见批评是”重复造轮子”——社区已经有 Flatpak 了，Canonical 为什么还要另搞一套？这个问题的答案在于两者的设计目标从一开始就完全不同。
Flatpak 是为桌面 GUI 应用设计的。它的社区明确限制纯命令行应用的提交，系统服务、守护进程更是超出它的范围。你没法用 Flatpak 去管理 Docker 容器、运行 LXD 系统服务或者部署内核模块。
Snap 的设计定位是全场景通用方案。命令行工具可以打包成 Snap（snap install zig、snap install rustup、snap install yazi），图形应用可以打包成 Snap（Firefox、VSCode、Steam、Telegram Desktop），后台服务可以打包成 Snap（Docker、LXD、Multipass），甚至系统级组件也可以打包成 Snap。Ubuntu Core 就是一个完全由 Snap 组件构建的不可变操作系统。
3.2 Snap 早于 Flatpak 1.0
还有一点常被忽略的时间线事实：Snap 的概念提出和早期实现都早于 Flatpak 1.0 的正式发布。它并非 Canonical 看到 Flatpak 之后故意要”制造分裂”，而是一条从更早启动、面向更广泛场景的技术路线。
3.3 不可变基础设施：全行业都在往同一个方向走
跳出桌面看，整个基础设施领域正在趋向同一个方向：不可变系统、原子更新、自动回滚。
- Ubuntu Core 用 Snap 构建整个操作系统，每个组件都是只读、原子更新、可回滚的 Snap。
- Red Hat 推出了基于 bootc（OCI 容器镜像）的 Image Mode，操作系统作为容器镜像部署，同样支持原子更新。
- Fedora 有 Silverblue/Kinoite，基于 rpm-ostree 实现不可变桌面。
- SUSE 有 MicroOS，基于事务性更新做同样的事。
这些方案的技术路线不同，但目标一致：让系统状态可预测、可重现、可回滚。Snap 在 Ubuntu 生态里就是这条路的载体。把一个全场景基础设施方案纯粹用桌面应用打包工具的视角去衡量，是在不同的维度上强行做比较。
3.4 “造轮子”的前科与知错能改的 Canonical
社区对 Canonical 的信任赤字并非空穴来风。回顾历史，Canonical 确实有过三次著名的”造轮子然后放弃”的记录：Mir 显示服务器在 Wayland 成为行业共识后退场，Upstart 初始化系统在 systemd 胜出后放弃，Unity 桌面环境最终让位于 GNOME。这些尝试对当时的用户和生态确实造成了分裂和困惑，社区的不信任由此而来。
但这恰恰说明 Canonical 并非顽固不化。它试过，争过，输了之后也认了——Mir 的后续技术积累已转向为 Wayland 合成器提供底层支持，Unity 的设计遗产也在 Ubuntu 的 GNOME 定制中延续（Unity 已经独立出来了另外维护，即 Ubuntu 风味版）。这些失败不是”邪恶”的证据，而是一家公司在探索差异化路径时付出的代价和精力。Google 关掉的产品不比谁少，Microsoft 推过的 Windows Phone 和 Zune 甚至是 WSA 早已成为互联网记忆，Red Hat 在 Linux 领域的尝试也并非一帆风顺（想一下 Centos 的历史）——哪家活得久的科技公司没有几段”黑历史”？
如今 Canonical 已经找到了适合自己的路：RHEL 向下扎根，聚焦基础设施的极致稳定；Canonical 向上生长，用 Snap 等容器化方案拥抱应用和开发者场景（物联网、云原生、机器人）。两者不是对手，而是 Linux 生态里互补的两端。拿十几年前的 Mir 和 Unity 来否定今天 Canonical 做的每一件事，既不公允，也无助于推动任何实质性改进。批评应该对准具体的问题和具体的做法，而不是对着公司名字条件反射式地开火。
四、2026 年的 Snap：别再拿几年前的印象说事
早年的 Firefox Snap 确实不是一来就完美的——插件兼容性问题、中文输入法无法调用、冷启动速度让人焦虑，这些我自己也经历过。但抓着几年前的印象来判断今天的 Snap，没有任何道理，以前是以前，现在是现在。承认过去的不足和承认现在的改善，两者并不矛盾。
4.1 性能已经大幅改善
围绕 Snap 的性能抱怨，很大一部分还停留在 2019 到 2021 年的阶段。那时候 Snap 确实存在冷启动延迟明显、首次挂载耗时较长的问题。到了 2026 年，情况已经有了显著变化。压缩镜像和挂载机制经过多轮优化后，冷启动延迟与原生 deb 的差距大幅缩小（我是没感觉到很大的启动速度区别），日常使用中几乎感觉不到差异。这是工程迭代带来的实际改善，而不是什么公关话术。
4.2 主题集成不再麻烦
gtk-common-themes snap 的完善让大多数桌面应用能自动适配系统主题，不再需要手动配置。权限管理方面，snap connections 命令和图形化权限控制界面已经相当成熟，用户能清晰管理应用的摄像头、网络、文件访问等权限。
权限管理确实不如
Flatseal直观
4.3 对开发者的价值：一键环境，零依赖冲突
在实际工作中，Snap 版开发工具正在让环境配置变得更简单。snap install zig 提供一个沙盒化的 Zig 环境，与系统库完全隔离（这是另一个锁版本问题，官方仓库的 Zig 落后于 Snapcraft上的版本）。顺便一提， Ghostty 也是官方仓库落后于 Snap 版本。snap install code 一行命令装好 VSCode，不需要操作系统的库版本配合或者微软的第三方源（事实上需要 Wayland 的话我建议用微软源的）。Canonical 在 2026 年进一步推出 Devpacks 计划，把 GCC、LLVM 等编译器也纳入这个”一键开发环境”范畴（之前已经有 Go 了）。（以为这又是在造轮子的去看 Phoronix 和官方博客，这跟 Podman/Docker 路线有明显区别）
4.4 对新手用户：它只管工作（实用主义）
对刚接触 Linux 的用户来说，Snap 有一个非常直白的优势：装得上，跑得动。普通用户不需要知道这个包是 deb 还是 snap，他们只需要浏览器能打开网页，软件能正常工作。snap install telegram-desktop/steam 一行命令，依赖全解决，不操心发行版版本、不缺库、没有依赖冲突。Ubuntu 不是只给高级桌面用户做的发行版，它的桌面产品也必须服务更普通的群体。工程上的权衡需要把这一块人群也纳入考量，而不是只从打包者的视角出发。
别问为什么不用 Flatpak ，首先没人让你不用，然后就是又没看上文
4.5 桌面端的客观短板：需要批评，也需要贡献
说了这么多 Snap 的进步，不代表它在桌面上已经完美。和专注于桌面 GUI 的 Flatpak 相比，Snap 在桌面端确实有实实在在的短板需要改善。比如 VSCode 的 Snap 版至今仍只支持 XWayland，无法原生运行在 Wayland 下；非 Yaru 主题的适配不够完善，切换系统主题后部分 Snap 应用的界面会显得格格不入；Intel Xe 核显的 VA-API 硬件解码在部分 Snap 应用中也存在问题。
但反过来，有些被忽视的方面 Snap 做得比 Flatpak 更好。典型的例子是图形驱动集成。Flatpak 用户通常需要额外安装对应版本的 NVIDIA 驱动 runtime（如 org.freedesktop.Platform.GL.nvidia），当系统更新了驱动而 Flatpak runtime 没跟上时，就会出现版本不匹配导致的黑屏或崩溃。(参考文献是 Arch Wiki，自己查)
Snap 的机制不同。它通过 content interface 让应用 snap 共享图形栈提供者（如 mesa-2404）。其工作原理是：mesa content snap 向应用 snap 提供 DRI 驱动、VA-API 后端、Vulkan 驱动等一整套图形接口，同时对 NVIDIA 专有驱动采取 host 端直通而非沙箱内捆绑的方式，因此不会出现”沙箱里塞了一份和宿主不同步的驱动”的割裂问题。多个 snap 应用通过 gpu-2404 接口共享同一份图形栈，snapd 在 Ubuntu 上自动处理连接，用户几乎无感。最终效果是：系统更新驱动后，snap 应用自动跟随宿主环境，不需要像 Flatpak 那样手动对齐版本。
此外，另一个绕不开的争议是 Snap Store 本身。与 Flathub 由社区共同维护不同，snapcraft 的后端服务目前完全由 Canonical 控制，代码也不开放。这意味着 Snap 的分发渠道本质上是中心化的——对习惯了传统 Linux 包管理去中心化模型的用户来说，这和”Linux 版 App Store”十分接近，引发控制权担忧是完全可以理解的。这是 Canonical 作为商业公司的决策，此处不替它辩护。但需要指出的是，snapd 本身是开源的，社区在客户端层面仍有贡献和改进的空间——如果桌面用户希望 Snap 变得更好，这里就是可以下手的地方。
客观地说，两个方案各有优劣。Snap 在桌面上确实需要社区——尤其是我们这些占 Linux 不到 5% 的桌面用户——去提 issue、做测试、甚至是贡献代码，实实在在改善 Wayland 支持、主题适配、硬件加速等问题，而不是丢一句 “snap 就是垃圾” 就关掉终端。批评是为了推动改善，不是为了让批评本身变成身份标签。
五、”apt 静默重定向”应该批评，但不应无限上纲
5.1 一个合理且值得被批评的问题
在这三个包的具体实现中，apt install firefox 静默安装 Snap 版本，这个行为确实有问题。它打破了老用户对 apt 的预期。”apt 是 Debian/Ubuntu 生态的基石，用 apt install 就应该装 deb 包”——这个心理契约被打破了。更具体的困扰在于行为不一致：用户输入 apt install firefox，系统装了一个 Snap。用户执行 apt remove firefox，这个 Snap 不会真正被卸载，因为它装在 /snap 下而不在 apt 的追踪范围内。这种操作的不一致性给用户造成了实实在在的困惑和挫败感。
还需要补充一点：Ubuntu 桌面版在安装完成后就已经自带了 Firefox 浏览器。对绝大多数注重实用的新手用户来说，开机就能上网，根本不需要碰命令行，底层是 deb 还是 snap 完全不重要——Firefox 图标在桌面上，双击就开，这就够了。真正产生困惑的场景往往是用户有意识地想要卸载后重装：用了 apt remove firefox，却发现浏览器还好好地待在系统里。这种”装上时无感、卸载时混乱”的不一致体验，才是问题的症结所在。
Canonical 在这件事上的沟通和实现方式做得不够好。更合理的做法（但也可能违反 Debian 打包原则）是在 postinst 脚本中用 echo 给出明确提示，告知用户”这个命令实际安装的是 Snaps 版本，如需传统 deb 包请使用其他方法”，而不是静默重定向。这部分该批评，没什么好维护的。
5.2 有问题的实现不等于”全面入侵”
但合理批评和全盘否定之间有一条清晰的界限。把这三次重定向夸大成”Ubuntu 全员 Snap 化”，把一个工程取舍定性为”垄断阴谋”，把一个具体实现中的不足上纲上线为”Canonical 在摧毁 Linux 生态”——这就越界了。
因为默认用 Snap 版 Firefox，Ubuntu 并没有删除 deb 支持，没有禁止用户安装 Flatpak，没有屏蔽其他浏览器。用户完全可以使用 sudo apt remove snapd 卸载整个 Snap 体系，然后添加 Mozilla 的 apt 源安装传统 deb 版 Firefox，或者使用 Flatpak 安装。选择权一直在那里，没有人把它夺走。如果你不喜欢，换个发行版也是完全自由的——Arch、Fedora、openSUSE、Linux Mint，哪一个都能用，没有人强制任何人用 Ubuntu。
此外，如果实在无法接受 Snap 的哲学，用户也完全不用被困在 Ubuntu 上。Arch Linux、openSUSE Tumbleweed、Fedora、Gentoo、Debian Sid 等滚动或半滚动发行版的维护压力相对小得多：它们通常只需维护一个版本仓库，无需在多个 LTS 分支上做大量向后移植，也无需承诺长达十年的行为不变，因此打包新版本的 Firefox 或 Chromium 的成本远低于 Ubuntu LTS，用户自然可以直接通过原生包管理器获得最新的滚动版浏览器——但代价是用户自己承担系统更新中可能出现的不稳定或配置变动风险，这与 Ubuntu LTS 对企业级稳定性的承诺是完全不同的路线。
六、社区偏见从何而来
6.1 桌面中心主义：用自己的使用场景丈量一切
这是最容易被忽视但也最普遍的偏见来源。很多批评者只从自己的桌面使用经验出发，认为”我就是 Linux 的典型用户”，然后用自己的场景去衡量所有发行版的决策。这种以偏概全的视角，恰恰是社区中大量无意义争论的根源。
但事实是，Linux 桌面用户在整个 Linux 生态中占比不到 5%。Ubuntu 的大部分用户运行在服务器上、云实例里、物联网设备中。对服务器管理员来说，浏览器版本新不新根本不重要；对物联网工程师来说，系统能否原子更新和可靠回滚才是关键。桌面用户的声音尽管响亮，却只是 Linux 生态中很小的一片。一个为企业级基础设施设计的发行版，不可能只按照桌面用户的喜好来做技术选型。
理解不了这一点，对”他们为什么这么干”感到困惑是很自然的事情。但困惑是一回事，在完全不理解对方约束条件的情况下张嘴就骂，是另一回事。你可以不需要了解服务器、物联网、长期支持契约的压力，但如果你拒绝了解这些背景，却依旧坚持用”我就是用户”的身份去批判发行版的每一个决策，那这种批评本身就失去了成立的基础。
个人桌面用户确实没有义务去理解服务器和数据中心的需求。但反过来，如果你不理解这些需求，你又有什么资格一口咬定对方的决策是”愚蠢”的？ 批评的前提至少是了解你批评的对象。
6.2 自利归因：找一个最显眼的靶子
心理学上有一个概念叫自利性归因偏差：自己做成了功劳归自己，自己做砸了责任推给外界。在技术世界里，这种心理体现得非常直接。当系统出问题，如果用户自己不具备足够的排查能力，最省力也最舒服的处理方式就是找一个明确的靶子来承担全部责任。
这种偏差在两个平台上分别有各自的经典套路。
在 Windows 上，用户可能运行过各类一键优化工具、关闭了系统更新、用 PowerShell 脚本删掉了 Microsoft Store 等关键组件。系统出问题之后，结论是 Windows 就是垃圾，而自己做过什么则只字不提。
在 Linux 上，同样的逻辑处处可见。网上复制粘贴一段看不懂的 shell 脚本直接执行、添加不被发行版维护者支持的第三方软件源，系统出了依赖冲突或黑屏问题，结论不是”我刚才干了什么”，而是”某某发行版真烂”。Snap 就是这个很明显的靶子——它新，它来自 Canonical，它在一些老硬件上确实不够快。于是从显卡驱动到无线网卡的故障，都很容易被归因为”都是 Snap 害的”。
此外，硬件本身也是一个经常被忽略的变量。Windows 蓝屏可能是因为内存超频没跑稳或内存条松了，Linux 这边的黑屏也可能是同一根不稳定的硬件在作祟。现在内核已经发展到 7.0 时代，主流硬件的兼容性远好于过去，冷门或极新的硬件有点小毛病也难免，但不分原因直接骂操作系统，既对解决问题毫无帮助，也遮蔽了真正的根因。当然，问题确实有可能是操作系统的 bug——而这恰恰需要调查才能确认，不是张嘴就喷的前提。承认”可能是我自己搞的”需要克服一些心理阻力，这也是理性排查的第一步。
6.3 NIH 综合征：不是我做的，所以就是烂的
很多技术人员身上存在一种思维惯性：不是我自己或者我认可的小圈子做出来的东西，天然不可信。Snap 是 Canonical 的产品，没有经过社区协商，所以它必须是不好的。这种心态直接把”我不喜欢它的设计哲学”等同于”它是垃圾且毫无价值”，跳过了对具体功能和实际体验的评价。NIH 本身未必全是坏事——它有助于保持审慎和对控制权的意识。但问题是，当 NIH 变成一种条件反射，它就会阻挡所有来自外部的有效尝试。
6.4 回声室效应：事实在传播中被不断简化
一个偏见一旦出现，会通过论坛热评、短视频、meme 等形式快速复制和强化。apt install firefox 会装 Snap 这个事实，在传播链条中被简化为”Ubuntu 强制装 Snap”，再被简化为”Ubuntu 把所有东西都变成了 Snap”。每一个传播环节都会把原有信息再夸张一点、再简化一点。提出相反证据的人会被指责为”给商业公司洗地”，理性的讨论空间被情绪挤占。最后，三个包变成了”大量包”，再变成了”所有包”，事实本身已经没人关心了。
七、更大的背景：开源社区的资源危机
7.1 Debian 的数据：人力正在坍塌
围绕 Snap 的讨论背后，有一个更深层的事实一直被忽略：开源维护的人力严重不足。Debian 在 2012 年有约 3270 名活跃贡献者，到 2025 年这个数字降到了约 1473 人，十三年间下降超过一半。而实际负责上传代码的核心开发者仅约 975 人，由他们维护着超过 61000 个软件包（现在有七到十万了）。2026 年，Debian 项目领导人选举一度演变成现任领导人与”None of the above”的对决——这已经不是说”候选人不够多”，而是几乎没有新人愿意接这个担子。
7.2 原因不只是缺钱，更缺人和工具
Debian 银行账户有超过 90 万美元的资金，但钱在这里解决不了人的问题。开发者因现实压力离开，但没有及时告知项目，导致任务和 bug 无人接手。像 Debian 的网站使用了 WML 这样极其古老的工具链，二十多年积累的数万网页需要手动迁移，找到熟悉这套技术栈的开发者本身就极为困难。Debian 的工作流程中仍然充斥着以邮件为核心的古老机制，繁琐程度让新人望而却步。
7.3 人力资源有限是所有选择的基础
回到 Canonical 和 Snap 的讨论。Canonical 的人力不是无限的，他们的精力需要集中在生产环境的核心领域。让 Mozilla 自己维护 Firefox Snap，让 Chromium 通过 Snap 减少维护负担，这些选择的底层逻辑不是”Canonical 想造轮子”，而是”Canonical 没有多余的精力在每一个高频更新的上游项目上做回溯补丁”。这个逻辑同样适用于 Debian 选择 Firefox ESR、RHEL 选择只回溯安全补丁而不升级版本。
在人力资源的硬约束下，不是所有的”更好方案”都是可行方案。工程上能做的是在可行方案中选择对当前目标帮助最大的那一个。
八、商业模式与开源生态的三代进化
8.1 从志愿者到公司再到公共基础设施
开源不是只有一种形态。第一代商业模式以 Red Hat 为代表，靠企业服务收费。第二代以 HashiCorp、MongoDB 为代表，提供开源社区版的同时推出增强的企业版或云服务。第三代以 Neon、Supabase 为代表，直接把商业服务本身做得足够优秀来吸引用户付费。还出现了混合模式：个人开发者通过企业赞助（如 Vue.js）、技术咨询与服务（如 cURL 作者）来维持项目运转。
这些模式迭代的背后，是同一个问题的不同解决方案：免费软件的维护者到底靠什么活下去？
8.2 国家层面：从基础设施到数字主权
一个更宏观的趋势是，越来越多的国家开始将关键开源项目视为公共基础设施，通过政府采购和定向拨款来确保其长期稳定。开源的发展路径正在从志愿者驱动，到商业参与，再走向政府和公共资金的支撑。这不是理想主义的愿景，而是在现实压力下正在发生的事情。
8.3 Canonical 是这套逻辑中的一环
把 Canonical 放回这个框架里看，它的角色是提供企业级稳定支持并从中获得收入，然后用这些收入来维持 Ubuntu 的开发和维护。选择 Snap 来分摊浏览器的维护成本，是这个商业模式中的一个具体决策。你可以批评这个决策的具体实现，但不应该因为它来自一家公司就全盘否定。
九、结语：基于事实、成本与选择的边界
9.1 事实层面
六年来通过 postinst 脚本重定向到 Snap 的包只有 Firefox、Chromium、Thunderbird 三个。Ubuntu 数万个官方 deb 包没有在这个层面被动过。所谓”Ubuntu 全面 Snap 化”，不是事实，是一个被反复复读到失去了事实基础的标签。
9.2 工程层面
把这三个包做成 Snap 不是 Canonical 随意制造轮子，而是锁版本发行版在人力有限的情况下，解决浏览器高频更新与系统稳定性之间矛盾的一个具体方案。方案本身不是完美的，但它有明确的工程动因。
9.3 可以批评的地方
apt install 静默重定向到 Snap 的行为透明度不足、卸载行为不一致、对部分用户的体验不友好，GUI 仍然存在的体验问题，这些是合理且值得持续反馈的批评。在这些具体问题上提 issue、做测试、贡献改进代码，才是倒逼 Canonical 把产品做得更好的有效方式。
9.4 需要理解的地方
Canonical 不是慈善组织，也不是恶魔。它是一家在资源约束下做工程选择的公司。Ubuntu 的目标人群既包括桌面新手，也包括服务器管理员、物联网设备厂商和 AI 基础设施团队。发行版的选择需要在这些不同的群体之间做权衡，没有一个方案能让所有人都满意。
9.5 选择的自由一直都在
不喜欢 Snap？sudo apt remove snapd，然后加 Mozilla 的 apt 源装 deb 版 Firefox。或者用 Flatpak 替换。或者换个发行版——Arch、Fedora、openSUSE、Linux Mint，任选一个。Linux 生态的核心价值之一就是用脚投票的自由。但请把不一样的选择和”邪恶”分开，也请把六年来只有三个包的事实，和”整个 Ubuntu 都沦陷了”的夸张叙事分开。
9.6 对社区的一点期待
一个有生命力的技术社区，应该能够同时容纳两件事：一是批评具体实现中的不足；二是在理解工程约束的前提下承认方案背后的合理性。不问事实直接贴标签、把工程取舍曲解为道德问题、把情绪宣泄包装成正义发声——这些做法既不能解决实际问题，也不能让软件变得更好，它只会持续消耗社区有限的讨论空间。
真正有效的批评，是先核实事实，再评估成本，然后针对具体的点提出具体的改进意见。一个健康的开源生态，需要的不是更多的站队和复读，而是更多愿意停下来问一句”事实到底是什么”的人。
如果你有批评，请落在具体问题上。如果你有精力，请去提交 issue 或贡献代码。如果你实在不喜欢，就换掉。社区的前进不靠骂退某一方，而是靠在事实基础上，用理性的方式推动每一方都做得比昨天更好。