作者需要拥有独立网站，而非依赖Substack

文章核心观点：Substack仅应作为内容分发工具，而非作者的数字家园。作者应拥有并控制自己的独立网站域名。

问题：将Substack作为主要基地的风险

• 许多作者已离开自己的网站，转而将Substack视为数字家园。
• 即使购买了域名并链接到Substack，该平台作为内容管理系统（CMS）功能有限，尤其在SEO管理和页面自定义方面存在不足。
• 若使用 xx.substack.com 格式的链接，作者实际上是在向Substack让渡内容控制权。
• 这种做法是短视且不明智的，可能损害作者在互联网上的长期可见性。

平台依赖的“方便”陷阱

• 每隔几年，互联网便会推出一个新的“数字天堂”（如Facebook、Tumblr、Medium、Substack），承诺提供受众、变现和社群支持。
• 然而，在他人平台上建立受众意味着作者是“租客”或“数字佃农”，而非“业主”。
• 企业房东（平台）最终总会改变规则，以满足投资者或股东的利益，作者的数字资产可能因公司决策而瞬间消失。

独立网站：永恒的数字基地

• 作者的创作需要一个由自己拥有和控制的永久基地——一个独立的域名。
• 长期案例：科幻作家John Scalzi在自己的独立博客 whatever.scalzi.com 上持续写作了28年，不受任何平台兴衰影响。他的网站构成了他的“机构记忆”和官方记录。

解决方案：采用“POSSE”模式

• 核心策略：POSSE（Publish on your Own Site, Syndicate Elsewhere），即在自己的网站上发布，然后同步到其他平台。
• 操作方式：
  1. 将个人网站视为内容的唯一真实来源。
  2. 将Substack等平台视为分发渠道，用于吸引读者。
  3. 最终目标是将读者引导回自己的网站。
• 这种方法让作者既能享受平台的受众流量，又能保持对内容的主权。

对平台局限性的现实认知

• 平台算法和规则会迫使作者顺从平台偏好，可能导致内容同质化，不利于地方性或少数群体声音的传播。
• 盲目追求下一个“纯净”平台是徒劳的。技术会变，企业算法会优先考虑利润，平台会经历炒作与衰落的周期。

结论

• 作者应停止在“租来的土地”上进行数字佃耕。
• 通过拥有一个使用RSS等开放分发渠道的独立网站，可以从根本上摆脱对平台兴衰的依赖。
• 利用平台寻找读者，但要将他们带回自己的“家”。

@openai/codex-security 是一款用于查找、验证和修复代码安全漏洞的 CLI 工具和 TypeScript SDK。

主要功能与使用

该工具通过命令行进行漏洞扫描，基本命令如下：

npm install @openai/codex-security
npx @openai/codex-security login
npx @openai/codex-security scan . [选项]

扫描模式可配置，例如：

• --mode deep：深度扫描模式。
• --model gpt-5.6-terra：指定特定模型。
• --effort high：设置扫描强度。
• --workers 和 --subagents：配置并行工作线程和子代理。
• --stop-after-no-new 和 --max-discovery-runs：控制扫描终止条件。

环境与认证

• 系统要求：Node.js 22.13.0+ (22.x)、24.x 或 26.x，以及 Python 3.10+。
• 认证方式：
  1. 登录：通过 npx @openai/codex-security login 进行交互式登录。
  2. API 密钥：在 CI 环境中，可设置 OPENAI_API_KEY 或 CODEX_API_KEY 环境变量，这些密钥仅用于当前扫描，不会被存储。
• 支持多种推理提供商：通过设置对应环境变量并使用 --provider 和 --model 参数，可接入 OpenRouter、Fireworks、Amazon Bedrock 等服务。
• 凭证管理：工具使用独立的持久化状态目录存储登录和扫描凭证。若同时存在 ChatGPT 登录和 API 密钥，交互式扫描会提示选择，非交互模式默认使用 API 密钥。可通过 --auth chatgpt 或 --auth api-key 显式指定。

扫描结果与诊断

• 扫描历史存储在状态目录中，可通过 CODEX_SECURITY_STATE_DIR 环境变量自定义路径。
• 结果比较：scans compare BEFORE_SCAN_ID AFTER_SCAN_ID 命令可自动匹配漏洞根因，识别新增、持续、重现、已解决或未知的发现。
• 详细日志：使用 --verbose 选项可向标准错误输出扫描诊断信息。设置 CODEX_SECURITY_LOG_LEVEL=debug 或 LOG_LEVEL=debug 也可启用诊断，且凭据和提供商标识符会被编辑。

TypeScript SDK

SDK 提供了编程接口：

import { CodexSecurity } from "@openai/codex-security";

const security = new CodexSecurity();
const result = await security.run(".", { mode: "deep", workers: 2, /* 其他选项 */ });
console.log(result.reportPath);
await security.close();

容器化扫描

官方提供 Docker 镜像和 Docker Compose 配置，用于对固定 Git 版本的仓库进行非交互式、可恢复的扫描。可通过 --knowledge-base PATH 参数共享安全文档。

文档与帮助

更详细的命令帮助、运行时默认值、多代理工作线程限制、环境变量、深度扫描配置和 SDK 选项，请参阅 包 README 和 官方 CLI 参考文档。

本文介绍了在越狱Kindle上使用Tailscale的增强功能，主要基于社区开发者的改进。核心更新包括默认启用Tailscale SSH、新增代理模式以及部分设备支持的完整TUN模式。

主要改进功能

1. 默认启用Tailscale SSH：无需依赖USB网络SSH及其默认的不安全凭证，提升连接安全性。
2. 代理模式：通过本地代理（SOCKS5和HTTP CONNECT模式）使KOReader等应用能够访问Tailnet中的其他节点（如Calibre、Wallabag服务器），解决用户态模式下无法直接路由Tailscale IP地址的问题。
3. 完整TUN模式：在部分Kindle上实现设备级别的网络路由，提供更完整的Tailscale网络体验。

代理模式的工作原理与应用场景

• 工作原理：应用（如KOReader）通过设置代理地址（如127.0.0.1:1055）连接本地代理，代理再将请求转发至Tailnet，从而实现数据交换。
• 应用场景：
  • 连接Calibre或Wallabag内容服务器。
  • 通过KOReader访问Audiobookshelf有声书服务器。
  • 使用Readest同步跨设备阅读进度。
  • 通过KOReader的RSS阅读器连接自托管的Feed服务器。
  • 在Kindle浏览器中访问简易仪表板或网页。
  • 结合蓝牙键盘和kterm应用SSH连接Tailnet设备。

KOReader专用Tailscale插件

• 功能：独立于KUAL应用，专注于为KOReader创建代理接口，支持Kindle、Kobo和PocketBook设备。
• 安装步骤：将插件复制到KOReader插件目录，通过菜单安装/更新Tailscale，复制密钥文件并启用Tailscale，最后在KOReader中配置代理地址。
• 兼容性：已在Kindle PW5/PW6、Kobo和PocketBook上测试，可配合SyncThing插件实现内容同步。

注意事项

• 以上功能基于社区代码，适用于非官方越狱设备状态，可能需要耐心调试。
• 改进显著增强了Kindle在Tailnet中的连接能力，扩展了其作为便携终端的实用性。

文章摘要：Demo Scene 的用户界面

本文探讨了 Demo Scene（数字艺术亚文化）中工具的用户界面设计特点。Demo Scene 的参与者（Sceners）倾向于自行开发或改造工具，这些工具的界面往往因实验性、平台限制和独特的创作需求而显得奇特甚至不直观。

1. 正弦波预计算工具

• Elite Sinus Producer (Amiga)：用于创建查找表（precalc），界面包含主菜单、用F键选择功能（并伴有杜鹃钟声音）、可保存为汇编源代码的图形路径生成器，以及一个背景闪烁、字体古怪的帮助屏幕。
• The Sinus Creator (Amiga)：另一款正弦预计算器，采用双窗口文本界面，结果可保存为Seka源文件。

