2025 06 14 HackerNews

2025-06-14 Hacker News Top Stories #

GCP在2025年6月13日发生了为期7小时27分钟的中断，影响了52个产品和58个地区，可能由内部服务Chemist故障引发，并波及依赖GCP的第三方服务。

频繁的重新认证并不会提升安全性，可能导致工作流程中断和多因素认证疲劳，安全性应通过有效的访问权限管理和快速响应策略来实现。

Jemalloc内存分配器自2004年诞生以来经历了三个主要发展阶段，成功解决了碎片问题，并在性能上取得了显著成就，但在Meta时期发展放缓。

如果月球只有一个像素，太阳系模型展现了宇宙的浩瀚，光速在宇宙尺度上显得缓慢，人类对宇宙的感知受到自身尺度和新陈代谢的限制。

通过直接光栅化字形曲线，实现了GPU上实时渲染清晰文本，解决了子像素抗锯齿和高质量渲染问题。

Meta投资143亿美元用于启动超级智能实验室，增强其在人工智能领域的实力，显示了其在AI领域的战略布局和竞争决心。

Cloudflare因关键Workers KV服务中断而出现服务中断，可能与第三方服务故障有关，事件已恢复但仍在监控平台稳定性。

OxCaml是OCaml编程语言的扩展，专注于性能优化，特别是在并发和内存管理方面，适合高性能应用场景，但仍处于实验性阶段。

一些虚假广告技术帝国利用虚假CAPTCHA和推送通知传播虚假信息，绕过社交媒体平台的内容审核，构成网络安全威胁。

一个用Go语言从零开始编写的BitTorrent客户端实现了核心功能，包括种子文件解析和对等体通信，计划添加磁力链接和DHT支持。

GCP Outage #

https://status.cloud.google.com/

这个网页是 Google Cloud 的服务状态页面，提供了 Google Cloud 服务的状态信息。用户可以在这里查看服务的当前状态，并在遇到未列出的问题时联系支持。页面还提供了一个 FAQ 链接，用于了解更多关于仪表板上发布内容的信息，并且可以访问 Google Cloud 的官方网站以获取有关这些服务的额外信息。

页面上显示了最近发生的一起事故，该事故发生在 2025 年 6 月 13 日，18:00 PDT 更新，持续时间为 7 小时 27 分钟，已关闭。这次事故影响了多个 GCP 产品，包括 API Gateway、Agent Assist、AlloyDB for PostgreSQL 等 52 个产品，以及 africa-south1、asia、asia-east1 等 58 个地区。用户可以查看事故历史记录。

页面还提供了按产品和地区检查状态的功能。用户可以通过点击不同的标签来检查特定地区和多地区的状态。多地区服务由 Google 管理，以确保在一个大地理区域内的多个地区中具有冗余和分布。全球服务状态指的是特定全球分布服务的状态，并不涉及全球所有产品服务。

HN 热度 1429 points | 评论 491 comments | 作者：thanhhaimai | 1 day ago #

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

Google Cloud Platform（GCP）的中断可能是由于 Google 内部名为 Chemist 的中心服务故障导致的。
Firebase Auth 和 FCM 可能也受到了影响。
不仅是 GCP，多个互联网服务都出现了中断。
Cloudflare 的中断可能是由于依赖 Google 的一个关键第三方服务导致的。
Cloudflare 的基础设施可能缺乏冗余，因为它依赖于 GCP。
云服务提供商之间应该减少相互依赖。
Cloudflare 可能认为自己的基础设施是独立的，但这次事件后可能会重新评估。
即使有冗余，也不能保证完全免疫于故障。
有人认为 Google 是一家以广告为主的公司，不应依赖其进行任何非广告收入相关的临界任务。
Amazon 被看作是一家云服务公司，AWS 比零售业务更重要。
Cloudflare 可能没有自己的基础设施，这令人惊讶，因为它是一个大规模的互联网服务提供商。
Cloudflare 的非边缘计算可能完全依赖于 GCP 等竞争对手的云服务。
Cloudflare 的主要业务模式是 B2B，依赖于少数高价值客户，因此没有避免依赖 Google 等云服务的战略理由。

Frequent reauth doesn’t make you more secure #

https://tailscale.com/blog/frequent-reath-security

这篇文章讨论了频繁重新认证对安全性的影响，并解释了为什么这种做法可能适得其反。文章由 Avery Pennarun 撰写，他指出频繁的登录提示不仅打断工作流程，让用户感到沮丧，而且实际上可能削弱安全态势。

文章首先描述了一个常见的场景：用户在专注工作时，会话突然过期，需要重新输入密码和完成多因素认证（MFA），这种重复的操作不仅令人烦恼，而且随着合法 MFA 请求的增多，MFA 疲劳成为网络钓鱼的一个日益增长的攻击向量。作者指出，过去人们认为频繁更改密码和登录是好的安全措施，但现在发现事实并非如此。

文章强调，安全性不在于登录的频率，而在于如何有效地管理访问权限，如何快速响应账户策略变化，以及如何确信用户的密钥自上次认证以来未被泄露。文章提到，可以通过不让用户感到痛苦的方式获得强大的安全保证。

接着，文章探讨了认证通常检查的两个方面：用户是否仍然拥有物理设备，以及用户是否是正确的人。身份提供商（IdPs）主要关注用户身份，而集成的认证系统如苹果的 Face ID 和 Touch ID，以及 Windows Hello 等工具，同时检查两者。

文章解释了为什么频繁重新登录存在：通常是因为管理员不确信更改会立即生效。有时，尤其是在 SAML 配置中，IdP 被配置为仅在用户交互式登录过程中向应用程序发送策略属性，这意味着他们需要新的登录才能更新。文章提出，频繁登录并不是正确的答案，因为它们解决了错误的问题，给攻击者提供了更多窃取凭证的机会，并且现代操作系统已经通过屏幕锁定解决了这个问题。

