内容摘要：Extra Big Ass Intelligence

该内容描述了一个名为“Extra Big Ass Intelligence”的概念，其核心要点如下：

• 核心属性：宣称其为“100% 非人工”（100% ARTIFICIAL-FREE）。
• 定义：将其定义为“纯无铅超级智能”（PURE UNLEADED SUPER INTELLIGENCE, SI）。
• 建立依据：声称该智能是通过“行政命令”（EXECUTIVE ORDER）设立的。

Apple Pass Designer 简介

Apple Pass Designer 是一款旨在简化 Apple Wallet 卡券（Passes）设计与预览的工具，适用于从小型健身中心、音乐场馆到大型航空公司及连锁咖啡店等各类业务场景。

核心设计功能

• 模板与自定义：用户可以利用 Apple 提供的预设模板，或使用自定义模板来体现品牌个性。设计者可以在外部设计工具中制作 Logo、背景或条带图像，随后将其导入 Pass Designer 完成设计。
• 实时预览：工具提供实时预览功能，展示卡券在 iPhone 和 Apple Watch 上的呈现效果。该预览采用与 iOS 和 watchOS 相同的渲染技术，确保设计效果与用户设备上的实际显示完全一致。
• 视觉与布局定制：
  • 颜色调整：可轻松修改卡券的背景色、前景颜色及标签颜色。
  • 自适应布局：支持利用 Apple Wallet 最新特性的先进设计，同时也兼顾向后兼容的卡券布局。
  • 标准字段：每种卡券类型均包含用于显示信息的标准字段，用户可以直接在工具内编辑这些字段的内容。
• 实时验证：在编辑过程中，Pass Designer 会自动验证卡券，并针对缺失的必要键值或异常定义发出警告。

语义化功能 (Semantic Tags)

针对登机牌和活动门票，语义标签允许添加结构化数据（如活动日期、场馆地点或航班详情），从而驱动系统的深度集成功能，包括：

• Siri 建议
• 日历集成
• 地图导航

用户可以在 UI 中直接编辑语义标签，并支持将“语义化卡券”与“非语义化卡券”进行并排对比。此外，工具能够根据语义数据自动生成不依赖语义标签的向后兼容结构，以确保卡券在不支持该功能的设备上仍能正常运作。

下载要求

Pass Designer Beta 版要求系统为 macOS 27 或更高版本。用户需使用 Apple Account 登录下载，并需完成免费注册及接受 Apple Developer Agreement。

Kolibri 模型技术摘要

Kolibri 是由 Aleph Alpha 开发的一种针对德语和英语设计的开源权重（open-weight）大语言模型（LLM）。该模型采用混合专家架构（Mixture of Experts, MoE），旨在通过“主权”设计平衡创新与合规性，特别针对欧盟 AI 法案进行了优化。

1. 基本规格

• 参数量：总参数量为 781 亿，但在处理每个 token 时仅激活约 34.6 亿参数（约 4.4%）。
• 语言能力：专注于德语和英语。
• 上下文窗口：原生支持 262,144 个 token，并经过测试可支持高达 1,048,576 个 token。
• 训练数据：基于约 24 万亿 token 进行训练，其中超过 20% 为德语。
• 许可协议：权重和配置文件采用 Apache 2.0 协议。

2. 核心技术架构与创新

混合专家架构 (MoE)

Kolibri 拥有 50 个层，每层包含 384 个专家和一个共享专家。通过路由器（router）机制，每个 token 仅由 6 个专家处理。这种设计使得模型在拥有 78B 参数规模的知识容量的同时，保持了约 3.5B 参数规模的计算效率。

高效的德语分词器 (UniBPE)

针对德语复合词较长的特点，Kolibri 开发了名为 UniBPE 的新算法。相比 GPT-5 的分词器，Kolibri 在处理德语法律文本时所需的 token 数量减少了约 15%，这提升了模型在相同上下文窗口内处理德语文本的能力。

长上下文处理

模型采用了滑动窗口注意力机制（Sliding-window attention），其中 50 层中有 40 层仅关注前 512 个 token，每 5 层中有一层使用全局注意力。这种结构有效降低了处理百万级长上下文的计算成本。

德语原生推理

不同于许多在英语思维基础上进行翻译的模型，Kolibri 通过大规模德语推理数据的训练，实现了在德语提示词下的原生德语推理能力。此外，用户可以通过设置 reasoning_effort 参数（none, low, medium, high）来控制模型的思考深度。

幻觉抑制 (Merlin-Arthur 协议)

为了提升检索增强生成（RAG）的效果，模型采用了 Merlin-Arthur 协议进行训练。该协议通过模拟“隐藏证据”的博弈过程，训练模型在无法从给定文档中找到答案时主动承认“不知道”，从而显著降低了幻觉率。

3. 性能表现

• 优势领域：

  • 数学推理：在 AIME 2025 测试中，其德语和英语数学得分表现优异，超越了同规模的其他 MoE 模型。
  • 长文档理解：在处理长上下文（如 100 万 token）和企业私有文档检索方面具有强竞争力。
  • 主权与合规：由于在德国和芬兰的欧洲基础设施上训练，且符合欧盟法律，适合对数据隐私、主权和知识产权有严格要求的政企客户。

• 局限性：

  • 知识存储：作为 MoE 模型，其闭卷测试（即不依赖文档的常识问答）表现弱于密集型（dense）模型。
  • 特定任务：多轮工具调用（Tool calling）和编程能力（Coding）较弱。
  • 语言局限：仅限于德语和英语。

4. 部署要求

由于需要加载全部 78B 参数，模型对显存要求较高：

• 硬件需求：至少需要约 78 GB 的 GPU 显存（例如 2 张 NVIDIA A100/H100 80GB，或单张 H200/B200/B300）。
• 软件支持：需要使用 Aleph Alpha 提供的专用 vLLM 插件进行推理。

