Hacker News 每日播报 2025-10-02

欢迎收听 Hacker News 每日播报，今天我们将探讨为未来设计的开源数据文件格式 F3、深入文学巨匠科马克·麦卡锡的私人图书馆、学习如何榨干 GPU 的全部性能、关注 Gmail 的一项重要功能变更、见证在《我的世界》中诞生的 ChatGPT、了解荷兰法院对 Meta 推荐系统的裁决、庆祝自托管相册 Immich 迎来首个稳定版、探索本地优先应用的访问控制新范式 Keyhive、揭示铁器时代的起源之谜，并关注 CNN 关于加沙人道主义危机的可视化报告。

F3：为未来设计的开源数据文件格式

一篇来自卡内基梅隆大学的论文，向我们介绍了一种名为 F3（Future-proof File Format）的新型开源数据文件格式，旨在解决 Parquet 和 ORC 等传统列式存储格式在现代硬件和工作负载下面临的挑战。

核心创新

面对“宽表”（数千列）、高维向量和云存储随机访问等新需求，现有格式显得力不从心。F3 带来了多项关键创新：

• 高效元数据：采用 FlatBuffers 序列化元数据，支持零拷贝反序列化，显著降低了在宽表场景下的元数据解析开销。
• 解耦的 I/O 单元：将物理 I/O 粒度与逻辑行组解耦，允许写入器根据存储介质（如 S3）独立优化写入块大小，避免了内存溢出问题。
• 灵活的字典编码：允许根据数据特性选择局部、共享甚至跨列共享的字典，以实现更优的压缩比。
• 嵌入式 WebAssembly (Wasm) 解码器：这是 F3 最具革命性的特性。每个 F3 文件都内嵌了一个 Wasm 二进制文件，其中包含了用于解码数据的代码。这意味着，即使读取器本身没有对应的原生解码器，它也可以通过运行这个安全的沙盒化 Wasm 代码来读取文件，从而彻底解决了数据格式的向后兼容和可扩展性难题。

社区观点

社区对 F3 的讨论充满了兴奋与审慎的思考。许多开发者对 Parquet 的复杂性和低效元数据处理等痛点深有共鸣，认为 F3 的设计直击要害。特别是，论文作者团队包括了 Pandas 和 Apache Arrow 的创建者 Wes McKinney 以及数据库领域的权威 Andy Pavlo，这为项目带来了极高的可信度。

最具争议的特性是嵌入式 Wasm 解码器。一方面，它被视为解决数据格式碎片化和演进困难的“银弹”。但另一方面，也有人对其安全性表示担忧，将其与历史上带来安全风险的“数据与代码混合”模式（如 Excel 宏）相提并论。同时，Wasm 带来的 10-46% 的性能开销是否值得，也引发了激烈的辩论。

论文作者亲自下场解释，强调 Wasm 只是一个备用方案：当系统拥有高效的原生解码器时会优先使用；只有在兼容性出现问题时，才会回退到 Wasm。“损失一些性能总比完全无法读取文件要好。” 这一解释在很大程度上缓解了社区的疑虑。尽管 F3 要想在庞大的 Parquet 生态中站稳脚跟并非易事，但它所展示的前瞻性设计，无疑为数据存储的未来指明了方向。

深入科马克·麦卡锡的私人图书馆

美国文学巨匠科马克·麦卡锡以其深邃的作品和隐居的生活方式而闻名。在他去世两年后，史密森尼杂志的一篇文章带领我们走进他位于新墨西哥州的故居，一窥他那藏书超过两万册的惊人私人图书馆，揭示了这位天才作家不为人知的另一面。

书海中的思想世界

麦卡锡的藏书范围之广令人咋舌，从哲学、高等数学、量子物理到鲸鱼生物学，无所不包。这不仅展现了他百科全书式的求知欲，更重要的是，许多书上留下的批注为我们理解其思想来源和创作灵感提供了前所未有的窗口。文章描绘了一个复杂的形象：他是一位自学成才的建筑师和机械师，拥有过目不忘的记忆力，却生活在一个不用电脑、只用老式打字机写作的“囤积者”环境中。

黑暗中的人性之光

社区的讨论深入到了麦卡锡作品的核心。许多人认为，他广博的知识体系与其笔下角色的哲学思考紧密相连，例如《血色子午线》中那位博学而残暴的“法官”。大家普遍认为，麦卡锡的世界观深刻而清醒，他直面人类文明的脆弱性和暴力的本质。

