antirez 重返 Redis：缘由、观点与新技术构想

回归缘由

作者 antirez 在离开 Redis 项目约 4.44 年后，决定重新参与其生态系统。离开期间，他专注于写作和个人项目，但逐渐感到缺乏明确目标，并目睹了 Redis 社区有分裂的趋势。他认为自己可以扮演一个“布道者”角色，重新成为公司与社区之间的桥梁，帮助 Redis 核心代码重获开发焦点，并从社区中汲取反馈以推动 Redis 的演进。

许可证变更立场

针对近期 Redis 许可证变更的争议，antirez 表示：

• 非本人决定：该变更发生在他离开期间，并非由他主导。
• 可理解性：他理解大型云服务商对开源商业模式的冲击，认为许多项目因此未能启动。他并非开源许可证的极端主义者，认为许可证是一个光谱。
• 新许可证实质：他认为新许可证（与AGPL类似）并非完全闭源。只要不将 Redis 作为一项服务直接售卖，用户仍可免费用于商业用途、修改和分发。它主要限制了云服务商在不贡献代码的情况下直接售卖 Redis 服务的能力。
• 核心关切：他认为社区分裂的关键并非许可证本身，而是项目发展方向过度向公司利益倾斜。他希望新许可证能促使开发重心回归 Redis 核心，带来更多新特性。

早期经历与“罗宾汉”模式

antirez 回顾了 Redis 早期，他曾考虑通过闭源工具或延迟开源许可来盈利。但得益于 VMware 和后来的 Redis Labs（现为 Redis）的赞助支持，他得以在 12 年间专注于以社区利益为核心进行开发，如同“开源软件的罗宾汉”。他认为这是一种比创办自己公司更好的模式。

对 AI 与向量索引的热情

antirez 对人工智能和神经网络持积极态度。他认为 AI（如 Claude AI）是强大的辅助工具，能加速和提升工作质量，而非取代人类。

基于此兴趣，他正在设计一个新的 Redis 数据结构，暂称为 “Vector Sets”。其核心思路源于排序集（Sorted Sets）：

• 核心概念：将排序集的“分数”（score）替换为多维向量（即嵌入/Embeddings），从而支持向量相似度计算（K近邻匹配）。
• 设计哲学：遵循 Redis 作为“程序员乐高”的理念，提供基础的数据结构操作，将上层应用逻辑（如混合搜索、过滤）交由开发者自行实现。
• 初步实现：他已编写了一个实现该功能的模块，提供了如 VSIM（向量相似性查询）、VADD、VCARD 等命令，并展示了查询电影相似度的示例。当前处于概念验证阶段，正在进一步优化（如多线程、降维、量化）。
• 扩展想法：考虑增加 STORE 选项，将结果存储到另一个排序集中（以相似度为分数），这将为脚本和高效处理带来新的可能。

结语

antirez 宣布正式重返 Redis 项目，感谢社区多年的支持，并希望为这段旅程增添新的内容。

Gemini 2.0：为智能体时代打造的新AI模型

谷歌DeepMind发布了Gemini 2.0，这是一款专为"智能体时代"设计的新型AI模型。它在多模态能力上实现了重大突破，能够原生输出图像和音频，并支持工具调用。

核心模型：Gemini 2.0 Flash

• 性能与速度：作为系列首款模型，Gemini 2.0 Flash在保持低延迟的同时，性能显著提升，其关键基准测试成绩甚至超过了上一代的1.5 Pro模型，且速度快两倍。
• 原生多模态输出：除了处理图像、视频和音频输入，现在能原生生成图文混排内容，并支持可控制的多语言文本转语音。
• 原生工具使用：可直接调用谷歌搜索、代码执行以及第三方用户定义的函数。
• 可用性：该实验模型已通过Gemini API向开发者开放。明年1月将正式发布并推出更多模型尺寸。同时，面向所有Gemini用户的聊天优化版本也已上线。

解锁智能体体验

Gemini 2.0 Flash的原生UI操作能力、多模态推理、长上下文理解和规划能力，共同催生了新一类"智能体"体验。谷歌正通过一系列原型进行探索：

• Project Astra：一个通用AI助手的升级版研究原型。基于Gemini 2.0，其改进包括多语言对话、调用谷歌搜索/地图等工具、长达10分钟的会话记忆以及接近人类对话的延迟。
• Project Mariner：探索以浏览器为中心的人机交互。它能理解并推理浏览器屏幕上的信息，通过Chrome扩展程序为用户执行任务。在WebVoyager基准测试中达到了83.5%的先进水平。
• Jules：一个集成到GitHub工作流中的实验性AI代码智能体，能在开发者的指导下处理问题、制定计划并执行。

在其他领域的探索

• 游戏：基于Gemini 2.0的智能体能够仅通过屏幕画面理解游戏规则，并实时提供下一步建议。正与Supercell等游戏开发商合作测试。
• 机器人：将Gemini 2.0的空间推理能力应用于物理世界，探索辅助机器人发展的可能性。

负责任地构建智能体时代

谷歌强调在开发过程中将安全与责任放在首位：

• 通过内部审查委员会（RSC）识别潜在风险。
• 利用Gemini 2.0的推理能力进行AI辅助的红队测试，自动生成评估和培训数据以缓解风险。
• 持续评估和训练模型在图像与音频输入输出方面的安全性。
• 针对各项目实施具体安全措施，如Project Astra的隐私控制、Project Mariner防止恶意提示注入。

总结

Gemini 2.0 Flash的发布及其在智能体领域的探索原型，标志着Gemini时代的一个新篇章。谷歌表示将继续在确保安全的前提下，探索通往通用人工智能（AGI）的新可能性。

Google Willow 量子芯片概述

Google 量子团队发布了名为“Willow”的105量子比特超导芯片，实现了表面码纠错的量子比特演示，并基于随机电路采样（Random Circuit Sampling）完成了新一轮量子霸权实验。该进展在量子计算2024年Q2B会议期间公布，被视为领域内的一个重要里程碑。

技术进展与里程碑

• 芯片参数：Willow 芯片拥有105个量子比特，相比2019年谷歌量子霸权实验时的量子比特数量约翻倍，相干时间提升5倍，两比特门保真度达到99.7%（CZ门）或99.85%（iSWAP门）。
• 量子纠错突破：在表面码实验中，随着码距从3×3增至7×7，编码逻辑量子比特的存活时间变长而非缩短，这标志着跨越了量子纠错的关键阈值。但谷歌尚未实现容错两比特门（目标错误率~10⁻⁶），目前仅演示了单个编码量子比特，未进行编码操作。
• 量子霸权实验：基于40层门电路的随机电路采样，谷歌称该实验若用经典最优算法（基于张量网络收缩）和百亿亿次超算模拟，需约3亿年（无内存限制）或10²⁵年（有内存限制）。但结果的直接验证同样需要经典计算机花费约10²⁵年，因此所有验证均基于对小电路实验的外推，属于“不可直接验证”范畴。

行业反应与竞争意义

• 技术对比：Willow的发布被视为谷歌对离子阱（如Quantinuum）和中性原子（如QuEra）等竞争对手的回应，展示了超导路线的持续进展。超导门速优势（快千倍）与离子阱可移动性、高门保真度形成不同技术特点的对比。
• 科学验证争议：部分学者如Gil Kalai继续对谷歌的实验方法持怀疑态度，但该领域已有多家机构（IBM、Quantinuum等）报告类似随机电路采样结果，支持量子计算可行性。
• 作者观点：文章作者认为Willow是扎实的技术进步，符合领域预期，但强调量子霸权实验的验证难题是当前设计的关键挑战。对于量子力学诠释（如多世界理论），新实验未带来额外哲学突破。

后续展望

量子计算从重大实验里程碑到下一阶段通常需要数年时间。谷歌的成就推动了实验量子计算的发展，但实现完全容错量子计算仍任重道远。行业需继续探索更高效的量子算法、纠错方案及可验证的近中期实验设计。

Limbo：用Rust对SQLite进行完全重写

Turso团队（libSQL项目维护者）宣布启动名为 Limbo 的实验性项目，目标是使用内存安全的语言 Rust 从头重写SQLite，以在保持兼容性的同时探索新的可能性。

背景与动机

团队最初通过 fork SQLite 创建了libSQL项目，并取得了成功（超过1.2万GitHub星标，85位贡献者），支持原生复制和向量搜索等功能。然而，fork方式存在局限性：

• SQLite的测试套件是私有的，难以对大规模改动建立信心。
• SQLite使用不安全的C语言编写，影响代码演进的可靠性。
• 在尝试为libSQL添加向量搜索时，若需要索引，难以实现理想的SQL语法，需要迂回的解决方案。

因此，团队决定尝试完全重写SQLite，以验证能否在保持文件格式和语言兼容性的前提下，实现更高的灵活性与可靠性。

核心目标

• 构建一个完全兼容SQLite（语言和文件格式）的重新实现。
• 确保同等或更高的可靠性，同时实现完整的内存安全。
• 采用现代化的新架构，为未来扩展（如异步I/O）提供更坚实的基础。
• 若成功，Limbo的代码库将并入libSQL，采用相同的MIT许可证和社区友好模式。

关键特性与进展

1. 全面异步I/O设计

   • 从底层设计支持异步操作，扩展了sqlite3_step等核心API。
   • 在Linux上利用高性能的io_uring接口。
   • 解决了SQLite同步接口在处理慢查询或网络环境（如Turso的HTTP服务、S3存储）时的局限性。

