Agili 的 Hacker Podcast 2026-08-30

2026年8月30日

今日科技界消息密集：RISC-V 正式进入 CPython 官方支持名单，加州立法者给开源操作系统开了年龄验证的豁免通道，Qubes OS 披露了一个可被利用的严重漏洞。天文方面，罗曼太空望远镜已顺利升空。软件工程质量、AI 爬虫和开源项目存续这几条深度内容，同样值得一读。

CPython 官方支持 RISC-V 架构

Tier 3 级别支持落地

CPython 官方博客宣布，RISC-V 架构正式成为 CPython 支持的平台，级别为 tier 3。过去几个月，CPython 开发者持续改进这个开源解释器对 RISC-V 的支持，最终把这项支持写进 PEP 11（CPython 官方平台清单）的 tier 3 列表。RISC-V 是一种开放指令集架构，与 x86、ARM 这类专有指令集不同，它以开放标准形式开发，任何人都可以自行实现。RISC-V 生态近年增长迅速，有市场预测称到 2032 年规模将增至现在的四倍，Python 在这些平台上的可靠运行也随之变得重要。

这项支持靠社区长期积累，不是一次提交完成的。很多人测试真实硬件、修复架构特定问题、改进构建支持、报告 bug、审查补丁，把平台带到了可以进入 PEP 11 的程度。RISE Project 为 CPython 提供了多台 RISC-V 机器，建成了 buildbot（补丁合并后自动运行的测试机器人），让持续测试成为可能。Sovereign Tech Agency 的 fellowship 资助了这项工作。

基线之争：RV64GC 还是 RVA23

CPython 目前为 riscv64-unknown-linux-gnu 目标构建，事实基线是 RV64GC（64 位 RISC-V 加上整数、乘除、原子、浮点、双精度浮点与压缩指令组成的基础组合）。CPython 开发者 Emma Smith 在讨论中解释，团队手上只有 RV64GC 机器可测，发行版的 Python wheel 平台标签 manylinux_riscv64 也以它为准。新一代高性能核心（如 SiFive P800）支持更高的 RVA23 配置文件，其中包含向量和位操作扩展，有人建议用它们优化解释器性能。Smith 回应说，用户普遍采用 RVA23 之前更换基线不明智。也有人认为向量扩展确实是 RVA23 相对 RV64GC 最大的差距，但 CPython 本身从这类指令中受益有限。想提前测试 RVA23 可以用 QEMU 模拟器，不过有评论指出，对最新 RISC-V 芯片，QEMU 已经不比真实硬件快。

评论里一句“RISC-V 碎片化又来了”招来反驳：x86 有 x86-64-v1 到 v4 的档次，ARM 也有大量可选特性并非所有核心都支持。应用级 RISC-V 核心都能执行 RV64GC 二进制，问题更多是生态成熟度而非碎片化。Ubuntu 26.04 将要求 RVA23，新应用级处理器也会支持这一配置文件，基线可能会很快移过去。

Tier 3 的局限与下一步

32 位 RISC-V 不在支持范围内。这类芯片基本只用在微控制器上，没有面向 Linux 的 RV32 项目，嵌入式场景用的是 MicroPython——一个独立于 CPython 的轻量级 Python 实现。有人以为 CPython 是 C 写的，在 RISC-V 上只需要重新编译。并非如此：测试套件出现过真实失败，Linux perf 性能分析支持也尚未合并。RISC-V 之前未列入支持名单，主要是缺少硬件访问权限和愿意投入时间的提交者。一位用户说自己在 RISC-V 上跑过 Python 3.14，编译无错、测试全过，因此不太理解这次公告的分量。公告的意义在于官方正式认可，而非第一次能跑。

Tier 3 的局限依然存在：平台仍可能随时坏掉，且不阻塞任何发布。要升到 tier 2，需要 CI 基础设施被证明可靠，还要至少两名核心开发者承诺在 24 小时内响应问题。作者接下来计划把 RISC-V 直接接入 CPython 的 CI（由 RISE 的 RISC-V Runners 计划支持），在补丁合并前就捕获架构问题，长期目标是提升到 tier 2，并探索针对 RISC-V 的架构优化。

Bug 盲区：为什么开发者看不见产品坏了

从搜索引擎到企业软件的质量失明

Dan Luu 在《Bug Blindness》里讲了一个现象：他每周能发现成百上千个软件问题，但大多数人遇到同样的问题却完全无感。这不是因为他用电脑的方式异于常人，而是多数人根本没留意到软件坏了。他逐渐意识到，这种“Bug 盲区”对程序员尤其有害，因为他发现很多团队明明在交付有严重缺陷的产品，内部却一致认为产品很好、很受欢迎。

他举了几个例子。他之前写过文章批评 Google、Bing 和 Kagi 的搜索结果质量差、充满 SEO 垃圾内容和骗局，几乎没人反对他对 Google 和 Bing 的评价，但很多人坚持说 Kagi 没问题。有人把自己的 Kagi 搜索结果发给他，结果那些结果里既没有有用信息，也满是垃圾内容。只有用户手动把 GitHub 置顶才能搜到想要的东西，但那只对下载软件这类查询有效。另一个例子是 Blackboard（大学课程管理软件），当年它被学生和教授广泛厌恶，Fast Company 2011 年的调查显示 93% 的受访者“讨厌”这家公司，维基百科上甚至写着它是“教育界最令人讨厌的公司之一”。但 Dan Luu 遇到一位 Blackboard 员工，对方真心相信用户很喜欢这个产品。还有个例子是 Discourse 论坛软件，它的员工认为性能很好，但实际上 Discourse 为了在 LCP（Largest Contentful Paint，网页加载性能指标）上作弊，特意在代码里延迟了真实页面加载，这种“作弊”不仅对用户没好处，反而损害用户体验。

习惯性规避是熟练度的真相

Dan Luu 认为，人会对自己喜欢的东西的缺点视而不见，哪怕是自己或自己公司做的东西。他会刻意寻找对自己工作的批评，而很多人会质问他：“如果别人批评你的作品，你会怎么想？”他的回答是，他自己觉得作品充满缺陷，别人说不好很正常。

他把自己这种敏感追溯到童年经历。他用机械鼠标时，鼠标球上积了灰尘导致指针乱跑，他自己完全没察觉，直到朋友用他的电脑才发现根本没法用。他坐下来演示时发现自己为了把指针移成直线，手在剧烈地乱甩。他已经不知不觉适应了鼠标的故障，并用反向的乱动来抵消它。他由此联想到，自己现在可能还有很多类似的无意识补偿动作。

他列举了很多自己形成的“习惯性规避”：打开 Google Docs 后不能立刻输入标题，因为输入内容会被覆盖，所以要等一会儿再改标题；在微软工作时，登录前要把笔记本的 WiFi 开关关掉，否则某个服务会失败并导致登录报错“目前没有可用的登录服务器”。他认为所谓的“电脑熟练度”很大程度就是积累这类绕开 Bug 的下意识习惯。

