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

HN 每日深度阅读 · 2026-08-02

本期主线落在个体与系统的张力上：一边是电梯调度、Lean 内核 bug、ripgrep 段错误、NetBSD 发布、Web Components、开发流水线等工程议题对可靠性与真实体验的重新审视，另一边是 AI 让"一个人的软件"和拉面站。

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

共 20 篇 · 约 14,315 字 · 约 36 分钟读完

1. 电梯调度算法：从 SCAN 到目的地派梯的真实表现

文章以可视化的方式系统介绍了电梯调度算法。最基础的 SCAN 算法（1961 年申请专利）让电梯从底层直上顶层再返回，途中接送乘客；改进版 LOOK 只到达最高被请求楼层就折返，符合大多数人的直觉。多轿厢场景下，最朴素的做法是中央调度器把新请求分配给最近的电梯。作者指出，衡量算法优劣不应只看平均等待时间，而应关注等待时间分布，尤其是 p90——人们记住的是那些等得特别久的时刻。早高峰几乎全是从大堂到楼上的单向流量，是等待时间最糟糕的时段。

奥的斯的 RSR（相对系统响应）算法给每部电梯打分，综合考虑预计到达时间、载荷、方向匹配、防聚集、附近空闲奖励等因素，并每 5 秒重新优化一次，允许把已分配给 A 的乘客改派给 B。基准测试显示，RSR 在中低流量下明显优于 LOOK，但在流量很高（电梯层层爆满）或小型建筑中，LOOK 反而更好，简单策略胜出。

反直觉的是，目的地派梯（Destination Dispatch，在楼层触屏输入目的楼层后指定电梯）在大多数场景下 等待时间反而比传统上下按钮更差。原因在于触屏一旦分配就锁死，牺牲了每 5 秒重优化带来的灵活性，只有在超高层且每组 8 部以上电梯时才可能占优。

HN 讨论中，会议散场、高层酒店周末等场景被反复提及：电梯已满仍在每层停靠开门再关门，浪费大量时间，评论者呼吁增加满载检测以跳过后续呼叫。有人把 SCAN 与硬盘寻道算法联系起来。也有人质疑模拟中目的地派梯的表现，认为真实办公场景下人们成组同去同一楼层，派梯批处理效果实际上不错。另有开发者分享了在电梯题材手游中采用 LOOK 并按等待时长加权以优化 p90 的经验，以及双层轿厢、换乘层、快线井等更复杂设定。还有评论指出用户按错方向按钮、居民楼两部电梯联动导致大车无法单独调用等现实体验问题，以及心理学层面上”让人做点事”能显著降低对等待的感知不适。

2. 如何存在：一次关于”什么都不做”的冥想练习

作者提出一个简单实验：坐着三分钟，不动、不幻想、不玩弄手指舌头，同时保持”完全满意”。他指出，绝大多数人几秒内就会难以忍受，急切地想让这段时间结束。这揭示了人类的一个奇特处境——本能地对自己”当下存在”这一自然状态过敏，总在寻找下一口冰淇淋、下一条消息、下一场对话，以逃离此刻。

文章引用了 2014 年发表于 Science 的研究：受试者独自在房间里 6–15 分钟无事可做时普遍不喜欢，许多人宁愿给自己施加电击也不愿独处思考。作者进一步指出，连”思考”本身有时也是逃避——反刍并非在解决问题，而是逃向别处躲避焦虑。人们买不需要的东西、和伴侣吵架、无聊时进食、刷令人痛苦的内容，本质都是逃离”存在本身”的策略。

作者随后给出一套具体练习：放松身体，用一次吸气或一次呼气（约 5–10 秒）作为时间单位，在这半个呼吸期间完全打开自己，接纳所有感觉——刺痛、怪异、不安、怀疑——不抵抗、不紧绷，像”人形水洼”一样。分心也没关系，休息几口气再继续。随着熟练度提高，可以把多个半呼吸串起来，延长至五分钟乃至更久。他刻意避免使用”冥想”一词，以免把事情复杂化，强调”最小有效剂量”就是半次呼吸。

HN 讨论热烈且分化。有人坚持每天冥想 20 分钟长达数十年，认为它显著降低了情绪冲击、让人更温和；也有人诚实分享连续冥想近 200 天但”毫无感觉”，最终放弃。有评论引用 Oliver Burkeman《四千周》，将现代人对”行动”的执念追溯到工业革命后按时间售卖劳动的转变。有人质疑那项”宁愿电击也不独处”的研究解读，认为受试者只是好奇新玩具。还有人指出，在追求冷静之前应先戒掉垃圾食品和无脑刷屏；也有人反思：“想让自己更能安于无为”本身是否也是一种’为’——构成了正念实践的内在悖论。多位评论者提到长距离散步、深井下的绝对黑暗静默等替代方式所带来的类似效果。

3. 一个人的软件：AI 让”家常菜式应用”成为现实

