1. 德州女子因发帖质疑自来水被捕 (Texas woman arrested for Facebook post about town water quality)
Reclaim The Net 报道，德州 Trinidad 居民 Jennifer Combs 因在 Facebook 社区页面发布关于当地水质的帖子，被警方以州监狱重罪“虚假警报或报告”逮捕。她的帖子称收到居民报告，有人因水中细菌住院，并呼吁水色异常、有沉淀或异味、出现健康问题的居民提供信息，供她汇总后上报州机构。市政府称“有人住院”这一说法不实，警方则适用原本用于惩罚假炸弹威胁、虚构紧急事件的 Texas Penal Code §42.06。吊诡的是，Trinidad 本身确有水质问题，市长承认管道老旧，市政府也在 4 月 21 日发布过煮沸用水通知。Combs 已提起联邦诉讼，称逮捕是有意政治报复。
原文链接：https://reclaimthenet.org/texas-woman-arrested-for-facebook-post-about-town-water-quality
论坛讨论链接：https://news.ycombinator.com/item?id=48249747
HN 讨论认为，要求普通居民先向医院核实住院情况本身就不现实，医疗机构也不可能随便向私人披露病患信息。许多评论者关注的不是她每个细节是否准确，而是地方警察为何要动用刑事拘押来处理公共卫生传言。有人指出，如果政府真正关心社区知情权，完全可以请新闻机构或州级卫生机构调查，而不是逮捕发帖人。评论普遍认为这会造成寒蝉效应：居民看到别人因水质问题发声被捕，就会更不敢公开讨论基础设施失败。
2. Prusa 指控 BambuStudio 长期违反 AGPL (BambuStudio has been violating PrusaSlicer AGPL license since their fork)
Josef Prusa 在 X 上指控 BambuStudio 自 fork PrusaSlicer 以来一直违反 AGPL 许可证，尤其围绕一个网络相关二进制黑盒持续存在争议。他进一步把问题放到中国法律和 3D 打印产业战略背景下，列举《国家情报法》《密码法》《数据安全法》《反间谍法》修订以及网络产品安全漏洞报告规则，认为中国公司在数据、漏洞、加密和情报协作方面没有真正“中立出口”。在他的论述中，Bambu 这样具有全球用户和设备网络的中国公司，不只是开源合规问题，也涉及用户模型、打印任务、网络组件和潜在工业数据流向。帖子把 3D 打印从消费者设备争议提升到供应链、知识产权和国家产业政策层面。
原文链接：https://twitter.com/josefprusa/status/2054602354851254330
论坛讨论链接：https://news.ycombinator.com/item?id=48245862
HN 评论对 Prusa 的担忧并非全盘接受。有人指出，Cloud Act 也让美国政府可以向大型云平台索取数据，而欧洲企业大量依赖 AWS、Google、Microsoft，不能只把中国公司视为唯一风险。也有人批评 Prusa 自己的云服务 PrusaConnect 尚未完全开源，许多高级功能也依赖把文件发到捷克服务器，因此与 Bambu 的实际操作并非完全不同。讨论核心是：AGPL 合规、云控制和国家司法辖区风险都是真的，但竞争对手提出这些问题时，商业动机也需要被纳入判断。
3. SpaceX 首飞 Starship V3，带故障完成关键测试 (SpaceX launches Starship v3 rocket)
SpaceX 从德州 Starbase 新建第二发射台发射了 Starship V3，这是第 12 次亚轨道测试飞行，也是 V3 版本首次飞行。火箭高 408 英尺，采用全面重新设计，目标是向实际运营任务过渡。发射中并非一切顺利：Super Heavy 一级 33 台 Raptor 中一台关机，随后 boostback 点火未按计划完成；Ship 39 上面级在上升阶段也损失一台发动机，但仍靠剩余五台进入预定可接受轨迹。飞行中成功部署 20 个模拟 Starlink 和 2 个带成像传感器的 Starlink 载荷，后者用于拍摄并检查 Starship 隔热瓦。由于发动机问题，原计划的太空中 Raptor 重新点火测试被取消，但 Ship 仍完成再入、机动和软着水测试。
论坛讨论链接：https://news.ycombinator.com/item?id=48242959
HN 的现场总结认为，这次飞行是“带着多个大改动至少没有倒退”。最大的失败是一级 boostback 未完成，其次是上面级发动机故障；但 Starship 在发动机失效下仍完成入空、载荷部署和再入，也算意外验证了容错能力。评论者特别提到再入等离子体直播画面已经从罕见奇观变成例行展示。多数人判断，下一飞想直接塔架回收或真正入轨可能会推迟，但工程进展仍明显。
4. 30 年睡眠研究催生新的睡眠呼吸暂停药物 (Sleep research led to a new sleep apnea drug)
多伦多大学介绍，Richard Horner 教授数十年关于睡眠和呼吸生理的研究，为一种新的阻塞性睡眠呼吸暂停口服药 AD109 奠定了基础。阻塞性睡眠呼吸暂停发生在睡眠中上气道肌肉反复塌陷，导致呼吸中断，长期会增加高血压、心脏病、代谢问题和认知损伤风险。Horner 团队发现两条关键通路：REM 睡眠时去甲肾上腺素下降会削弱舌肌“启动”信号，而毒蕈碱受体则会抑制舌头运动。AD109 正是组合两类药物，一类提高去甲肾上腺素，另一类阻断毒蕈碱受体。最近 III 期随机临床试验显示，服药者气道阻塞减少、氧气水平改善，每小时睡眠平均少约 4 次呼吸暂停或浅呼吸事件。
原文链接：https://temertymedicine.utoronto.ca/news/how-decades-sleep-research-led-new-sleep-apnea-drug
论坛讨论链接：https://news.ycombinator.com/item?id=48242278
评论区重点不是药物本身，而是睡眠呼吸暂停的低认知度。有人提醒，白天疲惫、醒来仍累、夜间频繁醒来、缺乏精力都可能是症状；未治疗者更容易抑郁、失业，并承受长期缺氧对大脑和心血管的影响。他还指出，家庭检测并不复杂，CPAP 对许多人非常有效，脑部灰质恢复可能需要约一年。评论也提到 GLP-1/减重药对由肥胖引起的睡眠呼吸暂停可能更强，但并非适用于所有病因。
5. 80386 微码被从芯片照片中反汇编出来 (80386 microcode disassembled)
Reenigne 介绍了一个硬件考古项目：团队从 Intel 80386 芯片的高分辨率 die photo 中提取并反汇编微码。相比 8086 的 10752 位微码，80386 微码 ROM 达到 94720 位，且缺少像 8086 专利那样的路线图。GloriousCow、Smartest Blob 等人通过图像处理、神经网络和人工校验，把微码阵列从照片转成二进制 blob，再逐步识别出 μ-op 的排列、字段、结束标记和入口点。结果显示，80386 有 215 个来自解码 ROM 的微码入口，所有指令都通过微码执行，不像 8086 和现代 CPU 那样有部分指令完全不走微码。作者还疑似发现一个 IO permission bitmap 边界检查缺陷，可能是隐藏 40 多年的硬件级安全 bug。
原文链接：https://www.reenigne.org/blog/80386-microcode-disassembled/
论坛讨论链接：https://news.ycombinator.com/item?id=48247004
HN 讨论主要惊叹于“如何从芯片照片恢复微码”。参与提取的 GloriousCow 解释，第一步是在微码阵列中标出每个 bit 的坐标，再根据晶体管是否存在判断 0/1；因为图像有灰尘和模糊，普通阈值工具效果不好，他们训练卷积神经网络分类 bit 区域，并把结果叠回原图人工检查数天。随后才进入更难的微码 word 排列和字段解释阶段。评论整体把这视为硬件逆向、图像识别和历史研究结合的漂亮工作。
6. sp.h 想给 C 一个现代、可移植的标准库 (sp.h: Fixing C by giving it a high quality, ultra portable standard library)
sp.h 是一个 15000 行、单头文件、C99 编写的标准库替代方案，目标是“修复 C”：不依赖 libc，除非平台强制要求；尽量直接面向系统调用；提供 allocator-first、无默认 heap、pointer+length 字符串、显式错误处理和无可变全局状态等设计。作者认为 libc 的 FILE*、null-terminated string 等接口已经不适合现代高性能和异步程序，很多复杂软件需要更接近 OS primitive 的抽象。sp.h 支持 Linux、Windows、macOS、WASM、浏览器、MSVC、MinGW、Cosmopolitan、TCC 等环境，核心平台相关代码约 40 个 syscall。它不是为了兼容 libc 接口，而是让新 C 程序可以用更明确、更安全、更可读的基础设施构建。
论坛讨论链接：https://news.ycombinator.com/item?id=48207043
HN 争论集中在“极致可移植”和“不关心 obscure 架构/OS”是否矛盾。有人指出，在 2026 年新写 C 的主要场景往往正是微控制器和奇怪平台，而不是 Windows/macOS/Linux 桌面程序；如果一个 C 库不关心这些目标，就很难自称极端可移植。作者回应说，支持怪平台不是哲学反对，而是时间优先级问题；库的结构已经把平台层压到几十个 syscall，如果有人愿意补端口，他愿意接受合理 patch。讨论体现了 C 社区对“现代 C”目标场景的分歧。
7. 同一个 LZ4 解压器在四种老 CPU 上怎么写？ (Comparing an LZ4 Decompressor on Four Legacy CPUs)
Bumbershoot Software 用 LZ4 解压器作为例子，比较 Z80、Intel 8080、8086 和 6502 四种老 CPU 上的实现差异。作者此前在 SNES 项目里为了节省卡带空间使用 LZ4，并发现一些约束和捷径适用于许多 8/16 位平台；后来又写过 6809、68000、Z80 等版本。这篇文章先回顾 LZ4 的基本结构：压缩流由 literal 字符串和 backreference 交替组成，每个 sequence 用一个字节同时记录 literal 长度和 backreference 长度，并用两字节 offset 指回已输出内容。作者利用 LZ4 最后一段只含 literal 的特性，用 offset 0 作为结束信号，从而省掉传统 frame 数据。后半部分则把 Z80 实现转写到 8080、8086 和 6502，展示寄存器模型、寻址方式和循环代价如何影响真实汇编代码。
原文链接：https://bumbershootsoft.wordpress.com/2026/05/09/comparing-an-lz4-decompressor-on-four-legacy-cpus/
论坛讨论链接：https://news.ycombinator.com/item?id=48206313
HN 评论不多但很对口。有人称这是很好的 8 位 CPU 实现对比，能看出 6502、Z80、8080、8086 不同设计如何影响实际代码。也有人指出 LZ 系算法过去常用于自解压可执行文件，因为它们结构简单、效率高、解压器可以很小，像 RLE 的自然扩展。还有评论抱怨 WordPress consent banner，并推荐 archive 链接。整体讨论偏复古计算爱好者，认可文章干燥但细节扎实。
8. Rubish：用纯 Ruby 写一个兼容 Bash 的 Unix Shell (Rubish: A Unix shell written in pure Ruby)
Rubish 是一个用纯 Ruby 写的 Unix shell，思路是把 shell 语法解析并编译成 Ruby 代码，再由 Ruby VM 执行。项目目标是完全 Bash 兼容，现有 Bash 脚本理论上无需修改即可运行，同时提供深度 Ruby 集成：可以用 {} 写 Ruby 条件、用 Ruby 方法调用风格执行命令、用点号链式组成 pipeline、用 .each/.map/.select 等迭代器逐行处理命令输出，也可以在 shell 中直接执行 Ruby 类、数组、正则和 lambda。Rubish 还支持 Ruby 风格函数定义、可编程 prompt、lazy_load 延迟初始化 rbenv/nvm/pyenv，以及禁用 Ruby 集成的 restricted mode。它既是 shell，也是 Ruby 交互环境和脚本语言的混合体。
原文链接：https://github.com/amatsuda/rubish
论坛讨论链接：https://news.ycombinator.com/item?id=48245262
评论者的反应是“惊叹但恐惧”：很多人长期想把 Ruby 和 Bash 融合成理想 shell，Rubish 比他们尝试过的方案走得更远，但最大问题仍是可用性和部署。bash 的持久优势是无处不在，远程环境、服务器和临时机器上未必能安装 Rubish，长期维护两个 shell 世界并不现实。也有人指出 fish、nushell、elvish 等替代 shell 已经证明 bash 不是不可挑战，只是兼容性、习惯和脚本生态让替换过程非常慢。
9. 重新认识 HTML 里的 description list (On The (2021))
Ben Myers 的旧文解释了 HTML <dl>、<dt>、<dd> 这组常被低估的元素。<dl> 表示 name-value groups，适合图书信息、住宿设施、费用明细、技术术语表等模式；<dt> 是 term，<dd> 是 detail，一个 term 可以有多个 detail，也可以用 <div> 包住一组 <dt>/<dd> 便于样式控制。文章强调，语义化标记的价值在于浏览器、屏幕阅读器和其他工具可以识别结构，而不是只看到一堆嵌套 div。对屏幕阅读器用户来说，description list 可以提供列表长度、当前位置、整体跳过等体验。作者也提醒 <dl> 支持并非所有组合都完美，但在许多 name-value UI 中比纯 div 更合适。
原文链接：https://benmyers.dev/blog/on-the-dl/
论坛讨论链接：https://news.ycombinator.com/item?id=48247325
HN 讨论补充了文章遗漏和 ARIA 细节。有人指出 <dl aria-label="..."> 并不严格正确，因为 <dl> 没有默认对应 role；若要命名，需要加合适的 role="list"，并进一步处理子项 role。另一个重要补充是 spec 允许连续多个 <dt>，不只是一个 term 对多个 detail，因此它们更准确地说是 name-value groups，而不总是 name-value pairs。评论也提醒，现实中浏览器和屏幕阅读器对 <dt>/<dd> 的 accessibility tree 支持不完全一致，若无障碍是最高优先级，最好保持简单结构。
10. 马蹄为什么被称为马的第二颗心？ (Blood Pumping Mechanism of the Hoof (2020))
这篇 2020 年文章介绍了马蹄的泵血机制。血液由心脏经动脉送到蹄部，但马的下肢和蹄内没有肌肉帮助静脉血回流，因此蹄本身需要承担类似泵的作用。蹄内侧软骨两侧和敏感结构中有发达的静脉丛；当马蹄承重时，plantar cushion、侧软骨和 coffin bone 会压迫这些静脉，把血液向腿部和心脏方向挤回去。腿部静脉的一向阀阻止血液倒流，静脉丛受压还会形成液压缓冲，帮助吸收冲击、保护 coffin bone。每次脚落地和抬起，静脉压缩与开放交替发生，血液借助体重、动脉脉冲和重力循环，因此马蹄常被称为“第二颗心”。
原文链接：https://horses.extension.org/blood-pumping-mechanism-of-the-hoof/
论坛讨论链接：https://news.ycombinator.com/item?id=48204985
评论区从马蹄泵血机制引申到生物体是否可能理解自身每个低层细节。有人感叹，马是极其复杂的生物机器，却并不知道自己如何运转；人类也只是通过科学一点点补全自身模型。评论者进一步想象一种能完美感知自身糖原储备、免疫反应、思维递归和全部生理状态的意识体，并怀疑这种自我建模复杂度是否会遭遇上限。后续回复则指出，思想的意义正是用低复杂度模型解释高复杂度系统，不必与被解释对象等量复杂。