Bob Cringely 去世、在家用显卡上跑 125B 的 Qwen，与关掉 macOS 27 里的 Apple Intelligence——Hacker News Top 20（2026 年 10 月 5 日）

1. Run Qwen 3.8 Flash Next (125B) on consumer hardware (RTX 4090) at 100T/s

• 原文入口：GitHub · Strata
• HN 讨论：49953495
• 提交者：snehesht（提交于 2026-10-04 20:51）
• 快照热度：570 points | 272 comments
• 原文日期：2026-09-24（仓库创建日；项目页本身是 README，不标发布日期）
• 中文要点：Strata 是一个安装器加运行器，目标是在一台普通游戏 PC 上跑起 Qwen3.8-Flash-Next 这个 125B 模型，要求 12 GB 以上显存的 NVIDIA 或 AMD 显卡、32 GB 以上内存、大约 80 GB 磁盘，系统是 Windows 10/11 或 Linux。项目页给出的两组实测配置分别是 RTX 5070（12 GB）配 Ryzen 5 7600 与 64 GB 内存、RX 9070 XT（16 GB）配 Ryzen 9 3900X 与 47 GB 内存；在 NVIDIA 那台上，Q2_0 量化写答案 94 token/s、读 32K 提示 2,650 token/s，更精细的 IQ3_S 是 53 与 1,620；AMD 那台上 Q2_0 是 60 与 1,160。模型按内存选型号：32 GB 用砍掉一半专家的 Coder 版（作者称达到完整模型 SWE-bench Verified 成绩的 91%，也能塞进 32 GB），64 GB 可以选 IQ3_S，96 GB 以上再考虑 4-bit。启动时会把 35–55 GB 载入内存，前一到三分钟机器可能卡顿。装好之后浏览器打开 127.0.0.1:8080 就是聊天界面，同时提供一个 OpenAI 兼容接口和一个 MCP server，Claude Code、Cursor、Codex 这类工具可以自己启动和停止它。项目页还建议把一行指令直接粘给自己的编码助手，让它照着仓库里的文档自动装好。272 条评论分成几路：有人在自己机器上实测并报数（4090 加 128GB DDR5 与 7950X3D 跑到 124 token/s，3090 上「飞快」，做 PHP 代码库安全审计效果不错）；有人争论量化是不是等于把模型掏空——把 125B 压到 Q2 甚至 Q1、再摘掉一半专家，跑得是快，但长任务推理靠的正是被砍掉的那部分，结论是「要么老老实实凑够跑 Q4 的显存，要么换个小模型」；有人提醒项目页写着「把这一行粘给 AI 助手」比自己敲 curl 管道更危险；也有人把它和 ds4、FreeToken 比较，并感叹现在每个本地推理引擎都比 llama.cpp 快，但都更窄。

2. Infidel goes wild

• 原文入口：Zarf Updates · Infidel goes wild
• HN 讨论：49943637
• 提交者：tobr（提交于 2026-10-03 20:19）
• 快照热度：50 points | 3 comments
• 原文日期：2026-10-02
• 中文要点：Andrew Plotkin 在他的 Zarf Updates 上分析 Infocom 的旧作《Infidel》里一个野指针 bug。作者说他最近用上了相当于内存级调试器的手段，才成为第一个发现它的人；这个 bug 几乎不影响游玩，但它是野指针写坏了不该写的内存，而且出自编译器，所以在他看来属于最严重的一类问题。文中说明他分析的是 Infidel release 22、序列号 840522 的 Macintosh 更新版，最初的 830916 版有同样的 bug，只是内存地址略有不同。文章接着讲《Infidel》的地图：游戏发生在埃及沙漠，营地以西是尼罗河，以东是九个沙漠地点组成的 3×3 网格，其中一处埋着玩家要找的金字塔；一旦走出这片区域，玩家就会被判定在沙漠里迷路，无论怎么走都只会遇到更多沙子，直到中暑。这借用了《Enchanter》里第一次出现的技巧：所有未编号的沙漠位置共用一个叫 ENDLESS-DESERT 的房间，游戏只记录经纬度，移动时没走回营地或已编号区域就绕回这个房间。为了让它显得可信，游戏必须小心地搬动物件，bug 就出在这套逻辑上。只有 3 条评论，讨论没有展开：一条问作者怎样才能写出这种把个人经验写进技术文章的作品，一条只留下一句「太有意思了」。

3. Turn off Apple Intelligence on macOS 27 and get its disk space back

