文章总结：RP2350 微控制器的优势与改进

本文作者长期使用树莓派的 RP2040 微控制器，同时对其不足之处（如核心性能有限、无法支持 QSPI PSRAM、GPIO 数量不足等）感到遗憾，有时不得不转而使用问题频出的 STM32H7 系列。作者曾秘密参与 RP2350 的测试长达一年，发现新芯片几乎满足了其所有改进愿望。

RP2350 的主要改进包括：

1. 更强核心：搭载双 Cortex-M33F 核心，支持浮点运算，并添加了自定义指令以加速双精度数学运算。可稳定超频至 300MHz，性能显著提升。
2. PIO 增强：PIO 单元增至三个；FIFO 可作为随机存取存储器使用，增加了临时变量空间；PIO 之间可发送中断，支持更复杂的同步与协议实现（如作者成功实现了索尼 Memory Stick 和 SDIO 从设备）。
3. DMA 改进：支持无限传输模式，无需额外通道触发；内存地址调整方式更多样（如支持递减、按不同大小递增）。
4. 优秀的 QSPI PSRAM 支持：读写稳定，缓存工作正常，配置简单（仅需三行 C 代码），可轻松添加 16MB RAM。与 STM32H7 的 PSRAM 问题频出形成鲜明对比，作者测试中数据无丢失、芯片无挂起。
5. 其他特性：GPIO 数量增加，提供带内置 2MB Flash 的 RP2354 变体，开发板与 Pico 兼容，SDK 简洁易用。

实践验证： 作者以 DEFCON 32 徽章项目为例，展示了 RP2350 的实际应用：一个核心负责游戏画面放大（利用 SIMD 指令），另一个核心运行 Game Boy 模拟器。该硬件亦可运行 PalmOS，且在填充 PSRAM 后能支持视频播放等更复杂应用。

结论： RP2350 解决了 RP2040 的多项短板，尤其在 QSPI PSRAM 支持方面远优于 STM32H7，同时保持了优秀的外设设计与文档质量。作者认为 RP2350 是替代 STM32H7 项目的更优选择，并提供了更多 GPIO 和内置 Flash 的变体型号。

免责声明： 作者声明本文基于个人体验撰写，未收取任何报酬或寻求批准，所有观点均为己出。

Firefox Nightly 131版本现已推出全新的侧边栏和垂直标签页体验。这是社区高度期待的功能，旨在优化上下文切换和多任务处理两种核心浏览工作流。

新功能与启用方式

1. 垂直标签页：使标签页在浏览器侧边纵向排列，便于快速浏览信息和切换任务。
2. 侧边栏：允许用户快速访问常用工具，如手机上的标签页、扩展程序或书签，方便与主任务进行交叉参考。
3. 启用方法：用户需更新至最新Nightly版本，在“设置”>“Firefox Labs”中激活相关实验功能，并通过自定义工具栏将侧边栏图标拖至工具栏。

当前状态与未来计划

• 此功能目前仍在开发中，将在未来数月持续优化。
• 开发团队在Mozilla Connect上分享了改进计划的积压列表，让用户了解最终目标。
• Mozilla鼓励社区用户测试并提供反馈，这些意见将帮助完善功能。
• 特别呼吁Web扩展开发者测试其扩展程序在新UI下的兼容性，尽管相关Web Extension API未发生改变，但有助于发现潜在的界面问题。

这篇文章详细记录了作者通过挖掘经典游戏《托尼霍克职业滑板4》（Tony Hawk's Pro Skater 4）等系列作品中的漏洞，成功对初代Xbox、PlayStation 2、GameCube乃至Xbox 360等游戏主机实现漏洞利用和代码执行的完整过程。核心内容如下：

1. 漏洞发现与初步利用 作者在2016年为提升漏洞挖掘技能，开始研究初代Xbox的旧游戏。他发现《托尼霍克职业滑板4》的自建滑板公园（Create-A-Park）功能中，玩家命名的“缺口”（gap）字符串存在一个缓冲区溢出漏洞。该字符串最大长度为31字符，但游戏在读取存档时使用了不安全的strcpy函数将其复制到栈上，且未进行边界检查，也未启用栈保护（Stack Cookies）。通过构造超长字符串，可以覆盖栈上的返回地址，控制程序执行流。

2. 绕过安全措施与实现代码执行 尽管初代Xbox内存区域存在一定的执行保护，但作者通过精巧的攻击链实现了代码执行。他利用存档文件头部数据会被复制到游戏可执行文件数据段（可执行内存）的特性，在其中嵌入一小段“拷贝桩”代码。当栈溢出触发后，程序跳转至该桩代码，将后续更大的攻击载荷（shellcode）从存档缓冲区拷贝到可执行内存区域并跳转执行，从而获得完整的代码执行能力。

3. 网络远程代码执行（RCE）的突破 作者并未止步于此。他将漏洞利用拓展至局域网对战场景：攻击者作为主机创建恶意公园存档，当其他玩家加入游戏时，主机会通过网络发送该存档。客户端在加载存档时触发溢出，导致被远程控制。作者解决了文件传输中的内存泄漏问题（通过热修补一个游戏中的15年前的旧漏洞），最终实现了在受害者不知情的情况下，于游戏进行过程中静默传输并执行恶意程序的效果，完成了跨主机的RCE攻击。

4. 跨平台漏洞移植与利用 该漏洞存在于多款《托尼霍克》系列游戏中。作者将该漏洞成功移植到：

• PlayStation 2：实现了网络RCE，可远程发送并启动自制程序。
• GameCube：实现了存档漏洞利用，但因主机特性，利用价值有限。
• Xbox 360：这是技术上的重大突破。作者利用同一漏洞，在特定内核版本（4548）的Xbox 360上，通过一个包含24个gadget的ROP链，利用系统调用处理器中一个疑似编译器导致的漏洞，首次实现了纯软件漏洞利用。该利用链成功绕过Xbox 360的Hypervisor安全机制，获得最高权限的代码执行能力，并能修补内核以运行未签名程序。

5. 总结与影响 作者的研究表明，一个简单的strcpy漏洞可以跨越多年、多个平台产生深远影响。这些漏洞利用代码和补丁存档已在GitHub上开源。作者还提醒，在PC平台上运行相关游戏同样存在此类漏洞风险。整个过程展示了从复古主机到相对现代化的Xbox 360，内存安全漏洞在不同安全机制下的利用技术，是一次全面的漏洞利用技术实践。

Puppeteer 原生支持 Firefox

核心发布

自 Puppeteer v23 起，该浏览器自动化库正式提供对 Firefox 的原生支持。开发者现可使用同一套代码在 Chrome 和 Firefox 上运行自动化和端到端测试。只需在启动时配置 browser: "firefox"，Puppeteer 即可自动下载并运行最新稳定版 Firefox。

底层技术：WebDriver BiDi

Firefox 的支持并非基于浏览器专属协议，而是基于正在 W3C 标准化的跨浏览器协议 WebDriver BiDi。该协议目前在 Gecko 和 Chromium 中均已实现。这种跨浏览器协议的应用大幅降低了未来支持更多浏览器的成本与复杂度，其打破生态壁垒的意义类似于代码编辑器领域的 LSP（语言服务器协议）。

关键功能

得益于 WebDriver BiDi 的事件驱动特性，Puppeteer 在 Firefox 中实现了以下跨浏览器高级功能：

• 捕获日志消息：通过事件监听（如 page.on('console')）实时获取控制台日志，避免了传统的轮询方式。
• 设备模拟：支持模拟移动设备的视口尺寸和设备像素比，便于进行响应式布局测试。
• 网络拦截：可跟踪和拦截网络请求，提供 Mock 数据、处理 HTTP 认证或修改请求/响应头（例如拦截特定字体请求以防布局破坏）。
• 预加载脚本：支持在页面加载前注入并执行自定义 JavaScript，避免脚本竞态条件，并可通过 MutationObserver 等机制发射自定义事件与页面交互。

