Arc浏览器远程代码执行漏洞分析

漏洞概述

攻击者可在用户未访问任何网站的情况下，通过篡改Arc浏览器的云端数据实现远程代码执行。该漏洞源于Arc使用Firestore数据库时存在安全规则配置缺陷，结合其"Boosts"（网站自定义样式/脚本）功能，可向任意用户注入恶意代码。

技术原理

1. 架构依赖：Arc强制要求用户登录，并使用Firebase服务存储用户数据。
2. 数据存储结构：
   • 用户偏好设置（preferences/）
   • 用户基础信息（users/）
   • Boosts自定义配置（boosts/）
   • 用户推荐关系（user_referrals/）
3. 关键漏洞：Firestore安全规则允许用户修改自身Boosts记录的creatorID字段。攻击者可将自己的恶意Boost关联到受害者ID，使受害者在访问特定网站时自动加载恶意脚本。

攻击链

1. 获取受害者用户ID：
   • 通过邀请码系统（user_referrals表）
   • 通过公开的Boost快照页面
   • 通过共享的Easel白板功能
2. 创建恶意Boost：在攻击者账户下创建包含恶意JavaScript的Boost配置。
3. 篡改creatorID：通过Firestore API将Boost的creatorID字段修改为受害者ID。
4. 触发执行：当受害者访问对应网站时，Arc自动加载并执行该恶意Boost。

漏洞影响

• 远程代码执行：可在任意网站上下文执行任意JavaScript。
• 权限提升：恶意Boost甚至可在chrome://settings等特权页面执行。
• 隐私泄露：Arc实际上传了用户访问网站的hostPattern数据，违反其隐私政策。

修复措施与时间线

1. 应急响应：
   • 2024年8月25日：研究人员通过加密渠道联系Arc联合创始人
   • 同日完成漏洞验证
   • 2024年8月26日：完成修复并发放漏洞奖金
2. 根本修复：
   • 1.61.1版本修复隐私数据传输问题
   • 后续版本将弃用Firebase服务
   • 新增Boosts禁用功能
3. 长期改进：
   • 启动外部安全审计
   • 建立正式漏洞奖励计划
   • CVE-2024-45489已分配

技术细节

研究人员通过Frida脚本拦截了Firebase SDK的Objective-C方法调用，还原了完整的Firestore查询逻辑：

• 使用firebase.doc()操作偏好设置
• 使用firebase.collection().where()查询Boosts和推荐关系
• 关键过滤字段为creatorID和hostPattern

结论

该漏洞揭示了当移动/桌面应用使用无服务器数据库（如Firestore）时，严格的安全规则配置至关重要。错误的字段权限设计（如允许用户修改其他用户关联数据）会导致严重的跨用户数据污染攻击。Arc在披露后采取了透明的修复措施，并开始向更安全的架构迁移。

Simple Icons 这是一个提供超过3000个免费SVG图标资源的集合，主要专注于流行品牌的图标。

• 内容性质：这是一个开源项目或资源库，旨在为设计师和开发者提供便捷的品牌图标。
• 核心资源：图标以SVG（可缩放矢量图形） 格式提供，适用于网页设计和开发，因其无损缩放和文件轻量的特点。
• 数量规模：图标数量庞大，标题明确指出有3000个以上的免费图标。
• 主要用途：这些图标可用于网页、应用程序或任何需要正确使用品牌标识的数字产品中。
• 访问状态：根据提供的上下文（"0%Loading"），这很可能是一个在线网站或应用的界面片段，用户可从中浏览和获取图标。

该资源的核心价值在于提供了一个集中、免费且标准化的主流品牌SVG图标库。

Linux/4004项目总结

项目概述

该项目在1971年推出的首款商用微处理器Intel 4004（4位）上成功启动完整的Debian Linux系统，旨在刷新在最低端硬件上运行Linux的记录。整个系统基于一块真实4004 CPU的电路板运行，启动过程极其缓慢（约需4.76天），但属于真实Linux内核与根文件系统。

技术挑战与4004架构特性

• 4位限制：4004仅支持4位操作，无逻辑运算指令（AND/OR/XOR），指令集为单操作数。
• 内存系统：内存访问需通过特殊指令（SRC）设置地址，速度缓慢；包含“状态nibbles”作为快速访问存储。
• I/O与外部设备：通过4289芯片连接外部ROM，支持SPI接口的SD卡、PSRAM、VFD显示屏和UART串口。
• 性能瓶颈：模拟32位MIPS架构需大量循环和查找表，每条4004指令需8或16时钟周期。

实现方法

1. 模拟方案：在4004上模拟MIPS R3000架构运行Linux，使用超调用处理磁盘I/O等操作。
2. 硬件设计：
   • 开发板包含4004、4289（ROM控制器）、4002（RAM）、SPI PSRAM（内存）、SD卡（存储）、VFD显示屏和UART芯片。
   • 使用电平转换电路适应MCS-04芯片的-10V电压和反相逻辑。
3. 性能优化：
   • 通过查找表优化逻辑运算和乘法。
   • 展开循环、优化内存拷贝和移位操作。
   • 裁剪Linux内核配置，减少不必要的驱动和功能。
   • 实现ROM银行切换以扩展代码空间。
4. 启动流程：
   • 固件初始化硬件，探测RAM大小和TLB条目数。
   • 从SD卡加载引导程序，最终启动Linux内核。

最终成果

• 系统性能：模拟MIPS CPU主频约70-75Hz，启动至Shell需4.76天。
• 硬件成本：1970年代芯片成本较高（如4004约250美元），现代组件相对廉价。
• 艺术表达：电路板设计为可挂墙的艺术作品，使用VFD显示屏绘制曼德勃罗集等图案，计划在设备上编译Linux内核作为长期艺术项目。
• 可复现性：提供了完整原理图、BOM、固件源码和磁盘镜像，支持他人复现。

SSH隧道与端口转发图解指南摘要

概念与用例

SSH隧道和端口转发用于通过安全的SSH连接转发TCP流量。主要应用场景包括：

• 安全：加密不安全协议（如FTP）；通过公钥认证安全访问Web管理面板；减少暴露的端口数量（仅需22端口）。
• 故障排除：绕过防火墙/内容过滤器；选择不同的网络路由。
• 连接：访问NAT后面的服务器；使用跳转主机通过互联网连接内部服务器；将本地端口暴露到互联网。

前提配置

• 用户在本地和远程机器上需有打开端口的权限（0-1024端口通常需要root权限）。
• SSH服务器必须启用端口转发（AllowTcpForwarding yes，默认已启用）。
• 若要在非回环地址（如127.0.0.1）上转发端口，需在SSH服务器配置中启用GatewayPorts yes。

SSH跳转主机

通过-J选项通过一个或多个中间主机透明连接到远程主机。

ssh -J user@跳转主机:22 -p 22 user@内部服务器IP

多个跳转主机需用逗号分隔。

端口转发类型

本地端口转发 (-L)

将远程服务器的端口映射到本地端口。

• 示例1：ssh -L 10.10.10.1:8001:localhost:8000 user@远程主机。本地访问10.10.10.1:8001等同于访问远程主机的localhost:8000。
• 示例2：ssh -L 8001:10.99.99.1:8000 user@远程主机。本地访问localhost:8001等同于访问远程主机所在网络内的10.99.99.1:8000。

远程端口转发 (-R)

将本地机器的端口暴露给远程服务器的网络。

