Soda · Photos 奇鸟行状录
A quiet archive · Est. 2026 · AUG 17, 2026
HN Daily Reading · 每日阅读

HN 每日深度阅读 · 2026-07-14

本期主线是"基础设施与默认设置正在被重新审视"：从 LAPD 终止车牌监控、维基百科暂避英国重度监管、三星以删数据胁迫 AI 训练同意，到潜伏 15 年的内核漏洞与 t.me 域名被注册局冻结，制度与底层栈的脆弱性同时显现；

2026.07.14 20 篇摘录
← 返回每日阅读列表

共 20 篇 · 约 12,414 字 · 约 31 分钟读完

1. Ask HN：2026 年 7 月大家在做什么

这是 Hacker News 每月一次的「Ask HN: What Are You Working On?」帖子，2026 年 7 月版本收到近千条回复，展示了社区成员在业余或创业阶段进行的各类项目。整体上，项目类型延续了 HN 一贯的多样性：独立开发者的小工具、注重隐私的替代品、面向特定语言或地区的垂直服务，以及借助生成式 AI 重新回到创作岗位的个人尝试。

在社交与沟通类项目中，有开发者发布了 Beacon，一款「谁现在有空聊聊」的移动应用：向一组好友同时发起呼叫，最先接听者进入 1v1 通话，其他人静默挂断，试图减轻未接来电带来的心理压力。另一位开发者做了 valuepair.app，一个基于 14 道问题匹配的交友/相亲应用，强调价值观优先、照片最后揭晓。

面向儿童的实体月刊也出现在讨论中：一位家长自建排版工具，制作包含谜题、数学、自然、科学实验和户外寻宝的纸质报纸，主打「无屏幕」教育。

有一位曾参与 RTS 与叙事型 RPG 的资深游戏设计师因健康原因中断职业生涯，通过 Claude Code 重新启动了个人项目 Vestiges——一款 2D 单机 roguelite 策略游戏，玩家通过软件浏览一个人被数字化的记忆。

隐私与替代搜索方向，一对夫妻运营的欧盟搜索引擎 Uruky 达到 250 个月活账户，新增 Monero 支付支持，并承诺付费满 12 个月后开放源码。iOS 隐私照片保险箱 Media Den 也持续迭代。

地区性项目方面，摩尔多瓦的开发者构建了 vorbim.org（面向俄语人群学罗马尼亚语的 AI 生成课程站点）与 domio.md（摩尔多瓦版 Zillow 房产地图）。整体来看，本期帖子中 AI 辅助编程带来的「个人项目产能提升」是一条隐含主线，而独立开发者对隐私、离线、小而美的偏好依然明显。

2. 洛杉矶警局以隐私和公民自由担忧为由，让 Flock 监控合同到期

洛杉矶警察局（LAPD）决定不再续签与车牌识别监控公司 Flock Safety 的三年合同，合同于本周六到期。作为美国第三大警察部门，LAPD 是 Flock 最大的政府客户之一。LAPD 首席信息官 Dean Gialamas 表示，终止合作的原因是围绕这些摄像头所采集数据的隐私、安全和共享问题存在「严重的公民权利与公民自由担忧」，在通过合同条款理清这些问题之前将暂停使用 Flock 服务。此前，加州 Mountain View、缅因州 South Portland 等城市也已因类似理由退出，部分与庇护城市政策下联邦移民官员利用摄像头追踪居民有关。

Flock 在美国部署了至少 8 万台车牌识别摄像头，网络覆盖广泛。近来它面临多重压力：多起因误报导致无辜司机被拔枪拦停或拘留的案例；一名汽车媒体记者因试驾车牌被错误标记为失窃遭警方围堵；404 Media 记录到 Flock 摄像头因配置疏漏暴露在公网、警方账号缺乏多因素认证，甚至有 DEA 官员盗用地方警员密码进行移民相关搜索。多地居民曾以垃圾袋覆盖摄像头进行抗议，而 Flock 在未获地方授权下重装设备的行为也引发争议。

HN 讨论集中在几点。一是 Flock 拥有摄像头及杆件的所有权，合同终止不代表设备停止运转——数据仍可能通过其他机构（CHP、LASD、FBI、Palantir 等）继续被 LAPD 间接访问，被称为「设计上抗政治压力」的模式；有城市在解约后无法合法拆除设备，只能以官方形式用袋子遮挡。二是评论者呼吁立法禁止政府购买其自身无法合法收集的数据或情报。三是有人指出讽刺之处：以民权诉讼赔付金额巨大而闻名的 LAPD，居然是率先觉得 Flock「过火」的机构。也有人担忧后续替代方案（如 Axon Outposts）内含 Amazon Sidewalk 模块，可能带来新的后端连接风险。

3. GhostLock：潜伏 Linux 内核 15 年的 rtmutex 栈 UAF 漏洞

安全团队 VEGA 披露了一枚被命名为 GhostLock（CVE-2026-43499）的 Linux 内核漏洞，存在于自 2011 年 Linux 2.6.39 引入 rtmutex 重写以来的所有主线版本中，直到 2026 年 4 月的 Linux 7.1 才修复，覆盖过去约 15 年内几乎所有主流发行版。触发漏洞不需要特殊内核配置或权限，只需开启 CONFIG_FUTEX_PI，且不依赖 user namespace 或任何 capability，非特权本地用户即可利用。研究者将其构造为稳定率约 97% 的本地提权（LPE）与容器逃逸，通过 Google kernelCTF 获得 92,337 美元奖金。

