2026 09 18 HackerNews

2026-09-18 Hacker News Top Stories #

  1. 训练4B模型用强化学习生成比Postgres快81%的查询计划，但实验环境受限，推广性存疑。
  2. 小米公开Mimo 2.6实时后训练仪表盘，通过率约0.59，透明度罕见，引发社区热议。
  3. Hister是一款为访问页面和本地文件设计的隐私搜索引擎，支持全文与语义搜索，可本地运行并接入AI助手。
  4. GLM自建推理基础设施，在10万块国产AI加速器上优化，端到端性能提升约3倍，但实际服务体验与宣传有落差。
  5. 备份的核心在于可恢复性，需遵循3-2-1策略并定期测试恢复，简单方案往往更可靠。
  6. Servo受赞助开发一周年，新增8位维护者、审查1150个PR，社区讨论其与Ladybird的定位差异。
  7. 第40届CCC大会以“模范公民”为主题，邀请所有人参与塑造包容社区，但评论区未提供具体内容。
  8. 联合国调查认为美国对伊朗学校的袭击构成战争罪，同时伊朗镇压抗议也犯下反人类罪。
  9. 作者从驾照条码签名中数学恢复ECDSA公钥，验证真伪，并呼吁更多州采用公开数字签名。
  10. 加拿大总理马克・卡尼对欧盟提出的将加拿大作为首个 “准成员国” 的想法表示欢迎。

1. 训练一个 4B 模型，以生成比 Postgres 快 81% 的查询计划。 (Training a 4B model to produce 81% faster query plans than Postgres) #

https://rohanbansal.com/qorl

本文探讨了如何训练一个 4B 参数的语言模型，通过监督微调（SFT）和主动强化学习（RL），使其在生成 Postgres 查询计划时比 Postgres 的默认计划快 81%。研究表明，尽管查询优化器经过了十年的研究仍然存在很多不足，但通过合适的方法可以显著提升其性能。

文章首先回顾了查询优化器的复杂性，指出查询优化特别是连接顺序的选择是一个 NP 难题。一个好的查询优化器应该能够生成快速执行的查询计划，而不好的优化器则会生成执行缓慢的计划。语言模型在学习如何执行有明确可验证输出的任务方面表现优异，因此将其应用于查询优化可以显著提升执行速度。

作者的实验包括以下几个重要部分：

  1. 在 113 个以连接为主的查询中，使用 4B 模型达到了 44.7% 的延迟降低，尽管最初该模型无法为其中 99 个查询生成计划。
  2. 构建了一个 Postgres 测量平台，以最小化 Linux 页面缓存争用噪声，确保实验数据的准确性。
  3. 设计了一个自定义的 GRPO 变体，用于在噪声环境中对 RL 的回报进行评分。
  4. 将 RL 任务分配到两台机器上进行处理，使用租赁的 2x H100 节点和四个运行在作者桌面上的 Postgres 容器。
  5. 在 500 个 GPT-6 Astra 代理轨迹上运行了离线蒸馏。

接下来，文章深入探讨了查询优化器的内部工作机制，具体以 IMDB 数据集为例，展示了如何通过 SQL 查询来获取信息。以一个关于 “2000 年代日本公司发行的标题数量” 的查询为例，作者详细分析了 Postgres 在执行查询时的步骤，以及如何选择连接的顺序。

文章还强调了连接顺序对性能的影响，详细计算了在不同连接顺序下，可能产生的行数，并指出了选择不当会导致的性能损失。由于 Postgres 依赖于统计数据来估计表的基数，而这些估计有时会偏差，因此会影响优化器的决策。

为了解决这些问题，文章提到了 pg_hint_plan 扩展，通过添加结构化的提示，可以影响 Postgres 的查询计划，使其选择更优的执行路径。

最后，作者总结了通过训练语言模型以改进查询优化的潜力，强调了该领域的研究还有很大的发展空间，并提出了未来的研究方向。通过适当的算法和模型训练，能够使查询优化器在实际应用中更为高效，为数据库查询提供更快速的响应。

HN 热度 664 points | 评论 136 comments | 作者：polyphilz | 1 day ago #

https://news.ycombinator.com/item?id=49731285

  • 实验环境高度受限（8GB 全内存数据集、shared_buffers 限制、预热查询、只读 SELECT），结果可能过拟合，难以推广到真实大规模 OLTP 场景。
  • 查询计划器本身的已知局限早已存在，DBA 一直用 hints 或自定义计划来弥补，LLM 介入未必带来足够值得的权衡。
  • 引入 LLM 会增加成本和复杂度，数据库核心应保持对 CPU/内存的简单依赖，可靠性更重要。
  • 4B 模型本身消耗大量内存，有人建议直接用 CUDA 加速 Postgres 的排序、哈希和 Join，可能更实际。
  • 模型可只在初始阶段调用一次，后续复用计划（替换参数），但 Postgres 会根据实际参数和统计信息动态调整计划。
  • 生产中 LLM 可能幻觉导致漏用索引，造成查询卡死，需要多次重试，可靠性远不如传统计划器。
  • 传统查询计划器本身就会因统计信息刷新或启发式阈值变化而突然变慢，LLM 的非确定性并非独有问题。
  • 最优计划构建是高度数学和算法密集的问题，LLM 太“钝”，更期待 AlphaGo 式神经网络启发式。
  • 有人质疑为何用 LLM 而非更小的专用网络，直接输入数据特征（而非文本）可能更高效。
  • Postgres 已有 GEQO 遗传查询优化器，属于早期“AI”尝试，但主要用于超大查询，效果并不理想。
  • 混合方案（传统优化器 + LLM 竞争选优）听起来有趣，但如何不实际运行就判断哪个更好是核心难题。
  • 成本基于优化依赖完美估算（尤其行数），如果估算足够准，根本不需要 LLM。
  • 作者花费约 800 美元租 H100 + 400 美元 OpenAI API，训练时间未计入基准，可能不适合频繁更新。
  • 模型偏好的设置（如 random_page_cost=1.1、enable_sort=off）本身就能大幅改善默认 Postgres 计划，可能解释大部分收益。
  • 8GB 数据集规模太小，真实业务常是 TB 级，这种加速意义有限。
  • 更合理的用法是离线分析常见查询日志，批量生成 hints 存入代码库，而非实时嵌入数据库。
  • 有人认为结果被蒸馏自前沿模型轨迹，可能引发蒸馏争议，但也有人反驳前沿模型本身也是大规模“偷数据”。
  • 最终理想方向是自适应查询计划（执行中动态切换），Oracle/SQL Server 已部分支持，Postgres 未来或许也会有。
  • 整体上，文章被认可为有趣的实验和漂亮的技术博客，但多数人认为短期内无法替代传统查询计划器。

2. 小米 Mimo 2.6 实时后训练仪表盘 (Xiaomi Mimo 2.6 live post-training dashboard) #

https://mimo.xiaomi.com/rl/

本文记录了 mimo-v2.6 版本的强化学习训练过程中的多个关键指标，内容主要包括模型在训练中的接受、评估、通过率等数据。以下是详细的总结：

  1. ** 训练接受数 **：每次训练迭代中，模型接受的样本数量和判断的样本数量都在变化。例如，在某些时间点，模型接受了 2808 个样本，且判断的样本总数为 1568。
  2. ** 通过率 **：通过率是一个重要的性能指标，代表模型在经过评估后，成功通过的样本比例。文中多次提到的通过率约为 0.590，表明在大约 10,937 个样本中，有 59.1% 的样本获得了通过。
  3. ** 评估状态 **：每次迭代后，模型的评估状态被记录，包括已判断的样本数、接受的样本数以及剩余样本数。这些数据在不同时间点上有所变化，反映出模型的学习进程和效率。
  4. ** 剩余样本 **：随着训练的进行，剩余待评估的样本数量逐渐减少。这些数据指示了训练的进展情况。例如，某些时刻剩余的样本数为 117 个，而在后续的迭代中这个数字又减少到 96 个。
  5. ** 部分和奖励数据 **：除了接受和评估的样本外，文中还提到部分样本和奖励样本的数量。这些样本代表了模型在学习过程中获得的反馈，有助于进一步优化模型的决策能力。
  6. ** 预热步数 **：预热步数也被记录在内，表明在模型完全投入训练前的准备阶段。预热步数在不同的时间点为 287 至 289 不等，反映出模型准备过程的稳定性。