技术背景与实验性 CDP 支持的移除

传统的 W3C WebDriver 基于 HTTP，缺乏事件监听和并发能力；而 CDP 等浏览器专属协议虽功能丰富但无法跨平台。WebDriver BiDi 结合了两者优势，提供了标准化且功能丰富的自动化方案。 此前 Puppeteer 对 Firefox 的实验性支持基于部分 Chrome DevTools Protocol (CDP) 实现。由于 CDP 并非跨浏览器自动化的发展方向，该实验性支持已停止维护，且不支持站点隔离等现代特性，计划于 2024 年底正式移除。

未来计划

目前仍有部分 API 尚未在 Firefox 中支持，主要分为三类：

1. 高度依赖 CDP 的 API（如 CDPSession 模块），未来可能针对特定用例进行标准化。
2. 需要进一步标准化工作的 API（如无障碍树快照、地理位置设置）。
3. 已有标准但尚未实现的 API（如在 Web Worker 中执行脚本）。

官方鼓励开发者在 Firefox 中运行 Puppeteer 测试，并积极反馈缺失功能或 Bug，以协助规划未来的标准制定与开发优先级。

Raspberry Pi Pico 2 微控制器板发布

Raspberry Pi Pico 2 是第二代微控制器板，搭载新型高性能安全微控制器 RP2350，即日起发售，售价为 5 美元。

核心升级与特性

• 性能提升：双核时钟频率更高（150MHz Arm Cortex-M33），内存翻倍（520KB SRAM），接口能力更强。
• 安全架构：集成 Arm TrustZone、签名启动支持、8KB OTP 内存、SHA-256 加速及硬件真随机数生成器。
• 电源与功耗：内置开关电源与低静态电流 LDO，支持低功耗待机。
• 扩展性：支持外部 QSPI PSRAM，提供两种封装选择（RP2350A 30 GPIO / RP2350B 48 GPIO），并包含集成 2MB 闪存的型号。
• 性价比：芯片面积虽增至 5.3mm²，但价格仅比前代略高（RP2350A 单价约 $1.10）。

开发板设计

• 搭配 4MB 外部 QSPI 闪存（原版为 2MB）。
• 与初代 Pico 在尺寸和电气上兼容。
• 预计年底前推出无线版本 Pico 2 W 及带排针版本。

软件与开发生态

• 发布更新版 Pico SDK、MicroPython 及 CircuitPython 镜像。
• 支持 Rust 语言开发。
• 与 Google 合作推出 Pigweed SDK，提供原生支持。
• 作为 Trusted Firmware-M 2.1.0 参考硬件平台，致力于实现 PSA Certified Level 2 安全认证。
• 提供完整数据手册及 Visual Studio Code 开发教程。

安全研究与漏洞赏金

• 签名启动是安全核心，可防止未经授权代码执行。
• 公司已委托 NewAE 和 Hextree 进行安全审计，并公开悬赏 $10,000 征求首个签名启动漏洞（为期一个月）。
• 与 DEF CON 黑客大会合作，将 RP2350 集成到会议徽章中，便于安全研究。

合作伙伴产品

多家合作伙伴同步推出基于 RP2350 的开发板与模块，涵盖显示模组（4D Systems）、Arduino 兼容板（Adafruit）、工业控制器（Cytron）、小型化开发板（Seeed XIAO）、模块化合成器（ThisisNotRocketScience）等多个领域。

RISC-V 支持

RP2350 内置双 Hazard3 RISC-V 核心，可在启动时替代 Arm Cortex-M33 核心。这是 Raspberry Pi 首款支持 RISC-V 的产品，旨在促进该架构在稳定环境中的应用与普及。

生产与供货

• 目前由索尼负责生产，库存有限，已接受预订。
• 预计 2024 年底前实现 RP2350 芯片大批量供货。

致谢

产品开发得到 Arm、TSMC、索尼、NewAE 等众多合作伙伴及内部团队的支持。

文章总结：苹果违背并悄然删除 OCSP 退出选项承诺

事件背景 macOS 在启动应用时会连接苹果的 OCSP 服务以验证开发者证书。2020年11月，该服务发生大规模宕机，导致全球 Mac 用户无法启动应用。事后，苹果在官方支持文档中承诺了多项隐私与安全改进措施，包括停止记录 IP 地址、引入加密协议、增强服务器故障保护，以及提供让用户选择退出（opt-out）这些安全检查的偏好设置。

违背承诺与文档篡改 作者指出，苹果从未在 macOS 中实现上述的“退出”选项。更严重的是，在2023年9月26日（macOS 14 Sonoma 公开发布当天），苹果悄悄从支持文档中删除了关于提供退出选项的承诺（此修改可通过 Wayback Machine 查证）。此外，原始支持文档的 URL 也被重定向到了一个新的 URL。

信任危机与批评 作者严厉批评了苹果此举，认为其试图掩盖违背承诺的事实。尽管苹果对外宣称“隐私是基本人权”，但在赋予用户阻止设备向苹果服务器发送数据的权利方面却缺乏实际行动。作者强调，这种言而无信的行为严重破坏了用户对苹果其他隐私承诺（如不记录 IP 地址）的信任，因为外部根本无法验证这些声明的真实性。

应对建议 鉴于苹果未能兑现承诺且拒绝提供官方退出机制，作者建议用户目前只能通过使用第三方防火墙（如 Little Snitch）来手动阻断 OCSP 连接，从而保护自身隐私。

Cosmic 桌面环境概览

核心定位

Cosmic 是一款为打造美观用户体验而设计的基础软件，适用于多种Linux发行版。

核心优势

• 用户与产品双赢：通过优越的性能、效率和深度个性化定制，满足多样化的使用场景，提升用户体验。
• 高度可定制的用户体验：提供模块化组件，包括面板、小程序、主题、平铺布局、启动器、应用库、快捷键以及动态/固定工作区，均可灵活调整以适配用户需求。
• 品牌化主题定制：内置的主题系统允许组织轻松使用自身品牌色板创建默认主题，同时保障可读性。
• 便捷的应用开发：采用统一的语言和工具包开发应用和小程序，提供模板支持，甚至Shell组件和合成器也使用同一工具包，降低学习与维护成本。

技术亮点与安全性

• 基于Rust构建：作为内存安全的编程语言，Rust提供了卓越的稳定性与安全性。
• 原生Wayland支持：作为Wayland原生桌面环境，消除了键盘记录、输入欺骗等漏洞，并借助Rust的内存安全机制，大幅减少缓冲区溢出、释放后使用等常见攻击面。

社区与生态

• 拥有活跃的Cosmic社区，汇集众多开发者，共同推动其作为直观且强大的工具持续发展。
• 作为开源倡导者，Cosmic由System76公司设计和工程化实现，该公司致力于生产高端Linux计算机、Pop!_OS系统和安全固件，旨在赋能用户自由。

媒体报道与进展

• Pop!_OS 24.04 LTS（搭载Cosmic桌面）已发布首个公开测试版。
• 在开源峰会等场合，Cosmic被介绍为首个模块化、可组合的桌面环境。
• 媒体广泛关注其Rust驱动的首次亮相，视其为重写Linux桌面历史的重要一步。

开放与免费

Cosmic可供免费下载和使用，用户可通过Pop!_OS LTS 24.04开始体验。

深入探讨 CVE-2023-2163 eBPF Linux 内核漏洞

本文主要聚焦于 Linux 内核中的 eBPF 子系统漏洞 CVE-2023-2163。近年来，eBPF 作为关键的内核子系统，吸引了大量安全研究人员的密切关注。

文章的核心内容涵盖以下几个方面：

