openSUSE Slowroll 这个系统，我也断断续续用了快两个月了。经过这段时间的使用，我发现慢滚这个东西，很难用一句话概括：你说它激进吧，它偏偏又叫“慢滚”。但你说它稳定吧，它又经常在一些意想不到的地方给你来那么一下。

所以今天就简单聊聊，经过这段时间使用之后，我的感受。

首先是安装。

目前慢滚的安装介质有个很离谱的问题：它不能被 Ventoy 正常引导。也就是说，Ventoy 这个几乎已经成为 Linux 用户默认工具的 U 盘方案，在这里直接失效了，最后只能老老实实的把 ISO 直接刻录进去。

这件事本身不算严重，但它会立刻给人一种感觉：这个发行版，好像跟主流 Linux 用户生态之间，存在一点微妙的错位。别人都已经默认 Ventoy 了，它还停留在“请正确烧录镜像”的年代。

然后，系统装好了。接下来第一件事，当然是更新。

结果更新直接报错：

Access to requested URL is forbidden

第一反应还以为是网络问题。结果打开镜像站一看，发现不是我有问题，而是镜像根本没同步完。等镜像站同步完成之后再更新，问题就解除了。

事情到这里，本来还能理解：毕竟是镜像同步，延迟问题多少都遇到过。结果下个月更新发布之后，同样的问题又来了，而且这次更离谱：等了半个月，镜像依旧没同步完整。

最后的解决方案非常具有 Linux 精神：不用国内镜像了，直接挂代理，把下载源分流到海外服务器。不过，这个其实未必算 Slowroll 自身的问题，更像是国内镜像站对它的同步优先级比较低。

当然，Slowroll 还是有优点的。

因为它的很多设计，都能明显看出它的“工程化思维”。

比如第一次打开 YaST 软件管理的时候，它会自动检测系统状态，并且建议安装一些额外组件，甚至能自动添加两个十分有用的软件源：

• Slowroll 自己的软件源
• NVIDIA 专有驱动源

而且如果安装系统时选择启用在线源，这一步甚至会自动完成。

这个体验其实相当不错——特别是针对英伟达专有驱动。因为很多发行版的 NVIDIA 驱动安装，本质上还是一场 Wiki 阅读理解考试。而 openSUSE 会自己发现你缺什么，然后尽量帮你补全。理论上来说，非常现代化。

但这个补全，想必有些朋友会感觉有点熟悉。

对的，之前就有提过这个英伟达驱动安装问题：从发布 590 版本驱动发布之后，openSUSE 开始自动给你挖坑了。

就像之前提到的，安装完专有驱动源后，重启系统，再次打开 YaST 软件管理，这时候系统会自动帮你选择 NVIDIA 专有驱动。但它自动选择的，是旧版 G04 驱动相关组件。而且不仅如此，它甚至还准备把 kernel-default 一起降级。如果你直接按照自动勾选进行安装的话，会直接得到安装失败的结果，于是整个 NVIDIA 驱动直接不可用。

至于解决方法，我之前也说过，就是不接受自动安装，手工选择全套的 G06 专有驱动即可。也就是说什么呢，系统自动化做了 90%，最后 10%，突然开始朝反方向狂奔。

这种感觉非常 openSUSE。它不是不会自动化，而是自动化得很积极，甚至能自动化到直接把你送进沟里。

经典YaST。

就目前我的使用来看，YaST 更新这个组件基本不可用。它会提示“未配置更新源”。

但原因其实不难理解。因为 YaST更新这个组件的逻辑，本来就是针对 leap 版本的 cve 更新——也就是执行 zypper patch 获得的内容——而设计的。但 Slowroll 本身属于风滚草系列，不存在这种更新。所以理论上，真正适合 Slowroll 的更新方式同风滚草类似，直接通过 YaST 软件直接进行软件包的升级即可。

但也仅仅是理论上。因为通过 YaST 软件这个组件获取到的升级结果，跟终端执行 zypper dup 的结果有出入。

