OpenAI O3在ARC-AGI-公开测试中取得突破性高分

核心成果

OpenAI的新系统O3在ARC-AGI-1的公开排行榜上取得了重大突破：

• 高效率模式（计算限制在1万美元内）：在半私有评估集（100个任务）上获得75.7% 的得分，位列公开排行榜第一。
• 低效率模式（计算量为高效率模式的172倍）：在同一评估集上得分高达87.5%。

在400个任务的公开评估集上，高效率模式得分为82.8%，低效率模式得分为91.5%。

重大意义与背景

• 这是一个阶跃式的AI能力提升，展示了前所未有的新任务适应能力。
• 作为对比，从2020年GPT-3的0%到2024年GPT-4o的5%，ARC-AGI-1基准测试的成绩增长缓慢。O3的得分标志着质的飞跃，所有关于AI能力的直觉都需要更新。

性能与成本分析

测试揭示了性能与计算成本之间的权衡：

• 高效率模式成本相对可控（半私有评估约2680美元），符合公开排行榜规则。
• 低效率模式成本极为高昂（半私有评估约45.6万美元），但证明了增加计算量能提升新任务表现。
• 与人类解决相同任务的成本（约5美元/任务）相比，O3目前的成本（高效率模式约26-27美元/任务）仍然很高，但预计未来将快速下降。

技术突破与原理

O3的突破在于解决了传统大语言模型（LLM）的根本局限：

• 传统LLM擅长“记忆-检索-应用”模式，但在适应新任务方面能力有限。
• O3的核心机制被认为是测试时的自然语言程序搜索与执行。它能在处理新任务时，动态地搜索并组合知识，生成解决问题的“思维链”（Chain of Thought）程序。这类似于AlphaZero的蒙特卡洛树搜索，但搜索空间是自然语言描述的步骤。
• 这种深度学习引导的程序搜索范式，使得模型能够适应从未见过的任务，是架构上的重大创新，而非简单通过扩大数据和模型规模就能实现。

关键局限性

• 这还不是通用人工智能（AGI）：ARC-AGI并非AGI的终极测试。O3仍然会在一些对人类而言非常简单的任务上失败，表明其与人类智能存在根本差异。
• 即将面临新挑战：计划于2025年推出的ARC-AGI-2基准测试（格式相同但更难）的早期测试表明，即使是O3，其得分也可能低于30%，而人类仍能轻松达到95%以上。
• 技术细节待明：其具体的搜索和评估机制、扩展性的具体瓶颈，仍需进一步研究。

未来展望

1. 开源复现：2025年ARC Prize竞赛将推动O3的开源复现，这对研究社区至关重要。
2. 新基准开发：ARC-AGI-1正在趋于饱和。ARC-AGI-2将致力于设定更高的标准，推动AGI研究边界。第三代基准测试也已开始构思。
3. 社区参与：OpenAI和ARC Prize基金会公开了部分测试数据（包括O3未能解决的人类易解任务），邀请社区分析其特征、难点，并设计更难的新任务。

总结

OpenAI O3在ARC-AGI测试中的表现代表了AI适应性和泛化能力的真实突破。它通过测试时的程序搜索解决了LLM无法在推理时重组知识的核心缺陷，开辟了AI发展的新领域。尽管成本高昂且尚未达到AGI，但其展现的能力表明，具备类似人类适应性的AI能力有望在短期内变得具有经济竞争力。

FindMy.py 项目摘要

这是一个旨在简化通过Python查询苹果"Find My"网络位置信息的开源库。它整合了分散在各处的代码，提供了一个统一的解决方案。

核心功能与特性：

• 跨平台支持：无需Mac电脑即可使用。
• 设备兼容性：支持查询官方配件（AirTag、iDevice等）以及基于OpenHaystack的自制标签的位置报告。
• 账户认证：支持通过Apple账户登录，并兼容短信（SMS）和受信任设备两种双因素认证（2FA）方式。
• 设备扫描：能够扫描附近的FindMy设备，并解码其公共密钥、状态字节等信息。
• 密钥管理：支持导入或创建自定义配件密钥。
• API模式：同时提供异步（async）和同步（sync）的API接口。

安装与使用： 该库可通过Python包管理器PyPi安装。项目提供了使用示例和命令行工具（CLI）的初步支持。完整的文档也已提供。