文章还提到，网站会话过期几乎不提供任何保护，对于大多数人来说，这只是过去时代的遗物。文章建议，正确的安全处理方式应该是在关键时刻检查设备占有，使用连续验证而不是频繁登录。例如，Tailscale SSH 的检查模式和 Tailscale Slack Accessbot 仅在真正重要的时候验证用户是否在场，而不是基于任意的时间间隔。文章强调，安全应该是连续的，而不是与任意的交互周期绑定。

最后，文章总结说，频繁登录并没有让你更安全，它们只是让你养成了更糟糕的安全习惯。最好的安全是在后台悄然发生的，确保安全而不碍事。Tailscale 相信安全应该是适应性强、智能的，并且真正有用，而不仅仅是安全表演。Tailscale 确保在正确的时刻以最小的摩擦进行认证，而不是强迫用户进行无意义的登录。

HN 热度 1134 points | 评论 478 comments | 作者：ingve | 1 day ago #

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

频繁的密码重置并不会使账户更安全，反而可能导致用户在假期等时候被锁定，需要联系 IT 部门重置密码。
许多公司仍然执行密码过期政策，尽管 NIST 和微软已经不推荐这种做法。
密码复杂性要求通常来自审计要求，而非 IT 部门，因为这样可以降低保险费用或信用卡处理费用。
一些密码政策可能是为了在发生数据泄露时提供证据，表明公司已经尽力采取了安全措施。
某些密码政策可能来自网络安全保险政策的要求。
一些密码政策可能是为了避免支付保险金。
大型系统的惯性和市场失灵导致密码政策更新缓慢。
改变现有政策可能带来个人责任风险，因此决策者更倾向于维持现状。
有些系统为了防止密码重复使用，会存储旧密码的历史记录。
有些系统会拒绝与之前 30 个密码相似的新密码，这可能导致密码列表以明文或可逆加密形式存储，成为黑客攻击的目标。
通过存储密码的多个哈希版本，可以在不直接存储密码的情况下检测密码是否重复。
存储所有可能的密码变体的哈希值是不切实际的，因为组合爆炸会导致存储需求过高。
如果密码守卫不要求输入旧密码，那么他们可能存储了用户的密码。
频繁的密码更改可能导致系统错误，如“broken pipe”。
有些系统要求新密码与旧密码有超过一定数量的字符不同。

Jemalloc Postmortem #

https://jasone.github.io/2025/06/12/jemalloc-postmortem/

jemalloc 内存分配器的回顾

jemalloc 内存分配器自 2004 年初诞生以来，已经公开使用了约 20 年。由于开源软件许可证的性质，jemalloc 将无限期地公开可用。但活跃的上游开发已经结束。本文简要描述了 jemalloc 的开发阶段，每个阶段都有一些成功和失败的亮点，然后进行一些回顾性评论。

第一阶段：Lyken 2004 年，作者开始在科学计算的背景下开发 Lyken 编程语言。Lyken 最终走入了死胡同，但其手动内存分配器在 2005 年 5 月功能完整。（计划利用其特性的垃圾收集器从未完成。）2005 年 9 月，作者开始将分配器集成到 FreeBSD 中，2006 年 3 月，作者将分配器从 Lyken 中移除，转而使用系统分配器功能的薄包装。

为什么在投入了如此多的努力之后，还要从 Lyken 中移除内存分配器呢？一旦分配器被集成到 FreeBSD 中，就很明显系统分配器缺少的唯一特性是跟踪分配量以触发每个线程的垃圾收集的机制。这可以通过使用线程特定数据和 dlsym(3)的薄包装实现。有趣的是，许多年后，jemalloc 甚至添加了 Lyken 所需的统计收集。

第二阶段：FreeBSD 回到 2005 年，向多处理器计算机的过渡正在进行中。FreeBSD 有 Poul-Henning Kamp 的优秀 phkmalloc 内存分配器，但该分配器没有为并行线程执行提供任何规定。Lyken 的分配器似乎是一个明显的可扩展性改进，并且在朋友和同事的鼓励下，作者将很快被称为 jemalloc 的分配器集成进来。但是，不久之后，很明显 jemalloc 在某些负载下存在严重的碎片问题，特别是由 KDE 应用程序引起的负载。就在我认为我几乎完成的时候，这个现实世界的失败使 jemalloc 的可行性受到质疑。

简而言之，碎片问题源于使用统一的范围分配方法（即没有大小类隔离）。作者从 Doug Lea 的 dlmalloc 中获得了基本的灵感，但没有避免许多最糟糕的碎片问题的交织在一起的经过实战测试的启发式方法。随后进行了大量的研究和实验。到 jemalloc 成为 FreeBSD 发布的一部分时，其布局算法已经完全改变，使用大小隔离的区域，如 2006 年 BSDCan jemalloc 论文中所描述。

第二阶段 1.5：Firefox 2007 年 11 月，Mozilla Firefox 3 即将发布，高碎片化是一个未解决的问题，特别是在 Microsoft Windows 上。因此，作者开始与 Mozilla 合作进行内存分配工作。将 jemalloc 移植到 Linux 是微不足道的，但 Windows 是另一回事。规范的 jemalloc 源代码在 FreeBSD libc 库中，所以我们基本上分叉了 jemalloc 并添加了可移植性代码，将任何与 FreeBSD 相关的内容上游化。整个实现仍然在一个文件中，这减少了分叉维护的摩擦，但在这个阶段的开发中，实现的复杂性肯定超过了一个文件的合理性。

多年后，Mozilla 开发人员对上游 jemalloc 做出了重大贡献，试图摆脱他们的分叉。不幸的是，Mozilla 的基准测试一致显示分叉版本优于上游版本。我不知道这是因为过度适应局部最优还是实际表明性能退化，但这仍然是我最大的 jemalloc 失望之一。

第三阶段：Facebook 当作者在 2009 年开始在 Facebook 工作时，他惊讶地发现，Facebook 基础设施中普遍使用 jemalloc 的最大障碍是工具。关键的内部服务处于尴尬的境地，依赖 jemalloc 来控制内存碎片，但工程师需要使用 tcmalloc 和 gperftools 中的 pprof 堆分析工具进行内存泄漏调试。pprof 兼容的堆分析功能成为 jemalloc 1.0.0 版本的头条。

