之前，我提到自己停用自建 RSS 服务的事情，而且还说要继续使用 RSS。在综合对比了各种 RSS 阅读器之后，最终选择了Flare，而且还意外地收获了一些增值性体验。来看看。

关于Flare

Flare 是一款开源的社交客户端，它支持多种社交平台，也内置了 RSS 阅读器。目前，项目支持的平台包括微博、X、Mastodon、Misskey、Bluesky 等。这意味着，我们不一定需要为每个平台单独准备一个应用，只需要接入 Flare，就可以在同一个客户端里查看相关内容了。此外， Flare 除了 iOS，也提供其他系统及桌面端版本，适配覆盖得很全面。对于平时需要同时关注多个信息源的人来说，这种整合方式还是挺有吸引力的。

这个项目是开源的，至少在目前，使用这个应用不需要付费。可以直接从官网进入项目页面，查看下载方式和相关信息。

混合时间轴

具体使用不太多介绍，十分简单，自定义能力也很强。主要来看我比较关注的功能：混合时间线。首先，把自己平时使用的账户和信息源接入进来。比如我已经登录了微博账号，可以看到登录成功之后，微博的关注和发现两个信息流就可以在这个应用中展现了。

此外，我喜欢的RSS 也可以直接添加，如此就得到了一个 RSS 的时间线。

但能浏览各自平台的时间轴只能算是在一定程度上有所简化，接下来的整合操作能更进一步改善体验。

直接轻点顶部时间轴选项，选择混合，已经加入到应用中的信息流就会按时间排序到一个整合的时间轴中了，可以直接将不同平台的内容放到一起浏览，不仅不再需要看完一个平台就换一个应用，甚至连时间轴都不需要再切换了。

当然，你也可以通过添加分组，将你想要整合的部分来源单独成册，以满足个性化的整合时间轴。

翻译

除了混合时间轴，Flare 还有一个我比较感兴趣的功能：翻译。如果每次阅读过程中遇到外语都要先复制正文，再切换到其他翻译工具查看的话，整个阅读过程会很凌乱。通过 Flare 则可以直接在应用内完成翻译。进入设置-翻译。

可以看到它提供了三种翻译维度：来源平台的翻译功能、应用提供的翻译服务，还可以接入大模型完成翻译，我们根据需要选择即可。

如果你选择 AI，那么就需要在软件中配置大模型的接口。这个配置也很方便，进入设置-AI，输入地址、密钥，下方选择使用的模型即可。

AI摘要

而且在启用 AI 之后，你还可以额外获得一个总结全文功能。这样，对于长文本的信息——特别是 RSS——你可以直接在时间轴中看到一句话总结，不必每一篇都进入详情页面浏览全文了。

是“社交客户端”，不是阅读器

不知你有没有一个疑惑：为什么管这应用叫“社交客户端”呢？因为对于微博这种既能看又能发的信息来源，从 Flare 登录之后是具备发布内容、管理评论等基本功能的。

不过对我来说

因为我本意只是需要一个 RSS 阅读工具，这应用首先满足了这个基本需要，而大模型翻译、总结是在基本功能上锦上添花，时间线整合更是额外收益，所以即使微博只能看不能写，对我来说也足够了。

但至于它能不能完全取代你目前的使用场景，还是得看你自己，以及它对相应平台的支持程度。不过如果你也只是想找一个能够整合多个信息来源的工具，不妨试试看。

如果你是关注这个博客的老朋友，那么你也许会发现：我这个主题前一阵子出bug了。

起因在这条评论。当时也是工作繁忙，看了一下主页侧栏，发现随机文章模块有在正常显示文章标题，便回复了所谓的“我这儿看没问题”。不过，在正经回复这条评论之前，我看我的首页就总觉得哪里别扭。观摩半天，终于发现端倪。因此我的回复紧跟了一句话：

但是首页新文章预览没有。得空得看看咋回事儿。

这一看，就看了小半年。

而且这个过程中，我也终于意识到为什么说随机文章模块坏掉了——文章链接全部指向首页，并不能成功跳转。

其实我大概知道是为什么——毕竟在很长一段时间里，我对这个博客做的唯一变更就是更新了Typecho到1.3版本。脚后跟也能想到是更新导致的功能损坏。但问题在于：互联网上对1.2、1.3的变更信息记录的太少了，我甚至不知道应该从我主题的哪一个函数下手，只能一点点的尝试，然后愉快的接受失败。

就这样，我开始了长达2个月的7天无休的工作，也顺理成章的忘掉了这个事儿。

直到最近，我的加班结束了，这个问题又回到了我的脑海之中。就在这段时间，我接触到了AI办公，而且真正的帮我解决了很多曾经需要大量手工标记/挑选的任务，极大提升了工作效率。实际上，我的主业并不是搞代码，加之之前接触的那种聊天类的AI幻觉太厉害，所以我自己对AI工作的输出结果可靠性抱有很大的怀疑。但随着办公过程中AI的出色表现，加之AI对自然语言需求的理解能力超出了我的预期，这让我冒出了用AI来修复我博客主题bug的想法。

