2026 03 06 HackerNews

2026-03-06 Hacker News Top Stories #

  1. gws 是一个开源命令行工具,能动态加载 40+ 个 Google Workspace API 并以结构化 JSON 输出,支持 dry-run、自动分页、NDJSON、AI 代理等功能(非 Google 官方,Apache-2.0 许可)。
  2. 维基媒体因在生产环境误加载来自 ruwiki 的恶意用户脚本,导致全球 JavaScript 污染、管理员账户受影响并短暂进入只读模式,暴露测试与审计流程不足。
  3. Anthropic CEO Dario Amodei 指责 OpenAI 关于与美军合作的宣传为“谎言”,批评“所有合法用途”条款与军事伦理上的分歧并引发公众不信任。
  4. 联邦法官下令政府开始退还超过 1300 亿美元的关税(此前最高法院认定这些关税无效),此案可能影响数千家公司与消费者。
  5. 开发者用 C#、Avalonia 和 SkiaSharp 重写了现代化的 2D 动画工具“Flash 2026”,实现矢量绘图、时间轴、脚本系统等以期成为跨平台替代。
  6. DeFlock 的互动地图收集并展示自动车牌识别(ALPR)摄像头位置,鼓励公众补充数据,凸显广泛监控与滥用风险。
  7. 文章批评当前大语言模型在软件开发中容易“编造”内容、缺乏对需求的深刻理解,助长低质量的“vibe-coding”并损害开源社区信任。
  8. chardet 在发布 v7.0.0 改为 MIT 许可引发争议,原作者称新版仍大量基于 LGPL 代码因而无权重新许可,触及开源许可合规性问题。
  9. 关于使用 AI 辅助重写并改许可的讨论指出 chardet 案件带来三重法律困境:训练数据中含受限代码、AI 输出是否为衍生作品以及“人类作者”原则不明。
  10. 在 Apple Silicon 上用 PersonaPlex 7B 实现了端到端全双工语音对话,显著降低延迟与显存占用,适合本地化实时语音助手部署。

Google Workspace 命令行工具(CLI) (Google Workspace CLI) #

https://github.com/googleworkspace/cli

这是一个名为 gws 的 Google Workspace 命令行工具(CLI)的项目主页,旨在为开发者和 AI 代理提供统一、智能的 Google Workspace API 操作入口。

项目核心特点:

  • 无需手动编写 API 调用代码,自动从 Google Discovery Service 动态加载所有 API 接口,支持 Drive、Gmail、Calendar 等 40 多种服务。
  • 所有命令输出为结构化 JSON,便于程序处理,特别适合与 AI 代理集成。
  • 支持参数预览(–dry-run)、自动分页、NDJSON 流式输出等开发友好功能。

安装方式多样:

  • 通过 npm 全局安装:npm install -g @googleworkspace/cli
  • 支持直接使用预编译二进制包,无需 Rust 工具链
  • 提供 Nix flake 支持,方便在 Nix 环境中使用

认证支持多场景:

  • 支持 gcloud 工具快速配置(推荐)
  • 支持手动 OAuth 流程
  • 支持 CI/CD 环境下的无头认证

项目还内置 AI 代理技能(Agent Skills),可让大模型直接操作 Google Workspace,无需额外工具开发。

重要提示:

  • 该项目非 Google 官方产品,处于积极开发阶段,可能存在破坏性变更。
  • 提供环境变量配置支持,可通过 CONFIG_DIR 自定义配置路径。

文档完整,包含快速入门、高级用法、环境变量说明、架构设计和故障排查指南。项目采用 Apache-2.0 开源协议,欢迎贡献。


HN 热度 897 points | 评论 279 comments | 作者:gonzalovargas | 1 day ago #

https://news.ycombinator.com/item?id=47255881

  • Extrasuite 是一个类似 Terraform 的工具,用于管理 Google Drive 文件,通过 pull/push 工作流实现对 Google Sheets、Docs、Slides 等文件的本地编辑与同步,支持将文档转换为可编辑的本地格式(如 TSV、XML、HTML),并利用 AI 生成的变更通过 batchUpdate API 推送回云端。
  • 该工具使用与用户一对一映射的服务令牌,确保编辑行为在 Google Drive 版本历史中显示为“Alice’s agent”,提升安全性和可追溯性,且仅能访问用户明确共享的文件。
  • 与直接调用 batchUpdate 相比,Extrasuite 降低了出错率和令牌使用效率问题,尤其适用于团队协作场景,已在 100 人团队中内部使用。
  • 对于 Google Slides 的支持仍在完善中,但 Sheets、Docs 和 Forms 已表现良好。
  • 有评论者认为,将 Google Docs 转为 HTML 后由 AI 编辑,再通过 diff 计算差异并提交更新,是一种比 Anthropic 文档编辑技能更优的方案。
  • 针对大型文档(如整本书)的上下文管理问题,该工具通过将文档拆分为可处理的本地文件来缓解,避免一次性加载全部内容。
  • 类似于 Extrasuite 的思路,也有开发者在 Zoho Writer 和 Confluence 中采用 HTML 或 XML 转换 + AI 操作 + 差异更新的模式,实现高效文档编辑。
  • Confluence 的 XML 导出与导入方式被证实非常有效,优于直接发送编辑命令,尤其适合 AI 代理进行结构化修改。
  • 有团队通过自研 CLI 工具对接 Confluence、Jira、Zendesk 的 REST API,实现跨系统信息联动,例如自动识别 AIT-553 等编号并生成跨系统链接,显著提升 AI 代理的信息获取效率。
  • 使用 Claude Code 快速构建这些 CLI 工具和技能,仅需几天时间,且能有效嵌入公司内部规范和工作流知识。
  • 所有操作均基于用户个人账户登录,AI 代理继承用户权限,写操作需用户确认(Ask 模式),确保安全性。
  • 有团队尝试将 Markdown 通过 GitHub 工作流编辑后,再手动插入 Confluence 页面,但存在大页面更新时超时的问题。
  • 为解决大文档处理问题,部分开发者选择绕过官方 MCP 服务,直接使用 REST API 构建自定义 CLI 工具,提升稳定性和可控性。
  • 也有开发者构建了 gdoc2md 和 md2gdoc 等 CLI 工具,实现 Google Docs 与 Markdown 之间的双向转换,支持嵌入图片,提升协作效率。

维基百科因管理员账户大规模泄露而进入只读模式 (Wikipedia was in read-only mode following mass admin account compromise) #

https://www.wikimediastatus.net

该网页是维基媒体基金会(Wikimedia)的系统状态页面,用于实时展示其旗下服务(如 Wikipedia 等维基项目)的运行状况。

当前所有系统均处于“正常运行”状态,但部分服务性能略有下降。具体指标显示:

  • 每秒请求量达 12.5 万次,处于高位。
  • 用户报告的连接错误为每秒 0.05 次,极低。
  • 维基页面错误响应为每秒 2.3 次,处于可接受范围。
  • 页面响应时间平均为 0.28 秒,表现良好。
  • 每秒成功编辑次数为 12.2 次,说明编辑功能正常。

近期历史事件回顾:

  • 2026 年 3 月 3 日,曾出现编辑延迟问题,已修复并恢复正常。
  • 2 月 26 日及 25 日,出现访问性能下降问题,已解决。
  • 2 月 20 日,欧洲地区出现访问缓慢问题,已修复。

页面支持多种通知方式,包括邮件、Slack 和 Webhook,用户可订阅获取实时更新。同时提供 Atom 或 RSS 订阅,便于集成到其他系统中。

页面由 Atlassian Statuspage 提供支持,数据按日、周、月展示,包含多维度系统指标图表,帮助用户直观了解系统健康状况。


HN 热度 861 points | 评论 297 comments | 作者:greyface- | 9 hours ago #