总体来看，这一训练日志展示了 mimo-v2.6 版本强化学习模型的训练状态和效果，提供了关于模型学习和评估的重要数据。这些数据有助于分析模型的表现及其在实际应用中的潜力。

HN 热度 535 points | 评论 153 comments | 作者：krackers | 1 day ago #

https://news.ycombinator.com/item?id=49732270

  • 有用户称用 MiMo-V2.5 做软件工程日常工作，ROI 极高，质量接近去年 Anthropic 模型，成本却低一个数量级，已全面投入使用。
  • 有人觉得 MiMo 只适合非常基础的任务，在编码和终端基准上明显弱于 Qwen 3.8 Flash Next、GLM 5.x 等模型，虽快但容易犯低级错误。
  • 多人称赞 DeepSeek 4.1 Flash 在 Rust 编码等场景表现优秀，MiMo 常被当作 DeepSeek 不可用时的备份。
  • Qwen 3.8 Flash Next 可本地运行、体积小却性能惊艳，有人用它一天内做出 3D 游戏。
  • MiMo 2.5 在工具调用和指令跟随上表现不错，且在 OpenRouter 上有免费额度。
  • 有人反馈 MiMo 2.5 发布后不久就表现不佳，已取消订阅，现在继续用等于自我设限。
  • 仪表盘显示 2.6-Pro 在 DeepSWE 基准上已从 2.5 的 19% 快速提升到 60%+，让人兴奋。
  • 总训练花费已约 120 万美元，有人好奇具体硬件资源和 MFU 指标。
  • 这种实时公开后训练过程在竞争激烈的行业里非常罕见，透明度令人赞叹。
  • 其他大厂（OpenAI、Anthropic 等）不太可能这样做，因为可能泄露模型规模、训练方法，且营销收益不如小米明显。
  • 有人质疑在训练中跑基准是否构成污染/过拟合，多数人认为只是作为验证集和停止标准，属于常见做法。
  • 这是后训练强化学习阶段，并非预训练，进度条看起来比想象中快。
  • 有人怀疑仪表盘数据是假的（进度会回退、重启日志与图表不对应），可能只是回放或 LLM 生成来制造开放假象。
  • 中国公司比美国/欧洲公司更开放，有人感叹“世界怎么了”，并联系到中国政策鼓励开源模型。
  • 有用户试用了即将推出的下一版模型，感觉多任务、设计和主动性都比 2.5 Pro 明显进步。
  • 有人开玩笑称训练成本其实是 Anthropic/OpenAI API 调用账单，或讽刺是在实时蒸馏。
  • 整体氛围积极，希望更多实验室能效仿这种透明度，尤其是对中小型或追求用户信任的公司。

3. Hister：一个为你访问的页面和你保存的文件而设计的隐私搜索引擎 (Hister: A private search engine for the pages you visit and the files you keep) #

https://github.com/asciimoo/hister

Hister 是一个私人搜索引擎，专为用户访问的网页和存储的文件设计。它能够对所访问页面的完整内容进行索引，使用户能够通过网页界面、终端或连接到 AI 助手的 MCP 来再次查找信息。

快速入门方面，用户可以从最新版本下载适合自己平台的二进制文件，并将其重命名为 hister（在 Windows 上为 hister.exe）。对于 Linux 或 macOS 用户，需要将其设为可执行文件，并在终端中启动 Hister；而 Windows 用户则需在 PowerShell 中运行 .\hister.exe listen，保持该终端处于打开状态，以便索引页面和搜索。

用户需要打开 http://127.0.0.1 并为 Firefox 或 Chrome 安装浏览器扩展。在启用扩展的情况下，访问一个网页后，用户可以返回 Hister 并搜索该页面的某个短语，以找到第一个已索引的结果。对于本地个人设置，无需任何配置，用户还可以选择索引内容，如导入浏览器历史、索引本地目录或导入文件。还有其他安装方法，如使用 Homebrew、Docker 和 Nix，详细的安装指南也可以查看。

Hister 的主要特点包括：注重隐私，不收集用户数据或强制使用云服务，用户可以在本地或自己控制的基础设施上运行 Hister；支持全文索引，允许用户搜索所访问页面和本地文件的实际内容，而不仅仅是标题和网址；通过浏览器扩展自动索引新访问的页面；提供强大的查询功能，支持字段过滤、短语、通配符、否定、别名和结果优先级；可选的语义搜索，允许用户通过自定义的嵌入端点按意义查找文档；支持爬虫和浏览器历史导入，用户可以索引网站或导入现有的浏览器历史；同时支持网页、终端和 MCP 客户端，用户可以通过浏览器、TUI、命令行或 AI 助手进行搜索；最后，支持多用户，能够在共享服务器上为每个用户保留文档和搜索结果的独立性。

在隐私方面，Hister 默认不进行遥测和云同步。浏览器扩展仅将索引的页面内容发送到用户配置的 Hister 服务器，除了下载页面的图标外。服务器会存储文档和搜索索引。可选的语义搜索会将文档文本发送到用户选择的嵌入端点，用户在启用远程集成之前应查看隐私概述和语义搜索配置。

HN 热度 407 points | 评论 123 comments | 作者：bookofjoe | 7 hours ago #

https://news.ycombinator.com/item?id=49743097

  • 作者（asciimoo，曾开发 Searx）亲自现身，介绍 Hister 是从浏览器访问页、书签、历史、本地文件构建个人搜索索引，支持全文 + 语义搜索，可完全本地运行，并提供 MCP 接口。
  • 因与美国商标冲突，作者计划改名，征求短、好听且有 .org 域名的建议（如 chronilog、histro、clipshot、Histeria、hisect、Seekdex 等）。
  • 浏览器扩展只捕获已打开标签页内容，不主动请求，因此能索引 Instagram 等封闭站点，绕过验证码和反爬。
  • 支持多设备使用，只要能访问服务器即可（可用 Tailscale 等），甚至支持多用户和访问令牌认证。
  • 有人希望支持 PikaPods 等一键托管，但目前需手动改配置文件，作者计划加配置 UI。
  • 用户建议增加：视频转录搜索（如 YouTube）、页面笔记、书签过滤、保留旧版本、与当前页面 diff、只索引停留超过几秒的标签页。
  • 与 ArchiveBox 对比：Hister 侧重快速搜索和知识库，ArchiveBox 侧重长期归档保存。
  • 多人表示已使用一段时间（数千文档），体验不错，尤其 MCP、扩展和用户脚本提升了便利性。
  • 有人怀念 Chrome 2008-2013 年的离线全文搜索功能，以及 Google Desktop，认为 Hister 填补了空白。
  • 类似工具推荐：Zotero、SingleFile、LinkDing、LinkWarden 等，可用于归档或补充。
  • 有人自己做了类似项目（自动抓取浏览器历史转 Markdown 进 Obsidian + LLM 分类），或基于浏览器 SQLite 历史做工具。
  • 安全顾虑：有人只愿用发行版官方包，担心自建软件/扩展风险，建议容器化、无网络、源码审计或 LLM 审查。
  • 有人用 ChatGPT 模糊回忆“几个月前读过的东西”也能找到，但被批评增加对大模型依赖，且可能不准确。
  • 整体氛围正面，认为这是长期缺失的个人知识管理工具，作者积极回应建议，欢迎继续反馈。

