2025 07 17 HackerNews

2025-07-17 Hacker News Top Stories #

Linux 在美国桌面市场份额首次突破 5%，主要得益于 Windows 的问题、Steam Deck 的流行以及 Linux 的改进。

乌克兰黑客与军事情报合作，成功摧毁了俄罗斯无人机制造商 Gaskar Integration 的 IT 基础设施，导致其生产和运营中断。

Cloudflare 的 1.1.1.1 公共 DNS 解析器因配置错误导致全球中断，影响持续 62 分钟，非攻击或 BGP 劫持所致。

通过在脑海中进行小规模的逻辑证明，可以帮助程序员编写更高效、更准确的代码，减少调试时间。

Mozilla 的 Firefox 141 版本在 Windows 上支持 WebGPU，提升网页应用的图形处理性能，计划扩展至其他平台。

Helix 编辑器 25.07 版本发布，新增文件浏览器、LSP 文档颜色和命令模式新功能，共有 195 位贡献者参与开发。

Mozilla 启动征集用户意见活动，邀请用户参与 Firefox 的未来发展方向讨论，并举办社区 AMA 活动。

作者分享了转向使用 Python 的经历，认为其语法简洁且生态系统完善，适合构建 AI 应用。

Tilck 是一个小型的 Linux 兼容内核，支持 i686 和 RISCV64 架构，适合内核模式实验和教育用途。

GPUHammer 研究展示了 GPU 内存的 Rowhammer 攻击是实际可行的，可能篡改共享环境中其他用户的数据。

https://ostechnix.com/linux-reaches-5-desktop-market-share-in-usa/

Linux 在美国桌面市场份额达到 5%

Linux 在美国的桌面市场份额首次正式突破 5% 的大关，这是开源领域和 Linux 社区的一个重要里程碑。许多人可能认为 Linux 是一个小众选择，但新的数据显示，一个重大的转变正在发生。

市场份额数据：Linux 在美国达到 5.03%

根据 StatCounter 全球统计数据，截至 2025 年 6 月，Linux 在美国桌面操作系统市场份额为 5.03%。这一数据与去年同期相比，Windows 市场份额下降了近 13%，而 Linux 的增长显著。在美国桌面市场，Windows 仍以 63.2% 的市场份额占据主导地位，OS X 和 macOS 合计市场份额约为 24%，Linux 市场份额为 5.03%，未知类别为 4.76%，Chrome OS 为 2.71%。

为什么越来越多的人转向 Linux？

Linux 市场份额的增长并非偶然，有几个明显的原因导致 Linux 越来越受欢迎：

Windows 的问题：许多用户对微软的做法感到厌烦，Windows 10 的生命周期即将结束，人们在寻找替代品，而不是仅仅为了 Windows 11 升级硬件。对隐私侵犯、广告软件和强制更新的担忧也在推动用户远离 Windows。
游戏的新领域：Steam Deck 游戏设备基于 Linux 系统，为 Linux 带来了一群新的游戏玩家，他们享受 Linux 的强大和灵活性。
Linux 自身的发展：Linux 变得更加用户友好，Ubuntu 和 Linux Mint 等发行版在界面上做出了重大改进。隐私是许多人的首要考虑，Linux 提供了一个优秀的开源替代方案。Linux 可以让旧硬件焕发新生，延长电脑的使用寿命。软件生态系统不断壮大，Wine 等工具提高了对许多流行应用程序的兼容性。

Linux 市场份额可能更高

虽然 5.03% 的市场份额令人兴奋，但实际的 Linux 用户数量可能更高。许多注重隐私的 Linux 用户使用可以隐藏操作系统或更改用户代理的工具，这可能导致一些 Linux 用户被误识别。此外，“未知”类别可能包括一部分低调运行的 Linux 系统。Chrome OS 虽然单独列出，但实际上是基于 Linux 内核的开源 ChromiumOS。如果将 Linux 和 Chrome OS 的市场份额合并，Linux 家族的市场份额将达到 7.74%。

更多用户转向 Linux

5% 的市场份额不仅仅是一个值得夸耀的成就，它标志着对替代操作系统的兴趣日益增长。这表明桌面用户对开源解决方案的需求正在增加。这种增长的可见性可能会为 Linux 社区带来“雪球效应”。随着越来越多的人采用 Linux，更多的热情用户和熟练的开发人员被吸引进来，为 Linux 的持续改进做出贡献，使生态系统更加强大。

展望未来

Linux 的发展历程一直是缓慢而稳定的，近年来加速发展。从 1% 增长到 2% 用了八年时间，从 2% 增长到 3% 用了 2.2 年，从 3% 增长到 4% 只用了 0.7 年。现在，Linux 在美国的市场份额已经超过 5%，这种指数级增长表明我们正处于一个有希望的上升趋势中。这是一个令人兴奋的 Linux 时代，作者相信最好的还在后头。

HN 热度 885 points | 评论 521 comments | 作者：marcodiego | 13 hours ago #

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

Linux 桌面市场份额增长可能是由于人们不再使用传统电脑，转向手机和平板
由于 Steam Deck 的流行，Linux 桌面市场份额有所上升，但微软优化 Windows 游戏可能会影响这一趋势
Steam Deck 运行的是 Linux 桌面环境，与 Android 不同
Android 系统并不真正运行 Linux 内核，而是有大量补丁代码
尽管 Android 和桌面 Linux 在内核层面有所不同，但它们共享 Linux 内核
可以通过 Termux 在 Android 上运行典型的 Linux 软件
Waydroid 允许在 GNU/Linux 手机上运行 Android 软件
从用户角度来看，虚拟容器的轻重并不重要
即使 Android 和桌面 Linux 在内核层面共享，它们在用户空间层面是不兼容的
共享 Linux 内核在实际中具有重要意义，比如 Android 开发对内核的改进可能惠及标准 Linux 发行版
编译主线 Linux 内核让人意识到内核的作用远超过人们的想象
将 Android 和桌面 Linux 分开统计是出于方便，而非技术原因
讨论 Linux 市场份额时，关注的是内核的使用情况，这取决于具体关注点
Windows 子系统 for Linux（WSL）是否计入 Linux 市场份额取决于评估的目的

Ukrainian hackers destroyed the IT infrastructure of Russian drone manufacturer #

https://prm.ua/en/ukrainian-hackers-destroyed-the-it-infrastructure-of-a-russian-drone-manufacturer-what-is-known/

乌克兰黑客破坏了俄罗斯无人机制造商的 IT 基础设施：已知情况