盲区可以被治愈

对于如何治疗“质量盲区”，他建议让开发人员吃自己的狗粮，但这个方法有限，因为程序员特别擅长绕过软件问题，往往会忽略这些障碍。反过来，让软件好用，本质就是让这些奇怪习惯变得不必要。但开发者的本能反应常常是“这很容易啊，只要这样做就行”，而他们说的步骤对普通用户来说根本不可能想到。这个盲区可以被治愈，因为他已经帮不少朋友做到了：只要持续指出对方没注意到的 Bug，几周后对方就开始自己发现问题了。

他见过不少团队因为质量盲区，把根本没成功希望的产品发布出去，而所有人都以为自己在交付高质量作品。他特别提到，在编码智能体（coding agents）时代这个问题更严重，因为生成低质量软件变得更容易，但提升质量也同样变得更容易——前提是你得先注意到质量可以被提升。

在附录里，他引用了几位朋友的观察。Michael Malis 提到广告盲区：程序员几乎都用广告拦截器，眼睛会自动跳过广告，所以他们觉得广告没用。但 Dan Luu 看过两个大公司的数据，包括地理分段的 A/B 测试（按地区投放广告，对比有广告和没广告地区的效果），证据显示广告带来的真实营收提升远超广告成本。他还提到很多人根本不知道自己在搜索结果里点的是广告。另一位朋友 Em Chu 描述了 Mac 笔记本唤醒时黑屏的 Bug，只能合盖再打开，她靠“等一秒再操作”来规避。Gary Bernhardt 在阅读本文草稿时又遇到了 Google Docs 的滚动 Bug。

Hacker News 的讨论里，sgentle 提出了一个很有洞察的观点：程序员和非技术用户对 Bug 失明的原因正好相反。开发者的心智模型离系统太近，盲区与系统一致；而普通用户可能根本没有心智模型，他们点击、看结果、不符合预期就换一种点法，电脑对他们来说更像神灯而不是机器。用户不会区分“预期行为”和“异常行为”，因为他们本来就不怎么形成预期。所以他们会默默绕过大量 Bug，而开发者也不知道这些问题存在。

有评论反驳“用户不够聪明”的说法。DrewADesign 认为开发者常常看不起用户不读文档，但用户只是不想关心技术细节，他们想解决问题，而界面本身就是软件。一位自称做过技术支持的人说，确实存在一批“绝对不够聪明”的用户，他花了近 30 分钟帮一个人排查问题，最后发现是一个弹窗挡住了屏幕，那人始终读不出弹窗上的几个字，直到让他倒着拼写才成功。jakevoytko 分享了一个有趣的团队实践：为了复现难以捕捉的运动控制 Bug，他同事会去找没怎么用过系统的经理来操作，因为高频使用的人已经下意识避开了所有小毛病；而最难复现的 Bug 则交给经理的经理——那位领导用 Xbox 手柄时的空间推理能力像金鱼一样，从来没失手过。

罗曼太空望远镜升空：视场是哈勃的 100 倍

从间谍卫星改装的宽视场巡天

南希·格雷斯·罗曼太空望远镜（Nancy Grace Roman Space Telescope）以 NASA 首位首席天文学家、被称为“哈勃之母”的南希·格雷斯·罗曼命名，目标是回答暗能量、系外行星和红外天体物理中的关键问题。它于 2026 年 8 月 30 日搭乘 SpaceX 猎鹰重型火箭从佛罗里达升空。发射窗口只有约一分钟，因为猎鹰重型加注过冷推进剂后不能长时间等待，错过就要等第二天。目前望远镜正在前往距离地球约 150 万公里的日地拉格朗日 L2 点，航程约三个月。

Roman 的视场面积至少是哈勃的 100 倍，每张图像覆盖的天区大于满月，而哈勃的视场通常小于满月，韦布更小。凭借近 3 亿像素的宽视场相机，它有望在任务期内测量约 10 亿个星系发出的光。望远镜主体改造自一台退役间谍卫星，这被认为是项目低于预算、提前完成的原因之一。主镜来自那颗卫星，但平台、电子设备和两台科学仪器由 NASA 重新打造。两台仪器分别是宽视场成像仪（WFI）和日冕仪（CGI）。日冕仪遮挡宿主星的光，直接拍摄木星大小的系外行星和行星形成盘，也是未来宜居世界天文台（HWO）的技术前身。日冕仪的飞行软件有超过 10 万行 C++，运行在抗辐射的 LEON4 处理器上。有评论指出历史背景：哈勃当年并没有直接复用间谍卫星组件，只是主镜口径受到 Keyhole 间谍卫星生产设施的影响。

数据全部公开

Roman 的数据面向所有人。NASA 在任务计划中写明：所有巡天数据一经处理即公开，不设独占期。原始压缩数据量每天约 1.4TB，地面下行速率最高 500Mbps，实际每天约下传 1.5TB，远超韦布的 23Mbps。任何人都可能成为第一个看到某个星系的人。接触过韦布数据的研究生提醒，实际操作中，Roman 的数据需要在 NASA 的计算机上处理，并支付计算和存储费用，很难全部下载到本地；也有评论认为，既然平台允许运行任意处理程序，数据就难以真正限制流通。数据开放意味着科学更民主，但也让原本靠独家数据发表论文的研究生压力更大。

与韦布搭档观测

观测策略上，Roman 与韦布是搭档。Roman 会反复拍摄同一片天区，用图像相减剔除每一张都出现的恒星和星系，留下超新星等瞬变天体，再由韦布对准这些目标精查。它还会统计银河系内的行星系统。加上地面上的鲁宾天文台、哈勃和韦布的配合，未来十年的天文图像值得期待。有评论问到为什么不像行星探测器那样造两架 Roman，答案指向主镜制造：磨制和抛光一面主镜需要极长时间，成本随口径急剧上升；而旅行者号、火星车这类任务确实常成对飞行，飞行备件也常被用来在地面模拟故障。

加州通过 Linux 年龄验证豁免

开源许可证成豁免标准

加州立法者一致通过一项修正案，将开源操作系统排除在年龄验证法律之外。修正案把“操作系统提供商”重新定义为不包括“根据允许接收者复制、再分发和修改软件的许可条款”分发操作系统或应用程序的个人或实体。GPL、MIT、BSD 和 Apache 许可证都满足这一测试，Debian、Fedora、Ubuntu、Arch 以及 BSD 家族因此不再属于 AB 1856 法案的管辖范围。