4. GLM 如何构建自己的推理基础设施 (How GLM built its own inference infrastructure) #

https://z.ai/blog/glm-built-its-inference-infrastructure

这篇文章探讨了 GLM（Generative Language Model）如何在自身推理基础设施的建设中逐步实现递归自我改进（Recursive Self-Improvement, RSI）的过程。文章回顾了从 GLM-4.7 到 GLM-5.3 的演进，强调了在这个过程中，GLM 如何通过自身的能力来加速基础设施建设以及优化推理服务。

首先，文章提到 GLM 在网络安全领域的应用。团队原本希望增强模型的网络安全能力，没想到 GLM 在不到一年的时间内就帮助发现了成千上万的代码漏洞，甚至改变了网络安全的格局。此后，GLM 开始协助构建 AI 自身，尤其是在基础设施方面的表现超出了预期。GLM 能够完成原本需要经验丰富的基础设施工程师几周时间才能完成的任务，并且这种能力使得 GLM 逐渐成为团队日常编码不可或缺的伙伴。

接着，文章详细描述了 GLM-5.3-Flash 的推出过程。这一过程中，团队在超过 100,000 个中国制造的 AI 加速器上构建了一个生产级推理服务，处理了前所未有的复杂性和技术挑战。GLM-5.3-Flash 在短短六天内处理了超过 62 万亿个 token，成为 OpenCode 和 OpenRouter 上使用最广泛的模型之一。通过一系列内存优化和性能调整，团队成功地将端到端服务性能提升了约 3 倍。

在优化过程中，GLM-5.3 的 “Infra Agent” 扮演了关键角色。Infra Agent 通过反馈循环，利用丰富的反馈信息不断改进模型的工程效率。文章指出，反馈不仅包括模型的代码生成能力，还强调了如何将稀疏的端到端结果转化为具体的、可追溯的工程反馈，以指导后续操作。这意味着在整个优化过程中，GLM-5.3 不仅仅是在代码层面进行操作，更在系统级别上进行深度分析。

在这个优化循环中，团队采取了 “密集反馈” 的策略。密集反馈强调反馈信息的局部性、及时性和客观性，以帮助 Infra Agent 更有效地定位问题。通过将正确性测试、运行时日志、执行跟踪、微基准测试和端到端指标整合到代理的迭代工作流中，团队能够在不同层次上进行观察和验证，从而增强了代理的决策能力。

文章还详细描述了几个具体的优化案例，包括如何确保模型计算的正确性、识别 KV 传输中的瓶颈，以及如何解决性能问题。通过这些案例，展示了密集反馈在定位和解决问题中的重要性。例如，GLM 团队通过建立并比较不同执行路径的数值精度，发现并解决了在并行执行情况下产生的数值准确性问题。此外，团队还通过分析 KV 传输的时间线，识别出并发瓶颈，并通过释放 GIL（全局解释器锁）来优化任务调度，从而提升了性能。

总结来说，GLM 的开发不仅展示了 AI 在工程领域的潜力，还通过不断的自我优化推动了技术的进步。文章强调，随着 GLM 的能力不断增强，未来有可能实现完全自主的设计和训练新的模型，这将是人工智能领域的重要里程碑。

HN 热度 356 points | 评论 259 comments | 作者：whiteros_e | 15 hours ago #

https://news.ycombinator.com/item?id=49737922

  • 美国芯片出口限制反而加速了中国自主 AI 芯片发展，迫使企业快速优化国产硬件，成为意外优势。
  • 文章称在相同硬件上实现了端到端服务性能 3 倍提升，硬件效率和单 token 成本已接近主流 NVIDIA GPU 水平。
  • 有人质疑“早有人预见限制会反噬”的说法，认为 2022 年主流观点是“中国已被切断未来”，事后诸葛亮居多。
  • 有人指出 NVIDIA 的护城河不在推理，TPUs、AMD 等已大规模用于推理
  • 国产芯片（如华为 Ascend）目前主要用于推理和小规模训练，前沿大模型训练仍多依赖 NVIDIA（包括走私的 Blackwell）。
  • 出口限制可能加速了国产替代进度，但也有人认为中国本就在推进自主芯片，限制只是增加了紧迫感。
  • 有人认为限制对美国硬件厂商（NVIDIA、AMD、TSMC 等）是损失，对依赖 NVIDIA 的美国 AI 实验室反而有利（减少竞争）。
  • 中国仍受 EUV 光刻机限制，短期内难以大规模量产先进制程芯片，完整自主供应链仍需时间。
  • 文章描述的激进内存优化、大规模自动研究式调优被赞为“真正懂行的人做的工业级优化”。
  • 有用户反馈实际使用 GLM（z.ai）服务时速度慢、有严格额度限制，与文章宣称的高性能有落差。
  • 有人认为美国实验室也在做类似软件优化，只是因为硬件充足，优化动力不如被限制的中国公司强烈。
  • 有人选择 GLM 是因为开源权重、价格更低，而非单纯性能，用来支持开放模型对抗闭源限制。
  • 讨论延伸到电力成本、太空太阳能、数据主权等长期瓶颈，认为 AI 真正的约束可能转向能源和政治。
  • 整体上，技术细节获得认可，但地缘政治与供应链自主性成为争论焦点，多数人认为国产推理栈已具实用竞争力。

5. 备份并非易事 (Backups Aren’t Simple) #

https://filipovski.net/2026/09/16/backups-arent-simple.html

文章开头提到了一句引人深思的评论：“有两种人：那些经历过灾难性数据丢失的人，以及那些将会经历的人。” 数据丢失的发生率远高于我们所希望的，而大多数人对此几乎没有准备。这种情况几乎总是在最糟糕的时刻发生。

作者分享了自己的一个经历：小时候，家里把所有的家庭照片存储到一个外部硬盘上，以腾出电脑空间。某天，父亲想将这个硬盘用作电视机顶盒的存储，结果误格式化了硬盘，导致所有文件索引被删除。虽然最终找回了照片，但这个教训提醒了他们重要数据不应该仅存放在一个地方。

文中强调了备份的重要性，首先是要有一个备份，即将文件复制到其他地方。仅仅将数据备份到同一个驱动器的镜像（例如 RAID 1）是不够的，因为这样无法回滚到过去的版本。因此，备份应该是快照式的。

作者提到恢复点目标（RPO）的概念：即希望在数据丢失后可以接受的最大数据丢失时间。小企业的 RPO 可能在 24 小时以上，而关键金融机构的 RPO 可能少于 30 秒。快照备份会增加存储的负担，因此需要对备份进行轮换管理。

举例说明，作者提出可以使用简单的方法保持 14 天的快照，新的快照替换最旧的快照。然而，这种方法需要不断监控，确保数据没有损坏。对于重要数据，接近今天的快照需要更频繁的更新，而更远的历史数据则可以减少更新频率。

建议可以采用 GFS（Grandfather-Father-Son）轮换策略：保持每天的快照，每周的快照和每月的快照，这样更有效率。但这又增加了复杂性，因此需要精心管理。

作者进一步探讨了如何优化存储，通过去重和硬链接来避免存储相同文件的多个副本，提到 rsnapshot 工具的增量备份功能。增量备份只存储两个相邻快照之间的变化，而非从最后一次完整备份以来的所有变化。