当然了，之前内容也提到过， suse 实质上已经舍弃了 YaST ，并针对软件包管理推出了替代程序：梅林。不过目前就我个人对比来看，同样不建议用这个来更新系统。因为它得到的结果跟 zypper dup 依然有出入。于是整个系统的更新流程，最后又回到要在终端执行sudo zypper dup来完成。

换句话说：最后最可靠的方法，还是命令行。

所以你会发现，Slowroll 很神奇。它一边努力降低 Linux 使用门槛，一边又在关键地方告诉你：“真正能解决问题的，还得是终端。”

接下来，关于引导程序。

openSUSE 在 2025 年末，开始逐渐从传统 GRUB2-EFI 切换到 GRUB2-BLS。

这个变化本身挺符合现在 Linux 世界的发展趋势。但它有个副作用：新的方案会把所有内核文件直接放进 ESP 分区。于是问题来了。ESP 分区如果太小，系统就可能出问题。因此现在基本需要一个大于 1GB 的 ESP 分区，用起来才比较稳妥。对于很多老机器、旧分区方案来说，这其实是个潜在雷点。很多人——包括我——装 Linux 甚至 Windows 时，顶多给 ESP 分个 300MB 就完事儿了。但谁能想到几年之后，一个引导分区都能开始膨胀。

当然，这只是一个新的默认选项。在安装系统时，记得将引导程序手工选择回 GRUB2-EFI 就可以。但这个变更很不起眼，使得在后期发现内核更新失败的原因是 ESP 空间不足，想调整的时候会比较麻烦。

另外，关于虚拟化。

对于 KVM，我之前也专门聊过。就是我这边安装 KVM 组件之后，虚拟机默认无法联网。需要编辑/etc/libvirt/network.conf，去掉 firewall_backend = "iptables"一行的注释，然后再去 YaST 防火墙里，给 libvirt 区域放行服务。这套操作完成之后，网络才恢复正常。

这个问题倒不一定是 Slowroll 独有，但它再次体现出一个特点：openSUSE 很喜欢“提供完整能力”，但默认配置，未必真的是开箱即用。

至于 VirtualBox

目前有一个潜在问题：它的内核模块更新速度，未必能跟上 Slowroll。

这不一定是每个月都会出现的情况，但我尝试安装的那个月，它会顺带着降 kernel-default 的版本。但造成如此的原因可能很有意思：慢滚从风滚草同步快照的时候，正好同步到了一个“系统内核已经更新，但 VirtualBox 模块还没跟上”的时间点。假如真是如此，就会有一个很别扭的结果：可能风滚草侧在 slowroll 推出本月更新的第二天就将 vbox 的内核模块版本更新了，以至于风滚草用户直接再滚一遍即可解决。而慢滚的每月更新特性，使得慢滚用户得等到第二个月发布新快照时才能得到匹配的 vbox 模块版本。这在一定程度上，反而让慢滚显得不如风滚草可靠了。

总的来说，两个月用下来，我对 Slowroll 最大的感受其实是：它不是“不稳定”，而是“系统逻辑还在磨合”。你能明显感觉到它想保留 openSUSE 的传统，又想获得滚动发行版的新体验。于是最后形成了一种非常独特的气质：它不像 Debian 那样保守稳定，也不像 Arch 那样彻底激进。

伴随 suse 的策略调整，让它——也可能是风滚草全系列——都更像一个正在转型中的系统：很多地方已经现代化了，但还有很多旧时代的逻辑残留。于是你会经常遇到一种很割裂的画面：前一秒还是自动化图形配置，后一秒突然需要你手改配置文件来补齐。

但即使踩了这些坑之后，我依然会感觉：Slowroll 可能是目前 Linux 桌面里一个方向很特别的发行版。因为它正在尝试的，是获得一种“保持新，但稍慢一步”的节奏。

安装一个全新的发行版之后，首先就是要装好英伟达显卡驱动。不过对于openSUSE Slowroll来说，这是个又简单又困难的操作。

先根据我使用发行版的经验，给安装英伟达专有驱动的繁琐程度简单排个序吧。