2. 基于文本的界面

• 汇编器：Seka 2.0（商业汇编器衍生）和 Asm-One（Seka的更新版）是场景中常用的汇编器，它们通常询问内存分配大小后进入命令行模式。Asm-One等版本打开了自己的屏幕，而非在工作台窗口中运行。
• 内存提取工具：如 Multi-Ripper（用于从内存中提取游戏中的音乐、图形数据）和专为从崩溃后的内存中提取Seka源代码而设计的工具。
• 其他文本工具：包括用于ANSI/BBS图形编辑的 Digital Intelligence's Ansi-Editor v2.4（界面奇特，工具栏颜色显示不可直接选择）和用于Commodore 64的 SoundMonitor 1.0（早期跟踪器，界面启发了后续工具）。

3. 音乐跟踪器

• 起源与演化：从Chris Huelsbeck的SoundMonitor（C64）开始，经Karsten Obarski的商业Ultimate Soundtracker（1987），衍生出场景中广泛使用的NoiseTracker、ProTracker等。版本和变体众多。
• 界面特点：
  • ProTracker：界面密集，“Disk Op.”按钮打开文件选择器，操作逻辑独特，存在垂直的“EXIT”按钮，容易误操作。
  • Fasttracker II (MS-DOS)：功能强大（支持多声道、16位采样），界面包含类似“贪吃蛇”的小游戏。
  • Abyss' Highest Experience (Amiga)：模拟SID芯片音色的芯片音乐跟踪器，界面融合了Soundtracker风格和Workbench 2.0元素。
  • JamCrackerPro (Amiga)：采用系统友好的多窗口界面，而非传统跟踪器布局。
  • Digicomposer 1.0 (Atari ST)和Megatizer (Atari ST)等，体现了跨平台的界面借鉴和创新。

4. 磁盘复制工具

• 用于复制演示和破解软件，因为标准工具常无法处理直接写入磁道的特殊磁盘。
• X-Copy：虽非纯粹场景原创（后商业化并遭破解），但被场景广泛使用。界面包含显示磁盘磁道状态的网格，完成时有“boing”声提示。
• D-Copy：作者个人偏爱的、界面“酷炫”的非商业场景产品。

5. 其他工具与相关软件

• 压缩器：如Titanics Cruncher (Amiga)，用于可执行文件的不对称压缩，以空间换时间。
• 字体/字符编辑器：如Charedit (MS-DOS)，用于创建滚动文本所用的字体。
• 专用硬件编程工具：如DSPdit (Atari Falcon)，用于56001 DSP的编辑器和汇编器，采用GEM工具包，界面简洁专业。
• 病毒查杀工具：SCA（瑞士破解协会）在制造了首个Amiga引导扇区病毒后，也发布了首款病毒查杀工具，界面直接。
• Trackmo工具与文件管理器：如TrackmoDOS (Amiga)，用于创建和管理不依赖文件系统的“trackmo”演示，其文件管理器界面带有色彩渐变。
• 磁盘杂志：如RAW (Amiga)，一种在软盘上发行的周期性刊物，UI带有纹理和渐变，内置调色板编辑器。
• 图形工具：虽然场景很少自制像素画软件，但Deluxe Paint是占绝对主导地位的工具，广泛应用于Amiga和PC的图形创作，包括游戏领域。文中也提及了其他平台的工具，如FuckPaint (Atari Falcon)。

总结

Demo Scene 的工具用户界面反映了其亚文化特质：追求技术极限、实验性、平台特异性，以及往往优先考虑功能而非传统可用性的设计哲学。这些界面既是历史产物，也承载了场景的创意与个性。

KOReader 文档查看器

KOReader 是一款专为 E Ink 设备设计的文档查看工具。它支持多种文件格式，包括 EPUB、PDF、DjVu、XPS、CBT、CBZ、FB2、PDB、TXT、HTML、RTF、CHM、DOC、MOBI 和 ZIP 文件。该应用可在多种平台上使用，如 Kindle、Kobo、PocketBook、Android 和桌面 Linux 系统。

DeltaNet系列线性注意力变体概述

背景与动机

现代线性注意力变体旨在解决标准Softmax注意力在自回归推理中的二次方复杂度问题。标准注意力（O_t = ∑_{i≤t} a_{ti} v_i）因softmax的分母依赖于所有历史键-查询对，导致缓存随序列增长、每次查询需遍历整个历史。线性注意力通过移除softmax，将注意力重写为固定大小状态矩阵的递归更新与读取： S_t = S_{t-1} + v_t ⊗ k_t，o_t = S_t · q_t。 此形式将复杂度降至线性（O(T)），但存在关键缺陷：加法更新（+=）会干扰旧记忆。若当前状态已正确关联某键，新写入会累加而非替换，导致输出翻倍。

DeltaNet：写入误差而非原始值

DeltaNet引入delta规则修正上述问题，有两种等效推导视角：

1. 要求写入可精确读回：在写入前，预测当前键在旧状态下的值v̂_t = S_{t-1} · k_t。只写入预测值与真实值v_t之间的误差e_t = β_t (v_t - v̂_t)，其中β_t∈[0,1]是可学习的写入强度。状态更新变为： S_t = S_{t-1} + e_t ⊗ k_t。 此更新确保立即读回该键时，输出为(1-β_t)v̂_t + β_t v_t，当β_t=1时精确等于v_t。修正仅影响当前键方向。

2. 在线学习视角：将当前键值对视为状态矩阵S的一个训练样本，最小化重构损失L_t(S) = ½‖S·k_t - v_t‖²。对其求梯度并执行步长为β_t的梯度下降，得到的更新与上述完全相同。

DeltaNet实现了针对性的记忆替换，但未解决整个状态矩阵中陈旧信息持续影响的问题。

Gated DeltaNet：整体遗忘

为让模型能主动丢弃旧信息，Gated DeltaNet在DeltaNet更新前引入一个标量遗忘门α_t∈[0,1]： S̃_t = α_t · S_{t-1}，然后对S̃_t应用DeltaNet更新。 这提供了全局遗忘机制：所有键通道以相同速率衰减。

Kimi Delta Attention (KDA)：逐通道独立遗忘

KDA将标量门α_t推广为向量α_t∈[0,1]^{d_k}，并置于对角矩阵D_t = Diag(α_t)中。状态更新变为： S̃_t = S_{t-1} · D_t，再执行DeltaNet更新。 这允许模型独立控制每个键值通道的保留程度，灵活性大增。

KDA的完整递归过程如下：

1. 遗忘：S̃_t = S_{t-1} · D_t
2. 预测：v̂_t = S̃_t · k_t
3. 修正：e_t = β_t (v_t - v̂_t)
4. 写入：S_t = S̃_t + e_t ⊗ k_t
5. 读取：o_t = S_t · (d_k^{-1/2} q_t)

其状态转移矩阵A_t = D_t (I - β_t k_t ⊗ k_t)是对角加低秩形式。

KDA的两种高效实现

KDA有两种执行模式，对应同一递归的不同调度：

1. 融合递归核：适用于低延迟解码。每个内核实例处理一个序列、一个值头分片和一个值维度分片（宽度32）。内核是递归方程的字面转录，逐步执行衰减、预测、残差计算、状态更新和输出计算。适合逐步生成场景。

2. 分块KDA：适用于训练和长序列预填充，将工作重组为矩阵乘法以利用张量核心。处理一个包含C个标记的“块”时，核心步骤包括：

   • 计算临时误差ē_i（假设块内无相互作用）。
   • 通过构建并求解严格下三角交互矩阵A_kk来恢复块内的因果依赖，得到最终误差E_c。
   • 通过矩阵乘法快速推进状态：S_{c+1} = S_c · D_{0:C} + E_c · K_c^{end}。
   • 通过矩阵乘法计算块内所有因果输出：O_c = s · S_c · Q_c^{boundary} + E_c · (A_qk)^T。 实现上通过前缀和计算衰减，构建交互矩阵，进行三角求解，并最终融合所有操作。