• 原文入口：GitHub · RemoveMacAI
• HN 讨论：49957116
• 提交者：privacyisntdead（提交于 2026-10-05 03:42）
• 快照热度：294 points | 178 comments
• 原文日期：2026-09-29（仓库创建日；项目页本身是 README，不标发布日期）
• 中文要点：macOS 27 取消了 Apple Intelligence 的单一总开关，功能关掉之后模型文件仍然留在磁盘上。RemoveMacAI 做三件事：关掉相关功能、删掉已经下载的模型、并阻止系统把它们再下回来，所有改动都可以撤销。它关掉的功能包括 Siri（含「嘿 Siri」与菜单栏图标）、写作工具、Genmoji、Image Playground、ChatGPT 扩展、邮件与信息等处的摘要、邮件智能回复、行内文字预测、空间照片、照片清理与 Xcode 预测式代码补全；删除的是 Apple Intelligence 基础模型以及图像生成、空间照片、照片清理、Xcode 补全各自的模型。实现方式是通过配置描述文件套用 Apple 的限制键、强制那些没有对应限制键的设置，并让模型下载被重定向到一个关闭的本地端口，因此系统不会重新下载；删除走的是 Apple 自己的 asset service，系统完整性保护（SIP）保持开启，不改动 /System 下的文件。安装方式有一行脚本，也有 Homebrew。作者说明它基于 4evy 的工具 pared 构建，并且不做任何网络请求、不收集数据。178 条评论里有几路声音：有人直接反对「curl 管道进 bash」这种安装方式，也有人指出这个项目其实做得挺规范——每次发布都由 GitHub Actions 从 tag 构建并附带构建来源证明，可以验证；有人追问这个工具本身是否可信、有没有手动做法；有人把它和 Windows 上的 O&O ShutUp10 相提并论，问 Apple 的产品策略到底怎么了；还有人抱怨 macOS 27 顺带移除了 Rosetta、要自己重装，觉得照这个趋势不如干脆换 Linux。

4. Self-hosted HTTP tunnels with SSH and Nginx

• 原文入口：Vincent Bernat · Self-hosted HTTP tunnels with SSH and nginx
• HN 讨论：49958569
• 提交者：renehsz（提交于 2026-10-05 06:25）
• 快照热度：27 points | 5 comments
• 原文日期：2026-10-03
• 中文要点：Vincent Bernat 用一台服务器、OpenSSH 和 nginx 搭出临时 HTTP 隧道，用来把只跑在 localhost 的预览页给朋友看。核心是反向端口转发：命令里把远程端口写成 0，服务器就自己分配一个空闲端口并转发到你本地的 8080，例如 ssh -N -R 0:localhost:8080 web02.luffy.cx 会返回一个形如 41535 的端口号。nginx 那边按端口号做正则匹配，把 p<端口>.ssh.域名 的请求代理回本机的对应端口；再接上通配 DNS 记录与 Let's Encrypt 的通配证书（用 DNS-01 挑战，作者的 acme 区域托管在 Route 53，NixOS 自动取证书）。文章也谈了访问控制：端口号本身就是唯一的「秘密」，所以他还讨论了如何限制会话时长、以及为什么这套方案不适合长期对外服务。5 条评论里，有人分享自己在做类似的想法，认为它比 Tailscale、Cloudflare 这类把流量经手第三方的方式更接近「自托管」；有人反问既然叫自托管，为什么还需要 ssh.luffy.cx 这样的域名；有人推荐 iroh 上的 https 方案，靠公共中继打洞、不需要公网 IP 和端口转发；还有人在做基于用户态 WireGuard 的同类工具。

5. Improper redaction reveals Google Data Center water and electricity usage

• 原文入口：10/11 NOW · Improper redaction reveals Lincoln's Google Data Center water and electricity usage
• HN 讨论：49957068
• 提交者：sensanaty（提交于 2026-10-05 03:37）
• 快照热度：199 points | 295 comments
• 原文日期：2026-09-30
• 中文要点：内布拉斯加州要求数据中心每年向州水资源、能源与环境部提交报告，但若被认定是商业秘密，公开版本会把关键数字涂黑。Google 在当地的三处数据中心都这么做了。记者发现涂黑做得不彻底：用光标选中涂黑文本框、复制粘贴到另一份文档里，数字就露了出来。林肯那处由 Agate LLC 运营的数据中心报告峰值用电 52.65 兆瓦，全年用水 13.299 百万加仑（约 1,300 万加仑），来源是冷却塔、蒸发系统与场地运营。同一手法还曝出帕皮利昂的 Fireball LLC 全年用水 547.88 百万加仑，是三处里最多的；到 9 月 30 日为止六处已上报的数据中心合计用水 7.65 亿加仑。报告还显示三家实体各自预期 2025 年的退税金额：Agate 5,582 万美元、Fireball 3,917 万美元、奥马哈的 Westwood Solutions 2,255 万美元；Agate 申报的建筑面积是 288,530 平方英尺。这些报告出自州长 Jim Pillen 7 月 20 日要求数据中心自报资源影响（主要是水、电网与本地基础设施）的行政令，9 月 30 日截止；10/11 已在 9 月 30 日提交公开记录申请，要求公开 Agate 报告里被涂黑的部分。295 条评论是本期最多的一串，主流意见是「其实没那么多」：1,300 万加仑大约相当于 20 个奥运泳池，不到林肯市 9 月 29 日一天用量的二分之一；有人拿高尔夫球场和大型酒店作比较，有人说数据中心用的是冷却水、不污染也不消耗掉，真正值得区分的是抽取不可再生的深层地下水那一类；也有人提醒被允许的取水量与实际取水量常被混为一谈。当然也有人盯着涂黑本身——爱泼斯坦文件的涂黑风波之后还是这么干。

