🛡️ 安全验证 验证您是否为机器人 ⏳ 正在验证您的浏览器… 验证并继续 ✓ 验证完成 此页面将在稍后自动跳转…
每日HackerNews RSS
## 绿河“上坡”路线的解释
一篇最近发表在phys.org上的文章讨论了一种地质之谜：绿河不寻常的河道。地质学家认为他们已经解决了这个问题，将河流的路径归因于大约200-500万年前，一股巨大的、缓慢移动的地幔物质向下沉入科罗拉多高原下的地球深处。“滴落”过程创造了一种隆起和沉降的“靶心”模式。
Hacker News上的讨论迅速转向了地质学进一步阅读的推荐，约翰·麦菲的《昔日世界编年史》被高度赞扬，作为对该领域的引人入胜且全面的介绍。用户还强调了韦恩·拉尼关于大峡谷的研究以及理查德·福蒂的《地球：一部亲密的历史》。
评论中反复出现的一个主题是对在线内容中使用的不准确图像的沮丧，特别是库存照片错误地代表了地理位置。除了科学之外，评论员还反思了地质过程所涉及的巨大时间尺度，将地球的固体物质描述为在数百万年的时间里表现得更像是一种缓慢移动的液体。
多年来，作者依靠通过10Gbps网络使用`rsync`来传输大型视频项目（通常包含数百个文件，有些高达10GB），在NAS和雷雳SSD之间进行传输。尽管存储和网络硬件很快，但`rsync`的单线程特性将传输速度限制在约350MB/秒，复制约59GB的数据需要超过8分钟。尝试使用压缩或守护进程优化`rsync`效果不佳，甚至由于NAS的基于Arm的处理器而导致速度变慢。 解决方案是`rclone`，这是一种先前用于云备份的工具。利用`rclone`的`--multi-thread-streams`选项，作者实现了4倍的速度提升，使传输速度达到1GB/秒的网络连接上限，并在短短2分钟多一点的时间内完成了相同的传输。虽然报告的数据大小存在细微差异（可能由于文件排除），但`rclone`的并行传输能力极大地提高了效率。对于增量更改，两种工具的性能相似，这表明`rclone`的优势在于其能够并发传输多个文件。
## Rclone 与 Rsync：更快的网络文件同步
一篇 Hacker News 的讨论围绕着一篇博客文章展开，该文章展示了使用 rclone 与 rsync 相比，文件同步速度明显更快（高达 4 倍）。虽然 rsync 在增量传输能力和带宽节省方面仍然很有价值，但有几个因素促成了 rclone 的性能提升。
主要观点包括：SSH 的接收缓冲区大小的限制（2MiB）会影响 rsync 在高带宽连接上的性能，单线程应用程序（如 rsync）可能存在瓶颈，以及 rclone 利用多流/线程的能力。一些评论员认为 rclone 缺乏默认压缩（与通过 SSH 的 rsync 不同）也起到了作用。
讨论强调了 TCP 调优的重要性以及网络层面限制的可能性。为了高性能场景，还提到了 Aspera（使用带有纠错的 UDP）和 Warp Speed Data Transfer 等替代方案。许多用户赞扬 rclone 的多功能性和易用性，尤其是在云存储方面，同时也承认 rsync 在特定用例（如临时传输和高效更新）中的优势。一个反复出现的主题是需要更好的工具和优化来处理大规模数据传输。
AdBoost：一个在每个网页上添加广告的浏览器扩展程序。
Show HN: Adboost – A browser extension that adds ads to every webpage
5 天前
## AdBoost：一款别出心裁的浏览器扩展
AdBoost 是一款独特且带有讽刺意味的浏览器扩展，专为 GitHub 设计，旨在*添加*广告到网页——与典型的广告拦截器相反。它由 surprisetalk 创建，并被宣传为“唯一一款向网页添加广告的浏览器扩展！”
该项目在 GitHub 上公开可用，需要通过 Chrome 的扩展开发者模式手动安装。它包含一个 `manifest.json`、`content.js` 和 `readme.md` 文件。
目前，AdBoost 获得了 2 颗星和 0 次分叉，表明它更像是一个新奇项目，而不是一个被广泛使用的工具。它作为对在线广告盛行的有趣评论，以及扩展开发的一个演示。
## Nano-vLLM：深入探讨LLM推理
大型语言模型 (LLM) 推理依赖于像 Nano-vLLM 这样的引擎，它是一个精简的（约 1,200 行 Python 代码）实现， 遵循 vLLM 的核心原理。本系列文章将探讨提示如何转换为令牌并被高效处理，从而影响系统设计。
Nano-vLLM 采用生产者-消费者模式：提示会被标记化并添加到调度器队列中。调度器将这些序列分批处理，平衡吞吐量（处理速度）和延迟（响应时间）——更大的批次会提高吞吐量，但可能会延迟单个响应。 推理发生在两个阶段：*预填充*（处理初始提示）和 *解码*（生成输出令牌）。
一个关键创新是块管理器，它将序列划分为固定大小的块，并通过哈希缓存常用前缀，以最大限度地减少冗余计算。该控制平面有效地管理 GPU 内存，重用块而不是重新计算它们。模型运行器然后执行模型，可能利用张量并行性将工作负载分配到多个 GPU 上。 CUDA 图进一步提升了性能，减少了解码阶段的开销。 最后，采样将模型输出（logits）转换为令牌，温度控制生成文本的随机性。
第二部分将深入研究模型的内部计算，包括注意力机制和张量并行性，从而完成对整个推理流程的理解。
## Nano-vLLM 解释与 AI 辅助写作辩论
一位具有云基础设施背景的开发者 yz-yu 发表了一篇两部分的博客文章，解释了 nano-vLLM 的内部运作，nano-vLLM 是一种 vLLM 风格的推理引擎。最初的反应质疑文章是否由 AI 生成，一位评论员指出缺少“PagedAttention”——vLLM 的核心概念——以及与代码库不一致之处。
yz-yu 澄清文章并非 AI 撰写，而是他们作为非英语母语者学习过程的结果。他们使用 Claude Code 进行初步理解和详细提问，并辅以手绘图表。在写作方面，他们利用 LLM 来润色语法和可读性，并纠正任何引入的技术错误。
这引发了关于 AI 辅助写作的更广泛讨论，评论员们争论 LLM 润色对写作风格的影响，以及区分人类、AI 生成和 AI 辅助内容之间的难度。一些人指出，增加的破折号的使用可能表明 AI 的参与，而另一些人则为将其用作一种风格选择进行辩护。作者强调了 LLM 在语法纠正方面的价值，同时也承认了对过度依赖 AI 的担忧。
## MaliciousCorgi：伪装成AI编码助手的间谍软件 最近的安全分析发现，两款 VS Code 扩展程序（总安装量达 150 万）秘密收集开发者数据并将其发送到中国的服务器。这些扩展程序被称为“MaliciousCorgi”，它们的功能如广告宣传的那样，是 AI 编码助手，提供有用的建议和代码补全，掩盖了其恶意活动。 这些扩展程序采用三种方法：实时文件监控（捕获*每个*打开和编辑的文件）、服务器触发的大规模文件收集（应命令泄露多达 50 个文件，无需用户交互）以及分析引擎（跟踪用户行为并通过嵌入式分析 SDK 构建详细档案）。 这些数据包括敏感信息，如 API 密钥、数据库密码和专有源代码。分析数据有助于攻击者识别有价值的目标，以便进行重点泄露。这些扩展程序利用开发者对市场工具的信任，利用合法功能来隐藏其间谍软件。 这一事件凸显了在没有彻底安全验证的情况下快速采用 AI 工具的风险。像 Koi 这样的解决方案提供安装后分析和阻止功能，以提供可见性并保护开发者免受此类威胁。
## Tailscale 回应近期服务可用性问题
Reddit 上最近的报告指出，Tailscale 的服务在过去一个月里出现了一些不稳定情况，公司对此表示承认并公开透明地进行回应。虽然 Tailscale 维护着公开的可用性历史记录，但明确事故的性质——例如“协调服务器性能问题”——至关重要。这些不一定是完全中断，但可能表现为延迟或影响特定的“尾网”。
Tailscale 的架构依赖于“协调服务”（以前是单个服务器，现在是多个服务器）作为消息总线，用于快速进行 ACL 更改和网络更新。虽然该设计旨在提高速度，但这种集中式方法意味着控制平面操作（添加/删除设备、更改过滤器）在中断期间会受到影响，即使现有连接保持稳定。
为了改进，Tailscale 正在关注几个关键领域：缓存网络地图以防止重启时断开连接，通过热备用和自动重新平衡等功能增强协调服务，以及改进多尾网共享以提高区域弹性。他们还在增加对测试和质量保证的投入。
尽管最近出现了一些事故，Tailscale 强调其致力于持续改进和清晰的沟通，旨在最大限度地减少停机时间及其对用户的影响。
## Tailscale 快速增长的挑战 – 摘要
Tailscale 最近发布的一篇文章，详细描述了快速增长带来的挑战，在 Hacker News 上引发了讨论。文章坦诚地讨论了增长过程中的阵痛，导致了中断并影响了服务的可靠性。尽管存在这些问题，许多用户报告称 Tailscale 的体验出奇地稳定，尤其是在较小的网络（<100 个节点）中。
评论者们争论“快速增长”的含义，一些人认为这是不可持续的，由风险投资驱动，并将规模扩张置于稳定性之上。另一些人则认为这是在市场上占据主导地位的必要策略，为了长期的成功，可以接受暂时的不稳定。
讨论还涉及技术方面，包括使用 Headscale 自行托管 DERP 服务器（Tailscale 的中继服务），以及对 CAP 定理中“可用性”组件的误解。一个反复出现、轻松的讨论主题集中在文章的封面图片上，被解读为一种包豪斯风格的暗示姿势。
最终，这场对话突出了快速扩张与维护稳定、高质量服务之间的权衡，以及扩展分布式系统的复杂性。
## 微软越来越青睐 Anthropic 的 Claude Code 几个月来，开发者一直在评估人工智能编码工具，Anthropic 的 **Claude Code** 正在脱颖而出，即使对于非技术用户也因其用户友好性而受到赞扬。这促使 **微软** 鼓励数千名员工，包括 Windows 和 Microsoft 365 团队，采用 Claude Code，作为对 **GitHub Copilot** 使用的补充。 微软的 CoreAI 团队正在积极测试 Claude Code，并且其使用已被批准用于代码仓库，甚至包括设计师和项目经理的原型设计。虽然 Copilot 仍然是面向公众的人工智能编码工具，但微软现在是 Anthropic 的主要客户，将 Anthropic 模型销售额纳入 Azure 配额——这与优先考虑自身或 OpenAI 产品形成了鲜明对比。 此举表明微软对 Anthropic 人工智能充满信心，因为它正在探索一个更加自主的人工智能驱动编码的未来。该公司预计开发者将使用多种人工智能工具，但 Claude Code 的易用性正在向更广泛的员工开放编码权限，可能会影响初级开发人员的职位。微软仍然致力于与 OpenAI 的合作，但显然正在多元化其人工智能战略。
## OxCaml 用于高性能行星计算与 Web 服务
由于对 Python 的不满以及对性能的追求，作者一直在探索 OxCaml——一个 OCaml 扩展，它在保持函数式风格和垃圾回收器的同时，提供了显著的速度提升。这促使他们构建了 `httpz`，一个新型高性能 HTTP/1.1 解析器和 Web 服务器，为作者的实时网站提供支持。
`httpz` 利用了 OxCaml 的关键特性，如 **解箱类型**（例如 `int16#`）和 **局部分配**，以最大限度地减少堆内存的使用。通过直接在栈上表示数据，服务器避免了频繁的垃圾回收，从而实现了可预测的性能和低延迟。可变栈变量和嵌套解箱记录等特性进一步提高了效率。
基准测试表明，与传统解析器相比，`httpz` 实现了显著更高的吞吐量（650 万 req/sec 对 300 万 req/sec）和 *零* 堆分配。
目前的工作包括将 `httpz` 与 Eio 集成，以通过 io_uring 实现零拷贝内核访问，并为 OxCaml 工具改进做出贡献。作者还创建了 Claude skills 来辅助 OxCaml 开发，并计划开源他们的 OxCaml 项目以促进更广泛的协作。
## OxCaml 中的零分配 Web 服务器：摘要
一位开发者分享了使用 OxCaml（一种扩展 OCaml 的语言）构建快速、零分配 Web 服务器的经验。讨论强调了 OCaml (4.08, 5.0-5.4) 的最新进展，增加了诸如 let 绑定运算符、多核运行时和动态数组等功能。
一个关键目标是实现类似于 C# 的内存控制——垃圾回收，同时为性能关键代码提供栈分配（“结构体”）的选项。讨论的挑战包括处理无分配的流水线 HTTP 请求，通过避免 HTTP/1.1 流水线并利用 OxCaml 的效应系统和延续来实现异步操作来解决。
对话还涉及类型系统更广泛的需求，即能够推断和约束内存分配，提到了子结构类型（Rust、仿射类型）和正在进行的研究，例如 Granule。最终，作者旨在平衡函数式编程原则与性能优化，利用 OxCaml 的特性实现 C/Rust 级别的速度，同时保持 OCaml 的模块化和类型安全。