O

openSUSE 中文社区

openSUSE 中文社区主页，为您带来最新的 openSUSE 资讯，为中文用户的交流提供一席之地。

https://suse.org.cn
https://suse.org.cn/feed.xml (RSS订阅地址)

ARMv9 构建基础设施后续进展

去年六月，NVIDIA Grace Hopper 正式入驻 Open Build Service (OBS) 基础设施，这不仅意味着新硬件的到来，更开启了 openSUSE 项目原生 ARMv9 构建能力的新纪元。 数月后的今天，成效正日益显现。 OBS 的工作节点监控面板呈现的画面，比任何变更日志都更能说明问题。横跨 x86_64、aarch64、ppc64le、s930x 等多种架构的数十个构建工作节点中，更新的 armv9 级别机器正在繁忙运转。 项目团队一直在为 ARMv9 重建 Tumbleweed 的部分软件包，工作节点面板直观反映了这些进展。 面板不仅揭示了 aarch64 和 armv9 节点上的高负载，更展示了构建目标的软件包多样性——从 Linux 内核、LLVM 和 GCC 等编译器工具链，到 Python 软件包、Qt 框架等，工作节点正以较高的成功率编译这些复杂工作负载。 这些活动对 ARMv9 至关重要，表明它已从概念验证阶段演进为与主 Tumbleweed 树并行的活跃开发发行版路径。 NVIDIA Grace 采用高性能 ARM 架构 CPU 核心与...

2026/5/12
阅读更多

近八年历程即将落幕

openSUSE Leap 15 系列在提供可升级至 SUSE 企业版产品的稳定社区发行版近八年后，即将走到终点。Leap 15.6 将于本月底（2026 年 4 月）停止支持（EOL, End of Life），标志着一个时代的结束，此后将不再提供维护或安全更新。 Leap 15 的旅程始于 2018 年 5 月 25 日，当时 15.0 作为基于 SUSE Linux Enterprise 15 的全新社区构建版本发布。它带来了大量新软件，同时提供了便捷的 SLE 迁移路径、事务更新、服务器角色、可扩展的云镜像等功能。 随后是一段令人印象深刻的持续迭代历程，从 Leap 15.1 到 15.6，每个稳定版本都与其同源的 SLE 版本保持源码和二进制兼容，并在数年间为用户提供维护和安全更新。 这一系列远超预期，最终跨越了近八年的活跃支持期。随着 Leap 15.6 停止支持，希望继续接收维护和安全更新的用户应升级至 Leap 16。Leap 16 预计将支持至 2031 年秋季的 16.6...

2026/5/12
阅读更多

新启动器旨在简化 Cockpit 安装流程

openSUSE 社区成员正在开发一套精简的系统管理界面，以应对从 YaST 迁移这一复杂工作。 在 openSUSE bar 经过多次调整并吸纳社区意见后，成员们基于现有工具，为 openSUSE 用户推出了一款启动器。它提供基于网页的系统管理界面，让从传统 YaST 配置工具切换过来的用户更容易上手。 这款 cockpit-client 启动器 解决了部分用户在尝试用 Cockpit 替代 YaST 时遇到的使用障碍。根据 openSUSE 论坛 上的反馈，在此之前，整个使用流程既不简单也不直观。 该启动器为 openSUSE 专属设计，图标沿用了经典 YaST 的配色，针对用户反馈制作。经过测试与小幅优化后，该软件包已正式发布，可在 Tumbleweed 和 Leap 中作为 Official 软件包安装使用。 Lubos Kocman 表示：“由于 Cockpit-client 同时提供 Flatpak 和 RPM 两种启动器，我们需要给它们设置不同图标，方便用户区分。不同颜色的图标能让用户一眼就知道打开的是哪个，避免混淆。” 安装步骤 该启动器将原本多步骤的操作简化为直观流畅的工作流程。此前，用户在通过 localhost:9090 访问 Cockpit 时会遇到诸多问题，社区也将其列为使用痛点。 sudo...

2026/4/15
阅读更多

openSUSE 发布更新后的法律分类模型