漏洞根因位于 kernel/locking/rtmutex.c 中的 remove_waiter()。该辅助函数原本假设「当前线程即为需要清理的 waiter」，因此清除的是 current->pi_blocked_on。但在 Requeue-PI 场景中，rt_mutex_start_proxy_lock() 会代表另一个休眠线程排队 waiter，出错回滚时 current 变成发起 requeue 的线程，而不是真正的 waiter。结果是清错了任务：真正的 waiter 线程返回用户态后，pi_blocked_on 仍指向其已弹出的内核栈帧，形成悬垂指针。后续任何走 PI 链的操作（如 sched_setattr）都会解引用这块已释放的栈内存。

由于释放对象位于内核栈，攻击者需要用一次系统调用把可控字节喷洒回同一深度的栈位置，从而伪造 rt_mutex_waiter 结构。文章展示了如何从这一初始原语获得「向受限地址写入指针」或「写入 8 字节零」的能力，并进一步劫持函数表以完成控制流劫持，最终达到 root。lockdep 未能发现该 bug，因为它只校验持有了某个 pi_lock，而不校验持有者是谁。

HN 讨论关注多个方面：漏洞跨越 15 年、影响面极广令人震惊；有研究者在 Android 9/13/16 上进行相关系列测试并触发了 bootloop，讨论是否可用于解锁通常不可解锁的手机 bootloader；也有人尝试在 Rocky Linux 9 上复现未成功，评价作者未直接放出可即用 exploit 是负责任做法。此外有评论调侃写作中大量出现「same shape」等表述，怀疑受到 Claude 等 AI 助手的用词影响。

4. Apple 新 SpeechAnalyzer API 首次基准测试：全面击败 Whisper Small

Inscribe 团队针对 iOS 26 / macOS 26 中新推出的 SpeechAnalyzer/SpeechTranscriber API 发布了首个第三方基准测试，与旧版 SFSpeechRecognizer、以及 WhisperKit CoreML 上的 Whisper Tiny/Base/Small 在 LibriSpeech test-clean 与 test-other 上对比。全部测试在 M2 Pro（macOS 26.5.1）本地完成。

结果显示，Apple SpeechAnalyzer 在干净语音上取得 2.12% WER、在噪声语音上取得 4.56% WER，优于所有测试的 Whisper 模型（Small：3.74% / 7.95%），同时速度约为 Whisper Small 的三倍。而它取代的旧 API SFSpeechRecognizer 表现最差，干净集 9.02%、噪声集 16.25%，甚至不如 40MB 的 Whisper Tiny。作者据此建议仍在使用旧 API 的应用应尽快迁移，新 API 在准确率上没有任何取舍，还能直接输出带标点和大小写的文本。

方法学上，团队使用与 Inscribe 用户相同的生产代码路径，对所有引擎使用统一的文本规范化器（对齐 OpenAI 英文 normalizer），采用 corpus WER 而非平均 WER，并强制 SFSpeechRecognizer 走本地识别以避免与云端结果混淆。Whisper 列作为可验证的对照：三个模型在两个 split 上的 WER 与 OpenAI 官方数字均只有约 +0.1 至 +0.4 的一致小偏移，符合诚实复现的特征。所有 5,559 条 Apple 引擎逐句转写结果均公开下载。作者也承认局限：仅覆盖英文朗读语音，且 SpeechTranscriber 只支持约 30 种语言，Whisper 在多语种和跨平台上仍具优势。基准测试过程中还意外发现 Inscribe 自身一个未调用 finalizeAndFinishThroughEndOfInput() 导致文件导入卡死的 bug。

HN 讨论较集中的批评是：Whisper Tiny/Base/Small 已近四年未更新，未包含 Whisper v2/v3、Large-v3 Turbo，也未与 Nvidia Parakeet/Nemotron、Mistral Voxtral、Cohere Transcribe 等更新的 SOTA 模型对比，说服力受限；有用户在数学讲座实测中反映 SpeechAnalyzer 比 Whisper-Large-V2 快很多但准确率略逊。另一条主线是围绕大量「Whisper 套壳」的付费转写应用的前景讨论：Apple 迟早会内置类似录音/转写 GUI，压缩这类第三方应用的生存空间。也有开发者已尝试将其接入 Handy 等开源项目。

5. Climate.gov 被下线后，靠公有领域数据得以在民间重建为 Climate.us

文章记录了美国气候数据门户 Climate.gov 在特朗普政府大幅削减 NOAA 预算后被下线的事件，以及三名前 NOAA 雇员——Rebecca Lindsey、其姐 Mary Lindsey 和前同事 Anna Eshelman——如何组队将其重建为 Climate.us 的过程。新站点保存了超过 15 年的关键气候数据与资源，包括关键地图、教育材料、气候指标报告，以及一度面临从公共视野中消失风险的《第五次国家气候评估》。

作者指出，这次「民间接管」之所以可能，是因为美国联邦政府的数据依法属于公有领域。若非如此，此次行政层面的下架就等同于数据永久丢失。新站点提供了气候仪表盘（例如追踪每年 9 月北极海冰至少 15% 覆盖面积）、教学资源、以及 NOAA 收集的受气候变化影响者口述历史档案等数据集画廊。但作者也强调，该项目依靠捐款维持运转，本应由税收支撑，脆弱性明显。

HN 讨论分为几条主线。一是运营可持续性问题：静态历史数据可以镜像保存，但持续的观测、采集与分析需要长期资金和基础设施，民间团体难以替代政府机构角色。二是原则层面：不少评论者认为政府发布的所有数据都应默认公有领域，也有人提出静态政务内容应默认通过 IPFS 等分布式方式发布与归档，避免单点失效。三是关于监管者自我监督的怀疑：有评论指出让负责限制排放的政府机构同时掌握其数据既得利益冲突，认为独立科学家和公民社会的数据采集反而更值得信赖。也有人半带讽刺地表示，此次事件某种程度上「证明了 DOGE 削减开支的观点」——新的 Climate.us 成本可能只是原站的一小部分。

