2026年06月15日 · 星期一 第 160044 期

The Hacker Daily

丙午年(马)五月初一

30 篇文章 · 4021 条评论 ·聚焦:LLM 诚信争议 · curl 漏洞响应 · PostgreSQL 性能
No.01 Your ePub Is fine
你的 ePub 没问题,但 Kobo 不这么认为
519 分 183 条评论 作者: sohkamyung
作者开发了一个 ePub 阅读应用,收到用户反馈称书籍在 Kobo 设备上无法正常显示。作者用专业工具验证了文件完全符合标准,却发现 Kobo 拒绝渲染——问题根源在于 Kobo 使用的 Adobe RMSDK(数字出版渲染引擎)仍基于 2013 年的 CSS 标准,既不兼容现代 CSS,也无法给出有意义的错误提示,只会直接跳过整本书。社区评论揭示了更深层的问题:Adobe 拥有数字出版领域约 80% 的市场份额,其软件以 DRM 为核心、阅读体验为辅;ePub 标准本身在 W3C 接手后变得臃肿混乱;epubcheck 只验证标准符合性,无法验证渲染器兼容性。评论者普遍对 Adobe 持批评态度,并推荐替代方案如 KoReader、 kepubify 转换工具,或转向 BOOX 等开源硬件平台。

评论精华

  • Adobe 数字出版方案始终以 DRM 为核心、阅读体验为次,导致 RMSDK 停滞在 2013 年 CSS 标准,Flash 的覆辙正在重演
  • ePub 标准在 W3C 接手后变得臃肿混乱,epubcheck 只检查标准符合性,无法检查渲染器兼容性
  • Adobe Digital Editions 和 RMSDK 已出售给 Wipro Engineering,Kobo 正在重写阅读器软件但仍基于 Adobe DRM
  • 解决思路包括:安装 KoReader 替代固件、用 kepubify 转换文件、转向 BOOX/PineNote 等开源硬件
  • 图书馆借阅电子书也因 Adobe DRM 不兼容 macOS 而形同虚设,开放格式的重要性被再次强调
No.02 Curl will not accept vulnerability reports during July 2026
curl 项目宣布2026年7月暂停接收漏洞报告
282 分 71 条评论 作者: secret-noun
curl 项目宣布2026年7月完全不接收和处理漏洞报告,称之为「curl summer of bliss」(盛夏长假)。维护者 Daniel Stenberg 表示过去四个月压力巨大,需要真正休息。暂停期间(7月1日至8月3日)HackerOne 提交表单和安全邮箱均关闭,GitHub 问题追踪保持开放,付费支持合同用户仍享服务。此外 8.22.0 版本发布推迟两周至9月2日。评论呈现两极:支持者认为维护者理应休息,curl 成熟稳定出严重漏洞概率低;批评者指出这暴露开源界对无偿维护者的系统性依赖,支持合同也被视为商业推广。另有担忧零日攻击风险,以及瑞典强制休假文化的讨论。

评论精华

  • FOSS 维护者长期超负荷、回报微薄,LLM 时代合并请求激增更添压力
  • curl 维护者需要休息,项目已足够成熟,严重漏洞概率接近零
  • 此举实为推广付费支持合同:客户仍获服务,普通报告需等一个月
  • 开源项目依赖少数无偿维护者是系统性风险,缺乏后备机制
  • 瑞典式强制休假文化:年假25-30天,休假时完全断开联系是常态
No.03 Even more batteries included with Emacs
Emacs 更多内置功能:那些少有人知却好用的特性
162 分 30 条评论 作者: signa11
作者分享 Emacs「随装即用」但鲜为人知的功能集第三弹,目标用户为有基础经验的 Emacs 使用者。介绍了四个功能:dictionary-tooltip-mode 可鼠标悬停查词(支持 Wiktionary);find-file 和 dired 支持通配符批量操作文件;ffap-menu 能扫描当前 buffer 所有文件路径和 URL 并提供补全交互;compare-windows 则轻量比对两个窗口的文本差异。规则:纯原版 Emacs 28.1+、无额外包、无陡峭学习曲线、不含常见功能(Flymake、outline-minor-mode 等)。评论焦点转向 Emacs 的稳定性争议——Doom/Spacemacs 用户抱怨更新易坏,有人则指出这是配置框架的问题而非 Emacs 本身;Dired 操作复杂被多人吐槽;另有用户转向 Neovim 认为其体验更稳定。

评论精华

  • Doom/Spacemacs 用户抱怨更新频繁出问题需手动修复,Emacs 稳定性引发争议
  • 纯原版 Emacs 用户反驳称十余年未遇到阻断性故障,问题多来自第三方配置框架
  • Dired 操作复杂难以上手,sunrise-commander 等双面板替代方案获推荐
  • 有用户从 Emacs 转向 Neovim(LazyVim),认为体验更稳定流畅
  • 编辑器的核心矛盾:Emacs 功能丰富但发现成本高,对新用户不够友好
No.04 Apple Foundation Models
Apple Foundation Models:Anthropic 发布官方 Swift 包让 Claude 接入苹果 AI 框架
54 分 10 条评论 作者: MehrdadKhnzd
Anthropic 发布了「Claude for Foundation Models」Swift 包,将 Claude 无缝接入苹果的 Foundation Models 框架。开发者只需使用苹果标准的「LanguageModelSession」API,即可驱动 Claude 云端模型,享受流式响应、结构化输出、工具调用等功能,且请求绕过苹果直连 Anthropic API,苹果无法看到提示词和回复。该包还支持服务器端工具(网页搜索、代码执行),并通过 fixedEffort 参数指定推理 effort 级别。开发者可自由切换本地模型与 Claude,按需分配任务。包内模型常量(如 .opus4_8、.sonnet4_6)携带各自能力声明,确保不会向模型发送其不支持的字段。目前处于 Beta 阶段,瞄准 iOS 27 测试版。社区评论聚焦苹果意图:有人认为是为苹果自有大模型铺路,让第三方模型成为默认选项;也有人指出,欧盟监管要求苹果必须开放竞争对手接入,这或许是真正驱动力。

