每日HackerNews RSS
多年以来，软件工程师很少为自己编写定制工具，因为维护成本往往高于其实用价值。我们不得不依赖死板的现成软件，仅能通过插件或配置文件进行表面的修改。 如今，AI 智能体从根本上改变了这种投资回报率。通过让智能体访问应用程序的源代码，你可以通过简单的自然语言提示来个性化软件，而无需学习复杂的代码库或局限于有限的 API。智能体可以承担繁重的编码工作，更关键的是，它能自动处理将本地更改与上游更新进行合并（rebase）的持续维护工作。 这一转变标志着“插件时代”的终结。开发者不再是为大众构建通用的、高度可配置的软件，我们正在进入一个用户可以根据自身需求塑造开源软件的时代。如果某个工具的使用方式不符合你的心意，你只需告诉智能体重写它即可。因此，软件及其开发公司必须转型为完全可个性化，才能保持竞争力。归根结底，在新范式下，为了让软件真正发挥作用，其源代码必须是可获取的；缺乏深度个性化钩子的闭源工具正逐渐走向淘汰。
这篇 Hacker News 讨论帖探讨了大型语言模型（LLM）与开源软件（OSS）之间不断演变的关系。
**核心主题包括：**
* **“个性化”范式：** 开发者认为，LLM 显著降低了“阅读和修改”代码的门槛。用户无需依赖僵化的插件系统，也不必等待上游维护者更新，现在可以使用 AI 代理来派生（fork）、理解并根据个人需求定制软件。
* **维护之争：** 批评者认为，通过“感觉编程”（vibe-coding）创建个人分支会带来不可持续的维护负担。许多人认为通过每日定时任务自动将自定义分支与上游代码库进行合并（rebase）是“安全和稳定性噩梦”，而另一些人则将其视为一种赋能且可控的工作流。
* **商业模式担忧：** 讨论帖强调了开源精神与开发者工具经济现实之间的张力。一些贡献者担心，AI 代理可能促成“版权洗白”，即 AI 模型或商业竞争对手可以轻松复制并“产品化”开源成果，从而可能挫伤创作者的积极性。
* **工具的未来：** 尽管有些人认为经 AI 个性化定制的软件是个人计算的未来，但另一些人坚持认为，对于生产级软件和协作环境而言，模块化、标准配置文件及专业支持仍然更具优势。
在 1989 年《GAMEST》杂志的一篇专栏文章中，《泡泡龙》的传奇设计师福谷孝（Fukio “MTJ” Mitsuji）曾警告游戏行业，切勿沉迷于那些追求盈利、流于表面的抄袭之作。MTJ 通过虚构的“抄袭机器人”（Rip-O-Bot）讽刺了这种趋势——这台机器能通过混搭现有资源，瞬间生成衍生游戏。他曾断言，随着技术进步和模仿变得易如反掌，游戏行业将充斥着克隆作品，设计师也将面临被取代的风险。
MTJ 极具前瞻性的观点是：如果机器可以处理技术上的“样板”工作和模仿，那么人类设计师剩下的唯一真正武器就是“原创性”。他向读者提出挑战，呼吁他们超越单纯的模仿，将自己的“头脑与心灵”注入只有人类才能构思出的机制、系统和创意之中。
几十年后的今天，生成式人工智能已然实现了 MTJ 当年对“抄袭机器人”的预言，他的警告对于开发者而言依然是一份至关重要的宣言。在这样一个点击按钮即可制作出合格仿制游戏的时代，创作者面临的核心挑战已不再是技术执行，而是对那些真正定义杰作的独特、创新理念的追求。
这篇 Hacker News 的讨论回顾了一篇 1989 年题为《The Rip-O-Bot》的文章，文中探讨了视频游戏衍生品的自动化创作。
参与者就游戏行业是否实现了这一预测展开了辩论。有人认为，90 年代充斥着衍生类的横版过关游戏，但由于玩法和设计上的细微差异提供了独特的体验，消费者对此依然感到满意。另一些人则认为，尽管游戏史上出现过“粗制滥造”或重复克隆游戏的浪潮，但高质量的作品往往能脱颖而出，从而维持了生态系统的健康。
讨论随后转向了现代人工智能和快速原型设计的影响。虽然有人认为这些工具促进了创新，但怀疑论者认为开发门槛早已大幅降低。他们主张，该行业真正的挑战不在于技术限制，而在于低质量作品的过度饱和，以及在拥挤的市场中脱颖而出的难度。最终，各方达成共识：尽管技术加速了开发进程，但核心概念的质量仍然是决定游戏能否成功的关键因素。
在我们的系统中寻找“僵尸”：一个关于 CPU 瓶颈的真实故事 Finding zombies in our systems: A real-world story of CPU bottlenecks
5 天前
请启用 JavaScript 和 cookie 以继续。
这篇 Hacker News 讨论帖围绕 Pinterest 的一篇工程技术博客展开，记录了他们发现并解决一个长期存在的 CPU 瓶颈问题的过程。技术讨论的焦点在于“僵尸”进程和意外的系统开销，并强调了工程团队如何通过参考现有的社区文档找到了根本原因。
评论者分析了此次修复的技术影响，质疑 Linux 调度器为何允许单个忙碌的核心阻塞整个 96 核系统的网络线程。其他用户则讨论了 ECS（弹性容器服务）代理的架构及其在集群管理中的作用。
除了技术调查，讨论还触及了“数字公地”的广泛价值，指出共享的工程经验是至关重要的知识库。讨论最后简要提及了 Pinterest 对机器学习的使用，明确了该公司庞大的计算资源消耗主要源于核心推荐算法和相似性搜索算法，而非现代生成式 AI 模型。
SPF (发件人策略框架) 是一种基于 DNS 的电子邮件验证协议，定义在 **RFC 7208** 中。SPF 记录是一条 `v=spf1` 的 TXT 记录，用于授权特定的 IP 地址和服务器代表该域名发送电子邮件。 ### 核心规则 * **结构：** 记录由版本标签 (`v=spf1`)、机制 (如 `ip4`、`include`、`mx`) 和修饰符 (`redirect`、`exp`) 组成。 * **评估：** 记录从**左到右**进行评估。匹配到第一项即停止，并由关联的限定符决定结果 (例如 `-` 表示失败，`~` 表示软失败)。 * **限制：** DNS 查询次数限制为 **10 次** (针对 `include`、`a`、`mx`、`ptr`、`exists` 和 `redirect`)，且**无效查询**不得超过两次。超过此限制将触发 `PermError` (永久错误)。 * **约束：** 每个域名只能发布 **一条** SPF 记录。超过 255 个字符的记录必须拆分为同一 TXT 记录内的多个字符串，由接收方进行拼接。 ### 最佳实践 * **避免使用 `ptr`：** 该机制已被弃用且不可靠。 * **` -all` 与 `~all` 的选择：** 如果同时使用 DMARC 和 DKIM，建议使用 `-all` (硬失败)；在初始设置阶段，建议使用 `~all` (软失败)。 * **验证：** 请务必使用在线 SPF 检测工具核对记录，以确保语法正确且符合查询次数限制。
此 Hacker News 讨论帖探讨了一份关于 SPF (Sender Policy Framework) 记录语法的指南。讨论强调了有关电子邮件验证的几个关键点：
* **遗留设计：** 一位大规模 SPF 记录的原始创建者指出，尽管该格式在 20 年后基本没有变化，但其设计初衷是为了灵活性，尽管在“include”语句解析方面存在挑战。
* **与现代标准的比较：** 用户普遍更喜欢 SPF 的简单性，而不是像 MTA-STS 那样复杂的协议，他们批评后者引入了对 Web 服务器基础设施不必要的依赖。
* **运营挑战：** 管理 SPF “扁平化”被认为是一个痛点，并建议使用 DNSControl 等自动化工具。参与者还对那些要求在 SPF 记录中使用臃肿的“include”语句作为服务先决条件的 SaaS 提供商表示不满。
* **内容真实性：** 评论者辩论了所链接参考文档的质量，指出其很可能是由人工智能生成的。许多人建议，寻求权威信息的用户应直接参考原始的 RFC 7208 文档。
本文介绍了“分解子域随机游走”（Walks on Decomposed Subdomains，简称 WoDS），这是一种用于求解拉普拉斯方程等椭圆型偏微分方程（PDE）的混合数值方法。
传统的基于网格的方法（如有限元法）虽效率高，但因网格生成困难，难以处理复杂几何形状。相反，诸如“球内随机游走”（Walk on Spheres，简称 WoS）等无网格蒙特卡洛方法虽能轻松应对复杂边界，却存在方差大、收敛慢的问题。
作者提出了一种“分而治之”的策略来调和上述两种方法。该算法无需网格，通过将域分解为较小的子域（瓦片），实现了以下步骤：
1. **估计局部算子**：利用简短且可并行化的蒙特卡洛游走为每个瓦片进行估计。
2. **耦合瓦片**：将瓦片整合为吸收马尔可夫链，仅将瓦片间的接口作为未知量。
3. **求解系统**：通过单一的确定性稀疏线性求解器求解，消除了纯蒙特卡洛方法的噪声和收敛缓慢问题。
这种混合方法既保留了随机游走在几何处理上的灵活性，又利用了确定性求解器的高精度与快速收敛性。它为模拟复杂系统提供了一种可扩展且稳健的替代方案，呼应了计算机图形学中混合渲染技术的成功演进。
抱歉。
MiniMax 发布了其第三代视频模型 **H3**，现已开放权重并支持在 ComfyUI 中原生运行。 H3 是一款强大的多模态模型，能够生成长达 15 秒、分辨率为 2K 并自带立体声的视频片段。它在跨模态任务方面表现出色，允许用户结合文本、图像、视频和音频来控制主体、动作和风格。主要特点包括： * **多功能输入：** 支持文生视频、图生视频、首尾帧控制以及基于参考的动作迁移。 * **集成音频：** 音频与视频同步生成，而非后期添加。 * **性能优化：** 通过权重剪枝、量化和自定义内核，内存占用减少了 66%。这使得模型能够在消费级硬件（如 RTX 3060）上运行，仅需 42.5 GB 显存。 如需开始使用，请将 ComfyUI 更新至 0.30.0 版本，从 Hugging Face 下载 H3 权重，并使用提供的工作流进行创作。此次发布标志着高保真 AI 视频生产在易用性方面迈出了重要一步。
MiniMax H3 在 ComfyUI 的发布是开源视频生成领域的一个重要里程碑，它使用户能够在本地硬件上实现高质量、原生音频集成的 2K 视频制作。
关键技术讨论包括：
* **优化：** 用户正在探索节省内存的技术，例如用查找表（Lookup Tables）代替调制权重——这是一种针对扩散模型的无损方法——以减少内存占用。
* **性能：** 虽然生成速度因硬件而异（据报道从几秒到几分钟不等），但诸如 SageAttention 和 EasyCache 等社区优化方案已经提高了吞吐量。
* **效用与伦理：** 社区对其影响看法不一。爱好者们称赞其在快速原型设计、分镜制作以及实现高端电影制作民主化方面的潜力，但批评者认为其美学风格仍然“平淡”或“同质化”，并对版权和创意劳动力被替代表示担忧。
* **未来展望：** 尽管存在提示词遵循能力和潜在监管挑战等技术障碍，但此次发布被视为一个主要的竞争对手，对闭源基础模型形成了价格压力。用户强调，随着技术的发展，在人工智能生成内容日益饱和的环境下，人类的“审美”、创意编排和原创愿景依然至关重要。
二十多年来，纽芬兰圣玛丽镇一直被90万升废弃鱼露散发的恶臭所困扰。2001年一项商业投资失败后，大量腐烂的多春鱼被遗弃在发酵罐中，迫使当地居民不得不封死门窗以抵御那股弥漫的臭味。 经过多年的努力，一项耗资200万美元的清理工程终于在本周启动。工人们正在抽走这些粘稠的污泥，将其与泥炭藓混合，并密封在有衬里的垃圾填埋场中。 尽管这对当地社区来说是一场噩梦，但对食品科学家而言，这却是一个独特的科研对象。化学家布莱恩·郭·勒（Bryan Quoc Le）指出，虽然这种混合物可能主要由挥发性、腐臭的胺类物质和脂肪酸降解产物组成，但从理论上讲，极长时间的发酵可能会产生浓郁而复杂的鲜味特征。尽管该混合物目前被视为危险废物而非调味品，但专家们对这些大罐中发生的“禁忌”化学反应进行了推测。然而，对于圣玛丽镇的居民来说，该项目将于10月完工，这意味着他们社区作为臭名昭著的“酱料厂”所在地，终于可以摆脱这一名声。
纽芬兰圣玛丽的一家废弃鱼露工厂在经历了二十年的法律和官僚僵局后，终于开始清理工作。该工厂在与加拿大食品检验局（CFIA）发生冲突后停止运营，留下了约 90 万升发酵鱼露。
清理工作引发了巨大争议。由于鱼露盐分极高，且对海洋生物具有“剧毒”，当局拒绝了倾倒进海洋或进行传统堆肥等简易处置方法。最终，这些废料在公共资金的支持下，被与泥炭藓混合后埋入垃圾填埋场。
评论者的讨论突显了官僚谨慎与务实（尽管有臭味）解决方案之间的张力。许多参与者批评政府的做法是“浪费公款”，认为海洋作为鱼类的自然环境，本可以通过稀释作用吸收这些废料。另一些人则探讨了鲜味（谷氨酸钠，即味精）的化学性质，并讨论了监管机构在管理此类恶臭产业中的历史角色。归根结底，该地点仍是一个鲜明的例证，反映了监管不力和复杂的法律斗争如何最终导致代价高昂、由纳税人埋单的长期环境清理工作。
AirLLM 是一个功能强大的库，能够让用户在消费级硬件上以极低的显存占用运行超大规模语言模型（LLM）。通过逐层（或在稀疏 MoE 模型中逐专家）处理模型，它消除了对传统量化、剪枝或蒸馏的依赖。
主要功能包括：
* **极致高效**：在单块显卡上运行超大模型，例如在约 12GB 显存上运行 DeepSeek-V3 (671B)，或在 8GB 显存上运行 Llama 3.1 (405B)。
* **广泛兼容**：通过简单的 `AutoModel` 接口，支持几乎所有主流架构，包括 Llama、Qwen、DeepSeek、Mistral 等。
* **卓越性能**：提供可选的块级 4-bit/8-bit 量化功能，在几乎不影响准确性的前提下，可将推理速度提升至原来的 3 倍。
* **简单易用**：只需提供 Hugging Face 的仓库 ID 即可初始化，AirLLM 会自动处理模型拆解。
虽然初始设置需要足够的磁盘空间用于模型分层拆解，但 AirLLM 为爱好者和研究人员提供了一种实用的“开箱即用”解决方案，使其能够在包括 Apple Silicon 在内的常用硬件上运行顶尖的 AI 模型。
关于“AirLLM”（一个允许在4GB显存的GPU上进行70B参数模型推理的项目）的Hacker News讨论，凸显了令人印象深刻的工程技术与其实际用途之间的巨大鸿沟。
用户指出，虽然该项目能在资源极其受限的硬件上运行大型模型，但性能极其缓慢——通常是以“每秒生成的Token数”来衡量，而不是“每个Token生成的秒数”。批评者认为，极高的延迟使得实时交互变得不可能，有人甚至表示完成简单的任务可能需要数天或数周的时间。
讨论随后演变为一场更广泛的辩论，内容包括：
* **应用场景：** 一些开发者认为，对于可以彻夜运行的批处理任务（如代码重构或数据分析），该技术能节省云端算力成本，具有一定价值。
* **技术质疑：** 许多人将其与 `llama.cpp` 或量化等现有解决方案进行对比，认为其效果不佳，并质疑逐层流式传输（layer-by-layer streaming）是否真能带来性能优势。
* **“Vibe Coding”趋势：** 评论者对“Vibe-coded”项目（通常缺乏文档或维护）的激增表示担忧，并争论这种碎片化的开源生态是否优于依赖集中的企业级API。
最终，尽管参与者对这一壮举背后的独创性表示赞赏，但大多数人认为，它目前更多是一种技术好奇心，而非可落地的生产工具。
本次 9front 发布带来了多项显著增强和工具，其中最重要的是在多个程序中采用了一套经过修订的 **affinewarp API**，以提升缩放效果。
**主要新特性：**
* **gdbfs(4)：** 一个可以将远程 GDB 实例挂载为 `/proc` 文件系统的新工具。
* **驱动程序：** 增加了对 Synaptics 触摸板的支持，以及用于 UPS 设备的 `nusb/battery` 驱动。
* **实用工具：** 用于 USB 描述符分析的 `nusb/dump`，以及一套全新的 `awk` 测试套件。
* **安全性：** `libsec` 现已支持 SHA3。
* **内核：** 在 `pc/pc64` 架构上增加了对 `x2apic` 的支持。
**系统改进：**
本次更新对内核、驱动程序（特别是 `devether` 和 `ether82563`）以及核心库进行了大量的错误修复和优化。`gefs` 文件系统在易用性和稳定性方面得到了显著改进。Git 工具集也进行了多项工作流优化，包括支持部分提交（`-p`）。
**获取方式：**
提供 PC（ISO）、树莓派、MNT Reform（SD 卡镜像）和 QEMU（QCOW2）的安装介质。下载地址及源代码可通过 9front 官方镜像站和 Git 仓库获取。完整的文档和手册已更新以反映这些变更。
抱歉。