皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

红帽公司ARM架构工程师放弃使用ARM64架构的Linux个人桌面系统,换回AMD锐龙平台设备

Editor, Kai

红帽公司ARM团队的高级软件工程师马尔钦·尤什凯维奇(Marcin Juszkiewicz)在过去近一年里一直将AArch64 Linux桌面版作为其主要个人系统使用。但现在他分享说,由于他的Ampere Altra桌面版遇到了AArch64 Linux问题,他已转而使用AMD Ryzen桌面版。

去年六月,Marcin分享说他正在计划一台新的开发机器,并决定使用ASRockRack ALTRA8BUD-1L2T主板,搭配Ampere Altra 80核CPU和AMD Radeon显卡,组装一台Ampere Altra AArch64 Linux桌面机。他一直在利用个人时间撰写博客,分享自己将这款原生AArch64 Linux系统作为日常个人开发桌面的使用体验。

但在使用11个月后,他决定结束这项“实验”,并重新使用之前的AMD Ryzen台式机。在一年中的大部分时间里,Ampere Altra系统运行良好,从Fedora 42到Fedora 44,除了由于Ampere Altra的PCI Express控制器问题,他每周都需要为自己的内核构建打补丁。但即使拥有80个Arm64内核,他发现性能仍然平平,尤其是在单线程任务方面。

导致他结束ARM64桌面体验的进一步原因是,在Linux ~7.0+版本上,当ARM64上开始出现视频播放和游戏错误时,他开始遇到AMDGPU内核驱动程序问题。随后,马尔钦(Marcin)转而使用带有Nouveau驱动程序的NVIDIA GeForce RTX显卡,同时仍在修补自己的内核构建。但由于AArch64上没有适合他的设置的NVIDIA Flatpak存储库,一些软件无法正常工作。简而言之,问题归结为使用AArch64 Linux桌面时,平台问题和硬件特定问题比基础架构问题更为突出。

红帽公司ARM架构工程师放弃使用ARM64架构的Linux个人桌面系统,换回AMD锐龙平台设备

最终,这位红帽公司的ARM工程师决定回到他之前使用的AMD Ryzen台式机上的x86_64系统。马尔钦·尤什凯维奇(Marcin Juszkiewicz)在最近的一篇博客文章中总结了这一情况:
“那时,我放弃了。然后启动了一直关着的x86-64系统。有很多线缆需要移动,还有一些新线缆需要整理,现在我的桌子下同时运行着‘wooster’(Ampere Altra)和‘puchatek’(Ryzen 5 3600)两个系统。”。

从80核降至6核(12线程)是一次奇特的体验。虽然核心数量大幅减少,但一切运行良好。我可以加载所有线程,音乐依然能播放。我Steam库中的所有游戏都能玩。能用的FreeCAD让我能完成家庭项目的设计工作,而且我还能直接从OrcaSlicer中3D打印原型。

“wooster”系统保持运行状态,不断构建RISC-V包。它在单线程方面可能较弱,但在多核负载方面却表现出色。
至于Ampere Altra,我不打算重复这个实验。再次尝试AArch64桌面系统需要全新的硬件平台。而且,我并没有计划花费两万多波兰兹罗提(PLN)去购买Nvidia DGX Spark系统。”

一位红帽工程师对AArch64 Linux桌面日常使用的有趣观点。鉴于当前RISC-V硬件性能不佳,他至少在将这台机器重新配置用于RISC-V交叉编译方面,对Ampere Altra硬件的投资是值得的。

转自 Red Hat ARM Engineer Abandons ARM64 Linux Personal Desktop, Goes Back To AMD Ryzen System – Phoronix

趣图:Linus大神又炮轰AI了

otto

趣图:Linus大神又炮轰AI了

就像在说:充气娃娃带不给你爱情一样。

趣图:Linus大神又炮轰AI了

但是大家都还是在冲

Ubuntu 26.10 代号“轰鸣黄貂鱼”的第二版系统快照现已开放下载

Editor, Kai

Ubuntu 26.10 代号“轰鸣黄貂鱼”的第二版系统快照现已开放下载