6. densha：与日本实时同步的体素东京，边坐山手线边学日语

densha 是一个网页项目，将玩家置于一个体素风格的东京场景中，沿山手线循环行驶，画面与日本的真实时钟、天气和季节保持同步，背景播放 lofi 音乐，同时以字幕和 TTS 朗读 N5 级别的日语句子飘过，定位为「按下播放键即进入的沉浸式日语学习房间」。建筑数据来自日本国土交通省 Project PLATEAU，地形来自 GSI Japan，均以 CC BY 4.0 授权。站点显示当前有数百名用户同时在线，句子累计学习数以万计。

HN 讨论氛围整体友好，但也集中反映了几类问题。语音方面，多位评论者指出 TTS 存在明显问题：第一句就忽略了振假名而误读；即使不刻意听角色感，也能感到某种节奏或时序上的「不自然」，建议更换 TTS 方案。可读性方面，字幕文字与不断变化的体素建筑窗户灯光叠加，对比度不足，导致阅读吃力。性能方面，有用户反馈网页在浏览器中占用大量资源，风扇满转，甚至难以关闭标签页；iPhone 用户报告页面触发音乐播放且直至重启才停止，怀疑存在异常行为。

也有关于产品定位与体验的讨论：有评论者认为进入页面后长时间只看到城市从眼前飘过，并没有真正「坐上电车」的感觉，也不清楚具体的「练习」形式是什么，希望作者澄清学习闭环。项目美术风格获得普遍好评，晚间模式被拿来与《攻壳机动队》中的「追踪 UI」类比。另有开发者表示正在做类似产品，希望联系作者合作。此外一条高票评论借题发挥吐槽了德国 IC 列车的严重延误，与作品营造的电车氛围形成对照。

7. Telegram 的 t.me 短链域名遭注册局 serverHold 暂停

根据 Whois 记录，Telegram 用于分享频道、群组和用户链接的短域名 t.me 出现了多个限制状态，其中最关键的是 serverHold——这是由 .me 注册局（而非注册商 GoDaddy）主动施加的状态，意味着该域名被从 DNS 中移除、无法解析。域名本身注册于 2010 年，登记至 2035 年，注册商为 GoDaddy，注册人通过 Domains By Proxy 隐私保护，DNS 使用 Google Cloud DNS。多个 clientDeleteProhibited / serverDeleteProhibited 等状态同时存在，表明域名不会被立即删除，但当前无法正常使用。

由于 t.me 是 Telegram 生态几乎所有对外链接的入口——邀请链接、频道、机器人、Web 登录等——其解析失败会广泛影响频道推广、外部跳转和第三方集成。备用域名 telegram.me 目前仍可作为替代。

HN 讨论主要有几条主线。一是围绕 serverHold 状态含义的技术解释：多位评论者引用 ICANN 文档说明该状态通常出现在法律纠纷、待删除、联系人验证问题、注册商转移问题，或涉及垃圾邮件、钓鱼、恶意软件、商标/域名抢注等场景，并特别指出 clientRenewProhibited 是不常见的状态，多与法律争议或删除处置相关。二是围绕可能的原因猜测：Telegram 近期在俄罗斯（涉极端主义调查）、法国（Durov 相关司法程序）和印度（被指被用于国家考试作弊/泄题）均处于监管或司法压力下，评论者倾向于认为印度案由时间上最接近。三是运营层面的批评：许多人对如此关键的域名居然托管在 GoDaddy 表示惊讶，认为 Telegram 应考虑申请并运营自有 gTLD（如 .tgrm）以掌控关键基础设施。也有开发者庆幸自己长期坚持「对外邮件永远使用自有域名重定向、不直接嵌入第三方链接」的 SOP，使得此次事件影响最小化。

8. 无回锋书写：为英文草书重新设计字母

作者从个人书写体验出发，指出拉丁字母草书的一个隐藏痛点：i 上的点、t 和 x 的横竖交叉，都要求写完主体后再回头补一笔，这种”回锋”（backtracking）打断书写节奏，还要在脑中维护一个待补笔画队列。作者先学的是西里尔字母，后来才用英文思考和书写，因而对比明显——俄文中只有 й 和 э 需要回锋，ё 上的两点还常被省略。

为量化差异，作者统计了《罪与罚》俄英两版：英文有 51% 的单词需要回锋，平均每词 0.68 次；俄文仅 6.4% 的词需要，平均 0.066 次。数字笔记软件里回锋更烦，因为撤销以笔画为单位，删掉一个多笔画的词要多次操作或用橡皮擦。

作者基于 SmithHand 草书并借鉴俄文学校体，设计了一套无回锋拉丁字母：x 改为两个镜像的 c；t 用一段回上再向左下的辅助线一笔连成，形似反转的数字 4，这种写法在瑞士老式 logo 上仍常见；i 和 j 最难，最终方案是在中线上方写一个小圈并顺势向下拉出竖笔，圈的位置和对齐至关重要，否则容易被误读为 ε 或 r。大写字母中 T、F、K 也做了小幅调整。作者已使用数月，声称写英文终于和写俄文一样愉悦。

HN 讨论集中在几个方向：一位美国用户回忆学校教的 Zaner-Bloser 体同样追求少提笔，但成年后循环的圈会使 l 和 e 难以区分，后来自己转向 Italic 手写体，笔画更多但更易读；不少评论者认为该设计”优化了写，牺牲了读”，尤其新版 i、j 和 tt 连字识别成本更高。荷兰、德国读者指出他们从小学的 t 本就是无回锋写法，只是近几十年被英式写法取代。也有人建议对更极致的效率追求者尝试 Melin 等正字法速记系统。还有讨论辨析”backtracking”一词是否准确——很多”修正后”的写法本身包含回描既有笔迹，或许”annotation”更贴切。另有俄语/白俄罗斯语使用者反驳称西里尔字母同样需要不少回锋（如给 ш 加下划线区分 т），并不构成困扰。