6. Homa: The end of TCP for AI clusters [video]

• 原文入口：YouTube · Homa: The End of TCP for AI Clusters — John Ousterhout, Stanford
• HN 讨论：49957117
• 提交者：signa11（提交于 2026-10-05 03:42）
• 快照热度：46 points | 12 comments
• 原文日期：2026-09-17（视频发布日）
• 中文要点：斯坦福的 John Ousterhout 在 AI Engineer 频道讲现代 AI 集群的网络负载为什么让 TCP 和 RDMA 成为瓶颈。他的讲纲写着：旧工作负载关心的是千兆字节和吞吐，新的工作负载是元数据与协调；一次缓慢的交换就能让所有 GPU 停下来；拥塞发生在接收端，而 TCP 的拥塞控制却装在发送端；字节流本身没有消息边界，而 RPC 有。视频随后给出 Homa 的设计，作为一次「推倒重来」的传输层方案。HN 上有人贴出 LWN 的报道和 USENIX ATC 2021 的论文链接，说 Homa 已经不是新东西，核心是发送端把消息拆成两部分：开头一段不等许可直接发（覆盖前一个往返时间内的字节数），其余部分等接收方用 GRANT 包点名再发——对短请求就是盲发，对长消息则是接收端驱动；有人把它类比成电路交换与分组交换之争，认为流量模式高度可预测的场景才适合这种定制协议；也有人抱怨把视频当主链接不合适，还有人从仓库的更新日志里看这项目几年来的变化。

7. A browser-native classic Visual Basic VB6 IDE

• 原文入口：Visual Basic — Browser Studio
• HN 讨论：49956681
• 提交者：wiso（提交于 2026-10-05 02:49）
• 快照热度：49 points | 18 comments
• 原文日期：日期未确认（站点是不标日期的单页应用，页面只有一段描述）
• 中文要点：Wiesław Šoltés 做了一个浏览器里运行的 VB6 风格开发环境，页面自己的描述是「独立的浏览器原生 Visual Basic 风格 IDE、运行时、窗体设计器与单文件 HTML 编译器」。打开网页就能拖控件搭界面、写 VB 代码并直接运行，成品可以导出成一个 HTML 文件。作者在社交账号上把这一版称为「VB6 Studio Web」，列举的能力包括 VB 风格源码运行时、窗体设计器、浏览器控件库、调试器与单文件 HTML 应用打包。18 条评论里，多人惊讶于它启动之快，说这一点足以让现在的 IDE 开发者脸红，也有人怀念自己当年用 VB 写作业自动化；一位读者试着导入学生时代用 BitBlt 写的 VB6 地图编辑器，因为缺少 Win32 API 层而没跑起来，于是建议至少实现一小部分；有人问有没有智能提示，答案是站点有、当年的 VB6 也有；还有一条被反复追问的线索是「这是不是用大模型做的」——有评论指出作者账号在过去四天里有 5,000 多次提交与 1,500 多个 PR，其社交账号一周内陆续放出浏览器里的 Windows Vista、XP、2000、ME、98、95、3.1、Mac OS 9，以及 Word、Excel、OneNote、Access、Visio、Illustrator、Acrobat、Git 客户端、CAD、视频编辑器等大量复刻。

8. A map of every lighthouse

• 原文入口：mapped.earth · Lighthouses of the World
• HN 讨论：49933461
• 提交者：karakoram（提交于 2026-10-02 21:45）
• 快照热度：156 points | 71 comments
• 原文日期：日期未确认（页面不标发布日期）
• 中文要点：mapped.earth 的这张图把全球每一处标在海图上的助航灯都放上一个夜间地球，每一盏都按海图上印着的节律闪或扫。站点由 Aaron Becker 一个人做，他自己的说明是：这里的东西都用真实数据搭、认真标注来源，做的是「能经得起看的图，不靠造假换注意力」。这张灯塔图是他的系列作品之一，同一站点还有活的地球、河流、降雨、紫外线等图层。71 条评论几乎全在讲体验问题：在手机上没法用手指缩放、点不中灯塔；MacBook 上的双指缩放会让整张图满地球乱飞，有人形容自己被甩到了拉布拉多内陆；有人用 M4 MacBook Pro 开三分钟风扇就满速。另一个方向是数据质量：有人对照自家附近，发现图上标出的灯比实际多出十倍左右，多数对不上实体，有人指出这里混进了浮标，还有 OpenStreetMap 数据被套用后把内陆一处码头也标成了灯塔。也有人给出真正有用的观察：同一片海区的灯塔会被安排不同的闪光周期，这样船员一眼就能分辨自己看到的是哪一座。另有一条评论把这张图归到「有人拿 Claude 生成」的一类，抱怨输出可以更用心、更可读一些。