为了确保备份的有效性，作者建议在多个机器上备份，以避免因单一硬件故障导致备份失效。此外，建议进行云备份，以防止因自然灾害或电力波动造成数据丢失。这形成了著名的 3-2-1 备份策略：保留 3 份副本，存储在 2 种不同的介质上，其中 1 份离线备份。

当选择云存储（如 Amazon S3）时，作者指出需要将多个小文件合并为较大的 tar 包，以保留文件的元数据，并降低上传费用。然后，考虑如何安全地分割文件并进行备份变得复杂，因此建议使用像 Borg 或 Restic 这样的成熟工具来处理这些复杂性，并确保数据加密、去重和校验和。

文章最后强调，无论备份做得多好，定期测试恢复功能是至关重要的。建议每六个月进行一次恢复测试，以确保备份解决方案的有效性。并提到避免在凌晨 2 点到 3 点之间运行备份任务，以免因时间跳跃导致问题。

感谢读者的讨论和补充，作者提到了几个重要的补充点，例如：

  1. 不要在凌晨 2 点到 3 点之间运行定时任务。
  2. 提到了 ZFS 文件系统，该系统专门用于保证数据完整性和快照功能。
  3. 考虑一致性组的概念，确保在快照期间所有 I/O 操作被冻结，以保证数据的一致性。
  4. 提及访问控制列表（ACLs）和稀疏文件支持的重要性。

总结起来，文章讨论了备份的复杂性和重要性，提出了许多实用的备份策略和工具，帮助读者更好地保护自己的数据。

HN 热度 343 points | 评论 211 comments | 作者：afilipovski | 1 day ago #

https://news.ycombinator.com/item?id=49732513

  • 多人分享真实数据丢失经历：雷击、OneDrive 条款变更导致无法及时下载、SD 卡突然损坏、备份脚本本身误删源文件和旧备份。
  • 备份真正的价值在于恢复（restore），而非备份动作本身；备份可以自动化，恢复则需要高度专注和验证。
  • 3-2-1 原则（3 份副本、2 种介质、1 份异地）被反复强调，但实际执行时很多人只对照片/视频严格执行。
  • 推荐工具包括 Restic、Borg、ZFS 快照 + sanoid/syncoid、rsync + Synology 快照、Time Machine、Kopia、Backrest 等。
  • 有人用 LTO 磁带库做冷备份，认为比可重写介质更安全；也有人用对象存储的 Object Lock 防止误删。
  • 物理介质（如蓝光）因刻录机难买、不便异地存放而逐渐被放弃；云端 + 本地 NAS 更常见。
  • 数据库备份需特别处理（停服务或 pg_dump），直接备份容器卷可能不一致；ZFS/btrfs 快照可缓解。
  • 恢复测试至关重要，未测试的备份等于没有备份；有人用 healthchecks.io 监控备份失败并报警。
  • 简单方案（rsync + 月度全量重建）在多年实践中被证明可靠，尤其在系统迁移时恢复速度快。
  • Docker 环境备份常因 root 权限文件或权限问题失败，建议最小化权限并用 systemd 限制。
  • 有人怀念 Google Desktop / Chrome 早期离线全文搜索，或批评数码相机仍停留在“拷卡到电脑”的老工作流。
  • 控制数据量是关键，否则备份成本和复杂度会失控；排除缓存等无用文件可大幅降低存储开销。
  • 整体共识：备份看起来简单，实际涉及权限、一致性、去重、加密、异地、监控和定期恢复演练，远比想象中复杂。

6. Servo 开发赞助一周年 (One year of sponsored Servo development) #

https://servo.org/blog/2026/09/15/one-year-of-sponsorship/

在 2026 年 9 月 15 日，Servo 项目的开发者回顾了其首次依靠捐款资助的工作。去年，Servo 项目宣布长期维护者 Josh Bowman-Matthews（@jdm）将会兼职改善 Servo 的贡献者体验，这一切都得益于 OpenCollective 和 GitHub 上的每月捐款。

Bowman-Matthews 对此表示了深深的感激，称这些捐款让他能够投入大量时间到他非常关心的项目中。过去一年中，他为这个项目做出了许多重要贡献，其中一些亮点包括：

  1. 提名了 8 位新的维护者。
  2. 审查了 1150 个拉取请求（pull requests）。
  3. 提出了 114 个针对新贡献者的问题，其中 92% 的问题已经得到解决。
  4. 编写了有关借用风险、实验特性、人工智能政策、如何寻找工作以及修复稳定和间歇性测试失败的新文档。

除了上述工作，他还花时间诊断其他人的拉取请求中的意外失败，并修复了多个间歇性测试失败问题，这使得合并拉取请求的过程变得更加顺利。他特别提到了一些在这一期间的突出工作：

  • 支持大规模重写 Servo 的 JavaScript 引擎集成，以解决与垃圾收集相关的间歇性崩溃问题。他不仅审查了大量拉取请求，还提出了很多问题，从而使得解决崩溃的问题能够分散到更多其他贡献者的工作中。
  • 参与理解测试失败，揭示了我们在 window.open 行为上的缺陷，并最终使得许多不稳定的测试变得更为稳定。
  • 支持另一位贡献者的资助提案，该提案得到了批准以继续为 Servo 工作。

Bowman-Matthews 表示，他在这个角色中找到了健康的平衡，能够兼顾家庭与对 Servo 的有意义贡献，同时也能花时间寻找使项目对其他人更易于参与的方法。他再次对所有支持该项目和他工作的人员表示感谢，强调每一笔个人的月捐款都意义重大。他对未来的一年充满期待，希望看到更多的可能性。

HN 热度 342 points | 评论 140 comments | 作者：AshleysBrain | 15 hours ago #

https://news.ycombinator.com/item?id=49737849

  • NLnet 也在持续赞助 Servo 大块开发工作，有人赞赏其从早期 ISP 转型为开源资助组织的历史与影响力。
  • 有人庆幸有 Servo 作为 Ladybird 的替代，批评 Ladybird 从学习项目转向“真正浏览器”目标不现实，且技术栈反复变更（C++ → 尝试 Swift → Rust）。
  • 有人反驳浏览器无法差异化，认为需要面向隐私、去广告、可深度定制的“Linux 式浏览器”，当前主流引擎都太同质化。
  • Huawei 因美国制裁无法向 Chromium 等美国主导引擎贡献，因此资助并推动了 Servo 的复兴，有全职小团队参与。
  • 有人希望更多厂商（如 Samsung）直接把 Servo 嵌入产品以获取用户份额，但也有人担心公司目标会扭曲开源方向。
  • 社区赞助模式被质疑不可持续，Mozilla 依赖 Google 资金的历史被拿来对比，认为商业赞助是开源浏览器现实出路。
  • 赞助金额公开：核心维护者过去一年约 5 万美元，时薪最高 150 美元，每月上限约 4800 美元。
  • 有人把 Servo 比作“浏览器界的 Hurd”，进展缓慢；但也有人指出它已可下载运行，并对比 Rust 从 2006 到现在的成功轨迹。
  • 实际用途讨论：有人用 Servo 渲染电子墨水屏 UI，内存和速度远优于 headless Chrome；也可作为 WPT 测试和规范验证的额外实现。
  • 批评 Servo 仍依赖 C++ 的 SpiderMonkey（mozjs），最大攻击面未用 Rust 重写；回应称 JS 引擎可插拔化正在进行，可后续替换。
  • Firefox 市场份额低、性能不如竞品、Google 产品体验差等问题被提及，有人表示一旦 Servo/Ladybird 可用就立刻切换。
  • 整体氛围对 Servo 一年进展持正面态度，认为独立引擎对浏览器生态多样性和长期竞争有价值，但距离完整可用浏览器仍有距离。