https://news.ycombinator.com/item?id=47263323

  • 一名 WMF 安全工程师在生产环境中测试时,意外加载了来自 ruwiki 的两年期恶意用户脚本,导致全球 JS 代码被污染并迅速传播。
  • 该事件暴露了组织在安全流程和测试环境管理上的严重缺陷,责任不应完全归咎于个人工程师。
  • 该工程师的行为虽有失当,但更深层次的问题是组织未能建立足够的防护机制来防止此类事故。
  • 有人认为这是一次“职业生涯的致命打击”,但也有可能成为一次“职业生涯的学习机会”。
  • 在现实中,许多类似事件后工程师并未真正吸取教训,未来仍可能犯下类似错误。
  • 由于事件细节公开有限,且背景调查通常不关注此类技术失误,涉事人员的职业生涯可能不会受到实质性影响。
  • 有人指出,该事件的根源在于在生产环境进行未经充分控制的测试,违反了基本的运维准则。
  • 在大规模系统中,某些罕见的 bug 或竞态条件在高并发下会频繁出现,因此必须在可控条件下逐步发布并具备快速回滚能力。
  • 有人强调,即使在高流量系统中,也应通过功能开关、灰度发布和严密监控来控制变更的范围和影响。
  • 修复方案包括使用正则表达式检测并回滚受影响页面,或直接从备份恢复系统。
  • 该恶意脚本能长期潜伏,说明系统在代码审计和长期监控方面存在明显漏洞。
  • 有人引用《深渊上的火》中的情节,警示人们不要轻视“古老代码”的潜在危害,即使看似无害也可能引发灾难性后果。

Dario Amodei 称 OpenAI 关于军事合作的宣传“纯属谎言” (Dario Amodei calls OpenAI’s messaging around military deal ‘straight up lies’) #

https://techcrunch.com/2026/03/04/anthropic-ceo-dario-amodei-calls-openais-messaging-around-military-deal-straight-up-lies-report-says/

Anthropic CEO Dario Amodei 在内部备忘录中严厉批评 OpenAI 与美国国防部(DoD)的军事合作,称其宣传为“彻头彻尾的谎言”。Amodei 指出,OpenAI 接受该合同的主要动机是安抚员工,而 Anthropic 则出于防止技术滥用的考虑拒绝了类似条件。

此前,Anthropic 与国防部未能就技术使用权限达成一致。Anthropic 要求国防部承诺不将 AI 用于国内大规模监控或自主武器系统,但遭拒绝。随后,国防部转而与 OpenAI 签署协议,后者声称其合同已明确排除非法用途。

Amodei 认为 OpenAI 的说法具有误导性,尤其在“合法用途”这一条款上存在漏洞,因为法律可能随时间变化,当前非法的用途未来可能被允许。他担忧这种宣传会影响 OpenAI 内部员工的认知。

公众反应倾向支持 Anthropic。数据显示,OpenAI 的 ChatGPT 在宣布该合作后,应用卸载量激增 295%。与此同时,Anthropic 的 Claude 在 App Store 排名升至第二,Amodei 认为这反映出公众对 OpenAI 战略的不信任。

该事件凸显了 AI 公司在军事合作中对伦理与透明度的不同立场,也反映出公众对 AI 技术被用于军事目的的深切关注。


HN 热度 773 points | 评论 410 comments | 作者:SilverElfin | 1 day ago #

https://news.ycombinator.com/item?id=47255662

  • OpenAI 在与美国国防部的合作中使用“所有合法用途”这一条款,实际上为可能的违法行为提供了保护,其条件形同虚设。
  • OpenAI 声称会通过模型内置规则防止滥用,但这种说法缺乏可信度,如同承诺解决 AI 对齐问题却毫无进展。
  • “所有合法用途”本质上是自洽的逻辑陷阱,当政府行为本身被定义为合法时,任何行为都可被合理化,即使其本质是不道德或有害的。
  • 历史上多个威权政权均以“合法程序”为名实施大规模镇压与监控,如苏联的肃反、东德斯塔西、古巴革命法庭、委内瑞拉政治清洗等,证明“合法”不等于正义。
  • 将 AI 作为“黑箱”推卸责任是常见操作,一旦出事便以“无法解释”为由推卸,甚至成立调查小组来掩盖真相。
  • 当问题爆发时,责任将被推给 AI 系统,而实际操作者却不会承担后果,形成典型的“替罪羊”机制。
  • 用“法西斯”一词批评不认同的观点已成为一种泛化标签,但在此语境下,它被用来指代那些以法律为名实施压迫的威权行为,具有现实批判意义。
  • 有人指出,对 AI 生成内容的过度警惕与对“AI 生成”标签的滥用同样令人反感,这种标签化行为削弱了有效讨论。

法官下令政府开始退还逾 1300 亿美元关税 (Judge orders government to begin refunding more than $130B in tariffs) #

https://www.wsj.com/politics/policy/judge-orders-government-to-begin-refunding-more-than-130-billion-in-tariffs-fdc1e62c

根据《华尔街日报》的报道,一位联邦贸易法院法官于周三命令特朗普政府开始退还超过 1300 亿美元的关税,这些关税在上个月被最高法院判定为无效。此判决是在涉及一家过滤器公司的退款诉讼后作出的,法官理查德・伊顿在位于曼哈顿的国际贸易法院下达了书面命令,要求政府开始退款程序。他还安排了在周五举行的听证会,以便对退款进程进行更新。

此案件引发了超过 2000 起公司提起的诉讼,这些公司希望追讨因无效关税而支付的款项。这些事件标志着一个重要的法律里程碑,可能会对贸易政策和经济产生深远的影响。


HN 热度 756 points | 评论 575 comments | 作者:JumpCrisscross | 11 hours ago #

https://news.ycombinator.com/item?id=47261688

  • 特朗普政府的关税政策本质上并非为了增加财政收入,而是通过提高进口商品价格,将成本转嫁给消费者,从而实现财富从民众向企业的转移。
  • 关税政策的实际效果是让企业获得远超 1300 亿美元的利润,不仅覆盖了关税成本,还实现了持续的价格上涨和利润增长。
  • 该政策还打击了新兴竞争企业,使大型企业得以低价收购破产农场和农业用地,进一步巩固其市场垄断地位。
  • 关税被用作政治工具,为后续的减税政策提供合理性,尽管其经济逻辑从未成立。
  • 政策背后存在内幕交易,企业利用关税公告提前布局获利,形成多方共赢的局面。
  • 关税政策的主要目的并非经济利益,而是制造“强硬”形象,服务于政治叙事和选举动员,而非真正解决经济问题。
  • 特朗普政府的政策缺乏长期规划,更多是基于个人情绪和政治表演,而非理性经济策略。
  • 关税政策的真正作用是作为谈判筹码,通过制造压力迫使他国让步,而非实际征收大量税款。
  • 消费者承担了关税带来的全部成本,而企业并未真正“损失”任何资金,因此最终退款只是将本应属于民众的财富返还给企业。
  • 关税政策反映了“后真相政治”的特征,政策本身不重要,重要的是制造舆论和维持支持者的情绪认同。
  • 企业通过提高价格获取超额利润,而政府却将这笔钱退还给企业,这违背了公共利益,也未能解决财政赤字问题。
  • 关税政策的逻辑在于制造“外部威胁”叙事,以强化国内政治动员,而非基于实际经济效率或产业保护需求。

构建一个全新的 Flash 2026 (Building a new Flash) #

https://bill.newgrounds.com/news/post/1607118

这是一个由用户 Bill 在 Newgrounds 平台发布的项目更新博客,内容围绕他正在开发的一款名为“Flash 2026”的全新 2D 动画创作工具。

该工具基于 C# 构建,使用 Avalonia 和 SkiaSharp 技术栈,旨在打造一个功能完整的现代版 Flash 作者环境,支持 Windows、macOS 和 Linux 系统。项目并非概念验证,而是已实现多项核心功能。