总结

DeltaNet家族的演进路径清晰地体现了线性注意力在记忆机制上的逐步完善：从基础线性注意力的加法写入干扰问题，到DeltaNet的针对性误差修正，再到Gated DeltaNet的整体遗忘能力，最终发展为KDA的细粒度逐通道记忆控制。其高效实现则通过递归核（利于解码）和分块矩阵计算（利于训练/预填充）两种调度策略达成，本质是同一递归算法在不同计算场景下的优化表达。

Casa Grande residents deserve safety with enforceable limits on Flock cameras. Read the evidence, sign the petition, and ask for warrants, audits, and oversight.

LearnVector：Andrew Ng 创办的一对一AI学习公司

公司概况

• 由人工智能领域先驱Andrew Ng（Coursera与Google Brain联合创始人、DeepLearning.AI创始人）于2026年创立并担任CEO。
• 获得来自Coursera的1亿美元战略投资。
• 公司位于加州Mountain View，采用现场办公模式。
• 核心理念是：AI不应取代人，而应通过创造一对一的个性化学习体验来加速人类发展，让每个人都能参与其中并掌握技能。

所面临的教育挑战

• 优质教学长期稀缺，受限于成本、地理位置和时间。尽管已知一对一辅导效果远优于大班教学，但经济局限性迫使教育仍主要采用一对多模式。
• AI在教育领域尚未真正改变学习方式，学习体验依然多为一对多。
• 缺乏引导的聊天机器人对学习有害：能提供答案，但会导致“认知卸载”，使学习者掌握的技能减少，且信息的准确性与可信度存疑。
• 社会对可信赖学习的需求空前高涨，学习者希望所学内容准确、重要且相关。

解决方案与产品愿景 LearnVector旨在打造一个“可信赖的学习向导”，其产品与现有聊天机器人有本质区别：

• 核心模式转变：从一对多转向一对一的个性化学习体验。
• 体验提升：从被迫劳动变为充满吸引力和乐趣、让人愿意进行的学习。
• 习惯养成：从偶尔学习变为日常习惯，如同本能而非负担。
• 产品功能（计划于2027年初展示）：
  1. 共同规划路径：与学习者一起制定学习计划。
  2. 适应个人学习风格：根据学习者的方式进行自适应调整。
  3. 耐心陪伴直至掌握：持续陪伴直到学习者熟练掌握新技能。

战略意义与未来合作

• Andrew Ng认为，十五年前Coursera通过在线课程扩展了学习的“地点”，但学习的“方式”依然千篇一律。现在AI提供了改变学习方式的机会。
• LearnVector计划与Coursera和Udemy紧密合作，利用Coursera的权威、可信赖的课程材料库，共同将可信赖的一对一学习带给所有人。
• Coursera的CEO Greg Hart表示，此投资有望成为其增长的倍增器，结合Andrew Ng的AI专长与Coursera的平台，能加速业务并扩大全球影响力。

团队与招聘 公司正在组建一支小型、快速的现场团队，招聘职位包括：

• AI工程师：构建理解学习者、规划路径并引导学习的智能体系统。
• 学习工程师：应用教学专业知识，构建能有效提升技能的产品。
• 学习科学家：发明利用智能体AI的新教学方法，并严格测量学习效果。
• 全栈软件工程师：端到端构建软件产品，实现大规模个性化AI学习体验。
• 运营专员：负责办公室运营与管理，支持团队高效工作。

总结 LearnVector致力于通过人工智能技术，彻底变革学习方式，将稀缺的一对一辅导体验规模化、个性化，最终实现“加速人类发展”的使命。它并非简单提供答案的聊天机器人，而是一个能够规划、适应并耐心陪伴的可信赖学习伙伴，其产品正在积极研发中。

GrapheneOS 是一个依赖个人、企业和其他组织捐赠维持运营的开源项目。捐赠资金由非营利组织 GrapheneOS Foundation 管理，主要用于支付开发者薪酬、购买测试硬件与工作站、维护基础设施（如域名和服务器）以及支付法律费用等项目必要开支。

该项目提供了涵盖传统支付、银行转账和加密货币的全面捐赠渠道：

1. 信用卡

通过 GitHub Sponsors 支持信用卡一次性或定期捐赠，提供 5 至 5000 美元的标准层级及自定义金额选项。

2. 加密货币

支持多种加密货币捐赠，且明确声明仅接收主币，不接受任何代币：

• Bitcoin (BTC)：支持 Bech32 (Segwit)、Bech32m (Taproot，首选) 及 BIP47/PayNym 隐私地址。
• 其他币种：支持 Monero (XMR)、Zcash (ZEC，透明地址)、Ethereum (ETH)、Cardano (ADA，支持 $grapheneos 句柄) 和 Litecoin (LTC，Segwit 地址)。

3. 银行转账与第三方支付

• Wise：提供 Wise Quick Pay 快捷支付链接，建议非支持货币用户选择 CAD 或 USD 以避免额外转换费。
• 本地银行转账：通过 Wise 账户支持 8 个国家/地区的本地转账，包括欧盟/SEPA (EUR)、英国 (GBP)、美国 (USD)、澳大利亚 (AUD)、新西兰 (NZD)、加拿大 (CAD)、匈牙利 (HUF) 和土耳其 (TRY)，并详细列出了各地区的账户名、账号/IBAN、路由号及银行地址等完整信息。
• PayPal：支持一次性、月度或年度捐赠，提供 CAD、USD、EUR 和 GBP 专属链接，也可通过 PayPal.Me 或官方邮箱转账。文中详细说明了 PayPal 在加拿大境内及跨境交易时的基础手续费、附加费及货币转换费。
• Interac e-Transfer：专为加拿大银行账户设计，支持向官方邮箱发送加元 (CAD) 捐款，已启用 Autodeposit 自动存款功能，无需设置安全问题。

总体而言，GrapheneOS 建立了多样化的全球捐赠体系，以保障项目能够获得稳定、透明的资金支持。

Steel Bank Common Lisp 版本 2.6.7

该文档是 Steel Bank Common Lisp (SBCL) 的发行说明，按版本倒序详细列出了从最新的 2.6.7 版本（发布于 2026-07-28）一直追溯到早期版本（如 0.9.0、1.0 等）的所有新特性、不兼容变更、平台支持、缺陷修复、性能优化及文档改进。

核心内容结构：

• 版本列表：首先列出所有历史版本号（从 2.6.7 到 0.7.0 等），每个版本作为一个可展开/查看的章节。
• 版本详情：每个版本下详细描述其更新，通常包括：
  • 新特性：如新增功能、模块或接口。
  • 不兼容变更：可能破坏现有代码的改动。
  • 平台支持：针对不同操作系统（如 Windows、Linux、macOS、FreeBSD 等）和 CPU 架构（如 x86、x86-64、ARM64、PowerPC、RISC-V、SPARC、MIPS 等）的新增支持或修复。
  • 缺陷修复：解决各类错误和问题。
  • 性能优化：提升编译速度、运行效率或内存使用。
  • 文档改进：手册和文档的更新。
• 重点版本：文档开头着重介绍了最新版本 2.6.7 的更新内容。

版本 2.6.7 主要更新：

• 新贡献模块：引入 SB-MANUAL 模块，将 SBCL 手册的文档字符串整合到 Lisp 定义中，便于通过交互式开发环境（如 Slime）探索，并支持通过 MGL-PAX 库浏览。此外，外部网站也提供了多种格式的手册渲染。
• 新特性：DOCUMENTATION 函数支持 DOC-TYPE DECLARATION。
• 平台支持增强：
  • SB-SIMD 贡献模块现支持 ARM64。
  • X86-64 平台新增 AVX512 指令集支持。
  • ARM64 和 X86-64 平台增加了对更多 SIMD 指令的支持。
  • 修复了 ARM64 平台上 SAP-REF-N 的编译错误。
  • 在 MIPS 和 LoongArch 架构上，为 INTEGER-LENGTH 在原始类型上实现了无循环实现。
