Hacker News 每日播报 2025-06-15

欢迎来到 Hacker News 每日播报，今天我们将深入探讨人工智能、编程语言、数据系统、奇特发明、硬件前沿以及软件可观测性等多个热门话题。

Q-learning 尚未实现规模化

一篇来自 seohong.me 的文章指出，尽管强化学习（RL）在某些领域取得了显著成功，但其中一种重要的算法——Q-learning，或者说基于时序差分（TD）学习的离策略（off-policy）RL，目前还无法像其他机器学习目标那样，通过简单地增加数据和计算资源来解决更复杂、更长期的任务。

文章首先回顾了机器学习在规模化上的成就，并指出强化学习也取得了进展，例如在围棋、国际象棋以及大型语言模型（LLMs）的复杂推理任务上达到超人水平。然而，这些成功案例大多依赖于在策略（on-policy）RL 算法（如 PPO），这类算法需要使用当前策略生成的新数据进行训练，无法有效重用旧数据。这在数据生成成本低的场景下不是问题，但在大多数真实世界应用（如机器人）中，数据收集成本极高，在策略方法效率低下。

离策略（off-policy）RL 原则上可以使用任何来源的数据，从而大大提高样本效率。Q-learning 是最广泛使用的离策略 RL 算法之一。文章提出了关键问题：Q-learning 是否也能像其他可扩展目标一样实现规模化？作者的回答是：尚未实现，至少对于需要超过约 100 个语义决策步骤的长周期（long-horizon）问题来说是如此。作者区分了两种规模化：“宽度”规模化（解决更多任务）和“深度”规模化（解决更具挑战性、更长周期任务），他认为 Q-learning 在“深度”方向上缺乏可扩展性。

文章给出了两个主要理由：首先是经验证据，大型成功案例（如 AlphaGo、LLMs 的 RL）大多基于模型基（model-based）RL、蒙特卡洛树搜索或在策略策略梯度方法，而非基于一步时序差分（1-step TD）的 Q-learning。其次是实证研究，作者引用了他们最近的一项研究，在复杂、长周期的机器人和解谜任务中，即使使用比典型数据集大 1000 倍的数据，标准离策略 RL 算法也未能解决所有任务，出现了明显的性能平台期。

根本问题在于 Q-learning 的预测目标是有偏的，并且这些偏差会随着决策周期的延长而累积。Q-learning 的时序差分损失函数中包含一个 max 操作符，这引入了偏差，这种偏差累积是 Q-learning (TD learning) 独有的根本限制。随着问题周期变长，偏差累积变得越来越严重，难以通过增加数据或模型规模来缓解。研究中唯一奏效的改进方法是**周期缩减（horizon reduction）**技术，例如 N 步回报（n-step returns）或分层 RL（hierarchical RL），这有力地支持了偏差累积是主要障碍的论点。

文章最后呼吁研究界寻找一种真正可扩展的离策略 RL 目标，认为找到这样的算法是当前机器学习领域最重要、最缺失的一环，将极大地推动 RL 在机器人、智能体等更广泛真实世界问题中的应用。

社区观点：挑战与潜在方向

社区对这篇文章展开了热烈讨论，补充了观点并提出了一些疑问。

一些观点同意作者关于偏差累积是核心问题的看法，并指出 Q-learning 的更新目标依赖于自身的近似值，缺乏一个稳定的地面真值（ground truth），这使得它像在追逐一个移动的目标。有人提到像 Double Q-learning 这样的方法就是为了减少这种过估计偏差。

除了作者提出的偏差累积，有观点补充了 Q-learning 在长周期任务中难以规模化的另一个重要原因：状态空间的指数级增长。他们认为，随着周期变长，可能的状态数量通常呈指数增长，这需要指数级增长的数据才能覆盖足够的状态。不过，也有人反驳说，如果状态空间存在可学习的结构，深度学习的泛化能力可以缓解这个问题，关键在于训练目标是否合适。

关于潜在的解决方案，社区也提出了多种看法。

模型基 RL 被多次提及，许多人认为这可能是解决长周期问题的方向。学习一个世界模型，然后在模型中进行规划或在策略学习，可以避免 Q-learning 的偏差累积问题。
分层学习也得到了共鸣，指出人类在学习复杂长周期任务时，也是将其分解为更短周期的子任务并进行组合，这与文章中周期缩减的有效性相符。
一些观点提到了决策 Transformer (Decision Transformers) 和轨迹 Transformer (Trajectory Transformers) 等方法，它们是离线 RL 方法，在长周期任务上表现良好。他们认为这些方法通过注意力机制，可以在一定程度上绕过传统 RL 的信用分配问题，直接关联远距离的状态和奖励。
还有观点提到了 TD-Lambda 或 Streaming DRL 等方法，认为它们可能通过更有效地管理长期奖励来解决长周期问题。

社区也出现了一些辩论和澄清。例如，有观点认为文章对 AlphaZero/MuZero 的分类有误，指出它们并非严格的模型基或在策略方法，而是通过训练时的温度采样和多步查找来提高学习效率。关于为什么折扣因子 Gamma 不足以处理极长周期任务，有解释说，对于相隔数百甚至上千步的稀疏奖励，即使是 0.99 的折扣因子也会导致奖励信号衰减到几乎为零，难以学习到有效的信用分配。

总的来说，社区普遍认可作者提出的 Q-learning 在长周期任务上面临的挑战，特别是偏差累积问题，并围绕可能的解决方案以及对现有算法的理解展开了深入讨论，为寻找可扩展的离策略 RL 算法这一重要研究方向提供了更多视角和思考。

Lisp 与写作的艺术 (2003)

这篇发表于2003年的文章《Lisp与写作的艺术》，作者 Richard P. Gabriel 提出一个核心观点：编程，尤其是使用像 Lisp 这样的语言进行编程，更应该被视为一种艺术或写作的创造性活动，而非仅仅是严格的工程实践。

文章深入阐述了这一观点，将艺术、工程和科学置于一个发现真理的连续体上。作者认为，艺术家和工程师都在探索世界的属性。他以写作为例，将其分解为“发现”（一种心流状态，想法自然涌现）和“完善呈现”（修改和打磨）。地图绘制也被用作类比，强调为了特定目的而选择性地包含、排除甚至扭曲信息。