项目贡献与规范： 项目欢迎代码贡献，并建议在开发新功能前先开issue讨论。项目使用Ruff进行代码检查和格式化，并配置了pre-commit钩子以自动化执行这些检查。

致谢： 项目的核心功能建立在多个其他开源项目和开发者的工作之上，包括OpenHaystack、Pypush、FindMy、pyprovision、anisette-v3-server以及GrandSlam SMS 2FA等。

Grayjay Desktop App 摘要

核心理念

Grayjay 桌面应用倡导 “关注创作者，而非平台” 的理念，旨在让用户以自主的方式观看内容，确保用户对观看的内容拥有完全的所有权和控制权，实现“你的内容，你的方式”。

主要特点

• 跨平台整合：打破平台壁垒，让用户能够在单一应用中关注和追踪喜爱的创作者，无需受限于特定平台。
• 内容自主权：强调用户对内容的控制，确保用户始终拥有内容访问和管理的权利，减少对平台的依赖。
• 用户体验优化：致力于提供灵活、个性化的观看体验，让用户根据自己的偏好和习惯消费内容。

用户收益

• 提升内容掌控力：用户可以更自由地管理订阅、播放列表和观看历史，避免平台算法过度干预。
• 简化内容获取：无需在多个平台间切换，集中关注创作者的作品，提高效率和便捷性。
• 增强隐私与安全：通过减少对中心化平台的依赖，可能降低数据追踪和隐私泄露的风险。

目标与愿景

Grayjay 桌面应用旨在推动内容消费模式的转变，从以平台为中心转向以用户和创作者为中心，促进更开放、去中心化的数字内容生态。

S2：面向云时代的流存储服务

核心定位

S2 是 Stream Store，旨在将日志（流）提升为云存储的基本单元。它解决了对象存储（如 S3）不适用于实时流数据的问题，为“数据在运动”提供原生支持。

与对象存储的关键区别

• 操作粒度：对象存储操作的是 字节范围（Blob），S2 操作的是 记录 和 序列号。
• 核心操作：对象存储使用 PUT/GET/DELETE；S2 使用 APPEND/READ/TRIM。
• 追加性能：对象存储进行细粒度追加代价高昂且复杂；S2 可轻松、廉价地追加记录。

核心特性与架构

1. 流式接口：
   • 写入操作追加至流尾，由 S2 保证多写者场景下的持久化序列。
   • 支持实时尾随读取和历史数据回溯（从秒到年）。
2. 命名空间：
   • Basins（流域）充当流的命名空间，类似对象存储中的桶。
   • 无流数量或数据保留期的硬性限制，适合按用户建模流。
3. 一致性与并发控制：
   • 提供强一致性尾部检查。
   • 支持悲观锁（使用 fence 令牌）和乐观锁（通过预期序列号）两种并发写入控制方式。
4. 存储与性能：
   • 完全无盘：架构基于对象存储的无限扩展性和持久性。
   • 存储类别：
     • Standard：基于 S3 Standard，p99 延迟 <500ms，具备跨云区域部署能力。
     • Express：基于 S3 Express One Zone，p99 延迟 <50ms，接近磁盘流系统性能。
   • 吞吐量：单流写入吞吐达 125 MiBps，近期数据读取吞吐达 500 MiBps。滞后读者可直接从对象存储获取数据，无上限。
   • 缓存：近期写入数据读取开销可忽略。
5. Serverless 与定价：
   • 真正的无服务器体验，无实例、集群等固定成本。
   • 预览期免费，并承诺正式定价将显著低于现有云流系统，尤其是那些流数量有限但溢价很高的“无服务器”产品。
   • 用户可基于单个流在延迟与成本间权衡选择存储类别。

当前状态与未来路线

• 当前：提供 gRPC API、Rust SDK 和 CLI，基于 Rust 构建并通过确定性模拟测试。
• 未来计划：
  1. Kafka 协议兼容：通过开源层实现，并可能将压缩等功能直接集成。
  2. 多区域 Basin：实现跨区域、跨云的流域。
  3. 延迟低于 5ms：通过进一步优化存储类别实现。

适用场景

S2 适合需要底层流 API 或对云流系统有更高要求的用户，例如：不希望受限于流数量、需要 10-100 倍更高的有序吞吐量、或需要精细并发控制。它被视为可替代 Kafka 或 Kinesis 的潜在方案，尤其在需要云原生、无限扩展和精细成本控制时。