Zig v0.17.0 发布摘要

Zig v0.17.0 是一个重大的更新版本，涵盖了为期 5 个月的开发工作，主要集中在构建系统的重构、链接器的增强、增量编译的实现以及语言稳定性的推进。

核心变更

1. 构建系统 (Build System) 重构

构建系统经历了大规模的架构调整：

• 进程分离：将配置过程（Configurer）与构建执行过程（Maker）分离。这种设计使得 zig build 在修改 build.zig 脚本时无需重新构建 Maker 执行文件，提高了效率。
• Build Server Protocol (BSP)：引入了构建服务器协议，允许 IDE 等第三方工具监控构建图、查看步骤状态并请求执行特定步骤。
• 缓存系统重构：缓存改用二进制格式以提升性能，并引入了目录支持和元数据模式（基于大小、inode 或修改时间触发缓存失效）。同时引入了“配置缓存污染（Configure Cache Poisoning）”概念，用于处理配置逻辑中的副作用。
• 包管理转移：所有包管理功能（如 zig fetch、zig init 等）已从编译器移至构建系统中。

2. 编译器与链接器 (Compiler & Linker)

• 增量编译 (Incremental Compilation)：得益于新 ELF 链接器的改进，目前在 x86_64-linux 平台上已能实现高效的增量编译。
• 链接器增强：
  • ELF 链接器：取得了重大进展，实现了对 x86_64 和 SPARC64 的完整支持，并支持静态/动态库生成、DWARF 调试信息等，是实现增量编译的关键。
  • COFF 链接器：增强了对对象文件、归档文件、TLS 以及 MSVC libc 的支持。
  • SPIR-V 链接器：经过重写，支持增量编译并能链接外部 .spv 文件。
• 后端进展：SPIR-V 后端实现了多线程化；Loongarch 后端进入实验阶段；WebAssembly 后端在行为测试中已达到与 LLVM 后端 100% 的一致性。

3. 语言变更 (Language Changes)

• 语言稳定性：为向 1.0 版本迈进，进行了大量的提案讨论与决策。
• @bitCast 语义变更：重新定义为重新解释值的“逻辑位表示”，使其具备字节序无关性（Endian-agnostic）。需要注意的是，这可能破坏涉及数组或向量类型的现有代码。此外，不再允许在 @bitCast 中使用 extern 类型。
• 新增内置函数：
  • @backingInt 和 @fromBackingInt：用于替代已弃用的枚举转换函数。
  • @SpirvType：用于处理 SPIR-V 特有的类型（如 sampler、image）。
  • @divCeil：执行向正无穷方向取整的整数除法。
• 语法移除：移除了数组乘法语法 (**)、void{} 语法、i0 类型以及 errdefer 的捕获功能。

4. 标准库 (Standard Library)

• 内存管理：
  • 引入了线程安全的 SafeAllocator，旨在替代 DebugAllocator，提供更严格的内存检查。
  • 重构了 StackFallbackAllocator，现在通过显式传递缓冲区来工作。
• API 更新：ArrayList 增加了指针稳定性；std.zon.parse 经过重构；fmt.allocPrint 移至 mem.Allocator。
• 弃用与重命名：大量 API 进行重命名或弃用（例如 std.builtin 转向 std.lang），以保持命名的一致性。

5. 目标平台支持 (Target Support)

• 增强了对 aarch64-openbsd、aarch64-freebsd 和 aarch64-netbsd 的 CI 支持。
• 提供了对 Loongarch、SPARC64 以及多种游戏机平台（如 Switch, GBA, WiiU）的支持。
• 改进了对 AArch64 栈回溯和指针认证的处理。

工具链更新

• 升级至 LLVM 22.1.8。
• 更新了 musl (1.2.5)、glibc (2.44) 以及 macOS/Linux/OpenBSD/NetBSD 的系统头文件。
• 新增了 zig objdump 工具，用于链接器的快照测试。

国际刑事法院法官受美国制裁的影响及背景

个人生活受到严重干扰 加拿大籍国际刑事法院（ICC）法官金伯利·普罗斯特（Kimberly Prost）表示，美国对其实施的制裁已导致其日常生活陷入困境。由于美国企业的制裁效力以及企业的“过度合规”行为，普罗斯特失去了包括Amazon、Google、Apple在内的许多科技服务（例如智能设备Alexa无法响应），其在荷兰和加拿大的信用卡被注销，银行转账也受到极大限制。此外，即使是法国保险公司AXA也出于商业决策，拒绝为其支付医疗保险理赔，尽管该公司在法律上并无义务遵守美国制裁。

制裁的诱因与争议核心 普罗斯特的制裁源于特朗普政府的一项行政命令，该命令旨在针对涉及阿富汗或以色列/加沙案件的ICC官员。普罗斯特指出，其个人案件源于六年前她在上诉分庭批准了一项关于阿富汗战争罪行（涉及塔利班和ISIS）的调查请求。她强调，她的角色仅属于司法授权（类似于法官批准搜查令），而非实际开展调查，且调查中涉及美国的极小部分成分随后已被搁置。她明确表示，自己并未参与任何涉及以色列与加沙的案件。

对国际司法的潜在威胁 普罗斯特认为，此类制裁的本质是试图通过行政手段干预司法独立，迫使法官根据美国政府的意愿而非事实和法律进行裁决。这种对抗态势正在扩大：预计到2026年8月，将有9名ICC法官以及多名检察官和工作人员受到美国制裁。特朗普政府甚至曾表示，将通过“全政府行动”来“系统性地拆解”ICC。

法律反击与工作现状 针对这些制裁措施，普罗斯特已与其他两名ICC法官在纽约联邦法院提起诉讼，起诉特朗普及相关政府官员，认为这些措施是非法的。尽管个人生活受到诸多限制，普罗斯特表示她绝不会放弃法官职位，并将继续保持客观、独立地履行司法职责。