评论精华

  • 苹果或借此让第三方 LLM 成为默认选项,为自有模型上线后占据优势地位铺路
  • 评论者将 AI 编程助手比作 90 年代「什么都承诺的中间人」,质疑层层封装的价值
  • 苹果可能要求模型提供商付费才能成为默认选项,类似 Google 搜索引擎的协议
  • 苹果必须提供此抽象层才能在欧盟合规运营,让竞争对手模型有接入途径
  • 已有开发者在该框架下使用本地模型,Claude 不过是又一个可选项
No.05 Show HN: Kage – Shadow any website to a single binary for offline viewing
Kage:把任意网站打包成单个二进制文件实现离线浏览
539 分 108 条评论 作者: tamnd
Kage 是一个用 Go 编写的开源工具,可以爬取整个网站(包括需要 JavaScript 渲染的页面),并将其打包成单个可执行二进制文件,实现离线浏览。项目作者使用 Chrome 无头模式抓取页面 DOM,转换为干净 HTML,支持本地 serve 或打包进二进制。评论区焦点包括:1)README 被多名用户指出是「AI 写作」,影响观感;2)安全性质疑——用 --no-sandbox 运行 Chrome 存在风险;3)与 HTTrack、SingleFile、Kiwix 等现有工具的功能对比;4)有用户建议增加单 HTML 导出功能和广告/弹窗拦截;5)作者表示计划开源 RSS 归档项目。总体评价积极,适用于航班、地下等网络不佳场景。

评论精华

  • 多名用户批评 README 是 AI 生成的「slop」,担心代码质量,建议作者改进文档
  • 安全担忧:用 --no-sandbox 运行 Chrome 无沙箱,作者尚未回应
  • 与 HTTrack、SingleFile、wget --mirror 等工具对比,Kage 优势在于支持 JavaScript 渲染
  • 离线使用场景:航班阅读、公司 Wiki 文档、Confluence 存档等
  • 有用户建议打包成单 HTML 而非需要服务器的二进制,提升可移植性
No.06 Bitsy
Bitsy:小游戏与互动叙事的轻量引擎
170 分 4 条评论 作者: tosh
Bitsy 是一款轻量级游戏引擎,专为创建小游戏、互动世界和故事而设计,界面简洁,适合制作像素风格的交互式叙事作品。社区反馈显示,其优势在于上手简单、能产出「既令人耳目一新又具复古感」的独特作品;但局限性也很明显——当涉及大量文本或复杂功能时,创作体验会变得 frustrating。与其定位相近的还有 Playdate 平台的 Pulp。

评论精华

  • 大多数 Bitsy 作品更接近互动诗/故事,而非传统游戏,寻找有游戏性的推荐
  • 去年夏天用 Bitsy 做游戏体验不错,但做大规模作品文本多是瓶颈
  • Bitsy 能做出可爱且兼具复古与现代感的游戏
  • 喜欢 Bitsy 的话可以试试 Playdate 的 Pulp
No.07 There Is(Ǝ) – Such That (∋)
一种可视化时钟编程语言:There Is(Ǝ) – Such That (∋)
15 分 4 条评论 作者: evakhoury
作者在 Recurse Center 的 6 周 batch 中开发了一门可视化编程语言,用于创作「不可能的日子」时钟。该语言基于向量、标量、修改向量、字形和栖息地等组件构建,编辑器采用无语设计(wordless),通过符号和手绘图标操作。技术栈包括 Svelte 5、TypeScript、Svelte Flow 和 p5.js,用户可在网页画布上拖拽节点、连接箭头,实时预览时钟效果,最终导出为独立 HTML 文件。时钟程序完全过程化生成,所有图形由 p5 原语构成,带有随机性。评论者普遍认为这类项目在 LLMs 辅助下开发效率大幅提升,不再需要一个月而只需几天;也有人澄清 Recurse Center 是一个让程序员聚在一起做个人项目的社群。

评论精华

  • 这类探索性项目以前需要一个月全心投入,现在借助 LLMs 几天就能完成
  • 本以为又是 AI 生成的伪概念文章,但实际内容相当有趣
  • 对 Recurse Center 的定位仍不清楚,从官网只了解到是某种带薪休假做项目的项目
  • Recurse Center 是让人们聚在一起花几周时间做编程爱好的社群
No.08 Dalus (YC W25) Is Hiring a Senior Software Engineer in Germany
Dalus(YC W25)招聘德国区高级前端工程师,主导复杂系统设计界面
1 分 0 条评论 作者: sebastianvoelkl
Dalus 是一家 YC W25 孵化的初创公司,正在打造面向系统工程师的 AI 驱动平台,客户涵盖火箭、卫星、国防系统和电动汽车等硬科技领域。该公司认为,当前的硬件设计行业仍被几十年前的笨重桌面工具束缚,开发节奏缓慢、协作困难、规模化受限。Dalus 的目标是「让原子设计像处理比特一样流畅」,推动下一次工业复兴。本次招聘的高级前端工程师将全面主导产品界面,直接与创始团队合作,从零塑造产品体验,核心挑战是把密集复杂的工程数据变得直观易用。要求具备前端开发经验,有工程类、开发者工具或技术类产品背景者优先。
No.09 Firewood Splitting Simulator
展示: 劈柴模拟器 - 屏幕上的解压小游戏
785 分 239 条评论 作者: memalign
这是一款来自 screen.toys 系列的网页互动小游戏,让用户在浏览器中模拟劈柴的乐趣。玩家通过点击原木来劈开柴火,劈好的木块会自动堆叠成圈。HN 社区的反应两极分化:一派认为它「令人上瘾」「画面精美」「音效满足」,像回到了 Miniclip 时代的经典小游戏;另一派则指出它过度理想化——真实劈柴的难点在于执行(如何精准命中、如何处理卡住的情况),而非决策木头该从哪里劈开,且木块劈开后几乎不会移动。此外评论还提到:专业人士用 Maul 而非 Axe、劈柴时站姿不对会把斧头嵌进小腿、木头有节疤会卡斧头等真实场景。页面据称由 AI(Claude)辅助开发,也有人注意到作者 Gavin Shapiro 还有一个位于北极的「假博物馆」。整体而言,这是一款披着「模拟器」外衣的休闲解压小游戏,而非严谨的物理模拟。

