OpenAI 针对用户询问其 o1 模型思维链（chain of thought） 的行为发出了访问权限撤销的威胁。这表明 OpenAI 可能将模型的内部推理过程视为敏感或受保护的信息，不允许用户进行探查或公开讨论。此事件突显了该公司对模型运作机制的控制策略，以及在使用条款中关于技术细节查询的限制。

本文总结了作者一台运行10年的4U 71 TiB ZFS NAS（配备24块4TB HGST硬盘）的使用经验。尽管期间更换过主板和电源，但创下了10年零硬盘故障的记录。核心要点如下：

硬盘管理与能耗控制

作者认为硬盘长寿的秘诀在于“按需使用”。通过脚本结合IoT智能插座和IPMI实现远程开关机，避免设备24/7空转。此举大幅降低了电费，并可能延长了硬盘寿命。为彻底省电，作者移除了待机功耗超10W的UPS，选择承担断电风险。

ZFS 与数据安全

ZFS文件系统表现极其稳定，跨操作系统迁移导入存储池毫无障碍。作者每年执行数次 zpool scrub，累计读取超PB级数据，从未发现校验和错误，证明了静默数据损坏风险在家庭环境中极低。备份策略上，仅对核心数据进行三重备份，非重要数据依赖ZFS和硬件冗余，接受潜在丢失风险。

散热与噪音控制

为解决机箱原装12V风扇全速运行噪音过大的问题，作者利用Supermicro主板的风扇控制接口，编写了一个基于PID控制器的Python脚本。该脚本根据机箱内最高硬盘温度动态调节风扇转速，成功将硬盘温度控制在40°C以下，完美平衡了散热性能与静音效果。

硬件维护与网络演进

• 硬件更替：主板曾因无法进入BIOS而损坏，通过eBay购买同款解决；电源在24块硬盘同时启动（瞬时功耗约600W）时偶发断电。作者目前备有主板、CPU、内存和HBA卡等关键备件。
• 网络升级：网络方案从千兆网卡链路聚合（约450 MB/s），升级至InfiniBand（约700 MB/s，后因更换Debian系统不兼容而弃用），最终稳定使用二手万兆（10Gbps）以太网网卡。

未来规划

目前NAS存储空间依然充足，短期内无升级计划。随着单盘容量的提升，未来可能会迁移至6-8盘位的小体积机箱（采用RAIDZ2冗余），或者在现有设备彻底报废后结束该存储项目。

CrowdStrike前员工指控质量控制问题

多位前员工透露，CrowdStrike为快速推出产品，时常匆忙进行软件质量检查。前员工Preston Sego（2019-2023年在职）表示，有时很难说服人员进行充分测试。他于2023年2月因在内部平台批评公司返岗政策而被解雇，被冠以“内部威胁”标签。公司对此表示不讨论具体人事问题。

具体事件与问题：

1. 数据错误：专业服务部门曾三次将客户私密信息误上传至其他客户文件夹，险些导致数据泄露。公司确认系“手动输入错误”，并称已实施检查措施。
2. 服务中断：前员工指出，CrowdStrike的Falcon LogScale服务曾因赶工发布不良更新，短暂中断了实时威胁警报。公司否认存在客户未收到警报的“不良更新”，并澄清该服务并非设计用于实时警报，而是用于快速检测与封锁威胁。
3. 云威胁狩猎服务（Falcon OverWatch Cloud Threat Hunting）仓促上线：
   • 前高级经理称，2022年该服务上线时，公司仅给予团队两个月时间（正常需一年），导致内部工具缺失。威胁猎手最初只能依赖现有安全系统应对警报。
   • 公司使用了仅受过传统终端（如电脑）监控培训的员工来负责复杂的云环境威胁狩猎，且未强制要求进行新的云安全培训。前员工比喻这如同“让地面警察去开飞机空中巡逻”。
   • 公司辩称，当时该领域为全新，无法雇佣有专门经验的人才，并提供了自愿培训。同时否认服务存在工具缺陷或仓促上线。

代码与工作量压力： 前员工表示，用于推进项目的临时代码往往得不到后续优化。一名前高级工程师曾超过20次请求修复旧代码未果。前员工将此归因于人员精简和重组后工作量增加。公司则回应称代码改进是行业常态，并强调研发支出和员工总数持续增长。

背景与后续： 这些指控正值CrowdStrike因2024年7月一次更新缺陷导致全球Windows系统大规模故障之后。该事件令公司市值蒸发超过210亿美元，并面临多起诉讼。公司总裁在黑客大会上公开接受了“史诗级失败”奖项，表示必须坦然面对重大错误。

Writing an OS in Rust 代码库摘要