ds4 (DwarfStar 4) 本地大模型推理引擎概览

ds4 是由 Redis 作者开发的一种高性能、轻量级的 C 语言本地推理引擎，专门设计用于在配备高内存的 Mac（Metal）、NVIDIA（CUDA）及 AMD（ROCm）设备上运行前沿的开源权重模型。

核心功能与支持

• 支持模型：支持 DeepSeek V4/V4.1 Flash、GLM 5.x 以及 Qwen3.8 Flash Next 的文本与视觉模型（需采用 GGUF 布局及非对称 2-bit + imatrix 加载方式）。
• 三大交互接口：
  • ./ds4：交互式命令行界面（CLI），用于直接对话。
  • ./ds4-server：本地 API 服务器，兼容 OpenAI 和 Anthropic 接口协议。
  • ./ds4-agent：原生编程智能体，用于持久化的编码会话。

关键技术特性

• 非对称 2-bit 量化 (Asymmetric 2-bit Quantization)：针对混合专家模型（MoE）设计，通过压缩路由专家（routed experts）并保持关键共享路径的精度，使巨量参数模型能够在消费级或专业级高内存机器上高效运行。
• KV 缓存磁盘化 (KV Cache as a Disk Citizen)：支持将长文本前缀缓存保存至 SSD，并可通过 Prompt Hash 进行恢复。这使得在程序重启后无需进行全量预填充（re-prefill），显著提升效率。
• 高性能特性：
  • 支持 SSD 流式传输（SSD Streaming）与张量并行（Tensor Parallelism）。
  • 支持会话批处理（Session Batching）、DSPARK + MTP 以及视觉输入。

运行环境与性能表现

• 硬件适配：在 128GB 内存的设备上表现优异。例如，在 M5 Max (128GB) 上，运行 DeepSeek V4 Flash Q2 模型时，2,048 token 上下文下的生成速度可达 39.4 T/S，预填充速度达 557 T/S。
• 部署流程：用户通过 Git 克隆仓库，运行模型下载脚本，并根据自身硬件后端（如 make cuda-spark）进行编译即可使用。

总结

ds4 通过创新的量化技术和缓存管理策略，解决了超大规模模型在本地运行时的内存与计算瓶颈，为用户提供了从命令行对话到 API 服务及自动化智能体的完整本地 AI 推理栈。

Kolibri 模型发布概述

Aleph Alpha 发布了名为 Kolibri 的新型开源权重模型。这是一个专为受监管领域（如公共管理、工业和航空航天）设计的英德双语混合专家（MoE）Transformer 模型。

核心技术规格

• 参数量：总参数 78B，每次推理激活参数 3B。
• 上下文长度：支持高达 100 万（1M）token 的上下文。
• 许可协议：采用 Apache 2.0 协议，可在 Hugging Face 下载。
• 主要能力：擅长数学、编程、逻辑推理、代理行为（Agentic behavior）以及长文本处理。

核心优势与定位

1. 主权与合规性（Sovereignty & Compliance）

Kolibri 强调“主权”概念，结合了开发过程的透明度和部署的自由度：

• 供应链完整性：从数据采集到预训练及评估，整个流程完全自主掌控。
• 合规设计：从底层构建时便考虑了欧盟《人工智能法案》（EU AI Act）、GDPR 以及版权法。
• 自主部署：模型规模适中，允许客户在本地（on-premise）运行，无需将敏感数据发送至第三方服务。

2. 专业化性能（Specialization）

通过在特定垂直领域（如德国公共部门、航空、汽车、半导体等）的专用评估集上进行迭代，Kolibri 在这些领域的表现显著优于通用模型。其设计目标是在性能与部署成本之间达到最优平衡（帕累托前沿）。

3. 深度双语优化

不同于仅通过翻译引入德语的模型，Kolibri 是原生双语设计：

• 数据构成：预训练 token 中德语占比达 21.3%。
• 分词器优化：采用了名为 UniBPE 的新型分词训练方法，能够更好地处理德语的复杂形态（如复合词），从而实现比竞品更高的压缩率和更快的推理速度。

技术实现与开发流程

Model Factory（模型工厂）

Aleph Alpha 通过“代码即流水线”的模式实现了极高的迭代速度。通过构建自动化的训练流水线，团队在三个月内完成了从 Kolibri Origin（30B 参数）到 Kolibri（78B 参数）的跨越式升级，并大幅提升了训练数据的规模（从 7.5T 增加到 20T tokens）。

架构特性

• 混合专家架构 (MoE)：采用 384 个较小的专家，而非少数大型专家，以提升性能。
• 注意力机制：结合了滑动窗口注意力（512 token）与每 5 层一次的全量注意力机制，平衡了计算效率与长文本处理能力。
• 推理模式控制：用户可以根据任务复杂度，在“无、低、中、高”四种推理努力等级之间进行切换，以权衡成本、延迟与质量。

减少幻觉（Grounding）

为了解决 LLM 常见的幻觉问题，Kolibri 引入了 Merlin-Arthur 协议：

• 主动弃权：模型经过专门训练，在上下文中缺乏足够信息时会选择回答“我不知道”，而非猜测。
• 合成负样本训练：通过自动化生成“剥离关键证据”的合成数据，训练模型识别信息的缺失，从而增强事实对齐能力。

部署建议

Kolibri 支持通过 aleph-alpha-inference 软件包结合 vLLM 进行部署。建议使用指定的推理解析器以启用推理与工具调用功能，并可通过配置参数扩展至 104.8 万 token 的上下文长度。

Muse Gadgets 概述

Muse Gadgets 是一系列开源的 DIY 设备项目，允许用户通过编程现有的硬件（如 ESP32 开发板或配备 SDK 的 Raspberry Pi）来构建自定义设备。用户可以将 Muse 连接到显示器、按钮、传感器、执行器等各种外设。

核心技术架构