Archlinux大概是常见发行版里边最简单的，直接pacman -S即可完成。

Debian系则需要先启用non-free源，更新仓库之后通过apt安装，感觉上会稍微繁琐一点点。

Debian的重要衍生版本：乌班图，则提供了附加驱动图形界面，可在这里切换英伟达驱动版本。但在我曾经使用乌班图的时候，这个附加驱动功能还不能保证100%成功。所以虽然看起来简单，但由于没有最新的体验，因此没办法给它排进来了。

至于红帽系，以fedora来说，同Debian类似，先开启non-free，更新仓库后通过dnf安装驱动。

openSUSE则是巧妙的简化了这个操作。

先看增加英伟达驱动源的这个过程。如果是使用 YaST 安装程序的系列，且在安装过程中启用了在线软件源，那么安装完成后，英伟达的源就已经自动添加好了。

如果安装时没有启用在线软件源，那么安装好系统后第一次打开YaST软件管理，它会自动勾选好一些推荐安装的包，而这其中就有英伟达的软件源。此时直接接受安装，源也就自动添加并启用好了。

接下来是安装。无论是如何添加的驱动源，总之在添加源后第一次打开YaST软件时，它又会自动勾选好一些包，这其中就有英伟达的专用驱动了。直接接受安装即可。

如此看来，openSUSE好像是最简单的？毕竟比Arch还进一步，只需鼠标点两次接受就能完成。

在英伟达发布590版本驱动之前是这样的，590之后出现了一些小问题：关联的包出现偏差了。

590伴随着一个变更：开源了部分驱动内容，且放弃了帕斯卡架构以前的显卡支持。因此多数发行版都新增了nvidia-open包以与前序驱动区分。

openSUSE是类似的，只不过它是按照它的命名方式，增加了一个G07系列驱动。我的显卡正好可以使用这个驱动，所以YaST默认勾选的它。但它关联的包有些问题：大量的G04包被作为依赖选中了，这使得并没有办法通过无脑接受来完成安装。那需要如何操作呢？

还是在YaST软件，打开后不要直接接受，先取消所有关于英伟达的变更，手工勾选nvidia-driver-G06-kmp-meta包，它会自动勾选所有与G06驱动相关的软件包。换句话说，放弃最新的所谓“开源”驱动，使用最后发布的纯闭源驱动来规避这个问题。

为何会导致这种情况呢？在openSUSE的论坛里存在关于这个问题的帖子，但并没有最终答复。所以也只能看后续再有重大更新时，能否调整好这个依赖关系问题了。

KVM虚拟机可以说在Linux中是一套十分成熟的套件。在suse中，它可以很简单的安装好，但好像又没那么简单。

首先是安装。有两个方式，但无论哪种，都先打开YaST吧。

第一种，控制中心有一个虚拟化专区，这里可以直接点击安装KVM选项即可进行全配件的安装。

另一种，打开YaST软件管理，进入到“模组”标签页。如果没有这个标签，可以通过“视图”按钮添加。在这个标签页下，直接勾选“KVM主机服务器”软件集——接受，等待安装完成就可以了。

现在，你可以打开libvirt这个图形化的虚拟机管理器了。但试试就会发现：虚拟机连不上网——这是我在slowroll下发现的问题。如果你在使用Leap 或者风滚草本草，可以试试是不是有相同的情况。如果有同样问题，那么就需要进行一些配置操作了。

原因其实很简单：防火墙阻止虚拟机的网络连接了。因此放开相关策略即可。但首先我们需要配置一下libvirt自己的防火墙策略：

1. 用文本编辑器打开/etc/libvirt/network.conf
2. 将firewall_backend = "iptables"最前面的注释符号去掉，保存

然后，配置系统防火墙。还是在YaST里：