2025 年 7 月 15 日 15 时 53 分，乌克兰黑客与军事情报部门合作，成功瘫痪了俄罗斯最大的无人机制造商之一——Gaskar Integration 的活动。这次攻击摧毁了超过 47TB 的关键数据，封锁了内部系统，并有效地停止了工厂的运营。

据“Pryamiy”引用军事情报来源报道，黑客团队 BO Team 和乌克兰网络联盟小组，在军事情报专家的情报支持下，成功攻击了俄罗斯军队无人机主要供应商之一——Gaskar Integration 公司的网络和服务器基础设施。

参与攻击的黑客团队“BO Team”的消息正在 Telegram 上的网络活动社区传播。

乌克兰网络犯罪分子获得了超过 47TB 的有关俄罗斯无人机生产的技术信息。包括显示俄罗斯无人机制造商与中国密切合作的数据。制造商服务器上的所有信息已被销毁，包括 10TB 的备份材料。

由于网络攻击，企业的互联网、生产和会计程序无法工作，Gaskar 公司的研发中心工作陷入瘫痪。此外，无人机生产厂的所有门都被封锁，员工被迫使用消防出口。

被盗数据中包括公司员工的保密问卷，最重要的是，有关无人机生产的完整技术文件，已移交给乌克兰国防军的相关专家。

我们提醒您，乌克兰国防部主要情报局的网络专家曾关闭了俄罗斯铁路的网站，进行了强有力的攻击。

此前，GUR 网络专家攻击了俄罗斯 Regiontransservice 并关闭了所有服务。

HN 热度 589 points | 评论 401 comments | 作者：doener | 15 hours ago #

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

重建整个基础设施是一个巨大的任务，尤其是当它由多人多年管理时。
从零开始恢复基础设施非常困难，尤其是当涉及到需要回忆为什么某些设置是这样的。
即使有文档和测试，实际情况也可能非常复杂。
个人实验室在遭遇设备被警方扣押后，依靠备份和旧硬件迅速恢复运行。
警方在没有充分证据的情况下进行搜查和扣押，给当事人带来巨大困扰。
警方的搜查和扣押行为可能对个人生活造成长期影响，甚至导致心理创伤。
警方的行为可能导致人们对警察和刑事司法系统失去信任。
即使最终归还了扣押的物品，当事人也可能因为长时间的等待和不确定性而感到愤怒和无助。

Cloudflare 1.1.1.1 Incident on July 14, 2025 #

https://blog.cloudflare.com/cloudflare-1-1-1-1-incident-on-july-14-2025/

2025 年 7 月 14 日，Cloudflare 对其服务拓扑进行了更改，导致 1.1.1.1 服务在边缘出现中断，使用 1.1.1.1 公共 DNS 解析器的客户出现了 62 分钟的停机时间，同时 Gateway DNS 服务也出现了间歇性的服务降级。Cloudflare 的 1.1.1.1 解析器服务从 21:52 UTC 开始无法访问互联网，并在 22:54 UTC 结束，全球大多数 1.1.1.1 用户受到影响。对于许多用户来说，无法使用 1.1.1.1 解析器解析域名意味着几乎所有互联网服务都无法使用。这次中断可以在 Cloudflare Radar 上观察到。

这次中断是由于用于维护 Cloudflare IP 地址广告到互联网的遗留系统的配置错误所导致的。这是一次全球性的中断。在中断期间，Cloudflare 的 1.1.1.1 解析器在全球范围内都无法使用。Cloudflare 对此次中断表示非常抱歉。根本原因是内部配置错误，而不是攻击或 BGP 劫持的结果。在这篇博客中，我们将讨论失败的原因、为什么会发生，以及我们正在采取哪些措施以确保这种情况不再发生。

背景： Cloudflare 在 2018 年推出了 1.1.1.1 公共 DNS 解析器服务。自宣布以来，1.1.1.1 已成为最受欢迎的 DNS 解析器 IP 地址之一，任何人都可以免费使用。Cloudflare 的几乎所有服务都是通过一种称为任播的路由方法提供给互联网的，这是一种旨在允许流行服务在互联网的许多不同位置提供服务，以增加容量和性能的众所周知的技术。这是确保我们能够全球管理我们的流量的最佳方式，但同时也意味着，如果广告这个地址空间出现问题，可能会导致全球性的中断。

Cloudflare 向互联网宣布这些任播路由，以便将流量发送到这些地址并由 Cloudflare 数据中心提供服务。大多数 Cloudflare 服务都是全球提供的，如 1.1.1.1 公共 DNS 解析器，但有一部分服务特别限制在特定区域。这些服务是我们的数据本地化套件（DLS）的一部分，它允许客户以多种方式配置 Cloudflare 以满足他们在不同国家和地区的合规需求。Cloudflare 管理这些不同需求的一种方式是确保正确的服务 IP 地址只在需要的地方可以被互联网访问，以便您的流量可以在全球范围内正确处理。特定服务有一个匹配的“服务拓扑”，即，服务的流量应该只路由到特定一组位置。

事件时间线：

2025 年 6 月 6 日 17:38：问题引入，无影响。为尚未投入生产的 DLS 服务进行了配置更改。这个配置更改不小心包含了对 1.1.1.1 解析器服务的引用，以及与 1.1.1.1 解析器服务相关的前缀。
2025 年 7 月 14 日 21:48：影响开始。对同一 DLS 服务进行了配置更改。更改将一个测试位置附加到非生产服务；这个位置本身不活跃，但更改触发了全球网络配置的刷新。
2025 年 7 月 14 日 21:52：全球 DNS 流量开始下降至 1.1.1.1 解析器服务。
2025 年 7 月 14 日 21:54：相关非因果事件：BGP 起源劫持 1.1.1.0/24 由于 Cloudflare 撤回路由而暴露。这不是服务故障的原因，而是一个不相关的问题，因为该前缀被 Cloudflare 撤回而突然变得可见。
2025 年 7 月 14 日 22:01：影响被检测到。内部服务健康警报开始对 1.1.1.1 解析器发出。
2025 年 7 月 14 日 22:01：事件被宣布。
2025 年 7 月 14 日 22:20：修复部署。开始执行还原以恢复先前的配置。为了加速服务的完全恢复，在测试位置验证手动触发的操作，然后执行。
2025 年 7 月 14 日 22:54：影响结束。解析器警报清除，DNS 流量在解析器前缀上恢复正常水平。
2025 年 7 月 14 日 22:55：事件解决。

影响：任何通过这些 IP 地址的 1.1.1.1 解析器服务发送到 Cloudflare 的流量都受到了影响。这些地址的相应路由也受到了影响。