本文研究了将C代码编译为安全Rust的自动化方法。当前将C翻译为Rust的工作往往依赖于unsafe代码，这虽然实现了自动化，却削弱了Rust的内存安全保证，违背了移植的初衷。本文提出一种新方法：由程序员逐步重构原始C代码，使其变得结构化，从而能够被编译为完全安全的Rust代码。该过程允许在现有测试和生产环境中增量评估重写带来的性能和正确性变化。

该方法基于以下技术贡献：

1. 类型导向的翻译：将C的一个子集直接翻译为安全的Rust代码。
2. 基于“分裂树”的静态分析：一种新颖的分析技术，能够使用Rust的切片和分裂操作来表达C的指针算术。
3. 可变借用推断：分析并确定哪些借用必须是可变的。
4. 指针类型编译策略：设计了一种兼容Rust对非拥有和拥有内存分配区分的C指针类型处理方案。

作者在密码学库、二进制解析器/序列化器和文件压缩库等真实项目上评估了该方法。结果表明，通过对原始C代码进行较小的重构，即可将其转换为Rust，且生成的Rust代码在性能上与原始C代码相当。此外，在翻译过程中，研究者在bzip2压缩库和微软的FrodoKEM密码学原语实现中发现了未定义行为。

工具名称： spacer

核心功能： 一个简单的命令行界面工具，用于在命令输出停止时自动插入分隔符。它解决了用户在执行持续输出命令（如 tail -f）时，需要手动按回车来标记输出间隔的痛点，使日志条目或输出块之间的分隔更加清晰。

主要特性与使用：

• 工作原理： 监控标准输出（STDOUT），当在指定的时间内没有新输出时，自动插入一个分隔符。
• 安装方式： 支持通过 Homebrew 或直接从 Cargo 安装。
• 核心用法： 通常与持续输出的命令结合使用，例如 tail -f some.log | spacer。
• 可配置性：
  • 默认触发时间为 1 秒无输出。
  • 通过 --after 标志自定义等待时间（单位为秒），支持浮点数以实现更高精度（例如 --after 0.5）。
• 重要注意事项： 该工具仅监控 STDOUT。如果被管道连接的程序主要将信息输出到标准错误（STDERR），spacer 可能不会正常工作。此时，需要将 STDERR 也重定向到 STDOUT，使用 |& 作为管道符（例如 command |& spacer）。

文章摘要：Bash 光线追踪器实现

本文介绍了一个用 Bash 语言实现的简易 3D 光线追踪器，灵感来源于 Lode 的计算机图形学教程。项目演示了在 Bash 终端中模拟《德军总部》风格的伪 3D 效果，用户可使用方向键移动，按 q 退出。

核心技术挑战

1. 性能瓶颈：Bash 执行速度极慢，若逐像素执行命令则无法达到可接受帧率，因此无法在内存中存储屏幕状态。
2. 数学限制：Bash 无浮点运算支持，所有计算均通过整数乘以 64K 缩放实现。
3. 终端显示优化：为提升垂直分辨率，使用 Unicode 半角字符配合前/背景色组合。但终端无法单独更新单元格的某一颜色，每次绘制都需查询相邻像素状态。
4. 输入延迟：大多数终端无法实时检测按键状态，通常每秒仅能接收 5-6 次输入，且不支持多键同时按下。
5. 数据吞吐量：填充终端颜色需大量数据传输（约 10MB/秒），且 Bash 的打印机制会在每行末尾添加额外字符，进一步增加数据量。

主要功能与限制

• 功能：基础伪 3D 渲染、流畅移动、并行渲染尝试、24 位色彩支持、鼠标控制原型等。
• 兼容性：需 Bash 5.2 以上版本；依赖 stty 命令调整终端设置，部分统计信息通过其他工具收集。
• 常见问题：
  • 窗口调整可能导致显示异常。
  • 高 CPU 占用可能拖慢旧设备，可降低分辨率或设置 FPS 环境变量。
  • 杀毒软件（如微软 Defender）可能严重影响性能。

未来计划

路线图包括：提升帧率、实现纹理/精灵渲染、添加敌人与粒子效果、声音支持、多人游戏模式、动态墙壁颜色与地图事件等。