文章呼应 Robin Sloan 2020 年”家常菜式应用”的理念——只为几位家人做一个 App 也算成功。作者认为，2026 年的 AI 编程工具终于让这种”极度个人化的软件”变得普及可行。他在过去六个月里为自己和家庭构建了大量小工具：按照睡眠顾问 PDF 中条件逻辑自动排程的婴儿睡眠 App（妻子、保姆和他共享，随小睡失败自动重排），把 Strava、Oura、Withings 和 FatSecret 数据聚合、根据当日跑量调整八种原料早餐奶昔配比的健身 App，基于个人比赛成绩而非年龄公式推导心率区间的马拉松训练计划，量化钢琴课上和弦声位的”爵士版 Duolingo”，以及在专科就诊前梳理病历缺口的工具。

技术栈方面，他使用 Claude Code Max、Anthropic API、Vercel 和 Neon，总成本约每月 160 美元，其中大部分是本就会订阅的 Claude；轻量使用者通过免费额度可控制在 25–30 美元。作者总结了几点心得：构建成本断崖式下降，想象力成为唯一瓶颈；维护出乎意料地简单，截图反馈让 Claude 修 bug 通常一次到位；聚合多源数据 + LLM 生成洞见是新的通用模式；短命应用完全可以接受（睡眠 App 用了四个月就退役）；AI 一方面制造大量同质应用，另一方面也解锁了”公司不愿做但值得做”的小众场景；好的 API 变得比以往更重要；构建过程本身既有趣又”像老虎机般上瘾”。他预测随着 ChatGPT 等工具进一步降低门槛，非开发者也会加入自造软件的行列。

HN 讨论中，许多人晒出了自己近期为个人需求 vibe-coded 的工具：带 agent 循环的 Apple Music 播放器、卡路里追踪器、菜单栏温度监控、SageMath 计算器前端、蒙古语版 Duolingo、本地 LLM 路由器等等。一条高赞评论强烈反对”家常菜”的类比，认为用 AI 生成软件更像”把方便面配上微波蔬菜”，AI 热潮最令人沮丧之处正是科技从业者贬低人类亲历创作的价值。另有资深开发者回忆 90 年代 FoxPro、MS Access 让非技术人员也能做表单应用，指出 SaaS 整合浪潮曾摧毁那一波”个人软件”，并预言长期而言人们仍会倾向订阅 5 美元/月的成熟产品，因为”没人真想调试自己写的东西”。也有人对文中顺带提及的”睡眠顾问用 PDF 输出条件逻辑方案”这一行业感到新奇。

4. Google 如何一步步扼杀了 RSS 的普及（2023）

文章梳理了 Google 在 RSS 生态中”拥抱、扩展、扼杀”的完整轨迹。早期 Chromium 在地址栏内置橙色 RSS 订阅按钮，可一键订阅当前站点的 feed，之后被无声移除，官方从未给出理由。2007 年 Google 收购 FeedBurner，将开放 RSS 替换为私有可加广告和追踪的版本；2012 年关闭 FeedBurner API，切断第三方集成；2022 年又下线邮件订阅等核心功能，导致大量订阅链接失效。

2005 年推出的 Google Reader 曾是最受欢迎的网页 RSS 阅读器，2013 年被关闭。官方理由是”使用量下降”，但当时在 Google 工作的工程师透露”整个项目期间一直有人试图杀掉它”。这一决定被广泛认为是 RSS 用户规模断崖式下滑的转折点：没有替代品，也没有迁移引导，大量用户干脆放弃了 RSS。同年 Google Alerts 也一度移除 RSS 输出选项，在强烈反弹后才恢复，但用户流失已成事实。Google 自家的 Chrome RSS 扩展也曾被下架又”因失误”恢复；Google News 中的 RSS 集成同样被逐步移除。文章将这些行为归结为一个模式：借开放协议积累用户信任，再在用户锁定后抽走支持。

HN 讨论中，多位评论者哀叹 2000 年代初的互联网”更特别”，如今 99.999% 的内容被围在少数花园之内，浏览器、操作系统乃至协议都为广告投放而优化，而 RSS 因去中心化、无法插入广告，天然不符合平台利益。有人特别气愤 Google Reader 关停时官方以”使用量下降”为借口，却在同期力推几乎无人问津的 Google+。也有人补充 Firefox 64 移除 Live Bookmarks 也是一记打击。有开发者呼吁复兴开放网络，介绍如何用 Rails 免费为电商站点、订单、追踪信息添加 RSS 与其他表征。多人推荐 NetNewsWire 等桌面阅读器，指出 RSS 从未真正死亡，“这条讨论我就是从 RSS 里点进来的”。也有反思声音：博客作者未必愿意支持 RSS，因为它剥离了排版、字体、交互带来的”氛围”，也压缩了变现路径；另有人认为电子邮件 newsletter 因能获取读者邮箱、可衡量打开率、可售卖付费订阅，是 RSS 衰落的另一重要原因。还有评论指出对普通用户而言 RSS 的价值很难解释清楚，一旦浏览习惯定型，“非常规”的方式就本能地被视为错误。

5. ripgrep 的 musl 版本在超大规模搜索中偶发段错误