该代码库是 "Writing an Rust" 博客系列的源代码，配套博客位于 os.phil-opp.com。代码按每篇文章组织在独立的 git 分支中，分支命名为 post-XX（XX 为文章编号，如 post-03 对应 VGA Text Mode，post-07 对应 Hardware Interrupts）。用户可使用 git worktree add code post-XX 在子目录中检出特定文章的代码，构建说明见各分支的 README。

当前版本为第二版，文章主题如下：

• 基础部分：包括 A Freestanding Rust Binary、A Minimal Rust Kernel、VGA Text Mode 和 Testing。
• 中断处理：包括 CPU Exceptions、Double Faults、Hardware Interrupts。
• 内存管理：包括 Introduction to Paging、Paging Implementation、Heap Allocation、Allocator Designs。
• 多任务处理：包括 Async/Await。

第一版文章已过时且不再维护，但可供参考，涵盖 Bare Bones、Memory Management、Exceptions 和 Additional Resources 等子部分。

项目许可证：除 blog/content 文件夹外，代码采用 Apache License 2.0 或 MIT 许可证（用户可选）。blog/content 文件夹的许可详见其 README。贡献默认根据上述双许可进行许可。

OpenAI o1模型在ARC-AGI-Pub上的测试结果

OpenAI新发布的o1模型（包括o1-preview和o1-mini）在ARC-AGI公共评估数据集上进行了测试。其核心创新在于完整实现了**链式思维（Chain-of-Thought, CoT）**范式，在训练和推理阶段均应用CoT，通过强化学习（RL）和合成CoT数据训练，使模型能生成并优化推理过程。

测试表现

在ARC-AGI-Pub基准上，o1-preview得分为21.2%，与Claude 3.5 Sonnet（21%）相当，但耗时显著更长（平均每任务4.2分钟对比0.3分钟）。o1-mini得分12.8%，GPT-4o和Gemini 1.5得分均低于10%。o1的性能提升伴随着时间成本：处理400个公共任务总耗时70小时，而GPT-4o和Claude 3.5仅需30分钟。

技术原理

• 链式思维与强化学习：o1在训练时通过新RL算法利用合成CoT数据优化推理；推理时使用RL进一步优化CoT策略，可能结合搜索或回溯机制。
• 测试时计算扩展：o1展示了在非形式语言（如自然语言）中应用CoT推理搜索的实例。测试时计算量（如推理标记数）与准确性呈对数线性关系——更多计算通常带来更高准确性。但OpenAI未公开效率数据，也未允许开发者自定义计算量。

与AGI的关系

尽管o1在IOI、AIME等复杂基准中表现优异，但在ARC-AGI上仅取得中等成绩。文章指出，这并非意味着仅靠扩展测试时计算就能实现AGI：

• 效率限制：通过暴力搜索（O(x^n)）理论上可解决ARC-AGI，但需生成上亿解决方案，不切实际。
• 人类对比：人类解题依赖感知网络和系统2思考，而非穷举试错。
• 数据分布局限：o1仍主要依赖预训练数据分布（包括合成CoT），擅长复用已知推理模板，但难以实时合成全新推理。CoT优化仅能有限纠正推理错误。

结论与展望

o1代表了从“记忆答案”到“记忆推理”的范式转变，但仍属于通过拟合数据分布提升性能的范畴。实现AGI需要新思路，例如：

• 更高效的搜索与优化方法（如深度学习引导搜索）。
• 探索CoT与多模态、代码生成或程序搜索的结合。

ARC Prize鼓励开源创新，呼吁研究者参与探索这些新方向。

摘要：

作者宣布将不再续订其自2011年开始使用的网络书签服务Pinboard的订阅，该订阅将于2025年2月到期。这一决定源于Pinboard服务近年来日益衰落的现状。

Pinboard的历史与作用：

• 自2011年底起，作者将Pinboard用作一种微型博客，用以分享多为科技和事件的内容，填补了Google Reader社交功能关闭后的空缺。
• 通过多种应用（包括IFTTT）集成，其Pinboard帖子曾同步发布到Twitter、app.net及Mastodon等平台。
• 该服务导入了作者旧的Google Reader书签，积累了超过50,000个书签，形成了一个相对完整的分享记录集。
• 围绕Pinboard曾形成一个包含多种第三方应用的小型生态系统。

停止续订的原因：

1. 服务恶化与中断增加：过去几年，Pinboard服务中断次数缓慢增加，且官方沟通不足。
2. API限制与功能问题：作者在处理一次中断时发现，Pinboard的下载API受到限制，只能下载其约50,000个书签中的100个（尽管完整数据仍可作为文件下载）。
3. 单人维护与支持缺失：Pinboard由Maciej Cegłowski一人运营，而此人已不再回复支持邮件，也不再活跃于社交媒体，其支持论坛也已沉寂多年。