评论精华

  • 劈柴真实难点在执行(命中、卡住、反弹),而非决策砍哪,模拟器完全省略了这一点
  • 唤起了 Miniclip / Addicting Games 时代的经典小游戏回忆,令人满足且上瘾
  • 专业劈柴应用 Maul 而非 Axe,真实场景还有木头反弹、节疤卡斧、站姿不当伤腿等问题
  • 建议加入烧火功能完成「劈柴→堆放→燃烧」的完整闭环,或加入喝酒误伤自己的搞笑场景
  • 页面据称由 Claude 开发,有人好奇具体 prompt;技术层面相机自动旋转和高斯泼溅效果获关注
No.10 The Last Surviving Japanese Porsche 912 Police Car
日本仅存保时捷912警车
70 分 18 条评论 作者: zdw
1960年代,日本神奈川县引进了4辆定制版保时捷912作为高速巡逻警车,主要在第三京浜和东名高速公路上服役。这辆912从1968年运行至1973年,五年内行驶超过15.5万公里,甚至追捕过时速178公里的超速驾驶者。警车通常在服役期满后被报废,但这辆912因发动机故障退役后,被神奈川县警察学校保存展示长达26年,后因老化严重于1999年被卖给废品场,经六个月谈判才得以抢救修复,如今成为研究日本高速巡逻车历史的重要实物档案。

评论精华

  • 评论者对日本为何仅引进4辆保时捷912、是否集中在东京等问题深感好奇,并指出阿姆斯特丹、意大利、奥地利等地也有过警用保时捷或兰博基尼的案例
  • 有人注意到侧装式警笛设计,赞赏其中世纪风格的美学;同时好奇仪表盘上大型计时设备的用途
  • 部分评论指出经典保时捷价格已失控,沦为彰显身份的工具,失去了原有「车迷之车」的属性
  • 有评论提及保时捷品牌在1930-1940年代的历史争议,认为不应单纯美化该品牌
  • 作为车迷的评论者则从工程技术角度肯定保时捷的机械设计理念
No.11 21 years and counting of 'eight fallacies of distributed computing' (2025)
分布式计算八大谬误:21年后的回顾与反思
68 分 14 条评论 作者: teleforce
本文回顾了分布式计算领域的八大经典谬误,这些谬误最早由Sun Microsystems联合创始人Bill Joy和Tom Lyon于1994年前后提出,后由L. Peter Deutsch扩展至七条,最终由James Gosling补全为今日熟知的八条:网络可靠、延迟为零、带宽无限、网络安全、拓扑不变、单一管理员、传输零成本、网络同构。文章逐条阐释了这些「想当然」假设的现实反例——IP协议不保证交付、微波/卫星传输有时比光纤更快、家庭Wi-Fi瓶颈被忽视、流量分析可暴露隐私等。作者强调这些谬误是网络软件设计的底层常量,开发者需自问:数据是否真的送达?能否重发?量子计算更对公钥加密构成潜在威胁。评论指出文章多为维基百科内容重述,与Deutsch本人说法存在出入;也有观点将谬误与微服务风潮联系起来,感叹领域内技术与实际需求间的张力。

评论精华

  • 评论者补充「本地计算四大谬误」:CPU无限快、RAM无限大、CPU缓存不存在、缓存行不存在
  • 有评论指出文章内容多重复维基百科,与Deutsch本人说法存在矛盾
  • 部分评论将这些谬误与近年微服务风潮相联系,认为过度复杂化系统是典型反面案例
  • 有人认为盈利与高可用性是不同目标,不应混为一谈
  • 评论提到还有因果关系、事件顺序感知等未被列入的分布式系统谬误
No.12 Why does paper fold so well?
为什么纸张折叠效果如此好?
33 分 7 条评论 作者: zeristor
这是一期BBC播客,探讨纸张折叠背后的物理学原理。纸张能干净折叠的核心原因之一是「纤维结构」——纸张由木纤维压制而成,薄且有一定刚性,折叠时纤维在折痕处有序排列,因此折痕呈现为精确的直线。评论中有趣指出,纸张本质上是「被压碎的木头」,却能比木头本身更容易折叠。有读者对「纸张不拉伸所以能折叠」这一常见解释提出质疑:锡箔纸同样不拉伸,但折叠效果远不如纸张,说明该解释并不充分。播客内容轻松有趣,适合对折纸科学感兴趣的听众。

评论精华

  • 纸张折叠时折痕是直线——这是纸张最有趣的特征之一。
  • 有人指出「纸张不拉伸」的解释不够充分,锡箔纸同样不拉伸但折叠效果差得多。
  • 一位读者评论纸张本质是被压碎的木头,却比木头本身更易折叠,产生趣味反差。
  • 社区推荐了相关YouTube视频,对播客内容表示肯定。
  • 评论整体较短,讨论深度有限。
