No.01
We Rebuilt the Linux MicroVM Stack on Apple Silicon
Encore 在 Apple Silicon 上重建 Linux MicroVM 栈
20 分
1 条评论
作者: signa11
Encore 自 2022 年起用 Firecracker microVM 隔离构建，但 Firecracker 依赖 Linux KVM，Mac 开发者只能通过共享 Linux 构建机、SSH、rsync、Docker 镜像转块设备等复杂流程调试，导致断点、日志、性能分析和镜像迭代都很低效。为此他们开发「crackling」，用统一 API 在 Linux 上驱动 Firecracker、在 macOS 上驱动 Apple Virtualization.framework，并重建 OCI 镜像到可启动 Linux rootfs 的工具链，让同一套构建系统能在 Apple Silicon 本地运行。文章重点展示了从远程开发迁移到跨平台 microVM 抽象的工程取舍；评论则指出 VZ.framework 能力有限，可能不如更接近 KVM 的 Hypervisor.framework。
No.02
The August 17 outage
GitHub 8 月 17 日近 8 小时故障复盘
481 分
549 条评论
作者: 0xedb
GitHub 8 月 17 日发生持续 7 小时 47 分钟的严重故障，影响网站、认证、Actions、API、PR、Issue 和 Copilot。官方称根因不是代码或配置变更，而是在流量创下新高时，Central US 数据中心的关键基础设施未能随负载扩展，引发容量压力、认证失败和多服务中断；Copilot 的客户端重试循环还加剧了恢复期流量。GitHub 表示已增加 300 多万 CPU 核、120PB 高速存储并加速迁往 Azure，目前约 58% 平台负载在 Azure。后续将加强容量、隔离关键系统、限制重试风暴并改进告警。争议集中在复盘过于笼统、对付费客户补偿不足、AI/自动化带来的流量暴增是否失控，以及 GitHub 集中化依赖风险。
No.03
I like 'em thick: an apology to my English teachers
为厚重作品辩护：向英语老师道歉
702 分
291 条评论
作者: Ariarule
作者反思自己曾把经典文学视为学校强加的苦役，后来意识到伟大作品的价值在于「厚度」：它们会随着持续注意力不断展开，而不是在初看时自明。文章以博斯《人间乐园》中所谓臀部乐谱为例，说明细节、历史语境和误读如何让作品变得更丰富；又提出未走之路、留给读者参与的空白、每个选择背后的理由等都是增厚因素。作者也批评教育常把学生直接推入洞穴，却没有说明应如何探索。评论区多认同这种对人类创作、深读和反 AI 垃圾内容的辩护，也有人质疑厚度与晦涩、过度阐释之间的边界。
No.04
HTML Can Do That
HTML 现在能做到这些事
750 分
184 条评论
作者: encyclopedism
文章展示了现代 HTML 已能原生完成不少过去常靠 JavaScript 实现的动态能力，包括 popover、dialog、互斥的 <details> 手风琴、command/commandfor 控制、图片懒加载、hidden until-found、原生颜色/日期/范围输入、progress、meter 与 datalist 自动补全等。作者强调这些能力能减少脚本、降低实现复杂度，但也反复提醒浏览器支持、样式一致性与无障碍体验仍不完善，尤其是 datalist 和部分表单控件，不能把示例当成生产决策的充分理由。核心价值在于提醒开发者重新认识平台能力，同时谨慎评估兼容性和可访问性。
No.05
The Religious Experience of Philip K. Dick by R. Crumb (1986)
R. Crumb 漫画：菲利普·K·迪克的宗教体验
24 分
9 条评论
作者: wise_blood
这篇页面转载了 R. Crumb 1986 年刊于 Weirdo #17 的漫画「菲利普·K·迪克的宗教体验」，并提供 .cbr 下载。作品以漫画形式呈现科幻作家 PKD 晚年著名的 1974 年神秘经验，即他所谓的启示、异象与对现实本质的怀疑。页面下方评论围绕这段经历是否应被视为急性精神分裂、真正的神秘启示，或两者边界本就模糊展开激烈争论。支持者认为许多历史人物也有异象，不能简单病理化；反对者则认为社会过度神化了 PKD 的晚年幻觉，忽视了他庞大的文学作品本身。文章价值在于把 Crumb 的地下漫画、PKD 的宗教迷思与读者对精神疾病和神秘体验的分歧放在一起呈现。
No.06
Version Control for Everything
给一切工具加上版本控制
22 分
8 条评论
作者: evakhoury
作者认为，AI 编程代理能快速普及，关键不只是模型强，而是代码天然有 Git 提供审计、回滚、分支、并行开发和开发/生产隔离等护栏；非编程场景缺少这些机制，因此让 LLM 修改日历、文档、邮件、Slack、Issue 等信息会很危险。文章比较两条路：为现有服务加代理层来暂存和审核跨系统变更，但会遇到撤销、冲突、原子性和全局状态不可见等难题；或把 Issue、设计文档、评审元数据等都迁入 Git，实现统一的原子变更。作者承认这会显著降低人类体验，需要大量产品工作，但认为为 LLM 打造的版本化基础设施也会让开发者和团队协作更高效。
No.07
Malicious Rust crate Arrayref runs a build-time payload
Rust 热门 crate arrayref 遭投毒，构建时下载并运行恶意载荷
478 分
409 条评论
作者: abhisek
SafeDep 披露，Rust 热门 crate「arrayref」0.3.10 被植入对仿冒包「proc-macro1」的依赖；后者伪装成「proc-macro2」副本，在「build.rs」中拼接隐藏地址，跳过 TLS 证书校验，按平台下载远程二进制并在编译期后台执行。攻击者还将旧版 0.3.5 至 0.3.9 yanked，诱导 Cargo 用户升级到恶意版本。arrayref 下载量约 2.45 亿，常作为 GUI 生态的传递依赖出现。crates.io 已移除恶意版本，但事件凸显构建脚本任意执行、依赖膨胀、账号接管和注册表应急透明度等供应链风险。
No.08
The Lost Treasure of Sid Meier's Pirates
《席德·梅尔的海盗！》被遗忘的设计遗产
5 分
0 条评论
作者: spankibalt
文章回顾 1987 年 Microprose 推出的《Sid Meier’s Pirates!》，认为它的价值不在于某个成熟类型，而在于早期游戏尚未被类型惯例束缚时的原始设计想象。它把海盗文学、电影与殖民贸易、衰老、家族营救等主题转化为一套可操作的钟表式世界：航海、贸易、决斗、寻宝与政治关系交织，而非简单拼贴小游戏。作者指出，这类设计曾影响 Microprose 后续作品，也代表 1980 年代 PC 游戏的一段被主机时代与后来的类型化叙事遮蔽的历史。
No.09
Ox Alpha
Ox Alpha：OpenRouter 上的匿名免费推理模型
124 分
94 条评论
作者: mtokmak06
OpenRouter 发布匿名第三方提供的「Ox Alpha」预览模型，定位为面向代码、长期代理任务、复杂推理和多模态工作流的推理模型。页面显示其免费、上下文窗口约 100 万 token、最多 13 万 token 输出，支持文本、图像、视频输入以及工具调用和 JSON 输出；吞吐约 35 token/s，P50 延迟约 3.95 秒。争议集中在「stealth model」机制：OpenRouter 只负责转发，真实提供方不公开；虽然声明不会用提示和补全训练，但会保留数据，引发透明度、隐私和安全担忧。社区还在通过风格、审查边界和性能猜测其可能来自中国厂商或某种变体测试。
No.10
I should have loved biology (2020)
我本该热爱生物学
262 分
101 条评论
作者: tyre
作者反思自己本应热爱生物学，却在学校里只接触到高尔基体、克雷布斯循环等术语背诵，而没有被带入生命如何运作的惊奇。文章主张，生物学应从问题和实验出发：胚胎如何分化、DNA为何能承载遗传、免疫系统如何识别病毒。作者用艾弗里的细菌转化实验、中心法则与 Lisp 程序类比说明，真正的生物学像逆向工程外星飞船，复杂、凌乱、充满例外，但底层仍是物理结构与功能的耦合。争议在于，这种浪漫叙述可能低估了学科训练、实验现实和职业环境的艰难。
No.11
Japan tried to build an operating system for the world, the US intervened
日本曾试图打造世界级操作系统，却遭美国介入
77 分
33 条评论
作者: rdmuser
文章回顾日本东京大学坂村健在 1984 年发起的「TRON」计划：它并非单一操作系统，而是覆盖嵌入式、桌面、主机、电信、硬件到字符编码的国家级计算架构。桌面版「BTRON」以超媒体文档部件取代文件和应用中心模型，链接、复合文档和多语言字符支持都远超当时主流；嵌入式版「ITRON」后来广泛部署。但 1989 年美国贸易报告将 TRON 列为日本政府扶持造成的不公平贸易壁垒，学校推广受挫，BTRON 未能进入大众市场。文章也指出，硬件性能、生态兼容、市场时机及日本内部商业力量同样影响其失败，不应只归因于阴谋论。
No.12
Why aren't smart people happier? (2022)
为什么聪明人并不更快乐？
158 分
219 条评论
作者: rafaelc
文章质疑一个直觉：若智力意味着推理、计划和解决问题，聪明人为何没有明显更快乐？作者引用元分析、英国代表性研究和 GSS 词汇测试数据，指出智力与幸福感相关性很弱，甚至略负。他认为问题出在斯皮尔曼以来对智力的理解过窄：IQ 测试主要衡量「定义良好」的问题，如边界清晰、答案可判定、可重复的题目；但人生中的伴侣、职业、育儿、衰老和共处等关键难题多是「定义不良」的，靠抽象推理和考试能力未必能解决。文章因此把幸福更多关联到智慧、自知、情绪调节和处理开放问题的能力。争议在于，有评论认为 IQ 与幸福其实正相关，或标题本身混淆了智力与幸福的因果关系。
No.13
CIA funding helped keep NeXT afloat in the 80s
CIA 采购如何帮 NeXT 渡过早期危机
392 分
237 条评论
作者: EwanG
文章称，20 世纪 80 年代 NeXT 在商业市场迟迟打不开局面时，美国情报机构的采购和支持成为重要现金流：CIA、NSA 等三字母机构不仅购买 NeXT 机器，还可能通过人脉与承包体系帮助其制造扩张。评论区认为，这更像政府作为早期大客户扶持高端硬件公司，而非阴谋式「秘密资助」；也有人指出标题有误导性，采购产品不等于注资。讨论还延伸到冷战时期国家安全预算对硅谷、数据库、Sun、Oracle、Google 等技术生态的长期推动，以及 Jobs、Ross Perot、政府合同之间的现实主义关系。
No.14
Launch HN: Vendo (YC S26) – Let users build features on top of your product
Launch HN：Vendo，让用户在你的产品上自建功能
34 分
18 条评论
作者: yousefh409
Vendo 是一个面向软件公司的工具，主张让终端用户用自然语言在现有产品之上生成定制功能、仪表盘或界面，尤其服务那些没有能力直接使用 Claude Code、API 或本地开发工具的非技术客户。团队称会通过真实 API 调用保证数据准确，并学习宿主产品的风格与约束。社区认可软件会变得更可塑、用户会要求更深定制，但也担心这会放大客服噩梦、权限与质量控制问题；另有人质疑它相对优秀 API、CLI、MCP 的增量价值，以及定价中「用量」表述不清。
No.15
Show HN: Huzzah – a novel approach to coding with AI
展示：Huzzah，用持久伪代码驱动 AI 编程
289 分
154 条评论
作者: danielvaughn
作者认为 2026 年初编码 Agent 带来效率跃升后，开发者很快遇到疲劳：反复用长篇英文描述改动既低效，也缺少可追溯的人类意图。Huzzah 提出把提示从临时的命令式聊天，改成持久的声明式伪代码文件；保存文件时，系统用伪代码 diff 作为提示，重新生成受影响代码。作者强调这种方式更精炼、像设计代码、可作为文档，并可能支持跨语言生成；但也承认在大型项目、既有代码库、跨文件依赖和缺乏领域知识时会受限。评论区主要争议在于：这是否只是规格驱动开发、DSL 或更贵的编译器，以及它是否真正解决了 AI 代码可理解性问题。
No.16
Captain Zilog
Zilog 队长
46 分
6 条评论
作者: rbanffy
这篇文章应是 Zilog 公司当年推出的促销漫画「Captain Zilog」相关页面。评论指出，Zilog 正是 Z80 处理器背后的公司，它不仅做芯片，也曾用动作漫画这类非传统形式传播产品或技术概念。社区讨论围绕企业宣传漫画的历史趣味、技术传播方式以及类似案例展开：有人补充背景资料，有人联想到 Google Chrome 早期由 Scott McCloud 创作的漫画说明书，也有人分享 90 年代在相关机构获得实体刊物的经历。整体价值在于展示早期科技公司如何借流行文化包装复杂技术；争议不多，更多是怀旧、考据与对图像化文档效率的肯定。
No.17
Make a 6-Tesla-class high-temperature superconducting dipole magnet at 4.2 K
4.2K下制成6特斯拉级高温超导偶极磁体
37 分
8 条评论
作者: supermagnet
文章报告了一种在4.2K液氦温区运行的6特斯拉级「高温超导」偶极磁体。虽然材料按零场临界温度属于高温超导，但实验仍选择极低温，以换取更高临界电流和磁场裕度，面向加速器、MRI、NMR等强磁场应用。评论区的争议集中在命名和实用性：有人认为既然在4.2K下性能还不如成熟的Nb-Ti技术，工程价值并不明显；也有人解释，高温超导的优势不是一定在高温运行，而是在强磁场下仍可能保有更高上限。讨论还延伸到20K液氢冷却等潜在方案。
No.18
Codex on AWS bedrock bug causing 10x charges
Codex 在 AWS Bedrock 上的缓存计费异常疑致十倍费用
128 分
39 条评论
作者: TheP1000
这则 GitHub issue 指出，Codex 通过 AWS Bedrock 使用时疑似没有正确复用提示缓存：缓存写入很贵，但读取命中率不到 5%，导致本应被缓存摊薄的上下文反复按高价写入，实际成本可能接近预期的十倍。评论区还把问题延伸到近期 Codex App 和 VS Code 插件用量异常飙升，部分用户称官方否认但轶事反馈很多。技术讨论集中在 OpenAI 提示缓存机制、不同模型架构是否影响 KV 缓存复用，以及 issue 中疑似 AI 生成回复质量差。争议点则包括这是普通工程失误、计费系统修复优先级不足，还是平台总在用户多付费方向出错。
No.19
Seed: Minimal, self-modifying agent harness
Seed：极简自修改智能体框架
13 分
1 条评论
作者: gandalfgeek
Seed 是一个托管在 GitHub 上的极简「自修改智能体」harness，核心卖点似乎不是堆砌复杂功能，而是用尽量短小、清晰的结构展示智能体如何运行、观察自身并修改自身。由于原文正文无法抓取，具体实现细节、接口边界和安全机制尚不明确；但从标题与评论看，社区关注点集中在它对近两年臃肿、发散的智能体项目的一种反向选择：保持小、可读、可理解。唯一评论者赞赏其简洁和清晰，并希望项目不要膨胀。这也提示潜在争议：自修改能力很有启发性，但若缺少约束、测试和审计机制，极简设计可能在扩展后迅速失控。
No.20
Vomit: Clean up Claude 5's token output with a separate LLM
用另一个 LLM 清理 Claude 5 的啰嗦输出
243 分
241 条评论
作者: Bluestein
Vomit 是一个围绕 LLM 输出后处理的小工具：当 Claude 5 尤其是 Opus 5 生成大量别扭、冗长、带固定 AI 腔的技术文字时，把结果再交给另一个模型改写成更正常、简洁的英语。评论区普遍认为 Anthropic 新模型近期 prose 质量明显退化，常出现奇怪隐喻、空洞免责声明和难读的 PR 描述；有人用自定义 prompt、技能、正则、Vale 规则或本地模型做类似「去 Claude 味」处理。争议在于：为一个昂贵模型再加一层模型是否荒谬，是否不如直接换 Codex、旧版 Opus 或开源模型；也有人认为这是模型推理增强、RLHF 或多 agent 场景的副作用。Anthropic 新增的「concise」模式被认为有帮助但不彻底。
No.21
Show HN: Argentic – An L402 Lightning toll booth for AI scraping agents
展示：Argentic，用于 AI 抓取代理的 Lightning 付费关卡
5 分
1 条评论
作者: Ag0146
Argentic 似乎是一个面向网站和内容提供者的「L402」方案：把 HTTP 402 付款要求与 Lightning 微支付结合，作为 AI 抓取代理访问内容前的付费关卡。其核心价值在于让被抓取方不只是封禁机器人，而是能对自动化访问按次收费，探索 AI 时代内容变现和访问控制的新机制。唯一评论质疑「收费站」类比是否成立：现实收费站会阻止未付款车辆通行，并可追责；而网页抓取场景中，系统如何实际阻止绕过、识别违规代理或执行处罚仍不清楚。
No.22
Linux 7.2
Linux 7.2 发布：调度、内存与图形栈更新
243 分
90 条评论
作者: mariuz
Linux 7.2 按周期发布，是近年最繁忙的内核周期之一。文章重点介绍 Igalia 的贡献：原计划默认启用的 DRM 调度器公平策略因最后阶段回归问题改为可选；sched_ext 增强了错误诊断；树莓派 4/5 GPU 获得运行时电源管理，树莓派 3 图形崩溃问题也得到修复；futex 修复了影响 14 年的 robust list 边界缺陷；另有 x86 启动 memcmp、ueagle-atm 驱动、HDMI 2.1 FRL 支持等改进。评论区主要围绕 Linux 桌面体验、内存管理、HDMI 与 DP、以及 DRM 术语误解展开。
No.23
AliExpress runs silent WebAudio fingerprinting that breaks Bluetooth multipoint
AliExpress 静默运行 WebAudio 指纹识别，干扰蓝牙多点连接
954 分
298 条评论
作者: emctech
作者发现打开 AliExpress 首页数秒后，蓝牙多点耳机会被电脑端静默占用，手机音乐中断；关闭标签页立即恢复，静音标签无效。排查显示页面没有常规音视频元素，而是由 Alibaba AWSC 反滥用脚本创建两个运行中的「AudioContext」，构造锯齿波振荡器、分析器、脚本处理节点和零增益输出，连接到系统音频目的地以采样浏览器音频实现差异。结合脚本中还检测 Canvas、WebGL、硬件、WebRTC、插件、交互事件等行为，作者认为这是综合浏览器指纹识别，可能用于反欺诈或追踪。文章给出 uBlock Origin 规则阻断相关脚本，但提醒可能影响登录、支付或触发更多验证码。
No.24
I Ported Moonshine to JavaScript
Moonshine 语音识别移植到浏览器 JavaScript
4 分
1 条评论
作者: jreynar
作者宣布将 Moonshine 官方移植到浏览器 JavaScript/WASM，并在 moonshine.ai 提供从最小转录示例到会议纪要应用的演示。移植不只是把 C++ 核心编译成 WASM，还包括符合浏览器开发习惯的高层 API、测试与 CI、交互示例、真实应用和内存模型加载支持。作者认为这并非单纯的「WASM 噱头」：开发者需求明确，JavaScript 覆盖面广，语音交互会增长，而本地端侧转录比服务器方案更低延迟、低成本且更符合隐私和工程直觉。文章核心主张是语音输入应像键盘、鼠标、摄像头一样本地可用，浏览器支持能降低采用风险并扩大应用场景。
No.25
Git at any scale
任意规模的 Git 托管
326 分
102 条评论
作者: meetpateltech
文章解释为什么大规模托管 Git 仓库很难：Git 原为分布式工作流设计，但现代团队实际依赖中心化主机；其核心存储与传输都围绕 packfile，适合本地磁盘却不适合多机高可用。对象级分布式存储看似天然匹配 SHA 寻址，但遍历 DAG 会产生大量串行远程读取，且协议仍要求发送 packfile，导致 clone 性能差。GitHub 早期尝试 NFS、GFS、DRBD 等分布式文件系统也因 Git 对本地文件系统语义和 packfile 布局的假设而碰壁。评论显示，读者认可文章对 Git 扩展痛点的解释，也关注 Cursor 方案对 S3、一致性、WAL、复制协议和运营复杂度的依赖。
No.26
Stop Anthropomorphizing Intermediate Tokens as Reasoning/Thinking Traces (2025)
别把中间令牌拟人化为推理或思考轨迹
225 分
151 条评论
作者: nunodonato
这篇立场论文批评把语言模型在给出答案前生成的中间令牌称为「推理轨迹」或「思考轨迹」。作者认为，这种说法暗示它们像人类解题步骤、可作为模型思维过程的可解释窗口，但证据并不支持。论文主张，拟人化不是无害比喻：它会误导用户过度信任模型、混淆模型机制，也可能推动建立在错误解释上的研究。争议焦点在于，中间令牌虽常能提升任务表现，并与答案正确性有一定相关，但是否代表真实内部计算、能否用于审计和解释，仍应谨慎区分。
No.27
Anti-AI fonts are useless and harmful
反 AI 字体既无效又有害
153 分
110 条评论
作者: speckx
文章批评通过混淆、打乱字形来阻止 AI 抓取的「反 AI 字体」思路。作者认为，这类字体首先会伤害无障碍访问：屏幕阅读器等工具读取的是被打乱的文本，残障用户会被排除在外；若试图为他们保留机器可读元数据，又会走向身份验证、隐私与安全风险。其次，只要人类能看懂，AI 也终会通过多模态训练、OCR 或专门适配绕过，公开演示反而会变成训练基准。若全网走向高度混淆，最终可能催生昂贵的访问系统、版权保护、审查和付费墙，违背开放 Web 精神。作者主张应按公开信息终将可被机器读取这一基线来规划，而不是押注字体混淆。
No.28
Speeding Up (Small) Ruby Hashes
加速小型 Ruby Hash 的查找
49 分
0 条评论
作者: arto
文章延续作者关于缩小 Ruby Hash 的分析，指出 Ruby 在 8 个以内键值时并不用真正的哈希表，而是用「ar_table」保存一组键值对和 1 字节哈希提示，因此查找本质上是线性扫描。基准测试显示，同一个小 Hash 中越靠后的键访问越慢，第 8 个键约比第 1 个慢 1.5 倍，甚至慢于真正的「st_table」。作者认为这虽是节省内存的合理取舍，但仍可优化：把 8 个提示字节视为一个机器字，用「SWAR」一次性并行比较，减少逐字节循环开销，让小型 Hash 查找更接近常数时间。核心价值在于展示底层数据结构、缓存友好性与微优化之间的真实权衡。
No.29
SpacetimeDB: a short technical review
SpacetimeDB 技术短评：快得有代价
88 分
17 条评论
作者: hurrrr
文章认为 SpacetimeDB 2.0 的营销和基准测试存在明显误导：它把「数据库+应用服务器」的一体化架构拿来对比传统分布式数据库，天然省掉网络开销，因此 QPS 优势并不公平。作者肯定其把应用逻辑放进数据库、以更好开发体验实现类似存储过程的思路有价值，但指出高写入性能主要来自内存数据存储、批量写入和本地执行等取舍，而非通用数据库魔法。其存储核心被描述为带全局读写锁的哈希表，写入线性化容易证明，但读写并发、饥饿、延迟和语义可配置性都缺乏清晰说明。文章核心主张是：数据库产品应诚实解释取舍和限制，而不是靠夸张 benchmark 与嘲讽竞争对手取胜。
No.30
AI companies destroy physical books – let's scan rare books before it's too late
AI 公司正在毁掉纸质书：趁太晚前扫描稀有书籍
292 分
215 条评论
作者: Cider9986
文章据标题与讨论推断，批评多家 AI 公司通过中介大量购买二手书，扫描后销毁纸本，以获取「未污染」训练数据；作者呼吁在这些实物书被私有化和物理消失前，尽快由公众或档案项目扫描保存。争议焦点在于：被毁的是否真是稀有书、AI 公司是否只买一册、扫描件是否仍被保留、版权法是否反而鼓励销毁而非共享。许多评论认为真正问题是版权和出版社封锁数字版本，也有人指出旧书本来就常被书商和图书馆处理，需用证据区分道德恐慌与真实文化损失。
评论精华