后续安排：

• 作者强调在Pinboard运营的十年间（在互联网上已属很长），该服务提供了价值，并对此表示感谢。
• 作者拥有自己的数据存档，且Pinboard仍提供书签数据的JSON或HTM格式导出功能，确保了数据出口。
• 作者正在研究其他的微型博客替代方案，并将在其他平台分享心得。

文章末尾附注更新，提及通过Mastodon看到的Hacker News文章，其中讨论了Pinboard的不佳结局及相关替代服务。

Factor 0.100 版本发布

版本号：0.100
支持平台：Windows、macOS、Linux（x86 和 x86-64 架构）
源代码：可下载 0.100 版本源代码

本次发布由超过1400次代码提交完成，主要贡献者包括Aditya Aryaman Das、Raghu Ranganathan等众多开发者。

主要新功能与改进

• 升级：升级至 Unicode 15.1。
• ARM64支持：非优化编译器获得早期ARM64支持，完整支持仍在进行中。
• 浮点数显示：改进了浮点数最短十进制表示的打印。
• 压缩镜像：支持压缩镜像，可显著减小文件大小。
• 主题检测：Windows上自动检测浅色/深色主题。
• 修复：修复了一些意外改为https的XML命名空间问题。

重要兼容性变更

• ui: focusable-child* 现在返回 f 表示应聚焦父级。
• peg: 和 partial-peg: 表单改为编译时处理，而非延迟到首次调用。
• 系统名称 macosx 已重命名为 macos。
• 函数 deg>rad 和 rad>deg 从 math.trig 移至 math.functions 词汇。
• 函数 integer-log10 和 integer-log2 从 math.functions.integer-logs 移至 math.functions 词汇。
• json: read-json 现在返回单个对象，读取多个对象请使用 read-jsons。
• rosetta-code 的解决方案已移至单独的Git仓库。
• base32 现包含所有来自 base32-crockford 和 base32hex 词汇的单词。

特别致敬

本次发布特别纪念了已故的杰出开发者Raghu Ranganathan（@razetime），他对Factor及多个技术社区做出了卓越贡献。

新增库概览

新版本引入了大量新库，涵盖：

• 数据编码：如 base45 (RFC 9285)、leb128。
• 网络协议：如 stomp (STOMP协议)、http.download。
• 工具与实用程序：如 command-line.parser (实验性)、containers (高级容器操作)、images.viewer.scaling。
• 游戏与算法：如 sududoku (数独游戏)、project-euler.061 与 .098 (欧拉计划解答)。
• 数据科学：如 kaggle API 包装器、math.statistics.running (运行统计)。
• UI扩展：如 ui.gadgets.comboboxes、ui.gadgets.alert。
• 集成与API：如 scryfall (MtG卡牌)、openai API 改进。

现有库的改进

对众多现有库进行了增强，包括但不限于：

• 核心功能：assocs、sequences、math、random 等库增加了新函数并优化了性能。
• 系统交互：改进了 io.directories、io.files、io.pipes 的跨平台行为。
• UI与渲染：ui.backend.windows 支持水平滚轮和主题检测；opengl 扩展更新。
• 数据处理：json、msgpack、xml、toml 解析器得到改进。
• 网络：http.server.responses 增加响应码，github 库扩展了REST API覆盖。
• 开发工具：tools.disassembler.capstone 支持新版Capstone，prettyprint.config 增加新选项。

虚拟机改进

• ARM64引导：改进了ARM64引导汇编，允许小表单在非优化编译器中成功原生执行。
• 压缩镜像：支持镜像压缩，尺寸最多可减小8倍，运行时解压会有一定开销。
• Windows控制台：改善了在cygwin和GitHub Actions等环境中的控制台I/O支持。

Factor语言简介

Factor是一种基于栈的、连接式编程语言，具有动态类型、可扩展语法、宏和垃圾回收等高级特性。它拥有完整的标准库，支持跨平台开发与部署，并采用BSD许可证开源。其实现为完全编译执行以保证性能，同时支持交互式开发。

用 Rust 宏实现的 Lisp 解释器

这是一个完全在 Rust 声明式宏（declarative macros）中实现的词法作用域（lexically scoped）Lisp 解释器。lisp! 宏将 Lisp 代码展开为其求值后的结果，并将其字符串化（stringify）。这意味着 lisp!(CAR (CONS (QUOTE A) (QUOTE (B)))) 会展开为字符串 "A"，并且所有计算都发生在 rustc 展开宏的编译时。

主要特点与示例