jemalloc 开发迁移到 GitHub，并在接下来的几年中，随着问题和机会的出现，继续零星地进行。其他开发人员开始贡献重要的功能。3.0.0 版本引入了广泛的测试基础设施和 Valgrind 支持。4.x 版本引入了基于衰减的清除和 JSON 格式的遥测。5.x 系列从“chunks”转变为“extents”，为与 2 MiB 大页面的更好交互铺平了道路。

更具争议的是，作者在 5.0.0 中移除了 Valgrind 支持，因为它是一个重大的维护复杂性（在微妙的地方有许多触角），并且在 Facebook 内部未使用；其他工具如 pprof 和 MemorySanitizer 占主导地位。作者收到的关于 Valgrind 支持的反馈很少，推断它没有被使用。回想起来，情况似乎并非如此。特别是，Rust 语言直接将 jemalloc 集成到编译程序中，我认为 Rust 开发人员和 Valgrind 开发人员之间有一些重叠。人们很生气。

jemalloc 可能比自然发展过程更早地从 Rust 二进制文件中被移除。

Facebook 的内部遥测令人惊叹，拥有来自无数服务的性能数据，对内存分配器开发是一个巨大的好处。我不认为这是一个偶然，过去十年中两个最快的内存分配器（tcmalloc 和 jemalloc）都从这样的数据中受益。即使是“简单”的事情，如快速路径优化，当手头有聚合的 Linux perf 数据时，也更容易做对。更难的事情，如避免碎片化，仍然很难，但如果成千上万的不同工作流程表现良好，没有异常回归，那么一个变化可能是安全的。jemalloc 从成为 Facebook 基础设施的一部分中获益匪浅，无论是在性能、弹性还是一致行为方面。此外，jemalloc 自己的集成统计报告功能直接响应这种无处不在的遥测环境，这通常对 jemalloc 开发和非 Facebook 应用程序的调整/调试都有很大的好处，远远超过了实现工作所需的努力。

在作者在 Facebook 的最后一年，他被鼓励建立一个小型 jemalloc 团队，以便我们可以处理一些否则会令人生畏的大任务。除了主要的性能改进外，我们还得到了持续集成测试和全面的遥测。当作者在 2017 年离开 Facebook 时，jemalloc 团队在没有我的参与下，继续进行了几年的优秀开发和维护工作，这几乎完全是在我的尊敬的同事 Qi Wang 的领导下，并且从提交历史来看，得到了许多其他人的优秀贡献。

第三阶段：Meta 当 Facebook 将自己重新品牌为 Meta 时，jemalloc 开发的性质明显转变。Facebook 基础设施工程减少了对核心技术的投资，而是强调投资回报。这在 jemalloc 的提交历史中是显而易见的。特别是，原则性大页面分配（HPA）的种子早在 2016 年就种下了！HPA 工作继续进行了几年，然后放缓，然后停滞，因为调整堆积在彼此之上，没有进行必要的重构以保持代码库健康。这个功能轨迹最近崩溃了。由于近年来我没有密切参与，所以心碎的感觉有所减轻，但由于 Meta 最近的内部变化，我们不再有人指导 jemalloc 的长期开发，以实现世代……

HN 热度 701 points | 评论 213 comments | 作者：jasone | 23 hours ago #

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

Jemalloc 是性能最好的通用内存分配器，但 TCMalloc 使用起来比较困难，尤其是在不使用 bazel 的情况下。
有人建议在 Jemalloc 最终版本中现代化默认设置，比如禁用“cache oblivious”设置和增加默认“page size”。
有人提到在 HP Superdome 服务器上进行移植工作是一种奇特的体验，并且对 HP 当时的盈利能力表示惊讶。
Itanium 处理器因其独特的架构而备受关注，但也导致了 SGI 的衰落。
有人对 SGI 的衰落表示遗憾，并认为 Itanium 处理器的失败对 ARM 和 POWER 架构是有利的。
有人提到现代编译器技术可能更好地利用 Itanium 架构。
TCMalloc 在 Google 内部使用时与外部使用有很大差异，因为它假设了特定的 Linux 配置选项。
Google 的项目通常很难在外部使用，因为它们与 Google 的系统深度集成。

If the moon were only 1 pixel: A tediously accurate solar system model (2014) #

https://joshworth.com/dev/pixelspace/pixelspace_solarsystem.html

这个网页是一篇关于太阳系和宇宙空间的探索性文章，通过一种旅行的视角，带领读者从地球出发，穿越太阳系，感受宇宙的广阔和空旷。

文章开始于太阳系的边缘，提到了太阳系中的行星，包括水星、金星、地球、火星、木星、土星、天王星和海王星，以及被降级为矮行星的冥王星。作者用幽默的语气表达了宇宙的空旷，提到了从地球出发，即使是到最近的行星，也需要穿越数百万公里的空旷空间。

文章接着描述了太空旅行的漫长和无聊，提到了如果乘坐宇宙飞船前往火星，可能需要七个月的时间，并且需要 2000 部电影来打发时间。作者强调了宇宙中大部分是空旷的空间，即使是在太阳系内，行星之间的距离也非常遥远。

文章中还提到了太阳系的比例问题，指出大多数太阳系的地图都不是按实际比例绘制的，因为实际的空旷空间难以在地图上表现出来。作者提到，即使是在太阳系内，行星之间的距离也是变化的，取决于它们在绕太阳轨道上的位置。

文章通过一些比喻和幽默的语言，试图帮助读者理解宇宙的广阔。比如，如果将地球比作一个像素点，那么需要数百万屏幕并排才能展示整个太阳系的地图。如果按照 300 像素每英寸的打印质量，地球将不可见，而纸张的宽度需要 475 英尺，大约是一个半足球场的长度。

文章还探讨了人类对巨大数字和空旷空间的感知困难，提到了我们习惯于处理比这小得多的尺度。作者指出，我们总是试图为大数字找到比喻，但这些比喻似乎总是不奏效。文章通过一些生动的例子，如水滴侵蚀峡谷、阿米巴变成海豚、恒星坍缩等，来说明即使在巨大的时间和空间尺度上，也可以发生很多事情。

