文章摘要：
大型演唱会中使用的可控发光手环由PixMob公司制造，用于创造体育场内的视觉效果。目前，Taylor Swift的Eras Tour采用了PixMob的X2型号手环。这些手环设计为可重复使用，内部结构包括两节电池和电路板。电路板上标注了版权日期20230629和版本号PALM V2.6r1，主要组件有两个RGB LED、微控制器、EEPROM和用于接收信号的红外二极管。

PixMob的工作原理基于红外遥控技术：通过一个大型可移动的红外投影仪向手环发送命令，控制其颜色、渐变、闪烁等效果。投影仪可以扫过体育场，并利用遮罩创造特定形状（如心形），实现动态视觉效果。

该技术引发了逆向工程社区的兴趣，相关努力已汇集在一个GitHub仓库中，专注于破解红外协议。由于Flipper Zero具备红外功能，一个项目已使其能够控制这些手环。文章附带视频演示了使用Flipper Zero将手环渐变为橙色的过程，突显了这项简单技术的高效性和酷炫效果。

WordPress 21周年回顾与关键观点

WordPress 已迎来 21 周年，作者回顾了自 2003 年首次发布以来的发展历程，并总结了早期成功的关键因素，为未来建设提出 11 点见解。

核心观点摘要

1. 简易与复杂平衡：简单操作应直观易用，复杂功能应可实现。
2. 动态内容价值：博客、评论和 pingback 需保持趣味性；动态网站优于静态，博客能提升多数网站。
3. 文档易编辑：借鉴维基模式，使文档编辑更便捷。
4. 社区论坛核心：论坛应居社区中心，需加强 bbPress 和 BuddyPress 的支持。
5. 插件与主题基础设施：每个扩展都应具备版本控制、错误跟踪、文档、国际化等完整设施，避免传统 ZIP 上传方式。
6. 主题多样性：主题预览需优化，非商业主题应涵盖多样美学与功能。
7. 灵活反馈机制：减少过度限制，依靠市场动态、自动化反馈和透明度，推动设计边界（严惩垃圾行为）。
8. 扩展反馈循环：反馈系统应随使用和社区扩展，而非依赖少数守门人。
9. 核心个性：核心软件应有独特风格，如彩蛋、个性化语言和创意元素。
10. 开发与决策统一：所有参与者应实际使用软件。
11. 贴近用户：开发者需参与支持、活动等，以保持与最终用户的联系。

附加信息

• Playground 潜力：Playground 工具预计带来变革。
• 趣闻回忆：作者提及 2003 年发布 WordPress 的经历，强调早期用户反馈对软件塑造的关键作用。

使用 llm.c 复现 GPT-2 124M 模型

概述

本文介绍了使用 llm.c（一个约4000行的C/CUDA代码库）复现 OpenAI 的 GPT-2 124M 模型的方法。该模型是GPT-2系列中最小的版本，于2019年发布。复现过程在单个8块A100 80GB SXM GPU节点上耗时约90分钟，成本约为20美元（按Lambda Labs每小时14美元计算）。llm.c 的效率很高，模型浮点利用率可达~60%。

技术实现与性能

• 模型规格：12层，12个注意力头，768维，1.24亿参数。
• 训练数据：100亿个token的 FineWeb 数据集。
• 性能对比：
  • 在FineWeb验证集上，表现优于OpenAI发布的原始GPT-2检查点。
  • 在 HellaSwag 基准测试中，准确率达到 29.9，超过了GPT-2 (124M) 的 29.4（GPT-3 Small为33.7，但其训练了3000亿token，而此处仅训练100亿token）。
  • 注意：由于训练数据分布（FineWeb vs. WebText）和网络环境的时间差异，此对比并非完全公平。

复现步骤

1. 环境准备（适用于Linux x86 64位 Ubuntu 22.04，CUDA 12）：

   • 安装 Miniconda。
   • （可选）安装 PyTorch nightly 版本。
   • 使用 pip 安装 tiktoken、datasets 等库用于数据分词。
   • （可选）安装 cuDNN 以支持 FlashAttention。
   • 安装 MPI（如果需要多GPU训练）。

2. 数据准备：

   • 克隆 llm.c 仓库。
   • 运行 python dev/data/fineweb.py --version 10B 对FineWeb数据集进行分词，生成约19GB的GPT-2 token文件（耗时约1小时）。

3. 编译：

   • 使用 make train_gpt2cu USE_CUDNN=1 进行编译（首次约1分钟）。

4. 训练命令示例（单GPU）：

   ./train_gpt2cu \
       -i "dev/data/fineweb10B/fineweb_train_*.bin" \
       -j "dev/data/fineweb10B/fineweb_val_*.bin" \
       -o log124M \
       -e "d12" \
       -b 64 -t 1024 \
       -d 524288 \
       -r 1 -z 1 -c 0.1 -l 0.0006 -q 0.0 -u 700 -n 5000 -v 250 -s 20000 -h 1
   

   • 关键参数说明：
     • -e "d12"：从零初始化一个12层的GPT-2模型。
     • -b 64：微批次大小（内存不足时可降低）。
     • -t 1024：最大序列长度（与GPT-2一致）。
     • -d 524288：总批次大小（约0.5M token），遵循GPT-3论文。
     • -r 1：重新计算GeLU激活以节省内存。
     • -z 1：启用ZeRO-1（多GPU时优化状态分片）。
     • 其他参数（学习率、权重衰减等）主要参考GPT-3论文。
   • 多GPU训练：在命令前添加 mpirun -np 8。

5. 训练过程监控：

   • 训练过程会输出步骤、损失、梯度范数、学习率、MFU（模型浮点利用率）和token吞吐量。
   • 总训练步骤数约为 18,865步（100亿token / ~52.4万token每批）。
   • 损失（Loss）会从约7.58下降到约3.29，困惑度（Perplexity）相应从2000降至27。
   • 梯度范数（Gradient Norm）超过1.0时会进行裁剪以防梯度爆炸。

6. 结果可视化：

   • 训练日志记录在 log124M/main.log。
   • 提供了一个Jupyter Notebook用于解析日志并生成训练曲线图。

7. 分词器与采样：

   • 分词器：可通过运行Python参考实现（train_gpt2.py）生成 gpt2_tokenizer.bin 文件，供C代码解码token。
   • 采样：代码支持低效的非条件采样和有限的条件采样（需修改代码）。例如，可让模型续写“The GitHub project llm.c is a”。

代码结构

• 核心文件为 train_gpt2.cu（约3500行），负责：
  • 初始化（MPI、NCCL、cuDNN、cuBLAS等）。
  • Transformer层的前向和后向CUDA实现（代码位于dev/cuda目录）。
  • GPT-2模型组装和训练循环（包括检查点恢复等）。
• 其他支持文件包括：文件I/O工具、分词器、数据加载器和随机数生成器。

扩展与未来工作

• 已复现 350M 参数模型（耗时14小时，成本约200美元，训练300亿token）。
• 计划复现 740M 和 1558M (GPT-2) 模型（估计1558M模型训练约需1周，成本约2500美元）。
• 未来将改进代码质量、测试、多节点支持，并计划构建完整教程。
• 代码目前不支持：高效推理、聊天微调、fp8训练、非NVIDIA GPU（欢迎移植PR）和位完全确定性（接近实现）。

常见问题

• CPU训练：无法复现GPT-2，但可使用参考CPU代码在类似TinyShakespeare的数据上微调OpenAI的GPT-2模型。
• 与PyTorch比较：llm.c是纯C/CUDA实现，PyTorch版本（train_gpt2.py）仅作参考，功能不完全对齐。
• 为何选择GPT-2：它是现代LLM架构的奠基之作，参数已公开，且许多后续模型（如Llama 3）在架构上仍与之相似。

致谢

感谢多位贡献者在CUDA内核优化、分布式训练和Windows支持等方面的贡献。

应用名称与定位
Grooved 是一款免费应用，通过播放歌曲来校准唱机转速，旨在重现早期 iPhone 时代“单一功能应用”的简洁体验。

核心功能与使用步骤

1. 播放歌曲：选择一首熟悉的音乐并播放。
2. 分析转速：启动应用进行实时音频分析。
3. 调整校准：根据结果调整唱机，重复操作直至校准完成。

技术特点与隐私保护

• 所有音频处理均在本地设备完成，不录制或传输数据。
• 完全基于苹果原生组件开发，未使用任何第三方库或 API。
• 应用完全匿名，开发者无法获取用户使用信息。

