Linux 最新资讯 20260327——Ubuntu 26.04 LTS Beta 版本发布;Fedora 45计划获准为的“蓝屏死机”DRM恐慌开发Web前端

Ubuntu 26.04 LTS 测试版已如期发布，现可供测试。在4月23日正式长期支持版本推出之前，这是测试该版本的绝佳机会。

Ubuntu 26.04 "坚毅浣熊" Beta 包含最新的软件包：尚处于开发阶段的 Linux 7.0 内核、默认搭载最新的 GNOME 50.0 桌面组件、全新的 Mesa 26.0 图形驱动程序、Python 3.14、GCC 15.2，以及自去年十月 Ubuntu 25.10 以来的大量其他软件更新。

Ubuntu 26.04 测试版涵盖 Ubuntu 桌面版、服务器版、WSL 及云产品等多个版本，同时还包括 Kubuntu、Lubuntu、Ubuntu Budgie、Ubuntu Studio、Ubuntu Unity 和 Xubuntu 等衍生版本。

用户可通过邮件列表公告获取 Ubuntu 26.04 测试版的下载链接及更多详细信息。

Canonical工程师计划将ntpd-rs作为最新的基于Rust的系统组件引入Ubuntu Linux，以处理时间同步功能。

继Rust Coreutils、sudo-rs以及其他正在进行的Ubuntu相关Rust项目之后，Canonical计划在Ubuntu Linux上采用ntpd-rs作为网络时间协议（NTP）和网络时间安全（NTS）协议的Rust实现方案，以提供客户端/服务器支持。此举有望使ntpd-rs替代Ubuntu当前用于时间同步的Chrony、LinuxPTP和GPSD等工具。

这项ntpd-rs的采用计划将针对"即将发布的Ubuntu版本"实施。由于距离Ubuntu 26.04 LTS发布已不足一个月，这意味着它不会出现在下一个长期支持版本中。官方计划是在Ubuntu 26.10中提供ntpd-rs，但默认配置的变更预计要到明年的Ubuntu 27.04才会实现。

采用ntpd-rs的目标在于提升系统安全性和整体用户体验。关于Ubuntu Linux中ntpd-rs计划的更多细节，可通过今日发布的Ubuntu Discourse公告获取。若需深入了解ntpd-rs，可访问Trifecta Tech项目网站。

距离Fedora 44正式发布仅剩数周，针对2026年末发布的Fedora 45版本的功能规划与开发工作已悄然启动。在早期获批的功能中，一项针对DRM Panic"蓝屏/黑屏死机"功能的新型网页前端特性引人注目——该功能将专门为内核错误生成定制化二维码。

主流内核中的DRM Panic功能已被证实能有效在内核恐慌等故障发生时，向终端用户展示更直观友好的可视化信息。该功能还支持扩展特性，例如将内核日志编码为二维码，相比当前屏幕帧缓冲器的有限显示空间，这种方式能更便捷地捕获系统输出信息。目前上游绝大多数DRM/KMS内核图形/显示驱动程序均已集成DRM Panic支持。

与简单将原始内核日志编码为二维码的传统方案不同，今年早些时候Fedora社区提出创新构想：在二维码中嵌入定制化链接，指向精心设计的Fedora专属网页。该页面不仅会清晰展示内核日志，还提供诸如指导终端用户如何提交Fedora错误报告等辅助功能。

这意味着当用户通过移动设备扫描Fedora恐慌界面的二维码时，将被引导至特制的功能型网页。

以下是今年早些时候原型实现阶段展示的DRM Panic网页界面示例：

本周，Fedora工程与指导委员会（FESCo）正式批准了这项针对Fedora 45的变更提案。若实施过程中在十月份之前未出现重大技术障碍，用户将能在F45版本中体验到这款更人性化的Fedora DRM恐慌界面及网页前端系统。

本周获批的Fedora 45 另外早期特性之一是在NetworkManager中启用IPv6-mostly支持，以提供更现代化的开箱即用网络体验。

IPv6-mostly 是一种主要运行于IPv6网络、同时为需要传统支持的设备保留IPv4连接的网络方案。它在完整的双栈IPv4/IPv6网络与纯IPv6网络之间取得平衡，通过DHCPv4选项108和464XLAT CLAT技术，在减少IPv4地址消耗的同时保持对传统设备的网络支持。

这种渐进式过渡方案为最终实现纯IPv6网络提供了缓冲路径。Fedora 45计划默认在NetworkManager中启用IPv6主导选项，在推进IPv6主导部署的同时保留必要的IPv4支持，避免网络中断。

相关技术细节可参阅IPv6主导功能的F45变更提案。本周Fedora工程与指导委员会已正式批准这项计划，该特性将随今年晚些时候发布的Fedora 45版本一同亮相。

多年来，关于在KWin Wayland合成器中实现Vulkan支持的讨论一直持续，如今我们终于看到围绕该功能的主流开发活动开始启动。三周前开启的合并请求实现了支持Vulkan的通用多GPU复制交换链，并为DRM后端提供了初步的Vulkan支持。

代码作者Xaver Hugl在合并请求中解释道： 

"本次合并请求添加了交换链，在DRM后端中启用该功能，并为其添加Vulkan支持。根据我的测试，在AMD集成显卡+AMD独立显卡组合下，其性能与OpenGL相当；在英特尔集成显卡+英伟达独立显卡组合下表现也是如此。

当英伟达作为主显卡时，Vulkan可能带来某些性能提升，但当前合并请求尚未解锁这些潜力。[据我所知]，若在EGL上渲染，我们需要进行两次复制：首先复制到中间线性缓冲区，随后再复制到扫描输出缓冲区。"

此次合并包含了最基础的Vulkan基础设施及交换链组件，其中也涵盖了多GPU场景的支持。

这次合并标志着KWin自2023年制定的Vulkan支持路线图中基础架构的首个步骤已完成。在基础架构方面仍有更多工作待推进，包括为KWin特效、插件、其他后端等功能启用Vulkan支持。

无论如何，我们迎来了激动人心的开端——Vulkan代码终于开始进入KWin主流代码库。期待更多相关进展能尽快接踵而至。