网站头条

‌

五月头条：统计编程语言市场正经历重大整合‌

本月，编程语言 R 再次达到其历史最高排名——在 TIOBE 指数中重回第 8 位。这并非偶然。统计编程语言市场正在经历一场显著的整合。最大的赢家是 Python 和 R，而许多长期存在的替代语言则持续失去动力。曾经统计计算领域由众多小众语言和平台割据的时代，似乎正在走向终结。

多个老牌选手正稳步下滑：

• MATLAB 已接近跌出 TIOBE 前 20 名。
• SAS 自 TIOBE 指数发布以来，首次面临跌出前 30 名的风险。
• Wolfram/Mathematica 仍远低于其历史峰值，并进一步失去市场份额。
• SPSS 上月已跌出前 100 名。
• S 语言也接近跌出前 100 名。
• Stata 目前位列第 124 位。

与此同时，较新的统计语言 Julia 尽管技术优势明显且在学术界兴趣日益增长，却多年来一直难以稳定跻身 TIOBE 前 30 名。展望未来，Stan 预计将在下月首次进入 TIOBE 指数，反映出‌概率编程‌（probabilistic programming）和‌贝叶斯统计‌（Bayesian statistics）日益增长的重要性。

在实际应用中，当今的统计编程市场正越来越集中于两个主导生态：

• ‌Python‌ 主导工业界、机器学习、人工智能和生产系统。
• ‌R‌ 仍是学术界、科研、流行病学和高级统计分析领域的领先环境。

在榜单其他位置，Java 和 C++ 本月互换了排名。Java 在成功发布 Java 26 后重获 momentum（发展势头）。另一个显著上升的语言是 Zig，它首次接近进入 TIOBE 前 30 名。Zig 日益增长的受欢迎程度，似乎源于其罕见的特性组合：底层性能、简洁的工具链，以及相较于传统系统编程语言而言更易上手的使用体验。

TIOBE 编程社区指数是衡量编程语言受欢迎程度的一项指标。该指数每月更新一次。其评分依据来自全球范围内具备相关技能的工程师数量、培训课程以及第三方供应商的数量。计算评分时参考了 Google、Amazon、Wikipedia、Bing 等超过 20 个主流网站的数据。需要特别注意的是，TIOBE 指数并不反映哪种编程语言“最好”，也不是衡量哪种语言编写了最多代码行数的指标。

该指数可用于检验你的编程技能是否仍然符合当前行业趋势，或在启动新软件系统开发时，作为战略性决策工具，帮助选择应采用的编程语言。TIOBE 指数的具体定义可在此处查阅。

May 2026	May 2025	Change	Programming Language		Ratings	Change
1	1			Python	19.98%	-5.37%
2	3			C	11.55%	+1.84%
3	4			Java	7.94%	-1.37%
4	2			C++	7.92%	-2.02%
5	5			C#	5.41%	+1.19%
6	6			JavaScript	3.08%	-0.60%
7	8			Visual Basic	2.90%	+0.28%
8	12			R	1.77%	+0.31%
9	10			SQL	1.57%	-0.33%
10	9			Delphi/Object Pascal	1.44%	-0.85%
11	11			Fortran	1.22%	-0.55%
12	14			Scratch	1.18%	-0.16%
13	16			Perl	1.18%	-0.02%
14	15			PHP	1.15%	-0.07%
15	19			Rust	1.14%	+0.21%
16	7			Go	1.12%	-1.58%
17	18			Assembly language	1.02%	+0.05%
18	23			Swift	0.93%	+0.16%
19	13			Ada	0.92%	-0.50%
20	17			MATLAB	0.89%	-0.13%

其他编程语言
以下是编程语言完整前50名的列表。此榜单为非官方发布，因为我们有可能遗漏了某种编程语言。如果您觉得某种编程语言未被包含在内，请通过 tpci@tiobe.com 与我们联系。也欢迎查看我们所监控的所有编程语言的完整列表。

以下是第51至第100名的编程语言列表‌（按字母顺序排列），由于排名差异较小，仅列出语言名称：

(Visual) FoxPro, ActionScript, Apex, Applescript, Awk, Bash, bc, BCPL, Bourne shell, C shell, CL (OS/400), CoffeeScript, cT, ECMAScript, Elixir, F#, GAMS, Groovy, Io, J, J#, JScript, JScript.NET, Logo, LotusScript, LPC, MDX, MQL5, NetLogo, OpenCL, PL/I, PowerShell, Pure Data, Q, REBOL, Ring, RPG, RPL, S, Scheme, Small Basic, Solidity, Tcl, V, Vala/Genie, VHDL, Wolfram, XC, Xojo, XPL

