Hacker News 每日播报

Hacker News 每日播报，为您带来本周科技与思想领域的精彩洞察。

Root for your friends

本周在 Hacker News 上，一篇题为《Root for Your Friends》的文章引发了广泛关注。作者 Joseph Thacker 探讨了一个看似简单但对个人职业、幸福感和人际关系有着深远影响的概念：真心为朋友的成功感到高兴，并拒绝嫉妒。

文章的核心观点是，生活中的许多“游戏”并非零和博弈，而是正和博弈——“水涨船高”，一个人的成功可以惠及他人。作者将这种积极支持朋友的人称为“Hypeman”（或“Hype Friend”），他们像啦啦队一样为你的胜利喝彩。文章提出了一个“Hypeman 飞轮”的概念：你支持朋友，帮助他们成长和获取信息；他们因此变得更成功、更了解情况，也更有可能反过来与你分享信息和机会，从而形成一个互助互利的良性循环。

文章强调，理想情况下，这个飞轮需要朋友之间的相互支持。如果朋友不回报，作者引用了 Alex Hormozi 的话，建议考虑改变朋友圈。但即使缺乏回报，作者也认为，不嫉妒、真心为朋友高兴本身就是一种更好的生活方式，能带来内心的平静。文章还列举了如何识别一个好的“Hypeman”朋友（例如，当面说真话，背后赞美你；在你成功时祝贺你；分享你的内容；介绍人脉；提供有意义的反馈；乐于合作等），以及如何成为一个好的“Hypeman”（快速赞美、策略性地诚实、拓展朋友的视野、积极宣传朋友的作品等）。

这篇文章引发了广泛讨论，人们分享了多样化的视角，尤其是在理想与现实的碰撞中。

理想与现实的碰撞

许多人对此深有共鸣，表示自己常常是那个积极支持他人的角色，却鲜少感受到同等的回报。这让他们感到有些失落，但也促使一些人反思，也许是因为自己不习惯分享成功，或者不信任他人会为自己高兴，从而没有给朋友机会成为自己的“Hypeman”。有人深入探讨了接受赞美为何令人感到压力，认为这可能源于被评价时的不适感，即使是积极的评价。

然而，对于文章中“水涨船高”和正和博弈的观点，也出现了不同的声音。一些人分享了痛苦的经历，他们曾真心支持的朋友却表现出嫉妒，甚至在背后诋毁或阻碍他们。有人提到朋友坦承享受看到他们失败，并引用了关于嫉妒、幸灾乐祸（Schadenfreude）和自我评价维持理论的研究，认为在亲近的朋友关系中，人们更容易产生竞争和负面情绪。这引发了关于人性的讨论，一些人认为嫉妒是普遍存在的，甚至有人悲观地表示“没有人希望你比他们做得更好”。

“朋友”的定义

这进一步引发了关于“朋友”定义的思考。一些人认为，文章描述的更像是“工作盟友”或“职业人脉”，而非传统意义上基于纯粹情感连接、不带功利目的的“朋友”。他们认为，真正的朋友是在你低谷时依然支持你的人，而文章中强调的互助互利、提升职业生涯的属性，让这种关系显得过于功利化。也有人指出，“朋友”的定义在不同文化中差异很大，并分享了在工作环境中，谦逊地支持同事、给予他人荣誉反而能赢得好感和支持的经验。

积极心态的重要性

尽管存在对现实中人际关系复杂性和负面情绪的清醒认识，许多人依然肯定了文章的核心价值。他们认为，无论朋友是否回报，选择积极、支持的心态，拒绝嫉妒，对自己的心理健康和幸福感至关重要。即使在充满竞争的环境中（如工作或军队），积极支持他人、建立良好关系也能带来意想不到的好处，例如提升团队士气、建立信任，甚至间接帮助自己的职业发展。

总的来说，这篇文章及其引发的讨论提供了一个关于支持朋友、拒绝嫉妒的理想化愿景与现实复杂性之间的精彩对话。它提醒我们积极心态的重要性，但也诚实地面对了人际关系中可能存在的竞争、嫉妒和不回报，促使读者思考如何在理想与现实之间找到平衡，以及如何识别和培养真正能相互支持的健康关系。

Why Algebraic Effects?

一篇题为《Why Algebraic Effects?》的文章，深入探讨了代数效应（Algebraic Effects）这一在 Koka、Effekt、Eff、Flix 等研究型语言以及 Ante 语言中日益受到关注的特性。作者认为，代数效应有望在未来的编程语言中大放异彩，但很多介绍只说了“是什么”，却没说清楚“为什么”要用它。这篇文章的目的正是解释代数效应的诸多用例和优势。

文章首先给出了一个理解代数效应的简单模型：可以把它想象成“可以恢复的异常”。你可以声明一个效应（effect），比如 effect SayMessage with say_message: Unit -> Unit。函数如果可能执行这个效应，需要在签名中声明 can SayMessage。调用效应函数（如 say_message()）就像“抛出”一个异常。而 handle 表达式则像 try/catch，可以捕获效应，并在处理后选择 resume() 继续原有的计算，或者不恢复，从而改变控制流。

接着，文章详细阐述了代数效应的几个核心优势：

核心优势

