2025 08 08 HackerNews

2025-08-08 Hacker News Top Stories #

  1. 邮寄一次性代码的登录方式比密码更不安全，Passkeys是更安全的替代方案。
  2. 项目Hyperion通过设计世代飞船探索载人星际旅行的可行性，吸引了跨学科团队参与。
  3. Litestar是一个值得关注的Python Web框架，具有异步优先和类型提示驱动的特点。
  4. Windows XP的启动界面和进度条设计暴露了用户体验和UI设计的历史挑战。
  5. 使用Bluesky构建博客评论系统能够实现跨平台对话和丰富内容支持。
  6. 富兰克林的讽刺文章揭示了英国对殖民地政策的荒谬性，引发了广泛关注。
  7. 在NVIDIA GPU上优化GPT-OSS-120B模型实现了更高的性能和更低的延迟。
  8. HashiCorp Vault暴露出多个零日漏洞，涉及身份验证和授权模块的安全问题。
  9. Gemini CLI GitHub Actions是Google推出的AI编码助手，支持自动化开发任务和协作流程。
  10. 测试发现不同浏览器对CSS中“无限像素”的处理方式存在显著差异。

Emailing a one-time code is worse than passwords #

https://blog.danielh.cc/blog/passwords

这个网页是 Daniel Huang 的博客文章，主题是关于在线服务登录方式的问题。文章批评了一种流行的登录方法：输入电子邮件地址或电话号码，网站发送 6 位数字代码，然后使用这个代码登录。作者认为这种方法对账户安全非常糟糕，因为攻击者可以简单地将你的电子邮件地址发送给合法服务并请求 6 位数字代码，你无法确定代码是否应该在正确的地方输入。密码管理器（通常用于防御网络钓鱼）也无法提供帮助。实际上，这种攻击方法已经被成功地用于现实世界中，例如微软的 Minecraft 账户登录就使用了这种方法，导致许多账户被盗。文章还提到了其他技术相关的博客帖子，包括 Linux 上的 PATH 问题、复合利息计算、过度工程化的拼图解决方案、投票系统问题、马里兰大学最喜欢的课程、意外编写快速 SAT 求解器以及对 LeetCode 的看法。最后，作者提供了电子邮件地址，供读者提问、反馈或打招呼。

HN 热度 838 points | 评论 679 comments | 作者：max__dev | 22 hours ago #

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

  • 通过电子邮件发送一次性代码的认证流程容易受到网络钓鱼攻击，用户难以避免这种错误。
  • “点击电子邮件中的链接"比发送一次性代码稍微安全些，因为它直接将用户带到官方网站。
  • 如果流行的电子邮件服务突然决定阻止登录电子邮件或登录链接，许多用户将无法登录。
  • Passkeys 是更好的选择，密码管理器对 Passkeys 的支持越来越好。
  • 用户丢失所有 Passkeys 比丢失密码要好得多，宁愿让用户去银行恢复账户访问，也不愿他们被网络钓鱼攻击。
  • Passkeys 的主要问题是设备丢失时访问权限的丧失，但这取决于你的设置，并不一定会发生。
  • Passkeys 可能会进一步巩固大型科技公司的地位，剥夺用户的自由。
  • Passkeys 在实际使用中存在问题，一些用户无法成功使用。
  • Passkeys 在 Windows 系统上的支持还不够完善，可能会遇到问题。
  • 一些用户发现 Passkeys 在不同的浏览器和操作系统上都能正常工作。
  • 非企业的大型科技公司（如 Google、Apple 和 Microsoft）使用的 Passkeys 不需要认证声明。
  • 认证声明在规范中的存在并不以任何有意义的方式侵犯用户自由。
  • 有些人担心第三方系统可能需要认证声明，但这更多是理论上的问题。
  • 微软的 Entra ID 系统强制执行 FIDO 2 密钥的认证。
  • 企业系统可能会要求认证，这是企业自己的业务决策。
  • 一旦存在这样的安全措施，它最终会出现在安全审计清单上，人们会不加思索地执行。

Project Hyperion: Interstellar ship design competition #

https://www.projecthyperion.org

项目超离子探索了通过世代飞船进行载人星际旅行的可行性，这种飞船设计用于长时距星际旅行，可能需要几个世纪才能完成。世代飞船的理念是初始船员将在船上生活、繁衍和死亡，他们的后代将继续旅程直到到达目的地。这些飞船通常被设想为自给自足的生态系统，包括农业、居住和其他必要的生命支持系统，以确保多代人的生存。

星际研究计划（i4is）很高兴地公布了项目超离子设计竞赛的获奖者，这是一个全球性的挑战，要求跨学科团队设想一个世代飞船——一个设计用于 250 年旅程到达宜居星球的载人星际飞船。团队设计了这样的飞船栖息地，允许一个社会在高度资源受限的环境中自我维持并繁荣发展。

项目超离子设计竞赛要求建筑设计、工程和社会科学领域的专家合作，解决使飞船作为一个封闭社会在几个世纪内运作的关键任务方面。不同学科之间的合作是寻找全面解决方案的关键，这些解决方案要能够满足要求的复杂性，以提供：

  • 1000 ± 500 人几个世纪的可居住性
  • 通过旋转实现人工重力
  • 确保良好生活条件的社会，包括住所、衣物和其他基本需求
  • 用于食物、水、废物和大气的健壮生命支持系统
  • 保留文化和技术的知识传递机制

竞赛要求的更多细节可以在这里找到。

我们感谢我们的评审团，他们由在建筑、工程和社会科学领域拥有丰富经验的杰出专业人士组成。评审团成员包括来自休斯顿大学的 Olga Bannova、NASA-JPL 的 A. Scott Howe、亚利桑那州立大学的 Elena Rocchi、俄勒冈州立大学的 Cameron Smith 和南加州大学的 Madhu Thangavelu。