原法案要求操作系统提供商在账户设置时收集用户年龄。修正案通过后，Windows、macOS、iOS 和 Android 仍在范围内，需从 2027 年 1 月 1 日起在账户设置阶段收集年龄；更早设置的设备截止日期为 2027 年 7 月 1 日。SteamOS 的情况尚不明确：其 Arch 基础组件是开源的，但 Valve 随镜像分发了专有的 Steam 客户端。

社区解读与担忧

社区反应复杂。部分人把它看作开源社区施压的成果，认为这会推动 Linux 桌面的采用。也有评论指出，Android 作为 Linux 的商业再打包版本不会因此免责：设备上的闭源组件和 Google 服务使其仍受管辖。GrapheneOS 等开源替代品则可能符合豁免条件。

不少评论担忧这只是暂时妥协。有人警告，豁免确立了“使用电脑需要知道年龄”的基线，今后可能被收紧；网站可能开始拒绝不提供年龄信号的用户，甚至要求远程证明（remote attestation）来确认设备系统。还有用户对法律本身持批评态度，认为年龄验证是对隐私的侵犯，豁免只是“给坏想法贴上胶带”。

技术争议集中在法律定义的模糊性上。macOS 的 Darwin 核心部分开源，但 Apple 的整体系统包含专有组件，无法满足豁免条件；公共领域软件因没有“许可条款”，可能被排除在豁免之外。systemd 此前提交了一个添加出生日期字段的 PR，评论者指出该 PR 同时提到了加州、科罗拉多州和巴西的法律，加州豁免不会让这些工作失去意义。有评论者开玩笑说，孩子们从此都会变成 Linux 原生用户，“2027 年会不会是 Linux 桌面之年”。也有人提到 Minecraft 已经让一代年轻人熟悉了命令行，这项法律可能进一步推动开源系统在年轻用户中的普及。

德州车险的 1 美元，变成了 2000 台监控摄像头

保险费流向 Flock 网络

2023 年，德克萨斯州议会一致通过一项法律，将德州车主的汽车保险费每年提高 1 美元，用于打击猖獗的催化转换器盗窃。三年后，一个不太知名的州机构——机动车辆犯罪预防管理局（Motor Vehicle Crime Prevention Authority，由州长 Greg Abbott 任命的董事会主导）已将该费用中的至少 3000 万美元用于建设 Flock 监控网络，在从埃尔帕索到路易斯安那州边境的高速公路和街道上部署摄像头。《德克萨斯论坛报》的分析发现，该机构已发放至少 95 笔拨款，帮助执法机构购买和维护约 2000 台 Flock 摄像头；另有 1590 万美元用于德克萨斯州公共安全部增加近 1200 台。8 月初，该机构又批准 300 万美元，用于未来一年在收费公路上安装 583 台摄像头。

这笔每年 1 美元的费用已筹集约 8100 万美元，其中 5080 万美元通过 234 笔拨款，用于报销警察部门的人员、犯罪分析师、检察官、无人机和其他监控设备。Flock 摄像头是全国最常用的车牌读取器，用人工智能生成“车辆指纹”，存储车牌、品牌、型号、颜色以及凹痕和保险杠贴纸等细节，全国执法机构无需搜查令即可访问数据库。

议员称不知情

2023 年立法时，法案未提及车牌读取器，几位投票支持的议员表示不知情。州参议员 Carol Alvarado 说，她从论坛报得知保险费被用于资助 AI 车牌读取器时很惊讶：“我通过法案时没有这个想法。”共和党议员 Brian Harrison 称：“我永远不会想到这会变成无证监控。否则我敢打赌它不会获得全票通过。”

Flock 数据共享让车辆追踪效率极高。公司发言人 Trevor Chandler 说，去年通过 Flock 找到了超过 1 万名失踪人员。但反对者认为，这种网络结合了侵入性监控和缺乏监督，侵犯隐私。德克萨斯州已有至少 100 个城市终止 Flock 合同，包括奥斯汀。近期曝光的滥用案例加剧了担忧：一名 Lufkin 警察因 100 项滥用官方信息罪被起诉，Baytown、Harris County 等地的警察也因用 Flock 数据跟踪前伴侣或同事而被捕或受调查。DFW DeFlock 组织者 Kenneth Feagins 说：“这数据能做很多恶意的事，这些事不再是假设。”

暂停拨款

执法部门则大力支持。Pasadena 警察中士 Douglas Buckert 说摄像头“改变了游戏规则”：“得到的线索多到不可思议，我再多六个调查员也处理不完。”Temple 警方犯罪分析师说，该市 84% 的 Flock 摄像头由州拨款资助，帮助减少了被盗车辆。在人口 3.6 万的 Cibolo，拨款让摄像头从 11 台增加到 52 台。Flock 摄像头在德州的确切数量不明；反监控组织 DeFlock 通过众包地图识别出约 1.3 万台，保险费增加部分支付了其中四分之一。

8 月 28 日晚，Abbott 办公室宣布暂停所有用于 Flock 摄像头的州资金对地方拨款。发言人 Andrew Mahaleris 说：“城市获得的大部分资金来自联邦政府；来自德州机构的任何资金，这些机构正在澄清不能用于 Flock 摄像头。”此前几小时，Abbott 在电台采访中提到了 Lufkin 警察的起诉案。有用户调侃德州法律允许对夜间盗窃使用致命武力，并引用德州刑法第 9.42 条，称射杀催化转换器盗贼可能合法。另有人提醒“保护好你的电动车，电池会是被偷的下一个目标”。

AI 爬虫吃掉 git.kernel.org 20% 的算力

每天 600 万次请求里只有 2% 是真人

git.kernel.org 的维护者最近公布了一组数据：为了应付 AI 爬虫，系统正持续消耗大量计算资源。目前该站点每天收到约 600 万次请求，其中 66% 被 Anubis 工作量证明挑战直接挡下，但剩下 33% 的请求已经能解出答案、进入主站。在 5 个地理分布节点、总计 90 个 CPU 核中，有 14 到 16 个核一直在做的唯一一件事，就是把 git 提交渲染成 HTML 供爬虫抓取。这约占全部容量的 20%，而且爬虫是波浪式袭来，实际负载比一条 20% 的平线要尖得多。相比之下，所有正常访问（包括 git clone）消耗的 CPU 周期加起来还不到这些爬虫的一半。

对 LLM 来说，Linux 内核的提交历史是一块金矿：它完全由人类编写、没有 AI 生成内容混入。用 AI 自己产出的内容训练模型，相当于让模型患上“数字朊病毒病”，所以像内核提交这种保证纯净的数据源价值极高。但奇怪的是，爬虫选择了最笨的方式来获取数据。linux.git 目前有约 148 万个提交，git.kernel.org 上还有 922 个 fork，理论上可以生成数十亿个有效 URL。如果直接用 git clone，一次就能拿到全部历史；但爬虫偏偏要一个提交一个提交地渲染成 HTML 再解析。爬虫还经常去抓那些 8 年前就没人维护的 fork，于是同一个提交要被重复渲染 922 遍。

