网站头条 第7页

作为 AMD 为 AMD Ryzen AI 系列 PC 提供的 AI 推理工具和库集合，Ryzen AI 软件的最新点版本支持 Linux，尽管这种“早期访问”的 Linux 支持仅限于注册的 AMD 客户。

今年早些时候，我们报道了 AMD 预览了一个新的 Linux 运行时堆栈，用于 Ryzen AI NPUs，并基于他们的 AMDXDNA 内核加速器驱动程序构建。现在这被捆绑到了 Ryzen AI 软件集合中，该集合之前仅限 Windows 使用。在最新的 Ryzen AI 软件 1.6.1 点版本中，发布说明中唯一提到的变化是支持 Linux：

Ryzen AI Linux 支持 CNN、Transformer 和 LLM 流。尽管“Ryzen AI Software Early Access Lounge”会将你引导到 AMD 注册开发者/客户的登录区域。然而，关于今天早些时候刚刚了解到的这个新的 Linux 支持，我并没有任何细节。很可能它只是基于上游的 AMDXDNA 内核加速器驱动程序，然后是用户空间的部分，如 Xilinx XRT 堆栈。他们继续在预构建的 Linux 二进制文件上设置门槛，这无疑让 Linux 开发者更难参与和利用 Linux 下的 Ryzen AI NPUs。

此文档页面指出 Ubuntu 24.04 LTS 是 Ryzen AI Software 唯一官方支持的 Linux 发行版。

据说 Linux 支持 NPU 执行，并与 INT8 或 BF16 格式的 CNN 模型、BF16 格式的 NLP 模型以及仅用于 NPU 执行的 LLMs 协同工作，通常需要 64GB+的系统内存。

转自  Ryzen AI Software 1.6.1 Advertises Linux Support – Phoronix

快科技11月6日消息，今日，中科曙光宣布正式发布全球首个单机柜级640卡超节点scaleX640。

scaleX640超节点采用“一拖二”高密架构设计，不仅实现了单机柜640卡超高速总线互连，构建大规模、高带宽、低时延的超节点通信域，还可通过双scaleX640超节点组成千卡级计算单元。

据介绍，相比业界同类产品，scaleX640不仅综合算力性能实现倍增，同时单机柜算力密度提升20倍。

相比传统方案，可实现MoE万亿参数大模型训练推理场景30%-40%的性能提升。

通过30天+长稳运行可靠性测试验证，可保障10万卡级超大规模集群扩展部署。

scaleX640采用AI计算开放架构，在硬件层面支持多品牌加速卡，软件层面兼容主流计算生态。

支持MoE万亿参数大模型训练、高通量推理、科学智能（AI4S）等场景。

antiX 的开发者，一个轻量级、无 systemd 的桌面 Linux 发行版，特色是 IceWM 窗口管理器，宣布了基于 Debian 13 的全新版本 25 的初始 beta 构建版本。此版本增加了 s6-rc 和 s6-66 作为 runit 和 Dinit 初始化系统的替代品：“这是 antiX 25（64 位）的第一个 beta ISO 镜像。目前要点如下：基于 Debian 13 ‘Trixie’；四个现代无 systemd 的初始化系统 – runit（默认）、s6-rc、s6-66 和 Dinit；新的默认外观；传统的‘antiX 魔法’；你应该能够在非默认初始化系统中启动 live，安装后它应该成为默认设置。请注意，与 antiX 的先前版本相比，现在可能需要用户干预，尤其是如果不使用默认的 runit 选项。这意味着用户需要为他们所使用的初始化系统添加任何需要的服务文件，例如，network-manager 也需要 runit-service-network-manager（以及 dinit、s6-rc 和 s6-66 的等效服务，如果可用）。在论坛的线程中测试并发布反馈。” 这个版本与众不同，如果没有许多其他发行版开发者的合作，它将不会存在。”以下是简短的发布公告。下载：antiX-25-beta1_x64-full.iso（2,126MB，MD5）。

这是简短的发布公告。下载：antiX-25-beta1_x64-full.iso（2,126MB，MD5）。

转自  Development Release: antiX 25 Beta 1 (DistroWatch.com News)

Debian 开发者 Julian Andres Klode 在万圣节发送了一条消息，可能会让一些 Debian Linux 用户和开发者感到惊悚：APT 打包工具明年将开始要求使用 Rust 编译器。这将使 Debian Linux 对所有架构的 Rust 支持成为硬性要求。目前有移植但缺乏 Rust 支持的 Debian CPU 架构将需要看到支持工作得到推进，或者被淘汰。

Julian 在周五发送了消息，他计划最早不早于 2026 年 5 月将 APT 引入硬性 Rust 依赖。

在 APT 代码库的一些领域，使用内存安全的 Rust 编程语言具有优势，因此在 Debian 世界中强制要求使用 Rust 是合理的：

“我计划在 2026 年 5 月之前将硬 Rust 依赖和 Rust 代码引入 APT。这最初扩展到 Rust 编译器和标准库，以及 Sequoia 生态系统。

