泰晓资讯·8 月 / 第二期 / 2024

“泰晓资讯”，广泛报道 “Linux/开源” 业界资讯。欢迎广大读者投递相关资讯来源和素材，本站将进一步收集整理后发布给大家。

Linux 内核最新消息

Torvalds 在本周初发布了 Linux 6.11-rc3。没有什么特别奇怪或有趣的事情发生，事情看起来很正常。不出意外的话，6.11 将于九月中旬发布。Linus Torvalds 在他的公告中说：

“Nothing particularly strange or interesting going on, things look normal.

Half the changes are to drivers (all the usual suspects: sound, gpu, and networking are big, but we have usb and other misc driver fixes there too).

The rest is the usual random mix, with filesystem fixes (bcachefs, btrfs, smb), architecture fixes (arm64, loongarch, x86), documentation, and networking. And some core kernel and tooling fixlets too.”

本周值得注意的改动包括针对 AMD Zen 5 支持了更多的 CPU ID，修复了 ASUS（华硕）的 ROG Ally X 游戏掌机问题，以及针对 Intel P-State EPP 的更新，该更新有助于提高 Xeon Scalable “Emerald Rapids” CPU 的性能和能效。

此外，最新合入的改动还包括最近发现的 32 位 x86 页表隔离 （Page Table Isolation）代码中发现的问题。内核页表隔离代码对于缓解 Meltdown 安全漏洞非常重要。事实证明，32 位 x86 PTI 代码并不完全符合标准。

https://www.kernel.org/ updated by 2024/8/15

关键词: Linux

新的 Linux 内核补丁更好地为 sched_ext 做好准备

While Linus Torvalds called for including the “sched_ext” extensible scheduler in Linux 6.11, he ultimately decided not to merge it for Linux 6.11 after some technical issues were raised on the Linux kernel mailing list.

虽然 Linus Torvalds 期望在 Linux 6.11 中包含 “sched_ext”（extensible scheduler），但考虑到大家在 Linux 内核邮件列表上提出的一些技术问题后，他最终决定放弃在 Linux 6.11 中合并它。

好消息是，从那时起，人们一直在讨论如何解决这些问题，以便将 sched_ext 在新一轮内核开发周期中合入主线。由此产生的相关工作包括 Peter Zijlstra 的新内核补丁系列，更好地为 sched_ext 做好准备。

这组内核补丁于本周二发布，这些补丁反过来又依赖于即将 “完成”的 EEVDF 调度程序代码。Peter 对补丁系列的评论如下：

“These patches apply on top of the EEVDF series (queue/sched/core), which re-arranges the fair pick_task() functions to make them state invariant such that they can easily be restarted upon picking (and dequeueing) a delayed task.

This same is required to push (the final) put_prev_task() beyond pick_task(), like we do for sched_core already.

This in turn is done to prepare for sched_ext, which wants a final callback to be in possesion of the next task, such that it can tell if the context switch will leave the sched_class. … The patches do a fair bit of cleaning up. Notably a bunch of sched_core stuff – Joel, could you please test this stuff, because the self-tests we have are hardly adequate.”

让我们看看 sched_ext 是否能够在 9 月中旬的 Linux v6.12 合并窗口之前做好准备。如果开发需要更多时间的话，这个可扩展的调度器代码可能会被推迟到 2025 年才能进入内核主线。

新闻出处，“New Linux Kernel Patches Better Prepare For sched_ext”: https://www.phoronix.com/news/Linux-sched_ext-Prep。

关键词: Linux, sched_ext

XZ 代码看起来已经准备好在 Linux 6.12 合入主线

The past few months have seen patches for updating the XZ (de)compression code within the Linux kernel that’s been a lengthy process in part due to the XZ backdoor situation earlier this year and the reputable XZ developers in turn being busy cleaning up that mess. In any event it appears that the updated XZ code for the Linux kernel is now on track for mainlining come Linux 6.12.

针对 XZ（解）压缩代码的内核补丁开发工作已经持续了好几个月，这是一个漫长的过程，部分原因是今年早些时候发生的 XZ 后门事件，这导致 XZ 开发人员不得不花费了不少精力来忙于清理这个烂摊子。但目前来看，更新后的 XZ 代码现在有望在下个开发周期，即 Linux 6.12 开发期间合入主线。