军备竞赛：工作量证明能撑多久

维护者最初用 fail2ban 封 IP，爬虫就伪装成普通浏览器；再按 IP 段封，爬虫就扩散到整个子网；后来干脆封整个 ASN（自治系统号）。但真正的转折点是爬虫开始从数百万个随机的住宅或移动 IP 涌出，伪装成现代浏览器，每个 IP 只请求四五次就消失。这些 IP 来自“住宅代理 SDK 商业化”网络，很可能是被安装了代理 SDK 的智能电视或其他家用设备。维护者说，欢迎来到“代理 SDK 变现”的世界，你的电视可能正在参与这件事。

于是他们部署了 Anubis（一种工作量证明挑战，要求客户端算出一个带若干前导零的 SHA-256 哈希）。刚开始效果极好，爬虫直接放弃，论坛平静了几个月。但很快爬虫回来并解决了难度 4；调到难度 5 后，爬虫又跟上了。现在有 33% 的爬虫能解出难度 5 的题目。在做出“慷慨假设”后，维护者估计 git.kernel.org 的真实合法流量只占约 2%，其余全是爬虫。系统目前还没被拖垮，真正导致宕机的往往是设计糟糕的 CI 系统用 20 个节点同时对 stable.git 做浅克隆（shallow clone）——维护者说浅克隆很糟糕，想这么干请自己跑镜像。但为了应对爬虫，他们已经在考虑关闭一些功能、减少可爬取的 URL 数量。匿名访问可能会失去部分功能。维护者保证所有数据仍会提供下载，只是门槛会更高。

社区看法：军备竞赛赢不了，但能拖

Hacker News 上的讨论围绕 Anubis 是否有效展开了激烈争论。一位用户半开玩笑地说，他用 Claude 花 10 分钟写了个 Safari 扩展，用原生 ARM SHA-256 指令把 iPhone 的解算速度从约 100 KH/s 提到 200 MH/s，难度 6 的挑战只需几毫秒。他说 Anubis 这类“证明工作”的军备竞赛不可能赢，因为一台 5000 美元的 ASIC 矿机算力是手机的数百万倍。也有人反驳，称 Anubis 的实际效果不在于理论上的不可破解，而在于 66% 的爬虫会直接放弃；只要它能把资源消耗降到可容忍水平，就是有用的，哪怕只是暂时的。还有人指出，Anubis 真正的杀招不是工作量证明本身，而是“定制化”——如果每个站点的挑战算法稍微不同，爬虫就无法套用现成方案，需要逐个适配。

另有用户分享了自己的经历：维护一个原本人气不错的游戏网站，在线用户数从一两百涨到几千，后来发现几乎全是爬虫会话，真实用户只剩个位数。有人因此直接关掉了自己的 cgit 实例，因为负载已经影响到同一台机器上的其他虚拟机。也有人选择反向操作，在自己的网站里给爬虫设陷阱：用假路径把它们引向无限循环，图片按字节慢慢吐，或者返回 AI 生成的“性感烤面包机”图片。还有评论提到，这类爬虫流量很多来自巴西等地的住宅 IP 池，单个 IP 每请求一两次就消失，禁令毫无作用。

关于出路，评论中出现了几种方向。有人建议对爬虫提起 DDoS 诉讼，因为这种规模的抓取已经是犯罪，但有人回应说普通站长根本无力追查藏在住宅代理背后的运营者。也有人提议把旧提交的访问成本提高、要求登录、或者干脆停止提供 HTML 界面。一位用户指出，问题的根源在于网络内容寻址方式：服务器名字被当作权威，导致每个想要副本的实体都得反复请求源站。如果改用数字签名和内容寻址，一次负载就能传播给所有人，但这类系统（如 IPFS）至今没成气候。还有人怀念简单的解决方案：克隆仓库、遍历提交，完事。但正如一位评论者所说，爬虫根本不关心你的内容或更高效的方式，它们只是程序化地遍历所有 URL。文章最后说得很直白：没有简单的解法。做 AI 模型的公司每天还在冒出来，都在找训练数据；应用开发商为了赚钱，还在把你的家电变成攻击工具。维护者只能用加拿大人的方式道歉：“对不起。”

FreeCORE 让 FreeBSD 版 TrueNAS 继续走下去

项目定位与升级路径

FreeCORE 是一个独立维护的操作系统项目，延续 TrueNAS CORE 13.3，基于 FreeBSD。TrueNAS CORE 是 FreeBSD 分支，已经停止开发新功能；TrueNAS SCALE 则是 Debian Linux 分支，是官方未来主推的版本。FreeCORE 的存在就是为了让 FreeBSD 版 TrueNAS 继续走下去。当前 15.0-U1 已稳定，TrueNAS CORE 13.3 系统可以直接就地升级到 15.0，之后跟随项目的更新通道。安装指南、ISO 下载和就地升级脚本都在 freecore.org 上，源码托管在 Codeberg，GitHub 上有镜像，问题跟踪和 IRC 频道也都有。

开源商业化争论

这条消息出现在 TrueNAS 刚刚停止发布构建脚本的背景下。有用户在 TrueNAS 论坛中指出，他们不再公开构建脚本，导致开源代码更难自己编译。有人质疑这是否违反 GPL——GPL 要求提供控制构建的脚本——但有人纠正说 TrueNAS CORE 是 BSD 许可，不强制要求。争论焦点在于：开源项目维护者是否有义务继续免费提供未来的工作。有评论者认为，如果公司靠开源社区起家，然后把梯子抽走，是破坏社会契约；也有人反驳说，BSD 许可下开发者有权这么做，批评者是“觉得免费东西不够多”的 entitlement。

不少用户表达了对开源商业化趋势的疲惫。一位用户说，在公司里他们只采用有付费支持计划的开源软件，否则就是在等 rug pull，把开源当闭源对待。有人回应说，很多开源项目本来就是靠商业客户养着的，TrueNAS 的开发者也在给 OpenZFS 等项目贡献代码，公司需要生存。还有人提到 Proxmox 和 OpnSense 的做法：提供“不适合生产”的社区补丁通道，既让企业付费，又不影响家庭用户。

用户怎么看 FreeCORE

对 FreeCORE 本身，有用户质疑一个没有资金支持的分叉是否值得把 NAS 数据托付给它。也有人分享自己已经离开 FreeNAS 的经历：有人因为硬件故障后改用纯 FreeBSD，用命令行管理存储和文件服务，十年没出问题；有人迁移到 TrueNAS SCALE 后觉得 Linux 性能更好，还跑 Docker 服务；还有人直接用 Debian 配 LVM 和 Samba，并不复杂。一位用户把使用了 11 年的 TrueNAS 系统迁移到了 Linux，整个过程很顺利，但他更喜欢 FreeBSD，因为日常工作都在 Linux 上，FreeBSD 能带来一点不一样的东西。

