2026年08月09日 · 星期日 第 160049 期

The Hacker Daily

丙午年(马)六月廿七

30 篇文章 · 1530 条评论 ·聚焦:复古计算 · AI代理 · 系统性能
No.01 Microsoft Word for Windows 1.1a, Native X64 Port
Microsoft Word for Windows 1.1a 的原生 x64 移植版
40 分 15 条评论 作者: BruceEel
该项目将早期 Microsoft Word for Windows 1.1a,也就是历史代号「Opus」的版本,移植为可在现代 Windows x64 上原生运行的程序,而不是依赖模拟器。评论者认为,把 16 位分段内存模型转换到 x64 并保持界面工作流可测,是相当有难度且有价值的复古软件工程。讨论中也出现一些质疑:有人尝试构建时发现仓库似乎缺少 CMake 生成菜单帮助头文件的脚本;也有人觉得 README 带有 LLM 写作痕迹,并延伸到 AI 是否正在改变这类移植工作的成本与可行性。另一个轻松话题是「Opus」这个代号与 Anthropic 模型及其词义的混淆。

评论精华

  • 有人构建时发现仓库缺少 cmake/GenerateMenuHelpHeader.cmake。
  • 评论称赞从 16 位分段内存到 x64 原生移植难度很高。
  • 测试套件覆盖 UI 工作流,被认为是项目亮点。
  • 「Opus」代号引发与 Anthropic 模型和词义的玩笑讨论。
  • 有人怀疑 README 有 LLM 痕迹,并讨论 AI 改变移植经济性。
No.02 My server is a phone now
把手机变成我的服务器
278 分 106 条评论 作者: seg6
作者为了省去 Hetzner VPS 费用,并获得比廉价云主机更适合远程浏览器 Surf 的性能,把闲置的 CMF Phone 1 改造成个人服务器。首次尝试刷 postmarketOS 因驱动缺失和软砖风险失败,转而保留 Android,让 Termux 负责控制面,配合 Tailscale、Termux:Boot、runit、Caddy 和 Ansible 实现可重启、可部署、可健康检查的服务体系。应用最初通过 PRoot 跑 Debian 文件系统,后因 Chrome 性能瓶颈改为 root 后 chroot,部署由工作站解析 OCI 镜像并固定 digest。争议集中在电池长期供电安全、手机闪存寿命、Android 封闭性,以及是否不如二手迷你 PC 划算。

评论精华

  • 许多人认为二手 Optiplex、NUC 或旧台式机更便宜稳妥。
  • 长期插电的电池安全和寿命是最大争议,作者称限制充电到 80%。
  • 有评论指出锁定 bootloader 的手机难以复现完整方案。
  • 部分读者担心手机闪存跑数据库,但也有人认为备份比介质更关键。
  • 社区赞赏 Ansible 与 digest 固定部署,让项目不像玩具服务器。
No.03 Os8088: A powerful Mac-like OS for the IBM XT, 286, 386
os8088:面向 IBM XT/286/386 的类 Mac 图形操作系统
147 分 69 条评论 作者: jggonz
os8088 是一个为 IBM PC/XT 级 8086/8088 机器重建的类早期 Macintosh 图形操作系统:从软盘启动,无 DOS 底层,以实模式汇编实现窗口、菜单、图标、Dock、可加载程序和 18.2Hz 抢占式多任务,可在 256K 内存、CGA/Hercules/VGA 上运行,并已在真机验证。文章强调它像是 1980 年代 PC 图形桌面的另一条历史分支,呼应 GEM 被苹果诉讼后删减的往事。争议焦点在于项目几乎由 Claude 辅助生成,社区同时赞叹其展示了 AI 编程潜力,也质疑「手写汇编」等表述和网站文案的真实性。

评论精华

  • 许多人认为这是 Claude 编程能力的强力展示,而非单纯怀旧玩具。
  • 作者承认项目是「hand-prompted」,并称正在更新页面让 AI 参与更明确。
  • 社区讨论了无内存保护下抢占式多任务的脆弱性和教育价值。
  • 有人补充 Visi On、GEM、GeoWorks 等历史先例,质疑「本可如此」叙事。
  • 不少人想在真机或 Pocket 8086 上尝试,并关注未来网络和硬盘支持。