No.13 Rio de Janeiro's "homegrown" LLM appears to be a merge of an existing model
里约「自主研发」LLM 实为合并模型:隐瞒来源引争议
336 分 182 条评论 作者: unrvl22
里约热内卢市政府通过IT子公司IplanRio发布了「自主研发」的Rio-3.5-Open-397B模型,声称是基于Qwen3.5的微调。但调查发现,该模型实际上是Qwen与Nex-N2(同样是Qwen微调)按60/40权重逐层合并的结果,且未披露Nex-N2 Pro的存在。模型合并技术(Model Merging)通过线性组合不同模型的权重矩阵工作,在某些基准上确能提升性能,但这需要透明披露。社区争议焦点在于:里约市隐瞒了真实模型来源,夸大自主研发工作,涉及公众信任问题;合并操作本身技术可行且在开源社区常见,但用于骗取政府预算则构成欺诈。

评论精华

  • 模型合并本质是逐权重线性组合:60% Nex权重+40% Qwen权重生成新模型,技术上可行且可提升部分基准表现
  • 隐瞒来源才是核心问题:里约市谎称完成了微调工作,实际只是合并他人模型,涉嫌政府合同欺诈
  • 合并模型在开源社区很常见(如图像生成领域的checkpoint合并),但公开声称「自主研发」则涉及诚信问题
  • 技术层面看,Nex本身就是Qwen微调,合并Qwen和它的微调版能work是因为具有线性模式连接性
  • 有人指出这可能是一种「套取预算」操作:提出庞大LLM训练预算后,用廉价合并冒充以套取资金
No.14 Under-16s to be banned from social media, Starmer announces
英国宣布将禁止 16 岁以下未成年人使用社交媒体
14 分 2 条评论 作者: petepete
英国首相斯塔默在唐宁街演讲中宣布,政府将立法禁止 16 岁以下未成年人使用社交媒体,预计 2027 年春季生效。斯塔默称社交媒体「旨在让人上瘾」,正在损害儿童心理健康、为校园霸凌提供便利,「每一位家长都希望英国为孩子们提供更好的未来」。政府参考了澳大利亚的类似立法,还将对游戏服务和直播平台实施更严格监管。禁令将覆盖 Snapchat、TikTok、YouTube、Instagram、Facebook 和 X 等平台,但 WhatsApp、Signal 等通讯服务不在范围内。

评论精华

  • 禁令将覆盖主流社交平台,但明确排除了 WhatsApp、Signal 等端对端加密通讯服务。
  • Google 等公司试图将 YouTube 排除在社交媒体定义之外,但 YouTube 从一开始就被设计为社交平台,「You Tube」这个名字本身就说明问题。
  • 有评论指出监管机构在定义「社交媒体」与「通讯服务」时存在明显的边界模糊问题。
No.15 A short history of Cerro Torre, the most controversial mountain (2012)
塞罗·托雷峰:登山界最具争议的山峰史
33 分 13 条评论 作者: joebig
塞罗·托雷峰位于智利与阿根廷边境,高3128米,是登山界争议长达半个多世纪的话题。1959年,意大利登山者切萨雷·马埃斯特里声称完成首登,但其搭档托尼·埃格在下撤中遭遇雪崩丧生,首登真实性一直受质疑——后续循该路线攀爬者从未发现任何痕迹。直到1974年,卡西米罗·费拉里才完成首次无争议首登。1970年马埃斯特里重返此山,用重达150公斤的汽油动力钻机在岩壁上凿入螺栓,开辟「压缩机路线」,并拒绝攀爬最后的50米冰蘑菇(他认为那不是山体本身)。此举激怒了登山纯粹主义者,斯洛文尼亚登山者西尔沃·卡罗直言「那座山被从未来偷走了」。2012年1月,美国登山者海登·肯尼迪和杰森·克鲁克以纯自由攀登方式在13小时内完成首登,下撤途中拆除沿途125个螺栓——此举相当于数小时内将压缩机路线从山上抹去。他们抵达埃尔查尔滕村时被警方逮捕并没收102枚螺栓。争议的核心是:马埃斯特里当年安装螺栓固然不道德,但已建立并被广泛使用的路线,肯尼迪和克鲁克是否有权单方面将其拆除?有人以「应该用奴隶劳力建造的金字塔是否该被铲平」反驳,也有人认为他们的行为是利他之举。

评论精华

  • 山峰根本不该被打螺栓,装设后已成既定路线是否该保留,涉及特权思维。
  • 他们拆除的是已建立多年的公用路线,尽管可以争论它不该被装设,但他们无权单方面行动。
  • 自由攀登伦理的争论在于:若你主张无螺栓自由攀登,大可自行忽略螺栓,为何要强制拆除让别人也无法使用?
  • 海登·肯尼迪后来因伴侣在雪崩中遇难而自杀身亡(补充信息:这是作者写文章后才发生的悲剧)。
  • 「不留痕迹」原则在传统攀登中的体现是:先锋放好岩塞和岩楔后,收尾者会取回设备带走,不留任何东西在岩壁上。
No.16 Ask HN: What are you working on? (June 2026)
问 HN:你在做什么?(2026 年 6 月)
218 分 777 条评论 作者: david927
这是 Hacker News 每月一次的「你在做什么」社区帖,开发者们分享正在进行的 side projects。本月亮点项目包括:Kuberik(基于 Flux 的 Kubernetes 持续部署工具)、Artifacta(AI agent 工件的持久化存储)、Circuitscript(基于 Python 的电子电路描述语言);游戏类有 WWII 潜艇模拟 Silent Shark、城市建造游戏 Microlandia(售出近万份)、Sega 32X 模拟器支持等;工具类包括 ntfy(推送通知服务,已运营 4 年)、OneBusAway Cloud(公共交通云平台)、Django-logic(业务逻辑层);有趣的个人项目还有蘑菇觅食地图、Heathkit 示波器修复、个人基因组测序服务 banksia.bio。多名开发者表示 AI/agent 方向竞争激烈但仍有空间,也有老开发者感慨这类帖子是 HN 最具创意的部分。