• 用户可定义的控制流： 代数效应是一个统一的语言特性，可以用库的形式实现多种控制流结构，如异常、生成器（generators）、协程（coroutines）、异步编程（async）等。它通过使函数对效应多态（polymorphic over effects），解决了“函数颜色问题”（例如，一个 map 函数可以处理任何带有效应 e 的函数 f: a -> b can e）。文章通过代码示例展示了如何用代数效应实现异常（不恢复）和生成器（yield 后恢复）。
• 作为抽象机制： 代数效应可以用于依赖注入（Dependency Injection）。通过将数据库访问、日志、随机数生成、内存分配等操作定义为效应，函数签名可以声明它需要哪些能力（效应），而具体的实现（handler）可以在调用栈的上层动态提供。这使得代码更容易测试（用 mock handler）和灵活配置，替代了显式的上下文传递或全局变量，从而实现更清晰的 API 设计。文章展示了如何用 Use a 效应实现状态传递，避免了显式传递上下文对象。
• 直观的直接风格编程： 使用代数效应可以写出更接近命令式、没有太多嵌套或链式调用的代码，尤其是在处理可能失败的操作时。与使用 Maybe 或 Result 类型并进行繁琐的 map/and_then 链式调用不同，效应允许你直接写“成功路径”的代码，而失败或特殊情况的处理则交给上层的 handler。不同的错误效应类型也能自然地组合。
• 保证纯度： 大多数支持代数效应的语言要求函数在签名中声明所有可能的副作用（如 can IO, can Print）。这使得函数签名成为一种能力列表，便于代码审计和理解。纯函数对于并发编程中的一些技术（如 STM）至关重要。此外，通过记录和回放效应，可以实现程序的重放性（Replayability），这对于确定性调试、网络同步等非常有用。这与基于能力的安全性（Capability-based Security）有相似之处，效应签名就像是函数需要的“能力许可”。

文章也提到了代数效应的一些潜在缺点，主要是传统的效率问题（尽管现代语言已有很多优化策略）以及一个效应被意外处理的问题：如果一个函数新增了一个效应，而调用它的函数恰好已经声明了可以处理该效应，那么这个新增的效应可能会被无意中捕获，而不是像显式错误类型那样导致编译错误。

这篇文章在社区中引发了热烈讨论，大家围绕代数效应的优缺点、与其他现有概念的比较以及实际应用中的挑战展开了深入探讨。

主要担忧：可读性与调试难度

代数效应引入的动态性引发了一些担忧。最突出的问题是：在调用一个函数（如 LibraryA.foo()）时，代码本身没有直观的迹象表明它可能抛出效应（如失败）。你需要查看函数签名或依赖 IDE 提示。更重要的是，当效应被抛出时，很难静态地（例如在 IDE 中通过“跳转到定义”）找到实际处理这个效应的 handler 代码。handler 可能在调用栈的任意上层，而且同一个函数可能在不同的调用点被不同的 handler 处理。这被比作 goto 但没有标签，或者导致类似于面向对象中“Yo-yo 问题”的调试困境。

支持者认为，这种动态性正是代数效应的强大之处，它实现了灵活的依赖注入、测试和沙箱化。他们认为，这类似于追踪 DI 容器中的服务实现或 Haskell 中的 Monad 栈，你需要接受这种抽象带来的间接性。好的 IDE 工具（如显示内联效应提示、按效应过滤调用者列表）对于缓解这些问题至关重要。

与其他概念的比较

• Monads： 与 Monads 的比较是讨论中最常见的议题。许多人认为代数效应提供的能力与 Haskell 中的 Monad（特别是 mtl 风格的 Monad Transformer Library 或 Free Monads）非常相似。大家讨论了它们之间的区别：代数效应通常提供更简洁的语法（直接风格），避免了 Monad Transformer 组合的复杂性，并且“代数”部分意味着效应之间有良好的组合规则。一些人认为 Monads 也能实现动态处理，只是更笨拙。
• 异常： 文章以异常作为引入，有人指出代数效应是异常的泛化，特别是支持“恢复”。这与 Common Lisp 的 Condition System 有相似之处，但代数效应通常基于多重续体（multi-shot continuations），比 Lisp 的单重续体更强大。
• 依赖注入 (DI)： 代数效应被普遍视为依赖注入（DI）的一种形式化和语言级支持。有人认为这只是把 DI 容器的功能内置到语言中，可能导致 DI 的“蔓延”问题，增加代码的间接性。另一些人则认为，代数效应提供了类型安全的 DI，比手动传递上下文或使用 DI 库更清晰。
• 生成器/协程： 文章指出代数效应可用于实现生成器和协程，这引发了一些疑问：代数效应是否只是在底层用协程（如 delimited continuations）实现的语法糖？讨论澄清了代数效应通常支持多重续体（可以多次恢复同一个暂停点），而标准生成器通常是单重续体。此外，代数效应通过类型签名提供了静态的效应声明，这是普通协程不具备的。
• React Hooks： 有人认为 React Hooks 是代数效应的一种弱形式（固定的 handler，单重恢复）。但其他观点指出，Hooks 不是真正的注入，缺乏类型安全，且 handler 不可替换，与完整的代数效应有本质区别。

实用性与采纳前景