项目本质是探索 Bash 作为编程语言在图形计算领域的极限，所有优化均围绕其语言特性与终端限制展开。

提供的文章内容仅为网站维护公告，显示网站暂不可用，预计很快恢复。由于未提供关于“逃避谷歌手动声誉惩罚”的具体措施、案例或策略等实质内容，无法生成相应摘要。建议补充完整文章以获取准确总结。

英国电费昂贵的原因分析

一、电费构成：批发成本仅占三分之一

英国电费账单中，电力批发市场价格仅占约三分之一。剩余三分之二由以下部分构成：

• 网络成本：支付电网线路和变电站维护费用。
• 发电成本：补贴战略性发电项目（如海上风电、家用光伏和稳定的燃气发电）。
• 其他杂费：包括公用事业公司客服运营、各类税费等。

二、费用即将大幅上涨

• 网络成本飙升：英国电网投资已停滞20年，但当前急需扩容以替代部分管道能源传输。
• 差价合约补贴增加：作为支持可再生能源的核心机制，已分配的合约超半数尚未激活，且下一轮分配预计规模更大。虽然该合约在能源危机中抑制了批发价，但长期平均会增加成本。
• 容量市场成本增长：为保障供电稳定，需支付备用发电和需求响应费用，相关成本预计到2028年将增至三倍。

三、现有成本被长期锁定

英国在2010年代推行的高额绿色补贴将持续数十年：

• 可再生能源义务：要求公用事业公司购买风电和光伏证书，2017年已停止接受新项目，但现有项目补贴将持续至2037年。该政策约占平均账单的10%，且早期获批的生产商可享受与通胀挂钩的固定电价，与市场电价脱钩。
• 上网电价补贴：为安装光伏的家庭提供高额出口电价，2019年停止新申请，但部分项目补贴可持续至2044年。该政策在光伏成本下降后未能及时调整，导致补贴成本与市场动态严重脱节。

四、未来降低电价的路径

当前网络成本已约70英镑/兆瓦时，难以实现未来50英镑/兆瓦时的目标。可行方案包括：

• 弃用电网：依赖本地太阳能和储能电池，但在光照不足的北欧地区可行性较低。
• 优化电网利用：通过平衡全天用电负荷提升电网效率，而非仅扩建电网应对峰值需求。

五、背景与反思

英国在发达经济体中实现了最快的电网脱碳速度，但早期可再生能源成本较高导致遗留成本负担。随着可再生能源成本下降，未来政策权衡将更为灵活。作者认为，尽管早期高价补贴推动了技术学习曲线，但政策需更及时响应市场变化。

文章摘要：Spotify的“虚假艺术家”问题揭露

问题发现

• 作者于2022年初注意到Spotify爵士歌单中出现大量陌生艺术家，这些艺术家许多来自瑞典（Spotify总部所在地）。
• 有报道称，大量流媒体音乐可能由仅20人使用500多个不同名字创作。
• 一个不知名瑞典爵士音乐家的播放量甚至超过格莱美年度专辑《We Are》中的曲目，引发质疑。

异常现象

• 听众发现重复曲目被冠以不同标题和艺术家名，甚至创建了包含49个版本同一曲目的歌单。
• 爵士钢琴歌单中所有曲目音色一致，但艺术家名称各异，疑似AI生成。
• 这些现象指向Spotify可能通过播放“廉价”音乐来减少支付给真实艺术家的版税。

调查揭示

• 记者Liz Pelly经过一年调查，采访前员工、获取内部文件，揭露Spotify的**“完美契合内容”计划**。
• 该计划与生产公司合作，提供Spotify可从中获益的音乐，并由员工将这些曲目植入歌单。
• 目标是增加平台总播放中成本较低音乐的占比，从而与音乐人和唱片公司对抗。

计划细节

• PFC计划主要针对氛围音乐、古典、电子、爵士和低保真节奏等适合背景收听的类型。
• 参与的音乐人常需放弃某些版税权利，这些权利在曲目流行时可能极具价值。
• 管理层曾表示“听众不会察觉差异”。

CEO获利与类比“回扣”

• Spotify CEO在2023年多次出售股票，总计获利超3.28亿美元，远超许多知名音乐人。
• 这种行为被类比为20世纪50年代的电台“回扣”丑闻，但现今操作更隐蔽且合法。

行业反思与建议

