🔥 Hacker News 热榜 Top 30

2026-05-25 16:01:03 北京时间

1. Jira Is Turing-Complete
Jira 是图灵完备的
126 分 42 条评论 作者: vinhnx
作者通过在 Atlassian Jira 的自动化功能中构造一台 Minsky 双计数器寄存器机,给出了 Jira 图灵完备的严格归约证明。具体映射方式是:用 Epic 的状态编码当前指令,用关联工单的数量充当寄存器,「INC」与「DEC」对应工单的创建与删除,条件分支由 JQL 条件规则实现。文章演示了一个最小可运行实例:用一个 Epic、五个关联工单和每条指令对应的一条自动化规则,完成 2+3=5 的加法运算,并在真实 atlassian.net 实例上记录了五次状态跃迁的执行轨迹。作者还利用「Convert Issue Type」把 DEC+INC 合并为单步操作,把 Fibonacci 机压缩到三个状态、三种工单类型,结果序列出现在 Task 计数中;由于 Jira Cloud 有 10 层链式触发深度上限,需要人工再触发 Epic 继续推进,但归约依然成立。结论是:复杂的 Jira 自动化之所以像程序,是因为它字面意义上就是程序。

💬 评论精华

  • 有人指出所有工作流编排引擎本质上都是图灵完备的,这并不稀奇
  • 多位用户吐槽 Jira 加载慢、布局抖动、配置混乱,团队常被少数管理员把规则搞得一团糟
  • 讨论 Jira 替代品:OpenProject、YouTrack、Phabricator/Phorge,以及简单团队改用 Trello 就够
  • Atlassian 自带 AI 功能 Rovo 评价不佳,更多人选择把 API 接给 Claude 自动处理工单
  • 有人调侃这解释了为何 Jira 操作的停机问题无法判定,也有人吐槽 10 人到 11 人之间的授权价格陡增
2. Didgeridoo playing as alternative treatment for obstructive sleep apnea(2006)
迪吉里杜管演奏作为阻塞性睡眠呼吸暂停的替代疗法(2006)
78 分 20 条评论 作者: kelseyfrog
这是一篇 2006 年发表于《英国医学杂志》(BMJ) 的随机对照试验研究,探讨澳大利亚原住民传统乐器「迪吉里杜管」(didgeridoo) 演奏对中度阻塞性睡眠呼吸暂停综合征 (OSA) 患者的治疗效果。研究通过中央电话服务进行随机化分配,对招募医师和迪吉里杜管教师双盲设计。结果显示,规律练习该乐器能显著改善患者的睡眠质量、减少日间嗜睡,并降低呼吸暂停-低通气指数。关键机制被认为是吹奏过程中训练了上呼吸道肌肉,特别是「循环呼吸」(circular breathing) 技巧对软腭和咽部肌肉的强化作用。评论区有读者讨论该研究缺乏安慰剂对照组的局限性,也有人指出类似的舌部和咽喉肌肉训练 (如吸气肌训练 IMT) 可能达到同样效果而不扰民。一名读者亲述十年练习迪吉里杜管预防睡眠呼吸暂停复发的经验。

💬 评论精华

  • 质疑研究设计:未设安慰剂对照组,难以排除心理效应
  • 关键机制可能是循环呼吸而非乐器本身,但缺乏其他乐器的对比研究
  • 有读者亲身实践十年,认为可有效预防睡眠呼吸暂停复发
  • 推荐替代方案:舌咽肌训练或吸气肌训练 (IMT),效果类似且不扰邻
  • 调侃迪吉里杜管声音扰民,引发关于邻居噪音的玩笑互动
3. Show HN: Audiomass – a free, open-source multitrack audio editor for the web
展示: Audiomass — 免费开源的网页多轨音频编辑器
331 分 68 条评论 作者: pantelisk
作者发布了 Audiomass 的多轨编辑模式,这是一款完全运行在浏览器中的免费开源音频编辑器,整体仅 98KB JS 加 10KB CSS,体积极为精简。项目在视觉与交互上致敬经典的 Cool Edit Pro 与 Audacity,但带来更现代、平静且直观的 UX,原生支持 FLAC 等格式,被不少用户视为「终于不用再忍受 Audacity」的替代品。代码风格也颇为复古,采用安全闭包、函数赋值、顺序 var 声明等「老派」写法,让一些开发者感到怀旧。社区讨论焦点集中在功能边界:目前不支持 MIDI 与 VST 插件,也缺乏 stem bundle(如 Suno、stemsplitter 输出)的导入;有用户希望加入云端协作与「分支签出」式的多人协作工作流,作者回应会谨慎评估,避免破坏体积与性能。已有用户成功加载 1 小时以上播客甚至 12 小时有声书,整体反馈以正面为主。

💬 评论精华

  • 作者强调坚持精简体积,对加新功能持谨慎态度
  • 多人希望支持 MIDI、VST 与 stem 导入,目前均不支持
  • UX 被赞类似早期 Cool Edit Pro,比 Audacity 更直观舒适
  • 有用户期待云端协作与「签出/分支」式多人工作流,被推荐 BandLab、opendaw 等替代
  • 代码风格老派(闭包、var),引发开发者怀旧共鸣
4. I love my Bluetooth keyboard
我爱我的蓝牙键盘
53 分 31 条评论 作者: evakhoury
作者去中国旅行十天没带电脑,只带手机加一个蓝牙键盘,结果意外地爱上了这种组合。他总结了三大好处:一是用键盘给朋友发消息体验远胜虚拟键盘,可快速打字并使用复制粘贴;二是用键盘在手机备忘录里写作接近「打字机体验」,因为手机屏幕离手太远反而难以分心,娱乐内容在小屏上也不够吸引人,但又保留了文字处理器的编辑便利;三是开启 iOS 的「完整键盘访问」后,可用快捷键导航手机,「Cmd+Space」搜索成了他最常用的命令,弥补了手机端缺少 Alt+Tab 的遗憾。作者承认这种方式也让他在聊天中更啰嗦,并注意到手机上写出的段落明显更短,可能因小屏让空白页看起来不那么吓人。他用的是 Logitech Pop 键盘,但并不强推具体型号。