核心功能包括:

  • 矢量绘图引擎:采用 DCEL(双重连通边列表)数据结构,支持 Flash 原生的五种绘画模式(正常、背后、填充、选择、内部),实现形状合并等高级操作。
  • 完整的时间轴系统:支持多层、关键帧、逐帧动画、洋葱皮、经典补间、运动补间、形状补间(含轮廓对应)及自定义缓动函数。
  • 符号系统:支持图形符号、影片剪辑、按钮符号和富文本符号,具备独立时间轴与实例变换能力。
  • 文件兼容性:可导入并编辑旧版 .fla / XFL 文件,是目前少数能真正读写 Flash 项目文件的开源工具。
  • 脚本系统:采用 Roslyn 编译器,提供作者时脚本(类似 JSFL)与运行时脚本(类似 ActionScript),并计划开发 ActionScript 到 C# 的转换器。
  • 其他功能:内置音效编辑器(基于 SkiaSharp 渲染波形)、自动保存、多文档标签页、场景管理、相机动画、滤镜效果(模糊、阴影、发光、斜面)、颜色与透明度控制、路径变形、对齐分布、撤销重做(支持 100 步)等。

项目已具备完整工作流,支持导出 SWF 文件。作者已启动 Patreon 以寻求支持,计划组建团队进一步完善功能。他承诺将持续在 Newgrounds 发布更新。


HN 热度 712 points | 评论 229 comments | 作者:TechPlasma | 1 day ago #

https://news.ycombinator.com/item?id=47253177

  • Flash 时代的创作环境是独一无二的,它让程序员和艺术家能无缝协作,通过 FLA 文件直接交换动画资源,实现高效整合与调整。
  • 尽管现代技术如 SVG + CSS + JS 能实现 Flash 的视觉效果,但缺乏相应的高效创作工具,导致制作流程复杂且不直观。
  • Flash 的核心优势在于跨平台一致的渲染表现和统一的开发环境,而现代 Web 技术虽然功能强大,但兼容性与一致性仍存在挑战。
  • Adobe 曾尝试将 Flash 过渡到基于 SVG 和 JS 的开源框架,如 Apache Royale(原 FlexJS),但未能形成主流生态。
  • 当前如 Rive 等新工具在动画创作和跨平台部署方面已接近 Flash 的能力,尤其在设计师与开发者协同方面有所突破。
  • 现代 Web 的音频和时间同步机制曾长期落后于 Flash,导致交互式多媒体应用体验不佳,影响了 Web 多媒体的发展进程。
  • Flash 的消亡并非技术问题,而是由于其在浏览器中的性能、安全与兼容性问题,以及缺乏现代化的创作工具生态。
  • 缺乏一个能同时满足艺术家与程序员的集成开发环境,是当前替代 Flash 的最大障碍,现有工具难以实现当年的协同效率。

Flock Cams 互动地图 (An interactive map of Flock Cams) #

https://deflock.org/map#map=5/37.125286/-96.284180

DeFlock 是一个基于 OpenStreetMap 社区众包数据的网页地图平台,旨在收集和展示自动车牌识别(ALPR)设备的位置信息。页面强调地图数据目前尚不完整,鼓励用户贡献新数据,补充缺失的 ALPR 设备位置。用户可通过提交数据、添加摄像头、悬挂标识、提供公共记录等方式参与。平台支持与城市议会、本地团体、GitHub 项目及捐赠渠道联动,推动社区协作。地图使用 Leaflet 技术渲染,底图来自 OpenStreetMap,版权归属其贡献者。使用该网站即表示同意其服务条款。


HN 热度 610 points | 评论 233 comments | 作者:anjel | 1 day ago #

https://news.ycombinator.com/item?id=47252049

  • 这个地图显示了大量遍布各地的车牌识别摄像头,让人感到恐惧,即使避开已知摄像头,仍可能被其他未被记录的摄像头监控。
  • 有人提出可以通过修改开放街道地图数据,创建绕开摄像头的导航路线,但这种方法无法避免未知摄像头的监控。
  • 有人开发了动态避开摄像头的在线导航工具,可在离线状态下使用。
  • 有人质疑 Flock 摄像头在特定刑事案件中被使用的说法,指出地图上并无相关区域的摄像头数据,且缺乏可靠新闻来源支持。
  • 有评论指出,Flock 的透明度报告并不可靠,执法部门使用其服务的情况常未被公开。
  • 一些摄像头由私人和企业拥有,警方在调查时会调取这些本地摄像头数据,但这些数据未被集中管理,无法大规模查询。
  • 有人担忧 Flock 系统可能被滥用,用于追踪前伴侣或政治异见者,认为系统存在被滥用的风险。
  • 有人认为,私人摄像头的使用是基于所有者授权,与政府集中监控不同,因此不应被过度担忧。
  • 有人指出,警方使用 Flock 系统进行执法时,有时会出现误判,例如错误地对无辜车辆进行逮捕,说明系统存在缺陷。
  • 有人认为,任何技术系统都可能存在错误,不能因为存在误判就完全否定其价值,应接受一定程度的失败。
  • 有人强调技术应服务于安全目标,若无法确保安全,就不应部署此类系统。
  • 有人认为,Flock 系统带来的风险远大于其收益,其管理应像核武器或民航安全一样严格,目前的监管远远不够。
  • 有人提醒,每辆警车几乎都配备了车牌识别设备,因此即使避开 Flock 摄像头,仍可能被警方扫描。

“LLM”中的“L”代表谎言 (The L in “LLM” Stands for Lying) #

https://acko.net/blog/the-l-in-llm-stands-for-lying/

文章标题为《The L in “LLM” Stands for Lying》,作者 Steven Wittens 在 2026 年 3 月 4 日发表,探讨了当前大语言模型(LLM)技术在软件开发中的实际应用与深层问题。

文章指出,尽管 AI 技术被过度炒作,但实际产出的软件质量并未显著提升,仍停留在“勉强可用”的水平。作者认为,这种技术的真正问题不在于“智能”或“效率”,而在于其本质是“伪造”——即通过模仿生成内容,而非真正创造。

作者将 LLM 的运作类比为“伪造”:无论是伪造一幅梵高风格的画作、一份假的法律文件,还是捏造的研究报告,只要其目的被当作真实产物使用,就构成了伪造。LLM 正是让人能快速生成“看起来像”自己或他人产出的内容,但这些内容缺乏真实性和原创性。

在软件开发领域,这种“伪造”表现为“ vibe-coding”——即开发者依赖 AI 生成代码,以快速构建看似完整、详尽的代码提交,实则缺乏深度思考与问题理解。这种行为不仅降低了代码质量,还破坏了开源社区的协作生态,导致维护者拒绝贡献、关闭漏洞奖励,甚至公开嘲讽。

作者强调,真正有价值的软件开发源于对用户需求、现实约束的深刻理解,而非对代码量或复杂度的盲目追求。那些仅靠 AI“加速”产出的工程师,往往忽视了代码背后的逻辑与可维护性,最终导致系统臃肿、成本高昂,甚至违背初衷。

文章最后指出,有经验的开发者仍能识别出 AI 生成代码中的“粗糙感”——如重复、过度复杂、不愿重构等。但即便资深工程师,也可能在依赖 AI 时犯下低级错误,因为其思维已陷入“自动巡航”状态,不再主动思考。

核心观点:LLM 的“L”不是“学习”或“语言”,而是“谎言”(Lying)。它允许人们伪造产出,但若将伪造品当作真实成果,就会损害技术、社区与用户信任。作者呼吁:不使用 AI 并非落后,而是一种清醒与自律。


HN 热度 605 points | 评论 421 comments | 作者:LorenDB | 21 hours ago #