• 缺陷修复：
  • 修复了在 *READ-SUPPRESS* 为 T 时使用 READ 可能发出无关警告的问题。
  • 修复了编译对 CONCATENATE 函数调用时可能出现的类型错误。
  • 修复了类型系统未将 (EQL <complex>) 视为数值类型的问题。
  • 改进了 LOG 函数处理静默（非信号）NaN 输入的方式。
  • 修复了 MULTIPLE-VALUE-CALL 的编译错误。
• 性能优化：
  • 向局部函数传递常量复数时不再进行分配。
  • 在可用情况下，为 UTF-8 转换使用增强的 SIMD 例程。
  • COUNT 函数的编译转换现在适用于更广泛的关键字参数组合。
  • 从 SB-ALIEN:DEREF 中移除了至少一条冗余指令。
  • 调整了编译器中的稀疏集实现，以提高在真实工作负载下的性能。
• 文档改进：
  • 修正了多处排版问题和拼写错误。
  • 更正了 SB-MANUAL:@FOREIGN-FUNCTION-INTERFACE 中关于数组是行主序（而非列主序）的描述。
  • 内部文档字符串现在符合 Markdown 子集规范，但 DOCUMENTATION 函数会剥离部分标记。官方手册仍从 Texinfo 生成，而 Texinfo 源文件已由 SB-MANUAL 生成。
  • 手册现在为声明提供了单独的索引。

其他版本概览： 文档后续部分以类似格式详细列出了从 2.6.6 一直回溯到 0.7.0 及更早版本的所有更新。这些更新共同构成了 SBCL 长期的开发历程，涵盖了从核心语言实现、编译器优化、垃圾回收器改进、多线程支持、Unicode 处理、外部函数接口（FFI）、平台移植到众多第三方贡献模块（如 sb-simd, sb-concurrency, sb-prof, sb-cover, sb-introspect 等）的广泛领域。

使用Claude发现密码学弱点

Anthropic的研究人员利用Claude Mythos Preview模型，在密码学研究领域取得了突破性进展，发现了攻击加密算法的新方法。这两项主要发现分别针对后量子数字签名方案HAWK和广泛使用的对称加密标准AES的简化版本。这些是重大的研究进展，但目前并未影响任何实际运行的系统。

主要发现

1. 对HAWK数字签名方案的改进攻击

• 背景：HAWK是美国国家标准与技术研究院（NIST）为应对量子计算机威胁而征集的“后量子密码学”数字签名方案候选之一，已经历了两年两轮的人类专家评审。
• 攻击效果：Claude在约60小时的工作中，找到了一种改进的攻击方法。该方法显著提升了攻击速度，相当于将其有效密钥强度削弱了一半。
• 技术原理：攻击利用了HAWK所使用的格中一个此前未被发现的对称性，即“非平凡自同构”。这一发现允许进行更快的枚举攻击，使得要达到原有安全级别，必须将HAWK的密钥大小加倍，而这会破坏该方案的吸引力。
• 发现过程：研究人员与Claude以半自主的多智能体协作模式进行。关键的攻击思路是由两个智能体协作讨论后共同发现的。整个发现、开发和验证过程耗时约60小时，API成本约为10万美元。

2. 对简化版AES的改进攻击

• 背景：AES是使用最广泛的对称加密标准。研究人员通常通过攻击轮次减少的简化版本来理解全算法的安全性。
• 攻击效果：Claude找到了攻击7轮AES（完整版为10轮）的新方法，改进了此前最佳的“中间相遇”攻击。它提出了一种称为莫比乌斯桥的新型指纹算法，将攻击速度提升了200至800倍。
• 技术原理：新算法通过一种更复杂的变换，大幅减少了需要查询预计算表的工作量，尽管计算该变换本身的成本更高，但通过其他优化技术实现了整体加速。
• 发现过程：此发现几乎完全由Claude自主完成。研究人员构建了一个脚手架，使Claude能够提出假设、运行实验并设计攻击。在最初因认为问题不可能解决而受阻后，经过少量提示，Claude重新定义了探索方向，最终在三天内（输出约十亿token）自主发现了核心算法。后续人类研究人员花费了数百小时来验证其正确性。

其他相关进展

除了上述两项主要成果，Claude还展示了在其他密码算法上的分析能力，进一步证实了其潜力：

• 对LEA轻量级加密算法：针对其13轮版本（完整版为24轮），开发了一个可在一小时内恢复密钥的实用攻击。
• 对Serpent-128密码：针对其6轮版本（完整版为32轮），提出了一个完整的密钥恢复攻击。
• 基准测试：为便于评估大语言模型（LLM）的密码分析能力，研究团队与学术机构合作构建了CryptanalysisBench基准。

意义与讨论

1. 对密码学研究的意义：这些发现展示了前沿AI模型在发现重要密码算法缺陷方面的巨大潜力，能够辅助甚至加速密码系统的压力测试，有助于在部署前发现漏洞，从而最终构建更安全的系统。
2. 当前影响：两项主要攻击均无即时实际影响。HAWK仅为候选方案尚未部署；对AES的攻击仅针对简化版本，未破解完整密码。
3. 未来展望：AI模型的密码分析能力正在快速提升。许多在用的加密算法可能尚未得到足够审查，可能存在潜在弱点。未来，AI有望在审查现有系统和设计下一代更强韧的密码方案中发挥关键作用。
4. 挑战与共识：随着AI自主产出新颖研究成果，人类研究者可能面临验证这些成果有效性、新颖性和实用性的瓶颈。业界需就如何应对AI在具有即时现实影响的密码系统中发现漏洞这一问题展开讨论。

ReFrame 电子纸相机简介

ReFrame 是一款实验性相机，采用彩色电子纸显示屏。其设计理念是每次仅拍摄并显示一张照片，旨在让每一帧都经过深思熟虑且值得铭记。

核心技术与显示效果

• 该相机使用六色电子纸显示屏，照片在显示前会进行抖动处理。
• 抖动后的图像效果介于报纸网点图和复古电子游戏画面之间。
• 照片显像过程本身是体验的一部分：用户能像观看数码拍立得一样，看着色彩逐一浮现。
• 按下快门后，照片需要约15秒才能完全显示。这是因为显示屏通过电荷物理移动墨水粒子来成像。

功能与使用体验

• 持久显示：利用电子纸技术，照片在关机后仍能保留在屏幕上。
• 唯一刷新方式：清除屏幕的唯一方法是拍摄一张新照片。
• 相框模式：闲置时，相机可作为桌面相框，最后一张照片会持续显示，其处理后的质感具有独特的印刷品风格。
• 数字保存：拍摄的照片会被数字保存。用户可通过网络仪表板下载每张照片的原始版本和抖动处理版本。

项目信息与开源性质

• 开源：ReFrame 的硬件和软件均为开源项目。
• 可自建：相机仅使用现成组件，用户可以根据 GitHub 上的指南自行组装。
• 核心硬件：包括 Raspberry Pi Zero、Pi Camera 3、4 英寸电子纸光谱六色显示屏和电池。
• 项目状态：目前是 Kaloyan Kolev 及朋友们的一个热情项目，暂不对外销售，但未来可能接受个人订单。

《半条命》移植至Mac OS 9

游戏背景

《半条命》是一款剧情驱动的第一人称射击游戏，讲述理论物理学家戈登·弗里曼在黑山研究设施经历失败实验后，试图逃离外星维度入侵的故事。该游戏最初由Valve开发，于1995年发布。

移植历史