设计初衷
作者观察到当前文案过度追求幽默和标签化，但实际产品更注重实用性与隐私保护，试图回归简单直接的工具型应用本质。

命名即宣传：非营利组织工业复合体如何腐蚀美国城市

命名行为本身即是一种宣传。文章以“智利海鲈鱼”为例，说明一个名称并非客观描述，而是影响认知的工具。这种营销策略同样适用于“非营利组织”这一名称。该名称天然带有公益、利他、可信的光环，使其在公众和政府面前享有近乎本能的信任，从而避免了应有的严格审视。

非营利组织的现实：监管缺失与利益冲突

由于享有“非营利”名称带来的信任，这些组织常常缺乏足够的监管。大量公共资金被拨付给它们，但资金使用和服务效果常与公共利益背道而驰。许多非营利组织的行为与其宣称的使命完全矛盾：

• 执行层高薪与服务缩水： 组织高管薪酬大幅上涨，而用于直接服务（如帮助租户）的支出比例却持续下降。
• 利益冲突驱动的游说： 尤其是在可负担住房领域，许多非营利组织作为现有物业的运营方，其获得的政府补贴与市场租金挂钩。这构成了根本性的利益冲突：新建住房会平抑租金，从而减少它们的补贴收入。因此，它们反而会积极游说反对新的住房开发项目，尽管其宗旨是提供更多可负担住房。
• 资金滥用与雇佣风险： 由于监管薄弱，存在资金被挪作私用（如高管购买奢侈品）的情况。更严重的是，许多组织雇佣有严重犯罪记录（如谋杀、性犯罪、抢劫）的人员，用公共资金支付高额合同，这既浪费了资源，也带来了公共安全隐患。

案例分析：以旧金山和西雅图为例

• 旧金山TODCO（租户与业主发展公司）： 作为可负担住房非营利组织，它在近20年未新建任何住房，同时任其管理的建筑破败不堪。它将数百万美元用于政治游说，甚至采取诉讼手段阻止其他开发商建造包含数百套可负担单元的项目。其行为逻辑清晰：通过阻止住房供应来维持高租金，从而最大化自身从政府获得的补贴收入。
• 西雅图的系统性问题： 该市多次将大额合同授予由有犯罪前科者运营或雇佣有犯罪记录人员的非营利组织。例如，一个旨在减少枪支暴力的项目雇佣了多次定罪的重罪犯，结果该雇员在项目资助期间再次犯罪并遭枪击。监管的缺失使得公共资金被浪费，甚至助长了危险行为。

系统性根源：进步主义政治与政府能力空心化

文章指出，支持这一“非营利工业复合体”的政治意识形态通常被称为“进步主义”，但这与历史上的进步主义运动名实不符。在实践中，这种“进步主义”表现为：

1. 核心矛盾： 一方面主张政府应增加公共项目支出，另一方面又对集中化的国家权力抱有无政府主义式的反对态度。
2. 导致的结果： 这些城市削弱了核心政府部门（如环卫、警力）的预算和能力，转而将服务外包给众多非营利组织。这本质上是将政府职能私有化。
3. 低效与恶果： 由多个碎片化、缺乏监督的非营利组织来提供服务，效率低下，无法形成规模效应，且难以问责。例如，旧金山在无家可归者服务上的支出从2016年的2亿美元激增至2021年的11亿美元，但无家可归者人数几乎未减。
4. 恶性循环： 居民承受着高昂的税费，却换来日益恶化的公共服务（如垃圾堆积、治安下降、公共卫生风险）。这导致人口和税基流失，进而迫使政府削减服务，形成“城市厄运循环”。文章认为，这些城市的问题并非源于“过于社会主义”，恰恰相反，是源于它们“不够社会主义”——即未能建立并强化一个直接、高效、负责的公共部门来解决社会问题。

结论

总而言之，文章批判了美国城市中一个扭曲的体系：“非营利”之名掩盖了其追逐私利的实质；“进步主义”政策导向导致政府职能被外包给效率低下、利益冲突严重的私人组织。其结果是高税收并未带来良好的公共服务，反而加剧了城市衰退。最终，就像“智利海鲈鱼”这个营销谎言一样，在这个体系中，许多人从中牟利，而真相被漠视。

执行呈正态分布，学习呈对数正态分布

本文探讨了 gwern.net 上关于“漏斗管道”或对数正态分布的概念，并将其应用于软件开发和学习过程。主要观点如下：

核心概念：漏斗管道与对数正态分布

• 漏斗管道模型：多步骤过程中，每个步骤的成功概率相乘，导致总体成功率低于单个步骤。例如，从零到第一个客户的成功概率：0.9（启动应用）* 0.8（处理基础设施）* 0.7（获取客户）≈ 0.5，远低于任一步骤的概率。
• 对数正态分布 vs 正态分布：执行任务（如常规工作）通常呈正态分布（钟形曲线），但学习新技能或应对未知障碍呈对数正态分布，意味着任务耗时可能远长于预期，且变化更大。

软件估算的挑战

• 传统项目管理（如瀑布模型、甘特图）基于正态分布假设，但软件开发中常涉及“即时学习”，学习过程是对数正态分布的。
• 这导致时间估算不准确：例如，项目可能耗时两倍、三倍或五倍于预期，尽管偶尔也可能提前完成，但总体易超支。
• 技术障碍难以预测，符合“有效市场假说”——如果某事已知如何做，可能已被完成；但现实中存在未知挑战。

对行业的影响

• 招聘实践：雇主更倾向于雇佣有特定工具或语言经验的开发者，因为学习新事物的风险高。例如，非 Java 背景的开发者学习 Java 可能需要 1 到 5 个月，雇主不愿承担时间成本和不确定性。
• 业务流程优化：大多数新过程涉及学习阶段，需通过重复实践转化为例行活动，才能实现正态分布的、可预测的执行。作者以 Django 和 Hugo 网站开发为例，多年经验使其能直观估算时间，但新领域仍回到对数正态分布模式。

学术学习的对比

• 学术学习（“以防万一”的学习）可能更可预测，因为内容提前规划，但仍有意外：例如，作者在大学课程中，无线通信和 DSP 耗时少，而麦克斯韦电磁学耗时多。
• 在线教程的流行可视为减少最坏情况（如任务从预期一周变为一年）的策略。

总结

文章强调，学习过程的对数正态分布特性是软件估算混乱和行业实践（如招聘偏好）的根本原因。要实现稳定执行，需将学习转化为经验积累，从而缩小不确定性。

本文探讨了Transformer模型在算术任务中表现不佳的原因及改进方法。研究发现，性能瓶颈主要源于模型无法准确追踪大跨度数字序列中各数位的精确位置。为此，作者提出为每个数字添加一种能够编码其相对于数字起始位置的嵌入表示。这种位置嵌入不仅自身能显著提升算术性能，还使得进一步的架构改进（如输入注入和循环层）成为可能，从而带来更大增益。

解决位置追踪问题后，研究进一步考察了Transformer的逻辑外推能力，即处理比训练数据更长、更复杂数学问题的潜力。实验表明，仅使用20位数字在单GPU上训练一天，模型便能实现高达99%的准确率，处理100位数的加法问题，达到了当前最优水平。最后，文中指出，这种数字处理能力的提升也解锁了模型在其他多步推理任务（如排序和乘法）上的性能改进。

Tantivy 全文搜索引擎库摘要

核心定位

Tantivy 是一个受 Apache Lucene 启发的全文搜索引擎库（Rust crate），不是开箱即用的搜索引擎服务器（如 Elasticsearch 或 Solr）。它用于构建自定义搜索引擎。其分布式搜索功能由独立项目 Quickwit 提供。

主要特性

• 全文搜索：支持 BM25 评分（与 Lucene 相同）、自然查询语言和短语查询。
• 高性能：启动时间极短（<10ms），多线程索引速度快（例如，索引英文维基百科桌面端<3分钟），且根据基准测试比 Lucene 快约 2倍。
• 可配置分词器：支持 17 种拉丁语系词干提取，并通过第三方库支持中文、日文和韩文。
• 索引与查询功能：
  • 增量索引与更新（通过删除并重新索引实现文档编辑）。
  • 支持范围查询、分面搜索、聚合收集器（直方图、范围桶、平均值等）。
  • 字段类型丰富：文本、数值、日期、IP、布尔值、层次化分面等。
  • 压缩文档存储（LZ4、Zstd 或无压缩）。
  • SIMD 整数压缩（支持 SSE2 指令集）。
  • Mmap 目录、快速字段（等同于 Lucene 的 doc values）。