💬 评论精华

  • 多人推荐 Logitech K380/K480,可在手机、平板、Mac 间三向切换
  • 有人指出标题真意是「手机虚拟键盘太烂才被迫外挂实体键盘」
  • 推荐可折叠款如 iClever BK05S、ProtoArc XK01、微软 Universal Foldable
  • Android 用户提到可直接插 USB 键盘,配合 Termux 写代码、跑 vim 和 ffmpeg
  • 怀念触屏前用实体键盘长聊的时代,如今没人愿意打长文本了
5. DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost
DeepSeek Reasonix:面向 DeepSeek 的原生编码 Agent,主打高缓存命中与低成本
537 分 225 条评论 作者: Alifatisk
Reasonix 是一个第三方开源编码 Agent(非 DeepSeek 官方),专为 DeepSeek 模型设计,核心卖点是利用 DeepSeek 的「字节稳定前缀缓存」(byte-stable prefix cache)实现 90%+ 的缓存命中率,长会话输入 token 成本可降至原来的 1/5。其设计采用「append-only」事件循环,不做重排序或基于标记的上下文压缩,以最大化前缀复用;同时内置「工具调用修复」(schema-aware repair)来纠正模型输出的 JSON 错误。在 Claude Code 限额收紧、各家前沿模型涨价的背景下,作者意在为 DeepSeek V4 用户提供 C/Codex 之外的廉价替代。但社区争议明显:网页本身被批评由 AI 生成、动画导致布局抖动、字体配色出错;不少人质疑其相对 OpenCode、Pi Agent 等成熟 harness 没有实质差异,且 DeepSeek 官方编码 harness 据称即将发布,第三方工具的存在意义存疑。

💬 评论精华

  • 页面顶部打字动画导致内容反复上下抖动,UX 体验糟糕,多人吐槽
  • Claude 近期收紧 IDE/-p 用法和涨价,推动用户寻找 DeepSeek 等廉价替代
  • 质疑:Claude Code 直接换 DeepSeek API 也能达到 99% 缓存命中,新 harness 价值有限
  • JS/npm 实现被诟病,希望出 Rust/Go 单二进制版本,且 npx 存在供应链攻击风险
  • DeepSeek 官方编码 Agent 据传即将推出,做第三方 harness 可能很快被淘汰
6. Migrating from Go to Rust
从 Go 迁移到 Rust
240 分 226 条评论 作者: jabits
作者是 Rust 咨询顾问,坦言对 Go 设计有偏见,但试图客观对比两者。文章聚焦后端服务场景:Go 和 Rust 都是编译型、静态类型、单二进制部署语言,工具链都很完善,差别在于编译器提供的保障强度。Go 依赖约定、`go vet`、`-race` 等工具和运行时检测来维持正确性,而 Rust 把空值处理(`Option`)、错误传播(`Result`)、数据竞争(`Send`/`Sync`)、资源生命周期等都编码进类型系统。例如共享可变 `HashMap` 跨线程在 Go 中能编译通过、生产环境炸掉,在 Rust 中直接是类型错误,必须用 `Arc>` 或 channel。作者承认 Go 在大多数后端工作负载下「足够快」,迁移动因主要是冗长的错误处理、`nil` 段错误、长期缺失泛型以及类型系统薄弱(连 `Set` 都没有,要用 `map[T]struct{}` 模拟)。文中引用 InfluxDB 3.0 重写案例佐证「无畏并发」的价值,并讨论何时该坚持用 Go、何时迁移划算,以及增量迁移策略。

💬 评论精华

  • tptacek 认为该文身兼迁移指南与 Rust 鼓吹两职定位混乱,选择本质就是要不要托管运行时。
  • 多人指出文风有明显 LLM 痕迹,「genuine」「worth being precise about」等措辞频繁出现。
  • amusingimpala75 抱怨 Rust 包管理散乱,stdlib 太薄,依赖 crates.io 易受供应链攻击。
  • 多位评论者表示 Agentic 编码时代 Rust 反而占优:强类型 + 详细编译错误让 LLM 改 → 编译 → 改循环更可靠。
  • 反方观点:Rust 编译慢、build.rs 任意代码风险高,Go 在 Web 后端依然是更务实的选择。
7. White Rabbit – sub-nanosecond synchronization for large distributed systems
White Rabbit:面向大型分布式系统的亚纳秒级同步技术
81 分 21 条评论 作者: michaelsbradley
White Rabbit 是源自 CERN 的开源同步技术,为大型分布式系统提供亚纳秒级精度和皮秒级精确度的时间同步,同时支持确定性、可靠的数据传输。它本质上是在 PTP(精确时间协议)和 SyncE(同步以太网)基础上增加额外智能:通过相位锁定环路测量主时钟与本地时钟的相位差,并对光纤温度变化引起的长度变化进行主动补偿,从而在节点间典型距离 10 公里、最多数千节点的规模下实现千兆以太网级可靠数据传输。该技术完全开放硬件、固件和软件,已有多家厂商商业化生产相关设备。CERN 实验室测试显示,在 50 公里光纤上主从客户端的相位锁定抖动约为 10 皮秒;最新的 eRTM 板卡在 100Hz 至 20MHz 区间集成抖动低于 100 飞秒,是目前已知最精密的 WR 节点。文章同时发布了多个 FPGA 与硬件工程师招聘信息,用于推进 WR 交换机 v4 等下一代项目。

💬 评论精华

  • 有评论指出 GitLab Wiki 是更易上手的入门资料,特别是「Synchronization」页面
  • 10 公里对应约 33 光微秒,亚纳秒同步必然依赖巧妙机制(相位锁定+双向时间传递补偿光速延迟)
  • 对于同步而言光速延迟与其他延迟无法区分,只要可测量就能补偿,因此精度可超越光程时间
  • 实验室实测 50 公里光纤上抖动约 10 皮秒,且能主动补偿温度引起的光纤伸缩
  • 有人开玩笑说亚纳秒精度足以体现引力时间膨胀:山顶相对海平面每 2-3 小时多一个时钟周期