文章最后讨论了宇宙中的“空无”对人类心理的影响，提到了人类大脑不善于处理“空无”的概念。作者用幽默的语言描述了进化如何没有时间为人类提供处理广阔无垠空间的能力，因为进化更忙于处理其他生存问题。文章强调，尽管我们无法完全理解这些巨大的空间，但数学模型和科学知识帮助我们构建了对宇宙的理解。

总的来说，这篇文章通过一种旅行的视角，让读者感受到了宇宙的广阔和空旷，同时也探讨了人类对宇宙的感知和理解的局限性。通过幽默和比喻，文章让读者对宇宙的浩瀚有了更深的认识，同时也反思了人类在宇宙中的位置和意义。

HN 热度 657 points | 评论 212 comments | 作者：sdoering | 16 hours ago #

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

在宇宙尺度上，光速显得非常慢，人类可能永远无法到达另一个星球。
人类对时间的感知可能与我们的新陈代谢速度和微小的体积有关，而植物和星星可能以不同的时间尺度存在。
从星星的视角来看，地球上的生态变化在它们漫长的寿命中只是一瞬间。
人类可能只是宇宙中的一个短暂存在，而硅基生命可能是我们的“启动序列”。
在这个模型中，光速显得慢是因为它没有考虑特殊相对论。
理论上，通过接近光速旅行，可以在极短的时间内到达宇宙的任何地方，尽管这可能会对旅行者的身体造成影响。
即使以 0.5 倍光速旅行，到达最近的恒星也需要数月的时间，而且还要考虑到减速的问题。
人类在宇宙中的渺小和光速的相对慢速使得探索宇宙变得困难。
接近光速旅行可以让旅行者在一生中穿越数千光年，但对留在地球上的人来说，这将是数千年的时间。
如果能够以 1G 的加速度持续加速，理论上可以在相对较短的时间内到达银河系中心甚至仙女座星系。
在宇宙中旅行时，可能不需要担心空气阻力，但需要考虑如何持续提供加速所需的能量。

Rendering Crispy Text on the GPU #

https://osor.io/text 这篇文章讨论了实时渲染文本的技术，特别是关注于在 GPU 上渲染清晰文本的方法。作者之前使用多通道符号距离场（SDFs）来渲染文本，虽然效果不错，但仍有一些不满意的地方，比如抗锯齿、大纹理、慢构建时间、缩放和平滑移动等问题。作者因为新购买了一台 OLED 显示器，这台显示器由于非标准的子像素结构存在边缘泛光问题，这促使作者重新研究字体渲染技术，特别是子像素抗锯齿。

文章首先展示了一些字体测试，包括不同风格如圆润、尖锐、非常细的线条等，并提供了一个高分辨率的测试链接，建议在新标签页中打开并使用 100% 的原生缩放查看。还有一个动态展示菜单，展示了文本在移动中的效果，以及控制台和之前展示的演示文本。

作者提到，展示图像和视频时可能会因为缩放、像素对齐和子像素结构等问题而出现伪影。使用 SDFs 的主要问题包括质量、图集大小、灵活性和简单性。某些字体，特别是具有细特征或许多细节的字体，渲染效果不佳。SDFs 需要一定分辨率才能获得良好的输出质量，尤其是对于包含大量字形的字体，这会导致图集大小增加。此外，SDFs 需要在运行时加载多个字体，这会增加内存成本和流式传输带宽。作者还提到，SDFs 在处理缩放和实现新想法（如子像素抗锯齿）时较为复杂，而且作者希望能够在运行时处理任何矢量图像。

文章提出了一个解决方案，即不将任何内容烘焙到纹理中，而是直接获取当前可见字形的曲线，将它们发送到 GPU 并进行光栅化。这种方法可以减少存储需求，因为不需要为图集中的每个字形单元分配空间，而且可以直接渲染矢量表示，从而在任何分辨率下都能保持良好的效果，并且与子像素抗锯齿等技术兼容。

解决方案包括直接加载字形曲线数据，实时光栅化到图集，并根据需要采样图集以渲染可见字形。作者强调，只要字形在后续帧中继续使用，就将其保留在图集中，这样可以积累和细化光栅化结果，甚至可以获得非常高的质量子像素抗锯齿效果。

文章概述了整个处理流程，从加载原始字体到最终显示在屏幕上。作者使用 FreeType 作为离线工具来加载字体格式，并遍历每个字形的曲线，将它们存储在资产格式中，然后传递给 GPU。字形可能包含线条、二次贝塞尔曲线或三次贝塞尔曲线，作者将所有这些转换为二次贝塞尔曲线，以简化着色器的复杂性。文章还讨论了如何将直线和三次贝塞尔曲线转换为二次贝塞尔曲线。

最后，文章讨论了计算覆盖率的过程，这与其他地方可能找到的方法没有太大区别。通过在每个像素上水平发射射线，测试与曲线的交点，并累积一个环绕数来确定是否被认为是外部（零）或内部（非零）。这个过程涉及到解决一个二次方程。作者推荐了两个资源来解释这一数学原理：GreenLightning 的 GitHub 仓库和 Sebastian Lague 的文本渲染视频，这些资源涵盖了字形光栅化的原理和他的解决方案改进过程。如果读者对源代码感兴趣，这些链接也能提供帮助。作者还提到，由于交点计算的不准确性，这一步可能会出现问题。

HN 热度 390 points | 评论 121 comments | 作者：ibobev | 22 hours ago #

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

