niri v26.04 发布了。

它是一个 scrollable-tiling Wayland compositor。窗口按列排在一条向右延伸的“无限带”上，新窗口不会把旧窗口挤小。这是 niri 最核心的差异。

这次版本最容易被看到的是 blur。最该被记住的，是项目迁入 niri-wm GitHub 组织。仓库已经超过 2 万 star，热度上来后，个人账户式维护会越来越吃力。

v26.04 改了什么：blur 抢眼，组织迁移更硬

blur 是 GitHub 上呼声最高的功能。它此前由 visualglitch91、Naxdy 等人在社区 fork 中长期维护，现在进入主线。

这对普通用户很直接：如果你之前为了 blur 去用 fork，现在可以开始评估回到主线。别急着盲升。先看自己发行版的包是否跟上，再检查配置差异。

变化事实影响对象判断
blur 进入主线社区 fork 长期维护后合入想要模糊效果的日常用户补齐强需求，不是桌面革命
迁入 niri-wm 组织从 YaLTeR 个人账户迁走贡献者、维护者、报 issue 的用户权限开始分层，维护不再全压一人
周边项目归拢awesome-niri、artwork 等迁入组织新用户、文档整理者、社区贡献者小生态有了统一门牌号
打包要求变化Rust 最低版本升至 1.85，service 文件调整发行版打包者、滚动更新用户升级顺不顺，先看打包链

niri 不是 GNOME、KDE 这种完整桌面环境。它也不是简单复刻 Sway 或 Hyprland。

它押的是窗口组织方式：列式、可滚动、不挤压旧窗口。写代码、查文档、开多个终端的人，会更容易感到这种设计的价值。屏幕上的东西不会频繁被重新切碎。

blur 会让桌面更顺眼，也会让截图更好看。但它不是分水岭。Linux 桌面留住用户，靠的从来不只是视觉效果。输入法、缩放、休眠、崩溃恢复、配置迁移，这些脏活更决定日常体验。

组织迁移说明什么：小项目开始补维护短板

官方给出的迁移理由很具体：为了给社区成员分配 issue triage 权限。Sempyos 等长期处理 issue、PR、答疑和诊断问题的贡献者，也被明确感谢。

这句话比 blur 更重。

开源桌面项目常被看成“功能竞赛”。谁动画更多，谁配置更酷，谁截图更漂亮。可真用起来，拼的是另一套能力：谁来复现 bug，谁来关重复 issue，谁来判断问题在 niri、驱动、协议、发行版还是用户配置。

独木不成林。早期 Linux 桌面生态反复证明过这一点：好点子很多，能长期接住 bug、文档、打包和用户支持的项目少得多。niri 这次做的不是公司化，也没有证据能推到商业化。它更像一次社区治理补课。

对开发者和贡献者，变化是权限更清楚。以前很多事要等项目作者处理，现在至少可以把 triage 这类工作分出去。

对普通用户，变化不会立刻变成“更稳定”。但如果 issue 分类更快、重复问题清理更快、有效反馈更容易被看到，最终会反映到升级体验上。

接下来该盯什么：别只看 star，看维护节奏

niri 超过 2 万 star，说明它被看见了。star 不是用户数，也不是稳定性证明。

更现实的观察点有三个。

  • blur 合入后，是否出现新的性能或兼容性反馈。模糊效果通常会增加渲染负担，但现在不能编造结论，只能看实际 issue。
  • issue triage 权限下放后，问题处理是否更快、更清楚。组织迁移如果只改门牌，不改响应速度，价值会打折。
  • 打包者能否及时跟上 Rust 1.85 和 service 文件变化。普通用户少不受罪，很多时候取决于这里。

使用 niri 的普通用户，最稳的动作是等发行版包更新后再升。尤其是日常工作机，不要为了 blur 抢第一时间。

维护包的人要先看构建链。Rust 1.85 是硬门槛，niri.service 不再硬编码 /usr/bin/，dinit service files 也有重构。这些不酷，但会决定安装、启动和升级是否顺。

我更看重这次权限调整。因为它触到了小型开源桌面项目的真问题：作者写得动，不等于项目撑得住。用户多了，issue 多了，硬件差异多了，靠一个人守门就是堵车。

niri v26.04 少见地把这件事做实了。没有只在发布页感谢社区，而是把仓库结构和权限结构也改了。功能是面子，杂活是地基。桌面项目能不能长久，最后常常死磕这点。