9. Tell HN: Bob Cringely has died

• 原文入口：无外链（Tell HN 帖，正文即发帖人自述）
• HN 讨论：49949438
• 提交者：paveworld（提交于 2026-10-04 08:50）
• 快照热度：795 points | 173 comments
• 原文日期：日期未确认（Tell HN 帖不标日期，发帖时间为 2026-10-04 08:50）
• 中文要点：发帖人说从这家人的朋友处得知，Bob 在周六凌晨睡梦中去世。帖子里写道，Bob 本名 Mark Stevens，是 Apple 的早期员工，最广为人知的是他拍的 PBS 纪录片，尤其是《Triumph of the Nerds》（书名常译《书呆子凯旋》）。173 条评论里，很多人从各自的经历说起：有人说是读他的《Accidental Empires》才知道科技行业是一个行业；有人评价他为后世理解个人电脑史上的人和事留下了底子；有人提到他 2020 年还写过一篇《Not dead yet》回应当时的讣告误传；有人喜欢他常唱反调的观点，说在互联网之前，他那份从别人手里接过来的 Cringely 专栏是硅谷之外的人了解行业的渠道；也有人回忆 2015 年前后他专程到南加州一间小联合办公空间看 ZeroTier，说这事「本该在十几年前就有人做」。也有人先去核对这是不是他本人，翻出他在自己网站上的自我介绍页确认了一遍。

10. Xray-core concealed a certificate verification bypass vulnerability

• 原文入口：GitHub · net4people/bbs issue #672
• HN 讨论：49956003
• 提交者：timbill（提交于 2026-10-05 01:38）
• 快照热度：36 points | 0 comments
• 原文日期：2026-10-02
• 中文要点：这是一份由漏洞报告者本人写的时间线，发在 net4people 的 bbs 仓库里。他的核心指控是：Xray-core 长期把「跳过证书校验」（allowInsecure）说成等于裸奔，但当它自己的代码造成同类风险时，选择的是掩盖。2021 年 10 月 21 日加入的 pinnedPeerCertificateChainSha256 本是可用的第二层保护；2026 年 1 月 9 日它被 pinnedPeerCertSha256 取代，旧选项同时移除，用户没有别的选择；1 月 13 日发布第一个带漏洞的版本；1 月 16 日修改逻辑，变成永远跳过常规校验、只做自定义的证书固定，于是整条防线只剩这一层。2 月 6 日报告者发现 pinnedPeerCertSha256 里的绕过漏洞并私下报告——中间人只要把一张叶子证书插进证书链的任意位置就能骗过校验；同一天 Xray-core 悄悄修掉，提交信息只说「简化代码」，当天发的新版本一个字没提；同一天它的 Telegram 频道还在讲「软件必须以安全为核心设计，消除人的因素」。7 月 3 日报告者发现修复不完整，某些情况下仍可绕过，只好改走 GitHub Security Advisory。按他统计，用户在这套设计下不知情地「裸奔」了将近半年。这条在快照时刻是 0 条评论、36 分，没有讨论可供参考。

11. Show HN: Glashütte Trash Clock – A 30-minute pendulum clock made from trash

• 原文入口：Niklas Roy · Glashütte Trash Clock
• HN 讨论：49930439
• 提交者：r0r0（提交于 2026-10-02 14:33）
• 快照热度：161 points | 21 comments
• 原文日期：日期未确认（页面只标「Glashütte, 2026」）
• 中文要点：艺术家 Niklas Roy 在德国萨克森州的格拉苏蒂做出了一座完全由捡来的废料拼成的摆钟。它一次只能走大约半小时，所以只显示秒和分，分针每到 12 点位置就敲一次玻璃瓶做的钟；额外的一个功能是：在快走的能量耗尽之前，它会触发一台外置的随机装置。他的曾祖父与高祖父都是瑞士制表匠，后来迁到萨克森；2026 年他收到 NOMOS 的邀请去格拉苏蒂做艺术家驻留，于是决定自己造一座钟。文章一步步讲了原理与做法：单摆的周期只由长度和重力决定，一米长的秒摆正好一秒一个单摆周期；擒纵轮做 30 齿，摆每摆一次放半齿，于是每分钟正好转一圈，秒针直接装在这根轴上；擒纵叉用一根弯过的金属杆，齿轮则用回形针做成，作者顺带开玩笑说这不像博斯特罗姆的「回形针最大化」预言——这里用回形针纯粹是实用考虑。动力来自一只装了废金属的油漆桶，桶用纸板做，桶上还挂了从路边捡来的儿童拼装玩具里的滑轮组，用动滑轮把行程减半、延长续航。分钟显示原本想用纸板齿轮，后来改成摩擦轮，靠打滑容忍误差，抬一下轴就能手动拨分。整点报时的机构独立供能，配重是一只橡胶靴。精度方面，他用手机拍了整段运行、再写程序追踪摆上的黑胶带，量出它的一「秒」平均是 1.004 秒（±0.001 秒），误差 0.4%。文章后半段讲时间尺度，并顺势发明了 GTC：以这座钟为准的全球参考时间。21 条评论里，有人推荐《纽约客》那篇关于格拉苏蒂与钟表收藏的长报道，有人把它和 Ciechanowski 那篇讲机械表原理的经典长文对照着看，有人称赞页面上那些会跟鼠标互动的回形针，还有人借文中提到的闰秒转到闰秒存废的历史上。