• 易用性：提供 tantivy-cli 命令行工具，支持快速创建、索引和搜索，并内置 REST API。

平台与支持

• 平台：支持 Linux、macOS 和 Windows，运行在稳定版 Rust 上。
• 语言绑定：存在 Python (tantivy-py) 和 Ruby (tantiny) 等语言的绑定。
• 支持方式：可通过使用体验反馈、报告问题、撰写文章、改进文档或贡献代码来支持项目。

常见问题

• 文档编辑：数据不可变，需删除后重新索引。
• 搜索可见性：文档在调用 commit 后变为可搜索，现有读取器需重新加载以反映变更。
• 非功能特性：不支持分布式搜索（需使用 Quickwit）。

Notepad Tab 功能摘要

Notepad Tab 是一个笔记工具，其主要特点是将笔记内容自动保存到浏览器的地址栏和浏览器历史记录中。这意味着用户写下的任何内容都会被即时记录，无需手动保存。

该工具的核心便利性在于笔记的备份和分享方式。用户只需复制当前页面的 URL，即可完成笔记的备份或与他人共享。这种方式简化了传统笔记的导出和传输步骤。

总之，Notepad Tab 利用浏览器本身的功能（地址栏和历史记录）来持久化存储笔记，并通过 URL 实现一键式备份与分享。

File0：简化无服务器文件管理的S3替代方案

File0旨在提供一种比AWS S3更简单、更快速的文件存储方案，专注于无服务器应用。其核心理念是将文件管理操作简化到类似使用浏览器内置localStorage的程度，从而大幅减少配置和开发时间。

核心优势：极简API与快速部署

通过提供直观的JavaScript API，File0将常见的文件操作（如上传、下载、删除）简化为几行代码。例如，使用f0.set()上传文件，或使用f0.publish()将文件通过全球CDN自动发布。相比之下，使用S3达成相似功能（如设置公共访问和CDN）需要编写更多配置代码和处理复杂的权限策略。

解决S3的复杂性问题

File0的诞生源于对现有云存储服务（特别是S3）复杂性的不满。S3的权限系统被认为对大多数应用来说过于复杂和危险，其设置流程也从早期的简洁变得繁琐。File0旨在为独立开发者、初创公司和小型项目提供一个无需学习复杂企业级配置即可使用的方案。

技术特点与全球服务

• 现代Web标准兼容：基于现代Web标准构建，可在任何运行时、框架甚至浏览器中运行。
• 零依赖与轻量：包大小仅为2.5kB，无额外依赖。
• 低延迟全球访问：所有公开文件自动通过全球CDN提供服务，无需额外配置。

定价模型

File0提供三层定价，避免意外的使用费用：

• 免费版：适合测试和小型项目（0.1GB存储，1个应用，无需信用卡）。
• 专业版（$12/月）：包含无限应用、100GB存储和无限带宽。
• 企业版：针对极端工作负载的定制方案，提供无限存储和带宽。

总结

File0定位为一个开发者友好、轻量级的文件存储服务，通过极简的API和开箱即用的CDN功能，旨在解决S3等传统云存储服务配置复杂的问题，让文件管理在无服务器应用中变得更加直接和快速。

基于Wi-Fi的定位系统对公众的监控风险

漏洞原理 研究人员发现，苹果公司的Wi-Fi定位系统可被恶意利用，形成全球性隐私威胁。该系统通过移动设备检测附近的Wi-Fi接入点来确定位置。攻击者可利用MAC地址空间中密集分配区域相对较少的特点，在数天内收集全球Wi-Fi BSSID的地理定位数据。

影响规模 通过此技术，研究人员在一年内获取了全球超过20亿个BSSID的精确位置。由于Wi-Fi接入点通常长期固定，而部分设备（如便携路由器）设计为可移动，这种大规模数据集可长期追踪设备移动，带来严重隐私风险。

案例研究

• 冲突地区追踪：通过远程定位无线接入点，可追踪进出乌克兰、加沙等战区的设备移动。
• 自然灾害影响：可监测毛伊岛山火等灾害期间的设备位置变化。
• 针对性追踪：可利用第三方接入点间接追踪特定个人。

建议与修复

• 向Wi-Fi定位系统运营商和接入点制造商提出隐私增强建议。
• 披露漏洞后，苹果及制造商已独立或联合实施多项缓解措施。
• 研究团队进行了负责任漏洞披露，并详细记录修复过程。

关键信息

• 攻击者仅需利用较少权限即可实施攻击。
• 大规模位置数据纵向分析可揭示设备移动模式。
• 漏洞影响全球数亿用户隐私安全。

（注：本文基于研究论文摘要整理，具体技术细节、案例数据及修复方案详见原文PDF。）

论文摘要

本文研究了Transformer模型能否通过**“grokking”（即远超过拟合点的长时间训练）来学习对参数化知识进行隐式推理**。研究聚焦于两种代表性推理类型：组合和比较。

主要发现

1. 学习能力：Transformer能够学会隐式推理，但必须经过grokking才能实现。
2. 泛化差异：
   • 面对分布外样本时，模型在组合推理上无法系统性泛化。
   • 在比较推理上则能够成功泛化。

机制分析

研究通过训练过程中的模型内部实验揭示了：

1. Grokking的机制：源于泛化电路的形成，以及泛化电路与记忆电路相对效率的变化。
2. 系统性关联：模型能否系统泛化，与泛化电路的具体配置有关。

指导意义

• 训练指导：研究结果为如何设计数据与训练设置以更好地诱导隐式推理提供了指导。
• 架构改进：暗示了改进Transformer架构的可能方向，例如鼓励跨层知识共享。
• 能力展示：在一个搜索空间很大的困难推理任务中，基于非参数记忆的GPT-4-Turbo和Gemini-1.5-Pro表现不佳，而经过完全grokking的Transformer实现了近乎完美的准确率，凸显了参数化记忆在复杂推理中的强大优势。

摘要：

泄露的OpenAI文件显示，公司CEO萨姆·奥特曼明显知晓并通过合同条款压制前员工言论，引发了对其信誉和公司透明度的质疑。

事件背景：

• 近期OpenAI多名高管和安全团队成员离职，媒体Vox曝光公司曾威胁离职员工签署严格的保密和非贬低协议，否则可能收回其已归属的公司股权。
• 在硅谷初创公司中，收回已归属股权的做法极为罕见，这通常违背了员工通过股权激励换取未来收益的预期，损害了OpenAI声称的“开放”形象。

关键争议点：

• 奥特曼的否认与矛盾证据：奥特曼在社交媒体上道歉，承认存在股权取消条款，但声称公司从未实际执行，且他本人不知情。然而，Vox审查的文件显示，奥特曼的签名出现在管理OpenAI股权的控股公司相关文件上，这些文件明确赋予公司近乎任意的权力来收回前员工股权或阻止其出售。
• 公司行为问题：离职员工在办理手续时被OpenAI代表强调股权收回条款，甚至只给予七天时间做出重大决定，法律专家批评这种做法过分且不正常。
• 公司回应：OpenAI首席战略官Jason Kwon等人也签署了相关文件，但公司道歉并承诺修复问题，称已努力纠正。但此前有报道指出奥特曼在沟通中“不一致地坦率”，削弱了其可信度。

相关背景：

• OpenAI面临其他争议，包括与演员斯嘉丽·约翰逊的法律纠纷，后者指控公司未经同意模仿其声音用于AI助手。
• 公司安全团队“超级对齐”组大量离职，引发对AI安全工作的担忧。
• OpenAI官网章程宣称使命是确保人工智能（AGI）造福全人类，但缺乏“透明度”原则，与此次事件形成对比。

综上，泄露文件和相关报道揭示了OpenAI在员工权益和内部管理上的问题，挑战了其公开倡导的价值观。

自己的网站写博客20年

作者回顾了自己20年（始于2004年）在个人网站上写博客的经历。当时不熟悉WordPress等现有工具，尝试使用基于Perl的Movable Type未成功，因此决定自己编写博客引擎。他创建了名为Jlog的项目，这个简单易装的博客软件被数百个网站使用。