Canonical公司今日正式发布了尚在开发中的Ubuntu 26.10(代号“轰鸣黄貂鱼”)的第二版系统快照,面向希望提前测试应用兼容性的尝鲜用户与应用开发者开放下载。

Ubuntu 26.10(代号“轰鸣黄貂鱼”)的开发工作于2026年4月30日正式启动,按照Ubuntu版本开发惯例,项目启动后首先完成了全套开发工具链的上传部署;5月底推出了首个系统快照,该版本基于上一代Ubuntu正式版——Ubuntu 26.04 LTS(代号“坚毅浣熊”)构建,默认搭载Linux 7.0内核与GNOME 50桌面环境。

本次发布的Ubuntu 26.10第二版快照同样默认搭载Linux 7.0内核与GNOME 50桌面环境,但Canonical后续计划将这些核心组件升级到即将推出的Linux 7.2内核系列与GNOME 51桌面环境系列,同时还会默认集成尚未正式发布的Mesa 26.2图形栈。

Ubuntu 26.10(轰鸣黄貂鱼)的正式版预计将于2026年10月15日推出,按照官方发布日程安排,Ubuntu 26.10测试版将于2026年9月24日发布;此外官方还规划了两场可选参与的Ubuntu测试周活动,举办时间分别为7月2日与8月27日。

在此之前,你现在就可以通过官方公告页面下载Ubuntu 26.10的第二版系统快照。和以往惯例一致,本次新快照面向所有官方Ubuntu衍生版本开放,涵盖Ubuntu桌面版、Ubuntu服务器版、Kubuntu、Xubuntu、Lubuntu、Edubuntu、Ubuntu Studio、Ubuntu Budgie、Ubuntu Cinnamon、Ubuntu Unity、Ubuntu Kylin(优麒麟)以及Ubuntu MATE。

如果你找不到自己偏好的衍生版本对应的第二版快照镜像,随时可以下载最新的每日构建镜像——这类镜像相比固定版本的快照镜像,内置了更新的软件包。但请注意:所有这些版本都属于预发布测试版,可能存在漏洞或其他稳定性问题,请勿在生产环境的设备上安装使用。

Ubuntu 26.10的第三版快照预计将于2026年7月30日(也就是下月底)推出,后续还会在8月底发布第四版、同时也是最后一版开发快照。Ubuntu 26.10正式版将于2026年10月15日正式上线。作为非长期支持的过渡版本,Ubuntu 26.10的官方维护周期仅为9个月,支持服务将持续到2027年6月。

转自 Ubuntu 26.10 “Stonking Stingray” Snapshot 2 Is Now Available for Download – 9to5Linux

‌KaOS Linux 2026.06 正式发布,这是首个采用 Dinit 的版本‌

Editor, Kai

‌KaOS Linux 2026.06 正式发布,这是首个采用 Dinit 的版本‌

KaOS Linux 团队今日正式发布 KaOS Linux 2026.06,这是该独立发行版的首个 ISO 镜像快照,采用 Dinit 作为默认初始化系统,替代了原有的 systemd。

正如此前报道的那样,KaOS Linux 开发者在将 systemd 和 KDE Plasma 桌面环境作为默认配置使用超过 12 年后,决定放弃这两款组件。今年 2 月,他们就弃用了 KDE Plasma,转而采用 Niri/Noctalia 组合方案,但当时仍在推进将 systemd 替换为其他初始化系统的工作。

截至今日,他们已成功推出稳定版 ISO 镜像,用户可使用该镜像安装这款发行版,且默认初始化系统不再是 systemd。替代方案是 Dinit——一款现代轻量的初始化系统与服务管理器,以依赖关系驱动的设计实现了快速启动,是 systemd 的替代选项。

KaOS Linux 2026.06 预装了用于系统启动、会话管理和服务调度的 Dinit 0.22.0、Turnstile 0.1.11 以及 Seatd 0.9.3 版本。该版本还采用搭配 Tuigreet 的 Greetd 作为默认登录管理器,替换了原有的 SDDM。不过目前 KaOS Linux 尚不能被视为完全脱离 systemd 的发行版,因为其 udev 设备管理和临时文件管理功能仍依赖 systemd 实现。