• 原计划1999年由Valve移植至Mac OS 9，但在发布前被取消。
• 直到2013年（Intel CPU时代），游戏才正式登陆Mac OS X平台。
• 最新进展：28年后，GitHub用户doctashay通过Xash3D FWGS引擎分支实现了对PowerPC架构Mac OS 9系统的完整移植。

技术细节

• 支持硬件：基于PowerPC G3和G4处理器的Mac设备，需运行Mac OS 9.0或更高版本。
• 性能要求：GPU性能直接影响运行效果，低于8MB显存的设备（如iMac、iBook）可能出现性能不足。
• 功能完整性：移植版可完整通关，支持多人游戏模式。

包含内容

• 《半条命》主游戏
• 《半条命：蓝色行动》资料片
• 《半条命：针锋相对》资料片
• 附带《Uplink》试玩版

社区意义

此次移植被视为Macintosh游戏社区的重大成就，doctashay的技术工作为在老旧PowerPC平台上运行经典游戏提供了新可能。

Backchannel（前身为 HNewhere）是一款浏览器用户脚本，旨在解决在 Hacker News（HN）等网站上阅读链接时需要同时打开原始页面和评论页的不便。它通过将社区讨论以侧边栏形式直接嵌入当前浏览的页面，实现了一站式阅读体验。

核心功能：

• 跨平台评论聚合：可将来自 Hacker News、Bluesky、Reddit 等多个来源的讨论合并为一个对话流，每条评论会标注其来源。用户可通过勾选框选择启用的来源（Reddit 默认关闭）。
• 自动发现讨论：脚本会在用户访问的每个页面自动检查是否有关联的讨论帖，无需手动搜索。
• 上下文高亮：评论中引用的文章内容会被高亮匹配，点击高亮处可筛选只显示讨论该段落的评论。
• 直接参与互动：支持在侧边栏内对 Hacker News 帖子进行投票、回复甚至提交新帖，使用浏览器已有的登录会话，脚本不接触用户密码。
• 使用体验优化：提供缩进引导、标记原始帖子作者、高亮新评论等功能。
• 高度可自定义：可调整按钮样式、侧边栏宽度、主题、显示的注释层等，并可为特定网站禁用脚本。

隐私与安全： 该脚本为本地用户脚本，无后端服务器、无分析或遥测。根据用户启用的来源，它会与相应的平台服务器进行通信以获取数据。通信细节因来源而异：

• Hacker News：与 HN API 等通信，不携带持久性标识符。
• Reddit：将访问的页面URL发送至 reddit.com，登录用户以账户身份访问，未登录则使用设备标识符。
• Bluesky：与第三方索引 Constellation 通信，再查询 Bluesky，无需账户。
• Lobsters、Wikipedia、Lemmy：均仅发送域名或URL至对应平台的API，无需账户。 脚本会主动排除网银、邮箱、认证页面等敏感网站。详细信息可在 SECURITY.md 中查阅。

安装与使用：

1. 安装兼容的浏览器脚本管理器（如 Tampermonkey、Violentmonkey 或 Safari 的 Userscripts）。
2. 通过提供的链接安装 Backchannel 脚本。
3. 正常浏览网页，当页面存在关联讨论时，浏览器工具栏的 (BC) 按钮会亮起，点击即可打开侧边栏查看讨论。

项目背景： 该项目最初名为 HNewhere，专注于 Hacker News。在 v1.6.0 版本扩展支持多来源后更名为 Backchannel。从 HNewhere 升级无需额外操作，脚本会自动更新并重命名，所有设置和阅读数据将保持不变。

该项目是开源的，欢迎提交 Bug 报告和拉取请求。代码为单一文件，无构建步骤或依赖项，采用 MIT 许可证。

法国音乐人Kavinsky去世

2026年7月29日，法国DJ Kavinsky在巴黎家中被发现死亡，终年50岁。其真名为文森特·贝洛尔热。巴黎检察院已就死亡原因展开调查，现场未发现嫌疑人。

Kavinsky是“法式触感”电子音乐运动的重要人物，与Daft Punk、Justice等齐名。法国文化部长卡特琳·佩加尔在社交平台上表示：“法国失去了最具辨识度的声音之一”，其音乐“既适合舞蹈又充满怀旧感，将继续跨越世代与国界”。

他最著名的曲目是《Nightcall》，该曲收录于2011年电影《亡命驾驶》原声带，并在2024年巴黎奥运会期间重新焕发活力。在奥运会闭幕式上，他与比利时歌手Angèle及乐队Phoenix合作，于法兰西体育场表演了改编版本。

Kavinsky自学钢琴，出生于塞纳-圣但尼省，职业生涯始于2000年代初，曾为Daft Punk开场，并与电子乐坛新兴艺人同台。他原定于7月31日迎来51岁生日。

这篇文章探讨了在Linux的Wayland环境下实现多个鼠标光标（即多座位）的现状、挑战与可能性。

核心发现

作者调研后发现，Wayland核心协议本身对多座位有深度集成，每个输入事件都与特定的座位（wl_seat）关联。然而，这种支持在软件栈的各个层面（合成器、图形库、应用程序）表现不一。

各层面支持现状

1. Wayland合成器：

   • sway：支持较好，可为每个座位设置独立窗口焦点，但存在设备分配问题（如将设备从一个座位移到另一个时，可能会增加而非替换）。
   • Weston：是早期实现多座位的参考合成器，支持多光标和窗口焦点，但配置复杂，需手动设置udev规则。
   • River：内置支持良好，有其自己的输入管理协议，作者为其编写了配置工具。
   • niri：目前尚无官方支持，作者进行了实验性移植。

2. 图形库：

   • GTK：在概念上支持（事件携带座位信息），但大多数控件未正确处理多座位输入。作者编写了实验性的多座位文本控件原型。
   • SDL：在较新版本中支持通过设备ID区分不同座位的输入，但鼠标在绝对模式下该功能失效，需打补丁。
   • LÖVE：基于SDL，作者通过修改SDL和LÖVE使其支持多座位，并创建了多人物理沙盒游戏示例。

3. 应用程序：

   • 目前几乎没有现成的应用程序利用此功能。
   • 终端模拟器中，Alacritty接受所有座位的输入，而Kitty仅响应第一个座位。
   • 浏览器中，Firefox在启动后能响应已存在的座位输入，Chromium则完全不响应额外座位。

远程协作与设置

作者探索了通过VNC实现远程多座位协作：

• wayvnc（VNC服务器）支持为每个连接创建临时座位（--transient-seat），需使用ext-transient-seat-v1协议（sway支持，River尚未支持）。
• 配合noVNC（Web客户端），可以实现通过浏览器远程加入，并获得独立的虚拟鼠标和键盘。
• 作者提供了从配置wayvnc、生成证书到使用noVNC的完整设置流程。

结论与展望

• 现状：sway + wayvnc提供了可行的多座位本地和远程协作基础，但应用程序支持是最大瓶颈。
• 主要挑战：需要在应用层、图形库层（如修复SDL的绝对模式问题、GTK的座位发现）和合成器层（如为niri添加支持、解决sway的设备分配问题）持续改进。
• 开放项目：文章中标记了多个待解决的问题，例如为River添加transient-seat支持、编写真正支持多座位的窗口管理器或浏览器、改进GTK的座位通知机制等。
• 意义：这种多玩家计算模式能非常自然地促进应用内协作，适用于结对编程、多人游戏等场景。作者呼吁对此领域感兴趣的人共同探索。

文档型AI蠕虫可通过Word中的Copilot自我传播

核心发现

研究人员与微软安全响应中心合作披露了一项安全漏洞。该漏洞表明，攻击者可利用微软Word中的Copilot功能，通过在文档中嵌入隐藏的恶意指令，创建能够自我传播的文档型AI蠕虫。这是首次在主流商业生产力套件中公开展示此类攻击的自传播能力。