7. CCC 邀请所有模范公民参加 40C3。 (CCC invites all model citizens to 40C3) #

https://events.ccc.de/en/2026/09/12/40c3-model-citizens/

Chaos Computer Club（CCC）将在 2026 年 12 月 27 日至 30 日举办第 40 届 Chaos Communication Congress（40C3），这是欧洲最大的黑客聚会、会议以及科技、社会与公民自由的平台。会议的主题是 “模范公民”，旨在探讨新的社会模型，因为过去的 “模范公民” 已经将地球置于一个不稳定的状态。

CCC 邀请所有人参与，帮助塑造这一盛会。活动的参与方式包括提交演讲、娱乐节目、艺术、朋克和音乐等，参与者不仅是被动的消费者，而是积极参与到活动的组织与实施中。会议将于汉堡展览中心举行，这里为创造性的想法提供了充足的空间。

在当今社会，共同向更美好的未来努力的共识正逐渐被一种威权国家的模型所取代，强者将自己的观点强加于弱者，个人的责任感和承诺逐渐淡化，取而代之的是对 “强人” 的渴望，认为他们能够 “让一切重回辉煌”。在这种情况下，剩余的自由势力只能采取守势，试图阻止事态恶化，而非创造新的可能性。

与此不同的是，CCC 提倡更具战斗精神的理念，认为会议是展示不同可能性的平台，差异被视为财富，不同的观点被认为是灵感的来源。会议旨在营造一个大家都能感到舒适和受欢迎的社区。

对于 40C3 的讲座程序，主办方正在呼吁讲者响应内容征集，DJ 和音乐人被邀请在休息区和派对舞台上展现才华。艺术家和设计师可以通过艺术征集申请展出不需要舞台的作品、雕塑和表演。此外，主办方还在寻找参与者，共同策划反对法西斯主义的朋克表演，营造温暖而粗犷的氛围。

HN 热度 323 points | 评论 176 comments | 作者：antonly | 16 hours ago #

https://news.ycombinator.com/item?id=49737787

  • 有人回忆早期 CCC（约 26C3）体验：能见到网友、技术氛围好，但与人互动充满“千刀万剐”式小负面经历，如无端被指责反犹、被嘲讽“这就是你们现在的黑客？”。
  • 有人对相机极度敏感甚至发怒，反映德国对公开拍照的强烈反感，与美国“公共场所无隐私权”观念冲突。
  • CCC 明确规定拍照需征得所有入镜者同意，宽角度人群照几乎不可能，活动是私人场地，规则优先于一般公共摄影权。
  • 有人认为禁止拍照导致文化无法被记录留存，建议摄影师戴特殊标识或采用 opt-in 信号；反对者称“远离永恒记录”是难得的清静。
  • 德国法律对“自己的肖像权”更严格：公开发布需同意，拍摄本身在公共场合通常合法但针对个人可能侵权；CCC 作为私人活动可直接禁止。
  • 有人批评黑客文化被各种人“收编”，傲慢、看不起新手是老传统，但如今加上影响者、商贩后氛围更差。
  • 有人赞赏 CCC 仍是见面和交流好地方，也有人觉得那里“最酷的人”和“最糟的人”都有，类似 Stallman 式复杂人物。
  • 讨论延伸到德国隐私文化与实际数据泄露的矛盾、对相机的敌意是否过度、以及德国人“礼貌抱怨”的文化习惯。
  • 有人分享其他欧洲活动对比（如荷兰 WHY、FOSDEM），认为露营式活动与 CCC 大厅式体验不同。
  • 部分评论转向政治（乌克兰援助、德国对俄能源依赖等），引发激烈争吵，偏离主题。
  • 整体上，帖子引发对 CCC 氛围、摄影规则与德国隐私观的激烈辩论，正面体验与“死亡千刀”式小摩擦并存。

8. 伊朗学校爆炸：联合国认为有理由相信美国是这起暴行的幕后黑手 (Iran school bombing: grounds to believe US was behind atrocity, UN finds) #

https://www.theguardian.com/world/2026/sep/17/iran-school-bombing-un-mission-us-military-behind-attack

一项联合国调查小组的报告指出，有充分理由相信美国在今年 2 月对伊朗的一所学校和一个体育设施的军事袭击中负责，并且这些袭击构成了战争罪。报告指出，这次针对位于霍尔蒙兹甘省米纳布的 Shajareh Tayyebeh 小学的袭击造成 156 名平民遇难，其中包括 120 名儿童。袭击中使用了美国的战斧导弹，导致学校屋顶坍塌。联合国表示，学校是 “明显可识别” 的目标。

第二次袭击发生在同一天，目标是位于拉梅德的一个体育综合体和居民区，使用的武器散布了钨弹片。联合国调查小组在声明中指出：“在美国和以色列于 2 月 28 日的袭击之后，调查小组发现有合理理由相信美国犯下了发动不分青红皂白的袭击，导致平民伤亡或对平民设施造成损害的战争罪。”

调查还发现，伊朗当局在对抗议活动的镇压中也犯下了反人类罪。调查团队的报告将提交给日内瓦的联合国人权理事会，重点审查了在今年 2 月开始的伊朗战争期间美国的行为，以及伊朗政府对去年 12 月开始的全国性动乱的反应。

美国官员曾表示，军事行动是依法进行的，而伊朗则始终否认系统性人权侵犯的指控。调查小组认为，对 Shajareh Tayyebeh 小学的袭击构成了不分青红皂白的攻击，导致平民死亡和对民用基础设施的损坏，依据国际法构成战争罪。报告指出，美国在未能充分验证情报的情况下，对学校发起了攻击，而相关情报声称一名高级伊朗军事指挥官可能在场。调查人员表示，未能更新目标情报和确认建筑物是否为军事目标超出了单纯的疏忽，反而显示出美国在进行袭击时意识到可能对平民造成损害，并在此情况下鲁莽地行动。

美国中央司令部在 3 月发表声明称，2 月 28 日当天并未对拉梅德市进行任何袭击。调查小组还发现，伊朗当局在抗议活动中对平民进行了广泛和系统的攻击，包括非法杀戮、酷刑、任意拘留、强迫失踪以及严重限制言论自由。人权组织指出，在这次自 1979 年伊朗伊斯兰革命以来规模最大的镇压中，旁观者也成为了受害者。调查无法独立验证死亡人数，但认为真实的死亡和受伤人数可能远高于官方数据，后者声称已造成 3,038 人遇难和 25,000 人受伤。伊朗政府对抗议活动的反应，包括使用暴力和杀戮、切断互联网以及实施死刑，标志着镇压异议的模式显著升级。

HN 热度 306 points | 评论 263 comments | 作者：hebelehubele | 13 hours ago #

https://news.ycombinator.com/item?id=49739018

  • 核心争议并不是学校是否被炸，而是美军究竟是故意攻击民用目标，还是因为严重过时和错误的目标情报造成了灾难。
  • 一部分网友认为，连续两次袭击学校具有明显的“double tap”特征，因此怀疑第二次攻击可能是为了打击幸存者或救援人员。
  • 另一部分网友反驳说，仅仅同一地点受到两次攻击并不能自动称为“double tap”，关键要看两次攻击之间是否存在刻意等待救援人员聚集的时间间隔。
  • 有网友指出，根据相关调查，两次袭击之间可能相隔约 40 分钟，这使得“double tap”是否成立成为评论区争论最激烈的问题之一。
  • 也有人认为，即使最终不能证明存在故意的二次打击，仅仅使用严重过时的情报攻击一所学校本身就已经足够严重。
  • 多名网友特别强调，联合国报告并没有认定美国“故意杀害儿童”，而是认为美国明知存在击中民用目标的重大风险，却没有采取充分措施确认目标。
  • 一些评论认为，把“战争罪”理解成必须证明攻击者明确知道目标里面都是平民并故意攻击，是对国际人道法过于狭窄的理解。
  • 另一些网友则坚持认为，在缺少完整目标选择记录、军事内部通信和直接证据的情况下，对攻击方的主观认知应该更加谨慎地下结论。
  • 评论区因此出现了大量围绕“证据”和“调查结论”区别的争论，有人要求看到更加直接的物证或内部决策记录。