openSUSE 项目在项目的 HuggingFace 平台上推出了一款新版本语言模型，专为开源软件的法律合规检查自动化而设计。 Cavil-Qwen3.5-4B 模型是 Cavil 的最新迭代版本，该项目依托精心整理的数据集，用于提升法律文本自动化分类能力。此次更新凸显了社区驱动型开源人工智能日益重要的作用。 该模型是基于阿里巴巴 Qwen3.5-4B 基础模型的专项适配版本，专门用于识别代码仓库与文档中具有法律意义的文本，例如许可证声明、版权声明及同类法律标识。通过为基础模型添加低秩适配（LoRA）层，可高效完成微调，且计算开销极低。更小的模型体积让 Cavil-Qwen3.5-4B 能够在普通硬件上运行。 本次版本的核心特性之一是提供了 GGUF 格式量化版，该版本由社区成员贡献并托管在 HuggingFace 上。GGUF（GPT 生成统一格式）是一种专为本地运行大语言模型优化的模型文件格式，可搭配 llama.cpp 等工具使用。量化会降低模型精度，通常从 16 位浮点数降至 4 位甚至 2 位整数，从而大幅降低内存占用，可在笔记本电脑、单张 GPU 甚至 CPU 上使用。 Cavil-Qwen3.5-4B 的发布也彰显了 openSUSE 与更广泛的开源 AI 社区之间持续的合作。与专有模型不同，Cavil 的训练数据和微调方法公开透明，允许用户审核、复现或扩展相关工作。 随着 Cavil 这类项目的发展，本地开源 AI 正持续走向成熟，这也证明了针对性微调与社区优化能够在不依赖超大规模算力或封闭生态的前提下创造价值。 该模型、训练数据集及验证工具均已在 Hugging Face 上线，其许可协议体现了各组件的不同属性。欢迎有意参与贡献或提出改进建议的用户，在 HuggingFace 上与 openSUSE...

2026/3/17
阅读更多

社区完善 Git 打包工作流

openSUSE 项目的贡献者与开发者近期举行会议，协调面向 Leap 16 的基于 Git 的打包工作流，并讨论该流程今后如何应用于 Leap 发行版，而滚动发行版 Tumbleweed 仍需做一些工作才能完成过渡。 该工作流以 Gitea 作为界面平台，标志着开发向更透明、以软件包为中心的方向转变。项目记录的架构决策包括：采用 Git 作为唯一版本控制系统，使用拉取请求进行变更管理，并在各仓库间统一工作流。 所有官方发行版的软件包源码托管在 src.opensuse.org/pool。社区软件包使用名为 leap-x.y 的分支，例如 leap-16.0。源自 SUSE Linux Enterprise（也被称为 SUSE Linux Framework One(SLFO) 的软件包使用 slfo-main 或带版本的 slfo-x.y 分支。当一个软件包同时存在这两类分支时，贡献者应基于 leap-x.y 分支开展工作。 该项目依托多项自动化工具来管理工作流。workflow-pr 机器人负责拉取请求的生命周期，包括审核与合并。workflow-direct 机器人在可信开发项目有代码推送时同步子模块。obs-staging-bot 机器人在 Open Build Service 中创建隔离的测试环境，用于端到端验证。这些自动化工具的源码可在 AutoGits 仓库中获取。它们无需特殊权限即可运行，通常以普通用户身份在 Gitea 中运作。 项目鼓励贡献者使用标准工具：用于与 OBS 交互的...

2026/3/9
阅读更多

社区在召开线上会议后推进治理提案