2. 原生WASM支持

   • 从开始就为WebAssembly环境设计，提供了可直接与Drizzle ORM等工具配合的VFS实现。
   • 简化了在浏览器或类似Stackblitz环境中使用嵌入式数据库的流程。

3. 卓越的性能

   • 在早期基准测试中，Limbo执行SELECT * FROM users LIMIT 1的耗时已比SQLite快约20%（506ns vs 620ns）。

4. 简化的用户体验

   • 保留了SQLite的字节码和文件格式兼容性，但移除了一些现代环境中不太重要的特性（如单一C文件的“amalgamation”构建方式）。
   • 提供更开箱即用的性能，减少了用户为优化SQLite而需要手动调整的复杂配置。

可靠性保障策略

为实现超越SQLite的可靠性，Limbo采用了先进的测试方法：

• 确定性模拟测试（DST）：从项目初期就内置DST框架，能够模拟罕见场景并可靠复现问题。
• 与Antithesis合作：利用其系统级DST平台，模拟各种硬件和软件故障，通过确定性超级管理器进行并行模糊测试。例如，已借助该合作发现了在部分写入条件下io_uring实现的潜在问题。
• 持续模糊测试：定期对输入进行模糊测试，并确保Limbo与SQLite生成相同的字节码，以验证兼容性。

项目现状

Limbo仍处于早期阶段，但已达成重要里程碑，包括异步I/O、WASM支持和显著的性能优势。项目以MIT许可证在GitHub上开源，欢迎社区参与共建。

根据提供的文章标题，核心信息是：超重已取代烟草吸烟，成为2024年的首要疾病风险因素。

需要说明的是，所提供的文章实际内容为一段网页安全验证代码（Cloudflare challenge），无法从中获取更详细的正文信息。因此，总结仅基于给定的明确标题。

关键要点如下：

• 风险因素排序变化：在2024年，身体超重（overweight）在主要疾病风险因素中占据了第一位。
• 取代了烟草的地位：此前长期被视为头号健康威胁的烟草吸烟（tobacco smoking），其排名已降至超重之后。
• 潜在意义：这一转变反映了公共卫生问题的变化，表明与体重相关的健康风险在当前变得尤为突出和普遍。

Electric (Postgres 同步引擎) 发布 Beta 版本

Electric 是一个 Postgres 同步引擎。它实现了将 Postgres 数据实时部分复制到本地应用和服务中。开发者可以使用 Electric 以数据同步替代传统的数据获取，从而构建基于即时、实时、本地数据的应用，无需自行开发同步引擎或更改技术栈。团队同时开发了 PGlite，一个可在浏览器中运行的轻量级 WASM Postgres。

迈向 Beta 的历程

项目于2024年6月29日进行了彻底的重写，经过600个拉取请求后，现已准备好投入生产应用使用。

已具备生产就绪性

Electric 和 PGlite 已被 Google、Supabase、Trigger.dev、Otto、Doorboost 等公司用于生产环境。

• Trigger.dev：使用 ElectricSQL 为其核心功能 Trigger.dev Realtime 提供支持，在用户执行后台任务时提供即时更新，操作简单且每天可扩展处理数百万次更新。
• Otto：构建了电子表格产品，其中每个单元格都是独立的 AI 代理。ElectricSQL 能够可靠地实时传输代理更新，并高效管理大型电子表格，简化了架构并实现了单元格级响应式更新。
• Doorboost：聚合来自十几个平台的数百万行数据，并将其提炼到一个简单的仪表板中。Electric 使该仪表板能够在毫秒级内交付并实时更新。

可扩展性

Electric 从设计之初就针对高吞吐量工作负载进行了工程优化，能够以低延迟和扁平的资源消耗运行。可以从单个常规 Postgres 实例向数百万并发用户流式传输实时数据。 基准测试图表显示，在每分钟960次写入的持续负载下，将并发客户端从10万扩展到100万时，内存使用和延迟基本保持平坦。 更新后的 Linearlite 演示（一个克隆了10万条问题及其评论的 Linear 应用，数据量约150MB）展示了大规模应用使用 Electric 时的即时交互体验。

易于采用

API 经过大量迭代，力求简洁且强大。后续的次要版本或补丁版本将不会引入破坏性变更。

• 更新了文档，提供了新的快速入门指南和针对身份验证、本地写入、使用 Shape 进行部分复制、部署 Electric、为任意语言或环境编写客户端等主题的指南。
• 提供了客户端库、集成文档、演示应用和代码示例，展示如何在不同的模式和框架中使用 Electric。

渐进式采用

可以逐个组件、逐个路由地逐步采用 Electric。例如，可以将一个组件中通过 fetch 获取数据的传统模式：

import React, { useState, useEffect } from 'react'
const MyComponent = () => {
  const [items, setItems] = useState([])
  useEffect(() => {
    const fetchItems = async () => {
      const response = await fetch('https://api.example.com/v1/items')
      const data = await response.json()
      setItems(data)
    }
    fetchItems()
  }, [])
  return <List items={items} />
}

替换为使用 Electric 的 useShape 钩子进行数据同步：

import { useShape } from '@electric-sql/react'
const MyComponent = () => {
  const { data: items } = useShape({
    url: 'https://electric.example.com/v1/shapes',
    params: {
      table: 'items',
    },
  })
  return <List items={items} />
}

此方式适用于任何 Postgres 数据模型、主机、数据类型、扩展和 Postgres 功能（包括 pgvector、PostGIS、顺序 ID、唯一约束等），无需更改数据模型或迁移。由于 Electric 通过 HTTP 同步，可以与现有 API 一起使用，利用现有代码处理身份验证和写入等事务。

提供 Electric Cloud 早期访问

团队正在构建 Electric Cloud，提供托管的 Electric 主机服务。

《作为软件工程师制作我的第一个机器人》摘要

作者是一名计算机视觉软件工程师，首次接触机器人硬件后，决定在业余时间制作一个视觉控制的笔式绘图机。以下是项目的主要步骤和关键点。

硬件选择与设计

• 电机选择：作者研究了直流电机、伺服电机和步进电机，最终选用Nema 17步进电机，因其可通过步数精确控制角度。
• 3D打印与CAD设计：购买BambuLab A1 3D打印机，使用Onshape进行CAD设计，制作了机器人基座、臂和肘部部件。设计时参考了双摆结构，基座用于隐藏电机，臂部采用铝合金型材以简化原型制作。
• 电机驱动与控制：电机驱动器通过磁铁传感器和PID控制器实现闭环控制，但固件版本不兼容（V1.0与V1.1）导致通信失败。作者修改了Arduino库以支持多版本，解决了问题。
• 电源与微控制器：使用12V电源适配器为电机供电。最初使用Arduino Uno，但串口不足，后切换到ESP32以获得更多串口，便于与电机通信。
• 底板与绘图表面：利用旧公寓的玻璃塑料板作为底板，覆盖白板膜以扩大绘图区域。通过胶合快照铆钉固定基座，但后期改为更稳定的固定方式。
• 笔架设计：最初设计弹簧式笔架以保持笔压均匀，后改用伺服电机控制笔的升降，实现绘图中断。伺服电机需5V供电，最终切换回Arduino利用其5V输出。

软件与控制实现

• 运动学计算：通过线性代数推导正向运动学公式，将电机角度转换为笔的坐标位置。逆向运动学使用scipy优化库最小化目标位置误差，实现笔的定位。
• 控制方式：尝试闭环PID控制但出现抖动，最终采用开环控制（CR_OPEN模式）以获得稳定运动。通过串口定义通信协议（如PD、PU、M、H命令）控制绘图机动作。
• 视觉控制集成：使用摄像头和MediaPipe手部检测库，允许用户通过空中手指绘图控制机器人。右手食指移动笔位，左手食指与拇指接触表示笔升降，双食指接触结束绘图。

遇到的挑战与解决

• 电机驱动器固件不兼容：修改库代码支持不同版本。
• 绘图机抖动：切换到开环控制。
• 笔架压力不均：引入伺服电机和弹簧机制，后简化设计。
• 底板固定问题：设计可拆卸连接，但最终调整方案以增强稳定性。

结果

作者成功制作了视觉控制的笔式绘图机，能够通过摄像头检测手部动作，在白板上绘制图形。项目涵盖了硬件选择、CAD设计、运动学计算、软件控制和视觉集成等多个环节，体现了从软件到硬件的跨学科实践。

Dioxus 0.6 发布：跨平台应用开发框架的重大更新

Dioxus 是一个用于使用单一代码库构建全栈 Web、桌面和移动应用程序的 Rust 框架，其目标是成为“更好的 Flutter”。Dioxus 0.6 是一次重大版本更新，旨在简化框架使用、提升开发者体验并修复长期存在的问题。

核心亮点与主要改进

1. 全新重写的 CLI（命令行工具）

• dx serve 支持移动端：现在可以直接在 Android 和 iOS 模拟器及真机上运行应用。
• 神奇的热重载：支持格式化字符串、组件属性以及嵌套的 rsx!{} 代码块的热重载。
• 交互式 CLI：提供全新的交互式用户体验，灵感来源于 Astro 框架。
• 内联堆栈跟踪：可以直接在终端捕获并显示 WASM 应用的 panic 和日志。
• 原生服务器函数：为桌面和移动应用引入了内联的服务器 RPC 功能。
• dx bundle 全平台支持：现在支持为 Web、iOS 和 Android 打包。
• JSON 输出模式：支持以 JSON 格式输出 CLI 消息，便于第三方工具和 CI/CD 管道集成。