9. 不打开 Xcode 也能构建和发布 Mac/iOS 应用

针对近来播客中”Xcode 难用、应该更适合 vibe coding”的抱怨，作者提出另一条路径：Xcode 必须安装，但完全不必打开。xcodebuild、notarytool、stapler、devicectl 等命令行工具都随 Xcode.app 附带，可从 shell 直接调用，配合 LLM 编码代理即可完成从构建到公证再到安装的全流程。

一次性 GUI 设置包含：确保 xcode-select 指向 Xcode.app 而非独立 Command Line Tools；接受许可并运行首次启动；在 Xcode 设置里登录 Apple ID；创建 Developer ID Application 证书（与 Apple Development 证书不同，前者用于分发时通过 Gatekeeper）；在终端用 notarytool store-credentials 保存一次公证凭据（需 App 专用密码，非 Apple ID 密码）。作者提醒凭据要以 app 命名、Apple ID 密码变动后会静默失效导致 401 错误。

工具链方面推荐 XcodeGen：Xcode 的 .xcodeproj 实际是文件夹，Xcode 会频繁改写引起 git 冲突，XcodeGen 允许仅提交 project.yml，每次构建重新生成整个工程。签名密钥存于 login keychain，xcodebuild 自动查找，团队 ID 等敏感字段放在被 gitignore 的 Local.xcconfig。最后由 Claude Code 生成一个 release.sh，串起 archive → 签名 → 公证 → staple → 安装到 /Applications 的整条链路。作者的哲学是：任何不想手动做的事都告诉 LLM 去处理。

HN 讨论呈现几种态度。安全派担心让代理直接在宿主 Mac 上跑意味着放弃多年沙箱实践，近期 xAI 上传用户 home 目录（含 SSH 密钥）事件加剧了这种顾虑，有人在考虑用独立用户加 700 权限隔离。工具派推荐了替代方案：xtool 支持在 Linux 上构建 iOS 应用并通过 USB 部署到 iPhone；Axiom 提供 xclog/xcprof 等对 LLM 友好的 token 高效命令；swiftbundler 也是选择之一。一位老开发者提醒把整个 app 组织为 Swift Package、Xcode 工程只留一个调用 app_main() 的文件，可基本摆脱 pbxproj 冲突。也有人指出用 CLI 发布 app 是从 2012 年就有的老实践，“不打开 Xcode”其实一直可行，只是文章把它与 AI 代理工作流结合得更彻底。文中反复出现”有疑问就问 LLM”引来调侃：连这篇博客本身读起来也像 Claude 在说话。

10. Clawk：给编码代理一台一次性 Linux 虚拟机，而不是你的笔记本

Clawk 试图解决自主编码代理落地时的两难：要么每条命令都点确认成为人肉守门员，要么用 —dangerously-skip-permissions 放开权限、面对 rm -rf 或令牌泄露的风险。它提供第三条路——cd 进仓库，输入 clawk，Claude Code、Codex 或普通 shell 就跑在一台一次性 Linux 虚拟机里，代码通过挂载共享，代理在 guest 中拥有 root，但宿主的文件、钥匙串、其他资源都在隔离墙外。

关键设计包括：任何 OCI 镜像可作为 rootfs，无需 Dockerfile 或 devcontainer；网络出站基于白名单，github.com 等预置允许，未知域名连接被拒绝；ssh-agent 转发进 VM，git push 可用但私钥不进入 guest；每个项目或工单一个沙箱，可并行运行，空闲 VM 自动释放内存并挂起到磁盘；VM 被搞坏后 clawk destroy && clawk 即可重来，代码与代理对话历史保存在宿主，—resume 恢复会话。

作者强调选 VM 而非进程沙箱的理由：独立内核、常规 Linux 用户态、guest 内 root、可安装系统包/运行后台服务/加载模块/绑定特权端口，甚至在硬件支持时可在 VM 内跑 Docker 和 Kind。安全边界是 hypervisor 而非提示词或策略规则。但项目也坦承局限：白名单只挡未知服务器，代理能读到的任何东西都可能通过已允许通道外泄。目前要求 macOS 14+ Apple silicon，Linux 通过 firecracker 实验支持。

HN 讨论涌现出大量类似项目，反映出这是一个明显痛点。有人提出更彻底方案：独立机器跑 QEMU/KVM 加代理服务器隐藏凭据。flar 走轻量路线，用 bubblewrap 命名空间秒起而非 VM。agentjail 使用 macOS sbpl 和 OPA 策略实现毫秒级启动的原生沙箱。yoloAI 支持 Docker/Podman/gVisor/Kata/Firecracker/Apple containers 等多种后端并保护工作目录。Katsuobushi 基于 microvm.nix 为 Nix 用户量身打造。还有人用 Podman + Arch 镜像挂载项目目录得到简易方案。技术细节层面，有开发者好奇 clawk 如何在不需 root 的前提下实现网络白名单，自己的项目最终仍需 nftables 例外。也有评论提醒读者：该项目名义上支持 Linux，但目前基本是 macOS-first。

11. 三星健康 App 拒绝 AI 训练即删除用户健康数据

据 Neowin 报道，三星健康 App 在改版后向用户呈现新的数据授权条款：如果用户不同意其将睡眠、用药、医疗记录、生理周期这四类敏感健康数据用于训练 AI，App 将删除这些数据。换言之，用户面对的是”授权训练”或”失去这部分功能”的二选一，而非常规意义上的可选加入。