• 目的与规模：该实现完全由 Rust 宏完成，代码量少于 250 行。
• 运行机制：所有计算在编译时完成，结果被转换为字符串。
• 示例：

  let output = lisp!(CAR (LIST (QUOTE A) (QUOTE B) (QUOTE C)));
  assert_eq!(output, "A");
  

• 多表达式与输出：支持 PROGN 用于多个表达式。DISPLAY 表达式会先对其参数求值，然后展开为 println!("{}", stringify!(evaled_argument)) 语句来打印字符串化后的结果。
• 自省程序（Quine）：可以编写能求值为自身代码的程序。

递归支持

当前实现不支持显式的递归形式。然而，可以通过 lambda 和自应用（self application）来实现递归。例如，一个追加两个列表的函数可以这样定义和调用：

(DEFINE append 
    (LAMBDA (self X Y) 
        (COND 
            ((EQ X NIL) Y) 
            (TRUE (CONS (CAR X) (self self (CDR X) Y))) 
        )))
(append append (QUOTE (A B)) (QUOTE (C D)))

此表达式将求值为 "(A B C D)"。

使用注意事项

1. lisp! 宏只求值单个表达式。要评估多个表达式，请使用 (PROGN expr1 expr2 expr3)，它会求值所有表达式并返回最后一个表达式的值。
2. 空列表不是自求值的。要使用 NIL 或 (QUOTE ()) 来获取一个空列表值。空列表是唯一的“假”（falsy）对象。
3. 不支持点列表（dotted lists）。CONS 假设其最后一个参数是一个列表。
4. TRUE 是唯一的自求值原子（非函数）。
5. DEFINE 形式可在任何地方使用，并求值为空列表，但不支持递归定义（更像 Scheme 中的内部定义）。

支持的形式

DEFINE, QUOTE, LAMBDA, LET, PROGN, CAR, CDR, CONS, LIST, EQ, ATOM, APPLY。

元循环解释器

文中提供了一个用此 Lisp 实现的元循环（metacircular）Lisp 解释器的示例。该解释器实现了求值函数 eval，可以处理引用、原子、列表操作、lambda 表达式等。然而，评估如 ((lambda (X) X) (quote a)) 这样的简单表达式需要极长的时间（超过30秒）并产生巨量的宏展开令牌（tokens），导致进程被终止。这表明使用显式的 Y 组合子（combinator）进行递归在此上下文中效率不高。作者建议添加显式的递归原语来改进。

技术说明

该宏本质上是模拟一个 SECD 机器（一种用于求值 lambda 演算项的简单基于栈的抽象机）。

资源与计划

• 参考资源：列出了函数式编程的相关书籍和论文。
• 待办事项（TODO）：
  • 添加 letrec。
  • 添加递归定义。

文章摘要

本文是Rob Landley对Toybox邮件列表中关于全局变量空间影响的讨论回复。核心解释了全局变量对内存，特别是无MMU系统的重要性，并概述了Linux二进制格式（ELF）与内存管理的基本概念。

1. 全局变量与内存占用问题

• 用户询问了Toybox中全局变量（尤其是this结构体）的大小影响。
• Rob解释，在有MMU的系统（如Android）上，全局变量的可写数据页在访问时才会按需分配（需求分页），主要影响是内存页对齐（通常向上取整到4KB）。
• 然而，在无MMU系统（如许多嵌入式设备）上，全局变量的影响至关重要。因为这些系统必须立即分配物理内存，并且需要连续的物理内存块。

2. ELF二进制格式基础

Linux自1996年起使用ELF（可执行与可链接格式）作为可执行文件格式。一个进程的典型内存布局由以下六个段组成，其中前四个与ELF文件相关：

• text (代码段)：存储可执行代码。映射为只读、可执行。
• rodata (只读数据段)：存储常量、字符串等。映射为只读。
• data (已初始化数据段)：存储已初始化为非零值的全局变量。
• bss (未初始化数据段)：存储初始化为零的全局变量。操作系统在运行时分配清零的内存。
• stack (栈)：函数调用栈，包含局部变量和调用帧。由内核设置，通常向下增长。
• heap (堆)：用于malloc/free的动态内存分配。

在有MMU的系统中，当多个进程运行同一程序时，text和rodata段可以在进程间共享。

3. MMU与无MMU系统的关键差异

• 有MMU系统：拥有内存管理单元，支持虚拟内存、需求分页、交换、写时复制和内存重映射。进程可以使用分散的物理内存页，并通过页表呈现为连续的虚拟地址空间。
• 无MMU系统：没有内存管理单元，直接使用物理地址。无法执行以下操作：
  1. 地址重映射：无法为不同进程映射同一虚拟地址到不同物理内存。
  2. 整合分散内存：需要大块连续的物理内存来满足映射请求，内存碎片是严重问题。
  3. 使用交换空间：物理内存大小是固定的。
  4. 需求分页：必须在mmap()时立即加载全部文件数据或分配物理内存。
  5. 写时复制：创建写入映射的副本需要立即复制所有数据。
  6. fork()：无法复制进程地址空间，通常使用vfork()。
  7. 许多mmap()标志无效：例如MAP_PRIVATE、需求分页等。
  8. 动态增长栈：栈大小在exec()时固定，通常很小（如4KB-128KB）。