• 研究背景：回顾 eBPF 子系统在安全研究领域备受关注的背景与发展。
• 漏洞发现：详细讲述研究团队发现 CVE-2023-2163 漏洞的完整过程。
• 根因分析：深入剖析团队在定位漏洞根本原因（root-cause analysis）时所采用的具体分析流程与方法。
• 漏洞修复：介绍最终为彻底修复该内核漏洞所采取的具体措施和解决方案。

C# 类型联合官方提案摘要

核心动机

该提案旨在为C#引入**类型联合（又称可辨识联合）**特性，以解决在单一变量中存储多种限定类型时缺乏类型安全、当前方案存在局限的问题。当前开发者常被迫使用 object 类型并依赖文档/注释维护安全，或采用繁琐的自定义包装类型，这降低了代码的清晰度和安全性。

四种解决方案

提案根据不同的使用场景，提出了四类类型联合：

1. 标准联合类

   • 定义：使用 union 关键字在单一声明中定义所有成员类型（类似于枚举）。
   • 特点：基于类层次结构实现，成员类型可以是具状态的类。适用于需要分配内存、生命周期较长的值（如UI数据模型、序列化类型）。
   • 实现：编译为一个抽象记录类（abstract record）及其派生记录类，并使用 [Closed] 属性封闭层次结构以支持穷尽性检查。

2. 特殊联合结构体

   • 定义：在 union 声明中添加 struct 关键字。
   • 特点：所有类型均为结构体，旨在避免堆分配。适用于高性能场景，如图形管线、频繁改变的状态机状态或作为参数/返回值。
   • 实现：编译为结构体，内部采用高效布局存储数据，并通过隐式运算符和 TryGet 方法进行转换与访问。具有 Kind 属性用于标识当前成员类型。
   • 特殊处理：支持 default 状态警告或显式默认成员；支持 ref 修饰符以包含引用或 ref struct 类型；装箱后仍支持在成员类型间进行类型测试和拆箱。

3. 特设联合

   • 定义：使用 (A or B or C) 语法匿名组合现有（可能不相关的）类型。
   • 特点：成员类型相同的联合被视为同一类型，支持子集/超集的赋值和强制转换。可从上下文（如条件表达式、Lambda）推断出联合类型。
   • 实现：通过擦除为 object 和运行时检查实现。联合类型信息通过自定义属性编码在元数据中。注意：这会导致值类型装箱，且不支持包含引用类型。

4. 自定义联合

   • 定义：允许开发者声明自己的类或结构体，并通过特性（如 [Closed] 或 [Union]）和特定API模式使其被编译器识别为联合类型。
   • 特点：用于前述方案无法满足的特定需求，如自定义存储布局、现有层次结构改造或特殊API设计。

常见预定义联合类型

提案建议将以下类型纳入运行时：

• Option<TValue>：结构体联合，表示一个值可能存在（Some）或不存在（None），用于替代可能为 null 的场景。
• Result<TValue, TError>：结构体联合，表示操作成功（Success）或失败（Failure），用于显式错误处理。

相关语言特性

该提案依赖于若干其他待定或已提议的语言特性：

• 闭合层次结构：通过 [Closed] 属性使编译器知道类型层次是封闭的，从而支持穷尽性 switch。
• 单例值：允许在非类型上下文中使用具有静态 Singleton 属性的类型。
• 嵌套成员简写：允许在类型上下文中直接使用其嵌套类型的名称。

关键问答要点

• 联合类与结构体选择：联合类提供简洁语法和层次结构便利；联合结构体避免分配但可能增大栈开销且不适用于匿名场景。
• 穷尽性检查：所有联合类型都支持在 switch 中覆盖所有成员后省略 default 分支。
• 与object的区别：特设联合在编译时提供静态类型安全，并在运行时生成验证检查，比直接使用 object 更安全。
• 与 F#/TypeScript 的差异：C#的联合类/结构体类似F#的判别联合，但成员是类型而非带状态变量的标签；特设联合类似TypeScript的类型联合。

错误消息摘要：
提供的内容是一个错误提示，表明在x.com上操作时出现问题。消息建议禁用隐私相关扩展并重试，以解决该问题。内容未涉及技术主题或RLHF相关讨论，仅包含简单的故障排除建议。

FlexAttention 摘要

核心问题：优化的注意力实现（如FlashAttention）虽然大幅提升了性能并支持长上下文，但牺牲了灵活性。研究人员尝试新的注意力变体（如因果注意力、相对位置编码、ALiBi、滑动窗口等）通常需要编写定制化内核，形成了“软件彩票”困境。各种变体的组合数量呈指数级增长，导致支持零散且新变体无法得到支持。

解决方案：引入 FlexAttention，一个PyTorch API。它允许用户用几行PyTorch代码（通过一个用户定义的score_mod函数）实现多种注意力变体。该函数在softmax前修改注意力分数。

工作原理：

1. 自动融合：通过torch.compile，FlexAttention将score_mod自动编译并融合成一个高效的FlashAttention内核，无需物化额外内存。
2. 反向传播自动生成：利用PyTorch的autograd机制自动生成反向传播。
3. 稀疏性利用：引入mask_mod函数和BlockMask数据结构，专门处理掩码模式，以充分利用注意力掩码的稀疏性，显著提升性能（例如，因果掩码可实现约2倍加速）。
4. 灵活性与组合：score_mod函数签名独特（接收标量分数及批次、头、查询/键位置索引），可以表达多种修改。通过mask_mod和create_block_mask处理掩码，并支持使用and_masks、or_masks等组合多个掩码。

关键特性与示例：

• 表达力：仅修改分数即可实现相对位置编码、ALiBi、软上限、因果掩码等。
• 稀疏性优化：对于因果掩码等稀疏模式，使用mask_mod比使用score_mod快约15-20%，因为它能跳过整个稀疏块的计算。
• 高层修改：支持如generate_doc_mask_mod等高层函数，能将任意mask_mod转换为适用于“锯齿序列”（文档掩码/样本打包）的版本。
• 内存高效：BlockMask元数据在默认块大小（128）下内存消耗小（例如，序列长度100万时仅60MB）。

性能：FlexAttention在性能上接近手写的Triton内核。在A100上，与FlashAttention2相比，因果注意力的前向传播性能达到约90%，反向传播约85%。反向传播的差距源于当前使用的确定性算法，未来有改进计划。

限制与未来工作：

• 当前在PyTorch夜间版可用，计划作为原型功能在2.5.0版本发布。
• 尚未涵盖推理优化（如PagedAttention）。
• 需提升至匹配H100上FlashAttention3的性能。
• 当前要求序列长度为128的倍数。
• 计划增加GQA支持。

总结：FlexAttention旨在通过结合PyTorch的灵活性与FlashAttention的性能，解决注意力变体实现的“软件彩票”问题，其核心是用户定义的score_mod和mask_mod函数，经由torch.compile自动融合优化，并高效利用稀疏性。

1970年《清洁空气法》旨在涵盖二氧化碳排放

一项新研究发现证据表明，美国国会在1970年制定《清洁空气法》时，其意图是涵盖二氧化碳排放。这一发现加强了对温室气体进行法律监管的依据。

研究背景源于前总统巴拉克·奥巴马时期，美国环境保护署（EPA）提出了针对发电厂二氧化碳排放的法规。然而，2022年美国最高法院撤销了这些标准，理由是国会并未授权EPA监管温室气体。

哈佛大学和杜克大学的研究人员通过审查历史记录，对最高法院的结论提出了挑战。他们的研究发现，《清洁空气法》的主要起草者理解燃烧化石燃料会导致地球变暖，并将二氧化碳视为一种污染物。尽管立法者当时并不认为二氧化碳是迫在眉睫的威胁，但他们确实认为这种温室气体最终需要被监管。