对于代数效应能否在主流语言中普及，一些人表示怀疑，认为其复杂性、调试难度和潜在的性能开销可能限制其应用范围，可能只适用于需要复杂并发或控制流的特定领域。关于是否需要新语言，有人认为像 TypeScript 的 Effect 库证明了可以在现有语言中实现类似功能。但支持者反驳说，完整的代数效应（特别是多重续体）需要语言运行时支持（如 delimited continuations），这是库难以完全模拟的，因此新语言有其必要性。文章中 Ante 语言的伪代码风格受到了好评，被认为兼具 Haskell 的表达力和 Elixir 的实用性。

其他讨论

讨论中还出现了一些关于静态类型系统与动态逻辑系统（Abstraction Logic）的哲学探讨，探讨了类型是否是形式化和保证程序性质的唯一或最佳方式，以及 AI 对编程语言设计可能带来的影响。这段讨论虽然偏离主线，但反映了社区对编程语言基础理论的兴趣。

总的来说，这篇文章成功地解释了代数效应的强大之处和多样化用例，特别是它在统一控制流、抽象、依赖注入和纯度保证方面的潜力。然而，讨论也诚实地反映了开发者社区对这种新范式的担忧，尤其是它在大型项目中的可读性、调试复杂性以及与现有成熟模式（如 DI、Monads）的权衡。未来的发展将取决于语言设计者如何在提供强大能力的同时，解决这些实际应用中的挑战，特别是通过优秀的工具链支持。

Mermaid: Generation of diagrams like flowcharts or sequence diagrams from text

Mermaid 是一个基于 JavaScript 的图表和图示工具，它允许用户使用类似 Markdown 的文本定义来生成和修改复杂的图表。这篇文章主要介绍了 Mermaid 项目本身，强调其核心目标是帮助文档跟上开发进度，解决“文档腐烂”（Doc-Rot）的问题。通过将图表定义嵌入到文本中，Mermaid 使得图表更容易修改和维护，甚至可以集成到自动化流程中。

文章详细阐述了 Mermaid 的多种功能和应用场景，展示了它可以生成的图表类型，包括流程图、时序图、甘特图、类图、状态图、饼图、Git 图、用户旅程图以及 C4 图。这些示例直观地展示了如何用简洁的文本语法来创建不同类型的图表。Mermaid 提供了在线编辑器（Mermaid Live Editor）方便用户实时预览和编辑，并且强调了其在 GitHub、Notion 等平台上的广泛集成。项目还提到了其在安全方面的努力，特别是通过沙箱 iframe 来防止恶意脚本执行，以及如何报告安全漏洞。最后，文章对项目的贡献者和使用的底层库表示了感谢。

社区对 Mermaid 的讨论非常活跃，展现了开发者们对文本生成图表工具的看法和实际应用。

Mermaid 的集成能力

Mermaid 的集成能力是讨论中的一个主要亮点。许多人赞扬了 Mermaid 在 GitHub、Notion 和 Obsidian 等平台上的原生支持。他们认为这种无缝集成是 Mermaid 的杀手级特性，使得在文档（尤其是 Markdown 文件）中嵌入和维护图表变得异常方便，例如在大型 PR 中包含架构图或在笔记中快速绘制概念图。尽管有人提到 Notion 集成的 Mermaid 版本可能比较旧，但这并未削弱其在这些平台上的实用性。

与大型语言模型（LLMs）的结合使用

Mermaid 与大型语言模型（LLMs）的结合使用，也是一个备受关注的话题。多位用户分享了他们如何利用 ChatGPT 或 Gemini 等 LLMs 来生成 Mermaid 代码。这种用法极大地提高了效率，无论是从简单的文字描述、流程要点，甚至是手绘草图的照片，LLMs 都能快速生成可用的 Mermaid 或 PlantUML 代码，然后用户再进行微调。这被视为一种非常有价值的工作流程，尤其是在需要快速产出图表以供讨论或初步文档使用时。

图表工具的选择和价值

关于图表工具的选择和图表本身的价值，也引发了思考。一些用户将 Mermaid 与 Graphviz/dot、PlantUML、Excalidraw、Miro、D2 等其他工具进行比较。Mermaid 的优势在于其广泛的 Markdown 集成和文本可 diff 的特性，方便版本控制。然而，也有人认为 Mermaid 的语法有时过于严格，或者在布局方面不如 Graphviz 等工具灵活。关于图表本身的价值，存在两种观点：一部分开发者认为图表对于理解复杂系统、促进共享理解至关重要，一张图胜过千言万语；另一部分则认为许多图表文档很快过时，成为“写了没人看”的文档，不如直接阅读结构良好、可读性强的源代码，他们更倾向于将图表视为一种快速沟通或“应付要求”的工具，而不是核心文档资产。

此外，讨论中还提到了 Mermaid 的本地渲染问题，有人认为需要启动 headless Chrome 比较麻烦，但也有人指出 VS Code 等编辑器有插件支持本地预览。还有用户分享了特定领域的图表需求，例如根据 SQL 模式生成数据库关系图（并推荐了 DrawDB 和 Cacoo 等工具），以及生成家谱图的需求。

总的来说，Mermaid 因其文本化、易于版本控制以及在主流文档平台上的广泛集成而受到许多开发者的青睐，尤其是在与 LLMs 结合使用后，其生成效率得到了显著提升。尽管存在语法严格性、布局效果和图表价值本身的争议，但 Mermaid 已经成为开发者工具箱中一个实用且流行的选择。

Jupiter was formerly twice its current size, had a much stronger magnetic field

本周，一项发表在《自然天文学》（Nature Astronomy）上的研究引起了广泛关注，该研究表明，木星在早期曾是其当前大小的两倍，并拥有更强的磁场。