4. 无MMU系统的可执行文件格式

• 普通ELF（基于绝对地址）在无MMU上无法运行多个实例。
• PIE（位置无关可执行文件）：所有段连续排列，通过一个基址寄存器访问。需要大的连续内存块，且无法共享只读段。
• FDPIC（一种ELF变体）：为每个主要段使用独立的寄存器。允许只读段共享，并且可写段可以分别映射到内存的不同位置，能更好地利用碎片化的内存。

5. 对Toybox项目的启示

• GLOBALS()块（主要是this结构体）和栈是每个新进程在无MMU系统上最大的连续内存分配需求。
• 例如，this结构体（8232字节）加上toybuf和libbuf（各4096字节）等BSS段，总共需要约20KB的连续物理内存（向上取整到页面边界）。
• 减少全局变量（特别是大型结构体）的大小，能直接减少对稀缺连续物理内存的需求，对在无MMU系统上运行多个Toybox实例至关重要。
• 建议通过USE()宏确保未编译进二进制文件的命令的全局变量不会被包含。

总结：在嵌入式/无MMU系统中，优化全局变量大小不仅仅是代码风格问题，更是直接影响系统能否稳定运行和资源利用率的关键因素，因为它们需要宝贵的连续物理内存。

开源时序数据库的崛起

时序数据库能够高效地存储和查询带时间戳的度量数据，广泛应用于基础设施监控、金融、物联网和制造业等领域。与传统的关系型数据库（如PostgreSQL）不同，时序数据库针对海量时间序列数据进行了优化，能够以更少的资源处理数十亿甚至数万亿行数据，但其设计也意味着它不擅长频繁更新或存储非数值类型数据。

发展历程

• InfluxDB (2013年)：作为首个主流的开源时序数据库出现，极大地推动了时序数据库的普及，但其早期版本因稳定性和向后兼容性问题而备受批评。
• Prometheus：SoundCloud工程师开发，专注于指标和事件监控。其设计更专注，因此在稳定性、易用性和配置方面优于InfluxDB，成为了观测领域的事实标准。
• VictoriaMetrics：创始人在工作中发现Prometheus在处理大规模数据时遇到瓶颈，同时受ClickHouse数据库高效架构的启发，创建了VictoriaMetrics。它继承了Prometheus的设计，并采用了先进的压缩、块处理和多核利用技术，在磁盘使用率和查询速度上显著优于Prometheus。

当前格局

在2010年代末，众多开源时序数据库涌现，如VictoriaMetrics、TimescaleDB、QuestDB等。尽管也存在一些成功的专有数据库（如用于高频交易的kdb+），但开源模式已成为该领域的主流，为用户提供了丰富的选择。

未来挑战与趋势

时序数据库目前面临两个主要挑战：

1. 高基数问题：活跃时间序列的数量（由标签的唯一组合决定）直接影响数据库性能。标签值的微小增加可能导致序列数量激增，从而引发性能下降或故障。
2. 时间序列流失率：在容器化和Kubernetes环境中，Pod的频繁重启会导致标签值（如Pod名称）不断变化，从而在短时间内产生和失效大量时间序列，给历史数据查询和数据库性能带来压力。

此外，宽事件作为一种新的数据类型受到关注。它是结构化的日志条目，包含事件及其丰富的上下文属性。虽然它不太可能完全取代存储效率更高的度量数据，但有望增强日志和跟踪的可查询性。VictoriaMetrics团队也推出了VictoriaLogs来支持宽事件和非结构化日志。

总而言之，开源时序数据库因应用户对海量历史数据存储与分析的需求而生，并在开放协作的生态系统中蓬勃发展。

2022年一篇技术文章披露，珍妮特·杰克逊的音乐视频《Rhythm Nation》曾导致某些型号的笔记本电脑崩溃，甚至能影响附近未播放该视频的电脑。

调查发现，问题根源在于该歌曲包含5400转笔记本电脑硬盘的固有共振频率。这一频率引发了硬盘的物理共振，导致系统崩溃。受影响范围不仅限于一家制造商，竞争对手的笔记本电脑同样出现故障。

制造商通过一个技术手段解决了此问题：在音频播放管道中添加了一个自定义滤波器，用于检测并移除触发共振的频率。文章推测该滤波器可能被长期保留，但作者担心其具体原因可能已被遗忘。

