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

Linus Torvalds: “AI 混乱问题 *NOT* 会通过文档解决”

Editor, Kai

Linus Torvalds: "AI 混乱问题 *NOT* 会通过文档解决"

Linux 内核开发人员已经数月来一直在讨论提交给 Linux 内核的工具生成提案的指南。作为“工具”的一部分,这份文档的主要动机围绕着人工智能和大型语言模型以及编码助手的时代。考虑到人工智能辅助的贡献可能会继续,无论文档如何,Torvalds 在 Linux 内核邮件列表上就专注于“工具”而不是明确专注于人工智能发表了一些评论。

对于想知道 Linus Torvalds 最近关于 AI 辅助的 Linux 内核补丁的立场的人来说,他在这场讨论中发表了一些有用且切中要害的看法:

“| 将 LLMs 视为‘仅仅是另一种工具’实际上是说内核
| 这不受此影响。这在我看来是个愚蠢的立场。

不。你的立场才是愚蠢的。

讨论 AI 垃圾毫无意义。这纯粹是愚蠢。

“为什么?因为那些AI垃圾人不会把他们的补丁记录为补丁。这真是个‌讨厌的‌(或‌令人反感的‌)问题。”

所以停止这种愚蠢的行为。

文档是给好演员准备的,假装其他任何事都是毫无意义的姿态。

正如我在私下里 elsewhere 所说的,我不希望任何内核开发文档变成某种 AI 声明。我们双方都有足够多的人认为”世界末日”和”将彻底改变软件工程”,我不希望某些内核开发文档采取任何立场。

这就是为什么我强烈希望这是那种”只是一个工具”的声明。

AI 混乱问题*绝对*不会通过文档解决,任何认为可以解决的人要么是天真,要么是想“发表声明”。

这两者都不是文档的好理由。”

Linus Torvalds 的思考非常合理且切中要害。关于 Linux 内核的 AI/工具文档的讨论仍在继续。

转自  Linus Torvalds: “The AI Slop Issue Is *NOT* Going To Be Solved With Documentation” – Phoronix

所有 Fedora 44 KDE 版本将使用 Plasma 登录管理器而不是 SDDM

Editor, Kai

Fedora 工程与指导委员会(FESCo)已批准 Fedora 44 的一项变更,将所有 KDE 变体从使用 SDDM 显示管理器切换到使用更新的 Plasma 登录管理器。

在过去的一年中,KDE 开发者一直在开发 Plasma 登录管理器,作为 SDDM 的现代替代方案,并将 GNOME 的 GDM 视为登录/显示管理器的”黄金标准”。

所有 Fedora 44 KDE 版本将使用 Plasma 登录管理器而不是 SDDM

Fedora 44 变更提案概述了 KDE 版本 Fedora Linux 的益处:

“即将发布的 KDE Plasma 6.6 版本将附带一个新的集成登录管理器。作为发布的一部分,Fedora KDE 版本将切换使用它而不是 SDDM。这将改变 Fedora KDE Plasma 桌面版、Fedora KDE Plasma 移动版和 Fedora Kinoite。

这使 Fedora 能够继续为其旗舰版提供最高质量、最前沿的集成 KDE Plasma 体验,并通过利用推荐的堆栈支持其新兴版本的开发,从而实现从启动到关机的流畅体验。”

本周 FESCo 批准了从 SDDM 切换到 Plasma 登录管理器的变更,以进一步增强 Fedora 上 KDE Plasma 的体验。

转自   All Fedora 44 KDE Variants To Use Plasma Login Manager Rather Than SDDM – Phoronix

2026 年 1 月 TIOBE 指数

Editor, Kai

2026 年 1 月 TIOBE 指数

这是第三次,C# 语言再次被 TIOBE 指数评为年度编程语言。C# 通过获得最大的年度排名提升而获得这一殊荣。多年来,这门语言经历了根本性的变化。从语言设计的角度来看,C# 一直很早地采用主流语言的新趋势。同时,它成功地进行了两次主要的范式转变:从仅限 Windows 到跨平台,以及从微软所有到开源。C# 始终在关键时刻不断演进。