该补丁跟上了上游 XZ 的改动，从 public domain 转向 BSD Zero Clause license，删除了臭名昭著的 “Jia Tan” 维护者信息，并在 ARM64 和 RISC-V 内核构建的过程中添加了对 Image.xz 的支持。

这个更新的 XZ 补丁现在设置为使用 128MB 字典并强制 XZ 的单线程模式。开发人员 Lasse Collin 对该修改做出的解释原文如下：

“Desktop kernels on x86-64 are already around 60 MiB. Using a dictionary larger than 32 MiB should have no downsides nowadays as anyone building the kernel should have plenty of RAM. 128 MiB dictionary needs 1346 MiB of RAM with xz versions 5.0.x - 5.6.x in single-threaded mode. On archs that use xz_wrap.sh, kernel decompression is done in single-call mode so a larger dictionary doesn’t affect boot-time memory requirements.

xz >= 5.6.0 uses multithreaded mode by default which compresses slightly worse than single-threaded mode. Kernel compression rarely used more than one thread anyway because with 32 MiB dictionary size the default block size was 96 MiB in multithreaded mode. So only a single thread was used anyway unless the kernel was over 96 MiB.

Comparison to CONFIG_KERNEL_LZMA: It uses “lzma -9” which mapped to 32 MiB dictionary in LZMA Utils 4.32.7 (the final release in 2008). Nowadays the lzma tool on most systems is from XZ Utils where -9 maps to 64 MiB dictionary. So using a 32 MiB dictionary with CONFIG_KERNEL_XZ may have compressed big kernels slightly worse than the old LZMA option.

Comparison to CONFIG_KERNEL_ZSTD: zstd uses 128 MiB dictionary.”

这些针对 Linux 内核的 XZ 更新已合入 Andrew Morton 的 mm-everything 分支。此后将进入 MM Git 仓库，除非最后一刻出现什么不可预知的问题。不出意外的话，该补丁会被 Morton 提交到 9 月中旬打开的 Linux 6.12 合并窗口。

新闻出处，“Updated XZ Code For The Kernel Looks Like It’s Ready For Linux 6.12”: https://www.phoronix.com/news/XZ-Update-Linux-6.12-Queue。

关键词: Linux, XZ

Linux 将因为一行改动而得以在启动中节省 0.035 秒

The Linux kernel itself can already boot quite fast but with a simple one-line patch another ~0.035 seconds will be able to be shaved off the boot time.

Linux 内核的启动速度本身已经很快，但是最近有个补丁只修改了一行，让内核的启动速度又减少了大约 0.035 秒。

来自 Intel 的 Linux 工程师 Colin Ian King 发现，如果通过 “SLAB_HWCACHE_ALIGN” 标志对齐 ACPI 代码中的 slab，将显著提高内存性能并减少内核启动时间。

Colin 对这个只有一行改动的内核补丁解释是：“对 ACPI object caches 启用 SLAB_HWCACHE_ALIGN 可以加速 object 的分配和释放，尤其是在启动阶段中执行 AML 解析和执行时，并最终提高了 ACPICA core 的启动速度。对启动进行 100 次测试显示，与未对齐的版本相比，acpi_init 函数中平均启动节省了大约 35000 微秒。在用于分析和执行的关键路径中，大多数被分配和释放的 ACPI 对象的生存期时间都非常短，因此用于对齐的额外内存开销不会太大。”

Linux 在优化内核启动时间方面已经做了很多工作，最初可以追溯到上网本流行的年代，以及此后的几年里，针对 Linux 服务器启动的优化。

对于最终用户来说，0.035 秒的启动开销几乎不会引起注意，但每一改进都是值得的，尤其是在超大规模应用场景和其他需要最大限度地减少数据中心停机时间的情况下，对于无论是裸机服务器还是虚拟机都有好处。而且，更值得称赞的是，这个改进只需要一行代码。

新闻出处，“Linux Will Be Able To Boot ~0.035 Seconds Faster With One Line Kernel Patch”: https://www.phoronix.com/news/Linux-Faster-Boot-One-Line-ACPI。

关键词: Linux, Boot, ACPI

Firefox 129 发布，默认使用 HTTPS 替换 HTTP

