谷歌计划在2026年第二季度将Chrome浏览器带到ARM64 Linux设备上，此前已成功在macOS（2020年）和Windows（2024年）ARM平台上发布。此举旨在满足对功能齐全的浏览体验日益增长的需求，该体验将谷歌的服务与开源Chromium项目集成。 ARM64 Linux版本将提供与其他Chrome版本相同的安全性、稳定性以及丰富的功能，包括通过Google账户无缝同步、访问Chrome网上应用店扩展程序以及即时网页翻译。增强的安全功能，如带有AI保护的安全浏览、Google Pay集成以及Google密码管理器也包含在内。 谷歌正在与NVIDIA合作，简化DGX Spark用户的安装流程，其他用户可以直接从chrome.com/download下载。此发布标志着谷歌对Linux社区和不断扩展的Arm生态系统的承诺。
每日HackerNews RSS
## Chrome 登陆 ARM64 Linux
谷歌官方宣布 Chrome 将登陆 ARM64 Linux 设备，预计于 2026 年第二季度发布。虽然 Chromium 已在 ARM64 Linux 上可用一段时间，但官方 Chrome 版本一直缺失，这让用户感到沮丧，尤其是那些使用基于 ARM 的工作站，例如 NVIDIA Spark 的用户。
此举弥补了长期存在的差距，因为 Chrome 已经支持基于 ARM 的 macOS 和 Windows。讨论指出，由于 perceived 的有限需求和支持成本，谷歌之前缺乏支持 ARM64 Linux 的动力，尽管现有的 ARM Chromebook 已经使用了类似技术。
官方发布的关键优势包括潜在的 Widevine DRM 支持改进（Spotify 和 YouTube 等服务需要），以及同步功能，在使用 Chromium 时设置起来一直很麻烦。用户希望获得更好的硬件加速，尤其是在 Raspberry Pi 等设备上。此版本还将帮助使用浏览器自动化工具的开发者。
NaN 很奇怪。
NaN Is Weird
19 天前
最近在Python Discord的讨论中，发现`float('nan')`（非数字）存在一种奇怪的行为。令人惊讶的是，`nan`是可哈希的，允许将其添加到集合并用作字典的键。然而，`nan`甚至不等于自身（`nan == nan`的结果是`False`），这意味着每个`nan`实例都被认为是唯一的。 这导致了意想不到的结果：一个集合可以包含多个`nan`值，一个字典可以保存多个以`nan`作为键的条目——但使用`nan`本身检索值会引发`KeyError`。只有使用*特定*的`nan`实例（存储在变量中）才能访问字典。 即使计算可迭代对象中`nan`的出现次数也是不准确的，因为`Counter`将每个`nan`视为不同的值。虽然这在实际应用中没有用处，但这展示了Python处理`nan`值时一个有趣且违反直觉的特性。
## Python & NaN：一则黑客新闻讨论总结
一则黑客新闻讨论围绕Python中NaN（非数字）的特殊行为，特别是关于相等性和哈希的问题。核心问题是NaN不等于自身（NaN != NaN），这是IEEE 754浮点标准的结果。这在使用NaN作为字典键时会导致意外结果，因为Python在这种情况下依赖于对象标识进行哈希。
评论者争论这是否是Python的缺陷，或者是否是对标准的忠实实现。一些人认为NaN代表一个无法表示的数字，因此不应该进行相等性比较。另一些人建议Python应该用错误来处理除以零的情况，而不是NaN，从而与更直观的数学期望保持一致。
一个关键点是，IEEE 754标准允许全序和偏序浮点数，而Python默认使用后者，因此需要小心处理NaN。许多人认为取消屏蔽无效操作异常比处理NaN的怪癖更干净。讨论还涉及C++、Rust和JavaScript等其他语言中相关问题，强调了处理浮点错误的不同方法。
这次Hacker News的讨论围绕一张大型公告板系统（BBS）的照片，照片来自互联网普及之前的时代。这张图片引发了人们对这些系统运作方式的怀旧和技术讨论。
关键点包括：BBS在互联网广泛普及之前是重要的在线交流方式，通常在配备多个调制解调器的PC网络上运行。虽然有些人认为容量有限，但许多BBS通过多任务操作系统（如DESQview）或专用软件支持多个并发用户。照片中设置的规模——可能包含数十条电话线和计算机——引发了关于维护这种系统所需的工作量与运行它的“炫酷程度”的争论。
用户分享了拨号上网、下载共享软件以及BBS培养的独特社区的记忆，并将其与现代在线平台的算法性质进行了对比。讨论还涉及了当时使用的调制解调器、串行卡和网络技术等硬件的技术细节，突出了早期在线先驱的独创性和足智多谋。
由于提供的内容是PDF二进制数据流，其中包含大量非文本字符，无法直接翻译成可读的中文。它看起来像是图像或压缩数据的一部分，而不是人类可读的文本。
一场 Hacker News 的讨论围绕着一篇近期文章（以及链接的 PDF）展开，该文章详细描述了在创造“AI 亲密关系”中涉及的令人不安的情感劳动，特别关注数据标注员的经历。核心问题是 AI 开发背后的人力成本，尤其是在 AI 聊天机器人和“AI 女朋友”等领域。
文章强调，一些人，包括来自非洲的一名男子，被雇佣来提供逼真的回应，甚至参与角色扮演以训练这些 AI 模型——有时甚至是用于性暴露目的。评论员对这项工作的剥削性质表示震惊，并将其与人们对 AI 纯粹是技术的认知形成对比。
关于这项工作是仅仅一份工作，还是本质上具有创伤性，引发了争论。一些人指出，其他数据标注任务也存在类似的问题，并质疑应该采取什么具体的行动。另一些人强调了一些 AI 应用的欺骗性，用户认为他们正在与真人互动。讨论还涉及公司将这项劳动外包到印度等国家的情况，以及围绕“AI”解决方案的误导性营销，这些解决方案严重依赖人工输入。
启用 JavaScript 和 Cookie 以继续。
过去一年，作者一直在努力使编码代理真正具有协作性，为此赋予它们对项目的深入理解——超越仅仅是文件内容。最初的尝试侧重于手动向代理提供上下文，虽然有效但不可持续。各种解决方案被尝试过——规则、提取的会话数据和“技能”——但都受到难以持续捕捉*决策时刻*上下文的困扰。 突破来自于意识到 Git 的提交历史已经*记录*了会话。缺失的部分是详细提交信息的规范，解释代码更改的*原因*，而不仅仅是*内容*。这促成了“上下文提交”，一种受 Conventional Commits 启发的规范，在提交信息中使用结构化的行为行来记录意图、决策和学习到的信息。 这种方法消除了对单独上下文跟踪系统的需求，利用了 Git 本身的扩展性和并发性。一个简单的“回忆”技能允许代理主动搜索这段历史以获取推理依据。作者已经将此作为标准开源，希望得到更广泛的应用，并有可能与编码工具进行原生集成，最终目标是实现“更好的提交”——以及更知情、更具协作性的编码体验。
## 上下文提交：在Git历史中记录“为什么”
最近Hacker News上的一场讨论围绕着一项“开放标准”提案——上下文提交，旨在通过明确记录代码变更背后的*原因*，而不是仅仅记录*做了什么*，来改进Git历史。目前，提交信息通常侧重于“做了什么”，而忽略了“为什么”，这会阻碍理解，尤其是在项目增长和开发者变更的情况下。
核心思想是使用键值对（例如 `rejected(oauth-library)`）来构建提交信息，从而可以针对历史决策进行查询。虽然有些人认为提交正文足以解释意图，但支持者认为这种结构化方法更适合“代理编码”——即AI工具需要理解代码背后的逻辑。
这场辩论凸显了既定实践（例如引用外部问题跟踪器，如Jira）与对自包含、机器可读历史的渴望之间的紧张关系。人们对可执行性和潜在复杂性表示担忧，一些人建议现有的工具，如提交尾部，可以实现类似的结果。最终，这场讨论强调了在代码中清晰沟通的重要性，无论对于人类开发者还是日益复杂的AI助手。
启用 JavaScript 和 Cookie 以继续。
## 苦涩的教训与AI辅助写作：摘要
最近的Hacker News讨论围绕一篇论文展开，该论文认为“苦涩的教训”——即在足够算力下，扩展简单方法总是胜出的——并不需要特定的“效用函数”。作者承认使用Claude（一种LLM）作为起草伙伴，引发了关于作者身份和真实性的争论。
许多评论者担心依赖LLM进行散文写作会降低写作的清晰度和直接性，将其比作引入不准确性的图像人工放大。一些人认为，高质量的写作优先考虑简洁和清晰，而这些是LLM经常牺牲的品质。
一个关键点是，尽管LLM具有令人印象深刻的能力，但人们缺乏努力去*理解* LLM正在学习的内容。这些模型被视为黑盒子，而预处理和后处理仍然很初级。
作者为他们的流程辩护，表示他们提供了论点，而LLM完善了文笔，并认为对这种劳动分工感到不适，反映了人们对“苦涩的教训”本身的偏见。然而，其他人批评由此产生的写作可能缺乏真正的理解，并且不必要地冗长，强调了LLM在缺乏真正理解的情况下填补语义差距的风险。最终，这场讨论质疑了AI对作者身份的影响以及清晰简洁沟通的未来。
## 计算大型堆砂身份：加速的故事
该项目专注于高效计算大型“身份堆砂”，这是对一个迷人数学概念的可视化。 最初的算法太慢——生成 100x100 的身份需要几秒钟，阻碍了对更大尺寸的探索。 目标是实现显著更快的计算，最终计算出 16384x16384 的身份，耗时不到一小时，相比于之前已知最大的例子（10,000x10,000，耗时 10 天）有了巨大改进。
主要有两种方法：“差分法”和“迭代燃烧法”。 作者改进了这两种方法，最终开发了一种利用堆砂与使用快速傅里叶变换和多重网格法求解泊松方程之间的关系的新方法。 这使得能够有效地将任何堆砂“投影”到数学理想状态（“零晶格”）上。
加速的关键在于认识到堆砂身份的尺度不变性，并递归地应用这种投影，从较小、预先计算的身份开始。 通过对“稳定化”函数进行细致的优化，也获得了显著的性能提升——这是算法的核心组件——利用了 AVX256、OpenMP、内存对齐以及利用对称性等技术。
虽然进一步的优化是可能的（AVX512、GPU 实现、改进的多重网格技术），但这项工作展示了在计算这些复杂结构方面取得了实质性的飞跃，为进一步的探索和可视化打开了大门。 代码可供那些有勇气探索它的人使用。
一个黑客新闻的讨论围绕着“eavan0”发表的一篇博客文章，文章详细介绍了高效计算大型“身份沙堆”的努力。这些沙堆在视觉上类似于康威的生命游戏，但总是会稳定下来，之前生成速度很慢——一个100x100的沙堆需要几秒钟。
为了创建更大、前所未见的沙堆身份，eavan0开发了一种更快的算法，被描述为之前一篇关于“美丽的阿贝尔沙堆”的博客文章的后续。讨论包括对损坏链接的修正以及与游戏“连锁反应”的比较。
几位用户在尝试访问博客时遇到了网站连接问题（PR_CONNECT_RESET_ERROR），eavan0对此进行了调查。总的来说，这篇文章和随后的对话凸显了计算效率、视觉模式和数学概念之间一个引人入胜的交叉点。
“人工智能是非洲智慧”：训练人工智能的工人正在反击
'AI is African intelligence': The workers who train AI are fighting back
19 天前
迈克尔·杰弗里·亚洲的经历凸显了人工智能兴起背后隐藏的人为代价。在肯尼亚，亚洲每天花费数小时标记色情内容并参与模拟的在线关系——本质上为人工智能性机器人提供劳动力——而报酬微薄。这项工作由算法控制，要求改变人物设定，对他的身心造成严重损害，导致失眠、创伤后应激障碍和性功能障碍，最终破坏了他的个人生活。
现在，作为数据标注者协会（DLA）秘书长，亚洲倡导改善这些经常被剥削的工人的工作条件。数据标注者对于训练和完善人工智能至关重要，但他们获得的报酬极低，缺乏足够的心理健康支持，尽管他们驱动着Meta、OpenAI和Gemini等科技巨头的估值。
DLA正在争取公平工资、福利以及结束限制性保密协议，将这种情况定义为现代跨国公司延续的殖民剥削。由于数据标注是肯尼亚科技劳动力中的重要组成部分，该运动寻求更广泛的团结以及对人工智能依赖弱势劳动力的伦理影响的认识。
```python from openai import OpenAI client = OpenAI( api_key="sk-your-key-here", base_url="https://api.ionrouter.io/v1" ) response = client.chat.completions.create( model="qwen3.5-122b-a10b", messages=[ { "role": "user", "content": [ {"type": "image_url", "image_url": {"url": "..."}}, {"type": "text", "text": "What's in this image?"} ] } ] ) ```
## IonRouter：快速且经济实惠的AI推理 (摘要)
Cumulus Labs，一家YC W26初创公司，推出了IonRouter (ionrouter.io)，这是一款推理API，旨在弥合开源和微调AI模型在速度和成本之间的差距。他们的目标是解决现有问题：快速的提供商价格昂贵（例如Together AI），而廉价的DIY方案（例如Modal）则需要大量的设置并存在冷启动慢的问题。
IonRouter利用定制的C++运行时IonAttention，专为GH200架构构建，实现了令人印象深刻的吞吐量——尤其是在多模态流水线中，达到了588个token/秒，超过了Together AI等竞争对手。目前，其延迟略高（p50 ~1.46s vs 0.74s），团队正在积极优化。
定价按token计算，没有空闲成本（例如，GPT-OSS-120B的输入为$0.02，输出为$0.095）。该服务允许用户轻松地在现有的OpenAI代码中替换基础URL，以访问更广泛的模型。目前，他们专注于展示其引擎，并计划扩展到托管微调模型，为定制AI部署提供简化的解决方案。他们正在积极寻求用户反馈，特别是那些使用微调模型的人。