No.04 Melatonin impairs morning cognition in healthy young adults (2023)
褪黑素可能损害健康年轻人的晨间认知
94 分 47 条评论 作者: bohaska
这篇 2023 年睡眠研究摘要称,健康年轻成年人服用外源性褪黑素后,虽然可能睡得不错,但次日早晨认知表现会下降;研究结论暗示,对本来没有睡眠障碍的人,负面晨间效应可能超过助眠收益。评论区主要质疑摘要信息不足:未清楚说明剂量、剂型、服用时间及是否区分 2mg 与 5mg;不少人指出市售剂量常远高于生理所需,100–300 微克可能更合理。也有人认为比较对象不应是「完美自然睡眠」,而应是失眠者在「少睡」与「服药后略昏沉」之间的取舍。

评论精华

  • 许多人认为剂量是关键,常见 3–5mg 可能过高。
  • 失眠者强调现实权衡:昏沉可能仍好过睡不着。
  • 评论质疑摘要缺少剂量、剂型、时间等关键方法细节。
  • 多位用户分享低剂量或缓释褪黑素更少晨间脑雾。
  • 有人指出咖啡因习惯、夜猫子作息也会影响晨间测试。
No.05 The original URL for this prediction will no longer be available in 11 years (2011)
一场关于 URL 能否存活 11 年的长期赌局
115 分 38 条评论 作者: doubletwoyou
这篇 2011 年的 Long Bets 预测围绕「Cool URIs don't change」这一网页理想展开:Jeremy 认为网页链接腐烂是网络熵增,哪怕 11 年也足以让原始地址失效;Matt 则认为经过 20 年发展,稳定 URI、301 重定向和基础维护已足够让网站长期存活。赌约规定,到 2022 年 2 月 22 日,访问 http://www.longbets.org/601 或其 301 重定向后的页面,必须返回含指定文本的 HTML 文档。条件满足则 Matt 赢,否则 Jeremy 赢。争议焦点不只是 Long Bets 是否还在,更是 Web 持久性究竟依赖技术规范、维护意愿,还是域名和托管的长期付费能力。

评论精华

  • 不少人惊讶页面和 Disqus 评论都仍在线,评论存活甚至更稀奇。
  • 有人认为赌局近乎自我实现:金额足够大时,一方会主动维护 URL。
  • 社区普遍认同理想是稳定 URI,现实做法则是靠 301 重定向。
  • 有人指出最脆弱环节可能是 HTTP 本身,未来浏览器或安全策略会阻断。
  • 讨论延伸到长期托管困境:域名、主机、公司倒闭和人员变动都可能导致链接腐烂。
No.06 Improving Heuristics for A* Pathfinding
改进 A* 寻路启发式:用地标加速搜索
200 分 21 条评论 作者: bobbiechen
文章指出,优化 A* 不应只盯优先队列或地图表示,启发式函数本身也能显著影响性能。常见距离启发式不了解墙体,可能把搜索推向错误方向;理想的「完美启发式」虽可由目标到各点的真实距离得到,但对不同目标预计算成本过高。作者介绍「差分启发式」:预先选择若干地标并计算到地标的距离,利用三角不等式为任意起终点提供更紧的下界,再取多个地标估计值的最大值。地标位置需结合路径分布、地图是否动态、长路径优化价值等取舍;动态地图中边成本变化会影响最优性或加速效果。实现上无需改 A*,只需替换启发式函数。

评论精华

  • 多人称赞 Red Blob Games 的可视化讲解一贯顶级,尤其适合理解寻路。
  • 有评论提到 NBA*、Jump Point Search 等相关寻路优化方向。
  • 读者关注地标选择的理论边界,以及如何覆盖更多起终点组合。
  • 动态地图如 Dwarf Fortress 会不断改变可通行路径,需后台更新地标数据。
  • 有人指出文中示例数字和术语动机可更清楚,作者回应会修正。
No.07 Shopify replaced Redis with MySQL for inventory reservations–and it scaled
Shopify 用 MySQL 取代 Redis 做库存预留并扛住高峰
172 分 98 条评论 作者: adletbalzhanov
Shopify 介绍将结账时的库存预留从 Redis 迁回 MySQL 的实践:原 Redis 方案虽并发好,但预留与库存账本分属两套系统,无法用单个 ACID 事务覆盖支付成功后的扣减与清理,带来超卖或少卖风险。新方案用 MySQL 8 的「SKIP LOCKED」和「一件库存一行」模型,并把每个商品地点的可预留行池限制在 1000 行,由补货流程维持容量。工程关键包括复合主键减少锁、改用「READ COMMITTED」避免间隙锁、统一锁顺序防死锁、批处理降低开销。评论争议集中在复杂度是否只是从 Redis 转移到 MySQL、1000 行池是否合理,以及现实方案与系统设计面试标准的落差。

