当前位置:首页>Linux>Linux 最新资讯 20260131——GNOME 50 不再将可变刷新率(VRR)视为实验性功能

Linux 最新资讯 20260131——GNOME 50 不再将可变刷新率(VRR)视为实验性功能

  • 2026-10-08 22:11:50
Linux 最新资讯 20260131——GNOME 50 不再将可变刷新率(VRR)视为实验性功能
Open Source Daily
开源技术资讯 · 开发者必读
📅2026-01-31
📆星期六
📰3 篇
01
               GNOME 50 不再将可变刷新率(VRR)视为实验性功能             

GNOME 50迎来了一项虽迟但重大的改进:面向现代显示器的可变刷新率(VRR)功能现已升级,不再作为实验性功能对待。

回顾GNOME 46,可变刷新率支持一直处于实验阶段。经过两年作为实验性功能的隐藏期后,该功能在GNOME 50中被认定为稳定功能。在当前版本中使用GNOME VRR需要先执行 gsettings set org.gnome.mutter experimental-features "['variable-refresh-rate']" 命令,随后可变刷新率选项才会出现在显示设置中——前提是用户使用的显示器支持可变刷新率运行。

Michel Dänzer提交了将VRR从实验状态升级的合并请求,并在请求中评论道: 

"经过近期改进,VRR在大多数系统上应能良好运行。虽然极端情况仍可能存在(特别是对于VRR支持不佳的显示器),但该功能默认仍处于关闭状态,需在显示设置中手动启用。若在特定系统上运行不佳,建议暂时保持关闭状态。

同时修复了开发过程中发现的若干细微问题。" 

截至今日上午,该合并请求已及时并入Mutter Git仓库,将随GNOME/Mutter 50测试版发布。 

GNOME VRR仍有部分改进待完成,例如VRR光标处理的优化以及与VRR配合的截止时间定时器应用。但即使这些改进尚未合并,现有的VRR支持已足够成熟,最终在GNOME 50中摘掉了实验性功能的标签。

此次升级使GNOME VRR支持默认出现在显示设置中,用户若想在现代硬件上使用动态刷新率功能,仍需手动启用该设置。

---
02
               AI代码审查提示倡议在Linux内核方面取得进展             

长期从事Linux内核开发、以创建Btrfs文件系统而闻名的克里斯·梅森,近日致力于构建一个包含AI审查提示的Git仓库,旨在通过大语言模型辅助Linux内核补丁的代码审查。这项计划已持续数周,最新进展已于今日发布并征集反馈。

克里斯今日在Linux内核邮件列表中写道: 

"对于正在使用这些提示词的用户,我希望获得关于今日推送改动的反馈——这些改动将审查流程拆分为独立任务。原有提示均保留完整,因此我们可以从耗时、tokens成本和实际效果三个维度直接对比两种方案。

采用任务分解机制后,我们能够将大型代码差异拆分为小块,并逐块进行审查。这种方式在多数情况下能显著减少tokens消耗,因为我们无需在每轮交互中为整个差异反复传递上下文。同时该机制还能更全面地捕获代码缺陷。

我使用Python脚本进行代码变更的拆分与批量处理,以提取修改后的函数、类型及调用关系图。这也有助于降低tokens使用量——我们只需指示AI批量加载处理结果,而非让其自行重复发现相同信息。当前脚本可能存在缺陷,后续必然需要持续优化。

节省的tokens有望抵消额外消耗。每个任务拥有独立的上下文窗口,因此当差异中不同文件需要加载相同函数时,针对单个文件的研究成果需重复执行。虽然AI供应商的令牌缓存机制能部分缓解此问题,但我特别期待关于这部分的反馈。

新框架包含以下任务类型:

- 代码块审查 

- 历史邮件列表线索核查(若语义代码可用) 

- 修复标签校验 

- 深度分析Syzkaller修复方案(详见后续说明) 

- 生成最终审查报告"

这位Meta工程师正倾注大量精力提升AI/大语言模型辅助代码审查的准确性与实用性,以期更好地服务于Linux内核上游生态。该方案已显现积极成效,按照当前发展节奏,未来有望在Linux内核代码审查中发挥重要作用。

对克里斯·梅森针对Linux内核及systemd代码审查的AI辅助提示感兴趣的开发者,可通过此GitHub仓库获取相关资源。

---
03
               Ubuntu 26.04 LTS 仍将采用 Linux 6.20~7.0 内核版本,即使其未在发布前完成最终定版             

去年,Canonical承诺在新版Ubuntu发行时搭载最新的上游Linux内核版本,这相较于此前版本中较为保守的选择有所不同——过去的策略并不总能与最新的Linux内核上游保持良好同步。早在去年12月,他们已确认Ubuntu 26.04计划采用Linux 6.20~7.0内核,这一计划至今未变,即便这意味着稳定的Linux 6.20~7.0正式版可能无法在初始ISO发布时准时推出。

由于年末假期的影响,当前的Linux 6.19开发周期将延长一周。考虑到假期安排,为稳妥起见,原定于上周发布v6.19-rc7后于本周日发布的计划已调整为发布v6.19-rc8。Linux 6.19稳定版将于2月8日发布,但这给Linux 6.20~7.0内核周期以及Canonical计划于4月23日正式发布Ubuntu 26.04 LTS带来了额外压力。

如果下一个内核周期不需要发布-rc8版本,Linux 6.20(或更可能被称为Linux 7.0)将于4月12日发布。但若下一周期需要额外的候选版本,稳定内核的发布时间将推迟至4月19日。这已超出Ubuntu 26.04原定于4月16日的最终代码冻结日期。官方内核冻结日期也标记在4月9日。

尽管时间紧迫,Canonical内核团队的Kleber Souza重申了团队对在4月发布的Ubuntu 26.04中搭载这一最新内核版本的承诺。Souza指出,考虑到时间冲突,这可能意味着需要通过"第0天稳定发布更新"(SRU)来推送最终的非候选稳定内核版本: 

"类似于我们为[25.10] Questing Quokka版本所做的,Canonical内核团队计划在内核冻结里程碑之后,继续基于上游候选版本和最终版本对Ubuntu内核进行重构,以便快速为用户提供基于上游最终版本的内核更新。我们将此次更新称为'第0天SRU',目标是在常规SRU周期开始前发布。我们的目标是在26.04最终版本发布后尽快推送此更新,但目前尚无法承诺具体日期。" 

相关细节已于今日在Ubuntu Discourse中公布。

<OpenSource/>
感谢阅读
每天推送最新开源技术动态
// Source: Phoronix

最新文章

随机文章