网站头条 第6页

除了 Ada、C/C++、COBOL、D、Fortran、Go、Modula-2、Objective-C/Objective-C++和 Rust 之外，另一种编程语言也预计将加入明年即将发布的 GCC 16 编译器版本。

GCC 指导委员会本周末宣布，允许 Algol 68 前端加入主分支，从而允许这个实验性前端包含在 GCC 16 发布版本中。

自日历年开始以来，人们一直在努力引入这个用于已有半个世纪历史的编程语言的新 GCC 前端。但在 3 月份决定暂时不将该代码合并到 GCC 中。今天宣布的是，GCC 指导委员会已经改变立场，将允许 Algol 68 前端被合并。

GCC 指导委员会的这次宣布是在最新一轮提供各种改进和修复的 Algol 68 前端补丁之后。

David Edelsohn 在周六晚上宣布：

“GCC 指导委员会已经同意将 Algol 68 前端包含在 trunk 中，并指定为实验性版本，但需满足以下条件：

1. Algol 68 并非所有默认构建的语言的一部分。
2. Algol 68 不在 GCC 发布标准之内。
3. 所有不负责 Algol 68 前端的 GCC 开发者都可以拒绝处理与 Algol 68 前端相关的问题。
4. 如果 Algol 68 前端出现故障或未得到维护，它将被移除。

为了继续允许 Algol 68 的发展，Jose E. Marchesi 被任命为 Algol 68 前端维护者。

由于被允许合并到 “trunk” 代码中，这次合并可能会在 3 月至 4 月发布的 GCC 16.1 稳定版本之前发生。GCC 16 最近已经进入第三阶段开发，但只要新移植不会影响现有功能，仍然允许添加新移植——就像 COBOL 在 3 月被合并回 GCC 15 一样。

因此，如果一切顺利，Algol 68 编程语言支持将成为新年 GCC 16.1 编译器发布中值得期待的新（实验性）语言。

Algol 68 是一种命令式编程语言，它是 Algol 60 的后继者。以下是一个 Algol 68 代码示例：

GCC Wiki 上可以找到更多关于 GCC 当前 Algol 68 前端支持的详细信息。

转自  GCC Steering Committee Allows New Language Front-End To Land For GCC 16 – Phoronix

Proxmox 虚拟环境是一个开源的虚拟化平台，用于运行虚拟设备和虚拟机。该公司最新发布的版本 9.1 继续完善基于 Debian 13 “Trixie” 的 9.x 分支。发布公告报告：”我们自豪地推出 Proxmox 虚拟环境平台的下一代版本。这个新版本 9.1 是自我们重大更新以来的首个点发布，专注于完善。这个版本基于 Debian 13.2 ‘Trixie’，但我们使用了更新的 Linux 内核 6.17.2 作为新的稳定默认版本。除了主要系统的增强外，此次更新还集成了核心技术的最新版本，包括 QEMU 10.1.2、LXC 6.0.5、ZFS 2.3.4 和 Ceph Squid 19.2.3，所有内容均已完全测试并集成。请查看下方的关键亮点，并一如既往地感谢您宝贵的支持。以下是 Proxmox VE 9.1 的一些亮点：从 OCI 镜像创建 LXC 容器；支持 qcow2 格式的 TPM 状态；新的 vCPU 标志用于对嵌套虚拟化进行细粒度控制；增强的 SDN 状态报告。”

发布说明提供了更多细节。下载（SHA256）：proxmox-ve_9.1-1.iso（1,747MB，种子，pkglist）。

转自  Distribution Release: Proxmox 9.1 “Virtual Environment” (DistroWatch.com News)

Git 2.52 今天发布，作为这个分布式版本控制系统最新的功能发布，并朝着希望于 2026 年底发布的 Git 3.0 前进。