评论精华

  • 不少人认同库存账本在 MySQL,预留也放 MySQL 可减少跨系统一致性风险。
  • 有人质疑一商品地点 1000 行和后台补货会引入新复杂度与失败模式。
  • 部分评论提出购物车级预留或直接扣减库存等更简单替代方案。
  • 社区讨论了 InnoDB 锁、隔离级别、SKIP LOCKED 成本和死锁规避细节。
  • 也有人认为真实生产方案常不符合面试模板,但规模约束会改变最优设计。
No.08 Fastmail offers EU data region
Fastmail 提供欧盟数据区域选项
394 分 197 条评论 作者: groomlake
Fastmail 宣布用户可选择将账户主要数据存放在欧盟,其自建服务器位于阿姆斯特丹,硬件和软件由内部团队管理,不依赖大型云服务商。欧盟区域会让邮件与文件的主副本在欧洲,应用优先连接欧洲服务器;但为可用性和灾备,副本、紧急备份、日志、部分元数据及第三方服务数据仍会流向或保存在美国。公司强调这不是「仅限欧盟存储」保证,也不会改变其作为澳大利亚公司受澳洲法律及国际协作请求约束的事实。用户可在设置中切换区域,迁移期间账户继续可用。争议焦点在于数据主权、CLOUD Act、五眼联盟和端到端加密缺失,使部分评论者认为此举更多是象征性或合规姿态,而非真正隔离司法风险。

评论精华

  • 欧洲用户欢迎多一个数据驻留选择。
  • 多数人指出这不等于数据只留在欧盟。
  • CLOUD Act、澳洲法律和五眼联盟是主要担忧。
  • 有人认为司法管辖权比服务器物理位置更重要。
  • 评论推荐 Tuta、Proton、mailbox.org 等欧洲替代品。
No.09 Dithered QR Codes
抖动图像风格的二维码
154 分 15 条评论 作者: jmusall
文章解释如何把二维码的数据模块嵌入一张低分辨率黑白图像中。普通做法是把每个模块缩小到 3×3 网格中央,其余像素显示图片,但数据位会形成随机盐胡椒噪声。作者用 Floyd-Steinberg「误差扩散」改进:先把必须固定的二维码数据像素强制设为目标颜色,再把由此产生的亮度误差扩散到周围像素,随后正常抖动整张图,从而显著隐藏数据噪声。生成器还支持旋转、调整编码参数和少量牺牲纠错像素,但作者强调美观与可扫描性存在权衡,屏幕上能扫不代表印刷、弱光或差手机也可靠,且边距、背景色和浏览器缩放模糊都会影响识别。

评论精华

  • 有人指出类似方法也可用彩色图像生成二维码。
  • 评论分享了另一款彩色二维码实验工具。
  • 有人联想到二维码动画,玩笑称或许能在二维码里运行 Doom。
  • 读者称赞文章开头对二维码原理的解释清晰简洁。
  • 评论提到作者还制作过 Ronin、Cell Tower 等每日谜题。
No.10 Unexpected events and prosocial behavior: the Batman effect (2025)
蝙蝠侠现身地铁会让人更愿意让座
55 分 14 条评论 作者: davidbarker
这项准实验在米兰地铁观察 138 次乘车场景:一名假扮孕妇的女性上车,实验组另有一名穿蝙蝠侠服装者从另一门进入。结果显示,有蝙蝠侠时乘客让座率从 37.66% 升至 67.21%,逻辑回归显著,优势比约 3.39。作者认为,意外事件可能打断通勤中的自动驾驶状态,提升对当下和他人需求的注意,从而促进亲社会行为。争议在于实验只测试了蝙蝠侠,难以区分是新奇刺激、超级英雄道德联想,还是他人更显眼带来的社交压力减轻。

评论精华

  • 不少人认可作者没有硬套潜意识英雄效应,而是强调异常事件提升注意力。
  • 有人认为通勤者常处于自动驾驶状态,类似下雪等罕见事件也会让人更友善。
  • 多位评论者指出应改用小丑等角色复现实验,以区分新奇性和道德联想。
  • 有人怀疑让座增加可能来自蝙蝠侠分散了尴尬感,降低主动让座的社交焦虑。
  • 也有评论调侃孕妇出行可带蝙蝠侠朋友,并称论文摘要异常清晰易懂。