第一名：Chrysalis Chrysalis 以其系统级连贯性和创新的模块化栖息地结构设计给评审团留下了深刻印象，还包括了太空制造和南极洲任务前船员准备的价值。其模块化外壳设计促进了灵活性和连通性，支持功能性和可扩展性。大型穹顶结构增添了戏剧性的、电影般的质感，让人联想到科幻经典，而整体系统级规划——不仅包括建筑，还包括如何建造飞船——非常强大。辐射保护策略坚实，实用的结构方法非常适合。虽然文化系统可以进一步发展，但概念提供了一个引人注目的起点。展示内容丰富且视觉上引人入胜，与 Rama 等标志性作品相提并论，展示了对设计和叙事的清晰热情。其整体飞船设计似乎受到了 1980 年代巨大世界飞船概念的启发。

第二名：WFP Extreme WFP Extreme 因其在文化和社会维度上的特别关注而受到赞誉，包括服装和精神空间等概念。它在文化和社会考虑方面表现出色，提供了这一领域中最深思熟虑的想法之一。建筑设计引入了辐射保护等先进技术，并展示了“出租车胶囊”和个性化船员服装等创意。尽管系统级连贯性和人工重力下的室内设计可以进一步发展，但结构方法非常适合轨道应用。总体而言，该项目在技术雄心与对未来太空生活的独一无二和敏感愿景之间取得了平衡。这个概念通过精心制作的手册和海报清晰呈现，注重细节，具有独特的以人为本的审美。

第三名：Systema Stellare Proximum Systema Stellare Proximum 以其沉浸式叙事脱颖而出，将技术、社会和文化方面无缝地结合在一起。这个概念提供了一个丰富而富有想象力的叙事，巧妙地编织了长期太空居住的社会、技术和文化方面。其叙事引人入胜，创造性地探索了社区动态甚至精神性——强调了共享价值观在建立有韧性、跨代社会中的作用。使用小行星作为辐射盾牌是一个大胆而引人注目的策略，与受水母形态启发的视觉引人注目的结构相搭配。虽然薄壳小行星的物理可行性可以进一步细化，但概念显示出对宇宙辐射挑战的扎实理解。系统级规划经过深思熟虑，展示内容详细且视觉上动态，艺术插图增强了效果。这个参赛作品通过其整体愿景和对深空生活的诗意方法留下了深刻的印象。

荣誉提名：Arkkana Arkkana 的设计深思熟虑地考虑了时间维度以及人口的角色和需求如何随着栖息地的生命周期演变——这是长期太空定居规划中一个重要且经常被忽视的方面。通过反旋转环实现脱钩人工重力是一个优秀的起点，显示出对旋转动力学和居住者舒适的强烈意识。虽然环不是同心的，这可能会因偏移的重心引入不必要的扭矩，但概念仍然反映了对关键机械挑战的扎实把握。包括磁悬浮支持的栖息地车厢增强了系统冗余和安全，通过多个压力容器实现。认识到曲线圆柱模块将带来结构质量处罚，并相应地转向带有圆顶端的直线“香肠”形状模块，显示出一种务实的工程方法，基于现实的结构约束。最后，质量/设备清单（MEL）预算代表了将概念建筑转化为可量化系统要求的值得称赞的早期步骤。

荣誉提名：EBS: Endless Beyond the Stars EBS 的 Galaxy Express 999 提出了一个经过深思熟虑的社会组织方法，对内部模块化和可适应的生活安排有着实际的愿景。“Negotiopolis”概念特别引人注目，提供了一个富有想象力的公民建筑和一个基于谈判的治理模型，为星际背景下的社会结构引入了新的视角。虽然设计在技术实施上较轻，但它对更广泛的讨论做出了有意义的贡献。

HN 热度 351 points | 评论 312 comments | 作者：codeulike | 1 day ago #

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

  • 这个竞赛是国际空间定居点设计竞赛的成人版，旨在培养下一代航空航天人才。
  • 竞赛为参与者提供了与波音和 NASA 工程师学习的机会，是一次难忘的经历。
  • 新的竞赛目标是将工作专业人士的设计和创意视为重要的输出。
  • 太空旅行的成功依赖于低成本获取额外资源、稳定的收入流或战争/防御需求。
  • 长途且昂贵的单程旅行在商业上没有意义，因为需要巨额资金。
  • 探险者之所以能得到资助，是因为承诺能带来大量财富和资源。
  • 即使所有尚未发明的技术都存在，完成此类项目所需的世界 GDP 年数也是一个问题。
  • 整个结构旋转无法实现多个壳体表面都有 1G 的重力，因此设计上需要多个壳体。
  • 从月球和地球经济的角度来看，月球-地球 L1 拉格朗日点不是最佳的建造点。
  • 最佳设计是将整个生活模块作为一个整体旋转，大多数活动将在外壳上进行。
  • 对于燃料和反推发动机，是否旋转取决于设计选择。
  • 如果需要维护主驱动，备用动力系统是必要的。
  • 如果拥有“直接聚变”技术，就不需要常规的环形核聚变反应堆。
  • 对于持续 400 年的旋转，需要三重冗余系统，并且避免使用齿轮以减少故障。
  • 将孩子放在一个可能需要 400 年的太空船上是不明智的。
  • 风车虽然有 400 年的历史，但它们是经过维护和修理的，而在太空中更换大型齿轮或轴承是不现实的。
  • 在太空中更换旋转壳体的主齿轮需要“关闭”重力一段时间。

Litestar is worth a look #

https://www.b-list.org/weblog/2025/aug/06/litestar/