技术错误描述及发生方式： 1.1.1.1 解析器服务的失败：如上所述，6 月 6 日的配置更改在预生产 DLS 服务的服务拓扑中引入了一个错误。7 月 14 日，对该服务进行了第二次更改：一个离线数据中心位置被添加到服务中…

HN 热度 527 points | 评论 352 comments | 作者：nomaxx117 | 20 hours ago #

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

许多用户由于无法使用 1.1.1.1 解析器解析域名，导致所有互联网服务都无法使用。
如果 DNS 服务器列表上有两个 DNS 服务器，那么第二个服务器是否也宕机了，如果没有，为什么没有切换到第二个服务器。
1.1.1.1 的问题在于使用了任播技术而不是 DNS 本身。
Cloudflare 推荐用户配置 1.1.1.1 和 1.0.0.1 作为 DNS 服务器，但这次事故导致 Cloudflare 对这两个 IP 段的 BGP 广告失效。
建议使用 Cloudflare 作为其中一个 DNS 服务器，另一个使用完全不同的公司。
在公共 Wi-Fi 网络中手动设置 DNS 服务时，需要频繁地禁用和启用，非常麻烦。
DNS 只是一个查找服务，可以进行过滤，但最终是“真实来源”。
在 Android 设置中，只能提供一个私有 DNS 提供商的主机名，不能直接提供 IP 地址。
Android 的私有 DNS 指的是’DNS over HTTPS'，通常只接受主机名。
Android 11 及更新版本支持 DoH 和 DoT。
DoH（DNS-over-HTTPS）流量相对稳定，因为大多数 DoH 用户使用域名 cloudflare-dns.com 来访问公共 DNS 解析器。
DoH 主机可以解析到多个 IP 地址，甚至为不同客户端解析到不同的 IP 地址。
许多客户端不支持跨组织机构的 DoH 备用服务器，但普通 DNS 可以。
一些设备/路由器没有主备 DNS 服务器，而是随机轮询它们，这意味着用户一半时间使用 Cloudflare，另一半时间使用 Google DNS。

To be a better programmer, write little proofs in your head #

https://the-nerve-blog.ghost.io/to-be-a-better-programmer-write-little-proofs-in-your-head/

这篇文章是由 Matthew Prast 在 2025 年 7 月 14 日撰写的，主题是如何通过在脑海中进行小规模的证明来成为一名更好的程序员。文章提出了一个简单的概念：在编程过程中，通过在脑海中构建证明，来确保代码能够按照预期工作。这种方法虽然听起来简单，但在不打断编程流程的情况下进行实践需要大量的练习。一旦熟练掌握，你会发现代码在第一次或第二次尝试时就能正常工作，这感觉有点像魔法。

文章中提到了几种在编程中进行推理的方法：

单调性（Monotonicity）：在数学中，单调函数是指不会“倒退”的函数，即单调递增函数只能增加或保持不变，而单调递减函数只能减少或保持不变。在编程中，单调性的概念更加模糊，但它捕捉了只能朝一个方向进行的过程的思想。例如，检查点（checkpointing）就是一个单调性的例子。如果你有一个需要按顺序执行多个任务的脚本，你可以在磁盘上保留一些状态信息，以记录你已经完成了多少任务。如果脚本崩溃，它可以检查磁盘上的状态，然后从最早的未执行状态重新开始。检查点意味着脚本中的“当前步骤”指针只能向前移动，因为脚本不能倒退并重新执行已经完成的步骤。在这种意义上，脚本是单调递进的，如果脚本最终成功完成，它将恰好执行每个步骤一次。
预条件和后条件（Pre- and post-conditions）：预条件和后条件是指定函数行为约束的方法。函数的预条件是在函数运行之前假定为真的条件，这些可以是关于函数输入的条件，或者是关于程序状态或环境的更一般性的声明。函数的后条件是在函数返回后假定为真的条件。如果函数的预条件在函数运行前为真，而后条件在函数完成后不为真，那么函数就没有正确实现，至少根据指定的约束条件来看是这样。这些概念很简单（甚至显而易见），它们本身并不是证明技术，但仅仅在形式上跟踪它们可以帮助你的推理。
不变量（Invariants）：代码的不变量是在代码运行之前、期间和之后始终为真的条件，无论发生什么。与预条件和后条件一样，不变量可以涉及几乎任何事情。以不变量的形式思考一致性很有用——在这些情况下，不变量是“这个数据结构是一致/有效的”，你需要向自己证明代码在任何情况下都保持这个不变量。一个简单的方法是将代码分解成原子的“步骤”，并证明每个步骤单独保持不变量。然后你可以得出结论，无论哪些步骤运行或它们运行的顺序如何，不变量都将保持。最著名的不变量之一是会计方程，它是复式记账的基础。会计方程大致上说，公司账簿上的借方总额必须等于贷方总额。很容易证明，如果复式记账做得正确，它将保持这个不变量：对于每一笔交易，所有贷方账户的增加（或减少）必须等于所有借方账户的增加（或减少）。很容易看出，如果借方和贷方在交易前平衡，那么交易后它们也将平衡。因此，不变量始终被保持。
隔离（Isolation）：作者坚信，软件的“工艺”（或应该是）以不破坏任何东西为中心，对现有系统进行修改或增强。在对代码库进行修改时，知道如何证明你无意改变的行为实际上没有改变是非常有用的。

文章强调，通过在编程过程中进行这些推理，可以帮助程序员写出更快、更准确的代码。

HN 热度 433 points | 评论 161 comments | 作者：mprast | 1 day ago #

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

二分查找及其变体左端点和右端点二分查找很难正确编码，需要考虑循环不变性。
90% 的专业程序员实现普通二分查找时会出错，最常见的是不小心进入无限循环。
循环不变性是不需要 DSL 就能从形式方法中获得最大收益的方式。
二分查找中最常见的错误是计算中间点时的整数溢出问题。
Python 的内置 int 类型具有任意精度，因此避免溢出的计算公式在 Python 中不必要。
在 C 语言中，整数溢出仍然是问题，因为 int 类型不适合用作索引。
使用二分查找作为面试题，发现大多数高资质的候选人无法在 20 分钟内写出无 bug 的实现。
许多人因为教学接口不当而写不出正确的二分查找。
Python 的闭左开右语法避免了包含性边界问题。
许多切片方法都遵循 Python 的这种语法，JavaScript、Java 和 Golang 的切片语法也类似。
将二分查找作为面试题可能不是一个好选择，因为它可能只是筛选出练习过 leetcode 的人。
面试中更重要的是考察候选人解决问题的方法，而不仅仅是能否立即解决问题。