• 唱片公司曾长期支持Spotify，但作者指出Spotify实为对手，而非合作伙伴。
• 音乐媒体未能深入调查，独立记者发挥了关键作用。
• 建议国会调查流媒体平台的道德违规，推动立法要求透明化，并禁止基于经济激励推广歌曲。
• 呼吁唱片公司和音乐人共同创建合作制流媒体平台，收回音乐产业控制权。

作者自加入AWS后，开始实验并公开记录个人工作日志（CHANGELOG），认为这不仅是开源社区的最佳实践，也能在企业内部带来诸多益处。

初衷与价值 作者认为，在开源世界中，清晰的变更日志体现了维护者对用户的关怀，能提升透明度、清晰度和信任。他将此理念应用于职场，将AWS的同事、开发者和管理者视为“客户”，通过公开日志逐步建立信任。尤其在高级工程岗位上，工作范围更广、更具独立性、成果周期更长，建立信任尤为关键。

实践中的具体好处

1. 提升一对一会议效率：会议开始时，经理可先行阅读日志，快速了解作者近期工作与上下文，从而直接进入深入讨论。
2. 帮助新同事融入：作者早期的日志记录（如培训、设备设置、首次代码修改）为新工程师提供了了解入职初期真实工作的宝贵参考。
3. 成为个人知识库：日志充当了个人维基和参考索引，方便快速查找过去阅读过的文档、联系过的人或重要对话。
4. 作为内部动力与反思工具：记录工作有助于作者诚实地面对自己，通过数据分析“琐碎工作”与“实际有效工作”的比例，从而明确改进方向。

记录方法 作者的做法很简单：每周在便签上随手记录事项，然后每周一整理并发布到公司内部的Wiki页面上。他特别强调需注意保密，不记录任何敏感信息（如面试候选人姓名或客户具体信息）。

鼓励与工具 最后，作者鼓励读者也尝试建立自己的工作日志，并分享了一段简单的Ruby脚本，用于生成当年剩余所有周一的日期列表。

Rivet Actors 是一个用于构建有状态工作负载的轻量级、长时间运行的进程框架。它使用 Rust、FoundationDB 和 Isolates 构建，旨在为每个代理、会话或用户创建独立的 Actor，其状态驻留在内存中并支持自动持久化。

核心特性：

• 状态管理： 内存状态与计算共置，实现快速读写，可自动持久化到 SQLite 或自定义数据库。
• 生命周期： 活动时长期运行，空闲时休眠，可无限扩展并能缩放至零，节省成本。
• 全球化部署： 支持全球边缘网络部署，可贴近用户或满足特定司法管辖区要求。
• 内置功能： 提供 WebSocket 实时双向流、带自动重试的工作流、持久消息队列以及 Actor 内的定时和计划任务。

关键优势（与传统基础设施对比）：

• 冷启动： 约 20 毫秒（包含状态初始化），远快于 Kubernetes Pod（约 6 秒）和虚拟机（约 30 秒）。
• 资源占用： 每个实例仅约 0.6KB 内存，而 Kubernetes Pod 和虚拟机分别需要约 50MB 和约 512MB。
• 空闲成本： 缩放至零时空闲成本为 0，而传统集群和虚拟机仍有固定成本。
• 读取延迟： Actor 内状态读取延迟为 0 毫秒，而 Redis 和 PostgreSQL 分别有约 1ms 和约 5ms 的延迟。
• 扩展性： 水平扩展理论上无上限，支持多区域全球边缘网络。

应用场景： 该框架可用于 AI 代理、沙盒编排、工作流、协作文档、每租户数据库和实时聊天等多种场景，每个 Actor 可以承载一个代理、一个会话或一个用户的独立状态。

技术栈与部署： RivetKit 是一个库，可连接至 Rivet Cloud 或进行自托管。自托管只需一个 Rust 二进制文件或 Docker 容器，支持 PostgreSQL、文件系统或 FoundationDB 后端。项目是 Apache 2.0 许可的开源项目。

可观测性： 提供内置工具，包括 SQLite 查看器、工作流状态检查、事件监控和交互式 REPL，用于调试和监控。