Mozilla Firefox 129.0 is now available for download ahead of its formal release announcement on Tuesday. Making Firefox 129 notable is that for non-local sites it’s now replacing HTTP with HTTPS by default. Firefox will now aim for HTTPS as the default protocol on non-local sites.

Mozilla Firefox 129.0 现在已可以下载。在 Firefox 129 中值得注意的一个改进是，对于非本地站点，它现在默认用 HTTPS 而不是 HTTP。也就是说 Firefox 现在将把 HTTPS 作为非本地站点的默认通信协议。

Firefox 129.0 将尝试通过 HTTPS 作为默认协议访问远程站点，但如果 HTTPS 连不上远程服务器，它将回退到使用 HTTP。现在大多数网站都在将 HTTP 连接替换升级到 HTTPS，所以浏览器这么做也是顺应形势。

Firefox 129 版本还改进了其 reader view，以及在法国和德国支持地址自动填充，支持通过媒体功能 API 查询加密密钥系统配置，删除了 Navigator.vibrate()，以及各种其他开发人员添加的内容。有关 Firefox 129 开发者更改的更多详细信息，请访问 https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/129。

新闻出处，“Firefox 129 Now Available With HTTPS Replacing HTTP As Default Protocol”: https://www.phoronix.com/news/Firefox-129-Released。

关键词: Firefox, HTTPS, HTTP

SiFive 发布 P870-D，包含多达 256 个 RISC-V 核心

SiFive today lifted the lid on the P870-D, its new RISC-V processor dor data center and AI workloads. The P870-D is designed to scale up to 256 cores while supporting modern features like CXL and other AI/HPC minded features.

SiFive 于本周三宣发了一款新处理器 P870-D，该新款 RISC-V 处理器适用于数据中心和 AI 应用场景。P870-D 设计为最高扩展至 256 个核心，同时支持 CXL 和其他 AI/HPC 等现代功能。

SiFive P870-D 设计为可扩展至多达 256 个内核，完全兼容 RISC-V RVA23 profile，支持 RISC-V Sv57 虚拟地址空间扩展、提供 CHI ports/clusters 以及各种其他新功能。SiFive P870-D 目前正在向 SiFive 合作伙伴和客户提供样品，预计将于 2024 年底发布商业化版本。

有关 P870-D 的更多详细信息，请访问 https://www.sifive.com/press/sifive-announces-high-performance-risc-v-datacenter-processor-for-ai-workloads。如果现在就能拿到他们的 HiFive Premiere P550 或其他更高端的 RISC-V 开发板就好了，这样我们可开展一些更有趣的 RISC-V 性能测试和基准测试。总之，非常期待看到哪些场景会应用 P870-D，以及 P870-D 的衍生产品会如何被部署。

新闻出处，“SiFive Announces P870-D For Up To 256 RISC-V Cores”: https://www.phoronix.com/news/SiFive-P870-D-RISC-V-CPUA。

关键词: SiFive, P870-D, RISC-V, CPU

Linux 基金会希望更多地参与 AI 模型，欢迎 OMI

With all the craze around “AI” and hoping to foster more open-source AI models, the Linux Foundation has welcomed the Open Model Initiative (OMI) into its umbrella of open-source initiatives to help foster high quality, openly-licensed AI models.

伴随着 “AI” 概念的兴起，人们希望培养更多的开源 AI 模型。Linux 基金会本周发布声明，欢迎 Open Model Initiative（OMI）加入其开源计划，以帮助孵化高质量、开放许可的 AI 模型。

OMI 由 Invoke、Comfy Org 和 Civitai 合作发起成立，作为一项社区驱动的努力，旨在促进开放许可的 AI 模型的开发和采用，用于图像、视频和音频生成。这项社区倡议是在夏天提出的，旨在帮助推进开源 AI 模型，而现在正在成为 Linux 基金会的一部分，以推进他们的事业。

作为 Linux 基金会的一部分，OMI 将致力于建立治理框架和工作组，创建共享标准以增强模型互操作性和元数据实践，开发用于训练和字幕的透明数据集，完成针对 red teaming 的 alpha 测试模型，并在 2024 年底之前发布带有微调脚本的新模型的 alpha 版本。