Gabriel 区分了 Lisp 这样的“编程媒介”和 Java 这样的“编程语言”。他认为 Lisp 因其高度的可塑性和动态性，更适合用于探索计算思想和应对在开发过程中涌现的内部和外部需求。相比之下，Java 等语言被被设计用于表达已完成的程序，强制开发者提前做出僵化的决策，这阻碍了在构建过程中进行必要的探索和调整。他引用建筑师 Christopher Alexander 的观点，强调系统本身的内部力量会产生需求，设计必须与这些现实相平衡。作者批评主流软件开发倾向于僵化的语言，认为这是“过早优化”的结果——为了编译器和性能而牺牲了对开发者探索和发现的支持。他指出，敏捷开发等方法论虽然强调迭代和适应变化，但使用的工具（僵化的语言）却与这一理念相悖。Lisp 的灵活性和开放性，在他看来，体现了艺术和编程中那种“鲁莽地遭遇一切”的精神。

社区观点：编程的本质与工具选择

社区的讨论热烈且多角度。许多读者对 Gabriel 的哲学思考和优美文笔表示赞赏，并推荐了他的其他作品。

关于 Lisp 本身，一些观点认为，如今 Lisp（如 Common Lisp, Scheme）的吸引力部分在于其较低的商业就业率，这反而培养了一种更纯粹、更少受商业驱动的社区氛围。

文章的核心类比——Lisp 与写作/诗歌——引发了有趣的辩论。一些人认同 Lisp 通过宏等特性允许开发者重塑语言本身，使其更像是在操作一种媒介，从而与写作的创造性相呼应。然而，也有观点反驳说，即使是诗歌，人类语言也遵循相对固定的语法和规则，而 Lisp 改变“语法”的能力使其与自然语言有根本区别。这场辩论围绕着类比的精确性以及不同语言在灵活性上的程度展开。

讨论也触及了其他编程语言。有人认为 Python 在某种程度上继承了 Lisp 的动态和艺术特质。另一些人则偏爱 Go 这样的语言，欣赏其稳定性、简洁性和性能，认为“有用”的语言才是最美的。

更广泛的行业趋势也被纳入讨论。关于 LLM 是否“商品化”了编程，以及编程是否曾被“把持”的观点存在分歧。一个重要的观点是，外部限制（如生态系统的封闭性、平台收费）对编程创造力的影响可能远大于语言设计本身。这引发了关于开放平台重要性的讨论，一些人认为像 Emacs/Lisp 这样的环境提供了真正的、实践上的自由，而许多现代设备和平台正变得越来越封闭，限制了用户的创造性探索。

总体而言，社区既有对文章深刻见解的共鸣，也有基于不同语言经验和对行业现状看法的辩论，共同探讨了编程的本质、工具的选择以及外部环境对开发者创造力的影响。

Rust 中的 Datalog

这篇 Hacker News 文章的主题是 Frank McSherry 关于在 Rust 中实现 Datalog 的一篇博客文章。文章深入探讨了构建一个 Datalog 引擎的技术细节和挑战。

文章的重点内容在于作者如何着手实现一个 Datalog 系统，并在这个过程中遇到的具体问题和优化过程。社区反馈显示，文章可能涵盖了 Datalog 程序的解析、数据存储结构（有观点提到了 LSM 树），以及核心的查询执行策略，特别是连接（join）算法。文章似乎通过一个具体的例子（可能是程序分析中的别名查询）来展示实现过程，并详细描述了如何通过优化将一个最初占用大量内存的实现变得更加高效。社区特别赞赏了文章的叙事方式，称其技术深度与引人入胜的“侦探故事”般的优化过程相结合，使得阅读体验非常愉快。

社区观点：技术实现、应用与生态

社区展现了对 Datalog 和其在 Rust 生态中应用的广泛兴趣和多样的视角：

首先，许多开发者对 Frank McSherry 的新文章表示欢迎和兴奋，认可他在数据系统领域的贡献。

其次，不少开发者分享了他们当前或过去的 Datalog 相关项目经验，尤其是在 Rust 环境下。有人正在使用 Differential Datalog 和 Rust 开发实时策略游戏，这显示了 Datalog 在特定应用场景（如游戏逻辑）中的吸引力。也有人提到了将其他 Datalog 实现（如 Mangle）移植到 Rust 的工作，并讨论了不同实现方式（如使用 proc-macros 进行静态分析 vs. 支持运行时查询）的优劣。此外，还提到了其他 Rust 中的 Datalog 项目，如 Cozodb、Ascent 和 Crepe。

第三，关于查询执行策略，特别是连接算法，引发了深入的技术讨论。文章可能介绍了二元连接（binary join）的方法，这促使社区对比了二元连接与最坏情况最优连接（Worst-Case Optimal Join, WCOJ）的优缺点。讨论指出，虽然 WCOJ 在理论上最优，但在实际应用中，尤其对于程序分析等物化（materialization）密集型工作负载，经过优化的二元连接计划可能因为更好的可伸缩性（更少的锁）和无需使用 Trie 结构而表现更好。同时，讨论也承认在某些查询中，所有二元计划都会“爆炸”，此时 WCOJ 是必需的，并提到并行化 WCOJ 仍然是一个开放的研究问题。

第四，社区也探讨了 Datalog 与传统关系型数据库语言 SQL 的比较。一些人认为 Datalog 在表达能力上优于 SQL，特别是在处理递归查询方面，SQL 的递归语法（如 WITH RECURSIVE）被认为不够直观。有观点提到了 Materialize 和 Feldera 等系统在 SQL 中提供了更友好的递归表达方式，以及 Logica 和 Percival 等项目尝试将 Datalog 编译为 SQL，这表明了 Datalog 思想对现代数据系统的影响。

最后，关于 Datalog 社区的活跃度也有不同看法。有人认为近期 Datalog 相关会议规模较小可能预示着其复兴势头有所减缓，但也有人反驳说，会议规模受多种因素影响，并指出 Datalog 的研究前沿已经超越了“香草 Datalog”引擎本身，转向了流处理、选择、追溯（chase）引擎等更复杂的理论和应用，这表明 Datalog 作为基础理论依然活跃并被用于构建更高级的系统。

总的来说，这篇文章及其讨论提供了一个关于在 Rust 中实现 Datalog 的技术实践案例，并引发了关于 Datalog 的实现技术、与其他查询语言的比较以及其在当前技术生态中地位的广泛讨论。