文章指出这属于近来常见的”胁迫式同意”模式：厂商把原本独立的数据处理用途与核心功能捆绑，使拒绝的成本高到用户难以承受。评论区对做法本身的合规性提出多重质疑：在欧洲，这类捆绑可能与 GDPR 关于同意必须自由给出的要求相冲突；在美国，是否触及 HIPAA 也被讨论，尽管 HIPAA 通常只覆盖医疗机构而非消费级设备厂商。日本市场用户则反馈在自己的 Watch 6 Classic 上没有看到相应开关，说明策略可能按地区分阶段推行。

用户使用体验层面的抱怨集中在三星健康 App 本身：Galaxy Watch 硬件和手表端 One UI 评价不错，但手机端 App 长期充斥课程和视频广告；导出个人数据功能存在缺陷，会跳转浏览器报未登录错误，并要求访问全部照片视频权限；改版后自动加入无用卡片，还出现”数据未同步到三星账户”的提示。

对比讨论中，多位评论者指出 Google Gemini 也采用类似模式——个人付费账户想禁用训练只能连带关闭聊天历史，而 Workspace 账户则可两者兼得，这被视作对个人用户的差别对待。有评论总结道，问题不在于公司偶尔管理不善数据，而在于它们的行为持续迫使用户呼唤更强的监管。另有用户提醒，三星手机的一个优点是可以完全不注册三星账户使用，因此避开这类条款的方式之一就是从一开始不接入其云服务生态。

12. Sega CD《Silpheed》的艺术与工程

Fabien Sanglard 花两周逆向了 Sega CD 版《Silpheed》的 FMV 格式，这次没有写代码，而是借助自制的 AI 框架完成。文章回顾 90 年代 CD-ROM 加入主机的悖论：容量是卡带的 320 倍，但寻道 800ms、单速带宽仅 150 KiB/s，反而比卡带慢得多。Mega-CD 上大量 FMV 游戏因此声名狼藉，而《Silpheed》却以精致美术和令人瞠目的动画成为例外，玩家难以分辨哪些是实时 3D、哪些是预渲染。

技术约束令人震撼：近全屏过场跑在 12.5MHz 的 m68k 上，16 色，总带宽 150 KiB/s，扣除 16-bit 16kHz 音乐后，15fps 视频流每帧只剩约 8 KiB。文章详细描绘了 Genesis 与 Mega-CD 的双系统架构：主机侧的 MC68000 加 VDP 加 Z-80 音源，扩展口连接 Mega-CD 侧另一颗 12.5MHz MC68000、Word RAM、Program RAM、Ricoh PCM 与图形 ASIC，两者通过共享内存和模拟音频混音协同，同步问题相当棘手。

《Silpheed》利用这套架构分工：Sub-CPU 在 Word RAM 中以 L1 双缓冲模式生成背景 B 的 tile 和 tilemap，同时主 CPU 处理含 HUD 的背景 A 与前景精灵层。文章后续拆解了其视频格式如何在极窄带宽下模拟 3D 观感。有 HN 评论精辟指出：本用于位图旋转与字体渲染的 ASIC 被以近似 MPEG 的方式挪用，是全片最巧妙之处。

评论区充满怀旧氛围。有玩家回忆 12 岁时第一关激光撕裂舰队、碎片布满屏幕的震撼，并指出 Sega CD 本身完全没有 3D 能力，只有 2D 旋转缩放，GameArts 用带锯齿的 FMV 骗过了眼睛。另有评论推荐 demo 场景团体 Titan 的《Overdrive 2》，展示原版 Mega Drive 能被压榨到何种程度。也有人对文章提到的 Mega Drive I 音频线路做了补充：机型本身扩展口就有声音输入，Mega CD 的音频混音路径比文中描述更复杂。对作者提到的”AI 辅助工作流让写作更愉悦”，也有读者好奇细节，期待其下月开源框架。

13. 前沿模型的真实价格：同样的 TypeScript 在 Claude 上比 GPT 贵 73%

文章核心论点是：模型账单等于”内容被切成的 token 数”乘以”每 token 单价”，而 pricing 页只公布后者、把前者当常量。实际上不同厂商的 tokenizer 差异巨大，$/Mtok 无法跨厂商直接比较。作者用 16 份真实素材（英文散文、HTML、JS/Python/TS/Rust、JSON schema、中文对话、agent system prompt 等）通过各家官方计数端点逐字节测量。

关键发现一：Anthropic 新 tokenizer（Sonnet 5、Opus 4.8、Fable 5 使用）相比旧版（Sonnet/Opus 4.6）在同一内容上多产生约 30% 的 token，list price 却未变。TypeScript +31%、Rust +29%、Python +23%、系统 prompt 甚至 +39%，中文散文几乎无变化，涨幅集中在英文和代码。Opus 4.8 名义 $5/$25，实际相当于 $7.50/$37.50；Sonnet 5 目前 $2/$10 的引导价堪堪抵消，2026 年 9 月 1 日恢复 $3/$15 后同工作量将比 Sonnet 4.6 贵约 1/3。作者用真实付费请求校验，count_tokens 预测与账单完全一致，Fable 5 与 Opus 4.8 token 数相同、没有隐藏加价。

关键发现二：以 GPT 的 o200k 为 1.00x 基准，Claude 新 tokenizer 在 TypeScript 上为 1.73x、Rust 1.58x、JS 1.52x、Python 1.50x、英文散文 1.40x。TypeScript 差距最大是因为 o200k 对 web JS/TS 尤其高效（约 4.24 字符/token），camelCase 和 JSX 常压缩为单 token。中文上 Claude 长期约为 GPT 的 1.45–1.55x，与 tokenizer 版本无关，而 Gemini 在中文上反比 GPT 更高效。

