openSUSE Leap 16.1 发布，整合传统与不可变安装模式

openSUSE 项目已正式发布 openSUSE Leap 16.1，对该发行版的安装、维护和部署方式引入了一项重大变化。该更新于 2026 年 11 月 3 日发布，带来了集成的 Immutable Mode（不可变模式），允许用户安装一个具有只读根文件系统、以事务方式更新的操作系统，同时继续提供传统的 Linux 安装模式。

这一新方案也标志着 openSUSE Leap Micro 作为独立发行版走向终结的开端。其功能现已并入 Leap 16.1，为管理员提供了一个统一平台，适用于桌面、传统服务器、容器主机、虚拟机和边缘计算环境。用户可以选择最契合自身工作负载的安装模式，而无需切换到完全不同的 openSUSE 产品。

除了新的安装架构之外，Leap 16.1 还将 KDE Plasma 更新至 6.6 版本，保留 GNOME 48 并附加了额外的维护修复，引入 LXQt 2.4，并继续使用 Linux 6.12 长期支持内核系列。该版本还扩展了容器工具、改进了系统监控、更新了安全组件，并引入了旨在让面向企业的 Linux 部署更具可预测性的变化。

openSUSE Leap 16.1 最重要的新增功能是其新的 Immutable Mode，它允许操作系统使用只读根文件系统和事务性更新。每当安装或更新软件包时，不可变配置不会直接修改正在运行的操作系统，而是在单独的文件系统快照中准备变更。

这种方法不同于传统的 Linux 安装方式——在传统方式中，包管理器通常会修改活动根文件系统中的文件。在传统系统上，一次更新可能会在应用程序继续运行的同时替换库、可执行文件和配置组件。尽管 Linux 包管理器会谨慎处理这些操作，但更新中断或软件包组合不兼容有时仍可能使系统处于不一致状态。

Immutable Mode 通过将操作系统变更与当前运行环境分开准备，降低了这一风险。更新在重启后才会生效，使系统能够开始使用一组一致的软件包和配置变更。如果更新引入问题，管理员可以回退到较早的快照，而无需手动逐个撤销软件包修改。

底层技术对 openSUSE 来说并不完全陌生。类似功能已通过 Leap Micro 提供，后者专为轻量级、事务性更新的服务器和基础设施部署而设计。Leap 16.1 的变化在于，这种运行模式成为主 Leap 发行版内的一种安装选择。

从历史上看，openSUSE 用户会根据自己需要传统操作系统还是更专门化的不可变环境来选择不同产品。Leap 提供熟悉的通用 Linux 安装，而 Leap Micro 则专注于容器主机、虚拟机和其他基础设施工作负载——在这些场景中，受控更新和最小化维护是优先事项。

Leap 16.1 将这些方案合并到单一版本中。偏好传统模式的用户仍可继续安装具有可写根文件系统和熟悉包管理工作流的标准系统。希望获得更受控运行环境的用户则可以选择 Immutable Mode，以事务方式管理系统变更。

这种统一也简化了维护规划。管理员无需再分别遵循 Leap 和 Leap Micro 的发布计划与支持政策，而是可以对两种安装模式使用同一个 Leap 版本系列。openSUSE 项目已确认，Immutable Mode 下的 Leap 16.1 接替 Leap Micro 6.2，且不计划单独发布 Leap Micro 6.3。

这一区别仍然很重要，因为两种模式服务于不同的运维需求。传统安装为频繁的软件包变更和直接的系统定制提供了灵活性，而不可变安装则优先考虑可预测的更新、回滚能力以及更严格受控的基础操作系统。

两种方案并非普遍适用。合适的选择取决于系统是用作交互式工作站、通用服务器、容器主机还是专用设备。

新的安装模式已集成到 Agama 中，这是随 Leap 16 一代引入的安装程序。用户无需单独安装镜像或进行复杂的安装后转换流程，而是可以在安装设置期间选择自己喜欢的操作系统模式。

Agama 提供了现代化的安装工作流，旨在同时支持交互式和自动化部署。在 Leap 16.1 中，安装程序提供标准安装和 Immutable Mode 之间的选择。标准选项创建一个具有可写根文件系统的传统 Linux 环境，而不可变选项则配置只读根并启用事务性系统管理。

一个重要限制是，安装模式在安装后无法更改。安装传统系统的用户无法稍后通过配置开关直接启用 Immutable Mode，不可变安装也无法通过安装程序直接转换为传统安装。

这使得初始选择对于规划长期部署的管理员尤为重要。经常需要直接修改系统软件包的开发工作站可能更适合传统模式，而从受控更新中获益的设备或容器主机则可能更适合 Immutable Mode。

（原文较长，此处译出前 6000 字，完整内容请点「打开原文」。）