多年来,Java 和 C#一直在商业软件市场中展开直接竞争。我一直认为 Java 最终会胜出,但经过这么长时间,这场竞争仍未分出胜负。Java 能否继续压制 C#,仍然是一个开放的问题,毕竟 Java 以其冗长、充满样板代码的风格以及 Oracle 的拥有权而著称。

2025 年排名前十中也出现了一些有趣的变动。C 和 C++交换了位置。尽管 C++正在以前所未有的速度发展,但其中一些激进的改动,如模块概念,尚未在业界得到广泛采用。与此同时,C 语言依然保持简单、快速,并且非常适用于不断增长的小型嵌入式系统的市场。即使 Rust 本月达到了历史最高的第 13 名,也仍然难以在这一领域取得突破。

那么,除了 C#之外,2025 年的其他赢家是谁呢?Perl 出人意料地重回榜单,从第 32 名跃升至第 11 名,重新进入前 20 名。另一门语言 R 也重返前十,这主要得益于数据科学和统计计算领域的持续增长。

当然,有赢家的地方也必然有输家。Go 在 2025 年似乎永久失去了前十名的位置。Ruby 也似乎同样失去了前二十名的位置,而且短期内不太可能重返榜单。

那么我们能从 2026 年期待什么呢?我有很长一段时间都在做错误的预测,但我怀疑 TypeScript 最终会进入前十名。此外,Zig 在 2025 年从第 61 位攀升至第 42 位,看起来是进入 TIOBE 前 30 名的有力竞争者。

 

TIOBE 编程社区指数是衡量编程语言流行程度的指标。该指数每月更新一次。排名是基于全球熟练的工程师数量、课程和第三方供应商。用于计算排名的流行网站包括 Google、Amazon、Wikipedia、Bing 以及 20 多个其他网站。需要注意的是,TIOBE 指数并不是关于最好的编程语言,也不是关于编写最多代码的语言。

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

2026 年 1 月 2025 年 1 月 变更 编程语言 评分 变化
1 1 2026 年 1 月 TIOBE 指数 Python 22.61% -0.68%
2 4 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 C 10.99% +2.13%
3 3 2026 年 1 月 TIOBE 指数 Java 8.71% -1.44%
4 2 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 C++ 8.67% -1.62%
5 5 2026 年 1 月 TIOBE 指数 C# 7.39% +2.94%
6 6 2026 年 1 月 TIOBE 指数 JavaScript 3.03% -1.17%
7 9 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Visual Basic 2.41% +0.04%
8 8 2026 年 1 月 TIOBE 指数 SQL 2.27% -0.14%
9 11 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Delphi/Object Pascal 1.98% +0.19%
10 18 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 R 1.82% +0.81%
11 32 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Perl 1.63% +1.14%
12 10 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Fortran 1.61% -0.42%
13 14 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Rust 1.51% +0.34%
14 15 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 MATLAB 1.40% +0.34%
15 13 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 PHP 1.38% -0.00%
16 7 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Go 1.24% -1.37%
17 12 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Scratch 1.24% -0.31%
18 26 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Ada 1.19% +0.54%
19 17 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Assembly language  1.07% +0.05%
20 25 2026 年 1 月 TIOBE 指数 2026 年 1 月 TIOBE 指数 Kotlin 0.97% +0.23%
 

其他编程语言

编程语言的完整前 50 名如下所示。此概览为非正式发布,因为有可能我们遗漏了某种语言。如果您觉得缺少某种编程语言,请通过 tpci@tiobe.com 通知我们。也请检查我们监控的所有编程语言的概览。

排名 编程语言 评分
21 COBOL 0.95%
22 Swift 0.91%
23 Prolog 0.87%
24 Classic Visual Basic 0.80%
25 SAS 0.78%
26 Dart 0.63%
27 Ruby 0.58%
28 Julia 0.57%
29 Objective-C 0.46%
30 Lua 0.43%
31 Lisp 0.34%
32 TypeScript 0.32%
33 Scala 0.32%
34 PL/SQL 0.32%
35 (Visual) FoxPro 0.32%
36 Haskell 0.32%
37 ABAP 0.28%
38 VBScript 0.25%
39 Elixir 0.20%
40 Ladder Logic 0.20%
41 Solidity 0.19%
42 Zig 0.19%
43 Erlang 0.18%
44 PowerShell 0.17%
45 Apex 0.17%
46 LabVIEW 0.16%
47 Wolfram  0.16%
48 Bash 0.16%
49 RPG 0.15%
50 ML 0.15%