作为进一步努力用 SHA256 替代 Git 3.0 中的 SHA1 哈希的一部分，Git 2.52 带来了 SHA1-SHA256 互操作性工作的初步进展。那里还有许多工作要做，但希望能在 Git 3.0 大约一年后发布时，拥有良好的 SHA1-SHA256 互操作性体验。

Git 3.0 将会引入的一个变化是使用 “main” 作为默认分支名，而不是当前的默认 “master”。Git 2.52 中有一个提交添加了新的提示以帮助用户在默认名称切换时进行操作。新的提示还将告知用户如何将分支重命名为 “master”，如果需要的话，例如为了匹配任何教程/文档。

Git 2.52 还为各种 Git 子命令带来了改进，新增了 “git repo” 子命令以向用户提供各种仓库特性，新增了 “git last-modified” 子命令以显示触及每个路径的最近祖先提交，进行了各种性能改进，以及其他修复和渐进式改进。

今天的发布公告中详细介绍了 Git 2.52 的完整发布亮点。GitHub 博客上也有更多关于 Git 2.52 功能的详细信息。

转自  Git 2.52 Released With More Preparations Toward Git 3.0 – Phoronix

近期有人提出将 C++20 作为 GCC 编译器的默认 C++语言方言而不是 C++17，发现 GNU 编译器集合本身在 C++20 模式下存在构建问题。

与当前 GCC 编译器使用的默认 C++17 方言（GNU++17）相比，当尝试以 C++20 模式编译 GCC 时，它暴露出自身的一些问题。红帽编译器工程师 Jakub Jelinek 在 GCC 邮件列表上提供补丁以解决 GCC 中的 C++20 构建错误时指出：

“我尝试测试一个将 -std=gnu++17 C++ 默认切换到 -std=gnu++20 的补丁（稍后将发布），但在 GCC 自举过程中遇到了各种问题，我们的代码库尚未完全支持 C++20。

最常见的问题是不同枚举类型的枚举器之间的算术或位运算（或在测试套件中枚举器与浮点数之间），由于忘记在参数内部对 const 进行 const 限定而导致模糊的多重加载运算符 ==，以及 libcody 大部分时间仍停留在 C++ 并与 C++20 不兼容，C++20 引入了 char8_t 类型并使用它来表示 u8 字面量。”

以下补丁修复了我遇到的各种问题，对于 libcody 来说，这个补丁确保包含 cody.hh 的代码可以与-std=gnu++20 一起编译，libcody 本身我在另一个补丁中做了调整。”

这项工作目前正在 gcc-patches 列表上。

这个补丁同时是提议将 GCC 默认的 C++方言改为 C++20/GNU++20 的提案。考虑到明天预计将进入其”阶段三”开发里程碑，是否会在下一次 GCC 16 编译器发布中实现这一点还有待观察。

转自  GCC Developer Discovers “Our Codebase Isn’t Fully C++20 Ready” – Phoronix

随着 Weston 15.0 即将发布，这个 Wayland 参考合成器将终于具备 Vulkan 渲染器功能。对于那些对其潜力感到好奇的人，最近的一次演示概述了这条 Vulkan 代码路径的当前状态。

Red Hat 的 Erico Nunes 主导了为 Weston 开发的 Vulkan 渲染器工作，该渲染器基于现有的 OpenGL 渲染器。这个渲染器针对基本的 Vulkan 1.0 规范，以便能够在尽可能多的 Vulkan 实现上运行。该渲染器几个月前已被合并，并将成为即将发布的 Weston 15.0 的一部分。

埃里科·努内斯在维也纳举行的 XDC2025 会议上介绍了这个 Vulkan 渲染器的状态。尽管如此，未来仍需实现颜色管理支持、YUV 格式以及其他功能。这个 Vulkan 渲染器的使用场景包括仅支持 Vulkan 的平台（无遗留 OpenGL）、Vulkan 驱动的开发/测试、Vulkan 驱动的持续集成（CI），以及可能的嵌入式/自助服务终端用途。Vulkan 渲染器可能比 OpenGL 渲染器具有更低的开销，但这尚未完全证明/量化。