事实证明：确实修复了，而且即使算上AI的思考时间，全程花费也不超过半小时。

就在这短短的半小时里，AI帮我

• 部署了本地的Typecho1.3环境
• 查看了1.2、1.3核心功能的差异
• 定位并修复了困扰我半年时间的问题
• 修复了数据库兼容性问题

我感觉，我慢慢明白AI的魅力所在了。

大概从 2020 年前后开始，我就一直在使用自建 TTRSS。

那几年，RSS 这个东西在 Linux、开源软件、博客圈子里边还算热闹。很多人会自己搭一个服务，把常看的博客、新闻站、技术论坛全部聚合到一起。我当时也专门出过几期内容，记录怎么搭建 TTRSS，以及自己都订阅了哪些 RSS 源。

那时候，这东西对我来说几乎算是每天必开。但后来，情况慢慢变了。

一方面，是毕业之后工作越来越忙。另一方面，这几年开始骑车上下班之后，原本那些可以坐下来刷文章的时间，也被占掉了不少。于是慢慢地，我不再关注 TTRSS 本身有没有更新，也不再专门整理自己订阅的 RSS 源。甚至很长一段时间里，我都忘了自己服务器上还跑着这么个服务。

直到去年，TTRSS 的原作者宣布停止开发项目。虽然之后有人继续接手维护，但这件事还是突然提醒了我：我已经很久没专门维护过它了。同时我特意关注下手机端，这才意识到：TTRSS 软件图标右上角的那个小红点，已经很久没有出现过三位数了。

这个数字，代表的是未读文章数量。以前随便一天不看，数字都会堆得飞快。但现在，它甚至很难再突破一百。这时候我才意识到：不是我把 RSS 看完了，而是我订阅的很多网站，本身已经不更新了。

后来重新登录网页版看了一圈，发现很多订阅源已经变成了红色。在 TTRSS 里，这意味着订阅地址失效了。有些网站已经关闭，比如 Linux 中国；有些则是改版之后，直接把 RSS 给砍掉了。这就使整个列表看起来非常冷清。

其实这些年里，我不是没想过关掉这个服务，毕竟它已经很久没有真正被使用过了。但人多少还是会有点情怀，哪怕后来已经不会每天专门去刷新文章，也总觉得：“反正服务器还开着，就先放那儿吧。”

结果这一放，就是两三年。直到现在。

一边是越来越冷清的 RSS 列表。另一边，则是 TTRSS 原作者停止开发带来的“时代结束感”，终于让我下定决心，把这个自建自用了快十年的服务停掉。

不过有意思的是，即使到了今天，我依然觉得 RSS 这种东西，本身其实没有过时。至少相比现在各种算法信息流，RSS 这种“主动订阅”的形式，依然有它的价值，尤其是通过订阅综合性网站，去接触一些自己原本不会主动点开的内容。这使得它在某种程度上，确实能稍微打破一点信息茧房。只是如今再去维护一个完全自建、自用的 RSS 系统，对我来说已经没什么必要了。

所以最后，我还是决定换一种方式继续使用 RSS。至于后面会变成什么样，继续观察吧。

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

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

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

你可能会想到 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又向前了一步。

去年十月份，bcachefs 相关内容突然停了下来。

原因其实很简单。

我的硬盘坏了。

那是一个再普通不过的周末晚上。

我正在录制下一期内容，也就是 btrfs 的实际使用。

录制进行得很正常，直到某一个瞬间，图形界面毫无预兆地卡死了。

一开始我并没有太在意。

图形界面而已，Linux 用户对这种场面并不陌生——重启服务，通常就能解决问题。

但当我尝试切换到文本模式的时候，情况开始变得不对：键盘没有任何响应。

系统不是图形卡住了，而是完全冻结。

即便如此，我依然没有意识到事情的严重性。

类似的情况以前也遇到过。

就连 Windows 还有蓝屏的时候呢。

大多数时候，重启就够了。

于是我按下了电源键，强制关机。

重启之后，系统停在了启动画面。

没有报错，也没有继续。

就这么卡着。

我又重启了一次。

结果没有任何变化。

不过这一次，系统至少还能响应键盘输入。

我关掉了启动画面的 Logo，想看看它究竟卡在了哪一步。

这时候，问题终于显现出来了。

屏幕上是一连串读写错误。

从根挂载点，到 home 挂载点。

到这里，结论已经很明确了：我的硬盘坏了。

而且坏得并不突然。

事实上，早在几年前，这块硬盘的 SMART 信息里重映射扇区就已经开始报警。

只是一直抱着“得用且用”的想法，我把它用到了去年十月份。

现在回头看，如果不是深度的安装程序在去年下半年让我不得不多次重新格式化系统，

这个问题，可能还会继续潜伏一段时间。

从这个角度来说，

咱还得谢谢它呢。