特别是，我们解析.deb、.ar、.tar 以及 HTTP 签名验证代码的代码将极大地受益于内存安全语言和更强大的单元测试方法。”

这使得一些 Debian 移植，如 m68k、惠普精简指令集架构（HPPA）、SuperH/SH4 和 Alpha，目前缺乏适当的 Rust 支持，但作为移植又处于困境。他们需要努力支持 Rust，否则将面临 Debian 移植的淘汰：

如果您维护的移植没有可用的 Rust 工具链，请确保在接下来的 6 个月内安装一个，或者淘汰该移植。

对于整个项目来说，能够继续前进并依赖现代工具和技术，而不是被尝试将现代软件强行适配到旧式计算设备所拖累，这一点非常重要。

Julian 的完整公告可以在邮件列表上阅读。

转自  Debian’s APT Will Soon Begin Requiring Rust: Debian Ports Need To Adapt Or Be Sunset – Phoronix

Rust 项目今天宣布发布了 Rust 1.91，这是这款以内存安全能力自豪的流行编程语言的最新更新。

Rust 1.91 最引人注目的是将aarch64-pc-windows-msvc提升至一级平台地位。这使 Rust 编程语言对 ARM 支持的级别与其他常见操作系统和架构保持一致。Rust 1.91 为 64 位 ARM/AArch64 上的 Windows 提供一级支持，也意味着新版本将提供预构建的二进制文件。

Rust 1.91 同时也将 aarch64-pc-windows-gnullvm 和 x86_64-pc-windows-gnullvm 移植提升至二级状态，并支持主机工具。

Rust 1.91 现在也对来自局部变量的悬空原始指针进行 lint 检查，并稳定了多个不同的 Rust API。

有关今天 Rust 1.91 版本的下载和更多详细信息，请访问 Rust-Lang.org。

转自 Rust 1.91 Promotes Windows On 64-bit ARM To Tier-1 Status – Phoronix

快科技10月26日消息，我国光刻胶领域取得新突破！

据科技日报报道，近日，北京大学化学与分子工程学院彭海琳教授团队及合作者通过冷冻电子断层扫描技术，首次在原位状态下解析了光刻胶分子在液相环境中的微观三维结构、界面分布与缠结行为，指导开发出可显著减少光刻缺陷的产业化方案。相关论文近日刊发于《自然·通讯》。

光刻技术是推动集成电路芯片制程工艺持续微缩的核心驱动力之一。

简单来说，光刻胶是芯片制造中刻画电路的颜料，核心作用是将设计好的电路图案精确转移到硅片上。通过显影液溶解其曝光区域，完成从掩模版到硅片的图案复刻，这是光刻工艺的基础环节。

“显影”是光刻的核心步骤之一，通过显影液溶解光刻胶的曝光区域，将电路图案精确转移到硅片上。

光刻胶在显影液中的运动，直接决定电路画得准不准、好不好，进而影响芯片良率。光刻胶性能直接影响光刻机效能的发挥，只有二者适配才能实现先进制程突破。

长期以来，光刻胶在显影液中的微观行为是“黑匣子”，工业界的工艺优化只能靠反复试错，这成为制约7纳米及以下先进制程良率提升的关键瓶颈之一。

为破解难题，研究团队首次将冷冻电子断层扫描技术引入半导体领域。研究人员最终合成出一张分辨率优于5纳米的微观三维“全景照片”，一举克服了传统技术无法原位、三维、高分辨率观测的三大痛点。

彭海琳表示，冷冻电子断层扫描技术为在原子/分子尺度上解析各类液相界面反应提供了强大工具。深入掌握液体中聚合物的结构与微观行为，可推动先进制程中光刻、蚀刻和湿法清洗等关键工艺的缺陷控制与良率提升。

延伸阅读：

一般来说，芯片制造可以划分为5个核心步骤：

1、晶圆制备，也就是造 “地基”

先把纯度 99.9999% 的硅料，做成圆柱形的单晶硅棒，再切成晶圆，这就是芯片的 “地基”，所有电路都要刻在这上面。

2、晶圆氧化，刷防护层

在晶圆表面烤一层 二氧化硅膜，像给地基刷防水漆，防止后续步骤损伤硅片本身。

3、画电路图， 也就是光刻（此时光刻胶将发挥作用）

这是最关键的一步，相当于给 “地基” 画电路蓝图，分3小步：​

涂胶：把光刻胶均匀涂在氧化层上；​

曝光：用光刻机照晶圆，光线透过设计好的掩模版，只让光刻胶的特定区域感光变脆。

显影：用显影液洗掉变脆的光刻胶，剩下的光刻胶就像 “镂空的电路模板”，精准盖在晶圆上。

4、刻电路， 蚀刻​

用化学、物理方法雕刻晶圆：没被光刻胶盖住的氧化层会被刻掉，被光刻胶盖住的区域保留，相当于光刻胶当保护罩，只让该刻的地方刻出电路凹槽。