文中将此现象与物理学中的共振原理相联系，并提及了1940年塔科马海峡大桥倒塌的著名案例（尽管作者随后澄清大桥倒塌并非主要由共振导致）。此外，文中还引用了其他类似案例，如特定游戏导致原型PC崩溃的事件。

Electrico 概述

Electrico 是一个实验性的、与 Electron 兼容的轻量级应用容器，使用 Rust 和 JavaScript 构建，并基于跨平台的 WebView 渲染库 Wry/Tauri。

核心特点

• 轻量化：无需捆绑 Node.js 和 Chromium 二进制文件，构建体积极小（约 10MB）。
• 跨平台支持：兼容 Linux、macOS、Windows、iOS 和 Android。
• 开发调试：支持使用原生浏览器开发工具调试前端和后端。

技术实现

• 所有 JavaScript 代码在系统原生 Web View 中执行：一个用于模拟 Node.js “后端”，另一个用于每个 Electron 应用的 GUI 浏览器窗口。
• Electron 和 Node API 通过对应的 Rust API 调用进行模拟，Web View 与 Rust 之间的通信基于同步和异步的 XMLHttpRequest。

已实现的 API 部分

• Electron：基本应用启动、BrowserWindow 方法、IPC、preload.js、部分对话框 API（打开、保存、消息框）。
• Node.js：部分文件系统 API（访问、获取状态、创建目录、读写文件、监视）、部分进程 API（子进程生成）。

测试与演示

• 测试应用：项目中的 /Resources 文件夹包含默认启动的测试应用。
  • 调试模式下，会为 “node 后端” 打开浏览器调试窗口，所有 GUI 窗口也附带调试工具。
  • 可通过命令以非调试模式启动。
• 应用演示 ‘Codex’：以 Josh Vickery 的 Codex 应用为例进行更全面的展示。
  • 克隆 Codex GitHub 仓库，在开发模式下启动 Codex。
  • 在 Codex 仓库目录中，将 ResourceLink.json 文件中的链接指向该目录，然后启动 Electrico。

苹果公司宣布在iOS 18中推出新功能，将激活锁（Activation Lock）扩展到iPhone的单个组件，该更新定于2024年9月16日推出。

主要更新内容：

• 新功能适用于iPhone的电池、摄像头、显示屏等组件。
• 每个部件通过唯一序列号与所有者的Apple账户关联，提供额外安全层。
• 当iPhone在维修中检测到使用过的部件时，将要求输入原始设备所有者的Apple账户密码，以验证组件合法性。
• 苹果旨在通过此功能打击被盗iPhone零件市场，降低盗窃动机。

注意事项：

• 该功能目前仅适用于iPhone，不适用于搭载iPadOS 18的iPad。
• 更新可能使涉及其他设备部件的维修过程复杂化，但符合苹果允许使用正品二手部件进行维修的政策。

影响：

• 被盗iPhone此前在用户从“查找我的”中删除设备前已基本无用，现在连其备用零件也无法使用。

Valkey 实现每秒百万级请求的技术解析

Valkey 从 Redis 分叉仅六个月后，通过一系列优化实现了每秒119万次请求（RPS）的性能。核心优化聚焦于解决内存访问延迟这一主要瓶颈。

问题根源：内存访问延迟

尽管主线程CPU利用率达100%，但性能分析显示其大量时间用于等待外部内存访问。在随机访问键值时，数据在处理器缓存中的命中率低。外部内存访问延迟是L1缓存的约50倍，导致主线程虽持续运行，但实际处于“等待”状态。

核心技术：内存访问分摊与交错执行

1. 交错执行：现代处理器通过推测执行提升性能。但链表、哈希表等动态数据结构会阻碍处理器对内存加载指令的并行推测，尤其在访问大型数据结构时，易引发高延迟的外部内存访问。
2. 解决方案：通过交错执行多个对随机内存位置的访问操作（如并行遍历多个链表），而非顺序执行，可以显著提升性能。示例代码显示，对包含大量元素的链表数组求和，交错执行版本比顺序版本快10倍。通过加入预取指令（__builtin_prefetch）可进一步优化。

在 Valkey 中的具体应用

1. I/O 线程卸载：首先，将几乎全部I/O操作卸载至I/O线程，释放主线程CPU周期用于执行命令，将SET命令吞吐量提升至780K RPS。
2. 优化 lookupKey 函数：性能分析发现，主线程超过40%的时间消耗在 lookupKey 函数上，该函数在字典中定位键。字典采用链式哈希实现，访问序列为 table→dictEntry→...→robj，依赖链条长，内存访问无法并行。
3. 批量预取与交错：当I/O线程准备好一批命令后，主线程在执行前调用 dictPrefetch。该函数交错处理该批命令中所有键所需的内存访问序列，预先发起多个内存访问请求。这使得 lookupKey 函数耗时减少超过80%。同样，对I/O线程传入的已解析命令的缓存访问问题也通过相同方法解决。相关代码位于 memory_prefetch.c。
4. 整体效果：内存访问分摊技术为Valkey性能带来了接近50%的提升，最终使请求处理能力达到每秒119万次。