攻击机制

1. 初始感染：攻击者在文档中嵌入经过格式处理（如白色文字、极小字体）的恶意提示（prompt）。这些文字对用户不可见，但能被Copilot读取。
2. 指令执行：当用户使用Copilot处理该文档（如将其作为附件起草新文档）时，Copilot会将隐藏的指令误认为用户的请求，从而执行恶意操作（例如，篡改文档中的财务数据）。
3. 蠕虫传播：更关键的是，Copilot会将原始的恶意指令复制到它新生成或编辑的文档中。这使得新文档本身也成为一个携带恶意指令的载体。
4. 持续传播：如果后续有用户使用这个被感染的“下游”文档作为来源材料再次通过Copilot进行创作，恶意指令会再次触发并继续复制，从而实现无需原始攻击文件即可在组织内部文档工作流中持续传播。

攻击影响与特点

• 隐蔽性高：篡改行为和指令复制可能不会主动告知用户，攻击难以察觉。
• 扩散性强：攻击一旦进入内部工作流，可通过正常的文档共享和协作（如通过SharePoint、Teams）在组织内部乃至合作伙伴之间传播。
• 溯源困难：受影响的文档由合法用户通过正常流程创建，难以追溯攻击源头。
• 无需特殊权限：攻击者只需能让受害者获取其恶意文档即可，无需访问受害者的Microsoft 365租户。

漏洞状态与协调披露

• 研究人员于2026年3月向微软报告，双方进行了长达144天的协调披露期。
• 微软部署了多次缓解措施（包括模型升级至GPT-5.5），成功阻断了特定的攻击载荷。
• 然而，截至2026年7月公开披露时，研究人员使用修改后的攻击载荷在最新模型上仍能复现完整的自传播攻击链，表明该漏洞的根本类别（即：文档中的指令可影响Copilot行为并自我复制）尚未被彻底修复。
• 因此，用户在使用Copilot for Word时，应将外部来源文档视为不可信，并在使用Copilot生成或编辑内容后仔细审查。

技术根源与更广泛的启示

作者指出，此漏洞反映了当前基于大语言模型系统的架构性弱点：

1. 安全边界模糊：LLM必须处理外部内容（如附件文档）才能理解其含义，但攻击者控制的内容在被“检查”的同时，已经参与并影响了模型的计算过程。
2. 检测困难：依赖模型自身来检测提示注入攻击存在根本矛盾。外部检测器若能力弱于目标模型，则可能无法识别攻击；若使用另一个LLM作为检测器，则会引发“LLM层层嵌套”的新问题。
3. 设计挑战：当前LLM架构无法可靠地区分“意图”和“解释”，使得攻击性信息既能影响模型的输出，也能影响模型对任务的理解。 因此，任何将LLM集成到可信工作流中的系统，都必须假设进入模型上下文的攻击者控制内容可能导致一定程度的安全漏洞。该研究强调，在AI助手广泛集成的现代工作环境中，信息的完整性已成为一个核心安全关切。

SQLite 生产环境优化：WAL模式、并发与VFS层

打破SQLite“仅限本地”的迷思

SQLite长期被视为嵌入式数据库，用于移动端、IoT和本地开发，生产环境则依赖客户端/服务器数据库（如PostgreSQL/MySQL）。然而，现代硬件发展（高速NVMe SSD、本地存储）使网络延迟成为主要瓶颈。将SQLite直接运行在应用服务器同一进程中，可消除网络开销，将读取操作变为亚毫秒级的内存映射文件操作。但生产环境需重新配置SQLite以实现高吞吐，关键在于优化其内部机制：WAL、锁定、缓存和自定义VFS层。

深入Write-Ahead Logging（WAL）模式

SQLite默认使用回滚日志机制，写操作前复制数据页到日志文件，此机制导致读写相互阻塞，限制并发。启用WAL模式可彻底改变并发模型：

PRAGMA journal_mode = WAL;

• 并发读写：读者读取主数据库文件，写者追加新事务到.wal文件，两者互不阻塞。
• 检查点机制：WAL文件会增长，需定期将其页面合并回主数据库文件。默认自动检查点可能引发延迟尖峰，有四种模式（PASSIVE、FULL、RESTART、TRUNCATE）。生产环境建议在后台线程显式执行PASSIVE或RESTART检查点。
• 同步优化：配合 PRAGMA synchronous = NORMAL 可减少磁盘同步开销，仅在关键点（如检查点）同步，WAL模式下保证数据完整性。

并发架构：处理SQLITE_BUSY

WAL模式仍为单写者模型。当并发写尝试发生时返回SQLITE_BUSY错误，需应用层处理：

1. 设置忙超时：PRAGMA busy_timeout = 5000; 让SQLite内部重试，避免应用级错误。
2. 使用IMMEDIATE事务：默认DEFERRED事务易导致死锁。若事务含写操作，应始终使用 BEGIN IMMEDIATE TRANSACTION; 立即获取保留锁，避免死锁。

内存与缓存优化

• 缓存大小调整：默认缓存过小（约2MB），生产环境应扩大以减少磁盘I/O。PRAGMA cache_size = -64000; 设置约64MB缓存。
• 内存映射I/O：使用 PRAGMA mmap_size = 2147483648; 将数据库文件映射到虚拟地址空间，利用内核管理页缓存，加速读取。

云时代定制VFS层

SQLite通过VFS抽象层委托文件操作，允许自定义存储方式，催生现代复制引擎：

• Litestream：流式复制工具，拦截WAL帧增量发送至对象存储（如S3），实现时间点恢复。
• LiteFS：基于FUSE的VFS，集群内实时复制事务，支持全球分布式SQLite部署。 在云环境（如AWS ECS、Kubernetes）中，本地磁盘可能不持久，必须使用基于VFS的复制工具确保数据持久性和高可用。

生产就绪SQLite配置蓝图

应用初始化连接时立即执行以下PRAGMA序列：

PRAGMA journal_mode = WAL;          -- 启用WAL模式
PRAGMA synchronous = NORMAL;        -- 平衡性能与安全
PRAGMA busy_timeout = 5000;         -- 避免写冲突
PRAGMA cache_size = -64000;         -- 64MB缓存
PRAGMA mmap_size = 1073741824;      -- 1GB内存映射
PRAGMA foreign_keys = ON;           -- 启用外键约束
PRAGMA journal_size_limit = 67108864; -- 限制WAL文件大小（64MB）
PRAGMA auto_vacuum = INCREMENTAL;   -- 优化索引与查询

结论：何时在生产环境使用SQLite

经过适当配置（WAL模式、内存映射、合理事务边界），SQLite能处理高并发请求，适用于读密集型、数据量适中、需超低延迟的场景。若需跨地域分布式写入或处理PB级数据，传统数据库仍是更好选择。SQLite已从嵌入式玩具转变为高性能、低成本、运维简单的生产级方案。

Apple Upgrade 计划正在取代 iPhone Upgrade Program。

Apple Upgrade 计划概述：

• 性质：设备租赁计划，仅适用于美国（不包括美国领土）。

• 提供方：贷款由 Klarna 提供，需满足资格和信用批准（包括结账时的最终批准）。

• 资格要求：

  • 美国居民，年满18岁（或所在州法定年龄）。

  • 持有有效的信用卡或借记卡。

  • 拥有 Apple ID。

  • 设备必须完好归还，损坏可能产生费用。

• 适用设备：仅适用于 iPhone，必须选择符合条件的运营商（不能使用预付费运营商计划）。

• 升级条件：升级需签订新租赁协议，并满足资格和信用批准。

• 限制与例外：

  • 不适用于翻新设备。

  • 不适用于以下特殊商店：Apple Employee Purchase Plan、参与的企业员工购买计划、Apple at Work（针对小型企业或企业）、政府、教育、退伍军人及军人购买计划。

Hubble：开源笔记应用程序