James Bennett 在他的博客中分享了对 Litestar 这个 Python web 框架的看法。Litestar 是一个异步优先、类型提示驱动的新一代 Python web 框架，Bennett 在项目中选择了它，并且对选择感到满意。他强调 Litestar 是 Python web 生态系统中的一个隐藏的宝石，并希望更多人了解它。

Litestar 的代码示例展示了一个简单的单文件应用程序，通过装饰器定义路由和异步函数来响应 HTTP 请求。Bennett 提到，尽管 FastAPI 等其他框架也能实现类似的功能，但 Litestar 在 Python 世界中有一些独特的优势。

Litestar 最初被称为“Starlite”，后来因为不再依赖 Starlette 库，并且为了避免与 Starlette 混淆，项目在 2023 年更名为 Litestar。

Bennett 讨论了“扩展性”的概念，他关注的是代码库的扩展性，即框架如何帮助或阻碍开发者处理不同数量的代码。他提到 Django 在小型项目中扩展性不佳，而 Litestar 则在这方面表现出色。

Litestar 避免了其他框架在单文件到多文件应用过渡中遇到的问题，因为它的路由装饰器是独立的，不依赖于父应用或类似应用对象。这让 Litestar 的文档能够早期介绍路由分组结构，并将其作为连贯的分层架构/配置概念的一部分。

Litestar 的分层架构是其最佳特性之一，它的分组构造和共享配置的能力提供了一种优雅的方式来组合功能。例如，Bennett 展示了如何使用 Litestar 的 Router 和 Provide 来创建一组 CRUD 端点，所有端点都可以访问相同的配置和依赖项。

HN 热度 328 points | 评论 82 comments | 作者：todsacerdoti | 1 day ago #

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

  • FastAPI 官方文档不够完善，不适合构建复杂应用
  • 有人推荐使用 Litestar 作为替代，因为它更适合构建复杂应用
  • FastAPI 需要用户自己构建框架，适合喜欢自定义构建的用户
  • FastAPI 的文档和社区支持不如 Django 等成熟框架
  • 有人批评 FastAPI 的文档质量差，社区贡献的 PR 长时间未被审查
  • 有人建议使用 Polar 的开源代码作为 FastAPI 大型应用的参考
  • 有人提出 FastAPI 适合快速构建 CRUD 应用，但不适合复杂应用
  • 有人反对将 FastAPI 用于大型项目，认为需要自己构建框架
  • 有人提到 FastAPI 的文档页面曾因使用表情符号而受到批评
  • 有人提到 FastAPI 的作者 Tiangolo 倾向于按照自己的方式开发，不接受太多外部输入
  • 有人提到 Iam-abbas 有一个 FastAPI 的样板项目，但有人对其结构表示反对
  • 有人支持垂直切片架构（Vertical Slice Architecture），认为这是复杂应用的唯一出路
  • 有人提到 Litestar 有内置的事件系统，这是 FastAPI 所缺乏的
  • 有人对 Litestar 的文档和社区支持表示疑问，不确定它是否适合构建复杂应用

Windows XP Professional #

https://win32.run/

这是一个显示计算机启动选项的页面，具体内容如下：

  1. 使用 ↑ 和 ↓ 键选择启动设备，按 Enter 尝试启动或按 ESC 取消
  2. 启动选项包括：
    • 正常启动 Windows
    • 安装 Windows
    • 板载网卡(IPv4)
    • 板载网卡(IPv6)
    • 其他选项：BIOS 设置、设备配置、BIOS 刷新更新、更改启动模式设置
  3. BIOS 版本信息：
    • PhoenixBIOS 1.4 Release 6.0
    • 版权所有：1985-2001 Phoenix Technologies Ltd.，2001-2003 VMware, Inc.
    • VMware BIOS 构建版本 314
  4. 检测到的设备：ATAPI CD-ROM，VMware 虚拟 IDE CD-ROM 驱动器
  5. 正在初始化…

HN 热度 274 points | 评论 166 comments | 作者：pentagrama | 10 hours ago #

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

  • 通过鼠标对角线移动到弹出菜单中可以判断 UI 是否为克隆版，真正的系统会保持菜单开启。
  • 旧的 UI 界面指南和研究使得界面对用户更有用，现在更多是考虑如何对公司有用。
  • 每个公司都在设计自己的 UI 组件，导致重复投资于 UX 研究，用户体验往往被忽视。
  • 互联网档案馆对于恢复旧链接和个人作品非常有用，值得更多赞誉。
  • 进度条的动画效果不佳，如旋转动画，不如分段的进度指示器直观。
  • 进度条很难编程，因为它需要准确估计任务完成时间。
  • 进度条通常代表任务状态而非时间，但传统上会伴有预计剩余时间的标签。
  • 在 DOS 时代，进度条相对简单，因为大多数操作涉及磁盘 I/O，可以相对准确地估计完成时间。
  • 用户常见的操作如 CRUD 通常涉及远程数据库和网络往返，难以准确显示进度。
  • 早期的文本终端等效进度指示器有多种表现形式，如点、圆圈和旋转符号。
  • 进度条如果“重置”会让用户普遍不满意，而随机进度条和准确线性进度条的用户满意度相当。
  • 有些工具的进度条会快速填满然后下降，重复此过程，这让用户感到困惑。

Building Bluesky comments for my blog #

https://natalie.sh/posts/bluesky-comments/

作者对博客评论系统的问题进行了探讨，他不喜欢 Disqus 因为慢、重、追踪用户，而且不拥有任何内容。他尝试过自托管解决方案，但需要管理用户、审核垃圾信息、维护数据库等，非常麻烦。GitHub Issues 作为评论系统对于开发者博客可能适用，但限制了观众范围。作者作为 Bluesky 用户，认为使用 Bluesky 作为评论系统很有意义，因为它不需要维护基础设施，支持丰富的内容，使用真实身份，跨平台对话，并且作者拥有自己的内容。

