2026-06-05

24 篇热帖

1. Changing how we develop Ladybird (ladybird.org)

Ladybird 项目宣布调整代码贡献流程,不再接受公开的 Pull Request(PR),未来所有代码变更仅由项目维护者直接引入。

这一调整出于多重考量。首先,项目正迈向首个 Alpha 版本和面向真实用户的新阶段,需要更严格的开发流程、更清晰的安全模型,以及更明确的代码责任归属。浏览器需要处理来自整个互联网的不受信任输入,一个精心伪装的漏洞就可能被攻击者利用。因此,进入代码库的每一行代码都必须由最终对其架构兼容性、长期维护性和安全性负责的人来把控。

其次,AI 工具的迅速普及改变了开源贡献的“经济学”。以往,一份厚重的补丁往往意味着贡献者投入了大量时间和精力,这也是维护者判断其善意与可信度的重要依据。但如今,AI 能够以更低的成本和更快的速度生成看似严肃、高质量的代码,使得 PR 本身已无法像过去那样有效反映提交者的真实能力与意图。项目方指出,已有先例表明存在长期、有资源支持的攻击者通过逐步获取维护者信任来渗透开源项目,而 AI 进一步降低了此类攻击的门槛。

作为过渡措施,项目将关闭所有当前处于开放状态的公开 PR,并且不会设立其他替代性补丁提交流程(如通过 Issue、评论、邮件或 Fork 等渠道)。管理层明确表示,不希望形成“影子贡献系统”,也不愿意将外部 Fork 或补丁汇总视为上游的待审队列。

与此同时,Ladybird 强调其代码依然以开源许可证向公众开放,项目本身仍是开源项目。外部参与者仍可通过提交清晰的 Bug 报告、最小化复现、网站兼容性测试、Web 标准讨论、设计反馈、安全漏洞报告及技术评议等方式继续推动项目发展。

总体而言,Ladybird 认为在准备向普通用户交付浏览器的关键节点上,开发流程必须与产品责任相匹配:将代码引入权限严格限定在维护者群体之内,以确保质量、安全与可维护性。

2. When AI Builds Itself: Our progress toward recursive self-improvement (www.anthropic.com)

Anthropic正将日益增长的AI开发工作委托给AI系统,推动朝向递归自我改进——即AI完全自主设计并开发自身继任者。这一趋势并非必然,但可能早于多数机构的准备速度,既带来科学和医疗等领域的巨大潜力,也增加了人类失控的风险。

发展阶段经历了从2021年人类手动编码,到2023–2025年聊天机器人辅助生成片段,再到2025–2026年代理自主编写文件,直至当下自主代理可运行代码并委托数小时工作。未来可能出现"闭环":Claude自身持续改进后继版本。

外部证据显示,AI可靠自主完成任务所需时长约每4个月翻倍。SWE-bench(真实软件工程测试)和CORE-Bench(研究复现测试)均在约两年内从低分走向饱和。

Anthropic内部数据表明:

  • 工程产出:截至2026年5月,代码库中逾80%的合并代码由Claude编写;2026年Q2工程师人均日合并代码量达2024年的8倍。
  • 代码质量:开放任务成功率在2026年5月达76%;代码质量从2025年末低于人类提升至当前大致持平,预计年内超越。自动化Claude审查可捕获过去约三分之一的生产事故bug。
  • 实验执行:在明确目标下优化训练代码速度,Claude将加速比从2025年5月的约3倍提升至2026年4月的约52倍,超越人类研究者数小时才能达到的4倍。
  • 实验设计:2026年4月,Claude端到端自主完成了开放式AI安全研究项目,自主提出假设、测试并迭代,在人类仅设定问题的情况下恢复了97%的性能差距。
  • 研究判断:在129个研究路径偏离节点上,模型选择优于人类研究员的比例从2025年11月的51%升至2026年4月的64%。

未来工作方面,人类角色正从编写代码和运行实验,转向审查与方向设定。研究品味和判断力仍是人类暂时的比较优势,但AI正快速缩小差距。

文章提出三种未来情景

  1. 增长停滞(被视为不太可能):能力扩散但趋势放缓,社会组织有更多适应时间;
  2. 复合效率持续提升(最可能路径):AI高度自动化开发,人类主导方向设定,知识工作和政府服务效率革命性提升,但也将出现新的组织瓶颈;
  3. 完全递归自我改进:AI自主设计继任者,开发速度完全由算力和算法效率决定,人类转向监督与验证。这将深刻改变经济结构,但也使对齐问题更加严峻。

应对建议上,Anthropic认为若能可验证地放缓前沿AI开发以争取适应时间将是好事,但单方面暂停效果有限,可能只会让最不谨慎的参与者领先。Anthropic Institute将研究建立可信协调与验证机制,使多方在可验证条件下共同放缓或暂停成为可能,并计划组织政策制定者、研究人员和民间社会展开对话,让社会更广泛地参与这一关键抉择。

4. Anthropic's open-source framework for AI-powered vulnerability discovery (github.com)

