原文作者：Can Artuc，源自 Medium
标题：《35 Years of Linux Principles. Ubuntu Just Threw Them Away in One Snap.》
副标题：Ubuntu 26.04 LTS just shipped the fastest developer setup Linux has ever seen. It is hidden in a roadmap Canonical published one day before public release.
阅读耗时：约9分钟
Linux坚守35年的原则，Ubuntu用一个Snap就抛诸脑后了。
Ubuntu 26.04 LTS 刚刚推出了Linux有史以来最快的开发者环境搭建方案。它就藏在 Canonical 公开发布前一天发布的路线图里。
一个 Snap 商店，一家公司。
Linux有史以来最快的开发者环境搭建方案，运行在一台你无法复制的私有服务器上，并由一家你绕不开的公司签名。这就是 Snap Devpacks 的本质。
2026年4月22日，也就是 Ubuntu 26.04 LTS “Resolute Raccoon” 被添加到镜像站的前一天，Canonical 发布了一篇题为《从 Jammy 到 Resolute：Ubuntu 工具链的演进》的博客文章。在这篇文章里，藏着一份 Snap Devpacks 路线图，它悄然改变了 Ubuntu 作为开发者机器的意义。大多数 Linux 社区都错过了它。这篇文章是在周三发布的，当时所有人都在等待第二天发布的长期支持（LTS）版本。
devpack-for-spring 已上线。devpack-for-go 已上线。.NET snap 包已上线。Rust、C/C++ 和 Python 是下一批。还有关于 Conda 包和游戏引擎的暗示。每一个都通过你无法复制的唯一 Snap 商店发布，依赖一套你无法自己托管的基础设施，由一家公司签署每一个包。
我从2004年起就在 Linux 笔记本上安装 Java 工具链。我用过 Sun、Oracle、OpenJDK 镜像站、SDKMAN、asdf 和 mise 获取 Java 开发工具包。我运行了 sudo snap install devpack-for-spring --classic，然后从零构建了一个 Spring Boot 项目。
它能用……而且配置速度比 Linux 以往推出的任何方案都快。
一条命令，四合一
devpack-for-spring 1.3.3 版不是像 SDKMAN 那样的 JDK 捆绑包。这是我根据名字的第一反应。它是一个命令行工具，以 classic 权限运行，在一个地方做四件事。
首先，setup 命令会在你的机器上安装一组选定的 APT 和 Snap 包。你可以通过 $HOME/.config/devpack-for-spring/setup-configuration.yaml 文件修改这个列表。其次，它可以直接从命令行通过 Spring Boot 初始化器创建一个新项目。第三，它将 Spring 项目库作为可离线安装的 snap 包来管理，同时支持 Maven 和 Gradle，并提供 list、install 和 remove 命令。第四，它附带两个即装即用的插件：用于源代码格式化的 io.spring.javaformat，以及构建 OCI 镜像的 Rockcraft 插件 (io.github.rockcrafters.rockcraft)，该插件在一个精简的 Ubuntu 基础镜像上运行，并已内置了部分 OpenJDK、busybox 和 git。
说白了：开发者只需输入一条命令，最终就能得到一个默认的 Java 21 工具链、Maven 和一个当前 Gradle 8.x 版本，Spring 格式化工具和容器构建插件已就绪，并且能够直接发布服务的精简 OCI 镜像，完全不用打开 Dockerfile。~/.sdkman 或 /opt/jdk-21 目录下什么都没有。也不用玩 update-alternatives 那套游戏去弄清楚系统到底在用哪个 Java。
这就像苹果在 Xcode 中封装了十五年的那种捆绑包。你安装 Xcode，就得到了 Swift、Clang、iOS SDK、Instruments、模拟器、链接器和 App Store 提交通道，全都打包在一起，并且锁定在特定版本上。
微软也一样……你安装 Visual Studio，就得到了 MSVC、MSBuild、Windows SDK 和符号服务器，一站式配齐。
这种捆绑模式主导了 Windows 和 macOS 的开发者体验长达十年。而 Linux 基于原则，与之抗争了三十年。通过 Devpacks，Canonical 认定这些原则已不值得坚持。
两个工程师，同个周一早晨
想象一家柏林金融科技公司正将其后端服务迁移到 Ubuntu 26.04 LTS。首席架构师来自 Windows VDI 环境，他眼睁睁看着新员工环境搭建脚本从200行增长到了1400行，耗时五年。他选择了 devpack-for-spring，这样入职配置只需一个上午，而不是一周。两名 Java 团队的工程师在同个周一入职了。
如果你的生产二进制文件追溯到一个你无法检查或复刻的供应商签名，请鼓掌、留言，或者把这篇文章分享给那位在审计员进门时必须为此供应链辩护的架构师。
Snap 商店只有一个服务器，代理解决不了问题
如果 Canonical 将 Devpacks 作为 Flatpak 包发布在 Flathub 上，Linux 社区只会耸耸肩，然后该干嘛干嘛。Flathub 由社区运营，支持多个远程仓库。你可以在企业内部网络运行自己的 Flatpak 仓库。你可以查看任何应用频道的控制者是谁。
但 Snap 商店无法复制。服务端代码是闭源的。没有你可以自己运行的公共 Snap 服务器。当你运行 snap install devpack-for-spring 时，你是在与由一家公司控制的一组服务器通信。这和苹果 App Store 及微软商店的模式一样：一个供应商，一个服务器，一套规则。区别在于，在 macOS 和 Windows 上，这本来就是默认的游戏规则。而在 Linux 上，从来不是，直到现在。
Canonical 给出的答案是企业商店，之前叫做 Snap Store Proxy。企业商店是一个本地边缘代理，可以在气隙模式下运行。它允许运维人员覆盖上游 snap 版本并为设备锁定特定版本。对于 Ubuntu Core 物联网设备的工厂部署来说，这是合适的工具，且运行良好。
但对开发者工具链而言，企业商店并没有改变根本问题。Snap 签名、包名和真理之源仍然位于 Canonical 的中心服务器上。这个代理只是个缓存，不是独立的注册中心。你无法像复刻 Flathub 或运行自己的 Nix 二进制缓存那样去复刻 Snap 商店。
Flatpak 社区多年来对此取舍一直态度明确。当 Mozilla 在2022年推出仅 Snap 渠道的 Firefox 时，Flathub 维护者就请求发布者不要将 Snap 商店作为唯一的发布渠道。同样的逻辑，现在以更大规模地适用于 Devpacks。
其他四种管理工具链的方式
当 Canonical 正在收尾 Devpacks 时，另外三种方法在 2025 和 2026 年悄然成长。
mise 是一个多语言版本管理器，即一个工具能处理多种语言。大多数团队已经用它取代了 asdf。asdf 是更老的基于 shell 脚本的版本管理器，mise 正是为替代它而设计。你把想要的版本列在 .mise.toml 文件中，提交到仓库，每个克隆仓库的开发者就能得到完全相同的 Java、Node.js、Ruby、Go、Python 及其他400多种运行时环境。这个文件就是契约，笔记本变得可替换。mise 用 Rust 编写，运行速度比 asdf 的 shell 脚本快20到200倍，并且能读取 asdf 的 .tool-versions 文件及大部分 asdf 插件，所以从 asdf 迁移的团队几乎不用改变什么。它能在 Ubuntu、Fedora、macOS 和任何符合 POSIX 标准的系统上运行。它完全免费，并可以通过任何标准的二进制缓存进行镜像。
Nix devShells 是可复现的开发环境，定义在单个文件中。你在项目文件夹里写一个 flake.nix，运行 nix develop，就能得到一个 Java、Maven 和 Spring 环境，并且确切的编译器版本被锁定在签入 Git 的 flake.lock 文件中。十年后，一位同事在不同的机器上克隆同一个提交，得到的工具链将完全一致，字节不差。没有任何东西是从私有商店下载的，也不会在你背后自动更新。devShells 在上游 Nix 中官方仍标记为实验性功能，但 Determinate Nix（由前 Nix 维护者创立的公司 Determinate Systems 提供的商业支持版 Nix 发行版）在2025年已将其作为稳定功能发布，更广泛的社区也将其视为生产就绪。如今 Nixpkgs 注册中心拥有超过12万个包。像 Devbox 这样的工具搭建在 Nix 之上，让你可以完全跳过 Nix 语言。Devenv 则为想降低入门门槛的团队保留了一个薄的 Nix 层。
Fedora 应对多版本工具链的旧答案是 DNF 模块流。那个答案已经作古。Fedora 在 Fedora Linux 39 中退役了 Modularity 功能，不再构建模块。目前的答案非常朴实：为每个版本安装不同包名（如 java-21-openjdk、java-25-openjdk），或者从 COPR（酷炫的其他包仓库，Fedora 的社区构建包服务）拉取你需要的，并镜像它。仓库结构保持标准。你可以用 dnf reposync 在15分钟内镜像它。无需添加新的守护进程、沙箱层或商店到你的技术栈里。
另一个选择是将工具链放入容器。一个 Dockerfile 或 Containerfile 描述工具链，Podman 或 Docker 构建镜像，该镜像在任何兼容 OCI 的运行时上运行结果相同。经历过容器大战的 Linux 开发者都知道故事的结局：当 Docker 公司试图锁定生态时，OCI 规范保持了 Docker 镜像的可移植性。而 Devpacks 没有对等的开放规范。不存在什么“开放 Devpack 倡议”。
Canonical 到底在构建什么
Mark Shuttleworth 多年来一直明确表示，Canonical 的商业未来是成为开发者的默认 Linux 和云工作负载的默认 Linux。Devpacks 是我从 Canonical 看到的第一个以苹果能理解的方式，兑现其开发者机器承诺的策略。4月22日 Canonical 的博客文章称其结果是“框架感知平台”，具有“集中管理的工具链”。
Xcode 捆绑了 Clang、Swift 编译器、iOS SDK、Instruments、模拟器和 App Store 提交流程。你无法在 Xcode 内只安装 Swift 而不要 Xcode 的其余部分。你无法选择苹果的开发者工具链而又不选择苹果的分发模式。Canonical 想在 Ubuntu 上构建同样的垂直捆绑，并且自己扮演苹果的角色。
这个策略合乎逻辑。十多年来，在开发者笔记本的战场上，Linux 一直输给 macOS。过去二十年我招聘的所有软件工程师中，大约12%使用 Linux 作为日常开发机器，约70%使用 macOS。剩下的就不用提了。
Canonical 认定，把那些开发者拉回来的唯一途径，是推出一款能简单提供“开箱即用”感觉的产品。Ubuntu 26.04 LTS，在 sudo-rs 之上叠加了 Devpacks，搭载了 Wayland 上的 GNOME 50，以及官方仓库中的 AMD ROCm，正是这张牌的全貌。
这是一个清晰的商业策略。这也是 Linux 几十年来所坚守原则的对立面。先给便利，后搞锁定。这是苹果编写的剧本，现在 Canonical 正在照着演。
4月22日公告的直白解读是，Canonical 已经不再假装 Ubuntu 26.04 LTS 是一个通用的 Linux 发行版了。按其发布形态，它是一个开发者平台，带有一个精心策划的应用商店、一个中心化更新守护进程，以及一个意见明确的工具链捆绑包，全部由单一供应商交付。这就是 Canonical 选择发布的产品。
对于我们其他人来说，问题是：要不要用它？
如果你当初选择 Linux，就是因为没有任何一家公司能突然掀桌子，请鼓掌、留言，或者把这篇文章分享给你那位在个人笔记本上跑 Linux 的朋友，以及为你们团队下一批设备升级签字批准的架构师。
一条命令，一个供应商，巨大的权衡
Snap Devpacks 本身是一项出色的工程。在 Docker 让单一声明式环境的概念深入人心后，这是沿着同一方向的明晰下一步。标准化的设置有其价值。从全新安装到运行起 Spring Boot 服务只需一条命令，这相比 Linux 桌面二十年来提供的东西，确实是一个真正的进步。
在 Ubuntu 的历史上，首次出现了一家供应商，掌握着构建你生产代码所用工具链的唯一钥匙。
10个月宝宝每天需要喝多少奶粉？