该 GitHub issue 报告了 ripgrep 使用 musl libc 静态构建的二进制在执行体量非常大的搜索任务时偶尔会崩溃 segfault，而 glibc 构建则无此问题。原始网页抓取失败，但从 HN 评论可以拼出事件的高层脉络：一位调查者提交了一份深入分析，最终线索指向 Linux 内核层的一个 bug，相关内核补丁邮件列表讨论中明确提到”在 ripgrep 中看到了一份有趣的报告，以及一份用心但相当糟糕的 AI 生成分析”，指的正是那份分析文档。也就是说，看似 ripgrep 或 musl 的问题，根因很可能位于内核。这属于典型的”最底层组件被最上层用户程序意外暴露”的案例，披露正在进行中，修复方向在内核补丁而非 ripgrep 本身。

HN 讨论集中在几方面。首先是关于 musl 默认分配器 mallocng 的性能与并发行为：有评论者分享经验，musl 默认分配器在多线程（哪怕仅 8 线程）竞争下会让原本 I/O 密集的应用变成 malloc 瓶颈，切换到 mimalloc 后性能提升可达 20 倍，接近甚至媲美 glibc + mimalloc 的组合；因此对以”快”为卖点的 ripgrep 仍使用 musl 默认分配器感到意外。有人进一步追问：为什么这个 bug 只在 musl 下出现而不在其他 libc 下出现，怀疑与 musl 默认线程栈更小有关。也有人质疑内核 bug 是否已被确证。另一条较为尖锐的评论批评在大型 HPC 集群共享文件系统上直接跑 ripgrep 属于工作流设计问题——它会产生海量小 I/O 冲击元数据子系统，几个用户同时这么做就足以让高带宽集群文件系统跪倒，建议改造工作流让数据留在内存子系统中处理。文中未涉及任何复现细节或 exploit 内容。

6. Cursor 从用量页面和 CSV 导出中悄悄移除了美元成本信息

Cursor 用户在官方论坛集中反映：一直用于日常盯预算的 Usage 页面突然把美元金额换成了 token 数量，CSV 导出中的 Cost 列也一并消失。多位重度用户表示这让他们无法再按用户、按模型追踪团队消费，其中一位 Teams 计划管理员称本计费周期已产生约 3 万美元支出，几乎全部按 API 定价计费，如今失去了原有的细分视图。

Cursor 员工 Kevin 在帖中解释：个人计划不再显示美元金额是”有意设计”，因为个人计划包含较慷慨的额度，此前把这部分显示为美元让用户误以为是实际账单，产生了混淆；企业计划因采用共享额度池仍保留美元展示。Ultra 计划下按 token 计费，计划内用量标记为”Included”不收费，超出的按需用量在 Cost 列仍会显示美元。他指引用户前往 Dashboard > Spending 查看当前周期的按需支出，或在 Usage 页面导出 CSV。事件发酵后另一名员工进一步说明，CSV 中美元列消失系昨日清理旧 feature flag 时”意外损坏”，已修复；面向部分自助用户显示的美元图表则因”包含用量以美元展示”引起持续混淆而被主动下线。

HN 讨论普遍偏负面。多位评论者将其解读为在被 SpaceX 股票收购后为支撑高估值而进行的”用户敌意”操作，认为隐藏成本不可能有正面解读。也有人指出 Cursor 早期借易于从 VS Code 迁移而快速崛起，反过来同样易于迁回，加上 Codex、Claude Code、Claude Desktop 在能力上已经追平或反超其 agentic 与 IDE 体验，Cursor 的护城河主要剩下自研 Composer 2.5 与批量采购 Claude 额度带来的价格优势。一条高赞技术评论展示了同一任务在不同 agent harness（smol、Pi、OpenCode、Codex、Hermes、Claude Code）下 token 用量相差数十倍的实测数据，从 17 万到 500 万不等，强调选择 harness 对成本的影响可能远超选择模型本身，建议使用者定期实测。还有企业用户表示因隐藏成本、无法自建 API 代理以及对 IP 保护的不信任，将建议管理层不再续约。也有人本月观察到即便宣传”用量翻倍”，Composer 2.5 上的额度反而消耗更快。

7. 伪装的监控条约：加拿大悄然签署联合国网络犯罪公约

Michael Geist 撰文批评加拿大政府在 7 月中旬几乎没有引起公众注意的时机下签署了《联合国打击网络犯罪公约》。官方新闻稿强调其儿童保护条款和”国际刑事司法条约中最强人权保障之一”，但作者指出这份条约实质上并非网络犯罪条约，而是一份宽泛的跨境监控与电子证据共享协议——加拿大原本反对它，二十家加拿大公民社会组织和专家曾联名呼吁政府拒签，多个关键盟友迄今仍未签署。签署本身不产生约束力，需批准（ratification）才会生效，但九个月前加拿大在河内签署仪式上明确缺席，如今却在无公众咨询、无解释的情况下改变立场，令人不安。