HN 讨论对该分析既肯定又批评。肯定方指出 OpenAI 至少公开 tokenizer 且两年多未变，Anthropic 则不公开，只能通过免费的 count_tokens 端点测量；实测 90k 行 C++ 代码 GPT 1.12M vs Claude 2.2M，30k 行 TS 代码 260K vs 437K。批评方认为文章遗漏了更大的成本因素：KV cache 读写价格、输出 token 数量、tool call 反馈回 input 等，agent 场景下多轮上下文导致的实际支出可能远高于单次 prompt 1.7x 的差距；此外 16 份小样本、最长仅 15K token 也不能代表真实生产负载。也有评论把这一现象引申到激励结构：按 token 计费本质上鼓励模型输出更多 token，就像按小时计费的合同工鼓励拖延。playcode.io 团队本身分享了在产品中切换默认模型的经验：Opus 4.8 消耗过快，Sonnet 5 对中小企业网站生成够用，Fable 5 完全用不起，Grok 4.5 意外稳定。

14. 摩尔斯电码的”绝对魔力”仍在全球连接人们

BBC 报道英国布里斯托附近的 Shirehampton 业余无线电俱乐部，一群爱好者带着轻便天线和摩尔斯电键在山坡上向未知发出”有人在吗”，等待远方陌生人以点划回应。欧洲摩尔斯俱乐部网络主席形容这种跨越距离的人际接触是”绝对的魔力”，并称越来越多年轻人出于纯粹好奇加入、随后深深爱上。他强调，“如果服务商关掉路由器我们就没信号了，但业余无线电依然会在”。俱乐部主席 Paul Roberts 参与 Parks on the Air 活动，操作者在自然公园架设电台、根据联络到的欧洲及更远地点得分，“有些人年纪大爬不动山，但我们还是去”。成员 Chloe Barker 说，联络到罕见呼号国家时会兴奋地跑去告诉俱乐部。

HN 评论区呈现出一个远比新闻热闹的爱好者社区。一位十年前做了个”只能用摩尔斯电码敲一个按钮聊天”的公共网站的用户表示，围绕它成长起来的社区让他惊讶，来自世界各地各年龄段。有人分享贝尔晚年失聪、开会时助手在桌下用摩尔斯 + Phillips 简语在他腿上敲问题、无人察觉的轶事，并推荐 1990 年代出版的《Victorian Internet》讲电报如何塑造世界。也有人指出 Nokia 手机短信提示音”…— …”正是摩尔斯的 SMS。

多条评论谈到摩尔斯为何在应急场景下仍是理想手段：可通过无线电、光、声甚至拍肩传递；自同步、无需两端时钟对齐；抗损容易恢复，丢几个字符仍能重新识别，比 ASCII 稳健得多。K1USN 俱乐部举办限速 20wpm 的比赛帮助新手过渡。技术玩家分享了自己入坑经历：先玩低功率便携电台、SSTV 图像和 FT8 长距离签到，接着尝试写摩尔斯软件解码器，发现要达到人类识别水平出奇地难。老 ham 能在几乎全是静电的信号中抄出内容，被形容近乎超能力。对”竞赛派”只交换呼号和格式化 5-9 信号报告、并不真正对话的做法，也有人表达不解。工具方面推荐了 Morserino 学习器（支持 WiFi 通过 vband 在线练习）和 fieldspotter.radio 查看野外活动分布。

15. 对话的”社会物理学”：沟通模式决定群体表现

文章基于 MIT 人类动力学实验室主任 Alex Pentland 的研究展开。研究团队为 2500 多人佩戴电子传感器，记录语调、肢体语言、轮流发言、谁与谁说话、说多久等交互模式，而非谈话内容本身。结果发现：沟通的结构比内容更能预测团队表现，其预测力相当于智力、性格与才能之和，研究者甚至无需了解团队成员或工作内容即可判断哪支队伍会胜出。

Pentland 将这种现象称为”想法流动”（idea flow），并归纳出三项关键指标：能量（成员之间交流的频率与质量，面对面尤为有效）、参与（成员之间直接对话，而非全部经由中心人物中转）、探索（团队向外部获取视角的程度）。高绩效团队中，成员发言与倾听大致均衡，贡献简短，彼此直接对话，并存在被主持人常常压制的”两人窃窃私语”式旁支对话——这些恰恰是想法被检验和发展的场所。相反，看似最有秩序、一人发言全场倾听、一切经由中心的会议，往往生产力最低。

文章将常见的”轮辐结构”（所有对话经过一位处于中心的主持者）与”网状结构”（想法在所有成员间流动，中心是共同问题而非个人）对比，指出前者会形成信息瓶颈，抑制集体智能，而这种结构常常并非人为造成，而是由房间布局、座椅方向等物理环境隐性塑造。

Pentland 团队在一家银行呼叫中心的实验尤具说服力：仅仅把咖啡休息时间调整为团队同时进行，最低绩效团队的平均处理时长下降超过 20%，全中心平均下降 8%，无需任何培训或流程改动。文章由此建议：为集体思考设计的场合应允许有意义的休息、非正式对话与走廊闲聊，因为真正重要的交流常常发生在正式议程之外。

HN 评论中，有读者分享类似经验，例如刻意安排客户会后经过厨房停留闲聊，往往能获得项目最关键的方向指引；也有人补充信任、团队规模、团队授权同样是重要因素。有人质疑文章过度绑定”生产力”这一西方语境概念，也有人追问该模式在远程办公环境下如何适用。还有评论认为，若能改造正式会议本身减少表演式沟通，对”水房闲聊”的依赖也会降低。

16. Wikipedia 暂时逃过英国《在线安全法》Category 1 认定