Muse 提供两套主要的软件开发工具包（SDK）以支持不同的硬件平台：

• ESP32 Device SDK：用于连接 ESP32 开发板，通过扩展屏幕、音频输入/输出或传感器来增加功能。
• Linux Device SDK：旨在将 Raspberry Pi 或其他 Linux 设备转化为 Muse 插件，使其能够处理系统管理任务或集成 Home Assistant。

开源与社区

• 开源属性：所有的设备 SDK 和固件均在 GitHub 上开源，采用 Apache 2.0 许可协议，用户可以基于此进行二次开发或贡献改进。
• 社区支持：用户可以通过 Discord 社区进行交流、寻求支持并分享自己的定制化作品。

硬件应用示例

项目展示了多种基于不同硬件的实现方式，涵盖了从微型设备到 Linux 系统的多种形态：

• Linux/高性能类：
  • Raspberry Pi 5：用于实现与 Home Assistant 及其他 Linux 应用的深度集成。
• 显示与交互类：
  • Waveshare ESP32-S3-Touch-AMOLED：配备 1.75 英寸圆形 AMOLED 触摸屏、扬声器、麦克风及电池，支持语音通话。
  • Seeed reTerminal E1002：利用彩色电子墨水屏显示早间简报、提醒或购物清单。
  • M5Stack StickS3：口袋大小的设备，带有状态显示屏和按键。
  • AiPi Lite：小型桌面交互设备，支持通过按键进行语音通话并在彩色屏幕上显示图片。
  • IdeaSpark ESP32：配备 1.9 英寸彩色显示屏，用于直观查看设备状态。
• 特定功能类：
  • Home Assistant Voice Preview Edition：配备扬声器、麦克风和 LED 灯环，专注于语音交互。
  • Muse TV Stick（即将推出）：通过 HDMI 接口连接电视，实现大屏交互。

macOS 全磁盘访问权限（Full Disk Access）更新说明

背景与问题

为了确保备份应用等软件能够正常运行，macOS 提供了“完全磁盘访问权限”（Full Disk Access），该权限可以绕过大部分旨在保护用户隐私的数据控制机制。然而，目前部分开发者正在滥用这一权限，在用户未能充分理解风险的情况下，获取包括文件、邮件、信息及浏览历史在内的系统全面数据。对于通信类应用而言，这种权限的使用还可能危及用户通信对象的隐私。

风险趋势

随着 AI 智能体（AI agents）的能力增强且自主性不断提升，此类高权限访问所带来的安全风险也将随之大幅增长。

更新措施

为应对上述安全挑战，Apple 将引入额外的控制机制。未来，用户只有在执行“非常明确的操作”后，才能授予应用这种极高水平的访问权限。Apple 旨在确保用户在授予此类权限前，能够清晰地了解潜在风险，从而针对自身的数据和隐私做出知情的决策。

Cloudflare OHTTP Gateway 产品概述

Cloudflare 推出了全新的 OHTTP Gateway，旨在帮助开发者通过 IETF 标准——Oblivious HTTP (OHTTP)，在应用层实现更高水平的用户隐私保护。

OHTTP 的核心原理

传统的客户端-服务器交互会暴露用户的 IP 地址和 TLS 指纹，使用户身份与请求内容关联。OHTTP 通过引入两个独立运行的环节来打破这种关联，实现“双盲”隐私模型：

• 中继 (Relay)：接收客户端请求，剥离客户端标识（如 IP 地址）后转发加密请求。中继仅知晓用户身份，不知请求内容。
• 网关 (Gateway)：接收来自中继的加密请求并进行解密，随后将明文 HTTP 请求转发给应用服务器。网关仅知晓请求内容，不知用户身份。

由于中继和网关由互不串通的第三方运营，没有任何单一实体能同时掌握用户的身份信息和请求数据。

Cloudflare OHTTP 产品矩阵

为了提供更灵活的架构选择，Cloudflare 对其产品线进行了调整，将原有的 "Privacy Gateway" 更名为 Cloudflare OHTTP Relay。目前开发者有两种主要方案：

1. 使用 Cloudflare OHTTP Relay + 自建 Gateway：适用于应用服务器托管在 Cloudflare 之外，且具备自行构建和运维安全、高性能网关能力的客户。
2. 使用 Cloudflare OHTTP Gateway + 第三方 Relay：适用于应用服务器已托管在 Cloudflare（如使用 CDN 或 Workers）的客户，或希望通过托管服务降低延迟和运维成本的客户。

Cloudflare OHTTP Gateway 的优势

• 降低运维难度：构建高性能的 OHTTP 网关具有挑战性，Cloudflare 提供即插即用的托管服务，支持自动扩展。
• 低延迟体验：利用 Cloudflare 的 Anycast 全球边缘网络，减少中继与网关之间的跳转延迟。若用户已使用 Cloudflare CDN，解密与解析过程可在同一边缘节点完成。
• 简化集成：开发者只需在特定端点（/.well-known/ohttp-gateway）启用功能，即可开始接收 OHTTP 流量。

技术实现与安全性

• 请求处理：支持标准 OHTTP 和 Chunked OHTTP（推荐使用，以实现增量处理并提升性能）。网关会拦截请求、解密、发起子请求至原站，并封装响应返回客户端。
• 密钥管理：网关全权负责 HPKE（混合公钥加密） 密钥的管理，并通过特定的 GET 请求向客户端提供公钥。
• 中继身份验证：利用 Cloudflare Access 在请求解密前进行身份验证，允许通过互操作 TLS (mTLS)、静态服务凭证或自定义逻辑来保护网关免受滥用。
• 隐私模型保护：为严格遵守 OHTTP 的“分离信任”原则，防止 Cloudflare 同时掌握身份和内容，网关会拒绝解密任何来自 Cloudflare Workers 或 Cloudflare 代理主机的请求。

开发者入门建议

开发者实现 OHTTP 方案时需完成以下步骤：