作者详细介绍了如何构建 Bluesky 评论组件，包括理解 AT 协议、组件架构和处理嵌套回复的挑战。他选择了一个简单的递归方法来显示回复，最多显示 5 层深度。对于富媒体内容，如图片和外部链接，需要特殊处理。作者将这个系统与 Astro 博客集成，通过 React 集成和 client:load 指令确保评论组件立即激活。

作者总结了使用 TypeScript 的好处，渐进增强的有效性，以及默认的性能优化。他对结果感到满意，认为这种评论系统更自然，类似于社交媒体。他考虑了一些改进，但核心系统已经足够好，不需要急于改变。作者认为这种方法有效，因为它利用了现有的社交媒体账户，而不是强迫用户创建新账户和学习新界面。这种方法随着 Bluesky 的成长而扩展，不需要作者额外的工作，并且因为一切都建立在开放协议上，作者不会受到任何单一平台决策的限制。作者甚至可以考虑编写自己的评论 AppView，因为 ATProto 设计灵活，监听正确的事件并存储数据以重建评论线程相对简单。

作者认为，当独立网站能够连接到更广泛的对话而不失独立性时，网络会更好。他认为 Bluesky 的重点是用户拥有的身份和通过 PDS 实现的应用互操作性，使其成为更好的选择。作者邀请读者在 Bluesky 上加入对话。

HN 热度 256 points | 评论 102 comments | 作者：g0xA52A2A | 8 hours ago #

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

  • Cactus.chat 是一个基于 Matrix 的评论系统，支持游客评论。
  • 有人建议使用自己的 Matrix 账户来评论，这样可以加入 Matrix 聊天室。
  • 有人分享了自己构建的简单评论系统，评论存储为文本文件，手动审核后发布。
  • 有人通过电子邮件形式接收评论，然后手动添加到文章下。
  • 有人直接在文章底部提供自己的电子邮件地址，不使用表单。
  • 有人觉得评论不值得麻烦，因此没有在自己的网站上包含评论功能。
  • 有人将评论比作报纸的“读者来信”。
  • Bluesky 对于存储用户现有账户信息很有用，有人基于 Bluesky 构建了评论系统。
  • 有人建议使用 Mangrove.reviews 而不是 Bluesky，因为 Mangrove 使用 CC-BY-SA 许可证。
  • 有人对 Bluesky 的盈利能力持怀疑态度，担心 API 会锁定，导致评论系统失效。
  • Bluesky 架构允许用户切换到其他提供商的个人数据服务器。
  • 有人支持 POSSE（在自己的网站上发布，同时在社交平台分享）的理念。
  • 有人建议 Bluesky 应该像 Squarespace 那样运营域名注册。
  • Bluesky 社区目前很有趣，但未来如何发展还有待观察。
  • 有人担心 Bluesky 会重现 Twitter 的问题，导致账户被禁或被黑名单。
  • 有人对 Bluesky 的开放性和新想法表示赞赏。

Rules by which a great empire may be reduced to a small one (1773) #

https://founders.archives.gov/documents/Franklin/01-20-02-0213

本杰明·富兰克林在 1773 年 9 月 11 日撰写了一篇讽刺文章《使大帝国缩小为小帝国的规则》，该文发表在《公共广告者》上。富兰克林通过这篇文章和另一篇《普鲁士国王的法令》来吸引公众关注美国问题，目的是让公众重新审视美洲殖民地的困境。文章中，富兰克林以幽默讽刺的方式，向管理广阔领土的部长们提出了一系列“规则”，这些规则实际上是对英国政府对待殖民地政策的批评。

文章中提出的“规则”包括：首先关注最偏远的省份，使它们与母国分离；确保殖民地不享有与母国相同的权益，受到更严格的法律约束；忽略殖民地对母国的贡献，甚至将它们的忠诚视为冒犯；将殖民地视为潜在的叛乱者，驻扎军队以压制任何不满；精心挑选贪婪或无能的官员担任总督和法官，以破坏殖民地对母国政府的信任；对于投诉不公的殖民地居民，要严厉惩罚，以加深他们对政府的负面印象。

富兰克林的讽刺手法旨在揭露英国政府政策的荒谬，尽管他希望通过这种方式引起关注并促使改变，但他也意识到讽刺可能无法说服那些固执己见的人，反而可能激怒他们。尽管如此，这些文章在当时广受欢迎，并在英国和美国被广泛转载。然而，讽刺的效果是短暂的，政府很快对富兰克林进行了反击，许多“规则”最终在 1774 年的强制法案中被立法实施。

HN 热度 251 points | 评论 159 comments | 作者：freediver | 1 day ago #

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

  • 本杰明·富兰克林在英国生活了 13 年，试图游说议会和国王关注殖民地对英国治理的不满。
  • 富兰克林博物馆提供了对他生活时期的有趣视角。
  • 富兰克林研究所位于费城。
  • 有人提到了位于伦敦的本杰明·富兰克林故居。
  • 富兰克林是共济会成员。
  • 富兰克林在礼貌地请求后，以讽刺的方式反映出英国的态度。
  • 富兰克林对英国的爱和他 15 年后返回殖民地的行为显示了他的性格。
  • 有人讨论了关于一个被标记的评论，询问它如何反映了富兰克林的性格。
  • 有人提出，性格是荣誉、原则、正直和更高水平的学习和理解的组合。
  • 有人提到了个性障碍。
  • 有人指出，南方邦联通过攻击美国政府军事设施引发了内战，而不是林肯。
  • 林肯在内战期间暂停了人身保护令，但没有国会批准，囚禁了政治对手、记者，进行了针对平民的军事审判，并广泛使用行政命令统治。
  • 有人批评对历史人物的贬低和破坏行为。
  • 西方的敌人试图破坏西方社会文化，但西方社会由个体主义者组成，这种破坏行为是徒劳的。