他的第一个博客使用德语编写，至今仍在线。最初的设计因过于简陋而受到批评，后在哥哥帮助下进行了改进。引入博客软件前，作者从2003年开始就在自己的网站上手动发布HTML文章，有了博客软件后发布变得更加便捷，因此写作频率也大大增加。早期博客允许直接评论，曾引发热烈讨论，例如2005年关于Firefox与Opera的博文就有71条评论。

作者移居瑞典后，希望使用瑞典和德国读者都能理解的语言，因此开始尝试发布英文博客。但考虑到RSS订阅用户期待德语内容，他决定基于Ruby on Rails开发第二个英文博客引擎，其设计后来演变为深色模式以匹配他日常使用的GNOME桌面环境。为应对垃圾评论，他移除了传统的评论功能，但保留了Webmention机制，并且发现Mastodon中链接文章的帖子也能正常显示在评论区。

作者写博客主要是为了整理思绪、记录事件，以便未来回顾。随着年龄增长，他减少了发布个人化内容以保护家人隐私。他还增加了短内容形式，以避免每次都需要拟定标题，但这反而降低了博文发布的频率。尽管如此，作者强调他只是为自己写作，如果他人觉得有趣则是额外收获，并计划以同样低频率继续坚持下去。

本文介绍了在Go语言中实现运行时代码生成与执行的概念、方法及注意事项，主要内容如下：

核心概念澄清

• 作者刻意使用“运行时代码生成与执行”而非JIT（即时编译）或AOT（预先编译），以避免术语混淆。JIT通常指程序执行期间的编译，AOT指执行前编译，而本文描述的是在Go进程中生成机器码并立即执行，更接近一种“进程内运行时编译”。

实现前提与挑战

• 该操作完全不安全，依赖Go运行时内部细节，仅限深刻理解风险者尝试。
• 生成的机器码必须适配Go运行时的行为，否则会导致难以调试的致命错误（如栈追踪失败、非法指令等）。例如，需避免修改Go运行时保留的寄存器（如AArch64的x28）。

基本实现步骤

1. 生成机器码：将目标架构的机器码（如x86-64、AArch64）表示为[]byte切片。
2. 分配可执行内存：通过mmap分配可读写内存，写入机器码后，使用mprotect将其标记为可读可执行。
3. 获取入口地址：通过unsafe.Pointer获取机器码起始地址。
4. 跳转执行：通过Go汇编编写的“跳板函数”将入口地址作为参数，跳转至生成的机器码执行。

示例演示

• 作者以AArch64架构为例，展示一个最小程序：分配内存、写入单条RET指令的机器码（0xd6_5f_03_c0），标记为可执行并执行。
• 示例中故意展示未写入机器码时的非法指令错误（SIGILL），以及正确写入后程序正常输出“ok”的结果，说明步骤完整性。

重要性说明

• 此技术使Go程序能在运行时生成并执行机器码，无需CGo依赖。作者基于此开发了wazero（WebAssembly运行时），可从WebAssembly字节码生成x86-64/AArch64机器码并执行。
• 文章强调，函数调用、结果返回等与Go运行时交互的复杂细节将在后续文章介绍。

相关项目

• 文章列举了Go生态中类似尝试的项目（如gojit、sonic），均以纯Go实现，避免CGo。

本文为系列文章的第一篇，旨在阐述基本概念与最小可行示例，为深入探讨运行时代码生成在Go中的实践奠定基础。

Gh-dash：GitHub的漂亮CLI仪表板

Gh-dash是一个为GitHub设计的丰富终端用户界面（TUI）工具，旨在提供不中断工作流程的流畅体验。

主要特性

• 自定义视图：支持用户为每个仓库定义PR（Pull Request）和Issue板块。
• 键盘优先：提供可覆盖的vim风格键盘快捷键。
• 工作流定制：允许添加自定义操作以满足特定工作流程需求。
• 功能全面：支持在GitHub上进行几乎所有操作，包括查看差异、评论、检出分支、推送更新等。
• 配置驱动：所有设置均可通过一个YAML配置文件进行精细控制。

定位与适用对象

该项目特别适合那些喜欢通过键盘快速导航、需要高效管理PR和Issue，并且喜爱在终端中工作的用户。

文档与社区

• 项目提供详尽的文档，地址为gh-dash.dev/getting-started。
• 设有Discord社区供用户交流和提问。
• 欢迎社区贡献，贡献指南详见项目网站。

技术实现

该项目在底层使用了多个Go语言工具库构建：

• TUI框架：bubbletea
• 样式渲染：lipgloss
• Markdown渲染：glamour
• CLI框架：cobra
• GitHub功能：gh CLI
• 差异查看：delta

项目由Dolev Hadar及其社区共同维护。

more-itertools 库概述

more-itertools 是一个 Python 库，作为对标准库 itertools 的扩展和增强。它提供了额外的构建块、配方和例程，用于更高效、更优雅地处理 Python 的可迭代对象。

主要功能分类

该库的函数按功能被组织成多个类别，涵盖了迭代器操作的广泛需求：

• 分组 (Grouping)：用于将可迭代对象拆分为多个子部分，例如 chunked（分块）、split_at（分割）、bucket（按条件分组）等。
• 前瞻与回看 (Lookahead and lookback)：提供 peekable（可查看下一个元素而不消费）和 seekable（可重复迭代）等工具。
• 窗口 (Windowing)：生成滑动窗口或子序列，如 windowed、pairwise、sliding_window 等。
• 增强 (Augmenting)：向迭代中添加额外元素或模式，例如 intersperse（插入元素）、padded（填充）、repeat_last（重复最后一个元素）。
• 组合 (Combining)：用于合并或交织多个可迭代对象，如 interleave、flatten（扁平化）、roundrobin（轮询）。
• 并发 (Concurrency)：提供并发安全的迭代工具，如 concurrent_tee 和 serialize。
• 汇总 (Summarizing)：对迭代过程进行统计或判断，例如 ilen（获取长度）、run_length（游程编码）、all_unique（判断所有元素是否唯一）。
• 选择 (Selecting)：从迭代中提取或过滤元素，包括 first、last、one（确保只有一个元素）、unique_everseen（保留首次出现的元素）等。
• 数学与整数运算 (Math & Integer math)：提供数学相关的迭代工具，如 polynomial_eval（多项式求值）、is_prime（素数判断）、factor（分解质因数）。
• 统计 (Statistics)：用于计算运行统计量，如 running_mean、running_median。
• 组合数学 (Combinatorics)：生成组合、排列、幂集等，例如 powerset、distinct_combinations，以及按索引获取特定组合或排列。
• 包装 (Wrapping)：提供迭代器包装或转换工具，如 always_iterable（确保对象可迭代）、consumer（装饰器）。
• 其他 (Others)：包含 locate（定位元素）、replace（替换）、numeric_range（数值范围生成）、side_effect（执行副作用）等实用函数。

安装与使用

可以通过 pip 安装：

pip install more-itertools

使用时可以直接导入需要的函数。该库包含了 itertools 文档中的配方，也提供了大量新功能：

from more_itertools import flatten, chunked, spy

# 展平嵌套可迭代对象
list(flatten([(0, 1), (2, 3)]))  # [0, 1, 2, 3]

# 将迭代对象分块
list(chunked([0, 1, 2, 3, 4, 5, 6, 7, 8], 3))  # [[0, 1, 2], [3, 4, 5], [6, 7, 8]]

# 查看迭代对象的开头部分而不消费它们
head, iterable = spy((x*x for x in range(1, 6)), n=3)
list(head)       # [1, 4, 9]
list(iterable)   # [1, 4, 9, 16, 25]

完整的函数列表和详细用法请参阅其 API 文档。

维护与开发

该库由 @erikrose 和 @bbayles 维护，并得到众多贡献者的帮助。版本历史记录在文档中。用户可以通过在代码仓库中提交问题或拉取请求来反馈问题或提出建议。

互联网档案馆遭受DDoS攻击

• 攻击确认：互联网档案馆（archive.org）通过官方Mastodon账号发布声明，确认其网站正遭受分布式拒绝服务（DDoS）攻击。
• 当前影响：此次攻击未影响存储的数据，但导致大部分服务暂时不可用。
• 应对措施：团队正在积极处理此次攻击事件，并承诺将在评论区持续发布最新进展更新。

Wasmi v0.32 更新摘要

项目概述

Wasmi 是一款专注于嵌入式环境的高效 WebAssembly (Wasm) 解释器，广泛应用于插件系统、云主机和智能合约引擎。v0.32 是其迄今最重大的更新，引入了基于寄存器的字节码和延迟编译等新技术，使执行性能提升高达 5 倍，启动性能提升数个数量级。