https://news.ycombinator.com/item?id=47257394

  • 游戏玩家对 AI 生成的艺术资产有抵制情绪,但对 AI 生成代码并无异议,Steam 的调查问卷也未将代码列入 AI 内容范畴,表明 LLM 辅助编程已成不可逆趋势。
  • 代码的复用不仅无害,反而可能带来效率提升,LLM 帮助开发者节省重复劳动,是技术进步的体现。
  • 程序化生成在游戏领域已有成功先例,如《精英》《我的世界》《星露谷物语》等,证明该技术本身并非失败,关键在于使用方式。
  • 《我的世界》是全球最畅销的游戏,其核心机制依赖程序化生成,说明该技术具有巨大成功潜力。
  • 程序化生成在某些场景下(如地形、植被、关卡布局)已被广泛应用于主流 AAA 游戏,技术成熟且普及。
  • 尽管部分玩家对程序化生成的剧情或复杂叙事效果存疑,但已有如《矮人要塞》等作品在叙事生成方面表现不俗。
  • 一些游戏开发者尝试程序化生成内容但最终放弃,原因在于难以保证生成内容的质量与可玩性,手绘设计仍具优势。
  • 程序化生成更适合对多样性要求高而对质量要求相对较低的场景,而非替代精心设计的完整世界。
  • 与传统程序化生成不同,当前 LLM 生成的内容具有更高复杂度和创造性,不能简单类比为早期随机算法。
  • 程序化生成的挑战在于如何设置合理约束并验证生成内容的可玩性,而非技术本身不可行。
  • 顶级游戏如 From Software 作品和《塞尔达传说》系列的成功,源于精心设计的世界观与关卡,而非程序化生成。
  • LLM 未来可能实现类似《龙与地下城》的动态剧情生成和角色互动,极大提升游戏沉浸感,但需解决版权与伦理问题。

无权重新许可该项目 (No right to relicense this project) #

https://github.com/chardet/chardet/issues/327

该网页是 GitHub 上 chardet 项目的一个 issue 页面,标题为“No right to relicense this project”(无权重新许可该项目)。原作者 Mark Pilgrim 发起此问题,指出 chardet 在版本 7.0.0 中被重新许可为 MIT 许可证,这一行为违反了 LGPL 许可协议。

他强调,尽管维护者声称此次更新是“完全重写”,但代码仍大量基于原始 LGPL 许可的代码,不属于“洁净室实现”(clean room implementation),因此不能随意更改许可证。他要求将项目恢复为原始的 LGPL 许可证。

该 issue 引发广泛讨论。部分开发者支持原作者观点,认为修改许可证属于法律违规;也有观点认为,只要 API 兼容且实现方式独立,重新许可可能合法。但多数人认为,当前版本仍与原作高度相关,不具备完全独立性。

有用户建议使用 v7.0.0 之前的版本(如 v6.0.0)作为替代,因为这些版本仍保留 LGPL 许可。同时,有人提出应尝试真正的“洁净室重写”以解决法律争议。

该事件也引发对开源项目许可合规性的深层讨论,涉及版权、衍生作品与公平使用等法律问题。


HN 热度 465 points | 评论 301 comments | 作者:robin_reala | 16 hours ago #

https://news.ycombinator.com/item?id=47259177

  • 独立实现代码不违反版权法,即使开发者曾接触过原代码,只要未直接复制即可,法律并不强制要求“洁净室”开发环境。
  • AI 对 GPL 代码的自动化重写可能被用来规避开源许可证,这削弱了开源社区迫使企业回馈代码的法律手段。
  • 当前版权法尚未跟上技术发展,需重新审视法律以应对 AI 生成代码带来的挑战。
  • 通过 AI 进行逐文件重写或使用 LLM 生成中间表示再转回代码,可绕过 GPL 限制,且难以被检测,尤其在闭源项目中。
  • 代码接口本身不受版权保护,因此基于公开接口重写代码是合法的,这与是否使用 AI 无关。
  • 企业完全有权在不违反版权的前提下,重写并重新许可其贡献的代码,这并不违背原作者权利。
  • GPL 的核心是鼓励共享而非限制使用,不应因担心被规避而放弃共享精神。
  • 重写代码并私有化是常见做法,开源社区应关注如何促进协作而非过度担忧法律漏洞。
  • 技术进步将使新代码更多依赖重构与再利用,而非从零开始编写。
  • 人类应保持对社会和他人福祉的关注,不应仅追求个人效率或技术便利。
  • 开源精神应包含对他人和公共利益的关怀,不应因技术发展而放弃道德责任。
  • 保护开源生态需要集体努力,不应因技术便利而放弃对共享原则的坚持。
  • 未来的发展不应以牺牲开源精神为代价,应积极寻求技术与伦理的平衡。

使用 AI 辅助重写带来的许可证争议:chardet 项目 v7.0.0 版本的法律困境 (Relicensing with AI-Assisted Rewrite) #

https://tuananh.net/2026/03/05/relicensing-with-ai-assisted-rewrite/

本文讨论了开源项目 chardet 在发布 v7.0.0 版本时因使用 AI 辅助重写代码而引发的版权与许可证争议。该项目原基于 Mozilla 的 LGPL 许可证,长期面临企业用户使用上的法律风险。新版本通过 Claude Code 重写代码,并将许可证改为更宽松的 MIT,引发原作者 a2mark 的质疑。

核心争议在于:AI 重写是否构成“清洁室重写”(clean room rewrite)。传统做法要求两支团队协作,其中一支不得接触原始代码,而 AI 在训练过程中接触了 LGPL 代码,因此其输出可能被视为衍生作品,必须继续遵循 LGPL 许可。

美国最高法院于 2026 年 3 月 2 日拒绝审理关于 AI 生成内容版权的案件,维持了“人类作者”原则。这一裁决带来三重法律困境:一是若 AI 生成内容无法获得版权,那么新版本可能缺乏合法授权基础;二是若 AI 输出被视为衍生作品,则违反 LGPL;三是若代码被视为机器生成的公共领域作品,MIT 许可证将失去效力。

文章指出,若允许 AI 重写作为合法的许可证变更手段,将严重冲击 Copyleft 机制。开发者可能通过 AI 将 GPL 项目“改写”为 MIT 许可,绕过开源义务,从而破坏开源生态的公平性。

该事件成为 AI 与开源法律边界的关键测试案例,凸显当前法律体系在面对 AI 生成内容时的滞后与模糊。


HN 热度 374 points | 评论 361 comments | 作者:tuananh | 20 hours ago #

https://news.ycombinator.com/item?id=47257803

  • 使用 AI 进行代码重写时,即使在没有原始代码的情况下,AI 仍可能因训练数据中包含受版权保护的代码而产生侵权风险,因为 AI 无法真正“遗忘”或忽略这些训练数据的影响。
  • 维护者声称的“从零开始重写”说法站不住脚,因其长期参与原项目,且在重写过程中持续使用原项目的测试数据,缺乏真正的“隔离”。
  • 有研究提出基于内容的哈希掩码技术,通过随机丢弃部分训练数据来减少模型对原始内容的直接复制,从而降低侵权风险,但该方法在推理阶段仍可能生成与原始内容语义相似但形式不同的输出。
  • 当前 AI 生成内容的版权归属问题尚未明确,美国版权局坚持认为人类创作是获得版权的必要条件,AI 生成内容无法获得版权。
  • 企业用户使用 AI 服务时,若使用免费或基础版本,需自行承担版权侵权的法律责任,而付费用户可获得厂商的法律赔偿保障。
  • AI 生成内容是否构成对训练数据的侵权,以及是否属于“合理使用”,目前仍处于法律争议阶段,尚无明确判例支持。
  • 尽管 AI 可能生成与训练数据高度相似的内容,但目前尚无法律手段有效追责 AI 训练过程中的版权侵权行为。
  • 提示词本身是否受版权保护存在争议,尤其在复杂、详细的编程指令场景下,其可版权性需具体分析。
  • 将 AI 生成内容视为对已有作品的“重述”并不自动构成合理使用,尤其在涉及大量复制或直接再现的情况下,法律风险较高。