这项研究由加州理工学院的 Konstantin Batygin 和密歇根大学的 Fred C. Adams 共同完成，旨在探索木星的原始状态。核心思想是，了解太阳系最大行星的早期演化至关重要，因为木星常被称为“建筑师”，它显著影响了其他行星的形成和轨道。

那么，这项研究的主要发现是什么？研究人员计算得出，在太阳系中第一批固体形成约 380 万年后——一个围绕太阳的气体和尘埃盘正在消散的时期——木星的体积显著更大。我们谈论的是大约是其当前半径的两倍，这意味着其体积相当于超过 2000 个地球。除此之外，其磁场强度估计是今天的 50 倍左右。

他们是如何得出这些结论的？这正是有趣之处。研究人员没有仅仅依赖传统的行星形成模型（这些模型在气体不透明度或核心质量等因素上存在不确定性），而是采用了不同的方法。他们分析了木星微小内卫星木卫五（Amalthea）和木卫十四（Thebe）略微倾斜的轨道。这些轨道动力学，结合角动量守恒原理，提供了独立的约束条件，使他们能够重建木星在太阳星云消失那个关键早期时刻的大小和磁场强度。研究人员认为，这为完善现有理论（如巨行星形成的核心吸积模型）建立了一个有价值的“基准”。

这项研究在社区中引发了热烈讨论，大家围绕几个引人入胜的领域展开了探讨。

如何定义气态行星的大小？

一个基本问题随即浮出水面：如何定义气态行星的大小？与有固体表面的岩石行星不同，气态巨行星越往深处密度越大。有人指出，标准定义通常是大气压力等于 1 巴（地球海平面压力）的点。虽然这有些武断，但大家普遍认为一致性是关键——只要对过去和现在的状态应用相同的定义，大小的相对变化（例如大两倍）仍然有意义。压力随高度快速指数下降的特性也被讨论，认为这使得所选的精确压力水平不会大幅改变行星整体范围的图景。

大小、质量与密度的关系

另一个重要的讨论点围绕着大小、质量与密度之间的关系。如果木星曾经大两倍，它的质量是否也更大？文章和讨论澄清，其质量可能与今天没有太大差异。相反，早期的木星密度更低、温度更高，并且可能旋转得更快。大家讨论了气态巨行星中温度、质量和半径之间复杂的相互作用，并指出对于低于聚变阈值的行星，质量增加通常会导致密度增加，从而导致相对于质量增加而言半径更小，而热量则会使气体膨胀。土星密度低于其他气态巨行星的特殊情况也被作为这些复杂性的一个例子提出。

研究方法论的探讨

研究方法论也引发了讨论。一些人对就不可重复的过去事件做出强有力声明的科学有效性表示怀疑，质疑此类研究的可证伪性。另一些人则反驳说，虽然你无法重演太阳系的形成，但这类科学依赖于基于可观测物理定律和当前数据（如卫星轨道）构建模型。这些模型会做出预测（或对过去的逆推），并可以根据它们解释当前观测结果的程度进行测试和完善。这关乎通过展示模型在不同现象中的解释力来增加其可信度。

其他有趣的讨论

其他有趣的讨论还包括对木星核心成分的猜测（可能是向内迁移的重元素，源自一次先前的超新星爆发，而非我们的太阳），以及更广泛的问题：为什么气态巨行星在太阳系中形成于它们所在的位置（这与温度梯度和核心吸积所需气体的可用性有关）。甚至还有一段引人深思的题外话，探讨了遥远的未来，木星是否最终会冷却到其氢和氦大气层变成液体甚至固体“岩石”的程度，尽管这与地球上的岩石截然不同。

总而言之，这项研究通过巧妙分析木星最小的卫星，为木星早期的大小和磁场强度提供了具体的数字，从而揭示了木星炽热的青年时期。讨论突出了这引发的关于气态行星定义、其演化物理学以及对遥远过去进行科学研究本质的基本问题。这是一个很好的例子，说明当前的观测如何能够阐明我们太阳系的戏剧性历史。

The world of Japan's PC-98 computer

今天我们要聊的是一个来自日本的、在西方世界相对被遗忘的计算平台——NEC 的 PC-98 系列电脑。这篇文章深入探讨了这个平台独特的艺术风格和它所孕育的亚文化。

文章开篇就抓住了眼球，指出我们在网上看到的那些充满怀旧感、有时甚至有些诡异的像素艺术图像，很多都源自 PC-98。这种独特的风格，以其 4096 色的调色板和手工绘制的渐变效果为特征，催生了一个专门的收藏和创作亚文化。文章强调，早期的图形艺术家和黑客们在这些 80 年代的机器上，通过逐像素的精心绘制，将有限的内存推向极致，留下了深刻的数字艺术印记。

那么，PC-98 到底是什么？文章解释说，它是日本电子巨头 NEC 在早期家用电脑市场上的主导产品，一度占据了日本市场 60-70% 的份额。它之所以能击败 IBM 等竞争对手，关键在于其强大的图形能力。为了更好地显示复杂的日文字符，NEC 的机器配备了比同期美国电脑多达 16 倍的显存。这促使开发者充分利用这些特性（以及它们的局限性），催生了大量新游戏。