No.11 Stylized GGX Shading
风格化 GGX 着色:卡通高光的 PBR 做法
9 分 0 条评论 作者: ibobev
文章介绍一种介于传统卡通渲染与物理渲染之间的「Stylized GGX Shading」。传统 toon shading 常通过阈值化光照制造平涂效果,但作者希望在低粗糙度下得到更大、更锐利的高光,同时在高粗糙度下保留柔和的 PBR 渐变。核心做法是在 GGX Cook-Torrance 微表面模型的 Trowbridge-Reitz NDF 中加入「Specular Size」参数,扩展高光范围;改进版再用「GGXMatching」随粗糙度调节,使粗糙材质不至于过亮。作者还提到在游戏项目中可结合简化 GI 探针、Kuwahara 滤镜、雾、边缘光和描边等手段强化 2D 感。
No.12 _for-sale DNS records
用 DNS 记录标记域名可出售
386 分 142 条评论 作者: shaunpud
文章介绍 RFC 10023 定义的「_for-sale」DNS 叶节点:域名持有人可在「_for-sale.example.com」发布 TXT 记录,表明域名仍正常使用但可洽购。它不是停放页,也不同于 WHOIS/RDAP,而是给经纪人和自动化查询服务的机器可读信号。格式要求以「v=FORSALE1;」开头,每条记录最多一个键值对,可提供联系 URI、自由文本或参考价格,TTL 建议不超过 3600 秒,售出或撤销意向后应删除。文章强调 DNSSEC、输入消毒和不要把报价视为承诺。争议焦点在于它可能便利域名投机,但也解决了隐私化 WHOIS 后买卖双方难以接触的问题。

评论精华

  • 多人担心公开出售标记会在商标仲裁中被视为恶意抢注证据。
  • 不少评论批评该标准会让域名囤积和投机更容易、更赚钱。
  • 有人提出类乔治主义税制:自报域名价格并按比例缴年费。
  • 实际用户认为它能帮助找到仍在使用或停放但无联系渠道的域名。
  • 安全方面担心 furi 链接会被滥用为恶意软件或钓鱼入口。
No.13 Incentives are for losers
别把激励当成人生目的
90 分 54 条评论 作者: bkudria
作者批评把一切问题归因于「激励坏了」的思维:它暗示人应当服从外部奖励,甚至无法选择做正确的事。文章用棒球头盔比喻说明,人若不自带价值体系,就只能使用社会提供的劣质激励。作者认为成熟的一部分是形成目的感和道德判断,否则空洞会被金钱、权力、名望填满,成为只会「响应激励」的人。文中还借宗教社会学和「解释深度错觉」指出,很多人以为自己有信念,其实价值系统很浅。争议在于:这种主张强调个人责任与勇气,但可能低估了无视激励的现实成本,以及制度设计在公共政策中的必要性。

评论精华

  • 有人赞同激励不是唯一动力,个人仍可基于原则行动。
  • 多名评论者认为作者低估了不服从激励的成本,原则常是有资源者的特权。
  • 反对者指出激励定义过窄,道德、惩罚、社会评价也可视为激励。
  • 不少人强调公共政策仍需要激励与机制设计,不能依赖人人高尚。
  • 也有人联想到教育和管理中过度奖励会削弱内在动机。
No.14 Open-source interactive map for the Aug 12 total solar eclipse
8 月 12 日日全食开源交互地图
137 分 30 条评论 作者: MarcoDewey
这篇展示的是一个面向 8 月 12 日日全食的开源交互式地图网站,提供全食带、月影路径、贝塞尔元素、实时本影、3D 阴影、云层投影、地形与太阳路径等图层,帮助观测者选择地点和时间。评论普遍称赞其细节丰富,尤其能显示低太阳高度下山脉阴影、地形遮挡等信息;也有人询问源码位置。讨论焦点集中在观测体验:多位用户强调日偏食与日全食差别巨大,真正值得长途奔赴的是「全食带」内的数分钟;2026 至 2028 年西班牙连续三次日食、冰岛和马略卡等地也成为热门观测目的地。

评论精华

  • 网站细节获赞,能结合地形、太阳路径和山影显示观测条件。
  • 多名用户强调「全食」与偏食体验差距极大,建议进入全食带。
  • 有人询问既然标称开源,源码仓库在哪里。
  • 西班牙 2026 至 2028 年连续日食,引发当地观测计划讨论。
  • 过往观测者提到气温骤降、动物异常和返程堵车等真实体验。