8. Bug 1950764: Work Around Crash on Intel Raptor Lake CPU
Firefox 修复 Intel Raptor Lake CPU 崩溃 Bug
78 分 21 条评论 作者: luu
这是 Mozilla Firefox 的一个补丁(Bug 1950764),用于绕过 Intel Raptor Lake CPU 上的硬件缺陷导致的崩溃。问题出在 Huffman 编码相关代码中,LLVM 编译器生成了「movb %ch, [mem]」这类使用高 8 位寄存器别名(h 寄存器,即 bits 8..15)的存储指令,在受影响的 Raptor Lake CPU 上会触发错误。修复方法是改写源码,把两个 dist 字节合并为单个 2 字节存储,避免这种指令模式。社区指出同样的问题在 Oodle 压缩库(同样是 Huffman 编码场景)中也被独立发现,背景文章见 fgiesen 博客。讨论焦点在于:这种在每个软件里手工绕过硬件 bug 的做法不可持续,正确的解法应该是 Intel 出微码更新或 LLVM 层面规避;而 Intel 此前在 Raptor Lake 电压不稳问题上的处理态度也让用户信任度下降,有人将其与当年的「Pentium FDIV bug」相提并论。

💬 评论精华

  • 希望 Intel 通过微码或编译器修复,而非每个软件单独绕过
  • 同类问题已在 Oodle 压缩库(Huffman 编码)中被独立发现
  • errata 详情:避免「movb %ch, [mem]」高字节寄存器存储指令
  • 有人质疑 Intel 验证流程,对比当年 Pentium FDIV bug
  • h 寄存器切片编译器很少用,因此该 bug 长期未被发现
9. A fundamental principle of aeronautical engineering has been overturned
航空工程基本原理被颠覆:微观粗糙表面反能减阻
149 分 73 条评论 作者: littlexsparkee
日本东北大学流体科学研究所的Aiko Yakino副教授团队首次证明,在物体表面施加肉眼无法分辨的「分布式微观粗糙度」(DMR),可将气动阻力降低多达43.6%。这颠覆了80多年来「表面越光滑阻力越小」的航空工程基本原理。该原理源自1940年谷一郎的研究,但他在1989年自己重新解读数据时已暗示粗糙未必只促进湍流转捩。团队采用1米磁悬浮天平系统(1m-MSBS)让模型在风洞中无接触悬浮,避免支撑杆干扰气流,精确测量了雷诺数0.35×10⁶到3.6×10⁶范围的阻力。DMR涂层高度仅为边界层厚度的1%,机理与高尔夫球凹坑及鲨鱼皮微沟槽完全相反——后者通过制造湍流减小压差阻力,而DMR延迟层流到湍流的转捩,直接抑制壁面摩擦本身。大涡模拟(LES)确认主要因素是摩擦阻力降低而非分离抑制。该技术随机分布、不依赖气流方向,无需运动部件或电力,若应用于飞机有望显著降低运营成本和碳排放。

💬 评论精华

  • 有人指出高尔夫球凹坑早已说明光滑未必最优,但文章明确DMR与凹坑机理相反
  • 帆船和水翼运动员熟知1000-1500目砂纸打磨的水下表面摩擦最低、层流最佳
  • 怀疑论者表示要等真实飞机的燃油效率实测数据,类似「革命性」设计常常无下文
  • 若仅靠喷砂即可施加,理论上可低成本改装现有机队,但航空认证流程繁琐昂贵
  • 有人提到汉莎Aeroshark等鲨鱼皮薄膜已商用,宣称可降低约4%油耗
10. C constructs that still don't work in C++
那些在 C++ 里仍然行不通的 C 写法(以及一些已经变了的)
49 分 33 条评论 作者: jalospinoso
作者在 2019 年那篇「C 在 C++ 里行不通的写法」基础上,结合 C++20 与 C23 的更新做了重新梳理。核心观点是:C++ 从来不是 C 的超集,讨论兼容性时必须明确语言版本(C17、C23、C++17、C++20、C++23)。C++20 引入了「指派初始化」,但只允许按声明顺序、直接非静态成员,不支持数组下标、嵌套指派或与位置参数混用,因此并非 C99 的等价物。C23 则把 「void f()」改为等同于「void f(void)」,向 C++ 靠拢,但旧 C 代码可能因此在 C23 下编译失败。关于「malloc」与对象生命周期,C++20 为「隐式生命周期类型」打了补丁,「std::malloc」配 「static_cast」对聚合类型不再是反例,但仍不会调用构造函数,对「std::string」之类类型依然是未定义行为,应使用「placement new」或「make_unique」。「const_cast」可以编译并不等于行为有定义,向真正的 const 对象写入仍是 UB。文章强调:写跨语言代码时,要问清谁拥有存储、何时开始生命周期、如何初始化、谁负责析构、失败如何处理。

💬 评论精华

  • 有评论认为指派初始化自 C99 起就有,C 在这块比 C++ 表达力强得多。
  • 「restrict」在 C++ 里水土不服:推荐用 string_view/span,难以承载 restrict 语义。
  • 作者本人现身说法:写此文是因频繁看到 C 老手转 C++ 时反复踩这些坑。
  • 有人吐槽 C++ 设计与演进流程本身有问题,过度委员会化导致兼容碎片。
  • 补充遗漏点:C 的「_Atomic(T)」与 C++ 的「std::atomic」不互通,柔性数组成员也是 C++ 的设计缺口。
11. I spent 50 hours drawing a line graph
我花了 50 小时手绘一张折线图
514 分 91 条评论 作者: dougdude3339
艺术家 Doug MacDowell 分享了用尺子、铅笔、墨水和字模套件手工绘制数据可视化的过程,软件 20 分钟能搞定的事,他花了 50 多小时。文章以一张关于咖啡机电脑的折线图为例,详细介绍了所需工具:光面 Bristol 纸、丁字尺、三角板、圆形模板、Micron 针管笔、字模套件等。绘制流程从打网格开始,用铅笔标点后借助圆形模板控制线宽,再用直边工具连接圆的外缘形成折线,最后上墨、擦除铅笔痕迹。作者推荐了 Tufte、杜波依斯、Brinton 等人的经典手绘数据可视化书目,认为手绘不仅是技艺,更是艺术。他坦言这是一种「软件 20 分钟、人工一周」的反效率实践,但慢工出细活,过程本身就是收获。配图被 Hackaday 评价为「像 1970 年代大学课本里走出来的」。