9. 密钥未随附：恢复美国驾照条码的签名密钥 (Keys Not Included: recovering the signing keys for US driver’s license barcodes) #

https://ryan.science/blog/keys-not-included

在 “设计不安全” 一文中，作者 Ryan Fahey 讨论了美国各州驾驶执照和身份证的数字签名问题。他指出，虽然一些州如纽约和弗吉尼亚的证件采用了专有方式签名，但加利福尼亚州最近开始实施一种公开标准的数字签名方式，以提高安全性。

在每个美国州的身份证和驾驶执照背面，都有一个标准的 AAMVA PDF417 条形码，包含各种个人信息。这些信息的格式是公开的，任何人都可以根据该标准解读。然而，各州可以在这个标准格式中添加特定于州的子文件，而这些子文件可以保留在标准格式的合规性内。

2025 年 10 月，加利福尼亚州机动车辆管理局（DMV）宣布将为其驾驶执照和身份证添加数字安全签名，这是美国首批采用此种技术的州之一。加州的身份证由第三方供应商 IDEMIA 生产，该公司为美国多个州提供身份证件。在加州的 ZC 子文件中，嵌入了一个 W3C 可验证凭证条形码，使用了 ECDSA 签名技术。签名的内容和如何使用公钥进行验证都详细列出，并且加州还提供了一个开源验证工具，方便公众自行检查。

在研究过程中，Fahey 发现，加拿大银行公司（Canadian Bank Note）为纽约、弗吉尼亚、北卡罗来纳、南卡罗来纳和威斯康星州制造证件，并且所有这些州的证件都使用了数字签名。但由于缺乏公开的验证方法，这些签名在实际应用中并不安全。

Fahey 通过破解签名结构，成功恢复了纽约、弗吉尼亚和北卡罗来纳州的公钥。这些公钥能够验证相应州签发的证件的真实性。通过测试，他发现虽然伪造证件在视觉上看起来相似，但由于签名无法通过验证，因此容易被识别为假证。

尽管 IDEMIA 已经在加利福尼亚州成功实施了公开的数字签名，但其他州并未普遍采用这一技术，Fahey 认为这是一个奇怪的选择，因为这种技术的工程工作已经完成，并且在加州已经投入生产。文中呼吁，其他州和制造商应当意识到数字签名的重要性，推动这一安全特性在更多州的应用，从而提高美国身份证件的安全性和可靠性。

HN 热度 278 points | 评论 146 comments | 作者：Ryan5453 | 21 hours ago #

https://news.ycombinator.com/item?id=49735930

  • 文章展示如何从已签名的驾照条码（PDF417）中数学恢复 ECDSA 公钥，从而验证签名真伪，作者提供了加州、纽约、弗吉尼亚的验证演示。
  • 有人纠正标题与用词：恢复的是公钥（验证密钥），而非私钥（签名密钥），ECDSA 本身设计不允许从签名恢复私钥。
  • 公钥本应公开，有人惊讶于部分州或机构仍不愿发布；公开后任何人可验证，无法伪造。
  • 加密术语“密钥”类比引发长讨论：公钥更像“地址”或“锁”，私钥像密码；物理锁钥匙类比在非对称加密中并不完美。
  • 伪造者常用真实签名但错误数据，或自行生成密钥；仅检查条码签名不够，需同时比对正面可读信息与照片。
  • 条码容量有限（约 1100 字节），无法存入照片；护照等使用 NFC 芯片可解决照片绑定与防克隆问题，是更成熟方案。
  • 有人建议移除 ID 表面照片，仅存芯片内，强制使用 NFC 验证，减少人工目视误判；但也有人担心每次买酒都被扫描存储隐私。
  • 芯片 ID 理论上更难克隆，但历史显示射频钥匙等仍可被攻破；人类仍是密钥管理薄弱环节。
  • 现实中许多便利店/酒吧只扫条码不看照片，假 ID 只要条码有效就容易通过；有人故意破坏条码防止被录入数据库。
  • 数字凭证（如 Apple Wallet + W3C 标准）被视为未来方向，可建立到州政府的完整信任链，但依赖闭源钱包被质疑。
  • 各州驾照发放流程差异大：有的现场打印，有的邮寄临时证；旧证处理方式也不同。
  • 整体上，文章被认可为扎实调查，凸显美国驾照条码签名未统一、公钥不公开的问题，NFC 与数字 ID 被普遍视为更好长期方案。

10. 加拿大欢迎欧盟提议其成为“准成员” (Canada welcomes EU proposal to become ‘associate member’) #

https://www.bbc.com/news/articles/cwly7vkke4jxo

加拿大总理马克・卡尼（Mark Carney）对欧盟提出的将加拿大作为首个 “准成员国” 的想法表示欢迎，强调在国防、关键矿产和能源安全等领域需要更紧密的合作。卡尼在斯特拉斯堡的欧洲议会发表讲话时表示，加拿大与欧洲在面对 “地缘政治破裂” 的情况下 “共同更强大”。他的言论是在欧盟委员会主席乌尔苏拉・冯德莱恩（Ursula von der Leyen）提出 “为加拿大的准成员身份打开大门” 后的次日。

美国总统唐纳德・特朗普（Donald Trump）对此提议表示讽刺，称其 “可笑”，并威胁如果认为这一举动是 “敌对行为”，将对欧洲实施 “非常严厉的关税”。当前，加拿大与美国之间的贸易争端日益加剧，双方互相施加关税。

卡尼在演讲中提到，现代社会面临着气候变化、民主规范的侵蚀以及 “贸易武器化” 等新挑战。他指出，经济一体化正在被用作武器，关税成为施加压力的手段，金融机制也被用于胁迫。卡尼认为，加拿大与欧盟的联盟将成为 “其他民主国家的灯塔”，同时强调双方并不寻求形成新的权力集团。

在被问及特朗普的评论时，卡尼回应称：“这一联盟是一个积极的进程。” 他表示，加拿大人团结一致，拒绝他人对其文化和语言的干预，以及国际协议的限制。卡尼还提到，加拿大并不打算或寻求成为欧盟的完全成员，而是将这一提案视为一种 “不同的框架”。

冯德莱恩在欧洲议会的发言中表示，希望加拿大能够成为欧盟的首个准成员，推动在制造业、技术、国防、能源关键矿产和经济安全等领域的更深层次合作。尽管 “准成员” 这一状态在欧盟内尚不存在，因此具体关系尚不明确，实施可能需要数年时间，并且需要所有 27 个欧盟成员国的同意。

目前，加拿大与欧盟已经有自由贸易协议，并在贸易、防御和研究等领域开展合作。卡尼强调，加拿大与欧洲可以通过在关键矿产等战略能力方面的深度合作来增强 “战略自主性”。他提到，加拿大可以向欧洲供应液化天然气和氢气，以支持欧洲的能源安全，同时从欧洲在清洁能源技术方面的专业知识中受益。