启动性能优化

Wasmi 通过以下核心技术大幅优化了字节码翻译与启动速度：

• 延迟翻译 (Lazy Translation)：支持 Eager（默认）、Lazy 和 LazyTranslation 三种模式。Lazy 模式仅翻译执行所需的代码部分，显著缩短启动时间。
• 无检查翻译 (Unchecked Translation)：提供 Module::new_unchecked API，允许跳过已预验证 Wasm 文件的验证步骤，可节省 20-40% 的启动时间。
• 非流式翻译 (Non-streaming Translation)：默认采用非流式翻译以提升性能，同时保留 Module::new_streaming API 供流式处理需求使用。
• 链接器缓存 (Linker Caching)：引入 LinkerBuilder，在定义大量主机函数时，实例化新 Linker 的速度提升达 120 倍。

执行速度与内存优化

• 基于寄存器的字节码：将内部中间表示 (IR) 从基于栈改为基于寄存器。这减少了指令数量与调度开销，更契合计算密集型工作负载。
• 内存消耗降低：新 IR 设计有效减少了 Wasm 二进制文件的内存占用，并显著提升了指令执行时的缓存效率。

基准测试表现

• 启动与翻译性能：得益于延迟编译，Wasmi 与 Wasm3 表现最佳，远优于 Wasmtime 等优化型 JIT 运行时及 Winch 等单次 JIT 运行时。
• 执行性能：v0.32 在计算密集型任务（如矩阵乘法、Argon2）中表现优异，Coremark 得分大幅提升。其在 AMD 服务器芯片上性能尤为突出，但在 Apple Silicon 上稍逊（计划在未来版本中优化）。

未来展望

v0.32 为后续开发奠定了坚实基础，未来计划包括：

• 实现 multi-memory、SIMD 和 GC 等 Wasm 提案。
• 优化 Apple Silicon 平台的执行性能。
• 实现 Wasm C-API，使支持 C 语言接口的各类生态系统能将 Wasmi 作为库使用。
• 持续巩固其作为低内存消耗、高启动性能的嵌入式 Wasm 解释器的行业地位。

文章摘要

本文揭露了大英博物馆历史上最大盗窃案之一的侦破过程。丹麦古董商伊泰·格拉德尔因其对古宝石的精通和超凡记忆力，从eBay上可疑的低价交易开始，历经数年调查，最终将矛头指向博物馆内部员工。

起因与首次怀疑（2016年） 格拉德尔长期从eBay卖家“sultan1966”处购买古宝石，卖家声称宝石为继承所得。2016年，他注意到一件刻有生育之神普里阿普斯的浮雕宝石被短暂低价挂牌，他凭记忆认出该物曾出现在大英博物馆1926年的藏品目录中，随即产生怀疑。卖家随后撤下商品并解释为“妹妹的物品”。

深入调查与身份揭露（2020-2021年） 2020年，格拉德尔在一本新书中再次发现疑似大英博物馆的藏品图片，追溯后发现其曾通过中间商购自“sultan1966”。通过整理交易记录，他在一张PayPal收据上发现了卖家的真实姓名：彼得·希格斯。经朋友提醒，希格斯正是大英博物馆希腊与罗马部的策展人。进一步调查发现，“sultan1966”是希格斯的Twitter用户名，“Bodrum1966”是其PayPal邮箱（“博德鲁姆”是希格斯专业领域——哈利卡纳苏斯古城的现代地名），且收货地址与希格斯的住址相符。格拉德尔由此断定，博物馆策展人正在监守自盗。

博物馆的迟缓反应与内部掩盖 格拉德尔于2021年2月向博物馆管理层举报，但起初未获重视。希格斯本人则收到另一考古学家的预警后，迅速采取措施掩盖痕迹：他向管理层提交虚假报告，声称涉事宝石“数十年前已遗失”，并在馆藏数据库中伪造记录以使其看起来像是1963年的备注。博物馆初期调查后声称“所有物品已清点，无员工不当行为迹象”，但希格斯被允许继续担任部门主管。

盗窃规模扩大与事发（2021-2023年） 2021年12月，一次例行抽查再次发现物品缺失，引发新一轮秘密调查。2022年，受聘的策展人检查发现，超过300件有记录的藏品遭损坏或盗窃（部分留有钳子刮痕），且在一个储藏室中，1161件未编目物品遗失，占该储藏室藏品的四分之三以上。当该策展人将报告提交给时任部门主管希格斯时，希格斯试图以“周末/圣诞前夕不宜公布”、“生日”等理由拖延上报。

2023年初，博物馆新任主席乔治·奥斯本将此前格拉德尔的举报与新发现的盗窃规模联系起来，决定报警。希格斯被停职，警方随后搜查其办公场所及住所，发现了疑似用于修改馆藏记录的笔记以及据称来自博物馆的物品（希格斯否认）。2023年7月，希格斯被正式解雇。博物馆时任馆长哈特维格·菲舍尔因初期应对不力辞职。

后续影响与现状 博物馆承诺将完成全部800万件藏品的编目工作，并加强安保程序（如禁止员工单独进入储藏室）。格拉德尔已交还他经手过的360多件宝石，并呼吁其他买家归还物品。博物馆正在考虑如何补偿无意购买失窃物品的买家。伦敦警察厅的调查仍在进行中，但目前无人被捕或被正式起诉。希格斯否认所有针对他的民事指控。

此案凸显了博物馆在内部监管、藏品编目以及处理外部举报方面存在的严重漏洞，一位外部专家的执着调查最终揭开了这场持续多年的盗窃案。

Gleam 1.2.0 版本发布：聚焦容错编译与开发者体验提升

Gleam 1.2.0 是一个重要的版本更新，核心目标是提升语言服务器的响应速度和整体开发者体验。主要更新包括：

1. 容错编译

• 过去：编译器在遇到错误时立即停止，仅报告第一个错误。这在代码存在多个错误或进行大型重构时，会导致语言服务器信息过时，影响IDE功能。
• 现在：编译器在分析模块时遇到错误会跳过并继续处理下一个定义，最终返回所有错误及更新的代码信息。这显著提高了语言服务器的响应速度和准确性，尤其在长时间未成功编译的场景下。
• 未来将改进容错编译的粒度并引入容错解析。

2. 语言服务器导入增强

• 现在可以在编写 import module.{...} 时，自动补全模块内具体要导入的类型和值。
• 支持在导入语句中对类型、值和模块本身进行悬停查看文档和跳转到定义。

3. 单行管道表达式

• 如果一系列管道操作足够短，现在可以将它们全部写在同一行，代码格式化器不会强制换行。
• 可以通过手动添加换行符来强制将管道拆分为多行。

4. use 表达式错误信息改进

• 针对 use 表达式中常见的错误（如右侧不是函数、函数参数数量不正确等），提供了更具体、更有指导性的错误信息，降低了学习和调试难度。

5. 类型/值混淆反馈

• 当尝试将类型作为值导入，或将值作为类型导入时，编译器现在会检查是否存在匹配项，并明确提示混淆错误，例如“One 只是一个类型，不能作为值导入”。

6. 断言穷举性检查

• 编译器现在会对 let assert 语句进行穷举性检查。如果模式已覆盖所有可能性（即模式是穷尽的），则会发出警告，提示该断言是冗余的。

7. 检测常见崩溃错误

• 针对 todo 和 panic 表达式，如果错误地使用函数调用语法（如 panic("message")），编译器会发出警告，因为参数不会被用作消息。

8. 常量函数调用错误改进

• 现在尝试在常量中调用函数时，会给出清晰的错误信息（“函数只能在其他函数内部调用”），而不是令人困惑的解析错误。

9. 不可达代码检测

• panic 表达式之后的代码永远不可达。编译器现在会对这种情况发出警告。

10. 更多与Hex包管理器的集成

• 新增 gleam hex revert 命令，允许在发布后24小时内撤回一个包版本。
• 改进了尝试发布已存在版本时的错误提示。

11. Erlang模块名冲突预防

• 现在，如果Gleam模块编译后的Erlang模块名与Erlang/OTP内置模块同名，构建工具会报错，防止因覆盖内置模块导致运行时错误。

12. 其他改进与修复