No.15 Making difficulty curves in games
游戏难度曲线的设计方法
104 分 40 条评论 作者: hakkikonu
文章讨论游戏关卡和谜题如何安排「难度曲线」:目标不是让游戏一路变难,而是让玩家持续获得变强的感觉。作者建议把难度拆成围绕各个新机制的小曲线,通过安全教学、可控风险、组合旧机制、压力测试和最终展示来引导学习;同时用可选收集品、支线、动态辅助、多路径、视觉提示等照顾不同水平玩家。文章也强调不能面向所有人设计,应明确目标受众,并用死亡位置、完成率、测试录像和问卷等数据校准曲线。争议点主要在动态难度调整:有人认为它是魔法般有效的工具,也有人觉得会破坏公平感和成就感。

评论精华

  • 不少人认为「普通难度」高度主观,难度设置应更细分。
  • 动态难度引发强烈争议:隐藏得好可提升体验,明显则显得廉价。
  • 评论提到可分别调整机制难度,如城市建造和 Ghost Recon 的多项开关。
  • 一些玩家更喜欢无难度选项但工具丰富的设计,例如魂类游戏。
  • 有人补充节奏和经验曲线同样关键,尤其是 JRPG 和增量游戏。
No.16 TheoremDB – A public workspace for machine mathematics
TheoremDB:面向机器数学的公共协作空间
31 分 0 条评论 作者: frozenseven
TheoremDB 是一个处于 alpha 阶段的机器数学公共工作区,目标是让研究代理和人类研究者共享可搜索的数学问题记录,避免重复尝试。每张问题卡包含明确目标、已证明内容、失败路线、计算代码和证据等级,Lean 形式化证明为最高等级。网站目前开放公开写入,并列出多类开放问题,涵盖离散数学、自动机、复杂性理论、数论、几何、动力系统等。其愿景类似数学研究中的「OEIS」:长期积累问题、方法、证据和结果索引。
No.17 Retraction: The App Store Rejection of the Week That Was a Correct Rejection
Daring Fireball 撤回对 App Store 审核的错误批评
159 分 14 条评论 作者: minimaxir
John Gruber 撤回了前一天批评 Apple 错拒「Dark Hours」的文章,承认核心前提错误:开发者 Terry Godier 最初提交的应用名为「Asterly」,实为占星应用,包含每日塔罗等内容,App Store 以相关指南拒绝并非荒谬。Gruber称自己过度信任了 Godier 的公开说法和私信,误把问题描述成纯天文学应用被当作占星拒绝。文章还指出,所谓「Dark Hours」网页版与已有开源项目 DarkHours 名称相近且存在相同 bug,随后 Godier 将域名重定向到原项目。Gruber向读者和 App Store 审核人员道歉,并补充说明 Apple 对占卜类应用的限制依据。

评论精华

  • 多数评论赞赏 Gruber 公开撤回并完整交代背景。
  • 有人认为开发者措辞像文字游戏,回避了应用曾是占星产品。
  • 多条评论关注疑似抄袭开源 DarkHours 项目及相同 bug。
  • 也有人提醒可能仍是沟通误会,不应过早断定撒谎。
  • 社区把此事视为验证信源和纠错透明度的案例。
No.18 Illinois just told every operating system to start reporting your kid's age
伊利诺伊要求操作系统上报儿童年龄段
77 分 43 条评论 作者: WaitWaitWha
伊利诺伊州州长签署 HB5511,将设备制造商、操作系统提供商和应用商店纳入儿童社交媒体安全框架。到 2028 年,设备在账号设置时需收集儿童生日并转换为四档年龄段,应用可通过 API 获取信号;一旦识别为未成年人,必须默认限制推荐流、陌生成人可见性、私信、精确位置和夜间通知,违规最高罚款 5 万美元。文章重点批评该法定义过宽,未像科罗拉多和加州后续修订那样豁免开源操作系统,可能把 Linux 等开源项目卷入合规压力,并以保护儿童之名削弱用户对计算设备的控制。

评论精华

  • 有人认为 Meta、Google、Apple 支持年龄验证,是为广告数据和责任豁免铺路。
  • 多名评论者质疑州法能否要求操作系统和开发者写代码,预期会有诉讼。
  • 有人指出加密条款只针对年龄段信号,不是要求所有网络协议都加密。
  • 支持者认为 OS 级年龄信号优于第三方验证,可减少向随机公司提交个人信息。
  • 反对者担心年龄信号会暴露儿童身份,被恶意网站或捕食者利用。