12. How to scale intent, quality, and artistry with AI [video]

• 原文入口：YouTube · How to scale intent, quality, and artistry with AI — Katie Dill (Stripe)
• HN 讨论：49951891
• 提交者：simonjgreen（提交于 2026-10-04 16:41）
• 快照热度：44 points | 13 comments
• 原文日期：2026-09-26（视频发布日；内容录制于 2026-09-10 旧金山 Lenny and Friends Summit）
• 中文要点：Stripe 的设计负责人 Katie Dill 在 Lenny and Friends Summit 上的演讲，主题是当 AI 让做东西变容易之后，怎样避免产品变成千篇一律的「僵尸界面」。她的主张是：好的设计仍然取决于有没有清楚的观点、有没有真正理解用户、有没有在细节上较真；这些标准可以写进 AI 工具里，让工具按同一套要求工作。她还讲到不要停在第一版，要在 AI 的初稿之上继续编辑，以及怎样用 AI 做出更有原创性的产品。13 条评论里，有人把它称作自己看过的、在「避免 AI 流水线垃圾」这件事上最好的短篇；更多是批评：有人认为这不过是把「以 TED 演讲的形式讲人写的流水线垃圾」包了一层，归纳起来就是「要当回事、把做法制度化、反复审查重做、保持创造力」；有人从标题本身开火，说明确、品质与艺术性在他看来根本就不是该被「规模化」的东西，做音乐的人不会想着把一张专辑扩成一百张，要扩大的顶多是听众；也有人摘出演讲里的一句话表示认同——「用人的判断力，让 AI 去放大」。

13. Incentives in Academic Research

• 原文入口：Mate Soos · Incentives in Academic Research
• HN 讨论：49956035
• 提交者：zero_k（提交于 2026-10-05 01:42）
• 快照热度：32 points | 15 comments
• 原文日期：2026-10-03
• 中文要点：作者 Mate Soos 从 Munger 那句「给我看激励，我就给你看结果」出发，认为学术研究的激励已经严重偏离了原本的目标——推进科学理解、训练下一代研究者。他讲了几个亲历：他质疑过一篇被称为当前最优的论文，那篇论文的评测结果连作者自己都知道有问题，对方的回应大致是承认问题、但拒绝撤稿，反而问他这是不是妨碍他发自己的论文；他还遇到一位博士生写的工具，他说明评测方法不对之后对方完全没有跟进，直到他摆出证据表明该工具没有论文里看上去那么好。他反思自己当学生时的心态完全不同——有人指出他的算法找强连通分量的方法错了，他当天回家就把工具改成 Tarjan 算法；一次报告中他漏讲了 SAT 求解器史上的「重启」，被听众当场指出，他为此感到难堪。文章最后说，他看不到好的修法，只是担心在这样的环境里长起来的学生，已经越来越不在意正确性、精度与科学好奇心，甚至觉得他写的这些既陌生又令人反感。15 条评论里，有人不同意文章那种对抗式的归因，认为问题出在系统上，更该做的是让编辑鼓励后续研究、复现与评论，并把这些链接到原论文上；有人反驳说现在研究者面对的审视其实比以前多得多——发现错误的人可以写博客、发推，经济学界已经有人用 AI 复现旧论文并报告问题，还有工具能在投稿前帮着查错；也有人写下一段更常见的经历：几乎每个进学术圈的人都会经过这个幻灭期，权威与派系、人情与交换，本来就在，只是如今的规模与量化指标变了。

14. Page Table Memory Consumption