2. 开发者体验全面升级

• Web 开发反馈：开发期间为 Web 应用增加了 Toast 通知和加载屏幕。
• 自动补全大幅改进：显著提升了 rsx 宏的自动补全能力，与 Rust-analyzer 集成更好。
• asset!() 系统稳定化：集成了基于链接器的资源系统，用于原生应用。
• HTML 流式传输：支持从服务器向客户端流式传输悬停边界和错误边界。
• 静态站点生成与增量再生：新增了对静态站点生成和增量静态再生的支持。
• 错误处理改进：在事件处理器、任务和组件中支持使用 ? 运算符处理错误。
• 新文档元素：引入了 Head, Title, Meta, Link 等组件，用于设置文档属性。
• 同步事件处理：跨所有平台同步处理事件，并直接支持 prevent_default()。
• 新事件处理器：新增 onresize 和 onvisible 事件处理器，无需 IntersectionObserver 即可跟踪元素尺寸和可见性。
• WGPU 集成：支持将 Dioxus 作为覆盖层渲染在 WGPU 表面和子窗口之上。
• 新模板：提供三个新的跨平台应用入门模板。

3. 重大特性深度解析

• 原生移动端支持：这是本次更新的重点。Dioxus 从头开始构建了完整的移动工具链，使得 dx serve --platform ios/android 开箱即用，无需额外配置 Gradle、CocoaPods 等。它支持所有平台使用相同的 main.rs，是首个实现此功能的 Rust 框架。
• 热重载引擎全面改造：目标是实现“零完全重建”的开发迭代。新引擎支持热重载格式化字符串、嵌套 rsx 块、组件属性以及简单的 Rust 字面量（数字、布尔值、字符串），并覆盖了移动平台。
• 悬停边界与 HTML 流式传输：引入了用于异步 UI 的核心原语。Suspense 组件可在子组件加载时显示占位符。配合全栈支持，悬停边界可以从服务器流式传输到客户端，无需等待整个页面加载完成。
• 静态站点生成与增量静态再生：内置了对 SSG 的支持，通过添加 static_routes 服务器函数并使用 dx build --ssg 标志即可生成静态 HTML。ISG 则允许服务器按需生成页面并缓存。
• asset!() 资源系统：该系统已稳定，它通过构建管道自动处理 CSS（压缩、去重）和图片（生成缩略图、优化格式如 AVIF/WebP），并集成到所有平台。资源的自动哈希和命名有助于 CDN 和浏览器缓存。
• 混合式 WGPU 覆盖层：Dioxus 桌面版现在支持“子窗口”功能，可以轻松地将原生应用覆盖在 WGPU 或 OpenGL 等现有渲染器之上。

总结与展望

Dioxus 0.6 是迄今为止最大的版本更新，合并了超过 350 个拉取请求，解决了数百个问题。此次更新的核心目标是大幅提升热重载、自动补全和资源打包的质量，使 CLI 更加稳健易用，并将移动端工具链内联到 CLI 中以提供一流的移动支持。

团队计划在 0.6 版本上停留较长时间，专注于制作教程、编写文档、修复 bug、提升性能和社区协作。未来（0.7及之后）的计划包括：真正的 Rust 代码热重载（通过二进制补丁）、集成路由器的 Wasm 包拆分、以及支持一键部署到托管平台。

关于将 memcpy(NULL, NULL, 0) 定义为良定义行为的提案总结

提案核心：C语言标准提案 N3322 已被接受（面向 C2y），该提案将一系列与空指针和零长度操作相关的行为从“未定义行为”转变为“定义良好”。

定义良好的具体场景： 以下操作当涉及空指针且长度为零时，将是定义明确的：

• memcpy(NULL, NULL, 0);
• memcmp(NULL, NULL, 0);
• (int *)NULL + 0;
• (int *)NULL - 0;
• (int *)NULL - (int *)NULL;

未改变的未定义行为： 以下操作依然是未定义行为：

• memcpy(NULL, NULL, 4); （长度非零）
• (int *)NULL + 4; （偏移量非零）

提案动机：

1. 避免隐蔽的代码缺陷：在实际代码中（例如，当两个可能为空的字符串进行比较时），很容易无意中调用 memcmp(NULL, NULL, 0) 这样的函数。按现行标准，这属于未定义行为。
2. 防止编译器进行有害优化：基于此类未定义行为，编译器可能会移除后续看似冗余的空指针检查，从而引入安全风险。
3. 简化代码并提升性能：开发者目前需要为这类情况添加额外的长度检查代码（如在调用 memcmp 前检查 len == 0）。新标准将使代码更简洁、高效且不易出错。
4. 保持语言内部一致性：为了使像 memcpy 这样的库函数实现本身自洽（例如，实现中涉及指针算术 src + n），也需要定义空指针的零长度算术操作。

反对意见：

1. 地址空间扩展：当存在非标准的“地址空间”扩展时，可能存在多个空指针表示形式，确保 NULL - NULL 返回 0 可能需要额外代码，影响“零开销”承诺。
2. 静态分析工具：静态分析器将无法再无条件地报告传递给 memcpy 等函数的空指针错误，它们现在必须考虑长度参数。未来可能需要引入 __Optional 等限定符或新属性（如 GCC 考虑的 nonnull_if_nonzero）。

结果与影响：

• 尽管存在反对意见，提案的投票结果强烈支持这一变更。
• 更值得注意的是，投票还建议编译器和库实现者将此变更向后应用到旧的标准版本中，即在不指定 -std=c2y 标志的情况下默认生效。
• 对性能无负面影响，甚至可能带来积极影响。
• 此次标准化实际上是对主流编译器（如 LLVM, GCC, MSVC）和运行时库现有实践的确认，因为它们在实际实现中（例如作为编译器内建函数）早已将 memcpy(NULL, NULL, 0) 视为良定义行为。提案的起源部分也来自于 LLVM 与 C 标准之间的语义差异。

致谢：该提案是与 Aaron Ballman 合作完成的，并感谢 David Stone 的早期反馈，后者将提案的焦点从单纯的内存库函数扩展到更通用的“零长度”操作。

总结

提供的文章标题为“数字消费让我无法更好地工作”，但实际内容是一个错误页面，显示“看起来这个页面不存在。让我们带你返回主页。”内容中未包含关于数字消费或工作改进的讨论。

文章《不要被分散注意力》讲述了作者Caleb作为一名软件开发者，如何在不完全知情的情况下参与了一个为美国国防部开发杀伤性工具的实习项目，并以此警示开发者需要时刻保持对代码伦理影响的警觉。

• 项目背景与技术细节：作者加入国防承包商实习，项目是开发一款通过WiFi信号强度定位信号源的手机应用。技术上使用了卷积算法、高斯估计和R²误差计算来预测位置，后通过遗传算法优化精度，并用卡尔曼滤波器实现对移动目标的跟踪。
• 被忽视的真相：项目负责人反复询问能否追踪手机信号，暗示工具的真实用途是定位人员。作者和团队沉浸于解决技术挑战，未深究目的，最终意识到工具可能被用于军事打击目标。
• 伦理警示与案例：作者列举了多个开发者无意中构建有害工具的例子，包括：一位开发者按需求制作总是推荐特定药物的问卷，间接导致用户自杀；Uber开发“灰球”功能用于逃避执法。这些案例表明，开发者易因专注于技术或利益而忽略伦理后果。
• 责任与建议：开发者拥有影响世界的能力，因此有责任审视代码的潜在影响。文中建议：在规划阶段设想软件最坏可能的用途；不满足于表面需求，持续追问“为什么”以理解真实意图；在必要时应拒绝开发或提出替代方案。
• 核心呼吁：开发者不应被截止日期和功能请求分散注意力，而需主动思考所构建事物的后果，设置防护措施防止滥用，或在风险过高时选择放弃。技术发展迅速，但伦理考量必须同步，因为代码一旦发布便难以收回。

《训练LLM在连续潜在空间中推理》总结

问题背景

大型语言模型（LLM）通常被限制在语言空间中进行推理，通过思维链（CoT）表达推理过程来解决复杂问题。然而，语言空间可能并非推理的最优选择：大多数词元主要用于维持文本连贯性，对推理并非必需，而一些关键词元则需要复杂规划，对LLM构成挑战。

创新方法

为探索超越语言的推理潜力，本文提出了一种新范式 Coconut（连续思维链）。其核心思想是将LLM的最后一个隐藏状态作为推理状态的表示，称为“连续思维”。与传统CoT不同，Coconut不将该状态解码为词语，而是直接将其作为下一步输入嵌入，在连续空间中反馈给模型。

技术特点

这种潜在推理范式启用了一种先进的推理模式：连续思维可以编码多个可能的后续步骤，使模型能够执行广度优先搜索（BFS），而非像CoT那样提前承诺于单条确定性路径。

实验结果

Coconut在需要大量规划搜索的逻辑推理任务上优于CoT，并在准确率和效率之间实现了更好的权衡。

对谷歌“量子霸权”声明的质疑

