置顶文章

感谢原插件(WikimoeBangumi)的创作者 广树,我所做的仅仅是在其基础之上进行了些许改动而已。不想看废话的,就请直接拉到最后。最近更新1.0.0.2504, 2025.4.4更新修正了...

3.0版本上线!大改版,简约同时更实用!建议一定更新!我一直很喜欢一种网页风格:没有排版,也没有华丽的装饰,各种文字信息以较高密度呈现在观看者眼前的风格。后来我逐渐意识到,这种风格十分偏向于千禧...

最近更新

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

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

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

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

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

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

那么,这样的发行版存在吗?

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

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

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

通过官方给的示意图:

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

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

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

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

终于,所有工作都搬到我的Arch下面了,所以我把我的磁盘重新分了一遍区。这样一来分区更清晰,完全遵循了Linux 的文件管理习惯。但是因为我的电脑安装了三块硬盘,所以对一部分分区做了LVM,便于...

直播推流是离不开ffmpeg组件的。尤其像我这种全天推电视剧的直播间。而我不可能一直在我的电脑上开着直播(这不现实),所以我需要一台最基本的服务器来维持它。而一般的服务器默认都是配置CentOS...

闲来去读DDE-Dock的代码,发现了一点儿东西,可以把颜色换成亮色,很简单。从GitHub上下载DDE-Dock源码包前往GitHub,搜索 DDE-dock ,可以找到 linuxde...

商店中的OBS版本实在不敢恭维…尤其到了15.7以后,推流总会闪退。遂想到来自己编译最新版本的OBS。而本着服务大众的理念,便将其打包成Appimage格式,便于传播的同时还可以避免各种依赖的问...