3天前
|
|
|
## 今天 Hacker News 社区聊了啥？ NO.20250830
这期日报内容超丰富！从提升代码可读性的认知负荷，到RISC-V芯片的最新进展，再到AI模型虚拟机的必要性，还有AI编码助手的统一通信标准，简直是干货满满！此外，还有软件设计原则、经典字体选择、注意力机制演变、高性能网络开发套件等精彩内容等你来探索。更有趣的是，还有动森风格信件编辑器，让你重拾童年回忆！别犹豫了，快来一起充电学习吧！
---
## 提升代码可读性：降低认知负荷的重要性
本文探讨了软件开发中一个关键但常被忽视的概念：认知负荷。文章指出，降低认知负荷对于提高代码可读性、减少理解成本至关重要，尤其是在面对大型或不熟悉的项目时。
文章首先定义了认知负荷，即开发者完成任务所需的思考量。当阅读代码时，我们需要将变量的值、控制流逻辑和调用序列等信息加载到大脑的工作记忆中。一旦信息量超过工作记忆的容量（大约四个“块”），理解代码就会变得非常困难。文章将认知负荷分为内在认知负荷（任务本身的难度，无法降低）和外在认知负荷（由信息呈现方式引起，可以大大降低）。作者重点关注如何减少外在认知负荷，并通过具体的代码示例来说明。
文章列举了几个常见的高认知负荷代码模式，并提供了相应的改进建议。例如，复杂的条件语句可以通过引入具有描述性名称的中间变量来简化。嵌套的if语句可以使用早返回（early returns）来避免，从而使代码更易于理解。此外，文章还讨论了继承的滥用以及过多的小方法、小类或小模块的问题。作者提倡使用组合优于继承，并强调了“深模块”（简单接口，复杂功能）的优点，认为隐藏复杂性可以降低认知负荷。深模块拥有强大的功能，但接口却非常简单，例如 Unix I/O 的例子，它只有五个基本调用，但底层实现却非常复杂。
总之，文章强调，编写易于理解的代码需要时刻关注认知负荷，并通过各种技巧来降低它，从而提高开发效率和代码质量。
- 原文: [Cognitive Load is what matters](https://github.com/zakirullin/cognitive-load)
- Hacker News: [https://news.ycombinator.com/item?id=45074248](https://news.ycombinator.com/item?id=45074248)
- 作者: nromiun
- 评分: 111
- 评论数: 33
- 发布时间: 2025-08-30 20:58:48
---
## Condor Cuzco RISC-V 核心亮相 Hot Chips 2025
Condor Computing 在 Hot Chips 2025 上展示了他们的 Cuzco RISC-V 核心，这是一款高性能的设计，旨在与 SiFive 的 P870 和 Veyron 的 V1 等产品竞争。Cuzco 采用宽发射乱序执行，并结合了现代分支预测器和基于时间的调度技术。
Cuzco 是一款 8-wide 乱序核心，拥有 256 项 ROB，目标时钟频率在 TSMC 5nm 工艺上约为 2 GHz (SS) 至 2.5 GHz (TT)。其流水线有 12 个阶段，但考虑到 10 个周期的误预测惩罚，实际流水线长度可能更长。Cuzco 的独特之处在于其后端主要采用静态调度，Condor 称之为“基于时间的”调度方案，旨在降低功耗和复杂性。
Cuzco 的前端配备了复杂的分支预测器，包括 TAGE-SC-L 预测器，该预测器使用多个表来处理不同的历史长度，从而高效地利用分支预测器存储。分支目标缓存由一个 8K 条目的分支目标缓冲区 (BTB) 提供，分为两个级别。指令获取逻辑从一个 64 KB 8 路组相联的指令缓存中获取指令，并通过一个 64 条目的全相联 TLB 加速地址转换。
Cuzco 的重命名和分配阶段是其设计的关键，它不仅执行寄存器重命名和后端资源分配，还预测指令调度。为了实现基于时间的调度，Cuzco 维护了一个时间资源矩阵 (TRM)，该矩阵跟踪未来一段时间内各种资源（如执行端口、功能单元和数据总线）的利用率。TRM 可以查看未来 256 个周期，但 Cuzco 只在预测指令的依赖项准备就绪后的一小段时间内查找可用资源，以控制存储需求。Cuzco 采用了一种新颖的方法，将动态调度的任务转移到重命名/分配阶段，而不是传统的后端调度器，从而简化了后端调度器的设计。
Cuzco 是一款可配置的授权核心，允许客户调整执行切片的数量、L2 TLB 大小、片外总线宽度以及 L2/L3 容量。Condor 还可以调整各种内部核心结构的大小，以满足客户的性能要求。Cuzco 核心可以组成最多 8 个核心的集群，并通过 CHI 总线与系统连接，允许客户使用自己的片上网络 (NoC) 来实现更高的核心数量。
- 原文: [Condor's Cuzco RISC-V Core at Hot Chips 2025](https://chipsandcheese.com/p/condors-cuzco-risc-v-core-at-hot)
- Hacker News: [https://news.ycombinator.com/item?id=45074895](https://news.ycombinator.com/item?id=45074895)
- 作者: rbanffy
- 评分: 14
- 评论数: 0
- 发布时间: 2025-08-30 22:18:41
---
## AI 模型需要虚拟机
本文探讨了将 AI 模型嵌入软件时，将控制软件层视为虚拟机的重要性，并提出标准化 AI 模型嵌入方式的必要性。
文章指出，随着 LLM 能力的演进和 MCP 等扩展机制的出现，调用 LLM 的控制软件的复杂性也在增加。AI 软件系统需要操作系统提供的安全、隔离、可扩展性和可移植性等特性。文章作者借鉴 Java 虚拟机 (JVM) 的思想，认为应该为 AI 编排器创建一个虚拟机规范，从而为 AI 模型创建一个“一次编写，随处运行”的执行环境，同时提供熟悉的约束和治理，以维护现有软件系统中的安全和隐私。
文章将与 AI 模型交互的软件层称为模型虚拟机 (MVM)，MVM 充当模型和外部世界之间的中介。文章列举了现有 AI 模型接口的一些操作，例如：认证、加载、初始化和卸载给定的 AI 模型；使用上下文调用模型；解析模型的输出；认证、加载、初始化和卸载工具；调用工具；解析工具调用的结果；将工具调用的结果存储到内存中；要求用户输入；向历史记忆中添加内容；以及标准控制结构，如条件、排序等。文章认为，VM 应该在一个类型良好的上下文中支持所有这些操作，并在调用的进行、传递的参数等方面设置约束。
文章还讨论了现有工作中涌现出的一些良好接口所需元素，包括 OpenAI 的结构化工具调用协议、Anthropic 的模型上下文协议 (MCP) 以及 FIDES 和 AC4A 等安全编排器。OpenAI 的 JSON 函数调用 API 和插件系统展示了结构化工具调用协议如何减少歧义并简化集成。MCP 旨在成为连接 AI 助手与外部数据和工具的通用接口。FIDES 和 AC4A 等项目展示了标准的 AI VM 如何包含内置的安全和访问控制，就像现代操作系统一样。
尽管如此，文章也强调，即使 VM 规范中构建了强大的访问控制，AI 模型仍然会带来新的安全挑战，需要在设计中加以考虑。例如，即使阻止 AI 模型访问特定的数据项，它也可能利用其链式推理来设计收集可访问数据的方法，从而推断出无法访问的数据项。因此，安全研究人员必须设计新的缓解措施，以防止 AI 模型采取对抗行动，即使受到虚拟机的约束。
- 原文: [AI models need a virtual machine](https://blog.sigplan.org/2025/08/29/ai-models-need-a-virtual-machine/)
- Hacker News: [https://news.ycombinator.com/item?id=45074467](https://news.ycombinator.com/item?id=45074467)
- 作者: azhenley
- 评分: 34
- 评论数: 12
- 发布时间: 2025-08-30 21:25:39
---
## Agent Client Protocol (ACP): 为 AI 编码助手打造统一通信标准
Agent Client Protocol (ACP) 旨在标准化代码编辑器和 AI 编码助手之间的通信，类似于语言服务器协议 (LSP) 对语言服务器集成的作用。通过定义统一的协议，ACP 降低了集成 AI 编码助手的复杂性，并允许开发者在不同的编辑器和助手之间自由选择。
ACP 的核心思想是让用户在编辑器中无缝地使用 AI 助手完成特定任务。AI 助手作为编辑器的子进程运行，并通过 JSON-RPC over stdio 进行通信。协议复用了 MCP 中的 JSON 格式，并针对代码编辑用户体验加入了自定义类型，例如显示差异。默认的文本格式为 Markdown，保证了足够的灵活性，可以展示丰富的格式，而无需编辑器支持 HTML 渲染。
目前，Zed 编辑器和通过 CodeCompanion 插件的 Neovim 已经支持 ACP。支持的 AI 编码助手包括 Gemini，未来还将有更多助手加入。ACP 的目标是建立一个开放的生态系统，让开发者可以轻松地使用各种 AI 编码工具，提高开发效率。
评论区对 ACP 的看法不一。有人担心 ACP 的命名与现有的 Agent Communication Protocol (ACP) 过于相似，容易造成混淆。也有人对 Zed 编辑器积极拥抱 ACP 表示赞赏，认为这有助于打破 AI 编码助手市场的垄断。一些开发者希望 ACP 能够尽快在 VS Code 上得到支持，并期待 Zed 改进其差异视图功能。还有人担心为 AI 定义点击按钮的接口可能会导致潜在的问题。总的来说，社区对 ACP 的发展持观望态度，希望它能够真正解决 AI 编码助手集成的问题，并避免重蹈其他 LLM 标准被迅速抛弃的覆辙。
- 原文: [Agent Client Protocol](https://agentclientprotocol.com/overview/introduction)
- Hacker News: [https://news.ycombinator.com/item?id=45074147](https://news.ycombinator.com/item?id=45074147)
- 作者: vinhnx
- 评分: 85
- 评论数: 19
- 发布时间: 2025-08-30 20:42:30
---
## 软件设计原则：做最简单可行的事情
本文探讨了在软件系统设计中，遵循“做最简单可行的事情”（Do the simplest thing that could possibly work）原则的重要性，并分析了其在bug修复、系统维护和架构设计中的应用。文章挑战了追求“理想”系统的传统观念，提倡深入理解现有系统，并在此基础上选择最简单的解决方案。
文章指出，软件设计需要掌握各种工具，但真正的精髓在于懂得何时少做。优秀的软件设计往往看起来平平无奇，因为它巧妙地隐藏了问题的复杂性。例如，Unicorn和Rails REST API就是通过利用Unix原生特性和提供最基础的CRUD功能，实现了简单而强大的设计。
文章通过一个Golang应用速率限制的例子，说明了如何在实际应用中贯彻这一原则。在考虑使用Redis之前，可以先尝试内存存储或利用边缘代理的速率限制功能。只有在这些简单方案无法满足需求时，才需要引入更复杂的持久化存储方案。
文章还讨论了“做最简单可行的事情”可能存在的问题，例如导致系统缺乏灵活性或形成“泥球”架构。然而，作者认为真正的“hack”并非简单，而是增加了代码库的复杂性。找到合适的解决方案需要深入理解代码库，而最终的方案往往比“hack”更简单。
文章进一步探讨了“简单”的定义，认为简单的系统拥有更少的“活动部件”和更少的内部连接。作者还提出了一个判断标准：简单的系统更稳定。如果一个系统需要持续的维护和调整，那么它可能不够简单。
总而言之，文章强调了在软件设计中，应始终以“做最简单可行的事情”为指导原则，避免过度设计和不必要的复杂性，从而构建出更稳定、更易于维护的系统。
- 原文: [Do the simplest thing that could possibly work](https://www.seangoedecke.com/the-simplest-thing-that-could-possibly-work/)
- Hacker News: [https://news.ycombinator.com/item?id=45068091](https://news.ycombinator.com/item?id=45068091)
- 作者: dondraper36
- 评分: 847
- 评论数: 331
- 发布时间: 2025-08-30 03:05:09
---
## 诺基亚经典字体：用户界面的新选择？
本文探讨了诺基亚经典字体 Nokia Sans 作为用户界面字体的可行性，作者分享了自己使用 Nokia Sans Wide 作为 UI 字体后的体验，并意外发现其在各种尺寸下都非常易读，且具有独特的个性。作者还提到了字体设计师 Erik Spiekermann 曾对诺基亚弃用 Nokia Sans 的决定表示不满，认为 Wide 变体完全可以胜任 UI 字体的任务。
作者在使用高 DPI 显示器和 KDE on Wayland 的环境下，发现 Nokia Sans Wide 表现出色，甚至取代了 Inter 成为他的首选 UI 字体。尽管作者承认这很大程度上是个人喜好问题，但他希望通过分享自己的经历，看看是否有人与他有相同的感受。同时，作者也提醒读者，在 Windows 或 macOS 系统以及低 DPI 显示器上，效果可能会有所不同。此外，文章还简单讨论了下载使用这些字体的法律问题，并表示很想创建一个包含所有 Nokia Sans 变体的 zip 文件，但可能存在版权风险。
评论区对 Nokia Sans 作为 UI 字体的适用性展开了讨论，观点各异。
* **字体设计的专业性：** 有评论指出，UI 字体需要经过特别的 hinting 处理，才能在低像素密度的显示器上表现良好，并且通常具有较高的 x 高度，以便于字符区分。
* **对 Inter 字体的评价：** 有评论认为 Inter 字体过于平淡，缺乏个性，不适合用于 UI 设计。
* **诺基亚在美国的普及程度：** 有评论反驳了文章中“非美国人”的说法，指出诺基亚手机在美国也很流行。
* **与 Fira Sans 的相似性：** 有评论认为 Nokia Sans 与 Fira Sans 有些相似之处，Fira Sans 是一款被低估的 sans serif 字体。
* **Nokia Sans 在 Hildon UI 中的应用：** 有评论指出，Nokia Sans 实际上曾被用作 Nokia 互联网平板电脑 Hildon UI 的字体，效果非常出色。
* **怀旧情怀：** 有评论表示，Nokia Sans 是一款能唤起人们怀旧情怀的字体。
* **与其他字体的相似性：** 有评论认为 Nokia Sans 与 Erik Spiekermann 设计的其他字体（如 Fira Sans 或 Meta Sans）非常相似。
* **网站字体选择的建议：** 有评论认为，文章链接的网站所使用的字体比 Nokia Sans 更适合作为 UI 字体。
总的来说，评论区的讨论涵盖了字体设计的专业性、个人喜好、历史应用以及与其他字体的比较等多个方面，为读者提供了更全面的视角。
- 原文: [Nokia’s legendary font makes for a great user interface font](https://www.osnews.com/story/143222/it-turns-out-nokias-legendary-font-makes-for-a-great-general-user-interface-font/)
- Hacker News: [https://news.ycombinator.com/item?id=45074071](https://news.ycombinator.com/item?id=45074071)
- 作者: rguiscard
- 评分: 98
- 评论数: 41
- 发布时间: 2025-08-30 20:31:43
---
## 从多头到潜在注意力：注意力机制的演变
本文深入探讨了从多头注意力（MHA）到多头潜在注意力（MHLA）等各种注意力机制的演变，重点介绍了它们的核心思想、优势和局限性。文章旨在帮助读者理解这些机制的底层逻辑，以及它们在计算速度、内存使用和可扩展性方面的改进。
文章首先解释了注意力机制的基本概念，即模型在生成每个输出词或 token 时，选择性地关注重要的上下文词。然后，文章详细介绍了多头注意力（MHA）的工作原理，包括 Query、Key 和 Value 向量的计算方式，以及多头并行计算的优势。然而，MHA 的一个主要挑战是，随着上下文的增长，Key 和 Value 向量的数量会急剧增加，导致计算和内存开销呈二次方增长。虽然 KV 缓存可以减少计算和内存开销，但无法降低关注所有先前 token 的根本成本。
为了解决 MHA 的问题，文章介绍了多查询注意力（MQA），它通过在所有 head 之间共享 Key 和 Value 向量来减少内存带宽需求。MQA 只需要计算一次 Key 和 Value 向量，从而降低了 Key/Value 投影的计算成本。此外，MQA 只需要缓存一组 Key-Value 对，从而降低了 KV 缓存的大小。
接下来，文章还可能会介绍分组查询注意力（GQA）等其他注意力机制，进一步探讨它们在计算效率和内存使用方面的改进。
总而言之，这篇文章全面地概述了注意力机制的演变历程，从最初的多头注意力到更高效的多查询注意力，再到其他变体。通过理解这些机制的原理和优缺点，开发者可以更好地选择适合自己任务的注意力机制，并构建更高效、更强大的模型。
（由于文章内容不完整，关于评论区观点和 GQA 的讨论无法进行总结。）
- 原文: [From Multi-Head to Latent Attention: The Evolution of Attention Mechanisms](https://vinithavn.medium.com/from-multi-head-to-latent-attention-the-evolution-of-attention-mechanisms-64e3c0505f24)
- Hacker News: [https://news.ycombinator.com/item?id=45072160](https://news.ycombinator.com/item?id=45072160)
- 作者: mgninad
- 评分: 105
- 评论数: 26
- 发布时间: 2025-08-30 13:45:24
---
## F-Stack：基于 DPDK 的高性能网络开发套件
F-Stack 是一款基于 DPDK 的开源网络框架，旨在解决 Linux 内核在处理高速网卡数据包时存在的性能瓶颈。它通过内核旁路技术，将数据流处理转移到用户空间，从而避免了内核数据包复制、线程调度、系统调用和中断等带来的性能损耗。
F-Stack 移植了 FreeBSD 11.0 的用户空间 TCP/IP 协议栈，提供完整的协议栈功能，并裁剪了大量不相关特性，从而显著提升了性能。它还提供了 Posix API (Socket, Epoll, Kqueue)、编程 SDK (Coroutine) 以及 Nginx、Redis 等应用程序接口，方便开发者快速构建高性能网络应用。
F-Stack 具有以下特点：
* 超高的网络性能，可以实现网卡满载，千万级并发连接，500 万 RPS，100 万 CPS。
* 完整的协议栈功能，移植自 FreeBSD 11.01 用户空间协议栈。
* 支持 Nginx、Redis 等成熟应用，服务可以轻松使用 F-Stack。
* 多进程架构，易于扩展。
* 提供微线程接口，各种有状态应用可以轻松使用 F-Stack 来获得高性能，而无需处理复杂的异步逻辑。
* 提供 Epoll/Kqueue 接口，允许多种应用程序轻松使用 F-Stack。
目前，腾讯云的多个产品已经使用了 F-Stack，例如 DKDNS (DNSPod 的授权 DNS 服务器)、HttpDNS (D+)、COS 接入模块、CDN 接入模块等。
评论区有用户提到，这项技术在八年前首次分享时被认为是创新的。这表明 F-Stack 背后的内核旁路思想由来已久，并且在不断发展和完善。
- 原文: [F-Stack – A network development kit with high performance based on DPDK](https://www.f-stack.org/)
- Hacker News: [https://news.ycombinator.com/item?id=45074115](https://news.ycombinator.com/item?id=45074115)
- 作者: anon6362
- 评分: 36
- 评论数: 3
- 发布时间: 2025-08-30 20:37:28
---
## OpenAnimationApp：使用 Kotlin Multiplatform 探索和编辑 Lottie 动画
OpenAnimationApp 是一个使用 Kotlin Multiplatform (KMP) 构建的应用程序，旨在帮助开发者探索和编辑 Lottie 动画。它提供了一个用户友好的界面，可以方便地浏览和修改 Lottie 动画文件。该项目托管在 GitHub 上，并提供 MIT 许可证。
这个项目的主要亮点在于它利用 KMP 实现了跨平台的能力，这意味着开发者可以使用相同的代码库来构建 iOS 和 Android 应用程序。此外，OpenAnimationApp 还提供了一个在线 Web 版本，方便用户直接在浏览器中查看和编辑动画。该项目目前有 48 个 stars 和 2 个 forks，表明它在开发者社区中具有一定的吸引力。
OpenAnimationApp 的主要功能包括：浏览 Lottie 动画库、编辑动画属性、预览动画效果。通过这个工具，开发者可以更轻松地集成和定制 Lottie 动画，从而提升应用程序的用户体验。该项目还包含一个在线演示站点，用户可以在无需安装任何软件的情况下体验其功能。
- 原文: [Show HN: OpenAnimation – KMP app for exploring and editing Lottie animations](https://github.com/orispok/OpenAnimationApp)
- Hacker News: [https://news.ycombinator.com/item?id=45074399](https://news.ycombinator.com/item?id=45074399)
- 作者: orispok
- 评分: 6
- 评论数: 0
- 发布时间: 2025-08-30 21:18:53
---
## 动森风格信件编辑器：重拾童年回忆
这款 Animal Crossing 风格的信件编辑器，让你瞬间回到童年时代。它模拟了动森游戏中的信件书写体验，让你能够创作出充满怀旧感的信件。
这款编辑器操作简单，用户界面友好，即使在手机上也能获得良好的用户体验。你可以自定义信纸、选择字体，甚至添加一些动森风格的装饰，让你的信件更加个性化。
这款工具不仅能让你重温童年回忆，还能用于各种场景。比如，你可以用它来给朋友写感谢信，或者给孩子写一些温馨的便条。
评论区里，有用户分享了关于动森信件机制的视频，帮助大家更好地了解这款工具的原理。还有用户提到，可以结合 animalese 库，让信件内容听起来也像动森里的动物说话一样，增加趣味性。
有用户指出 stationary 和 stationery 的区别，提醒大家注意拼写。还有用户分享了 Death Generator 网站，里面有更多像素风格的自定义屏幕。
有用户对瓶中信功能提出了疑问，担心审核问题。开发者可能需要考虑如何解决内容审核的难题，确保用户能够安全地使用这项功能。
总的来说，这款 Animal Crossing 风格的信件编辑器，是一个充满创意和趣味的小工具，它能够唤起人们美好的童年回忆，并为生活增添一份乐趣。它不仅是一个简单的信件生成器，更是一个连接过去与现在的桥梁，让人们在数字时代也能感受到手写信件的温暖。
- 原文: [Show HN: I made an Animal Crossing style letter editor](https://acmail.idreesinc.com)
- Hacker News: [https://news.ycombinator.com/item?id=45039292](https://news.ycombinator.com/item?id=45039292)
- 作者: IdreesInc
- 评分: 87
- 评论数: 12
- 发布时间: 2025-08-27 21:18:04
---
## John Carmack 论 Meta 构建定制 XR 操作系统：为何不可行？
John Carmack 认为，构建新的操作系统在当今的商业环境中并不合理。即使拥有顶尖的工程师、充足的资源和高质量的代码文档，定制操作系统所带来的成本、维护周期和开发者负担也往往超过其带来的好处。
Carmack 在 X 上分享了他对 Jonathan Blow 关于“今天我们为什么甚至无法想象编写一个新的操作系统”的帖子的看法，并回忆起他曾反对 Meta 构建完全定制的 XROS。他认为，Meta 在 XROS 上投入了大量资源，但最终产品并没有因此而变得更好。他甚至因为反对 XROS 而被该项目的经理举报到人力资源部，理由是他的言论让团队成员感到不舒服。Carmack 强调，要创造真正不同的东西，需要一个与世隔绝的计算机工程师团队，就像 Plan 9 一样。他认为，为了创造一个新的操作系统，可能需要牺牲一个非常成功的产品，但他自己作为利益相关者不会这样做。
评论区对 Carmack 的观点进行了热烈的讨论，主要集中在以下几个方面：
* **硬件供应商的支持：** 有评论指出，现在不编写自己的操作系统的一个主要原因是硅供应商的支持不足。过去，他们会提供足够详细的规范，以便开发者可以编写自己的驱动程序。但现在，他们只提供中等程度的描述和一个质量有问题的 Linux 驱动程序。
* **Meta 的 XROS 项目：** 有评论指出，XROS 项目是 Oculus 被 Facebook 收购后出现的一个令人恼火和分心的项目。许多核心技术团队需要首先解决多个技术堆栈的问题。Carmack 是绝对正确的，但在重组后，他的影响力逐渐减弱。
* **从零开始构建操作系统的难度：** 有评论提到，Google 的 Flutter 团队曾经构建了一个名为 Fuchsia 的新操作系统。他们拥有惊人的才华和庞大的团队，但没有人能够说清楚谁会使用它。从技术上讲，它是辉煌的，但没有商业计划。
* **利用现有内核的优势：** 有评论指出，现在有很多机制可以绕过 Linux 内核，而且多核 CPU 很常见。这意味着你可以隔离一些内核并以你想要的方式固定线程，然后使用一些内核旁路来直接访问硬件。这让你既能获得为硬件精心设计的系统的最佳性能，又能利用完整的 Linux 内核进行管理、监控和调试。
* **创建“与世隔绝的计算机工程师团队”的设想：** 有评论者赞同 Carmack 的观点，并提出了一个“与世隔绝的计算机工程师团队”的设想：选择一个生活成本很低的地方，建立一个非常宜居的村庄，然后投入大量的计算机，几乎没有软件，也没有互联网，尝试从头开始重新发明计算世界。
总的来说，评论区对 Carmack 的观点表示赞同，并从不同的角度分析了构建新操作系统的困难和挑战。许多评论都强调了硬件支持、商业计划和团队协作的重要性。
- 原文: [John Carmack's arguments against building a custom XR OS at Meta](https://twitter.com/ID_AA_Carmack/status/1961172409920491849)
- Hacker News: [https://news.ycombinator.com/item?id=45066395](https://news.ycombinator.com/item?id=45066395)
- 作者: OlympicMarmoto
- 评分: 431
- 评论数: 508
- 发布时间: 2025-08-30 00:45:21
---
## 《Lisp from Nothing》第二版发布：探索极简 Lisp 的奥秘
本文介绍《Lisp from Nothing》第二版，探讨了最小 Lisp 语言如何解释自身，以及如何编译自身。书中通过实现一个简单的元循环求值器和一个完整的编译器，展示了 Lisp 的极简主义。新版增加了关于 Lisp 和 Lambda 演算关系的章节，并在宏部分引入了准引用，修复了错误，并改进了文字。
本书探讨了在打孔卡、电传打字机和大型计算机时代，Lisp 黑客是什么样的，以及 Lisp 与 Lambda 演算的关系。书中提供了多个实现，从简单的元循环求值器到一个完整的编译器，该编译器发出一个独立的 C 程序。书中还包含 Common Lisp 和 Scheme 编写的元循环 Lisp 解释器，以及一个自托管 Lisp 编译器，代码量约为 400 行。此外，还提供了垃圾收集器和用于生成打孔卡图像的 Postscript 代码。读者可以下载完整的 Lisp 代码和 Scheme 代码，以及标题页面的艺术作品。
评论区里，有读者分享了作者的其他作品链接，并表达了对作者作品的喜爱，认为其融合了亚洲哲学和计算。也有读者对作者的创作动机和愿景感到好奇，认为这些作品是文化瑰宝，是作者的个人旅程。还有读者分析了书中 `church.scm` 文件中列表构造函数的优化空间，提出了更简洁的实现方式。
其他评论还包括：有读者推荐了作者的另一本书《Scheme 9 from Empty Space》，认为它详细解释了如何从头开始构建一门语言；有人刚开始学习 Peter Seibel 的《Practical Common Lisp》，认为这本书的发布时机很好；有人表达了对 Lisp 社区过度强调元循环求值器的不解，认为 Polish notation 语法和实际实现也应该得到更多关注；还有人引用了一句关于列表的妙语：“What else are lists, but alternatives?”。有读者指出，本书并不适合 Lisp 初学者，建议先掌握一些预备知识。
- 原文: [Lisp from Nothing, Second Edition](http://t3x.org/lfn/index.html)
- Hacker News: [https://news.ycombinator.com/item?id=45037419](https://news.ycombinator.com/item?id=45037419)
- 作者: nils-m-holm
- 评分: 300
- 评论数: 90
- 发布时间: 2025-08-27 17:50:05
---
## xAI 发布 Grok Code Fast 1：快速且经济的代码模型
xAI 推出了 Grok Code Fast 1，一款专为 agentic 编码工作流程设计的代码模型，旨在提供更快速、更经济的解决方案。该模型从零开始构建，采用了全新的架构，并使用包含大量编程相关内容的数据集进行预训练。通过与合作伙伴的紧密合作，Grok Code Fast 1 掌握了 grep、终端和文件编辑等常用工具的使用，能够无缝集成到各种 IDE 中。
Grok Code Fast 1 在推理速度方面进行了优化，通过创新的技术显著提升了服务速度。该模型在软件开发栈中表现出色，尤其擅长 TypeScript、Python、Java、Rust、C++ 和 Go 等语言。它可以完成从零开始构建项目、解答代码库问题到执行精确的错误修复等常见编程任务。
在经济性方面，Grok Code Fast 1 的定价为每百万输入 token 0.20 美元，每百万输出 token 1.50 美元，每百万缓存输入 token 0.02 美元。xAI 强调，该模型在性能和成本之间取得了平衡，使其成为经济高效地处理日常编码任务的理想选择。目前，xAI 正在与 GitHub Copilot、Cursor 等合作伙伴合作，限时免费提供 Grok Code Fast 1。
xAI 还发布了 Prompt Engineering Guide，旨在帮助用户充分利用 Grok Code Fast 1。团队表示将持续更新该模型，并在未来几周内推出支持多模态输入、并行工具调用和扩展上下文长度的新版本。
### 评论区观点
评论中，有用户分享了使用 Grok Code Fast 1 的体验，认为它速度快，与 agentic 工作流程配合良好，并且能够生成不错的代码，性能可以达到甚至超过 gpt5-mini 的水平。该用户还提到，Grok Code Fast 1 在处理高上下文任务时没有出现问题，并且在遇到问题时，会创建一个新文件进行测试，体现了其智能性。总的来说，该用户对 Grok Code Fast 1 给予了积极评价。
- 原文: [Grok Code Fast 1](https://x.ai/news/grok-code-fast-1)
- Hacker News: [https://news.ycombinator.com/item?id=45063559](https://news.ycombinator.com/item?id=45063559)
- 作者: Terretta
- 评分: 456
- 评论数: 433
- 发布时间: 2025-08-29 21:01:45
---
## 数学写作语法指南：Douglas B. West 的见解
本文档总结了 Douglas B. West 关于数学写作的观察和建议，旨在帮助作者，特别是学生和非英语母语者，写出更清晰易懂的数学作品。通过关注细节，可以显著提高数学写作的可读性，使更广泛的读者受益。
West 的指南涵盖了数学写作的多个方面，包括数学风格、符号和术语、标点符号和英语语法，以及非英语母语者的常见英语用法错误。他强调，即使是细微的调整也能使数学写作更加清晰。该指南并非旨在限制写作的灵活性，而是旨在提高写作的透明度，避免因含糊不清或笨拙的叙述而分散读者的注意力。
文章首先讨论了数学研究论文的总体结构，包括摘要、引言和结论。摘要应尽可能完整地陈述结果，并定义关键术语，且不应包含对参考文献的编号引用。引言应激发问题、讨论相关结果、更完整地陈述结果，并总结论文的技术或结构。West 认为，单独的结论部分通常没有价值，因为其中的信息要么是多余的，要么读者可以在引言中找到。
关于定义，West 建议用斜体（或教科书中的粗体）来区分被定义的词。当使用斜体来表示被定义的词时，不需要使用 "called" 或 "said to be"，因为斜体的使用已经表明这是一个被定义的术语。他特别指出，非英语母语者在定义中可能会出现多余的逗号，并给出了具体的例子来说明如何避免这些错误。
此外，West 还讨论了在数学写作中如何正确使用 "which" 和 "that" 等词语，以及如何避免其他常见的语法错误。他承认，他的某些结论可能与英语风格手册相冲突，但他认为，为了产生更清晰、更符合逻辑的数学写作，有时需要打破常规。
总而言之，Douglas B. West 的《数学写作语法指南》是一份宝贵的资源，可以帮助数学家们提高他们的写作水平，使他们的作品更容易被更广泛的受众所理解。该指南强调了清晰、简洁和准确的重要性，并提供了许多实用的建议，可以帮助作者避免常见的错误。
- 原文: [The Grammar According to West](https://dwest.web.illinois.edu/grammar.html)
- Hacker News: [https://news.ycombinator.com/item?id=45039662](https://news.ycombinator.com/item?id=45039662)
- 作者: surprisetalk
- 评分: 34
- 评论数: 4
- 发布时间: 2025-08-27 21:51:05
---
## 编码理论基础
本文档是 Venkatesan Guruswami、Atri Rudra 和 Madhu Sudan 编写的编码理论课程讲义，日期为 2025 年 8 月 26 日。 这份资料基于他们在华盛顿大学、卡内基梅隆大学、布法罗大学、哈佛大学和麻省理工学院教授的编码理论课程笔记。
该书涵盖了编码理论的基础知识，从基本概念和定义开始，例如纠错、码距和汉明码。 深入探讨了线性码的性质，包括群、有限域、向量空间和线性子空间等数学基础。 此外，还介绍了概率论和 q 元熵函数，为理解随机噪声下的编码性能奠定了基础。
书中还讨论了编码理论的界限，例如汉明界、Gilbert-Varshamov 界、Singleton 界和 Plotkin 界，这些界限限制了码的可能参数。 特别关注了 Reed-Solomon 码，这是一种最大距离可分 (MDS) 码，并探讨了其性质。 此外，还介绍了香农定理，该定理描述了在随机噪声下可靠通信的极限。
为了弥合汉明码和香农定理之间的差距，书中引入了列表解码的概念，并讨论了 Johnson 界和列表解码容量。 最后，探讨了基于多项式的码，并分析了其在不同情况下的性能。 总之，本书全面介绍了编码理论的基本概念、界限和码的构造，为读者提供了深入理解该领域的坚实基础。
- 原文: [Essential Coding Theory [pdf]](https://cse.buffalo.edu/faculty/atri/courses/coding-theory/book/web-coding-book.pdf)
- Hacker News: [https://news.ycombinator.com/item?id=45065705](https://news.ycombinator.com/item?id=45065705)
- 作者: ibobev
- 评分: 328
- 评论数: 57
- 发布时间: 2025-08-29 23:53:41
---
## 使用 Rust 和 JIT 编译模拟 aarch64 架构
本文介绍了作者使用 Rust 语言和即时编译（JIT）技术，实现了一个简单的 aarch64 架构模拟器。该模拟器的目标是理解 QEMU 中 TCG (Tiny Code Generator) 软件模拟的原理，并为 aarch64 架构提供基本的模拟功能，暂不包含 SIMD 等可选特性。
文章详细阐述了将虚拟机指令翻译为原生代码的过程，主要分为以下几个步骤：首先，使用 binja 反汇编 aarch64 二进制代码。然后，使用 Cranelift 的 JIT 后端将每条指令翻译成对应的原生代码。在翻译过程中，需要对指令操作进行匹配，并生成等效的 JIT 操作，同时更新机器状态，例如条件标志。为了提高效率，指令被组织成翻译块，在块的入口加载所有 aarch64 架构寄存器到 JIT 变量，在块的出口更新所有寄存器的值。此外，文章还提到了 QEMU 的一项优化技术，即直接块链接，通过跳过不必要的寄存器状态保存/加载来提高性能。
除了 ISA 翻译，文章还讨论了设备模拟的重要性，例如中断控制器、块设备、闪存和定时器等。作者将之前在 QEMU 中实现的 PL011 (Arm UART 外设) 移植到该模拟器中，实现了基本的输出功能。该模拟器还支持配置大小的内存映射区域作为虚拟机的 RAM，并可以生成简单的设备树。
该项目使用 Rust 编写，充分利用了 Rust 的优势，例如内存安全和高性能。通过 JIT 编译技术，该模拟器能够将 aarch64 指令动态翻译为原生代码，从而提高模拟效率。该项目对于理解 QEMU 的 TCG 原理以及学习 aarch64 架构具有一定的参考价值。
- 原文: [Emulating aarch64 in software using JIT compilation and Rust](https://pitsidianak.is/blog/posts/2025-08-25_emulating_aarch64_in_software_using_JIT_compilation.html)
- Hacker News: [https://news.ycombinator.com/item?id=45023579](https://news.ycombinator.com/item?id=45023579)
- 作者: todsacerdoti
- 评分: 38
- 评论数: 12
- 发布时间: 2025-08-26 15:58:02
---
## 向量嵌入检索的理论局限性
这篇论文探讨了基于向量嵌入的检索方法在理论上的局限性，即使在简单的查询场景下，现有模型也可能无法达到理想效果。论文指出，即使使用更好的训练数据和更大的模型，单向量范式也存在根本性的限制。
文章的核心在于揭示了向量嵌入在处理复杂检索任务时面临的挑战。随着向量嵌入被应用于推理、指令跟随、编码等领域，对它们的要求也越来越高。虽然之前的研究已经指出了向量嵌入的理论局限性，但通常认为这些问题可以通过改进训练数据和模型规模来解决。然而，这篇论文通过连接学习理论中的已知结果，证明了即使在非常简单的查询下，也可能遇到这些理论限制。
具体来说，论文指出，能够作为查询结果返回的文档 top-k 子集的数量受到嵌入维度的限制。即使将 k 限制为 2，并直接在测试集上优化自由参数化嵌入，这个限制仍然存在。为了验证这一理论，作者创建了一个名为 LIMIT 的数据集，专门用于测试模型在这方面的性能。实验结果表明，即使是最先进的模型在这个数据集上也表现不佳，尽管任务本身非常简单。
这项研究表明，现有的单向量嵌入模型在根本上存在局限性，未来的研究需要探索新的方法来克服这些限制。这对于信息检索领域具有重要的指导意义，提醒研究者们在追求更大模型的同时，也要关注模型本身的理论瓶颈。
- 原文: [The Theoretical Limitations of Embedding-Based Retrieval](https://arxiv.org/abs/2508.21038)
- Hacker News: [https://news.ycombinator.com/item?id=45068986](https://news.ycombinator.com/item?id=45068986)
- 作者: fzliu
- 评分: 121
- 评论数: 32
- 发布时间: 2025-08-30 04:25:34
---
## Splunk 入职失败的反思：定义成功、窗口期和干系人对齐
本文作者分享了在 Splunk 入职三年未能晋升的经验教训，重点剖析了在定义成功、把握入职窗口期和对齐干系人方面所犯的错误，旨在为其他职场人士提供借鉴，避免重蹈覆辙。文章强调了入职时明确成功标准、尊重企业文化和建立良好沟通的重要性。
作者反思，当初过于相信面试时听到的信息，没有深入了解 Splunk 真实的晋升标准。他应该主动向最近晋升的员工了解情况，明确晋升所需的具体贡献和影响。此外，作者没有充分利用入职的“窗口期”，急于求成，未能建立信任就对团队提出批评，导致团队关系紧张，错失了晋升机会。在干系人对齐方面，作者虽然在团队内部取得了积极成果，但忽略了与上级领导的沟通，未能及时汇报工作进展和遇到的问题，导致领导层未能充分了解他的贡献。作者建议，应该系统性地向上级汇报工作，了解他们对成功的定义，并寻求他们的支持。
作者最后总结说，入职是关键时期，需要谨慎对待。要明确成功标准，尊重企业文化，建立良好沟通，才能为未来的发展奠定坚实基础。不要把晋升作为首要目标，而应该专注于做好入职的基本功。
- 原文: [My Failures Onboarding at Splunk](https://people-work.io/blog/my-failures-onboarding-at-splunk/)
- Hacker News: [https://news.ycombinator.com/item?id=45032630](https://news.ycombinator.com/item?id=45032630)
- 作者: mooreds
- 评分: 20
- 评论数: 15
- 发布时间: 2025-08-27 05:38:35
---
## 使用 96 块 H100 GPU 部署 DeepSeek：PD 解耦与大规模专家并行
本文介绍了如何使用预填充-解码解耦（PD 解耦）和大规模专家并行（EP）在 96 块 H100 GPU 上高效部署 DeepSeek，这是一个流行的开源大型语言模型（LLM）。该方案在 Atlas Cloud 的 12 个节点上运行，每个节点配备 8 块 H100 GPU，实现了每节点每秒 52.3k 个输入 token 和 22.3k 个输出 token 的速度，用于 2000 个 token 的输入序列。
DeepSeek 模型因其独特的架构（包括多头潜在注意力（MLA）和混合专家（MoE））而闻名，这使得大规模高效服务成为一项挑战。为了优化性能，文章详细阐述了并行设计，包括如何针对注意力层、密集前馈网络（FFN）、稀疏 FFN 以及语言模型（LM）头进行优化。
对于注意力层，采用了 DP Attention 策略，消除了跨设备的 KV 缓存重复，从而显著降低了内存开销。对于密集 FFN，选择了数据并行（DP）而不是张量并行（TP），以提高可扩展性和内存效率，并最大限度地减少通信开销。稀疏 FFN 则通过专家并行（EP）进行处理，将专家权重分布在多个设备上，从而有效地扩展了内存容量。
文章还强调，该实现几乎与 DeepSeek 官方博客中报告的吞吐量相匹配，并且所有组件都是完全开源的，方便社区访问和进一步开发。通过本地部署此实现，每百万输出 token 的成本约为 0.20 美元，大约是官方 DeepSeek Chat API 成本的五分之一。与使用相同资源的原始张量并行相比，这种优化策略将输出吞吐量提高了高达 5 倍。
该文章深入探讨了并行设计、优化方法和结果，并提供了完整的实验复现说明。SGLang 现在支持预填充-解码（PD）解耦和大规模 EP，包括 DeepEP、DeepGEMM 和 EPLB 的全部功能。
总而言之，这项工作提供了一个关于如何使用 SGLang 和各种优化技术，在大量 GPU 上高效部署和运行 DeepSeek 模型的实用指南。
由于没有评论内容，所以略过评论相关的输出。
- 原文: [Deploying DeepSeek on 96 H100 GPUs](https://lmsys.org/blog/2025-05-05-large-scale-ep/)
- Hacker News: [https://news.ycombinator.com/item?id=45064329](https://news.ycombinator.com/item?id=45064329)
- 作者: GabrielBianconi
- 评分: 256
- 评论数: 73
- 发布时间: 2025-08-29 22:07:28
---
🫵 来啊，说点有用的废话!
▲