该公约源自俄罗斯 2017 年的倡议，旨在替代加拿大等国已加入、俄罗斯拒绝加入的《布达佩斯公约》。2019 年联合国大会启动谈判时，加拿大与美国、欧盟一同反对，担心其扩张国家监控权。表决失败后，民主国家选择”进场博弈”以限制损害，成功将威权阵营主张的”言论与内容犯罪”清单挡在最终文本之外，条约于 2024 年 12 月经协商一致通过。但公约所列的程序性权力适用于任何刑事案件的电子证据，国际合作义务覆盖任何本国法律下最高刑期四年以上的”严重罪行”——某些国家将批评政府、新闻报道、亵渎、同性关系等定为此类罪行，条约实际上把这些国家的压制性法律转化为跨境取证的触发器。EFF、人权观察等指出，公约要求各国建立实时拦截和数据收集能力，却将事先司法授权等保障留给各国自行决定，允许对合作请求下达封口令，也缺少政治罪例外条款。加拿大 24 家组织在 2024 年 12 月的联名信中警告，条约将成为针对加拿大境内海外侨民社群实施跨国压制的常设通道，并可能架空加国现有的司法互助保障框架。作者猜测此次签署与国内”合法访问”（lawful access，如 C-22 法案中扩展的调取令与跨境数据共享权力）议程相互配合，因为批准公约将需要正好这类立法。

HN 讨论涵盖了信号博弈（政客在不同受众间”眨眼”的双层沟通），对 Michael Geist 多年隐私议题报道的赞扬，以及对签署国名单的观察——名单中同时包括朝鲜、沙特、中国、俄罗斯、伊朗与英国、澳大利亚、法国、德国、欧盟等，美国目前尚未签署。多位评论者将其与推进国际化年龄验证、身份验证挂钩，认为封锁匿名访问是执法跨境化的前置条件；也有人质疑各国政府对”网络犯罪分子”实际上心照不宣地存在某种默契，条约的现实执法价值有限；还有评论呼吁美国推动一份保护数字权利（维修权、root 自有设备权、免于大规模监控权、通用计算权、不受政府强制身份/年龄核验访问言论权）的宪法级”数字权利法案”。

8. 灯泡寿命越长，其他方面就越差

文章重新审视了广为流传的”Phoebus灯泡卡特尔”故事。1925年灯泡制造商确实合谋将白炽灯寿命标准化为1000小时，但作者认为流行叙事中”这是为了让人多买灯泡”的结论建立在一个错误的前提上：即长寿命灯泡是好产品。

文章从工程原理解释了这一权衡。白炽灯依靠钨丝加热发光，可见光的理想温度约为5700°C（太阳表面温度），而钨的熔点仅为3422°C。因此灯丝必须运行在熔点以下，发射峰位于红外区，只有高能尾部对照明有用。温度稍微升高，效率会大幅提升、光色更接近白光，但代价是钨原子蒸发加速、晶体滑移，寿命急剧缩短。因此色温/效率与寿命之间存在本质权衡。

作者以那盏在加州消防站点亮120多年的著名灯泡为例：它标称60W却只消耗4W，昏暗发橙，实际上很可能是残次品，只能当夜灯用。早期手工灯泡昂贵，都被优化为长寿命，代价是效率极差。自动化生产后，灯泡便宜到只有几美元，而1000小时使用的电费高达6美元，因此优化效率而非寿命才合理。作者指出，即便卡特尔只维持14年，现代非卤素白炽灯寿命依然在500–2500小时区间。之所以需要卡特尔强制执行，是因为消费者天然偏好”寿命长”这个易懂指标，市场竞争会逼制造商生产更差的产品。

HN讨论中，多位评论者认同工程逻辑成立，但指出这只是卡特尔的”合法化包装”——真实动机仍是价格合谋与利润，用合理论据推向不合理极端才是商业合谋的常态。若目的是避免劣质竞争，禁止虚假广告即可，不必真正限制寿命。也有人吐槽LED灯远达不到宣称的5–7年寿命，讨论了外置驱动器、24V直流灯具方案等话题。Technology Connections的相关视频被多次推荐作为延伸阅读。

9. 硅谷创始人”绞肉机”：一个真实故事

作者讲述了一位化名”Jim”的朋友的真实经历，以此反思硅谷创始人文化的运作机制。Jim原本在训练营学编程，靠富家女友供养、兼职酒保。他有野心、勤奋，且高大有魅力、带英式口音，能吸引他人注意。作者通过人脉帮他在一家创业公司找到工作，一年后公司被财富100强收购，Jim瞬间跻身六位数薪资阶层。

但收入上升暴露了Jim的弱点：他失去专注，花一万美元买树切片桌、养宠物、酿啤酒，生活方式膨胀。几个月后被解雇，随后瞄准硅谷。通过前老板的引荐，他与一位美国人一起申请YC并成功入选。此后是社交媒体上一连串炫目更新：与Sam Altman合影、豪言壮语、高估值数字。首个创业失败后，他又加入另一家创业公司当工程负责人（距他训练营结业仅3年），再联合创办新公司，接连失败。他的发帖变成每日的AI生成内容，中间穿插疑似药物影响下的全大写乱语。

之后便是沉寂。一年后作者从共同朋友处得知，Jim参加了旧金山的”创始人派对”、群交等狂欢，与未婚妻分手、精神崩溃、身无分文，最后借钱买机票回国，从此消失。作者虽然措辞带批判，但坦承他钦佩Jim的勇气，并反思自己稳健但线性的路径。他认为硅谷有一套完整流水线，成千上万的”Jim”进入这台绞肉机，少数被追捧，多数被碾碎。

