《Wi-Fi 只在下雨时工作》文章摘要

核心事件

作者在大学假期回家时，发现家庭网络出现异常——Wi-Fi 仅在下雨时才能正常连接，雨停后约15分钟便恢复高丢包率（90%以上）。其父亲作为资深网络工程师，此前已察觉问题但未深入排查。

网络环境背景

• 家庭网络通过高增益定向Wi-Fi天线桥接，连接父亲办公室的商业级宽带（因家庭宽带质量较差）。
• 该系统已稳定运行近十年。

故障排查过程

1. 初步测试：确认本地路由器和桥接设备无异常，但远程桥接端丢包率极高。
2. 硬件检查：依次排查设备故障、线缆松动、电源适配器、固件更新、天线接口腐蚀等问题，均未发现原因。
3. 关键发现：作者注意到邻居院中的树木逐年生长，其最高枝条在晴天时阻挡了Wi-Fi信号传输路径。
4. 原理分析：
   • 下雨时：雨水积聚在树叶上增加重量，使枝条下垂，暂时移出信号路径。
   • 雨停后：雨水滴落使枝条回升，重新阻挡信号。

解决方案

• 将设备升级为支持波束成形（Beamforming） 技术的802.11n标准，该技术能通过多天线主动优化信号方向，增强抗干扰能力。
• 安装新设备后，即使不下雨网络也恢复正常。

文章背景

本文发布于愚人节（April Cools Club活动），内容为作者真实的故障排查经历，旨在以意外主题呈现技术故事。

Bun 1.1 是一个重大更新，新增了 Windows 支持，并包含超过 1,700 次提交，重点提升稳定性、兼容性并修复了大量错误。主要更新如下：

Windows 支持

• Bun 现在可在 Windows 10 及更高版本上运行，通过了 98% 的测试套件。
• 安装命令：powershell -c "irm bun.sh/install.ps1 | iex"
• bun install 速度极快，比 yarn 快 18 倍，比 npm 快 30 倍。
• bun run 通过新的 .bunx 文件格式实现，比 npm run 快 11 倍，解决了 Windows 符号链接和提示问题。

JavaScript 运行时改进

• 大型项目启动速度提升 2 倍。
• 新增 Bun Shell：一个跨平台（包括 Windows）的 bash 式 shell，可通过 bun.$ API 在 JS/TS 中使用，并自动在 Windows 的 bun run 脚本中启用。
• 新增 Bun.Glob API：用于 glob 模式匹配，速度比类似库快 3 倍。
• 新增 Bun.Semver API：用于语义化版本解析和排序，比 node-semver 快 20 倍。
• 新增 Bun.stringWidth()：测量终端字符串可视宽度，比 string-width 包快 6000 倍。
• 新增 server.url、server.requestIP() 和 subprocess.resourceUsage() 等 API。
• 新增 import.meta.env 支持，与 process.env 等价。

Node.js 兼容性

• 新增 HTTP/2 客户端支持。
• 修复了 Date.parse() 以匹配 Node.js（V8）行为。
• 支持递归的 fs.readdir()，速度比 Node.js 快 22 倍。
• 支持与 Node.js 进程间的 IPC 消息传递。
• 添加或修复了大量未文档化的 Node.js API（如 _headers、_implicitHeader）。

Web API 改进

• WebSocket 已稳定，通过 Autobahn 一致性测试。
• 支持 performance.mark() 和 performance.measure()。
• fetch() 支持 Brotli 压缩、Unix 套接字以及 AsyncIterator 作为响应体。
• 支持 URL.canParse()。

包管理器 (bun install)

• 改进了生命周期脚本（如 postinstall），在 Windows 上使用 Bun Shell 运行。
• 引入 可信依赖项 安全模型，默认阻止不受信任包的脚本运行，可通过 bun pm trust 管理。
• 新增 bun pm migrate 命令，可将 package-lock.json 转换为 bun.lockb。

构建工具 (bun build)

• 修复了 --target=node 的多个错误。
• --compile 现在支持嵌入 NAPI 插件（.node 文件）。
• 改进了宏系统，支持在打包时导入内置模块。

测试运行器 (bun test)

• 新增数十个 expect() 匹配器。
• 支持通过 expect.extend() 创建自定义匹配器。
• 支持模块模拟（可模拟 ESM、CommonJS、本地文件、npm 包和内置模块）。

内置 SQLite

• 支持多语句查询。
• 提供更详细的错误信息。
• 支持通过 import 导入 SQLite 数据库文件（使用 with { type: "sqlite" }），并可在编译时嵌入。

开发者体验

• 错误信息现在带有语法高亮。
• 简化了错误堆栈跟踪。
• 新增 bun --eval / bun -e 和 bun --print 命令。
• 新增 --env-file 选项加载自定义 .env 文件。

行为变化

• 网络超时默认延长至 5 分钟。
• Bun.write() 现在会自动创建父目录。
• 条件导出中默认不再包含 worker 条件。
• NODE_ENV 默认值改为 undefined（匹配 Node.js）。
• bun install lodash@latest 现在会解析版本并写入具体版本号。
• Bun.$ 在子进程以非零代码退出时现在会 reject。

性能与稳定性

• 修复了超过 1,000 个错误。
• 多项性能改进，例如 bunx 比 npx 快 50 倍，fs.readdir 比 Node.js 快 40 倍，内存使用普遍降低。
• 改进了 fetch()、文件操作、SQLite 等模块的性能。

升级与开始

• 升级命令：curl -fsSL https://bun.sh/install | bash (Unix) 或 powershell -c "irm bun.sh/install.ps1 | iex" (Windows)。
• 也支持 Docker 镜像 oven/bun。

Python Cloudflare Workers 摘要

Cloudflare Workers 现已进入公开测试阶段，支持直接使用 Python 编写。此项支持与以往通过编译至 WebAssembly 或 JavaScript 的方式不同，其将 Python 运行时 (Pyodide) 直接集成到了 Workers 运行时 (workerd) 中。从第一天起，所有绑定（包括 Vectorize、Workers AI、R2、Durable Objects 等）均已受支持。开发者可以直接导入部分流行的 Python 包（如 FastAPI、Langchain、Numpy），且无需额外的构建步骤或外部工具链。

核心实现与优势