• 示例：ssh -R 8000:localhost:8001 user@远程主机。在远程主机上访问localhost:8000等同于访问本地机器的localhost:8001。
• 若要在远程主机的其他网络接口（非回环地址）上监听，必须在SSH服务器启用GatewayPorts yes。

动态端口转发 (-D)

利用SOCKS5协议创建透明代理，适用于转发多个端口。

• 示例：ssh -D 10.10.10.1:5555 user@远程主机。将本地10.10.10.1:5555设置为SOCKS5代理服务器，流量经由远程主机路由。
• 客户端应用程序需配置为使用该SOCKS代理。

SSH TUN/TAP隧道 (-w)

可使用-w标志创建双向TCP隧道，但需要预先创建网络接口，文中作者表示尚未测试。

管理与维护

• 后台运行：使用-fN参数（-f 后台运行，-N 无远程Shell）。

  ssh -fN -L 8001:127.0.0.1:8000 user@远程主机
  

• 终止后台连接：通过ps查找进程ID并使用kill命令终止。
• 保持连接存活：可通过客户端配置ClientAliveInterval和ClientAliveCountMax发送心跳包防止超时。断线重连需借助外部工具（如autossh）。

限制与注意事项

1. 不支持UDP：SSH依赖可靠传输，而UDP无可靠性保证。
2. TCP-over-TCP问题：可能导致性能下降、延迟增加，在丢包或高延迟网络中可能引发“TCP meltdown”。
3. 非VPN替代品：虽然可用作类似VPN的用途，但专业VPN性能更优。
4. 潜在安全风险：如无需要，建议禁用相关功能，以防威胁行为者利用其绕过防火墙等安全措施。

参考：本文总结了SSH隧道与端口转发的核心概念、配置方法、不同类型转发的用途、管理技巧及其局限性。具体细节、示例日志和完整配置请参阅原文。灵感来源于Unix StackExchange问答及Dirk Loss的博客文章。

FTC报告揭示社交媒体和视频流媒体公司的大规模用户监控行为

美国联邦贸易委员会（FTC）发布的一份工作人员报告显示，主要的社交媒体和视频流媒体服务公司大规模监控消费者，以将其个人信息货币化，同时未能充分保护用户（尤其是儿童和青少年）的在线安全。

调查背景与对象 该报告基于FTC于2020年12月根据6(b)条款向九家公司发出的信息获取令。被调查公司包括亚马逊（旗下拥有Twitch）、Meta（原Facebook）、YouTube、X Corp.（原Twitter）、Snap、字节跳动（旗下拥有TikTok）、Discord、Reddit和WhatsApp。调查内容涉及公司如何收集、跟踪和使用个人及人口统计数据，如何决定向用户展示的内容，以及它们的做法对儿童和青少年的影响。

核心发现

1. 海量数据收集与留存：报告发现，这些公司收集并可无限期保留海量数据，包括从数据经纪商获取的信息，以及平台用户和非用户的信息。许多公司的数据收集、最小化和留存做法被评价为“极其不足”。此外，部分公司未能响应用户的删除请求而完全删除其数据。

2. 以广告为核心的商业模式驱动数据监控：许多公司的商业模式激励了大规模收集用户数据以进行货币化，特别是通过定向广告实现盈利，这与其收入的绝大部分来源。报告指出，这种激励机制与用户隐私保护存在根本性冲突。

3. 广泛的数据共享与隐私风险：公司间存在广泛的数据共享，引发了对其数据处理控制和监督充分性的严重担忧。一些公司部署了侵犯隐私的追踪技术（如像素标记）来促进基于用户兴趣的广告投放，增加了身份盗窃、跟踪骚扰等风险。

4. 自动化系统缺乏透明度与用户控制：公司将用户和非用户的个人信息广泛用于其算法、数据分析和人工智能等自动化系统中。报告指出，用户几乎没有或完全没有途径选择退出其数据在这些系统中的使用，且各公司在监控和测试这些系统方面的做法不一、不一致且不充分。

5. 对儿童和青少年保护严重不足：

   • 报告指出，许多公司声称其平台没有儿童用户，以此试图规避《儿童在线隐私保护法》（COPPA）规则下的责任，但报告认为这是一种明显的回避行为。
   • 对于青少年，大多数公司将其视为成年用户，允许他们在平台上创建账户而没有设置特殊限制，缺乏足够的隐私保护。

6. 潜在的市场竞争影响：报告注意到，大量积累用户数据的公司可能借此获得市场主导地位，这可能导致损害用户隐私的恶性竞争。在社交媒体和视频流媒体服务竞争有限的情况下，消费者的选择权也会受到限制。

政策建议 基于调查结果，FTC工作人员向政策制定者和企业提出了一系列建议：

• 立法层面：国会应通过全面的联邦隐私立法，以限制监控、建立基线保护并赋予消费者数据权利，特别是填补COPPA对13岁以上青少年保护的空白。
• 企业层面：
  • 限制数据收集，制定具体、可执行的数据最小化和保留政策。
  • 限制与第三方及关联公司的数据共享，在数据不再需要时予以删除。
  • 采用清晰、简单、易于理解的消费者友好型隐私政策。
  • 不应通过侵犯隐私的广告跟踪技术收集敏感信息。
  • 审查基于敏感类别进行广告定向的政策和做法。
  • 解决用户对自动化系统数据使用缺乏控制权和透明度的问题，并实施更严格的测试和监控标准。
  • 不得无视平台上存在儿童用户的现实，应将COPPA视为最低要求并提供额外安全措施。
  • 应认识到青少年不同于成年人，为其提供更强的隐私保护。

报告发布 该工作人员报告已获得FTC委员会5-0一致投票通过。主席莉娜·汗及其他委员分别发表了声明。

CuPy 总结

核心定位 CuPy 是一个与 NumPy 和 SciPy 兼容的 Python 数组库，专为 GPU 加速计算而设计。它可作为 NumPy/SciPy 的直接替代品，使现有代码能够在 NVIDIA CUDA 或 AMD ROCm 平台上运行。

主要特性

• 兼容性：提供了与 NumPy 和 SciPy 高度一致的 API，便于将现有 CPU 代码移植到 GPU 上执行。
• GPU 加速：所有核心计算在 GPU 上进行，显著提升数值计算任务的性能。
• 低层访问：除了高层数组操作，还允许用户通过 RawKernels、Streams 或直接调用 CUDA Runtime API 来访问底层的 CUDA 功能，以满足高级定制化和性能优化需求。

安装方式 提供多种便捷的安装途径，用户需根据平台（CUDA 版本、ROCm 版本）和架构（x86_64, aarch64 等）选择对应的命令。

1. Pip：可通过 pip install 命令安装预编译的二进制包。例如：
   • 对于 CUDA 12.x: pip install cupy-cuda12x
   • 对于 ROCm 7.0 (实验性): pip install cupy-rocm-7-0
2. Conda：通过 Conda-Forge 通道安装，例如 conda install -c conda-forge cupy。支持指定 CUDA 版本和进行轻量化安装（仅安装核心）。
3. Docker：可使用 NVIDIA Container Toolkit 运行预构建的 CuPy 容器镜像。

资源与生态

• 提供详细的安装指南（含源码构建）、API 参考文档、示例和教程。
• 列出了基于 CuPy 构建的项目和相关的会议演讲资源（如 GTC、ICASSP）。
• 自 v13.0.0 版本起，cuSignal 信号处理库已正式合并至 CuPy 中。