作者对帖子在 Hacker News 上的讨论表示惊讶和感谢。
视频中斜体字母“j”上的点不见了。
子像素字体渲染对于可读性至关重要，但无法从现有显示标准中获得像素布局规格。
标准分辨率显示器上子像素渲染并非“关键”，而是“锦上添花”；Retina 显示器上几乎没有子像素渲染的必要。
子像素渲染带来了许多问题，比如截图与特定子像素布局绑定，无法缩放位图等。
有人反对子像素渲染，认为它只是 LCD 时代的一种临时创新。
即使在非 Retina 显示器上，也有人因为价格问题而没有升级到更高分辨率。
47 英寸 4K 显示器对于编程来说非常出色，但子像素渲染仍然有其价值。
有人十年前就购买了 4K 显示器，对 4K 电视的损失表示遗憾。
即使在标准分辨率显示器上，也有人看到子像素渲染导致的颜色边缘。
调整显示伽马值可以改善子像素抗锯齿效果。
苹果可以确保其生态系统中的屏幕具有特定的子像素对齐，但他们还是取消了这个功能。
高像素密度下，子像素 AA 产生的伪影是不必要的。
苹果不能保证所有外部显示器的像素密度都足够高。
有人质疑市面上使用的显示器中有多少是 Retina 类型的。
现代手机几乎都是 Retina 屏幕，但电脑仍然停留在 1080p 分辨率。
有人提出需要更好的截图图像格式，以保留矢量和文本而不是光栅化。

Meta invests $14.3B in Scale AI to kick-start superintelligence lab #

https://www.nytimes.com/2025/06/12/technology/meta-scale-ai.html

Meta（前身为 Facebook）宣布将对初创公司 Scale AI 投资 143 亿美元，这是其首次对外进行重大少数股权投资。这笔交易旨在增强 Meta 在人工智能（AI）领域的实力，以应对不断增长的竞争对手，包括谷歌、微软、OpenAI 和 Anthropic 等公司。

Scale AI 是一家专注于为人工智能系统提供数据训练的公司，在 AI 的发展中扮演了重要的幕后角色。根据交易条款，Scale AI 的首席执行官亚历山大・王（Alexandr Wang）将加入 Meta，并担任新成立的 “超级智能实验室” 的高管。王被 Meta 内部视为一位富有远见的领导者，他还将带领部分 Scale AI 的员工加入 Meta。

此次投资金额相当于 Meta 2024 年收入的约 10%，也是 Meta 继 2014 年以 190 亿美元收购 WhatsApp 后的第二大交易。Meta 希望通过这次战略合作，进一步加深与 Scale AI 的合作，以提升其在 AI 模型数据生产方面的能力。

Meta 发言人表示：“Meta 已完成与 Scale AI 的战略合作和投资。作为此合作的一部分，我们将加深在 AI 模型数据生产方面的合作，亚历山大・王将加入 Meta，参与我们的超级智能项目。” 此举显示出 Meta 对 AI 领域的重视以及其希望在这一变革性技术上赶超竞争对手的决心。

HN 热度 388 points | 评论 404 comments | 作者：RyanShook | 12 hours ago #

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

Meta 已经拥有两个 AI 实验室，它们之间存在竞争，并且都在失败的边缘。
Meta 在招聘超级巨星加入 GenAI 时遇到了困难，因为没有人愿意加入一个即将沉没的泰坦尼克号。
OpenAI 的上升潜力比 Meta 大，即使 Meta 提供大量的现金和股票补偿。
Meta 支付 7-8 位数的高薪，但问题在于大家都知道 Meta 是一个混乱的地方，只能吸引那些只关心薪酬的人。
OpenAI 的股权有一个超过 2 年的有效悬崖期，而 Meta 则支付的是现金。
Meta 需要一个像 Sam Altman 这样的人来领导，以推动结果。
Meta 和 Scale 都以高压和政治斗争文化著称，这限制了创新。
AI 技术的半衰期以月为单位，许多 AI 从业者的职业生涯可能很短。
Rob Fergus 是 FAIR 的创始人之一，领导 FAIR 是合理的。
Yann LeCun 在 Meta 的作用有限，他并不真正领导任何项目。
Scale 除了数据标注工具外，还构建了大量专有数据集，并将其授权给大型企业用于训练。
Meta 可能希望通过收购 Scale 来切断其他竞争对手使用 Scale 数据的途径。
OpenAI 和 Anthropic 依赖多个数据供应商，以确保没有外部公司了解他们如何训练自己的专有模型。
Scale 的数据并不是最好的，因此对 Meta 的吸引力有限。
其他公司可能会填补 Scale 留下的市场空白，因此 Meta 的收购可能没有实际效果。
Meta 可能希望通过这次收购实现更垂直的整合。

Cloudflare was down #

https://www.cloudflarestatus.com/incidents/25r9t0vz99rp

这个网页是关于 Cloudflare 在 2025 年 6 月 12 日发生的一次服务中断事件的报告。以下是该事件的详细中文摘要：

事件状态：该服务中断事件已被解决。Cloudflare 的所有服务已经恢复并全面运行。目前，团队正在监控平台指标以确认稳定性。
服务恢复情况：Cloudflare 的服务在全球范围内迅速恢复。WARP 和 Turnstile 服务已经运行，尽管仍有一小部分残余影响，团队正在努力消除。核心 KV 服务已经恢复，依赖于 KV 服务的产品正在重新上线。预计在未来几分钟内将进一步恢复，影响将逐步降低。
服务中断原因：Cloudflare 的关键 Workers KV 服务由于一个第三方服务的中断而离线，这个第三方服务是 KV 服务的一个关键依赖。因此，一些依赖于 KV 服务存储和传播信息的 Cloudflare 产品无法使用，包括 Access、WARP、Browser Isolation、Browser Rendering、Durable Objects（仅支持 SQLite 支持的 Durable Objects）、Workers KV、Realtime、Workers AI、Stream、部分 Cloudflare 仪表板、Turnstile、AI Gateway 和 AutoRAG。Cloudflare 的工程师正在尽快恢复服务，并意识到这次中断造成的严重影响，正在全力以赴地尽快恢复所有服务。
服务恢复进展：服务开始恢复，预计在受影响的服务中仍会出现间歇性错误，因为系统处理重试和填充缓存。
受影响的服务：包括 Access、WARP、Durable Objects（仅支持 SQLite 支持的 Durable Objects）、Workers KV、Realtime、Workers AI、Stream、部分 Cloudflare 仪表板和 AI Gateway、AutoRAG。
调查进展：Cloudflare 工程团队正在调查导致 Access 认证失败的问题。Cloudflare Zero Trust WARP 连接也受到影响。
订阅更新：用户可以通过电子邮件和/或短信订阅 Cloudflare 服务中断的更新。当服务中断事件更新时，用户将收到电子邮件通知，当 Cloudflare 创建或解决服务中断时，将收到短信通知。