• 原文入口：frn.sh · Page table memory consumption
• HN 讨论：49916753
• 提交者：shellpipe（提交于 2026-10-01 09:55）
• 快照热度：37 points | 6 comments
• 原文日期：2026-10-01
• 中文要点：这篇文章从 Linus Torvalds 反对哈希页表的一段话讲起（树状页表里相邻页的条目挨在一起，一次缓存行填充就能带进多个 TLB 条目，哈希表却把邻居散到不同桶里），随后把重点转向内存占用。作者算了一笔账：页表大约占被映射内存的 1/512，这个比例在每一页只被映射一次时成立；但如果 N 个地址空间映射同一批页，每个进程都要为它维护自己的页表项，页表的开销就变成 N/512。极端情况下 512 个进程映射同样的页，页表占据的内存与数据页相当——每页 4 KiB、每个页表项 8 字节，512 个 8 字节正好 4 KiB。文章接着回溯了几次真实事故：2020 年 Shakeel Butt 给 memory.stat 加上页表指标，Roman Gushchin 质疑这个统计有没有用武之地，Shakeel 举出的是一个用零拷贝映射应用内存的用户态网络驱动；2002 年 Andrea Arcangeli 发现 64 GiB 的 32 位 x86 机器在有大量空闲内存时仍然 OOM，原因是数百个进程共享 1 GiB 内存、各自的页表又只能待在低位内存区，补丁把页表挪到了高位内存；2022 年 Khalid Aziz 报告了同一形状的问题——一台 512 GB 内存的 Oracle 数据库服务器，在 1,500 多个客户端连上 300 GB 的 SGA 之后被 OOM 杀掉。6 条评论里，有人指出文章虽然批评哈希页表，却没能说明 PowerPC 那套方案为什么更差，按他的分析每个问题在哈希页表下只会同样或更糟，因为哈希也是对虚拟地址做的、同样要为共享物理页保存多份条目；有人说这听起来更像是「应该多线程而不是多进程」的理由；有人提到 Windows 上僵尸进程不占内存却仍可能占着 32 KiB 以上的页表，还举了一个 AMD 集显驱动 bug 导致页表吃掉近 100% 内存的极端例子。

15. Results from the ASIC puzzle

• 原文入口：Jane Street Blog · Results from the ASIC puzzle
• HN 讨论：49934078
• 提交者：eru（提交于 2026-10-02 22:42）
• 快照热度：69 points | 30 comments
• 原文日期：2026-10-02
• 中文要点：Jane Street 在 8 月出了一道题：给出一颗小芯片最终的 GDS 版图，但不给网表，也不给内部信号名，让你把它逆向出来。这篇是公布答案与解题过程的文章。他们收到约 400 份提交，来自 30 多个国家，以美国、印度、英国、澳大利亚最多；参与者里有高中生、研究者、在职工程师和退休人员，多数人用 KLayout、Yosys 与 Z3，另外用 Python、Rust、C++、OCaml、Haskell 甚至 Odin 写自己的工具。谜底是：这颗芯片是 11×11「Star Battle」（又叫 Two Not Touch）谜题的硬件检查器——每行、每列、每个色块里恰好放两颗星，任意两颗星都不能相邻，斜对角也不行。芯片接收 121 个周期的输入，每位表示对应格子是否放星，然后并行做几项检查：每行每列各有 2 位计数器，要求正好是 2；一个 121 位的 ROM 把格子映射到区域，每个区域再配 2 位计数器；一条延迟线负责盯着相邻格子，保证两颗星不挨着；还有一个总星数计数器，用来在某些条件下输出彩蛋。所有检查相与之后得到成功信号。答案字符串存在 ROM 里，并用一个由棋盘驱动的小型 LFSR 做了混淆，成功时解出后输出 (* TWO STARS *)；多数错误解会输出 TRY AGAIN，少数会触发彩蛋。整颗芯片用开源标准单元库 SKY130 与 LibreLane 工具链设计。30 条评论里，有人称赞这类活动给一向封闭的芯片设计行业建起了社区，同时吐槽这是靠高频交易出钱；有人问大模型能不能解出来；一位 Jane Street 的人引用自家招聘口气说，以前要花几小时甚至几天盯着波形和指令轨迹找问题，现在 AI 很擅长调试失败的测试，「这一点我不会怀念」；还有人说让 Claude「对电路做模糊测试」，虽然没按预想的路子走，但最后自己拐到 Z3/SMT 上，三个小时就解出来了。

16. Show HN: AI search for every photo and every frame of video on macOS