生态系统： 提供 TypeScript、实验性的 Rust 和 Python 客户端库。引擎本身由多个组件构成：Pegboard（Actor 编排与网络）、Gasoline（持久执行引擎）、Guard（流量路由代理）、Epoxy（多区域 KV 存储）以及仪表板和网站。它支持与多种基础设施（Vercel、AWS 等）、框架（React、Next.js 等）和运行时（Node.js、Bun 等）集成。

图灵机

1936年，为回应数学家希尔伯特提出的“判定问题”（即是否存在一个通用算法能判定所有数学命题的真伪），艾伦·图灵提出了“通用机器”这一理论模型，后被命名为图灵机。图灵与阿隆佐·丘奇独立得出结论：这样的通用判定算法不存在。图灵机通过一个极其简单的模型，奠定了现代计算理论的基础。

图灵机的组成与工作原理 图灵机是一个理论计算模型，由四个核心部分构成：一条无限长的纸带（用于存储符号）、一个可读写和移动的读写头、一个记录当前状态的状态寄存器，以及一个程序（状态转换表）。其编程语言仅包含五条指令：P（打印符号）、L（左移读写头）、R（右移读写头）、↪︎（跳转至指定状态）、H（停机）。

机器根据当前状态和读写头下的符号，执行程序对应的指令。通过组合不同的状态与符号匹配，图灵机能够完成任何可计算任务。例如，它可以打印字符串（如“Alan”）、生成交替序列（0101...），或实现两个二进制整数的加法。

可计算性与二进制的优势 一个函数或问题是“可计算的”，当且仅当存在一个算法（即图灵机程序）能将输入转化为正确的输出。例如，整数加法是可计算的。文中通过一个执行二进制加法的图灵机程序演示了这一点。

在编程实践中，使用二进制比十进制更具优势，因为二进制程序更简短、更易于编写和理解。这也映射了物理现实：制造在两种状态间切换的电子元件（代表0和1）比制造十种状态的元件更廉价、可靠。

不可计算的问题：停机问题 图灵证明了存在无法通过算法解决的问题，其核心是停机问题：不存在一个程序能判定任意给定程序在给定输入下是否会最终停止。其关键在于可以构造一个“悖论”程序，该程序接收一个判定程序作为输入，并故意做出与判定结果相反的行为，从而导致逻辑矛盾。

图灵完备性 一个系统被称为图灵完备，如果它能够模拟一个图灵机。尽管严格的图灵完备需要无限内存，但在实践中，只要系统拥有足够大的有限内存，通常就认为其是图灵完备的。现代编程语言（如文中的JavaScript）以及一些令人意外的系统（如C++模板、TypeScript类型系统、Excel）都具备图灵完备性。

与现代计算机的关系 现代计算机在本质上可以被视为一个高效的、物理实现的图灵机。其关键差异在于：

1. CPU与寄存器：CPU拥有的寄存器可以看作图灵机带式格式中定义的、位于固定位置的“寄存器”，用于快速存取操作数。
2. 性能：图灵机通过在纸带上反复移动、模拟简单的加减法来完成“加法”这类基础操作，过程极其繁琐。而现代计算机使用专用电路，能在纳秒级时间内完成同样的运算。
3. 内存：现代计算机拥有可直接随机访问的内存，无需像图灵机那样通过移动纸带来定位数据。

尽管实现方式天差地别，但从理论上讲，任何现代计算机能执行的计算，包括运行网页浏览器、玩视频游戏，其底层逻辑都可以用一个足够复杂的图灵机程序来模拟。

文章最后提供了一个基于网页的图灵机模拟器开发环境，鼓励读者尝试编写自己的程序，例如尝试实现两个数的相加，以加深对这一理论模型运作方式的理解。

Collatz’s Ant 摘要

Collatz’s Ant 是基于 Langton’s Ant 的 Collatz 序列可视化。Collatz 函数定义为：

• 若 ( n \equiv 0 \ (\text{mod}, 2) )（即 n 为偶数），则 ( f(n) = n/2 )。
• 若 ( n \equiv 1 \ (\text{mod}, 2) )（即 n 为奇数），则 ( f(n) = 3n + 1 )。

在可视化中，根据 n 的奇偶性，蚂蚁行为如下：

• 如果 n 为偶数，蚂蚁顺时针旋转 90 度。
• 如果 n 为奇数，蚂蚁逆时针旋转 90 度。

之后，单元格状态被翻转，蚂蚁向前移动一个单位。这个过程重复进行，直到 ( n = 1 )。