PC-98 的独特硬件（虽然颜色丰富但速度慢，且与当时的 MS-DOS 电脑不兼容）以及为其开发的游戏风格，让它被戏称为“动漫电脑”。由于速度限制，它特别适合开发故事驱动的游戏，比如后来成为主流的“视觉小说”。文章提到，《合金装备》的创作者小岛秀夫（虽然讨论中对此有争议）以及经典恐怖游戏《尸体派对》都与 PC-98 平台有关。

文章接着探讨了为什么 PC-98 在日本如此流行，但在西方却鲜为人知。一个主要原因是它的游戏“非常怪异”，甚至“淫秽”。这里引入了“Doujin”（同人）的概念。这些由爱好者组成的团体为 PC-98 创作了数千款游戏，形成了一个前卫、怪诞、常常涉及色情或侵犯版权内容的“狂野西部”。这些游戏在“御宅族”群体中非常流行，开发者们不断挑战硬件和“良好品味”的极限。文章指出，一些后来的主流游戏开发者正是通过在 PC-98 平台上的“成人内容”积累资金和经验。

PC-98 时代的终结是由于基于 Windows 的机器在性能上迅速超越了它，并且开放的标准打破了 NEC 的垄断。到 2000 年代，NEC 放弃了 PC-98，开发者转向了硬件更优越的新平台。那些专注于成人内容的开发者则迁移到了微软和苹果平台，因为这些平台没有主要发行商对成人游戏的禁令。宽带互联网的普及也改变了内容分发方式。

尽管如此，PC-98 的遗产仍在延续。仍有小团队甚至个人开发者在为它创作新游戏，模拟器社区也在努力翻译和保存这些作品。文章认为，虽然大多数人可能不会玩这些游戏，但它们的影响力在现代亚文化中依然可见，比如 Vaporwave 音乐、像素动画师的作品以及像《World Of Horror》这样的现代游戏。

这篇文章在社区中引发了热烈讨论，大家为文章增添了许多重要的视角和修正。

对文章描述的修正与补充

首先，许多人指出，文章对 PC-98 的描述可能过于侧重于其“怪异”和“同人”的一面，并且将文章中展示的许多游戏错误地归类为同人作品，它们实际上是商业出版物。大家强调，PC-98 在 80 年代末到 90 年代初是日本最流行的电脑，拥有海量的软件，包括大量的办公和生产力应用，以及各种类型的游戏，而不仅仅是那些小众的、奇怪的作品。它之所以在西方不为人知，主要是因为它从未在美国销售。

关于小岛秀夫的起点，讨论中也出现了不同的说法，有人认为应该是 PC-88 上的《Snatcher》，而不是 PC-98 上的《Policenauts》，并且他在此之前还有其他作品。这反映了对历史细节的考证和补充。

技术层面的深入探讨

在技术层面，讨论中也展开了有趣的探讨。有人认为 PC-98 独特的像素艺术风格可能与其早期普遍采用的模拟 RGB 输出有关，这与当时美国电脑主要针对复合视频输出（依赖像素混合和伪色）不同。PC-98 的艺术家可以直接针对 RGB 显示器进行创作。此外，PC-98 的图形能力被描述为介于 EGA 和 VGA 之间，拥有 4096 色的调色板，虽然一次只能显示 16 色，但这比 EGA 的 64 色调色板要宽得多，为艺术家提供了更大的选择空间。讨论还探讨了 IBM PC 早期图形能力的局限性，认为 IBM 当时并不重视游戏，只满足于基本的商业图形需求。

关于像素艺术的创作方式，讨论中也存在争论。文章提到艺术家是“逐像素”绘制的，但有观点指出，虽然细节部分确实需要精细调整，但日本 PC-98 上的高级绘图软件（如 Multi Paint System）提供了自动抖动和混合工具，使得艺术家可以更快速地完成大面积的渐变和填充，不完全是纯粹的逐像素操作。这两种观点可能反映了不同平台、不同时期或不同艺术家的工作流程差异。

文化与社会层面的反思

在文化和社会层面，文章中对“御宅族”和“eroge”（色情游戏）文化的描述也引发了一些批评，认为文章的语气带有偏见，并且没有将 PC-98 时代的成人内容与当今主流的、规模更大的色情产业进行恰当的对比。也有人指出，“怪异”或“变态”并非特定群体的专属，在其他粉丝社区中也普遍存在。同时，讨论也承认 PC-98 平台确实存在大量纯粹的色情或暴力内容，但也存在许多高质量的艺术作品，市场需求确实影响了内容的走向。

个人观察与额外信息

此外，讨论中还分享了一些个人经历和额外信息，比如在 PC-98 上安装 Linux 需要打补丁、它在大学实验室被用于商业应用、FreeBSD 曾经支持 PC-98 等，这些都进一步丰富了我们对这个平台的认识，展现了它作为一台功能全面的电脑在日本社会中的实际应用。

总的来说，讨论极大地补充和修正了文章的观点，提醒我们 PC-98 不仅仅是“怪异艺术”的温床，更是日本计算机历史中一个重要且多面向的平台，其技术特点、文化影响和历史地位都值得更全面地审视。

Show HN: HNRelevant – Add a "related" section to Hacker News

今天我们来聊一个非常有意思的 Hacker News 相关项目：HNRelevant，这是一个浏览器扩展，旨在为 Hacker News 页面添加一个“相关提交”部分。