• 原文入口：GitHub · SCM
• HN 讨论：49952111
• 提交者：allenleee（提交于 2026-10-04 17:24）
• 快照热度：134 points | 64 comments
• 原文日期：2026-10-03（仓库创建日；项目页本身是 README，不标发布日期）
• 中文要点：SCM 是一个纯本地的 macOS 应用，用自然语言在任意文件夹里搜照片和视频的每一帧，不上传、不注册账号、推理都跑在机器上。它分成几种模式：Files 按语义找整张照片或整段视频，结果按余弦相似度打分并带文件名与短语加权，每张缩略图上有「为什么匹配」的标记；Scenes 先把视频切成镜头再逐个编码，命中直接给到时间码，打开视频就跳到那一刻；OCR 用 Tesseract 在画面和帧里找可见文字，支持英文加 35 种语言开关，命中的词会在图上框出来；Dialogue 用 Whisper 转写做逐字检索，分「整句命中、同一句或 8 秒窗口内命中、同一视频内出现」三档，不依赖向量，模型没启动时也能用；LLMs 是可选项，一个绑在本地回环地址上的 llama.cpp 边车，用已经抽好的对话、OCR 文本和文件名回答问题并给出可点击的编号引用。默认视觉模型是 CLIP，首次使用时下载约 435 MB 权重，之后完全离线。安装走 Homebrew 的 cask（仅 Apple 芯片、macOS 12 以上，安装时自动清掉隔离标记，不用手动过 Gatekeeper），也能用 Bun 自己构建打包。64 条评论里，最集中的担心是时间成本：有人有一万两千个视频，问要先把电脑搁置多久，另一位做过类似工具的人说帧采样率就是全部关键，一秒一帧在一万两千个视频上要跑好几天，只用关键帧才压到一晚；有人推荐跨平台的 Immich 做近似的事；有人问能不能像 iOS 那样搜人、脸和宠物，也有人问在 32 GB 的 M1 上拿两千张库存照片试效果如何。还有一条跑出题外：有人希望照片的向量以后能由相机直接写进文件里。

17. Bill Draper has died

• 原文入口：The New York Times · He Was a Tech Investor Before There Was a Silicon Valley
• HN 讨论：49953288
• 提交者：bookofjoe（提交于 2026-10-04 20:21）
• 快照热度：67 points | 17 comments
• 原文日期：2026-09-30
• 中文要点：Bill Draper 于 9 月 8 日在加州阿瑟顿的家中去世，享年 98 岁，死讯由他的女儿 Polly Draper 确认。他 1959 年到加州，加入父亲 William H. Draper Jr. 参与创办的 Draper, Gaither and Anderson，那被视为密西西比河以西的第一家风险投资公司；他自己有哈佛商学院学位，后来参与创办 Sutter Hill Ventures 与 Draper Richards，与 Arthur Rock、Eugene Kleiner、Thomas J. Perkins、Don Valentine 同属把「风险投资」变成一个数百亿美元行业的那一批人。早年他租了一辆庞蒂亚克，在还是果园的圣克拉拉谷里跑业务，那时企业家几乎没听过「风险投资」这个词。他在 Draper Richards 的同事叫他「Dr. Yes」，因为他喜欢在第一次见面、尽调还没做完时说「我们投」。他押中过的项目包括动视（Activision）、Skype、OpenTable、打印机公司 Qume，以及做除颤器、起搏器和心电监护的 Corbin-Farnsworth。17 条评论里，有人指出 Draper 家已经是第三代做这行，这本身就少见；有人感慨圣克拉拉谷原本是极高产的农业用地，如今被铺成了园区；有人对比两代人的做法，说 Draper 后来去做了公职、资助过 280 家非营利组织，今天那些顶级基金的合伙人大概很难读懂这种选择；有人回忆在旧金山机场旁的酒店蹭过一场会，左边坐着写过多本行业著作的 Steven Levy，右边就是 Bill Draper。

18. Why don't more developers "use the platform"?

• 原文入口：Nolan Lawson · Why don't more developers "use the platform"?
• HN 讨论：49950554
• 提交者：vinhnx（提交于 2026-10-04 12:10）
• 快照热度：272 points | 285 comments
• 原文日期：2026-10-03
• 中文要点：Nolan Lawson 多年来站在「用平台本身」这一边，主张既然浏览器能做，就别自己用 JavaScript 造一遍。这篇他反过来替平台怀疑论者辩护，理由按重要性排：历史——很长时间里浏览器都在追赶长在它上面的生态，jQuery 之类填补了关键空缺，而且还得等 IE6 这类落后的浏览器退出；熟悉度——习惯在 npm 上找 React 组件的人，遇到任何问题都会去 npm 找，而 npm 上不会有一个包写着「直接用 CSS 的 position: sticky」；生态确实填了有用的空档——比如虚拟列表库在内部大量用原生 DOM API 追求性能，对外却给出新手更容易上手的接口，等于把不熟悉的平台能力包成熟悉的形态；文档——很多 npm 包有精心写的 README 与示例，而 MDN 成为公认的 Web 文档入口之前，平台自己的文档是出了名的难读。285 条评论是本期第二多，最集中的一条反驳是围绕原生 <dialog>：开发者选第三方实现，是因为它有更好的可访问性、焦点管理、移动端与读屏支持，也更灵活；「用平台」如果结局是更差的结果，就很难说服人。另一路把原因归到历史偶然：过去平台做不到，要弹窗就得找库，于是开发者被训练成遇到问题先找库，React 出现之后学 Web 开发的人更把碰 DOM 当成坏习惯，现在建议用原生 CSS 也会被人侧目，因为「Tailwind 和 shadcn 才是默认选择」已经成了多数人的习惯。也有人指出文章其实已经把问题回答得很细，还有一条纯粹的题外话是夸另一个项目的名字和 logo。

