给软件开发者准备的优质简报，每日阅读 10分钟。
Changing how we develop Ladybird
Ladybird 改变开源开发模式：停止接受公开拉取请求
- Ladybird 项目将停止接受公开拉取请求，代码更改今后仅由项目维护者引入，原因是项目正朝向首个 alpha 版本迈进，需要更严格的开发流程、更清晰的安全模型，以及更小范围的代码责任人
- AI 工具已改变了开源贡献的信任机制——一份代码补丁不再能有效证明提交者的诚意和投入，实质性的补丁曾被视为善意的合理代理，但这一假设已不再成立
- 对于浏览器而言，运行来自互联网的不可信输入意味着一个精心隐藏的漏洞就可能造成严重后果；关键不在于代码是否手工输入，而在于谁对进入项目的代码负责并承担后果
- 所有当前开放的公开拉取请求将被关闭，且不会建立任何替代性的外部补丁提交流程；外部代码可存在但不会被视为上游审查队列
- Ladybird 依然保持开源，代码继续在开源许可证下公开可见；外部仍可通过 bug 报告、测试用例、标准讨论、安全报告及技术反馈等方式继续参与
I built a vulnerable app and spent $1,500 seeing if LLMs could hack it
1500美元漏洞挑战：LLM安全测试揭示AI黑客能力差异
- 安全研究员 Kasra 构建了一个名为 BookNook 的书籍评论应用（React Native + FastAPI），漏洞类型为 Firebase 配置不当导致的访问控制缺陷——攻击者可通过 APK 中的
google-services.json直接使用 Firebase 注册新账户，从而直接读取 Firestore 数据库中其他用户的私有评论，而非攻击 API 本身（属于 Broken Access Control/Missing Object-Level Authorization 类漏洞） - 实验在每轮 10 美元上限、2 小时时间限制下进行，GPT 5.5 表现最佳（7/10 解决率），Deepseek V4 Pro 次之（3/10），Claude Sonnet 4.6 和 Opus 4.8 各 2/10，其余模型解决率均低于 1/10，其中 Deepseek V4 Flash、Gemini、MiniMax、Step 等多款模型解决率为零
- 多个模型存在共同的策略失误：部分运行发现 Firebase 后错误地尝试将其认证机制用于 API 而非直接访问 Firebase（MiniMax M2.7 每次运行都犯此错误，Deepseek V4 Pro 和 GLM 5.1 也频繁出现）；Claude Opus 4.8 多次接近正确答案但被安全护栏提前终止
- 部分模型存在严重拒绝或效率问题：Gemini 3.1 Pro Preview 立即拒绝安全测试仅生成 9k tokens，Gemi 3.5 Flash 也多在早期拒绝；Qwen 3.7 Max 本地测试成功但大规模运行失败，每次消耗高达 730 万 tokens；Kimi K2.6 成功完成挑战但因 API 不支持并发代理使用而未能继续测试
- 中文模型（Deepseek、Kimi 等）对直接操作数据库的接受度明显更高，而西方模型常因"这会影响真实数据库"产生犹豫退缩
- 技术基础设施问题严重：MiniMax 和 GLM 的 API 频繁宕机导致实验多次中断，GLM 5.1 单次运行消耗高达 125 万 tokens 成本极高，Modal 抢占机制造成约 10% 运行失败；整体实验非科学评估、样本量有限、50% 运行因失败或测试未计入，结果仅供参考
Did Claude increase bugs in rsync?
Claude是否导致rsync缺陷增加——基于36个版本的经验数据分析
- 分析方法：使用"每10次提交加权缺陷严重度"（sev/10c）指标，由Qwen 3 35B按0-100分制独立评分，通过精确排列检验（p=46%）和Fisher精确检验（p=74%）对v2.4.6至v3.4.3共36个版本进行统计分析
- 核心发现：两个Claude版本（v3.4.2：0.00 sev/10c位于IQR下方；v3.4.3：3.29 sev/10c位于第77百分位）以相反方向分布于IQR两侧，均非异常值，统计检验表明Claude版本与历史版本无显著差异
- 最大悖论：历史数据中缺陷率最高的版本是v3.4.1（39.39 sev/10c，无Claude提交），却未引发任何争议；v3.4.3的3.29 sev/10c仅排第77百分位，8个历史版本缺陷率更高
- 争议本质：2026年5月，一篇无技术证据的Mastodon帖子将v3.4.3回归与Claude关联，引发针对维护者Andrew Tridgell的300+评论、骚扰和死亡威胁，而非基于缺陷数据的实证分析
- 根本原因：rsync后期大量变更源于AI生成的CVE安全报告涌入（维护者本人确认），Claude版本平均缺陷率（1.65 sev/10c）仅为历史均值（2.95 sev/10c）的56%，是"更多安全修复"问题而非代码质量下降
- 数据局限：仅2个Claude版本样本过小，无法确定真实效应方向，只能表明当前缺乏Claude造成损害的统计学证据
Mouseless – keyboard-driven control of macOS/Linux/Windows
Mouseless：键盘鼠标替代工具的创新解决方案
- 鼠标点击操作耗时不到1秒，远快于传统鼠标的2秒以上，大幅提升工作效率
- 跨平台支持 Mac、Windows、Linux 系统，可同时在最多 5 台设备上使用
- 完整模拟所有鼠标按钮和操作，涵盖左键、右键、中键、前进、后退等按钮，以及点击、移动、拖拽、滚动、双击和三击等操作
- 采用 Free mode 无覆盖层模式，实现流畅可定制的移动体验，是对操作系统内置"鼠标键"功能的现代化升级
- 保护手腕健康，减少重复性鼠标点击带来的疼痛和劳损，将点击工作分散到键盘上
- 支持无障碍操作，为无法使用传统鼠标的用户提供高效、完整的鼠标功能替代方案
- 用户评价显示显著改善工作舒适度和效率，被称为"最值得的一笔花费"
Conventional Commits encourages focus on the wrong things
停止使用 Conventional Commits
- Conventional Commits 将类型标注（如 fix、feat、refactor）置于变更范围之前且范围设为可选——这对贡献者、调试者和事故响应者而言是本末倒置，因为"哪个区域被修改"才是核心信息，而非"修改了什么类型"
- commit 描述本身通常已能表明变更类型，类型标注不仅浪费宝贵的提交行空间，还具有限制性——许多提交难以单一归类为某种类型
- 自动生成 CHANGELOG 的承诺不成立：CHANGELOG 面向用户关注功能性/业务层面的变更，而 commit 日志面向开发者记录代码演进过程，两者受众和目的截然不同，试图合并只会产生次优结果
- 自动确定语义化版本号的机制存在严重漏洞：回滚操作、意外破坏性变更或事后多个提交组合修复等情况都会导致版本号计算错误，而为修复这些问题而改写历史会破坏 commit 日志的可靠性
- 自动触发构建/发布流程存在安全隐患：基于 commit 类型而非实际变更文件触发流程可能被恶意利用，compute 已足够廉价，应使用 git diff 识别实际修改的文件
- Linux、Git、Go、FreeBSD、NixOS 等顶级开源项目均采用范围前缀式提交格式（如
subsystem: description），作者创建了 scopedcommits.com 网站倡导回归更实用的提交信息规范
I tested every IP KVM in my Homelab
家庭实验室IP KVM设备全面评测
- IP KVM（IP键盘视频鼠标）是一种独立于目标计算机的硬件设备，通过IP网络实现远程控制，即使计算机死机、蓝屏或关机仍可访问；传统远程桌面/VNC/SSH需要目标系统正常运行才能工作，因此IP KVM特别适用于远程基准测试（不占用系统资源）或紧急救援场景
- 设备价格跨度极大：从24.99美元的DezKVM-Go（仅支持USB直连）到499美元的TinyPilot Voyager 3（商业级管理功能）不等；主流产品包括基于树莓派CM4的PiKVM（$275-400）、基于RV1126芯片的GL-iNet Comet系列（$99-179）、Sipeed NanoKVM系列（$69-120）、JetKVM（$103）等，支持1080p至4K分辨率、触摸屏、HDMI直通、PoE供电、ATX电源控制等功能
- 安全性需高度重视：Sipeed NanoKVM Cube曾被朝鲜黑客用于企业间谍活动（伪装成Apple Watch寄给美国员工），导致作者收到FBI问询；所有IP KVM都应视为网络入口，必须及时更新固件、不使用不信任的厂商产品、并做好防火墙隔离
- 开源生态主要分为两大阵营：PiKVM（GPLv3许可）和JetKVM（GPLv2许可）；BliKVM、GL-iNet系列、Sipeed NanoKVM等均为PiKVM软件栈的分支，而LuckFox PicoKVM、LeafKVM、ArkKVM等则是JetKVM的分支
- 作者实际使用最多的是JetKVM，因其体积小巧、USB供电（无需额外电源）、锌合金外壳坚固、软件界面响应迅速；PiKVM功能最完整但价格最高（$275-400），推荐优先购买以支持开源项目本身
- IP KVM市场正在快速增长，本文发布时GL-iNet已宣布即将推出支持USB控制的Comet Q和内置4口切换器的Comet X等产品
pg_durable: Microsoft open sources in-database durable execution
pg_durable：PostgreSQL 数据库内持久化执行框架
- 核心定位：微软开发的 PostgreSQL 扩展，将持久化执行能力带入数据库内部，让长时间运行、容错的 SQL 函数在数据库崩溃、重启或步骤失败后自动从检查点恢复，无需 cron jobs、队列、状态表等外部基础设施
- 目标用户：希望工作流与数据共置的后端/数据工程师、需要工作流在重启后仍可审计的 DBA/SRE、构建需要逐行/逐文档/分批持久化执行的数据或 AI 管道团队
- 技术特性：基于 SQL 定义工作流（使用
~>、|=>等组合操作符和df.if()、df.loop()等控制结构）；状态、重试逻辑和进度追踪持久化在数据库内部；零外部依赖（无需 Redis、Temporal 等外部服务）；由后台工作进程执行 - 适用场景：向量嵌入管道（分块→调用嵌入 API→写入 pgvector）、数据摄取管道（分阶段→去重→转换→发布）、并行扇出聚合、外部 API 工作流（富化、分类、webhook 调用）、定时维护任务
- 核心机制：工作流定义后以
df.start()启动并返回实例 ID；运行时在步骤之间执行检查点；状态存储在df.*和duroxide.*schema 中；通过df.instances等表查询状态和结果 - 架构与部署：基于 Rust 和 pgrx 框架构建，依赖底层的 duroxide 运行时引擎（确定性重放、检查点、定时器）和 duroxide-pg 状态提供者；提供 Debian 包安装或从源码构建；通过
df.grant_usage()授权应用角色，行级安全策略确保用户只能访问自己的实例；需要 PostgreSQL 17 或 18，当前处于预览阶段
Gemma 4 QAT models: Optimizing compression for mobile and laptop efficiency
Gemma 4 QAT 模型：通过量化感知训练优化移动端和笔记本端模型压缩
- Google 发布 Gemma 4 的量化感知训练（QAT）检查点，通过在训练过程中模拟量化来减少压缩后的质量损失，相比标准后训练量化（PTQ）能获得更高的整体质量
- 提供两种量化格式：通用 Q4_0 格式适用于所有模型，以及专为移动设备设计的自定义移动量化架构，后者可将 Gemma 4 E2B 内存占用压缩至 1GB，无逐层嵌入的纯文本版可低于 1GB
- 移动端优化采用四项核心技术：静态激活（预计算缩放设置以减轻芯片负载并加快响应）、通道级量化（适配移动加速器硬件设计）、针对 token 生成部分使用 2 位量化、嵌入和 KV 缓存优化降低活跃内存占用
- 模型权重已在 Hugging Face 发布，提供 GGUF 格式（适配 llama.cpp、Ollama、LM Studio）和压缩张量格式（适配 vLLM），同时支持未量化检查点供自定义转换
- 兼容多种开发工具：边缘端支持 Google LiteRT-LM 和 Transformers.js Web 端推理；Apple Silicon 用户可使用 MLX 框架；模型服务支持 SGLang 和 vLLM
- QAT 检查点可保留多令牌预测（MTP）的推理加速能力，并支持通过 Hugging Face Transformers 和 Unsloth 进行权重微调
Do the Hardest Thing
做最难的事
- Jesse Hanley 提出"做最难的事"哲学：困难的事竞争者少，持续深耕终有回报——Bento历时七年才找到产品市场契合点即是证明
- "做最难的事"≠拼命工作。作者经营滑雪板店时工作强度极高，却是围绕简单想法的苦差事；同年成立的Skype选择解决互联网免费通话这一真正难题，两位创始人最终各获约3.5亿美元
- 真正区分成败的是问题空间的选择，而非努力程度。作者与Jon Buda共同创立的播客托管平台Transistor，因底层问题足够困难、多数人不敢涉手，才形成真正的竞争壁垒
- 最难的想法往往也是最好的想法。幂律效应在风险投资和个人点子上同样适用——你的最佳（最难）点子，其价值可能超过其余所有点子之和
- 实践路径：在自身专业区域内寻找需求已存在但多数人不敢触碰的高价值难题；Jason Cohen将其精炼为："找到一个真正值得做的好点子，然后沉迷其中、坚持到底"
- 这一建议是成功的必要条件而非充分条件——每家公司都难以建立，所以不如选择去做那件困难的事