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 目前仍处于测试阶段。因此，这次把它装在这台电脑上，也算是对这个版本做一个长测。后续更细节更实际的体验，再慢慢记录。

转眼都到了2024年了。回看一下2023年，我居然发布了整整16个乱七八糟的内容，我实在太勤奋了。

那么，作为一个以类unix系统教程碎片为主的频道，在新年之际跟你分享一下2023年的一些变化。

更新频率降低的最主要原因就是莫名其妙的没有太闲着，而没有太闲着导致的结果就是很少打开家中常用的电脑，而不用家中电脑就意味着我这一年实际上很少使用Linux或者macOS系统。可以说，我在2020年换掉archlinux时候的预言在2023年得到了完美的体现。属实是：不是不报时辰未到。

但即使使用的频率很低，我还是将ubuntuunity更换到了Debian12。这可能是我这一年中最大的一个更改，这其中的具体原因我也有分享过，可以回看一下。

提到了乌班图，这让我想到了2023年乌班图的一个改变人生轨迹的变化：引入了基于flutter的应用商店。这项调整体现在了前几个月发布的乌班图23.10版本中，用以替代老朋友——乌班图软件中心。相对来说，新版本的商店有着更现代、更流畅、更一致的使用体验，可能也会助力乌班图全局snap化的布局。

可能你觉得使用flutter开发应用商店与全局snap化没啥关联，不过乌班图在2023年2月宣布，官方版本不再支持flatpak格式软件包开箱即用你又如何看待呢？很明显，乌班图为了推广并应用自己发布的snap格式软件包在自己的系统上不遗余力，撤销开箱支持flatpak可以说是最明显的一项措施。不过仅仅是无法开箱即用，你还是可以手动部署相关的程序以恢复flatpak支持。

顺带一提，即将推出的ubuntu24.04为长期支持版本也有一个新的变化，那便是它将可以获得长达12年的更新支持——当然，这需要你注册ubuntu pro。不过这项服务对于个人用户来说是免费的，如果你习惯并长期使用乌班图的话，安装这个版本并加入ubuntu pro也不失为一个好的选择。

你方唱罢我登场，与ubuntu所处的Debian分支相对的，则是RHEL分支中一个改变人生轨迹的变化：RHEL与2023年中旬宣布限制其源码访问。现在看来这个大概是转变CentOS性质的接续步骤：目前的CentOS完全可以说是RHEL的测试版，而曾经的CentOS则可以看作是RHEL的免费版。两者位置的变更似的RHEL可以将全部精力投入到企业客户上，而无需再考虑普通用户。这个消息在刚发布时反响剧烈，不过就目前来看，这更多的改变了RHEL下游发行版的生存轨迹，对于其他分支，甚至RHEL本身的企业用户来说，影响不大——暂时不大。

现在从发行版层面剥离出来，看看内核层面改变人生轨迹的变化：支持周期从六年缩短至两年了——我是说LTS内核。这个变化大概对用户来说影响不大，毕竟现在常见的发行版，要么像SuSE，不更新内核主版本，但自己长期单独维护，以至于跟用新内核没啥区别；要么就像Arch，有新的就直接给更新上来了。但支持周期的缩短对与内核维护人员来说可是重大利好——再也不用管理那么多没啥人用的旧版本内核了。

上面这些2023年Linux世界的变化是好是坏还请各位评判。不过，Linux版Steam使用率超过macOS，从哪种角度来看到可以算是2023年Linux世界一个不错的消息吧——当然了，这俩货加起来都追不上Windows的零头，不过，这至少证明Valve这几年在Linux游戏领域所做的不懈努力不是白费的——要知道，为了能让Linux运行Steam 中大多数的游戏，Valve从大概疫情前便开始基于wine来开发Linux 的游戏兼容层proton，并在这些年中取得了极大的进步。截止目前，Steam上热门游戏通过官方测试可以运行的已经超过了10000款，而根据玩家的测试，这个数量可以上升至大约17000款。我想这对于一名普通玩家来说已经不是一个小数字了。

但诚然，目前这个兼容层还不是十全十美：比如联网游玩的游戏，反作弊插件目前还无法正常运行。但车到山前必有路，由于Valve的proton套件是开源的，因此针对部分特定游戏，有个人开发者定制了proton套件，使得可以通过定制版套件达到正常运行带有反作弊插件游戏的目的。不过这些仍只是个例，Linux联网游戏任重而道远。

以上便是跟各位分享的2023年Linux世界的一些重大的、改变人生轨迹的变化。祝各位能在这曲里拐弯的人生中好好生活。