No.19 Fixing my tooltip accessibility mistake
修正我在工具提示可访问性上的错误
29 分 1 条评论 作者: robin_reala
作者复盘自己在演示「popover=hint」工具提示时犯下的可访问性错误:他最初用「aria-describedby」把图标按钮关联到 tooltip,又因 VoiceOver 重复朗读「Bold」而移除了按钮的「aria-label」。这样虽然在 VoiceOver 中看似可用,却让按钮失去真正的可访问名称,JAWS 还会从邻近 DOM 元素误取文本,导致读出错误内容。TetraLogical 的 Léonie Watson 和 Gez Lemon 指出,应改用「aria-labelledby」让 tooltip 提供按钮名称;若快捷键或长说明需要分离,则可再配合「aria-describedby」。核心教训是:交互元素必须有可访问名称,并应尽量用多种屏幕阅读器测试。

评论精华

  • 读者称赞文章用逐步 diff 展示代码变化,便于跟随理解。
No.20 Triton: DirectX 11 Driver for QEMU
Triton:面向 QEMU 的 DirectX 11 驱动
173 分 32 条评论 作者: electricant
UTM 团队发布 Triton,一个新的 Windows 图形驱动,结合此前的 Neptune 协议转发层,为 QEMU 虚拟机提供完整 DirectX 11 支持。文章解释了为何简单替换应用目录中的 d3d11.dll、dxgi.dll 不足以带来流畅桌面体验:DWM 会把画面当作普通图像处理,性能差且兼容性、反作弊问题多。Triton 选择实现 Windows 图形驱动的 UMD/KMD 与 DirectX DDI,把 DDI 调用重新映射为 DirectX 11 API,再走 Neptune 传输,避免 VirtualBox 那种中间字节码解释层带来的延迟、维护和许可问题。难点在于开源 DDI 资料稀缺,团队参考了 Mesa DX10 UMD、VirtualBox DX11 UMD 和 Venus KMD 工作。

评论精华

  • 用户期待多年,认为这能让 Windows 虚拟机游戏体验大幅改善
  • 多人追问是否支持 DX1 到 DX10,尤其是老游戏兼容性
  • DX12 被认为复杂得多,更接近 Vulkan,短期实现难度高
  • 有人提到 VirtualBox、VMware、Parallels 也主要停留在 DX11
  • 评论调侃 Triton 命名撞车,已有多个 GPU 相关项目使用该名
No.21 Should you stop cracking your knuckles?
掰手指关节会伤身体吗?
45 分 46 条评论 作者: tchalla
文章解释了掰手指关节发出声响的机制:关节腔被拉伸后滑液压力下降,溶解气体形成并塌陷,声音可高达 83 分贝。现有研究总体认为,适度掰指关节不会增加骨关节炎风险,也没有可靠证据表明会让指节变大、肌腱松弛或握力下降;个别扭伤多与用力过猛有关。相比之下,颈部和背部的强力扳动风险更高,可能影响神经和通向大脑的动脉,文章建议不要自行掰颈。若有关节疼痛、肿胀、麻木或头晕,应就医而非继续操作。想戒掉习惯可记录触发情境,用压力球等替代。

评论精华

  • 多人总结为:掰手指通常没事,但别用力过猛,更别掰脖子。
  • 评论区大量转向质疑整脊疗法,认为其科学基础薄弱且常被包装成医学。
  • 有人建议肌肉和关节痛先从轻度力量训练、减重、运动和工学调整入手。
  • 程序员分享腕痛经验:攀岩、键盘高度、腕托等可能比掰关节更影响手腕。
  • 有人好奇掰手指是否像打哈欠一样具有传染性,会让旁人也跟着掰。
No.22 Building a local positioning system to track runners using Ultra-Wideband
用超宽带为接力跑比赛搭建本地定位系统
73 分 5 条评论 作者: robinpdev
文章介绍比利时根特学生社团 Zeus WPI 为 12 小时接力跑探索自建「超宽带」本地定位系统。现有蓝牙接力棒方案只能估算赛道进度,UWB 可通过多锚点测距获得厘米级位置,从而在各队独立起跑线精确计圈,并生成速度、弯道表现等统计。团队选择低价 DWM3000 模块和 ESP32,自行补齐多标签、多锚点同步与时隙调度,调参后实现约 50 米测距,近距离误差约 2 厘米,远距离经校准可到 10 厘米级。文章价值在于展示低成本替代商用 RTLS 的可行性,也指出开源生态薄弱、多设备同步、遮挡和金属反射仍是难点。

评论精华

  • 有人认为每个模块 10 美元以上无法和一次性 RFID 竞争,但适合接力赛。
  • 评论提到鲁汶大学 24 小时跑曾开源过计圈系统,可供参考。
  • 有人联想到赛车应用,认为实时遥测和直播追踪潜力很大。
  • 一条评论把本文 UWB 误解为蜂窝网络高速下行,随后被指出两者完全不同。