鸡眼镜

今天我们要聊的话题非常特别，来自 Hacker News 上一篇关于维基百科文章的分享——“鸡眼镜”（Chicken Eyeglasses）。这听起来可能有点不可思议，但它确实是真实存在过的东西。

这篇文章详细介绍了“鸡眼镜”，也被称为“鸡规格镜”或“啄食防护罩”。顾名思义，这是一种为鸡设计的小型眼镜，其主要目的是为了防止鸡群中的恶习，比如互相啄羽毛甚至同类相食。文章指出，鸡眼镜与另一种家禽用品“眼罩”（blinders）不同，眼罩是完全不透明的，会阻碍鸡向前看，而鸡眼镜则允许它们向前看，但会以某种方式影响它们的视野。

文章深入阐述了鸡眼镜的设计和用途。它们通常由赛璐珞或铝制成，设计多样，有的通过绑带固定，有的则通过小钩或销钉穿过鸡的鼻孔或鼻中隔来固定。值得注意的是，某些需要穿刺组织的设计在一些国家是违法的，出于动物福利的考虑。鸡眼镜被视为喙修剪（debeaking）的一种替代方案。喙修剪是一种通过切除部分喙来减少啄伤的方法，但这会给鸡带来痛苦并影响其福利。

文章特别提到了红色的镜片。一种流行的观点认为，红色的镜片可以掩盖其他鸡身上的血迹颜色，从而降低鸡因看到血而产生攻击行为的倾向。然而，文章也引用了主要生产商的说法，他们认为这种血迹掩盖理论可能只是个神话，因为他们认为鸡是色盲的（尽管文章随后纠正了这一点，指出鸡和其他鸟类一样具有良好的色觉）。有趣的是，有一种带红色镜片的鸡眼镜设计是铰接式的，当鸡低头啄食时，镜片会向上翻起，提供清晰的视野；当它们抬头时，镜片则会落下，呈现红色的视野，以此来抑制攻击性。文章甚至提到曾有人提出过使用红色隐形眼镜来解决这个问题。

从历史上看，鸡眼镜早在20世纪初就获得了专利并开始大规模生产和销售。它们曾通过邮购公司或饲料店销售。虽然现在已不再大规模生产，但它们已成为收藏品。文章还提到，直到1970年代，仍有农场使用这种眼镜，并且这种奇特的发明甚至在电视节目中作为嘉宾的职业被展示过。

社区观点：动物福利与工业化养殖的思考

社区的讨论非常活跃，围绕着这个奇特的发明展开了多角度的探讨：

首先，动物福利和伦理是讨论中最突出的主题。许多观点认为，鸡眼镜以及喙修剪等措施，都是在试图解决由集约化养殖环境（将大量鸡塞进狭小空间）引起的行为问题。他们呼吁用同情心和尊重对待这些动物，认为更好的解决方案是改善饲养条件，提供更多空间和自然环境，而不是用技术手段去“工程化”地解决症状。一些用户推荐购买经过认证的人道饲殖或散养鸡蛋和鸡肉，以此来支持更道德的养殖方式。

由此引申出一个更深层次的讨论：工业化养殖的本质。有观点认为，工业化养殖似乎总是在试图通过技术手段来规避其根本问题——即动物在非自然环境下的痛苦和异常行为。这引发了关于“中间地带”的讨论，即在极端集约化养殖和完全回归田园式养殖之间，是否存在可以改善动物福利的规模化养殖方式。

除了伦理讨论，社区也对鸡的行为本身表现出兴趣。有人提到，即使在最好的条件下，鸡也可能因为各种原因（比如建立啄食顺序）而互相攻击，这并非完全是环境恶劣导致的问题，尽管环境会加剧。还有人分享了养鸡的经验，提到公鸡的攻击性和对母鸡的过度交配行为，以及蛋白质摄入不足可能导致鸡群更具攻击性。关于是否应该用人类的道德概念来描述动物的交配行为，也引发了一场关于拟人化的辩论。

当然，作为一个如此奇特的发明，讨论也充满了好奇和幽默。有人抱怨维基百科文章的顶部没有鸡戴眼镜的图片，并由此引申出关于维基百科图片惯例的玩笑。有人分享了在老式棋盘游戏中看到过鸡眼镜的回忆，认为这是一个“解决方案寻找问题”的典型例子，但也反映了前工业时代解决动物福利问题的尝试。还有人提到了鸡隐形眼镜的失败尝试，这进一步凸显了人们在解决这个问题上的各种奇思妙想。

总的来说，这篇关于鸡眼镜的维基百科文章及其讨论，不仅展示了一个鲜为人知却充满历史趣味的发明，更引发了社区对现代农业、动物福利、技术解决方案的局限性以及人类与动物关系的深刻思考。这是一个关于工程、伦理和生物行为交织在一起的引人入胜的故事。

AMD 的 AI 未来是机架级“Helios”

好的，各位听众，欢迎回到 Hacker News 播客。今天我们要聊的是 AMD 在人工智能领域的新动向，特别是他们面向数据中心的“Helios”机架级解决方案。

这篇来自 More Than Moore 的文章，详细介绍了 AMD 在其 Advancing AI 2025 活动中发布的一系列重要更新。核心主题是 AMD 如何基于其最新的硬件和软件，将 AI 战略从单一加速器推向完整的机架级系统，以更好地与市场领导者竞争。

文章首先介绍了 AMD 的新一代 AI 加速器：Instinct MI350 系列，特别是液冷版的 MI355X 和风冷版的 MI350X。这些新芯片基于第四代 CDNA4 架构，相比上一代 MI300X，矩阵运算性能几乎翻倍，并且首次原生支持 FP6 和 FP4 等低精度数据类型，在理想情况下峰值吞吐量可达 MI300X 的四倍。MI350 系列配备了 288GB 的 HBM3E 内存，带宽高达 8 TB/秒。制造工艺上，CDNA4 采用了台积电最新的 N3P 节点，晶体管数量达到 1850 亿。功耗方面显著提升，MI355X 可达 1400W，MI350X 也达到 1000W，这反映了市场对极致性能的需求。AMD 认为，凭借这些特性，MI350 系列在每美元可处理的 tokens 数量上能比 NVIDIA 的 GB200 平台高出 40%。MI350 解决方案预计将在今年第三季度由合作伙伴推出。