文章对谷歌2019年在《自然》上发表的“量子霸权”论文提出了一系列严重的方法论质疑。该论文声称，谷歌的53量子比特“悬铃木”量子计算机在约200秒内完成了一项特定计算，而最先进的经典超级计算机完成同一任务需约一万年。作者认为，谷歌的“保真度主张”和“霸权主张”均存在重大缺陷，其结论可能更多地反映了研究者的期望，而非客观科学现实，并建议在制定政策时谨慎对待此类声明。

主要质疑点

1. “霸权”主张：对经典运行时间的估计存在严重错误

   • 估计的经典计算时间被夸大了10个数量级。
   • 谷歌团队当时已知存在更优的经典算法，却在实验前几周更改了电路类型以进行演示。
   • 论文中“量子计算能力将按双指数速率增长”的断言在科学论文中显得过于夸张。

2. “保真度”主张：统计上不合理的预测暴露方法论问题

   • 论文基于单个组件错误率的简单先验预测，与实验估算的保真度高度吻合，这在统计上难以置信（“好得不真实”）。
   • 谷歌为解释此一致性提出的三个统计前提（组件保真度精确至±20%、误差无偏、各组件保真度统计独立）均不合理，且与其他实验发现矛盾。
   • 至今，谷歌团队仍未公开关键组件（如两量子比特门）的错误率数据。

3. 校准过程：存在未经记录的全局优化证据

   • 统计证据表明，校准过程存在方法论有缺陷的全局优化，甚至影响最小规模（12量子比特）电路的结果。
   • 非统计证据（如提供给合作者的校准版本与最终实验版本不符）也支持这一指控。
   • 谷歌以商业秘密为由未公开校准程序，也未兑现分享输入数据的承诺。

4. 与IBM的对比及建议采纳问题

   • 在随机电路采样任务上，谷歌声称的性能与更先进的IBM量子计算机的已知能力存在巨大差距。作者认为这更可能反映了谷歌实验的方法论问题。
   • 谷歌团队虽认可作者提出的一些改进控制质量的建议，但在后续实验中并未实施，反而使得实验更难验证。

背景与后续发展

• 谷歌2019年的“霸权”声明已被多个研究团队的系列论文所反驳，包括IBM的研究人员等。
• 谷歌现已承认，使用张量网络收缩方法，其2019年的53量子比特结果可在200秒内经典完成。但在2023/24年的新论文中，谷歌声称对于67-70量子比特的电路，经典计算机仍需数年。
• 作者指出，即使对于较小规模的电路，其针对谷歌保真度主张的方法论质疑仍然独立存在。
• 作者对谷歌2024年12月关于其“Willow”量子计算机（声称在5分钟内完成需经典超算10^25年才能完成的计算）以及量子纠错实验的新主张，同样持谨慎态度，认为需要对其非凡声明保持警惕。

作者结论

作者认为，谷歌量子人工智能团队的声明应谨慎对待，特别是那些非凡的声明。这些声明可能源于重大的方法论错误，因此可能反映了研究者的主观预期，而非客观科学现实。作者不建议将谷歌过去或未来的声明作为政策制定的坚实基础。

pgroll 是一个专为 PostgreSQL 设计的开源数据库模式（Schema）迁移工具。其核心目标是实现零停机、可逆且安全的模式变更，消除在生产环境进行数据库迁移的风险和复杂性。

核心特性与工作原理

1. 零停机迁移：通过在新旧版本的数据库模式上创建并维护可更新视图（Updatable Views），确保应用程序在整个迁移过程中保持可用。应用的不同实例可以同时访问新旧两个版本的模式，从而无需停机。
2. 多版本并发：这是实现零停机的关键。工具会同时呈现两代模式，允许代码平滑过渡到新版本，而无需临时添加向后兼容的代码。
3. 可逆迁移：回滚操作设计得非常简单和安全。如果迁移后发现问题，可以快速回退，只需移除临时创建的列和视图即可，不会导致数据丢失或需要复杂的恢复脚本。
4. 自动化数据回填：工具自动处理模式变更所需的数据回填（Backfill）和数据转换/操作，开发者无需编写和维护一次性数据迁移脚本。
5. 隐藏列与批次处理：在迁移过程中，pgroll 会使用隐藏列来存储需要回填的数据，并以批次方式处理。当迁移完成时，这些隐藏列将正式成为物理模式的一部分。
6. 遵循扩展-收缩模式（Expand-Contract Pattern）：pgroll 自动化了这一复杂的模式变更范式，负责处理其繁琐的中间步骤。

管理与集成

• 迁移请求：提供统一的界面来管理复杂的模式变更，支持在单个请求中进行审查、测试（通过模拟运行）和部署。
• 模拟运行与测试：允许针对暂存数据库测试迁移部署计划，增加实施信心。
• 工具无关性设计：pgroll 能够无缝集成到现有的开发和部署流水线中，如 Jenkins、GitHub Actions 或其他 CI/CD 工具，无需对现有设置进行重大更改。
• 兼容主流 ORM：支持与 Prisma、Drizzle 等流行的数据库对象关系映射（ORM）工具集成。

社区反馈

该工具获得了开发者社区的关注，被认为是 Postgres 模式迁移的创新方案。多位开发者在社交媒体上分享了正面评价，认可其在提供零停机部署、实现数据库版本化以及简化回滚操作方面的价值。

总结

pgroll 旨在通过其自动化、版本化和可逆的机制，消除数据库模式迁移的恐惧，使生产环境的数据库变更如同管理代码一样可靠和便捷。

该页面不存在。

阿尔茨海默病研究显示酮体有助于清除错误折叠的蛋白质

• 核心发现：巴克研究所的科学家揭示了酮体（特别是β-羟基丁酸，βHB）直接调节错误折叠蛋白质的分子机制。研究利用线虫和小鼠模型证明，酮体能与错误折叠的蛋白质相互作用，改变其溶解度和结构，从而通过自噬过程促进其从大脑中清除。

• 研究背景：酮体是脂质衍生的小分子代谢物，在禁食期间为细胞供能。此前已有研究表明，通过饮食、运动或补充剂提升酮体水平对大脑健康有益，并在阿尔茨海默病（AD）动物模型中改善认知和运动行为。

• 实验与证据：

  • 体外实验：酮体与错误折叠蛋白直接作用，改变其溶解度。
  • 线虫模型：喂食酮体后，表达人类淀粉样β蛋白（导致淀粉样斑块）的线虫恢复了运动能力。
  • 小鼠模型：酮酯治疗促进了不可溶蛋白的清除，而非病理聚集。
  • 蛋白质组分析：研究构建了详细的蛋白质组溶解度图谱，证实酮体影响脑细胞中的蛋白质质量控制。

• 机制与新见解：研究推翻了以往认为酮体改善大脑健康仅通过供能或抗炎的间接观点，提出酮体作为“分子清洁工”，直接帮助清除受损蛋白质。这揭示了一种代谢调节蛋白质稳态的新形式，类似代谢物也表现出类似效果，提示代谢变化可能通过多种分子协同改善脑功能。

• 应用前景：酮体易于实验和治疗操控，该发现为开发针对衰老和AD的代谢相关靶点疗法提供了新方向。研究者指出未来需在人类中验证此机制，并探索酮体在大脑以外组织（如肠道）的作用。

Canvas：ChatGPT 的新型协作界面

Canvas 是 ChatGPT 推出的全新界面，专为写作和编码项目设计，旨在超越简单的聊天交互。它会在一个独立的窗口中打开，让用户与 ChatGPT 能够并肩协作，共同创建和完善想法。

核心功能与使用场景

Canvas 的核心是提供一个更适合编辑和修订的协作环境。它解决了传统聊天界面在需要频繁修改的项目中的局限性。

• 上下文理解：Canvas 让 ChatGPT 能更好地理解你项目目标的全局。你可以高亮特定段落，指示 ChatGPT 重点关注，它会像一位编辑或代码审查员一样，提供基于整体项目的内联反馈和建议。
• 用户主导：在 Canvas 中，你可以直接编辑文本或代码。界面提供快捷操作菜单，方便你要求 ChatGPT 调整文章长度、调试代码或执行其他操作。
• 版本控制：你可以通过 Canvas 中的返回按钮恢复之前的工作版本。
• 触发方式：Canvas 会在 ChatGPT 认为有帮助时自动打开。你也可以在提示词中加入“use canvas”来手动打开。

专属快捷操作

写作快捷操作：

• 建议编辑：ChatGPT 提供内联建议和反馈。
• 调整长度：将文档编辑得更短或更长。
• 改变阅读水平：调整文本的阅读难度（从幼儿园到研究生水平）。
• 最终润色：检查语法、清晰度和一致性。
• 添加表情符号：为文本添加相关表情符号以增强表现力。

编码快捷操作：

• 审查代码：ChatGPT 提供内联建议以改进代码。
• 添加日志：插入打印语句以帮助调试。
• 添加注释：为代码添加注释以便理解。
• 修复错误：检测并重写有问题的代码以解决错误。
• 移植到其他语言：将代码翻译为 JavaScript、TypeScript、Python、Java、C++ 或 PHP。

模型训练与优化

Canvas 基于 GPT-4o 构建。为了使其成为有效的协作伙伴，研发团队对模型进行了专门训练，使其能够：

1. 判断何时打开 Canvas。
2. 生成多样化的内容。
3. 执行有针对性的编辑或完整重写。
4. 提供精准的反馈和建议。

团队通过多项自动化评估来衡量进展，并运用了从 OpenAI o1-preview 等模型中提炼的合成数据生成技术进行训练，以快速提升写作质量和交互体验。