NVIDIA PersonaPlex 7B 在 Apple Silicon 上实现全双工语音到语音交互(Swift 实现) (Nvidia PersonaPlex 7B on Apple Silicon: Full-Duplex Speech-to-Speech in Swift) #

https://blog.ivan.digital/nvidia-personaplex-7b-on-apple-silicon-full-duplex-speech-to-speech-in-native-swift-with-mlx-0aa5276f2e23

本文介绍了一项基于 Apple Silicon 的全双工语音对话技术突破,使用 NVIDIA 的 PersonaPlex 7B 模型实现端到端的语音到语音实时交互,无需文本中间步骤。该系统在本地 Swift 环境下运行,完全基于 MLX 框架,无需 Python 或服务器支持,实现真正的实时语音对话。

项目从语音识别(ASR)起步,逐步扩展至语音合成(TTS)和多语言语音合成,最终整合为单一模型——PersonaPlex 7B,可直接处理音频输入并输出音频响应。与传统三步流程(语音转文字 → 大模型处理 → 文字转语音)相比,该模型跳过文本中间环节,保留语音中的语调、情感等信息,显著提升对话自然度与实时性。

PersonaPlex 7B 原始模型为 16.7 GB,经 4 位量化压缩后仅需约 5.3 GB,可在 M2 Max 芯片上以 68ms/步的速度运行,实时因子(RTF)为 0.87,即运行速度超过实时。系统采用 17 个并行音频流,每 80ms 生成一帧,基于 Mimi 音频编码器实现高效音频压缩与解码。

关键技术亮点包括:

  • 使用 Mimi 编码器,复用此前开发的成熟模块,确保稳定性和性能。
  • 采用 Depformer 架构,通过“逐步权重切换”机制生成音频代码本,实现低延迟与高效率。
  • 4 位量化技术使 Depformer 内存占用从 2.4 GB 降至 650 MB,性能几乎无损。

系统支持多种角色提示(system prompts),如客服、教师等,通过预设提示可显著提升响应质量,避免模型随意发散。例如,面对“能否保证明天发货”问题,加入提示后模型能精准回应,而非偏离主题讨论烹饪。

所有功能集成于统一 Swift 库中,支持端到端测试:输入语音 → 生成响应 → 再转回文本进行验证,确保输出语义准确。该库同时支持离线与流式处理,适用于本地部署的智能语音助手场景。

整体技术路径清晰,强调本地化、低延迟、高保真语音交互,是 Apple Silicon 平台实现强大语音智能的重要进展。


HN 热度 354 points | 评论 113 comments | 作者:ipotapov | 17 hours ago #

https://news.ycombinator.com/item?id=47258801

  • 全双工语音交互架构虽有潜力,但当前在准确性和训练难度上仍有不足,而传统的 ASR→LLM→TTS 流水线更易实现模块化与灵活性。
  • 将全双工语音代理与智能代理框架结合面临挑战,需解决“大脑”与“嘴巴”之间的协调问题,如何时切换、如何避免矛盾输出。
  • 可以设计异步机制,让快速响应模型提供即时反馈,同时后台运行更复杂的推理模型处理任务,模拟人类“思考中”的自然交互。
  • 使用轻量级模型进行快速响应并触发工具调用,可实现低延迟交互,同时保持功能扩展性。
  • 在 8GB M1 Air 设备上运行轻量化语音代理(如 Parakeet+Qwen 0.8B+Kokoro)是可行的,尤其在使用 INT8 或 4-bit 量化后内存占用更低。
  • 当前全双工方案多为单向语音处理演示,缺乏实时交互能力,需额外处理语音识别以获取用户输入。
  • 通过并行运行另一个小模型来判断何时调用工具,可有效增强全双工语音代理的功能,实现如控制灯光等实际应用。
  • 现有方案虽能实现低延迟回声和自然轮换,但缺乏与高级推理模型的深度集成路径,难以支撑复杂任务。
  • 语音代理的未来方向应是同时运行全双工响应与智能推理双路径,实现“边说边想”的类人交互体验。

Hacker News 精彩评论及翻译 #

Judge orders government to begin refunding more th… #

https://news.ycombinator.com/item?id=47261957

Cantor Fitzgerald, formerly led by Commerce Secretary Howard Lutnick and is now run by his son, went to various companies that were affected by tariffs and bought the rights to their potential tariff refunds for 20% of the value on the expectation that it’d be struck down by the courts.

Now they stand to make huge returns of 3 to 5x for being correct on that bet, while, of course, consumers get nothing. Now if this isn’t insider trading (by the literal Commerce Secretary), I don’t know what is.

satvikpendem

由前商务部长霍华德·卢特尼克领导,现由其子执掌的康拓斐森公司,曾找到多家受关税影响的企业,以潜在关税退款价值20%的价格购买了其追索权。他们打赌法院最终会裁定这些关税违宪,现在看来赌对了。因此,他们有望获得3到5倍的投资回报,而消费者却一无所获。如果这(由商务部长本人主导的)不算内幕交易,那我不知道什么才算了。


MacBook Neo #

https://news.ycombinator.com/item?id=47252471

List of differences from the MacBook Air:

  • Only supports 8 GB of unified memory

  • No MagSafe

  • One of the two USB-C ports is limited to USB 2.0 speeds of just 480 Mb/s

  • No Thunderbolt support means the Neo cannot drive either of Apple’s new Studio Displays. However, it can push a 4K display with 60Hz refresh rate over USB-C.

  • “Just” 16 hours of battery life, compared to the 18 hours quoted for the 13-inch MacBook Air

  • Display supports sRGB, but not P3 Wide Color

  • No True Tone

  • 1080p webcam doesn’t support Center Stage

  • No camera notch

  • Dual side-firing speakers, down from four speakers on the Air

  • Does not support Spatial Audio with dynamic head tracking on AirPods

  • Dual-mic system, down from a three-mic system on the Air

  • The 3.5 mm headphone jack does not have support for high-impedance headphones

  • No keyboard backlighting

  • Touch ID not included on base model

  • Trackpad does not support Force Touch

  • Supports Wi-Fi 6E, not 7

  • No fast charging

  • The Apple on the lid isn’t shiny

https://512pixels.net/2026/03/the-differences-between-the-macbook-neo-and-macbook-air/

theopsimist

与 MacBook Air 的差异列表:

  • 仅支持 8GB 统一内存
  • 无 MagSafe
  • 两个 USB-C 端口中有一个仅限 USB 2.0 速度,即 480 Mb/s
  • 不支持 Thunderbolt,意味着 Neo 无法驱动苹果新款的任何一款 Studio 显示器。不过,它可以通过 USB-C 输出 4K、60Hz 刷新率的显示画面。
  • 电池续航“仅为”16小时,而 13 英寸 MacBook Air 官方宣称的续航为 18 小时
  • 显示屏支持 sRGB 色域,但不支持 P3 广色域
  • 无原彩显示功能
  • 1080p 摄像头不支持人物居中功能
  • 无摄像头“刘海”设计
  • 双侧扬声器,而 Air 拥有四个扬声器
  • 不支持佩戴 AirPods 时的空间音频与动态头部追踪功能
  • 双麦克风系统,而 Air 为三麦克风系统
  • 3.5 mm 耳机接口不支持高阻抗耳机
  • 无键盘背光
  • 入门款未配备 Touch ID
  • 触控板不支持力度感应
  • 支持 Wi-Fi 6E,不支持 Wi-Fi 7
  • 不支持快速充电
  • 顶盖上的苹果标志并非亮面设计

BMW Group to deploy humanoid robots in production … #

https://news.ycombinator.com/item?id=47255205

Whenever I hear german companies mention digitalisation, I get reminded that they still use pen and pencil in production environments to log data, pass those sheets to secreteries who enter the data into legacy systems so data analysts can enter it into another system that then has an integration with SAP. Data from SAP then flows onwards to some buzzword filled Azure product that costs a few million a month from which someone downloads an xls file and uploads it to Tableau where they run some simple calculations. Someone else downloads it as an xls and manually writes (not copy pastes) the numbers into a power point presentation and makes graphs by drawing shapes. This is then presented at some bi-monthly meeting.