• 冗余模式匹配警告：当在 case 表达式中对多个值进行匹配时，如果使用了不必要的元组或列表包装，编译器会发出警告并建议直接匹配多个主体。
• 冗余模式自动修复：语言服务器提供代码操作，可自动移除 case 表达式中冗余的元组包装。
• JavaScript程序员辅助：错误地使用 === 进行比较时，会提示应使用 ==。
• 构建工具改进：改进了 manifest.toml 文件损坏时的错误提示；简化了依赖解析失败时的错误消息。
• 包含了大量错误修复。

致谢 感谢所有赞助者和贡献者，特别是Ameen Radwan、Giacomo Cavalieri、Pi-Cla、Nino Annighoefer、Nicky Lim、Rabin Gaire、zahash等人在本次版本中的突出贡献。

该内容主要描述了arXiv网站页面的辅助功能模块，与量子计算机主题无直接关联。页面包含以下核心功能区域：

1. 文献工具

   • 提供文献浏览和引用工具，包括“文献浏览器”（Bibliographic Explorer）开关功能。

2. 代码、数据与媒体

   • 列出与文章相关的代码、数据和媒体资源链接。

3. 演示与推荐

   • 包含演示项目列表和相关论文推荐/搜索工具。

4. arXivLabs

   • 介绍arXivLabs作为与社区合作者开发实验性功能的平台，强调开放性、社区协作、卓越品质和用户隐私保护价值观。

需要说明的是，未提供量子计算机主题的实际文章内容，以上仅为页面辅助功能模块的总结。

GTFL – Common Lisp 的图形终端

核心概述

GTFL 是一个专为 Common Lisp 设计的图形化调试和可视化工具。它允许 Lisp 程序员将算法运行过程、复杂数据结构或控制流等信息，以动态的、交互式的图形化形式推送到 Web 浏览器客户端页面上，从而替代传统的、难以阅读的文本监听器输出。

工作原理与技术架构

• 客户端-服务器模型：GTFL 包含两个主要组件：一个运行在 Web 浏览器中的 HTML 客户端页面，以及一个作为中间件的 Lisp Web 服务器。
• 通信机制：Lisp 端维护一个“请求列表”。客户端页面通过每 200 毫秒进行一次的 AJAX 长轮询，异步获取列表中的内容并渲染。服务器基于 HUNCHENTOOT 构建，客户端/服务器通信使用 HT-SIMPLE-AJAX 库。
• 内容生成：使用 CL-WHO 库将 Lisp 的 S-表达式转换为符合 XHTML 1.0 Strict 标准的 HTML 代码。

主要功能与应用

1. 基础内容输出与操作：

   • start-gtfl：启动 Web 服务器（默认地址 localhost:8000）。
   • gtfl-out：向客户端页面推送 HTML 内容（使用 CL-WHO 语法）。
   • replace-element-content、append-to-element：动态更新或追加页面中特定元素的内容。
   • who、who2s、who-lambda：辅助宏/函数，用于方便地生成 HTML 字符串或函数。

2. 可交互的可展开元素：

   • 提供 make-expandable/collapsable-element 等函数，用于创建初始折叠、可点击展开的 HTML 元素。
   • 设计高效：仅将折叠版本发送至浏览器，展开版本存储在 Lisp 端，按需发送。
   • 支持元素组的同步展开/折叠（make-expand/collapse-all-link）。

3. 树状结构绘制：

   • draw-node-with-children 函数可递归绘制树状图，自动生成连接线。
   • 布局自适应浏览器窗口宽度，并可配置方向（从右到左）、颜色、线宽等样式。

4. S-表达式的动态排版显示：

   • html-pprint 函数能像 Lisp 的 pprint 一样美化打印 S-表达式，但输出是动态排版的，能根据浏览器窗口宽度自动调整布局并保持缩进。

5. 自定义扩展：

   • define-css、define-js：向客户端页面注入自定义 CSS 和 JavaScript 代码片段。
   • make-id-string：生成唯一 ID，用于操作 HTML 元素。
   • reset-gtfl：重置客户端页面和 Lisp 端状态，支持通过 *reset-functions* 钩子自定义重置逻辑。

典型应用场景

• 算法调试：可视化展示算法内部状态和步骤，例如在 流体构式语法 框架中跟踪语言解析和生成过程。
• 数据结构可视化：交互式展示复杂数据，如 asdf 系统的依赖关系树，用户可通过点击节点展开/折叠详情。

安装与兼容性

• 安装：可通过下载 tar 包手动安装，或使用 Quicklisp ((ql:quickload "gtfl")) 或 ASDF-INSTALL 自动安装依赖。
• 依赖：依赖 CL-WHO、HUNCHENTOOT (≥1.1.0)、HT-SIMPLE-AJAX 及它们的一系列依赖库。
• 浏览器支持：2012 年时，除 Internet Explorer 外，所有现代浏览器均可正常工作。

许可与来源

GTFL 采用 BSD 风格许可证 发布。最初作为 Babel2 框架 的一部分开发。

一个与时俱进的空气质量模型

空气质量是影响全球人类健康与福祉的最大因素之一。空气污染来自多个来源，包括电力、工业、住宅和交通部门的化石燃料燃烧，以及野火、农业活动等。它与气候相互作用，加剧无数健康状况，并估计每年导致数百万人死亡。保障公众健康和应对气候变化，依赖于对空气质量进行稳健的影响评估和制定有效的政策，而这又需要准确理解空气组成及其变化过程。

几十年来，科学家运用基于观测的多尺度建模方法，以增进对空气质量及其与气候相互作用的理解和预测能力。这类研究正变得越来越深入、越来越能揭示过程细节，并且越来越被更广泛的群体所使用。此类方法持续成功的关键在于，所用模型必须跟上科学知识、建模技术以及地球观测系统能力的发展步伐，并且其有价值的特点应被解读其结果的科学家和决策者充分认识。

本文回顾了其中一个有影响力模型——开创性的硫输送与沉积模型的历史，并展望了它如何能持续揭示更多关于空气质量、气候和其他社会重要问题的信息。

硫模型的先行之路

STEM的开发始于1976年，远早于许多同时代的空气质量与大气化学模型。当时，化石燃料消耗屡创新高，而有效的排放物硫清除技术尚未广泛应用。由此产生的大气硫污染和酸雨对人类、基础设施和生态系统造成了日益严重的负面影响。这些影响也提高了人们的意识，即空气污染不仅是一个局部问题：一个地方的排放可能影响下风向数百甚至数千公里之外的地方。STEM最初旨在帮助理解大气硫的输送、转化和去除过程，并为减排策略提供信息。

自创建以来，STEM已扩展到涵盖更广泛的关键空气污染物，如臭氧和颗粒物，这些问题也造成了区域性乃至洲际影响。结合广泛使用的气象模型（包括WRF和MM5的多个版本），STEM已被用于研究美国、北极、亚洲和南美洲等地区的空气质量，并为数百篇同行评审出版物做出了贡献。这些研究突出了此类模型在解决与大气化学物质分布、量化其环境影响以及评估环境缓解策略相关的广泛科学问题方面的用处。

通过回答这些科学问题，STEM还展示了模型支持机载和地面实验设计和部署的能力，其中许多实验由NASA或其他机构领导。例如，在2001年NASA的TRACE-P实验期间，STEM对太平洋上空污染流出区域的每日预报被用于帮助规划飞机采样空气污染物的位置。在实地应用STEM也使其能够用于解释和提供收集观测数据的背景，从而帮助改进了模型。此后，空气质量模型在此类预报应用中的使用急剧扩大，如今这些模型已在城市、国家和全球尺度上运行使用。

STEM还通过支持Aura等卫星任务、促进其主要数据产品的新应用、刺激新检索产品的开发和评估，以及参与国际多模型比较实验（如亚洲模型比较研究和半球输送空气污染物工作组），为科学界服务。这些实验有助于更稳健地估计空气污染的源-受体关系及环境影响，并帮助科学家更好地理解各种模型比较中的优缺点。

简洁、稳定与灵活

STEM悠久的历史和广泛的应用塑造了其主要技术优势。这些优势包括其结构简洁，便于用户修改；稳定性，基于数十年与现场和实验室测量及其他过去应用信息的调整而建立；以及灵活性，提供了生成化学边界条件和其他关键输入的灵活工具以及先进的数据同化能力。特别值得一提的是动力学预处理器软件的开发，它使得更改STEM（及其他模型）中使用的化学机制变得容易，并提高了其同化观测数据的能力。