19. 'Neanderthals Among Us' review

• 原文入口：History Today · 'Neanderthals Among Us' by Peter Sahlins review
• HN 讨论：49947565
• 提交者：pepys（提交于 2026-10-04 04:41）
• 快照热度：52 points | 46 comments
• 原文日期：2026-09-28
• 中文要点：Helen Wickstead 为 Peter Sahlins 的新书《Neanderthals Among Us: The Making of a Prehistoric Human》写的书评。1856 年，工人在德国西部尼安德谷的一个洞里挖出骨头，起初以为是某种老穴熊，当地教师 Johann Carl Fuhlrott 看出这是一个额头低平、眉骨粗大、四肢粗壮的陌生人类，把骨头带到了波恩大学；这批遗骸后来被认定年代久远，可能就是欧洲最早的人群，史称 Neanderthal 1，也是第一个被认定属于另一物种的古代人类。此后 170 年里，尼安德特人是被研究得最多的一类早期人类：欧洲与西亚含化石的考古遗址里出土了 350 多个个体，还有数百处以莫斯特石器为标志的遗址。这本书是第一部完整讲述尼安德特人在科学与流行文化中形象变迁的著作，既有从颅相学式的早期种族科学到古 DNA 分析的科学史，也覆盖了从小说、诗歌、电影到漫画、广告、电子游戏的庞大图像谱系，Sahlins 让科学与流行文化彼此对话，把「尼安德特人」呈现成一个不断变形的嵌合体。书评还讲到更深的文化源头：从古代的萨提尔到中世纪的野人，西方想象里长期住着一类缺语言、缺理性、缺美与节制的「次等人」，它们可以说是尚未命名的尼安德特人；殖民时代的探险者把传说中的野人搬进了关于原住民与类人猿的报告，为 18 世纪的种族科学准备了条件；1856 年之后的颅骨被排进等级，欧洲人置顶、有色原住民在下、尼安德特人在最底层。46 条评论里，有人问现在有没有 23andMe 的替代品；有人顺着一篇 2026 年的研究追问——那次发现杂交主要发生在尼安德特男性与人类女性之间，而不是反过来，随后找到一篇把这归因于择偶偏好的新论文；有人拆解 Homo neanderthalensis 的字面意思是「来自新人之谷的人」，觉得对一个灭绝的人类来说这名字讽刺得刚好；有人推荐 Sahlins 的《Stone Age Economics》；也有人说尼安德特人的消失让人联想到近代族群被抹去的方式，过程往往比后来记住的更漫长。

20. Declaring a bird extinct: The median wait is 36 years after the last sighting

• 原文入口：Birds History · Declaring a Bird Extinct: The Median Wait Is 36 Years After the Last Sighting
• HN 讨论：49948738
• 提交者：Heidi_70（提交于 2026-10-04 07:16）
• 快照热度：18 points | 7 comments
• 原文日期：2026-10-02
• 中文要点：这篇统计的是「最后一次确认记录」与「权威机构第一次正式宣布灭绝」之间的间隔。站点上两段日期都齐全的物种与亚种共 13 个，中位数 36 年，平均 47.5 年，区间从 3 年到 124 年。最短的是 dusky seaside sparrow，最后一只个体 1987 年死在笼中、腿上带着编号脚环，1990 年就被宣布灭绝；最长的是 Kauaʻi nukupuʻu，1899 年最后一次被采集到，直到 2023 年 10 月才从美国濒危物种名单上除名。另外还有 4 种鸟的最后记录分别在 1935、1944、1956、1963 年，至今没有被宣布灭绝。文章解释了这些延迟的来源：IUCN 对「灭绝」的定义是「没有合理怀疑最后一个个体的死亡」，这本质上是一个否定命题，而关于野生动物的否定命题几乎无法证明——没有任何调查能走遍每一道山谷，一种常见时都难找的鸟在濒临消失时只会更难找，没人走过的森林里的「没看见」不等于「不存在」。红名录取要求已知与预期栖息地、在合适季节、覆盖历史分布范围的详尽调查，对只栖身一条沟壑的鸟做得到，对在加拿大北极某处繁殖、在阿根廷潘帕斯越冬的极北杓鹬就等于没说。1980 年代曾有人提出更简单的规则——五十年内没有可靠目击就算灭绝，但它没能经住证据的考验。7 条评论里，站点作者自己第一条就交代了方法，并且提醒样本小、偏重夏威夷，所以这个中位数只描述这些鸟、不是一条普遍常量；他还说明同一只鸟被两次宣布（IUCN 一次、2023 年 10 月美国除名一次）时取更早的那次，否则数字会被抬高。另有评论提到有些数量锐减的种群能适应新环境慢慢恢复，并追问那种适应到底是行为上的还是生理上的。