I wish I was making this stuff up.

Maxion

每当听到德国公司谈论数字化,我就会想起他们仍在生产环境中用笔和纸来记录数据。然后把这些表格交给秘书,由她们将数据输入到老旧的系统里,以便数据分析师再将数据输入到另一个系统,而这个系统又与SAP系统对接。数据再从SAP系统流转到一个满是热门词汇的Azure产品上,而这个产品每月要花费数百万。有人会从中下载一个xls文件,再上传到Tableau进行一些简单的计算。另一个人又把它下载成xls文件,然后手动(而不是复制粘贴)把数字写入PowerPoint演示文稿,再通过画图来制作图表。然后这些东西就在某个双月例会上被展示出来。我真希望这些是我编造的。


Dario Amodei calls OpenAI’s messaging around milit… #

https://news.ycombinator.com/item?id=47256372

When @sama announced within hours that OAI was replacing Anthropic with the “same conditions “, it was clear that either the DoW or OAI (or both) were fudging. DoW balked at Anthropic’s conditions so OAI’s agreement must have made the “conditions” basically unenforceable.

And sure enough, my reading of it left the impression the OAI conditions were basically “DoW won’t do anything which violates the rules DoW sets for itself.”

mrandish

当@sama宣布OAI将在几小时内以“相同的条件”取代Anthropic时,很明显,要么是DoW,要么是OAI(或两者都在)在糊弄。DoW拒绝了Anthropic的条件,所以OAI的协议必定让这些“条件”形同虚设。果然,我的理解是,OAI的条件基本上就是:“DoW不会做任何违反自己定下的规则的事。”


Wikipedia was in read-only mode following mass adm… #

https://news.ycombinator.com/item?id=47265243

See the public phab ticket: https://phabricator.wikimedia.org/T419143

In short, a Wikimedia Foundation account was doing some sort of test which involved loading a large number of user scripts. They decided to just start loading random user scripts, instead of creating some just for this test.

The user who ran this test is a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account, which has permissions to edit the global CSS and JS that runs on every page.

One of those random scripts was a 2 year old malicious script from ruwiki. This script injects itself in the global Javascript on every page, and then in the userscripts of any user that runs into it, so it started spreading and doing damage really fast. This triggered tons of alerts, until the decision was made to turn the Wiki read-only.

tux3

请参阅公共Phabricator工单:https://phabricator.wikimedia.org/T419143

简而言之,一个维基媒体基金会账户在进行某种涉及加载大量用户脚本的测试。他们决定直接开始加载随机用户脚本,而不是为此测试专门创建一些。运行此测试的用户是WMF的员工安全工程师,他们自然决定使用其高权限的维基媒体基金会员工账户进行此测试,该账户有权限编辑在每页运行的全局CSS和JS。其中一个随机脚本来自ruwiki的两年前恶意脚本。该脚本将自己注入到每页的全局Javascript中,然后注入到遇到它的任何用户的用户脚本中,因此它开始快速传播并造成损害。这触发了大量警报,直到决定将Wiki设为只读。


MacBook Neo #

https://news.ycombinator.com/item?id=47252664

You forgot an important difference: the macbook neo has the A18 Pro chip (2 performance cores + 4 efficiency cores) whereas the macbook air has the M5 chip (4 performance cores + 6 efficiency cores)

Also the A18 Pro chip has a 5-core GPU whereas the M5 chip has 8 or 10.

Personally, the only dealbreaker in the list you posted is the amount of RAM. macOS 15 uses ~5GB on startup without any app open. I’d be swapping all the time on 8GB of RAM.

MYEUHD

你忘记了一个重要的区别:MacBook Neo 配备的是 A18 Pro 芯片(2个性能核心 + 4个能效核心),而 MacBook Air 配备的是 M5 芯片(4个性能核心 + 6个能效核心)。

此外,A18 Pro 芯片拥有 5 核 GPU,而 M5 芯片则有 8 核或 10 核。

就我个人而言,你列出的清单里唯一让我无法接受的是内存容量。macOS 15 在启动时即使不打开任何应用程序也会占用大约 5GB 内存。用 8GB 内存的话,我估计会一直频繁地进行内存交换。


MacBook Neo #

https://news.ycombinator.com/item?id=47252716

macOS 15 uses ~5GB on startup without any app open

Sort of? Mac very aggressively caches things into RAM. It should be using all of your RAM on startup. That’s why they’ve changed the Activity Monitor to say “memory pressure” instead of something like “memory usage.”

I’m typing this on an 8 GB MacBook Air and it works just fine. I’ve got ChatGPT, VSCode, XCode, Blender, and PrusaSlicer minimized and I’m not feeling any lag. If I open any of them it’ll take half a second or so as they’re loaded from swap, but when they’re not in the foreground they’re not using up any memory.

post-it

macOS 15在没有任何应用打开的情况下启动时会占用约5GB内存?

算是吧?macOS会非常积极地缓存数据到RAM中。启动时理应会占用你所有的内存。这就是为什么他们把“活动监视器”改成了显示“内存压力”,而不是类似“内存使用量”这样的指标。

我现在就在一台8GB内存的MacBook Air上打这些字,用起来完全没问题。我已经将ChatGPT、VSCode、XCode、Blender和PrusaSlicer最小化,并且没有感到任何卡顿。如果我打开任何一个应用,它们会从交换空间中加载,大概需要半秒钟左右,但当它们不在前台时,就不会占用任何内存。


GPT-5.4 #

https://news.ycombinator.com/item?id=47267414

I find it quite funny how this blog post has a big “Ask ChatGPT” box at the bottom. So you might think you could ask a question about the contents of the blog post, so you type the text “summarise this blog post”. And it opens a new chat window with the link to the blog post followed by “summarise this blog post”. Only to be told “I can’t access external URLs directly, but if you can paste the relevant text or describe the content you’re interested in from the page, I can help you summarize it. Feel free to share!”

That’s hilarious. Does OpenAI even know this doesn’t work?

Philip-J-Fry

我觉得这篇博客文章底部那个“询问ChatGPT”的框真是相当好笑。你可能会想,可以就博客内容提问,于是你输入了“总结一下这篇博客文章”。然后它确实打开了一个新的聊天窗口,里面带着博客文章的链接和你的问题。结果却得到回复说:“我无法直接访问外部网址,但如果你能粘贴相关文本或描述页面中你感兴趣的内容,我可以帮你总结。请随时分享!” 这简直太搞笑了。OpenAI难道不知道这根本行不通吗?


Building a new Flash #

https://news.ycombinator.com/item?id=47254184

I made Flash Games back in the day. Here’s my old profile on Newgrounds: https://cableshaft.newgrounds.com/

One thing Flash had that nothing else has really seemed to replicate as well since, is an environment that both coders and artists could use. I’d collaborate with an artist, they’d make their animations within an FLA, send it to me, and then I’d copy+paste into the project file, and it’d just work. I could even tweak their animations if need be to remove a frame here or there to tighten the animations and make it feel more fluid, etc.

That being said, I’m not sure I could go back to it now. I’ve been working with Love2D lately, and I prefer that (especially for the version control). FLA version control was always me going ‘GameName-1.fla’, ‘GameName-2.fla’, or when I got a little smarter ‘GameName-Date.fla’. Eventually they let you split out the actionscript files into its own files, and that was better for version control, but you still had the binary mess of the FLA file.

But all these sprite-based game editors just can’t handle the crazy intricate animations that vector-based Flash games could handle. Porting one of my old games (Clock Legends) that had hundreds of frames of hand drawn animation for a boss that filled the screen would be ridiculously huge nowadays, but the FLA for that was like 23MB, I believe (I’ll need to hunt it down, I have it somewhere), and several MB of that were for the songs in the game.