评论精华

  • 城市建造游戏 Microlandia 销量近万份,远超预期;ntfy 推送通知服务运营 4 年仍在迭代,用户增长出乎意料
  • Django 业务逻辑层开发者对「vibe coding」趋势下的工具价值产生疑虑,引发关于 AI 辅助编程影响的讨论
  • 多人为 AI agent 工作流开发配套工具:工件存储、代码库分析、搜索等,隐私导向的个人基因组测序服务也现身
  • 游戏开发仍是热门方向,涵盖 TTRPG、象棋谜题、城市建造、SC2 回放分析等多种类型
  • 有开发者感慨 build 容易推广难,作品无人问津是常态;也有从业者表示艺术销售已超过自由职业收入
No.17 Show HN: Trace – Offline Mac meeting transcripts you can flag mid-call
展示:Trace——可在通话中随时标记的离线Mac会议转录工具
152 分 55 条评论 作者: AG342
Trace是一款纯本地运行的macOS会议转录工具,运行于Apple Silicon上,所有音频和transcript永不离开设备。核心功能是在任何视频会议(Zoom、Teams等)中按⌘K即时标记关键时刻,标记会以时间戳内嵌到Markdown transcript中供后续AI阅读。另有⌘?可查看近两分钟实时transcript。支持日历集成自动获取会议标题、说话人识别、快捷键完全可自定义。定价10美元一次性买断。评论关注点:有人已购买并反馈积极;德国用户因隐私法律只能录自己的声音;强烈要求非App Store分发选项;速度很快,使用Parakeet-TDT等本地模型;有人认为macOS原生功能迟早会取代它;也有关于两人同意录音州法律合规的疑问。

评论精华

  • 用户反馈积极,已购买,但希望能提供App Store之外的下载分发方式
  • 德语等多语言支持不足,内置macOS语音模型对非英语识别效果差
  • 转录速度出色,使用了Parakeet-TDT等轻量级本地模型
  • 有人指出macOS未来可能原生支持这类功能,质疑独立应用的生存空间
  • 定价10美元一次性买断,用户认为相比20美元/月的AI订阅更划算
No.18 Formal methods and the future of programming
形式化方法与编程的未来:Jane Street 的新赌注
250 分 91 条评论 作者: eatonphil
Jane Street 技术高管回顾了公司 25 年来对形式化方法的怀疑态度——高成本(如 seL4 微内核花费 25 人年验证 8700 行代码)使其对大多数软件「不值」,而 Jane Street 的类型系统已是轻量级形式化方法的成功案例。但 AI 代理编程(agentic coding)的出现改变了这一判断:AI 大幅降低了形式化方法的门槛,同时 AI 生成的代码质量不稳定、需要大量验证,正好由形式化方法弥补;类型系统等轻量级方法证明「全称量化保证」对 AI 编程有巨大价值,这让团队更看好完整的证明技术。Jane Street 宣布组建形式化方法团队,核心优势在于深度掌控 OCaml 语言(可量身定制证明集成),以及一支对这类工具有强烈需求的技术社区。

评论精华

  • 形式化方法本质是换一种方式写规格,关键在于规格本身是否贴合真实需求,而非证明过程本身
  • seL4 等经过形式化验证的系统仍存在 bug,证明技术不能消除所有缺陷,只缩小信任面
  • AI 辅助证明正在快速成熟,Claude/GPT 已能自动完成部分 Rocq/Coq 证明
  • 相比普通测试,证明的价值在于全称量化——不必逐条覆盖边界情况,漏洞无法被遗漏
  • 形式化方法行业采用率低,Spec-Driven Development 仍是少数派的「奢侈品」
No.19 Chaosnet (1981)
Chaosnet:MIT 1975 年设计的去中心化本地网络
81 分 9 条评论 作者: RGBCube
Chaosnet 是 MIT 人工智能实验室于 1975 年为 Lisp Machine 系统开发的本地网络,其名称「Chaos」源于网络中没有集中控制元件的设计理念。系统设计目标是简单性和高性能——通过高速传输介质和低开销的简单协议实现,而非复杂的算法。每个活跃用户拥有独立处理器和内存,通过 Chaosnet 访问共享文件系统、打印机、磁带机等资源。物理层采用有线电视用的 75 欧姆同轴电缆(ether),最大长度约 1 公里、节点约数十个。网络可通过网桥(bridge)互联多个 ether。Chaosnet 在设计上去除了与本地网络无关的功能(如低速率链路、长距离传输、多路径等),硬件采用载波侦听多路访问(CSMA)机制,软件协议则借鉴了以太网、TCP 和阿帕网的设计。数据包最大 4032 位数据加 48 位硬件头部,支持 CRC 校验。

评论精华

  • 有人指出 Chaosnet 的 CHAOS 协议对应 IP 协议号 0x10,trollbridge 补充说明该协议在 IPv6 下同样有效
  • 提醒不要将 Chaosnet 与 Chaos VPN(Chaos Computer Club 的前身 dn42 网络)混淆
  • 有评论者激动地提到可以用 Space Cadet Keyboard 配合 Chaosnet 使用
  • dang 提供了两篇延伸阅读:A Short History of Chaosnet (2018) 的相关讨论链接