• 超越“编译至WebAssembly”：虽然原则上可通过编译实现，但实际应用需要完整的生态系统支持。Python Workers 提供了对 Python 语言的一等公民级支持。
• 工作原理：开发时，运行时会根据兼容性日期注入合适的 Pyodide 版本，并自动创建执行环境。Pyodide 是 CPython 的 WebAssembly 移植版，它在沙箱中解释执行 Python 代码，并提供了一个关键特性：与 JavaScript 的外部函数接口。
• FFI 的关键作用：通过 FFI，Python 代码可以直接调用 JavaScript API（例如 from js import Response）。这确保了 Python Workers 能够访问 Workers 平台的所有 JavaScript 功能，避免成为“二等公民”，也是 FastAPI、Langchain 等包能开箱即用的基础。
• 动态链接的必要性：Pyodide 使用 Emscripten 编译，支持动态链接。这允许在运行时链接 WebAssembly 模块，并使得 Python 的 C FFI 能够被重定向。更重要的是，动态链接使得 Python 运行时和包（作为 WebAssembly 模块）的底层代码可以在同一台机器上的多个 Workers 之间共享，极大地节省了内存。
• 包支持与适配：
  • 异步HTTP客户端（如 httpx, aiohttp）：通过 FFI 将请求重定向到 JavaScript 的 Fetch API 实现。
  • 同步HTTP客户端：目前受限，未来可利用 WebAssembly 栈切换 提案来支持。
  • FastAPI：由于其基于 ASGI 协议，不直接处理套接字，因此可以无缝运行，只需将底层 ASGI 服务器替换为 Workers 兼容的实现。
  • 依赖包通过 requirements.txt 声明，具体版本由 Pyodide 固定以保证兼容性。

性能优化：处理冷启动

Pyodide 及 Python 包体积较大，直接加载会导致冷启动缓慢。为此，Cloudflare 在部署时执行以下优化：

1. 扫描 Worker 代码中的 import 语句并执行，随后拍摄 WebAssembly 线性内存的快照。
2. 将此快照与 Python 代码一同部署到网络。
3. 请求到来时，使用快照快速引导隔离环境，将基础 Python Worker 的冷启动时间降至 1 秒以下。
4. 未来计划：创建预置的共享快照并预热到隔离环境池中，模拟 JavaScript Workers 的体验，进一步降低延迟。

版本管理与兼容性

为了确保现有 Worker 能持续运行，Python Workers 同样采用 兼容性日期和标志 机制。

• 新版本的 Pyodide（对应新版本的 Python）将通过兼容性标志引入，并在特定的兼容性日期后生效。
• 每个 Python 版本有五年支持期。支持期结束后，使用该版本的 Worker 将被自动升级至下一个较旧的支持版本。
• 包更新也使用类似的标志机制（例如 python_3.17_packages_2025_03_01）。

未来展望

• 提供更 Pythonic 的 API：计划像为 Rust 提供 workers-rs 一样，为 Cloudflare 资源（如 Workers AI、Vectorize）提供内置的、更符合 Python 习惯的绑定。
• 增强生态系统兼容性：目标是实现 Python 标准库中 socket API 的子集，以支持更多依赖它的包。
• 推动标准化：长期目标是发起一个标准化的无服务器 Python API。

Cloudflare 表示，Python Workers 是其对支持新编程语言的重大投资的开始，并将持续致力于提升性能、扩大包支持范围。

xz攻击脚本分析

本文详细分析了2024年3月披露的xz-utils供应链攻击中，恶意Shell脚本的工作原理。攻击通过篡改构建过程，将恶意代码注入最终生成的liblzma库中。

攻击载体与触发

攻击始于恶意添加的build-to-host.m4文件。在configure阶段，此文件会从预先植入的恶意测试文件（如bad-3-corrupt_lzma2.xz）中提取并解压出一段隐藏的Shell脚本。该脚本随后通过eval执行，开始了多阶段的攻击链。

脚本的两阶段执行

1. 配置阶段 (configure):

   • 脚本首先检查构建环境是否为目标平台（x86_64 Linux、使用GCC和GNU ld、支持共享库和ifunc特性等）。
   • 然后，它修改构建系统的核心文件：
     • 在src/liblzma/Makefile中插入若干看似无害的变量定义（如am__test、am__strip_prefix）。
     • 添加链接器标志 -Wl,--sort-section=name,-z,now，强制动态链接器在程序启动时立即解析所有符号（包括ifunc），此时全局偏移表(GOT)和过程链接表(PLT)尚未变为只读，为后续修改创造了机会。
     • 篡改libtool文件，添加额外的编译标志（-fno-lto -ffunction-sections -fdata-sections）。
     • 在Makefile的特定规则中，插入一段命令，该命令在make阶段会再次解压并执行同一个恶意Shell脚本。

2. 构建阶段 (make):

   • 当构建运行到src/liblzma目录时，脚本的make分支被触发。
   • 它再次从恶意测试文件（good-large_compressed.lzma）中提取数据，经过一系列解密（包括使用awk实现的类RC4解密算法）后，生成一个恶意的目标文件liblzma_la-crc64-fast.o。
   • 随后，脚本对crc64_fast.c和crc32_fast.c源文件进行“就地”修改：
     • 将函数is_arch_extension_supported的调用改为_is_arch_extension_supported。
     • 在#include "crc_x86_clmul.h"后插入一段新的C代码。这段代码声明了一个外部函数_get_cpuid，并定义了_is_arch_extension_supported函数，后者会调用_get_cpuid。
   • 最后，脚本将提取的恶意目标文件与编辑后的源代码一起重新编译，覆盖了原始的编译结果。编译完成后，还会重新链接liblzma库。

攻击效果

通过以上操作，恶意函数_get_cpuid被植入liblzma库。由于该函数通过ifunc机制在程序启动早期（GOT/PLT变为只读之前）执行，它能够修改GOT/PLT，将RSA_public_decrypt函数替换为恶意版本。当SSH守护进程处理特定证书时，就会触发攻击者的代码，实现后门功能。

总结

此攻击展示了极其复杂的供应链攻击技术：利用开源构建系统（autoconf/make）的合法机制，在看似合理的测试文件中嵌入加密的恶意载荷，并通过多阶段的Shell脚本在构建过程中悄无声息地注入后门。脚本本身包含大量环境检查以确保攻击只在特定条件下执行，并设计了扩展机制以备未来更新。

低成本机器人手臂项目概述

本项目是一个可自主搭建的低成本机器人手臂方案，总成本约为430美元，包含一个用于控制的主导臂和一个执行任务的从动臂。该设计适用于机器人学习研究，两台手臂协作可完成如折叠衣物等复杂任务。其核心优势在于成本低廉、构建相对简单，并且比使用原厂适配器具有更低的延迟。

1. 从动臂