💬 评论精华

  • 有人吐槽字模拼写的字距「kerning」糟糕,作者本人也认可这一批评
  • 评论调侃这是「最 HN 的帖子」:用 50 小时干软件 20 分钟的活,完美讽刺
  • 多人怀念学生时代的工程制图课,认为手工绘图能学到自动化掩盖的细节
  • 有人警告:正式数据可视化里再小的瑕疵也会误导读者,这种做法只适合玩票
  • 网友补充推荐 Calvin Schmid 的《图形展示手册》和 1889 年巴黎统计图集等资源
12. Constraint Decay: The Fragility of LLM Agents in Back End Code Generation
约束衰减:LLM 智能体在后端代码生成中的脆弱性
227 分 122 条评论 作者: wek
论文系统评估了 LLM 智能体在多文件后端代码生成中处理结构性约束的能力。研究固定统一的 API 契约,覆盖 8 个 Web 框架共 100 项任务,结合端到端行为测试与静态校验进行双重评估。核心发现是「约束衰减」现象:当架构模式、数据库、ORM 等结构性要求逐步累积,智能体性能显著下滑,强配置从基线到完整规约平均掉 30 分断言通过率,弱配置接近归零。框架敏感性分析显示,智能体在 Flask 这类显式简洁框架表现尚可,但在 FastAPI、Django 等约定重的框架中明显劣化。错误分析指出数据层缺陷(查询组合错误、ORM 运行时违规)是首要根因。结论是:同时满足功能性与结构性需求仍是编码智能体的核心未解难题,意味着智能体适合快速原型而非生产级后端。

💬 评论精华

  • 有人称用裸 SQLite 比 Drizzle ORM 更顺手,印证数据层是重灾区
  • 质疑测评用 GPT-5.2 而非专为编码优化的 GPT-5.2-codex,结论可能偏低
  • 认为这其实就是「上下文腐烂」的另一种说法,并非全新现象
  • 实践派建议先规划、引用架构文档并以代码库内典范文件作示例,效果优于 markdown 规则
  • 悲观派认为这再次说明 LLM 不会真正思考,人类必须留在回路中评估优雅性与可维护性
13. Microsoft open-sources “the earliest DOS source code discovered to date”
微软开源「迄今发现最早的 DOS 源码」
464 分 164 条评论 作者: DamnInteresting
微软再次公开 MS-DOS 早期源码,这次回溯到品牌诞生之前,发布了 86-DOS 1.00 内核源码、PC-DOS 1.00 内核多个开发快照,以及 CHKDSK 等经典工具的代码。由 Stacey Haffner 与 Scott Hanselman 撰文宣布。文章简述了 DOS 的来龙去脉:程序员 Tim Paterson 最初为 Seattle Computer Products 的 Intel 8086 套件写出 86-DOS(前身为 QDOS,意为「快速且简陋的操作系统」);微软为了给开发中的 IBM PC 5150 提供操作系统,先授权 86-DOS 并聘用 Paterson 继续开发,随后买断全部权利。微软将其授权给 IBM 称作 PC-DOS,自留对外销售权,对外版本即 MS-DOS。八九十年代 IBM PC 兼容机泛滥,使 MS-DOS 成为绝大多数人实际使用的版本。值得一提的是,这批源码因年代久远从未数字化保存,团队不得不从纸质打印件 OCR 还原。

💬 评论精华

  • 源码从未数字化,靠 OCR 纸质打印件还原,commit 显示「49 年前」
  • 怀念那个写几千行汇编就能开公司的年代,但也有人指出 DOS 是买来的
  • IBM 原本想要 CP/M,却因 Digital Research 拒签 NDA 让微软上位,成计算史转折
  • 有人已在 DOSBox 跑通 DOS 1.0,仍丝般顺滑;期待微软再放出早期 Windows 源码
  • 讨论纸质印刷比数字存储更耐久,以及未来「数字考古学」这一新兴领域的兴起
14. Memory has grown to nearly two-thirds of AI chip component costs
内存成本已占AI芯片元件成本近三分之二
373 分 386 条评论 作者: intelkishan
Epoch AI 对英伟达、AMD、谷歌、亚马逊设计的 AI 芯片进行成本拆解,将单芯片成本分为四类:内存(HBM)、逻辑芯片、先进封装(CoWoS)和辅助元件,再乘以季度产量估算总支出占比。从 2024 年 Q1 到 2025 年 Q4,内存份额从 52% 飙升至 63%,封装从 19% 降至 15%,辅助元件从 15% 降至 9%,逻辑芯片稳定在 13-14%。AI 芯片元件总支出从 2024 年约 220 亿美元增至 2025 年约 520 亿美元,其中 HBM 单项就贡献了约 200 亿美元的增量。这一结构性转变意味着内存已成为 AI 算力扩张的最大成本中心,也是产业链瓶颈所在。

💬 评论精华

  • 有人指出若剥离内存溢价,AI 硬件成本理论上可降至三分之一
  • DDR4/DDR5 价格暴涨,96GB 内存从 250 美元飙到 1200 美元,PC 玩家与自建服务器者哀嚎一片
  • 讨论为何超大规模厂商不自建晶圆厂垂直整合,质疑内存厂商可能借机串通维持高价
  • 担忧手机内存涨价导致低端机型被迫减配,穷人被挤出市场
  • 期待 SeedLM 等内存高效推理算法或统一内存架构能缓解 HBM 依赖
15. Scientists solve 200-year-old puzzle of how tobacco plants make nicotine
科学家破解 200 年悬案:烟草如何合成尼古丁
84 分 27 条评论 作者: sohkamyung
约克大学与哥本哈根大学团队在《自然·通讯》发表研究,揭开烟草植物(Nicotiana tabacum)合成尼古丁的完整生化路径,终结了自 1828 年首次从烟叶中分离出尼古丁以来困扰科学界 200 年的谜题。研究发现尼古丁分子最初以「葡萄糖加合物」形式合成,葡萄糖为构筑单元提供能量推动两个环状结构拼接,但在最后一步又被脱去并「凭空消失」,正是这一隐藏步骤让该路径长期成谜。团队还解析了两个关键酶 NaGR 和 NicGS 的精确结构,证实尼古丁的两个环分别来自类维生素化合物和氨基酸代谢。该成果具备重要应用价值:烟草近缘种本氏烟草(Nicotiana benthamiana)已被广泛用于「分子农业」生产疫苗和药物,但天然尼古丁污染是长期障碍。掌握合成机理后,研究者可敲除或改造该路径,让烟草成为更纯净的药用蛋白生产平台,甚至改造其酶系统合成新型药物分子,让烟草「不再用于香烟,而是造福医药」。