1. 打开防火墙组件
2. 点击接口—自定义，弹出的窗口中，区域选择“libvirt”，接口输入libvirt 中的虚拟网卡名（默认应该是“virbr0”），确定
3. 点开区域中的libvirt，确认右侧至少有dhcp、dhcpv6、dns、ftp、http、http3、https、imap、imaps、proxy-dhcp、telnet、tftp。至少目前我使用下来，允许这些就已经不会出现莫名连接不上的问题了。如果你有特殊的使用场景，也针对性的添加即可。
4. 接受，保存防火墙配置。

到此，一个正常可以联网的KVM虚拟机套件就安装完成了。

openSUSE在Leap上启用了全新安装器，且舍弃了YaST。借着安装虚拟机的机会，来看看。

先解释一个问题：为什么要在suse里再安装一个suse虚拟机？一句话回答：需要一个纯净的系统，以便维护OBS仓库。
接着，给不使用suse的朋友简单介绍一下YaST是什么。

YaST界面

依然一句话概括：Windows控制面板在图形Linux中的实现。几乎你能想到的各种需要终端才好完成的设置，在这里可以图形化解决。
最后，来看看传统的suse安装程序是什么样。

旧系统安装界面

我的评价就是：典型的线性设定流程、高度的系统组件及环境自定义性、以及完全面向桌面设备的界面设计。

那么，如今的安装程序是什么样子呢？

新系统安装界面

这个安装器名字叫Agama，基于web技术实现。直接把鼠标顶到顶端就可以直观的发现，安装过程直接运行在火狐浏览器中。

指针顶到顶部，可激活火狐窗口功能

如此设计带来一个直接的变化：如果安装过程中需要访问互联网，可以直接新开标签页，而不再需要拿起另一个硬件来完成了。

但相对于传统安装器来说，新的安装器暂时没有老安装器那么高的自定义性，且弱化了线性设定流程，仿佛刚进入安装程序就已经可以直接点击安装来部署系统了。

概览页变可直接点击安装按钮，此时才会弹出未设定内容提示

就个人的使用体验来说，还原以前的自定义性都是次要，将必要步骤放在安装程序“必须设定”的流程中还是有一定的优化空间。

接下来，舍弃YaST这个操作。从社区讨论得知，有一个只有YaST自己使用的C++-Ruby绑定，维护的性价比很低。因此目前Leap的新版本已经舍弃了YaST图形界面，转而提供了梅林和Cockpit来部分替代YaST原有的功能。

但就我个人—可能也是一部分桌面版SUSE用户—来说，YaST可以说是openSUSE相比其他发行版一个最独特的优势。在我前面发布的内容中，评论就有提到SUSE跟红帽的功能存在一定重叠。舍弃YaST就SUSE来说，也许是可以降低相当成本的。但如此“降本增效”之后，进一步减少了同红帽的区别，那由此产生了一个问题：使用RPM包的发行版，为什么要选择openSUSE而不是红帽或其衍生呢？

不过，风滚草系列目前还是保留有YaST的。只能说希望在风滚草系列也完全去除YaST之前，SUSE能推出一个替代性的“控制面板”，以一定程度上维持SUSE这个独特产品吧——虽然可能性不大。

虽然现在存储价格不低，但这台电脑还是被我修好了。既然系统重装，那就又回到了一个老问题：该选哪个发行版？

滚动更新的发行版，更新频率高，但组件变化快，系统在一段时间内可能出现不稳定。而按版本发布的发行版，整体更稳，但在跨版本升级时，同样存在失败的风险。

那么，有没有一种介于两者之间的更新模式？既不过于激进，也不至于滞后。

你可能会想到 Manjaro。它基于 Arch Linux，会先对上游更新进行一段时间的测试，再推送到自己的仓库。

但它本质上并不是由 Arch 官方维护。在我有限的使用过程中，偶尔会遇到组件之间配合不够顺畅的情况。

如果从这个角度来看，一个更理想的前提是：发行版本身就同时提供滚动和版本两种更新模式。在这样的体系下，才有可能衍生出一种更“折中”的官方方案。

那么，这样的发行版存在吗？

确实存在。比如我之前提到过的 openSUSE。

而现在，它不仅提供两种模式，还进一步引入了一种更接近“又新又旧”的方案：Slowroll。