关键优化成果：

• 触发准确率：在写作和编码任务中，模型触发 Canvas 的准确性分别达到了 83% 和 94%（相较于未优化的基线模型）。
• 编辑行为：模型被训练在用户明确选中文本时进行针对性编辑，否则倾向于重写。在针对性编辑任务上，表现比基线模型提升了 18%。
• 注释质量：通过人工评估，Canvas 模型在代码注释的准确性上提升了 30%，质量提升了 16%。

发布计划与未来展望

Canvas 目前处于早期测试版阶段。从今天起，向全球的 ChatGPT Plus 和 Team 用户推出。企业和教育版用户将在下周获得访问权限。待测试完成后，也计划向所有 ChatGPT 免费用户开放。

Canvas 是自 ChatGPT 推出两年来，其视觉界面的首次重大更新。它代表了一种新的交互方式，旨在让 AI 更有用、更易用。团队计划根据用户反馈，快速迭代和增强其功能。

这篇文章阐述了网页设计中一个简洁的颜色系统方案，建议使用4种颜色来构建完整的视觉层次。

4种颜色的分工如下：

1. 主色与次色：分别用于文本和背景，通常是一对对比色（例如浅色背景配深色文本，或反之）。
2. 强调色：用于高亮显示最重要的交互元素，如按钮或特定数字。
3. 第三色（可选）：用于增添页面个性与视觉兴趣。

实现方式： 文章通过CSS自定义属性（变量）来具体演示该颜色系统。在:root选择器中定义了一套默认颜色值，在.dark类中则定义了对应的深色模式颜色值，便于实现主题切换。例如，主色从浅色调变为深色调，次色反之，而强调色和第三色也相应调整亮度和饱和度以保持可读性和风格一致性。

Helium: 轻量级Python网页自动化库

Helium是一个用于自动化浏览器（如Chrome和Firefox）的Python库。它本质上是一个封装了Selenium的高级API包装器。

核心优势：

• 更简洁的API：与Selenium需要使用HTML ID、XPath或CSS选择器不同，Helium允许开发者通过用户可见的标签（如按钮文字、链接文本）来定位网页元素。这使得Helium脚本通常比等效的Selenium脚本短30-50%，并且更易读、更稳定，不易受网页底层结构变化影响。
• 简化复杂任务：
  • iFrames处理：无需先“切换”到iFrame，即可直接与嵌套iFrame内的元素交互。
  • 窗口管理：能自动识别弹出窗口的打开和关闭，并能通过窗口标题轻松切换窗口。
  • 隐式等待：默认情况下，等待元素出现最多10秒，而非像Selenium那样立即失败。
  • 显式等待：提供更简洁的API来等待特定条件成立，例如 wait_until(Button('Download').exists)。

与Selenium的关系： Helium在底层将每个调用转发给Selenium，因此可以与Selenium API自由混用，开发者不会损失任何Selenium的功能。它专注于解决Selenium使用中的常见痛点。

安装与开始：

1. 环境要求：Python 3及Chrome或Firefox浏览器。
2. 建议创建并激活虚拟环境（python3 -m venv venv 等）。
3. 通过pip安装：python -m pip install helium。

项目状态与贡献： 作者因时间有限，主要专注于维护。项目欢迎Pull Request（PR）形式的贡献。提交PR前需确保测试通过（测试命令：python setup.py test，默认针对Chrome，可通过环境变量TEST_BROWSER指定Firefox）。

历史： Helium最初由Michael Herrmann于2013年为一家波兰IT初创公司开发。公司于2019年底关闭后，作者将其现代化并开源。目前仅维护Python版本，已移除对Internet Explorer的支持。其名称“Helium”取意比Selenium更“轻量”。

AMD可信执行环境遭BadRAM攻击破解

漏洞概述

国际研究团队公开了一种名为BadRAM的概念验证攻击，该攻击可彻底破坏AMD SEV-SNP（安全加密虚拟化-安全嵌套分页） 技术的安全性。SEV-SNP从AMD EPYC 7003处理器开始引入，旨在为云服务器中的虚拟机（VM）提供加密保护，确保即使物理服务器被恶意管理员、执法机构或黑客控制，敏感数据也无法被未授权访问。

攻击原理

BadRAM攻击的核心在于篡改服务器内存的SPD（串行存在检测）芯片。该芯片负责在启动时向BIOS报告内存容量等信息。攻击者通过连接一个简单的树莓派设备（成本低于10美元）或利用软件漏洞，使内存模块虚报其容量为实际容量的两倍，从而创建出不存在的“幽灵内存”。

具体步骤包括：

1. 篡改SPD芯片，使内存模块向CPU报告虚假容量。
2. 配置操作系统忽略幽灵内存（如Linux中通过memmap内核参数）。
3. 利用脚本定位内存别名，即幽灵内存地址与真实受保护内存地址的映射关系。
4. 通过别名绕过CPU访问控制，直接读写SEV-SNP原本保护的加密内存区域，窃取完整性校验哈希值，并植入后门虚拟机而不触发警报。

技术细节

• 幽灵比特（Ghost Bit）：篡改后的SPD使内存地址多出一个无效位（幽灵比特）。CPU将其视为新地址，但内存模块会忽略该位，导致两个不同地址指向同一物理内存位置。
• 物理访问要求：攻击通常需要物理接触服务器内存模块，但部分未锁定SPD芯片的DIMM型号（如某些Corsair DDR4模块）可能支持纯软件攻击。
• 影响范围：主要针对AMD EPYC 7003及以上支持SEV-SNP的处理器，影响亚马逊AWS、谷歌云、微软Azure等主流云平台。

厂商回应与缓解措施

• AMD已发布固件更新修补漏洞，跟踪编号为CVE-2024-21944。
• 建议：使用锁定SPD的内存模块，并加强物理系统安全实践。
• 性能影响：修补后无显著性能损失，仅可能增加启动时间。

研究结论

BadRAM展示了通过操纵内存报告信息来破坏可信执行环境的可行性。尽管对Intel SGX等其他平台的影响有限，研究团队警告此类设计缺陷可能存在于其他系统中，强调需采纳AMD的缓解措施，并在设计中考虑不可信内存的风险。

2024年度天文摄影师大赛获奖作品概览

总冠军

• 作品：《月环食期间月球表面扭曲的阴影》
• 摄影师：Ryan Imperio（美国）
• 简介：该作品由超过30张单独的太阳照片合成，捕捉了2023年10月日环食期间短暂出现的“贝利珠”光学现象，巧妙地绘制了月球接触点处的地形图。

分类奖项获奖作品

天空景观

• 作品：《塔斯曼宝石》
• 摄影师：Tom Rae（新西兰）
• 简介：作品成功平衡了前景的细致地貌与背景宇宙的活力与细节，营造出超现实的梦幻感。

星系

• 作品：《过去的回声》
• 摄影师：Bence Tóth & Péter Feltóti（匈牙利）
• 简介：出色地捕捉了独特的半人马座A星系，凭借精确的图像处理和合作，成为该天体迄今最佳影像之一。

我们的月亮

• 作品：《虹湾的阴影山峰》
• 摄影师：Gábor Balázs（匈牙利）
• 简介：利用月球天平动现象，清晰呈现了虹湾直径约260公里的崎岖地形及周边环形山，为月球地质学提供了宝贵资料。

极光

• 作品：《皇后镇极光》
• 摄影师：Larryn Rae（新西兰）
• 简介：捕捉到了新西兰上空罕见的红色和粉色极光。此类极光通常仅在极地附近可见，此次由强烈的太阳活动引起，更具独特性。

行星、彗星和小行星

• 作品：《接近中》
• 摄影师：Tom Williams（英国）
• 简介：从金星通常缺乏细节的云层中提取出惊人的相位细节，并以准确的比例呈现，色彩虽为伪色但接近自然色调。

人与空间

• 作品：《高科技剪影》
• 摄影师：Tom Williams（英国）
• 简介：完美捕捉到国际空间站划过太阳东侧边缘的瞬间，在宏伟的太阳背景下凸显了人类航天器的存在。

恒星与星云

• 作品：《SNR G107.5-5.2，意外发现（仙后座的涅瑞伊得斯星云）》
• 摄影师：Marcel Drechsler、Bray Falls、Yann Sainty、Nicolas Martino & Richard Galli（多国团队）
• 简介：在知名星座中揭示出此前未知的精妙超新星遗迹结构，色彩处理巧妙，细节丰富。

帕特里克·穆尔爵士最佳新人奖

• 作品：《SH2-308：海豚头星云》
• 摄影师：辛丰 & 苗工（中国）
• 简介：出色呈现了由沃尔夫-拉叶星强劲恒星风塑造的氢气泡三维结构，连底部罕见的小行星状星云也清晰可见。

安妮·莫德图像创新奖

• 作品：《宜居行星解剖图》
• 摄影师：Sergio Díaz Ruiz（西班牙）
• 简介：通过科学数据的色彩映射，创作出熟悉而陌生的地球图像，深刻揭示了地球已遭受的环境破坏，强调了保护地球的紧迫性。

青少年组

• 作品：《NGC 1499，多尘的加州》
• 摄影师：Daniele Borsari（意大利）
• 简介：以惊人的平衡感捕捉了星云、大气层气体以及光线、构图和结构的完美结合，展现了新一代天文摄影师的无畏与才华。