“彻底完成了脱离systemd作为初始化系统的迁移工作。KaOS当前采用「dinit → turnstile → seatd」的链路架构,负责系统启动、会话管理与服务调度。但这并不意味着该系统完全摆脱了systemd,目前仍保留了一个功能大幅精简的systemd分支,主要用于提供udev设备管理和tmpfiles临时文件管理能力。”KaOS Linux开发团队表示。

尽管KDE Plasma不再是KaOS Linux 2026.06的默认桌面环境,该发行版仍预装了KDE Gear 26.04.2软件套件,同时适配多款主流常用应用,包括Mozilla Firefox 152网页浏览器、Mozilla Thunderbird 152邮件客户端、GIMP 3.2.4图像编辑器以及LibreOffice 26.2.4办公套件。

底层架构层面,本次搭载Dinit的KaOS Linux 2026.06正式版默认使用Linux 7.0.13内核,软件仓库中还提供基于Linux 7.1版本的开发版内核Linux-next;图形栈升级至最新的Mesa 26.1.3版本,工具链同步更新为GCC 15.2.1编译器与GNU C库2.41版本。

其余预装核心组件包括:Niri 26.04、Noctalia 5 Alpha、PipeWire 1.6.7、GStreamer 1.28、OpenZFS 2.4.3、OpenSSH 10.3、GNU nano 9.1、cURL 8.21、GNU Bash 5.3、Elogind 257.16、OpenCV 4.13.0、Poppler 26.06.0、CMake 4.3、Qt 6.11.1以及libgcrypt 1.12.2。当然,系统仍沿用Calamares作为默认安装程序。

更多细节可查阅官方发布公告页面。与此同时,如果你想在个人电脑上体验测试该版本,可直接从KaOS官网下载KaOS Linux 2026.06 Dinit镜像。现有KaOS Linux用户只需在终端模拟器中执行sudo pacman -Syu命令,即可完成现有系统的全量升级。

转自 KaOS Linux 2026.06 Launches Officially as First Release with Dinit – 9to5Linux

在收到Linus Torvalds的投诉后,”令人反感的”Linux sched_ext源代码已被重组

Editor, Kai

上周,sched_ext 的核心变更内容已正式并入 Linux 7.2 版本,其中包含对子调度器支持功能的持续开发工作。虽然 Linus Torvalds 并未反对这个依赖用户空间 BPF 程序的可扩展调度框架正在推进的任何功能,但他对新增 C 源代码文件的布局方式感到不满,直言:“请别做这种令人反感的事……正经的分层文件系统早在 1965 年就已经出现了。”

Linus Torvalds 对上周提交的 sched_ext 合并请求很不认可:开发者在 kernel/sched 目录下直接新建了多个以 ext_ 为前缀的 C 代码文件和头文件,而非像创建 kernel/sched/ext/ 这类子目录的方式来管理文件,完全没必要给大量独立文件都加上统一前缀。

Torvalds 最终合并了这批代码,但附上了如下评论:

新建模式 100644 的文件 kernel/sched/ext_arena.c
新建模式 100644 的文件 kernel/sched/ext_arena.h
新建模式 100644 的文件 kernel/sched/ext_cid.c
新建模式 100644 的文件 kernel/sched/ext_cid.h
新建模式 100644 的文件 kernel/sched/ext_types.h

请别做这种令人反感的事。

我们设置子目录是有明确意义的:就是为了把相关文件归类到一起,和其他文件区分开。

用文件名前缀代替目录分类的做法既离谱又错误。如果你有这么多零散的 sched-ext 相关文件,完全应该整理妥当,不该搞得这么一团糟。

我这次合并了代码,但对此郑重提出抗议。正经的分层文件系统早在 1965 年就已经存在了。

相应地,今日早些时候一份全新的合并请求已被发出,旨在重构sched_ext的源代码目录结构:改用kernel/sched/ext/子目录来存放相关文件,而非在通用调度器目录下零散堆放大量ext_*前缀的文件。
在收到Linus Torvalds的投诉后,"令人反感的"Linux sched_ext源代码已被重组

Linus Torvalds现已正式合并了这份用于调整sched_ext文件布局的代码。