openSUSE 项目在昨日（2 月 18 日）举办的线上会议后，推进了一套拟议的治理架构。本次会议召集社区成员共同探讨项目领导力框架的完善方向。 此次会议成效显著，参会者审议了项目治理机构的草案提案，其中包含技术指导委员会、社区与营销委员会、基础设施团队代表以及理事会。 该提案托管在 GitLab 平台，被设计为一份动态文档，欢迎社区通过反馈对其进行修订。 会议期间的讨论提议，技术指导委员会应在初期由 5 名成员组成，主席由委员会选举产生。该小组将借鉴 Fedora 的 FESCo 模式，建立用于审核和批准技术变更的清晰流程。技术指导委员会的决策将采用 +1 赞成、0 中立、-1 否决的投票机制。提案在无异议的情况下即可通过。若出现 -1 否决票，则需召开专门会议，由参会多数成员决定最终结果。反对意见必须附带清晰、书面的理由说明。 有关社区与营销委员会的讨论将聚焦于推广、宣传和社区发展。该委员会也可作为争议的初步升级处理机构。若该层面无法达成共识，相关事项将提交至理事会。 理事会的职责将以代表工作为核心，包括与 SUSE 协调、治理监督、冲突调解以及战略指导。随着时间推移，其运营职责可能会收窄，转变为类似监督机构的职能，处理商标事务、预算审批，并在必要时进行最终申诉裁决。 参会者强调，培育维护者尽责的良好文化依然至关重要，这也可能是新架构启动阶段最具挑战性的环节之一。 项目鼓励社区成员提交合并请求，以完善这份治理草案。 文档可在此处获取。组织者表示，相关讨论应通过对文本提交修改建议的方式进行。 目前尚未公布最终采纳的时间安排。项目贡献者将继续通过 GitLab 仓库及后续社区会议展开讨论。 原文：Community Advances Governance Proposal After Virtual Meeting，作者：Douglas DeMaio

2026/3/2
阅读更多

理事会候选人征集工作正在推进