这个项目的核心目标是帮助用户更方便地发现与当前正在浏览的文章或讨论相关的内容，从而挖掘出那些可能被埋没但同样精彩的旧帖子或相关讨论。开发者 imadj 提到，这是该项目自两年前初次发布以来的一个更新版本。最初的版本只是一个基本原型，需要手动安装，而现在它已经作为一个成熟的浏览器扩展发布，支持 Chrome、Firefox（包括 Android 版）以及 Microsoft Edge，并且提供了 Userscript 版本以支持更多浏览器。

在功能上，HNRelevant 的主要亮点包括：

• 即时显示相关提交列表： 当你访问一个 HN 提交页面时，扩展会自动或按需加载相关内容。
• 可定制搜索查询： 用户可以直接在页面上修改用于查找相关内容的搜索词。
• 无缝集成： 扩展的设计风格与 Hacker News 原生界面高度融合，看起来就像是网站自带的功能。
• 灵活的加载模式： 用户可以选择“自动”加载相关结果，或者设置为“手动”，只在需要时点击加载。
• 改进的准确性： 新版本通过分析文章标题以及评论内容来更准确地判断话题，从而提供更相关的结果。
• 支持移动设备： 扩展在窄屏和移动设备上也能正常工作。
• 偏好设置： 提供了弹出菜单供用户调整默认行为。

这个扩展的工作原理是利用了 HN Algolia 搜索 API，最初的搜索查询基于当前提交的标题。

社区对这个扩展普遍表示欢迎，并展开了多方面的讨论。

社区反馈与兼容性挑战

许多用户赞赏它能够很好地融入 HN 的原生设计，感觉就像是网站的一部分。特别是对 Firefox 的支持受到了好评，包括在 Firefox Android 版和 Orion iOS 上的可用性。

然而，一些用户也指出了兼容性问题，特别是与另一个流行的 HN 界面美化扩展“Modern for Hacker News”冲突。有用户报告说，当“Modern for Hacker News”启用时，HNRelevant 的相关内容块不会显示。开发者 imadj 迅速回应了这个问题，并创建了一个 GitHub Issue 进行跟踪。他初步调查发现，“Modern for Hacker News”对 HN 的 DOM 结构进行了彻底的重构，这使得兼容性成为一个挑战，并表示欢迎社区提供兼容不同设计的建议。

对“相关内容”功能的思考

关于扩展可能带来的影响，有用户提出了一个有趣的观点，他认为这种“相关内容”功能虽然很酷，但也可能像社交媒体的算法推荐一样，导致用户花费过多时间。开发者 imadj 对此进行了回应，强调 HNRelevant 与社交媒体的个性化推送不同，它更像是一个嵌入式的搜索引擎或图书推荐功能，并且提供了“手动”模式，让用户可以控制何时加载相关内容，从而避免成为一个被动的时间消耗器。

功能请求与开发者响应

讨论中还出现了一些功能请求，例如过滤掉评论数较低的重复帖子。开发者 imadj 积极采纳了这个建议，并表示已在最新版本 v1.3.0 中实现，该版本将在几天内上线到各个浏览器商店。

更广泛的技术讨论

此外，讨论中还出现了一些更广泛的思考，例如关于“Perma-Web”和使用向量嵌入、余弦相似度进行语义搜索的设想，以及对余弦相似度在搜索中的局限性的探讨。这些讨论虽然偏离了扩展本身，但也体现了 HN 社区对相关技术和未来网络形态的思考。

总的来说，HNRelevant 是一个受到社区欢迎的实用工具，它通过添加一个“相关提交”部分，增强了 Hacker News 的内容发现能力。尽管存在一些兼容性挑战，但开发者积极响应用户反馈并快速迭代，展现了开源项目的活力。

Modification of acetaminophen to reduce liver toxicity and enhance drug efficacy

今天我们要聊的话题围绕着一种我们很多人都非常熟悉的药物——对乙酰氨基酚，也就是大家常说的扑热息痛或泰诺。不过，这次的讨论视角非常特别，来自一位高中生的科学研究项目。

这篇来自 Society for Science 的文章介绍了一位名叫 Chloe Yehwon Lee 的 17 岁高中生，她是 Regeneron Science Talent Search 的决赛选手。她的研究项目聚焦于对乙酰氨基酚进行化学修饰，目的是降低其对肝脏的毒性，同时可能增强药效。

文章指出，对乙酰氨基酚是美国每周超过 6000 万人使用的止痛药，但它也是美国急性肝衰竭的主要原因，以及全球肝移植的第二大常见原因。Chloe 的研究正是为了解决这个严重的副作用。

她通过研究对乙酰氨基酚分子苯环的化学变化，探索如何降低肝毒性。她开发了修改后分子的计算机模型，以测试它们缓解疼痛和毒性作用的能力。根据她的研究，她发现并合成了一种修改后的对乙酰氨基酚分子，这种分子可能毒性更低，甚至可能比原始分子更能有效止痛。她认为，她的新分子可能是创造更安全、更有效对乙酰氨基酚形式的第一步。

文章还提到，Chloe 在学术之外的成就，比如她是学校管弦乐队主席和首席小提琴手，以及 Girls in STEM 俱乐部的创始人兼主席。

这项研究在社区中引发了热烈讨论，大家围绕着几个核心点展开了探讨：对这位年轻研究者的赞叹、对高中科学竞赛背景的审视、以及对对乙酰氨基酚本身药效和毒性的深入探讨。