💬 评论精华

  • 有人指出人类用烟草已逾万年,把谜题起点定在 1820 年代略显学界中心主义
  • 推荐直接读 Nature 原论文,新闻稿过于简化
  • 调侃可借此给番茄转基因产尼古丁,呼应《辛普森一家》的 Tomacco
  • 讨论尼古丁医学价值:与 nAChR 受体高亲和,或可清除病毒残片和自身抗体
  • 有人吐槽尼古丁「认知提升」效果平平,希望未来能改造出更强劲的类似物
16. Build Adafruit projects right from Firefox
Firefox 151 新增 Web Serial:浏览器直连 Adafruit 开发板
159 分 50 条评论 作者: mch82
Mozilla 与 Adafruit 合作推出落地页,宣传 Firefox 151 新增的「Web Serial」API 支持,让用户可直接从浏览器与兼容的开发板(如 Arduino、ESP 系列、Adafruit 板卡)通信,无需安装本地驱动或 IDE。这一变化标志着 Mozilla 立场的重大转向:2020 年 Mozilla 曾明确反对 Web USB、Web Bluetooth、Web NFC、Web MIDI 等「原始设备访问」类规范,认为存在安全与隐私隐患。如今 Firefox 终于跟进 Chromium 阵营已支持 5 年的能力,主要面向教育机器人(First、Vex 等平台)、微控制器烧录(如 Meshtastic)等场景,降低初学者门槛。功能通过类似 Web MIDI 的「附加组件门控」机制启用,需用户显式授权。社区普遍欢迎,但也有人担忧浏览器控制外设带来的恶意代码注入风险,并期待 Web USB、Web Bluetooth 后续跟进。

💬 评论精华

  • 教育机器人(First、Vex)严重依赖浏览器串口,Chromebook 场景刚需
  • Mozilla 终于松口,结束了多年对 Web USB/Serial 的强硬抵制
  • iOS 版 Firefox 基于 WebKit 仍不支持,落地页推广有点尴尬
  • 采用附加组件门控机制,默认不暴露给普通用户,需显式授权
  • 安全派担忧:恶意网站可借此劫持 ESPHome 等烧录工具投毒
17. The Eternal Sloptember
永恒的 Sloptember:AI 编程代理是软件史上最昂贵的错误
288 分 210 条评论 作者: razin
geohot(George Hotz)旗帜鲜明地宣称:将 AI 代理引入软件开发将成为该领域历史上代价最惨重的错误之一。他过去六个月用代理写过 tinygrad、逆向过 USB-PCIe 芯片,结论是代理「会把进度全部前置,然后给你一根老虎机拉杆」,最后的打磨永远做不到位。他承认 AI 是更好的「Google」,做原型极快,但远未达到工程师标准。真正的危害在大型组织内部:高手能识别「slop」并修正,底层员工却用代理产出十倍垃圾,组织平均质量被拉低。他举苹果强推 AI 为例,预测 macOS 两年后只会更糟。人们看到产物时默认背后是人类心智,而 AI 产物以前所未有的方式破碎,语法正确却无法在人类层面被继续构建。他认同 LeCun/Marcus 阵营,认为 LLM 永远不会真正编程,需要「世界模型」而非「注释掉失败测试就宣称通过」的 RLVR。这个时代的真正叙事,是谁能在「AI 精神病」中不自伤。

💬 评论精华

  • tptacek 反驳:AFL 并未比 LLM 找到更多漏洞,崩溃多数不可利用,仍需人类判断
  • Balinares 指出最难的是「定义正确的问题」,这恰是代理目前最薄弱之处
  • rakel_rakel 强烈认同:底层员工借代理产出 10 倍代码,组织平均质量正在崩塌
  • nilirl 务实回应:代理写的代码不如他,但快得多,多数场景下「快」就是赢
  • decimalenough 提醒读者背景:作者是 geohot,本人 comma.ai 也是「vibe coding」出来的
18. Using HTTP/2 Cleartext for a server in Go 1.24
Go 1.24 中为服务器启用 HTTP/2 明文传输 (h2c)
82 分 8 条评论 作者: dan_sbl
作者团队在 Google Cloud Run 上运行长连接 SSE(服务器推送事件)流,超时设为 15 分钟。但 Cloud Run 在使用 HTTP/1.1 时存在已知问题:客户端断开不会传递到后端服务,因此他们转向 HTTP/2 明文传输(h2c)。Cloud Run 在前端终止 TLS,可将流量以 HTTP/1.1 或 h2c 转发给后端,对应 RFC 9113 中的「HTTP/2 with Prior Knowledge」模式。文章对比了 Go 1.24 前后的配置方式:旧版需引入 「golang.org/x/net/http2」 和 「h2c.NewHandler」 包装 handler,再用 「http2.ConfigureServer」 配置;Go 1.24 后无需额外包,直接在 「http.Server.Protocols」 上调用 「SetHTTP1」 和 「SetUnencryptedHTTP2」 即可,可读性大幅提升。本地可用 「curl --http2-prior-knowledge」 验证。文末给出 Terraform 配置 Cloud Run 的代码片段,将容器端口命名为 「h2c」,并把超时调到 900 秒以容纳长连接 SSE。

💬 评论精华

  • mdavidn 提醒 AWS ALB 不支持 h2c,会盲目转发升级头并失败
  • xyzzy_plugh 询问 Go 1.24 的 HTTP/2 性能是否改善,此前强制 HTTP/1.1 反而吞吐和延迟更优
  • jeffbee 指出 Go 运行时读写 socket 的方式让 HTTP/2 每连接多两个 goroutine,存在根本性瓶颈
  • nickcw 分享 rclone 中相关提交,源于 golang.org/x 的安全漏洞
  • superkuh 认为支持非 TLS 的协议实现对长期可维护性更友好