在该法律制定之时，社会对气候变化的认知已在增长。为林登·约翰逊和理查德·尼克松总统撰写的报告警告了全球变暖的风险，此类信息通过通俗杂志、电视节目或学校教育逐渐渗透到公众意识中。例如，1969年诗人艾伦·金斯伯格在《默夫·格里芬秀》节目上就曾抨击“由汽车激增导致的当前空气污染速率”可能引起“地球热量的快速积聚”。

该研究阐释了《清洁空气法》主要设计者、参议员埃德蒙·马斯基的幕僚如何追踪关于气候变化的公众讨论。这位来自缅因州的民主党人当时就警告，不加控制的污染将“威胁不可逆转的大气和气候变化”。

这项即将发表于《生态法律季刊》的研究得出结论：国会议员们“对人为气候变化潜在威胁的理解，远超最高法院或大多数评论家的认知”。

Web透明视频技术解析

背景与需求

在Shopify团队中，经常需要将带有透明通道的UI视频动画合成到不同的CSS背景上。虽然使用Web技术创建动画是常见方案，但视频在保证帧率和实现运动模糊等效果方面具有优势，因此需要在Web中实现带透明通道的视频播放。

原生支持方案的挑战

AVIF方案的局限性

• 兼容性问题：虽然AVIF支持透明度和动画，但在Safari中透明效果无法正常工作，且性能极差。
• 性能瓶颈：Chrome和Firefox中AVIF动画帧率不稳定，移动端几乎无法流畅播放。
• 流媒体问题：作为<img>而非<video>处理时，缓冲策略不佳，网络慢时播放卡顿。
• 功能限制：无法使用视频控件、编程控制播放，也不支持音频和格式回退。

VP9 + HEVC方案

• 原理：VP9用于Chrome/Firefox，HEVC用于Safari，通过<video>标签的<source>提供跨浏览器支持。
• 缺点：文件体积较大（VP9约1.1MB，HEVC约3.4MB），且存在已知浏览器兼容性bug（如Chrome Android的透明通道错误）。

手动合成方案（推荐）

核心思路

将视频分为上下两半：

• 上半部分：原始RGB颜色数据
• 下半部分：透明通道数据（作为亮度信息存储）

通过WebGL片段着色器在运行时合成：

uniform sampler2D u_frame;
varying vec2 v_texCoord;
void main() {
  vec2 colorCoord = vec2(v_texCoord.x, v_texCoord.y * 0.5);
  vec2 alphaCoord = vec2(v_texCoord.x, 0.5 + v_texCoord.y * 0.5);
  vec4 color = texture2D(u_frame, colorCoord);
  float alpha = texture2D(alphaCoord).r;
  gl_FragColor = vec4(color.rgb, alpha);
}

优势

1. 文件体积小：AV1编码版本仅460KB，HEVC版本1.14MB，远小于原生方案。
2. 跨浏览器兼容：支持Chrome、Firefox、Safari（需硬件解码器支持）。
3. 技术实现简单：透明通道数据增加体积极小（仅8KB左右），因内容为单通道且帧间变化少。

实现工具

• Web组件：<stacked-alpha-video>，通过NPM发布，内部可直接访问WebGL渲染逻辑。
• 编码命令（ffmpeg示例）：
  • AV1编码：

    ffmpeg -y -i input.mov -filter_complex "[0:v]format=pix_fmts=yuva444p[main]; [main]split[main][alpha]; [alpha]alphaextract[alpha]; [main][alpha]vstack" -pix_fmt yuv420p -an -c:v libaom-av1 -cpu-used 3 -crf 45 -pass 1 -f null /dev/null && ffmpeg ... -pass 2 output_av1.mp4
    

  • HEVC编码（用于不支持AV1的设备）：

    ffmpeg -y -i input.mov -filter_complex "..." -pix_fmt yuv420p -an -c:v libx265 -preset veryslow -crf 30 -tag:v hvc1 output_hevc.mp4
    

技术注意事项

1. 像素格式：默认使用受限范围（16-235），可能导致渐变条纹，可改用10位格式（yuva444p10le）缓解。
2. 兼容性策略：通过<source>顺序优先保证Safari选择HEVC，其他浏览器选择AV1。
3. 原生方案对比：手动方案在文件大小和兼容性上全面优于原生透明视频格式。

结论

对于Web透明视频，推荐采用手动堆叠合成方案，结合AV1/HEVC编码和WebGL渲染，在保证性能与兼容性的同时最小化文件体积。已有现成Web组件和编码工具链支持快速集成。

音乐明星生涯的统计分析

本文通过统计数据与心理学理论，分析了音乐明星职业生涯的真实轨迹、持续时间及其背后的行为动机，揭示了现实与音乐传记电影套路化叙事的显著差异。

关键数据与发现

• 成名时长极短：大多数进入Billboard Top 40的艺人，其主流认可期不到一年，通常仅为3至4个月（如乐队Of Monsters And Men）。仅有约1%的极少数巨星（如Elton John）能维持20年以上的文化影响力。短暂爆红后迅速过气并彻底转行是常态（如Tommy Tutone乐队主唱转行成为程序员）。
• 成名年龄年轻化：流行音乐是“年轻人的游戏”。多数音乐人在30岁前（通常是20多岁）获得首支Top 40热门歌曲。
• 预期寿命较短：基于历史名人数据库的分析显示，音乐明星的预期寿命在所有职业中处于最低梯队，与拳击手、军人和赛车手相当。这侧面印证了“27岁俱乐部”现象，反映了早期成名带来的巨大压力与潜在健康危害。

心理动机与决策分析

文章引入决策理论，解释了为何在极低的成功率和短暂的生涯预期下，仍有人渴望成为主流明星：

• 反事实思维（Counterfactual Thinking）：人们会构建关于生活的替代场景，权衡“短暂拥有名气后失去”与“从未实现梦想”两种结果，思考不同选择对人生轨迹的影响。
• 遗憾最小化（Regret Minimization）：娱乐行业是“赢家通吃”的锦标赛模式。尽管成名概率极低，但为了避免未来产生“如果当初尝试了会怎样”的遗憾，这种对遗憾的厌恶成为了强大的驱动力，促使人们追求看似不可能的梦想。

结论

统计数据表明，音乐明星的生涯往往在年轻时短暂绽放后迅速消亡，且现实中极少有电影中那种“最终救赎”的完美结局。然而，出于对未来遗憾的恐惧和对音乐热爱的追求，人们依然无视残酷的统计概率，前赴后继地投身于这一充满风险的行业。

根据德国联邦交通部的回复，越来越多的德国铁路（Deutsche Bahn）列车因严重晚点而被禁止进入瑞士。这一情况在2024年第一季度显著加剧。

核心要点如下：

1. 现象加剧：2024年第一季度，超过十分之一（约11%）的德国列车在瑞士边境被拦截，无法继续行程。与2023年仅2%的受影响率相比，增幅显著。
2. 具体线路数据：
   • 慕尼黑-苏黎世线：11%的列车被阻止入境。
   • 弗莱堡-巴塞尔线：受影响比例高达12.4%。
3. 措施背景：该规定由瑞士联邦铁路（SBB）与德铁协商后，于2022年7月作为一项“临时措施”引入，旨在确保瑞士铁路网的准点率。目前该措施已成为永久性规定。
4. 具体规则：SBB为慕尼黑-苏黎世线的欧洲城际列车（Eurocity）提供10分钟的缓冲时间，为弗莱堡-巴塞尔线的ICE高速列车提供15分钟的缓冲时间。若德铁列车超出此缓冲时间仍晚点，其运行路径将被重新分配，列车需在边境停运。
5. 瑞士的考量：瑞士铁路系统准点率极高（2023年为92.5%），而德国长途列车准点率较低（同年仅为64%）。因此，拦截晚点的德国列车是SBB保护本国铁路网络高效运行的必要手段。

Jepsen: Jetcd 0.8.2 分析摘要