Hubble 是一个免费、开源的笔记应用程序，专为用户和他们的代理人（如 AI 代理或其他用户）设计。它基于 Markdown 和 HTML 支持，旨在提供灵活的笔记管理体验。

主要特点

• 开源与免费：应用程序完全免费，并公开源代码，鼓励社区协作和自定义。
• Markdown 和 HTML 支持：用户可以使用 Markdown 语法或 HTML 格式来创建和编辑笔记，适用于技术文档、富文本或代码风格的笔记。
• 基于标签的组织系统：笔记通过标签进行分类和检索，示例标签包括：
  • 旅行相关：如 "Travel", "Kyoto", "Tokyo", "Lisbon", "Big Sur"
  • 户外活动：如 "Outdoors", "Desert stars", "Tide pools", "Trail notes"
  • 生活类别：如 "Cooking", "Books", "Home", "Garden log"
  • 其他：如 "Sourdough", "Star maps", "Field guide"
• 多样化的笔记示例：应用内置或支持多种笔记类型，例如：
  • 旅行笔记：记录地点和体验，如 "Kyoto garden", "Joshua Tree", "Big Sur"
  • 生活日志：如烹饪食谱 "Sourdough", 花园记录 "Garden log"
  • 户外指南：如 "Tide charts", "Night sky", "Sea glass"
  • 创意想法：如 "Added 3 ideas for next time."，表明应用可能具有任务或想法添加功能。
• 用户友好界面：通过标签云或列表展示笔记，便于快速访问和管理。

总结

Hubble 作为一个开源笔记工具，结合了简洁的设计和强大的标签组织功能，适合个人或团队使用，尤其适用于需要处理多种主题和格式笔记的用户。其支持 Markdown 和 HTML 的特性使其在技术文档和创意笔记方面表现出色。

水生系统缺氧对地球稳定性的威胁

研究概述

由加州大学圣地亚哥分校斯克里普斯海洋研究所科学家领导的新综述论文警告，海洋及其他水生生态系统中氧气的快速流失正将地球推向一个“不安全空间”，其影响在人类时间尺度上可能是不可逆的。

核心观点

• 水生缺氧现状：溶解氧在海洋、沿海水域、河流、湖泊和溪流中的普遍下降。
• 与行星边界框架的关联：研究审查了水体缺氧与“行星边界”框架中九个过程之间的广泛相互作用。该框架于2009年首次提出，识别了关键地球系统过程以及人类活动如何推动其超出维持地球稳定和弹性所需的条件。
• 建议扩展框架：作者建议将溶解氧状况纳入行星边界框架，以提升水体缺氧作为全球威胁的可见度。

行星边界框架的九个过程

1. 气候变化
2. 海洋酸化
3. 生物多样性丧失
4. 大气气溶胶加载
5. 平流层臭氧消耗
6. 淡水变化
7. 土地利用变化
8. 化学污染
9. 生物地球化学流（包括氮循环）

缺氧的主要驱动因素

• 人为因素：
  • 人类活动导致的全球变暖
  • 过量营养物污染
  • 水体内部通风的变化

缺氧的影响

• 生态系统功能：扰乱调节地球气候的生物和化学过程。
• 生物多样性威胁：影响范围从微生物到鱼类、鲨鱼等海洋生物。
• 间接影响：即使呼吸空气的海洋哺乳动物，也会因猎物、栖息地和食物网的改变而受影响。

研究意义与目标

• 综合视角：研究源于作者参加2019年联合国气候变化大会（COP25）后的思考，旨在鼓励科学家和政策制定者综合考虑水体缺氧与其他行星压力因素。
• 政策启示：将水体缺氧纳入行星边界框架有助于理解其对地球系统稳定性的影响，减轻其影响是维持生物多样性和气候的关键组成部分。

研究背景与发表信息

• 研究团队：由斯克里普斯海洋研究所校友、加州大学圣巴巴拉分校博士后学者Erica Ferrer领导，高级作者为斯克里普斯生物海洋学家Lisa Levin。
• 发表信息：2026年6月30日发表于《湖沼学与海洋学》期刊，有多位合著者参与。
• 资助来源：国家科学基金会研究生研究奖学金计划、斯克里普斯和加州大学圣地亚哥分校研究生基金等。

Uv 0.12.0 版本摘要

Uv 0.12.0 是一个包含多项破坏性变更的版本，旨在提高正确性、安全性和规范兼容性。预计大多数用户可直接升级。

主要行为变更

项目创建 (uv init)

• 默认生成带构建系统的项目：uv init example 现在会创建一个使用 uv_build 构建系统的可安装包项目，源码位于 src/example，并包含一个命令入口点。
• 旧的无构建系统布局仍可通过 uv init --no-package example 创建。
• 此变更稳定了 packaged-init 预览功能。

安全与合规性

• 拒绝不支持的发行版格式：严格遵循 PEP 625，拒绝 .tar.bz2 和 .tar.xz 等旧格式的源码分发包。轮子文件中的条目不能再使用 bzip2、LZMA 或 XZ 压缩，仅支持 stored、DEFLATE 或 zstd。
• 阻止覆盖 Python 解释器：拒绝可能替换解释器的轮子文件，包括大小写变体（如 Python）以及将解释器文件放置在特殊目录中的轮子。
• 哈希验证增强：
  • uv pip install 和 uv pip sync 现在会遵守 requirements.txt 文件中的 --require-hashes 指令并强制执行哈希检查。
  • 在哈希检查模式下，拒绝仅提供 MD5 哈希的要求，必须至少提供一个安全哈希（如 SHA-256）。
• 验证 pylock.toml：
  • packages 数组必须存在。
  • 锁文件名必须为 pylock.toml 或 pylock.dev.toml 等单名称变体。
  • 如果工件声明了大小，下载或缓存的大小必须匹配。

证书处理

• 尊重显式证书覆盖：当 SSL_CERT_FILE 或 SSL_CERT_DIR 指向无效或空的文件/目录时，不再回退到默认信任根，而是导致 HTTPS 请求失败（因为没有任何受信任的证书）。
• 为 uv pip 新增 --cert 参数：该参数接受一个 PEM 捆绑包路径，用以替代所有其他证书来源。

项目发现与运行

• 从脚本目录发现项目：uv run project/script.py 现在会从脚本所在目录开始进行项目和工作区发现，而非当前目录。稳定了 target-workspace-discovery 预览功能。
• 安全清除目录：uv venv --clear 现在会拒绝清除不是虚拟环境的目录，除非显式使用 --force。稳定了 venv-safe-clear 预览功能。
• 拒绝初始化时的 --project：在 uv init 时使用 --project 参数现在会报错，应直接指定路径或使用 --directory。
• 拒绝无效的 --project 路径：当 --project 指向不存在的目录或非 pyproject.toml 文件时会立即报错。

其他重要变更

• 预发布版本解析：默认行为变为 if-necessary。优先尝试稳定版本，在无稳定版本满足约束时再回退到预发布版本，支持传递性预发布要求。旧模式 if-necessary-or-explicit 已弃用。
• 跳过非规范化文件名的分发包：发布时跳过文件名未规范化的轮子或源码包。
• 识别名为 base 和 root 的 Conda 环境：根据路径识别，而不再默认视其为 Conda 基础环境。
• 遇到损坏的 .venv 符号链接时停止：在环境发现过程中遇到损坏的 .venv 符号链接时会停止并报告路径。
• 重装匹配已安装的 Python 补丁版本：uv python install 3.12 --reinstall 现在会重装已存在的特定补丁版本，而不是隐式升级到最新版。
• --upgrade-group 需指定存在的组：uv lock --upgrade-group 现在会验证指定的依赖组是否存在。
• 相对索引路径相对于 --directory 解析：--index、--find-links 等路径现在相对于 --directory 选项指定的目录解析。
• 保留 uv add 的绝对路径：添加本地依赖时，如果原始请求使用绝对路径，则在 pyproject.toml 中保留该形式。
• 移除旧的仅 bzip2 存档的 PyPy 分发：不再支持仅通过 .tar.bz2 归档提供的旧版 PyPy 补丁发行版。