No.23 Assert(): A Modern How To
现代 assert 使用指南
8 分 4 条评论 作者: nyc_pizzadev
作者认为「assert」不应只是可关闭的轻量调试语句,而应成为保障软件正确性、安全性和可维护性的基础工具。文章主张在四类场景中使用断言:覆盖参数与返回值的意外取值,确保值空间完整;对内存边界、整数溢出等操作安全做即时检查;在开发期捕捉索引、状态和逻辑错误;并辅助文档化不变量。作者强调断言开销通常极低,生产环境也常有价值,尤其能在环境差异、罕见资源失败或隐性假设被打破时立即暴露问题。争议点在于哪些断言可进生产、哪些应由错误处理、类型系统、单元测试或契约式设计承担。

评论精华

  • 有人赞成把断言与可重启架构结合,失败后回到已知安全状态。
  • 有评论认为断言本质只是状态空间谓词,其他用法都是推论。
  • 有人提出「解析而非验证」可把已检查事实编码进类型,减少运行时断言。
  • 有评论认可主题价值,但希望讨论契约式设计、前置条件和不变量。
No.24 Real-time MCP interceptor that blocks .env reads and dangerous commands agents
实时 MCP 拦截器与 MCP 市场目录
10 分 2 条评论 作者: eddyflores
文章介绍 MarketNow,一个面向 Claude Desktop、Cursor、Cline、Continue、Aider 等 MCP 兼容代理的服务器与技能目录,声称收录 9248 个 MCP server,可按类别、标签、价格、安全评分和语言筛选,并通过 npm 命令一键安装。平台强调机器可读 JSON API、Stripe 或 Base USDC 支付,以及 Sentinel 安全扫描;但同时披露大多数条目只是自动扫描,人工审核和维护者验证数量很少。HN 评论指出其公开 GitHub 链接 404,且若要实现真正安全,应采用默认拒绝而非默认允许策略。

评论精华

  • 有评论指出官网声称公开的 GitHub 仓库返回 404,可信度存疑。
  • 评论认为这更像一个 Show HN 项目,但定位和说明有些混乱。
  • 安全观点认为真正防护应采用默认拒绝策略,而不是默认允许。
No.25 Finding zombies in our systems: A real-world story of CPU bottlenecks
在系统中寻找僵尸:一次真实的 CPU 瓶颈排查
44 分 9 条评论 作者: fagnerbrack
文章讲述 Pinterest 工程团队排查生产系统 CPU 瓶颈的案例:某些类似「僵尸」的残留资源或分配状态让系统在后台持续消耗 CPU,最终牵连网络线程或内核调度路径。评论推测问题可能与 Linux 中断下半部、CPU 亲和性、memcg 遍历和自旋锁有关,也有人质疑为什么 96 核机器上单核忙碌会影响其他线程。读者普遍认为这是少见而有价值的底层性能侦探故事,可作为真实系统调优和 AI 工具基准案例。

评论精华

  • 有人称赞这是久违的真实系统性能排查案例。
  • 评论联想到 Windows 上 63 核被七条指令阻塞的故事。
  • 有人疑惑单核繁忙为何会拖累 96 核机器上的网络线程。
  • 技术评论推测问题来自中断下半部、memcg 遍历和自旋锁。
  • 部分讨论转向 Pinterest 的 AI、推荐和站点质量变化。
No.26 The Sound and Music of 'Hyper Light Drifter' [video]
《Hyper Light Drifter》的声音与音乐设计
44 分 10 条评论 作者: hyperific
这段 GDC 视频回顾《Hyper Light Drifter》独特音景的形成过程。游戏以霓虹、梦魇般的声音语言著称,其音乐与音效由作曲家 Rich Vreeland(Disasterpeace)和声音设计师 Akash Thakkar 在三年中反复修改、重做与试验才逐渐定型。分享重点不只是配乐本身,也包括声音如何与像素美术、场景转换和情绪节奏结合,制造强烈的沉浸感与情感冲击。正文基本是演讲介绍,没有明显争议;社区讨论则更多延伸到 Disasterpeace 的其他作品、独立游戏美学和观看渠道。

评论精华

  • 多位评论者称赞 Disasterpeace 在《Fez》和本作中的作曲能力。
  • 玩家认为《Hyper Light Drifter》的像素美术、音效和配乐共同塑造了强烈氛围。
  • 有人推荐 Heart Machine 的后续作品,如《Solar Ash》等。
  • 评论提到本作承接并提升了 16-bit 复兴独立游戏的艺术风格。
  • 有用户补充了 YouTube 观看链接和相关视频推荐。