Excited for this project though. It deserves to come back in some form.

cableshaft

我以前曾制作过Flash游戏。这是我在Newgrounds上的旧个人资料:https://cableshaft.newgrounds.com/

Flash有一点是后来其他东西似乎都未能很好复制的,那就是它提供了一个能让程序员和美术师都能使用的环境。我会与美术师合作,他们在FLA文件中制作动画,然后发给我,我再把它复制粘贴到项目文件里,就能直接运行。如果需要,我甚至可以修改他们的动画,比如删掉一两帧,让动画更紧凑、更流畅等等。

话虽如此,我不确定自己现在还能否回到Flash。我最近一直在用Love2D,我更喜欢那个(尤其是在版本控制方面)。FLA的版本控制总是让我把文件命名为“游戏名-1.fla”、“游戏名-2.fla”,或者稍微聪明点的时候会用“游戏名-日期.fla”。后来他们终于可以把动作脚本拆分成单独的文件,这对版本控制好多了,但FLA文件这个二进制文件依然是一团乱麻。

但是所有这些基于精灵的游戏编辑器都无法处理基于矢量的Flash游戏所能呈现的那种极其复杂的动画。把我以前的一个游戏《Clock Legends》移植过来,其中那个占满屏幕的boss有数百帧的手绘动画,现在光是这一点就会显得异常庞大,但我相信那个FLA文件只有23MB左右(我需要找找看,我 somewhere 有它),而且其中好几MB是游戏里的歌曲。

不过我还是很期待这个项目。它理应以某种形式回归。


The L in “LLM” Stands for Lying #

https://news.ycombinator.com/item?id=47259150

Video games stand out as one market where consumers have pushed back effectively

No, it’s simply untrue. Players only object against AI art assets. And only when they’re painfully obvious. No one cares about how the code is written.

If you actually read the words used in Steam AI survey you’ll know Steam has completely caved in for AI-gen code as well. It’s specifically worded like this:

content such as artwork, sound, narrative, localization, etc.

No ‘code’ or ‘programming.’

If game players are the most anti-AI group then it’s crystal clear that LLM coding is inevitable.

This stands in stark contrast to code, which generally doesn’t suffer from re-use at all, or may even benefit from it, if it’s infrastructure.

Yeah, exactly. And LLM help developers save time from writing the same thing that has be done by other developers for a thousand times. I don’t know how one can spins this as a bad thing.

Classic procedural generation is noteworthy here as a precedent, which gamers were already familiar with, because by and large it has failed to deliver.

Spore is well acclaimed. Minecraft is literally the most sold game ever. The fact one developer fumbled it doesn’t make the idea of procedural generation bad. This is a perfect example of that a tool isn’t inherently good or bad. It’s up to the tool’s wielder.

raincole

电子游戏是消费者能有效抵制的一个突出市场。 不,这话完全不属实。玩家只反对AI生成的艺术资源,而且只有在这些资源非常明显时才会反对。没有人关心代码是如何编写的。 如果你仔细阅读Steam AI调查中使用的措辞,你就会知道Steam在AI生成代码方面也已经完全让步了。其措辞具体如下:

诸如艺术品、声音、叙事、本地化等内容。 没有提及“代码”或“编程”。 如果游戏玩家是最反AI的群体,那么LLM编程的必然性就再清楚不过了。

这与代码形成鲜明对比,代码通常不会因重复使用而受到丝毫影响,如果是基础设施代码,甚至可能从中受益。 没错,正是如此。LLM帮助开发者省去了编写其他开发者已经重复过上千次的代码的时间。我真不明白怎么能把这件事说成是坏事。

经典程序化生成值得一提,它作为一个先例,游戏玩家早已熟知,因为它在很大程度上未能达到预期效果。 《Spore》广受好评,《Minecraft》也是有史以来最畅销的游戏。仅仅因为一个开发商搞砸了,并不意味着程序化生成的理念就是坏的。这完美地证明了工具本身并无好坏之分,关键在于使用者。


10% of Firefox crashes are caused by bitflips #

https://news.ycombinator.com/item?id=47258500

I’ve told this story before on HN, but my biz partner at ArenaNet, Mike O’Brien (creator of battle.net) wrote a system in Guild Wars circa 2004 that detected bitflips as part of our bug triage process, because we’d regularly get bug reports from game clients that made no sense.

Every frame (i.e. ~60FPS) Guild Wars would allocate random memory, run math-heavy computations, and compare the results with a table of known values. Around 1 out of 1000 computers would fail this test!

We’d save the test result to the registry and include the result in automated bug reports.

The common causes we discovered for the problem were:

  • overclocked CPU

  • bad memory wait-state configuration

  • underpowered power supply

  • overheating due to under-specced cooling fans or dusty intakes

These problems occurred because Guild Wars was rendering outdoor terrain, and so pushed a lot of polygons compared to many other 3d games of that era (which can clip extensively using binary-space partitioning, portals, etc. that don’t work so well for outdoor stuff). So the game caused computers to run hot.

Several years later I learned that Dell computers had larger-than-reasonable analog component problems because Dell sourced the absolute cheapest stuff for their computers; I expect that was also a cause.

And then a few more years on I learned about RowHammer attacks on memory, which was likely another cause – the math computations we used were designed to hit a memory row quite frequently.

Sometimes I’m amazed that computers even work at all!

Incidentally, my contribution to all this was to write code to launch the browser upon test-failure, and load up a web page telling players to clean out their dusty computer fan-intakes.

netcoyote

我以前在HN上讲过这个故事,但我在ArenaNet的商业伙伴Mike O’Brien(battle.net的缔造者)在2004年左右为《激战》写了一个系统,用来检测比特翻转,作为我们故障排查流程的一部分,因为我们经常会收到一些来自游戏客户端、完全无法理解的错误报告。

《激战》每一帧(即约60FPS)都会分配随机内存,运行大量密集型数学运算,然后将结果与一个已知值表进行比较。当时,大约每1000台电脑中就有1台会通过不了这个测试!我们会将测试结果保存到Windows注册表中,并把它包含在自动生成的错误报告里。

我们发现这个问题的常见原因有:

  • CPU超频
  • 内存等待状态配置糟糕
  • 电源功率不足
  • 由于散热风扇规格不足或进风口积灰导致的过热

这些问题的发生,是因为《激战》需要渲染户外地形,因此与当时许多其他的3D游戏相比,它会渲染多得多的多边形。(那些游戏可以通过二叉空间分割、 portals等技术进行大量裁剪,而这些技术对于户外场景效果不佳)。所以,我们的游戏会导致电脑运行过热。

几年后,我了解到戴尔电脑存在超出合理范围的模拟组件问题,因为戴尔为他们电脑采购了绝对最便宜的材料;我想这也应该是一个原因。

又过了几年,我了解到内存上的RowHammer攻击,这也很可能是另一个原因——我们当时使用的数学计算,在设计上会相当频繁地访问内存的某一行。

有时候,我真觉得电脑能正常工作就已经是个奇迹了!

顺便提一句,我对这一切的贡献,就是写了一段代码:在测试失败时,它会自动启动浏览器,并加载一个网页,告诉玩家去清理他们电脑风扇进风口上的灰尘。


Pentagon formally labels Anthropic supply-chain ri… #

https://news.ycombinator.com/item?id=47266669

Exported all my chats and deleted my ChatGPT account yesterday. The current administration not liking you is the strongest signal I could possibly have to go all in on a particular company.

oompydoompy74

昨天我导出了所有聊天记录并删除了ChatGPT账户。当届政府不喜欢你,这对我而言绝对是全力押注某家公司的最强信号。


MacBook Neo #

https://news.ycombinator.com/item?id=47247748

“Education customers can purchase it for $499.”

That is insane pricing for a brand new apple product. They will sell so many of these!

r0fl