未来 50 种编程语言

以下语言列表表示排名 #51 到 #100。由于排名差异相对较小,仅列出编程语言(按字母顺序排列)。

  • ActionScript, Algol, Applescript, Awk, B4X, Caml, Clojure, Common Lisp, D, Elm, Emacs Lisp, F#, Forth, GAMS, Groovy, Hack, Icon, Inform, Io, J, J#, JScript, Logo, Maple, Modula-2, Mojo, MQL5, NATURAL, Nim, NXT-G, OCaml, OpenCL, PL/I, PostScript, Q, Racket, REXX, Scheme, Smalltalk, SPARK, Stata, Structured Text, SystemVerilog, Tcl, Transact-SQL, V, Vala/Genie, VHDL, X++, Xojo

非常长期的历史

要了解整体情况,请查看以下多年度排名前十的编程语言位置。请注意,这些是 12 个月期间的平均排名位置。

编程语言 2026 2021 2016 2011 2006 2001 1996 1991 1986
Python 1 3 5 7 8 26 14
C++ 2 4 3 3 3 2 2 2 9
C 3 1 2 2 1 1 1 1 1
Java 4 2 1 1 2 3 31
C# 5 5 4 6 7 11
JavaScript 6 7 7 11 10 9 33
Visual Basic 7 9 11
Go 8 13 60 17
Delphi/Object Pascal 9 190 12 10 9
SQL 10 11
Ada 15 35 27 23 17 18 5 10 3
Lisp 26 31 29 15 14 20 7 3 2
(Visual) Basic 5 6 4 3 5 4

重要观察:

  • 2001 年以前的数据并非基于网络搜索引擎的计数,而是基于 Usenet 新闻组的点击次数,这些数据是事后计算得出的。
  • 表格中”Visual Basic”和”(Visual) Basic”之间存在差异。直到 2010 年,”(Visual) Basic”指的是所有可能的 Basic 变体,包括 Visual Basic。经过一些讨论,决定将”(Visual) Basic”拆分为所有其变体,例如 Visual Basic .NET、Classic Visual Basic、PureBasic 和 Small Basic 等。由于 Visual Basic .NET 已成为 Visual Basic 的主要实现,因此现在它被称为”Visual Basic”。
  • SQL 编程语言在 2018 年被加入 TIOBE 指数,因为有人指出 SQL 是图灵完备的。因此,尽管这门语言非常古老,它在指数中的历史却很短暂。

编程语言名人堂

以下列出了所有“年度编程语言”奖项的获得者。该奖项颁发给在一年中评分上升最高的编程语言。

年份 Winner
2025 2026 年 1 月 TIOBE 指数 C#
2024 2026 年 1 月 TIOBE 指数 Python
2023 2026 年 1 月 TIOBE 指数 C#
2022 2026 年 1 月 TIOBE 指数 C++
2021 2026 年 1 月 TIOBE 指数 Python
2020 2026 年 1 月 TIOBE 指数 Python
2019 2026 年 1 月 TIOBE 指数 C
2018 2026 年 1 月 TIOBE 指数 Python
2017 2026 年 1 月 TIOBE 指数 C
2016 2026 年 1 月 TIOBE 指数 Go
2015 2026 年 1 月 TIOBE 指数 Java
2014 2026 年 1 月 TIOBE 指数 JavaScript
2013 2026 年 1 月 TIOBE 指数 Transact-SQL
2012 2026 年 1 月 TIOBE 指数 Objective-C
2011 2026 年 1 月 TIOBE 指数 Objective-C
2010 2026 年 1 月 TIOBE 指数 Python
2009 2026 年 1 月 TIOBE 指数 Go
2008 2026 年 1 月 TIOBE 指数 C
2007 2026 年 1 月 TIOBE 指数 Python
2006 2026 年 1 月 TIOBE 指数 Ruby
2005 2026 年 1 月 TIOBE 指数 Java
2004 2026 年 1 月 TIOBE 指数 PHP
2003 2026 年 1 月 TIOBE 指数 C++