HN评论呈现多种视角。有人分享了相反的正面案例：一个曾露宿废弃船上的人，坚持之下最终做出年入千万美元的产品，强调”坚持胜于聪明”。多位评论者指出湾区存在大量”扮演创始人”的人——他们享受身份带来的生活方式，却不做真正的工作；真正做出成就的公司环境反而”无聊”。还有人批评当下科技文化过度以金钱为导向，2010年前后的湾区更多聚焦于构建产品。另有评论提到”福布斯30 under 30到监狱的管道”现象，以及创始人圈子的兄弟会气质：靠外表和人脉进入高位，缺乏实际能力。

10. RamenHaus：一个旋转拉面网站

RamenHaus是一个极简的个人网站，由Ole Reissmann创建，专门收录拉面照片。截至发布，站点已展示114碗被拍摄、品尝并发布的拉面。用户可以从最新一条开始浏览，点击图片切换到下一碗，或查看完整索引。网站灵感来自Lauren的”Rotating Sandwiches”以及Naive Yearly社群。整个站点强调”无cookie、无打赏、无JavaScript，只有拉面”的极简理念。

HN讨论呈现多样化面貌。有评论者推荐经典日本电影《蒲公英》（Tampopo）作为拉面文化入门。有人坦言未去过日本，在西方城市尝试的拉面常常令人失望，认为其在西方被过度炒作，价格与内容不匹配。也有争论：一个旋转拉面的网站为何能登上HN首位。多位用户分享了个人计划：其中一位常年拍摄各式洗手台，被这个网站启发想做一个类似的”世界洗手台”站点，专注于水槽与水龙头搭配的奇特比例差异。

技术层面，有Linux用户发现自己Firefox里图片不旋转，追查后发现KDE开启了”减少动画”设置后浏览器会自动响应prefers-reduced-motion: reduce，意外了解到该CSS特性的工作机制。一位东京日本人评论说没想到其他国家的拉面看起来这么好。还有人分享类似的往事：早年利用Twitter开放API开发过一款叫”ramendan”的游戏，玩家需每天吃拉面晚餐并带话题标签、图片、地理位置标记发推，回忆那是”科技界更天真、更快乐的时代”。另有评论推荐了德语的拉面历史播客，以及东京赤坂的”一点張”、大阪的”たぶちゃん”等具体店铺。整体讨论氛围轻松愉快，围绕食物、极简网站美学和个人回忆展开。

11. 微软Flint：面向AI时代的可视化语言

Flint是微软发布的一个可视化描述语言，定位为”AI时代的图表语言”。其核心思路是提供一套统一的抽象接口，让LLM或AI代理生成简单的Flint规范，再由底层适配到不同的图表后端（如ECharts擅长层级旭日图、Plotly擅长统计分析、Excel擅长可编辑图表等），根据后端的强项路由渲染。

HN讨论对这一定位普遍存疑，是本条目最集中的争议焦点。多位评论者质疑”为AI时代设计”的说法：LLM已经在海量现有图表库（matplotlib、Plotly、Vega-Lite、ggplot等）上训练过，直接生成这些库的代码效率很高，再引入一层DSL反而增加抽象负担。有人担心Flint未能提供任何证明其优于既有方案的基准测试或量化数据，官方文档中也未解释为何这对LLM更友好。

一位用户分享了实际对比经验：让AI直接生成Vega-Lite规范比通过Flint能获得更高的灵活性和质量（例如为时序图添加最大最小点、为特定日期添加事件标记）；Flint适合预设图表类型、定制度低的场景，快速上手且更可靠，但需要深度定制时不如直接用Vega。也有评论怀疑Flint的长期策略可能是推出配套的”图表基准测试”，诱使AI实验室在其DSL上过拟合。

另一条高赞评论借机赞扬ggplot2的”图形语法”（Grammar of Graphics）设计：其名字并非营销噱头，作者们真的尝试写一套能表达所有定性图形的语法，还专门出了理论书。该用户还提到1960–80年代澳大利亚储备银行年报中手绘图表的独特魅力，认为现代图表库缺失了这种表达力。

也有人从架构角度提问：既然AI能写Flint，为何不直接让它写后端代码？可插拔后端到底解决了什么真实痛点？另有人指出这是Flint在HN的第三次讨论，前两次分别在7月2日和7月8日。

12. NetBSD 11.0 发布

NetBSD项目发布了11.0版本。此次发布延期较久，主要因为要等待第三方组件的稳定版本以获取修复，并且团队坚持每次改动都先发布候选版让用户测试。发布流程虽已尽可能自动化，但安全官签署发布哈希等步骤仍需人工介入，且受限于跨架构文件传输时间。

版本亮点（据发布公告）包括：npf(7)防火墙改进，新增二层过滤和基于用户/组的过滤；新的MICROVM x86内核，可在约10毫秒内启动；多项硬件支持改进。安装镜像分为CD-ROM尺寸（<700MB）和完整DVD版本，ARM设备可从armbsd.org获取预配置U-Boot的可启动镜像。