No.20 Windows 11 users are tired of MS account requirements creeping into everything
Windows 11 用户厌倦微软账户强制绑定:本地账户选项去哪了?
285 分 188 条评论 作者: josephcsible
Windows 11 安装过程强制要求用户创建微软账户,这一问题持续困扰用户多年。尽管微软通过 Windows K2 计划试图重建用户信任,却始终回避这一核心抱怨。用户 2025Fishy 在 Reddit 发帖指出,微软不应在 OOBE(开箱设置)中移除本地账户选项,引发广泛共鸣。微软的辩解是:BitLocker 加密需将恢复密钥绑定微软账户,以防止用户永久丢失数据。但批评者指出,许多用户在遇到 BitLocker 恢复界面时才首次意识到密钥与账户绑定,且账户可能已被遗忘。更深层的问题是用户控制权——人们感觉自己被迫让出原本属于自己的选择权。有报道称微软内部也有员工认同批评,但公司至今未承诺恢复简明的本地账户选项。评论者建议微软至少应将在线账户设为默认选项而非唯一选项,让用户能无摩擦地选择本地账户。

评论精华

  • 大量用户表示已转向 Linux 或 Mac,指责微软强制账户要求是「黑暗模式」陷阱,侵犯用户控制权。
  • 有用户指出 BitLocker 与微软账户绑定实为双刃剑——一旦账户被封禁,本地数据也将无法访问,风险极高。
  • 部分用户澄清 macOS 的 Apple ID 并非强制要求,与 Windows 11 的强制微软账户有本质区别。
  • Windows 10 LTSC 获推荐——可在离线状态下安装,避开账户强制要求,且运行更流畅。
  • 有用户提到 Start11 等第三方工具可恢复 Windows 10 风格的开始菜单和任务栏,花费约 8 美元。
No.21 TorchCodec 0.14: HDR Video Decoding for CPU and CUDA, and Fast Wav Decoder
PyTorch TorchCodec 0.14 发布:支持 CPU/CUDA HDR 视频解码及高速 WAV 解码器
42 分 5 条评论 作者: scott_s
Meta 发布了 PyTorch 官方编解码库 TorchCodec 0.14 版本,带来两大核心更新:一是新增 HDR 视频的 CPU 和 CUDA 解码支持,大幅提升了视频处理效率;二是大幅优化了 WAV 音频文件的解码速度,性能提升显著。TorchCodec 由 PyTorch 团队开发,主打与 PyTorch 张量无缝衔接的解码体验。社区对此反应热烈但也有担忧:有用户指出该版本强制要求 torch>=2.11,而目前许多 NVIDIA 相关库仍停留在 2.10 或未包含 C++ method 的 2.11 alpha 版,兼容性是一大痛点。另有人关心其使用的 FFmpeg 版本是否过旧。核心争议在于 TorchCodec 与现有 GPU 加速视频方案(如 NVVideoCodec、VPI)的差异化优势——VPI 已支持 PyTorch 零拷贝接口,TorchCodec 的独特价值尚需明确。

评论精华

  • TorchCodec 性能表现出色,但强制要求 torch>=2.11,令依赖旧版 torch 的 NVIDIA 用户为难
  • 有用户关注 TorchCodec 使用的 FFmpeg 版本,质疑其是否仍存在版本过时问题
  • 核心维护者 Scott_S 主动披露身份并开放问答,体现团队对社区沟通的重视
  • WAV 解码速度提升同样受到好评,多位用户对音频处理效率优化表示欢迎
  • antixk 质疑 TorchCodec 相比 VPI 等现有方案的差异化优势,VPI 已提供 PyTorch 零拷贝接口
No.22 Caddy compatibility for zeroserve: 3x throughput and 70% lower latency
zeroserve 新增 Caddy 兼容模式:3 倍吞吐、70% 延迟降低
178 分 52 条评论 作者: losfair
zeroserve 是一个高性能 HTTPS 服务器,核心创新在于用户态运行 eBPF 脚本(而非内核态)。最新版本支持「Caddy 兼容模式」——接收 Caddyfile 后,先 JIT 编译为 eBPF 再编译为原生 x86_64/ARM64 机器码,在 io_uring 事件循环中执行,号称比原生 Caddy 提升 3 倍吞吐、降低 70% 延迟。用户还可以通过 eBPF 插件扩展,比如用官方示例 `io.su3.aws-sigv4.c` 为 S3 兼容存储桶的请求添加 AWS SigV4 签名认证。社区争议集中在:缺失 ACME 自动签发(被多位评论者视为 dealbreaker)、io_uring 近期安全漏洞担忧、JIT 编译带来的攻击面、以及「eBPF 用户态运行」是否背离 eBPF 设计初衷等问题。

评论精华

  • 缺少 ACME 自动签发功能,多位评论者认为这是核心缺失,是项目实用性的主要障碍
  • eBPF 用户态运行遭质疑——评论者指出 eBPF 的设计初衷即是内核态执行,用户态方案是否徒劳
  • io_uring 安全顾虑:评论者提及近期 io_uring 安全公告,建议谨慎暴露此类服务
  • 性能优势被指场景有限——多数后端本身慢于代理,真正瓶颈在 TLS 握手高频场景
  • JIT 编译攻击面引发担忧,有评论者类比其他广泛使用的 JIT 运行时(Spring Boot、Lua、PHP)进行反驳