文章标题：Django and Postgres for the Busy Rails Developer

本文是一位经验丰富的Rails开发者在使用Python、Django和PostgreSQL后，对两者在数据库相关部分进行的对比总结。作者并非要转投Django，而是分享其使用体验。

核心对比点如下：

1. 语言与工具链

   • 运行时管理：Ruby使用rbenv，Python使用pyenv，两者用途和命令相似。
   • 依赖管理：Rails使用Bundler（Gemfile），Django团队使用poetry（pyproject.toml），命令（如poetry install vs bundle install）和锁文件概念类似。
   • 代码风格与检查：Rails常用RuboCop或standardrb。Django团队使用的ruff集格式化与检查于一体，速度快，易用性好。

2. PostgreSQL适配器

   • Rails使用pg gem。
   • Django使用psycopg2库。作者还用它创建了一个包装类，用于直接执行SQL查询（如查询Postgres系统目录）。

3. 迁移机制

   • Rails：开发者先生成一个迁移文件，再在文件中编写create_table等Ruby代码来描述变更。
   • Django：开发者首先修改models.py文件（定义模型属性及数据库细节，如数据类型、索引等）。然后运行python manage.py makemigrations命令，自动生成迁移文件。最后通过python manage.py migrate应用迁移。作者认为在快速迭代模型时，Django的这种方式（先改模型再生成迁移）与Rails一样高效，甚至更优。

4. 交互式控制台（REPL）与数据库客户端

   • 两者都提供REPL：Rails用rails console，Django用python manage.py shell（但需手动导入应用代码）。
   • 两者都提供数据库客户端命令：Rails用dbconsole，Django用dbshell，连接Postgres时均启动psql。

5. 项目结构

   • Django严格区分“项目”和“应用”概念。作者示例中项目为booksproject，应用为books。

6. 模型定义与查询

   • 模型定义：在Django的models.py中定义（如Author, Publisher, Books），可指定数据库模式。
   • 查询示例：Model.objects.filter()，Model.objects.first()，Model.objects.all()。
   • 创建对象：使用Thing.models.create(attr1=val, attr2=val)。

7. 迁移安全与DDL预览

   • 迁移安全：两者框架默认均不包含“安全”迁移概念（如PostgreSQL中默认不会并发创建索引）。需借助第三方库（如Rails的Strong Migrations）增加安全性。
   • DDL预览：Django可通过python manage.py sqlmigrate <app> <migration_number>命令预览迁移将生成的SQL DDL语句，而Rails默认不显示。Django默认使用IDENTITY列作为主键。

8. 示例资源

   • 作者提供了一个小型Django项目仓库（booksproject）作为参考，展示了基本的作者、出版商、书籍模型以及Postgres配置（自定义模式、用户）。
   • 作者还维护了一个django-tips页面用于收集提示。

结论：作者在享受使用Python、Django和Postgres的同时，并未打算从Rails和Ruby转换。文章旨在分享其作为Rails开发者对Django在数据库方面工具、工作流和特性的观察与比较。

Devin AI 正式上线发布

Cognition 团队宣布其人工智能软件工程助手 Devin 现已正式上线，面向工程团队提供服务，月费500美元起。该产品无坐席数量限制，包含 Slack 集成、IDE 扩展和 API 访问权限，并提供由 Cognition 工程团队负责的上手指导与支持。所有工程团队均可通过 app.devin.ai 开始使用。

适用场景与最佳实践

虽然 Devin 是一个通用工具，但团队建议从以下方面开始使用：

• 处理小型前端错误和边界情况（在 Slack 线程中提及 Devin）
• 为积压任务创建拉取请求草案（在每天开始时将待办事项分配给 Devin）
• 执行有针对性的代码重构（使用 VSCode 及其分支的 Devin IDE 扩展，指明需要编辑或升级的代码部分）

Devin 已在构建集成、迁移和维护文档等方面帮助了众多团队。为获得最佳效果，建议：

• 分配您自己也知道如何完成的任务。
• 告知 Devin 如何测试或检查其工作成果。
• 将会话控制在约3小时以内，并拆解大型任务。
• 提前提供详细需求。
• 通过在聊天中提供反馈、接受建议的“知识”或手动添加自己的“知识”来“指导”Devin。

工作方式

• Slack 集成：Slack 是启动 Devin 会话的主要界面，可通过提及 @devin 来快速分配小型任务和修复错误。Devin 完成工作后会自动发送消息通知，开发者可随时审查其创建的拉取请求。Devin 也会自动回应 GitHub 拉取请求评论。
• IDE 扩展：通过 ⌘ G 可从 IDE 直接将异步工作移交给 Devin。Devin 扩展（VSCode 及其分支的测试版功能）允许开发者直接在 IDE 中检出 Devin 的拉取请求，并审查、接受 Devin 编写的代码。

参与开源项目示例

为展示 Devin 的实际能力，团队分享了其在多个知名开源项目中解决问题的会话记录。虽然 Devin 通常需要指导，但这些例子展示了其如何加速工作流程。主要案例包括：

• Anthropic MCP：Devin 识别了用户报告问题的原因，通过阅读规范理解了“能力协商”，并在浏览器中进行了端到端测试。维护者根据 PR 反馈进行了后续修复。
• Zod：为流行的 Zod 库添加新功能。Devin 与用户协作规划、跨文件实现功能并编写测试。尽管合并冲突需要手动解决，但团队对其表现印象深刻。
• Google Go-github：修复了一个关于 HTTP 错误时也传播响应对象的问题。此类琐碎任务对人类工程师来说很麻烦，因为测试工作量常大于修复本身。Devin 经过几次迭代后完成，主要节省时间之处在于其编写并运行了单元测试。
• Llama Index：修复了 Anthropic 分词器实现未正确遵循协议的错误。Devin 首次尝试即找到正确修复方案并编写了单元测试。
• Karpathy’s nanoGPT：处理了一个单行代码更改。Devin 通过编写临时测试脚本对其进行了妥善测试。

获取与咨询

用户即日起可通过 app.devin.ai 开始使用 Devin。有关 Devin 企业版的更多信息，可联系其销售团队。

Trillium TPU 正式发布

谷歌第六代、性能最强的 TPU（张量处理单元）——Trillium 现已面向所有谷歌云客户正式发布。它是谷歌云 AI 超级计算机 的核心组件，旨在为大规模、多模态 AI 模型的训练、微调和推理提供高效、强大且可持续的基础设施。该基础设施已用于训练谷歌最先进的 AI 模型 Gemini 2.0。

核心优势与关键提升

相比上一代产品，Trillium 实现了全方位的性能飞跃：

• 训练性能 提升超过 4 倍。
• 推理吞吐量 最高提升 3 倍。
• 能效 提升 67%。
• 单芯片峰值计算性能 提升高达 4.7 倍。
• 高带宽内存 (HBM) 容量和芯片间互连 (ICI) 带宽 均翻倍。
• 支持在单一 Jupiter 网络架构中部署 10 万颗 Trillium 芯片。
• 性价比 显著提升：训练性能/美元最高提升 2.5 倍，推理性能/美元最高提升 1.4 倍。

技术架构与软件生态

Trillium TPU 是 AI 超级计算机 架构的关键硬件。该架构整合了性能优化的硬件、开源软件、领先的机器学习框架（如 JAX、PyTorch、TensorFlow）和灵活的消费模式。随着 Trillium 发布，其软件层也得到增强，包括 XLA 编译器的优化，以在大规模训练、微调和推理中实现领先的性价比。

其硬件创新包括利用海量主机 DRAM 进行计算卸载，与 HBM 协同工作，进一步提升效率。强大的 Jupiter 数据中心网络 提供高达 13 Petabits/秒的二分带宽，支持将单个分布式训练任务扩展到数十万加速器。

针对各类 AI 工作负载的优势

1. 扩展 AI 训练工作负载

Trillium 具备近乎线性的扩展能力。测试表明，在预训练 GPT3-175B 时，部署 12 个 pod（3072 芯片）的扩展效率达 99%，24 个 pod（6144 芯片）时仍能保持 94% 的效率。在训练 Llama-2-70B 时，从 4 个 slice 扩展到 36 个 slice 也能维持 99% 的效率。其扩展效率显著优于前代产品（如 v5p）。

2. 训练大型语言模型

• 密集型 LLM：训练 Llama-2-70b 和 GPT3-175b 的速度比前代 Cloud TPU v5e 快最多 4 倍。
• 混合专家模型：训练 MoE 架构模型的速度比 Cloud TPU v5e 快最多 3.8 倍。
• 主机 DRAM 容量是 v5e 的 3 倍，通过计算卸载，在训练 Llama-3.1-405B 等模型时，模型浮点利用率 (MFU) 性能可提升超过 50%。

3. 推理性能

Trillium 在图像扩散和密集型 LLM 推理上均提供最佳性能。

• 对于 Stable Diffusion XL，离线推理吞吐量比 Cloud TPU v5e 高 3.1 倍，在线推理高 2.9 倍。
• 对于 Llama2-70B，推理吞吐量几乎翻倍。
• 引入了集合调度功能，通过智能管理多个 TPU slice 副本，提升推理工作负载的整体可用性和效率。

4. 嵌入密集型模型

通过第三代 SparseCore（针对动态、数据相关操作优化的数据流处理器），Trillium 将嵌入密集型模型的性能提升了 2 倍，并将 DLRM DCNv2 的性能提升了 5 倍。