1. 实现 OHTTP 客户端：参考相关标准库。需注意 OHTTP 仅保护网络层隐私，不处理请求体内部数据，开发者应避免在请求体中发送敏感信息（如邮箱、用户名）。
2. 部署/选择中继：中继需运行在独立的基础设施上，并能向用户证明其不会审计包含客户端标识的日志。
3. 测试与调试：使用 Cloudflare 开源的 pvcli 工具进行测试。

文章摘要：对“核电站导致癌症”研究方法论的批判性分析

本文针对哈佛大学 T.H. Chan 公共卫生学院研究人员（Alwadi 等人）发表的一系列关于“居住在核电站附近会增加癌症风险”的研究提出了严厉批评。作者认为，这些研究在方法论上存在根本性缺陷，其结论是毫无意义的统计学谬误。

核心争议与研究背景

Alwadi 等人发表了多篇论文，声称在马萨诸塞州及全美范围内，居住在核电站附近的居民表现出更高的癌症发病率和死亡率。他们的研究方法是构建一个“接近度评分”（proximity score），根据居民距离核电站的远近（半径可达 120 至 200 公里）来设定权重，并利用回归分析来推算“归因死亡人数”。

方法论的主要缺陷

作者指出，该研究存在以下致命问题：

1. “接近度”不等于“暴露量”：研究仅以地理距离作为衡量标准，而非实际的辐射剂量。作者强调，即使是直接接触辐射的核电站工作人员，其接收到的年度剂量通常也极低（仅为职业限制的 2% 甚至更低）。如果工作人员的剂量都微乎其微，居住在数十公里外的居民理论上不可能接收到任何可测量的辐射。
2. 缺乏因果机制：这些研究属于“生态学研究”（ecological studies），仅能显示统计学上的关联，无法证明因果关系。研究人员试图通过构建“暴露路径”来解释结果，但这在物理学和实际监测数据面前站不住脚。
3. 研究范围过大：研究涵盖的半径范围（高达 200 公里）过于广泛，这使得研究对实际辐射暴露的敏感度极低，无法反映真实的物理现实。

验证实验：荒谬的“伪关联”

为了证明该方法论的无效性，作者使用了与原研究完全相同的逻辑和代码，将该方法应用于其他各类地标。结果显示，该方法可以为“任何事物”制造出导致癌症的假象：

• Costco 仓库：据该方法计算，居住在 Costco 附近每年可能导致超过 220 万癌症死亡。
• 教育机构：私立大学（包括哈佛大学）和公立大学也被归因为数百万癌症死亡的“原因”。
• 职业体育场馆：居住在 MLB（棒球）、NFL（美式足球）或 NBA（篮球）场馆附近也显示出极高的死亡关联。
• 其他：甚至包括州首府和超级基金场址（Superfund sites）。

这些荒谬的结果表明，该方法论通过选择特定的地标和距离，可以随意制造出统计学上的“正相关”结果。

结论

作者认为，Alwadi 等人的研究并非发现了核电站导致癌症的新机制，而是展示了一种**“精确的胡说八道”**。这种方法论在设计上是“盲目”的，它只处理坐标、距离和协变量，而不理解物理学中的辐射剂量概念。

文章最后警告称，利用这种存在缺陷的统计模型来构建科学叙事是非常危险的，因为看似合理的逻辑（如“核能产生辐射 $\rightarrow$ 辐射导致癌症 $\rightarrow$ 核电站导致癌症”）极易掩盖研究设计本身的逻辑漏洞，从而误导公众认知和政策制定。

Orion 浏览器开发策略更新：停止 Linux 与 Windows 版直接开发并宣布开源

Kagi 团队近日宣布了一项重要的战略调整：停止对 Orion 浏览器 Linux 和 Windows 版的直接开发，并将这两个版本的源代码开源，以交由社区继续推进。

核心调整原因

由于 Orion 是由规模较小的团队开发，且完全由 Kagi 用户资助，公司决定采取更加专注的策略。通过减少在多个平台间的精力分散，团队将把研发资源集中在 macOS 和 iOS 平台，以提升 Orion 在 Apple 生态下的速度、稳定性和功能表现。

开源计划与维护

• 源代码发布： Kagi 将释放 Orion Linux 和 Windows 版的源代码。关于发布的具体细节，官方将在未来 30 天内公布。
• 长期托管： Kagi 正在积极联系开源基金会和相关组织，寻求项目的长期托管。官方明确表示，Kagi 本身不会担任核心维护者的角色，而是希望寻找愿意承担项目所有权并持续推动其发展的社区力量。
• 招募维护者： 欢迎有兴趣参与 Linux 或 Windows 版 Orion 维护工作的开发者、维护者或组织通过 support@kagi.com 与官方取得联系。

对现有用户的影响

• Linux 用户： 当前的 Linux Beta 版本仍可继续使用，但 Kagi 将于 2026 年 10 月 2 日停止为其提供更新。官方建议用户不要将其作为主要的日常浏览器使用。
• Windows 用户： 原定于 2026 年底由 Kagi 推出的 Orion Windows 版计划取消。取而代之的是，相关的代码将通过开源形式提供，由社区进行后续构建。

总结

此次调整旨在平衡有限的研发资源与维持 Web 引擎多样性的目标。通过将非核心重点平台的开发权交给社区，Kagi 既能确保其在 Apple 平台上的产品竞争力，也能通过开源贡献为 Web 生态保留一个基于 WebKit 的独立选择。

“让 Tmux 成为操作系统”：一种新型桌面体验的构想

本文探讨了现代桌面操作系统（OS）在窗口管理和任务处理方面的局限性，并提出了一种以“任务”为核心、类似于 tmux 但对普通用户友好的新型桌面架构构想。

现代窗口管理的核心问题

作者认为，目前的桌面体验仍停留在为旧硬件设计的权宜之计中，主要面临以下挑战：