值得关注的是，NetBSD团队在发布公告中罕见地公开说明了未修复的安全问题：由于AI工具的出现使得安全漏洞发现和报告数量激增，团队无法在发布前修完所有问题，选择透明化处理。目前公开的三个待修复问题涉及hdaudio的ioctl访问检查（有简单的手动缓解方案）、ipfilter中可远程触发的空指针解引用（默认内核未包含IPF）、以及pf碎片重组中的use-after-free（PF已被废弃，默认内核未包含）。所有待修复项将在11.0发布后不久合入稳定分支，进入计划两个月内发布的11.1版本。

HN讨论中，有人对BSD家族（FreeBSD、OpenBSD、NetBSD）的现状和使用者群体感到好奇，希望了解其规模、特性、安全加固情况以及发展趋势。多位评论者赞赏NetBSD团队对开放安全问题的”近乎道歉式”的坦诚态度，认为其他组织不会这样处理。有评论对新增的npf二层和用户/组过滤、10毫秒启动的MICROVM内核表示赞赏。有人询问NetBSD上Wine的现状，希望在旧ThinkPad上运行仅Windows版的SDR软件。也有对CD-ROM镜像仍在发布感到怀旧，讨论了是否仍有系统只能CD启动而不支持USB启动。一位用户分享了使用cgd(4)加密的sysupgrade(8)顺利完成升级的经历，表示候选版就已相当稳定。

13. 加缪的荒谬

文章以1944年8月巴黎解放前夕的一幕开场：加缪造访法兰西喜剧院时发现负责守卫剧院的萨特已在座位上睡着，他打趣道：“你已把座位转向历史的方向。“这句玩笑既反映了两人友谊，也暗示了后来使他们决裂的历史观分歧。加缪出身法属阿尔及利亚的贫困家庭，由几乎不识字的寡母抚养长大；萨特则来自资产阶级、就读高等师范。两人1943年结识，加缪聘萨特为抵抗运动报纸《战斗报》撰稿，萨特则邀加缪主演《禁闭》。

文章重点阐释加缪的”荒谬”概念：人渴望理性与清晰，却面对生命的非理性与无意义，这种矛盾构成人类存在的核心。面对荒谬，享乐主义、信仰、绝望乃至自杀都是通过否认荒谬来逃避——但由于正是理性使我们感知荒谬，否认荒谬等于否认人性本身。加缪主张接纳荒谬：既然存在无意义，就充分地活、承认死亡必然、爱情善变、名声易逝，做”幸福的西西弗”。《局外人》中的默尔索就是这种态度的戏剧化。

在《反抗者》（1951）中，加缪把荒谬延伸到政治：反抗是对不义的本能回应。此处他与萨特分道扬镳。萨特虽不认同马克思的历史决定论，但仍认为若人们像信仰共产主义理想那样行动，就有机会实现它。加缪早年在阿尔及利亚曾加入并被开除出共产党，但二战和纳粹经历使他改变立场。他区分”反抗”与”革命”：革命试图通过创造完美社会来终结历史，结果反而摧毁其所声称保护的自由与人性；在此意义上苏联与纳粹德国无异。反抗则强调共同人性、坚守生命价值，通过团结在历史中战斗，而非终结历史。

HN讨论中，评论者高度赞赏《西西弗神话》的结尾力度，尤其”必须想象西西弗是幸福的”之前那些累积的隐喻。有深度评论认为《局外人》和《西西弗神话》仍是年轻时期的思考——用观念和词语试图与荒谬和解本身也未脱离荒谬，而《鼠疫》中里厄医生的整体存在才是更成熟的和解。多人推荐早期作品《婚礼集》（1936），认为它以诗意法语描绘对物质存在的感官热爱，为”荒谬”提供情感基石。有读者分享《局外人》如何软化了自己”新无神论”时期的傲慢，让他更同情人们对意义的追寻。也有细致的文学批评：认为《局外人》前半部达到大师级别，但后半部转折牵强、审判场景荒诞、结尾的不可靠叙述者问题严重。还有人推荐Ronald Aronson的《加缪与萨特：友谊与决裂》。

14. 《64位汇编的艺术（第二卷）》

Randall Hyde的《64位汇编的艺术》第二卷预计2026年6月出版，共约792页。副标题为”机器级面向对象、异常与并发”。全书基于Windows平台的MASM汇编器，将高级语言中常用的构造在指令级别从零重建：vtable与方法派发、继承、Windows结构化异常处理（SEH）、thunk与闭包、协程/生成器/纤程、并发同步原语、正确的Unicode字符串处理、以及在MASM之上构建领域专用宏语言。

书籍的营销文案以一段颇具争议的开场吸引注意：“你可以问AI vtable在x86上是如何工作的，它会给你一个听起来正确的答案，但它不会告诉你Windows实际期望的vtable结构、方法派发在指令级的真实行为，以及偏离约定时会出什么问题。“作者Randall Hyde曾长期为医疗设备、核系统和嵌入式硬件编写汇编代码，在大学教授汇编，著有《汇编语言的艺术》《ARM汇编的艺术》以及Write Great Code系列。

HN讨论中，有元评论者困惑于近800页汇编巨著竟然引发的讨论集中在”不喜欢营销文案第一句”、“不喜欢作者选用的工具”和”如果用LLM训练这本书会怎样”三类无关话题，几乎无人真正评论已放出的第1章”高级宏”样章。