此外，卡尼还提议整合技术资源，深化 “人际关系”，包括允许年轻人在大西洋两岸 “工作、学习和生活”，这可以通过加拿大加入欧盟的伊拉斯谟计划（Erasmus+）来实现。他描述这一提议的关系为 “独特而积极的方法，我们将共同定义”。

最后，卡尼表示，加拿大议会将对这些提案进行辩论和投票，但他强调双方目前仍处于 “起步阶段”。预计在 10 月底于蒙特利尔举行的加拿大 - 欧盟峰会上，双方将深入讨论具体细节。

HN 热度 268 points | 评论 330 comments | 作者：witweb | 10 hours ago #

https://news.ycombinator.com/item?id=49740507

  • 外交声明通常提前通过"夏尔巴人"式渠道协调，卡尼已与欧盟成员国进行数月高层会谈，欧盟外交官也认为进展异常迅速
  • 没人真正知道"准成员国"是什么概念，各方只是按自己的目标描述它，这是一个需要逐步明确的新事物
  • 欧盟成员国通常需位于欧洲，但加拿大与法国有海上边界（圣皮埃尔和密克隆）、与丹麦有陆地边界（汉斯岛），且"欧洲国家"定义本就模糊，塞浦路斯也有先例
  • 加那利群岛属于西班牙但地理位置在非洲，欧盟可以容纳加拿大这类国家；欧盟的目标是联合较小地区以增强话语权
  • 法律都是人为制定的，“准成员国"可以按需定义；宪法等法律虽难改，但只要有政治意愿就能改变
  • 自由贸易和人员流动本可分别谈判，只是打包成一个协议并贴上"准成员国"的标签
  • 维米岭纪念碑由法国永久交给加拿大并归加拿大公园局管理，因此加拿大在欧洲实际拥有土地
  • 有趣的想法：让格陵兰/丹麦在纸面上"吞并"加拿大作为变通办法
  • 欧盟是经济政治联盟，促进盟友间贸易和人员流动很自然
  • 欧盟和加拿大在品牌宣传上很成功，“准成员国"是个没人知道含义但让人有温暖感的新概念
  • 申根区因地理原因不太现实，但自由流动可以实现；申根要求全面接受欧盟法律，更可能的是放宽工作签证
  • 不喜欢世界被分成需要理由和许可才能旅行的区域，希望世界变得更友好
  • 只要加拿大是白人占多数的国家并分享欧洲文化就没问题，但这种情况不会持续太久

Hacker News 精彩评论及翻译 #

AWS says it can’t restore some data from mideast f… #

https://news.ycombinator.com/item?id=49733786

This interview with an AWS leader isn’t aging well, from CBS Sunday morning:

Pogue asked, “I don’t mean to give anyone ideas, but let’s say I figured out that one of these unmarked buildings was an AWS data center, and I blew it up. Are you saying that it’s so backed up and redundant that you probably wouldn’t notice?” Wood replied, “Yeah, you wouldn’t notice. I mean, we might be a bit upset, but you wouldn’t notice!”

https://www.cbsnews.com/news/cloud-computing-loudoun-county-virginia/

cmiles8

这段对AWS领导者的采访现在看来不太妙，来自CBS周日早间节目：

Pogue问道：“我不是想给谁支招，但假设我发现这些无标记建筑之中有一座是AWS数据中心，然后我把它炸了。你是说它的备份和冗余做得如此充分，以至于你大概都不会注意到吗？” Wood回答说：“是的，你不会注意到。我的意思是，我们可能会有点不高兴，但你不会注意到！”

https://www.cbsnews.com/news/cloud-computing-loudoun-county-virginia/

My temporary PHP fix from 2014 has nearly 20M inst… #

https://news.ycombinator.com/item?id=49737297

There is nothing as permanent as a temporary fix that works.

Sander_Marechal

没有什么比一个有效的临时解决方案更持久的了。

Training a 4B model to produce 81% faster query pl… #

https://news.ycombinator.com/item?id=49733010

“81% faster query plans than Postgres”…on an 8 GB dataset that fits entirely in memory, with shared_buffers constrained to a fraction of that, queries warmed before measuring, and read-only SELECTs.

I would be cautious about over fitting, it’s tough to say if those query plans would really be more optimal than Postgres heuristics at scale and with a bit more realistic OLTP workloads.

In any case, such is life with profile guided optimization. Many of us appreciate how database workloads can drift over time and with scale.

Kudos to the author for getting their hands dirty and writing up their experiments.

refibrillator

“比 Postgres 快 81% 的查询计划”……基于一个完全适合内存的 8 GB 数据集，shared_buffers 被限制为其一小部分，查询在测量前已预热，且仅涉及只读 SELECT。

我会对过度拟合保持谨慎，很难说这些查询计划在更大规模以及更接近现实的 OLTP 工作负载下，是否真的比 Postgres 的启发式方法更优。

无论如何，基于配置文件的优化就是这样。我们很多人都清楚数据库工作负载会随着时间和规模而变化。

感谢作者亲自动手实践并分享出来。

Nvidia announces native GPU programming in Rust #

https://news.ycombinator.com/item?id=49733918

The launch is checked rather than trusted.

Damn even Nvidia is putting out fully Claude-written articles.

claiir

发布是经过检查的，而不是被信任的。

天哪，连英伟达都在发布完全由Claude撰写的文章。

Nvidia announces native GPU programming in Rust #

https://news.ycombinator.com/item?id=49734586

I strongly dislike CUDA. Once you have allowed that proprietary cr*p

Genuine question…why not just type “crap”? It’s not even that much of a curse, but I’ve never really understood the point of self-censorship. If you don’t want to curse then you could just use a non-curse word.

tombert

我强烈不喜欢CUDA。一旦你允许了那个专有的垃圾玩意儿

真心提问……为什么不直接打“crap”呢？这甚至算不上什么脏话，但我一直不太理解自我审查的意义。如果你不想骂人，那直接用个不骂人的词不就好了。

Nvidia announces native GPU programming in Rust #

https://news.ycombinator.com/item?id=49734146

I strongly dislike CUDA. Once you have allowed that proprietary cr*p into your C++ codebase, it is very hard to get rid, and you end up with code that is either tied to a single vendor or an #ifdef hell, probably both.

The best way to program GPUs is face up to the reality that they are not the same machine as the CPU, write your kernels in separate files, and launch them manually, like in Metal, OpenCL, and D3D12, etc. These days we even have DSLs like Triton that make kernel writing much more ergonomic than anything you would hope to achieve in Rust.

jacobgorm

我非常讨厌CUDA。一旦你允许那种专有的鬼东西进入你的C++代码库，就很难摆脱它，最终你会得到要么绑定单一厂商、要么陷入#ifdef地狱的代码，很可能两者兼有。

编写GPU程序最好的方式是直面现实：GPU和CPU不是同一台机器，把你的内核写在单独的文件里，然后手动启动它们，就像Metal、OpenCL和D3D12那样。如今我们甚至还有像Triton这样的DSL，让编写内核比你在Rust里希望能实现的任何方式都更加符合人体工学。

The Google Play app review process now regularly t… #

https://news.ycombinator.com/item?id=49726755

I’m partly to blame. I accidentally ran an illegal unregulated money transference service over Google Play.

It let users cash out their Google Play Credits for real cash, which I automatically wired them.

Someone then hacked in to a major bookstore chain, stole piles of Google Play Gift cards, activated them using their access, and used my app to get cash for them.

Luckily, the whole thing blew up on me before I got in serious trouble, rightfully so, and the app was removed by Google, then an investigation followed. A ton of copycat apps popped up immediately after, then a few months months later Google announced their app review process.

davidmurdoch

我也有责任。我不小心在Google Play上运行了一个非法且不受监管的资金转账服务。

它让用户把Google Play余额兑换成现金，我会自动给他们汇款。