Running GPT-OSS-120B at 500 tokens per second on Nvidia GPUs #

https://www.baseten.co/blog/sota-performance-for-gpt-oss-120b-on-nvidia-gpus/

这篇文章介绍了如何优化 GPT OSS 120B 模型在 NVIDIA GPU 上的性能，以达到最佳延迟和吞吐量。作者们分享了他们在模型发布当天所采取的步骤，包括运行首次推理、修复兼容性错误和优化模型配置。他们使用了 Baseten 推理堆栈，并在 TensorRT-LLM、vLLM 和 SGLang 等推理框架上进行测试和基准测试，确保与 Hopper 和 Blackwell GPU 架构的兼容性，并集成了 NVIDIA Dynamo 等关键组件。他们选择了 Tensor Parallelism 来优化延迟，并采用了 TensorRT-LLM MoE 后端来提高性能。文章还提到了他们为 Hopper GPU 打包的首选配置，并使用 Blackwell 进行模型 API。最后，文章提到了他们正在研究的下一个性能优化更新，即添加推测性解码，以加速推理过程。作者们还提到，他们正在积极招聘模型性能工程师，并鼓励 AI 工程团队联系他们以优化延迟和吞吐量。

HN 热度 232 points | 评论 162 comments | 作者：philipkiely | 22 hours ago #

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

  • 家用抽屉里没有价值 25000 美元的 GPU 是意料之中的。
  • 应该有一种更快的方式来区分消费级硬件和企业级硬件。
  • 数学协处理器可能会回归。
  • 希望 Nvidia 能推出更快的硬件更新周期，并用品牌编号代替"H”。
  • 过去曾将高端工作站称为"加速卡"。
  • 大多数 GPU 中都包含张量核心。
  • 区分 SXM（节点）和 PCIe 是为了区分不同类型的 GPU。
  • “GPGPU"是十多年前的概念，现在更多用于通用 GPU 计算。
  • Crysis 游戏在 2007 年就可以在 GPU 上运行物理计算。
  • 苹果和博通分别将这类硬件称为 NPU 和 XPU。
  • 25000 美元的专业 GPU 和同等价格的多个消费级 GPU 相比，后者性能更强。
  • 消费级 GPU 理论上性能更强，但受到互连限制。
  • H100 有自定义的异步 WGMMA 指令，有助于优化内存访问。
  • 可以将消费级 GPU 称为 GFX 卡，而将矩阵乘法专用的称为 GPU。
  • GPU 代表“图形处理单元”，建议改为 MPU，M 代表矩阵/数学/MIPS。
  • 有人认为 GPU 已经从“图形”变为“通用”处理单元。
  • CPU 已经是通用计算处理单元，所以将 GPU 改为 MPU 并不合理。
  • 没有图形连接器的 GPU 不能处理图形。
  • RTX Pro 6000 虽然不是消费级产品，但有图形端口，可以渲染图形。
  • 区分 GPU 类别不能仅通过查看是否具有图形连接器。
  • 租用 GPU 比购买更划算，尤其是对于数据中心级别的卡。
  • 在 H100 上训练模型时遇到了问题，与在 Mac M1 或 RTX 5080 上的结果不同。
  • 从数据中心的角度来看，最快的硬件可能是旧的 iPhone 8。
  • Ollama 的 20B 模型可以在 8 张 TitanX 卡（2015 年）上运行。
  • 可以用 8 张旧 Titan X 卡的价格购买一张现代 GPU，拥有 16GB 或更多的 RAM。
  • 在许多地方可以以每小时不到 2 美元的价格租用 GPU。
  • “可用"并不意味着"便宜”。
  • 可以从大多数云提供商那里租用 GPU，每小时只需几美元。
  • 也可以直接使用 OpenAI 的 API。

Zero-day flaws in authentication, identity, authorization in HashiCorp Vault #

https://cyata.ai/blog/cracking-the-vault-how-we-found-zero-day-flaws-in-authentication-identity-and-authorization-in-hashicorp-vault/

2025 年 8 月 6 日，Cyata 的研究团队发表了一篇关于 HashiCorp Vault（Vault）的研究报告，揭示了在身份验证、身份和授权方面发现的九个零日漏洞。这些漏洞通过负责任的披露被分配了 CVE 编号，并与 HashiCorp 紧密合作，确保在公开发布前所有问题都已修复。这些漏洞可以绕过锁定、逃避策略检查，并实现冒充。其中一个漏洞甚至允许 root 级别的权限提升，另一个则导致了 Vault 首次公开报告的远程代码执行（RCE），使攻击者能够完全接管系统。

HashiCorp Vault 是一个开源工具，用于安全地存储和管理密钥，包括 API 密钥、数据库密码、证书和加密密钥。Vault 在现代 DevSecOps 流程中扮演着关键角色，帮助团队减少硬编码凭证、密钥扩散和未经授权访问的风险。Vault 的核心功能包括动态、多云和混合环境的密钥管理和加密引擎、通过 API 访问的集中式密钥存储、自动过期的动态凭证配置、基于身份的访问控制支持人类和机器认证、数据静态和传输中的加密服务、生成、轮换和撤销证书的证书管理，以及分发、启用、禁用和轮换加密密钥。