‌长期历史趋势‌
为展现更宏观的图景，以下是多年前各年度前10名编程语言的平均排名（基于12个月周期的平均位置）。

‌重要观察说明：‌‌

2001年之前的数据并非基于网页搜索引擎的搜索次数统计，而是基于Usenet新闻组（Usenet’s newsgroup）的访问量，这些数据是事后回溯计算得出的。‌

 

‌上表中，“Visual Basic”与“(Visual) Basic”存在区别。在2010年之前，“(Visual) Basic”涵盖所有Basic语言的变体（dialects），包括Visual Basic。经过讨论后，决定将“(Visual) Basic”拆分为其各个子类，例如Visual Basic .NET、Classic Visual Basic、PureBasic和Small Basic等。由于Visual Basic .NET已成为Visual Basic最主要的形式，因此现在“Visual Basic”这一名称特指Visual Basic .NET。

‌编程语言SQL于2018年被加入TIOBE指数，原因是有人指出SQL是图灵完备的（Turing Complete）。因此，尽管这种语言非常古老，但它在该指数中的历史很短。

‌编程语言名人堂‌
下方列出的是所有“年度编程语言”奖项的获奖者名单。该奖项授予在一年内评分涨幅最高的编程语言。

Year	Winner
2025	C#
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

在 Debian 14 “Forky” 开发周期进行到一半之际，Debian 发布团队于本周末发布了更新，并带来了若干重大消息。

Debian 发布团队已决定，现在是时候正式宣布：‌Debian 必须提供可复现构建的软件包‌。过去几年中，Debian 通过“可复现构建”（Reproducible Builds）项目取得了显著进展，该项目旨在确保独立用户能够逐位（bit-for-bit）地复现相同的软件包构建结果或二进制文件。从源代码到二进制文件的‌独立可验证路径‌，在当前的安全考量中变得愈发重要，也成为验证软件包真实性的关键手段。

未来，Debian 必须提供可复现构建的软件包，因此即将到来的 Debian 14.0 将是首个遵循这一新强制要求的主要版本。自昨日开始，Debian 的软件包迁移系统将‌阻止无法复现的新软件包进入稳定分支‌，同时也将阻止那些原本可复现但后来出现倒退（regress）的现有软件包迁移。

此外，Debian 发布团队还宣布了一个令人振奋的消息：两周前，他们已正式将 ‌LoongArch 64 位架构（“Loong64”）‌ 添加至官方软件包仓库中。这并不令人意外，因为去年就已宣布 Debian 14 将支持 LoongArch64 架构；如今，这一计划终于实现。LoongArch 是一种源自中国的 CPU 指令集架构（ISA），颇具特色。我很快就会在龙芯 3B6000 评测平台上试用 Debian 测试版。

上述信息由 Debian 发布团队于今日发布在 devel-announce 邮件列表上。

转自 Debian Release Team: Debian Must Now Ship Reproducible Packages – Phoronix

趣图:你是如何使用鼠标的

第三种是暴露年龄的用法

第三种是暴露年龄的用法

今天提交了一批针对 AMDGPU 图形驱动和 AMDKFD 计算内核驱动的“新内容”，这些内容将进入 DRM-Next 队列，等待 6 月份 Linux 7.2 版本合并窗口开启时并入主线。其中最引人注目的是引入了 ‌AMDGPU DC 电源模块‌，旨在使 Linux 下的 Radeon 显卡电源管理行为更好地与 Microsoft Windows 保持一致。

本次提交的拉取请求（pull request）包含了将新电源模块集成到 AMDGPU 显示核心（Display Core，简称 DC）中的工作。正如 Phoronix 网站在该电源模块首次以补丁形式发布时所报道的那样，其目标是更有效地管理诸如背光控制（backlight）和面板自刷新（Panel Self Refresh）等电源功能，使其行为方式与其他操作系统（特别是 Microsoft Windows）更加相似。当 Windows 和 Linux 都使用这一 DC 电源模块后，有望在显示相关的电源管理方面提供更一致的用户体验，并且由于 Windows 平台对这些功能进行了更全面的质量保证（QA）和验证（validation），Linux 用户也可能因此受益，减少 AMD 显卡在 Linux 上使用时的各种异常或兼容性问题。

除了 DC 电源模块之外，今天的 AMDGPU 补丁还包含以下更新：

• 针对旧款 GFX9/Vega 架构硬件的修复；
• 完成了对使用多个 SDMA 队列执行 TTM 内存管理操作的支持；
• AMD GFX12.1 图形引擎 IP 的更新；
• DCN 4.2 显示 IP 的更新；
• 计算队列状态描述符（MQD）的更新；
• 以及其他多项改进。

与此同时，AMDKFD 计算驱动也在这次更新中获得了多项修复。