开发与许可

• 采用 MIT 许可证 开源。
• 设计基于 NumPy 和 SciPy 的 API。
• 由 Preferred Networks 和社区贡献者共同开发和维护。
• 项目具有学术研究背景，其核心论文发表于 NIPS 2017 会议的 LearningSys 研讨会。

通过强化学习训练语言模型进行自我纠正 (SCoRe)

研究背景与挑战

自我纠正（Self-correction）是大语言模型（LLMs）的理想能力，但在现代 LLMs 中通常效果不佳。现有的训练方法多依赖多个模型、更高级的模型或额外的监督信号。研究表明，仅在离线生成的纠正轨迹上进行监督微调（SFT）往往无法有效培养自我纠正行为，主要面临两大挑战：

1. 分布不匹配：数据收集策略产生的错误与模型自身响应之间存在分布差异。
2. 行为崩溃（Behavior Collapse）：模型在训练中隐式偏好某种特定的纠正模式，而该模式在实际测试问题上通常无效。

提出方法：SCoRe

为解决上述缺陷，研究团队提出了一种名为 SCoRe 的多轮在线强化学习（RL）方法。该方法完全利用模型自生成的数据，显著提升了 LLM 的自我纠正能力。

核心机制与结构

SCoRe 在模型自身生成的纠正轨迹分布下进行训练，并采用适当的正则化手段，引导模型学习在测试时真正有效的自我纠正行为，而非单纯拟合特定提示下的高奖励响应。其正则化过程包括两个关键阶段：

1. 抗崩溃的策略初始化：首先在基础模型上进行多轮强化学习，生成一个不易发生行为崩溃的初始策略。
2. 奖励放大：随后引入奖励加成（reward bonus）机制，进一步放大和强化模型的自我纠正行为。

实验结果

在 Gemini 1.0 Pro 和 Gemini 1.5 Flash 模型上的实验表明，SCoRe 实现了当前最优（SOTA）的自我纠正性能。在 MATH 和 HumanEval 基准测试中，该方法使基础模型的自我纠正能力分别提升了 15.6% 和 9.1%。

苹果在iPhone 16中使用JPEG XL的原因及其对照片的影响

JPEG XL 概述 JPEG XL是一种于2022年初正式标准化的下一代图像编码标准。苹果的多个操作系统和应用程序（如Finder、Preview、Photos、Safari等）已支持该格式至少一年。Adobe的Camera Raw和Lightroom Classic也已支持。尽管技术优势明显，但该格式尚未被广泛采用，例如Chrome和Firefox浏览器仍不默认支持。

核心技术优势

• 压缩效率与质量：JPEG XL能在大幅减小文件体积（相比标准JPEG最多可减少55%）的同时，提供“无与伦比的每字节质量”，生成视觉无损的更清晰图像，消除典型JPEG伪影。
• 先进特性支持：支持广色域、高动态范围（HDR）图像，每通道支持高达32位，兼容RGB、CMYK、YCgCo和XYB色彩空间（XYB基于人类视觉生理设计，优化数据存储），支持多帧、图层和开源。
• 解决JPEG历史问题：克服了已有30年历史的JPEG格式的诸多缺陷，如仅支持8位色深、不支持HDR和透明度、存在压缩伪影和色带等问题。

苹果采用的原因与方式 苹果在iPhone 16 Pro中采用JPEG XL，主要看重其图像质量提升和压缩性能。例如，一个32MB的JPEG照片在无损JPEG XL格式下约为24MB，而在感知无损格式下仅约5MB。 苹果将JPEG XL照片封装在DNG容器中用于ProRAW文件，这使得专业RAW文件在保持灵活性的同时，体积显著缩小（最多可缩小近五倍）。一个约75MB的ProRAW Max文件，在使用JPEG XL压缩的有损ProRAW格式下仅约20MB，无损格式也不到50MB。

优势与潜在问题

• 优势：显著节省存储空间，同时不牺牲质量；更小的文件尺寸意味着更少的数据存储和能源消耗，具有积极的环境影响。
• 现状与挑战：JPEG XL尚未被普遍支持。文件被封装在DNG容器中，不能直接导出为.jxl文件。该格式能否像JPEG一样普及存在不确定性，且可能面临兼容性挑战（例如早期的HEIC格式推广过程）。
• 生态影响：苹果作为行业领导者的支持，可能推动其他公司（如三星今年已在Galaxy手机中支持）跟进，从而促进格式的普及。

结论 对于身处苹果生态系统（iOS 17+、macOS 14+）的用户而言，采用JPEG XL带来的存储节省和画质优势远大于潜在的兼容性烦恼。尽管跨平台支持仍在发展中，且存在反向转码等技术需求，但JPEG XL无疑是比传统JPEG更优越的图像格式。苹果的采用为其广泛传播迈出了重要一步。

Openpilot 概述

Openpilot 是一个用于机器人的操作系统，其主要应用场景是车辆驾驶辅助系统。它是一个开源项目，由 comma 公司及社区用户共同开发。

使用前提

在车辆上部署 Openpilot 需要四项基本组件：

1. 支持的设备：需要 comma four 设备。
2. 软件：在 comma four 设置过程中输入特定的软件 URL 进行安装。
3. 支持的车辆：兼容超过 300 种车型。
4. 车辆线束：用于将 comma four 连接至车辆。

虽然也存在其他硬件运行的可能，但官方提供的方案是即插即用的。

软件版本（分支）

软件提供多个预构建分支以适应不同需求：

• release：稳定发布版。
• staging：发布前的测试版，可较早获得新功能。
• nightly：最新的开发版，不稳定。
• nightly-dev：包含针对特定车型的实验性功能开发版。

开发与参与

项目欢迎社区参与，可通过 GitHub 提交代码（Pull Request）或报告问题（Issue）。相关资源包括社区 Discord、贡献文档、开发工具以及官方代码文档。

安全性与测试

项目遵循 ISO26262 安全指南，并建立了一套多层级测试体系：

• 软件在环测试：每次代码提交都会运行。
• 安全模型：核心安全逻辑由 C 语言编写，位于 panda 仓库中，并有独立的测试。
• 硬件在环测试：在内部测试环境中使用多台设备持续运行测试。

许可与免责

• 许可证：主体采用 MIT 许可证，部分组件可能使用其他许可证。
• 重要声明：该软件仅为研究目的的阿尔法质量版本，并非成熟产品。用户需自行负责遵守当地法律法规，且软件不提供任何明示或暗示的担保。用户需对使用该软件承担全部责任。

用户数据与隐私

• 数据收集：默认情况下，Openpilot 会收集并上传驾驶数据（包括道路摄像头、CAN 总线、GPS、IMU 等传感器数据）至云端，用于模型训练与改进。
• 用户控制：用户可选择禁用数据收集。
• 隐私政策：使用该软件即表示同意其隐私政策，理解并授权 comma 公司收集、使用相关数据。司机摄像头和麦克风数据仅在用户明确开启时才会被记录。

文章标题：Zb: An早期构建系统

作者Roxy Light决定将其实验性项目Zb发展为一个成熟的构建工具。此前的计划是不将其开发到生产就绪状态，但以下因素促使作者改变了主意：