这个分支基于 openSUSE Tumbleweed 的滚动更新机制，但显著降低了更新频率。

通过官方给的示意图：

可以清晰的看出来Slowroll 以月为单位发布快照，每一次更新都整合了当月内通过测试的 Tumbleweed 变更。

这种方式带来的结果很直接：更新节奏被控制在一个更可预期的范围内，同时依然能够跟进上游的新版本。在稳定性上，也比 Tumbleweed 更进一步，并且避免了 openSUSE Leap 那种跨版本升级带来的潜在风险。

如此看来，Slowroll确实提供了一种介于两者之间的选择。

当然，需要说明的是，Slowroll 目前仍处于测试阶段。因此，这次把它装在这台电脑上，也算是对这个版本做一个长测。后续更细节更实际的体验，再慢慢记录。

转眼间已经2026年的二月份了，马上春节的假期也要过完了，在这儿还是先跟各位拜个晚年，祝各位晚年幸福。

接下来就跟前两年一样，看看2025年的 Linux 世界又都发生了什么。

一、Wayland 差不多成为图形界面唯一的协议

过去几年，Wayland 一直被描述成“未来”。到了 2025 年，它基本已经成为图形Linux的默认方向。

就以主流的两大桌面环境：GNOME 和 KDE Plasma 来说，Wayland 是所有新特性设计的前提。虽然 X11 会话仍然存在，但更多的只是维护状态，不再承担创新。

这意味着一件很现实的事：

桌面版Linux 的显示系统已经完成了主线的切换。虽然目前你依然可以使用熟悉的X11，但终究也要慢慢去接受Wayland了。我在去年也简单尝试过 Wayland ，如果有兴趣的话可以看看。

二、英伟达的妥协

早年间，我有一个妥协系列，大概内容就是讲某一个软件或者厂商开始了 Linux 适配这个动作。其中提到过百度网盘、steam、QQ等等。现在想来，如果我把早年间制作的这个妥协系列延续下来，那去年英伟达驱动的妥协大概会是一个重磅的更新。

以Archlinux为例，它在去年开始提供一个名字为 nvidia-open 的官方驱动包。

这是英伟达官方提供的开源驱动。只不过，目前它的开源模式是内核态 GPU 模块开源、用户态驱动仍然闭源。

它并不像AMD那样完全开源，但目前的开源动作对于桌面 Linux 来说，已经足够产生一些有益的变化。特别是在 Wayland 环境下，多显示器、高刷新率、休眠恢复这类长期由于英伟达闭源驱动而影响稳定性的功能，第一次可以进入“系统性优化”的阶段了。

显然，这并不是一夜之间就能改变的，但至少改进方向可以明确了。

三、完全向前看的KDE Plasma 6

你也许会还记得，在我的硬盘完全损坏之前，我把我的系统切换到了 Debian13，其包含了 KDE6 图形界面。而2025年，也是KDE6逐步走向稳定的一年。这次升级的核心不在外观、插件，更多的在于底层结构：全面转向 Qt 6、完全以 Wayland 为前提设计、清理多年遗留的 X11 兼容负担。

如此重大的转变，使得KDE6 的早期版本确实不稳定，且大量的插件也需要重新适配。但换来的，是一个更现代化的桌面基础，后续发展也不再需要背负过多的历史包袱了。

四、KDE 更专业了

依然是 KDE。在技术基础逐步稳定之后，其在专业领域的表现也有所进步。如高 DPI、多屏、色彩管理、精细窗口规则等能力持续完善。这使得KDE不再只是“折腾党”的玩具，亦成为专业群体可以选择的稳定环境之一。

总的来说

2025 年的Linux，没有出现颠覆式的革命。但针对图形界面的几个关键节点现在大概可以确定了方向：显示协议主线明确、显卡驱动的生态开始松动、桌面环境完成了一次跨时代的清理。

2025年的变化并不会立刻改变所有人的使用体验，但其可以决定未来几年图形Linux的发展路径。

至少在图形界面，Linux又向前了一步。