Shipping WebGPU on Windows in Firefox 141 #

https://mozillagfx.wordpress.com/2025/07/15/shipping-webgpu-on-windows-in-firefox-141/

Mozilla Gfx Team Blog 发布了一篇新文章，宣布在 Firefox 141 版本中，Windows 用户将能够体验到 WebGPU 的功能。WebGPU 是一个现代的图形处理接口，能够让用户在网页上进行高性能的计算和渲染，这对于提升网页游戏、可视化和本地计算的性能至关重要。Mozilla 对 WebGPU 的到来感到兴奋，并相信它将极大地提高网页应用的性能上限。

文章中提到，用户可以在 webgpufundamentals.org 找到 WebGPU 的教程，尝试 WebGPU 示例，并在 MDN 上阅读 API 文档。WebGPU 基于两个 W3C 标准：WebGPU 和 WGSL，Mozilla 自 2017 年以来一直参与这些标准的发展。

WebGPU 自 2023 年起已在 Google Chrome 上可用，并预计在今年秋天将在 Safari 26 上推出。尽管 Firefox 141 只在 Windows 上启用 WebGPU，但 Mozilla 计划在未来几个月内将其扩展到 Mac 和 Linux 平台，最终也将支持 Android。Windows 是首要平台，因为大多数用户都在这里，但 Mozilla 也期待在其他平台上启用 WebGPU。

Firefox 的 WebGPU 实现基于 WGPU，这是一个 Rust 库，提供了一个统一的、可移植的接口，用于访问底层平台的低级图形 API，包括 Direct3D 12、Metal 和 Vulkan。WGPU 是一个独立的开源项目，Mozilla 是其主要贡献者之一。如果你是一个对 Firefox 的 WebGPU 支持感兴趣的 Rust 开发者，WGPU 是一个很好的起点。

WebGPU 是一个庞大且复杂的 API。Mozilla 目前的工作重点是确保高可见度的 WebGPU 应用和演示能够流畅运行，并且相信在 Firefox 141 中应该能够很好地满足许多用例。然而，为了提高性能和符合规范，还有很多工作要做。例如，Firefox 使用无缓冲的进程间通信来传递网页内容对 GPU 沙箱进程的请求，这带来了显著的开销。这个问题在 Bug 1968122 中得到了解决，并将在 Firefox 142 中出现。Firefox 目前使用间隔计时器来告知 GPU 何时完成任务，这给许多快速完成任务的应用带来了显著的延迟。Mozilla 正在改进这一点，并在 Bug 1870699 中跟踪进展。Firefox 还不支持 WebGPU 的 importExternalTexture 方法，该方法允许 GPU 直接从解码器读取解压缩的视频内容。你可以在 Bug 1827116 中跟踪进展。

文章最后鼓励用户在 Firefox 中尝试 WebGPU，并在遇到问题时在 Bugzilla 的 WebGPU 组件中报告。Mozilla 期待看到用户在 Firefox 中使用 WebGPU 能够创造出什么。

HN 热度 336 points | 评论 137 comments | 作者：Bogdanp | 17 hours ago #

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

Firefox 团队在 Windows 上实现 WebGPU 功能令人兴奋
有公司正在将 Unreal 引擎带到浏览器，并为 Unreal Engine 5 构建了定制的 WebGPU RHI
提供了技术演示链接，但目前只能在基于 Chromium 的浏览器和部分 Android 手机上工作
有用户在 Android Chrome 和 Linux Firefox 上遇到加载问题
Linux 上尚未支持 WebGPU，这可能是加载问题的原因
有用户询问是否会有 Firefox 兼容版本，以及在 Windows 上的 Firefox 141 中是否能工作
有用户提到在 macOS 的 Chrome 和 Safari 中也遇到了加载问题
有用户分享了一个替代链接，该链接在 Chromium 上可以较快加载
有用户认为现代图形 API 的使用体验不如 OpenGL 时代，需要重新创建自定义包装器以适应不同平台
有用户认为图形 API 的目标是尽可能快地将代码和数据送入 GPU，而不是易用性
有用户认为 WebGPU 是浏览器中计算和渲染的不错包装器，比 WebGL 更易发现和直观
有用户认为每个新的主要 D3D 版本都在提高易用性，而 Metal 在易用性和低开销之间取得了平衡
有用户认为 OpenGL 自 1990 年代末以来易用性一直在下降，Vulkan 不幸地延续了这一趋势
有用户认为 WebGPU 相对于 WebGL 在开发者体验上有所改进
有用户认为 WebGPU 技术相对于现代图形标准来说已经过时，并且不够直观
有用户认为 WebGPU 在渲染高质量线条或点方面并不是优先考虑的，需要用户自己去学习 SDFs 和 Beziers 等技术

Helix Editor 25.07 #

https://helix-editor.com/news/release-25-07-highlights/

Helix 25.07 版本更新亮点 2025 年 7 月 15 日备受期待的 Helix 25.07 版本终于发布。这个版本对 Helix 的核心组件进行了重大替换，并增加了许多引人注目的新功能。共有 195 位贡献者参与了此次版本的变化。感谢所有使这个版本成为可能的人。如果你是 Helix 的新手，Helix 是一个支持多选、语言服务器协议（LSP）、tree-sitter 以及实验性支持调试适配器协议（DAP）的模态文本编辑器。

新功能介绍文件浏览器 25.07 版本在e 下增加了文件浏览器。文件浏览器是一个选择器，类似于 Helix 中的望远镜式 UI 组件。与其他选择器一样，你可以在选项中进行模糊搜索。按 Enter 选择一个目录会在该目录下打开一个新的文件浏览器，选择一个文件则打开该文件。这对于以层次结构查看目录非常有用。相比之下，常规的文件浏览器（f）会打开一个包含目录内容的递归选择器。对于庞大的项目，文件浏览器可以是一个更精确的工具。

LSP 文档颜色语言服务器协议（LSP）规范中一个引人注目的功能是文档颜色请求。这个请求允许客户端（Helix）询问语言服务器（如 tailwindcss-language-server 或 vscode-css-language-server）文档中的哪些范围对应于 RGB 颜色。在 25.07 版本中，Helix 现在可以从语言服务器请求文档颜色，并在行内显示颜色样本（一个小框）。这与 LSP 内联提示功能完全相同——显示类型——但适用于颜色。