Cyata 的研究团队通过深入调查 Vault 的核心请求流程，特别是作为 Vault“大脑”的 request_handling.go 文件，发现了这些逻辑级别的漏洞。他们没有依赖于模糊测试或自动探针，而是进行了深入的手动源代码审查，寻找边缘情况，这些情况可能会模糊信任边界。通过重复发现微妙的不一致性、推理它们的下游影响，并通过控制测试来验证它们的过程，研究团队发现了报告中披露的九个漏洞。

研究团队首先检查了 Vault 在 userpass 身份验证下如何执行锁定保护，特别是如何跟踪、限制和归因失败的登录尝试。他们发现了三个与 Vault 跟踪和处理失败登录尝试相关的漏洞：CVE-2025-6010（待修复，暂时不公开）、CVE-2025-6004（通过改变已知用户名的大小写来重置锁定计数器，继续暴力破解）和 CVE-2025-6011（基于时间的枚举）。

HN 热度 231 points | 评论 91 comments | 作者：nihsy | 17 hours ago #

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

  • 作者 Shahar 澄清，所有漏洞都是由人类 Yarden Porat 手动发现，报告主要也是人类撰写，只是为了让更广泛的受众理解
  • 评论者 yodon 认为，尽管文章有 AI 写作的痕迹，但写得非常好，值得一读
  • skybrian 认为，关于文章是否由 AI 撰写的评论并不具有建设性，应该关注文章内容而非表现形式
  • oasisbob 认为文章过于冗长，如果 AI 参与了写作，这是值得讨论的问题
  • winwang 认为，文章的问题不在于是否由 AI 撰写，而在于写作质量不高
  • tptacek 认为，是否需要一个 logo 和微网站是论坛上的辩论话题，与漏洞研究实践不太相关
  • mike_hearn 认为文章信息量很大，值得一读，强调了在安全敏感软件中要小心处理字符串规范化调用
  • progbits 认为字符串规范化应该在正确的位置进行，而不是随意进行
  • Normal_gaussian 认为，我们早就应该对登录凭证进行严格的封装，这是十多年前就已经讨论过的问题
  • ramenfunded 指出，就像“不要用浮点数处理金钱”一样，尽管讨论过，但在每个初创公司中仍然看到相同的错误
  • jerf 认为，如果出现问题，可以通过类型定义来确保修复措施得到广泛传播
  • benterix 认为，尽管文章有 AI 的痕迹，但信息量很大，值得容忍
  • cipherboy 代表 OpenBao 项目，对未被告知漏洞表示失望，并提到他们已经修复了大部分漏洞
  • tptacek 指出，未授权的分支可能不会在保密名单中，这是开源项目社区驱动性质的一部分
  • cipherboy 回应 tptacek，认为他们作为一个已知实体，应该被告知这些漏洞，并对 HashiCorp 的回应表示不满

Gemini CLI GitHub Actions #

https://blog.google/technology/developers/introducing-gemini-cli-github-actions/

Gemini CLI GitHub Actions 是一个免费且强大的人工智能编码助手，可以为您的代码库提供帮助。它既可以作为一个自主代理来处理关键的日常编码任务，也可以作为一个按需合作者，让您能够快速委派工作。自 6 月份推出 Gemini CLI 以来，开发者的热情采用令人难以置信。为了跟上功能请求和贡献的洪流，我们使用 Gemini CLI 自动化问题分类和拉取请求审查。社区成员注意到我们的新工作流程后，要求我们分享我们的构建成果。今天，我们推出了 Gemini CLI GitHub Actions。它现在处于测试阶段，全球所有人都可以使用，并可以在 GitHub 上找到，地址为 google-github-actions/run-gemini-cli。

Gemini CLI GitHub Actions 是为团队协作而创建的，它在开发者相互合作的平台上工作。它由新问题或拉取请求等事件触发，异步在后台工作，使用项目的完整上下文自动处理任务。它了解您的代码，知道您想要做什么，并能完成它。

我们推出了三个功能强大的开源工作流程，可以帮助您更好地、更快地编码：

  1. 智能问题分类：自动化管理新问题的开销。Gemini CLI 可以分析、标记和优先处理传入的问题，帮助您集中注意力在最重要的事情上。
  2. 加速拉取请求审查：获得对代码更改的即时、有见地的反馈。Gemini CLI 可以审查拉取请求的质量、风格和正确性，释放审查者专注于更复杂的任务和决策。
  3. 按需协作：在任何问题或拉取请求中简单地提到 @gemini-cli 来委派任务。告诉它做诸如“为这个错误编写测试”、“实现上述建议的更改”、“头脑风暴替代解决方案”或“修复这个定义良好的错误”等事情。

您可以轻松地在 GitHub 上为 Gemini CLI 创建新功能请求，让它代表您处理。 Gemini CLI GitHub Actions 可以处理您的拉取请求，提供代码更改和人工智能生成的改进用户体验的建议。 通过“@gemini-cli”标签委派工作，代理可以完成从编写错误到修复错误的一系列任务。

这些初始工作流程可以作为您的起点。它们是开源的，并且完全可定制的——您可以创建自己的工作流程，或者配置 Gemini CLI GitHub Actions 中内置的工作流程。

Gemini CLI GitHub Actions 内置了企业级的安全和控制：

  • 安全的无凭证认证：Vertex AI 和 Gemini Code Assist Standard 和 Enterprise 用户可以利用 Google Cloud 的工作负载身份联合（WIF）来消除环境中长期 API 密钥的需求，大幅降低凭证泄露的风险。
  • 细粒度控制：通过多层控制强制执行最小权限原则。使用命令允许列表等功能，明确批准代理可以执行的每个 shell 命令。您还可以为代理创建自定义身份（例如，gemini-for-your-org），并仅授予它所需的确切权限。
  • 完全透明：GitHub on CLI 与 OpenTelemetry 集成，OpenTelemetry 是遥测的行业标准，因此您可以将日志和指标流式传输到您喜欢的观测工具。