维基媒体基金会发布特别报告，宣布 Ofcom 于 2026 年 7 月 10 日通知基金会：基于对法律的一种”新颖解读”，Wikipedia 目前不被认定为英国《在线安全法》（OSA）下的 Category 1 服务。但 Ofcom 同时把 Wikipedia 列入”观察名单”，意味着其身份随时可能被重新评估。

OSA 于 2023 年通过，2027 年起将对最热门服务施加额外义务，分类依据是用户规模与功能特征，而非风险级别。Category 1 服务被要求建立身份注册系统，并限制全球范围内未”自愿”提供真实身份用户的编辑权限——这与 Wikipedia 依赖匿名/化名编辑、社区自治的核心价值直接冲突。

基金会曾在 2023 年联合 Wikimedia UK 等发起游说，未能阻止立法通过。2025 年 5 月，基金会将分类细则告上法庭，编辑 Zzuuzz 作为个人用户加入诉讼，形成罕见的”平台运营方与其用户合作”的司法挑战。2025 年 8 月高等法院驳回诉讼，但明确表示这一驳回”不是给 Ofcom 与国务大臣的绿灯”，若最终监管方案严重妨碍 Wikipedia 运营，政府可能须修改法规或豁免特定类别服务。法官特别称赞 Zzuuzz 的陈述”详尽而有力”。

基金会表示，虽然目前松了一口气，但由于缺乏明确且可持续的分类边界，Wikipedia 仍然脆弱，将继续推动对公共利益空间的正式且永久豁免。

HN 讨论多集中于对英国监管路径的忧虑。有评论对比英美法律传统：欧洲更常出现”法律上违规但执法机关暂不追究”的默契，美国则更强调法律文本。多位评论者认为这是政府对互联网过度干预的典型体现，“暂时不认定”实际是”随时可以认定”的悬剑；有人指出身份验证应默认非法，需要业务方证明确有必要；亦有评论将其与东欧曾经的威权体制类比，表达对英国治理方向的失望。也有人指出，与其对整个互联网施加身份验证要求，不如把资源用于真正针对儿童性犯罪的执法。

17. Logseq 2.0 Beta 发布：转向数据库存储引发争议

Logseq 发布 2.0 Beta，是其”数据库版本”（DB version）的首个公开测试版。项目团队称经过长时间等待，2.0 终于交付用户试用，同时也宣布 Logseq 将分裂为两个版本——传统的 Markdown 文件版与新的 DB 版并行维护。发布说明强调 Beta 阶段可能存在粗糙之处，鼓励备份数据后再试。

HN 讨论围绕这一架构转变呈现明显分裂。批评意见指出：Logseq 长期停留在维护不力状态，桌面端仍基于已经过时（因而存在安全隐患）的 Electron 版本；等待多年，最终交付的却是一个牺牲纯 Markdown 存储换取解决内部技术债的数据库格式。在 Claude 承担半数编辑、jujutsu 追踪变更的当下，放弃平文件对不少用户而言反而是倒退。另一常见批评是”永久 Beta”式开发模式：稳定版本长期不更新，QoL 改进只在不稳定分支中出现，令 Logseq 难以推荐给普通用户，许多人已迁往 Obsidian。

支持者则表示，DB 版本已作为 nightly 使用近一年，是他们用过最好的笔记与组织工具，可对块打标签形成类型化实体（项目、作者、引言、想法），录入门槛极低、检索方便，虽然 Assets、Library 等概念仍显半成品，但方向令人期待。有评论持中立立场，认为 Logseq 处境尴尬：DB 是更整洁的存储方案，但会被直接拿来与以文档为基本单位的 Obsidian 对比，而 Logseq 的基本单位是要点（bullet）；开源与格式可移植性是其优势，但双向同步等关键功能仍标注”进行中”。

也有用户询问是否有类似 Roam 的大纲工具替代品，或分享自建方案：Markdown + git + 浏览器编辑。针对”数据库让 LLM 难以操作”的担忧，有评论指出 DB 版桌面应用附带完整 CLI，可供 Claude Code 或 Codex 与 Logseq 图交互。

18. DOM-docx：HTML 片段转原生可编辑 Word 文档的开源库

DOM-docx 是一个 MIT 许可的开源库，用于将语义化 HTML 片段转换为原生、可编辑的 Word 文档（OOXML），支持段落、行内元素、列表、表格、图片，输出的是真正的 Word 结构而非截图或布局 hack。库使用 TypeScript 编写，要求 Node.js ≥ 20；默认的 inline 路径纯 JS 实现，不依赖浏览器或 Playwright；仅在需要通过 getComputedStyle 解析样式表/类选择器（computed 模式）或对 canvas/复杂 SVG 做位图化时才需要 Playwright + Chromium。

功能覆盖标题、段落、有序/无序列表（含 list-style-type）、表格、链接、行内格式、块背景、引用块、<hr>、简单 flex 行、data: 图片与自定义 imageResolver 处理远程图片，页面尺寸/方向/边距、字体、元数据、页眉页脚 HTML、页码、目录与语言方向也都支持。可选路径可将 Highcharts 之类复杂 SVG/Canvas 光栅化为 PNG 后嵌入。当前尚不支持 inline 路径下的外部样式表、web 字体、CSS grid/float、表单、<pre> 精修、<dl>、表格 rowspan 等。

作者最有意思的开发方法是采用 Karpathy 的”Autoresearch”式回路验证保真度：先在 Chromium 中渲染 HTML 截图，用 dom-docx 转 docx，再用 LibreOffice 将 docx 栅格化截图，与浏览器截图打分对比布局保真度、可编辑性和速度，将分数反馈迭代改进。仓库中提供了测试分数与评分方法文档。