19. Building Pi with Pi
用 Pi 构建 Pi:AI 智能体时代的开源维护困境
76 分 40 条评论 作者: mplanchard
作者反思在 Earendil 项目「Pi」中用智能体(戏称「clanker」)开发自身的体验。issue 描述如今不只是用户与维护者的沟通,还会被当作 prompt 输入给智能体,因此 issue 质量直接影响修复效果。最棘手的是「5% 人类 + 95% 机器生成」的劣质 issue:包含听起来合理但其实错误的诊断、伪造的最小复现和虚假根因。即便用自定义命令 /is 提示「不要相信 issue 中的分析」,智能体仍倾向把 issue 当证据而非传闻。作者呼吁提交者只描述自己实际观察到的事实,把 LLM 分析放评论里。代码层面,LLM 倾向在局部加宽容性处理,而正确做法是「让坏状态不可能出现」,维护全局不变量。90 天数据:3145 个外部 issue/PR 中 2504 个被自动关闭,PR 合并率不足 10%。作者认为责任不在 GitHub,而在滥用智能体污染他人 tracker 的人。

💬 评论精华

  • 有人指出作者要求机器做的事,恰恰是人类自己也不愿做的
  • 「clanker」一词引发激烈争议:部分读者认为是带种族主义意味的侮辱性词汇,作者则视为给机器命名
  • 建议把用户原始消息单独存档,便于核对计划与实际执行是否偏离意图
  • Pi 与 Raspberry Pi 重名,命名冲突让读者困惑文章主题
  • 有人认为「智能体开发智能体」可能是首个稳定成熟的软件开发范式
20. Mastering Dyalog APL
精通 Dyalog APL:在线交互版教材
142 分 36 条评论 作者: tosh
「Mastering Dyalog APL」是学习 Dyalog APL 的事实标准教材,但 2009 年由 Bernard Legrand 撰写的初版随着语言演进逐渐过时。为此,Rodrigo Girão Serrão 基于 Jupyter Notebook 重写了一版现代化教材,提供更具交互性的学习体验,同时保留了静态在线版和未来的纸质版。新版本在尽量保留原书行文与示例的基础上,更新了过时内容,并新增章节涵盖 Dyalog APL 12.0 之后引入的特性。该在线版仍在持续完善中,存在缺失章节,作者邀请读者通过 GitHub issue 或邮件反馈错误与建议。项目对原书贡献者及 Adám Brudzewsky 等社区成员表达了致谢。

💬 评论精华

  • 有人质疑 Dyalog 作为商业编译器的定位,认为应开源或并入 GCC/LLVM
  • Dyalog 实际上是解释器而非 AOT 编译器,且对非商业用途免费
  • 推荐更简洁的现代 APL 入门教程 xpqz.github.io/learnapl 与 BQN 语言
  • 讨论 APL 解法是否真的高效,认为「写得好可以很快」与「常低效」并存
  • 不少聪明人仅把 APL 当谜题玩玩就放下,缺乏长期工程化使用场景
21. Greg Brockman interview [video]
Greg Brockman 访谈:OpenAI 内幕与 AGI 之路
196 分 206 条评论 作者: prakashqwerty
OpenAI 联合创始人兼总裁 Greg Brockman 接受 Knowledge Project 播客采访,回顾了 OpenAI 创立至今的关键节点。他详述了最初 Napa 闭门会议产出的「三步技术路线」:解决强化学习、解决无监督学习、逐步攻克更复杂任务,这一计划指导了 OpenAI 十年发展。他还解释了为何必须放弃纯非营利结构。访谈重点还原了 Sam Altman 被董事会解雇后的 72 小时:接到电话时的处境、当天辞职的原因、次日在 Sam 家设计「Phoenix」备份公司方案,以及 Ilya Sutskever 那条关键推文如何扭转局势。话题随后转向当下:全球 AI 竞赛格局、OpenAI 内部代码已有相当比例由 AI 编写(「很难说哪部分不是」)、为何停止展示推理过程、算力受限世界中谁能获得 AGI,以及对就业冲击的回应。

💬 评论精华

  • 多人质疑非营利转营利的合法性,认为 OpenAI 背叛初衷,开了恶劣先例
  • 有评论指出三步技术计划「解决 RL+无监督学习+复杂任务」过于空泛,谈不上真正的路线图
  • 对 Ilya 先签解雇 Sam 又签声援信的反转动机,访谈未触及,听众感到遗憾
  • 部分人认为 Anthropic 才是当下最重要的 AI 公司,OpenAI 已失去领导力
  • 有人讽刺访谈无新料,Brockman 是 Sam 的盟友,立场可疑,价值有限
22. Scammers are abusing an internal Microsoft account to send spam links
诈骗者滥用微软内部账号发送垃圾邮件链接
283 分 155 条评论 作者: spike021
数月以来,诈骗者一直在利用微软的一个漏洞,从微软内部邮箱「msonlineservicesteam@microsoftonline.com」发送垃圾邮件。该邮箱本是微软用于发送账户告警、双因素验证码等正式通知的官方地址,被滥用后让钓鱼邮件极具迷惑性,可绕过反欺骗保护机制。攻击者似乎能通过注册新微软账号获取该地址的发送权限,邮件主题模仿欺诈交易告警或私信通知,诱导用户点击诈骗链接。反垃圾邮件组织 Spamhaus 表示该问题已持续数月,并批评「自动化通知系统不应允许如此程度的自定义」,已通报微软。微软在 TechCrunch 询问后回应称正在调查并强化检测拦截机制、移除违规账号。文章指出,类似事件并非孤例:2023 年 Namecheap 邮箱被滥用、年初 Betterment 平台被入侵发虚假加密货币通知,社交媒体上也有用户反映其他公司邮箱遭遇相同问题,显示这是行业性漏洞。

💬 评论精华

  • 有用户质疑微软域名管理混乱,连「microsoftonline.com」是否真为官方都难辨认
  • Spamhaus 指出问题在于自动化通知系统允许用户自定义正文内容,这是设计缺陷
  • 多人反映 Google Cloud、PayPal、Booking、Meta 等大厂同样存在邮箱被滥用发垃圾邮件的问题
  • 有评论建议大厂应发布官方发件域名的权威清单,而非分散在数十个域名下
  • Outlook 字体让「rn」看起来像「m」,已导致钓鱼邮件成功欺骗用户