对年轻研究者的赞叹与背景分析

许多人对一位 17 岁高中生能够进行如此复杂的化学研究表示震惊和赞赏，认为这达到了研究生甚至博士水平的工作。然而，也有相当一部分人指出，这类高中科学竞赛的顶尖项目往往离不开外部资源和指导。有观点通过搜索发现，Chloe 的父母分别是生物化学和药物科学领域的教授，这很可能为她提供了实验室、专业知识和指导，使得她能够进行计算机建模、合成等复杂实验。

这种讨论引出了一个更广泛的话题：这些竞赛在多大程度上是关于学生的个人才华，又在多大程度上是关于他们所能获得的资源和人脉？人们认为，虽然不能否定学生的努力和聪明才智，但承认这些项目背后所需的“访问权限”（access）是重要的，这反映了科学研究领域现实中的资源分配问题。

对乙酰氨基酚的药效与毒性

对乙酰氨基酚的药效与毒性是讨论中最热烈的话题之一。许多人分享了他们使用对乙酰氨基酚的个人经验。

• 药效差异： 有人认为它对头痛和发烧非常有效，尤其是在儿童退烧方面表现出色。但也有很多人表示，它对身体疼痛、关节痛或剧烈疼痛（如牙痛）几乎无效。人们推测这可能与对乙酰氨基酚不像布洛芬等 NSAIDs 那样具有抗炎作用有关，因此对炎症引起的疼痛效果不佳。
• 低治疗指数与毒性： 社区普遍认识到对乙酰氨基酚的“治疗指数”较低，即有效剂量与中毒剂量之间的差距相对较小。人们强调了过量的危险性，指出仅仅超过推荐最大剂量 2-3 倍就可能导致严重的肝损伤甚至肝衰竭，而且这种死亡方式非常痛苦。
• 过量原因与监管： 讨论触及了意外或故意过量的问题。意外过量常发生在使用含有对乙酰氨基酚的复方感冒药或止痛药时，人们可能没有意识到自己摄入了过量。故意过量则常与自杀企图有关。人们对比了不同国家的监管措施，例如英国、瑞典和法国对单次购买数量或单盒最大剂量有限制（如 500mg 片剂，单盒不超过 10-20 片），认为这有效降低了自杀率，而美国在这方面的限制较少，可能与游说有关。
• 解毒剂： 讨论中提到了对乙酰氨基酚过量的解毒剂 N-乙酰半胱氨酸（NAC），但同时也指出其局限性，比如需要在中毒后 8-12 小时内尽快服用，且可能引起副作用（如恶心、呕吐、过敏反应），并不能保证完全恢复。

与其他止痛药的比较

人们将对乙酰氨基酚与 NSAIDs（如布洛芬、萘普生、阿司匹林）和阿片类药物（如吗啡、芬太尼）进行了比较。

• NSAIDs vs. 对乙酰氨基酚： NSAIDs 对炎症引起的疼痛更有效，但长期使用有胃肠道出血、肾脏损伤和心血管风险。对乙酰氨基酚则主要风险在于肝脏，且急性毒性窗口更窄。人们认为，对于轻度疼痛或发烧，对乙酰氨基酚是首选，因为它没有 NSAIDs 的长期风险，且非成瘾性。但对于需要抗炎作用的疼痛，NSAIDs 更优。
• 阿片类药物： 社区普遍认为阿片类药物是治疗剧烈疼痛的有效手段，尤其是在受控的医疗环境下（如术后、临终关怀）。但其成瘾性、呼吸抑制、便秘、恶心等副作用是主要问题。有观点认为，在某些情况下，阿片类药物的副作用可能比 NSAIDs 或对乙酰氨基酚的长期风险更可控，但成瘾风险巨大。

研究的潜在意义与挑战

如果这项研究成果（降低毒性、增强药效）能在后续的体外和体内实验中得到证实，那将具有巨大的临床意义，能显著提高对乙酰氨基酚的安全性。但也有人指出，从实验室合成到成为上市药物还有漫长的路要走，需要大量的测试（包括毒理学、药代动力学、临床试验）和克服监管障碍。一位观点从化学角度指出，她合成的分子可能在药物特性（如 Lipinski's Rule of Five）方面存在挑战，影响其生物利用度。此外，复杂的合成步骤可能会显著增加药物成本，使其不再是廉价的非处方药。

总的来说，这篇关于一位高中生研究对乙酰氨基酚的文章，在社区引发了一场关于药物科学、公共健康、教育公平和科学竞赛本质的广泛讨论。它不仅展示了年轻一代在科学探索上的潜力，也暴露了常用药物背后隐藏的风险，以及社会在药物监管和科学人才培养方面面临的复杂问题。

Show HN: Rotary Phone Dial Linux Kernel Driver

今天我们来聊一个非常有意思的项目，它将老式技术与现代 Linux 黑客精神完美融合：一个旋转拨号电话的 Linux 内核驱动。

这个项目的核心理念既简单又小众：将经典的旋转拨号电话机制，变成 Linux 系统上的标准输入设备。作者 Stefan Wiehler 将其视为一个为那些欣赏慢节奏拨号、希望将复古硬件融入数字世界，或者正在寻找一个简单直接的 Linux 内核驱动示例（包括强大的测试环境）的人而设计的项目。