1. 屏幕空间的动态变化：用户频繁在笔记本、扩展显示器等不同尺寸的屏幕间切换，但操作系统无法智能处理这种转变。当显示器连接或断开时，窗口布局往往会崩溃，迫使用户手动调整，造成效率浪费。
2. 用户行为的多样性：用户分为“窗口最大化者”（Maximizers）、“近最大化者”（Near-maximizers）和“协调者”（Coordinators），且普遍存在“私密窗口”与“公开窗口”的需求。目前的 OS 无法同时兼顾这些不同的使用模式。
3. 浏览器成为“微型操作系统”：现代工作大量发生在浏览器标签页中，但 OS 仍将其视为单一应用程序，忽略了标签页与工作流之间复杂的任务关联。
4. 文件系统的弱化：数据日益碎片化地存储在各类应用（如 Slack、iMessage、Apple Notes）的数据库中，传统的“文件-应用”工作链条已趋于瓦解，导致数据难以跨应用统一管理。

拟议的设计方案：基于任务的无限画布

作者提出了一种全新的桌面逻辑，旨在通过任务驱动而非应用驱动来组织工作空间：

• 无限画布与视口（Viewports）：桌面被视为一个连续的、无限的画布，物理显示器仅是该画布上的“视口”。
  • 确定性重流（Deterministic Reflow）：在切换显示器时，窗口的水平顺序和任务归属保持不变，仅根据视口宽度进行响应式布局调整。
  • 焦点与观察模式：系统通过输入遥感技术识别“焦点显示器”（主要工作区）和“观察显示器”（用于显示即时通讯、待办事项等辅助信息）。
• 任务导向的窗口组织：
  • 浏览器标签页将脱离浏览器概念，作为独立的窗口参与到特定的“任务”中。
  • 用户可以为每个任务定义一组窗口组合，实现类似 tmux 的会话持久化。
• 隐私作为一等公民：隐私不再是基于区域的，而是基于窗口属性。借鉴“演示者视图”（Presenter View）的概念，用户可以轻松实现公开展示与私密工作的隔离，且这种状态由硬件连接状态等客观事实驱动，而非用户主观猜测。

技术实现：本地 LLM 的辅助

为了解决配置复杂（如传统的平铺式窗口管理器过于硬核）的问题，作者提出引入本地大语言模型（LLM）：

• “Quake 叠加层”或“询问框”：用户可以通过类似命令行或对话框的交互，请求 LLM 协助组织工作空间。
• 分类、提议、预览与确认：LLM 根据窗口内容和用户意图提出布局建议，用户确认后由确定性代码执行，而非由模型直接操作窗口管理器，以保证稳定性。

实验中的挑战与反思

在尝试构建原型时，作者发现了该设计存在的潜在问题：

1. 隐私与监控的悖论：为了实现智能化的窗口管理，系统必须收集大量的行为数据（如输入焦点遥感），这本身可能带来隐私风险。
2. 逻辑缺陷：例如，“空闲状态”的判定存在困难。如果系统将“阅读”误判为“空闲”并自动切换视图，会破坏用户的操作体验。
3. “无限”带来的混乱：采用“仅追加、不替换”的无限画布模式会导致工作空间随时间推移而不断膨胀，缺乏自动化的“垃圾回收”机制，最终可能导致用户被过载的信息淹没。

ldraw-nova 开源乐高 AI 生成器项目摘要

ldraw-nova 是一个开源的 AI Agent 工具，旨在通过自然语言指令引导 AI 代理设计并构建符合 LDraw 标准的乐高（LEGO©）模型。

核心功能与输出

当 AI 构建过程完成后，用户可以获得以下成果：

• LDraw 源代码：标准的乐高模型描述语言。
• 多样化视图：包括 3D 查看器、3D 播放器、VR 交互视图（支持 Meta Quest 3）以及静态图像。
• Blender 兼容文件：可编辑的 .glb 格式 glTF 文件，并包含 Blender 自定义属性元数据。
• 交互记录：完整的聊天历史记录以及 Agent 的思考过程。

技术实现原理

该项目采用了一种“代理生成生成器”的创新思路，以规避大语言模型（LLM）在处理复杂几何数学计算时的弱点。

工作流程如下：

1. 接收指令：Agent 接收用户的模型构思提示。
2. 学习与规划：Agent 阅读内置的 LDraw 语言指南、设计规范及各类模型工作流文档，制定详细的构建计划（plan.json）。
3. 编写生成脚本：Agent 并不直接计算坐标，而是编写 Python 生成器脚本（generate.py）。
4. 迭代优化：通过执行脚本生成模型并进行“无头渲染”（Headless Rendering），Agent 会观察渲染结果，通过视觉反馈不断调整位置、形状和美学细节。
5. 最终产出：运行最终的生成脚本，产生 LDraw 源代码文件（.mpd）。

这种方法实际上是将 Agent 变成了一个“编译器”，通过编写代码来处理复杂的几何数学问题，从而提高模型的准确性。

安装与运行

项目通过 Docker 进行容器化部署，主要包含两个仓库：ldraw-nova（核心逻辑）和 ldraw-nova-docker（Docker 配置与 Web 应用）。

• 安装步骤：需同时克隆两个仓库（确保 Tag 版本一致），使用 docker compose build 构建镜像，随后通过 docker compose up -d 启动。
• 访问方式：
  • https://localhost:8443：支持 VR 模式（使用自签名证书）。
  • http://localhost:8765：标准 HTTP 访问。
• 搜索增强：项目集成了 jev-rerank 语义搜索工具。如果配置了 TypeSafe API Key，Agent 能更精准地查找零件和示例模型；否则将退回到全文搜索（FTS），模型质量可能下降。

当前挑战与开发方向

作为首个发布版本，项目仍处于开发阶段，面临以下挑战：