• 成本：约258美元。
• 核心组件：
  • 电机：使用Dynamixel伺服电机。肩部等需较大力矩的关节使用2个XL430-W250型号，其余轻量化关节使用4个XL330-M288型号（单个仅重18克）。
  • 连接：采用Waveshare串行总线伺服驱动板替代昂贵的U2D2适配器，以降低成本和延迟。
  • 电源：使用一个12V电源，并通过一个电压降压模块为部分5V伺服电机供电。
• 组装与配置：
  • 所有塑料部件均需3D打印（STL文件位于hardware/follower/stl）。
  • 组装前需使用Dynamixel Wizard工具扫描并设置每个电机的波特率（1M）和ID（从肩部到夹爪依次编号）。
  • 按照接线指南将电机、驱动板、降压模块和电源连接起来。组装完成后需调整降压模块，确保输出电压为5V。

2. 主导臂

• 成本：约183美元。
• 设计：设计灵感来源于GELLO项目，但结构更简单。夹爪被替换为一个带扳机的手柄，默认状态下扳机可受力打开。
• 核心组件：
  • 电机：全部使用6个更轻量的XL330-M077型号伺服电机，电压统一为5V。
  • 连接与电源：同样使用Waveshare驱动板，并直接使用一个5V电源供电，无需降压模块。
• 组装：组装过程比从动臂更简单，因为电气连接更统一。

3. 控制与模拟

• 软件依赖：通过pip install dynamixel-sdk安装Dynamixel SDK进行底层控制。
• 测试脚本：项目提供了teleoperation.py脚本用于测试主导臂对从动臂的远程控制。
• 模拟环境：提供了基于MuJoCo的简单模拟环境，可通过运行simulation.py启动。
• 组装指导：详细的组装步骤可通过提供的视频链接学习。

Wireproxy 项目摘要

Wireproxy 是一个完全在用户空间运行的 WireGuard 客户端，其核心功能是将建立的 WireGuard 连接暴露为 SOCKS5 或 HTTP 代理，或提供 TCP 隧道。

主要功能与用途

• 核心目的：无需创建新的网络接口或获取 root 权限，即可通过 WireGuard 对等节点代理特定的网络流量。
• 代理服务：可在本地创建 SOCKS5 和 HTTP 代理服务器，将流量通过 WireGuard 隧道转发。
• TCP 隧道：支持三种模式：
  • TCPClientTunnel：本地监听，通过 WireGuard 转发至远程目标。
  • TCPServerTunnel：在 WireGuard 网络上监听，将流量转发至本地服务。
  • STDIOTunnel：将进程的标准输入/输出通过 WireGuard 连接到远程 TCP 目标，可用作 OpenSSH 的 ProxyCommand。
• 健康检查：支持暴露一个 HTTP 健康检查端点（/metrics 显示 WireGuard 状态，/readyz 用于存活探针）。

典型使用场景

1. 希望以简单代理的方式使用 WireGuard，而非全局 VPN。
2. 需要在无 root 权限的环境下使用 WireGuard 进行流量代理。
3. 需要隔离 WireGuard 流量，不修改主机网络配置。

关键配置

配置文件包含以下部分：

• [Interface] 和 [Peer]：遵循 wg-quick 的配置格式，定义 WireGuard 接口和对等节点。
• [Socks5] 和 [http]：定义本地代理的监听地址，并可配置认证（用户名/密码）和 HTTPS 证书。
• [TCPClientTunnel]、[TCPServerTunnel] 和 [STDIOTunnel]：定义各种 TCP 隧道。
• 支持导入已有的 WireGuard 配置文件（WGConfig = <路径>）。
• 支持多个对等节点，需通过 AllowedIPs 指定流量路由。
• 支持 Resolve 部分配置 DNS 解析策略（ipv4、ipv6、auto）。

项目状态与部署

• 当前支持：SOCKS5/HTTP 代理（仅 CONNECT 方法）、TCP 静态路由。
• 待办功能：SOCKS5 的 UDP 支持、UDP 静态路由。
• 构建与安装：可通过 Go 语言源码编译或直接使用 go install 安装。
• 额外资源：提供了在 Firefox 容器标签页中使用以及 macOS 下自动启动的指南链接。

文章核心观点：在业余比赛和创业中，避免犯下重大失误（blundering）是取胜的关键，这比主动追求卓越更为重要。

1. 核心论点与类比

文章以业余国际象棋和业余网球为例，阐述“避免失误”即能带来胜利。

• 国际象棋：作者分析了自己的数百局业余比赛数据，发现胜负主要取决于谁犯的错误（特别是“重大失误”）更少。犯错更少的一方有81% 的胜率，而棋力等级分（Elo）更高的棋手仅以55%的胜率微弱占优。这证实了职业棋手Ben Finegold的观点：业余棋局的胜负通常是由一方的失误决定的。
• 网球：引用Simon Ramo的研究，业余网球比赛中约80% 的得分是由于对手失误（如击球出界、下网）而非自己打出制胜分。因此，保守打法，让对手犯错，是业余玩家的有效策略。

总结规律：在业余级竞争中，胜利更多来自“不犯错”，而非“做得多好”。

2. 应用于创业领域

作者将此规律类比到创业，并指出许多常见的“创业失败原因”实则是表面现象或不可控因素，而非根本的可预防失误。

• 非真正原因：
  • 直接/表面原因：如“资金耗尽”、“创始人放弃”、“未找到产品市场契合点（PMF）”。这些是失败的结果，而非原因。
  • 不可控坏运气：如经济剧变、意外的创始人解体等。这些虽导致失败，但无法预防，教训有限。
  • 常见的误解：“想法不好”、“无法做出产品”、“创始人数量不对”、“地理位置不佳”。作者认为这些单独并不构成必然的失误，成功与否更取决于执行、迭代和创始人特质。

3. 创业中可预防的失误

文章重点列举了创业者本应避免的、自导致的失误，这些是导致失败的主要原因：

• 未与客户沟通：未在创业前和创业后与客户充分交流并倾听。
• 市场需求不明确：未事先验证市场规模、客户需求、支付意愿等。
• 无明确目标受众：试图面向所有人，导致信息模糊，无法有效触达核心用户。
• 成功条件过多：商业模式要求太多环节同时正确，成功概率极低。
• 创始人/投资人间破裂：常因股权设计不合理（如缺乏归属期）或选择不慎导致。
• 市场无差异化：产品或公司缺乏独特优势，陷入同质化竞争。
• 拒绝面对真相：固执己见，不根据市场反馈调整策略和产品。
• 发布时机不当：过早发布糟糕的最小可行产品（MVP）或过晚发布（开发周期过长）。
• 过早规模化：在未验证PMF前就盲目扩张团队、营销投入。
• 过早转向企业市场：在营收较低时，盲目进入要求复杂、销售周期长的大型企业市场。
• 商业模式不可行：单位经济效益从根本上无法支撑盈利。
• 专注于编码而非获客：过度投入产品开发，忽视市场营销和销售。
• 过早扩大目标市场：在未赢得现有细分市场前就分散资源进入新市场。
• 缺乏热情或持久力：未在创业前深思熟虑自己的使命、热情与抗压能力。