想要了解更多信息的人可以在上方看到努内斯的 XDC2025 会议演示以及幻灯片集。

转自 The State Of The Vulkan Renderer For Wayland’s Weston 15.0 Compositor – Phoronix

Ubuntu 25.10 过渡到使用一些 Rust 系统工具的过程继续证明相当坎坷。除了 Rust Coreutils 早期性能问题、某些可执行文件损坏以及由于 Rust Coreutils 漏洞导致的无人值守升级失败外，sudo-rs 现在也让 Ubuntu 开发者头疼。有两个中等安全问题影响 sudo-rs，即 Ubuntu 25.10 使用的 Rust 版本的 sudo。

上周最初作为私人错误报告提交的是[sudo-rs]更新，用于解决两个中等严重性的漏洞。

“上游将在周五（2025 年 11 月 7 日）发布针对两个中等漏洞的修复。”

预计该修复的协调发布时间是周一（2025 年 11 月 10 日）。

其中一项漏洞是 CVE-2025-64170。

该错误报告现已公开，上游 sudo-rs 的修复程序已提交。Ubuntu 25.10 也将看到一个稳定的发布更新（SRU），用于解决这两个安全问题。

其中一个补丁是为了防止 sudo 密码在超时或 sudo 被终止时泄露。另一个补丁是使用枚举类型来处理反馈参数。另一个补丁是为了确保在退出未缓冲的读取代码之前始终清除反馈。另一个更改也是不将退格键视为密码字符，当密码为空时。

我还没有看到针对这些 sudo-rs 安全问题的 CVE 报告公开，但即使单独来看，在超时或 sudo 被终止时可能泄露 sudo 密码的问题也相当严重。

现在发布的 sudo-rs 0.2.10 包含了最新的修复和其他更改。针对 Ubuntu 25.10 的 sudo-rs 软件包正在 SRU（安全修复更新）过程中提供给用户。

转自  sudo-rs Affected By Multiple Security Vulnerabilities – Impacting Ubuntu 25.10 – Phoronix

11 月头条：C#将首次在历史上超越 Java 吗？

直到最近，没有人能击败 Python 的增长数据。但现在，Python 似乎已经达到了顶峰。取而代之的是，编程语言 C#现在成为了最快增长的编程语言。如果 C#能保持这种速度，它甚至可能成为 2025 年的 TIOBE 编程语言。C#是如何实现这一点的？Java 和 C#长期以来一直在同一领域竞争。现在看起来，C#已经消除了所有不使用 C#而选择 Java 的理由：它现在是跨平台的，它是开源的，并且包含了开发者想要的所有新语言特性。尽管金融世界仍然由 Java 主导，但在其他所有领域 Java 和 C#的份额都是相等的。除此之外，微软正在强势发展，C#仍然是他们最支持的编程语言。有趣的是：在 TIOBE 指数中，C#从未高于 Java。目前，这两大竞争对手之间的差距不到 1%。我们面前有激动人心的时刻。C#将在 TIOBE 指数历史上首次超越 Java 吗？

TIOBE 编程社区指数是编程语言流行度的指标。该指数每月更新一次。评分基于全球技术工程师的数量、课程和第三方供应商。流行的网站如 Google、Amazon、Wikipedia、Bing 以及超过 20 个其他网站被用于计算评分。重要的是要注意，TIOBE 指数并不是关于最佳编程语言或编写最多代码行的语言。

该指数可用于检查您的编程技能是否仍然是最新的，或者当开始构建新的软件系统时，做出关于应采用哪种编程语言的战略决策。TIOBE 指数的定义可以在这里找到。