多条评论抱怨开场那段”你可以问AI但AI做得不好”然后紧接着又像是AI生成的文本，认为不合胃口，希望作者能自己重写。工具选择也是争议焦点：多位评论者质疑为何选MASM——“64位汇编 + x64 + Windows + MASM”限定太狭窄，NASM/YASM等更受欢迎；也有人希望看到Linux版或POWER ISA版。有GNU汇编器开发者对比了MASM与GAS的宏能力，指出GAS缺失while循环、字符串处理等特性，MASM的%表达式求值也远比GAS的altmacro模式通用。

也有实用主义质疑：为追求性能而直接写汇编不如自己写编译器——汇编启动成本低但正确性维护困难，需要时刻在脑中跟踪寄存器状态与调用约定的破坏关系，两个月后回头调试几乎无望。另有读者惊喜作者仍在更新这套书，几十年前就从更早版本学过保护模式汇编。也有人推荐Daniel Kusswurm的汇编/C++系列和Igor Zhirkov的《底层编程：Intel 64架构上的C、汇编与程序执行》作为延伸阅读。

15. 百年后重见天日：梅西百货中间的”钉子户”小楼

纽约先驱广场（Herald Square）梅西百货旗舰店西北角，一栋五层高的小楼在被广告牌遮蔽超过一百年后，近期因facade改造而重新露面。Ephemeral New York 追溯了这段20世纪初纽约零售业大战的历史。

约1901年，梅西百货计划从14街的”淑女大道”购物区迁至先驱广场，逐块买下34街与第六大道交叉口的地皮，包括餐厅、理发店以及曾放映首场投影电影的 Koster & Bial 音乐厅。唯独一块30×50英尺的角地属于牧师 Duane Pell，他开出25万美元的天价。就在梅西同意收购前，Pell 却以37.5万美元将地卖给了竞争对手 Siegel-Cooper 百货老板 Henry Siegel 的代理人。Siegel 提出用这块地换梅西即将空出的14街店铺，遭梅西断然拒绝。梅西选择绕着这块角地建造新旗舰店，以彰显其行业地位。1903年 Siegel-Cooper 拆掉原有小楼，建起了如今这栋由 William Hume 设计的五层建筑。

自1920年代起，梅西一直向该楼业主租下外立面用于广告，最近的一版是巨型红白购物袋。楼宇现由 Kaufman Realty 持有超60年。2021年《纽约邮报》曾报道，Kaufman 试图在梅西租约到期前将广告位租给另一家公司（梅西怀疑是亚马逊），并援引1963年”永久禁止”竞争对手广告的协议提起诉讼，因此广告牌拆除与租约谈判相关。

HN 评论区有人指出这栋建筑在维基百科上被称为”百万美元角”（Million Dollar Corner），并类比伦敦 Wickhams 百货中间的 Spiegelhalters 珠宝店钉子户。也有人调侃标题”in the middle of”用词不准确，实际位于街角而非正中。多位纽约本地用户表示，长期在附近上班或路过却从未注意到广告牌背后藏着一栋独立建筑，趁”Summer Streets”活动特意前往拍照。还有评论好奇：出租广告面板与出租公寓住户，哪个更赚钱？有人认为该楼外观破败，怀疑内部是否仍有人居住。整篇讨论围绕城市中”隐身”于日常景观里的历史遗迹展开，带有典型的城市考古趣味。

16. I♥RSS：一个面向RSS爱好者的目录站上线

Andrew Shell 推出了 iheartrss.com，一个供 RSS 爱好者登记自己网站的目录。站点提供徽章供网站主嵌入页脚，首页展示由 FeedLand 驱动的实时博客列表（blogroll），可看到哪些人订阅了某个博客以及他们还订阅了什么，试图在不依赖算法推荐的前提下让 RSS 具备一定的社交属性。作者本人也已把徽章添加到自己博客的页脚并提交了站点。

HN 讨论热度相当高，衍生出几条主线。第一，多位用户借机推广类似项目，例如 rssvault.org 试图解决 RSS 目录长期失修、订阅按钮消失等痛点，并计划推出以小组件为核心的手机端应用，呼吁”RSS 复兴”。第二，关于格式本身的争论：一位用户强烈表达”讨厌 RSS”的观点，认为该格式在有机演化中积累了大量无法可靠表示的边角情况，本应在二十年前被 Atom 1.0 完全取代；他呼吁停止将 feed 一律叫作”RSS”，因为许多新实现者根本不知道 Atom 的存在，导致重复痛苦地实现有缺陷的 RSS。也有开发者站在解析者角度吐槽：即便标准简单，实际部署中大量站点输出的 RSS 格式微妙地不符合规范，用户会以”别的阅读器能读你的不能”施压，迫使 reader 不断增加对越界情况的兼容。