命令模式新功能命令模式（:）用于执行可输入的命令。例如，:write 是一个可输入的命令，它接受一个可选参数。:quit 也是一个可输入的命令，它不接受任何参数。命令模式的语法是微妙的。它应该简单，以便像:write path/to/doc.md 这样的常见操作易于输入。但它也需要工具来转义空格，如在:write ‘a b.txt’中。对于某些命令，拥有自定义或可扩展的语法是有用的，如:run-shell-command < 复杂的 shell 特定命令 >。 25.07 版本包括用于解析和表示参数以及为命令行提供补全的所有代码的完整重写。这修复了一些解析和补全的问题，比如尝试补全带有空格的文件名，引入了两个新功能：标志和扩展。

标志标志的工作方式与你在 shell 命令中传递的标志相同。它们旨在涵盖你想要以轻微修改的行为执行命令的情况。到目前为止，标志仅用于一小部分命令：:write 系列命令（任何以:write 开头的命令）和:sort。 25.07 版本移除了:rsort 命令，并用:sort –reverse 或简称:sort -r 替换。:write 命令现在都接受一个–no-format 标志。通常，如果当前文档配置为自动格式化，你希望格式化当前文档，但有时将文件原样写入是有用的。这些是标志的绝佳用例：你不应该需要额外的可输入命令来微调小细节。标志显示在可输入命令的信息框中，长版本（如–reverse）可以自动补全。

扩展扩展引入了一种特殊语法来插值值。这些大多遵循 Kakoune 的扩展概念，有一些小的调整。可以根据当前编辑器状态编写的变量可以写成 %{variable_name}。%{buffer_name}打印当前焦点文档在状态行中显示的名称，%{cursor_line}打印主光标 1 索引行号。可以使用 %sh{..}扩展执行 shell 命令。结合上述变量扩展和新的简单:echo 命令（打印到状态行），像这样的命令在状态行上打印当前行的 git blame： :echo %sh{git blame -L %{cursor_line},+1 %{buffer_name}} 变量名称和扩展类型（如 sh 用于 shell 命令或 u 用于 Unicode）都可以自动补全。

可扩展解析探索重写的初衷是重新审视命令行是如何解析的。在 25.07 版本中的变化之后，命令模式更好地解析和补全文件名，允许标志和扩展，并且还可以在行中切换到其他解析方法。可输入命令:set-option 和:toggle-option 现在使用 serde_json 的流式反序列化器来解析复杂的配置值，如列表。像:run-shell-command 和:pipe 这样的 shell 命令不再在命令名称之后尝试解析命令行。所以你不需要猜测如何逃避 Helix 的解析规则，然后是你的 shell 的解析规则——最终的引号地狱。

Tree-house 在这个版本周期中，我们替换了与 Tree-sitter 交互的 crates，增加了从头开始构建的新 crates，并移除了官方绑定以及 Helix 中的许多旧代码。本文的其余部分将讨论有关 Tree-sitter 和 Tree-house 的详细信息。想要了解更多自 Helix 25.01.1 以来的变化详情？请查看变更日志以获取完整的代码更改集。

Tree-sitter 不熟悉 Tree-sitter？在高层次上，它是一个用于生成和使用快速、容错的解析器的框架。在 grammar.js 文件中，你可以通过语法 DSL 编写解析器规则，然后使用 tree-sitter CLI 工具生成和测试解析器。像编辑器这样的工具随后可以使用你定义的解析器与 Tree-sitter C 库或特定于语言的绑定来解析和操作语法树。你对语法树的用途取决于你的想象力！语言服务器可以使用 Tree-sitter 作为它们的解析器，像 Difftastic 这样的差异工具可以生成语法感知的差异，像 Codebook 这样的语言服务器可以进行语法感知的拼写检查扫描。甚至 GitHub 也使用 tree-sitter 进行代码导航和一些语言的高亮显示。

处理解析树的非常强大的工具是 Tree-sitter 查询。查询是一种模式匹配方式，用于匹配子树并捕获节点以供将来使用。对于编辑器，你可能会使用一个查询，通常称为 highlights.scm，来捕获一个树节点，如 Rust 关键字，以便根据当前主题高亮显示节点的文本。像语法树一样，查询的应用只受你的想象力限制。我们目前在 Helix 中使用查询进行高亮显示、缩进和文本对象（识别函数、参数等）。将来，代码折叠、拼写检查和代码导航也可以使用 tree-sitter 查询。

Helix 中的 History Helix 甚至在最初的公开发布之前就依赖 Tree-sitter 进行语法高亮，通过官方的 Rust 绑定到 C 库，即 tree-sitter crate。tree-sitter crate 包装了 C 库，并且相当低级。我们还需要一个高亮器，由一个单独的 crate 提供：tree-sitter-highlight。 tree-sitter-highlight 提供了一个语法高亮器，它接受一种语言的查询和要高亮显示的文档文本，并可以迭代以产生高亮显示事件。Helix 可以在渲染可查看文档时消费高亮显示迭代器。这对于 tree-sitter-highlight 和我们的简单用例（如一次性高亮显示文档）来说都是开箱即用的，tree-sitter-highlight 是你需要的全部。 tree-sitter-highlight 的问题在于它不增量工作。创建一个新的高亮显示迭代器意味着完全重新解析文档以及重新分析查询。这是浪费的，因为 Tree-sitter 可以重用查询。此外，Tree-sitter 中的解析可以增量工作：你可以给 Tree-sitter 旧的语法树，它将更快地解析文档的新版本。

HN 热度 316 points | 评论 142 comments | 作者：matrixhelix | 1 day ago #

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

Helix 编辑器功能丰富，无需配置或安装插件即可使用，但与 Vim 的键绑定不同，可能会让习惯 Vim 的用户感到困惑和愤怒。
有用户推荐使用 evil-helix，这是一个引入 Vim 键绑定的 Helix 软分叉，解决了键绑定问题。
一些用户认为，由于在线编辑器和工作站几乎都有 Vim 键绑定，因此他们不愿意放弃这种灵活性。
有观点认为，如果能够在自己的机器上实现更高的生产力，就可以放弃在其他机器上的键绑定灵活性。
有用户认为，大多数插件不会根本改变与文本的交互方式，因此不应该因为插件在其他机器上不可用而放弃使用。
有用户表示，他们可以轻松地在 Helix 和 Vim 之间切换键绑定，并且能够适应 Helix 的逻辑。
有用户提到，Helix 的名词-动词模型与 Vim 的动词-名词模型不同，这可能会让一些用户难以适应。
Helix 缺乏重复编辑的功能，这在 Vim 中是通过 ‘.’ 实现的，这可能会影响编辑效率。
有用户认为，Helix 的编辑模式需要更多关注，这可能会分散对编程任务的注意力。
有用户提到，Helix 不支持 ‘.’ 键，因为它的模型是在执行操作后没有选中任何内容，因此无法推断重复上一次编辑的意图。
有用户通过保存宏来模拟 Helix 中的 ‘.’ 功能。
有用户认为，完全忽略重复键或宏的实用性是有些冒进的。
有用户表示，他们已经从 Vim 转向 Helix，并且更喜欢 Helix，尤其是它的多选和 LSP 支持。
Helix 正在添加 Scheme 语言进行可编程配置，这将允许更多的状态和上下文行为。
有用户因为 Vim 键绑定而阻碍了尝试 Helix 的意愿。