部分提交至 DRM-Next 的修复内容，此前已在 Linux 7.1 版本周期中作为紧急修复提交过，主要涉及各种 AMD GCN 1.0/1.1 架构的修复，包括那些被称为“收割型”（harvested）GPU 以及其他在从旧版 Radeon 驱动迁移到现代 AMDGPU 内核驱动过程中出现问题或性能退化的配置。

‌amdgpu 驱动：‌

• GFX9 架构修复
• Hawaii SMU 模块修复
• SDMA4 模块修复
• GART（图形地址重映射表）修复
• Userq（用户队列）修复
• 完成对使用多个 SDMA 队列执行 TTM 内存管理操作的支持
• SWSMU 模块更新
• 其他杂项清理与修复
• GC 12.1 图形核心更新
• RAS（可靠性、可用性与可服务性）功能更新
• SMU 15.0.8 版本更新
• DCN 4.2 显示控制器更新
• DC 类型转换修复
• 启用 DC 电源模块
• Replay（重播）与 PSR（面板自刷新）功能更新
• SMU 13.x 版本更新
• 计算队列时间片（MQD）状态描述符更新
• ASPM（活动状态电源管理）修复
• GPUVM（GPU 虚拟内存）修复
• DCE 6 架构修复
• 使 VKMS（虚拟 KMS）实现与通用标准保持一致
• RDNA 4 架构修复
• DC 模拟输出支持修复
• UVD 3 视频解码单元修复
• 针对 SI 架构的 TCC（纹理缓存压缩）“收割型”GPU 修复
• GC 11 APU 模块重载修复
• NBIO 6.3.2 支持
• IH 7.1（中断处理）更新
• DC 光标功能修复
• VCN（视频核心下一代）用户围栏（fence）修复
• JPEG 引擎用户围栏修复
• 支持无 DDC（显示数据通道）的连接器的 DC 功能
• 对默认 VGA 设备优先使用 ROM BAR（基地址寄存器）
• DC 带宽计算修复

‌amdkfd 驱动：‌

• GPUVM TLB（转译后备缓冲）刷新修复
• 热插拔（Hotplug）功能修复
• 边界检查修复
• 其他杂项清理与修复
• SVM（共享虚拟内存）修复
• CRIU（检查点/恢复在用户空间）功能修复

‌radeon 驱动：‌

• Hawaii SMU 模块修复
• 其他杂项清理与修复

请参阅此拉取请求以查看今日提交用于 DRM-Next 集成的完整补丁列表。预计在未来几周内还将提交更多补丁，AMD 仍有时间在 Linux 7.2 合并窗口开启前准备更多的内核图形驱动变更。

转自 Linux 7.2 To Integrate The AMDGPU “Power Module” To Better Align With Windows – Phoronix

Linux 内核源码树中文件系统数量的不断增长，给负责维护其周边虚拟文件系统（VFS）代码及相关代码的上游开发者带来了持续的负担。由于不断有新的文件系统被提议加入 Linux 内核，因此引入了新的文档，以确立将新文件系统纳入主线内核的明确指导方针。

从 fs/ 目录下的文件夹来看，截至当前 v7.1 版本开发阶段，主线 Linux 内核中大约包含了 69 种不同的文件系统（例如，NFS 就占用了多个目录）。这些文件系统包括 EXT4、Btrfs、F2FS 和 XFS 等本地文件系统，也包括 NFS 这样的网络文件系统，以及 proc 这样的伪文件系统（pseudo file-system），还有 ZoneFS 这类专用文件系统，甚至包括 BeFS 和 JFS 等早已过时的遗留系统。Linux 上如此庞大的文件系统阵容带来了巨大的维护压力，尤其是当某些文件系统不再有活跃的维护者时，问题更加严重。

由于最近又提出了 FTRFS 和 VMUFAT 两种新文件系统的提案，加之“被遗弃且无法测试的文件系统给 VFS 开发者带来的持续维护负担”，VFS 维护者决定是时候制定一份文档，为新文件系统进入主线内核设立更加清晰、明确的准入标准。

该文档重点关注‌采用性‌、‌可测试性‌、‌用户态工具支持‌、‌维护者的承诺‌以及‌用户基础的可持续性‌。文档建议开发者在可能的情况下，优先考虑‌扩展现有的文件系统‌，而不是从头创建一个新的文件系统。对于一些‌小众用途的文件系统场景‌，也鼓励尽可能使用运行在用户空间的文件系统（如 FUSE）来实现。

所提出的技术要求包括：必须使用现代的 VFS 接口，不得依赖已被标记为废弃（deprecated）的代码；必须提供必要的用户态工具，以支持文件系统的创建和检查（如 mkfs 和 fsck 类工具）；需要具备有意义的测试方案，并提供完整的文档说明。