4. 如何应用此理念

文章最后指出，存在一套降低风险、系统避免失误的创业方法论（作者提及其《产品/市场契合路线图》）。虽然无法保证百分百成功（就像下棋仍需后续技巧），但通过框架性地避免这些可预防的失误，能够将80%的胜算掌握在自己手中。核心是：寻求真相，面对真相，并基于真相行动。

（文章附录还汇总了CB Insights、Paul Graham等多位专家总结的创业失败原因清单，作为“可预防失误”论点的补充支持。）

a16z的博客内容被批评为对投资组合公司进行美化营销，而非客观行业分析。其关于LLM应用新兴架构的文章虽具信息量，但在关键部分存在明显偏颇：

1. 向量数据库部分未提及Milvus/Zilliz
   尽管Milvus在早期a16z文章中出现，且同一生态项目GPTCache被列出，但本次重点介绍Pinecone（a16z投资公司）。评论者指出，这暗示Vespa、Weaviate等竞争者缺乏长期竞争力，而实际上向量数据库并非零和博弈。

2. 其他领域存在类似偏向

   • 数据管道部分仅列Databricks（a16z投资），忽略有成熟集成的Snowflake。
   • 现代交易架构中仅提Fivetran（a16z投资）与Airbyte，掩盖其他主流连接器。
   • 加密领域曾投票反对LayerZero的竞争对手Wormhole。

3. 文章推荐替代性行业分析资源
   作者建议参考更全面的指南，如Matt Turck的MAD Landscape、Sequoia Capital的LLM架构分析、Unusual Ventures的AI原生基础设施展望及专注于向量数据库的专题图。

4. 结论：内容营销与中立分析的界限模糊
   虽然认可a16z在孵化企业方面的贡献，但指出其博客以“中立行业分析”为名推广投资组合公司的做法有失公允，类似搜索引擎未标注广告的付费结果。

HeyForm：面向小型企业的开源在线表单构建工具

核心介绍

HeyForm 是一款专为小型企业设计的开源在线表单构建工具，旨在简化对话式表单的创建过程，帮助用户通过引人入胜的调查问卷、测验和投票来高效收集信息或反馈。该项目承诺持续更新，包括修复错误、新增功能和性能优化。

主要功能特性

• 轻松构建表单

  • 多样化的输入类型：支持从基础的文本、电子邮件、电话字段到高级的图片选择、日期选择器、文件上传等多种输入方式。
  • 智能逻辑：支持条件逻辑和URL重定向，创建动态且适应性强的表单。
  • 强大的集成能力：可与Webhooks、分析工具、营销平台以及Zapier、Make.com等工具连接。

• 品牌个性化定制

  • 视觉主题：通过可自定义的字体、颜色、背景等选项，使表单外观与品牌标识保持一致。
  • 高级主题设置：提供更深度的控制选项，包括自定义CSS，实现更精细的个性化。

• 数据分析与行动

  • 深度分析：提供详细的分析数据，如放弃率和完成率，帮助获取洞察。
  • 数据导出：可轻松将表单结果导出为CSV格式，便于进一步分析或集成到其他系统中。

使用方式

• 官方托管服务（推荐）：这是最简单高效的使用方式。选择云版本可享受高可靠性、自动备份、强大安全性和免维护服务，所有这些均由HeyForm团队负责管理。使用官方托管版本不仅能节省大量时间和资源，同时也支持了HeyForm的开发与开源社区。
• 自托管：用户也可以根据提供的自托管安装指南，将HeyForm部署在自己的服务器上。项目提供了一键部署和本地开发两种自托管路径。

项目结构

HeyForm采用模块化的Monorepo结构，主要包含以下包：

• answer-utils：用于服务器和Web应用的表单提交工具。
• embed：表单嵌入的JavaScript库。
• form-renderer：表单渲染库。
• shared-types-enums：服务器和Web应用共享的类型和枚举。
• utils：通用工具库。
• server：Node.js服务器端应用。
• webapp：React Web应用程序。

社区与贡献

项目鼓励社区参与。用户可以通过帮助中心获取资源，或在遇到问题时通过Discord服务器寻求即时帮助。发现错误可提交至GitHub Issues。项目欢迎任何形式的贡献，并提供了详细的贡献指南。

许可证

HeyForm遵循 GNU Affero通用公共许可证 v3.0 开源。用户需遵守该许可证的相关规定。

Tonal.js 音乐理论库总结

Tonal.js 是一个用于处理音乐调性元素（音符、音程、和弦、音阶、调式、调性）的功能性 JavaScript/TypeScript 音乐理论库。它仅处理抽象概念，不涉及实际音频或音乐生成。

核心特点