升级建议

• 如果项目使用了 uv 构建后端（uv_build），请更新 pyproject.toml 中的上限，允许 uv_build 0.12，例如：uv_build>=0.11.32,<0.13。
• 本版本发布工件附带使用 GitHub Artifact Attestations 生成的证明。

MCP 2026-07-28 规范：转向无状态传输

MCP 协议自发布以来增长迅速，其 TypeScript 和 Python SDK 的总下载量均已突破 10 亿次。新版本 2026-07-28 是协议的一次重大更新，核心变化是将 MCP 从双向有状态协议转变为请求/响应式的无状态协议，旨在提高服务器的可靠性和可扩展性。

核心变更：无状态协议

新规范移除了传统的会话握手和状态维持机制：

• 废弃会话：不再需要 initialize/initialized 握手交换和 Mcp-Session-Id 请求头。每个请求独立携带协议版本、客户端信息及能力。
• 可选的发现机制：客户端可通过新的 server/discover RPC 调用提前获取服务器能力，但非必须。
• 请求自描述：任何请求都可以直接发送至负载均衡器后端的任意服务器实例，无需共享存储。
• 显式状态管理：若应用需要跨调用维持状态，需由工具生成明确句柄并作为参数传递，使状态对模型可见。

其他重要更新

1. 多轮请求：引入 MRTR 机制，替代了此前需要保持长连接的服务端请求（如 sampling/createMessage）。当工具在调用过程中需要用户输入（如确认信息）时，服务器返回 input_required 类型结果及待完成的请求，客户端随后重试原调用并附上响应。
2. 可路由与可缓存：
   • 请求头中新增 Mcp-Method 和 Mcp-Name，便于网关、限流器等基于头部进行路由和鉴权。
   • 列表类响应（如 tools/list）现携带 ttlMs 和 cacheScope 缓存提示，支持客户端缓存，减少重复请求。
3. 授权增强：
   • 要求授权服务器返回 iss 参数（遵循 RFC 9207），客户端必须验证，防止授权服务器混淆攻击。
   • 正式废弃动态客户端注册，转向客户端标识元数据文档。
   • 客户端凭证与颁发者绑定，禁止跨授权服务器重用。
4. 扩展框架与任务：正式引入扩展框架，任务作为 io.modelcontextprotocol/tasks 扩展的一部分，包含基于轮询的 tasks/get 和新的 tasks/update，订阅通知迁移至 subscriptions/listen 流。
5. 废弃项：Roots、Sampling、Logging 及旧版 HTTP+SSE 传输协议被正式废弃，但至少会继续支持12个月。

SDK 与生态支持

• SDK 更新：TypeScript、Python、Go、C# 四大 Tier 1 SDK 已更新支持新规范，Rust SDK 提供测试版支持。SDK 更新涉及一些破坏性更改，需参考迁移指南。
• 广泛行业支持：AWS、Anthropic、Cloudflare、Google Cloud、Microsoft、Netlify、Figma、Honeycomb 等众多合作伙伴已表示支持，并已在各自平台集成新规范，强调其为企业级可扩展性、安全性及现代代理基础设施带来的提升。

总结

MCP 2026-07-28 规范通过转向无状态核心，显著提升了协议的扩展性、可靠性和与现代 Web 架构的兼容性。结合多轮请求、缓存优化、授权强化等改进，为构建大规模、生产级的代理系统奠定了更坚实的基础。开发者可通过更新的 SDK 和相关文档立即开始采用新规范。

在M1 Max上运行Kimi K3

项目概述

Deltafin是一个单一的原生二进制文件，旨在运行完整的、未经剪枝的2.8万亿参数Kimi K3模型。其核心原则是：K3模型本身决定每一个输出的token，质量绝不妥协。所有16个专家网络和完整的K3目标模型被完整保留，确保输出与Moonshot AI发布的版本完全一致。

性能表现

在M1 Max笔记本上，实现了 0.2901 token/s 的吞吐量，比上一版本提升1.9%。历史基准测试显示，自2026年7月27日以来，性能从0.0141 token/s大幅提升至当前水平，体现了持续的优化成果。

核心目标与理念

• 目标：在不降低模型质量的前提下，尽可能提升运行效率。速度的提升不得通过减少模型参数或专家数量来实现。
• 实验性质：该项目是一个探索性实验，旨在研究如何将前沿AI模型在消费级硬件上运行。K3原始设计需要约4.8 TB显存和16个节点，而Deltafin的目标是使其能在一套约1.5万美元的家庭设备上运行。
• 质量保证：与其他可能对专家库进行压缩（例如降至~3位精度）以追求速度的项目不同，Deltafin坚持使用Moonship发布的原始模型权重。

安装与使用

1. 安装

• 方式一（完整下载）：下载完整的1.7 TB模型到本地磁盘，以获得最佳性能。
• 方式二（流式加载）：初始仅需215 GB磁盘空间，运行时按需流式获取专家权重，速度较慢，但可通过缓存逐渐提升。
• 默认包含 Inferact的Kimi-K3-DSpark 模型，可选安装 Qwen模型 以加速原始文本续写任务。

2. 升级

提供升级命令，可重新构建二进制文件，而不会重新下载模型或重置设置。升级过程安全，会检查环境一致性。

3. 使用方式

• 命令行：支持--chat（聊天模式）和原始续写模式，并可添加统计信息。
• 兼容OpenAI的API服务器：可启动一个本地服务器，支持/v1/chat/completions等端点，实现流式响应。该服务器实现了一个严格且功能有限的OpenAI API子集，注重正确性和可重现性。

技术特点

• 单一原生二进制：核心为Rust编写，包含C-ABI提供者、路由追踪、专家预取和原生分词器。
• 质量守卫：系统确保小模型（如DSpark、Qwen）的猜测必须经过K3的验证，任何未经K3确认的token都不会被输出。
• 严格API：服务器拒绝任何无法精确兑现的API请求，返回标准错误，而非静默忽略。

文档与参考

项目文档涵盖了：

• 原生运行时工作原理。
• OpenAI兼容服务器API的详细规范。
• 健康检查机制。
• 存储配置。
• 性能复现方法。
• 支持的平台（如MPS/Metal、CUDA、原生CPU）。

致谢与许可

该项目基于并致敬Moonshot AI发布的K3模型权重、Inferact的DSpark检查点、Qwen模型，以及众多开源项目和社区研究。Deltafin的项目代码以MIT许可证发布，而模型权重则遵循其上游许可条款。Deltafin是一个独立项目，与Moonshot AI无关联。

AI发展前沿的协调挑战

AI的巨大潜力与潜在风险

人工智能有望创造一个显著改善的未来，但这一结果并非必然实现。全球领先的AI公司认为，他们可能即将实现AI研究的自动化。尽管难以精确预测这将如何加速AI的进步，但确实存在一种切实的风险：AI能力的发展可能会迅速超越我们理解和控制所产生系统的能力。

竞争压力下的协调困境

为了实现AI的潜力，行业、政府和全社会可能需要一个**“争取时间”的选项**，以应对新兴风险、制定安全措施并加强监管。然而，每家公司乃至每个国家都面临着巨大的竞争压力，使其难以单方面放缓这种加速进程。当前，全球缺乏足够的技术和治理工具来有意识地协调整个前沿领域的进展节奏。

建立监测与节奏调控机制

文章指出，我们需要在现有针对前沿模型发布进行监测的工作基础上，进一步构建能够主动调控AI发展节奏的机制。这旨在确保AI能力的增长能够与我们的理解、控制及安全防护能力相匹配，从而在推动进步的同时管理好伴随而来的重大风险。