标签: #open-source

한국어English日本語中文

← 全部文章

• 同一家公司的两个项目，为什么在 AI 贡献上得出了完全相反的结论

  OpenJDK 在 2026 年 4 月全面禁止了由生成式 AI 产出的贡献，而同属甲骨文旗下的 GraalVM 在同一时期明确允许使用 AI 编码助手。两个项目用的是同一份贡献者协议。本文把三份文档并排来读：OpenJDK 的原文、GraalVM 的政策文件，以及两者都参考过的 Linux 内核文档。结论是：这个差异并不是对 AI 的态度差异，而是「把评审负担记到谁头上」的设计差异；知道了这根轴，你也就能写出自家仓库的政策。

  2026-08-09 · 12 分钟阅读 #culture#open-source#ai#policy#code-review

• 巴士系数不是懂代码的人数，而是能拍板的人数

  Nixpkgs 核心团队成立十个月后解散了。在一个有数千名贡献者的仓库里，握有被授权的决策权的人只有两位，而这两位一退出，那块管辖区就处于没有直接主人的状态。本文以这件事为依据，梳理为什么评估依赖风险时该看的是拥有批准权的人数、授权结构是否真正生效、以及升级路径，而不是星标数和提交数，并一并讨论用 GitHub API 就能自己数出来的指标及其局限。文中原样引用公告的措辞，以便把事实和解读分开。

  2026-08-09 · 13 分钟阅读 #devops#open-source#governance#nix#supply-chain

• 当开源治理崩溃时 — Ruby Central 之争与三根支柱

  2026 年 7 月 30 日，André Arko 发布《Ruby Central 的破坏性遗产》，让始于 2025 年 9 月的 RubyGems 仓库访问权限之争，在十个月后再度浮出水面。本文将双方的第一手陈述并列呈现，梳理出一条可核实的时间线，然后从结构层面分析为什么同样形态的危机会在 core-js、event-stream、xz-utils、Nix、Redis、Terraform 身上反复出现。核心是三根支柱 —— 商标归谁

  2026-07-31 · 24 分钟阅读 #open-source#governance#rubygems#supply-chain#licensing

• GCC 的 AI 政策与开源世界的选择 —— 15 行这条边界线到底想守住什么

  2026 年 7 月 29 日，GCC 指导委员会通过了 AI 政策工作组的建议。核心内容是：具有法律意义的贡献如果包含 LLM 生成内容或衍生自这类内容，将不予接受，判定基准线大致沿用 GNU 维护者指南里的约 15 行。不过测试用例是个例外，把 LLM 用于调研、分析、发现 bug、审查补丁本身并不受限制，只是 AI 辅助的工作需要附上 Assisted-by 标签。本文梳理这项政策实际要求了什么、其背后的版权转让与 DCO 问题、

  2026-07-31 · 19 分钟阅读 #ai#open-source#gcc#licensing#governance

• OPA 现在由谁维护 — Styra 团队加入 Apple，之后 11 个月的可验证记录

  2025 年 8 月 20 日，一则公告宣布 OPA 的创始人们和多名 Styra 团队成员将加入 Apple，社区中随之流传起「Apple 收购了 OPA」的传言。用一手资料核实后，实际情况并非如此 — 没有任何地方宣布过收购公司或资产，只是人员换了雇主，OPA 依然是 CNCF 毕业项目。本文直接用 GitHub API 和原始文档核实并梳理了：那则公告的准确措辞、此后 11 个月里实际发生的事 — 月度发布节奏的维持、Regal

  2026-07-17 · 18 分钟阅读 #security#opa#authorization#open-source

• MinIO 社区版是这样落幕的 — 用仓库记录复原的时间线，以及 Garage、SeaweedFS、Ceph RGW 的现状

  2026年4月25日，minio/minio 仓库在 GitHub 上被归档，7月14日连 mc 客户端仓库也变成了只读。愤怒的讨论帖不少，但本文追的不是情绪而是记录 — 2025年5月的控制台功能削减、9月的 Docker Hub 镜像停更、10月15日的最后一次发布与「仅源码分发」声明、12月的维护模式，直到2026年的归档连锁反应，全部用仓库自身的提交记录、发布说明和镜像仓库元数据核实过。与常见的误解不同，许可证自始至终都是 AG

  2026-07-17 · 23 分钟阅读 #storage#object-storage#s3#minio#open-source

• OpenBao 到底比 Vault 分叉了多少 — 从发布说明看分歧点，直到 v2.6 的命名空间封印

  距离 OpenBao v2.0.0 GA(2024-07-17)正好过去两年，而三天前 v2.6.0 才刚发布。本文抛开「BUSL 背叛」对「可持续性」这类阵营论调，只用两个项目自己发布的发布说明、变更日志和提交记录，来确认这个分叉到底在哪里真正分道扬镳。OpenBao 把曾经 Vault Enterprise 专属的命名空间在 v2.3.1 开源了出来，又在 v2.6.0 加上了上游没有的、按命名空间划分的加密封印。反过来，存储后端、

  2026-07-17 · 16 分钟阅读 #security#open-source#devops#licensing

• curl 8.21.0 的 18 个 CVE — 漏洞赏金终结之后迎来的「高质量混乱」

  2026 年 6 月 24 日，curl 8.21.0 在单个版本中发布了 18 个 CVE，刷新了项目记录。不过这 18 个全部是 Low 或 Medium，High 级别自 2023 年 10 月以来一个都没有出现过。这个数字背后，是一个被 AI 劣质报告折腾到 2026 年 1 月底废除了漏洞赏金的项目，从 3 月起却反过来迎来了「几乎全用 AI 写、但质量很高」的报告洪流。本文用 curl 自己公开的机器可读数据 vuln.js

  2026-07-17 · 23 分钟阅读 #network#security#curl#cve#open-source