• 个人项目需要一个依赖管理解决方案，且作者不愿继续投入Nix。
• 许多项目可以从更好的依赖管理/构建工具中受益，尤其是在全行业日益关注供应链安全的背景下，作者相信Zb能够满足此需求。
• Zb开发过程本身充满乐趣，为复杂的构建模型提供简洁接口是一项有趣的挑战。

作为构建系统，Zb提供以下特性：

1. 熟悉的配置语言：使用Lua，以避免引入重大的编程语言障碍。Lua被广泛用于提供脚本功能，其小代码库使得为Zb进行扩展（例如在每个字符串中包含依赖信息）变得直接明了。
2. 强大的构建功能：在《Build systems à la carte》的语境下，Zb是一个带有构造性跟踪的挂起调度器。这使其属于该论文中设想的“Cloud Shake”类别。因此，Zb支持早期截止优化（以加速构建）和动态依赖（即Lua配置可以读取构建目标的文件）。
3. 支持非确定性构建：Zb通过重新运行非确定性构建步骤，并在可能时重用工作成果来处理构建中的非确定性。即使构建步骤并非完全确定，或在对等体之间共享构建缓存时，构建结果也不会变得不正确。这降低了从其他构建系统迁移到Zb的摩擦。
4. 与Nix兼容的文件格式：Zb在内部使用与Nix相同的.drv文件格式和归档格式，这使得为Nix存储构建的工具可以被复用。（目前尚无与Nix衍生品明确互操作的方式，但理论上可行。）
5. Windows支持：作者希望建立一个除Linux和macOS外，也能在Windows上工作的构建系统，从而无需跨平台分割工具链。

发展现状与展望：

尽管Zb尚未准备好用于生产环境，但作者已达到一个重要里程碑：Zb不再依赖Nix！作者从头开始编写了一个构建后端，该后端支持内容寻址的衍生品（这是Nix中一个长期存在的实验性功能），更广泛地说，它使用了《The Purely Functional Software Deployment Model》中描述的“内涵模型”。这为Zb未来的利用奠定了坚实的基础。

作者邀请感兴趣者尝试使用Zb（参考项目README），并提醒注意已知问题。欢迎在GitHub上提供反馈。下一个开发目标是完成Linux用户空间，这将使引导其他开发工具变得更加容易。

（文章最后包含作者的咨询业务链接，以及Hacker News和Mastodon上的讨论链接。）

Contextual Retrieval 技术总结

核心问题

传统检索增强生成（RAG）在处理大型知识库时存在局限性：在将文档分割成小块进行编码和检索的过程中，往往会丢失关键上下文信息，导致系统难以准确检索到相关内容。

技术背景：传统RAG的局限

标准RAG系统通常结合了语义嵌入（捕捉含义）和BM25（通过词法匹配进行精确搜索）两种技术。虽然这提升了检索的全面性，但分块处理可能导致单个文本块缺乏足够的上下文，影响检索效果和结果可用性。

解决方案：Contextual Retrieval

该方法通过为每个文本块添加特定于块的解释性上下文来解决上下文丢失问题。它包含两个子技术：

1. Contextual Embeddings（上下文嵌入）：在将文本块转换为向量嵌入之前，为其前置一段生成的上下文。
2. Contextual BM25（上下文BM25）：在构建BM25索引之前，也为文本块前置相同的上下文。

实现方式：使用Claude模型，根据整个文档的内容，为每个文本块生成一个简短的上下文说明（通常50-100个词元），然后将其添加到原始块中。利用Claude的提示缓存功能，可以显著降低处理成本。

性能提升

实验表明，Contextual Retrieval能大幅提高检索准确性：

• 单独使用上下文嵌入：将Top-20检索失败率降低35%（从5.7%降至3.7%）。
• 结合上下文嵌入与上下文BM25：将检索失败率降低49%（从5.7%降至2.9%）。
• 结合上下文检索与重排序：将检索失败率降低67%（从5.7%降至1.9%）。

与其他技术的结合

• 重排序：在初始检索（如返回150个块）后，使用重排序模型（如Cohere）对相关性进行评分并选择最相关的块（如Top 20）输入模型，可进一步优化结果并降低成本。
• 提示缓存：Claude的提示缓存功能使得对大型文档应用Contextual Retrieval在经济上可行，因为它允许一次加载文档并重复使用缓存内容。

实施考量

• 分块策略：块的大小、边界和重叠会影响性能。
• 嵌入模型：所有测试的模型均受益于上下文检索，但Gemini和Voyage的嵌入效果尤其显著。
• 自定义提示：针对特定领域优化上下文生成提示可能带来额外收益。
• 块的数量：实验表明，向模型传递20个块比传递5个或10个更有效，但需在性能与延迟/成本间权衡。
• 评估：始终进行评估以优化设置。

总结建议

为实现最佳性能，推荐组合使用以下技术：

1. 上下文嵌入（来自Voyage或Gemini等优秀模型）。
2. 上下文BM25。
3. 重排序。
4. 向模型传递Top-20个块。

开发者可通过提供的配套实践手册部署自己的Contextual Retrieval方案。

本文深入剖析了英国经济长期停滞的核心原因，指出其根源在于对住房、基础设施和能源这三大经济增长基础的投资被系统性阻碍。文章通过对比法国、韩国等国的案例，揭示了英国在建设能力上的严重落后，并提出了改革建议。

核心论点：增长基础被禁止

英国经济停滞的根本原因并非缺乏投资意愿或战略，而是国家制度阻碍了最有价值的投资。政府通过规划、环保法规等手段，实际上禁止了对住房、交通网络和能源设施的建设，导致：

• 生产率下降：过去16年实际工资增长停滞，人均GDP增长远落后于法国、德国等同类经济体。
• 集聚效应缺失：无法为成功的产业（如生物科技、人工智能）提供足够的住房、办公空间和实验室，限制了其扩张和人才吸引。
• 能源成本高昂：工业电价远高于法国等国，使能源密集型产业难以生存，拖累整体工业竞争力。

主要问题与证据

1. 住房短缺：自1947年《城乡规划法》实施以来，英国建立了全球最严格的规划控制体系。结果是住房供应严重不足（法国住房比英国多700万套），房价飞涨，人口无法向高收入地区流动，加剧了地区不平等。
2. 基础设施昂贵与匮乏：英国大型基建项目（如HS2高铁、核电站、有轨电车）的造价是法国、韩国等国的数倍。高昂成本源于冗长的审批程序、过度设计、频繁的司法挑战以及成本控制激励缺失。
3. 能源危机：英国人均发电量仅为法国的三分之二，且电价高昂。核电站建设中断近30年，新建成本飙升。对风能和太阳能的补贴推高了整个电力系统的成本，却未带来廉价可靠的电力供应。

历史背景与反思

文章回顾了英国曾作为全球首个能源超级大国和基建领先者的辉煌历史，指出二战后国有化时期的低效投资以及1947年后规划制度的引入是转折点。尽管撒切尔时代的私有化改革曾提振经济，但土地规划等核心问题未被解决，留下了隐患。

对流行解释的批驳

作者否定了将停滞归咎于“缺乏政府战略”、“不平等”、“老龄化社会”、“脱欧”或“紧缩政策”的观点。他们认为，这些是次要因素，根本障碍在于物理投资被禁止。即使有投资意愿，现行制度也使其成本极高或无法实施。

解决方案与愿景

文章呼吁进行一场堪比1980年代自由化改革的系统性变革，核心是移除对建设的禁令，降低投资成本：

