1天前
|
|
|
## 今天 Hacker News 社区聊了啥？ NO.20250821
这期日报干货满满！AI 领域迎来大震荡：Meta 暂停 AI 招聘，是泡沫要破的信号？小心！新型 AI 攻击正在威胁生产环境，图像缩放也能搞事情！ 还有还有，带你探索 Common Lisp 的 Web 之旅，揭秘奇特的 d4d4 指令，重温经典 OS X Mavericks 的魅力。 别忘了，还有数据库查询优化、历史字体探索、以及如何识别16瓶年份不同的葡萄酒的有趣谜题等你来挑战！ 赶紧点开全文，一网打尽本周科技热点！
---
## 洗钱控制系统效果如何？
这篇文章探讨了反洗钱（AML）体系的有效性，以及它在打击犯罪和维护金融系统稳定方面的作用。文章指出，尽管各国政府和国际组织投入大量资源，但对于AML体系的实际效果，以及它所带来的成本，仍然缺乏充分的评估和讨论。
文章首先介绍了AML体系的背景，指出它是公私合作进行安全治理的重要例子。该体系要求私营机构承担起公共安全的角色，在发现和调查洗钱行为的早期阶段发挥作用。然而，文章也提到，这种模式面临着挑战，因为私营机构需要在追求利润和履行公共职责之间找到平衡。
文章接着分析了AML体系的目标，认为官方宣称的目标与洗钱监管的理论之间存在张力。文章提出，监管应该侧重于减少犯罪，而不是仅仅维护金融系统的完整性。文章还评估了FATF框架下的互评估报告，发现这些报告提供了大量信息，但缺乏真正的评估。
文章进一步利用其他数据，对AML体系的有效性进行了评估，并分析了系统性失败的原因。文章认为，AML体系的主要价值在于帮助执法机构打击其他犯罪，例如毒品走私和腐败，通过加强调查机构的情报基础。文章还探讨了AML体系的风险，包括“去风险化”和金融数据滥用。
文章最后强调，政府和其他利益相关者很少提及AML体系的成本，例如，某些客户群体可能因为被归类为高风险而被剥夺银行服务。文章认为，这些成本非常可观，应该纳入对系统设计的讨论中。文章总结了七个关键发现，包括银行因违反AML规定而支付巨额罚款，但银行高管很少面临刑事定罪；洗钱的难度和成本与FATF成立之初相比没有显著变化；大多数洗钱计划都非常简单；AML框架不成比例地使富裕国家受益；AML措施为执法调查提供了有价值的情报；AML措施存在风险；以及AML框架的成本很少被提及。总的来说，文章对AML体系的有效性提出了质疑，并呼吁对其成本和收益进行更全面的评估。
- 原文: [How Well Does the Money Laundering Control System Work?](https://www.journals.uchicago.edu/doi/10.1086/735665)
- Hacker News: [https://news.ycombinator.com/item?id=44972213](https://news.ycombinator.com/item?id=44972213)
- 作者: PaulHoule
- 评分: 65
- 评论数: 34
- 发布时间: 2025-08-21 20:58:17
---
## 针对生产环境 AI 系统的图像缩放攻击
本文深入探讨了一种新型攻击方式，即利用图像缩放漏洞来攻击生产环境中的 AI 系统，通过构造特殊图像，在缩放后植入恶意指令，从而实现数据泄露等目的。这种攻击手段隐蔽性强，对多种 AI 系统构成威胁。
文章指出，攻击者可以精心制作图像，这些图像在原始分辨率下看起来无害，但经过 AI 系统常用的缩放处理后，会暴露出隐藏的 prompt 注入代码。这种注入能够欺骗 AI 模型执行恶意操作，例如未经授权地访问和泄露用户数据。文章着重介绍了在 Google Gemini CLI 上的攻击实例，攻击者上传一张表面正常的图片，经过缩放后，图片中隐藏的恶意指令被触发，导致存储在 Google 日历中的用户数据被泄露到攻击者的邮箱。
此外，文章还展示了在 Vertex AI、Gemini 的 Web 界面和 API、Google Assistant 以及 Genspark 等多个平台上的成功攻击案例，进一步证实了该攻击方式的广泛适用性。文章还深入分析了图像缩放算法的细节，包括最近邻插值、双线性插值和双三次插值等，指出不同的算法实现对攻击方式有不同的要求，因此攻击者需要对目标系统的算法进行指纹识别，才能选择合适的攻击策略。
文章还提到了奈奎斯特-香农采样定理，解释了图像缩放攻击背后的原理。简而言之，如果采样率低于某个阈值，就无法准确重构原始图像，从而导致混叠效应。攻击者正是利用这种混叠效应，通过操纵特定像素，使得目标模式在缩放后的图像中显现出来。
- 原文: [Weaponizing image scaling against production AI systems](https://blog.trailofbits.com/2025/08/21/weaponizing-image-scaling-against-production-ai-systems/)
- Hacker News: [https://news.ycombinator.com/item?id=44971845](https://news.ycombinator.com/item?id=44971845)
- 作者: tatersolid
- 评分: 100
- 评论数: 14
- 发布时间: 2025-08-21 20:20:53
---
## 使用 Podman、Compose 和 BuildKit 的实践指南
本文深入探讨了如何在 Podman 环境中使用 Docker Compose 和 BuildKit，旨在解决 Docker 与 nftables 兼容性问题，并提供一种无需 root 权限和守护进程的方法来管理容器。文章详细介绍了使用官方 Docker Compose CLI 和 Podman 替代方案的优缺点，以及如何配置 Docker Compose CLI 以在启用 BuildKit 的情况下在 Podman 下运行。
文章的核心在于如何让 Docker Compose CLI 在 Podman 环境中运行并启用 BuildKit。作者首先指出了使用 Podman 支持 Docker Compose 项目的两种方式的不足：官方 Docker Compose CLI 无法使用 BuildKit 的新特性，而 podman-compose 替代方案则缺少某些功能。为了解决这个问题，作者探索了如何配置 Docker Compose CLI 以在 Podman 下运行，并启用 BuildKit。通过启用 Podman socket 并创建一个新的 Docker context，可以直接使用 Docker Compose CLI。此外，文章还介绍了如何使用 systemd 管理 BuildKit 服务，以及如何使用 Bake 将 Compose 项目转换为 JSON 描述，并使用 Bakah 工具利用 Buildah 构建镜像，从而避免运行 BuildKit 守护进程。Bakah 工具简化了构建过程，并允许更灵活地拆分 Dockerfiles。
评论区对 Podman 的使用提出了不同的看法。一些用户表示，尽管他们曾经是 Podman 的忠实粉丝，但最终还是选择了 Docker Compose，因为与系统作斗争并不值得。另一些用户则推荐使用 Quadlets 或 podman kube 支持来替代 Docker Compose，以便更好地与 systemd 集成。还有用户分享了使用 OrbStack 替代 Docker 的经验，认为它在基本的 Web 开发设置中表现完美。此外，有评论指出，Docker 技术的复杂性导致学习曲线陡峭，尤其是在构建多架构镜像时。总的来说，评论区反映了用户在容器化技术选型上的多样化需求和偏好，以及对简化构建流程的期望。
- 原文: [Using Podman, Compose and BuildKit](https://emersion.fr/blog/2025/using-podman-compose-and-buildkit/)
- Hacker News: [https://news.ycombinator.com/item?id=44971212](https://news.ycombinator.com/item?id=44971212)
- 作者: LaSombra
- 评分: 137
- 评论数: 24
- 发布时间: 2025-08-21 18:54:13
---
## ChartDB Cloud：数据库图表可视化与分享工具
ChartDB Cloud 是一款数据库结构图可视化工具，旨在帮助开发者更轻松地理解和分享数据库设计。该工具通过简单的查询导入数据库 schema，并允许用户以直观的方式进行编辑和协作。
文章提到 ChartDB 的主要功能是可视化数据库 schema 图，并支持分享。虽然文章本身由于出现 "Unexpected Application Error!" 错误，没有展示 ChartDB 的具体功能和界面，但从评论中可以了解到一些信息。例如，用户可以直接导入 schema 并开始使用，而无需学习新的工具集。一位 Supabase 用户提到，Supabase 自带的 ERD 查看器在处理超过 15 个表时会崩溃，而 ChartDB 能够更好地处理大型数据库。此外，团队协作也是 ChartDB 的一个亮点，用户可以共同编辑数据库图表。有用户希望 ChartDB 能增加 "dev diagram 和 live DB 之间的差异" 功能，以便更好地跟踪数据库变更。
评论区主要围绕 ChartDB 的实用性、功能以及 AGPL 许可展开讨论。
* **实用性讨论：** 有用户质疑在领域驱动设计（DDD）、ORM 和 API 盛行的今天，数据库图表是否还有存在的必要。他们认为，团队更倾向于文档化实体而非表，并使用更高级的抽象来操作数据库。但也有用户表示，ChartDB 在处理大型数据库时非常有用，可以弥补现有工具的不足。
* **功能建议：** 有用户希望 ChartDB 增加数据库 schema 差异对比功能，方便团队协作和版本控制。
* **AGPL 许可问题：** 有用户对 ChartDB 的 AGPL 许可模式及其对 SaaS 产品的影响表示关注，特别是如何处理在引入 CLA 之前的大量外部贡献代码。他们好奇开发者是否需要重写代码，或者整个云产品是否也是开源的。
- 原文: [Show HN: ChartDB Cloud – Visualize and Share Database Diagrams](https://app.chartdb.io)
- Hacker News: [https://news.ycombinator.com/item?id=44972238](https://news.ycombinator.com/item?id=44972238)
- 作者: Jonathanfishner
- 评分: 33
- 评论数: 6
- 发布时间: 2025-08-21 21:01:11
---
## 为什么 LLVM 的链接器 LLD 会插入 `d4d4` 指令？
这篇文章探讨了在 ARM 代码中发现的奇怪 `d4d4` 指令，揭示了 LLVM 链接器 LLD 使用它来进行对象文件边界对齐。作者通过实验和代码分析，逐步揭示了 `d4d4` 指令的来源和目的。
文章首先展示了一个简单的 C 代码示例，编译后在反汇编代码中出现了意料之外的 `d4d4` 指令。作者最初猜测是用于对齐，但通过进一步的实验，发现 `d4d4` 指令的出现与函数数量和链接顺序有关。最终，作者确认 `d4d4` 指令是由 LLD 链接器插入的，目的是将对象文件对齐到 32 位边界。
为了验证这一结论，作者尝试使用 GNU 链接器 ld 进行链接，发现 GNU ld 使用零填充而不是 `d4d4` 指令进行对齐。
通过研究 LLVM 源代码，作者找到了 LLD 使用 `d4d4` 指令的原因：LLVM 使用 `0xd4` 作为 ARM 架构的 trap 指令，用于填充可执行 section 中的空洞。这个设计最初由 Theo de Raadt 提出。
文章还深入研究了 ARMv7-M 架构参考手册，解释了为什么反汇编器将 `d4d4` 指令识别为条件分支。`0xd4` 被解码为 Thumb 指令集中的条件分支指令，但实际上它应该被视为一个 trap 指令。
总而言之，`d4d4` 指令是 LLD 链接器为了在 ARM 架构上进行对象文件对齐而插入的 trap 指令，虽然反汇编器会将其错误地解释为条件分支，但其目的是为了保证代码的正确执行。
- 原文: [D4d4](https://www.nmichaels.org/musings/d4d4/d4d4/)
- Hacker News: [https://news.ycombinator.com/item?id=44932401](https://news.ycombinator.com/item?id=44932401)
- 作者: csense
- 评分: 329
- 评论数: 37
- 发布时间: 2025-08-17 23:42:32
---
## 怀旧技术：在 2025 年使用 OS X Mavericks
本文介绍了作者为何以及如何继续使用 2013 年发布的 OS X Mavericks 操作系统，并提供了在老旧 Mac 硬件或 Hackintosh 上安装和配置 Mavericks 的指南。文章适合对老旧技术有兴趣，或者对现代 macOS 系统不满意的用户。
作者提到，现代 macOS 的每次更新都在蚕食他喜欢的功能，因此他决定回归更早的版本。在比较了 Snow Leopard, Mountain Lion 和 Mavericks 之后，他选择了 Mavericks，因为它在速度、美观性和应用程序兼容性之间取得了最佳平衡。Mavericks 拥有内存压缩等功能，并且在视觉设计上更贴近经典的 Aqua 风格。此外，它还能兼容一些较新版本的应用程序，例如 Affinity Photo 和 VMWare Fusion。
文章详细介绍了如何获取 Mavericks 安装镜像，并提供了两种硬件方案：使用 2008 年 10 月至 2014 年 9 月之间发布的旧款 Mac，或者构建一台 Hackintosh。对于 Hackintosh，作者给出了 CPU、GPU 和存储等硬件选择建议，并分享了一个基于 Clover 引导加载程序的工具包。此外，文章还提到了使用 OpenCore 引导加载程序的替代方案，并链接到了 Dortania 的 OpenCore 安装指南。
最后，文章提供了一个 postinstall 脚本，用于将 Mavericks 更新到最新版本，并将一些默认设置更改为类似于 Snow Leopard 的风格。作者希望通过这份指南，帮助那些想要体验经典 macOS 魅力的用户。
- 原文: [Show HN: OS X Mavericks Forever](https://mavericksforever.com/)
- Hacker News: [https://news.ycombinator.com/item?id=44942099](https://news.ycombinator.com/item?id=44942099)
- 作者: Wowfunhappy
- 评分: 132
- 评论数: 37
- 发布时间: 2025-08-19 00:01:44
---
## 在浏览器中使用 Common Lisp：Web Embeddable Common Lisp (WECL)
本文介绍了 Web Embeddable Common Lisp (WECL) 项目，该项目旨在将 Common Lisp 带入 Web 浏览器环境，并详细说明了项目的当前进展、技术细节、以及未来的计划。
WECL 允许开发者在网页中嵌入 Common Lisp 代码，通过 `<script type="text/common-lisp">` 标签，可以直接在 HTML 中编写 Lisp 代码。WECL 包含一个 JavaScript 外层和 Common Lisp 内核，内核编译为 WebAssembly，使得浏览器能够执行 Lisp 代码。文章详细介绍了 JS-FFI，这是一个低级的外部函数接口，允许 Common Lisp 代码与 JavaScript 代码进行交互。通过 `define-js-variable`、`define-js-object`、`define-js-function` 等宏，可以方便地定义 JavaScript 变量、对象和函数，并在 Lisp 代码中使用它们。文章还介绍了 LIME/SLUG 适配器，它允许开发者在 Emacs 中与 WECL 进行交互，方便开发和调试。
总而言之，WECL 为 Web 开发提供了一种新的选择，允许开发者使用 Common Lisp 编写前端代码，并与现有的 JavaScript 代码进行集成。虽然 WECL 仍处于早期开发阶段，但它展示了 Common Lisp 在 Web 开发领域的潜力。
- 原文: [Show HN: Using Common Lisp from Inside the Browser](https://turtleware.eu/posts/Using-Common-Lisp-from-inside-the-Browser.html)
- Hacker News: [https://news.ycombinator.com/item?id=44971744](https://news.ycombinator.com/item?id=44971744)
- 作者: jackdaniel
- 评分: 36
- 评论数: 3
- 发布时间: 2025-08-21 20:08:30
---
## Meta 冻结 AI 招聘：泡沫担忧？
本文报道了 Meta (原 Facebook) 暂停人工智能领域招聘的消息，引发了关于 AI 领域是否存在泡沫的讨论。扎克伯格此举可能反映了对 AI 领域过度投资和人才争夺的担忧。
文章指出，尽管 AI 技术持续发展，但其商业价值和盈利能力仍存在不确定性。Meta 的这一举动可能预示着科技巨头们对 AI 投资策略的重新评估。此外，文章还暗示，AI 领域的快速发展可能已经导致人才市场过热，Meta 或许希望在市场降温后以更合理的成本招聘人才。 暂停招聘也可能与 Meta 自身的业务调整有关，公司可能正在重新评估其 AI 战略，并调整相关团队的规模和结构。 这一决策也可能受到宏观经济环境的影响，经济下行压力可能促使 Meta 更加谨慎地控制成本。
由于文章没有评论区，所以无法分析评论区的观点。
- 原文: [Mark Zuckerberg freezes AI hiring amid bubble fears](https://www.telegraph.co.uk/business/2025/08/21/zuckerberg-freezes-ai-hiring-amid-bubble-fears/)
- Hacker News: [https://news.ycombinator.com/item?id=44971273](https://news.ycombinator.com/item?id=44971273)
- 作者: pera
- 评分: 299
- 评论数: 281
- 发布时间: 2025-08-21 19:04:08
---
## 使用调试视图优化数据库查询
本文作者分享了一个技巧，通过创建数据库调试视图来简化和加速日常问题排查。核心思想是预先定义包含多个表连接的视图，避免重复编写复杂的 SQL 查询，提高开发效率。
文章首先通过一个实际的 bug 报告场景，展示了在没有调试视图的情况下，需要编写复杂的 JOIN 查询才能找到所需信息。作者指出，这种重复性的工作既耗时又容易出错，尤其是在 CLI 环境下编辑查询语句非常不便。为了解决这个问题，作者建议为每个表创建调试视图，将常用的 JOIN 操作封装在视图中。
作者提供了一个 `debug_contributions` 视图的示例，该视图包含了 contributions 表以及相关的 projects、users 和 branches 表的连接。通过这个视图，可以更方便地查询贡献信息，例如：`SELECT * from debug_contributions WHERE author.username = 'sophie' AND project_shorthand = '@unison/cloud' ORDER BY source_branch_updated_at DESC;`。
虽然直接查询计算列 `project_shorthand` 可能会影响性能，但作者认为对于一次性的调试查询来说，这不是主要问题。作者强调，调试视图易于创建、更新和删除，并且不占用额外的数据库空间。总而言之，创建调试视图可以显著提高开发效率，节省时间。
评论区对这个技巧进行了更深入的探讨。
* **@jerf** 建议将查询逻辑封装成数据库函数，利用字符串函数解析 shorthand，从而实现高性能查询。
* **@ndriscoll** 认为可以将调试视图应用于实际应用中，简化逻辑并提高性能，甚至可以利用视图生成 XML 或 JSON 数据，实现服务端渲染。
* **@Ozzie_osman** 建议将查询写成代码中的函数，方便共享和修改。
* **@vincekerrazzi** 分享了自己的经验，表示虽然创建了调试视图，但只有自己使用。
评论区从不同角度探讨了调试视图的应用场景和替代方案，为读者提供了更全面的视角。
- 原文: [You Should Add Debug Views to Your DB](https://chrispenner.ca/posts/views-for-debugging)
- Hacker News: [https://news.ycombinator.com/item?id=44934476](https://news.ycombinator.com/item?id=44934476)
- 作者: ezekg
- 评分: 10
- 评论数: 5
- 发布时间: 2025-08-18 04:04:00
---
## 探索历史字体：Sütterlin
本文介绍了 Sütterlin 字体，一种在德国历史上使用过的手写字体。它由平面设计师 Ludwig Sütterlin 于 1911 年设计，旨在为学校提供一种现代的、易于学习的德语手写体。
Sütterlin 字体具有独特的倾斜和尖锐的笔画，与之前的哥特体手写体有所不同。它在 20 世纪上半叶的德国被广泛使用，尤其是在学校和政府部门。二战后，随着教育改革和打字机的普及，Sütterlin 字体逐渐被淘汰，取而代之的是更现代的字体。
尽管如此，Sütterlin 字体在德国文化中仍然占有一席之地。许多人仍然能够阅读和书写这种字体，并且它经常出现在历史文件、老照片和艺术作品中。对于研究德国历史和文化的人来说，了解 Sütterlin 字体是很有帮助的。
文章还提供了 Sütterlin 字母表的概述，展示了每个字母的独特形状。这对于那些有兴趣学习阅读或书写 Sütterlin 字体的人来说是一个有用的资源。此外，文章还包含指向其他资源的链接，例如在线字体转换器和教程。
总的来说，这篇文章是对 Sütterlin 字体的一个很好的介绍，涵盖了它的历史、特点和文化意义。它对于任何对字体、历史或德国文化感兴趣的人来说都是值得一读的。
- 原文: [Sütterlin](https://en.wikipedia.org/wiki/S%C3%BCtterlin)
- Hacker News: [https://news.ycombinator.com/item?id=44940649](https://news.ycombinator.com/item?id=44940649)
- 作者: anonu
- 评分: 38
- 评论数: 29
- 发布时间: 2025-08-18 21:56:44
---
## Activeloop 招聘后端工程师
Activeloop 正在招聘后端技术人员，这是一个加入 YC S18 创业公司的机会。虽然提供的文本内容非常有限，但我们可以推断出以下几点：
Activeloop 是一家公司，并且正在积极招聘。他们特别提到了后端工程方向的职位，这意味着他们需要开发和维护服务器端逻辑、数据库以及 API 等关键组件。作为一家 YC S18 的公司，Activeloop 应该是一家成立时间不长，但具有一定发展潜力的创业公司。
对后端工程师来说，这可能是一个不错的机会，可以参与到公司的早期发展中，并承担重要的技术职责。具体的工作内容、所需技能以及公司文化等信息，需要进一步参考 Activeloop 的招聘页面。
由于没有评论内容，这里就不做评论分析了。
- 原文: [Activeloop (YC S18) Is Hiring Member of Technical Staff – Back End Engineering](https://careers.activeloop.ai/)
- Hacker News: [https://news.ycombinator.com/item?id=44971670](https://news.ycombinator.com/item?id=44971670)
- 作者: davidbuniat
- 评分: 1
- 评论数: 0
- 发布时间: 2025-08-21 20:00:31
---
## 股市风险信号：美国融资融券债务激增至历史新高
本文主要探讨了美国融资融券债务在2025年6月大幅飙升至历史新高的情况，并分析了这一现象可能预示的市场风险。融资融券余额的快速增长通常被视为市场投机情绪高涨的信号，可能暗示市场即将面临回调或调整的风险。
文章指出，融资融券债务的激增可能与投资者过度乐观和冒险行为有关。当投资者借入更多资金进行投资时，他们的潜在回报和风险都会增加。如果市场走势不利，这些投资者可能会被迫平仓，从而加剧市场下跌。此外，文章还对比了当前融资融券债务水平与历史数据，强调了当前水平的异常之高。作者还提到，虽然融资融券债务本身并不一定导致市场崩盘，但它可以作为衡量市场风险偏好的一个指标，值得投资者密切关注。总而言之，融资融券债务的激增提醒投资者保持谨慎，并对市场风险进行充分评估。
- 原文: [Margin debt surges to record high](https://www.advisorperspectives.com/dshort/updates/2025/07/23/margin-debt-surges-record-high-june-2025)
- Hacker News: [https://news.ycombinator.com/item?id=44971396](https://news.ycombinator.com/item?id=44971396)
- 作者: pera
- 评分: 100
- 评论数: 125
- 发布时间: 2025-08-21 19:22:50
---
## Google 公布 Gemini AI 提示的能耗数据
Google 首次公开了其 Gemini 应用处理每个查询所消耗的能源数据，这项举措旨在提高 AI 领域的透明度，并让用户了解他们与 AI 交互的能源成本。
文章指出，Gemini 的中位数提示消耗 0.24 瓦时电力，相当于使用标准微波炉约一秒钟。该报告还包括了与 Gemini 文本提示相关的用水量和碳排放量的平均估算值。Google 首席科学家 Jeff Dean 强调，该测量涵盖了能源需求的各个方面，包括 AI 芯片的功耗以及支持硬件所需的基础设施。其中，AI 芯片（Google 的 TPU）占总电力需求的 58%，主机 CPU 和内存占 25%，备用设备占 10%，数据中心运营开销（包括冷却和电源转换）占 8%。报告还显示，Gemini 查询的总能耗随着时间的推移显著下降，2025 年 5 月的中位数提示比 2024 年 5 月减少了 33 倍的能源消耗。此外，Google 估算中位数提示相关的温室气体排放量为 0.03 克二氧化碳，用水量为 0.26 毫升。
密歇根大学教授 Mosharaf Chowdhury 认为，这类报告显示了行业对能源和 AI 研究的投入价值。Hugging Face 的 AI 和气候研究员 Sasha Luccioni 对 Google 发布这些数据表示欢迎，但也指出，目前仍然缺少一些细节，例如 Gemini 每天处理的查询总数。她还呼吁建立一个标准化的 AI 能源评分系统，类似于电器的能源之星评级。
评论区有用户指出，与人类大约 100W 的功耗相比，AI 提示的 0.24 瓦时能量相当于 40 个人类秒的能量消耗。该用户还补充说，LLM 本应链接到原始研究报告。
- 原文: [In a first, Google has released data on how much energy an AI prompt uses](https://www.technologyreview.com/2025/08/21/1122288/google-gemini-ai-energy/)
- Hacker News: [https://news.ycombinator.com/item?id=44972808](https://news.ycombinator.com/item?id=44972808)
- 作者: jeffbee
- 评分: 29
- 评论数: 18
- 发布时间: 2025-08-21 21:52:50
---
## 存储统一的概念模型
本文探讨了存储统一的概念模型，旨在将异构存储系统和格式虚拟化为一个连贯的资源，从而实现实时数据和历史数据的统一抽象。
文章的核心在于数据虚拟化，它通过抽象层将逻辑资源与物理实现分离。数据虚拟化包含前端抽象（将不同物理存储整合为统一逻辑模型）和后端工作（物理存储管理，如分层、物化和生命周期管理）。物理存储管理涉及数据组织/格式、数据分层、数据物化和数据生命周期。数据组织优化特定访问模式，数据分层将数据在不同存储层之间移动，数据物化将数据从主系统复制到辅助系统，数据生命周期管理则关注数据寿命和兼容性。文章还区分了内部分层和共享分层，前者仅主数据系统可访问，后者则在多个系统间共享。
共享分层是内部分层和物化的混合体，既能以较低成本存储历史数据，又能使辅助系统以其数据格式访问数据。然而，共享分层也带来了一些挑战，例如生命周期管理和模式管理。在生命周期管理方面，写入辅助系统的数据仍然与主系统相关联，因此数据管理应保留在主系统。在模式管理方面，主格式（如 Avro 或 Protobuf）的模式演变可能与辅助格式不匹配。因此，在设计数据虚拟化方案时，需要仔细考虑这些因素，以确保数据的一致性和可用性。
- 原文: [A Conceptual Model for Storage Unification](https://jack-vanlightly.com/blog/2025/8/21/a-conceptual-model-for-storage-unification)
- Hacker News: [https://news.ycombinator.com/item?id=44972406](https://news.ycombinator.com/item?id=44972406)
- 作者: avinassh
- 评分: 8
- 评论数: 0
- 发布时间: 2025-08-21 21:18:12
---
## 为什么 D3.js 代码如此冗长？
本文探讨了 D3.js 库代码冗长的原因，指出其冗长性是为了提供更大的灵活性和定制性，以便开发者能够创建独特的、艺术性的数据可视化作品。
文章作者在学习 D3.js 的过程中，通过绘制箱形图的例子，展示了使用 D3.js 需要编写大量代码才能实现简单的图表。作者认为，D3.js 的核心在于允许开发者绘制 SVG 图形，并将这些图形与数据绑定。通过将数据绑定到 SVG 属性，开发者可以根据数据动态地调整图形的各个方面，实现高度定制化的可视化效果。虽然 D3.js 看起来很冗长，但正是这种冗长性赋予了开发者极大的创作自由，可以创造出其他工具难以实现的独特数据可视化作品。作者还提到，尽管现在有很多开箱即用的数据可视化工具，但 D3.js 仍然是那些追求极致定制化和艺术性的开发者的首选。D3.js 允许你完全控制每一个细节，就像绘画一样，可以充分展现你对数据的理解和诠释。
评论区对文章的观点进行了补充和讨论。
* 有评论指出，文章中关于“绑定到数据”的例子存在误解，D3.js 中正确的数据绑定方式是使用 `.data()` 方法，将数据传递给访问器函数，从而实现数据驱动的图形属性设置。
* 还有评论认为，D3.js 的代码量并不一定比原生 JavaScript 多，并给出了使用原生 JavaScript 创建 SVG 元素的示例，说明 D3.js 在某些情况下可以简化代码。
* 有开发者分享了将 D3.js 与 Solid.js 结合使用的经验，利用 D3.js 进行数据处理，Solid.js 负责 SVG 渲染，从而兼顾了 D3.js 的强大功能和 JSX 的简洁性。
* 最后，有评论总结道，更精细的控制意味着更多的代码，这正是 D3.js 的特点。
- 原文: [Why is D3 so Verbose?](https://theheasman.com/short_stories/why-is-d3-code-so-long-and-complicated-or-why-is-it-so-verbose/)
- Hacker News: [https://news.ycombinator.com/item?id=44970981](https://news.ycombinator.com/item?id=44970981)
- 作者: TheHeasman
- 评分: 30
- 评论数: 15
- 发布时间: 2025-08-21 18:12:35
---
## AI 爬虫和抓取器正在给网站带来巨大压力，Meta 和 OpenAI 是主要责任方
Fastly 的一份报告指出，AI 爬虫正在给开放网络带来沉重负担，占所有 AI 机器人流量的 80%，剩余 20% 由 AI 抓取器使用。这些机器人对网站的请求量巨大，可能导致网站性能下降、服务中断和运营成本增加。Meta 的 AI 部门占爬虫流量的一半以上，而 OpenAI 则占据了绝大多数的按需抓取请求。
Fastly 的安全研究员 Arun Kumar 表示，AI 机器人正在重塑互联网的访问方式，为数字平台带来了新的复杂性，无论是抓取训练数据还是提供实时响应，这些机器人都会给可见性、控制和成本带来新的挑战。报告基于 Fastly 的下一代 Web 应用程序防火墙 (NGWAF) 和机器人管理服务分析得出，这些服务保护超过 13 万个应用程序和 API，每月检查超过 6.5 万亿个请求。数据显示，越来越多的网站负载并非来自人类访问者，而是来自代表聊天机器人公司工作的自动化爬虫和抓取器。
报告警告说，一些 AI 机器人如果设计不当，可能会给 Web 服务器带来不可持续的负载。Kumar 认为，这种增长是不可持续的，它带来了运营挑战，同时也破坏了内容创建者的商业模式。他呼吁业界建立负责任的爬行规范和标准，允许 AI 公司获取所需数据，同时尊重网站内容指南。Meta 占所有 AI 爬虫流量的 52%，其次是 Google 和 OpenAI，分别占 23% 和 20%。相比之下，Anthropic 仅占爬虫流量的 3.76%。在 AI 抓取器方面，OpenAI 是绝对的主导者，占所有请求的近 98%。
Perplexity AI 最近被指控使用超出其报告的爬虫范围之外的 IP 地址，并忽略了网站希望退出抓取的 robots.txt 指令。报告显示，Perplexity AI 仅占 AI 爬虫机器人流量的 1.12% 和 AI 抓取机器人流量的 1.53%，但这一比例正在增长。Kumar 谴责了忽略 robots.txt 注释的做法，并表示任何信誉良好的 AI 公司都应该遵守 robots.txt，并发布其 IP 地址范围，且其机器人应使用唯一的名称。
面对机器人无视 robots.txt 指令的行为，网站管理员越来越多地转向主动防御措施，例如 proof-of-work Anubis 或 gibberish-feeding tarpit Nepenthes。Fastly 的竞争对手 Cloudflare 也在测试一种按爬行付费的方法，以增加机器人运营商的经济负担。Kumar 指出，小型网站运营商，尤其是那些提供动态内容的网站运营商，最有可能受到这些影响。他建议首先配置 robots.txt，以立即减少来自行为良好的机器人的流量。
Anubis 开发者 Xe Iaso 认为，只有 AI 泡沫破裂才能阻止爬虫流量的增长。他们补充说，没有理由认为这种增长会停止，因为人们正在使用这些工具来取代知识和获得技能。
- 原文: [AI crawlers, fetchers are blowing up websites; Meta, OpenAI are worst offenders](https://www.theregister.com/2025/08/21/ai_crawler_traffic/)
- Hacker News: [https://news.ycombinator.com/item?id=44971487](https://news.ycombinator.com/item?id=44971487)
- 作者: rntn
- 评分: 93
- 评论数: 38
- 发布时间: 2025-08-21 19:35:22
---
## 为什么动漫猫娘会阻止我访问 Linux 内核？
本文讨论了 Anubis，一种旨在通过“衡量 HTTP 请求的灵魂”来防御 AI 爬虫的网络安全措施，但实际上可能适得其反，反而限制了普通用户对 Linux 内核等资源的访问。
文章指出，Anubis 通过要求访问者解决对计算机来说很简单但对人类来说很困难的问题来工作，这与传统的 CAPTCHA 方法相反。它要求用户暴力破解一个值，该值附加到挑战字符串后，使其 SHA-256 哈希以几个零 nibbles 开头，类似于比特币挖矿。作者认为，这种方法对于拥有大量计算资源的 AI 供应商来说成本很低，但对于资源有限的普通用户来说却造成了障碍。
文章通过计算表明，使用默认 Anubis 配置，爬取部署 Anubis 的所有网站所需的计算成本实际上非常低，对于大型 AI 供应商来说几乎可以忽略不计。作者还提到了 Anubis 论坛上用户的抱怨，他们因为这种机制而难以访问网站。
文章还提到了 Hashcash 和 Habeas 等其他反垃圾邮件解决方案，并将 Habeas 使用诗歌来阻止垃圾邮件的独特方法进行了比较。Habeas 会将简短的俳句授权给公司嵌入到电子邮件标头中，然后积极起诉任何未经许可复制其诗歌的人。
总而言之，文章对 Anubis 作为一种反爬虫措施的有效性提出了质疑，认为它可能无法有效阻止 AI 爬虫，反而对普通用户造成了不便。文章建议考虑其他替代方案，并对 Anubis 的设计理念提出了批评。
- 原文: [Why are anime catgirls blocking my access to the Linux kernel?](https://lock.cmpxchg8b.com/anubis.html)
- Hacker News: [https://news.ycombinator.com/item?id=44962529](https://news.ycombinator.com/item?id=44962529)
- 作者: taviso
- 评分: 697
- 评论数: 738
- 发布时间: 2025-08-20 22:54:45
---
## 十六瓶葡萄酒谜题：如何在限定次数内识别所有年份？
本文介绍了一个有趣的逻辑谜题：如何用最少的测量次数，识别出16瓶年份各不相同的葡萄酒。 谜题的核心在于利用葡萄酒年份的唯一性，减少测量次数，在50次测量内找出所有葡萄酒的年份。
文章首先回顾了简化版本的问题，例如两瓶和四瓶葡萄酒的情况，逐步引导读者理解解题思路。 对于两瓶酒，只需要一次测量即可确定；对于四瓶酒，通过巧妙地利用设备，可以将测量次数减少到五次。
更进一步，文章探讨了八瓶葡萄酒的情况，展示了如何通过分组和重复利用四瓶酒的策略，将测量次数控制在17次。最终，文章给出了十六瓶葡萄酒的解法：先用设备3测量15瓶酒，将问题分解为两个八瓶酒的问题，再利用八瓶酒的策略，最终可以在49次测量内解决问题。
文章还提供了可视化的方法，帮助读者理解概率变化的过程，以及如何通过观察来节省额外的测量步骤。 这种逐步递进的讲解方式，让读者更容易理解问题的本质和解题的精髓。
- 原文: [Sixteen bottles of wine riddle](https://chriskw.xyz/2025/08/11/Wine/)
- Hacker News: [https://news.ycombinator.com/item?id=44933019](https://news.ycombinator.com/item?id=44933019)
- 作者: chriskw
- 评分: 35
- 评论数: 10
- 发布时间: 2025-08-18 00:57:50
---
🫵 来啊，说点有用的废话!
