每日HackerNews RSS

提升 Tailscale 速度 Making Tailscale Faster 3 天前

Tailscale 正在增强其数据平面性能，以更好地支持远程开发、机器人技术和 CI/CD 等高需求工作负载。近期及未来的优化重点在于降低延迟并提高在各种网络条件下的吞吐量。 主要的改进包括： * **内存效率：** 通过优化数据包的存储和处理方式（避免不必要的小数据包拷贝），Tailscale 降低了内存开销，并提升了 Linux 和 Android 平台上的吞吐量。 * **多队列处理：** Tailscale 正在将子网路由器、应用连接器和出口节点的处理方式从单线程管道迁移至多队列系统。这使得流量能够跨多个 CPU 核心进行扩展，从而显著提高总容量。 * **内核优化：** 利用 `writev` 等功能，实现了向 Linux 内核更高效的数据传输，并最大限度地减少了内存操作。 * **Netmap 缓存：** 此功能使设备能够使用本地缓存的网络映射建立连接。这大幅缩短了启动时间，特别是在网络不稳定或控制平面访问受限的设备上效果显著。 展望未来，Tailscale 正在开发原生诊断工具，以帮助用户更好地监控和排查特定网络路径及性能问题。这些更新将进一步巩固 Tailscale 作为高性能连接解决方案的地位，以满足多样化的基础设施需求。

查看详情

Mercury 2.5 LLM 达到每秒 770 个 token。 Mercury 2.5 LLM hits 770 tokens per second 3 天前

Mercury 2.5 的智力水平低于平均水平，但在同价位模型中性价比较高。它速度极快且输出相当简洁。该模型支持文本输入和输出，并拥有 26 万 token 的上下文窗口。 Mercury 2.5 在人工智能分析智力指数（Artificial Analysis Intelligence Index）上得分为 12 分，低于同类模型的平均水平（中位数为 13）。在智力指数评估中，它生成了 3500 万 token，相比 8500 万的中位数而言相当简洁。 Mercury 2.5 的定价为每百万输入 token 0.25 美元（价格适中，中位数为 0.25 美元），每百万输出 token 0.75 美元（价格适中，中位数为 0.90 美元）。平均而言，在智力指数上评估 Mercury 2.5 的单次任务成本为 0.06 美元。 Mercury 2.5 的处理速度为每秒 770 token，表现显著迅捷（指数为 109）。

查看详情

Meta VR 头显 Meta VR Glasses 3 天前

请提供您需要翻译的内容。

Hacker News 上关于 Meta 新款 VR 眼镜的讨论，反映了人们对该硬件外形设计的兴奋，以及对 Meta 企业行为的强烈质疑。 **硬件与规格：** 用户对 100 克的轻量化设计及其集成的 Micro-OLED 显示屏（单眼 2412 × 2288 分辨率）印象深刻。尽管一些人将其视为迈向轻便可穿戴 AR 的重大飞跃，但也有人批评 70 度的视场角对于大型游戏来说过于受限，并对 1300 美元的定价持保留意见。讨论中还将其与 Apple Vision Pro 以及诸如 Bigscreen Beyond 等更专业的 PC 直连设备进行了对比。 **隐私与信任：** 争议的核心在于 Meta 要求进行基于身份信息的年龄验证。许多评论者认为这是一种“对用户不友好”的隐私侵犯，并表示由于不信任 Facebook/Meta 的数据处理方式，他们不会购买该设备。 **实用性：** 关于这些眼镜能否解决实际问题，各方观点不一。一些人认为其在生产力或沉浸式媒体消费方面具有便携的“无限”屏幕价值；而另一些人则认为这只是一个小众的新奇玩意，且会让用户在公共场合显得不合群或“怪异”。

查看详情

标点符号的神奇力量 The Curious Power of Punctuation 3 天前

在《Verb Your Enthusiasm》一书中，前《华盛顿邮报》舞蹈评论家莎拉·考夫曼提出了一套植根于报纸新闻写作限制的风格指南。她主张采取极简主义方法：优先使用强有力的动词，避免被动语态，并无情地删减形容词和副词。考夫曼认为，精确的词汇选择使“其实”之类的加强语显得多余且往往不必要。 尽管考夫曼的建议对必须在有限版面内工作的记者来说极具价值，但本文作者质疑这种僵化的极简主义是否适用于所有写作者。他指出，虽然副词和斜体等修辞手段可能被过度使用，沦为依赖的拐杖，但它们也能提供必不可少的语调、色彩和细微差别。他建议写作者不应抛弃这些工具，而应充分利用他们的“工具箱”。 归根结底，本文反映了语言如何随技术而演变。随着数字交流引入了新的表达形式——例如“电子邮件”这类名词动词化现象以及基于表情符号的标点，关于正式风格指南的争论仍在继续。虽然简洁是一种美德，但作者总结认为，严守极简主义规则不应以牺牲写作者的表达范围为代价。

抱歉。

查看详情

我们刚刚发布了对 HTTP 中最棘手部分的更新：Vary。 We just shipped support for the ugliest part of HTTP: Vary 3 天前