No.27 Lake Mead hits historic low water level as Colorado River struggles
米德湖水位跌至历史新低,科罗拉多河危机加深
5 分 0 条评论 作者: geox
美国最大水库米德湖水位降至海拔1040.4英尺,创其约90年前蓄水以来最低纪录,凸显科罗拉多河系统持续承压。该流域供水关系到美国七州、部落、墨西哥及约4000万人,干旱、升温、长期超采和创纪录低雪包共同加剧短缺。联邦政府近期提出短期方案,要求亚利桑那、加州、内华达等下游州减少取水,但长期分水协议仍未达成。水位下降也威胁胡佛坝、格伦峡谷坝等水电和生态管理,部分鱼类保护放水被迫让位于维持发电能力。模型预计米德湖年内还将继续下探。
No.28 Datalog Disassembly
用 Datalog 进行反汇编
36 分 6 条评论 作者: aboardRat4
Ddisasm 是 GrammaTech 开源的反汇编与二进制重写工具,项目核心亮点是用 Datalog/Soufflé 表达控制流、数据引用、重定位等分析规则,从 ELF、PE 等可执行文件中恢复可重组的汇编表示。评论者对其实际可用性感到惊讶,认为它在真实二进制上并非概念玩具。讨论焦点集中在二进制重写的可靠性:改变指令长度或数量是否会破坏相对、绝对引用,以及异常信息、重定位等元数据如何更新。回应指出常见做法是新增 section 放置重写代码,并利用 ELF/PE 的重定位信息修补引用;但裸二进制 blob 仍可能困难。另有评论关注 Soufflé 规则系统如何避免关系饱和爆炸,猜测可能通过按基本块等方式分区。

评论精华

  • 有人称 ddisasm 实际能用,令人惊讶,HN 讨论不足。
  • 读者关心改写指令数量或大小后,引用是否会失效。
  • 二进制重写通常新增 section 放重写代码和再生元数据。
  • ELF/PE 有重定位信息可辅助修补,裸 blob 更棘手。
  • 有人关注 Soufflé 如何避免 Datalog 饱和爆炸。
No.29 Message your other Claude Code sessions
Claude Code 支持跨会话消息传递
114 分 46 条评论 作者: mfiguiere
Claude Code 新增跨会话消息功能,让一个独立会话可通过「ListAgents」发现可达代理,并用「SendMessage」把发现、决策、状态或交接信息发送给另一会话,适合并行 worktree 协作、长任务汇报、跨机器回复等场景。系统会按接收端权限策略将消息判定为送达、暂存或拒收;远程机器会话通常只能回复不能主动发起。文章强调安全边界:会话消息不能代替用户批准、不能改配置,命令文本不会被执行,必要权限仍会弹窗。争议焦点在于它提升多代理协作效率的同时,也引入新的攻击面和权限治理复杂度。

评论精华

  • 许多人表示早已用 tmux、IRC、Telegram、Tailscale 或文件协议自建类似系统。
  • 安全担忧突出:跨会话消息可能成为新的提示注入和代理间攻击面。
  • 不少评论认为核心需求是会话压缩后仍能搜索完整历史,而不只是转发消息。
  • 有人询问与 CMUX、Orca、Codex、Antigravity 等多代理工具或 harness 的差异。
  • 实用派建议用 markdown 交接文件、hooks、通知铃声等简单机制协调代理状态。
No.30 “Code was never the hard part” is an insult to all programmers
说「代码从来不是难点」是在贬低程序员
718 分 426 条评论 作者: senko
作者反驳流行说法「代码从来不是难点」,认为这既低估了编程作为手艺所需的技能、经验、耐心与判断,也掩盖了软件长期高薪、高门槛、易出错和维护困难的现实。他同样批评另一端把代码神圣化、拒绝自动化的姿态,主张软件成功需要同时理解系统本身和为什么要构建它。面对 AI 带来的行业级变化,程序员应承认变化、辨别炒作与有效工具,并扩展到用户体验、业务、需求等相邻领域;资深者不能只加深技术,初学者也不能放弃底层知识。争议焦点在于「编码」「编程」「软件工程」是否被混为一谈。

评论精华

  • 许多评论认为作者把「写语法」和「编程」混淆了。
  • 不少人主张更准确说法是代码不是唯一或最大瓶颈。
  • 有人赞同代码很难,尤其是高质量、可维护工程代码。
  • 多位开发者称真正让人 burnout 的是需求混乱和组织问题。
  • 也有人认为 AI 让代码工业化,但技术判断仍更重要。