Jepsen对etcd官方Java客户端库jetcd进行了独立分析，发现其在0.6.0至0.8.2版本中存在一个严重的安全缺陷。该缺陷源于一个不当的重试机制，导致非幂等请求在不安全的情况下被自动重试，从而引发多种一致性异常。

核心问题

当应用程序调用如Txn.commit()时，jetcd可能会自动重试，发送多个相同的网络请求副本。问题在于，客户端在请求可能已成功执行或操作非幂等的上下文中进行了重试。这会导致在进程崩溃或网络丢包时，出现以下几种违反etcd预期一致性保证的行为：

1. 丢失更新：一个事务的更新被静默丢弃，因为客户端秘密提交了同一事务两次，后续事务读取了不同的版本。
2. 循环信息流：事务之间出现因果环，一个事务的执行效果被另一个尚未执行的事务观测到，违反了读已提交及以上的一致性模型。
3. 中止读取：一个已经中止（从未成功提交）的事务的效果，被后续事务观测到。即使在使用了带版本检查的条件写入时也会发生。

测试与发现

Jepsen使用list-append和wr-register工作负载进行测试，并模拟了进程崩溃故障。通过抓包分析（使用tcpdump和Wireshark），确认了jetcd客户端在单一事务调用下发送了重复的网络请求，直接导致了上述异常。

影响与现状

• 影响版本：jetcd 0.6.0 至 0.8.2。
• 问题持续时间：该问题已被报告超过两年半。
• 当前状态：官方尚无补丁。相关issue（如jetcd-1072）未得到及时解决。

建议与临时解决方案

• 立即缓解措施：在创建客户端时通过ClientBuilder.retryMaxAttempts(0)禁用重试机制。这可以有效避免上述问题。
• 根本原因分析：问题在于客户端库未能妥善区分确定性失败（如节点明确拒绝执行）和不确定性失败（如请求可能已发送）。对于后者以及非幂等操作，重试是不安全的。
• 长期建议：分布式系统工程师应谨慎设计重试逻辑，并对客户端库进行严格的安全性测试。etcd和jetcd团队应建立机制，共同解决官方客户端库中的关键安全问题。

注意

本次分析专注于jetcd客户端库，而非etcd服务器本身。服务器可能仍存在其他未发现的问题。

文章标题：用五金店基础零件从零打造的二冲程发动机

文章内容摘要：

• 项目背景：Camden Bowen 挑战不依赖深入文献研究，仅通过基础设计（使用OnShape CAD建模）和五金店材料，手工制造二冲程内燃机（ICE）。
• 所需材料与工具：主要使用金属管材等五金店可购零件，配合焊机和车床（使用Vevor迷你车床）进行加工，辅以角磨机等工具。
• 制作难点与解决方案：内燃机要求零件高精度、低摩擦，但车床精度不足（如镗杆晃动）。通过焊接加固镗杆、改进加工方法，实现了必要的精度。
• 关键部件制造：自制了曲轴箱、汽缸、曲轴等核心部件；化油器选用Amazon产品，经尺寸调整（从19mm改为13mm）后适用。
• 失败与改进：首次试制因发动机干磨（未加油）和启动液溶解作用导致损坏；第二次重建后加入曲轴箱机油，使用40:1燃油混合比，成功运行。
• 最终成果：发动机能怠速和运行，冒蓝烟、噪音大，证实了用基础机械技能和工具制造二冲程ICE的可行性。文章末尾引发对制造四冲程发动机难度的猜想。

Mouse Pong：通过视觉暂留光标在鼠标固件中玩游戏

概述

该项目实现了一个在鼠标固件中运行的乒乓球游戏，通过将光标快速移动到多个位置，利用视觉暂留效应在屏幕上呈现游戏画面。游戏通过点击滚轮启停，鼠标其他功能正常。

硬件配置

• 核心硬件：Seeed Studio XIAO RP2040开发板
• 通过TinyUSB库，该开发板可同时作为自定义USB设备和主机
• 将廉价HP鼠标的USB连接从内部断开，接入XIAO的USB端口（连接到计算机）
• 使用XIAO的电源/GPIO引脚连接辅助USB端口，回到原鼠标PCB
• 形成可编程的USB拦截器

技术原理

定位模式

• 现代鼠标通常使用相对定位：报告移动变化量
• 本项目实现了绝对定位的USB鼠标：可发送屏幕上的精确位置（X百分比，Y百分比）
• 该技术通常用于触摸屏驱动程序

视觉暂留实现

• 固件快速将光标移动到多个关注点
• 移动速度足够快，使光标看似同时出现在多个位置
• 利用人眼的视觉暂留效应呈现完整游戏画面

游戏机制

• 游戏完全在鼠标固件内运行
• 当游戏激活时，光标的关注点为：
  • 两个挡板
  • 球
• 得分显示：当一方得分后，光标会显示在左右挡板之间的某个位置
  • 光标越靠近某挡板，该玩家领先分数越多
  • 光标在中间表示分数持平

设置步骤

1. 硬件准备：需要任何基于RP2040的开发板，通过第二个USB端口连接。推荐使用Adafruit Feather RP2040 with USB Host
2. 环境配置：按照Adafruit指南设置Arduino IDE
3. 库安装：
   • Adafruit TinyUSB库
   • Pico PIO USB库
4. 引脚配置：确保USB D+/D-引脚正确设置
5. 构建运行：编译并运行项目

其他信息

• 该项目作者还制作了鼠标/键盘效果踏板
• 完整演示视频：mouse_pong_720.mov

背景与日本内部分歧

广岛和长崎遭受原子弹轰炸后，日本政府内部陷入严重分歧。文官派担忧苏联入侵，主张在保留天皇制的前提下投降；军方派则主张抵抗到底，并误判美国原子弹数量有限。

美国的核武准备与施压

美国当时仅够制造第三颗原子弹的钚核心，预计8月17日至19日可用。杜鲁门总统下令未经其直接授权不得再投放核武器，但通过声明和恢复常规燃烧弹轰炸持续向日本施压，并制定了在8月19日或之后天气允许时投掷第三颗原子弹的应急计划。

目标城市推测

第三颗原子弹的具体目标未公开。由于东京正在进行和平谈判，不太可能成为目标。外界推测目标可能是受损较轻的横滨或札幌，但最可能是原为第二颗原子弹首选目标的小仓，或同在候选名单上的新潟。

战争结束与天皇制保留

8月14日深夜，日本内阁在天皇敦促下最终决定接受无条件投降，第三颗原子弹因此未被使用。美国最终同意了日本保留天皇制的要求，以此维持战后社会秩序稳定，并将其培养为冷战时期的盟友。

“恶魔核心”的致命事故

未使用的第三颗原子弹钚核心被送往洛斯阿拉莫斯实验室进行临界质量实验。1945年8月和1946年5月，该核心在实验中先后发生两次临界事故，导致物理学家哈里·达格利恩（Harry Daghlian）和路易斯·斯洛廷（Louis Slotin）遭受致命辐射死亡。这枚钚核心因此获得了“恶魔核心”（Demon Core）的恶名。

最终归宿

“恶魔核心”原计划用于1946年7月“十字路口行动”的第三次核爆测试（Charlie），但该测试最终被取消。1946年8月，该核心被熔化，其钚材料被重新用于制造新的原子弹核心。

Argdown 概述

Argdown 是一种专为复杂论证映射（Argument Mapping）设计的轻量级语法，其设计理念类似于 Markdown。它旨在让用户通过简单的纯文本代码，轻松构建和分析复杂的逻辑论证关系，并实时生成可视化的论证映射图。

核心特点

• 简单易用：语法规则自然且易于掌握，编写论证的优缺点如同发布短消息一样简单，无需学习复杂的新概念。
• 表达力强：不仅能定义论证之间的复杂支持或反对关系，还能深入展示逻辑上的“前提-结论”结构细节。
• 功能强大：可无缝嵌入 Markdown 中使用，支持代码输入时实时转化为论证映射图，并能将结果导出为 PDF、图片，或作为 Web 组件嵌入网页。