5. 提供优异的性价比

Trillium 在训练和推理的性价比上表现卓越。对于训练密集型 LLM（如 Llama2-70b），其性价比比 Cloud TPU v5e 高 2.1 倍，比 v5p 高 2.5 倍。对于图像生成任务，其成本也显著降低。

客户应用与展望

已有客户如 AI21 Labs 在使用 Trillium 加速其语言模型（如 Mamba 和 Jamba）的开发。Trillium 代表了谷歌云 AI 基础设施的重大进步，为研究人员和开发者提供了突破 AI 创新边界、以前所未有的效率和规模构建强大解决方案的可能。

AI模型在消费级硬件上实现近乎即时图像创建

萨里大学以人为本人工智能研究所（PAI）宣布，其下属SketchX实验室研发的突破性AI模型 NitroFusion，能够在用户输入文本的同时，使用仅需普通、经济的硬件设备生成图像。该模型在全球尚属首例，且已由开发团队开源，这从根本上改变了创意专业人士获取AI图像生成技术的门槛。

核心突破与优势

1. 实时图像生成：NitroFusion是该领域首个实现“边输入文本边生成图像”的模型，支持快速迭代、增强控制并优化实验过程。
2. 硬件要求低：仅需一块消费级显卡即可运行，无需依赖昂贵的专业计算资源，使个人创作者、小型工作室及教育机构能够以可负担的成本使用高级AI功能。
3. 节能与可持续性：该技术大幅降低了能耗，提升了可持续性。
4. 完全开源与无云依赖：模型开源，无需订阅费用或依赖云服务，推动全球范围内的创新、适配与多样化应用。

技术应用与获取

该技术已通过官方项目网站公开，并提供完整文档与社区支持资源。相关技术论文已在Arxiv平台发布。

开发团队背景

NitroFusion由萨里大学PAI研究所旗下的 SketchX 实验室开发。SketchX是全球领先的计算机视觉与人工智能研究团队，专注于突破性AI技术在创意与交互应用领域的创新。PAI研究所则以“以人为本”为核心理念，致力于开发伦理、负责且包容的AI技术，整合了萨里大学在视觉、语音、信号处理、计算机科学等多领域的跨学科专长。

由于提供的文章内容显示为“403 ERROR”错误页面，无法访问实际的文章正文。因此，无法对文章内容进行总结。根据标题，可以知道这涉及 WPEngine, Inc. 对 Automattic 公司提出初步禁令动议的法律诉讼，但无法获取具体的诉讼理由、双方主张或法院裁决等详细信息。

使用GPU的C库概述

基本介绍

GPU C库允许在GPU上直接运行C标准库（libc）或数学库（libm）函数。目前并非所有C标准函数都支持GPU，需参考支持函数列表。

该库支持两种主要使用模式：

1. 作为卸载语言（如OpenMP、CUDA、HIP）的补充库，提供标准系统工具。
2. 将GPU作为宿主目标，直接为GPU编译C/C++程序，主要用于GPU上导出函数的测试。

卸载语言使用模式

卸载语言（CUDA、HIP、OpenMP）通过将同一源文件编译为宿主和目标设备代码来工作。Clang驱动使用胖二进制格式支持标准编译流程。链接GPU运行时库可通过-Xoffload-linker选项传递参数给设备链接器作业实现。

示例编译命令：

# OpenMP
clang openmp.c -fopenmp --offload-arch=gfx90a -Xoffload-linker -lc
# CUDA
clang cuda.cu --offload-arch=sm_80 --offload-new-driver -fgpu-rdc -Xoffload-linker -lc
# HIP
clang hip.hip --offload-arch=gfx942 --offload-new-driver -fgpu-rdc -Xoffload-linker -lc

卸载语言要求使用__device__关键字（CUDA/HIP）或declare target编译指示（OpenMP）声明设备函数。LLVM C库通过编译器资源目录中的包装器头文件暴露函数接口。

OpenMP完全集成，自动处理库链接、设备接口定义和RPC服务器运行。CUDA/HIP支持较实验性，需手动链接。

直接编译模式

可直接使用C/C++为GPU创建可执行文件（类似OpenCL）。通过Clang的交叉编译支持目标GPU架构。依赖编译器内建函数获取设备标识符（如AMDGPU的__builtin_amdgcn_workitem_id_x()和NVPTX的__nvvm_read_ptx_sreg_tid_x()）。

编译示例：

# AMDGPU
clang id.c --target=amdgcn-amd-amdhsa -mcpu=native -nogpulib -flto -c
# NVPTX
clang id.c --target=nvptx64-nvidia-cuda -march=native -nogpulib -flto -c

构建特定目标

AMDGPU目标

• 支持原生特性，使用lld链接器
• 安装目录包含include/amdgcn-amd-amdhsa和lib/amdgcn-amd-amdhsa
• 必须使用-flto和-mcpu=指定子架构
• 使用amdhsa-loader工具执行程序

编译示例：

clang hello.c --target=amdgcn-amd-amdhsa -mcpu=native -flto -lc <install>/lib/amdgcn-amd-amdhsa/crt1.o
amdhsa-loader --threads 2 --blocks 2 a.out

NVPTX目标

• 二进制工具有限，使用clang-nvlink-wrapper包装链接作业
• ABI要求函数签名匹配，需传递完整的main原型
• 使用nvptx-loader工具执行程序
• 推荐使用链接时优化（LTO）

编译示例：

clang hello.c --target=nvptx64-nvidia-cuda -march=native -flto -lc <install>/lib/nvptx64-nvidia-cuda/crt1.o
nvptx-loader --threads 2 --blocks 2 a.out

关键特性

• 安装包含启动对象crt1.o处理主函数执行、全局初始化器和命令行参数
• 提供静态库libc.a和LLVM-IR位码文件libc.bc
• 编译器自动处理包含目录和库搜索路径
• 主要用于GPU单元测试和开发调试

Caten：一个实验性深度学习编译器

项目概述

Caten是一个处于早期开发阶段的实验性深度学习编译器，名称源自"Compile+AbstracTENsor"。其目标是结合tinygrad的简洁性与TVM的灵活性，并扩展AI领域的交互式编程可能性。

核心特性

1. 编译架构

• 采用惰性求值机制，可独立生成所需计算核心
• 基于RISC风格架构，将所有操作归纳为26个可组合的原生操作
• 支持通过环境变量配置编译设置：
  • BACKEND=CLANG：启用JIT编译
  • JIT_DEBUG>=2：查看调度和生成的计算核心
  • PARALLEL=8：并行编译计算图

2. 模型支持

目前已支持GPT-2等模型的运行示例：

$ BACKEND=CLANG PARALLEL=8 ./roswell/caten.ros llm-example --model "gpt2" --prompt "Hello" --max-length 100

3. 调试功能

• 在不破坏计算图的情况下，可通过proceed命令检查中间结果
• 支持通过->dot函数在浏览器中可视化计算图

技术状态

已实现功能

• 推理：支持文本生成等任务
• 模型定义：支持自定义模型结构（如MLP）
• 惰性求值：完整的计算图编译和优化

实验性功能

• 训练支持：已有基础训练循环实现，但后向调度器尚未完全成熟
• 优化器集成：支持SGD等优化器

生态与路线图

计划支持模型

1. 生成式AI：Llama3、StableDiffusion等
2. 分类模型：MobileNet、ResNet、VIT等
3. 视觉任务：CenterNet、YOLO系列

后端与运行时支持

• 当前：LISP VM、CLANG JIT、原生JIT
• 计划中：CUDA、Metal、WebGPU、OpenCL、LLVM等
• 格式支持：ONNX、GGUF（含量化）

安装与使用

依赖项

• Roswell（Common Lisp环境）
• ISL（整数集合库）
• libyaml（YAML解析）

快速开始