软件层面，文章重点介绍了 ROCm 7。这是 AMD 的 GPU 计算软件栈的最新版本，为 CDNA4 架构和 MI350 系列提供了支持。AMD 强调 ROCm 7 在性能上的显著提升，声称现有 MI300X 在 ROCm 7 下的推理和训练性能比 ROCm 6.0 快了 3.8 倍。更重要的是，AMD 表示正将重心从追赶转向“日零支持”（day-0 support），力求在新框架和新服务发布时就能提供支持，特别是针对 PyTorch。此外，ROCm 7 还将开始预览对 Windows 原生环境的支持，包括 PyTorch 和 ONNX Runtime，并首次支持 RDNA 4 和 RDNA 3 消费级 GPU 进行 ROCm 开发。ROCm Enterprise AI 则提供了面向企业级集群管理的工具。

除了芯片和软件，AMD 还通过收购 Pensando 获得了高性能网络能力，推出了 Pollara 400 AI NIC。这款 400G 以太网卡是 AMD 构建完整机架解决方案的关键一环，使得客户可以采购由 AMD CPU (Turin EPYC)、AMD GPU (MI350) 和 AMD 网卡组成的整套系统。Pollara 400 也是首款 Ultra Ethernet Consortium (UEC) 就绪的 AI 网卡，AMD 正将未来押注在这一下一代以太网标准上，以实现大规模扩展。

最后，文章展望了 AMD 的机架级未来，特别是 2026 年的“Helios”系统。Helios 将搭载下一代 MI400 加速器（基于“CDNA Next”架构）、第六代 EPYC“Venice”CPU 和 800G 的“Vulcano”网卡。MI400 目标是实现 20 PFLOPS 的 FP8 性能，配备 432GB HBM4 内存，带宽高达 19.6 TB/秒，并将支持 Ultra Accelerator Link (UAL)，旨在实现高达 1024 个 GPU 的规模扩展。AMD 计划通过 Helios 机架（预计包含 72 个 GPU）在性能、内存容量和带宽上与 NVIDIA 的下一代 Vera Rubin 系统竞争。AMD 还公布了直到 2027 年的机架路线图，并设定了到 2030 年将机架级能效提升 20 倍的长期目标。

总的来说，文章描绘了 AMD 在 AI 领域雄心勃勃的计划，从强大的新硬件到改进的软件栈，再到完整的机架级解决方案和清晰的未来路线图。

社区观点：软件生态的挑战与机遇

社区对 AMD 的这些发布表现出了浓厚的兴趣，但同时也伴随着显著的怀疑和现实的考量。

讨论中最集中的点无疑是 AMD 的软件栈 ROCm。许多用户表达了对 ROCm 历史表现的失望，认为它“取决于用例，表现不稳定”（hit or miss），特别是对消费级显卡的支持“非常值得怀疑”（questionable to say the least）。有人直言，尽管硬件有潜力，但软件问题导致他们最终还是转向了 CUDA，因为 CUDA“节省了大量时间和精力”。这种观点认为，即使过了 15 年，AMD 似乎仍未完全掌握构建强大软件生态的秘诀，而 NVIDIA 在软件栈上的“心智份额”（mindshare）已经形成了强大的护城河。

一些观点指出，虽然 AMD 在 Top500 超级计算机榜单上表现不错，有系统使用了 Instinct 卡，但这往往是针对特定大型客户的“定制构建”（custom builds），有 AMD 工程师提供深度支持。这与更广泛的 AI 市场不同，后者需要一个能在各种系统上“开箱即用”（day 1 work）的软件栈。有人认为，AMD 过去可能被 HPC 市场的定制需求“拖累”，未能全力投入更广阔的 AI 市场。

关于 AMD 声称的“日零支持”和 ROCm 7 的性能提升，社区也存在分歧。一些人对此表示欢迎，认为 AMD 终于意识到了软件的重要性，并开始兑现承诺。但也有人持保留态度，认为 AMD 过去在软件支持上的记录不佳，特别是 RDNA4 消费卡发布后 ROCm 支持的延迟，让人怀疑他们能否真正实现“日零支持”。

一个反复出现的战略性讨论是，AMD 是否应该更重视消费级 GPU 的 ROCm 支持。许多观点认为，NVIDIA 之所以能在 AI 领域建立如此强大的生态，很大程度上是因为他们的 CUDA 可以在任何消费级 GeForce 卡上运行，这使得学生、研究人员和爱好者可以在家学习和开发，从而形成了庞大的开发者基础和人才库。如果 AMD 只关注数据中心，忽视这个“长尾”市场，他们将难以吸引开发者，最终可能影响到大型客户的人才招聘和技术采用。

当然，也有一些积极的声音。有人提到，MI300X 在一些训练任务中已经显示出不错的性能，在特定条件下能与 H200 的 GPU 小时性能大致匹配。还有人指出，像 PyTorch 这样的上层框架本身是硬件无关的，核心问题在于底层的 ROCm 后端能否高效工作。此外，AMD 提供的开发者云服务（提供免费 GPU 小时）被视为一个积极的尝试，让开发者有机会体验 AMD 硬件。

总而言之，社区对 AMD 的新硬件和机架级战略表示了关注，认可其在性能和技术规格上的进步。然而，长久以来困扰 AMD 的软件生态问题，特别是 ROCm 的稳定性和对消费级硬件的支持，仍然是社区最大的担忧和讨论焦点。AMD 的未来 AI 成功，在很大程度上取决于他们能否在软件层面真正缩小与 NVIDIA 的差距，并构建一个更广泛、更易用的开发者生态系统。

用 AI 生成的“掩膜”在数小时内修复受损画作

欢迎回到 Hacker News 播客。今天我们要聊的是一项来自 MIT 的创新技术，它将人工智能和材料科学结合起来，以前所未有的速度修复受损画作。

这篇来自 MIT News 的文章标题是《Have a damaged painting? Restore it in just hours with an AI-generated “mask”》。文章介绍了一种全新的物理修复画作的方法，核心在于使用一种由 AI 生成的“掩膜”（mask）。

传统上，修复一幅受损的画作是一项极其耗时耗力的工作。修复师需要逐点识别需要修补的区域，然后精确调色进行填充，这个过程可能需要数周、数月甚至数年。虽然数字修复工具已经出现，可以快速生成画作的虚拟修复版本，但这些数字成果无法直接应用到物理原作上。