• Flux 2.9 与 Weaveworks 之后的两年 — 失去赞助商的 GitOps 项目是怎么撑下来的

  2024 年初，Flux 的原开发公司 Weaveworks 关门时，GitHub 讨论区里冒出一个问题 — 「这个项目的未来有危险吗?」两年半之后的 2026 年 6 月 30 日，Flux 发布了 2.9.0。本文用可验证的一手资料，重构这期间真正发生的事 — 发布节奏如何动摇又如何恢复(v2.0 到 v2.9 每个次要版本的发布间隔实测)、如今 9 位核心维护者分别隶属何处(以 CORE-MAINTAINERS 文件为准，Cont

  2026-07-17 · 18 分钟阅读 #devops#gitops#fluxcd#kubernetes#open-source

• Redis 8.8 的 Array 类型 — 自 Stream 之后首次新增的核心数据结构，以及 Valkey 没有的东西

  2026 年 5 月，Redis 8.8 与 Valkey 9.1 相隔六天先后发布。Redis 8.8 加入了 antirez 亲自打造的全新核心数据结构 Array — 一种面向「索引本身就带有意义」的数据(传感器的分钟级槽位、预订系统的座位号、文件的行号)的稀疏索引容器，配备 18 个命令、基于切片的稀疏编码、服务端聚合，乃至正则 grep。从 server.h 里的对象类型编号来看，这是自 Stream(5.0)之后首次新增的核

  2026-07-16 · 23 分钟阅读 #redis#valkey#data-structures#performance#open-source

• Nix 2.35 更懒惰地把 flake 源复制到 store 了 — 一个持续 6 年 8 个月的 issue，以及上游没有选 lazy trees 而选的那条路

  Nix 2.35.0 于 2026 年 7 月 13 日打上标签，它的第一条亮点是「Sources are copied to the store more lazily」。被这一行改动关闭的 issue 3121，是 Eelco Dolstra 本人在 2019 年 10 月 7 日开的，2026 年 6 月 9 日关闭 — 历时 2,437 天。有意思的是，真正被合并的东西并不是 Dolstra 的 lazy trees。他的 PR

  2026-07-16 · 21 分钟阅读 #nix#reproducible-builds#build-systems#developer-experience#open-source

• tts-bench：当质量主观时，如何比较本地 TTS

  tts-bench 是开发者 5uck1ess 打造的本地基准测试，让你在手头的硬件上比较 55 个 TTS 模型。它把评测拆成三个视角：速度（TTFA、RTF、内存）、试听（用耳朵判断每一个模型）、评分（UTMOS、WER、SIM）。最有意思的是它对主观性的坦诚——没有一个"最好听"的单一分数，因为质量取决于你的耳朵和用途。本文梳理这个工具实际测量什么，客观指标在哪里有帮助、在哪里会误导，以及如何为自己的工作负载挑选合适的 TTS。

  2026-07-11 · 8 分钟阅读 #tts#text-to-speech#benchmark#local-ai#evaluation

• 解读 Microsoft Flint — 让智能体绘制图表的可视化语言

  Microsoft Research 公开的 Flint 并不是可视化智能体的语言，而是让 AI 智能体能够从数据中稳定地生成美观图表的中间语言。编译器会代替我们，从数据与语义类型中推导出比例尺、坐标轴、颜色、布局等低层决策，并把同一份规格编译为 Vega-Lite、ECharts、Chart.js。本文诚实地探讨 Flint 究竟是什么、解决了什么问题，以及智能体专用的可视化语言究竟是真正必要的构想，还是过度设计。

  2026-07-11 · 9 分钟阅读 #ai#agents#data-visualization#llm#microsoft

• 开发者离开 GitHub 转向 Codeberg 的原因 — 以及离开时真正失去的东西

  离开 GitHub 转向 Codeberg、Forgejo、自托管的文章突然多了起来。背景是 Ghostty、Zig、Gentoo 的出走、频发的故障、微软将其并入 CoreAI，以及 2026 年 4 月 AI 训练默认值的反转。本文基于真实的一手资料，均衡地梳理是什么在推动人们、Codeberg 与 Forgejo 实际能带来什么，以及离开 GitHub 时真正失去的东西(网络效应、CI、可发现性)是什么。这不是对 GitHub 的

  2026-07-11 · 9 分钟阅读 #github#codeberg#forgejo#self-hosting#open-source

• 重返终端的创业者 — Hashimoto 的 Ghostty、Zig 这场豪赌，以及“没有义务”的开源

  HashiCorp 联合创始人 Mitchell Hashimoto 从成功创业者的位置上再次走下来，用还不到 1.0 的语言 Zig 打造终端模拟器 Ghostty，本文以最近的一次采访为依据梳理他这样做的理由。他坦言自己做了 15 年 CLI，却并不了解终端内部是如何运作的，为了重新磨砺已经变钝的技术手感，他向下钻进了 GPU、桌面和 Zig。Zig 在 0.15 中把输出接口几乎整个改掉，至今仍不稳定，但他反而欢迎这种破坏性变更。

  2026-07-11 · 11 分钟阅读 #ghostty#zig#open-source#terminal#mitchell-hashimoto

• 开源 LLM 生态完全指南：2026 年的模型、工具与部署策略

  全面梳理 2026 年开源 LLM 生态的实战指南。涵盖主要模型家族(Llama、Mistral、Gemma、Qwen、DeepSeek)、本地推理工具(Ollama、llama.cpp、vLLM)、微调技术(LoRA、QLoRA)，以及运营自有 LLM 所需的实战部署策略。

  2026-03-17 · 28 分钟阅读 #open-source#llm#llama#mistral#gemma