这些特性使得使用该模型的研究人员在空气质量和气候领域都做出了与政策相关的显著科学贡献，并在全球范围内培训了数十名学生和早期职业科学家。这些贡献包括利用真实世界观测推导短寿命和长寿命气候强迫因子（如氮氧化物、二氧化碳、羰基硫）及其前体物的地表-大气通量，理解控制它们的因素；将气溶胶对空气质量和气候的影响归因于不同源部门（如能源生产、工业过程、交通、住宅来源和野火）的排放；以及识别在气候变化下大气环流和排放模式变化中的空气污染源。

这些基于STEM模型的研究激发了后续关于新应用的研究和讨论。例如，它们引发了关于使用羰基硫作为总初级生产力代理的讨论，因为植物吸收羰基硫与二氧化碳之间存在联系，这进一步导致开发和应用基于卫星的数据产品来追踪羰基硫。

同时，研究人员正在继续开发方法，以减少估计不同区域和源部门的气溶胶和温室气体排放对健康和气候影响的不确定性。这些努力部分涉及整合跨学科的地球观测，以改进用于进行这些估计的过程级约束。观测驱动的分析也在推进，以改进对背景空气污染水平的估计，这些信息与在气候变化下更新空气质量标准相关。

与时俱进以保持相关性

尽管STEM在其历史中已成果丰硕，但更新它（及类似模型）是必要的，以确保它仍然是空气质量与气候科学家研究环境和为政策制定及大气观测系统设计提供信息的一个稳健选择。

维持和增强可用于空气质量管理的模型的多样性非常重要，因为单个模型的预测（及其影响）仍存在重大不确定性。对STEM进行的主要更新正在进行中，以改进模型如何与最新和下一代气象与地表建模系统（例如可变分辨率运行的MPAS和能模拟多种配置下植被动态的Noah-MP地表模型）对接。这些更新可以促进大气沉降等过程的更好表示。STEM也将与区域和全球气候模型更紧密地整合，并将在逐渐更精细的、卫星可分辨的公里级或更低尺度上应用。

社区对STEM的目标和更新的输入一直在收集，且建议总是受欢迎的。理想情况下，STEM应适应在新一代高性能超级计算系统上运行，或许结合商业云计算、人工智能和机器学习及其他技术。

额外的更新可能包括提供模型元素、特性和执行步骤的详细文档，以及精心设计的后处理和可视化程序，以提高模型结果的可解释性和传播性。此外，模型可以更新以支持众包科学项目，通过整合来自或为其提供数据。用户社区应能够从集中、开放访问的平台轻松访问和贡献经过整合和现代化的模型及其相关文档。

这些更新将允许像STEM这样的模型在比以前更广泛的空间和时间尺度上实施，并支持新兴主题的研究，例如与环境正义相关的研究。区域到局部的空气质量模拟及其影响因素，结合社会经济数据，可以澄清某一感兴趣区域内的环境不平等状况，并帮助评估涉及移民、搬迁或城市或生态系统适应的潜在解决方案。

几十年来，STEM模型通过为塑造科学理解、基于科学的政策制定和软件设计贡献对空气质量、气候和环境的见解，证明了其价值。通过持续和计划中的更新，该模型在这些目的上的实用性将在未来许多年继续存在，其对新应用的相关性也将增长。

摘要内容：

本文描述了GitHub平台的网页界面，旨在展示GitHub作为AI驱动开发平台的各种功能和服务。内容主要包括以下方面：

• AI辅助编码：通过GitHub Copilot提供AI代码创建功能，帮助开发者编写更好的代码。
• 开发工作流自动化：包括GitHub Actions用于自动化工作流，Codespaces提供即时开发环境。
• 项目管理与协作：使用Issues进行计划和跟踪工作，Code Review管理代码变更。
• 应用安全：GitHub Advanced Security用于查找和修复漏洞，保障代码安全，防止秘密泄露。
• 平台探索与分类：用户可按公司大小（企业、中小团队、初创公司、非营利组织）、用例（应用现代化、DevSecOps、DevOps、CI/CD）和行业（医疗、金融、制造、政府）浏览解决方案。
• 探索主题与类型：涵盖AI、软件开发、DevOps、安全等主题，以及客户故事、活动、电子书等资源类型。
• 支持与社区：提供文档、客户支持、社区论坛、信任中心和合作伙伴等资源；社区项目包括GitHub Sponsors、安全实验室、维护者社区、加速器和GitHub Stars。
• 企业解决方案：介绍GitHub企业平台，提供AI开发者平台、高级安全功能、企业级AI功能和24/7高级支持。
• 界面交互元素：包括反馈提交、保存搜索功能、登录/注册选项和外观设置等用户界面组件。

整体上，该网页内容突出了GitHub作为集成开发平台的优势，涵盖从编码到部署的全流程工具，支持不同规模和行业的开发团队。

Blink Code: 在iOS设备上运行VSCode的集成方案

Blink Code是Blink Shell中集成的强大功能，旨在将完整的VSCode体验引入iOS设备，支持本地与远程开发。

核心功能与连接方式

• 统一的开发环境：提供适配设备的VSCode体验，可连接至VSCode Web、GitHub Codespaces、GitPod或自托管的Code Server。
• 灵活的文件系统：通过Blink Files扩展，能够直接编辑本地文件或远程文件（如同编辑本地文件一样）。
• 原生iOS体验：完美支持软硬件键盘，并提供无中断的全面屏体验。

使用方法

1. 启动与初始设置：
   • 在终端中运行 code <路径或URL> 命令。首次启动时，需要安装blink-fs扩展以连接Blink文件系统。
2. 打开远程项目：
   • 语法：code <主机>:<项目路径>。需确保主机已配置好免交互认证（如密码）。
   • 若主机已启用Files.app集成，也可在文件管理器中长按文件/目录并选择“Code”来打开。
3. 连接云端代码实例：
   • 语法：code <URL>（例如 code https://gitpod.dev/xxxxx）。
   • 支持GitHub Codespaces、GitPod和Code-Server等特定域名。对于私有IP，建议通过隧道以localhost访问。
   • Blink会捕获vscode://链接，可实现类似“在桌面应用中打开”的功能。
4. 编辑GitHub仓库代码：
   • 在界面左下角点击><按钮，选择“Open Remote Repository”，登录GitHub后即可浏览和编辑仓库代码。

技巧与配置

• 屏幕键盘：集成了与终端相同的屏幕键盘，并包含Ctrl、Cmd、Meta等修饰键。
• 键盘快捷键：部分Blink Shell的快捷键可能会覆盖VSCode的默认快捷键，可根据需要重新配置。

故障排除

• 加载问题：若VSCode显示空白，尝试关闭标签页重新运行code命令，或关闭并重启Blink应用。可尝试使用--vscode-url参数或通过Safari测试同一URL是否可访问。
• 扩展与连接：确保blink-fs扩展已安装启用；确保远程主机已启用SFTP且认证无需人工交互；检查远程路径是否有效。
• 日志与支持：查看日志文件 ~/.blink/blinkCode.log 获取线索。如遇问题，可在GitHub Discussions中提交支持请求并附上日志。

谷歌搜索内部工程文档泄露分析摘要

事件概述

谷歌搜索内容仓库API（Content Warehouse API）的内部文档因代码库配置失误被意外泄露。该文档包含2596个模块和14014个属性特征，详尽揭示了搜索算法的底层数据逻辑，并证实了谷歌官方过往的诸多公开声明存在误导。

揭露的四大官方“谎言”

1. 域名权重：谷歌否认使用“域名权重”，但文档显示存在 siteAuthority 特征，应用于Q*排名系统。
2. 点击数据：谷歌否认使用点击率（CTR）和停留时间，但文档证实 NavBoost 系统深度依赖点击信号（如好/坏点击、最长点击等）进行排名调整。
3. 新站沙盒：谷歌否认沙盒机制，但文档中的 hostAge 属性明确用于“在提供时隔离新鲜垃圾内容”。
4. Chrome数据：谷歌否认使用Chrome数据，但页面质量评分等模块确实使用了Chrome浏览量数据。

系统架构与核心算法

• 微服务与Twiddlers：搜索算法并非单一公式，而是由数百个微服务组成。Twiddlers 是主算法后的重排函数，用于动态调整得分或限制结果多样性。
• Panda与NavBoost：Panda算法基于独立外链数与参考查询（NavBoost查询）的比例计算质量修改因子；NavBoost 则是基于用户点击行为的核心重排系统。

对SEO的核心影响