• 改革规划体系：允许城市向上和向外扩展，释放土地用于住房和产业。
• 简化基建审批：借鉴历史上通过私人法案快速批准项目的做法，减少咨询和法律挑战。
• 拥抱核电：学习韩国“批量建造”模式，大幅降低核电成本，以提供可靠、清洁的基荷电力。
• 激发私营投资：政府无需直接主导投资，只需移除障碍，巨大的潜在需求自然会催生私营部门的建设热潮。

最终愿景：通过重建经济增长的“基础”，英国可以重新实现快速生产率增长、缓解住房危机、降低能源成本、振兴工业，并最终增强公共服务、家庭福祉与国际地位。历史上，1930年代英国正是通过解除管制、推动住房与电力网络建设，避免了经济大萧条并实现了繁荣。本文认为，如今英国完全有能力再次做到这一点。

DirectX 采用 SPIR-V 作为未来交换格式

Direct3D 和 HLSL 团队宣布，在 Shader Model 7 发布后，DirectX 12 将接受编译为 SPIR-V 的着色器。这一举措是 GPU 可编程性的重大进步，团队从开发初期就强调透明合作，与 Khronos Group 和 LLVM 项目共同推动过渡，以确保整个生态系统受益。

拥抱开放技术和标准

HLSL 的目标是成为适用于任何设备或 GPU 运行时 API 的最佳着色器编译语言。为此，团队积极采用开源技术，支持行业标准，并参与 Khronos Group 的 SPIR 和 Vulkan 工作组。这增强了 HLSL 在 Vulkan 和 Metal 等平台上的支持，通过 Clang 和 LLVM 推动 HLSL 开发，以满足行业对开放性和新功能的需求。Khronos Group 总裁 Neil Trevett 表示，欢迎微软的参与，这将促进 SPIR-V 标准的演进，惠及整个图形生态。

替换 DXIL 的路径

自 Shader Model 6.0 引入基于 LLVM 的 IR（即 DXIL）以来，Direct3D 功能大幅扩展，支持光线追踪等特性。然而，维护专有 IR 格式违背了开放技术的承诺。因此，Shader Model 7.0 将采用 SPIR-V 作为交换格式。团队将在未来几年定义 Direct3D 的 SPIR-V 环境，并开发 SPIR-V 扩展以支持所有当前和未来的着色器编程功能。

过渡期间，团队将提供 HLSL 到 SPIR-V 的编译器，并构建翻译工具以实现 SPIR-V 与 DXIL 之间的互转，帮助驱动开发者逐步适应。使用 AgilitySDK 的开发者工作流基本不变，但工具开发者可能需调整，不过 SPIR-V 的成熟工具将带来长期效益。SPIR-V 的可扩展性将加速 GPU API 特性创新，统一生态系统，提升开发者生产力。

解锁 Direct3D 创新

采用行业标准交换格式使微软和硬件供应商能专注于差异化功能，而非重复通用功能，从而加速新特性开发，推动下一代应用。这些变化结合对 Direct3D 的持续投资，将开启 Direct3D 创新的新篇章。

附录：GPU 交换格式简史

GPU 没有长期统一的架构，因此编程模型常延迟生成原生指令集架构（ISA），在运行时由驱动程序优化。Direct3D 从 Direct3D 8 开始支持虚拟 ISA，如 DirectX 字节码（DXBC），后演变为基于 LLVM 的 DXIL。LLVM IR 作为 SSA IR 优势明显，但其位码格式存在版本不稳定和压缩差等问题。

为此，Khronos Group 开发了 SPIR-V 作为 SPIR 的后继者。SPIR-V 继承了 LLVM IR 的思想，但提供稳定、简单的二进制序列化，易于非 LLVM 工具读写。它已成为 Vulkan、OpenCL 等 GPU 编程技术的标准交换格式，解决了先前问题，促进了跨平台兼容性。

优化 Guile Scheme 指南

本文总结了在 Guile Scheme 中提升代码性能的关键策略，主要针对性能敏感的代码核心部分（如游戏中的图形层）。优化核心在于辅助编译器进行优化，主要遵循两条规则：避免内存分配和优先使用单态而非多态函数。

核心优化原则

1. 避免分配：动态语言中，内存分配（尤其是堆分配）是性能瓶颈。Guile 中除立即数（如 fixnum）外，所有数字（包括浮点数）都是堆分配的。减少分配能显著降低垃圾回收（GC）开销。
2. 优先单态：单态函数（如 fx+、fl+）避免了运行时的类型分派开销。Guile 的编译器能通过类型推断，在可能的情况下将多态算术操作（如 +）特化为单态操作。

优化技术与示例

1. 处理可变参数：使用 case-lambda

• 问题：接受任意数量参数的过程（如使用 . 或 apply）在每次调用时会分配一个列表来存放参数，导致大量GC。
• 解决方案：为常见的参数数量（如1个、2个、3个）提供特化的代码路径。
• 示例：将计算平均值的函数从使用 fold 处理任意参数，改为使用 case-lambda 为0、1、2、3个参数分别提供优化实现，仅对更多参数的情况使用通用方法。
• 效果：性能提升约17倍，GC时间降至零。

2. 浮点数学运算：利用类型推断与装箱优化

• 问题：通用算术函数（如 +、*）和中间结果会导致浮点数的堆分配和GC。
• 解决方案：通过类型守卫（如 (inexact? x)）向编译器证明变量为浮点数。这允许编译器进行“装箱优化”，将浮点数保持在未装箱（unboxed）状态，使用特化的原始指令（如 fadd, fmul），并避免中间结果分配。
• 示例：在计算二维向量模长的函数中，添加对输入参数是否为实数（real?）且不精确（inexact?）的检查。
• 效果：性能提升约6倍。虽然仍有GC（最终结果需要装箱返回），但计算过程本身未分配。

3. 强制内联：使用 define-inlinable

• 问题：函数调用会作为优化边界，阻止跨函数的类型推断和装箱优化传播。
• 解决方案：使用 define-inlinable 宏强制内联函数，将函数体直接插入调用点。
• 示例：将优化后的 magnitude 函数声明为 define-inlinable。然后 normalize 函数调用 magnitude 时，其优化后的未装箱数学代码被直接内联，后续的除法操作也能被优化为 fdiv。
• 效果：性能再次提升约2倍。

4. 使用字节向量：彻底避免数字分配

• 问题：即使进行装箱优化，最终结果仍需装箱分配。对于极致性能，需要完全避免浮点数堆分配。
• 解决方案：使用 f32vector 或 f64vector 存储浮点数。字节向量的存取器（f32vector-ref, f32vector-set!）支持未装箱操作。
• 示例：
  • 定义内联辅助函数 vec2、vec2-x、vec2-y 来操作存储二维向量的 f32vector。
  • 修改 magnitude 和 normalize 以操作字节向量。
  • 进一步提供就地修改的 normalize! 函数，接受源向量和目标向量，完全避免分配新对象。
• 效果：使用就地修改函数 normalize! 比函数式 normalize 快约13倍，且GC为零。这是游戏开发中管理大量几何对象的常用模式（配合对象池使用）。

工具与建议