复现测试概要

• 硬件环境：AWS EC2 c7g.4xlarge实例（16核 ARM aarch64）。
• 关键配置：
  • 设置网络中断亲和性，将IRQ分配到专用核心。
  • Valkey服务器启动命令包含 --io-threads 9（1主线程 + 8 I/O线程）。
  • 使用 taskset 将Valkey主线程绑定到独立CPU核心。
• 基准测试：从另一实例运行 valkey-benchmark，使用512字节值、300万键、650客户端等参数，以测量和重现峰值吞吐量。

Valkey 8.0 RC2版本已可用于评估这些I/O线程和内存访问分摊优化。

圣剑传说：提升专注力的沉浸式体验

摘要提出一个创新的虚拟现实（VR）系统，名为“圣剑传说”，旨在通过沉浸式体验帮助用户提高专注力。传统提升专注力的方法常缺乏直接和自然的反馈，而该系统通过拔出圣剑的交互场景，让用户接收视觉、听觉和触觉的多模态反馈。这一过程不能仅靠物理力量完成，需依赖专注；系统帮助用户面对并有意识地控制自身专注力，从而在各类活动中最大化潜力。

项目目的

作者为个人旅行博客文章顶部添加了 SVG 地图功能，主要出于对地图可视化工作的热爱以及对早期博客自动插入地图功能的怀旧。

核心需求

1. 不依赖第三方平台：避免外部 API 价格变动、服务弃用或性能降级带来的不可控风险。
2. 构建时生成（Build-time）：在静态站点构建阶段生成地图，而非在浏览器运行时加载，以提升页面性能并确保在弱网环境下的稳定性。
3. 跨设备一致性：确保地图在桌面端和移动端均能正常显示，不破坏页面布局。

技术实现

• 框架与模板：基于 11ty 静态站点生成器，利用其短代码（Shortcodes）功能，在 Nunjucks 模板中创建了 cartographer 短代码以条件化渲染地图。
• 数据管理：摒弃在文章前置元数据（Front matter）中硬编码经纬度，转而使用独立的 cities.json 文件集中管理地点数据（包含经纬度、显示名称和维基百科链接），文章仅通过 location 键进行引用。
• 地图生成：
  • 使用 d3-geo 库将 GeoJSON 格式的全球地理数据（源自 Natural Earth 的开源转换数据）转换为 SVG 路径。
  • 采用 Equal Earth 投影，将地图中心对准目标坐标。
  • 在短代码中直接拼接 SVG 和 HTML 元素，绘制经纬网、国家轮廓以及带有虚线外圈的中心标记点。
• 响应式样式：通过在 SVG 内部直接定义基础样式，并结合 CSS 媒体查询（Media Queries），实现桌面端（宽度 75%）和移动端（宽度 100%）的自适应尺寸调整。

未来改进计划

• 引入更高精度的地理数据（如水域、道路、铁路）并支持地图缩放。
• 添加总览地图，在旅行标签页集中展示所有文章涉及的地点。
• 探索为地图增加适度交互功能的可能性。

Haiku R1/beta5 版本发布总结

发布时间：距 R1/beta4 发布一年半后。

核心更新：

• 稳定性与兼容性：解决了近350个错误与增强事项，系统稳定性和硬件支持显著提升，是迄今最完善的版本。
• 质量提醒：此版本为beta质量，功能完整但可能存在已知或未知错误，无法保证数据绝对安全。

开发者动态：开发者 waddlesplash 作为承包商持续参与开发，其工作由社区捐款支持。

系统要求：

• 支持平台：x86 32位和64位。
• 最低配置（32位）：Intel Pentium II / AMD Athlon CPU，384MB内存，800x600显示器，3GB存储空间。
• 推荐配置（64位）：Intel Core i3 / AMD Phenom II CPU，2GB内存，1366x768显示器，16GB存储空间。
• 注意：BeOS R5 兼容性仅限于32位镜像。

新功能与改进：

1. 外观与主题：
   • 简化颜色选择，默认仅展示3种主色，其余颜色自动生成。
   • 新增“暗模式”支持，系统会根据背景色自动切换文字颜色，并修复了大量相关显示问题。