这个摘要提供了 Cloudflare 服务中断事件的详细情况，包括事件状态、服务恢复情况、服务中断原因、服务恢复进展、受影响的服务以及订阅更新的相关信息。

HN 热度 333 points | 评论 86 comments | 作者：datadrivenangel | 1 day ago #

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

Cloudflare 的 Workers KV 服务因第三方服务故障而离线，该第三方服务是关键依赖。
有人猜测 Cloudflare 依赖 GCP（Google Cloud Platform）提供部分服务。
有观点认为这种依赖关系不会持续太久。
文章提到 Workers KV 正在转移到更弹性的基础设施，但在此事件中暴露了覆盖缺口。
有人猜测 Cloudflare 公司基础设施的 95% 可能依赖于这个服务。
有传言称这个“强制性依赖”是为了减轻“内部风险”。
有人询问 WAG（wild-assed guess，即无根据的猜测）的意思。
有人开玩笑说可能是用户在摇尾巴。
Cloudflare 的 CEO 表示这种依赖不会持续太久。
有人提供了 Cloudflare GDPR 子处理器页面的链接，以验证依赖关系。
有人提到 Google 否认有任何服务中断。
有人提供了 Google Cloud Status 页面的链接，显示有服务中断。
有人表示客户知道 Google 的说法并不真实。
有人提出可能是“100% 的服务中断影响 3% 的客户”的情况。
有人指出应该链接到 Google 的实际服务仪表板，而不是几个小时前的推文。
有人提到可能是为了避免 SLA/SLO（服务等级协议/服务等级目标）的支付。
有人提到 DownDetector 网站显示包括 Google、CloudFlare、AWS 在内的许多大公司都出现了服务中断，可能是由于大型 BGP 路由问题。
有人提到他们没有亲身经历任何服务中断，他们位于欧洲。
有人提供了一个 BGP 劫持的技术帖子链接。
有人提出这是否与以色列的紧张局势升级有关。
有人提到五角大楼披萨报告在过去 24 小时内有很多活动，可能是巧合。
有人提到 Internet Health Report 显示“没有数据可显示”。
有人提到 Anthropic 也出现了下降/降级。
有人提到 GCP 也出现了服务中断。
有人开玩笑说当服务中断规模化时。
有人好奇 Cloudflare 是否使用 GCP。
有人表示 Cloudflare 的认证基础设施可能受到了 Google 服务中断的影响。
有人确认 Cloudflare 的 KV 存储肯定出现了服务中断。
有人提到 Google 声称服务中断的根源是他们的中央 IAM（身份和访问管理）服务，这将对其他服务产生连锁反应。
有人询问这些信息是从哪里看到的，是否是在社交媒体上。
有人提供了 Google Cloud Status 页面的链接，显示多个 GCP 产品因 IAM 服务问题受到影响。
有人指出这个评论部分在他们回复时并没有出现。
有人表示他们的整个 GCP 基础设施运行正常，只是无法管理任何东西。
有人指出如果他们列出的许多服务真的出现了广泛的服务中断，情况会糟糕得多。
有人提醒说，不能因为服务对某人工作就推断对所有人都工作，Google 不会无缘无故地将服务列为中断。

OxCaml - a set of extensions to the OCaml programming language. #

https://oxcaml.org/

OxCaml 是 OCaml 编程语言的一组快速发展的扩展，它是 Jane Street 的生产编译器，同时也是一个实验性实验室，专注于使 OCaml 更适合性能导向的编程。OxCaml 的目标是希望这些扩展最终能够贡献给上游的 OCaml。

OxCaml 的主要设计目标是提供安全、方便、可预测的控制，以优化程序行为中的关键性能方面，但只在需要的地方提供，并且这一切都在 OCaml 中实现。这意味着 OxCaml 的扩展旨在使 OCaml 成为性能工程的优秀语言。性能工程需要控制，OxCaml 希望这种控制是安全的、方便的、可预测的。安全是提高程序员生产力和发布正确代码的关键特性。OxCaml 旨在在增加类型系统的表现力的同时，保持 OCaml 出色的类型推断能力。OxCaml 希望其扩展能够维持并改进 OCaml 的一个特性，即通过在类型级别明确关键性能细节，使代码的性能表现易于理解。

OxCaml 的扩展应该是按需付费的，即在不使用额外优化能力时，用户不需要承担额外的复杂性。所有有效的 OCaml 程序也是有效的 OxCaml 程序，但更深层次的目标是让 OxCaml 感觉像是 OCaml 进化成更好的版本，而不是一种新语言。为此，OxCaml 需要尊重 OCaml 的基本设计原则，并保持 OCaml 的安全性、易用性和生产力。

OxCaml 的扩展可以分为几个领域：

无畏并发：编写正确的并发程序非常困难。OxCaml 包括类型系统的扩展，以静态方式排除数据竞争。
布局：OxCaml 允许程序员指定数据在内存中的布局，并提供对 SIMD 处理器扩展的原生访问。
控制分配：OxCaml 提供工具以控制分配，减少 GC 压力，使程序更缓存高效和确定性。
生活质量：OxCaml 还包含一些不专门针对系统编程的扩展，但在日常工作中发现它们很有帮助，如多态参数、包含函子、标记元组和不可变数组。

使用 OxCaml： OxCaml 是开源的，欢迎实验性用户，特别是研究人员和修补者，他们可以试用系统并提供反馈。OxCaml 强调实验性，因为它对其扩展不承诺稳定性或向后兼容性（尽管它确实与 OCaml 保持向后兼容）。OxCaml 旨在易于使用，并为此提供了修改后的标准 OCaml 工具集，包括与 dune 和 opam 兼容的包管理、通过 LSP-server 的编辑器集成、源代码格式化和文档生成。