概述

Anthropic 开源的 AI 漏洞发现参考框架,基于 Claude 实现从侦察、发现、验证、分类、报告到修补的自主闭环。该项目源于 Anthropic 与安全团队合作的经验总结,仅作为参考实现提供,不接受维护或外部贡献。如需托管服务,可使用商业产品 Claude Security,支持跨项目源码漏洞扫描、多阶段验证、生命周期管理及自动修复。

核心组件

项目包含两部分:

  • Claude Code 交互式技能/quickstart/threat-model/vuln-scan/triage/patch/customize。用于交互式威胁建模、静态扫描、分类和补丁生成,仅涉及文件读写,无需沙箱即可安全运行。
  • harness/ 自主参考流水线:默认配置为通过 Docker 和 ASAN 发现 C/C++ 内存漏洞,执行“构建 → 侦察 → 发现 → 验证 → 去重 → 报告 → 修补”七阶段流程。该流水线为参考架构,其通用思路、提示词和沙箱机制可复用,但需针对具体代码库定制,无法开箱即用。

安全要求

交互式技能在 Claude Code 中逐条审批工具调用时,可安全地在无沙箱环境运行。自主流水线(包括基于流水线结果执行 /patch会执行目标代码,因此默认必须在 gVisor 沙箱内运行(通过 bin/vp-sandboxed 调用,并限制代理网络出口),除非显式覆盖否则会拒绝启动。

四阶段上手路径

阶段 时间 目标
1 第 1 天 交互式静态扫描闭环
2 第 2 天 在 C/C++ 库上运行自主流水线
3 第 3–5 天 针对自有目标定制流水线
4 第 2 周起 建立规模化自主扫描-分类-修补外层循环

第 1 天(交互式静态分析):依次使用 /threat-model 生成威胁模型,/vuln-scan 执行基于威胁模型的静态扫描,/triage 对结果进行验证、去重和排序,/patch 生成候选修复。产出包括 THREAT_MODEL.mdVULN-FINDINGS.jsonTRIAGE.jsonPATCHES/。此阶段完全基于源码静态审查,未编译或运行代码,假阳性率可能较高。

第 2 天(运行参考流水线):完成虚拟环境、Docker 与 gVisor 沙箱的一次性安装后,使用 bin/vp-sandboxed run 在已知存在漏洞的开源 C/C++ 库(如 drlibs)上启动完整七阶段流程:

  1. 构建:编译带 ASAN 的 Docker 镜像;
  2. 侦察:轻量级代理划分值得分别攻击的输入解析子系统,避免并行代理重复挖掘同一漏洞;
  3. 发现:多代理并行在隔离容器中构造畸形输入,直至崩溃可稳定复现;
  4. 验证:独立评分代理在全新容器中复现崩溃;
  5. 去重:裁判代理判定是否为已知漏洞的重复;
  6. 报告:生成包含可利用性、触发路径和严重程度的结构化分析;
  7. 修补:为每个独立漏洞生成修复方案,并验证其能否通过构建、能否阻止原崩溃输入、是否通过原有测试 suite,以及能否抵御新的发现代理绕过。

第 3–5 天(定制流水线):通过调整“发现信号(如异常/崩溃签名)”、“概念验证形式(如文件输入/HTTP 请求)”以及“构建运行方式(如容器化构建)”,可将流水线移植到其他语言或漏洞类别。先对自有代码运行第 1 天技能,再通过 /customize 读取威胁模型和扫描结果,自动生成 targets/<your-service>/ 配置,最后以单次冒烟测试(--runs 1)验证。

第 2 周(建立外层循环):运行多轮并行扫描(--runs 5 --parallel --stream --auto-focus),使用 /triage 跨所有运行结果去重、重新校准 severity 并路由给组件负责人,再基于优先级使用 /patch 自动生成并验证修复。快速修补或记录 known_bugs 能防止模型重复挖掘已知问题,从而持续发现更深、更新的漏洞。需注意,自动化分类与修补仍是当前瓶颈,严重性和优先级判断仍需结合业务环境投入工程人力。

后续优化方向

成功落地的团队通常沿以下方向深化:

  1. 对内部仓库与关键开源依赖进行风险与优先级排序;
  2. 搭建专用扫描基础设施,避免长期依赖个人电脑或一次性虚拟机;
  3. 将扫描纳入软件开发生命周期(SDLC),如配置每日/每周定时扫描或集成至 CI 流水线;
  4. 持续测试与选型,找到最适合自身场景的大模型配置。
5. Retro-Tech Parenting (havenweb.org)

复古科技育儿

作为一名技术专家与家长,作者既惊叹于数字技术的魔力,又对广告技术、监控资本主义和流量收割等现代商业模式深感不安。他担忧孩子暴露在这些无处不在的数字陷阱中,但仍希望与他们分享技术带来的 enriching 体验。因此,他选择放弃部分现代便利,转而采用二三十年前的复古技术方案,构建更安全的家庭数字环境。

实体媒体

作者重新拥抱 CD、DVD 和蓝光等实体媒介。他为家中购置了迷你 CD 音响,孩子们可以随身携带、在不同房间插电播放;还利用公共图书馆借阅 CD 和影碟。实体媒体的核心优势在于内容完全由家长物理掌控——不适龄的内容不会进入家门;孩子们可以独立操作播放,而设备内部不存在算法推荐或广告等“对手”。

固定电话

作者在厨房旁安装了一部有线实体电话,通过 VoIP 服务接入现代电话网络。这类电话保留了与智能手机的向后兼容性,孩子可以独立联系祖父母、亲戚和邻居;同时具备精细的数字管控能力,例如设置联系人白名单、自动屏蔽晚餐到凌晨时段的来电。孩子们能自己打电话约朋友玩耍,而不必再通过家长安排,真正获得了沟通的独立性。

家庭电脑

他在厨房旁放置了一台二手台式机,为每个孩子设立独立账户。网络层面通过 Pi-hole 过滤 DNS,并严格实施域名白名单:孩子可以访问维基百科、离线玩 Minecraft,或浏览家长精选的网站(如魔方解法、鞋带绑法教程),但无法使用 Google、YouTube、Spotify 或公共游戏服务器。此外,孩子还能将 CD 翻录到电脑上,逐步建立个人音乐库。这种方式让孩子在安全、可控的环境中独立使用计算机。

文章最后指出,尽管上述方案对非技术家长可能门槛较高,但其核心哲学具有普适性:现代技术中令人不安的部分之所以占主导,正是因为极致的便利,而这种便利往往伴随隐性代价。在育儿过程中,拒绝支付这一代价,并主动从过去的技术形态中汲取灵感,是一种值得且有意义的坚持。

6. C++: The Documentary (herbsutter.com)

《C++:纪录片》(C++: The Documentary)已于 YouTube 首映。本文作者 Herb Sutter 参与了首映直播,与 Bjarne Stroustrup 及 C++ 发展史上的众多关键人物在线交流,并感慨自己很荣幸能成为多年来推动这一项目的数百人之一。

Sutter 强烈推荐尚未观看的观众将其列入周末计划。该片精炼回顾了 C++ 四十年的成功历程:从 AT&T 贝尔实验室的 humble 起步,到全球普及,再到截至 2025 年第三季度已成为全球四大主流语言中增长最快者——过去三年半用户增长约 90%。

影片汇聚了 C++ 生态的核心人物,包括:C++ 设计者及最初实现者 Bjarne Stroustrup、STL 设计者 Alexander Stepanov、C#/TypeScript/Turbo Pascal 之父 Anders Hejlsberg、C++ 标准委员会创始成员 Andrew Koenig、贝尔实验室 C++ 开发团队经理 Barbara Moo、《C 程序设计语言》合著者 Brian Kernighan、LLVM/Clang/Swift 创造者 Chris Lattner、CERN ROOT 框架项目负责人 Danilo Piparo、Hudson River Trading 开发负责人 Eric Lubin、微软工程师与 C++ 工具构建者 Gabriel Dos Reis、标准 C++ 基金会主席 Herb Sutter、Doom/Quake 联合创始人 John Romero、Nvidia 首席研究科学家 Andrei Alexandrescu,以及 ISO C++ 委员会副主席 Nina Ranns 等。

影片章节按时间线梳理了 C++ 的完整历史与关键议题:AT&T 贝尔实验室的发明背景;"C with Classes" 的诞生与早期采用;向 C++(及 CFront 编译器)的演变;C++ 命名由来;AT&T 内部的销售策略与团队接管风波;早期版本开发及 2.0.0 的发布;语言向贝尔实验室外部传播;版本碎片化与标准化需求;Alexander Stepanov 的 STL;首个标准 C++98;90 年代在 CERN 的应用;向游戏与交易领域的扩展;2000 年代初的 "C++ 寒冬";与 C# 等语言的语言之争;对高效编程语言的再度需求;现代 C++(C++11)的推出;关于标准委员会是否使语言过于复杂的讨论;C++ 的无处不在;未来挑战;以及 Bjarne Stroustrup 的深远影响。

作者简介:Herb Sutter 是作家与演讲者,现任 Citadel Securities 技术院士,并担任标准 C++ 基金会及 CppCon 主席,曾于 2002 年至 2025 年担任 ISO C++ 标准委员会主席。

8. Meta's ships facial recognition on smart glasses (www.buchodi.com)

对Meta智能眼镜配套应用Stella(Android版本273.0.0.21)的逆向工程显示,应用内部已完整集成并部署了一套端上面部识别系统,但在普通未激活账户下并未向用户开放。

端上模型与算法栈
应用通过Meta的NMLML资源分发系统下载了三个ExecuTorch模型,总计约100 MB,对应开源社区广泛使用的架构:

  • SCRFD(3.4 MB):在图像中检测人脸;
  • KPSAligner(117 KB):基于关键点裁剪并对齐人脸;
  • SFace(96 MB):将人脸转换为2048维的生物特征嵌入向量。

本地向量索引与数据库
应用在RLDrive(Meta跨设备同步框架)的person_profiles命名空间下维护了一个SQLite数据库,路径为/files/rldrive/person_profiles/objects.db。其Schema包含:

  • person表:存储人员基本信息(姓名、URI等);
  • face表:存储人脸记录,通过personUri与人员关联;
  • face_mediaPath_vec虚拟表:使用开源扩展sqlite-vec,对2048维浮点向量建立余弦相似度索引,与SFace输出维度完全匹配。

识别流程即为:提取嵌入向量 → 在本地索引中执行余弦相似度查询 → 联表获取person.name用于通知文案。

端到端功能验证
研究者直接调用既有处理程序,在测试图片上跑通了完整链路:

  • 匹配成功:系统触发标题为*“Person recognized”的高优先级Android通知,正文显示“Recognized [姓名]”*。通知携带深链fb-viewapp://name_tags?face_id=...,但当前版本中该跳转的目标页面并未实际构建。
  • 未匹配:系统将经过检测与对齐的面部裁切图(.jpg)及其2048维L2归一化特征向量(.emb,8192字节,float32大端序)以UUID命名,成对写入私有目录/NameTagsPending/(权限0700,重启后保留)。该目录字面含义为“待命名标签”,实质构成了可用于后续追溯识别的生物特征数据集。

用户界面与入口
APK内存在一个文案为*“See your connections” / “Remember the people you met...”*“Connections”**卡片,但普通账户下不会显示。同时,前述通知所指向的个人资料页面在此版本导航图中缺失。

关键限定
作者明确区分了“能力存在”与“正在对用户生效”:

  • 在普通未激活账户上,用户可见UI不出现,也未观测到Meta服务器向person_profiles人脸库推送身份数据;
  • 因此,目前没有证据表明Meta正在对普通用户实时识别陌生人或秘密运行该功能。

然而,检测设备、对齐、 embedding生成、向量检索、本地存储、未匹配写盘路径及通知触发的完整链路已完全打通且数据维度彼此一致,这并非遗留代码,而是一项有目的的重大工程投入。是否及何时正式启用,由Meta远程控制。

9. Tracing a powerful GNSS interference source over Europe (arxiv.org)

标题与核心发现

论文《Tracing a powerful GNSS interference source over Europe》由 Todd Humphreys 撰写,已提交至美国导航学会(ION)期刊《NAVIGATION》审稿。研究基于2019年至2026年间从欧洲大陆、格陵兰和加拿大地面GNSS参考站网络收集的数据,分析并确认了一个自2019年以来在上述区域引发多次强瞬态大范围干扰事件的全球导航卫星系统(GNSS)干扰源。该干扰源最终被高置信度地识别为一组运行于闪电轨道(Molniya orbit)的俄罗斯早期预警卫星星座。

研究背景与意义

近年来,全球GNSS干扰事件的激增主要源于地面或近地干扰源。然而,本研究聚焦的星载干扰源具有特殊威胁性:其潜在覆盖范围极广,且标志着GNSS干扰在性质上的升级(qualitative escalation),因此需要特别关注。

研究内容与方法论

论文的核心工作与贡献可分为四个方面:

  1. 检测框架:开发了一套基于接收功率(received-power-based)的GNSS干扰检测框架。
  2. 干扰特征刻画:详细描述了该干扰源引发的大范围干扰事件在空间、时间和频谱上的分布模式。
  3. 识别技术:提出并分析了融合接收功率与到达时间差(Time-Difference-of-Arrival, TDOA)测量的联合识别技术。
  4. 干扰源确认:将上述技术应用于实测数据,最终将干扰源锁定为俄罗斯在闪电轨道(“Molniya”或bits)上运行的早期预警卫星星座。

文献与发布信息

  • 预印本编号:arXiv:2606.03673 [eess.SP]
  • 学科领域:信号处理(Signal Processing)
  • 提交日期:2026年6月2日(v1版本)
  • DOI:已通过 DataCite 分配 arXiv DOI(10.48550/arXiv.2606.03673),待注册生效。
10. Open Code Review – An AI-powered code review CLI tool (github.com)

Open Code Review(OCR)是阿里巴巴开源的 AI 代码审查 CLI 工具,源自集团内部官方 AI 审码助手,历经两年大规模生产验证后对外开源。用户只需配置大模型接口,即可对 Git 变更进行行级精度的结构化代码审查。

核心设计:确定性工程 × Agent 混合架构

针对通用 Agent 在代码审查中易出现的覆盖不全、位置漂移、质量波动等问题,OCR 采用“确定性工程 + Agent”的混合架构。确定性工程模块对关键步骤施加硬约束:精确筛选待审文件、智能捆绑关联文件(如多语言资源文件)并以子 Agent 分治并发处理、基于模板引擎实现细粒度规则匹配以消除信息噪声,并配备外部定位与反思模块以提升评论位置与内容的准确性。Agent 则专注于动态决策与上下文检索,通过针对代码审查深度优化的提示词模板和专用工具集,在保证效果的同时降低 Token 消耗。

安装与快速开始

支持通过 NPM(npm install -g @alibaba-group/open-code-review)、GitHub Release 二进制(覆盖 macOS、Linux、Windows 多架构)或源码构建安装,全局可用 ocr 命令。使用前必须配置 LLM:可通过 ocr config set 交互配置,或设置环境变量(OCR_LLM_URLOCR_LLM_TOKENOCR_LLM_MODEL 等),也兼容 Claude Code 环境变量。配置完成后执行 ocr llm test 测试连通性。

审查方式灵活:

  • ocr review:审查工作区所有变更(暂存、未暂存、未跟踪)。
  • ocr review --from main --to feature-branch:对比分支范围。
  • ocr review --commit abc123:审查单次提交。

常用选项包括 --preview 预览待审文件(不调用 LLM)、--format json 输出机器可读结果、--concurrency 控制并发数、--rule 加载自定义规则等。

与编码 Agent 及 CI/CD 集成

OCR 可无缝嵌入 AI 编码助手:作为 Skill 安装(npx skills add)、Claude Code 插件(/plugin install),或直接复制命令文件到 .claude/commands 目录使用斜杠命令调用。同时支持接入 CI/CD 流水线,通过 --format json 自动化处理 Merge/Pull Request,仓库内提供 GitHub Actions 与 GitLab CI 示例。

审查规则体系

规则按四层优先级链解析(由高到低):--rule 命令行指定、项目目录下的 .opencodereview/rule.json、全局配置 ~/.opencodereview/rule.json、内置系统默认规则。每层均为“首次匹配即生效”,JSON 格式支持 ** 递归匹配与 {} 花括号扩展。

配置、查看器与可观测性

主配置文件位于 ~/.opencodereview/config.json,环境变量优先级更高。内置 ocr viewer 可在本地启动 WebUI 查看审查会话历史(默认 localhost:5483),通过 Host 头白名单机制防御 DNS 重绑定攻击,非回环地址需通过 OCR_VIEWER_ALLOWED_HOSTS 显式声明。可选接入 OpenTelemetry 链路追踪与指标采集,默认关闭,支持 OTLP 导出;设置 telemetry.content_logging 可在遥测数据中包含 LLM 对话内容。

该项目采用 Apache-2.0 许可证。

12. Sagrada Família Lego set (www.lego.com)

乐高建筑系列 圣家堂 (21065) 产品概要

乐高建筑系列圣家堂(编号 21065) 是乐高迄今为止零件数最多的套装,共含 12,060 块积木,面向 18 岁及以上 成人玩家。套装售价 799.99 美元,现已开放预订,预计 2026 年 11 月 1 日 起发货,每户家庭限购 3 套

该套装以巴塞罗那地标圣家堂为原型,精细还原了安东尼·高迪的设计细节,窗户采用特殊的彩色玻璃效果。拼搭顺序模拟真实建筑工程,依次为:后殿与地下室、高迪生前唯一完成的诞生立面、受难立面、中殿、西侧圣器室、六座塔楼,以及最后的东侧圣器室与荣耀立面。

成品尺寸约为 高 62 厘米(24 英寸)、宽 47 厘米(18.5 英寸)、深 39 厘米(15 英寸),配有底座名牌,适合作为家居或办公室的收藏级建筑装饰展示。

主要特点包括:

  • 高阶创意挑战:超过 12,000 片零件,结构精密,还原真实建造流程。
  • 数字化拼搭辅助:通过 LEGO Builder 应用 查看 3D 说明,支持缩放、旋转、进度保存与多套装管理。
  • 会员积分回馈:购买可获约 5,200 LEGO Insider 积分,可用于结账抵扣、兑换会员限定套装或周边奖励。
  • 礼品定位:适合热爱旅行、欧洲历史与建筑收藏的成人,作为生日或节日礼物。

这是一款兼具挑战性、教育性与展示价值的高端建筑模型。

13. South Korean Forums Will Need to Scan Every Images with AI Censorship Tools (discuss.privacyguides.net)

根据提供的内容,韩国近期修订《电气通信事业法》(전기통신사업법),强制要求所有互联网社区及论坛运营者使用人工智能,对网站上每一处用户上传的图片与视频进行全面扫描审查。

此项新规将内容审核义务完全置于平台方,不仅涵盖所有用户生成的图像与视听内容,还要求运营者自行承担运行相关AI审查系统所需的硬件成本与基础设施。

这意味着韩国的在线社区必须部署全覆盖式的自动化内容过滤机制,任何用户上传的图像和视频都将先经过AI检测,方可完成发布或展示。该政策标志着韩国政府对网络论坛实施更严格的事前审查制度,将AI censorship 工具作为合规运营的必要技术条件。

14. WSL 2 is getting faster Windows file system access (www.boxofcables.dev)

WSL 2 正通过一项底层 DMA 优化缩小跨系统文件访问的性能差距。2026 年 5 月合并的修改(PR #40654,作者 Ben Hillis)为每个 virtio 设备分配独立的 DMA 内存池,消除了 virtiofs 路径上最后一处主要的资源争用点。

跨系统文件访问的演进

  • WSL 1(2016):通过 DrvFs 直接在 Windows NT 内核中处理 Windows 驱动器访问。由于没有虚拟机边界,/mnt/c 等路径的操作几乎可以直达 NTFS,文件密集型负载性能较好。
  • WSL 2(2019):改为在轻量级 Hyper-V 虚拟机中运行完整 Linux 内核,提升了 Linux 原生工作负载的兼容性与性能,但跨系统访问需要新机制。最初,WSL 2 在 Windows 侧内置 Plan 9(9P)文件服务器,Linux 会话通过 Hyper-V socket 与其通信。9P 存在协议开销,每条操作受消息大小限制(msize=65536,即 64 KB),大量小文件访问时效率受限。
  • virtiofs(约 2021 年起):作为实验性可选功能引入,通过 VirtIO 传输实现共享内存式文件访问,相比 9P 显著降低了序列化开销。用户需在 .wslconfig[wsl2] 段中设置 virtiofs=true 开启。此后微软持续迭代,包括设备复用改进(PR #40298)、无 DAX 的共享 mmap 支持(PR #40426)等。

DMA 层优化

Hyper-V 虚拟机通过“弹跳缓冲区”(bounce buffer)执行 I/O DMA:在 4 GB DMA 边界以下预留一段物理内存区域(Linux 内核中称为 SWIOTLB 池),供硬件直接寻址。此前,WSL 2 会话内的所有 virtio 设备(如 /mnt/c/mnt/d 的 virtiofs 挂载以及 virtio 网络适配器)共享同一个全局 DMA 池,在高 I/O 负载下相互争抢。

新修改(PR #40654)为每个 virtio 设备分配专属的 DMA 池。启动时,内核在 4 GB 以下分配连续的物理内存地址,并通过 sysfs(/sys/bus/vmbus/drivers/hv_pci/swiotlb_baseswiotlb_size)公布;WSL 服务读取后,在创建每个 virtio 设备时注入专属的 swiotlb= 选项。这消除了驱动器与网卡之间的共享队列争用。

要求:此功能需要内核版本 Microsoft.WSL.Kernel 6.18.26.3-1 及以上,并配合 WSL 2 DeviceHost 1.2.29-0 推出。若内核过旧,WSL 会提示:“The running kernel is missing a patch that significantly improves virtio device performance...”

实际影响与使用建议

该优化最利好频繁跨越 Windows/Linux 边界的文件密集型工作流,例如代码存放在 Windows 用户目录(C:\Users\...)中,却在 WSL 2 内通过 /mnt/c 执行 cargo buildnpm installmvn package 等构建操作。独立 DMA 池减少了 virtiofs 路径上的资源争抢。使用相同 DMA 基础设施的 VirtioProxy 网络同样受益。

要获得最佳体验,建议:

  • .wslconfig[wsl2] 段中设置 virtiofs=true
  • 通过 wsl.exe --update --pre-release 更新到最新 WSL 内核;
  • 确保 WSL 2 会话内存大于 1 GB,因为 SWIOTLB 池至少需要 64 MB 的可用空间。

现状

目前 virtiofs 仍为可选功能,默认的跨系统文件传输方式仍是基于 Hyper-V socket 的 Plan 9 协议。但从 WSL 1 的 DrvFs,到 WSL 2 的 9P,再到 virtiofs 及此次 per-device DMA 池优化,跨越 VM 边界的文件 I/O 性能差距正在不断缩小。相关开发仍在 github.com/microsoft/WSL 持续公开进行。

15. Fine-tuning an LLM to write docs like it's 1995 (passo.uno)

作者开展了一项独立非商业研究,通过微调本地大语言模型(LLM)来模拟20世纪80至90年代微软技术文档的写作风格,以验证“本地专用LLM”在辅助技术写作中的可行性。

数据准备与清洗 研究使用 Bitsavers 网站上的微软文档集合(1977–2005年,超过3700万词)作为训练语料。作者下载 OCR 文本后,利用 Python 脚本清理索引、前言等杂物,再经 OpenRouter 调用 gemma-4-26b 模型对段落进行“保留/丢弃”分类,筛选出可读内容。随后将文本按段落和章节切分为约512 tokens 的块,并为每块配上基于模板生成的合成指令,最终得到192,456条 JSONL 格式的训练样本。

微调方法与实验设置 为避免从零训练的高昂成本,作者采用 QLoRA(量化低秩适配)技术在 Runpod 云 GPU 上微调模型。QLoRA 通过冻结原始权重、在顶层添加轻量适配器(adapter)来实现行为调整。实验以 Llama 3.1 8B Instruct 和 Qwen 2.5 7B Instruct 为基座, varying 数据量(4万与19.2万条)、训练轮数(1 到 3 epochs)及适配器秩(rank 8 与 16),在一天内、总计约50美元成本下完成多组适配器训练,并导出为本地 Ollama 可运行的 GGUF LoRA 模型。

测试任务与结果对比 评估使用三项一致提示:文档化标准 C 函数 malloc();为虚构的 Win32 API ConnectWifi() 撰写文档;以90年代微软风格解释 REST API。未微调的基线模型输出现代 Markdown 风格文档。微调后的 Llama Instruct 虽能生成时代正确的结构(Synopsis、Return Value 等),但在 REST API 任务中因 RLHF 训练过重而退化为营销腔调。Qwen 系列表现更优:40k-3epochs 模型对虚构函数保持“角色沉浸”,将其当作真实 API 记录;192k-1epoch-rank16 模型在 REST API 任务中输出极具说服力的“Windows 2000 Resource Kit”式章节开头,成功实现风格迁移。

关键参数发现 对比 rank 8 与 rank 16 发现:rank 8(更少自由度)的适配器更“诚实”地服从训练语料风格,对虚构内容的扮演更彻底;rank 16 虽表达能力更强,但容易脱离语料产生幻觉(如将 REST 臆测为 SOAP)。基础模型(非指令版)因缺乏问答对齐能力,完全无法遵循提示,仅输出随机文本片段。

结论 fine-tuning 能以较低成本让小型本地模型习得特定历史时期的技术写作风格与结构,适用于按企业既有风格指南审稿或起草文档等任务。然而,该过程依赖大量高质量训练数据、合适的基座模型选择及繁复的超参数调优。微调模型仅是令人信服的“模仿者”,缺乏判断力,无法替代人类技术写作者,只能作为辅助工具。

16. Azure Linux 4.0 is Microsoft's first general-purpose Linux (www.boxofcables.dev)

Azure Linux 4.0:微软首款通用Linux发行版进入公测

微软在 Build 2026 开放 Azure Linux 4.0 公众预览。这是其自研Linux首次从专用基础设施底座变为通用发行版,用户可在任意 Azure 虚拟机运行,不再仅限于 Azure Kubernetes Service(AKS)底层主机。

历史背景

Azure Linux 前身是 2019 年内部启动、2020 年开源的 CBL-Mariner,属 RPM 体系,早期版本从零手工构建 spec 文件;同期基于 Debian 的 CBL-Delridge 已停止维护。2024 年 3 月更名为 Azure Linux 前,它主要用作 AKS 节点、WSLg 及 Azure SQL、Cosmos DB 等第一方服务的底座,普通用户无法直接部署。

4.0 核心变化

4.0 改为基于 Fedora 43 快照构建,通过“声明式覆盖层”跟踪上游,所有偏离 Fedora 的修改均附带书面原因,渲染后的 spec 文件公开可查,保障供应链透明。

关键升级包括:专为 Azure 调优的 Kernel 6.18 LTS(支持 Hyper-V、GPU/AI 加速器,微软维护独立分支并嵌入签名密钥);包管理器由自研 tdnf 换为标准 dnf5;以及 glibc 2.42systemd 258、支持后量子的 OpenSSL 3.5Python 3.14、数据库后端现代化的 RPM 6.0

安全方面,全镜像支持 SELinux,内核默认启用 ASLR、栈保护、seccomp 与 systemd 沙盒

19. Do transformers need three projections? Systematic study of QKV variants (arxiv.org)

研究背景与目的
Transformer 的查询(Q)、键(K)、值(V)注意力机制是各类 AI 任务的核心,但三个独立投影各自的贡献以及省略部分投影的影响尚不明确。本文系统研究投影共享约束,以验证 Transformer 是否必须依赖三个独立投影。

三种投影共享变体
研究评估了三种共享方案:(a) Q-K=V(共享键值投影);(b) Q=K-V(共享查询键投影);(c) Q=K=V(单一投影)。由于 (b) 和 (c) 会产生对称注意力图,作者引入二维位置编码以恢复非对称注意力。

实验设置与性能
实验覆盖合成任务、视觉任务(MNIST、CIFAR、TinyImageNet、异常检测)以及大规模语言建模(300M 和 1.2B 参数模型,在 100B tokens 上训练)。结果表明,在多数设置中,采用投影共享的 Transformer 与标准 QKV Transformer 性能持平,部分场景下甚至更优。在语言建模中,Q-K=V 共享可减少 50% 的 KV 缓存,困惑度(perplexity)仅下降 3.1%

与头共享的协同效应
投影共享与分组查询注意力(GQA)/多查询注意力(MQA)等头共享技术互补:

  • Q-K=V + GQA-4:KV 缓存减少 87.5%
  • Q-K=V + MQA:KV 缓存减少 96.9%

这极大降低了推理内存占用,使大规模语言模型的设备端/边缘部署成为可能。

内在机制分析
Q-K=V 能保持质量的原因是键和值可以占据相似的表示空间,且注意力在低秩机制下运行;而 Q=K-V 会破坏注意力的方向性,导致性能受损。Q=K=V(单投影)在引入非对称位置编码后仍可取得有竞争力的结果。

结论
该研究将投影共享系统性地表征为注意力机制中一种未被充分探索的权重绑定形式。实验证明其在维持模型质量的同时,可提供直接且可量化的推理内存收益,对计算与内存受限的边缘部署具有重要实践价值。

21. IPv6 zones in URLs are a mistake (xeiaso.net)

IPv6 zones in URLs are a mistake

该页面实际展示的是 Anubis 反爬虫系统的拦截说明。网站管理员部署此系统,旨在抵御 AI 公司 aggressive scraping 对服务器造成的压力——此类抓取行为会导致网站宕机,进而使所有用户无法访问资源。

Anubis 采用类似于 Hashcash 的工作量证明(Proof-of-Work)机制。其核心思路是:对单个用户而言,额外的计算开销微乎其微、可忽略不计;但在大规模爬虫场景下,这些开销会显著累积,从而使 scraping 成本大幅提高。

该系统被视为一种过渡性折衷方案。终极目标是通过更先进的指纹识别技术(例如分析字体渲染方式)来识别无头浏览器,从而区分真实用户与自动化爬虫,避免向普通访问者展示工作量证明验证页面。

另外,页面声明 Anubis 依赖现代 JavaScript 特性才能运行,与 JShelter 等隐私保护插件不兼容,要求用户禁用此类扩展。

22. Entanglement Builds Space-Time. Now "Magic" Gives It Gravity (www.quantamagazine.org)

在量子引力研究中,物理学家通过全息理论追溯时空可塑性的量子起源,发现一种名为“魔法”(magic)的量子特性可能是引力的关键。

约翰·惠勒曾以两句话概括广义相对论:时空告诉物质如何运动,物质告诉时空如何弯曲。然而,理论物理学家在构建量子层面的宇宙模型时,长期难以实现这两种作用的互动。上世纪90年代末发展的全息原理提供了一条新路径:将一个宇宙区域的三维时空替换为其边界上的二维量子粒子网络。研究发现,量子纠缠如同连接组织,赋予时空以结构,从而满足了惠勒的第一句话。举例来说,虫洞在全息图景中等价于两组高度纠缠的粒子;剪断纠缠即意味着空间连接的消失。

不过,早期的全息模型大多基于“稳定子码”(stabilizer codes)。这类量子纠错码虽然能将空间和物质编码进量子粒子,却将两者的纠缠严格割裂,使空间与物质无法相互影响——物质如同放在床垫上的保龄球,却无法压出凹陷。换言之,这些模型只能构建“惰性”的时空,无法产生引力,也未能实现惠勒的第二句话。

转折出现在对魔法的研究。魔法是量子计算中衡量状态复杂度的指标,源于非克利福德门(如T门)的操作。与单纯的纠缠不同,魔法无法被经典计算机有效模拟。查尔斯·曹(Charles Cao)等人发现,在全息对应中,魔法赋予了时空“弹性”,使其能够弯曲。2020年前后,曹与合作者在反德西特空间的研究中确认了这一点:边界粒子的魔法程度与内部时空的柔韧性直接相关。

基于这一洞察,曹、普雷斯金尔(John Preskill)等人在2026年初构建了一种新一代量子纠错码。该代码大量使用非克利福德门,引入充分的魔法,从而让原本相互隔离的“空间纠缠”与“物质纠缠”能够相互作用。这相当于让床垫上的保龄球终于压出了凹陷——物质开始告诉时空如何弯曲。研究人员因此获得了引力的“前体”,证明时空背景可以动态涨落,而非固定不变。

这一结果具有深远的理论含义:它表明时空本身就是极端量子的,其形状由纠缠决定,其柔韧性(即引力)由魔法决定。更出人意料的是,引力似乎源于不完美的量子编码。稳定子码之所以不产生引力,是因为它们对信息的保护过于完美;而真实的引力恰恰来自编码信息和误差纠正之间的近似与混合。正如研究者所言,完美的编码对应无引力的空间,而“牛顿的苹果落下”正源于这种必要的不完美。

尽管如此,当前的代码仍是一个高度通用的概念验证。它尚未描述我们生活的实际时空,也未纳入具体的爱因斯坦方程或时间的流逝。研究者坦承这仅仅是“5步中的第0.5步”。但它已为未来的量子引力理论勾勒出一个令人惊讶的轮廓:构成宇宙时空的根基不是经典几何,而是量子纠缠与魔法的交织。未来,物理学家或许能利用高魔法状态的量子计算机,模拟广义相对论失效的极端引力场景。

23. The IsUpMap lets you check the status of over 100 major sites at once (isupmap.com)

Real-time up/down status heatmap for 80+ popular internet services. See which services are up, degraded, or down — right now.

24. ESP32 Bit Pirate, a Hardware Hacking Tool with WebCLI That Speaks Every Protocol (github.com)

A Hardware Hacking Tool with Web-Based CLI That Speaks Every Protocol - GitHub - geo-tp/ESP32-Bit-Pirate: A Hardware Hacking Tool with Web-Based CLI That Speaks Every Protocol