23. Noroboto: Lying Fonts and Mitigation in Rust
Noroboto:用「撒谎的字体」欺骗 AI 阅读合同
74 分 31 条评论 作者: piker
作者展示了一种针对法律 AI 的攻击手法「lexploit」:利用 Word/PDF 允许文档内嵌字体的特性,构造恶意 TrueType 字体「noroboto.ttf」,让字形外观与原字体一致,但 cmap 把字符映射到 Unicode「私用区」(PUA) 或其他无关码点。人眼看到的是「Maryland」,复制出来或被 LLM 读取的却是乱码或「Delaware」。完全混淆易被 ChatGPT 5.5 通过单字母替换密码分析或 OCR 破解,作者于是引入 4 对 1 随机映射、多 PUA 轮换形成「多表替换」。更危险的是「部分混淆」和「替换攻击」:因 Agent 倾向走表面合法的 Unicode 快路径而懒得 OCR,所有被测平台都被「Maryland 变 Delaware」骗过。作者用 Rust 实现了缓解方案:渲染 ASCII 字形并 OCR,与声称的 Unicode 比对 Levenshtein 距离来计算「字形可信度」,未通过则告警。

💬 评论精华

  • 多人指出连字 (ligatures) 即可实现 Maryland→Delaware,比自定义字体简单得多。
  • 有人认为这只是替换密码,足够长的密文 LLM 都能破解,但作者反驳替换攻击不是密码而是直接改语义。
  • 类比合同里的「白色隐形条款」:人看不到但 LLM 读得到,可能构成欺诈或「错误」抗辩。
  • 建议直接把可见文字渲染成图像、再叠加隐形文本层,效果类似且更易实现。
  • PDF 本身是图灵完备语言,可对不同阅读工具呈现不同内容,类似手法早有先例。
24. Gorilla: A fast, scalable, in-memory time series database (2016)
Gorilla:Facebook 的高速可扩展内存时序数据库(2016)
7 分 1 条评论 作者: xnorswap
本文解读 Facebook 2015 年发表的 Gorilla 论文。Gorilla 是一个内存时序数据库,承担监控数据的写穿缓存角色,最终数据落到 HBase。截至 2015 年春,Facebook 监控系统每秒新增约 1200 万数据点,每天超 1 万亿,要求存储 20 亿条独立时序、保留 26 小时、读延迟低于 1 毫秒、峰值 4 万 QPS。为把海量数据塞进内存,Gorilla 设计了专门的压缩算法,平均压缩比 12 倍。时间戳采用「delta-of-delta」编码:以 2 小时为块,对相邻间隔的差值用变长位编码,约 96% 的时间戳可压到 1 位。数值则利用相邻值变化小的特性,用当前值与上一个值的 XOR 结果,再记录前导零和有效位长度,约 51% 的数值能压到 1 位。架构上按 key 分片、无共享、横向扩展,启动时 1.3TB 内存分布在 20 台机器,后扩到 80 台。持久化用 GlusterFS 三副本。Gorilla 显著加速了 Facebook 的故障定位与根因分析。

💬 评论精华

  • 有评论推荐 Sprintz 算法,认为压缩比更优、计算开销不大,是 Gorilla 之外值得考虑的替代方案
25. Childhood Computing
童年的计算机记忆
197 分 94 条评论 作者: blenderob
作者回忆 1992 年八岁时在印度小镇学校的计算机房经历。机房里是硅厂淘汰下来的 IBM PC 兼容机,单色 CRT 显示器,没有硬盘,只有几百 KB 内存,每月仅有两小时上机时间。进机房前要脱鞋,先用 5¼ 英寸软盘加载 MS-DOS,再加载 LOGO.COM 写小程序看海龟移动。由于没有存储设备,关机即丢失,「保存」意味着把代码抄进笔记本。作者大部分 Logo 编程是在家用纸笔完成,在坐标纸上「测试」程序。他写的一个画动态虚线房子的程序被同学手抄传播,成了他人生第一个「自由开源软件」。文章还提到 Moon Bugs、Digger、Grand Prix Circuit 等游戏带来的震撼,以及他在 2022 年终于实现儿时梦想写出 Andromeda Invaders。机房里电脑的嗡嗡声、POST 自检的哔声、空调房特有的气味,至今仍是他最鲜活的记忆。

💬 评论精华

  • 不少人共鸣那种「机房气味」一闻就回到童年的瞬间记忆
  • 有人怀念优化 MS-DOS 启动内存、研究 gorillas.bas 的折腾乐趣
  • 质疑微软当年为何不给学生提供廉价授权来培养下一代程序员
  • View Source 时代、Geocities、Angelfire 也是另一批人的启蒙路径
  • 感慨电脑越强大反而越无趣,当年屏幕画的图不擦不消失反而催生创意
26. Perceptual Image Codec: What Matters in Practical Learned Image Compression
PICO 感知图像编解码器:实用学习型图像压缩的关键要素
110 分 34 条评论 作者: ksec
苹果机器学习团队发布 PICO(Perceptual Image Codec),号称首个兼具实用性、并直接针对人类视觉系统优化的学习型编解码器。团队对实用学习型编解码器的建模选择进行了系统研究,在数百万种模型配置上联合优化感知质量与端侧运行时性能。基于大规模主观用户研究,PICO 相比 AV1、AV2、VC、ECM 与 JPEG-AI 实现 2.3 至 3 倍码率节省,相比最佳学习型编解码器节省 20% 至 40% 码率。在 iPhone 17 Pro Max 上,编码 1200 万像素图像最快 230 毫秒,解码 150 毫秒,比大多数顶级 ML 编解码器在 V100 GPU 上更快。与多数学习型编解码器不同,PICO 还提供跨平台鲁棒性保证。论文以 arXiv 预印本形式发布,作者来自苹果团队。

💬 评论精华

  • 质疑 PICO 在低码率下「编造」纹理细节,放大后树木、毛衣、鹦鹉花纹等被改写,属于 AI 压缩的幻觉问题
  • 担忧非确定性解码的法律风险:若图像被作为犯罪证据,模型生成的虚假细节可能误导陪审团
  • 批评对比基准选择不公:只比 AV1、AV2 等视频编解码器,未与 JPEG、JPEG-XL 等专门图像编解码器对比
  • 质疑用过时的 V100 GPU 作为对照,且大多数线上图像 bpp 高于 0.5,论文主打的低码率场景不具代表性
  • 类比 DLSS 与去噪自编码器:低维潜空间映射本质上会用先验「补全」内容,与纹理合成同源