HN 热度 230 points | 评论 93 comments | 作者：michael-sumner | 15 hours ago #

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

  • Google 在产品和研究文化之间需要明确的界限，研究环境的混乱是积极的，但客户界面需要不同的方法。
  • Google 有许多“孵化”空间，团队在其中构建可能成功也可能不成功的项目，这导致产品不是 Google 核心产品的一部分，让人感到困惑。
  • Google 的产品策略导致客户困惑，缺乏整合和责任感，产品常常处于半文档化状态，与其它产品整合不佳。
  • Google 倾向于快速推出产品，如果成功则获得赞誉，如果不成功则放弃，而不是花时间根据用户反馈进行改进。
  • Google 的员工更愿意推出自己的产品以获得奖金和晋升，而不是帮助其他团队改进产品。
  • Google 有多个编程代理，因为公司每个人都在做同样的事情。
  • Gemini 应用即使有访问用户 Google 账户和手机的权限，也被认为无用。
  • Gemini 应用在欢迎屏幕上显示用户的名字，但当被问及用户的名字时，却表示不知道，这种矛盾情况令人觉得有趣。
  • Gemini 应用中的“Hello Vasco”是生成的背景图片，并非聊天上下文的一部分。
  • Google 可能面临管理结构的失败，而不是仅仅是管理问题，许多团队可能放弃了旧项目，转而追求新的热门项目，忽视了客户、一致性和收入。

Infinite Pixels #

https://meyerweb.com/eric/thoughts/2025/08/07/infinite-pixels/

作者在社交媒体上发现了一个有趣的 CSS 技巧，即通过设置 width: calc(infinity * 1px); 和 height: calc(infinity * 1px); 来测试浏览器如何处理无限大的值。他首先按照这个技巧编写了一个简单的 HTML 页面，并在 Firefox Nightly、Chrome 稳定版和 Safari 稳定版上进行了测试。结果显示，Safari 和 Chrome 都将值限制在大约 33,554,400 左右，而 Firefox Nightly 则将高度计算为 19.2px，宽度计算为 17,895,700px，实际布局宽度为 8,947,840px。作者对这些结果感到困惑，希望有人能解释这些现象的原因。

接着，作者尝试将字体大小设置为 font-size: calc(infinity * 1px);，结果 Safari 和 Chrome 分别限制在 100,000 和 10,000，而 Firefox Nightly 计算值为一个 32 位单精度浮点数，实际字体大小为 2,400px。作者对这些结果同样感到不解，并尝试了将行高设置为无限大，发现 Safari 和 Chrome 的结果与元素宽度测试相似，Firefox Nightly 的计算值和渲染大小也与之前相似。

作者表示，他对这些测试结果感到困惑，并希望有人能提供解释。他还提到，他正在考虑测试 calc(-infinity) 可能带来的影响。这篇文章发表于 2025 年 8 月 7 日，归类于浏览器和 CSS 类别，并收到了七条回复。

HN 热度 211 points | 评论 48 comments | 作者：OuterVale | 11 hours ago #

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

  • Firefox 使用 32 位有符号整数，并且有一个高度声明限制，超过 17895697px 将被忽略。
  • Firefox 的单位设计很聪明，60 可以被 3、4、5 和 6 整除，未来适用于设备像素比为 6 的显示器。
  • Netscape 在加载期间假设布局是无限的，而 IE4 假设所有元素大小为零，这影响了两者的加载速度。
  • WebKit 使用 1/64 像素的布局单位，因此 2^25-1 像素实际上是 2^31-1 个布局单位。
  • 2^25-1 像素限制很有意义，因为 1/64 像素精度下，这正好是 2^31-1 个布局单位。
  • Chrome 和 Safari 接近 225-1 像素限制，Safari 比 Chrome 少 3 像素，Firefox 少 31 像素。
  • 使用虚拟 DOM/画布的无限数据网格可以获得原生滚动条的性能/可用性。
  • 对于非常大的网格，接近文章中描述的高度限制时，性能会下降。
  • 重新实现滚动条在移动设备上效果不佳，失去了“轻拂”/惯性/动量触摸手势。
  • 可以考虑使用“无限滚动”分页堆叠虚拟列表，或者在用户接近列表末尾时完全替换内容。
  • Blink（Chrome 的渲染引擎）是从 WebKit（Safari）分叉出来的，因此它们可能共享相同的底层代码。
  • CSS 中的“infinity”关键词与 JavaScript 中的“Infinity”关键词不同，前者仅存在 2-3 年。

Hacker News 精彩评论及翻译 #

Emailing a one-time code is worse than passwords #

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

The attack pattern is:

  1. User goes to BAD website and signs up.

  2. BAD website says “We’ve sent you an email, please enter the 6-digit code! The email will come from GOOD, as they are our sign-in partner.”

  3. BAD’s bots start a “Sign in with email one-time code” flow on the GOOD website using the user’s email.

  4. GOOD sends a one-time login code email to the user’s email address.

  5. The user is very likely to trust this email, because it’s from GOOD, and why would GOOD send it if it’s not a proper login?

  6. User enters code into BAD’s website.

  7. BAD uses code to login to GOOD’s website as the user. BAD now has full access to the user’s GOOD account.

This is why “email me a one-time code” is one of the worst authentication flows for phishing. It’s just so hard to stop users from making this mistake.

“Click a link in the email” is a tiny bit better because it takes the user straight to the GOOD website, and passing that link to BAD is more tedious and therefore more suspicious. However, if some popular email service suddenly decides your login emails or the login link within should be blocked, then suddenly many of your users cannot login.