Jane Street 长期以来开源了许多有用的库和工具。这些现在以两种形式发布：一种是上游 OCaml，其中我们的扩展已被剥离；另一种是 OxCaml，其中扩展被充分利用。并非所有扩展都可以擦除，因此一些库将仅适用于 OxCaml。当必要的扩展被集成到上游时，我们将导出这些库的 OCaml 兼容版本。

最后，Jane Street 正在寻找聪明、善良的人，他们对发现未知和解决难题充满热情。网站还提供了查看开放职位的链接。

HN 热度 253 points | 评论 73 comments | 作者：lairv | 11 hours ago #

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

OxCaml 是 OCaml 编程语言的一套扩展。
Janet Street 团队不仅创建了 OxCaml，还讨论了在使用 OCaml 时的性能考虑，特别是在需要极低延迟的应用场景中。
在高频交易中，垃圾回收（GC）暂停可能会成为问题。
交易系统通常在启动后不进行内存分配，以避免 GC 暂停。
JavaScript 有一个名为 “Zero” 的库，提供了一系列不进行内存分配的方法。
有人误以为 “JS” 指的是 JavaScript，实际上指的是 Jane Street。
在交易场景中，可以在市场开盘和收盘时禁用 GC，并在收盘后重启程序。
这是一种在银行系统中常见的设计模式，适用于只在市场交易时间内运行的系统。
有观点认为，通过增加足够的 RAM，可以使得在长时间（如 6 小时以上）内不进行 GC 变得可行。
有人认为 C++ 在金融领域比任何 GC 语言（通常是 Java，因为 OCaml 更少见）更常见。
有人提到了 JVM 项目 OpenHFT，该项目在实际生产中使用，并提供了一个外部视角来观察高频交易基础设施。
Dart 语言将元组和记录合并为单一结构，可以在类型注解中使用记录类型。

A dark adtech empire fed by fake CAPTCHAs #

https://krebsonsecurity.com/2025/06/inside-a-dark-adtech-empire-fed-by-fake-captchas/

这篇文章揭露了一个由克里姆林宫支持的虚假广告技术帝国，这个帝国通过利用恶意广告技术绕过社交媒体平台的内容审核，传播虚假信息。文章详细描述了这个黑暗广告技术行业的复杂性和相互关联性。

文章首先提到，2024 年 11 月，安全公司 Qurium 的研究人员揭露了一个名为“Doppelganger”的虚假信息网络，该网络通过克隆网站传播假新闻，推广亲俄叙事，并渗透欧洲媒体。Doppelganger 利用复杂的“域名隐藏”服务，使得网站能够向搜索引擎展示与普通访客不同的内容，从而延长虚假信息网站的在线时间，并确保只有目标受众能看到预定内容。

Qurium 发现，Doppelganger 的域名隐藏服务还推广了在线约会网站，并与被认为是现存最古老的恶意流量分发系统（TDS）VexTrio 共享了大量基础设施。VexTrio 主要管理来自网络钓鱼、恶意软件和社会工程诈骗受害者的网络流量。

进一步调查发现，Doppelganger 的域名隐藏服务使用瑞士的互联网服务提供商作为域名重定向链的第一个入口点，并且同一基础设施还托管了两个联合品牌的联盟营销服务，这些服务将流量导向可疑的成人约会网站：LosPollos.com 和 TacoLoco.co。

LosPollos 广告网络融入了热门剧集《绝命毒师》的许多元素和参考，模仿剧中作为暴力冰毒贩子洗钱操作的虚构“Los Pollos Hermanos”餐厅连锁。加入 LosPollos 的联盟成员会获得 JavaScript 重的“智能链接”，这些链接将流量导向 VexTrio TDS，然后分配给包括约会服务、抽奖优惠、诱骗移动应用、金融诈骗和恶意软件下载网站在内的各种广告合作伙伴。

LosPollos 联盟成员通常会将这些智能链接嵌入通过已知漏洞被黑客攻击的 WordPress 网站中，每当有互联网用户通过他们的被黑网站之一落入这些诱饵时，联盟成员就会获得一小笔佣金。

文章还提到，TacoLoco 是一个流量变现网络，使用欺骗手段诱使互联网用户启用“推送通知”，这是一种允许网站在浏览器外部显示弹出消息的跨平台浏览器标准。VexTrio 和 TacoLoco 的推送通知批准请求本身就是欺骗性的——伪装成用于区分自动机器人流量和真实访客的“CAPTCHA”挑战。多年来，VexTrio 及其合作伙伴成功地诱骗了无数用户启用这些站点通知，然后这些通知被用来不断向受害者的设备发送各种虚假病毒警报和误导性弹出消息。

GoDaddy 的 2024 年年度报告显示，2024 年近 40% 的被入侵网站通过 LosPollos 智能链接重定向到 VexTrio。

文章还提到了 Adspro Group，这是一家在捷克共和国和俄罗斯注册的公司，运营 LosPollos 和 TacoLoco 服务，并在瑞士托管提供商 C41 和 Teknology SA 运行其基础设施。LosPollos 和 TacoLoco 网站声明其内容由瑞士公司 ByteCore AG 和 SkyForge Digital AG 版权所有，这两家公司由 Teknology SA 的所有者 Giulio Vitorrio Leonardo Cerutti 运营。进一步调查发现，LosPollos 和 TacoLoco 是由 Holacode 开发的应用程序，该公司将 Cerutti 列为其 CEO。

Holacode 市场推广的应用程序包括许多 VPN 服务，以及一个名为 Spamshield 的应用程序，声称可以阻止不需要的推送通知。但 Infoblox 在 1 月份表示，他们在自己的移动设备上测试了该应用程序，发现它隐藏了用户的通知，然后在 24 小时后停止隐藏它们并要求付款。Spamshield 随后将其开发者名称从 Holacode 更改为 ApLabz，尽管 Infoblox 指出，几个重新品牌的 ApLabz 应用程序的服务条款仍然在其服务条款中引用了 Holacode。