Where’s Firefox going next? #

https://connect.mozilla.org/t5/discussions/where-s-firefox-going-next-you-tell-us/m-p/100698#M39094

这个网页是 Mozilla Connect 论坛上的一个帖子，主题是“Where’s Firefox going next? You tell us.”，由 Mozilla 的员工 jboscacci 发起。帖子的主要内容包括：

新的尝试和用户反馈：Mozilla 正在尝试一种新的快速调查方式，以了解用户的需求和期望，这些反馈将帮助塑造 Firefox 的未来功能，并让用户更直接地与开发团队联系。jboscacci 强调了用户反馈对于 Firefox 发展的重要性，提到了如标签组、垂直标签、配置文件、新标签页壁纸、PWA 和任务栏固定等功能都是基于用户反馈而实现的。
社区 AMA（Ask Me Anything）计划：Mozilla 正在考虑如何与社区互动，并计划举办一个社区 AMA 活动，邀请 Firefox 产品经理参与。帖子邀请用户提出问题，以帮助规划 AMA 活动，并在帖子末尾提出了一个有趣的问题，询问用户哪种动物最能代表他们的 Firefox 浏览风格。
用户 tilwiti 的回复：tilwiti 在帖子中分享了自己的浏览风格，并提出了一些建议和问题。他提到了对分屏功能的需求、对 Android 界面和主题灵活性的期望，以及对 Firefox 浏览器开发的专注。他还提到了自己对 Firefox 的长期支持，并提出了关于 Firefox 团队日常工作、Reddit 反馈、用户研究参与、AI 功能中缺少西里尔语言支持、Orbit 功能改进等问题。
用户 tilwiti 的其他问题：tilwiti 还提到了对用户基数和 YouTube 冻结问题的担忧，以及对 Pocket 和 Fakespot 服务的怀念。他还询问了关于 Mozilla 遥测数据的问题，以及用户对遥测或服务条款变化的反应。
用户 Kvin 的回复：Kvin 感谢 Firefox 团队的开发工作，并提出了对 Firefox 未来发展的三点建议：优化、功能和设计。他强调了 PC 版本的优化的重要性，并提到了对浏览器定期全面改进的需求。

整个帖子的氛围是开放和互动的，鼓励用户参与讨论，分享他们的想法和问题，以帮助 Firefox 团队更好地了解用户需求并改进浏览器。

HN 热度 311 points | 评论 507 comments | 作者：ReadCarlBarks | 1 day ago #

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

Mozilla 的营销/公关趋势将社区成员当作幼儿园儿童对待，这种语气令人分心和反感。
有人支持 Firefox，但对 Mozilla 的社区参与方式感到不满，认为其缺乏真诚。
有人认为 Mozilla 的文章写作质量差，充满了废话和不相关的信息。
有人批评 Mozilla 在安装过程中提供的信息无聊且无用，与 Windows 相比，Firefox 的安装后设置更加繁琐。
有人提到，尽管 Chrome 也有其问题，但至少它通常能够正常工作，而不需要像 Firefox 那样的额外设置。
有人对 Mozilla 使用表情符号和感谢用户的方式感到愤怒，认为这是虚伪的表现。
有人指出，Mozilla 作为一个有使命感的非营利组织，其政治立场是公开的，不应该因为使用表情符号或感谢用户而感到愤怒。
有人强调，他们的主要问题是 Mozilla 的不真诚，而不是他们使用的特定语气。

I’m switching to Python and actually liking it #

https://www.cesarsotovalero.net/blog/i-am-switching-to-python-and-actually-liking-it.html

这篇文章是关于作者转向使用 Python 并真正喜欢它的体验分享。文章发表于 2025 年 7 月 15 日，阅读时间大约 18 分钟。

作者大约 6 个月前开始更多地使用 Python 进行编程，原因是人工智能（AI）的兴起。作者认为 AI 是目前最大的金钱机会所在，而 Python 是 AI 领域的事实上的编程语言。虽然之前作者也用过 Python，但仅限于编写小脚本，例如一个用于从 YouTube 频道抓取视频元数据并将其以 JSON 文件形式输出的脚本，该脚本每周一通过 GitHub Actions 自动运行。作者认为使用 Python 比使用批处理命令更为方便，不仅因为 Python 的语法更人性化，还因为 Python 解释器在所有 Unix 发行版中都有原生集成。

作者提到，直到最近他才开始认真对待 Python，这是在他想要为现实世界构建 AI 应用程序（如 RAG、Agents、GenAI 工具等）之后。他发现 Python 及其周边生态在过去几十年中已经有了很大的改进，例如 Python 拥有一个完整的库和工具生态系统用于数据处理和分析，通过优化的静态编译器如 Cython 变得更快，以及在隐藏其遗留的丑陋（例如__init__、__new__等）方面做得很好，使其语法更加优雅，以适应有良好品味的开发者。

文章中，作者分享了他用于构建 Python 应用程序的工具、库、配置和其他集成方法。他强调，使用 Python 构建“生产就绪”应用程序与通常的 Jupyter 笔记本或基于脚本的工作流程之间存在很大差距。作者偏好使用单体仓库结构（后端和前端）来组织 Python 项目，因为他不喜欢代码分散在多个仓库中，认为这不利于搜索，而且对于单个开发者来说，多个仓库通常是不必要的，他倾向于保持事情尽可能简单，从单一位置进行编译、测试、容器化和部署。

文章中还详细介绍了项目结构，包括 GitHub Actions 工作流程、VSCode 配置、文档、后端 API、数据存储、Jupyter 笔记本、工具脚本、源代码、Docker 配置、Makefile、Python 项目配置文件、README 文件等。作者强调项目应该是自包含的，包括文档、构建/部署基础设施以及其他运行所需的文件。

作者还介绍了他使用的 Python 工具箱，包括 uv 作为 Python 包管理和构建工具，ruff 作为 Python 的快速代码格式化和检查工具，以及 tyty 作为 Python 的类型检查器。作者认为这些工具有助于保持代码库的清洁和可维护性，并帮助他在开发过程中及早发现类型错误。