No.23 The only scalable delete in Postgres is DROP TABLE
PostgreSQL 唯一可扩展的删除方式是 DROP TABLE
161 分 58 条评论 作者: hollylawly
文章指出 PostgreSQL 中大规模数据删除的最佳实践是 DROP TABLE 或 TRUNCATE,而非 DELETE。作者解释了 DELETE 的工作机制:由于 MVCC 架构,DELETE 并不真正释放物理空间,而是产生「死元组」(dead tuples),由后续 vacuum 清理。这导致大量写放大和复制开销,且 index 中的死行仍需读者处理。相比之下,DROP TABLE 只扫描缓冲区描述符(每 8KB 页面对应 64 字节头信息,约 1/128 缓存大小),直接删除文件,几乎无死元组开销。文章建议通过分区表(如按日期)将大规模 DELETE 转化为偶尔的 DROP TABLE 操作,并给出了临时表 + TRUNCATE 的具体手术步骤。评论中有争议认为文章过于绝对,小规模删除或 CRUD 场景下经过调优的 autovacuum 配合 DELETE 同样可用;分区方案也非万能,需视业务写入模式而定。

评论精华

  • MySQL/MariaDB 同样存在 DELETE 写放大问题,但程度较轻,有可调低的隔离级别选项
  • 文章标题过于绝对;有评论指出经良好调优的 autovacuum 在 TB 级数据下也能良好运行
  • 分区是更优雅的解决方案:按月分区每月初 DROP 一个分区,避免大规模 DELETE
  • 小规模删除场景下 DELETE 反而比 TRUNCATE 更快,需根据实际数据量选择策略
  • DROP TABLE trick 受限于外键、触发器和并发写入,需使用触发器镜像方案或原子 RENAME 换表
No.24 Perlisisms (1982)
佩里斯语录:编程之道(1982)
110 分 56 条评论 作者: tosh
本文收录了首位图灵奖得主 Alan Perlis 于 1982 年发表的约百条编程箴言,涵盖语言设计、数据结构、复杂度管理、代码风格、系统构建等主题。Perlis 认为数据结构应延迟绑定、简单性是复杂性的结果而非前置条件;强调模块化与对称性以降低复杂度;警示程序最终会变得「洛可可化」并最终崩塌,优化会阻碍进化;指出编程语言的真正价值在于改变思维方式。这些洞察在四十年后仍具启发意义,尤其关于语言设计哲学和代码组织的洞见对当代开发者有重要参考价值。

评论精华

  • 「影响编程思维的编程语言才值得学」是最高赞金句,引发对现代语言的讨论
  • LLM编程代理时代重新解读#27:理解程序后应让别人(AI)来写
  • #31「简单性不先于复杂性」被多人引用为最喜欢的语录
  • #8低级别语言定义引发讨论:与当代语言设计的对比
  • 部分评论认为某些语录表面有趣实则经不起推敲
No.25 Show HN: Discover Wikipedia articles popular on Hacker News
展示: 发现Hacker News热门维基百科文章
100 分 25 条评论 作者: octopus143
Orange Crumbs是一个每周邮件订阅服务,汇总在Hacker News上引发讨论的热门维基百科文章,帮助用户发现那些在技术社区引发深度讨论的知识性内容。评论者普遍认为这个产品执行出色、界面清新,适合知识探索。类似项目包括wikitok和quack.sdan.io,也有用户提到mostdiscussed.com提供类似功能。评论建议可增加按点赞数或评论数排序的功能,以及加入「研究论文」和「邮件列表」等分类模式。此外,有用户指出HN的BigQuery免费数据集可提供更丰富的数据挖掘可能。