2. 内置应用：
   • Icon-O-Matic：新增“参考图像”导入、透视变换功能，优化了复制粘贴。
   • PowerStatus：检测到电池时自动安装至桌面栏，改进了状态处理与低电量提示。
   • Tracker（文件管理器）：改进对只读文件夹的处理（显示为淡色背景并禁用写入操作）。
3. 硬件支持：
   • 新增对 USB 音频设备的基本输入/输出支持。
4. 网络与性能：
   • 新增 TUN/TAP 网络驱动，主要用于VPN。
   • TCP 性能大幅提升：本地回环速度达两位数Gbit/s级别；实际连接性能提升8-10倍，得益于ACK合并、SACK及窗口缩放算法等改进。
   • 网络栈整体优化，包括统计计数、减少缓冲区拷贝、支持接收端校验和卸载。
5. 终端与底层：
   • Terminal：支持带括号的粘贴，新增自定义配色方案设置。
   • TTY/PTY 层：代码重构统一，提升大数据读写稳定性。
6. 系统核心优化：
   • 内核与驱动性能优化：包括I/O批处理、减少锁竞争、改进内存映射等，编译性能提升约25%。
   • 用户互斥系统重写：解决正确性问题，提升多线程争用下的性能。
7. 文件系统：
   • FAT 驱动完全重写：移植自FreeBSD，解决了长期存在的兼容性和数据问题。
   • 新增 UFS2 文件系统的只读支持（FreeBSD默认文件系统）。
8. API 与兼容性：
   • 实现 kqueue(2) API 子集，高效处理大量事件源（类似Linux的epoll）。
   • 增强 POSIX 兼容性：新增 getentropy, arc4random, UNIX数据报套接字等支持。
9. 调试与开发工具：
   • strace 和 profile 工具得到增强，输出更清晰（如使用名称替代十六进制码），统计更精确。

软件移植：

• 新增 GDB 15 的完整移植，功能全面。
• 实验性移植 .NET Core 8/9。
• 通过X11兼容层新增 FLTK 工具包移植。

错误修复与稳定性：

• 修复数百个错误，系统各模块均得到改进。
• 进行了大量内核和驱动稳定性工作，修复了众多崩溃、挂起问题。

社区与支持：

• 新增一名核心开发者 nephele。
• 源代码可通过GitHub或Haiku的Git实例获取。
• 用户可通过论坛、IRC、Matrix、邮件列表等渠道获取帮助。

文章总结

核心事件：安全厂商Doctor Web于2024年9月12日报告，发现名为 Android.Vo1d 的恶意软件（后门程序）已感染全球近130万台基于Android系统的电视盒设备，涉及197个国家。

恶意软件特征：

• 性质：一种后门程序，能秘密下载并安装第三方软件。
• 名称来源：其组件之一被命名为vo1d，意在伪装成系统进程vold。
• 感染方式：通过修改系统关键文件（如install-recovery.sh、daemonsu）并替换或创建新文件（如vo1d、wd、debuggerd）实现驻留，确保开机自启。它采用了至少三种不同的方法来确保在目标系统中的稳固性。
• 运作机制：
  • 核心组件 vo1d 和 wd 协同工作。
  • vo1d（Android.Vo1d.1）负责启动和监控wd，并可从命令与控制（C&C）服务器下载运行可执行文件。
  • wd（Android.Vo1d.3）负责解密并运行另一个加密的守护进程（Android.Vo1d.5），也能下载运行程序，并会监控特定目录自动安装发现的APK文件。

影响范围：

• 感染设备：受影响设备型号包括R4、TV BOX、KJ-SMART4KVIP等，其宣称的系统版本与实际不符（例如标注Android 12.1实为Android 7.1.2）。
• 地理分布：感染最集中的国家包括巴西、摩洛哥、巴基斯坦、沙特阿拉伯、俄罗斯、阿根廷、厄瓜多尔、突尼斯、马来西亚、阿尔及利亚和印度尼西亚。

潜在原因与分析：

• 目标选择：TV盒子通常运行过时的Android版本（存在未修补的漏洞且不再获得更新），且廉价设备制造商可能虚标系统版本。用户也可能误以为此类设备比手机更安全，从而疏于安装安全软件。
• 感染源未知：可能的感染途径包括：1）利用系统漏洞获取root权限的其他恶意软件攻击；2）使用了内置root权限的非官方固件。

解决方案：Dr.Web Android版反病毒软件可检测并清除所有已知的Android.Vo1d变种（需设备拥有root权限）。

技术细节（关键指标）：

• 涉及恶意组件：vo1d (Android.Vo1d.1), wd (Android.Vo1d.3) 及加密的Android.Vo1.5。
• 被修改或新增的系统文件包括：install-recovery.sh, daemonsu, /system/xbin/vo1d, /system/xbin/wd, /system/bin/debuggerd 等。