第三，怀旧与生态。多位评论者表示”我爱的不是 RSS，而是坚持写博客的人”，希望更多人回到旧时代那种记录日常、随想的博客文化。一位博主提到 RSS 依然是自己博客最大流量来源之一，但他自己自 Google Reader 关停后就不再是 RSS 消费者。也有用户推荐自托管方案 miniflux，以及基于 SSH 的 pico.sh 服务集群（含 RSS 转邮件应用）。还有人称赞 FeedLand 的社交化 blogroll 设计和该目录站的策展价值——不同于那些机械收录一切feed的巨型清单。也有轻松的观察：HN 标题里居然出现了彩色 emoji 心形，引发不少人惊讶。

17. 开发流水线就是生产系统

Jerry Orr 提出一个简单却常被忽视的观点：对开发团队而言，开发流水线本身就是生产系统。软件开发者从入行起就被灌输”生产环境故障最紧急、需全员响应”的理念，但对开发工具、构建系统、QA 环境等基础设施的问题，团队往往容忍度极高。作者认为这是错位的：开发者的职责是为公司交付价值，而当代码无法编译、CI 挂掉、QA 服务器宕机、包仓库不可访问时，团队实际上无法生产任何软件——这对开发团队就是”生产事故”，对 QA 团队亦然，应享受同等优先级。

文章列举了应纳入”广义生产系统”考量的组件：Issue 跟踪系统（Jira、GitHub Issues）、IDE 与构建工具（Gradle、Maven）、包仓库、本地容器与数据库、CI/CD（Jenkins、GitHub Actions）、测试套件、QA 环境，以及任何阻断”从需求到部署”链路的环节。作者类比制造业将其称为”生产线”（production line），暗示软件业对”production”一词的用法或许正源自工业生产。

HN 讨论中，做基础设施运维的评论者提供了纵向视角：越往底层看，“生产环境”的范围就越向开发端延伸——对产品开发者，用户系统是生产；对基础设施运维，dev 与 test 环境同样是生产，甚至配置管理测试和部署流水线本身就是他们的生产系统。有大厂经验的评论者证实，无法部署代码在大公司确实会被当作事故对待，CI/CD 团队常设 on-call，也常有专门的 Developer Experience 组织，但效果参差不齐。

也有反对声音。有评论者直言”不，它不是生产系统”：如果流水线在周六晚上坏了，没有立刻抢修的必要；关键是要有绕过流水线的紧急热修复通道，因为真正的生产环境必须在流水线故障时仍能修复。另一评论批评文章仅反复强调结论、未讨论优先级取舍与成本收益，等同于说”重视你的工具”这样的空话。还有人指出，同样存在因过度投入工具链而忽视产品交付的失败案例，究竟应处于光谱的哪个位置取决于市场与产品阶段。另有评论者分享了一个真实事故：部署脚本使用 rsync —delete 后误删了不在 git 中的 .env.local 与生成内容，提醒”把流水线当生产系统”还应包括审计流水线本身的写入范围与权限。也有人将思路扩展到招聘流水线——招聘停摆同样能拖垮公司。

18. Progressive Web Components：从 HTML 与 CSS 出发的 Web Components

Ariel Salminen 基于近十年构建企业级设计系统的经验，提出”Progressive Web Components”（渐进式 Web 组件）设计理念，并开源了配套库 Elena（压缩后仅 2.6kB）。作者认为 Web Components 作为跨框架、基于平台原生能力的设计系统基础仍具吸引力，但现有实现普遍存在布局抖动（layout shift）、无样式内容闪烁（FOUC）、SSR 支持差、过度依赖客户端 JS、与 React Server Components 兼容不良、可访问性问题等痛点，根源在于构建方式而非模型本身。

Progressive Web Component 是分两层构建的原生 Custom Element：基础层是无需 JS 即可立刻渲染的 HTML 与 CSS，增强层则用 JS 添加响应式、事件与模板。作者划分了三种类型：Composite Components（HTML Web Components，包裹并增强内部 Light DOM 中的 HTML）、Primitive Components（自包含、渲染自己的 HTML，CSS 与初始 HTML 均在 Light DOM）、Declarative Components（结合 Declarative Shadow DOM 的混合型）。Elena 不强制这套分类，仍完整支持标准 Custom Element 生命周期、开/闭 Shadow DOM、template 与 slot。SSR 方面，没有 render() 的组件天然可 SSR，有 render() 的组件可先渲染初始状态、客户端再水合。

HN 讨论集中在几个方向。高票评论主张应把 Web Components 理解为”Custom Elements”而非其他框架意义上的”组件”：它们在渲染效率与表达力（如无根片段、context API）上永远比不上 React 等框架的组件，但作为跨框架的自定义元素 API 套件与框架组件共存时价值就显现出来了。作者感慨主流框架对 Shadow DOM、局部样式与局部事件的支持不够。另有一线开发者分享了踩坑经历：其平台团队本以为纯原生 JS 写 Web Components 即可跨框架复用，但在 React 中遇到重渲染清空组件状态、切换按钮无限重渲染、事件处理无法强制约束导致线上多起 P0 事故等问题，说明”跨框架兼容”名义上易得、实践中代价不小。

也有正面评价：文章介绍的 Elena 的语法类似 Lit，但”HTML+CSS 优先、JS 仅作增强”的思路更贴近应有的做法。有人分享用 Custom Elements API 创造 元素、结合 MutationObserver 升级