• 性能与成本：目前的生成过程较慢，且依赖昂贵的高端模型（如 Claude Opus 5.5 或 GPT-4 等）才能完成复杂模型；VR 模式在 Meta Quest 3 上存在性能问题。
• 模型能力局限：对于人偶（Minifigs）、高级太空船及复杂机械结构的生成精度仍需提升。
• 兼容性：需要优化工具链，使其能适配低端 LLM（如 Haiku 等），并提升从图纸（Manuals）直接构建模型的能力。

SaaS 业务的演进：从软件服务转向“模型控制架”（Harness）

这篇文章探讨了 SaaS（软件即服务）业务未来的核心逻辑：所有的 SaaS 企业最终都将演变成围绕大语言模型（LLM）构建的“控制架”（Harness）。

1. 什么是“控制架”（Harness）？

作者对“控制架”给出了广义的定义：它不仅仅是像 LangGraph 或编程代理（Coding Agents）这样的工具，而是指围绕无状态 LLM 的所有基础设施、接口、上下文（Context）和状态（State）的总和。一个复杂的控制架可以由多个针对特定任务的子控制架组成（例如一个“软件工厂”控制架，包含编写规范、编写代码、代码审查等子控制架）。

2. SaaS 业务的四个演进阶段

随着 AI 技术的发展，软件服务业务将经历以下轨迹：

1. 传统 SaaS 阶段：通过传统方式构建和销售软件服务，没有控制架。
2. 个人操作控制架阶段：工程师、产品经理和销售人员开始与 AI 代理（Agents）协同工作，以提高个人生产力。
3. 个人编排控制架阶段：大量核心任务转移到云端的后台代理上。人类负责触发代理（编写提示词）并审查输出。
4. 控制架编排个人阶段：代理成为主动执行任务的后台力量，人类的角色转变为“审查者”。代理开始主动决定工作流，而不再仅仅是执行人类预设的设计。

3. 核心转变：工作重心从人转向控制架

当公司进入第四阶段时，其本质发生了变化：

• 生产力转移：产生软件服务的核心工作从“人”转移到了“控制架”上。产品本质上是模型输出，而公司提供的是上下文、集成能力和人工审查接口。
• 组织架构反转：组织架构不再是单纯的人力堆叠，而是研究如何将人类安置在控制架中最能发挥“审美与判断力”（Taste and Judgment）的位置。
• 竞争壁垒重构：公司的领域知识、工具链、权限管理、审查闭环和上下文，共同构成了企业的“业务控制架”。

4. 如何避免“质量平庸化”？

作者指出，人们担心由 AI 主导的生产会变成“垃圾工厂”，但有效的控制架可以通过在关键节点引入人类输入来解决。优秀的控制架应通过代理汇总信息、测试方案，最后将最具决策价值的选择提交给人类“审美/判断力持有者”（Taste-holders）进行最终审核。

5. 战略建议与未来趋势

• 掌握顶层控制架：企业不应完全依赖第三方工具，而应拥有“顶层控制架”，决定“构建什么”并“审查结果”，将供应商产品视为控制架中的特定工作流插件。
• 规避商品化风险：如果第三方供应商能够接管整个“外部循环”（Outer Loop，即从需求到交付的全过程），那么该业务就会被商品化。
• 预期的行业趋势：
  • 企业会投入大量精力在内部构建控制架（涵盖研发和销售端）。
  • 组织结构和岗位职责将围绕控制架进行重塑。
  • AI 原生初创公司将在传统优势护城河容易被“控制架化”的领域击败老牌企业。
  • 所有企业使用的软件都需要具备“无头”（Headless）特性，以便被外部控制架调用和运行。

Newgrounds 社区动态摘要

Newgrounds 是一个集游戏、音乐和艺术创作于一体的社区平台。以下是其最新的社区动态、活动日程及热门内容概览：

1. 活动与挑战赛

社区在 10 月份组织了多项艺术挑战、音频挑战及线下聚会：

• 艺术与音频挑战： 包括 “Evil Doer Inktober” 提示词挑战（10月1日至31日）和 “Analogtober” 音频挑战（10月1日至31日）。
• 线下聚会： 达拉斯（Dallas, TX）Arcade 聚会（10月10日）和芝加哥（Chicagoland）Quad Con 聚会（10月17日）。
• 协作项目截止日期： 涵盖了 Smash Bros Ultimate 阵容、Puyo Puyo 协作、Emo Art 协作、I Wanna Be the Guy 艺术协作、PS2 协作以及 Ruby Gloom 艺术协作等多个项目的截稿时间。

2. 精选内容推荐

• 热门电影/动画： 展示了近期上传的多部作品，如 the villain's villain、cute cockamamie conundrums、Bleed for Me from IWTV2 以及 Deadlock The Cartoon Vol 1 等。
• Takeover Tuesday 热门游戏： 重点推荐了 Newgrounds Gijinka Collab: 3GX Edition、PIG 2: Interactive Experience、THE BOOTLEG ART COLLAB 以及拥有百万级播放量的万圣节主题游戏 Trick-or-Treat Adventure!。
• 最新发布： 平台持续更新了各类新游戏与新动画作品，涵盖了从短篇动画到实验性视觉效果的不同风格。

3. 创作者动态与周边

• 创作者更新： 社区成员分享了个人的创作动态，包括新作品发布预告、委约（commissions）开放信息、参加展会记录以及音乐作品发布。
• 官方周边： 平台提供了 Newgrounds 官方 T 恤的购买链接。

The coming proxy wars will be devastating for civilians and do little to improve governance and human welfare in Ethiopia and the wider Horn

GrapheneOS 已修复 Android 17 QPR1 中的内核性能退化问题。

摘要：平台大迁徙趋势

本文观察到一种数字领域的显著趋势：用户正逐渐离开主流的大型平台，转向更小规模的数字空间。