然后有人入侵了一家大型连锁书店，偷走了一大堆Google Play礼品卡，利用他们的权限激活这些卡，再用我的应用套现。

幸运的是，整件事在我惹上大麻烦之前就曝光了，这是罪有应得，应用被Google下架了，随后还进行了调查。紧接着冒出了一大堆山寨应用，几个月后Google就宣布了他们的应用审核流程。

Nvidia announces native GPU programming in Rust #

https://news.ycombinator.com/item?id=49735639

It doesn’t read as emphasis to me. It reads like the person is trying hard not to curse, and they think “crap” is a curse word. It’s a little bit adorable, like I’m reading a comment from an obedient child.

josephg

对我来说，这读起来不像是在强调。更像是这个人拼命忍着不骂脏话，而且ta觉得"crap"就是个脏话。有点可爱，就像在看一个听话的小孩写的评论。

Nvidia announces native GPU programming in Rust #

https://news.ycombinator.com/item?id=49734293

That’s actually a magnificent observation. This is not only an indication of a keen eye, but a trained brilliant mind as well.

bayindirh

这实际上是一个绝妙的观察。这不仅表明目光敏锐，还体现了训练有素的出色头脑。

AWS says it can’t restore some data from mideast f… #

https://news.ycombinator.com/item?id=49733667

Hi, I’m from the future. You might want to consider storing the data somewhere besides an Azure datacenter in the UAE.

jackb4040

你好，我来自未来。你可能需要考虑将数据存储到阿联酋的Azure数据中心之外的地方。

Salesforce Global Outage #

https://news.ycombinator.com/item?id=49725742

Have you tried turning it off and then on again?

We’re no longer pursuing restarts as a path to remediation.

Oh you have

raffraffraff

你试过关掉再重新打开吗？

我们不再将重启作为修复途径。

哦，你试过啊。

Anecdotally, programmers dislike “reduce” #

https://news.ycombinator.com/item?id=49731007

Related to the point about worse performance, I’m pretty sure I was there when reduce was “banished” from Python 3 – demoted to functools.reduce(), instead of the builtin reduce() in Python 2

The story is that sometime in 2006 or 2007, Guido van Rossum was debugging why a web page in Google’s internal code review tool (which he wrote) was taking 30+ seconds to render.

This is basically a “production” incident, since thousands of Google engineers relied on the tool. Requests like this were probably tying up threads and exhausting thread pools, perhaps

Eventually it was tracked down to a line wrapping algorithm written with reduce(). I don’t think he wrote it – it may have come in through a dependency. As many know, reduce() is basically:

s1 + s2
s1 + s2 + s3
s1 + s2 + s3 + s4 
...

And that’s O(n^2) when s_i are strings. And I think it showed up if you viewed a 5000+ line diff, or a 5000+ line file. (Newer programs like Github also suffer here)

I believe, in Python at that time, += was already optimized to avoid this (just like essentially all JS VMs are). Or you can use the idiom of append() to list and join() after.

But reduce() basically forces the inefficient implementation, and I’m sure this is still true in Python 3.

So basically Guido spent a long time debugging a performance problem related to reduce(), and made the decision to eject it, to help users avoid “footguns”. I was his officemate at the time, so I recall this, but I wasn’t involved directly

Also, somebody contributed reduce() to Python way back in the 90’s, as well as other functional idioms. He wouldn’t have added that himself – it was never his preferred style.

He preferred a more imperative style. But he allowed those contributions, and then slightly regretted it later.

https://docs.python.org/3/library/functools.html#functools.reduce

chubot

关于性能变差的那一点，我相当确定当时我就在场，那时 reduce 被“驱逐”出 Python 3——降级为 functools.reduce()，而不是 Python 2 中的内置函数 reduce()。

事情是这样的：大概在 2006 年或 2007 年的某个时候，Guido van Rossum 在调试为什么谷歌内部代码审查工具（他写的）中的一个网页渲染需要 30 多秒。

这基本上算是一次“生产”事故，因为成千上万的谷歌工程师都依赖这个工具。像这样的请求可能占用了线程，甚至耗尽了线程池，也许吧。

最终，问题被定位到一个用 reduce() 编写的换行算法上。我觉得不是他写的——可能是通过某个依赖引入的。正如许多人所知，reduce() 基本上就是：

s1 + s2
s1 + s2 + s3
s1 + s2 + s3 + s4 
...

当 s_i 是字符串时，这就是 O(n^2) 的复杂度。而且我认为，当你查看一个 5000 行以上的 diff，或者一个 5000 行以上的文件时，这个问题就会显现出来。（像 Github 这样的新程序也有这个问题）

我相信，在当时的 Python 中，+= 已经被优化以避免这种情况（就像现在几乎所有 JS 虚拟机一样）。或者你可以使用 append() 到列表然后 join() 的惯用法。

但 reduce() 基本上强制了这种低效的实现，我确信在 Python 3 中仍然如此。

所以基本上，Guido 花了很长时间调试一个与 reduce() 相关的性能问题，然后决定把它剔除掉，以帮助用户避免“脚枪”。我当时是他的办公室同事，所以我记得这件事，但我并没有直接参与。

另外，早在 90 年代，有人向 Python 贡献了 reduce()，以及其他函数式惯用法。他自己是不会添加这些的——那从来不是他偏好的风格。

他更偏好命令式风格。但他允许了这些贡献，后来有点后悔。

Hackers Got Inside a Flock Camera #

https://news.ycombinator.com/item?id=49727461

Title is missing “(YC S17)” after “Flock”.

deaux

标题在“Flock”后面缺少了“(YC S17)”。

The Google Play app review process now regularly t… #

https://news.ycombinator.com/item?id=49726697

With Signal, the biggest issue we have is that review times are extremely inconsistent. Sometimes it’s 4 hours, sometimes it’s 5 days, and there’s no visibility as to why. Our working theory is that there’s automated and manual queues, and occasionally, for whatever reason, we fall into the manual queue. But when you work on an app that has weekly updates, randomly getting hit with a review time of several days really throws off your groove. And it can obviously be terrible for moments where you’re fixing a critical issue.

greysonp

使用Signal时，我们遇到的最大问题是审核时间极不稳定。有时是4小时，有时是5天，而且完全看不到原因。我们的推测是存在自动和人工审核队列，偶尔由于某种原因我们会落入人工队列。但当你运营一个每周更新的应用时，突然遇到几天审核时间真的很打乱节奏。而且在你修复关键问题时，这显然会非常糟糕。

Introducing System One Models and Jev #

https://news.ycombinator.com/item?id=49720537

if it puts a high confidence value on a wrong answer, thats still hallucinating, no?

llm hallucinations are high probability tokens that are incorrect vs the real world

8note

如果它对一个错误答案给出了高置信度，那仍然是幻觉，不是吗？

LLM的幻觉就是那些高概率的token，但它们与现实不符。

PS5 Linux lead quits: “a bunch of noobs using LLMs… #

https://news.ycombinator.com/item?id=49728413

Hobby groups projects like this are less fun for a lot of people who used to enjoy interacting with smart people.

Same thing did happen to many work places. People at all levels proxy questions through LLMs and don’t even bother to read/trim/edit the response.

Funny, how suddenly a tight, 1-2 sentence response on point is a sign of skill.

aeonflux

像这样的业余爱好小组项目，对很多曾经喜欢与聪明人交流的人来说，乐趣变少了。同样的事情也发生在许多工作场所。各个层级的人都通过大语言模型来代问问题，甚至懒得去阅读、删减或编辑回复。有趣的是，突然之间，一个简洁的、一两句话切中要点的回复就成了技能的标志。