openSUSE 项目已正式开启常规理事会选举的提名与候选人报名工作(https://lists.opensuse.org/archives/list/project@lists.opensuse.org/thread/MVYPHOGGKS3EPPR45EDGLY65CXM74WPB/)，投票环节定于 3 月 1 日启动。 因整理会员数据库工作有所延期，选举委员会现已确认，选举流程已回归正轨。本次项目成员将投票选出候选人，填补 openSUSE 理事会的两个空缺席位。 这两个空缺席位目前由 Shawn W. Dunn 和 Simon Lees 担任。 本次征集面向所有符合条件、有意为项目的社区建设、治理工作及对外代表事务提供指导的 openSUSE 会员。加入理事会，将获得直接参与塑造 openSUSE 问题解决方式、支持贡献者发展，并在开源社区中代表项目发声的机会。 提名与自主报名通道将开放至 2 月 28 日，候选人须为 openSUSE 现任会员。 投票将于 3 月 1 日启动，3 月 8 日截止，选举结果预计于 3 月 9 日公布。 有意参选的会员请将本人姓名、注册邮箱及 openSUSE 用户名，发送至邮箱 project@lists.opensuse.org 和 election-officials@lists.opensuse.org。 选举委员会鼓励社区成员积极参选，openSUSE 项目的发展，离不开愿意牵头引领、倾听意见并代表项目共同价值观的社区成员。 近期发布的一篇文章为有意参选...

2026/2/25
阅读更多

openSUSE 理事会谈参与、治理与社区

随着 2026 年 openSUSE 社区 理事会选举临近，Ish Sookun、Jeff Mahoney 和 Rachel Schrader 为上届当选成员，将继续履职 1 年。我们对他们进行了专访，并提出了一些问题。 1. 理事会主要负责什么工作？ Jeff 纸面上，理事会负责领导 openSUSE 项目。这听上去职责重大，但实际工作中，它的职能更加聚焦、也更有限。理事会不参与项目版本发布，也不管理项目基础设施，而是作为外部人员对接项目的联络窗口，协助调解冲突，处理商标等相关法律事务，并在需要时提供指导。 Rachel 从我目前的经历来看，理事会只是整个 openSUSE 社区的一部分。我们负责少数几项事务，例如版务处理的最终裁定、作为与 SUSE 公司对接的联络渠道，并在很多方面为社区内其他团队提供指导。 2. 是什么促使你站出来参选理事会？ Jeff 2024 年理事会选举时，主动竞选空缺席位的人很少，于是我想着自己不妨主动报名。我已经参与社区多年，也有一些想要提出的想法。项目当时需要志愿者，我便站了出来。 Ish 我是在第二次招募时才参选的。当 Lubos 联系我，希望提名我时，我立刻觉得这是一份荣幸。我非常感谢他的提名，也感谢 Johannes Segitz 作为附议人。 Rachel 上届选举期间，愿意主动为理事会服务的人并不多。在项目中其他几位活跃成员的鼓励下，我决定参选。 3. 请谈谈在任期间理事会遇到过的一项挑战 Jeff 在营造健康、远离不良风气的社区氛围，与过度管控、干涉过多之间，存在一条非常微妙的界限。提交到理事会的问题中，有些很容易判断，但另一些却牵扯个人过往、沟通方式差异以及各种细节。在这类情况中找到恰当的平衡点，是很有挑战性的。 Ish 我虽然知道理事会成员需要定期（线上）开会讨论项目事务，但没有意识到会有这么多非技术相关的议题需要处理。例如与“审核”相关的问题，我认为就很有挑战性，因为需要了解事件的来龙去脉、行为准则等。在这方面，我很依赖其他资深理事来帮助我完整理解事件背景。 Rachel 最直接也最头疼的挑战，是为所有人凑出一个都能参会的时间。我们的成员遍布全球，有些人必须早上 6 点起床参会，而另一些人则要到晚上...

2026/2/25
阅读更多

社区将讨论新治理提案

openSUSE 社区 成员将于 UTC 时间 2 月 18 日下午 3 点 30 分（北京时间 2 月 18 日晚 11 时 30 分）召开线上会议，讨论一份的治理框架提案，旨在让项目社区内部的决策流程更清晰。 本次会议可通过项目的 Jitsi 频道参与，会议召开前，项目方已发布一份最新提案草案，其中概述了项目在技术决策与社区决策管理模式上的架构调整。 该提案提议设立两个全新的治理机构：负责把控技术方向、解决技术争议的技术指导委员会，以及专注于社区发展与沟通平台建设的社区与营销委员会。 现有 openSUSE 委员会 将继续负责法律、财务及组织管理相关事务。 该治理框架旨在解决提案中所提及的非正式决策流程问题：这类流程往往更青睐时间充裕、毅力较强的参与者，而非遵循明确的议事规程。提案旨在搭建透明化的治理架构，同时保留维护者自主权与开放参与的核心原则。 拟设立的两个委员会均由社区选举产生的成员组成，任期为 2 年。在 FOSDEM 大会上针对该议题的部分反馈建议，将任期缩短至 1 年。提案建议，技术指导委员会设 7 至 9 名成员，社区与营销委员会设 5 至 7 名成员。 草案明确规定，所有内容均需经社区讨论、并获得委员会批准后方可生效。在初步讨论阶段结束后，相关反馈将被纳入修订草案，再由委员会与社区商议后续推进步骤。 讨论要点 委员会架构与规模：技术指导委员会是否应设 7 至...

2026/2/6
阅读更多

开源社区应对 2038 年时间戳危机（Y2K38）

仅剩12年，记录时间中的根本性限制威胁着未准备的计算机系统；2038 年问题（Y2K38）正在成为新的千年虫问题（Y2K），开源社区贡献者们正致力于创建可行的警告机制。 这种被称为错误日期逻辑的问题，在计算机系统中比人们想象的更为常见。openSUSE 正在通过早期测试、工具链改进和社区协作，积极识别并修复此类问题，以确保软件系统在 2038 年后仍能稳定运行。 在 2038年1月19日 UTC 时间 03:14:07，UNIX 纪元时间戳将超过有符号的 32 位整数最大值：2,147,483,647（0x7fffffff）。在此之后，仍依赖 32 位时间表示的系统可能会发生时间回滚，导致从细微的数据损坏到彻底崩溃等不同程度的故障风险。 距未来 32 位平台（如 i586 或 armv7）面临此问题的时间还剩 12 年，但现代 64 位系统也存在部分漏洞，正如多年前的 openSUSE 会议演讲中所揭示。 近期 openSUSE 开发者的测试表明，2038 年问题已经迫在眉睫且真实存在。通过将构建系统的时钟提前至 2038 年，大量软件包出现了编译失败或测试套件未通过的情况。受影响的软件包括版本控制工具、编辑器、编译器、Python 库、桌面工具包及系统组件。 在某些案例中，基础系统行为（如正常运行时间报告）都受到了影响。 尽管部分故障已得到修正，但测试中暴露的问题残余表明，32 位时间存储问题的渗透深度远超预期。 每次新增功能或代码重构时，若开发者默认使用 int 或 long 等类型而非更安全的 time_t、int64_t 或 long long，都可能重新引入这一问题。 此风险不仅限于应用程序层。广泛使用的协议（如 SOAP/XML-RPC 和...

2026/1/26
阅读更多