Nov 2025  2025 年 11 月	Nov 2024  2024 年 11 月	Change  变化	Programming Language  编程语言		Ratings  评分	Change  变化
1	1			Python	23.37%	+0.52%
2	4			C	9.68%	+0.67%
3	2			C++	8.95%	-1.69%
4	3			Java	8.54%	-1.06%
5	5			C#	7.65%	+2.67%
6	6			JavaScript	3.42%	-0.29%
7	9			Visual Basic	3.31%	+1.36%
8	11			Delphi/Object Pascal	2.06%	+0.58%
9	27			Perl	1.84%	+1.16%
10	10			SQL	1.80%	-0.14%
11	7			Go	1.72%	-0.63%
12	18			R	1.67%	+0.65%
13	8			Fortran	1.55%	-0.42%
14	14			Rust	1.39%	+0.21%
15	13			MATLAB	1.38%	+0.11%
16	12			PHP	1.31%	-0.16%
17	25			Ada	1.23%	+0.52%
18	19			Assembly language  汇编语言	1.16%	+0.20%
19	16			Scratch	1.02%	-0.09%
20	20			Kotlin	0.98%	+0.06%

其他编程语言

以下列出了完整的编程语言前 50 名。这个概述是非官方发布的，因为我们可能遗漏了一种语言。如果您觉得缺少了一种编程语言，请通过 tpci@tiobe.com 通知我们。也请查看我们监控的所有编程语言的概述。

下一个 50 种编程语言

以下列表表示第 51 至第 100 种语言。由于差异相对较小，编程语言仅按字母顺序列出。

• ActionScript, Algol, Awk, B4X, Caml, CHILL, CLIPS, Clojure, Common Lisp, Crystal, D, Elm, F#, Forth, GAMS, Groovy, Hack, Icon, Inform, Io, JScript, Logo, Maple, Modula-2, Mojo, MQL5, NATURAL, Nim, OCaml, Occam, OpenCL, PL/I, Q, Racket, REXX, S, Scheme, Simulink, Smalltalk, SPARK, SPSS, Stata, SystemVerilog, Tcl, Transact-SQL, VHDL, Wolfram, X++, XC, Xojo
  ActionScript, Algol, Awk, B4X, Caml, CHILL, CLIPS, Clojure, Common Lisp, Crystal, D, Elm, F#、Forth, GAMS, Groovy, Hack, Icon, Inform, Io, JScript, Logo, Maple, Modula-2, Mojo, MQL5, NATURAL, Nim, OCaml, Occam, OpenCL, PL/I, Q, Racket, REXX, S, Scheme, Simulink, Smalltalk, SPARK, SPSS, Stata, SystemVerilog, Tcl, Transact-SQL, VHDL, Wolfram, X++, XC, Xojo

本月指数变化

本月对指数的定义进行了以下修改：

• Aubell9 建议将 Asymptote 编程语言添加到 TIOBE 指数中。该语言符合所有标准，已被添加到跟踪列表。本月 Asymptote 在 TIOBE 指数中首次亮相，排名第 268 位。

长期历史

为了了解更全面的情况，请查看以下多年来的前 10 种编程语言的排名。请注意，这些是 12 个月期间的平均排名。

Important observations:  重要观察：

• 2001 年之前的数据不是基于网络搜索引擎的计数，而是基于 Usenet 新闻组的点击量，这些点击量是事后计算的。
• 上表中的“Visual Basic”和“(Visual) Basic”有所不同。直到 2010 年，“(Visual) Basic”指的是 Basic 的所有可能方言，包括 Visual Basic。经过一番讨论，决定将“(Visual) Basic”细分为所有其方言，如 Visual Basic .NET、经典 Visual Basic、PureBasic 和 Small Basic 等，仅举几个例子。由于 Visual Basic .NET 已成为 Visual Basic 的主要实现方式，现在被称为“Visual Basic”。
• 在 2018 年，有人指出 SQL 是图灵完备的，因此编程语言 SQL 被添加到了 TIOBE 指数中。所以尽管这种语言很古老，但在指数中的历史却很短。

编程语言名人堂