对于其作品中“过度男性化”和“沉溺于暴力”的批评，许多读者给出了不同的解读。他们认为，麦卡锡对暴力的描绘并非美化，而是一种“临床式”的揭露，旨在呈现历史中被遗忘的残酷真相。更有读者指出，在其最黑暗的作品如《路》中，核心并非虚无主义，而是在绝境中对父爱、善意和希望的坚守——那“传递火种”的信念，恰恰是其作品中最动人的乐观主义光芒。对于想要接触麦卡锡的读者，大家建议可以从《老无所依》等相对易读的作品开始，逐步深入他那宏大而深邃的文学世界。

榨干 GPU：Hazy Research 的 Llama-70B 推理性能优化之道

斯坦福 Hazy Research 的一篇博文以一个极具冲击力的标题——《我们买了整块 GPU，所以我们他妈的要用尽整块 GPU》，宣告了他们对大模型推理性能优化的极致追求。文章详细介绍了一种名为“巨型核函数”（megakernel）的技术，旨在将 NVIDIA H100 GPU 的潜力发挥到极限。

巨型核函数的核心理念

当前主流的推理引擎（如 vLLM）将模型的前向传播分解为上百个独立的 CUDA 核函数，频繁的启动和数据等待导致 GPU 资源大量闲置。Hazy Research 的方案反其道而行之，将整个模型的前向传播融合到一个单一、巨大的核函数中。通过精巧的“指令-解释器”模型，在 GPU 的每个流式多处理器（SM）内部实现指令流水线，让数据加载、计算和存储等操作高度重叠，从而最大限度地减少了等待时间，让宝贵的张量核心（Tensor Cores）始终保持忙碌。

这种优化不止于单个 SM，还扩展到了跨 SM 和跨 GPU 的层面。通过全局工作队列和在核函数内部直接进行的异步跨设备读写，该方案在多 GPU 环境下也实现了计算与通信的无缝重叠。最终，集成该技术的推理引擎在 Llama-70B 模型上实现了超过 22% 的端到端吞吐量提升。

极致优化与通用性的权衡

这篇文章引发了社区关于软件开发哲学的热烈讨论。许多人联想到了游戏主机开发和 Demoscene 场景，在固定的硬件上，开发者可以进行不计成本的极致优化。这引出了一个经典问题：在通用计算领域，我们为了开发效率和跨平台兼容性，究竟牺牲了多少性能？

同时，这也激发了大家对 AI 辅助代码优化的想象。未来是否可以将代码交给一个“计算机大脑”，让它自动榨干硬件的每一分性能？此外，关于 GPU 共享和虚拟化（如 NVIDIA MIG/MPS）的安全性与效率的讨论也十分深入。尽管 Hazy Research 的代码仍处于研究阶段，但它所展示的“压榨硬件”的理念和惊人成果，无疑为大模型推理的未来优化指明了一条硬核而激动人心的道路。

Gmail 将停止支持从第三方账户收取邮件

Google 宣布，从 2026 年 1 月起，Gmail 将不再支持通过 POP 协议从第三方邮件账户（如个人域名邮箱、其他服务商邮箱）拉取邮件，同时也将终止 Gmailify 功能。这意味着用户将无法再在 Gmail 网页版中统一管理所有邮箱的收件。

影响与替代方案的困境

这一变化对许多长期依赖此功能来整合多个邮箱的用户造成了不小的冲击。Google 建议的替代方案主要有两个：在移动端使用 IMAP 连接，或将第三方邮件直接转发到 Gmail。然而，社区的反馈揭示了这些方案的严重局局限性：

• 邮件转发不可靠：大量用户反映，从其他邮箱转发到 Gmail 的邮件，极易被错误地标记为垃圾邮件，甚至被静默丢弃，导致重要邮件（如登录验证码）丢失。这与 SPF/DKIM/DMARC 等邮件认证机制有关，使得转发成为一个“碰运气”的选项。
• IMAP 并非替代品：Gmail 网页版根本不支持通过 IMAP 协议从外部账户拉取邮件，它只允许其他客户端通过 IMAP 访问 Gmail 自身。因此，对于希望在网页端统一管理邮件的用户来说，这并非一个可行的解决方案。

对 Google 的普遍失望

这次调整再次引发了社区对 Google 产品策略和用户支持的广泛批评。许多人认为 Google 的官方公告措辞含糊，沟通不畅。更深层次的观点认为，此举是为了将用户推向付费的 Google Workspace 服务。然而，即便是付费用户，也常常面临账户无故冻结、功能不一致和支持缺失等问题。

这种“温水煮青蛙”式的产品功能退化，让许多用户感到失望和厌倦，并开始积极寻找替代方案。Fastmail、Proton Mail 和 Zoho 等服务被频繁提及，它们被认为在可靠性、用户支持和隐私保护方面提供了更好的体验。

大神在《我的世界》中用红石电路搭建出 ChatGPT

一位名叫 sammyuri 的玩家完成了一项几乎不