HN 热度 310 points | 评论 483 comments | 作者：cesarsotovalero | 16 hours ago #

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

使用"if not API_KEY or not CHANNEL_ID:“这样的代码逻辑会让用户感到困惑，因为实际上只需要两个独立的 if 语句来分别检查 API_KEY 和 CHANNEL_ID。
使用 := 运算符可以简化代码，并减少开发时间。
对于内部工具，直接让 os.environ["API_KEY"] 引发 KeyError 是一个清晰且足够描述性的做法。
Python 的海象运算符（walrus operator）可能会让人感到不直观，因为它允许变量在 if 语句之外被访问。
Python 的变量作用域比看上去更复杂，它实际上有三个变量作用域：全局、局部和异常块。
异常变量在异常块之后不会被绑定，这与 if 语句不同，后者中的变量必然是已定义的。
JavaScript 在 ES5 之前也具有类似的块作用域特性，但仅限于 catch 块中引入的变量。
通过重命名变量可以管理块作用域，但这可能会导致性能下降。
异常作为变量作用域的一个例外是有趣的，因为它是唯一一个不能保持绑定的情况。
在 if 语句中，被测试的表达式中的变量必然是已定义的，这与 for 循环不同。
Python 没有块作用域，最小的作用域是函数级别。
列表推导式中的变量不会泄露到外部作用域，这会导致一些奇怪的情况。
Python 的变量作用域不是由块限制的，而是由函数限制的。
使用海象运算符可以访问最内层的“可分配”作用域。

Tilck: A tiny Linux-compatible kernel #

https://github.com/vvaltchev/tilck

Tilck 是一个教育性质的单核内核，设计为与 Linux 在二进制级别上兼容。目前，它支持 i686 和 RISCV64 架构。Tilck 的小规模和简单设计使其成为在内核模式下进行实验的理想平台，同时保留了与 Linux 内核运行相同用户模式代码的能力。这种特性在教育内核中较为罕见。因此，为 Tilck 构建程序只需要一个来自 bootlin.com 的 gcc-musl 工具链。与其他大多数教育内核不同，Tilck 不需要一套自定义编写的应用程序，它可以直接运行主流的 Linux 程序，如 BusyBox 套件。

未来计划方面，Tilck 可能会在需要完全确定性和超低延迟系统的嵌入式系统中得到广泛应用。如果运气好，Tilck 可能会填补嵌入式 Linux 和典型的实时操作系统（如 FreeRTOS 或 Zephyr）之间的空白。Tilck 已经在 RISCV64 上运行，未来将移植到 ARM 架构。它也可能被适配到没有 MMU 的 CPU 上。由于 Tilck 的设计重点之一是消耗极少的 RAM，因此它非常适合这些用例。目前，Tilck 可以在仅有 3 MB 内存的 QEMU 机器上启动和运行。

此外，计划中还包括添加对网络和存储的基本支持，尽管具体细节尚未确定。网络支持可能仅限于 UDP + IP（至少在最初阶段），并且可能只在有限的网络卡上可用。存储支持也将类似：不会支持所有类型的块设备，内核中可能只实现少数文件系统（可能只有 fat32 和 ext2）。FUSE 文件系统的兼容性也将被考虑。

项目的一个主要里程碑将是为特定的 SoC（如 Raspberry Pi）支持网络和存储。

HN 热度 262 points | 评论 51 comments | 作者：chubot | 20 hours ago #

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

TILCK 是一个介于 xv6 和完整 Linux 内核之间的有趣中间点，运行在 LicheeRV Nano 这样的低成本 RISC-V 开发板上
TILCK 目前不支持网络或块设备，也没有多核支持
TILCK 使用 RAM 映像提供 FAT 支持，主要用于 initrd
早期 Linux 版本也只是一个 PC 控制台的终端模拟器，TILCK 的起点与之类似
TILCK 的快速启动和运行 Doom（帧缓冲）的能力给人留下深刻印象
TILCK 的 README 文件内容丰富且有趣，值得操作系统开发者阅读
TILCK 被标记为教育用途，但也可能适合小型嵌入式设备
TILCK 是一个小型确定性单内核，实现了约 100 个 Linux 系统调用，适合教育目的，也计划作为 Linux 兼容的 RTOS 内核
TILCK 缺乏多用户支持是一个缺点，希望作者重新考虑这一点
TILCK 的文件系统兼容性是一个更大的障碍，对于需要文件所有权和权限设置的场景来说，TILCK 可能不如经过实战考验的平台
作者考虑为 TILCK 编写块层、VFS 和 AHCI 驱动，以及移植 ZFS 和 NFS 服务器等组件，尽管这需要大量的代码工作
有人对 TILCK 的教育价值和在嵌入式系统生产中的潜在用途表示怀疑，认为它在信息安全和数据健壮性方面不够强大

GPUHammer: Rowhammer attacks on GPU memories are practical #

https://gpuhammer.com/

GPUHammer：GPU 内存的 Rowhammer 攻击是实际可行的

GPUHammer 是首个展示 GPU 内存中 Rowhammer 位翻转攻击的研究，特别是针对 NVIDIA A6000 GPU 中的 GDDR6 内存。攻击者可以在所有测试的 DRAM 银行中诱导位翻转，即使存在 DRAM 内部防御如 TRR，也能通过用户级别的 CUDA 代码实现。这些位翻转允许恶意 GPU 用户在共享、时间分割的环境中篡改另一用户的数据。在概念验证中，研究者使用这些位翻转篡改受害者的 DNN 模型，将模型准确度从 80% 降低到 0.1%，仅通过一次位翻转实现。启用错误校正码（ECC）可以减轻这种风险，但 ECC 可能会使 A6000 GPU 上的 ML 推理工作负载降低多达 10% 的性能。

Rowhammer 是硬件漏洞，快速激活内存行会在相邻内存行中引入位翻转。自 2014 年以来，这一漏洞已在 CPU 及其基于 CPU 的内存（如 DDR3、DDR4 和 LPDDR4）中得到广泛研究。然而，随着关键的 AI 和 ML 工作负载现在在云端的独立 GPU 上运行，评估 GPU 内存对 Rowhammer 攻击的脆弱性变得至关重要。

Rowhammer 在基于 GPU 的 GDDR 内存上更具挑战性，原因如下：

GDDR6 具有更高的延迟和更快的刷新速度，使得敲击更难。
GDDR 内存中未知的 DRAM 地址映射使得制作有效的模式变得复杂。
GDDR 中的 DRAM 内部缓解措施不透明且未记录。