转自 TIOBE 指数 – TIOBE — TIOBE Index – TIOBE

Linux 解决在大型核心系统中 Out-Of-Memory Killer 的不准确性

Editor, Kai

一个补丁正在前往 Linux 内核的路上,看起来可能在 6.20~7.0 内核版本中准备好,以解决在处理大量核心系统时 OOM 杀手的不准确性行为。

本周,由 Linux 开发者 Mathieu Desnoyers 提交的补丁进入了 Andrew Morton 的 “mm-everything” 队列,旨在修复在大型多核系统上 OOM 杀手的不准确性问题。

Linux 解决在大型核心系统中 Out-Of-Memory Killer 的不准确性

2025 年初报告称,在处理当今高核心数系统时,OOM 杀手存在不准确性,至少在 250 核/线程以上的范围内:

“最近,几个内部服务在内核升级过程中出现了 RSS 使用量的回归问题。之前,它们运行在 6.2 版本之前的内核上,并能够通过备份看门狗进程读取 RSS 统计信息来监控并决定是否超出了内存预算。然而现在,一个具有五个线程的代表性服务,预计使用约一百 MB 内存,在一个 250 核的机器上,其内存使用量与预期值相差数十 MB —— 这构成了相当大的不准确性,导致看门狗进程采取了行动。

这对于任何在大型机器上的少量线程程序来说都是一个巨大的不准确性,严重影响了监控效果。这些统计计数器也用于做出 OOM 杀死决策,因此这种额外的不准确性可能在 OOM 情况下产生重大影响 —— 无论是导致错误的进程被杀死,还是 OOM 杀死后返回的内存少于预期。”

最后,虽然对 percpu_counter 的更改在许多多线程服务中显著提高了准确性,相比之前的每线程错误,但它也带来了性能影响 – 短生命周期进程可能慢达 12%,在 make test 工作负载中系统时间增加 9%。

此补丁正在前往主线内核的途中,希望能在即将到来的 Linux 6.20~7.0 版本周期中得到解决,以纠正这些不准确之处。

转自  Linux Addressing Out-Of-Memory Killer Inaccuracy On Large Core Count Systems – Phoronix

Intel 的 Xe Linux 驱动程序将在 2025 年底推出,支持多设备 SVM

Editor, Kai

英特尔的开源图形驱动程序工程师在 2025 年底迎来了一个高潮。今天发布的将是今年最后一个 drm-xe-next 的拉取请求,其中包含了准备用于下一个 Linux 内核版本的新功能代码。今天的拉取请求新增了对 SR-IOV 调度器组的支持,以及多设备共享虚拟内存(SVM)的支持。

drm-xe-next 的拉取请求正在前往 drm-next 的途中,作为代码提前排队,以便在下一个内核周期中使用。这个内核周期将被称为 Linux 6.20,或者更有可能是 Linux 7.0。这个新内核具有重要意义,因为它预计将成为 Ubuntu 26.04 LTS 的默认内核。

通过这次更新的 Xe 驱动程序代码,下一个 Linux 内核版本将支持跨英特尔显卡的多设备 SVM 共享虚拟内存。这对于使用 Level Zero 或 OpenCL 的多设备 AI 和 GPU 计算工作负载非常重要。在过去的一年中,英特尔的 Xe SVM 支持已经趋于完善,现在多设备支持也已经实现,这对于他们 Project Battlematrix 计划(涉及多块 Arc Pro B 系列显卡或即将推出的 Crescent Island AI 推理加速卡)至关重要。

此次拉取请求的另一个显著特性是 SR-IOV 调度器组。此前针对 Intel SR-IOV 调度器组的补丁系列将其描述为:

“传统的 SRIOV 设置会将整个 GT(图形处理单元)在 VFs(虚拟功能)之间进行时间片分配。虽然在大多数情况下这是可以接受的,但在某些情况下,管理员知道某个 VF 不会使用全部的 GT 硬件,而某些引擎将会长期处于空闲状态。