文章还提到了代码实现和示例，包括从 ( n = 10^{30} ) 到 ( n = 10^{30} + 20 ) 的连续轨迹示例。

本文介绍了DOS中APPEND命令的作用、应用场景及工作原理。

1. 解决的实际问题
作者在整理DOS 2.11源代码时，希望将源码按目录结构组织（如将公共头文件放在inc目录）。但用于编译的旧版汇编器MASM 1.25仅支持单目录操作，无法跨目录查找文件。通过运行APPEND ..\..\INC;..\INC，MASM在当前目录找不到头文件时，能自动到指定路径查找，从而在不修改旧工具的前提下实现了文件跨目录引用。

2. APPEND的本质与工作原理

• 本质：一个TSR（内存驻留程序），通过拦截DOS中断INT 21h来扩展文件查找能力。
• 核心功能：当应用程序（使用FCB或文件句柄）打开文件失败时，APPEND会根据预设的路径列表重新尝试打开。
• 影响的DOS子功能：主要包括0Fh（FCB文件打开）、3Dh（文件句柄打开）和23h（获取文件大小）。

3. 历史与发展

• 起源：1985年首次随IBM PC Network Program 1.0发布，旨在帮助网络环境下的应用程序跨目录访问数据。
• 集成到DOS：1987年的DOS 3.3（IBM开发）正式将其纳入系统，并增强了与COMMAND.COM的集成。
• 实现：初始版本由G. G. A.编写，后由B. A. F.（Barry A. Feigenbaum）为DOS适配。

4. 重要参数与特性

• /E：将路径列表存储在APPEND环境变量中，允许不同进程拥有独立路径。
• /X：扩展挂钩更多DOS功能（如Find First和Exec），甚至可以取代PATH变量。
• 作为“内外部命令”：首次运行时作为外部程序加载为TSR；之后通过INT 2Fh/AEh接口，COMMAND.COM可将其视为内部命令直接调用。
• 编程接口：通过INT 2Fh/B7h提供控制与查询功能。

5. 总结
APPEND是一个用于扩展文件查找路径的TSR，主要解决早期DOS应用程序无法支持多目录结构的问题。它通过透明拦截文件操作请求，使旧程序能访问预设路径下的文件。尽管在现代系统中已罕见，但在特定历史场景下曾发挥重要作用。

苹果间谍软件通知机制与非营利组织Access Now的角色

苹果公司近年来通过向政府间谍软件的目标和受害者发送安全通知，警告用户设备可能被黑客攻击。通知明确告知用户：他们因身份或工作原因成为雇佣间谍软件攻击的特定目标，并建议立即采取防护措施。关键点在于，苹果并不直接为用户提供法医分析或攻击调查，而是将用户引导至非营利组织Access Now运营的数字安全热线。

这一做法在网络安全领域被广泛认可。例如，2020年美国大选前，副总统哈里斯的团队曾因两名竞选工作人员的iPhone出现异常而求助苹果，但苹果拒绝进行设备分析。专家指出，苹果的“通知-转介”模式是间谍软件问责研究的重大突破。Citizen Lab研究员John Scott-Railton强调，波兰、泰国等多起重大间谍软件案件均始于苹果的通知。

Access Now的法律顾问Natalia Krapiva表示，在苹果发送通知前，调查者常处于被动状态；通知机制使他们能系统性地识别和支援受害者。该热线由30余名工作人员运营，仅2024年就处理了4,337起求助工单。

专家共识认为，苹果避免介入个人设备调查是合理的。数字安全专家Runa Sandvik指出，大科技公司不应承担用户设备的法医鉴定工作，以保持独立性和客观性。不过，电子前沿基金会总监Eva Galperin认为苹果仍可提升行动力，例如发布更详细的威胁报告或提起诉讼，但这些举措需要大量资源。

苹果建议通知接收者立即更新iOS系统和所有应用，并启用锁定模式（Lockdown Mode）。该功能通过限制易被利用的设备特性，有效阻断间谍软件入侵。苹果称自2012年以来已向150多个国家用户发送通知，并强调未有任何启用锁定模式的设备感染间谍软件的成功案例。

安全专家强烈建议，记者、人权工作者及异见人士等高风险群体应主动启用锁定模式，并严肃对待苹果的安全通知。这一机制不仅提升了个人设备防护，也为全球间谍软件追踪提供了关键线索。