尽管如此，GPUHammer 克服了这些障碍，成功地对 GDDR6 发起了攻击。

步骤 1：逆向工程 GPU DRAM 映射为了制作有效的 Rowhammer 攻击，首先需要识别映射到 NVIDIA GPU 上同一 DRAM 银行的内存地址。与 CPU 不同，NVIDIA GPU 不向用户级别的 CUDA 代码公开物理地址，这使得识别和敲击同一银行的 DRAM 行变得困难。然而，观察到 NVIDIA GPU 驱动程序一致地将虚拟内存映射到相同的物理内存，我们逆向工程了虚拟内存偏移量到 DRAM 银行映射。受 DRAMA 技术的启发，我们使用相同银行与不同银行内存访问之间的时序差异。

一个关键障碍是，如图 1 所示，成对访问地址时的非均匀内存访问（NUMA）效应使得难以精确定位同一银行地址。基于同一 DRAM 银行中的地址在单独访问时必须具有相似的延迟的洞察，我们过滤掉那些对 NUMA 效应有贡献的地址，并清晰地识别出映射到同一 DRAM 银行的地址（见图 2）。这准确地识别了用于制作 Rowhammer 模式所需的同一银行地址对。

步骤 2：最大化敲击强度 GPU 内存访问速度比 CPU 慢多达 4 倍，使得使用像 CPU 那样的单线程敲击难以达到 Rowhammer 攻击所需的激活率（见图 3，绿线）。为了克服这一点，我们利用 GPU 的 SIMT 并行性，同时启动多个线程和 warp。这种多线程、多 warp 方法（见图 3，橙线）消除了内存控制器中的空闲时间，并达到了最大可能的敲击率。图 4 显示了这些策略如何最大化内存控制器的利用率。

步骤 3：同步刷新，击败缓解措施先前的工作如 SMASH 和 BlackSmith 表明，将敲击同步到刷新（REF）是绕过 DRAM 内部防御的关键。然而，CUDA 的同步原语（如__syncthreads()）用于同步线程可能会重新排序 warp 执行。相反，我们使用隐式的每个 warp 延迟，对齐使得 REF 命令与我们插入的延迟重叠，以将我们的敲击与刷新对齐并击败像 TRR 这样的 DRAM 内部缓解措施，同时保持 warp 执行顺序。

我们使用 GPUHammer 在 NVIDIA RTX A6000（48 GB GDDR6）上运行，并在四个 DRAM 银行中观察到 8 个不同的单比特翻转，所有测试的银行都出现了位翻转（见图 6）。诱发翻转的最小激活计数（TRH）约为 12K，与之前的 DDR4 发现一致。

使用这些翻转，我们进行了首次使用 Rowhammer 在 GPU 上降低 ML 准确性的攻击。先前的工作表明，翻转 FP16 模型权重中浮点指数的最高有效位可以大幅降低模型准确性。基于这一见解，我们展示了在时间共享的 GPU 设置中，攻击者可以通过内存按摩将受害者数据定位到易受攻击的 DRAM 行，并在这些位置强制位翻转。

在我们的概念验证中（见图 7），仅通过一次位翻转，所有五个测试的 ImageNet DNN 模型的准确性都降低到 1% 以下，导致高达 80% 的准确性损失。

常见问题解答：

哪些 GPU 容易受到攻击？我受到影响了吗？我们在配备 GDDR6 内存的 NVIDIA A6000 GPU 上确认了 Rowhammer 位翻转。其他 GDDR6 GPU，如 RTX 3080，在测试中没有显示出位翻转，可能是由于 DRAM 供应商、芯片特性或操作条件（如温度）的变化。我们还在配备 HBM 内存的 A100 GPU 上没有观察到位翻转。
为什么测试这么少的 GPU？这不是一个小样本量吗？与 CPU 不同，DRAM 模块可以轻松更换以进行测试，GPU DRAM 是焊接的，大规模测试成本高昂（GPU 可能花费数千美元）。我们的攻击代码可以扩展到其他 Ampere GPU 以及更多，我们鼓励未来的工作扩大测试覆盖范围。
如何减轻 GPUHammer？管理员可以通过启用 ECC 来减轻 GPUHammer，通过 nvidia-smi -e 1（随后重启）实现。到目前为止观察到的所有位翻转都是单比特的，ECC 可以纠正。然而，启用 ECC 可能会降低 A6000 上的性能高达 10%，并减少内存容量 6.25%。尽管如此，这并没有消除硬件缺陷的根本原因，这将需要重新设计 GDDR6，并引入像 PRAC 这样的原则性缓解措施，这已经为 DDR5 及以后提出了，或者像 PRIDE 这样的概率性缓解措施。
新的 GPU，如 H100 或 RTX 5090，是否受到影响？目前没有。H100（HBM3）和 RTX 5090（GDDR7）具有片上 ECC，这可能掩盖了单比特翻转。然而，未来的 Rowhammer 模式可能导致多位翻转，可能会绕过这样的 ECC，如 ECCploit 攻击所示。
你们是否向 NVIDIA 披露了这一点？他们的回应是什么？是的。我们在 2025 年 1 月 15 日负责任地向 NVIDIA 披露了 GPUHammer，并向主要的云服务提供商（AWS、Azure、GCP 等）披露。NVIDIA 确认了这个问题，并推荐启用 ECC 作为缓解措施。

更多信息：请参考我们在 USENIX Security 2025 上发表的论文…

HN 热度 261 points | 评论 89 comments | 作者：jonbaer | 23 hours ago #

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

Rowhammer 攻击能够通过直接操纵宇宙的底层物理来逃脱封闭的虚拟世界
通过在虚拟宇宙内创建模式，可能影响底层模拟的宇宙
模拟攻击可能对性能产生负面影响，导致性能降低
许多计算不需要安全性，但对于需要安全的地方，任何连接到互联网的设备都应该是安全的
任务如果被授予了原生 GPU 访问权限，就已经在安全边界内部，不信任的任务不应让其访问 GPU
GPU 有能力运行不受信任的任务，类似于页表的机制
如果我们在一个模拟中，可能有许多相当于 SysRq 或控制-Alt-Delete 的退出方式
我们可能无法察觉到父宇宙的物理规则，就像我们无法察觉到更多物理一样
通过撞击墙壁来测试物理现实的想法，类似于对科学的不信任
模拟攻击可能让我们思考如何在更高层次的宇宙中找到类似的漏洞
模拟攻击可能不会在所有系统中都存在逃脱的可能，系统不一定需要包含逃脱口
通过模拟攻击，我们可以思考如何在更复杂的系统中找到并利用漏洞