MIT 机械工程系的研究生 Alex Kachkine 开发的新方法弥补了这一鸿沟。他的技术流程大致是：首先对画作进行传统清洁，去除旧的修复痕迹。然后扫描清洁后的画作，利用现有的 AI 算法分析扫描图，生成画作原始状态的虚拟修复版本。接着，他开发了软件，根据虚拟修复结果，生成一个需要填充区域的地图以及所需的精确颜色。这个地图被转化为一个物理的、双层掩膜，打印在非常薄的聚合物薄膜上。第一层是彩色图案，第二层是完全相同的图案但用白色打印（用于精确再现颜色）。最后，将这个打印好的掩膜小心地对准并粘贴到画作上，使用一层薄薄的传统清漆作为粘合剂。

这项技术的关键在于，这个掩膜是可移除的，可以使用文物保护级别的溶剂轻松溶解，以便未来的修复师查看原始状态或进行新的修复。此外，掩膜的数字文件也被保存下来，为画作的修复历史提供了前所未有的清晰记录。

文章提到，在一幅受损严重的15世纪油画上进行的演示中，该方法自动识别了5612个需要修复的区域，使用了57314种不同的颜色进行填充。整个过程，从扫描到应用掩膜，仅耗时3.5小时，据估计比传统方法快了约66倍。

研究人员也承认，这项技术的使用涉及伦理问题，需要与专业的文物保护师合作，确保修复结果符合艺术家的风格和意图。他们希望这项技术能让大量目前因损坏而无法展出的艺术品重见天日。

社区观点：技术创新与艺术哲思

社区对这项技术表现出了浓厚的兴趣，同时也引发了关于艺术修复本质和 AI 角色的多角度讨论。

一些观点对这项技术的可逆性和数字记录表示赞赏。他们认为，与过去一些不可逆甚至破坏性的修复尝试（比如有人提到西斯廷教堂天顶画的修复争议和臭名昭著的“Ecce Homo”修复失败案例）相比，这种方法提供了一个清晰的记录，并且可以移除，大大降低了风险。这被视为一个重要的进步。

然而，也有不少观点对文章中**“AI”一词的使用**持保留态度。他们认为，这项技术真正的创新点在于物理掩膜的制作和应用流程，以及其可逆性和数字记录的特性，而 AI 可能只是用于辅助识别损坏区域和预测颜色，是整个流程中的一个环节，并非核心突破。有人戏称，现在什么都喜欢加上“AI”来吸引眼球或获取资金，以前可能就直接称为“算法”或“软件”了。

关于技术的局限性，有观点指出，这种方法可能无法处理具有厚重笔触（impasto）的画作，因为薄膜需要贴合表面，而厚涂的纹理会造成问题。此外，该方法主要解决了“填充缺失部分”这一环节，但艺术修复还包括重要的前期清洁和稳定化工作，这些仍然需要人工完成。还有人担心，即使技术完美，在画作表面覆盖一层薄膜是否会改变观赏体验。

讨论也深入到了艺术修复的哲学层面。有观点认为，画作随着时间推移产生的损坏本身也是其历史的一部分，修复是否应该完全抹去这些痕迹？修复师在多大程度上应该“恢复”到艺术家最初的意图，而不是保留作品随时间演变的状态？这种技术能快速修复大量画作固然好，但如果修复面积过大，这幅作品还能被称为“原作”吗？这些都是艺术界长期以来争论不休的问题，这项新技术让这些讨论变得更加紧迫。

此外，社区还出现了一些有趣的旁枝讨论，比如有人开玩笑说希望 AI 不会生成有七根手指的图像（这是当前 AI 图像生成的一个常见问题，尽管与本文的修复 AI 应用场景不同），这反映了社区对 AI 当前能力的普遍认知和担忧。也有人建议将这项技术应用于老照片的修复。

总的来说，这项来自 MIT 的 AI 辅助画作修复技术，以其惊人的速度和可逆性，为艺术保护领域带来了新的可能性。它不仅展示了技术如何赋能传统行业，也引发了关于 AI 在创意领域的角色、修复的伦理界限以及艺术品本质的深刻思考。

使用 OpenTelemetry 为 GitHub CI/CD 提供可观测性：一步步指南

今天的 Hacker News 播客，我们来聊聊如何提升 CI/CD 流水线的可见性。文章标题是《使用 OpenTelemetry 为 GitHub CI/CD 提供可观测性：一步步指南》。

文章开篇指出，在快节奏的 CI/CD 世界里，理解流水线的性能和行为至关重要。GitHub Actions 是流行的自动化选择，但调试不稳定或长时间运行的工作流却非常困难，通常只能依赖构建日志、时间数据或猜测。作者提出，如果能像追踪应用服务一样，一步步追踪流水线运行，或者获得工作流随时间变化的性能指标，那将非常有帮助。这就是 OpenTelemetry (OTel) 发挥作用的地方。

文章详细阐述了使用 OpenTelemetry 观测 CI/CD 流水线的好处：首先是端到端可见性，可以追踪工作流从触发到完成的整个生命周期，可视化每个作业和步骤的执行和交互。其次是性能优化，通过测量作业和步骤的持续时间，识别流水线中的瓶颈，比如漫长的测试阶段或缓慢的依赖安装。再者是错误检测和调试，追踪可以精确指出工作流失败或出现异常路径的位置，简化调试过程。最后是依赖分析，在复杂的工作流中，追踪有助于理解不同作业和步骤之间的关系。

文章强调，与传统的日志导出或特定 CI 分析工具不同，OpenTelemetry 提供了一个统一的方法，可以同时捕获追踪（用于结构和时序）和指标（用于定量监控）。每个流水线运行都可以成为一个追踪，关键绩效指标（KPIs）可以作为指标发出。

文章的核心内容是手把手教你如何通过 OpenTelemetry Collector 的 GitHub Receiver 来实现这一目标。这个 Receiver 可以通过 GitHub Webhook 接收 workflow_run 和 workflow_job 事件并转换为追踪数据，同时也可以通过 GitHub API 抓取仓库和工作流相关的指标，比如仓库大小、星标数、PR 数量、问题数、贡献者统计等。

具体的设置步骤包括：