关于 FreeBSD 和 Linux 的偏好也有讨论。有人觉得 FreeBSD 在服务器上更优秀，尤其是文件服务器；也有人认为 Linux 现在发展更快。FreeCORE 提供了一个选择：如果你在意 FreeBSD 这条路，它可以继续跟下去，但项目能否长期持续，目前没有保证。

Qubes OS 披露 dom0 任意代码执行漏洞

漏洞细节

Qubes OS 发布了安全公告 QSB-118，披露了一个允许在 dom0（管理域，Qubes 中权限最高的组件）中执行任意代码的漏洞。漏洞出在 qvm-copy-to-vm 的错误报告环节：当用户从 dom0 向某个 qube（Qubes 中的虚拟机）复制文件时，目标 qube 如果已被攻击者控制，可以在传输确认消息中伪造文件名。dom0 端代码对这个文件名做了过滤，但只把非 ASCII 字符和双引号替换成下划线，保留了 shell 元字符；随后错误处理函数用 system() 拼接命令并通过 shell 执行，导致攻击者可以注入任意命令，直接控制整个系统。所有 Qubes OS 版本均受影响，修复包为 dom0 中的 qubes-core-dom0-linux 4.3.22。漏洞由 Tim C. 发现。公告还指出，qube 内部的复制命令变体不受影响，因为它用 execlp() 直接执行程序，没有经过 shell。

社区评论

Hacker News 评论中，多数人认为这不是虚拟化边界被突破，而是 system() 的经典误用：把不可信输入拼进 shell 命令，属于 C 语言安全基础问题。有人提到，从 dom0 复制文件本身就不符合 Qubes 的最佳实践，但实际使用中很常见，比如 xfce4-screenshooter 截图会先存到 dom0，再复制到其他 qube 处理。还有评论引用了 Theo DeRaadt 多年前对虚拟化安全性的批评，并围绕“复杂抽象是否真的提升安全”展开争论。也有用户称赞 Qubes 的安全公告写得很清楚，附带了完整的 PGP 签名验证步骤，让人能确认公告真实性。

地球上最长的海上与陆上直线路径

算法确认了 Reddit 用户的猜想

Rohan Chabukswar 和 Kushal Mukherjee 在 2018 年的论文中，用分支定界算法（一种通过分支和剪枝寻找最优解的优化算法）计算了地球上两条最长的直线路径：一条全程在海上，另一条全程在陆上。这个问题因为岛屿、湖泊和海岸线的分形特征而变得复杂。

论文的起因是一个 Reddit 帖子。用户 kepleronlyknows（真名 Patrick Anderson）声称找到了海上最长直线，并在图书馆用绳子和实物地球仪验证过，后来用 Google Earth 做了可视化。作者实现算法、载入海拔数据后确认：这个 Reddit 用户是对的。海上最长直线从巴基斯坦南部近海出发，穿过太平洋、大西洋和印度洋，在俄罗斯堪察加半岛附近结束，长度约为地球周长的 80%。这条线在地图上看起来很像昼夜线，因为它是一段大圆（过球心的平面与球面相交的圆弧，也是球面上两点间的最短路径）。

陆上路线与争议

陆上路线从中国泉州附近延伸至葡萄牙南部，长度约为地球周长的 28%。论文称之为“最长可驾驶直线”，但评论指出它直接跨过阿尔卑斯山，开车不可能，步行也许可行；沿途还会穿过大量河流湖泊，严格来说需要桥梁。如果规则是“不能碰任何水体”，有评论认为最佳答案可能是横穿南极洲，只是南极洲覆盖着固态水，夏季考察站周围还会有水坑。

有评论者发现论文可能漏掉了一条更长的陆上路线：从塞内加尔附近到中国的一条大圆路径长约 13,250 公里，比论文结果长 2000 公里。它被排除是因为路径经过死海，而论文把一切低于海平面的区域都当作水。这条路线还会穿过苏伊士运河，有评论说桥梁或隧道不算比较公平。论文附有球体和平面的路线图。有读者做了“第一人称”视角的渲染，也有人把这个地理谜题比作现代版的柯尼斯堡七桥问题。社区还讨论了地平论者眼中的答案：若采用以北极为中心的极地方位等距投影，最长陆上直线可能是从葡萄牙南部到俄罗斯堪察加。

凯西·穆拉托里解剖“过早优化”这句名言

三小时演讲与问答

凯西·穆拉托里（Casey Muratori）在 Better Software Conference 2026 上发表了题为《The Root of The Root of All Evil》的演讲。视频于 8 月 25 日发布，上线 4 天观看次数 21 万，总时长 2 小时 50 分钟：前 2 小时 8 分钟是演讲部分，之后是凯西与 gingerBill 的问答。

演讲主题是“过早优化是万恶之源”（premature optimization is the root of all evil）这句名言。凯西把这句话放回原始语境，追溯到 1960 年代末到 1970 年代初的计算机科学界，涉及结构化编程（structured programming）的兴起，以及 Dijkstra、Knuth、Tony Hoare、Douglas T. Ross 等人的工作。演讲中有一段趣闻：Dijkstra 被一期印着 Go Go Girl 程序员的 IBM 广告搞得陷入抑郁。有观众形容这场演讲是“计算机科学的考古学”。

观众反响

一位 YouTube 观众说，自己一直想写一场题为《Most Misunderstood Messages》的演讲，盘点编程界那些被扭曲成更流行但更无用的原始思想——匈牙利命名法（Hungarian notation，在变量名里编码类型信息的命名约定）是其中之一，Smalltalk 的面向对象编程（OOP）理念与后来 C++/Java 风格的分歧也是。他计划中的压轴话题正是“过早优化”这句被滥用最多的名言。“看来凯西替我把这件事做了。”另一位 1974 年在英国技术中学学过“结构化编程”的观众补充，这门课是当时 17 岁学生的计算机科学入门内容，霍尔的通信顺序进程（CSP，描述并发交互的形式化模型）理念至今仍影响他的编程思维。

这是凯西在 BSC 2025 讲《The Big OOPs: Anatomy of a Thirty-five-year Mistake》（85.5 万次观看）之后又一场三小时的历史考据。Hacker News 上的讨论从“传奇游戏程序员”这个称呼展开：有人发帖这样叫他，有人立刻问“那不是 Jonathan Blow 吗”——两人都是游戏编程领域的知名人物。有用户解释，这个称呼来自 Primeagen 的播客节目《The Standup》上的一个梗：凯西被这样称呼时觉得受之有愧。HN 用户 mberning 说，他打算等孩子睡后再看这场演讲：“我喜欢凯西的很多观点，尽管并非全部同意。”

播客全文

女：Hello 大家好，欢迎收听 Agili 的 Hacker Podcast，我是莓莓。