那些希望了解更多信息的人可以查看 Linux 基金会的新闻稿 https://www.linuxfoundation.org/press/linux-foundation-welcomes-the-open-model-initiative-to-promote-openly-licensed-ai-models。似乎还没有发布太多的代码，但 Open Model Initiative 已经在 Github 上建立了代码仓库 https://github.com/Open-Model-Initiative。

新闻出处，“Linux Foundation Looks To Become More Involved With AI Models, Welcomes OMI”: https://www.phoronix.com/news/Linux-Foundation-OMI-AI-Models。

关键词: Linux Foundation, OMI, AI Models

Canonical 将为 Ubuntu 版本提供最新的上游内核代码

Following decisions like exploring -O3 package builds for Ubuntu Linux, another newly-announced change by Canonical I must applaud is their decision to commit to shipping the very latest upstream kernel code at release time.

Canonical 新宣布的一个变化让我们备受鼓舞，那就是他们决定承诺在发布时使用最新的上游内核代码。

到目前为止，Ubuntu 的每个版本都会使用最新的已经处于 freeze 状态的上游内核版本。但在某些情况下，这意味着即使新的上游 Linux 内核版本即将 freeze，但因为赶不上下一个计划中的 Ubuntu 版本，导致 Ubuntu 只能使用上一个大约 2 个月前 freeze 的内核版本。但现在 Canonical 的内核团队对 Ubuntu 的发布进行了调整，以适应这种差异，以确保 Ubuntu 在发布时使用最新的上游内核。

历史背景：

• Linux 内核的发布时间较为灵活，一般会根据开发进度和稳定性，大约每两到三个月发布一个新版本。

• 相较之下，Ubuntu 有更严格的基于时间的发布流程，严格遵循六个月的周期性模式，计划提早制定，几乎不受外部因素影响。

通常情况下，CKT 会在上游 Linux 内核发布后等待大约一个月，确认稳定性后才将它纳入 Ubuntu 系统，以保证与 Ubuntu 软硬件生态的兼容性和可靠性。然而，这一策略即将发生变化。根据 Canonical 的最新政策，CKT 正在采取更加积极的立场：现在，Ubuntu 将在其 “发布冻结” 日期采用上游 Linux 内核的最新版本，即使该版本仍处于候选版本（RC）阶段。

这意味着对于即将到来的 Ubuntu 24.10 版本，它将使用 Linux 6.11 内核。

要了解更多关于 Ubuntu 新内核选择策略的详细信息，请访问官方公告：https://discourse.ubuntu.com/t/kernel-version-selection-for-ubuntu-releases/47007。

新闻出处，“Canonical Moves To Shipping Very Latest Upstream Kernel Code For Ubuntu Releases”: https://www.phoronix.com/news/Ubuntu-Releases-Fresher-Kernels。

关键词: Ubuntu, Canonical, Kernels

Ubuntu 24.04.1 LTS 推迟到月底

Ubuntu 24.04.1 LTS was scheduled to ship this week but has now been delayed to the end of August in order to address some high profile upgrade bugs.

Ubuntu 24.04.1 LTS 原定于本周发布，但现在已推迟到 8 月底，以解决一些备受瞩目的升级错误。

由于 Ubuntu 24.04.1 LTS 是当前长期支持系列的第一个单点版本，Canonical 开始鼓励为之前的 LTS 系列（Ubuntu 22.04）用户进行版本升级，因此 Canonical 在确保升级过程顺利进行方面格外谨慎。由于遇到了一些 “high impact” 的升级错误，Canonical的发布团队决定将点发布推迟两周。

Ubuntu 24.04.1 LTS 现在计划于 8 月 29 日首次亮相，以便有时间确保刚开始从 Ubuntu 22.04 升级到 24.04 的用户的升级过程顺利进行。

Ubuntu 24.04.1 LTS 延迟发布的消息于今天下午在 Ubuntu-devel 邮件列表上得到确认。对于那些已经在使用 Ubuntu 24.04 LTS 的人来说，这种延迟并没有很大的影响，因为该点版本只是捆绑了自 Ubuntu 24.04 四月发布以来合并的所有稳定版本更新。

新闻出处，“Ubuntu 24.04.1 LTS Delayed To End Of Month”: https://www.phoronix.com/news/Ubuntu-24.04.1-LTS-Delay。

关键词: Ubuntu

联系我们

欢迎扫描二维码加微信联系我们：