• 链接价值：索引层级影响链接权重，高层级或新鲜页面的链接价值更高；首页PageRank和信任度被用作新页面的代理指标；企鹅算法会丢弃部分内部链接；锚文本和词汇的字体大小会被系统追踪。
• 内容特征：文档存在Token截断限制，核心内容需前置；短内容会评估原创性；页面标题与查询的匹配度依然重要；页面日期需在URL和结构化数据中保持一致。
• 降权与分类：存在锚文本不匹配、SERP体验差、精确匹配域名等多种降权信号；YMYL（你的钱你的命）内容有专门分类器；视频占比超50%的网站会被区别对待。
• E-E-A-T与偏题检测：系统明确存储作者信息并结合向量嵌入进行评估；使用站点向量嵌入（Site Embeddings）衡量页面是否偏离网站核心主题。

战略行动建议

• 专注优质内容与推广：创造能引发受众共鸣的内容并有效推广，以获取真实的点击和多样化链接信号，这是应对算法（如Panda和HCU）的根本。
• 坚持实验与测试：不要盲信谷歌的公开声明，SEO从业者应建立系统的实验计划，通过数据测试验证策略。
• 回归SEO本质：深刻理解受众需求，提供最佳用户体验，确保技术可访问性并持续进行站外推广。

菱形立交：革新传统交叉路口的设计

设计原理与核心优势

菱形立交是一种非常规的立交设计，其核心特点是车辆在进入立交时会通过红绿灯控制，在特定路段短暂切换到道路左侧行驶。这种设计使左转变得简单高效，因为左转时无需面对对向来车，可实现“自由左转”。

与传统立交相比，菱形立交能显著提升效率与安全性。左转操作在传统路口会产生大量与行人和车辆的“冲突点”，而菱形设计通过重构交通流线，减少了侧面碰撞和T型碰撞的风险，这类事故往往更致命。

实际应用与效果

该设计于2009年首次在美国密苏里州斯普林菲尔德的一个拥堵路口投入使用。应用后，原本左转需等待20分钟的情况立即得到改善，且事故率立即下降了40%至50%。

目前全美已有超过200个菱形立交，分布在30多个州。弗吉尼亚州的案例显示，立交桥上的交叉设计虽然初看令人困惑（车辆会短暂行驶在左侧道路），但熟悉后能有效提升通行效率。

公众反应与设计发展

驾驶员对此设计看法不一。部分人（如校车司机）认为不熟悉该设计的驾驶员可能带来安全隐患；而另一些使用者则称赞其减少了交通拥堵和事故。

该设计由交通工程师吉尔伯特·克莱维茨基提出。他自幼热爱道路设计，于2003年在马里兰大学读研究生期间首次发表相关论文。尽管法国等国家早有类似设计，但他确立了“菱形立交”的名称并推动其在美国普及。美国联邦公路管理局的支持加速了该设计的推广。

克莱维茨基目前任职于弗吉尼亚州交通部，正探索将菱形立交与环形交叉口等其他创新设计结合的新方案。对他而言，用二十年将一个学术概念转化为广泛应用，已是政府主导的复杂工程中“非常迅速”的进展。

R语言中面向对象编程支持的概括性扩展

R语言内置了两个函数式面向对象编程（OOP）系统：S3和S4，它们分别对应S语言的第三和第四版。这两个系统基本兼容，但本质上是两个独立系统，给用户、开发者和R核心维护者都带来了理解和协调的负担。

S7 是一个正在开发的新OOP系统，由R-Core、Bioconductor、tidyverse/Posit、ROpenSci以及更广泛的R社区代表合作，目标是统一S3和S4，并提升互操作性。长期目标是将S7整合进R的基础系统中。

开发S7促使作者反思如何更通用地支持像S3、S4、S7这样的函数式OOP系统，因为此领域仍有创新空间。这三个系统存在一些共性：

• 将类、泛型和方法重定义为对象（S4和S7中）。
• 通过泛型根据一个或多个输入参数分派到方法实现来实现多态性。
• 将对象建模为组件的集合（如槽或属性），这些组件可以被访问和修改。

为了更方便地基于S3实现像S7这样的包，R基础系统已整合了四个补丁，引入了四个新的S3泛型：

1. chooseOpsMethod()
2. %*%
3. nameOfClass()
4. @

这些增强功能对于集成或实现替代OOP系统的包普遍有益。本文将概述这些新泛型、驱动其实现的S7特性，以及它们对S7之外更广泛R社区的用途，并以 reticulate 包（桥接Python与R的S3系统）为例进行说明。

1. chooseOpsMethod()

S3泛型仅支持基于第一个参数的分派，而S4泛型支持基于任意数量参数的分派。S7在S3之上实现了双重分派（即对恰好两个参数进行多重分派）。S7的分派分两阶段：S3泛型先基于第一个参数分派到一个S7感知的方法，然后调用S7内部的多重分派机制。

任何分派实现的一个通用复杂性在于，原始函数和其他具有内部实现的函数必须在C代码中进行内部分派。内部分派与多重分派在 Ops 组泛型（包含 +, -, * 等中缀二元运算符）处交汇。在R 4.3.0之前，如果两个参数会导致分派到不同的方法，R会发出警告并使用两者都不适用。

从R 4.3.0开始，如果找到Ops泛型的第一个和第二个参数的不同方法，R会调用 chooseOpsMethod()，为对象类型提供机会声明其Ops方法实现可以处理该组合。如果为某个对象调用的 chooseOpsMethod() 方法返回 TRUE，则使用为该对象找到的方法。

这允许S7对象类型定义可以与其他S3对象（如 Sys.Date()）一起工作的 + 方法。同样，reticulate 包可以利用它实现一个默认的 + 方法来调用对应的Python例程，同时仍允许用户为特定的Python对象类型定义自定义 + 方法，从而解决了以前当两个参数都是S3类实例但分派到不同方法时的兼容性问题。

2. %*%

基础R定义了其他内部支持某种形式多重分派但不属于Ops组的运算符，矩阵乘法运算符 %*% 就是一个典型例子。

在R 4.3.0之前，%*% 仅适用于S4对象或基础R对象。现在，也可以为此运算符定义S3方法。与Ops组泛型类似，%*% 将基于第二个参数进行分派，并使用 chooseOpsMethod() 解决冲突。

为了启用此新行为，创建了一个新的泛型组：matrixOps。目前该组的唯一成员是 %*%，未来 crossprod() 和 tcrossprod() 预计将加入该组。matrixOps 组的添加是一个向后兼容的变更，旨在使现有运算符能够与S3和S7一起工作。

3. nameOfClass()

S7将类重定义为对象，其用户界面基于这些对象而非类名。S3分派中存储的类名被视为实现细节（它并非语法规范的，并且为了减少冲突被修改，且不面向用户）。此外，如果泛型定义在包之间迁移，该名称可能会改变。

因此，能够在不直接使用S3类名的情况下检查继承关系是可取的。为此，从R 4.3.0开始，base::inherits() 函数现在接受任意对象作为第二个参数：如果第二个参数是S3对象，则会调用新的 nameOfClass() S3泛型来解析适当的类名。

这对 reticulate 也有用处，例如在Python对象的S3类向量从其定义的Python模块生成的情况下，nameOfClass() 方法确保了跨Python库版本的兼容性。

4. @

在R 4.3.0之前，@ 运算符仅可用于访问S4对象的槽。从R 4.3.0开始，此运算符现在也可以执行S3分派。这使 @ 与早已能够进行S3分派的 @<- 运算符达到同等地位，并使 @ 在分派能力上与 $ 成为同级。

这是一个严格向后兼容的更改，因为只有在S4例程有机会分派之后，才会执行S3分派。S4和S7的一个优点是能够具有形式上定义的槽或属性；在S7中，有一个用于属性访问的专用运算符是可取的。我们期望其他OOP系统也将具有类似的概念，并从这种泛化中受益。除了执行S3分派外，基础R中的 @ 运算符没有其他面向用户的更改——在没有S3方法的情况下，@ 的默认行为保持不变。

总结：这些四个新引入的S3泛型（chooseOpsMethod()、%*%、nameOfClass()、@）主要目的是为了更好地支持和推广函数式OOP系统（特别是S7）在R中的实现，并提升不同OOP系统（如S3、S4、S7）以及R与其他语言（如通过reticulate连接的Python）之间的互操作性。它们通过增强R基础系统的分派机制和类处理能力，使开发者能够更灵活、更一致地构建和集成面向对象的代码。