核心现象 许多用户正在退出 Reddit、WordPress、Discord、GitHub、Codeberg 和 Photoshop 等知名平台。此外，还有一部分用户选择彻底离开传统的万维网（Web），转而投向如 Gopher 和 Gemini 等“小网”（smallweb）领域。

离开的原因 用户离开的主要动机包括：

• 经济因素：定价政策的变化。
• 数据隐私与 AI：平台利用用户发布的内容进行 AI 训练。
• 治理与所有权：所有权的更迭或平台政策的改变。
• 设计理念的偏移：平台逐渐失去了“以人为本”的设计初衷，变得不再服务于个人用户。

趋势特征：从“大”转向“小” 这种迁移呈现出明显的特征：用户并非在寻找下一个大型平台，而是转向更具私密性和自主性的环境，例如个人网站、自托管应用或不便于被偶然发现的“胶囊”式空间。尽管这种做法意味着牺牲了受众的触达率（reach），但用户认为这是一种通过换取更高控制权（control）来保障数字生活质量的明智选择。

结论 虽然大型平台本身并不会消失，但那些最初赋予这些平台活力与趣味性的核心用户，正在悄然地向更小、更受控的数字角落迁移。

荷兰计算机博物馆参观总结 (2022)

本文记录了作者在2022年参观荷兰三家不同风格计算机博物馆的经历。

参观的博物馆

1. HomeComputerMuseum (Helmond)

   • 风格：被称为“客厅博物馆”。
   • 藏品：拥有500多台电脑，主要来自1980年代以后。
   • 特点：许多机器处于运行状态，供访客互动或游玩。

2. Bonami SpelComputer Museum (Zwolle)

   • 风格：规模宏大的“仓库博物馆”。
   • 藏品：馆藏达数千件，包括大型机、打字机、计算器以及大量的视频游戏。
   • 特点：馆内设有专门的街机区，包含大量1980年代后期的 Atari 游戏。相比之下，该馆的互动性较低，布局较为杂乱。

3. DEC 收藏馆 (位于偏远农舍)

   • 风格：位于乡间农舍内的私人收藏。
   • 藏品：由一位 Digital (DEC) 爱好者收集，主要为1970年代和1980年代的 DEC 机器。
   • 特点：部分机器目前仍处于修复阶段，是一个长期的修复项目。

主要发现与特色文物

作者强调了非美国计算机博物馆的价值，认为它们展示了独特的区域性文物，例如非英语的键盘标识和各种本地化设计。

• 特殊设备：

  • Aesthedes：一款20世纪80年代早期的专业图形编辑器，配备了一个拥有514个按键的巨型键盘。其设计将许多现代图形软件中的功能通过物理按键直接实现。
  • 其他硬件：包括荷兰 Holborn 电脑、Philips CD-i 相关展示、韩国版 NES、Apple II 克隆机（被称为中国教育计算机）、ZX Spectrum 克隆机、Commodore 64 以及运行 Deluxe Paint 的 Amiga。

• 键盘与输入设备：

  • 展示了多种奇特的输入工具，包括1980年代的和弦键盘、单手数据输入设备、APL 编程语言键盘、Lorenz 电传打字机以及具有独特人体工程学设计的键盘。
  • 部分键盘展示了早期对按键功能的创新处理，例如明确标注 "Enter" 与 "Return" 相同功能的按键，以及用于处理特殊指令的宏观按键。

美国国土安全部被控利用 Palantir 数据库监视抗议者

一份新解密的法院文件揭露，美国国土安全部（DHS）涉嫌利用由 Palantir 开发的“调查案件管理”（Investigative Case Management, ICM）数据库，针对监视移民执法局（ICE）行动的观察员建立个人档案，记录内容包括照片、车牌号码及其他个人信息。

核心指控与事件背景

该诉讼是由四名在缅因州进行执法观察的个人发起的拟议集体诉讼。原告指控 DHS 特工存在恐吓观察员的行为，包括：

• 建立个人档案： 特工利用 ICM 数据库将观察员标记为“执法威胁”或“专业抗议者”。
• 利用面部识别： 特工将观察员的照片发送给海关及边境保护局（CBP）官员，通过名为 “Mobile Query” 的应用程序进行面部识别比对。
• 恐吓与骚扰： 文件记录了一名代号为 “Agent J.C.” 的特工通过电话恐吓观察员，暗示其行为可能导致被列入“国内恐怖主义观察名单”。此外，还涉及通过驾车巡视观察员住所等骚扰行为。

技术架构与功能

文件的重点在于 ICM 数据库的技术运作方式及其对个人权利的影响：

• 系统用途与来源： ICM 是由 ICE 的国土安全调查局（HSI）用于记录和追踪调查案件的管理系统。该系统由 Palantir 在 2014 年中标开发，基于其 Gotham 软件进行定制。
• 数据集成与自动化共享： 根据 DHS 的隐私评估，ICM 具有自动共享机制。特工在 ICM 中创建的记录会自动同步到 CBP 的 TECS 系统中，作为边境旅客筛查时的“观察记录”（lookout records）。这意味着在 ICM 中被标记的个人，在过境时可能会面临额外的二次检查。
• 合同规模： ICE 与 Palantir 维持着长期且巨额的合作关系。2022 年签署了一份价值约 9600 万美元的支持合同，并在 2025 年追加了近 3000 万美元用于开发名为 “ImmigrationOS” 的新平台。

政府辩护与法律诉求

• 政府立场： DHS 发言人称该诉讼“毫无根据”，并否认存在专门针对“国内恐怖分子”的数据库。政府律师在动议中辩称，相关行为属于“孤立事件”，特工仅针对其认为的“潜在执法威胁”进行记录，而非将其列入恐怖主义名单。
• 原告诉求： 原告律师指出，这些行为对公民行使第一修正案赋予的权利产生了“寒蝉效应”。他们要求法院命令封存相关记录、禁止政府利用收集到的信息针对原告，并禁止执法人员通过威胁观察名单或跟踪住所等方式进行恐吓。