男：大家好，我是阿迪。

女：今天想聊的东西有点多。先说个技术新闻：CPython 最近正式把 RISC-V 列入了支持的平台。

男：对，CPython 官方博客宣布 RISC-V 进了 PEP 11 列表，级别是 tier 3。

女：tier 3 是什么概念？

男：可以理解成官方平台清单里的一个支持级别。进入 tier 3 意味着官方正式认可这个架构能跑，也有人在维护，但平台仍可能随时坏掉，而且不阻塞任何发布。

女：那它是怎么进去的？一次大提交？

男：不是。社区里有人报告 bug、有人修架构问题、有人改进构建支持，攒了好几个月。RISE Project 提供了几台 RISC-V 真机，还建了 buildbot，就是补丁合并之后自动运行的测试机器人，让持续测试成为可能。Sovereign Tech Agency 的 fellowship 资助了这部分工作。

女：那普通人会感觉到什么变化吗？

男：短期不会有感觉。但 RISC-V 生态增长得很快，市场预测到 2032 年规模是现在的四倍，Python 要在这些平台上可靠运行，官方承认是第一步。现在用的是 RV64GC 基线，发行版的 wheel 平台标签 manylinux_riscv64 也按这个来。

女：那 32 位的 RISC-V 呢？

男：不支持。32 位 RISC-V 基本只用在微控制器上，没有面向 Linux 的 RV32 项目。嵌入式场景用的是 MicroPython，那是独立于 CPython 的轻量级 Python 实现。

女：所以这类支持背后是一群人不声不响的长期劳动。说到维护基础设施，git.kernel.org 的维护者最近写了一篇很无奈的博客。

男：那篇挺值得看。git.kernel.org 每天收到约 600 万次请求，66% 被工作量证明挑战 Anubis 直接挡下，剩下三分之一能解出答案、进入主站。整个站有 90 个 CPU 核，其中 14 到 16 个核专职在做一件事：把 git 提交渲染成 HTML 给爬虫抓。

女：为什么要渲染？直接 git clone 一下不就有整个仓库历史了吗？

男：这正是最怪的地方。linux.git 有约 148 万个提交，git.kernel.org 上还有 922 个 fork，爬虫不 clone，偏要一个提交一个提交地访问 HTML。而且不少 fork 是 8 年前就没人维护的，同一个提交被重复渲染 922 遍。

女：这像是写爬虫的人根本不懂 git。

男：很可能只是程序化遍历所有 URL。维护者一开始封 IP，爬虫换伪装；封 ASN 整段封，爬虫就扩散到整个子网。最后变成从几百万个住宅 IP 涌出来，每个 IP 只请求四五次就消失。这些 IP 来自装了代理 SDK 的智能电视之类设备。

女：所以我家的电视可能也在帮别人爬数据。

男：有可能。他们后来部署了 Anubis，要求客户端算一个带前导零的 SHA-256 哈希。刚开始爬虫直接放弃，难度调到 5 之后，又有三分之一的爬虫能解出来。有网友半开玩笑说用 iPhone 的原生 ARM 指令能把计算速度提到每秒 200 兆哈希，难度 6 只需几毫秒。

女：那还能拦住吗？

男：没有简单解法。有人建议对爬虫提 DDoS 诉讼，可普通站长连背后是谁都查不到。还有人怀念直接克隆仓库、遍历提交这种正经做法。维护者已经考虑关掉一些功能，减少可爬取的 URL，匿名访问可能失去部分功能。文章最后用加拿大人的方式道歉，只写了“对不起”。

女：这让我想到另一个概念，就是 Dan Luu 说的“Bug 盲区”。维护者在跟爬虫斗争，很多开发者对自己软件的缺陷却完全看不见。

男：对，Dan Luu 写了篇文章叫《Bug Blindness》。他说自己每周能发现成百上千个软件问题，但大多数人遇到同样的问题完全无感。他举例说批评 Google 和 Bing 的搜索结果质量差几乎没人反对，但有人坚持说 Kagi 没问题。把搜索结果发给他一看，里面照样全是垃圾内容和 SEO 页面，只有用户手动把 GitHub 置顶才搜得到想要的。

女：这像是自己没遇到就觉得没坏。

男：还有一种，是认识不到“坏”是什么。他举了 Blackboard，大学课程管理软件。Fast Company 2011 年调查显示 93% 的受访者讨厌这家公司，维基百科都写了它是“教育界最令人讨厌的公司之一”。但他遇到一位 Blackboard 员工，对方真心相信用户很喜欢产品。

女：这挺可怕。

男：还有 Discourse 论坛软件，员工觉得性能好，实际为了 LCP 这个网页加载指标，在代码里故意延迟真实页面加载。Dan Luu 说人会对自己做的东西的缺点视而不见。他自己会刻意找批评，别人问他“别人批评你作品你怎么想”，他说我自己就觉得作品充满缺陷，别人说不好很正常。

女：他怎么会有这种敏感？

男：他讲了个童年故事。用机械鼠标时，鼠标球上积了灰，指针乱跑，他自己完全没察觉。直到朋友用他电脑说“这根本没法用”，他才发现自己为了把指针移成直线，手在剧烈地乱甩。他已经不知不觉适应了鼠标的故障。

女：这个例子太具体了。

男：他还列了一堆习惯性规避：打开 Google Docs 后不能立刻输入标题，因为输入内容会被覆盖；在微软工作时，登录前要先把笔记本的 WiFi 开关关掉，否则某个服务会失败。他说“电脑熟练度”很大程度就是积累这类绕开 Bug 的下意识习惯。

女：那怎么治“质量盲区”？

男：他建议让开发人员吃自己的狗粮，但程序员特别擅长绕过软件问题，反而不容易发现。真正有效的方法是持续指出 Bug，他帮不少朋友做到过，几周后对方就自己发现问题了。Hacker News 上有个评论也很有意思：开发者的盲区是因为心智模型离系统太近，普通用户可能根本没有模型，电脑对他们来说更像神灯——点一下，不符合预期就换一种点法。

女：这也能解释为什么有些设计对开发者很明显、对用户很难。

男：对。他还提到编码智能体时代这个问题会更严重，因为生成低质量软件变得更容易，提升质量也一样更容易了——前提是你得先注意到质量可以提升。

女：说到这种自我审视，最近 Casey Muratori 好像做了个演讲，专门讲“过早优化是万恶之源”。

男：对，他在 Better Software Conference 2026 上讲了一场接近三个小时的演讲，标题叫《The Root of The Root of All Evil》。8 月 25 日放出视频，四天 21 万次观看。

女：三个小时就讲这一句话？

男：他把这句话放回 1960 年代末到 70 年代初的语境，当时计算机科学界在推结构化编程，涉及 Dijkstra、Knuth、Tony Hoare 这帮人。有个观众说这演讲是“计算机科学的考古学”。里面有个趣闻，说 Dijkstra 被一期印着 Go Go Girl 程序员的 IBM 广告搞到抑郁。