语法结构

Argdown 的核心语法由以下三个基本要素组成：

1. 嵌套的优缺点列表：

   • 使用方括号 [...] 定义声明（Statement）标题，使用尖括号 <...> 定义论证（Argument）标题。
   • 通过缩进和 +（支持/Pro）、-（反对/Con）符号来构建论证之间的嵌套与攻防关系。
   • 支持使用 #标签（Hashtags）对声明和论证进行分类或着色。

2. 前提-结论结构：

   • 使用带括号的数字 (1), (2) 等详细列出逻辑前提。
   • 使用分隔符（如 -- 或 ----）区分前提与结论，或标明推理规则（如肯定前件式 Modus ponens、最佳解释推论等）。
   • 使用 -> 符号将结论指向特定的声明或其他论证，以建立严密的逻辑链接。

3. 类 Markdown 文本格式：

   • 兼容大部分 Markdown 文本格式化功能（如标题、加粗、斜体、链接等），用于丰富论证内容的展示。
   • 使用 Markdown 标题（Headings）对映射图中的声明和论证进行逻辑分组。

开发工具与生态

为了提升使用体验，Argdown 提供了多种工具和环境支持：

• 浏览器沙盒（Browser Sandbox）：提供在线编辑环境及生成映射图的实时预览功能，适合快速上手。
• VS Code 扩展：提供完整的语言支持，包括实时预览、语法高亮、内容辅助、代码检查（Linting）及多种导出选项。
• 命令行工具（CLI）：允许用户通过配置文件定义自定义流程，并结合任务运行器（Task Runner）批量导出同一文档的多个论证映射图。
• 专属字体：提供免费的 ArgVu 字体，包含 Argdown 专用的连字（Ligatures）和字形，优化代码阅读体验。

注意事项

在编写 Argdown 代码时，需确保顶层元素之间使用空行进行分隔，以避免生成意外的映射结果。如遇语法问题，可查阅官方语法规则或在 GitHub 提交 Issue。

Gazette 项目概览

Gazette 是一个专注于云原生、毫秒级延迟流处理（Cloud-native millisecond-latency streaming）的开源项目。其代码托管页面主要展示了以下两个使用 Go 语言编写的公开仓库：

1. core（核心仓库）

• 核心功能：作为项目的主代码库，旨在构建能够灵活混合 SQL、批处理（batch）和流处理（stream processing）等多种数据处理范式的底层平台。
• 项目状态：拥有 791 个 Stars 和 57 个 Forks，是该项目的主要核心组件。

2. ping-pong（示例仓库）

• 核心功能：提供一个基础的 Gazette 消费者（consumer）应用程序示例。该示例通过实现“ping-pong”交互逻辑，向开发者演示了如何基于 Gazette 构建和运行大规模（At Scale）的流处理消费应用。
• 项目状态：拥有 15 个 Stars，最后更新于 2020 年 7 月 8 日。

总结：Gazette 项目通过 core 仓库提供融合多种处理范式的高性能流处理平台基础，并借助 ping-pong 仓库为开发者提供大规模消费者应用的实践参考。

Qwen2-Math 模型系列总结

核心概述

Qwen2-Math 是基于 Qwen2 大语言模型构建的、专注于数学推理能力的专业化模型系列。该系列包含基础模型（Qwen2-Math-1.5B/7B/72B）和指令微调模型（Qwen2-Math-Instruct-1.5B/7B/72B）。其旗舰模型 Qwen2-Math-72B-Instruct 在多项数学基准测试中，性能超越了包括 GPT-4o、Claude-3.5-Sonnet 和 Llama-3.1-405B 在内的领先模型。目前模型主要支持英语，双语（英中）版本计划很快发布。

技术细节

1. 基础模型 (Qwen2-Math)

• 初始化与训练：以 Qwen2-1.5B/7B/72B 为基础，在精心构建的数学专用语料库上进行预训练。该语料库包含高质量数学网页文本、书籍、代码、考试题目以及由 Qwen2 合成的数学预训练数据。
• 评估：在英语基准（GSM8K, MATH, MMLU-STEM）和中文基准（CMATH, 高考数学填空题、高考数学问答题）上，采用少样本思维链提示进行评估。

2. 指令微调模型 (Qwen2-Math-Instruct)

• 训练方法：
  1. 基于 Qwen2-Math-72B 训练了一个数学专用奖励模型。
  2. 结合该奖励模型的密集信号与答案正确性的二元信号，通过拒绝采样构建 SFT 数据。
  3. 在 SFT 之后，使用群组相对策略优化 (GRPO) 进行强化学习。
• 评估：在广泛且更具挑战性的英语和中文数学基准上评估，包括 OlympiadBench、AIME2024、AMC2023、高考（2024）、中国中考（2024）等。报告了贪婪解码、Maj@8 和 RM@8 的性能。结果表明，RM@8 通常优于 Maj@8，尤其在较小模型上，验证了奖励模型的有效性。

性能与案例

• 竞赛数学能力：模型展示了能够解决简单数学竞赛题的能力。文章提供了多个来自 IMO 短名单、国际奥赛、Baltic Way 等高难度竞赛的案例，模型均给出了完整的解答过程（文中注明解答由模型生成，不保证完全正确）。

数据净化

为确保评估结果的可靠性，对预训练和后训练数据进行了严格的去污染处理：

• 预训练数据：针对 GSM8K、MATH 等数学数据集，使用精确匹配和 13-gram 去重（最长公共子序列比例大于 0.6）来移除与测试集重叠的样本。
• 后训练数据：使用相同方法，移除了与 GSM8K、MATH、Aqua、AIME24、AMC23 等评估基准有重叠的积极污染样本。

总结

Qwen2-Math 是专为提升数学推理能力而打造的模型系列。其顶级模型在数学任务上展现了超越当前最先进商业模型的性能。模型当前仅支持英文，但即将推出双语（英中）版本，多语言模型也在开发计划中。团队将持续致力于增强模型解决复杂和挑战性数学问题的能力。

文章摘要：《新闻是信息垃圾食品》(2022)

本文作者认为，现代新闻主要以商业盈利为目的，而非为公民提供有价值的信息。作者通过停止消费新闻（及社交媒体）的个人经历，指出减少此类“信息垃圾”的摄入，显著降低了日常焦虑，并腾出了更多时间用于深度阅读和其他兴趣爱好。

核心观点

1. 新闻的商业模式

   • 现代新闻本质是消费者-商业关系，其目标是通过吸引注意力（等同于金钱的稀缺资源）来维持内容消费。
   • 为实现此目标，新闻倾向于数量而非质量，充斥着大量无用、不相关的信息，旨在娱乐而非告知。
   • 媒体产业高度集中，少数公司控制了绝大部分内容产出，导致信息渠道单一，观点易于受到广告商和股东利益的影响。
   • 成功的标准是“点击量”，这助长了耸人听闻的报道和标题党。

2. 新闻对认知与注意力的危害

   • 消耗注意力：注意力是稀缺资源，而新闻（尤其通过社交媒体推送）持续争夺注意力，具有机会成本，挤占了可用于深度学习、技能培养或现实社交的时间。
   • 导致认知偏差：
     • 确认偏误：新闻易强化我们既有的观点，形成信息回音室，加剧社会极化和极端主义。
     • 可得性偏差：我们过度高估新闻中频繁报道的事件（如空难、枪击案）发生的概率，而低估更常见但报道较少的风险（如心脏病、车祸）。
     • 过度自信：信息消费者可能误以为自己消息灵通、判断更佳，但实则不然，甚至可能做出更糟糕的决策（如加密货币投资）。
   • 引发负面情绪：新闻标题和内容多为负面（愤怒、恐惧、恐怖），长期接触易导致压力、焦虑、抑郁，并对世界产生与现实脱节的悲观看法和不信任感。
   • 制造“关心”与“行动”的幻觉：在社交媒体上分享和讨论新闻，可能让人产生参与感，但实际上通常无法改变任何事情，更多是陷入营销的循环。