文档还明确指出，如果一个文件系统因维护者‌不再响应‌、‌未能适配 Linux 内核基础设施的变化‌，或导致‌测试无法进行‌，那么该文件系统可能会被标记为‌弃用‌（deprecation），并最终从 Linux 内核中移除。

感兴趣的人士可以在 VFS.git 开发树中名为 “vfs-7.2.misc” 的补丁队列中找到这份初步的文档，该补丁计划在今夏 Linux 7.2 合并窗口开启前被合并。

转自 Linux File-System Proliferation A Burden: Requirements Laid Out For Any Future File-Systems – Phoronix

杰瑞·贝曾康（Jerry Bezencon）已宣布推出即将发布的 ‌Linux Lite 8.0‌ 的首个发布候选版本（RC1），这是该项目基于 Ubuntu 的发行版的一次重大更新，采用 Xfce 桌面环境。此次发布带来了新的高性能 Linux 内核、Calamares 系统安装程序以及一个自定义发行版构建工具。

“Linux Lite 8.0 RC1 现已可供测试。平台变更如下：基于 Ubuntu 26.04 LTS（此前为 24.04 LTS）；新增 Linux Lite 高性能定制内核；所有图形界面应用程序已迁移至 GTK4；APT 软件源已迁移到 DEB822 .sources 格式（取代传统的 .list 文件）；安装程序方面，Calamares 取代了原有的 Ubiquity；Python 升级至 3.14.4+ 版本（此前为 3.12）；新增 Plymouth 启动动画主题——动态羽毛旋转图标（基于脚本实现，取代原有的文本式启动画面）；为硬件厂商提供 OEM 安装支持。

新增应用包括：Firefox 浏览器重新回归；Lite Distro Builder —— 创建你自己的 Linux Lite 版本并与他人分享；Lite About —— 一款全新的基于 GTK4 的系统信息查看工具，可显示 CPU、GPU、内存、存储、网络和音频硬件的详细信息；Lite System Monitor —— 实时监控 CPU、内存、存储和网络使用情况（基于 System Monitoring Center 开发）；Linux Lite 高性能定制内核；Lite Core —— 将 Linux Lite 剥离到最精简状态，按需自定义构建……

请阅读发布公告的其余部分，了解完整的变更列表。下载：linux-lite-8.0-rc1-64bit.iso（2,534MB，SHA256，种子，pkglist）。

转自 Development Release: Linux Lite 8.0 RC1 (DistroWatch.com News)

由 Xint Code 发现的“复制失败”（CVE-2026-31431）安全漏洞——该漏洞可能允许本地用户将权限提升至 root 用户——已在 Debian、Ubuntu、AlmaLinux OS 以及其他受此缺陷影响的主流发行版中得到修复。

2026 年 4 月 29 日，一个影响 Linux 内核的本地权限提升漏洞被公开披露，编号为 CVE-2026-31431，被称为“Copy Fail”。该漏洞存在于 algif_aead 内核模块中，该模块用于提供硬件加速的加密功能。

‌谁受影响？‌
此漏洞主要影响多租户 Linux 主机、容器集群以及标准 Linux 服务器。如果你是系统上唯一的用户，那么你基本是安全的，因为该漏洞本身不会赋予远程攻击者访问权限，但可通过本地代码执行加以利用。

在不运行容器工作负载的 Linux 主机上，该漏洞允许本地用户将权限提升至 root 用户。在可能执行潜在恶意工作负载的容器部署中，该漏洞可能导致容器逃逸（container escape）场景。

‌哪些内核受影响？‌
受影响的受支持 Linux 内核包括 6.12 LTS、6.6 LTS、6.1 LTS、5.15 LTS 和 5.10 LTS，目前已分别通过版本 6.12.85、6.6.137、6.1.170、5.15.204 和 5.10.254 修复了“Copy Fail”漏洞。此外，运行已结束生命周期（EOL）内核的发行版（如 Linux 6.17 或 6.19，例如 Ubuntu 25.10）也受到影响。

主要发行版厂商（如 Debian、Ubuntu、AlmaLinux、Fedora、SUSE、Red Hat 等）均已发布针对 Linux 内核的安全补丁。然而，一些运行最新 Linux 7.0 内核的新版发行版（如 Ubuntu 26.04 LTS）似乎不受此漏洞影响。

与往常一样，请确保你的 GNU/Linux 发行版始终安装了最新的更新。如果你认为你的发行版受到“Copy Fail”漏洞的影响，请务必及时为其打上补丁。

转自 Copy Fail Linux Kernel Vulnerability Now Patched in Debian, Ubuntu, and Others – 9to5Linux