女：每个人物都很有画面感。

男：这次演讲是他继 BSC 2025 那场《The Big OOPs》之后又一段三小时历史考据，那场到现在 85.5 万次观看。YouTube 上有人留言说，自己一直想写一场《Most Misunderstood Messages》，盘点编程界被扭曲的思想，匈牙利命名法和 Smalltalk 的 OOP 都是候选，压轴就是“过早优化”这句。“看来凯西替我把这件事做了。”他这么写。

女：评论区里还管他叫“传奇游戏程序员”。

男：这是个梗。有人这么称呼他，评论区立刻有人问“那不是 Jonathan Blow 吗”。其实这个称呼来自 Primeagen 的播客节目，凯西在现场觉得受之有愧。

女：开源项目本身也在这种拉扯里。我前两天看到 FreeCORE 分叉的事，就挺能说明问题。

男：FreeCORE 是独立维护的 TrueNAS CORE 延续分支。TrueNAS CORE 基于 FreeBSD，官方已经停止开发新功能，主推的是基于 Debian 的 TrueNAS SCALE。FreeCORE 就是为了让 FreeBSD 版继续走下去，现在 15.0-U1 稳定，TrueNAS CORE 13.3 可以直接就地升级。

女：相当于社区接手了官方放弃的分支。

男：对，这个消息正好出现在 TrueNAS 停止发布构建脚本的背景下。有人指出开源代码更难自己编译了，问是不是违反 GPL。评论区纠正说 TrueNAS CORE 是 BSD 许可，没有义务提供构建脚本，GPL 才强制要求。

女：那这算不算破坏社会契约？

男：论坛里吵得很热闹。有人说公司靠开源社区起家，然后把梯子抽走很伤人。也有人说批评者是觉得免费东西不够多。有用户分享说，他们公司现在只采用有付费支持计划的开源软件，不然就是在等 rug pull，干脆把开源当闭源对待。

女：但这样小项目就没活路了。

男：Proxmox 和 OpnSense 的做法算是一条路：提供“不适合生产”的社区补丁通道，企业得到稳定的支持，家庭用户也能继续用。FreeCORE 现在的问题还是没资金，有人质疑无资金分叉值不值得把 NAS 数据托付给它。也有人已经离开 TrueNAS：有用户改用纯 FreeBSD 用命令行管理存储，十年没出问题；有人迁移到 TrueNAS SCALE 觉得 Linux 性能好还能跑 Docker；还有人直接用 Debian 配 LVM 和 Samba。

女：这个领域的用户动手能力都挺强。

男：是，而且选择很多。FreeCORE 更像是给喜欢 FreeBSD 的人留了一条路，但能走多远没有保证。

女：开源除了经济压力，还有法律层面的东西。加州最近有个年龄验证法案，专门给开源系统开了个口子。

男：对。加州立法者一致通过修正案，把开源操作系统排除在年龄验证法律之外。修正案把“操作系统提供商”重新定义为不包括“根据允许接收者复制、再分发和修改软件的许可条款”分发系统的人。GPL、MIT、BSD、Apache 都满足，Debian、Fedora、Ubuntu、Arch 和 BSD 家族都不归 AB 1856 管辖了。

女：原来的法案要求什么？

男：要求操作系统提供商在账户设置时收集用户年龄。修正案通过后，Windows、macOS、iOS、Android 还在范围内，从 2027 年 1 月 1 日起要收集年龄。SteamOS 有点模糊，它的 Arch 基础组件是开源的，但随镜像分发了专有的 Steam 客户端。

女：那 Android 呢？底层是 Linux 啊。

男：评论里也说了，Android 作为 Linux 的商业再打包版本不会因此免责，设备上的闭源组件和 Google 服务让它仍在管辖范围内。GrapheneOS 这类开源替代品反而符合豁免条件。

女：孩子会不会以后都去用 Linux。

男：评论区真有人这么说，说 2027 年可能是“Linux 桌面之年”。还有人提到 Minecraft 已经让一代年轻人熟悉了命令行，这部法律可能进一步把年轻人推向开源系统。但也有不少担忧：有人警告这个豁免确立了“使用电脑需要知道年龄”的基线，以后可能被收紧。网站可能开始拒绝不提供年龄信号的用户，甚至要求远程证明来确认设备系统。

女：这听起来比收集年龄更吓人。

男：还有个技术细节，systemd 之前提交过一个添加出生日期字段的 PR，同时提到了加州、科罗拉多和巴西的法律。所以即便加州豁免了开源系统，那些工作也不会白做。

女：法律总是能制造出意料之外的东西。德州那边也有一个。

男：这个挺让人意外。2023 年德州议会一致通过法律，把每位车主的汽车保险费每年提高 1 美元，用来打击催化转换器盗窃。三年后，这笔钱里至少 3000 万美元被一个不太知名的州机构用来建设 Flock 监控摄像头网络。

女：等等，保险费和摄像头有什么关系？

男：《德克萨斯论坛报》的分析发现，机动车辆犯罪预防管理局发放了至少 95 笔拨款，帮执法机构购买和维护约 2000 台 Flock 摄像头；还有 1590 万美元给州公共安全部增加近 1200 台。这笔钱一共筹集了约 8100 万美元，另外 5080 万用于报销警察部门的人员、分析师、检察官、无人机和其他设备。

女：立法者当时知道这笔钱会用来买监控摄像头吗？

男：有几个投票支持的议员说不知道。州参议员 Carol Alvarado 说她从论坛报上得知保险费被用来资助 AI 车牌读取器时很惊讶。共和党议员 Brian Harrison 说，他永远想不到这会变成无证监控，否则他敢打赌法案不会全票通过。

女：Flock 摄像头具体能干什么？

男：它是全国最常见的车牌读取器，用人工智能生成“车辆指纹”，存储车牌、品牌、型号、颜色、凹痕、保险杠贴纸。全国执法机构不需要搜查令就能访问数据库。公司发言人说去年通过 Flock 找到了超过 1 万名失踪人员。但反对者认为这个网络把侵入性监控和缺乏监督结合在了一起。

女：有滥用的例子吗？

男：有。Lufkin 一名警察因为 100 项滥用官方信息罪被起诉。Baytown、Harris County 等地也有警察用 Flock 数据跟踪前伴侣或同事，被逮捕或接受调查。DFW DeFlock 的组织者 Kenneth Feagins 说，这数据能做很多恶意的事，这些事不再是假设。德克萨斯州至少 100 个城市已经终止了 Flock 合同，包括奥斯汀。

女：那现在呢？