HN 讨论正面居多。作者本人现身说明动机：日常在做后端文档生成，模板与后端代码更新繁琐、错误晦涩、重建循环漫长，更希望用 React/Vue 生成 HTML 后直接转 docx，但现有 OSS 库输出的 Word 结构并不真正可编辑，因此启动这个项目。评论者认为截图对比打分的验证回路是保证布局保真的巧妙做法；有人指出 Pandoc 虽能完成类似任务，但并非 TypeScript，这一点让本项目在前端工程栈中更具吸引力。也有评论期待这类技术能反哺浏览器的打印和”另存为 PDF”体验，有人询问是否支持 docx → HTML → docx 往返，还有人分享自己在 PPTX 领域做类似工作时遇到的 MS 与 LibreOffice XML 实现差异的挑战。也有评论感慨：在 2026 年仍需要有人做这件事本身就颇为荒谬。

19. 用现代工作负载测试 15 张”电子垃圾”级 GPU

作者对多款已退役的 NVIDIA 数据中心 GPU 进行系统基准测试，动机是这些 EOL 硬件目前是少数仍可低价购得的大容量 VRAM 来源：K80（24GB GDDR5）约 60 美元、P100-16GB 约 75 美元、V100-16GB 不到 200 美元。搭配同样廉价的 X99 Xeon E5 平台（如 40 美元的 56 线程 E5-2690、200 美元的 Supermicro X10DRG-Q 双路 7 PCIe 主板），可以搭建家用实验室级的 4U GPU 节点。

作者反驳”这些硬件已 EOL、能效低、不该再用”的说法，认为对家用实验室（homelab）而言这种”手指摇动”并不合理：软件层面通过稍旧版本可绕过，llama.cpp 支持多种 CUDA 架构，通过 Docker 甚至能在 2014 年的 Kepler 架构上跑起所有测试；能效对 7×24 高可用场景确实重要，但家用场景本可按需开关机。

基准套件已开源，测试项覆盖 ResNet50 训练与推理、Blender GPU/CPU 渲染、Vision Transformer、llama.cpp 上 Qwen2.5-1.5B/Llama3-8B/Qwen1.5-MoE 的 prompt 处理与生成、Folding@Home 单/双精度、SHA-256、Whisper Medium FP16 以及 gdsio 存储→CPU→GPU 吞吐等。每个 GPU 会分别在单核、全并行、多 GPU 原生三种模式下测试。

HN 讨论补充了大量实践经验。有用户使用 6 张 75W、8GB 的 Tesla P4（约 80 美元/张）配合 Xeon E5 2696v3、48GB DDR4 组成 48GB 虚拟 GPU 池，在 20–30B Q4KM 稠密模型上得到 7–12 t/s，痛点是 prompt 载入比现代 tensor core 卡慢几分钟数量级。另一评论者选择 32GB 的 Radeon Pro V620，因其仍受当前 ROCm 支持且较同价 NVIDIA 卡更新，双卡 64GB 可流畅跑 Gemma 4 31B 4-bit QAT，但也提醒 eBay 上老卡价格已被抬高，或不如直接购买 Radeon AI Pro R9700（1400 美元）或 Intel ARC B70（1000 美元）。有人希望看到 PS5 芯片衍生的 bc-250（约 200 美元）加入对比。另有工程师回忆当年批量退役 K80 时它们已因反复冷热循环变得不稳定；也有人指出该文章图表以位图形式加载 7MB 略显臃肿。还有评论感叹：在 HN 关于 GPU 的讨论里已看不到 PC 游戏的踪影。

20. Linux 0.11 的”惯用 Rust”重写版：可在 QEMU 上引导

项目 linux-0.11-rs 使用现代 Rust 从零重写了 1991 年的 Linux 0.11 内核，可在 QEMU 模拟的 i386 上引导，运行完整的 init → shell → coreutils 用户态栈，并提供一键构建可引导磁盘镜像的工具链。作者强调保留原系统的语义，但重新用更强的类型、清晰的模块边界和惯用抽象来表达。

内核层面覆盖了 Linux 0.11 的大部分特性：进程管理、按需分页与 CoW fork 的虚拟内存、Minix v1 文件系统、ATA 磁盘驱动、VGA + PS/2 控制台、8250 串口控制台、TTY 层、信号与完整的系统调用表（软驱支持有意省略）。用户态方面，user_lib 模仿 std::{fs, io, path, env, process, time} 的公开形状，让用户程序像普通 Rust 代码而非系统调用胶水；用户程序含 80 多个 coreutils 与一个手写的 POSIX 子集 shell，支持管道、控制流、函数、glob、命令与算术替换、Tab 补全与历史。项目附带 devcontainer、端到端串口驱动测试框架，以及可独立使用的 mbrkit 与 miniximg 镜像工具箱。

HN 讨论呈现明显分歧。一位评论者对比原始 C 与 Rust 版本代码量后质疑：C 版本约 8–12k SLOC（含头文件），Rust 版本却达约 50k SLOC，为何 Rust 实现如此复杂。也有多位评论者对项目风格提出怀疑，认为 README 中充斥 emoji、题材”AI 味”过浓，很可能是 LLM 辅助生成的”slopware”。另有评论者反过来认为，AI 辅助编码正好适合此类”整体分叉重写并与原版并行运行以捕获回归”的完整重写方式，比起将现有大型项目拉入”半 Rust 的科学怪人”结构更合理。

讨论还延伸到 Rust 生态的整体走向：有人提到 uutils 社区正把 GNU coreutils 用 Rust 重写，Canonical 在 Ubuntu 26.04 中已默认切换到 Rust 版本的 /bin 工具，并推行”氧化”计划；但 Linus Torvalds 表态既有 Linux 内核不会完全用 Rust 重写。也有关于二进制体积、性能与”何谓惯用 Rust”的追问尚未得到项目方回应。不少评论则流露疲态，感慨五年前会觉得酷、如今却只想到”又一次 token 消耗”。