Spotify 正面临一个日益严峻的挑战：在线服务和人工智能代理需要从其“数据湖”的艾字节（exabyte）级数据中，进行亚秒级的“点查询”（即查找特定用户的数据）。虽然云存储延迟已大幅降低，但像 Trino 或 BigQuery 这样的标准查询引擎主要针对分析型吞吐量进行了优化，而非单行查找。
随机访问 Parquet（Random Access Parquet，简称 RAP）通过直接在现有 Parquet 文件上实现交互式查询，填补了这一空白，且无需数据冗余或专门的键值（KV）存储。
RAP 使用“外部索引”将键（如 `user_id`）直接映射到文件位置和行偏移量。这消除了标准 Parquet 文件中常见的昂贵、高延迟的扫描以及“依赖读取链”。通过优化文件布局（例如按键排序、交错列存储以及使用 ZSTD 帧重置），RAP 可以将查询简化为仅需几次千字节的并行范围读取，甚至可以通过覆盖索引完全免除存储读取。
最终，RAP 将数据湖从仅能进行批处理的系统，转变为能够提供交互式、实时 AI 上下文的系统，使企业能够以传统服务系统极低的分数成本和复杂度来查询历史数据。
每日HackerNews RSS
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
为在线点查询索引数据湖 (atspotify.com)
8 分，由 kalaracey 发布于 50 分钟前 | 隐藏 | 过往 | 收藏 | 讨论 | 帮助
考虑申请 YC 2026 年秋季批次！申请截止日期为 7 月 27 日。
指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
Cursor 用户对最近的一项刻意更新表示强烈不满。该更新将所有自助服务方案（包括 Teams 版）的费用追踪从美元计费方式改为仅显示 Token（令牌）用量。此前，用户可以查看每次请求、每个模型以及每日的费用详情，这对他们的预算管理、监控模型效率以及了解支出至关重要。
Cursor 代表 "kevinn" 解释称，此举是旨在简化计费并避免用户混淆“套餐内包含用量”与“按需付费”的刻意设计。尽管用户仍可在仪表板中查看总支出，但移除精细到请求层级的成本数据（甚至包括历史记录和 API 端点中的数据）引发了强烈抵制。
用户认为，仅凭 Token 数量难以进行财务规划，且透明度的降低妨碍了他们评估不同模型的性价比。许多用户呼吁提供一个切换选项以恢复美元显示方式，认为此项更改降低了工具的实用性与透明度。批评者将此举描述为“开倒车”，要求 Cursor 要么恢复成本显示字段，要么提供更稳健、透明的支出追踪方式。
最近的一场 Hacker News 讨论凸显了用户对 AI 代码编辑器 Cursor 日益增长的不满。讨论的导火索是该公司决定从其使用量页面和 CSV 导出文件中移除费用信息，此举被用户批评为缺乏透明度。
除了定价问题，长期用户还对 Cursor 近期的演变表示不满。一些人认为该工具已偏离了其作为可靠 VS Code 分支的初衷，并指出近期的更新妨碍了手动编码体验。尽管一些支持者仍看重 Cursor 与零散的代理工具相比所具备的无缝且流畅的集成优势，但也有越来越多的人开始探索替代方案。早期采用者表示，他们已迁移到更灵活的工作流程，将专用的 AI 代理（如 Claude Code）与标准编辑器结合使用。总体而言，这种情绪反映了社区正在权衡“一体化”AI 体验与更模块化、更透明的开发环境之间的利弊。
由于开发者兴趣转移，OpenBSD 的 `relayd(8)` 和 `httpd(8)` 的开发一度陷入停滞。作者出于对精通 C 语言的渴望，以及对“编程已被大语言模型解决”这一论调的挑战，主动承担起这些守护进程的现代化工作。 凭借实践经验和专业架构知识，作者对这些工具进行了系统性的重构。工作重点包括重构遗留的 `imsg` 代码、提升安全性、修复长期存在的错误以及增强功能。关键的安全更新包括：改用“安全”默认 TLS 密码套件、强化 HTTP 解析以防止请求走私，以及实施更严格的进程控制。 为了降低新贡献者的参与门槛，作者改进了文档，并打破了传统的仅限 CVS 的工作流，建立了易于访问的 Git 镜像（Gothub、Codeberg 和 GitHub）。这项振兴工作已经显著提升了这两个守护进程的稳定性和功能，未来还将有更多更新计划。通过拥抱 C 语言的复杂性并投身于规范的开源贡献，作者成功地焕新了这些此前面临停滞风险的关键基础设施。
Hacker News
最新 | 过往 | 评论 | 提问 | 展示 | 招聘 | 提交
登录
Dead Software Walking：relayd(8) 和 httpd(8) 的持续演进 (rsadowski.de)
13 点，tylerius 发布于 4 小时前 | 隐藏 | 过往 | 收藏 | 1 条评论 | 帮助
graemep 8 分钟前 [–]
据我所知，OpenBSD httpd 的编写与 OpenBSD 的其他项目一样，都专注于安全性？我原以为现在比以往任何时候都更需要它。relayd 也是如此。
回复
考虑申请 YC 2026 年秋季批次！申请截止日期为 7 月 27 日。
指南 | 常见问题 | 列表 | API | 安全性 | 法律 | 申请 YC | 联系
搜索：
受寻找琐事“最优解”（例如免费餐厅面包）的启发，一位软件工程师开始探寻“幂等键”（idempotency key）的起源，这是一种用于分布式系统中防止同一请求被重复处理的工具。
作者首先通过一个生动的类比阐述了这一概念：如何防止家里的狗林戈（Ringo）被不同的家庭成员重复喂食。在反驳了大型语言模型关于 Stripe 在 2011 年发明该概念的说法后，作者追溯了幂等性的演变过程，从 21 世纪初的“仅限一次 POST”（POST Once Exactly）规范和企业级传输协议，一直回溯到印加结绳记事等古老的记录方法。
将搜索范围聚焦于数字计算领域后，作者将这一谱系追溯到了施乐帕罗奥多研究中心（Xerox PARC）1984 年发表的研究论文《实现远程过程调用》（Implementing Remote Procedure Calls，作者为 Birrell 和 Nelson）。该论文描述了一种用于消除重复数据包的“调用标识符”，标志着该机制的一个基础实例。尽管作者承认要确定绝对的“首例”依然困难，但他们总结认为，对这类问题的探索凸显了人类是如何不断地重新发明解决方案，以应对分布式系统中“仅处理一次”这一持久难题的。
这篇 Hacker News 帖子表面上题为“第一个幂等键”（The First Idempotency Key），实际上演变成了一场个人轶事与技术批判的混合讨论。
尽管一些用户在轻松地谈论他们最喜欢的餐厅面包，甚至将从 Le Diplomate 到 Red Lobster 的选择进行了排名，但核心的技术讨论集中在幂等键实现过程中持续存在的困扰上。
用户 *mendapi* 指出，尽管这一概念已经存在数十年，但 API 的语义仍然存在危险的不一致性。例如，Stripe 会缓存 24 小时的响应，无论结果如何；而其他供应商则只对成功的请求进行去重。该评论者警告称，这些关键的行为差异往往隐藏在文档说明中，而非定义在 OpenAPI 规范里，这使得客户端生成器和重试中间件难以可靠地处理请求。这种不一致性带来了巨大的风险，因为供应商可能会在没有明确技术强制的情况下，悄悄更改保留期限。
星际循环 Astro Loop
2 小时前
``` CTRL 操作简单 单指操控。武器自动开火。易于上手，爱不释手。 SRC 开源 无黑箱。整个游戏在 GitHub 上开源，采用 GPLv3 协议。 OFF 离线畅玩 无需信号即可运行。整个游戏存储在您的手机中。 PRIV 无广告，无追踪 无需联网权限。不收集任何信息。数据绝不会离开您的手机。 PERM 无敏感权限 无需相机、麦克风、定位、通讯录、文件或网络权限。绝不索取任何权限。 FREE 永久免费 无价格，无应用内购买，无充值变强。完整游戏，完全免费。 ```
```
Hacker News 最新 | 往期 | 评论 | 提问 | 展示 | 招聘 | 提交 登录
Astro Loop (pubdeer.com)
19 点，由 BaseBaal 发布于 3 小时前 | 隐藏 | 往期 | 收藏 | 2 条评论
gumby271 54 分钟前 | 下一条 [-]
天呐，这简直是《小行星》（Asteroids）版《吸血鬼幸存者》（Vampire Survivors），主意太棒了！很高兴看到 Android 应用也能独立分发。期待去玩玩！
回复
mpalmer 22 分钟前 | 上一条 [-]
游戏本身看起来很有趣！但文案太烂了。我猜这点在如今也算意料之中。读起来就像我们在每三篇 HN 帖子中见到的那种 Claude 生成的营销垃圾。作者为什么就不能花五分钟给它加点个性呢？他们觉得这样就够好了吗？
回复
考虑申请 YC 2026 年秋季批次！申请截止日期为 7 月 27 日。
准则 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系
搜索：
```
耶鲁大学语言学家克莱尔·鲍恩（Claire Bowern）共同参与的一项研究显示，全球语言多样性在 1,000 到 3,000 年前达到顶峰，这一时期被认为是拥有数千种语言的“黄金时代”。与人们认为语言快速灭绝始于 500 年前欧洲殖民主义的观点不同，研究指出，语言的衰落开始得更早，且与古代国家及多民族帝国的兴起相吻合。 随着这些强大帝国的扩张，它们促进了自身语言的存续，同时取代或吸收了人口较少群体的语言。因此，现存的约 7,600 种语言只是人类原始语言遗产中一个片面的、带有历史偏见的样本。研究人员强调，理解这一长期趋势对于准确解读全球语言和文化演变的模式至关重要。
这篇 Hacker News 帖子讨论了保护濒危语言所面临的挑战。
讨论始于对语言复兴可行性的质疑。一位用户认为，由于学习小语种缺乏动力，实际应用几乎不可能。他们还怀疑大语言模型（LLM）能否有效弥补这一差距，并指出许多濒危语言的数据往往不足。
对此，另一位评论者建议，确保语言生存最有效的方法是有人用该语言创作出“伟大作品”，但这一观点随即遭到质疑，因为在现有使用者群体极其有限的情况下，作品很难获得更广泛的受众。帖子的最后提到了关于《吉尔伽美什史诗》文学意义的更广泛讨论。
本项目记录了将支持 MMU 的 Linux 成功移植到 ESP32-S31 (RV32IMAFBCNSUX) 架构的过程。由于开发期间无法获取 S31 的技术文档，该移植工作依赖于对自定义中断处理的逆向工程推测，特别是用自定义的 CLIC/SCLIC 驱动替代了标准的 PLIC。 为了适应硬件平台的局限性，内核采用了 Linux 6.12 版本，利用其 XIP（原地执行）支持，在优化设备 16MB PSRAM 使用的同时实现系统启动。 目前，基础系统运行正常，能够执行 shell 进程并运行 CoreMark 基准测试（得分约为 1058 次迭代/秒）。尽管内核可以启动且基础控制台访问已实现，但绝大多数特定于硬件的外设——包括 GPIO、以太网、I2C、SPI 和安全加速器——仍处于未测试、开发中或未实现状态。本项目代表了一项重大的“底层启动”工作，证明了 Linux 可以在 S31 上运行，但对于依赖大量外设的应用而言，尚未达到生产就绪水平。
近期的一场 Hacker News 讨论聚焦于一个将 Linux 移植到 ESP32-S31 的实验性项目。尽管一些用户认为该项目只是一个“进行中”的工作或存在争议，但技术辩论的核心在于在如此受限的硬件上运行 Linux 的可行性。
主要挑战在于 ESP32-S31 的内存架构。与传统 CPU 不同，它的“MMU”是用于内存映射外部闪存和 PSRAM 的外设，而非提供完整进程隔离的标准 Sv32 兼容单元。因此，该移植版本依赖 Linux 内核 6.12 以利用 XIP（原地执行）支持，因为 Linux 主线内核已经移除了对该功能的支持。
虽然参与者质疑 NetBSD 等替代方案是否更合适，或者缺乏真正的 MMU 是否使该项目不切实际，但也有人指出在如此小型且支持无线功能的设备上运行 Linux 具有技术新颖性。作者承认该构建版本具有实验性质，目前仍高度专业化，且未经过通用用途的测试。
这段文字记录了 Hacker News 上围绕科幻作家查理·斯特罗斯（Charlie Stross）拒绝在写作过程中使用人工智能一文展开的讨论。
这场对话反映出作者观点与该平台以技术为中心的用户群体之间存在深刻分歧。评论者们对斯特罗斯观点的技术准确性进行了辩论，一些人批评他并不了解人工智能的架构。讨论的很大一部分集中在斯特罗斯的代表作《加速》（*Accelerando*）上。虽然一些支持人工智能的读者将该书视为乌托邦式的“技术乐观主义”作品，但斯特罗斯等人澄清道，这实际上是对人类被超级智能机器操纵并最终灭绝的阴郁描绘。
归根结底，这一讨论凸显了“折磨之源”（Torment Nexus）式的讽刺：科技爱好者往往将反乌托邦小说的美学和概念视为奋斗目标，尽管作者的本意是将其描绘成一场噩梦。讨论最终得出一个细致的观察结论：尽管大语言模型在软件开发等受限环境下具有实用价值，但在复制创意写作所需的深思熟虑、长篇叙事结构方面，它们仍面临困境。
Codeberg 最近封禁 AI 生成项目的举措，凸显了开源生态系统中一个关键的缺失。虽然许多人都在寻求“更好的 GitHub”，但现有的替代方案都未能复制 GitHub 最宝贵的特性：其**社交层**。 GitHub 不仅仅是一个代码仓库托管平台，它还是一个集身份认证、协作和项目发现于一体的中心化枢纽。虽然 Git 本身是去中心化的，但围绕它构建的基础设施——如 Issue、Pull Request 和社区标准——并非如此。自托管或碎片化的小众平台会造成阻碍，使习惯了 GitHub 通用惯例的贡献者望而却步。 目前的替代方案（如 GitLab、SourceHut 和 Radicle）难以弥补这一差距。它们要么受困于臃肿的商业化，要么存在非传统的工作流程，又或者技术尚未成熟。随着 GitHub 性能和可靠性的下降，业界依然缺乏一个“显而易见”的继任者。 作者认为，一个可行的替代方案需要将**社交体验作为核心产品**，而不是作为事后的补充。无论是需要一家新的、“无聊”的营利性公司，还是联邦身份验证技术的突破，挑战依然存在：要取代 GitHub，平台必须提供共享的社区和发现网络，从而实现大规模下无缝的开源协作。
Hacker News 上的一场讨论探讨了为何尽管存在其他选择，GitHub 依然是行业标准。共识是，GitHub 的主导地位更多源于强大的网络效应，而非仅仅是其技术功能。
要点包括：
* **社会认同：** 星标、分支（fork）和社区互动等指标是衡量项目质量与可靠性的重要参考，这使得开发者不愿离开。
* **基础设施：** 内置的 Windows 和 macOS 运行程序等特定功能提供了实际便利，将开发者留在了该平台。
* **界面反感：** 批评者认为 GitHub 充斥着不必要的繁杂界面元素和干扰性功能，有人将其视为平台被广泛依赖后的副作用。
总之，尽管开发者偶尔会批评该平台的发展方向，但 GitHub 内置的集体“审计”和声誉生态系统，使得任何单一替代品都难以实现真正的取代。