3. 对“无知是福”论点的回应

   • 作者反驳“不看新闻就是无知”的观点，认为沉浸在24小时新闻循环中，反而会让人更不了解世界，注意力被分散，且形成扭曲的世界观。
   • 真正重要的信息（与社区、家庭、职业相关）自然会通过其他途径得知，无需主动追逐每一条新闻动态。

4. 改善信息饮食的建议

   • 目标：不是完全脱离信息，而是摒弃低质、碎片化的信息垃圾，转向更高质量、更深度的“精神食粮”。
   • 具体做法：
     • 进行深度阅读：多读书、长文，这些内容更能反映世界的复杂性。
     • 减少或取消新闻订阅：从社交媒体中取消关注新闻账号，甚至考虑删除社交媒体账户。
     • 利用工具：使用稍后阅读应用或阅读纸质书籍，以减少在线诱惑。
     • 重拾有意义的爱好：将时间投入社会科学、园艺、烹饪、编程等需要专注和技能发展的活动中。

引用与延伸

• 作者引用尤瓦尔·赫拉利的观点：“在当今世界，知道该忽略什么，才是真正的力量。”
• 借用尼尔·波兹曼在《娱乐至死》中的论述，对比了奥威尔（恐惧信息被剥夺）和赫勒（恐惧信息过载导致琐碎化）的担忧，指出后者更贴近现实。
• 推荐了 Rolf Dobelli 的《避免新闻：走向健康的新闻饮食》及 Mr. Money Mustache 的博客文章《低信息饮食》作为进一步阅读材料。

总结：作者将现代新闻比喻为“信息垃圾食品”，认为它商业化、碎片化、煽情化，不仅浪费时间，更损害心理健康和认知能力。他主张有意识地远离新闻流，转而追求深度、专注的信息摄入和生活方式，以实现更平静、更充实的生活。

Orbit：径向UI组件化CSS框架

Orbit 是一个用于构建径向（圆形）用户界面的 CSS 框架。它旨在通过提供可组合的元素，帮助开发者节省时间并轻松创建径向UI。

核心概念与组件

该框架的核心是围绕几个基础组件构建的：

• 轨道：作为布局的基础。
• 卫星：放置在轨道上的UI元素。
• 弧线、进度、向量、边：用于构建形状和视觉指示器。
• 弯曲文本：支持沿径向路径排版文本。

通过组合这些预定义的CSS元素，开发者可以构建出诸如圆形菜单等交互式界面。

应用示例与号召

文章中展示了一个圆形菜单的交互演示，用户可以点击按钮进行交互。框架鼓励开发者立即开始使用，以“改造你的项目”，并通过在GitHub上为其项目添加星标（⭐）来表示支持。

文档与社区支持

文档体系较为全面，包括：

• 入门指南：关于、安装、示例。
• 元素详解：重力点、轨道、卫星、向量、边、弧线、进度、胶囊。
• 工具介绍：视觉辅助工具、自动调整、颜色管理。
• 社区渠道：通过 GitHub 和 Telegram 进行交流与支持。

许可证与版权

Orbit 由 ZumerLab 开发，于2023-2025年期间发布，采用 MIT 许可证。

奥运会射击选手面部佩戴的是机械光圈，主要用于气手枪等项目中。该设备通过精细调节，使枪械准星保持清晰对焦。制造商Gehmann是此类产品的代表品牌，同时为不佩戴近视眼镜的运动员提供专用比赛镜框。

选择机械光圈而非普通处方眼镜的主要原因在于：射击过程中选手的视力可能因疲劳和光线条件变化而发生波动，机械光圈的可调节性能实时补偿这种变化。值得注意的是，2024年巴黎奥运会10米气手枪金牌得主、韩国选手吴艺珍（Oh Ye-jin）并未使用机械光圈，成为该装备的特例。

本文探讨了个人数据管理的挑战与解决方案，提出了一个名为“个人数据管道”（PDPL）的系统构想。

核心问题与动机

作者意识到个人数据散落在各个平台（如Strava、Google日历、iCloud联系人等），积累量巨大。虽然希望利用这些数据进行跨服务整合分析（如构建个人CRM、综合运动表现视图、关联行为与情绪等），但存在三大障碍：

1. 数据泄露风险：将数据从一个服务复制到另一个服务会增加泄露风险。
2. 应用依赖与局限：依赖特定应用可能无法满足所有需求，且需要手动导出数据。
3. 服务不可靠性：若应用被收购、关闭或不再可信，用户无法确保数据被完全删除。

因此，作者认为关键是要将数据（尽可能多地）直接控制在自己手中，例如存储在本地或私有云中，以实现备份、自主查询和灵活处理。

解决方案：个人数据管道（PDPL）

受工作中数据管道（ELT模式）的启发，作者构想了一个系统，其核心思想是：从各服务提取原始数据，存入中央存储库（用户可控），再进行转换和组合，最终生成用户需要的形式。这能减少对公司的依赖，增强数据控制和隐私。

PDPL 系统设计

系统由以下模块化组件构成，均可自托管，注重隐私和易用性：

1. 数据获取器：负责从各服务API拉取数据，处理分页、速率限制等，导出为JSON文件。
2. 密钥存储：安全存储API密钥，可由用户自行管理或作为未来付费服务提供。
3. JSON存储库：存放获取的原始JSON数据，可以是本地文件系统或云存储。
4. 处理器：核心组件，对JSON存储中的数据运行转换逻辑。转换通过可共享的“配方”定义，输出格式多样（CSV、JSON、数据库、应用等）。
5. 配方：可复用、可共享的数据转换描述（如使用YAML），定义数据源、关系、转换步骤和输出方式，降低使用门槛。
6. 关系型存储：处理器的输出选项之一，可将转换后的数据存入数据库，便于进一步查询。
7. Web UI（可选、闭源部分）：为非技术用户提供管理、监控和访问数据的简单界面。

系统强调 “文件优于应用” 、本地优先、隐私设计、开源和耐用格式。

实际应用示例：构建个人CRM

作者以创建个人CRM为例，展示PDPL如何工作：

• 输入：Google日历（活动）、iCloud联系人。
• 输出：Obsidian中的每日笔记，包含当天活动及关联联系人信息。
• 过程：处理器根据“配方”连接事件与联系人（通过邮箱匹配），并将格式化的活动信息追加到对应的Obsidian每日笔记文件中。这消除了手动整理数据的负担。

项目现状与邀请

作者已开源了PDPL的核心组件（数据获取器和处理器），提供了初步的教程。这是一个旨在让个人轻松收集、备份、转换和组合自身数据的开源系统，目标是让数据真正处于个人控制之下，并鼓励社区参与和贡献。

Python扩展应该实现懒惰加载

问题背景

一个Python工具大量调用ast.parse，在50万行代码的代码库上耗时约8秒。即使ast模块是用C实现的，性能依然不佳。

性能瓶颈分析

• ast模块工作流程：
  1. _PyParser_ASTFromString将源代码转换为C结构体mod_ty（C到C操作）。
  2. PyAST_mod2obj将整个mod_ty结构体立即转换为Python对象PyObject（C到Python操作）。
• 关键问题：PyAST_mod2obj强制将AST的所有节点和值立即转换为Python对象，导致：
  • 大量内存分配（约5900万次malloc调用）。
  • 显著的垃圾回收开销（约3k次GC，占用35%的运行时间）。

解决方案

将AST处理移入Rust扩展：

• 方法：在Rust中维护紧凑的数据结构，避免构建Python兼容的AST，仅将最终结果返回Python。
• 效果：
  • 运行时从8.7秒降至530毫秒（16倍加速）。
  • 内存压力大幅降低：malloc调用减少至约700万次，无显著GC活动。