评论精华

  • 类似项目参考:wikitok、quack.sdan.io、mostdiscussed.com等滚动维基百科或HN数据聚合工具
  • 可利用HN的BigQuery免费数据集挖掘更丰富的内容,详见HN讨论帖
  • 建议增加排序功能(按 upvotes 或评论数)及探索「研究论文」「邮件列表」等分类
  • Wikipedia可靠性引发争议:有用户列举篡改案例(如Assassin's Creed黑人武士事件),也有用户反驳称个别案例不代表整体
  • 评论者认为产品设计出色,Claude/Codez等工具可快速实现此类精美界面
No.26 Write for One Person
写给一个人看
196 分 64 条评论 作者: evakhoury
这篇来自 wizardzines.com(Julia)的文章阐述了一个写作原则:永远假设你的读者只有一个人。这个看似反直觉的建议实际上能帮助你摆脱「试图让所有人满意」的陷阱,找到自己真正的声音。评论者 simonw 补充了一个变体:「写给三年前的自己」,即假设你在向过去的自己解释一件事,同样能产生高质量的技术写作。Vonnegut 的名言被引用来说明这个道理:如果你「打开窗户对全世界做爱」,你的故事会得肺炎。围绕这个原则,评论延伸出多个话题:有人认为这本质上是 UX 设计中的「人物画像」(persona)方法论;有人提醒过度 niche(即目标读者太狭窄)反而会让产品失去受众;还有开发者分享用这个原则做产品后用户虽少但评价极高的经历。LLM 提出的「低调一点」建议被普遍批评为让内容变得平庸无趣。

评论精华

  • 核心写作原则:为一个人写作能摆脱取悦所有人的陷阱,「写给三年前的自己」是有效的变体(simonw)。
  • Vonnegut 的隐喻:面向所有人写作就像「打开窗户对世界做爱」,内容会得肺炎(PyWoody)。
  • C.S. Lewis 观点:为特定的孩子讲故事比面向抽象的「儿童」群体更好,能创造真实共鸣。
  • 产品开发同样适用:为一个用户打造往往比服务所有人更成功,但过度 niche 也会成为问题(ergocoder)。
  • LLM 写作建议普遍糟糕——它们倾向于消除个性让内容变得平庸,压制了真正的表达力(mediaman)。
No.27 Segmented type appreciation corner (2018)
分段显示字体在线模拟工具
71 分 16 条评论 作者: unexpectedVCR
这是一篇介绍分段显示(segment display)字体的网站的文章。该网站提供7段、16段等多种经典分段显示的在线模拟工具,用户可以输入任意字符并实时预览显示效果,支持自定义控制每个段的亮灭。网站还展示了不同地区的分段显示方案,包括西班牙火车和柏林地铁等实际应用案例。评论指出该网站不仅能显示数字和拉丁字母,还支持显示任意自定义字符。有硬件开发者表示正在用此类工具设计习惯追踪设备的屏幕。也有评论提到柏林地铁的分段显示与文中「German」样式存在细节差异,如后者有正确的降部设计。

评论精华

  • 面试常用7段显示问题来测试前端开发者的CSS定位和JS计时器能力,但此类LeetCode式题目饱受批评
  • 柏林地铁的实际分段显示与文章描述的「German」样式不同,具备正确的降部设计
  • 硬件开发者利用分段显示制作习惯追踪器,Sensor Watch项目也从Casio F-91W显示屏获得灵感
  • 16段显示被认为非常通用,输入「3.141」会显示5个字符而非4个,存在交互细节问题
  • 有评论者将7段显示用于炸弹拆除电影场景的想象,增添趣味性
No.28 Prove you're human by winning a claw machine
展示: 用抓娃娃机证明你是人类
62 分 44 条评论 作者: speckx
一款新型「验证码」要求用户操控爪机抓取毛绒玩具来证明自己不是机器人。评论普遍认为创意有趣,但实用性存疑。多名用户指出:目标永远在前层、爪机会「倾斜」方向错误等物理瑕疵;AI 可轻易破解——有用户称 Codex + Browser Use 已成功通关,Claude Opus 4.8 也能一击必杀。社区指出,这种游戏化验证本质上与 Google 图片选框无异,强化学习已能让 AI 像击败 Stockfish 一样轻松攻克此类游戏。部分评论认可其娱乐价值,认为只要作为「入口游戏」而非身份认证就无可厚非。也有人吐槽:真正好的验证是让用户直接放弃,而不是强迫他们玩无聊的小游戏。整体来看,社区对游戏化 CAPTCHA 的前景持怀疑态度,认为成本与安全之间的军备竞赛注定失败。

评论精华

  • AI 可轻松破解:Codex、Claude Opus 均能一击通关,游戏化验证形同虚设
  • 目标位置固定在前层且居中,物理机制失真,AI 仅凭视觉即可判断
  • 社区质疑游戏化 CAPTCHA 方向:强化学习已能攻克所有游戏形验证
  • 趣味性强但实用性不足,用户体验优于传统图片验证码
  • 部分观点认为只要作为「入口游戏」而非真实认证,创意本身值得肯定
No.29 How to earn a billion dollars
如何赚到十亿美元
610 分 1608 条评论 作者: kingstoned
Paul Graham 回应 AOC「不可能赚到十亿美元」的言论,用数学计算证明其可行性:他假设初始投资 200 万美元、维持 93% 月增长率,算出约 6 年可获 10 亿美元。核心论点是:超高财富来自创建高增长企业,用户喜爱推动指数级增长,而非传统工资积累。Graham 认为「赚」的定义取决于是否创造真实价值——若创业成功且用户愿意付费,即为正当所得。然而评论争议激烈:批评者指出其忽略了初始资本的阶级特权、例子(Facebook/Airbnb)的道德瑕疵、以及超高增长往往伴随不正当竞争手段;还有人区分「赚取」与「获取」——没人真正靠工作赚得十亿,更多是通过所有权变现。

评论精华

  • Graham 用「93% 月增长率」计算反驳 AOC,被批前提不现实——普通人无法凭空拿出 200 万美元初始资本
  • 评论者普遍认为「earn」的含义才是核心分歧:努力程度、运气成分、社会结构各自应占多少权重
  • Facebook、Airbnb 等 Graham 引用的成功案例被多人质疑其道德性,认为这些公司崛起过程中存在剥削
  • 有人指出亿万富翁财富大多是纸面价值,实质是对生产资料分配权的掌控,而非实际消费能力
  • 不少评论者认为 Graham 刻意回避了「财富积累必然伴随道德妥协」这一核心批评,论证流于数学游戏
No.30 I indexed 669 GB of my GoPro videos using my M1 Max computer and local ML models
我用M1 Max和本地模型索引了669GB的GoPro视频
364 分 88 条评论 作者: iliashad
作者分享了如何用M1 Max电脑对669GB的GoPro视频进行本地AI索引。项目采用帧分析pipeline将视频分割为1秒或1fps的场景片段,使用Qwen25-VL等多模态模型进行视觉理解和动作识别,通过RAG系统结合向量数据库与SQL数据库实现语义搜索。用户可用自然语言询问视频内容,系统会调用Ollama本地模型理解请求并检索相关片段。此外作者还尝试生成类似Spotify年度回顾的视频。作者已开源代码并提供桌面应用。社区讨论聚焦于M1 Max的统一内存架构优势(400GB/s带宽)、与DaVinci Resolve 21内置AI功能的对比、以及隐私导向的本地模型趋势。

评论精华

  • M1 Max统一内存架构让全部RAM可用作显存,AI加速器性能远超Windows ARM设备可比肩11代i9单核
  • DaVinci Resolve 21 Studio版内置AI IntelliSearch功能,可本地处理但暂不支持人脸标注
  • 有用户质疑示例视频缺乏亮点,作者解释狗叫视频是专门筛选含狗叫声音的场景片段
  • 社区热议本地LLM替代方案如Qwen25-VL,VLM虽能理解动作但担心性能开销过大
  • 律师因GoPro视频证据输掉案件引热议,有人认为这反映隐私与监控的边界问题