$ git clone git@github.com:hikettei/Caten.git
$ cd Caten
$ qlot install
$ qlot exec ros run
> (ql:quickload :caten)
> (in-package :caten-user)
> (proceed (!randn `(3 3)))

项目状态

• 早期阶段：仅开发数月，专注于构建基础库
• 不适合生产环境：明确声明"绝不要在产品中使用"
• 寻求贡献：希望社区参与功能添加、测试、文档完善等工作

总结

Caten是一个雄心勃勃的深度学习编译器实验项目，通过Common Lisp实现简洁的编译流程，目标是为AI模型提供跨多种硬件后端的统一编译支持。当前已能运行GPT-2等模型，但仍在积极开发中，未来计划涵盖训练支持、更多模型格式和硬件加速器。

文章总结了作者为解决笔记本电脑使用导致的手臂和手腕疼痛问题，历经多次迭代优化其便携式人体工学支架的历程。

迭代历程：

1. 原型1：笨重托盘：首个便携桌面原型，但体积大、重量沉，仅部分场景可用。
2. 原型2：背包可携版：为参加Recurse Center编程活动而设计。实现了便携使用，但仍偏重，且装入/取出电脑繁琐，无法放入个人随身行李袋。
3. 原型3：织物铰链版：为参加会议演讲制作。采用薄木板和织物铰链，重量轻、底座薄且模块化。但耐用性不足，铰链胶水失效，且过薄的设计导致肩部下沉，重现了神经问题。
4. 当前版本：Tray.One：解决了前几代的主要痛点。
   • 核心创新：可对半折叠，大幅提升了便携性和存放便利性。
   • 关键改进：重量极轻（不含电脑仅3.5磅）；完全展开后更符合人体工学；采用Corne键盘和Ploopy轨迹球鼠标以减少手指移动；利用魔术贴整理外设。
   • 优势：能完整放入航空随身行李袋，组装/拆卸快速（仅需操作一颗螺丝），适合旅途中随时使用。

设计与工作条件：

• 迭代过程中的部分设计灵感来源于作者生病卧床期间的思考。
• 作者拥有家庭工作室，这为快速原型制作提供了便利。他指出建立这样的环境需要时间、空间和资金的投入。
• 作者表示愿为有需要的人提供接近成本价的定制制作（仅适用于支持180度开合的笔记本电脑）。

附加项目：投影仪支架

• 为方便卧床工作（使用投影仪将画面投射到天花板），作者用边角料快速制作了一个稳固且可调节角度的投影仪支架，解决了原有放置不稳定的问题。

总结： 整个迭代过程体现了作者通过实践不断解决具体问题（便携性、人体工学、耐用性、组装效率）的思路，最终形成了目前轻便、可折叠且能有效缓解身体负担的个性化解决方案。作者欢迎交流并愿意提供帮助。

该HTML内容并非实际的文章，而是一个由Cloudflare生成的安全验证页面，用于拦截直接的自动化访问。

其核心目的是在用户（或爬虫）访问目标网页时，先进行一次安全挑战（Challenge）。页面本身内容极其简单，仅显示一条提示信息：“Enable JavaScript and cookies to continue”。

页面结构与关键技术细节：

1. 防御机制：通过<meta http-equiv="Content-Type">标签设置为noindex,nofollow，指示搜索引擎不要索引或跟踪此页面。
2. 资源加载策略：Content-Security-Policy元标签详细定义了允许加载资源的来源，主要包括challenges.cloudflare.com，这是执行安全挑战脚本的域名。
3. JavaScript挑战：页面底部的核心是一个内联JavaScript脚本。该脚本会：
   • 初始化一个配置对象window._cf_chl_opt，其中包含用于标识和验证此次挑战的令牌、参数等加密信息。
   • 动态创建一个<script>元素，其src指向Cloudflare的挑战平台（/cdn-cgi/challenge-platform/h/b/orchestrate/chl_page/v1）。
   • 通过history.replaceState修改浏览器历史记录，以便在验证完成后能跳转回原始的请求路径（/bryan-johnson-the-worlds-most-expensive-eating-disorder/）。
4. 元刷新：页面设定了360秒的meta refresh，作为备用机制，在脚本失效时尝试重新加载。

总结：这是一个典型的Cloudflare Bot Management 或 WAF的拦截页面。它的功能不是展示文章内容，而是充当一个“守门员”，通过执行客户端JavaScript验证来区分真实用户和自动化程序，验证通过后才允许访问被保护的实际文章。用户提供的原始URL路径暗示了其意图保护的文章主题可能与“布莱恩·约翰逊（Bryan Johnson）”及“世界上最昂贵的饮食失调”相关，但具体内容在此页面中不可见。

F16战斗机飞行员神经可塑性研究总结

研究目的

本研究旨在通过静息态功能磁共振成像（fMRI）技术，探究经常暴露于重力水平转换和高重力环境下的F16战斗机飞行员，其大脑功能连接（FC）是否与匹配的对照组存在差异，从而为神经可塑性提供证据。这些发现有助于理解人类大脑如何适应重力变化，对未来太空任务（如前往月球或火星）中宇航员的适应性训练具有潜在意义。

研究方法

• 被试：10名F16战斗机飞行员（平均飞行时长1025小时）与10名年龄、性别、教育水平和利手性匹配的无飞行经验的对照组。
• 数据采集：使用3T MRI扫描仪采集高分辨率T1结构像和静息态fMRI数据。
• 数据分析：
  • 全脑分析：使用内在连接对比度（ICC） 指标，评估每个体素与全脑其他体素的整体连接强度。
  • 兴趣区（ROI）分析：基于先验假设，选择了两个关键脑区作为种子点：1）右侧顶盖2区（rOP2），一个核心的皮层前庭区；2）右侧角回（AG），在抛物线飞行研究中显示连接性改变。
  • 统计分析旨在发现：1）飞行员中，脑功能连接与飞行时长的相关性；2）飞行员与对照组之间的组间差异。

主要发现

1. 功能连接与飞行经验的相关性：

   • 正相关：飞行时长越长，左侧额下回、右侧额中回和右侧颞极与全脑的连接越强。这些区域与高级认知功能（如执行控制、工作记忆、语义处理）相关，可能反映了应对复杂飞行任务的认知适应。
   • 负相关：飞行时长越长，双侧中央前回、中央旁小叶和中央后回（主要感觉运动区）与全脑的连接越弱。这可能反映了在高重力环境下对运动控制回路的优化或抑制。

2. 飞行员与对照组的组间差异：

   • 全脑连接性降低：飞行员的左侧额下回整体连接性低于对照组。进一步分析发现，该区域与内侧额上回的功能连接具体减弱，且左侧额下回属于额顶控制网络，该网络参与复杂信息处理和认知控制。
   • 前庭-视觉耦合增强：针对右侧OP2的分析显示，飞行员中该前庭皮层区与左侧视觉皮层的功能连接显著强于对照组。这可能是一种多感官再加权适应，即在前庭信号（受重力变化影响）不可靠时，大脑更多地依赖视觉信息。
   • 角回间连接增强：飞行员的右侧角回与左侧角回之间的功能连接强于对照组。角回参与多感觉整合和空间定位（如感知垂直方位），其双侧连接增强可能反映了在处理重力相关空间信息时的适应性策略。

讨论与结论

• 本研究发现，F16飞行员的大脑在功能连接模式上发生了显著改变，体现了神经可塑性。这些改变涉及：
  • 认知控制区域（如额叶区域）：适应高要求的飞行任务。
  • 多感觉整合区域（如顶盖和角回）：协调和处理来自前庭、视觉等系统的冲突信息，以应对重力水平变化。
  • 感觉运动区域：可能出现功能优化。
• 这些大脑层面的适应与飞行员在外周前庭系统（如对滚转倾斜更敏感）和行为（如模拟飞行控制更稳定）上观察到的适应一致。
• 局限性：研究设计无法完全区分观察到的差异是源于长期暴露于重力变化的后天适应，还是飞行员群体固有的先天特质。此外，未纳入行为学数据（如认知表现测试）使得对功能连接变化的具体意义解释仍属推测。
• 启示：研究结果为理解人类大脑如何适应变化的重力环境提供了新见解。这些知识未来可用于优化飞行员和宇航员的训练方案，例如通过强化特定脑区间的连接来增强适应能力。

阿尔伯克基“断箭”核事故

氢弹技术发展

• 1950年，美国总统杜鲁门下令启动氢弹研制计划。氢弹依赖核聚变反应释放能量，原理与恒星能量来源相同，但需要极高温度才能触发。
• 物理学家爱德华·泰勒受恩里科·费米启发，提出利用原子弹爆炸产生的高温引发聚变的“超级炸弹”构想。
• 1951年，数学家斯坦尼斯拉夫·乌拉姆提出通过辐射内爆压缩聚变燃料的理论，泰勒在此基础上完善，形成了“乌拉姆-泰勒设计”——采用分级辐射内爆原理。
• 1952年11月1日，首个基于该设计的装置“迈克”在太平洋恩尼威托克环礁试验成功，当量达10.4百万吨。

马克17氢弹

• 马克17是美国首批大规模部署的热核武器，基于固体燃料的“伦特”试验装置改进而成。
• 该弹体长24英尺，直径5英尺，重21吨，当量15百万吨（约相当于1000枚广岛原子弹），仅能由改装后的B-36轰炸机携带。
• 1954-1955年间生产约200枚，成为当时美国核武库中最强大的武器。

事故经过

• 时间与地点：1957年5月22日，美国新墨西哥州阿尔伯克基附近柯特兰空军基地。
• 事件：一架B-36J轰炸机（序列号52-2816）在降落过程中意外掉落一枚马克17氢弹。
• 原因：炸弹舱在降落前移除安全锁销后，因机械故障、人员误操作或飞机结构变形导致释放机构意外触发。
• 关键细节：
  • 炸弹坠落时降落伞未完全展开，以高速撞击沙漠地面。
  • 炸弹铀芯已被提前移除，未发生核爆炸，但内置的300磅常规炸药引爆，形成直径25英尺、深12英尺的弹坑。
  • 仅造成一头牧牛死亡，无人员伤亡。

后续处理

• 事故现场位于新墨西哥大学所属空地，由空军特种武器项目指挥部及爆炸物处理部队清理。
• 检测到爆炸坑内辐射水平为0.5毫伦琴/小时，污染物土壤部分清除。
• 事件被列为机密，空军对外宣称是常规炸弹事故，直至1986年相关文件解密。

历史遗产

• 马克17于1957年底逐步退役，被B-52轰炸机及更小型氢弹取代。
• 事故现场位于阿尔伯克基梅萨德尔索尔地区，无标识，仅供公众探索。
• 马克17弹体陈列于阿尔伯克基核科学与历史博物馆，其他残骸分布于美国多处军事博物馆。

事故影响：此次事件是冷战时期核武器运输安全问题的典型案例，凸显了早期核武管理的风险，但因未引发核爆未造成大规模后果。