Cerutti 在文章发表前就威胁要起诉作者诽谤，尽管作者甚至还没有提到他的名字或向他发出评论请求。当被要求对 Qurium 和 Infoblox 的调查结果发表评论时，Cerutti 强烈否认与 VexTrio 有任何关联。Cerutti 坚称，他的公司严格遵守其运营所在国家的规定，并且他们对所有运营都完全透明。

与 Qurium 合作的安全公司 Infoblox 研究人员向其行业合作伙伴发布了有关 VexTrio 基础设施的详细信息。Qurium 发布其调查结果的四天后，LosPollos 宣布暂停其推送变现服务。不到一个月后，Adspro 更名为 Aimed Global。

文章最后提到，2025 年 3 月，GoDaddy 的研究人员记录了 DollyWay——一种恶意软件，在其八年的活动中一直将受害者重定向到 VexTrio——突然在 2024 年 11 月 20 日停止这样做。几乎一夜之间，DollyWay 和其他几个以前使用 VexTrio 的恶意软件家族开始将他们的流量通过另一个名为 Help TDS 的 TDS 推送。研究人员进一步调查了历史 DNS 记录和 t…（此处原文未提供完整信息）

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

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

浏览器推送通知功能被滥用，尤其是欺骗用户启用通知的网络流量变现网络。
推送通知功能从一开始就有毒，尤其是弹出式的“是否启用通知”。
推送通知功能对于基于网页的电子邮件和聊天应用有用，其他用途则更多是解决网站方的问题。
YouTube 使用推送通知功能让用户及时获得视频更新，对用户和平台都是双赢。
推送通知功能可能会导致用户错过内容，但用户可以选择不立即点击通知。
推送通知功能可能会导致用户感到压力，因为它们创造了“立即参与否则会错过”的氛围。
推送通知功能是渐进式网络应用（PWA）的一部分，用于逃避苹果和谷歌商店的硬件锁定。
浏览器应允许用户阻止剪贴板 API，以防止复制粘贴被滥用。
在 Firefox 中可以通过 about:config 禁用某些功能，如 dom.disable_beforeunload 和 dom.event.clipboardevents.enabled。
某些网络协作工具可能使用 beforeunload 事件来确保数据与服务器同步。
beforeunload 事件在某些情况下有其合理用途，如在远程访问工具中警告用户即将关闭标签页。

Show HN: I wrote a BitTorrent Client from scratch #

https://github.com/piyushgupta53/go-torrent-client

这个网页是关于一个名为“go-torrent-client”的 GitHub 项目页面的摘要。以下是网页主体内容的详细中文摘要：

项目名称：go-torrent-client 项目描述：这是一个用 Go 语言实现的 BitTorrent 客户端，支持使用 BitTorrent 协议下载文件。该项目实现了 BitTorrent 客户端的核心功能，包括种子文件解析、对等体发现和文件下载。

特点：

Bencode 编码/解码：支持所有 Bencode 类型（字符串、整数、列表、字典），并具有健壮的错误处理和验证。
种子文件处理：解析.torrent 文件（包括单文件和多文件种子），计算信息哈希，提取块哈希，并支持所有标准种子文件字段。
对等体发现和通信：支持 HTTP 跟踪器，对等体握手协议和完整的 BitTorrent 消息协议，以及对等体连接管理。
下载功能：块和块管理，支持并发下载，进度跟踪，以及单文件和多文件种子的文件组装，具有块级粒度的存储管理。

项目结构：

cmd/：命令行界面和主应用程序。
internal/：内部包，包括 bencode 编码/解码、种子文件处理、跟踪器协议实现、对等体通信和下载管理。
pkg/：公共包。

要求：需要 Go 1.21 或更高版本。

安装：

使用 git 克隆项目：git clone https://github.com/yourusername/go-torrent.git
进入项目目录：cd go-torrent
下载依赖：go mod download

使用说明：随着项目的发展，使用说明将被添加。

开发状态：该项目正在积极开发中。当前实现状态可以在 checkpoint.md 文件中找到。

计划功能：包括磁力链接支持、元数据交换协议和 DHT（分布式哈希表）支持。

致谢：提供了 BitTorrent 协议规范和 Bencode 规范的链接。

关于：这是一个用 Go 语言实现的 BitTorrent 客户端。

资源：提供了 README 文件和 MIT 许可证信息。

活动：该项目获得了 218 个星标，2 个关注者和 8 个分支。

以上摘要涵盖了网页上的主要信息，包括项目介绍、特点、项目结构、安装和使用说明、开发状态、计划功能和致谢等部分。

HN 热度 185 points | 评论 44 comments | 作者：piyushgupta53 | 20 hours ago #

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

赞扬开发者从零开始编写 BitTorrent 客户端的工作，并认为这是一个挑战自我的好方法
建议开发者限制 bencode 解码器中的动态分配大小，以防止恶意输入导致 DoS 攻击
推荐使用 Kaitai Struct 编写 bencode 解码器，以避免一些常见问题
建议在 README 中添加简单的使用说明，以便用户知道如何下载.torrent 文件
建议添加对 magnet 链接的支持，并认为这是一个计划中的功能
询问为何使用较旧的 Go 版本 1.21，是否有特别的原因
提到 Windows 7 支持可能是使用旧 Go 版本的原因之一
认为支持更多平台是好事，即使是旧的 Windows 版本
回忆在大学时也做过类似的项目，认为这类项目是学习新语言的好方法
询问是否支持 magnet 链接，得知这是一个计划中的功能
询问添加 GUI 的难度，并提到过去没有看到很多 Go 的 GUI 实现
提供了一些 Go GUI 项目的资源链接，并分享了个人对不同 GUI 库的看法
询问项目的完整性，是否处理了 DHT、Magnet 和 NAT 穿越等复杂问题
认为 magnet 链接相对简单，但 DHT 是一个复杂的领域，且不是所有客户端都支持 DHT
询问是否支持 v2 和可变种子（mutable torrents）
指出项目中缺少崩溃恢复、加密对等握手或基本的 uTP 支持，以及 NAT 处理和内存保护等问题，认为这些是生产环境中的必要条件
询问是否可以将该项目用作库，并希望它能模块化
有人怀疑评论看起来像是机器生成的，并对帖子的真实性表示怀疑