男：8 月 28 日晚，州长办公室宣布暂停所有用于 Flock 摄像头的州资金对地方拨款。之前几小时，Abbott 在电台采访里提到了 Lufkin 那个警察的起诉案。但执法部门大多支持，Pasadena 一位警察中士说摄像头改变了游戏规则，线索多到处理不过来。

女：这个反差好大。说完地面上的监控，抬头看看太空吧。

男：正好，NASA 的 Roman 太空望远镜计划 2026 年 8 月 30 日发射，搭乘 SpaceX 猎鹰重型，从佛罗里达升空。发射窗口只有约一分钟，因为猎鹰重型加注过冷推进剂后不能长时间等待，错过就要等第二天。

女：为什么叫 Roman？

男：南希·格雷斯·罗曼，NASA 首位首席天文学家，被称为“哈勃之母”，以她命名。望远镜要去回答暗能量、系外行星和红外天体物理的问题，飞往距离地球约 150 万公里的日地拉格朗日 L2 点，航程约三个月。

女：它跟哈勃比有什么特别的？

男：视场面积至少是哈勃的 100 倍，每张图像覆盖的天区大于满月。哈勃的视场通常小于满月，韦布更小。近 3 亿像素的宽视场相机，任务期内有望测量约 10 亿个星系发出的光。

女：这规格是怎么压进预算的？

男：望远镜主体改造自一台退役间谍卫星，项目因此低于预算、提前完成。主镜来自那颗卫星，平台、电子设备和两台科学仪器由 NASA 重新打造。两台仪器是宽视场成像仪和日冕仪。日冕仪遮挡宿主星的光，直接拍摄木星大小的系外行星和行星形成盘，也是未来宜居世界天文台的技术前身。日冕仪的飞行软件有超过 10 万行 C++，运行在抗辐射的 LEON4 处理器上。

女：数据会公开吗？

男：公开，没有独占期。NASA 在任务计划里写明，所有巡天数据一经处理即公开。原始压缩数据量每天约 1.4TB，地面下行速率最高 500Mbps，实际每天下传约 1.5TB。韦布才 23Mbps。不过接触过韦布数据的研究生提醒，实际操作要在 NASA 的计算机上处理，还要付计算和存储费用，很难全部下载到本地。

女：那它跟韦布怎么配合？

男：Roman 反复拍摄同一片天区，用图像相减把每一张都出现的恒星和星系剔除，留下超新星这类瞬变天体，韦布再瞄准这些目标精查。它还会统计银河系内的行星系统。加上地面上的鲁宾天文台、哈勃和韦布的配合，未来十年的天文图像很值得期待。

女：有人问为什么不做两架 Roman？

男：评论里解释过：主镜磨制和抛光需要极长时间，成本随口径急剧上升。旅行者号、火星车这类任务确实常成对飞行，但大望远镜不这样。

女：说到地图和天区，我想起一个好玩的地理谜题，地球上最长的直线路径。

男：我正想说这个。Rohan Chabukswar 和 Kushal Mukherjee 在 2018 年用分支定界算法算出地球表面两条最长的直线：一条全程在海上，一条全程在陆上。分支定界就是在搜索空间里不断分支和剪枝来找最优解。

女：这还能验证？

男：起因是一个 Reddit 帖子。用户 kepleronlyknows 真名 Patrick Anderson 声称找到了海上最长直线，在图书馆用绳子和实物地球仪验证，后来用 Google Earth 做了可视化。作者实现算法、载入海拔数据后确认：这个 Reddit 用户是对的。

女：具体是哪两条线？

男：海上线从巴基斯坦南部近海出发，穿过太平洋、大西洋和印度洋，在俄罗斯堪察加半岛附近结束，大约相当于地球周长的 80%。地图上看很像昼夜线，因为它是一段大圆，就是过球心的平面与球面相交的圆弧，也是球面上两点间的最短路径。陆上线从中国泉州附近到葡萄牙南部，约周长 28%。论文管它叫“最长可驾驶直线”，但评论说它直接跨过阿尔卑斯山，开车不可能，步行也许还有戏。

女：如果要求不碰任何水呢？

男：那有人觉得答案就是横穿南极洲，但南极洲覆盖着固态水，夏季考察站周围还会有水坑。

女：有没有人发现更长路线？

男：有。从塞内加尔附近到中国的一条大圆路径长约 13,250 公里，比论文结果长 2000 公里。它被排除是因为路径经过死海，而论文把所有低于海平面的区域都当成水。这条路线还会穿过苏伊士运河，有评论说桥梁或隧道不算比较公平。

女：这感觉像现代版的柯尼斯堡七桥问题。

男：网上真有人这么说。还有人做了“第一人称”视角的渲染。至于地平论者，如果用以北极为中心的极地方位等距投影，最长陆上直线看起来是从葡萄牙南部到俄罗斯堪察加。

女：算法还能用来算这种纯好玩的问题，挺治愈的。不过算法有时候也会让人头疼，比如 Qubes OS 那个漏洞。

男：对，Qubes 最近发布了 QSB-118 安全公告，披露了一个允许在 dom0 中执行任意代码的漏洞。dom0 是 Qubes 里权限最高的管理域。

女：漏洞出在哪？

男：出在 qvm-copy-to-vm 的错误报告环节。用户从 dom0 往某个 qube 复制文件时，如果目标 qube 已被攻击者控制，它可以在传输确认消息里伪造文件名。dom0 端代码过滤文件名时，只把非 ASCII 字符和双引号替换成下划线，保留了 shell 元字符。然后错误处理函数用 system() 直接把命令拼进 shell 执行，攻击者就能注入任意命令。

女：这不是虚拟化边界被攻破了？

男：不是。评论里多数人也认为是 system() 的经典误用，把不可信输入拼进 shell 属于 C 语言安全基础问题。Qubes 的虚拟化边界本身还在，但 dom0 被命令注入，整个系统就没有隔离可言了。

女：如果遵守最佳实践是不是就不会触发？

男：从 dom0 复制文件本身就不符合 Qubes 最佳实践，但实际使用很常见。比如 xfce4-screenshooter 截图会先存到 dom0，再复制到其他 qube 处理。修复包是 dom0 里的 qubes-core-dom0-linux 4.3.22，所有版本都受影响。漏洞由 Tim C. 发现。注释里还提到，qube 内部的复制命令变体不受影响，因为它用 execlp() 直接执行程序，没有经过 shell。Hacker News 上还有人引用 Theo DeRaadt 多年前对虚拟化安全性的批评，争论复杂抽象是否真的提升安全。但大家都夸公告写得很清楚，PGP 签名验证步骤也很完整。

女：好，今天从芯片聊到望远镜，从爬虫聊到车牌摄像头。软件世界里有人看不见自己的 Bug，有人在看不见的地方维护着基础设施。希望这些坚持都有好结果。

男：如果你喜欢这期节目，用泛用型播客客户端订阅就行。

女：谢谢收听，我们下次再见。