下表展示了所有“年度编程语言”奖项的获奖者名单。该奖项授予在一年中评级上升幅度最高的编程语言。

Year  年份	Winner  获奖者
2024	Python
2023	C#
2022	C++
2021	Python
2020	Python
2019	C
2018	Python
2017	C
2016	Go
2015	Java
2014	JavaScript
2013	Transact-SQL
2012	Objective-C
2011	Objective-C
2010	Python
2009	Go
2008	C
2007	Python
2006	Ruby
2005	Java
2004	PHP
2003	C++

转自  TIOBE Index – TIOBE

两个已排入 Linux 内核构建系统开发树 kbuild-next 的补丁将允许在编译 Linux 内核时，GCC 和 LLVM/Clang 使用 Microsoft C 扩展的-fms-extensions 编译器参数。由于这些补丁位于 kbuild-next 中，它们很可能会在下个月的 Linux 6.19 内核合并窗口期间提交，但还需观察是否会有任何关于这一变化的最后时刻反对意见。

-fms-extensions 编译器选项由 GNU 编译器集合和 LLVM/Clang 支持，允许启用在 Microsoft 头文件中使用的一些非标准 C/C++结构，并由 Microsoft Visual C/C++编译器认可。出于 Linux 内核开发的目的，启用 Microsoft C 扩展将允许在另一个结构/联合中匿名包含一个标记的结构或联合。

许多年前，就有补丁被提出，无条件地启用 Linux 内核的-fms-extensions，但它们并没有通过 Linux 内核邮件列表。但现在，随着这两个补丁进入 kbuild-next，这意味着它很可能会在没有任何著名 Linux 内核开发者或 Linus Torvalds 本人的反对意见的情况下，提交给 Linux 6.19 内核合并窗口。

Rasmus Villemoes 与 Kbuild 进行了争论：启用-fms-extensions，这将允许“更漂亮的代码”，其他人过去也指出，这有可能节省栈空间，并在整体上能够利用 Microsoft C 的行为：

“偶尔，启用-fms-extensions 可能会让代码看起来稍微美观一些。但每次提出这个要求时，不得不使用的代码都被认为‘还算不错’，不值得引入另一个编译器标志。

这可能对每个具体案例都适用，但这也形成了一个鸡生蛋还是蛋生鸡的情况。

如果我们像 Linus 说的那样“咬紧牙关”，一次性启用它，那么它将在需要时随时可用，无需任何个别案例来证明其合理性。

在 lore.kernel.org 的搜索中提供了以下示例：

– https://lore.kernel.org/lkml/200706301813.58435.agruen@suse.de/
– https://lore.kernel.org/lkml/20180419152817.GD25406@bombadil.infradead.org/
– https://lore.kernel.org/lkml/170622208395.21664.2510213291504081000@noble.neil.brown.name/
– https://lore.kernel.org/lkml/87h6475w9q.fsf@prevas.dk/
– https://lore.kernel.org/lkml/CAHk-=wjeZwww6Zswn6F_iZTpUihTSNKYppLqj36iQDDhfntuEw@mail.gmail.com/

毫无疑问，代码中还有更多地方也可以使用这种方法，但“-fms-extensions”并没有在任何讨论中提到。”

第二个补丁是 kbuild：为具有专用 CFLAGS 的区域添加’-fms-extensions’，以确保为依赖于自己 CFLAGS 设置的 CPU 架构传递-fms-extensions，而不是主 KBUILD_CFLAGS。

Linus Torvalds 在之前的邮件列表讨论中发表了意见，看起来他并不反对从 Linux 6.19 内核开始启用-fms-extensions。

启用 -fms-extensions 将允许 C 代码看起来更好，尽管有些人可能觉得允许微软 C 行为在主线 Linux 内核编码中是错误的。

转自 The Linux Kernel Looks To “Bite The Bullet” In Enabling Microsoft C Extensions – Phoronix

作为 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）等场景。