Snaps。为什么？请停止

原文 ↗ Hacker News 讨论 ↗

Linux 用户在权衡 Canonical 的 Snap 包与传统由发行版管理的格式，如 .deb、Flatpak、AppImage 和 Docker。Snap 的批评者指出其磁盘占用大、性能问题、基础设施不透明且高度中心化，以及 Ubuntu 倾向于用 snap 替代原生包（如 Firefox、Chromium）；支持者则认为，自包含、自动更新的打包方式可以减少依赖地狱，并把维护责任转移给上游开发者。更广泛的矛盾在于：由谁来控制打包和更新——发行版还是应用厂商——以及如何在安全性、便利性、开放性和系统资源限制之间取得平衡。

讨论的时间背景与语境

  • 讨论串的核心是 Snaps 为什么存在，以及它们是否是个好主意，许多评论将其与 Flatpak、AppImage、Docker 和传统发行版打包方式进行比较。
  • 一些评论指出原始论坛帖子来自 2019–2021 年，但大家仍认为这些问题依然相关。

磁盘空间、存储与性能

  • 主要担忧：Snaps 由于捆绑依赖并为每个软件包保留多个版本，会消耗大量磁盘空间。
  • 例子：core 和 GNOME 基础 snap 在不同版本之间被重复；小应用也会膨胀到数百 MB 甚至更多。
  • 这被认为对那些存储空间很小、且通常不可升级的廉价笔记本电脑尤其成问题。
  • 有人报告 snapd 会导致持续的高 CPU 占用和大量日志。

硬件可升级性争论

  • 一方声称“很多笔记本”现在采用焊死的存储或 eMMC 存储，因此空间非常紧张。
  • 另一方认为这些仍然只是少数，大多数笔记本使用的是可轻松更换的 SSD。
  • 消费级笔记本中 eMMC 的使用范围存在争议，整体上仍被认为“并不清楚”。

打包模式与开发者负担

  • 一个强有力的观点是传统发行版打包方式无法扩展：要求厂商为每个发行版提供 .deb/.rpm 并不现实。
  • 也有人反驳说，诸如 Open Build Service 之类的工具以及标准构建系统，已经让跨发行版打包变得可管理。
  • 有些人认为打包应继续由发行版负责；另一些人则认为应该上推给应用开发者。

Snaps 的被认为优点

  • 跨发行版打包，以及让商业软件和第三方软件更容易分发。
  • 自动更新和严格沙箱被认为对服务器以及某些自托管服务（如 Nextcloud）是重大优势。
  • 一些人认为 Snaps 更适合依赖众多的“现代应用”，能够避免库冲突。

对 Snaps 的主要批评

  • 在 Ubuntu 中被强制使用（例如 Firefox/Chromium 即使通过 apt 安装也会走 Snap）。
  • 后端闭源、硬编码的 Canonical 商店，以及被认为存在中心化/把关。
  • 磁盘占用大、启动慢、保留多个版本，以及由于大量 loop 设备造成的挂载污染。
  • 集成/沙箱问题：VPN DNS、智能卡/YubiKey、CUPS 以及其他系统资源方面存在麻烦。
  • 一些人把 Snap 看作“尚未打磨好的 Canonical 技术”，以及试图复制移动端/应用商店经济模式的尝试。

Flatpak、AppImage、Docker、Nix 等

  • 一些人更偏好 Flatpak 来运行 GUI 应用；虽然仍有权限、主题和运行时臃肿问题的报告，但情况在改善。
  • AppImage 因简单而受到称赞，但缺少自动更新既是缺点，也是取决于工作流的优点。
  • 对于“前沿”或服务器工作负载，Docker/Podman 经常被用作替代方案。
  • 提到了 Nix/Guix 和不可变发行版，认为它们是在依赖控制方面更有原则的替代方案。

传统包管理器与稳定性

  • 几位长期使用 Debian/Ubuntu 的用户表示，只要坚持使用官方仓库或正确的 pinning，依赖地狱大多已经解决。
  • 另一些人坚持认为依赖地狱仍然存在，尤其是在第三方仓库和 PPA 的情况下。
  • 有些人离开 Ubuntu（转向 Debian、Arch、Mint、Pop!_OS），主要是为了避开 Snaps 和 Ubuntu 的额外工具/广告。
  • 持续存在的张力：希望获得稳定、与发行版深度集成的软件包，与“fix-forward”思维和快速自动更新之间的矛盾。