在 GitHub 仓库或组织设置 Webhook，配置发送 workflow_run 和 workflow_job 事件到 Collector 的指定端点，并设置 Secret。
安装或更新支持 GitHub Receiver 的 otelcol-contrib 版本的 OpenTelemetry Collector。
配置 Collector 的 YAML 文件，在 receivers 部分添加 github 配置，包括 Webhook 监听地址、路径和 Secret 引用。
在 github receiver 配置中添加 scrapers 部分，指定要抓取的 GitHub 组织和指标，并配置认证方式。
添加一个 processor 来为 telemetry 数据打上 service.name 标签，方便后续查询和分组。
添加一个 extension 来配置 GitHub API 请求的认证，通常使用 Personal Access Token (PAT)。
在 service 部分的 pipelines 中，将 github receiver 添加到 traces 和 metrics 管道，并配置 exporter（例如 OTLP exporter 发送到后端）。
运行 Collector，通过环境变量提供 GitHub Webhook Secret 和 PAT。
将 Collector 配置为将数据发送到选择的后端（文章以 SigNoz 为例）。
在后端平台查看和可视化接收到的追踪和指标数据。

文章最后总结，CI/CD 流水线作为软件交付的核心，理应获得与生产系统同等的可见性，OpenTelemetry 让这一点变得更加容易。

社区观点：OTel 的应用与生态对比

社区围绕文章主题展开了热烈讨论，观点多样：

关于 OpenTelemetry 本身及其应用场景： 有观点询问 OTel 是否适用于长时间运行的批处理/异步进程。有回复说可以使用 SpanLinks 来分析异步进程。也有用户分享了尝试追踪跨多个队列的事务失败的经历，最终选择回退到发布自定义指标。一位观点将 OTel 追踪比作“花哨的日志系统”，认为其核心在于通过 Span ID 关联事件，持续时间长短并不影响原理。但也有人反驳说，对于指标而言，OTel 涉及数据聚合，并非简单的日志记录；而且将追踪比作日志可能会误导，特别是考虑到追踪系统在处理 Span 顺序和丢弃数据时的行为。关于 Span 的工作方式，有澄清 Span 是在完成时发出的离散事件，包含持续时间和时间戳字段，而不是独立的“开始”和“结束”消息。这引出了关于如果 Span 未能成功发出（例如超时）或数据在收集过程中丢失时，追踪系统如何处理的讨论。

与其他可观测性工具的比较： 社区自然地将 OTel 与其他工具进行了比较。有人问它是否比 Honeycomb 更好，得到的回答是“更好”取决于具体指标，但开源（如 SigNoz 的 Apache 2 许可）在某些情况下是优势。Honeycomb 的 Refinery（尾部采样代理）和 GritQL（代码查询语言）也被提及作为有趣的开源项目。关于 Sentry，有观点认为它主要是一个错误报告工具（虽然也包含追踪和日志），而非全面的可观测性平台，可能不足以满足所有 OTel 提供的功能，且存在厂商锁定的担忧。对于 AWS 用户，有观点认为 CloudWatch 在基础设施层面拥有更多原生数据，可能更简单直接。但也有人指出 CloudWatch 在其他方面可能“痛苦”，并提到 SigNoz 提供了 AWS 集成。同时，有观点强调 OTel 的优势在于应用层面的自动插桩（Node.js, Python, Java, .NET 等），能提供更丰富的应用内部细节，并能跨服务关联追踪，这在调试分布式系统时非常有价值。除了 SigNoz，Uptrace 和 OpenObserve 也被提及作为接受 OTel 数据的开源后端。Jaeger Collector 也是一个选项，但 UI 可能不如 SigNoz 集成度高。还有观点提到了基于 eBPF 的工具（Pixie, Coroot, Parca, Sysdig）作为另一种强大的基础设施可观测性手段。

关于文章本身和 CI/CD 可观测性： 有人认为将 OTel 应用于 CI/CD 是一个“天才的想法”，“事后看来如此显而易见”。也有观点指出文章标题“CI/CD observability”不够精确，因为它特指 GitHub CI/CD，对其他 CI/CD 系统（如 Jenkins）可能不直接适用（尽管 OTel 原理可迁移）。关于 SigNoz，有用户提到了 UI 上的一些小 bug，SigNoz 维护者也参与了讨论，澄清了其开源核心的付费功能。

关于可观测性实践： 社区还讨论了从日志还是指标进行告警的问题。普遍观点是优先从指标告警，因为日志内容容易被无意或有意地修改，导致告警失效。但也有人指出指标同样可能改变，关键在于对用于告警的日志或指标进行测试，确保其持续有效。

总的来说，社区对文章提出的 GitHub Actions 可观测性方案表示了兴趣，并将其置于更广泛的可观测性生态和实践中进行讨论，涵盖了 OTel 的优缺点、与其他工具的对比、在不同场景（如长任务）下的适用性以及一些实际操作中可能遇到的挑战。

攻破我的安全作业

今天我们来看一篇来自 akpain.net 的文章，标题是《Breaking My Security Assignments》。这篇文章讲述了一位大学计算机科学专业的学生，如何在他们的安全课程中，通过一种意想不到的方式“攻破”了课程作业的提交系统。

文章的作者 abi abi 介绍说，他们课程的安全模块作业是通过一个预配置的虚拟机来完成的。每次新的作业发布，学生会收到一个更新文件，在虚拟机里运行一个叫做 installUpdate 的程序来安装。完成作业后，需要获取一个类似 CTF（Capture The Flag）风格的 token 进行提交。作者注意到，如果没有这个更新文件，虚拟机里就没有作业的痕迹，这说明更新文件里肯定包含了作业内容和生成 token 的关键信息。于是，作者决定尝试不通过正常做题，而是直接从更新文件中提取 token。

作者首先分析了虚拟机里的 installUpdate 程序。通过运行 strings 命令，作者立刻发现了关键信息：这个程序调用了 gpg 命令来解密更新文件，并且指定了 --homedir /root/.gnupg 和 --passphrase-file /root/.vmPassphrase 参数。这表明更新文件是 GPG 加密的，解密所需的密钥和密码存储在虚拟机的 /root 目录下。

