ParadeDB 在 PlanetScale 的 TIN 扩展最初带来显著更高的 BM25 性能后，对自家基于 Tantivy 的文本搜索进行了优化。主要改进包括：将 fieldnorms 与 postings 一起存储，以提升内存局部性；为稠密的多词项析取查询增加 MAXSCORE 剪枝路径；以及进行多项惰性加载优化。在 Hacker News 数据集上，ParadeDB 的吞吐量达到 344.6 QPS，而 TIN 为 145.7 QPS。
ParadeDB 还发现了基准测试中的差异：TIN 只搜索一个字段，而 ParadeDB 实际上搜索了两个字段；此外，TIN 的稠密词项消除机制会跳过常见词的评分，因此生成的是近似 BM25 排名，而不是精确排名。在 StackExchange 数据集上使用精确 BM25 时，ParadeDB 的吞吐量为 81.9 QPS，而 TIN 为 35.5 QPS；启用停用词后，ParadeDB 的吞吐量提升至 161.9 QPS。
该文章否定了“ctid 标识符天然更优”的说法。稠密的 u32 ID 能够高效压缩，并且可以自然地映射到列式数据，而列式数据正是过滤、排序和分面聚合所需要的。ParadeDB 仍将继续使用 Tantivy，并计划在 0.26.0 版本中将这些向后兼容的优化提交到上游，不过届时需要重建索引。
每日HackerNews RSS
ParadeDB 发布了一篇文章，介绍了其在基准测试暴露出高达八倍的性能下降后所做的搜索性能改进。团队对性能瓶颈进行了分析、优化并分享了相关成果；因其将竞争性基准测试视为提升工程水平的机会，而非单纯追逐榜单的做法，赢得了赞誉。
讨论还提到 ParadeDB 采用了 AGPL-3.0 许可证。该公司表示，此举旨在防止超大规模云服务商将社区割裂。维护者称，项目已有超过 150 名社区成员参与贡献；他们接受问题报告和拉取请求，但会严格拒绝质量低下或由 AI 生成的提交内容。
一些用户分享了生产环境中的使用经验，其中一个部署实例索引了超过 1 亿条记录，索引规模达到 4 TB。部分评论者仍对 ParadeDB 这种专注于特定搜索领域的产品能否实现可持续商业经营表示怀疑。
总体而言，这篇文章获得了 65 分和 10 条评论。
Git 3.0 即将默认采用 SHA-256，这将是一个代价高昂的错误。 Git 3.0's upcoming SHA-256 default will be a costly mistake
11 天前
作者认为，Git 3.0 计划从 SHA-1 切换到 SHA-256，将给整个生态系统带来巨大的成本，而实际安全收益却很小。尽管 SHA-1 在实际应用中存在碰撞弱点，但意外碰撞仍几乎不可能发生；现实中的攻击仍需要先攻破代码仓库、可信分发渠道，或实施精密的社会工程。在 Git 中，信任主要来自仓库来源、身份认证、代码审查和签名，而非内部的对象哈希算法。 默认采用 SHA-256 会造成仓库格式不兼容，并给托管服务、子模块、镜像、签名、URL、库、脚本和工具带来复杂性。现有仓库将面临艰难且需要多方协调的迁移，而许多组织最终也可能覆盖这一新默认值。 更好的替代方案是让 Git 的对象模型继续使用 SHA-1，同时为已签名的提交或标签独立计算并添加更强大的校验和。这样，验证时可以使用 SHA-256、BLAKE3 或多种算法，而无需重写历史记录。`git-evtag` 等现有工具已经采用了类似做法；基准测试也表明，即使面对非常大的仓库，生成校验和的速度依然很快。
Hacker News 的一则讨论围绕 Git 维护者、GitHub 联合创始人 Scott Chacon 的警告展开：在 Git 3.0 中将 SHA-256 设为默认哈希算法，可能是一个代价高昂的错误。他认为，Git 哈希主要用于标识内容；实际可行的碰撞攻击成本仍然极高，而真正的安全应来自可信的分发渠道。如果在整个仓库中替换哈希算法，就会重写每个提交 ID，从而使外部链接、CI 缓存、软件包锁定引用、溯源记录、签名以及代码托管平台的兼容性失效，尤其是子模块。因此，他主张改为提供可选的、独立的更强哈希和签名机制。
许多评论者不接受他的安全模型：人们经常使用提交哈希来验证来自不可信镜像的不可变快照，而 Git 的签名提交最终仍依赖其 Merkle 树哈希。他们指出，SHA-1 的碰撞安全性已经被突破，攻击成本因攻击者而异；Git 使用能够检测碰撞的 SHA-1DC，而合规要求也可能迫使项目迁移。另一些人把这次转变比作 Python 2 到 Python 3 的迁移：过程痛苦，但迁移是有道理的。尽管各方意见不一，许多人都认同，兼容性和长期支持通过旧哈希查找对象是不可或缺的。
启用 JavaScript 和 Cookie 以继续
《黑客新闻》的一则讨论帖围绕加拿大加快批准一条通往太平洋的输油管道展开。支持者认为，此举可以减少加拿大对美国的依赖，并使出口更多地面向亚洲市场。他们指出，该项目可能推动石油产量增长，降低对加拿大铁路运输和美国买家的依赖，增加财政收入，并支撑长期经济增长。批评者则质疑其气候代价、对原住民土地的影响、项目可行性，以及管道投资是否真正符合加拿大国家利益，而非仅仅服务于阿尔伯塔省或美国的政策。
更大的争议集中在不断恶化的美加关系。评论者认为，关税、吞并加拿大的言论、对相关机构的威胁，以及特朗普总统更广泛的贸易侵略行为，都在破坏加拿大对美国的信任。如今，许多加拿大人主张加强军事、科技和边境建设，并推动贸易关系进一步转向欧洲和亚洲。另一些人则认为，特朗普的现象反映了美国政治中更深层的问题，而且相关政策可能在未来历届政府中继续延续。
讨论还涉及《美墨加协定》是否仍然有效、加拿大乳制品保护措施的作用，以及与美国脱钩究竟是审慎之举，还是会作出不必要且难以逆转的决定。
Cloudflare 推出了 Clef 和 Clef-flash 决策模型，旨在为智能体工作流生成快速、一致且范围明确的结构化分类结果。与通用大语言模型不同，它们会返回受模式约束的答案及经过校准的概率，并且无需重新训练即可处理新类别。两种模型均支持图像输入和 64K 上下文窗口，其中 Clef 侧重准确性，Clef-flash 侧重低延迟。 在 Cloudflare 的网站分类测试中，Clef 用时 2.2 秒完成工作流，而 GPT-OSS-120B 用时 4.7 秒，同时 Clef 返回的分类结果更多。在 43 项基准测试中，Clef 系列模型也取得了较高的准确率，且整体延迟低于其他决策模型。 这些模型可通过 Workers AI 使用，并已在 Hugging Face 上以 Apache 2.0 许可证发布。它们完全兼容 Jev-API，并生成严格类型化的输出，便于集成。 Cloudflare 还将推出一项面向定制工作负载的强化学习微调服务。初期由驻场工程师提供支持，未来将转为自助服务。该服务将使用 Cloudflare 的 AI Gateway、Workers AI、Containers 和模型训练基础设施。潜在应用包括客户支持分流、信任与安全审查、威胁情报和机器人分类。
Cloudflare 发布了 **Clef**。这是一系列基于后训练 Qwen 模型的开放权重多模态决策模型，同时配有用于监督微调和强化学习微调的工具。Clef 能够输出结构化选项、评分和类置信度结果，可用于分类、内容审核、路由、智能体工作流及其他自动化任务。其模型权重已公开，但训练数据和完整训练方案并未公开，因此它属于开放权重，而非完全开源。
讨论主要围绕 Clef 与 Typesafe 的 **Jev** 展开。Cloudflare 表示 Clef 的基准测试准确率更高，但独立测试发现，在真实分类任务中，Clef 往往速度更慢、成本更高，偶尔准确性反而更低。其更大的模型规模和对视觉输入的支持，可能解释了其中一些取舍。
许多评论者认为，“决策模型”并不是新概念，只是换了新的包装：受约束的大语言模型输出、分类器、词元概率、后训练和概率校准都属于这一范畴。真正的难点在于校准、代表性数据、稳健的评估，以及判断模型输出何时可以安全地驱动自主行动。
总体而言，评论者认可 Clef 在低成本专用 AI 和本地推理方面的潜力，但也质疑其创新性、基准测试结果的泛化能力、可靠性，以及微调是否仍有必要。
turbopuffer 正在重新设计其存储架构（“v3”），以支持更多查询方案、更大的规模和更好的性能。 其原有架构将 ANN 向量索引作为主键：文档存储在基于聚类的 ANN 地址下，属性和全文检索倒排项则引用这些地址。这种方式对向量搜索非常有效，能够支持超过 1000 亿个向量的索引，在每秒超过 1000 次查询（QPS）的情况下实现 200 毫秒的 p99 读取延迟，但也带来了三个主要限制： - **存储放大：** 多向量文档会重复存储非向量数据。 - **写入放大：** ANN 负载均衡会迫使文档数据和二级索引一起迁移。 - **向量化受限：** 查询引擎受 ANN 聚类大小限制，无法使用更大、更高效的块。 turbopuffer v3 不再将 ANN 地址作为主键。文档改为独立存储，ANN 则像属性和全文搜索一样，成为二级索引。这样，每种查询方案都可以采用针对其执行模式优化的布局。 这次重新设计并不简单。尽管所有持续集成（CI）测试目前都已通过，但新架构最初导致生产环境性能明显下降，因为团队优先保证正确性和基础设计，而非性能调优。现在，团队已经开始进行性能优化，并计划在改进过程中持续发布基准测试结果。
Turbopuffer v3 放弃了以向量为主键的存储方式，转而采用更传统的设计：文档使用稳定的内部 ID，ANN 则作为二级索引。这类似于 PostgreSQL 与 InnoDB 之间的取舍：PostgreSQL 通过直接指向行来换取更快的读取速度，而 MySQL 则让二级索引指向稳定的主键，以提高写入效率。
支持者认为，这一改动减少了 ANN 重新平衡导致的高成本索引重写；批评者则质疑额外的一层查找是否会增加延迟，尤其是在冷存储的 p99 延迟方面。开发者表示，各集群可以在本地保留向量，因此只有获取结果时才会产生这层间接访问。
许多评论者认为，“向量数据库已死”只是夸大的营销说法。向量搜索正在成为更广泛检索系统中的一种查询原语，而传统数据库和搜索引擎也越来越多地支持它。独立的向量存储还会带来同步和运维复杂度。
另一个讨论分支则质疑，AI 生成的评论是否正在破坏 Hacker News 的讨论质量，以及采用邀请制准入的社区是否更能遏制垃圾信息。
罗伊·谢斯特维茨发布于2026年10月1日：
“Red Hat”品牌（及其徽标）今天又进一步被瓦解。
“两小时前（上文提到），‘徽标’上写的是 IBM，”托马斯·威尔逊说，“团队还在，工作仍在继续。我对接下来会发生什么感到兴奋。”
但它的角色变了，里面充满了废话（“嘿，嗨”）、杂质或填充内容。IBM里人人都知道，接下来就是 PIP 和 RA。很容易看出，redhat.com 上绝大多数博文卖的都是废话，而不是 Linux。这有助于推高股价，却没有取得任何实质性成果。这是“虚假工作”，和那些废话一样。它是在欺骗股东，但这种做法还能维持多久？
Red Hat 的“道路”“文化”或“开源组织”正在一步步消失。有些人干脆在今天（或昨天）离职，而且不只来自 Red Hat，也来自 Nordcloud。有些人则拿到一笔钱，“自愿”离开……
量子（雾件）团队正在沿着 Kyndryl 的老路，经由 Anderon 走下去。IBM 正在“创造性地”内爆。█
《黑客新闻》上的讨论帖围绕 IBM 收购红帽后是否正在逐步拆解红帽展开争议。文章链接的 Techrights 内容依赖轶事和猜测，多位评论者也质疑其可靠性。
大多数参与者承认，双方确实进行了一定程度的整合：人力资源、财务、法务、IT，以及部分销售业务现已纳入 IBM 体系。然而，工程、营销、支持、主要销售市场以及极具价值的红帽品牌在很大程度上仍保持独立。前红帽员工描述了公司文化和员工士气逐渐受损的情况，也有人坚称，红帽仍是 IBM 旗下一个重要且相对独立的组织。
一个关键担忧是，红帽在 Linux 和其他开源项目中发挥着广泛但经常被忽视的作用。支持者认为，开源项目的维护者不容易被“私有化”，否则他们可能另起分支创建新的项目，或加入其他资金充足的公司。另一些人则认为，Linux 的未来太重要，而且已有 Google、微软、高通、SUSE 等公司提供充分支持，因此不应依赖红帽。
更广泛的分歧在于 IBM 的战略：它究竟是在利用企业客户锁定效应来获取短期收入，如同 Broadcom 收购 VMware 后所采取的做法；还是希望通过支持服务、咨询以及定制化企业服务，将广受欢迎的开源项目商业化。
Cloudflare 推出 K2 公开测试版。这是一项无服务器、持久的事件流服务，可将生产者与消费者解耦，并在服务中断或流量峰值期间防止数据丢失。K2 将事件存储为有序日志，支持长期保留，并允许消费者并行处理数据，或通过独立订阅接收每条消息。 K2 基于 Cloudflare 边缘基础设施构建，使用分区日志段构建在高度持久且强一致的 R2 对象存储之上。事件会先短暂缓存在内存中，然后以批量分段文件的形式写入。该设计简化了协调机制，并使计算和存储能够独立扩展，不过初始的第 99 百分位生产延迟约为 1 秒。 消费者会收到租用批次，并可以确认、否定确认或延长租约。K2 支持共享订阅以分发工作、独立订阅以实现发布/订阅扇出，或两者结合。它不同于 Queues：Queues 用于处理单个成本较高的任务，并支持消息级重试；也不同于 Basin Pipelines，后者针对将事件转换并写入 R2 或 Iceberg 存储进行了优化。 测试版支持 Workers 付费账户，限制为每个流存储 10 GB、生产吞吐量为 30 MB/s。未来计划包括提高吞吐量、引入消息键、支持基于推送的消费者、降低延迟，以及兼容 Kafka 客户端。
Cloudflare 推出了 K2，这是一项基于对象存储构建的无服务器持久事件流服务。它将事件存储为有序日志，支持独立订阅和重放，并允许多个消费者并行处理相同的记录。
The Hacker News 上的讨论大致反映了一种转向“对象存储优先”系统的趋势：这类系统牺牲本地磁盘的低延迟特性，换取更便宜、更持久且几乎无限的存储，同时无需管理集群。K2 主要定位于高容量事件分发、长期数据保留、分析流水线和扇出型工作负载，而不是对延迟敏感的任务。
参与者区分了 K2 与队列：队列用于管理需要重试和状态跟踪的单个操作，而 K2 用于分发可由多个系统消费的不可变事件。
主要担忧包括更高且不稳定的尾部延迟、按 GB 计算的读写成本、对云服务的依赖、不同提供商之间的可靠性差异，以及可移植性。Cloudflare 表示计划提供兼容 Kafka 的 API，同时一种更简单的自定义 API 将提供更高的读取并行度。有人建议采用混合系统：將近期数据缓存在内存或本地存储中，同时将较旧的数据保存在对象存储中。
Figma 代表 Gayani 确认，其远程 MCP 服务器仅允许受支持白名单中的客户端连接，而 Pi 目前尚未被列入其中。她引导用户查看 Figma 的 MCP 目录，了解当前支持的客户端，并提供了一个表单，供用户申请未来支持 Pi。
MCP 创建者 David Soria Parra 批评了这一限制，认为 MCP 最初被设想为一个开放的生态系统，相关访问应当便捷且广泛可用。其他人也表达了同样的担忧，将客户端白名单制比作仅允许特定浏览器访问网站。这场争议凸显了开放 MCP 互操作性与厂商控制访问之间更广泛的矛盾。
Figma 的远程 MCP 服务器遭到用户反弹。该服务器允许 AI 智能体编辑 Figma 文档，但现在仅向 GitHub Copilot CLI 等获准客户端开放，Pi 等工具被排除在外。Figma 的桌面端 MCP 仍可使用，但仅限于读取；远程访问还需要公司批准和付费开发者席位，未来可能改为按使用量收费。
支持这些限制的人提到了 OAuth 安全、防范钓鱼、数据控制，以及 Figma 掌控商业变现的考虑。批评者则认为，这种做法既武断，批准机制也很容易被仿冒绕过，不仅违背 MCP 推动开放互操作的目标，还会损害 Figma 的长期竞争力。目前，许多用户已经开始转向 AI 生成原型、编程工作流，以及 Paper、Penpot、OpenPencil 和基于自定义 API 或插件的集成方案。
更广泛的争议在于，外部 AI 智能体是否会将 SaaS 产品拆解成可组合的工具，从而削弱传统界面和厂商的控制力；还是说，高度专业化且深度集成的原生 AI 体验仍具有更高的价值。总体来看，这场讨论预计厂商锁定会进一步加强，但认为 Figma 的限制也会推动开放替代方案的发展，并加速用户迁移 away from the platform。
Magnet Forensics 表示，它已开发出能够防止 iPhone 进入强化安全状态的工具，帮助执法部门保存和获取证据。其 GrayKey Preserve 设备以及适用于现有 GrayKey 工具的“证据保存模式”，主要针对 iOS 长时间未活动后自动重启的机制。该机制会在 72 小时后使数据更难提取，还会自动删除最近删除的照片、iMessage 消息和缓存位置等内容。 据一段泄露的培训视频显示，这些工具会先获取初始访问权限，随后关闭 Wi‑Fi、蓝牙和蜂窝通信等无线功能，并让 iPhone 保持在“首次解锁后”（AFU）状态，以便访问更多数据。据称，它们还会记录这一状态，使其在重启或断电后仍能保留，并阻止到期计时器无限期删除数据。视频没有透露具体技术方法。研究员 Jiska Classen 表示，Magnet 可能在操纵 iPhone 的系统时钟，或禁用会触发数据到期的任务，但这一点尚未得到证实。Apple 和 Magnet 均未对此置评。
Hacker News 的一则讨论帖提到，Cellebrite、GrayShift 等取证厂商可以在 iPhone 因长时间未活动而重启、恢复到“首次解锁前”状态之前，保留或利用其中的“首次解锁后”状态数据。这项能力价格昂贵，而且主要提供给执法机构，因此 commenters 认为，它与政府扣押设备的关系比与普通手机盗窃更大。
建议的 precautions 包括：在进入高风险区域前手动关机；设置强密码；及时更新设备；禁止在锁屏状态下访问控制中心；在适当情况下使用法拉第袋。GrapheneOS 用户指出，该系统可配置的自动重启计时器，以及使用指纹和 PIN 码的二次解锁功能，都是有用的安全特性。
讨论很大一部分集中在警方问责、搜查令、边境搜查，以及此类数据保留工具是否可能在获得法律授权前提取数据。各司法辖区针对强制解密的法律保护措施并不相同。参与者还讨论了一个问题：技术保护措施更强，是否就意味着应当更广泛地信任相关机构。他们强调，重要文件不应只在手机上保留唯一一份。
**RacketCon 2026** 将提供在线聊天，并开放早鸟优惠注册，截止时间为 9 月 13 日。两天均于美国太平洋夏令时间上午 8:30 开门。周六将以 2019 年 ACM 图灵奖获得者、斯坦福大学荣休教授 Pat Hanrahan 的演讲开始。 周六的议题包括：Typed Racket 宏的逻辑类型推断、Pille 基于 Rhombus 的 LLVM 系统语言、面向宏的容错 IDE 服务、Herbie 浮点精度编译器、cio 效果处理器库，以及 BrandX 的面向对象接口、泛型和契约。现场提供午餐，随后于下午 6:00 举行酒水和小吃社交活动。 周日议程包括 Uke 不可变数据框、Racket 全新的 `ffi2` 外部函数接口，以及于上午 11:30 开始的 Racket 管理者圆桌会议。所有安排时间均为美国太平洋夏令时间。
一则介绍 RacketCon 的 Hacker News 帖子引发了关于 Racket 相关项目及小众语言价值的讨论。评论者 dharmatech 展示了 **ALOE**：这是一个基于 Racket 的原型，将 Scheme、Smalltalk 和类型系统结合起来，采用受 Smalltalk 启发的消息传递对象模型，并支持 VS Code。
其他人还分享了 **pricklypear**，这是一款用 OCaml 编写的解释型 Lisp，并使用 PostgreSQL 存储数据；以及 **bjolang**，这是一种编译为 C# 的 S 表达式语言，具备 HM 类型推断、trait、不可变数据结构，以及同步和异步函数变体。
随后，一场更大的争论围绕人工智能是否正在促使业界转向少数主流语言展开。参与者指出，当前的大语言模型已经能够有效编写 Lisp，而 Lisp 简洁的语法、宏、DSL 支持、REPL 工作流以及 intellectual 价值仍然很有用。支持者认为，语言会影响人们思考问题的方式，而研究、实验和编程带来的乐趣本身就有价值，不需要以企业采用为前提。批评者则预计，小众语言的商业相关性会逐渐下降。讨论还因一些偏离主题的人工智能评论、版主管理，以及被举报内容的转载而变得颇有争议。