为了在这种情况下提高硬件利用率,从 v70.53.0 版本开始,GuC(图形微代码)支持调度组(也称为引擎组调度或 EGS)功能;这一特性允许驱动程序将一个 GT 划分为多个引擎组,GuC 随后会独立地在 VFs 之间进行时间片分配,从而允许多个 VF 同时访问硬件。由于每个组都是独立调度的,因此每个组每个 VF 的执行时间片和抢占超时时间都可以单独设置。请注意,虽然 GuC 从 v70.53.0 版本开始支持该功能,但一些相关的修复在 v70.55.1 版本中合并,因此我们要求驱动程序使用后者版本。”

drm-xe-next 拉取请求现在还配置了迁移队列为低延迟,系统控制器的 SoC 重映射器支持,可调整的 BAR“ReBAR”更新,以及其他一些小的更改。

随着 Project Battlematrix 接近 2025 年底,这是一个提出他们软件路线图的好时机,从 Computex 带回:

Intel 的 Xe Linux 驱动程序将在 2025 年底推出,支持多设备 SVM

在上游内核的状态下,他们基本上已经达到了目标。vLLM 优化仍在进行中,SR-IOV 改进持续进行,而遗留的性能优化则是一场永无止境的战斗。随着多设备 SVM 和更多 SR-IOV 工作将在 Linux 6.20~7.0 中推出,看起来这些功能在下一个内核版本中可能会非常完善。当然,这对应于大约四月的稳定内核发布,但至少应该会包含在 Ubuntu 26.04 LTS 中,以提供出色的 Intel 图形体验。

转自 Intel’s Xe Linux Driver Ready With Multi-Device SVM To End Out 2025 – Phoronix

NTFSPLUS Linux 驱动程序更名为”NTFS” 与最新代码重构

Editor, Kai

2025 年 Linux 内核的一个意外惊喜是 NTFSPLUS 被宣布为微软 NTFS 文件系统的新驱动程序,其性能和功能相比传统的只读 NTFS 驱动程序或 Paragon 软件提交的”NTFS3″内核驱动程序都有所提升。该 NTFSPLUS 驱动程序继续扩展其功能集和稳定性,并且今天发布的版本是补丁的第三次迭代。现在这个驱动程序被简单地称为”NTFS”,不再使用 NTFSPLUS 的名称。

今天发布的 v3 补丁修订版本中,NTFSPLUS 驱动程序现在仅称为 NTFS。部分原因在于该补丁系列现在基于对旧版只读 NTFS 驱动程序的还原。当 Paragon 将 NTFS3 驱动程序上游合并并稳定后,旧版 NTFS 驱动程序被移除。但 NTFSPLUS 最初是基于原始 NTFS 驱动程序的,因为其代码库比 NTFS3 更干净。为了帮助未来的代码审查流程,这个新的驱动程序补丁系列首先进行还原,以恢复原始 NTFS 驱动程序的代码,然后在此基础上进行修改,而不是将所有驱动代码作为全新的内容引入。这有助于代码审查人员更清楚地了解相对于原始代码的新更改,从而简化审查流程,并可以跳过那些早已存在于主线内核中的代码部分。

NTFSPLUS Linux 驱动程序更名为"NTFS" 与最新代码重构

今天发布的 v3 补丁系列还添加了一些新的通用辅助函数,允许对$MFT 文件进行预读,移除了 32 位系统上的 2TB 文件系统限制,并包含了一系列其他底层改进。

那些希望查看此最新补丁系列以了解新 NTFS 驱动程序实现及其相比 NTFS3/NTFS-3g FUSE 或类似方案的优势的人,可以查看补丁概述信以获取所有细节。此外,与该内核驱动程序一起,ntfsprogs-plus 用户空间程序也在同步开发,其中包括一个此前 NTFS 驱动程序用户空间程序所缺少的可工作的 NTFS 文件系统检查(FSCK)实现。

转自 NTFSPLUS Linux Driver Renamed To Just “NTFS” With Latest Code Restructuring – Phoronix

日本重新杀回内存市场 富士通联手Intel开发HBM替代品

Editor, Kai

快科技12月26日消息,HBM内存现在是高性能AI不可缺少的一部分,而且价值很快会超越GPU本身,这一市场也主要掌握在三星、SK海力士两家韩国公司手中。