数据布局优化：Enum of Arrays (EoA)

本文介绍了数据导向设计模式中，除了常见的结构体数组 (SoA) 之外，一种对应的优化模式：枚举的数组 (EoA)，并阐述了其优势与应用。

核心概念：从 AoS 到 SoA 的回顾

• 数组的结构体 (AoS)：将不同字段聚合在一个结构体中，并创建该结构体的数组。例如，一个包含 checksum, number, flag 字段的 Thing 结构体数组。
• 结构体的数组 (SoA)：将同一个结构体的所有同类型字段分别存储在不同的数组中，再用一个结构体来包含这些数组。
• SoA 的优势：
  1. 减少内存占用：通过分摊内存对齐的填充字节。例如，在 SoA 中，所有 flag 的填充只需计算一次，而非每个结构体实例都计算。
  2. 提高内存带宽利用率：对于批量数据处理（如循环），如果处理逻辑仅需访问部分字段，SoA 布局能减少不必要的数据加载。
  3. 利于 SIMD 优化：将同一字段的数据连续存放，便于一次性对多个数据项执行相同的 SIMD 指令，充分利用 SIMD 宽度。

核心创新：枚举的数组 (EoA)

文章指出，上述优化思想同样适用于枚举类型。

• 数组的枚举 (AoE)：标准方式是创建一个枚举的数组。在底层，每个枚举实例包含一个用于标识其当前变体的 tag（如 u8）和一个 payload（实际数据，通常是一个联合体）。
• 枚举的数组 (EoA)：将这种结构“内外翻转”。具体实现为：

  const EoA = struct {
      tag: u8, // 注意：这里只有一个tag
      payload: union {
          spam: []Spam,
          eggs: []Eggs,
      }
  }
  

• 关键思想：整个批次（例如1024个元素）共享一个 tag。这意味着一个批次要么全是 spam 变体，要么全是 eggs 变体，不能是混合的。

EoA 的优势

1. 减少 Tag 总字节数：单个 tag 的开销被整个批次分摊，显著降低了存储标签的总内存。
2. 避免变体大小差异的内存浪费：无需在存储不同大小的变体时，为较小变体与较大变体之间的“间隙”浪费内存。
3. 大幅减少分支预测：tag 是控制流分支的依据。EoA 将每批次的分支决策减少到只有一次，极大减轻了 CPU 分支预测的压力，避免了不可预测分支导致的性能下降。
4. 为 SIMD 优化铺平道路：消除了频繁的分支判断后，对同质数据的批量处理变得非常适合 SIMD 指令并行化。

实际应用案例：TigerBeetle

文章以金融数据库 TigerBeetle 为例，说明了 EoA 思想的实践。

• TigerBeetle 处理两种操作：创建账户和执行转账。这两种操作本可设计为一个异构枚举。
• 实际中，TigerBeetle 采用了同质批次处理：一次性处理 8000 个转账操作，或一次性处理 8000 个账户操作。整个批次共享一个标签。
• 这实现了 数据平面与控制平面的分离：
  • 控制平面：tag，是小而低频的信息，仅用于决策。
  • 数据平面：实际的批量数据（如大量转账记录），处理时只需一次决策。

总结

文章倡导将数据布局从 Array of Enums (AoE) 优化为 Enum of Arrays (EoA)。这种结构通过为整个数据批次共享一个标签，极大地减少了内存开销和分支预测失败，同时为 SIMD 并行计算创造了条件，是提升数据密集型应用性能的有效手段。

产品概述：Stasher是一款旨在解决浏览器标签页堆积和保存内容被遗忘问题的新产品。它自动保存用户的浏览记录，并在需要时智能地提供相关链接。

核心功能与工作流程：

1. 自动保存：所有打开的内容都会被自动保存并安全存储。
2. AI智能分类：利用人工智能即时整理内容，也可根据用户偏好手动调整。
3. 情境化重新发现：根据用户当前活动，无缝地浮现相关的历史保存项目。
4. 上下文感知搜索：提供智能搜索功能，能快速访问任何所需数据。

主要优势：

• 消除管理和评估海量标签页的繁琐过程。
• 确保在最需要时不会忘记重要信息。
• 实现对所有个人数据的轻松访问。
• 将保存的项目集合从“信息坟墓”转变为“资源宝库”。