• 分析工具：使用 ,profile 进行性能剖析，使用 ,disassemble 查看生成的字节码，以定位热点和验证优化效果。
• 优化建议：
  • 优化应聚焦于程序的核心循环或内核。
  • 不要盲目应用优化（如到处使用 define-inlinable），这会增大代码体积。
  • 依赖分析工具识别真正的瓶颈。
  • 上述优化技巧（尤其是字节向量和就地修改）是动态语言中通用的高性能编程模式。

通过结合编译器能力（类型推断、内联）和编程技巧（使用专用数据结构、避免分配），可以在 Guile Scheme 中实现接近静态语言的数值计算性能。

MemoRAG：通过记忆驱动的知识发现增强长上下文检索增强生成

核心概述

MemoRAG 是一个创新的检索增强生成框架，基于高效、超长的记忆模型构建。与主要处理明确信息需求的标准 RAG 不同，MemoRAG 利用其记忆模型对整个数据库实现全局理解，并通过从记忆中召回查询相关的线索来增强证据检索，从而生成更准确、更具上下文丰富性的响应。该论文已被 WebConf 2025 接收。

核心特点

• 全局记忆：单次上下文可处理高达 100 万个 token，对海量数据集提供全面理解。
• 优化灵活：能轻松适应新任务，仅需数小时额外训练即可优化性能。
• 上下文线索：从全局记忆生成精确线索，连接原始输入与答案，从复杂数据中挖掘隐藏见解。
• 高效缓存：支持分块、索引和编码的缓存，可将上下文预填充速度提升高达 30 倍。
• 上下文重用：只需编码一次长上下文，支持重复使用，提升需要重复数据访问任务的效率。

使用方式

MemoRAG 提供了多种使用模式：

1. Lite 模式：通过几行代码即可快速体验 MemoRAG 流程，支持处理高达数百万 token 的英文或中文上下文。
2. 基本用法：可使用 HuggingFace 模型初始化。通过 memorize() 方法，记忆模型为长输入上下文构建全局记忆。支持缓存已编码的 KV 缓存、索引和分块段落以实现快速重用。
3. 使用长上下文 LLM 作为记忆模型：支持利用 Meta-Llama-3.1-8B-Instruct 和 Llama3.1-8B-Chinese-Chat 等长上下文大语言模型作为记忆模型，并利用 MInference 优化上下文预填充。
4. 独立使用记忆模型：记忆模型可独立使用，进行上下文的存储、回忆和交互，包括回答查询、生成文本线索以及重写查询。
5. API 作为生成器：支持集成 OpenAI 和 DeepSeek 等外部 API 作为生成器模型。

评估结果

在多个基准测试（LongBench, InfBench, UltraDomain）上的实验表明，MemoRAG 在多种任务上，尤其是在多跳推理任务（如 Musique, 2WikiMQA）上，相比其他基线方法（如 BGE-M3, HyDE）取得了显著的性能提升。例如，在生成器为 Llama3-8B-Instruct 时，MemoRAG 在 Musique 数据集上取得了 28.4 的最佳分数。

项目状态与路线图

MemoRAG 目前处于积极开发中。未来目标包括通过工程改进实现轻量级优化，增强记忆能力，以适应更广泛的应用并支持更长的上下文（如超过一百万 token）。路线图涵盖发布代码/模型/数据集、支持更多模型、优化推理速度、集成任意检索方法等。

其他信息

• 许可证：Apache 2.0 许可。
• 引用：论文已在 ACM Web Conference 2025 发表。

哥伦比亚运动服公司的“关税工程”与女性衬衫口袋设计

关税背景与公司策略

关税是对进口商品征收的附加税，通常用于保护本国产业。哥伦比亚运动服公司（Columbia Sportswear）作为全球户外服装品牌，年销售额超过20亿美元，其产品在世界各地制造和销售。公司设有专门团队，与设计师、开发人员和海关合作，在产品设计阶段考虑关税影响，以降低进口成本。这种做法被称为“关税工程”。

具体案例：女性衬衫的口袋设计

美国关税政策中存在特定分类，例如女性或女孩的人造纤维衬衫（税则号6206.40.30）进口关税率可高达26.9%。但如果服装具备“腰部以下口袋、罗纹腰带或底部收紧装置”，则可归入另一类别（税则号6211.43.1060），关税率降至16%。哥伦比亚公司利用这一漏洞，在女性衬衫的腰部附近故意添加小口袋，以享受更低关税。这种口袋在公司内部被称为“护士口袋”或“润唇膏口袋”。

例如，哥伦比亚的PFG Tamiami女款短袖衬衫就采用了此设计，零售价为40至45美元。设计师Becca Johnson指出，这种口袋在户外服装中具有实用功能，如存放润唇膏等小物品。

历史与政治因素

关税分类中的“腰部以下口袋”例外至少可追溯至1989年，但具体起源原因不明确。贸易专家推测，这可能源于特定进口商游说国会，以保护相关行业或利益。美国关税代码非常复杂，包含许多细微分类（如按重量计算的纤维比例），税率调整往往基于政治谈判而非科学分析。国际贸易律师Frank Samolis指出，国会通过这些分类保护特殊利益，过程涉及大量政治交易。

关税工程的影响

哥伦比亚的“关税工程”展示了企业如何通过设计创新应对贸易政策。这种方法不仅降低了成本，还赋予了产品功能价值。关税规则的任意性反映了全球贸易谈判的政治性，企业需灵活适应以保持竞争力。

摘要：当Web应用用户不足100时，停止为数百万用户设计

在Web应用开发初期，开发者常犯的错误是过度设计以应对大规模用户增长，如优化数据库、设置强大服务器等。然而，在用户基数尚小时，这种做法会适得其反。以下是关键要点：

• 基于假设决策：早期阶段用户需求未知，为数百万用户设计依赖猜测而非真实数据，优先级应是构建满足首批用户需求的产品。
• 浪费时间资源：过度工程化消耗时间在未急需的基础设施上，应聚焦于功能开发、用户体验改进和收集反馈，以快速交付价值。
• 产生不必要成本：投资未使用的服务器、数据库和云服务会增加开支，资金更应用于营销、产品开发或客户获取。
• 降低灵活性：复杂系统难以快速迭代和调整，保持简单有助于根据用户反馈敏捷响应。
• 未来挑战未知：假设的未来问题可能与实际不同，应专注于当前问题如产品-市场契合和用户增长。
• 缩放技术简化：现代云平台（如AWS、Google Cloud、Azure）使按需缩放更易，无需从一开始就准备大规模基础设施。
• 用户体验优先：应用的可扩展性不如使用体验重要，应首先确保产品无bug、界面友好、功能齐全，以吸引和保留用户。

总结：在用户不足100时，避免为数百万用户设计Web应用。专注于构建当前用户想要的产品，快速迭代并从反馈中学习。当未来用户增长时，再利用现代工具进行缩放。

CNC显微镜项目概述

项目目标

使用现成零件构建CNC显微镜系统，用于拍摄叶片、CD-ROM等较大物体，揭示肉眼无法观察的微观细节。核心要求是采用金相显微镜（光线通过物镜照射到样本）。

硬件组成与安装

• 主要部件：
  • Genmitsu 3018-PROVer V2 CNC机床
  • Lapsun显微镜（40X-400X镜头）
  • 20X金相物镜
  • AmScope MU1803 18MP USB 3.0摄像头
• 辅助材料：氯丁橡胶胶带（用于固定显微镜）、索博圆盘（减震）、亚克力垫块（抬高样本）
• 安装挑战与解决：初期使用油泥固定显微镜失败，改用氯丁橡胶胶带后成功。需拆卸显微镜反光镜部分才能通过刀架安装。摄像头传感器和物镜通过适配器安装。