27. Getting an old Computer online with Android Ethernet tethering
用安卓以太网共享让老电脑上网
57 分 21 条评论 作者: speckx
作者怀念 Windows 9x/XP 时代的老电脑,但这些机器要么没有 Wi-Fi,要么只支持 WEP 加密,无法连接现代 WPA 网络。在没有以太网口可用的环境里,他给出一个出乎意料简单的方案:买一根便宜的 USB-C 转以太网适配器接到安卓手机上,再用网线连到老电脑的以太网口,然后在手机设置里开启「以太网共享」(Ethernet Tethering)。只要老电脑启用了 DHCP 自动获取 IP,手机就会自动分配地址并把 Wi-Fi 桥接到有线口,理论上对任何带网口的新老电脑都通用。作者也试过带网口的 USB-C 扩展坞,效果一样,只是需要额外供电。他没有 iPhone,不确定 iOS 是否支持类似功能,并自嘲这么简单的办法自己居然拖了这么久才想到。

💬 评论精华

  • 可用树莓派或多网口迷你 PC 跑 IP 伪装做 Wi-Fi 桥接,承载整个有线网络
  • 现代以太网支持 Auto MDI-X,已无需当年的交叉网线
  • 市面上现成的 Wi-Fi 转以太网桥接器约 40 美元,更省事
  • 安卓 USB 网络共享走 RNDIS 协议,可追溯到 Win95 时代,老系统驱动相对好搞
  • GL-iNet 的 OpenWRT 小路由自带 Wi-Fi/以太网桥接功能,是更通用的方案
28. Why is Vivado 2026.1 dropping Linux support for free tier?
Vivado 2026.1 为何取消免费版的 Linux 支持
316 分 196 条评论 作者: zdw
AMD(原 Xilinx)在 Vivado 2026.1 版本中宣布免费基础版(Standard/Free 版)将不再支持 Linux,仅保留 Windows 平台,付费高阶版本仍保留 Linux 支持。该决定在官方支持论坛引发强烈反弹:用户质疑此举针对的是学生、爱好者、教育用户和开源 FPGA 工具链生态,而这些群体恰恰是 Xilinx 长期以来相对 Altera/Intel 取得社区优势的关键。学术界与 CI/CD 工作流高度依赖 Linux,Windows 无法提供同等的交叉编译与脚本化能力。官方回复被批评回避核心问题、态度傲慢,仅强调「不可接受的辱骂行为」却不解释为何砍掉 Linux 免费支持。许多人推测这是为了迫使付费用户购买更高阶 license,或削减维护成本,但代价是把下一代工程师推向 Lattice、Altera Quartus Lite,乃至中国 FPGA 厂商和 OSS CAD Suite 等开源工具链。

💬 评论精华

  • 官方回复回避核心质疑,只谴责用户「辱骂」却不解释砍 Linux 的理由
  • 教育用户表示将带学生转投其他厂商,Windows 无法满足交叉编译与 CI/CD 需求
  • 推荐 Lattice + 开源 Yosys/OSS CAD Suite,或 Altera Quartus Prime Lite 作为替代
  • 硬件厂商靠卖芯片赚钱却对工具软件锱铢必较,是典型的「豆计师思维」自毁生态
  • 短视决策将把市场拱手让给中国 FPGA 厂商,重蹈 NVIDIA CUDA 学生态的反面教材
29. I keep bouncing off the Scheme language
我总是学不会 Scheme 语言
148 分 71 条评论 作者: ingve
作者公开承认自己虽然深爱 Scheme,甚至以 SICP 教材为博客命名,却始终无法真正掌握它。他能读懂 Scheme 代码,借助 LLM 也能在 Racket 里搭出类 Smalltalk 的实时环境,但落到自己动手写时就卡壳。问题在于他长期被「ALGOL 神经类型」塑造,习惯按指令序列和内存位置思考,几十年的 Java、Smalltalk-80 等 Simula 系 OP 经验进一步固化了这种思路。最近两个 Web 项目(包括 SICPers 播客的书单 SE100),他都考虑过用 GNU Artanis,最终却退回到 Go。他欣赏 Guix、Shepherd 这类 Scheme 软件的优雅与威力,也想为生态做贡献,但必须先迈过「已经熟练掌握更复杂的另一种方式」这道坎,愿意以初级开发者姿态重新学习。这篇文章是他给自己立的 flag,逼自己再试一次。

💬 评论精华

  • 有人推荐 The Little Schemer 系列,正是教人「用 Scheme 思考」的入门书
  • 老 Lisper 认为只有让 Lisp 镜像长期常驻、依赖 live editing 后才会真正上瘾
  • 建议每天用 Scheme 刷 leetcode,把它当成 wordle 一样的日常练习
  • 批评 Guile 的栈追踪晦涩、错误信息无用,Scheme 生态过度碎片化是大问题
  • 有人反驳「神经类型」之说,认为只是练习不够,建议从零写一个完整项目
30. Time to talk about my writerdeck
聊聊我的「写作终端」改造
479 分 284 条评论 作者: hggh
作者将一台六年旧的 System76 Galago Pro 笔记本改造成专用写作设备「writerdeck」,目的是摆脱现代互联网的注意力干扰。她选择 Debian Trixie 的纯 tty 命令行环境,不安装 X11 或 Wayland,从根源上斩断打开浏览器的肌肉记忆。具体配置包括:用 nm-tui 管理网络以便偶尔备份,装 kmscon 让 tty 支持 Ctrl+加减号缩放字体,用 neovim 写作,tmux 做分屏并自定义状态栏,通过 acpi 显示电池电量、light 命令绑定 F8/F9 调节屏幕亮度,最终用 vimwiki 组织笔记。她强调重点是「用现有设备开始写」而非折腾完美方案,硬盘加密都省了因为内容本就要公开。文章本质是一份可复制的极简写作环境搭建指南,也是对「单一用途设备」理念的实践。

💬 评论精华

  • 有人吐槽用搭系统的方式解决「专注写作」问题本身就很反讽,绕了一大圈
  • iib 提示其实直接 Ctrl+Alt+F3 切到 tty 控制台就够了,无需重装系统
  • 多人推荐替代方案:DOS、OpenBSD(控制台字体更美)、wordgrinder 控制台字处理器
  • 有评论指出原文未提自动保存机制,对写作场景是关键缺失
  • 不少人认为关掉通知或用纸笔/打字机更直接,折腾 Linux 是程序员式过度工程