懒惰（Laziness）的概念

• 核心思想：避免过早将数据推入Python内存模型。扩展应拥有数据的所有权，仅在必要时懒惰地创建Python对象。
• 类似案例：NumPy数组底层数据由C扩展管理，Python对象按需构建。
• AST应用示例：设计查询API，操作扩展拥有的专用数据（如二进制表示），懒惰地生成Python对象，提升性能。

总结

编译的Python扩展通过懒惰构建PyObject能显著优化性能，减少内存分配和垃圾回收开销，将数据紧凑地保留在扩展语言内部是关键策略。

如何与父母讨论硬件内存安全

核心观点

硬件内存安全技术如CHERI，并非直接为程序提供语言级的安全属性（如内存安全或控制流完整性），而是为编译器提供一套硬件原语和工具，使其能够跨不同编程语言、编译器甚至汇编代码来强制执行这些安全属性。这与早期将特定语言内存模型（如Algol、Lisp）直接固化在硬件中的设计截然不同。

CHERI 的根本理念

• 对象模型是语言层面的概念：内存安全依赖于程序的对象模型（定义对象边界与生命周期），CPU无法感知此模型，因此无法直接“提供”内存安全。
• CHERI 的角色：它不强制一种统一的对象模型，而是提供可组合的硬件基础，让不同语言的编译器能够安全地互操作。例如，Rust编译器可以利用CHERI来保证传递给C函数的借用引用不会被非法捕获或修改。

CHERIoT：面向嵌入式与IoT的优化

CHERIoT 是基于CHERI并针对资源受限设备优化的软硬件平台。它允许一个编译器强制以下关键属性，以对抗程序中的其他不可信代码（无论其源语言如何）：

1. 指针有效性：任何内存访问都必须通过一个由硬件保护的“能力”进行，该能力不可伪造，确保了访问权限的正当性。
2. 不可变性：通过能力上的权限位，可轻松创建不可变引用（浅层或深层），即使底层代码是C或汇编也能强制执行。
3. 不透明引用：利用CHERI的“密封”机制，可以创建类型安全的不透明句柄，防止代码在未授权的情况下直接操作对象内部。
4. 释放后使用防护：通过硬件支持的“释放”位图和“撤销器”，能在内存释放后立即使所有指向该内存的指针失效，防止使用已释放对象。
5. 指针不捕获：结合局部/全局信息流控制和栈清除机制，可以确保传递的指针（如借用引用）不会被函数长期持有或存储到堆中。

硬件与编译器的协作关系

• 硬件提供基础，编译器做选择：CHERI（及CHERIoT）硬件提供了丰富的工具（如权限操作、密封、撤销机制）。编译器根据源语言的需求，自主选择是否及如何使用这些工具。例如，在Rust中，编译器可能广泛使用这些工具来保障安全；而在C中，可能仅在安全边界（如跨部件调用）处使用。
• 旨在增强所有语言：CHERI的目标不是拯救C，而是为所有语言（包括Rust、Java等）提供一个共享且安全的内存交互基础，防止它们相互破坏彼此的安全保证。

总结

与父母讨论时，应强调CHERI类技术并非“魔法”，它不直接给出内存安全，而是像一套高级的“建筑工具”和“安防系统”，让编译器能够为各种编程语言建造出既独立又安全共存的模块，从根本上增强了嵌入式设备等系统的整体安全性。

Neon概述

Neon是一个开源的无服务器Postgres数据库平台。其核心设计是将存储与计算分离，并使用自定义的Neon存储引擎替代了PostgreSQL的原生存储层，通过跨集群节点重新分发数据来实现。

架构概览

一个Neon系统由计算节点和Neon存储引擎组成。

• 计算节点：无状态的PostgreSQL节点，由Neon存储引擎提供支持。
• Neon存储引擎：主要由两个组件构成：
  • Pageserver：为计算节点提供可扩展的存储后端。
  • Safekeepers：构成一个冗余的WAL服务，负责从计算节点接收WAL日志并将其持久化存储，直至被Pageserver处理并上传到云存储。

本地开发环境搭建

Neon可在工作站上运行以进行小型实验和代码测试。

1. 安装依赖

Linux系统

• Ubuntu/Debian:

  apt install build-essential libtool libreadline-dev zlib1g-dev flex bison libseccomp-dev libssl-dev clang pkg-config libpq-dev cmake postgresql-client protobuf-compiler libprotobuf-dev libcurl4-openssl-dev openssl python3-poetry lsof libicu-dev
  

• Fedora:

  dnf install flex bison readline-devel zlib-devel openssl-devel libseccomp-devel perl clang cmake postgresql postgresql-contrib protobuf-compiler protobuf-devel libcurl-devel openssl poetry lsof libicu-devel libpq-devel python3-devel libffi-devel
  

• Arch Linux:

  pacman -S base-devel readline zlib libseccomp openssl clang postgresql-libs cmake postgresql protobuf curl lsof
  

• Rust安装：

  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  

• 注意：构建需要protobuf-compiler版本≥3.15。如果发行版版本过旧，可从此处安装新版本。

macOS系统

• 安装XCode及依赖：

  xcode-select --install
  brew install protobuf openssl flex bison icu4c pkg-config m4
  echo 'export PATH="$(brew --prefix openssl)/bin:$PATH"' >> ~/.zshrc
  

  （若提示缺少m4，可运行brew install m4和brew link --force m4）
• 安装Rust：

  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  

• 安装PostgreSQL客户端：

  brew install libpq
  brew link --force libpq
  

2. Rust工具链版本

项目通过rust-toolchain文件定义构建所需的Rust版本。rustup用户会自动安装并使用该文件指定的工具链。非rustup用户需自行确保本地工具链版本与文件要求匹配。

3. 构建项目

Linux与macOS通用步骤

git clone --recursive https://github.com/neondatabase/neon.git
cd neon
# 默认进行debug构建（性能较release版慢）
make -j`nproc` -s  # Linux
make -j`sysctl -n hw.logicalcpu` -s  # macOS
# 进行release构建：设置 BUILD_TYPE=release

运行Neon数据库

在仓库根目录下执行：

1. 初始化并启动服务：

   cargo neon init
   cargo neon start
   

2. 创建租户和计算节点：

   cargo neon tenant create --set-default
   cargo neon endpoint create main
   cargo neon endpoint start main
   

3. 连接并使用数据库：

   psql -p 55432 -h 127.0.0.1 -U cloud_admin postgres
   

4. 创建分支（示例）：

   cargo neon timeline branch --branch-name migration_check
   cargo neon endpoint create migration_check --branch-name migration_check
   cargo neon endpoint start migration_check
   

   新分支将包含原始分支（如main）的所有数据，但对新分支的修改不会影响原始分支。

测试与清理

• 运行Rust单元测试：推荐使用cargo-nextest（cargo install cargo-nextest）。
• 运行集成测试：

  CARGO_BUILD_FLAGS="--features=testing" make
  ./scripts/pytest
  

  可通过环境变量（如DEFAULT_PG_VERSION=17 BUILD_TYPE=release）指定单个组合进行测试。
• 清理：
  • make clean：清除构建产物。
  • make distclean：彻底清除所有构建和配置步骤的产物，并可删除target目录和.neon数据库目录（注意：这将删除所有数据）。

文档与资源

• 项目文档：docs目录包含所有Markdown文档的概述；sourcetree.md说明了源码树布局。
• 生成文档：cargo doc --no-deps --open 可在浏览器中查看Rustdoc文档。
• 扩展阅读：
  • 《SELECT 'Hello, World'》、《Neon: Serverless PostgreSQL!》等博客和演讲。
  • Neon和PostgreSQL的术语表。
  • PostgreSQL内部机制学习资源。