成像实验与发现

• 对焦精度：Z轴微调（约0.31mm）即可实现从模糊到清晰的对焦，表明系统对垂直位置变化非常敏感。
• 放大倍率：测试了不同物镜（20X、10X）与显微镜转盘倍率（1X、4X）组合下的成像效果。
• 图像清晰度分析：采用拉普拉斯高斯算子评估图像不同区域的清晰度（锐度），并生成热图。发现CD-ROM图像中清晰区域分布可能与样本倾斜或光照有关。

软件与自动化

• 控制脚本：开发Python脚本，自动控制CNC机床按指定模式移动并采集图像。
• 自动对焦算法：通过Z轴移动并实时计算图像锐度（拉普拉斯算子），寻找最佳焦点平面。
• 图像稳定检测：使用均方误差比较连续帧，当标准差小于阈值时判定图像稳定，以确保采集质量。
• 图像拼接：使用Fiji（ImageJ）的拼接插件处理网格化采集的图像，并编写自动化脚本处理图像翻转和参数设置。

关键问题与优化

• 振动控制：振动显著影响图像质量和MSE值。实验对比了多种环境（桌面、地毯、石质壁炉）和减震措施（去除原装脚垫、使用索博圆盘），发现石质表面加索博圆盘效果最佳。
• 帧率提升：通过降低分辨率（从4912×3684至2456×1842）并改用手动曝光，将摄像头帧率从约3 FPS显著提高，满足了快速计算MSE的需求。
• 光照校正：拼接图像出现网格状明暗不均（暗角效应）。通过拍摄空白背景图像并利用算法校正，显著改善了成像均匀性。

最终成果与演示

• 成功拼接了CD-ROM表面约1mm x 1mm区域的微观图像（最终分辨率约10609×10077像素），可观察到其微观结构。
• 展示了书封面等样本的拼接效果，并演示了自动对焦过程。

待办事项与参考

• 未来计划：测试运动学平台（可能实现长距离移动无需调Z轴）、尝试焦点堆叠技术。
• 参考方案：
  • DIY项目：OpenFlexure（3D打印电动显微镜）、PUMA（3D打印显微镜）。
  • 商业方案：Labsmore（开源软件）、Meiji Techno（高端金相显微镜）。

文章介绍了奥地利业余天文摄影师费利克斯·肖夫班克利用家用14英寸道布森望远镜成功拍摄并分析了多颗美国机密间谍卫星的案例，揭示了此前未知或仅被推测的技术细节。

1. FIA雷达卫星（Topaz） 肖夫班克拍摄到五颗隶属美国国家侦察局的“未来成像架构”雷达卫星（又称Topaz）。这些卫星搭载合成孔径雷达，具备全天候、穿云成像能力，是“长曲棍球/缟玛瑙”系列的后续型号。根据图像分析：

• 卫星配有一个直径约12米的抛物面网状天线。
• 两块太阳能电池板翼展约10米。
• 天线可朝轨道左或右指向（观测28次中，6次向左，22次向右）。

2. KH-11 Kennen电子光学卫星 肖夫班克同时追踪了类似哈勃望远镜但用于对地观测的KH-11卫星。目前在轨运行四颗，分属第三代至第五代：

• 第三代：USA 186（2005年发射），主镜直径约2.4米。
• 第四代：USA 224和USA 245（2011年、2013年发射），主镜直径增至约3米。
• 第五代：USA 314（2021年发射），因图像有限尚未准确测得主镜尺寸。

3. 未知类型卫星：USA 290 该卫星原被疑为KH-11变体，但图像显示其具有约5米长的矩形面板，且轨道与典型的KH-11不同（后者多采用太阳同步轨道）。面板可能为冷却系统、相控阵天线或固定式太阳能板。

4. 观测者的看法 肖夫班克认为，业余摄影师的拍摄不会对国家机密构成实质威胁，因为各国专业机构拥有更先进的设备与更高清的图像。其更多成果发表于天文摄影社区Astrobin。

反应式关系代数概述

作者对关系代数持个人看法，认为它更像是一种“发明”而非“发现”，有时感觉像是一种勉强融入计算机科学课程的妥协。然而，当严谨地思考数据库、表格或电子表格，并需要借鉴前辈智慧时，关系代数便展现出作为数学与计算理论中一个吸引人分支的价值。

作者正在构建“更好的电子表格”，并处理类似数据库视图的“派生”表格。其核心是引入了一个受离散函数式响应编程（FRP）启发的时间索引范式，以处理异步数据（如HTTP请求、SQL查询）。尽管作者不确定自己的想法是否与FRP直接相关，但使用带时间标记的表达式（如 A[t+1] = B[t] ∪ C[t] 表示“A将由B和C的并集派生”）有助于思考并发问题。

为了模拟异步数据库操作（例如 A[t+n+1] = B[t] ∪ C[n] 表示“A将由B和C的异步/未来结果派生”），作者发现需要创建许多中间表格来模拟“内存”。最终，他采用自引用来合并表格，例如 A[t+1] = A[t] ∪ B[t]，该方式只能增加行（自联合）或减少行（自相交）。

在实际演示中，作者展示了如何用关系代数及其扩展表达复杂查询，例如 A[t+1] = φ{i>=max(i)-5}(A[t] ∪ B[t] ⨝ C[t]) 表示“A将是B与C连接结果的最近五条记录”。作者也尝试使用其开发的scrapscript表示法（如 a1 . a1 = a0 |> sheet/union (sheet/join b0 c0) |> sheet/limit 5）来自然地描述此类查询，并正在通过实验性的scrapsheet演示测试该范式处理更复杂情况的能力。

文章以作者的实验暂时告终，并开放讨论未来方向。

《开源应用程序的架构》内容概要

核心背景与目标

本书旨在改变软件开发者较少研究大型开源程序、易重复他人错误的现状。通过邀请数十位知名开源应用的作者亲自阐述其软件的架构设计、组件交互以及开发心得，为开发者提供宝贵的实战见解与设计经验。

书籍结构与内容

卷一（AOSA Volume 1）

• 内容：收录了25个经典开源项目的架构解析，涵盖多种类型，包括：
  • 系统工具：Bash（Bourne-Again Shell）、Sendmail
  • 开发环境与工具：Eclipse、CMake、LLVM、Mercurial、Python Packaging
  • 数据库与分布式系统：Berkeley DB、Hadoop分布式文件系统、Riak、NoSQL生态
  • 多媒体与通讯：Audacity、Jitsi、Telepathy、Asterisk
  • Web与应用：Selenium WebDriver、SocialCalc、Graphite、VisTrails
  • 游戏与模拟：Battle For Wesnoth、Thousand Parsec、SnowFlock
• 每章结构：由原作者撰写，阐述项目主要组件、组件间交互方式以及开发中的关键经验教训。

其他系列

• 卷二（AOSA Volume 2）：延续卷一模式，解析更多开源应用架构。
• 《开源应用程序的性能》：专门探讨开源软件的性能优化。
• 《500行代码或更少》：展示如何用极简代码实现特定功能。

许可证与版税

• 本书采用 Creative Commons Attribution 3.0 Unported 许可证发布。
• 所有书籍销售版税将捐赠给 国际特赦组织（Amnesty International）。

社区贡献