5、后续加工、封装​

往刻出的凹槽里加 “杂质”（形成晶体管）、铺金属层，最后把晶圆切成一个个小芯片，然后封装，变成能用的芯片。

除了在 Ubuntu 25.10 上切换到 Rust Coreutils 导致的早期故障和破坏外，还发现了一个更紧迫的问题：由于 Rust Coreutils 的漏洞，Ubuntu 25.10 的无人值守升级功能目前无法正常工作，该功能用于自动安全更新。

本月早些时候，有报道称，由于与 GNU Coreutils 相比存在差异，Ubuntu 25.10 上的`date -r`命令可能会报告错误日期。指出，这可能会对依赖于“date -r”输出和行为与 GNU Coreutils 相同的备份脚本和其他软件造成问题。

上周，一位 Ubuntu 开发者最初决定这不是一个特别紧迫的问题：

“这个问题已在 88a7fa7adfa048dabdffc99451d7aba1d9e6a9b6 上上游修复，我们可以在稍后的时间点将其拉入。目前，我们将专注于修复可能导致进一步不安全的临界问题，例如 bug 2125535 中的短写。

我不认为有很多 shell “监控”脚本，尤其是在 25.10 中，因为这不是一个 LTS 版本。对于即将到来的 LTS 版本，这当然是一个更高优先级的项目，考虑到有更多的企业用例。”

但现在意识到，这个回归最终导致 Ubuntu 25.10 上的无人值守升级功能出现问题。

今天早些时候，有人报告了这个导致无人值守升级中断的 bug：

这个漏洞破坏了 25.10 版本的无人值守升级！apt.systemd.daily 会检查时间戳文件/var/lib/apt/periodic/upgrade-stamp 的修改日期是否早于当前日期减去一个间隔。差异始终显示为 0，无人值守升级永远不会运行。哎呀:( 我现在创建了#2129660。

因此，这个 bug 报告现在被提升为“关键”重要性，作为一个公共安全问题。

现在有这个关于无人值守升级损坏的特定错误报告。正在对 Rust Coreutils 的修复版本进行工作，目前该版本已在提议的存档中。一旦该 rust-coreutils 更新在主存档中可用，用户需要首先手动更新他们的 Ubuntu 25.10 系统以获取该软件包，然后无人值守升级才能再次工作：

用户需要手动运行`apt update`来使更新的列表对无人值守升级可用，并且可以手动使用`apt upgrade`进行升级。更新发布后，我们将提供更多信息。

至少在 Ubuntu 25.10 中发现了这个问题，而且是在重要的 Ubuntu 26.04 LTS 周期之前…

转自  Ubuntu 25.10 Unattended Upgrades Broken Due To Rust Coreutils Bug – Phoronix

快科技10月21日消息，全球计算联盟（GCC）近日正式发布团体标准《统一基本输入输出系统（UBIOS）基础架构规范》（T/GCC 3007—2025）。

UBIOS全称为 “统一基本输入输出系统（Unified Basic Input Output System）”，是一种支持分布式架构与软硬芯协同的固件框架。

这标志着中国终于拥有了第一个完整、标准化、可扩展的国产固件体系标准，实现了真正意义上自主固件生态标准的突破。

据悉，该标准的起草单位包括中国电子技术标准化研究院、华为技术有限公司、南京百敖软件有限公司、昆仑太科 (北京) 技术股份有限公司等13家业内重点企业与科研机构。

与传统UEFI标准不同，UBIOS并非对 UEFI 的被动兼容或局部修改，而是从底层架构重构BIOS形态的全新体系，具备原生异构支持、分布式、低耦合、抽象化、统一性和可扩展性等核心特性。

在计算机体系中，BIOS被称为系统的 “灵魂引导者”，主要负责硬件初始化、提供硬件抽象层及发现启动媒体等关键任务，是操作系统之下最为核心的基础软件层。

过去二十年间，UEFI（统一可扩展固件接口）标准逐步取代传统BIOS，成为通用计算机主固件的主流实现方案。

UEFI凭借稳定的规范和成熟的生态，不仅在x86体系中占据主导地位，还逐步向 ARM 通用系统（服务器和PC）及RISC-V等新兴计算领域扩展。

经过二十年的发展，UEFI 的固有缺陷逐渐显现，其参考实现Tiano存在代码臃肿、效率低下、模块耦合度高的问题，且难以适配异构计算和 Chiplet 等新技术场景。

UEFI 的设计基因深度绑定于Intel与微软主导的生态，其设备发现逻辑和操作系统加载接口默认依赖x86处理器架构与ACPI系统描述表体系。

尽管ARM、RISC-V及国产LoongArch架构后续加入UEFI 标准，但适配效果仍显生硬，未能从根本上摆脱对原有生态的依赖。

在自主可控已成为国家级战略目标的当下，UEFI 与国外主导生态的深度绑定问题愈发突出，而标准及代码参考实现的控制权隐患，更成为国产固件体系发展的重要制约因素。