转自 “Disgusting” Linux sched_ext Source Code Restructured Following Complaint By Linus Torvalds – Phoronix

历经六年开发、累计合并360余处补丁后,Linux内核终于彻底移除了strncpy应用程序编程接口。

Editor, Kai

Linux 7.2 版本终于彻底从内核中移除了 strncpy 应用程序编程接口。这款原本用于将指定长度以内的字节完成拷贝的 strncpy() 函数早已被标记为弃用,历经六年迭代、累计数百处补丁修改后,Linux 内核范围内已经不存在任何调用该接口的代码,因此本次正式完成了彻底移除操作。

多年来,Linux 内核中的 strncpy 始终是「顽固漏洞高发源」:它的空终止符相关逻辑与运行行为完全不符合开发者的直觉预期,同时还会对目标内存区域执行冗余的零值填充,带来额外的性能损耗。过去六年里,维护团队累计提交约 362 次代码提交,逐一替换内核中所有调用 strncpy 的逻辑,如今这项工作终于在 Linux 7.2 版本中全部收尾。

历经六年开发、累计合并360余处补丁后,Linux内核终于彻底移除了strncpy应用程序编程接口。

上周五的一次代码合并操作,正式移除了 strncpy 顶层接口,以及最后剩余的各 CPU 架构专属 strncpy 底层实现。

在 strncpy 被移除后,Linux 内核开发场景下将按不同需求替换为更安全的替代接口:面向需要自动补全空终止符的目标内存场景使用 strscpy(),面向需要自动补零填充的空终止目标场景使用 strscpy_pad(),面向非空终止的定长字段拷贝场景使用 strtomem_pad(),面向带明确填充规则的限长拷贝场景使用 memcpy_and_pad(),面向已知精确长度的内存拷贝场景则直接使用 memcpy()

转自 Linux Finally Eliminates The strncpy API After Six Years Of Work, 360+ Patches – Phoronix

Linux 7.2 正式移除内核中最后一份经过性能优化的 MD5 实现代码

Editor, Kai

Linux 内核已正式移除了最后一份针对特定处理器架构做专属优化的MD5哈希算法实现代码。

尽管MD5此前曾被广泛用于生成校验值以验证数据完整性,但该算法早已被证实存在碰撞漏洞,相关安全隐患至今已存在多年——甚至可以说长达数十年。目前绝大多数软件都已彻底弃用MD5,转而采用安全性更高的哈希算法。对于仍有MD5使用需求的老旧兼容场景,现代处理器上运行的通用版MD5代码路径的性能已经完全够用,专门针对特定架构定制优化的实现版本早已没有实际保留价值。

去年,MIPS和SPARC架构对应的MD5优化实现就已被判定为“无保留必要”并从内核中移除。当时PowerPC架构的MD5优化实现原本也计划同步删除,但有PowerPC用户反馈其所在机构仍有多个业务程序依赖MD5,且该优化实现能为业务带来明显的性能提升,而这类使用场景是通过AF_ALG接口搭配libkcapi-hasher工具实现的。

不过随着Linux 7.2版本因AF_ALG接口本身存在严重安全隐患,正在快速推进该接口的废弃下线工作,此前PowerPC场景下依赖优化MD5代码的使用前提已经不复存在。后续如果有用户在搭载新版Linux内核的PowerPC设备上仍需要高性能MD5能力,完全可以直接在用户态自行部署该优化实现——这份优化版MD5代码本身不涉及任何特权指令,移植过程没有任何技术门槛。

Linux 7.2 正式移除内核中最后一份经过性能优化的 MD5 实现代码

随着目前已正式合并进Linux 7.2版本的加密库更新落地,PowerPC架构专属的MD5优化代码已被正式移除,这也标志着它成为了“最后一份被清理的MD5特定架构专属实现”。

内核层面的MD5支持并未完全消失,只是保留了不区分硬件的通用版本实现——这套通用实现对于现代硬件而言性能完全够用,足以覆盖所有CPU架构下的老旧兼容场景需求。

转自 Linux 7.2 Gets Rid Of The Last Optimized MD5 Implementation – Phoronix