日本曾经是内存市场一哥,繁荣时期甚至把Intel逼得退出内存市场,从而在CPU市场找到一条路,但日本内存后来也被韩国公司击垮了,尔必达破产之后也没有日本公司染指内存了。

去年软银跟Intel公司合作研发新型内存,现在日本电子巨头富士通也决定加入联盟,他们拿到了建设日本最强超算的合同,对高性能内存有很高的需求。

到2027年春,该项目预计投资5100万美元,并制造出内存原型,2029年则会开始大规模生产,除了这三家公司会投钱之外,日本RNI理化研究所及日本政府也会出钱补贴开发。

这种内存的具体规格没有列出,但它主要是替代HBM,预计内存容量会提升两三倍,同时功耗降低一半。

台积电也会参与制造,这种内存主要是3D堆栈架构,可以大幅提高存储密度。

日本重新杀回内存市场 富士通联手Intel开发HBM替代品

【本文结束】如需转载请务必注明出处:快科技

责任编辑:宪瑞

转自 日本重新杀回内存市场 富士通联手Intel开发HBM替代品–快科技–科技改变未来

OpenMediaVault 8.0-12发布

Editor, Kai

OpenMediaVault 8.0-12发布

Volker Theile 宣布发布了 OpenMediaVault 8.0-12,这是专为网络附加存储 (NAS) 服务器设计的基于 Debian 的 Linux 专用发行版的重大更新。OpenMediaVault 8.x 系列基于稳定的 Debian 13 发行版:“由于在 RC 阶段未报告任何关键错误,现在是时候发布 OMV8(Synchrony)的最终版本(8.0.1)了。由于技术原因,从这个版本开始,仅支持 AMD64 和 ARM64 架构。由于这一情况早已为人所知,许多原本计划用于 OMV8 的功能已经在 OMV7 中实现,因此已淘汰的架构也能从中受益。这就是为什么 OMV8 的新功能列表相当简洁。尽管如此,转向 Debian 13 仍带来了更新的软件、错误修复和改进。 变更日志将列出此版本中的所有改进,包括:升级到 Debian 13 ‘Trixie’;用 linux-cpupower 替代 cpufrequtils;改进多个与用户和组相关的 RPC;在配置更改应用后,在通知中显示更新的模块;在更新页面上显示可升级包的旧版本;在 chrony 配置中默认使用 pool 而不是 server 指令……”

更多详情请阅读发布公告的其余部分。下载openmediavault_8.0-12_amd64.iso(1,367MB,SHA256,签名pkglist)。

转自  Distribution Release: OpenMediaVault 8.0-12 (DistroWatch.com News)

LibreOffice 26.2 去除 “Community” 版本品牌标识

Editor, Kai

随着即将发布的 LibreOffice 26.2 开源办公套件版本,他们将去除这一广泛使用的跨平台办公套件标准版本的 “Community Edition” 品牌标识。

LibreOffice 之前为这一流行的免费软件办公套件使用 “Personal Edition” 品牌标识。”Personal Edition” 品牌标识引起了用户的困惑并受到批评,最终决定将其品牌为 LibreOffice Community Edition。这也导致了一些用户的混淆,现在正在逐步淘汰。

LibreOffice Community Edition 的初衷是区分 LibreOffice 的通用版本与其他软件合作伙伴提供的企业版办公套件。但早在六月份,董事会就决定从 The Document Foundation 的 LibreOffice 构建版本中移除 “Community” 品牌标识。

LibreOffice 26.2 去除 "Community" 版本品牌标识

删除 “Community” 字符串的这些更改现在已经合并到 LibreOffice 26.2 中。该提交早在本月早些时候就去除了徽标和欢迎画面中的 “Community” 引用。此次提交还移除了用于在版本字符串中添加 “Community” 的 disable-community-flavor 构建选项,而不会对办公套件的其他部分做出任何更改。

因此,在 1 月月底或 2 月月初发布的 LibreOffice 26.2 版本中,将不再有与 LibreOffice “Community” 品牌相关的多余内容。

转自  LibreOffice 26.2 Gets Rid Of The “Community” Edition Branding – Phoronix