问题是，学生在虚拟机里没有 root 权限，无法直接访问 /root。但作者意识到，虚拟机本身是运行在自己的电脑上的，他可以访问虚拟机的磁盘镜像文件。作者使用的是 QEMU 运行虚拟机，他利用 Linux 的工具将虚拟机的磁盘镜像挂载到本地文件系统，然后以 root 权限访问并复制了虚拟机的 /root 目录内容，包括 .gnupg 目录和 .vmPassphrase 文件。

有了这些文件，作者就可以在自己的电脑上使用 gpg 命令，配合从虚拟机里拿到的密钥和密码，成功解密了作业的更新文件。解密后的文件是一个 tarball，解压后发现里面包含了几个目录，其中最重要的是 bin 和 java。

深入查看这些文件，作者发现 bin 目录里有一个 updateVM 脚本，它是更新的入口点。而 java 目录里包含了 Java 源代码，通常有两个文件：一个是以 GenTokenEx*.java 命名的文件，负责生成 token，另一个是 Keys.java。作者惊讶地发现，课程方竟然直接提供了 Java 源代码，而不是编译好的 .class 文件，这大大降低了逆向工程的难度。

通过阅读 Java 源代码，作者理解了 token 的生成逻辑：程序会生成一个随机字符串，取前 11 位，然后与一个表示作业和练习编号的字符串（例如 Ex21 代表第二份作业的第一个练习）拼接起来，形成一个 15 个字符的字符串。最后，这个字符串使用 Keys.java 中包含的“模块密钥”进行 AES 加密。加密后的结果经过十六进制编码就是最终的 token。

掌握了 token 的生成原理和所需的密钥，作者只需要修改一下 Java 源代码，加入几行代码直接调用 genToken 函数并打印结果，就可以轻松生成任何作业的 token。作者提到，通过这种方式，他仅用了 45 分钟就“完成”了一个原本需要 4 小时才能完成的复杂作业，并且是第一个提交 token 的学生。

关于如何防止这种攻击，作者指出根本原因在于学生可以完全控制虚拟机磁盘镜像。如果课程方想要阻止这种行为，更安全的方式是为每个学生提供远程托管的虚拟机，并通过 SSH 等方式限制访问，这样学生就无法直接访问底层磁盘。作者在文章的未来评论中补充说，课程方后来确实改用了这种方式。

最后，作者反思说，虽然这种方法可以轻松获取 token，但这只是一个“无意义的练习”。因为课程的目的是学习知识，如果仅仅通过这种方式作弊，最终受害的是自己，会在期末考试中暴露不足，并且缺乏未来可能需要的实际技能。

社区观点：安全思维与学习的价值

这篇有趣的文章在社区引发了一些讨论。

社区首先对作者能够攻破课程环境表示赞赏，认为这本身就体现了安全课程所期望的思维方式。许多人同意作者的观点，即核心漏洞在于学生对虚拟机磁盘的完全控制。正如一些观点所说，通过虚拟机和混淆（如加密）来提供安全，其强度远不如网络边界和硬件保护。加密本身是自欺欺人的，因为密钥就存储在受攻击者控制的环境中。如果密钥是每次从服务器临时获取，并且与作业的完成状态相关联，那将难得多。

关于作者在文章末尾的矛盾说法——一方面说这种攻击表明自己已经超出了这个入门级模块的目标受众，另一方面又强调做作业的重要性——有观点提出了疑问。作者本人回复解释说，他确实已经具备了课程期望的安全思维，但这不代表课程就没有东西可教。他提到了课程中关于 setuid 位利用、密码学和基础二进制逆向工程等内容，这些是他之前没有深入接触过的。他认为，在技术领域，总有更多细节可以探索和学习，即使是在熟悉的方向也是如此。也有观点认为，理解概念和在考试压力下快速回忆并应用是不同的，做作业有助于巩固知识以应对考试。

有观点认为，如果在一个安全课程中通过“黑掉”系统来完成作业，这恰恰是“做对了”。他希望作者能因此获得高分，并引用了相关的 xkcd 漫画。另一位观点补充说，幸运的是作者攻击的是课程老师设计的系统，而不是大学的 IT 基础设施，后者可能会以学术不端处理。作者证实，老师对此反应非常积极，甚至邀请他去办公室讨论他是如何做到的以及如何改进系统，老师似乎甚至希望有人能去尝试攻击实现本身。

还有观点对课程方为何提供 Java 源代码而不是编译好的二进制文件感到不解。作者在文章脚注中已经提到，他对此也感到惊讶，猜测可能是课程团队为了尽快推出模块，没有花更多精力在代码混淆上。

总的来说，社区对作者的技术能力和诚实的分享表示赞赏，认为这是一个很好的案例，说明了在设计安全系统时，必须考虑攻击者对环境的控制程度。同时，大家也认同作者关于学习本身价值的观点，即理解原理比仅仅获得结果更重要。

如何修改 Starlink Mini，使其无需内置 Wi-Fi 路由器即可运行

好的，各位听众，今天我们要聊的是一篇来自 Oleg Kutkov 个人博客的文章，标题是《如何修改 Starlink Mini，使其无需内置 Wi-Fi 路由器即可运行》。

文章主题概括

这篇文章的核心在于对 Starlink Mini 终端进行硬件层面的改造。我们知道，Starlink Mini 设计上是一个紧凑的一体化设备，集成了 Wi-Fi 路由器。但作者 Oleg Kutkov 探讨并实践了如何物理移除这个内置的 Wi-Fi 路由器板，让 Starlink Mini 仅通过以太网接口工作。这显然是针对那些有特殊需求的高级用户、定制网络设置、嵌入式应用或对功耗、重量有严格限制的场景。

文章重点内容阐述

作者详细介绍了改造过程。首先是拆解 Starlink Mini，这需要耐心和合适的工具，比如金属和塑料撬棒。他特别强调，在拆解过程中，绝对不要移除主 PCB 板上的金属板。这个金属板不仅是重要的散热器，也是电磁干扰（EMI）屏蔽罩。Starlink 的 CPU 运行时会产生大量热量，没有散热片会导致降频甚至过热关机；同时，主板产生的 EMI 也很强，金属板通过导电胶与主板连接，提供有效的屏蔽，移除它可能导致设备干扰附近电子设备。

文章接着分析了主板和路由器板之间的连接器。虽然具体型号未知，但它是 2 毫米间距的板对板连接器。作者给出了连接器的引脚定义，指出主板和路由器之间是通过 1 Gbps 的以太网链路连接的，而且是 PHY-to-PHY 直接连接，没有以太网变压器。文章强调，对于任何定制的外部以太网连接，必须使用以太网变压器进行隔离。