从技术角度看，该驱动通过 GPIO 引脚与旋转拨号盘的内部开关连接，可能是在树莓派或类似嵌入式 Linux 板上。旋转拨号盘通常有两个主要开关：“BUSY”开关（当拨盘从静止位置拉开时闭合）和“PULSE”开关（当拨盘返回时快速开合）。驱动程序监控这些脉冲。脉冲的数量对应于拨出的数字——通常一个脉冲代表“1”，两个代表“2”，以此类推，直到十个脉冲代表“0”。驱动程序处理这些机械开关的时序和去抖动，并将脉冲计数转换为标准的按键事件，使旋转拨号盘基本上像数字键盘一样工作。项目包含了接线、时序特性以及如何使用 Linux 设备树进行配置的文档。

对于对内核模块感兴趣的开发者，该项目被构建为一个 out-of-tree 模块，并提供了一个使用 Nix 和 gpio-sim 的综合开发环境。这允许在虚拟机中模拟拨号盘的电信号来测试驱动程序的逻辑，而无需物理硬件。作者指出，这个项目是他接触嵌入式 Linux 的起点，并最终引领了他的职业生涯，突显了其作为学习工具的价值。他还提到最初曾考虑用 Rust for Linux 重写，但发现必要的绑定尚未成熟，并幽默地表示该驱动被主线（mainlined）到官方内核树的可能性不大。

这个项目在社区中引起了广泛共鸣，引发了技术讨论、怀旧轶事和创意想法的碰撞。

个人经历与相关项目

许多人分享了他们自己与旋转拨号电话相关的经历和项目。一位用户回忆起在 70 年代末为 HP-41C 计算器制作旋转拨号器，以及几十年后与一本关键编程手册作者的偶然相遇。另一位用户分享了他们将旋转拨号电话转换为功能齐全的蓝牙耳机（包括通过旋转机制拨号）的项目，该项目曾在 Hackaday 上被报道。还有人提到将旋转拨号电话转换为移动电话。这些例子展示了人们对重新利用这种标志性技术的广泛兴趣。

与现代 VoIP 服务的结合

关于将旋转拨号电话与现代 VoIP 服务结合使用的实用讨论也随之展开。人们讨论了需要支持脉冲拨号（而非更常见的 DTMF 音）的模拟电话适配器（ATAs），并分享了寻找兼容硬件和经济实惠的 VoIP 服务以保持“座机”号码与复古设备连接的技巧。这突显了理解脉冲信号的实际应用。

脉冲拨号的历史细节

一个引人入胜的历史细节浮出水面，涉及脉冲拨号的区域差异。虽然大多数国家使用标准的 1-9，0 映射，但有人解释说，新西兰使用反向映射（1 个脉冲代表 9，2 个代表 8，...，10 个代表 0）。另一位用户为此提供了深入的技术原因，将其与早期机械旋转电话交换机中离合器的磨损模式联系起来，这是一种巧妙的工程决策，旨在减少维护。这种历史背景是社区讨论中常见的乐趣。

创意与意外发现

这个项目也激发了一些有趣的创意，包括经典的“用旋转拨号盘通关《黑暗之魂》（Dark Souls）”的建议，这与其他非传统游戏控制器异曲同工。

或许最令人惊喜的讨论，是关于在现代智能手机上实现旋转拨号界面的想法。一位用户回忆起曾为最初的 iPhone 传闻提出过触摸轮旋转拨号的建议。这促使另一位在苹果公司工作过的用户透露，苹果确实为触摸轮上的模拟旋转拨号界面申请了专利，史蒂夫·乔布斯（Steve Jobs）被列为发明人之一，而他本人也在同一时间提交了类似的独立专利。这个关于苹果内部并行发明和专利申请的轶事，即使该功能最终未被实现，也是讨论中的一大亮点。

总的来说，这个项目不仅因其作为简单内核驱动示例的技术实现而受到赞赏，还因为它触及了怀旧情结，激发了创意的硬件黑客行为，并引发了对电信历史和工程怪癖的有趣探讨。

The Xenon Death Flash: How a Camera Nearly Killed the Raspberry Pi 2

今天我们要聊的是一个发生在树莓派（Raspberry Pi）上的离奇硬件故障，它被社区戏称为“氙气闪光死亡事件”（Xenon Death Flash）。这个故事不仅揭示了现代电子设计中的一些隐藏风险，也展现了社区协作解决问题的强大力量。

这篇文章讲述了 2015 年树莓派 2 发布后不久，一位用户偶然发现用带氙气闪光灯的相机拍照时，树莓派 2 会立即关机。这个看似荒谬的现象，经过社区的集体侦查，最终被定位到一个特定的电源管理芯片，并揭示了其背后的物理原理——光电效应，以及现代芯片封装技术带来的意外脆弱性。

故事始于用户 Peter Onion 试图给他的新树莓派 2 拍照。他注意到每次相机闪光灯亮起时，Pi 2 都会意外断电。起初以为是巧合，但重复发生后，他将问题报告到论坛，引发了社区的广泛关注。

社区成员迅速展开了“侦探工作”。他们尝试了不同的相机和光源，很快发现只有使用氙气闪光灯的相机才会触发问题，而 LED 闪光灯则没有影响。这确定了问题的光源特性。

接着，他们开始系统性地测试树莓派板上的哪个组件是罪魁祸首。通过遮盖不同的区域，他们发现只要遮住板上一个名为 U16 的小型