• 本书由志愿者协作完成，并持续欢迎社区参与：
  • 报告错误
  • 协助翻译为其他语言和格式
  • 撰写新章节（介绍其他开源项目架构）
• 可通过指定翻译协调员或邮件（gvwilson@third-bit.com）联系。

基于Matrix 2.0的Element X、Call与Server Suite现已投产

Element推出了基于即将发布的Matrix 2.0协议的通信平台，旨在提供超越主流替代方案的高性能、去中心化、自托管及端到端加密的实时通信解决方案，支持大型组织间的互操作性。

该新方案由三个核心部分组成：

1. Element X：下一代应用，带来一系列新功能。
2. Element Call：原生集成于Element X，提供矩阵加密的语音和视频通话。
3. Element Server Suite (ESS)：后端托管解决方案，提供强大的管理控制和Matrix 2.0性能。

Element X应用特性：

• 速度与设计：应用使用Rust重写，比前代快20000倍，登录、启动和同步更即时。采用最新平台UI工具包（SwiftUI, Jetpack Compose）和统一的设计系统Compound，提供直观、流畅的用户体验。
• 无缝视频通话：Element Call原生集成，支持端到端加密的1对1或群组视频通话，无需依赖第三方系统。新增画中画模式，支持多任务处理。
• 隐形加密：使端到端加密对用户无感。支持便捷的QR码登录，大幅改进加密稳定性和可靠性，减少加密警告，并优化了密钥备份和重置流程，提升业务连续性。
• 增强的消息功能：支持自动草稿保存、失败消息自动重发，富文本编辑器更稳定高效。

Element Server Suite (ESS)特性：

• 企业级平台：为大规模安全内部及跨组织通信设计。每月发布新版本，每六个月发布长期支持版。
• 灵活部署：支持Kubernetes Operators和Helm图表部署，包含超过20个可定制模块的应用商店。
• 简化认证：采用原生OpenID Connect (OIDC)，生产就绪的矩阵认证服务 (MAS) 支持独立运行及上游身份提供商集成，简化设置。
• 服务端同步：内置简化滑动同步API (SSS) 模块，实现即时更新和更流畅的用户体验，消除对代理的需求。
• 安全合规：提供高级审计工具，在保持端到端加密的同时满足企业监管需求。包含服务端网关模块以检查流量、执行数据防泄漏策略。

整体价值： 结合Element X的易用性与ESS的强大性能，形成了一个完整的、主权安全的通信解决方案，特别适合对安全和自主性有高要求的大规模组织。Element作为Matrix协议的创始公司，持续贡献开源代码（AGPLv3许可），其商用部署产品现已上线。

文章摘要

核心事件：美国司法部对软件和咨询公司 RealPage 提起反垄断诉讼，指控其策划了一场企业房东之间的广泛阴谋，旨在人为抬高全美数百万租赁单元的租金。这些房东共控制着全国 1600 万个租赁单元，占美国 4400 万个租赁家庭的 36%。

问题的重要性：

• 住房危机：住房成本是美国的危机。最新数据显示，过去十二个月租金上涨了 5%，且住房成本占整体通胀的 70%。
• 宏观经济影响：租金数据是美联储制定利率等货币政策的关键依据。租金上涨不仅影响家庭，还波及整个经济的信贷成本。

RealPage 的涉嫌操纵手段：

1. 信息共享：收集并分享敏感的市场价格信息，让客户了解竞争对手的定价。
2. 软件与顾问施压：通过其软件中的默认设置鼓励涨价，并派遣“定价顾问”不断催促客户提高租金。
3. 线下合谋：组织面对面会议，供其客户讨论共同提价事宜。

影响的量化估算（作者计算）： 由于缺乏相关研究，作者进行了粗略估算，试图量化这种涉嫌合谋对 2020-2024 年租金通胀的贡献。

• 关键数据假设：
  • 疫情以来全国租金通胀范围：19%（CoStar）至 33.4%（Zillow）。
  • RealPage 宣称其服务能带来年均 3% 至 7% 的“收入提升”。
  • 受其影响的租赁单元数量：司法部称 300 万，RealPage 销售材料称 480 万。
  • 在受影响城市（如图森、凤凰城），使用 RealPage 的单元比未使用的单元定价高 12-13%（存在“价格伞效应”，即拉高整体市场租金）。
• 估算结果范围：
  • 保守估计（仅限特定城市）：在 RealPage 占主导的城市，租金通胀中约 58%（基于 19% 总通胀）或 33%（基于 33% 总通胀）源于此阴谋。若平均到全国所有租赁单元，影响占总租金的不到 1%。
  • 中等估计：假设影响更大且全国平均，租金通胀中约 14% 源于此阴谋。
  • 最高估计（考虑溢出效应）：假设影响单元更多且对其他非直接控制区域有 2% 的溢出提价，租金通胀中高达 24% 可能源于这一涉嫌阴谋。

被忽视的问题与呼吁：

• 作者指出，尽管诉讼细节惊人，但政治和经济媒体对此大规模反垄断案件关注不足。
• 美联储等负责价格稳定的机构以及宏观经济学家们，对此类在关键通胀组成部分（住房）中发现的价格扭曲现象缺乏研究和关注，作者认为这可能导致货币政策基于模糊认知而非市场实际运作。

Microsoft TypeSpec 总结

概述

Microsoft TypeSpec 是一个用于 API 设计的工具，允许开发者提前定义数据模型，并自动生成多种输出，包括 API 规范、客户端/服务器代码和文档。它支持多种格式，如 HTTP、JSON Schema 和 Protobuf，旨在提升开发效率并实现 API-First 方法。

核心功能

• 数据定义与生成：开发者可以使用 TypeSpec 语言定义数据模型（如 Store、Address 和 Pet），然后生成对应的模式、API 规范和代码。
• 多格式输出：支持输出为 OpenAPI、JSON Schema、Protobuf 等格式，并集成到现有工具链中。
• 代码示例：TypeSpec 代码基于类似 TypeScript 的语法，例如使用 @route、@query 和 @path 装饰器定义 API 路由和操作，并生成标准的 OpenAPI 3.0.0 规范。

语言特点

• 轻量级和熟悉性：TypeSpec 受 TypeScript 启发，提供简洁的语法，帮助开发者以熟悉的方式描述 API 结构。
• 模块化：支持导入和命名空间（如 namespace MyOrg.Accounts），便于组织和重用代码。
• 扩展性：允许创建自定义装饰器和错误类型，增强灵活性。

集成与使用

• 工具链集成：通过 TypeSpec CLI 或 playground 快速开始，生成输出后可与生态系统（如 OpenAPI 工具）无缝集成。
• 项目初始化：使用命令如 tsp init 初始化项目，选择模板（如 REST API），自动创建文件（如 main.tsp 和 openapi.yaml）。
• 代码组织：示例展示了如何将代码拆分到多个文件（如 common.tsp），并使用导入管理依赖。

优势

• API-First 开发：通过定义优先的方式，减少手动编写文件的时间，快速生成标准合规的 API 规范。
• 开发效率：自动化生成减少错误，提高一致性，并支持迭代设计。
• 多场景应用：适用于生成文档、客户端/服务器代码，简化 API 生命周期管理。

入门指南

• 安装 TypeSpec CLI 或访问在线 playground 开始体验。
• 通过示例项目学习基本用法，如定义模型、路由和操作，并生成输出文件。