1. 纯函数式风格：所有函数均为纯函数，无数据突变，使用数据结构而非对象表示实体。
2. 模块化：以一系列 npm 包（@tonaljs/*）的形式发布，支持按需引入以减小打包体积。
3. 功能丰富：提供音符转换（如转MIDI值、频率、升降号）、音程计算、和弦与音阶的构建与转位、调性分析等功能。
4. 示例：
   • Note.midi("C4") 返回 60。
   • Scale.get("C major").notes 返回 ["C", "D", "E", "F", "G", "A", "B"]。
   • Chord.get("Cmaj7").name 返回 "C major seventh"。

安装与使用

• 安装：可通过npm一次性安装所有包，或按需单独安装以优化体积（如 @tonaljs/note）。
• 兼容性：支持 ES6 import、ES5 require 以及浏览器环境（可通过CDN引入）。

主要模块分类

• 音符与音程：@tonaljs/note, @tonaljs/interval, @tonaljs/midi 等。
• 音阶与和弦：@tonaljs/scale, @tonaljs/chord, @tonaljs/chord-type, @tonaljs/pcset 等。
• 声部排列：@tonaljs/voicing, @tonaljs/voice-leading 等。
• 调性与进行：@tonaljs/key, @tonaljs/mode, @tonaljs/progression, @tonaljs/roman-numeral。
• 节拍与节奏：@tonaljs/rhythm-pattern, @tonaljs/time-signature, @tonaljs/duration-value。
• 实用工具：@tonaljs/core, @tonaljs/collection, @tonaljs/range。

贡献、灵感与项目

• 贡献：鼓励提交 PR，需确保理论依据可靠、提供文档并包含测试。
• 灵感：借鉴了 Teoria、Impro-Visor、Music21、python-mingus 等其他音乐理论库。
• 使用项目：列出了众多使用 Tonal.js 的知名音乐 Web 应用与工具，如 Solfej、EarBeater、Chordify、React Guitar 等。

该库基于 MIT 许可证发布。

OneUptime：开源的综合可观测性平台

OneUptime 是一个全面、开源的在线服务监控与管理平台，旨在替代多种商业监控工具，提供从监控到事故处理的完整解决方案。其核心目标是减少服务停机时间，并帮助用户理解故障原因、有效管理事件。

核心功能

OneUptime 集成了通常需要多个独立工具才能实现的功能，主要包括：

• 正常运行时间监控：从全球多个位置监控网站和API的可用性及响应时间，并通过多种渠道（如邮件、短信、Slack）发送告警。
• 状态页面：创建可自定义品牌的状态页面，用于在停机或维护期间与客户和利益相关者沟通。
• 事件管理：提供从事件创建、分配到解决的完整协作工作流，支持事件报告和文档记录。
• 值班与警报：管理团队的值班排班和升级策略，确保在事件发生时正确的人能及时收到通知。
• 日志管理：收集、存储和分析服务日志，支持搜索、过滤和可视化以进行问题排查。
• 应用性能监控：跟踪应用的关键性能指标，如追踪、响应时间、吞吐量和错误率。
• 错误跟踪：检测并诊断服务中的错误，提供详细的错误报告。
• 工作流自动化：可与Slack、Jira、GitHub等5000多个应用集成，实现工作流自动化。
• AI协作者：一个AI代理，可24/7监控服务、在日志、追踪和指标中检测异常、识别根本原因，并能自动生成包含代码修复的拉取请求。

能够替代的工具

OneUptime 旨在成为一个统一平台，替代以下常见的独立服务：

• Pingdom（正常运行时间监控）
• StatusPage.io（状态页面）
• PagerDuty（值班与告警）
• Incident.io（事件管理）
• Loggly（日志管理）
• New Relic / Datadog（应用性能监控）
• Sentry（错误跟踪）

版本与部署

OneUptime 提供两种版本：

1. 社区版：完全开源，包含所有功能，适合自托管和小型团队。
2. 企业版：面向有合规要求的团队，提供加固镜像、优先支持、定制功能和数据驻留选项。

部署方式：

• OneUptime云（推荐）：无需安装和维护，注册即可免费使用。
• 自托管安装：支持使用 Kubernetes (Helm) 进行生产环境部署，也提供 Docker Compose 和本地开发等安装选项。

许可与支持

该项目基于 Apache License 2.0 许可证开源。社区可以通过提交反馈、贡献代码、参与讨论以及赞助项目等方式支持其发展。

禁止开放权重模型将是一场灾难

文章核心论点是反对美国商务部考虑限制或禁止公开分发的开放权重AI模型（如LLaMa、Stable Diffusion、Mixtral），认为此举将是一个严重错误。

开放模型的核心价值

• 促进创新与竞争：开放模型降低了准入门槛，使中小企业、学术机构和初创公司能够利用前沿AI技术开发应用，促进经济增长。与封闭的DALL-E相比，开放的Stable Diffusion催生了更多社区驱动的集成与创新。
• 增强安全与透明度：开放模型允许研究人员、安全专家和公众审查其内部运作，有助于发现偏见、后门或漏洞，从而建立信任。封闭模型则缺乏这种透明度。
• 平衡力量与国家安全：先进的AI技术不可避免地会被国家行为体和大型企业掌握。开放模型使安全研究人员和公民社会能够开发防御性AI工具来对抗恶意使用（如虚假信息运动、网络攻击），为民主力量提供应对手段。
• 推动公平与可及性：开放模型可以被重新训练以服务于公益事业（如医疗分析、社会研究），避免AI技术被少数营利性实体垄断，从而减少不平等。

禁止开放模型的危害

• 损害国家竞争力与安全：限制开放模型会使美国在AI领域落后于采取更开放政策的国家，并削弱其应对AI威胁的能力。
• 阻碍创新与经济增长：高昂的模型训练成本将导致市场寡头垄断，提高使用成本，限制广泛应用。
• 无法根除滥用，反而加剧风险：禁令只能限制守法实体，而犯罪组织和国家行为体总有资源获取技术。这只会将社会置于更大的系统性风险中，而非保护个人免受所有伤害。

对监管的建议

• 明确监管焦点：应惩罚滥用AI的行为，而非禁止技术本身。法律应针对使用层面（如生成诽谤性图像、欺诈），而非分发层面。
• 正视技术现实：模型权重的公开与否是二元状态。一旦公开，任何技术限制都极易被绕过。依赖许可证协议是可行的规范方式，但无法技术上强制执行。
• 支持开放生态：美国政府应鼓励和支持开放模型的发展，将其视为国家竞争力和安全的战略资产，而非威胁。
• 国际合作：与盟友协调监管，避免因政策宽松度差异导致漏洞；同时与竞争对手开展对话与合作，共同应对AI安全挑战。

总结而言，文章主张，一个拥有开放模型的世界虽然可能增加个体层面的某些风险，但能显著降低社会层面的生存性威胁，并为创新、竞争和民主防御提供关键基础。

本文作者分享了逆向工程并绕过《霍格沃茨之遗》中Denuvo DRM的个人技术研究经历。研究动机源于他人的质疑，并非出于破解目的，而是纯粹的技术探索。

Denuvo工作原理
Denuvo通过收集软硬件特征生成硬件“指纹”，与证明游戏所有权的Steam票据一起发送至服务器验证。验证成功后生成绑定特定指纹的Denuvo令牌，游戏运行需使用该令牌进行解密和运行时硬件匹配校验。

逆向工程方法
作者的目标是识别游戏用于生成指纹的所有硬件特征并修改相关检测。他使用Qiling逆向工程框架模拟二进制程序并分析特征收集过程，但该框架存在缺陷且需要大量自定义脚本。通过伪造或修改特征并测试令牌有效性，作者花费约5个月发现了所有指纹特征。逆向过程中还利用了自建的虚拟机管理器来辅助安装钩子。

绕过挑战与技术发现

• 非线性栈使用：Denuvo会破坏传统的线性栈操作，导致使用硬件断点等技术时可能因覆盖数据而崩溃。作者通过编写专用调试器接收断点异常，避免其直接干扰游戏栈，从而解决了该问题。
• 钩子与补丁：为了使令牌能在另一台电脑上使用，作者实施了约2000个钩子和补丁，成功使游戏在另一台机器上启动至开始界面，但运行时仍会崩溃，需进一步修补所有运行时检查。
• 性能影响分析：作者通过记录Denuvo检查触发频率来评估性能开销。日志显示检查仅每几秒发生一次，且主要集中在场景切换或加载时。作者认为其检查频率很低，不太可能导致显著性能损失，并指出Denuvo的集成程度优于其他DRM。

结论
作者认为Denuvo是强大的保护技术，虽然绕过过程极具挑战，但其运行时检查并不频繁，性能影响可能被高估。尽管Denuvo可以采用更复杂的策略来增加逆向难度，但作者认为其在游戏中的集成是良好的。最终，作者强调研究纯属技术兴趣，并对完成此项技术挑战感到满意。

文章探讨了JSON数字的确切定义及其在实际实现中的差异。JSON数字的标准定义（根据ECMA-404和RFC 8259）语法上允许任意长度和精度的数字序列，但RFC 8259为保证互操作性，建议其范围和精度不超过IEEE 754双精度浮点数。RFC 7493（I-JSON）则将此建议提升为规范性要求。

文章通过测试多种编程语言（JavaScript、C#、Python、Java、Go、Rust）的默认JSON解析/序列化行为，揭示了实际实现的巨大差异：

• JavaScript：所有数字均视为Number类型（即双精度浮点数），超出范围会损失精度。
• Python 3.8：整数在一定范围内可无损往返，小数与指数则按双精度处理。
• C# (.NET 8)：可尝试解析为int16、int64、decimal，提供一定精度保护。
• Java (Jackson)：支持解析为BigDecimal，可处理任意精度。
• Go：默认解析为float64；若已知数据结构，可映射到特定整数类型。
• Rust (serde)：默认按i64/u64或f64解析，可配置以实现任意精度。

在OpenAPI上下文中，JSON Schema和OpenAPI规范将number定义为任意精度十进制，integer定义为无小数或指数部分的JSON数字。然而，OpenAPI代码生成器的实际行为常与规范不符：

• number常被映射为float32（如Go）或特定浮点类型。
• integer通常被映射为int32，即使规范允许任意范围。
• 部分格式（如decimal、decimal128、double-int）支持有限，易导致精度损失或错误。

基于以上发现，文章总结：

1. 标准层面：JSON数字可表示任意精度数字。
2. 互操作性层面：为确保广泛兼容，应限制在双精度范围内。
3. 实践层面：各语言实现差异显著，需注意精度损失风险。
4. API设计建议：
   • 在OpenAPI中应始终为number和integer指定明确的format（如int32、int64、double）。
   • 避免使用不普及的格式（如decimal、decimal128、double-int）。
   • 若API包含JavaScript客户端，应避免直接使用int64，建议将其编码为字符串。
   • 序列化时应保留数字字面量格式（如10.0不应变为10）。

文章主题：关于IBus软件发布包与Git仓库存在无法解释差异的报告

在xz项目事件引发开源软件供应链安全担忧后，安全研究员Jan Engelhardt在oss-security邮件列表中披露了ibus（输入法框架）项目中类似的问题，即官方发布的源代码压缩包（tarball）与Git仓库中的源代码存在无法解释的差异。

核心问题

• 对象：ibus项目的1.5.29-rc2版本。
• 现象：从GitHub Releases下载的官方压缩包 ibus-1.5.29-rc2.tar.gz 与对应Git标签 1.5.29-rc2 的代码仓库进行对比（忽略构建系统生成文件后），存在多处无法解释的差异。
• 性质：Git仓库中的代码似乎比压缩包中的“更旧”（包含如“beta3”等旧标识），同时压缩包中包含一些不完整或过时的修改。

具体差异示例（基于邮件中的diff输出）

1. 版本信息不一致：
   • engine/simple.xml.in 文件中，Git仓库版本为 1.5.29-beta3，而压缩包中为 1.5.29-rc2。
2. 翻译文件元数据不一致：
   • po/de.po（德语翻译文件）中，POT创建日期不同（Git为2023-08-02，压缩包为2023-11-09）。
3. 源代码文件差异：
   • src/ibusunicodegen.h 文件存在显著差异：
     • 版权年份：Git仓库为 2018-2023，压缩包为更旧的 2018-2021。
     • 内容：Git仓库版本包含了一个 CJK Unified Ideographs Extension I 相关的字符串，而压缩包版本没有（但压缩包文件本身似乎缺少了这个提交，属于不完整的cherry-pick）。

结论与呼吁

• 发现者将此类问题与xz事件相联系，认为这属于同类别的“可疑压缩包”问题。
• 虽然目前未发现恶意后门，但这种构建产物（发布包）与源代码不一致的现象破坏了供应链的透明性和可验证性，构成了潜在的安全隐患。
• 此报告旨在提高开源社区对发布流程完整性的关注，强调从源码仓库到最终分发包之间确保可审计性的重要性。

背景与资源

• 邮件列表后附有指向开源软件安全Wiki及邮件列表使用指南的链接，作为安全讨论的补充资源。

Debian Git Monorepo 摘要

概述
Lars Wirzenius咨询公司创建了一个包含Debian 12（bookworm）主组件全部源代码的Git仓库，采用单体代码库（monorepo）形式，将所有源代码作为单个提交存储。

基本操作与现状

• 仓库地址：https://monorepo.liw.fi/git/debian。
• 克隆需谨慎：预计耗时数小时，占用约500 GiB磁盘空间，包含约1500万文件（.git目录外）。
• 当前为只读仓库，需迁移至Debian基础设施后方可用于协作。

单体仓库的优势

1. 简化协作：所有软件包使用统一流程和工具。
2. 简化迁移：所有更改可在单个分支中原子化合并。
3. 支持全面性更改：便于跨多包修改（如历史中的/usr/doc迁移）。
4. 变更追踪更清晰：发布说明可记录更详细的变更。
5. 更好的非自由软件管理：可通过git filter-branch移除非自由代码。
6. 质量控制提升：合并前需通过CI测试（使用Rust的bors工具），减少不稳定分支的问题。
7. 开发速度加快：减少维护不稳定版本的时间，可能促进企业资助开发。

未来与资源

• 传统.dsc格式可能被废弃，改用单体仓库副本。
• 大公司（如苹果、微软）有望捐赠硬件和云资源支持该仓库。

实现细节

• 使用unpack-debian-sources程序（Radicle网络），在家庭计算机上运行约7小时。
• 创建仓库命令：git init . → git add -v .（约3.5小时）→ git commit（约2.5小时），需16 GiB内存。
• 提交信息：Debian 12 main（哈希：8ae3129b9f222534d6ed20dd0489fb8f2f1d1a97）。

免责声明（关键说明）

• 本文为愚人节玩笑，Debian不会采用单体仓库模式。
• 作者自2018年起已非Debian成员，不代表Debian官方。
• 单体仓库真实存在，但计划在4月底删除。
• 真实动机为测试Git在大规模仓库下的处理能力（2024年已可支持）。

XZ开源项目攻击事件时间线

事件概述

2021年底至2024年3月，一名化名“Jia Tan”的攻击者通过长期、有计划的社会工程和技术渗透，最终在被广泛使用的XZ压缩库中植入后门。该后门被设计为针对特定Linux发行版（如Debian、Ubuntu、Fedora）中修补过的OpenSSH sshd服务，可实现未认证的远程代码执行。事件于2024年3月29日被公开披露，被认为是开源软件供应链遭受的首次重大攻击。

详细时间线

第一阶段：潜伏与渗透（2021年10月 - 2022年）

• 2021年10月起：攻击者“Jia Tan”开始向XZ开发邮件列表提交看似无害的代码补丁。
• 2022年4月起：其他身份可疑的账户（如“Jigar Kumar”、“Dennis Ens”）开始通过邮件施压，抱怨项目维护速度慢，暗示需要更换维护者。
• 2022年5月：原维护者Lasse Collin公开承认因精力有限，考虑让Jia Tan承担更大角色。
• 2022年6月：在持续的压力下，Lasse Collin表示Jia Tan“实际上已经是共同维护者”。
• 2022年底：Jia Tan被加入项目组织，并开始在代码库中直接提交更改，正式获得提交权限。

第二阶段：掌权与准备（2023年）

• 2023年3月：Jia Tan发布了其第一个版本（v5.4.2）。
• 2023年6月：一个关键的技术更改被合并：引入了“GNU indirect function”以动态选择快速的CRC函数。这为后门注入提供了技术接口。此更改的贡献者“Hans Jansen”在此后长时间内再无其他网络活动。
• 2023年下半年：Jia Tan继续巩固控制权，包括管理漏洞扫描（oss-fuzz）配置。

第三阶段：攻击实施与扩大（2024年2月 - 3月）

• 2024年2月23日：Jia Tan将隐藏的恶意二进制代码注入到二进制测试文件中。
• 2024年2月24日：发布包含后门的v5.6.0版本。恶意脚本build-to-host.m4被嵌入分发包，但不在源代码库中，用于在打包过程中注入后门。
• 2024年2月底至3月初：
  • 后门代码开始导致Gentoo、RedHat等系统出现崩溃和错误（如Valgrind报错）。
  • 与此同时，一个旨在移除liblzma依赖的Pull Request被提交，这可能会破坏攻击路径。攻击者可能因此加快了节奏。
• 2024年3月8日-9日：Jia Tan提交了所谓的“修复”，实际上更新了后门文件以掩盖踪迹，并发布了v5.6.1版本。
• 2024年3月下旬：
  • 早先的施压账户“Hans Jansen”重现，在Debian bug报告中要求更新到5.6.1版本。
  • 攻击者积极游说，促使Debian、Ubuntu等将含有后门的版本引入其软件库。

第四阶段：发现与响应（2024年3月28日起）

• 2024年3月28日：微软工程师Andres Freund在调查SSH性能问题时，意外发现了XZ后门，并私下通知了Debian和安全邮件列表。
• RedHat 为漏洞分配了CVE-2024-3094。
• Debian、Arch Linux、Fedora等 迅速采取行动，回滚至安全版本，中断构建流程，并开始评估影响。
• 2024年3月29日：事件被公开披露。

攻击手法特点

1. 长期社会工程：攻击者花费超过两年时间，通过持续贡献建立信任和声誉。
2. 协同施压：利用多个虚假账户制造“社区”对现有维护者的不满，为其上位制造舆论。
3. 技术隐蔽性：后门被巧妙地隐藏在测试二进制文件和构建脚本中，利用了项目已有的惯例，规避了常规代码审查。
4. 利用项目特性：后门的实现依赖于之前合并的、看似合理的性能优化（ifunc特性）。

影响与后果

• 该事件是开源软件供应链安全的一个警示，暴露了高度依赖关键但维护资源不足的项目所带来的系统性风险。
• 由于发现及时，后门未能在绝大多数生产环境中广泛激活，避免了可能的大规模安全灾难。
• 事件引发了开源社区对项目治理、代码审查流程以及维护者信任验证机制的深刻反思和讨论。

为Apple Vision Pro重现飞行烤面包机屏保

项目背景

• 开发者利用工作间隙的两周时间为Apple Vision Pro (AVP) 开发应用，旨在探索其潜力并学习新技能。
• 受到1989年经典"After Dark"屏保中"飞行烤面包机"动画的启发，决定将其移植到新平台。
• 结合现代代码生成工具，体验2024年的应用开发演变。

屏保概念与触发机制

• 历史上屏保用于防止CRT显示器烧屏，如今主要起美观和娱乐作用。
• 计划在AVP上实现基于用户不活动的触发机制：原想利用视线追踪，但因隐私限制无法实现。
• 替代方案：用户通过定期点击应用内的控制按钮重置不活动计时器，可自定义超时时间，将屏保转化为休息提醒。

屏保功能与特点

• 核心动画：飞行烤面包机在现实环境中翱翔，从显示太阳的门户出现，消失于显示月亮的门户。
• 交互功能：
  • 手势控制：可缩放和旋转门户。
  • 点击烤面包机会触发趣味短语，偶尔会出现小烤面包机。
  • 自定义选项：调整烤面包机数量、烘烤程度、颜色、音乐，以及启用"幽灵模式"避免碰撞混乱。

技术挑战与解决方案

1. 学习Swift：尽管熟悉Objective-C，仍通过教程和Swift Playgrounds学习Swift，并借助AI工具辅助调试。
2. 3D动画与艺术：从零开始学习3D动画，使用现有模型并自行制作烘烤纹理，经多次尝试使用Photoshop生成填充功能实现。
3. 门户手势：基于Apple示例代码实现直觉式缩放和旋转手势。
4. 物理与动画协调：RealityKit的物理引擎与严格动画路径不兼容，通过随机起点、贝塞尔曲线路径和阻尼系数模拟混沌运动，并提供幽灵模式选项。
5. 头部追踪：为使对话气泡始终面向用户，适配ARKit方法实现RealityKit未直接支持的头部位置追踪。

未来展望

• 项目开发过程充满乐趣，开发者期待用户反馈以持续改进。
• 如经典屏保曾历经十年演变，若获得足够兴趣，将进一步优化体验。
• 应用已在App Store上架，用户可查看预览和截图。

总结：该文章记述了开发者为Apple Vision Pro重新创建经典飞行烤面包机屏保的过程，涵盖项目灵感、现代屏保概念调整、具体功能实现、克服的技术挑战以及对未来的展望，展现了从创意到实践的完整开发历程。

RAGFlow 开源RAG引擎摘要

项目定义

RAGFlow 是一个领先的开源检索增强生成引擎，融合了前沿 RAG 与 Agent 能力，旨在为大语言模型构建卓越的上下文层。它通过统一的上下文引擎和预置的 Agent 模板，帮助开发者高效地将复杂数据转化为高保真、可投产的 AI 系统。

核心特性

• 质量进，质量出：基于深度文档理解，从格式复杂的非结构化数据中提取知识，可在海量 token 中精准检索。
• 模板化分块：提供智能、可解释的模板化文档分块方案。
• 可追溯的引用，减少幻觉：支持文本分块可视化及人工干预，提供关键参考文献的快速查看与可追溯的引用，确保答案有据可依。
• 支持异构数据源：兼容 Word、PPT、Excel、TXT、图片、扫描件、结构化数据、网页等多种格式。
• 自动化 RAG 工作流：提供简洁的 RAG 编排流程，适配个人及大型企业；支持配置 LLM 和嵌入模型、多路召回与重排序融合，并提供直观的 API 便于集成。

系统部署与配置

部署前提

• 硬件：CPU ≥ 4 核，内存 ≥ 16 GB，磁盘 ≥ 50 GB。
• 软件：Docker ≥ 24.0.0，Docker Compose ≥ v2.26.1，Python ≥ 3.13。若需使用代码执行器（沙箱）功能，需安装 gVisor。
• 注意：所有 Docker 镜像均构建于 x86 平台，ARM64 用户需自行构建。

部署步骤概要

1. 系统设置：确保 vm.max_map_count 值 ≥ 262144。
2. 克隆仓库：git clone https://github.com/infiniflow/ragflow.git。
3. 启动服务：进入 ragflow/docker 目录，使用 docker compose -f docker-compose.yml up -d 命令启动。可使用 GPU 加速文档处理任务。启动后通过 docker logs 检查状态，成功启动将显示特定标志。
4. 访问与配置：通过浏览器访问服务器 IP 登录。需在 service_conf.yaml.template 中配置所需的 LLM 厂商及 API 密钥。

主要配置文件

• .env：系统基础设置，如端口、数据库密码等。
• service_conf.yaml.template：后端服务配置，支持环境变量动态填充。
• docker-compose.yml：服务编排文件，可更改 HTTP 服务端口。

文档引擎切换

默认使用 Elasticsearch 存储全文和向量。可切换至 Infinity，需停止容器、修改 .env 中的 DOC_ENGINE 为 infinity 后重启（注意 ARM64 暂未官方支持 Infinity）。

构建与开发

• 构建镜像：可使用提供的 Dockerfile 构建约 2GB 的镜像，依赖外部 LLM 和嵌入服务。
• 从源码启动（开发模式）：
  1. 安装 uv 和 pre-commit。
  2. 克隆代码并安装 Python 依赖 (uv sync)。
  3. 使用 Docker Compose 启动依赖服务（MinIO, Elasticsearch, Redis, MySQL）。
  4. 配置 hosts 文件、设置 HuggingFace 镜像（可选）、安装 jemalloc（可选）。
  5. 分别启动后端和前端服务。

最新动态

项目持续更新，近期重要版本更新包括：

• 2026-04-24：支持 DeepSeek v4。
• 2025-12-26：为 AI Agent 支持 “记忆” 功能。
• 2025-11-19：支持 Gemini 3 Pro。
• 2025-10-23：支持使用 MinerU 和 Docling 进行文档解析。
• 2025-08-08：支持 OpenAI GPT-5 系列模型。
• 2025-08-01：支持 Agentic 工作流和 MCP。

资源与社区

• 文档：提供快速入门、配置指南、版本说明、用户/开发者指南、API 参考及常见问题解答。
• 社区：通过 Discord、X 和 GitHub Discussions 进行交流。
• 贡献：欢迎社区贡献，需遵循贡献指南。

文章摘要：XZ存储库维护者Lasse Collin在LKML上的回应

主题：网站管理员使用名为Anubis的系统保护服务器，防止AI公司的大量网页抓取行为。

背景：

• 服务器因受到AI公司激进的网页抓取而受到影响，导致网站宕机，资源无法访问。

Anubis系统：

• 定义：Anubis是一种基于工作量证明（Proof-of-Work） 机制的防护系统，类似于Hashcash（一种为减少垃圾邮件而设计的方案）。
• 原理：对个人用户而言，额外的计算负载可忽略不计；但对于大规模爬虫，累积成本会显著增加，使得抓取行为变得昂贵。
• 目的：作为临时解决方案，为开发更先进的浏览器指纹识别技术（例如通过字体渲染方式检测无头浏览器）争取时间。最终目标是避免向合法用户展示挑战页面。

注意事项：

• Anubis依赖现代JavaScript功能，而像JShelter这类插件会禁用相关特性。用户需禁用JShelter或其他类似插件以确保系统正常运行。

核心意义：

• 该方案旨在在保护网站资源的同时，减少对正常用户的影响，体现了在网络安全与可访问性之间的权衡。

OpenAI 宣布：ChatGPT 现可免注册即时使用

OpenAI 旨在让 ChatGPT 等工具广泛可及，以使人们体验人工智能的益处。目前，全球 185 个国家有超过一亿用户每周使用 ChatGPT 来学习新知识、获取创作灵感和解答疑问。即日起，用户无需注册即可直接使用 ChatGPT，该功能正在逐步推出，目标是让任何对 AI 能力感到好奇的人都能轻松访问。

为提升此次体验的安全性，OpenAI 已引入额外的内容保障措施，例如在更广泛的类别中屏蔽特定的提示和生成内容。

虽然免注册使用降低了门槛，但创建账户仍有诸多好处，包括：

• 保存和查阅聊天历史
• 分享对话内容
• 解锁高级功能，如语音对话和自定义指令等

对于那些一直对 AI 潜力感兴趣但不愿经历注册流程的用户，现在可以立即开始使用 ChatGPT。