教育客户可以以499美元的价格购买它。对于一款全新的苹果产品来说,这定价太离谱了。他们会卖出好多台!


MacBook Neo #

https://news.ycombinator.com/item?id=47247769

$599, 8 GB RAM, 256 GB, No Touch ID

$699, 8 GB RAM, 512 GB, Touch ID

Honestly pretty fantastic product and price.

This is clearly targeted towards education but I think I will happily replace by MacBook Air M1 with this :)

opjjf

599美元,8GB内存,256GB存储, Touch ID 699美元,8GB内存,512GB存储,支持Touch ID 坦白说,这款产品及其价格都相当出色。 这显然是面向教育市场的,但我想我会很乐意用它来替换我的 M1 MacBook Air :)


GPT-5.4 #

https://news.ycombinator.com/item?id=47266092

Wow insane improvements in targeting systems for military targets over children

elmean

军事目标瞄准系统的改进相较于针对儿童的系统,真是令人难以置信。


Judge orders government to begin refunding more th… #

https://news.ycombinator.com/item?id=47262902

Side topic, but this number puts into how crazy it was for trump[0] to go on tariff war against enemies and friends alike. All the propaganda and extortionist language about how all countries will pay up to USA.

Astronomical tariffs in some cases, trade wars and dramas, alienate all allies and from all of this they got only $130B ?

$7T of spending, $1.77T in deficit[1] and they planned to fix this hole with $100B?!

Masterminds!

…and now they need to refund it.

NB: also puts into perspective how numb I became about reading AI and AI related sums of money, and how crazy actually those numbers are.

[0] off course many knew that it’s crazy way before it happened.

[1] https://en.wikipedia.org/wiki/2025_United_States_federal_budget

trymas

顺便一提,这个数字也揭示了特朗普对敌对国家和盟友 alike 发起贸易战的疯狂程度。当时那些所有国家最终都会向美国付钱的宣传和敲诈言论。

在某些情况下征收了天价的关税,挑起了贸易战和各种闹剧,结果疏远了所有盟友,到头来只得到了1300亿美元?

7万亿美元的支出,1.77万亿美元的赤字[1],他们竟然计划用1000亿美元来填补这个窟窇?

大师啊!

……而现在他们又得把钱退回去。

注:这也让我明白,在阅读人工智能及相关领域的资金数额时,我已经变得多么麻木,以及那些数字实际上有多么离谱。 [0] 当然,在这一切发生之前,就有很多人知道这很疯狂。 [1] https://en.wikipedia.org/wiki/2025_United_States_federal_budget


US asked Ukraine for help fighting Iranian drones,… #

https://news.ycombinator.com/item?id=47266067

Did they say “thank you” and “please”?

akie

他们是说了“谢谢”和“请”吗?


Nobody gets promoted for simplicity #

https://news.ycombinator.com/item?id=47246979

AI coding tools are making this problem worse in a subtle way. When an agent can generate a “scalable event-driven architecture” in 5 minutes, the build cost of complexity drops to near zero. But the maintenance cost doesn’t.

So now you get Engineer B’s output even faster, with even more impressive-sounding abstractions, and the promotion packet writes itself in minutes too. Meanwhile the actual cost - debugging, onboarding, incident response at 3am - stays exactly the same or gets worse, because now nobody fully understands what was generated.

The real test for simplicity has always been: can the next person who touches this code understand it without asking you? AI-generated complexity fails that test spectacularly.

Niko901ch

AI编程工具正以某种微妙的方式让这个问题变得更糟。当一个AI代理能在5分钟内生成一个“可扩展的事件驱动架构”时,构建复杂性的成本已降至近零。但维护成本却并未改变。

因此,现在你不仅能更快地得到工程师B的产出,还能听到更令人印象深刻的抽象概念,晋升材料也能在几分钟内自动生成。然而,真正的成本——调试、新员工入职、凌晨三点的应急响应——却依然不变甚至更糟,因为现在没人能完全理解这些生成的内容。

对于简洁性的真正考验始终是:下一个接触这段代码的人能否在你无需解释的情况下看懂它?AI生成的复杂性在这一考验上可谓惨败。


Google Safe Browsing missed 84% of confirmed phish… #

https://news.ycombinator.com/item?id=47263387

Having spent some time in the anti-abuse and Trust & Safety space, I always take these vendor reports with a massive grain of salt. It’s a classic case of comparing apples to vendor-marketing oranges. A headline screaming about an 84% miss rate sounds like a systemic collapse until you look at the radically different constraint envelopes a global default like GSB and a specialized enterprise vendor operate under.

The biggest factor here is the false-positive cliff. Google Safe Browsing is the default safety net for billions of clients across Chrome, Safari, and Firefox. If GSB’s false-positive rate ticks up by even a fraction of a percent, they end up accidentally nuking legitimate small businesses, SaaS platforms, or municipal portals off the internet. Because of that massive blast radius, GSB fundamentally has to be deeply conservative. A boutique security vendor, on the other hand, can afford to be highly aggressive because an over-block in a corporate environment just results in a routine IT support ticket.

You also have to factor in the ephemeral nature of modern phishing infrastructure and basic selection bias. Threat actors heavily rely on automated DGAs and compromised hosts where the time-to-live for a payload is measured in hours, if not minutes. If a specialized vendor detects a zero-day phishing link at 10:00 AM, and GSB hasn’t confidently propagated a global block to billions of edge clients by 10:15 AM, the vendor scores it as a “miss.” Add in the fact that vendors naturally test against the specific subset of threats their proprietary engines are tuned to find, and that 84% number starts to make a lot more sense as a top-of-funnel marketing metric rather than a scientific baseline.

None of this is to say GSB is perfect right now. It has absolutely struggled to keep up with the recent explosion of automated, highly targeted spear-phishing and MFA-bypass proxy kits. But we should read this report for what it really is: a smart marketing push by a security vendor trying to sell a product, not a sign that the internet’s baseline immune system is totally broken.

epicprogrammer

鉴于我在反滥用和信任与安全领域的一些经验,我总是对这些供应商的报告抱有极大的怀疑。这就像经典地将苹果与供应商营销的橙子进行比较一样,根本不具可比性。一个宣称84%漏报率的耸人听闻的头条新闻,听起来像是系统崩溃了,但只要你看看谷歌安全浏览(GSB)这样的全球性默认服务与专业企业供应商所面临的根本不同的约束范围,你就会明白这并非如此。

这里最大的因素是误报悬崖。谷歌安全浏览是Chrome、Safari和Firefox上数十亿客户端的默认安全网。即使GSB的误报率只上升了很小的百分比,也可能导致其意外地将合法的小型企业、SaaS平台或市政门户网站从互联网上彻底清除。由于其巨大的“杀伤范围”,GSB从根本上就必须极其保守。另一方面,一家精品安全供应商则可以采取极具攻击性的策略,因为在企业环境中过度拦截只会导致一个常规的IT支持工单。

你还需要考虑到现代钓鱼基础设施的短暂性和基本的选择偏见。威胁行为者严重依赖自动化DGA(域名生成算法)和被攻陷的主机,在这些主机上,有效载荷的存活时间是以小时甚至分钟来计算的。如果一个专业供应商在上午10点发现了一个零日钓鱼链接,但GSB在上午10:15之前没有自信地将全球拦截传播给数十亿的边缘客户端,那么该供应商就会将其记为一次“未命中”。再加上一个事实是:供应商自然会针对其专有引擎专门用来查找的特定威胁子集进行测试,那么这84%的数字就更容易理解了——它是一个漏斗顶部的营销指标,而不是科学基准。

说这些并不是为了说GSB现在完美无缺。它确实难以跟上近期自动化、高度定向的鱼叉式网络钓鱼和绕过多因素认证的代理工具套件的激增。但我们应该看清这份报告的实质:它是一家安全供应商为了推销产品而进行的一场精明营销,而不是说互联网的“基础免疫系统”已经完全失灵了。