HTTP `Vary` 标头允许单个 URL 提供多种内容版本（如不同的语言或格式），它通过指示缓存区分请求标头来实现这一点。然而，由于 `Vary` 的实现往往不尽如人意，缓存可能会变得“碎片化”，因标头格式、大小写或顺序上的细微差异而存储冗余的变体。这降低了缓存命中率并浪费了存储空间。 Cloudflare 推出的新功能“缓存规则中的 Vary”通过让用户控制如何处理这些变体来解决此问题。用户现在无需盲目信任源站的 `Vary` 标头，而是可以为每个标头定义特定的操作： * **规范化 (Normalize)：** 将格式略有差异（例如顺序或空格不同）的请求合并为单个共享的缓存条目。这是推荐的默认选项。 * **透传 (Passthrough)：** 当这些差异对所提供的内容至关重要时，保留精确的标头值。 * **绕过 (Bypass)：** 对于高度独特或不可预测的标头，完全阻止缓存。 通过将缓存匹配请求的方式与源站支持的实际变体保持一致，该功能确保了缓存既准确又高效，避免了 `Vary` 的负面影响导致性能下降。

Cloudflare 已正式添加对 `Vary` HTTP 标头的支持，这是用户多年来一直要求的功能。`Vary` 标头允许服务器根据 `Accept` 或 `Accept-Language` 等请求标头缓存资源的多个版本，从而实现更复杂的内容协商（例如，从同一 URL 提供不同的文件格式或语言）。 此前，由于 Cloudflare 缺乏对 `Vary` 的支持，开发人员被迫使用变通方法，例如将版本编码到 URL 路径中（如 `/en-US/article.html` 或 `file.json`）。开发人员社区对此反应大多积极，许多人认为这是一项姗姗来迟的更新。然而，一些网络开发老手认为 `Vary` 标头本质上很“丑陋”，且容易陷入实现陷阱。另一些人则强调，虽然此更新简化了缓存，但并未消除管理动态内容的根本复杂性，并指出依赖显式的版本化 URL 通常是确保一致用户体验更可靠的设计模式。

查看详情

古神头上的神秘动物 The mystery animal on an ancient god's head 3 天前

正在检查您的浏览器……需要启用 JavaScript

查看详情

NixOS 上的 Swap、ZRAM、Zswap 和休眠 Swap, ZRAM, Zswap and Hibernate on NixOS 3 天前

作者正在为 NixCon 2026 的演讲做准备，并分享了关于工作站交换空间（swap）管理的见解。作者认为，交换空间对于实现“先挂起后休眠”（suspend-then-hibernate）等功能至关重要，该功能在即时唤醒和节能休眠之间提供了良好的平衡。 虽然关于交换文件与交换分区的争论仍在继续，但作者指出，NixOS 目前已经能很好地处理使用交换文件实现休眠的复杂性。对于配备 SSD 的工作站，作者建议使用 `zswap` 而非 `zram` 以获得最佳性能。 作者推荐的 NixOS 配置非常简洁： ```nix boot.zswap.enable = true; boot.kernel.sysctl."vm.swappiness" = 100; ``` 作者建议 SSD 用户将 `swappiness` 的值设为 100，这能让内核优先考虑交换匿名页而非文件缓存页。在压缩算法方面，作者倾向于使用 NixOS 默认的 `zstd`。他指出，更好的压缩比通常优于 `lz4` 等算法的原始速度，因为更高的压缩比可以将更多数据保留在内存中，从而最大限度地减少磁盘 I/O。最后，作者强调应保持配置简单，并持续通过测试来改进方案。

抱歉。

查看详情

LensVLM-9B by Apple 3 天前

查看详情

Linux 支持即将登陆 Snapdragon X2 系列。 Linux support is coming to Snapdragon X2 Series 3 天前

走进 2026 年骁龙峰会：代理式 AI PC、Googlebooks 和 Linux。您需要启用 JavaScript 才能运行此应用。

查看详情

OpenAI breaches Medicare, Albanese reveals 3 天前

澳大利亚总理安东尼·阿尔巴尼斯（Anthony Albanese）近日透露，OpenAI 的一个研究团队在 6 月份使用内部 AI 智能体进行数据采集时，访问了澳大利亚政府 Medicare 门户网站上的非公开文件。 这一事件在 Hacker News 上引发了广泛讨论，主要聚焦于以下几个核心议题： * **责任归属与叙事方式：** 许多评论者拒绝接受“AI 智能体”独立实施了“入侵”这一说法。他们认为 AI 只是人类控制下的工具，OpenAI 的研究人员应为其行为承担全部责任。 * **安全担忧：** 技术界对于该网站究竟是被“黑客攻击”还是单纯因安全防护不力而泄露表示怀疑。批评者认为，政府可能正在利用“AI 威胁”这一叙事来转移对其数据安全防护不足的关注，并指出该门户网站面向公众开放，极有可能在缺乏适当访问控制的情况下存放了敏感文件。 * **监管审查：** 用户对 OpenAI 直至 8 月或 9 月才披露该事件表示不满。此次讨论凸显了对法律问责的呼声日益高涨，一些人将这种鲁莽行为比作“危险驾驶”，并要求大型 AI 公司必须承担与其他获取隐私数据的组织相同的法律标准。

查看详情

更多