Passkeys is the way to go. Password manager support for passkeys is getting really good. And I assure you, all passkeys being lost when a user loses their phone is far, far better than what’s been happening with passwords. I’d rather granny needs to visit the bank to get access to her account again, than someone phishes her and steals all her money.

DecoPerson

攻击模式是：

  1. 访问恶意网站并注册。
  2. 恶意网站显示：“我们已向您发送电子邮件，请输入6位验证码！邮件将来自“GOOD”，因为它是我们的登录合作伙伴。”
  3. 恶意网站的机器人使用用户的电子邮件在“GOOD”网站上启动“使用电子邮件一次性代码登录”流程。
  4. “GOOD”向用户的电子邮件地址发送一次性登录代码邮件。
  5. 用户很可能会信任这封邮件，因为它来自“GOOD”，如果不是正常的登录，为什么“GOOD”会发送呢？
  6. 用户将代码输入到恶意网站。
  7. 恶意使用该代码以用户身份登录“GOOD”网站。恶意如今可以完全访问用户的“GOOD”账户。

这就是为什么“给我发送电子邮件一次性代码”是用于网络钓鱼的最糟糕的认证流程之一。用户很难不犯这个错误。

“点击邮件中的链接”会稍微好一点，因为这样可以直接将用户带到“GOOD”网站，并且将该链接转发给“BAD”更加繁琐，因此也更值得怀疑。然而，如果某个热门电子邮件服务突然决定要拦截您的登录邮件或其中的链接，那么您的许多用户将突然无法登录。

使用通行密钥是正确的方案。密码管理器对通行密钥的支持已经非常好了。我可以向你保证，当用户丢失手机导致所有通行密钥丢失，这远比密码泄露的情况要好得多。我宁愿让奶奶需要去银行才能重新获得对账户的访问权限，也不愿有人通过网络钓鱼骗走她的所有钱。

GPT-5 #

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

It is frequently suggested that once one of the AI companies reaches an AGI threshold, they will take off ahead of the rest. It’s interesting to note that at least so far, the trend has been the opposite: as time goes on and the models get better, the performance of the different company’s gets clustered closer together. Right now GPT-5, Claude Opus, Grok 4, Gemini 2.5 Pro all seem quite good across the board (ie they can all basically solve moderately challenging math and coding problems).

As a user, it feels like the race has never been as close as it is now. Perhaps dumb to extrapolate, but it makes me lean more skeptical about the hard take-off / winner-take-all mental model that has been pushed.

Would be curious to hear the take of a researcher at one of these firms - do you expect the AI offerings across competitors to become more competitive and clustered over the next few years, or less so?

highfrequency

人们经常说到，一旦某家人工智能公司达到了通用人工智能（AGI）的门槛，它就会与其他人拉开差距，一骑绝尘。但值得注意的是，至少到目前为止，趋势恰恰相反：随着时间的推移和模型的不断完善，不同公司产品的性能正变得越来越接近，趋向于趋同。目前，GPT-5、Claude Opus、Grok 4和Gemini 2.5 Pro整个来看都非常出色（即它们在数学和编程等各个方面表现都很不错）。

作为用户，我感觉这场竞赛从未像现在这般旗鼓相当。也许这种推测有些草率，但这让我对人言啧啧的“硬性起飞/赢家通吃”的思维模式更加怀疑了。

我很想听听这些公司的研究员们的看法——您认为在未来的几年里，竞争对手之间的人工智能产品会变得更加激烈也更加趋同，还是相反呢？

GPT-5 #

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

Perhaps it is not possible to simulate higher-level intelligence using a stochastic model for predicting text.

I am not an AI researcher, but I have friends who do work in the field, and they are not worried about LLM-based AGI because of the diminishing returns on results vs amount of training data required. Maybe this is the bottleneck.

Human intelligence is markedly different from LLMs: it requires far fewer examples to train on, and generalizes way better. Whereas LLMs tend to regurgitate solutions to solved problems, where the solutions tend to be well-published in training data.

That being said, AGI is not a necessary requirement for AI to be totally world-changing. There are possibly applications of existing AI/ML/SL technology which could be more impactful than general intelligence. Search is one example where the ability to regurgitate knowledge from many domains is desirable

beeflet

也许，使用一个用于预测文本的随机模型，是无法模拟高层次智能的。我不是人工智能研究员，但我的朋友们就在这个行业里工作，他们并不担心基于大语言模型的通用人工智能，因为其结果与所需的训练数据量相比存在收益递减。或许这就是瓶颈。

人类智能与LLMs有显著差异：训练所需的样本量要少得多，且泛化能力也强得多。LLMs却往往倾向于鹦鹉学舌般地复现那些已解决好问题的解决方案，而这些方案在其训练数据中通常都有广泛记载。

话虽如此，要让AI实现对世界的彻底变革，通用人工智能并不是一个必要条件。现有的人工智能/机器学习/监督学习技术可能存在一些应用，其影响力甚至会超过通用智能本身。搜索就是一个很好的例子，其能够复述海量多领域知识的特性，恰恰是所期望的。

GPT-5 #

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

What’s going on with their SWE bench graph?[0]

GPT-5 non-thinking is labeled 52.8% accuracy, but o3 is shown as a much shorter bar, yet it’s labeled 69.1%. And 4o is an identical bar to o3, but it’s labeled 30.8%…

[0] https://i.postimg.cc/DzkZZLry/y-axis.png

mtlynch

他们的SWE基准测试图表是怎么回事？ GPT-5 非思考版标着 52.8% 的准确率，但 o3 的柱形却短得多，标签上却写着 69.1%。而 4o 的柱形又和 o3 完全一样… 结果它却标着 30.8%…