作者提供了一个直接连接以太网的示例电路图，包含了必要的以太网隔离和电源滤波。他提到，Starlink Mini 在 12V 电压下的典型运行电流约为 3A，峰值可达 5A，因此选择合适的电感等元件非常重要。

在网络配置方面，文章解释说，Starlink 终端在未连接卫星时，会通过 DHCP 提供 192.168.100.0/24 网段的 IP 地址，终端本身在 192.168.100.1，提供一个简单的 Web UI 和 gRPC 服务用于监控。连接到 Starlink 网络后，以太网接口会提供一个隧道化的 DHCP 服务，分配来自 Starlink 池的 IP 地址（通常是 CGNAT IPv4 和 IPv6）。此时，客户端将无法直接访问 192.168.100.1。作者提供了一个通过添加静态路由来解决这个问题的 Linux 命令。

最后，文章还提供了一个非常有用的附赠信息：通过 gRPC 获取终端状态时，可能出现的各种“outage”（中断）原因和“disablementCode”（禁用代码），这些代码能帮助用户诊断连接问题或了解账户状态。

作者明确指出，这个修改方法仅适用于 Starlink Mini 1 型号。

社区观点：技术细节与特殊应用场景

社区围绕这篇文章展开了多方面的讨论，既有技术细节的探讨，也有对潜在应用场景的讨论。

技术实现与接口选择：
- 一些观点对 Starlink Mini 在主板和路由器板之间使用“调制过的板对板以太网”而不是更常见的 RGMII 接口表示好奇。
- 有观点认为，使用标准以太网接口可能出于原型开发便利性或不同团队协作的考虑，因为以太网更容易与现成的设备（如笔记本电脑）对接进行测试。
- 另一些观点则指出，RGMII 接口本身并不适合长距离或板对板连接，因为它对信号延迟匹配要求高，且容易产生 EMI 问题，这或许解释了 Starlink 选择 PHY-to-PHY 以太网连接的原因。
- 关于以太网隔离变压器，有观点注意到文章作者在外部连接方案中强调了其必要性，并讨论了为何内部连接可能省略它。
改造动机与潜在应用：
- 许多观点提出了一个直接的问题：Starlink Mini 本身就有以太网口，Wi-Fi 也可以在软件中关闭，为什么还要物理移除路由器？
- 对此，社区给出了几种可能的解释：
  - 彻底消除 Wi-Fi 信号： 即使在软件中关闭，Wi-Fi 芯片在启动时或因固件更新、意外重置等原因仍可能短暂发射信号。在某些敏感应用场景下，任何 Wi-Fi 信号都可能暴露设备位置。
  - 降低功耗： 物理移除 Wi-Fi 模块可以进一步降低设备的整体功耗，尽管软件关闭也能显著降低。
  - 减轻重量和体积： 对于嵌入式或移动平台（如无人机），每一克重量和每一立方厘米体积都很重要。移除不必要的组件可以优化这些参数。
- 结合作者的背景，社区普遍猜测这种改造的主要应用场景是特殊通信需求，特别是用于无人机或前线通信设备等对信号隐蔽性、功耗和重量有严格要求的场景。
其他技术细节：
- 有观点询问了 Starlink Mini 使用的 SoC（System on Chip），有人猜测是 Broadcom，有人则指出是 MediaTek。
- 文章中关于 gRPC 状态码的“彩蛋”被社区认为非常有用，对于需要监控终端状态的用户来说是宝贵信息。

总的来说，这篇文章不仅提供了一个硬核的硬件改造教程，更在社区引发了关于技术选择、实际应用需求以及技术在复杂环境中扮演角色的广泛讨论。

Text-to-LoRA：生成任务特定 LLM 适配器（LoRA）的超网络

今天我们要聊的是 Hacker News 上一个引起关注的项目：Text-to-LoRA。

这篇文章的核心主题是介绍一种新的方法，利用一个“超网络”（Hypernetwork）来根据文本描述自动生成针对特定任务的 LLM 适配器，也就是 LoRA（Low-Rank Adaptation）模型。

具体来说，这项技术旨在解决为不同下游任务微调大型语言模型（LLMs）的效率问题。传统的做法是针对每个任务收集数据并训练一个 LoRA 适配器。而 Text-to-LoRA 的创新之处在于，它训练了一个能够接收任务的文本描述作为输入，并直接输出一个相应的 LoRA 适配器的模型。这意味着开发者或用户可以通过简单的文本提示，比如“生成一个擅长写诗的 LoRA”，或者“生成一个能进行法律文本摘要的 LoRA”，来快速获得一个定制化的模型适配器，而无需进行传统的数据收集和训练过程。这极大地降低了为特定任务定制 LLM 的门槛和成本，有望实现更灵活、更即时的模型适应。

社区观点：LLM 定制的新范式

社区的讨论。首先有人分享了项目对应的论文链接，方便大家深入了解技术细节。也有观点提到了类似的工作，比如将这种适配器生成思想应用于视觉语言模型（VLMs），这表明了这种“生成适配器”的范式可能具有更广泛的应用前景。

关于 LoRA 本身的技术实现，有观点指出 LoRA 适配器会修改模型的内部权重，但也有人补充说，这种修改通常是以外部矩阵的形式存在，只有在明确进行“合并”（merge）操作后，才会真正改变原始模型的权重，而合并主要是为了推理速度优化，并非使用 LoRA 的必要条件。这澄清了 LoRA 如何与基础模型交互的技术细节。

此外，有用户好奇地提出，Text-to-LoRA 是否可以作为“前缀缓存”（prefix caching）的一种替代方案。前缀缓存是另一种优化 LLM 推理的技术，用于加速处理具有相同前缀的输入序列。将 Text-to-LoRA 与这类技术进行比较，反映了社区在探索不同 LLM 优化和定制策略时的思考方向。

总的来说，Text-to-LoRA 代表了 LLM 定制领域的一个有趣进展，它试图通过自动化适配器的生成过程，让模型更容易适应多样化的任务需求。社区的讨论则围绕其技术细节、相关研究以及与其他现有技术的比较展开，展现了对这一创新方法的关注和探讨。