关于iOS 18与macOS 15“照片”应用新功能“增强视觉搜索”的发现与隐私争议

作者Jeff Johnson发现，在升级至iOS 18和macOS 15（Sequoia）的设备上，“照片”应用默认启用了一项名为“增强视觉搜索”的新功能，且此功能未引起媒体广泛关注。该功能旨在帮助用户通过照片中的地标或兴趣点进行搜索。

苹果的官方说明与技术承诺： 根据苹果的隐私政策说明，该功能会在用户设备上将照片中的地点与苹果在服务器上维护的全球索引进行私密匹配。苹果声称采用了同态加密、差分隐私以及隐藏IP地址的OHTTP中继等技术，以防止苹果获取用户照片中的具体信息。此外，苹果在2024年10月发布的一篇技术博客中强调了其隐私原则，优先使用设备端处理，并表示此类服务器查询是在用户请求下为丰富设备体验而实现的，并已采取隐私保护措施。

作者的核心质疑：

1. 用户选择权与知情权缺失：作者认为，此功能是苹果单方面、未经用户明确同意而启用的，并非用户主动请求。这与计算隐私的简单理念相悖——即数据若离开设备，则无法保证完全私密。
2. 对隐私风险的根本怀疑：作者无法完全评估苹果技术实现的可靠性，并指出苹果软件本身频繁出现安全漏洞（由其安全更新记录证明）。因此，即使没有恶意意图，仅软件漏洞就足以使用户面临风险。苹果无法保证其软件毫无缺陷。
3. 与苹果营销口号的矛盾：作者引用苹果著名的“What happens on your iPhone, stays on your iPhone”广告语，认为该功能的默认启用行为与此口号相违背，证明其宣传不实。
4. 用户自我保护受限：在macOS上，用户可使用Little Snitch等防火墙软件阻止数据外传。但在iOS上，苹果不允许类似工具，作者认为苹果的限制实际上妨碍了用户自行保护隐私。

结论： 作者对“增强视觉搜索”功能不感兴趣，认为其潜在风险远大于收益。苹果在未征询用户意见的情况下默认启用该功能，被视为对用户及其隐私偏好的不尊重。此次事件进一步加深了作者对苹果隐私承诺的怀疑，并引发了关于用户是否应拥有设备数据外发控制权的讨论。

Google搜索的演变：从简洁到信息过载
Google在2000年代凭借极简设计、主动意图搜索和高信任度的有机结果获得成功。但其后续引入广告、SEO优化及聚合网站，导致搜索结果逐渐被商业化内容渗透。如今，Google搜索页面堆叠AI生成文本、自家产品广告、视频及优化链接，用户需在视觉噪音中艰难寻找信息，体验类似早期Yahoo的选择困难与信任流失。

OpenAI搜索的机遇与挑战
OpenAI的ChatGPT搜索采用对话形式，提供单一答案而非列表，继承了早期Google的主动意图搜索和简洁性。其优势在于符合用户对话习惯，且暂未商业化，但面临AI幻觉和信任建立的挑战。OpenAI正通过引用权威媒体来增强可信度，若能保持简洁与信任，可能成为主流搜索的替代选择。

关键分歧：信任与简洁决定未来
Google当前以功能堆砌应对问题，加剧用户体验下降；OpenAI则处于关键转折点——若能维持简洁并建立信任，有望以“答案助手”角色占领搜索市场。反之，若陷入复杂化设计，将面临与Google的长期竞争。两者核心差异在于：Google因过度商业化失去初心，OpenAI则需以可靠性证明其革新潜力。

摘要：Unity商标声明

本文为法律商标声明，明确了以下核心内容：

1. Unity商标归属：声明中指出，“Unity”、Unity标志及其他相关商标是Unity Technologies或其关联公司在美国及其他地区的注册商标或商标。
2. 其他品牌归属：声明强调，其他名称或品牌商标均为其各自所有者的财产。
3. 信息参考：相关详细信息可通过指定的链接进一步了解。

注意：本文内容仅为知识产权声明，不包含标题所暗示的关于内存损坏调试的技术性讨论或描述。

Fish 4.0：用 Rust 重写的忒修斯之船

背景与动机

Fish Shell 在 2023 年初提出用 Rust 重写整个代码库（从 C++ 迁移）。主要驱动力源于 C++ 的多个痛点：

• 工具链与平台差异：缺乏统一的编译器升级方式，支持旧系统困难。
• 开发体验与安全：C++ 在人体工学、线程安全方面表现不佳，头文件、模板复杂，容易引发未定义行为。
• 社区与吸引力：C++ 贡献者较少，语言本身对开发者吸引力不足。

Fish 需要实现真正的并发执行（如异步提示符、非阻塞补全），但 C++ 的原型多线程方案因对象共享风险难以安全推进。Rust 的 Send 和 Sync 特性能静态保证线程安全，是更可靠的选择。

选择 Rust 的理由

• 趣味性与吸引力：作为业余项目，Rust 的“酷”和“有趣”能吸引贡献者。
• 卓越的工具链：错误提示友好，rustup 安装简便，依赖管理轻松。
• 良好的人体工学：Option、模块系统等设计优于 C++ 指针和头文件。
• 静态线程安全：Send/Sync 为多线程执行奠定基础。
• 平台支持：主要目标系统（macOS、Linux、BSDs 等）均受支持，架构覆盖度极高。

迁移策略：忒修斯之船式渐进重写

采用“逐步替换，始终保持可用”的策略，避免长期无法使用和测试中断。

• 使用 autocxx 生成 C++/Rust 绑定，组件级迁移。
• 从独立性较强的内置命令（builtins）开始，逐步推进到更复杂的子系统（如输入/输出读取器）。
• 期间维护了 C++ 版本的 3.7.0 发布，不影响正常更新节奏。

遇到的挑战与问题

• autocxx 的局限：需处理 C++ 特定结构（如 vector<wstring>）、调整所有权模型，导致中期性能暂时下降。
• 构建工具：因 autocxx 生成代码庞大，rust-analyzer 等工具变慢。
• Rust 自身不足：
  • 可移植性处理：系统特性检测依赖手动枚举目标，缺乏“按函数存在性编译”的能力。
  • 本地化：编译期格式字符串不支持翻译，需移植 musl 的 printf。
• 初期误判：如字符串宏设计过度、对 time_t 迁移的误担心、错误处理不当（滥用 unwrap）。
• 未能移除 CMake：cargo 安装功能简陋，需保留 CMake 处理资产文件、测试和文档。

成果与收益

• 彻底移除 C++：2024 年初完成，beta 版于 2024 年 12 月发布。
• 技术改进：
  • 告别 curses 库，改用更简洁的 Rust terminfo 解决方案，简化构建。
  • 实现“自安装”包，支持静态链接（Linux 使用 musl），便于无 root 环境部署。
• 性能与稳定性：运行时内存使用更稳定，性能略优于 C++ 版本。
• 开发体验提升：代码库更受喜爱，新特性（如 YAML/JSON 支持）更易添加。

总结与遗留事项

迁移历时近两年，涉及超 11 万行插入、8.9 万行删除，由超过 200 位贡献者参与。尽管有挑战（如 autocxx 调试、平台可移植性检测），整体成功。Fish 现已成为一个以 Rust 为基础、具备更现代架构的 Shell，但保留了部分 C 风格代码（如使用 UTF-32 字符串）。Cygwin 暂时失去支持，未来有望改善。

本地运行大语言模型指南

硬件要求

• 非必需高端配置：即使使用旧GPU或CPU也能运行较小模型，但速度较慢且可能产生更多“幻觉”。
• 作者配置示例：Linux笔记本电脑，配备i9 CPU、4090 GPU（16GB显存）和96GB内存。
• 显存影响：模型大小决定运行方式——适合显存的模型生成速度更快，超大模型将部分数据卸载至内存，导致速度下降。

核心工具

1. Ollama：运行LLM的中间件，提供Python和JavaScript库，作者通过Docker部署。
2. Open WebUI：前端聊天界面，支持文本/图像输入，与Ollama后端通信并流式输出结果。
3. llamafile：单个可执行文件集成LLM，易于上手，但作者遇到GPU卸载问题。
4. 图像生成工具：
   • AUTOMATIC1111：用于定制化图像生成。
   • Fooocus：简化图像生成流程。
   • ComfyUI：复杂图像工作流自动化。
5. 其他应用：
   • Continue：VSCode中的代码补全插件。
   • Smart Connections：Obsidian笔记查询插件，结合Ollama使用。

模型选择与来源

• 选择依据：基于性能与模型大小的平衡，因LLM领域发展迅速，作者常更换模型。
• 当前常用模型：
  • Llama3.2：用于笔记查询和通用问答。
  • Deepseek-coder-v2：代码补全。
  • Qwen2.5-coder：代码对话。
  • Stable Diffusion：图像生成。
• 模型下载：
  • LLMs通过Ollama模型页面获取，并用RSS订阅更新。
  • 图像模型从CivitAI下载（注意：部分内容可能不适用于工作场景）。

维护与更新

• 使用WatchTower自动更新Docker容器。
• 通过Open WebUI界面更新模型。
• 未进行模型微调或量化（因担心CPU潜在缺陷导致过热）。

本地运行优势

• 数据控制：完全掌握数据隐私。
• 低延迟：响应更快。
• 依赖开源：得益于开源项目、免费模型及训练数据原作者的贡献。

资源与社区

• 入门资源：r/LocalLLaMA subreddit和Ollama博客。
• 持续更新：作者将根据工具和模型迭代更新本文内容。

内容说明

您提供的文章内容（HTML 代码）并非文章正文，而是 Cloudflare 的安全验证页面。该页面旨在进行人机验证（例如通过 JavaScript 挑战），其主要内容是验证逻辑和配置代码，并未包含标题《The average American spent 2.5 months on their phone in 2024》所承诺的实际文章文本。

因此，无法基于当前提供的实际内容生成关于“2024年美国人平均手机使用时长”的摘要。要生成准确的摘要，需要访问到文章的实际正文内容。

ASCII色情艺术概述

ASCII（美国信息交换标准代码）是一种用128个数字表示英文字母和符号的系统，用于数字文本呈现。早在20世纪70-80年代，随着点阵打印机、Usenet论坛等技术的出现，人们开始用ASCII字符拼凑图像，其中包含色情内容。

历史背景与传播

• ASCII色情被认为是互联网上最早传播的色情形式。与当时下载缓慢的图像文件不同，ASCII艺术作为文本加载速度极快。
• 其前身可追溯至更早时期，如20世纪初的电传打字艺术，以及1960年代无线电业余爱好者通过文本模式（如ASCII、PETSCII）转换《花花公子》图片。
• 早期传播途径包括公告板系统（BBS）、Telenet、Usenet以及通过软盘等物理媒介（俗称“跑腿网”）。
• 电传文字（Teletext）在欧洲（尤其北欧）曾是一种流行的文本媒介，也包含色情内容。

文化与代表艺术家

• ASCII艺术家常以三字母呼号签名，形成独特社群文化。代表人物包括：
  • Joan Stark（“jgs”）：作品以简洁优雅著称。
  • Vuk Ćosić：斯洛文尼亚当代艺术家，其《ASCII电影史》（1998）被视为网络艺术先驱，作品《Deep ASCII》将经典色情片《深喉》转换为55分钟ASCII动画，并曾在博物馆展出。
  • Laura Brown（“ldb”）：1998年起活跃于新闻组，认为简单符号（如乳房、臀部）是早期色情ASCII的雏形。
• 艺术家们常从技术限制中寻找创意，将ASCII色情视为突破传统艺术形式的实验。

演变与现状

• ASCII艺术从简单符号发展为复杂作品，如动画或互动游戏（例如PETSCII自慰游戏）。
• 如今ASCII艺术仍常见于Twitter、聊天服务器、Facebook群组等平台，常以“警长模因”、“持有标志的兔子”等形式出现。
• 面临的挑战包括：作品易被复制粘贴而缺乏署名，导致艺术家难以获得认可或收益。

收藏与资源

• 一些ASCII艺术收藏网站及社区（如Asciipr0n.com、互联网档案馆相关存档）保存了大量作品，但需注意其中包含成人内容。

总结
ASCII色情艺术源于早期计算机文化，随技术发展而传播，融合了艺术实验与网络社群特性。尽管面临版权等挑战，它仍在数字文化中持续演变并保有影响力。

GitHub假星标研究：4.5M疑似虚假星标分析

核心概述

本文通过系统性、全球性、纵向的测量研究，揭示了GitHub平台虚假星标（fake stars）现象。研究者开发了StarScout工具，可对2019年至2024年间所有GitHub元数据中的异常标星行为进行可扩展检测。研究发现虚假星标活动在2024年急剧增长，这些活动主要用于推广短期恶意钓鱼仓库，短期虽有效但长期会产生负面影响。

主要发现

1. 虚假星标活动趋势

• 2024年虚假星标相关活动迅速激增
• 虚假标星账号和仓库具有高度琐碎的活动模式

2. 虚假星标的用途

• 主要用途：大多数虚假星标用于推广短期钓鱼恶意软件仓库
• 次要用途：剩余部分主要用于推广：
  • AI/大语言模型（LLM）项目
  • 区块链相关仓库
  • 工具/应用程序
  • 教程/演示仓库

3. 虚假星标的效果

• 仓库可能通过虚假星标进行增长黑客（growth hacking）
• 虚假星标仅具有短期推广效果（少于两个月）
• 长期来看，虚假星标会成为负债（liability），降低仓库信誉和决策价值

研究影响

本研究对以下群体具有重要启示：

• 平台管理者：需加强虚假星标检测与治理
• 开源实践者：应理性看待星标数量，关注长期信誉建设
• 供应链安全研究者：需警惕虚假星标作为攻击向量的安全风险

研究方法

• 开发StarScout可扩展工具
• 分析2019-2024年所有GitHub元数据
• 识别异常标星行为模式

研究意义

• 假星标降低了星标作为决策信号的价值
• 对所有GitHub用户构成安全风险
• 揭示了开源平台中社会信号造假的现象与影响

研究提交历史：初版2024年12月18日，更新版2025年9月6日

这是一个基于WebGL技术的交互式流体模拟应用演示。

• 核心内容：提供了一个可在网页浏览器中实时操作的流体模拟程序。
• 主要形式：通过一个可交互的演示界面来展示。
• 核心功能：用户可以通过鼠标或触控设备与模拟的流体进行互动，直观地观察流体的物理行为。
• 技术应用：展示了WebGL在创建复杂、动态的物理模拟和可视化方面的应用。

# Anki AI Utils 项目摘要

## 项目概述
Anki AI Utils 是一套强大的 AI 工具套件，旨在通过自动生成解释、插图、助记符等内容来增强 Anki 闪卡学习体验，尤其适用于医学院学习场景。其核心思想是：每次答错卡片时，工具可自动生成 ChatGPT 解释、DALL-E 插图、个性化助记符等辅助材料，同时支持用户自定义的记忆方法。

## 主要工具
### 1. Illustrator (插图生成器)
- **功能**：使用 AI 图像生成（如 DALL-E 2/3、Stable Diffusion）为卡片创建自定义助记图像。
- **特点**：分析卡片内容识别关键概念，生成创意视觉记忆钩子，自动优化图像格式，支持每卡多图。

### 2. Reformulator (重构器)
- **功能**：智能重述闪卡内容，保持核心意义不变。
- **用途**：改进措辞不清的卡片、增加表述多样性、根据学习风格调整卡片格式（如转为列表、问题或记忆宫殿结构）。

### 3. Mnemonics Creator (助记符生成器)
- **功能**：为卡片生成定制化助记符。
- **特点**：创建多个助记选项，使用主要系统等记忆技巧，融入用户现有记忆锚点，支持批量处理。

### 4. Explainer (解释器)
- **功能**：当答错卡片时提供清晰详细的解释。
- **作用**：分解复杂概念，突出关键关系，添加背景信息，帮助理解错误原因并弥补知识缺口。

### 5. Mnemonics Helper (助记符助手)
- **功能**：轻量级交互式命令行工具，用于快速生成助记符。
- **特点**：基于语义相似性匹配现有助记符库，生成新选项供选择，可独立于 Anki 使用，适合头脑风暴。

## 开发者说明与求助
- 该项目是作者医学院期间贡献的 AI 功能成果，已进行详细文档记录。
- 作者因时间有限，希望社区帮助将这些脚本打包为 Anki 插件，并构建相应的图形界面。
- 欢迎任何形式的贡献，详细路线图已列出待改进项。

## 核心特性
- **自适应学习**：使用语义相似性动态匹配最相关的示例。
- **个性化记忆钩子**：复用用户自定义助记符库，构建个性化记忆系统。
- **自动化就绪**：支持通过 cron 等定时任务自动增强前一天答错的卡片。
- **通用兼容性**：直接修改 Anki 笔记，适用于所有 Anki 客户端（Windows、Mac、Linux、Android、iOS）。
- **提供商无关**：通过 LiteLLM 支持所有主流 LLM 提供商和模型。
- **无限可扩展**：训练数据集可随意添加示例，语义过滤会自动选择最相关的内容。

## 使用方法简述
1.  确保安装 Python（推荐 3.11 或 3.12 版本）。
2.  克隆项目仓库。
3.  建议创建 Python 虚拟环境。
4.  通过命令行运行各工具脚本（如 `reformulator.py`, `mnemonics.py` 等），需指定查询参数、数据集路径、LLM 模型等关键参数。

## 支持与通用功能
- **多语言支持**：支持 LLM 提供的所有语言，并保留特定格式。
- **成本控制**：内置安全防护，可限制每次运行的卡片数，记录花费，支持设置硬性支出限制。
- **历史记录与可追溯性**：通过标签和元数据跟踪修改，便于识别、回滚和评估处理情况。
- **多次运行处理**：多数工具会保存历史版本（使用可折叠HTML部分），重构器则在单独字段保存历史。
- **模型切换**：支持使用不同的 LLM 模型，可在测试时使用廉价模型，正式使用时切换。

## 路线图与未来方向
- **核心目标**：将脚本打包为正式的 Anki 插件。
- **代码优化**：统一代码库，减少重复，提升可维护性。
- **功能增强**：为各工具添加更多功能，如改进媒体支持、添加快捷键、优化查询性能、支持模板化输出等。
- **分发**：计划通过 PyPI 实现安装。
- **社区协作**：积极寻求贡献者，帮助实现插件化、文档完善等任务。

## 致谢
项目大量使用了 AnkiConnect 与 Anki 进行交互。

概述

本文测试了多个大语言模型（LLM）准确逐字回忆《圣经》经文的能力，旨在评估LLM处理被视作“上帝之言”的固定文本时的可靠性。测试方法包括六种场景，均在温度=0的设置下进行，以确保输出确定性和准确性。

测试方法

• 温度设置：使用0以确保模型生成最可能的响应，减少创造性偏差。
• 检查方式：忽略大小写和空格差异，给予一定容错空间。
• 测试场景：设计了六种情境来评估不同回忆能力。

测试结果

测试1：流行经文回忆（约翰福音3:16 NIV译本）

• 结果：除Llama 3.3 70B外，所有模型均通过。该模型因插入“begotten”（其他译本存在）而出现轻微不匹配。

测试2：冷门经文回忆（俄巴底亚书1:16 NIV译本）

• 结果：多数模型困难，常混淆不同译本。仅Llama 3.1 405B、GPT 4o和Claude 3.5 Sonnet完全正确；其他大中型模型部分正确或错误。

测试3：经文续写（历代志下11:13后的下一节）

• 结果：中大型模型表现较好，小型模型常虚构内容。Claude 3.5 Haiku因用词不当（用“they”替代原文）被标记为部分正确。

测试4：经文段落回忆（耶利米哀歌3:19-24）

• 结果：除Llama 3.1 8B外，所有模型基本正确。仅Llama 3.1 8B失败，且回忆的是章节开头。

测试5：基于查询的查找（查找关于“大地充满对耶和华荣耀的认识”的经文）

• 结果：所有模型均成功识别为哈巴谷书2:14，表明经文查找是LLM的强项。

测试6：整章回忆（罗马书第6章 KJV译本）

• 结果：除Llama 3.1 8B外，所有模型均准确回忆全部23节。Llama 3.1 8B虽失败，但仍正确回忆超98%的词汇。

结论

• 大型模型（如Llama 405B、GPT 4o、Claude Sonnet）表现最佳，在多数测试中准确无误。
• 中型模型（70B级）通常能保留经文原意，但可能混合不同译本或略有释义。
• 小型模型（7B级）易出错，常混淆译本或虚构内容。
• 建议：若依赖LLM提供准确经文，应选用大型模型；小型模型可用于涉及经文引用的讨论，但需以实际《圣经》文本为校正依据。
• 未来展望：小型模型可能改进，但信息编码能力存在固有局限。

详细测试结果与代码：可访问作者提供的GitHub链接获取。

这篇文章详细描述了在《动物森友会》中发现并利用隐藏NES模拟器功能的过程。作者原本试图激活开发者菜单，却意外发现了游戏可通过存储卡加载NES游戏的功能，并最终利用该机制实现了任意代码执行。

核心发现与流程

1. 隐藏功能：游戏内的通用“NES主机”家具物品（无自带游戏）实际上会尝试从GameCube存储卡扫描并加载特定格式的NES ROM文件，该功能由游戏内一个完整的NES模拟器支持。

2. 逆向工程过程：

   • 通过追踪函数调用链，作者定位到了处理场景切换的函数 Game_play_fbdemo_wipe_proc 以及与NES主机家具交互相关的函数 aMR_FamicomEmuCommonMove。
   • 发现当使用通用NES主机（游戏索引为0）时，会调用 aMR_RequestStartEmu_MemoryC 函数，该函数进而通过 famicom_get_disksystem_titles 和 memcard_game_list 扫描存储卡上的特定文件。

3. 存储卡文件格式：

   • 文件名：必须以 "DobutsunomoriP_F_" 开头，且不能以 "SAVE" 结尾。
   • 校验和：文件所有字节值之和的低8位必须为0。需要手动计算并设置校验字节。
   • 结构：文件包含一个32字节的头信息，之后是ROM数据。ROM数据可以是原始数据，也可以是使用任天堂压缩格式（如Yaz0）压缩的数据。
   • 功能：该文件不仅用于存储NES游戏存档，其设计本身允许加载外部ROM。

4. 加载外部ROM：作者成功构建了有效的文件，通过跳过校验和检查等调试手段，使游戏从存储卡加载并运行了非内置的NES ROM（如《大金刚》、《洛克人》）。

5. 漏洞利用与代码执行：

   • 作者分析了游戏解析ROM文件时处理的元数据标签，发现其中的 PAT标签 存在关键漏洞。
   • PAT标签漏洞：该标签在未对目标指针（nesinfo_rom_start）进行空值检查的情况下，使用其计算补丁目标地址。通过精心构造一系列PAT标签，可以计算出一个指向游戏代码区域（0x80000000 - 0x807FFFFF）的任意地址。
   • 实现代码执行：直接写入新指令会因CPU指令缓存而无效。作者利用游戏动态替换malloc/free实现函数的机制（通过my_malloc函数加载函数指针），通过覆写该函数指针来劫持控制流。最终实现了加载运行自定义PowerPC汇编加载器，该加载器可从存储卡读取并执行更大的代码补丁。

意义与应用

此发现意味着，使用一张普通版《动物森友会》游戏光盘和一个包含特定文件的GameCube存储卡，玩家可以在真实的GameCube硬件上实现任意代码执行，从而加载模组、作弊码或自制软件。文中提到了一个具体应用：通过注入代码激活游戏隐藏的“开发者模式”。

Bluesky使用策略：谨慎参与而非全情投入

作者观察到近期网络社区正向Bluesky迁移，决定亲自尝试并分享其使用原则。

核心理念：不在他人王国建造城堡 作者受《不在他人王国建造城堡》一文启发，认为应在自己可控空间创造价值，利用平台吸引注意力。社交媒体平台虽能帮助建立个人品牌、促进互动，但平台规则易变（如Twitter被收购后的变化），可能导致用户创造的“价值”被困在平台内。

三年假设原则 作者将Bluesky（及任何平台/服务）视为临时场所，假设其三年内可能消失、被收购或变质。因此，他采取以下策略：

• 内容引导：用博客文章代替长推文，仅在Bluesky发布简要引子。
• 关系迁移：重视的关系会引导至平台外培养。
• 链接优先：个人介绍等场景优先展示个人网站而非Bluesky主页。
• 社区分散：将特定社区讨论引导至Discourse、Discord等专属空间。
• 静态引用：若在写作中引用Bluesky内容，优先转为静态形式；或接受链接可能失效的风险。

为何不选择Mastodon？ 作者认为Mastodon虽提供服务器联邦等自主权特性，但其用户体验复杂（如身份标识困惑），且未形成足够用户规模和活跃度，难以满足“与人动态互动”的社交需求。他仍会使用Mastodon，但遵循相同价值导向原则。

实用规则附录 文章末尾引用《不在他人王国建造城堡》中的六条规则：

1. 在自己拥有的土地上建造城堡。
2. 像他人利用你一样毫无顾忌地利用其他王国。
3. 将人们引回自己的王国，而非他人的王国。
4. 行动时假定城堡可能随时关闭。
5. 对提供轻易可见性的新王国保持警惕。
6. 给出充分理由让人们回到自己王国的城堡，并持之以恒。

欧盟统一充电器法规生效

欧盟关于统一电子设备充电端口的法规于周六正式生效。新规要求所有在欧盟27国销售的新智能手机、平板电脑和相机等设备必须配备USB-C充电接口。

主要内容

1. 生效与范围：该法规自2022年获批，给予制造商适应时间至2024年12月28日。新规覆盖了新手机、平板电脑、数码相机、耳机、扬声器、键盘等多种电子设备。笔记本电脑制造商则需在2026年初前遵循此规定。

2. 法规目标：欧盟认为此举将简化消费者生活、降低购买成本，并通过允许消费者在购买新设备时不必另购新充电器，从而减少电子垃圾。据欧盟委员会估计，该法规预计每年可节省至少2亿欧元，并减少超过1000吨的电子废弃物。

3. USB-C标准优势：USB-C接口可提供高达100瓦的充电功率，数据传输速度可达40 Gbps，并支持连接外部显示器。

4. 行业影响与苹果公司：过去十年，欧洲电子消费品制造商曾在自愿协议下趋向统一充电标准，但作为全球主要智能手机销售商的苹果公司拒绝放弃其专有的Lightning接口。苹果曾称此类法规“扼杀创新”，但已于去年9月开始随手机附带USB-C接口。该法规终结了市场上同时存在多种充电线标准的混乱局面。

这篇文章讲述了作者对Parrot Anafi消费级无人机通信协议进行逆向工程的过程，最终实现了通过PC直接控制其起降，并揭示了潜在的安全风险。

1. 攻击设置与数据捕获 首先，作者将PC连接到Parrot Anafi无人机自身的Wi-Fi网络。然后，使用Ettercap等工具进行ARP欺骗，使PC位于无人机与遥控器之间，实施中间人攻击以捕获通信数据。

2. 协议分析与命令识别

• 使用Wireshark抓包分析，发现无人机与遥控器之间通过UDP协议通信，负载均为十六进制非ASCII字符串。
• 通过分析起降过程的数据包分布，并结合多次起降实验的数据（对比17次起降前后的包数量），作者推测长度为53字节的第三种UDP数据包即为起降控制指令。
• 进一步分析这些数据包的结构，最终逆向并确认了控制起飞和降落的具体命令格式。

3. 验证与攻击实现

• 作者编写了一个Python脚本，向无人机IP地址（192.168.42.1）的特定UDP端口发送构造好的十六进制负载。
• 成功发送起飞命令（负载 040bff0b000000300001000100）后，无人机自动起飞并悬停；发送降落命令（负载 040bff0b000000300001000300）后，无人机降落。
• 实验发现，将数据包中的计数器字段设置为FF可确保指令被无人机接受。同时，无需伪造MAC地址，即使PC不是主控制器，无人机也会处理指令。

4. 潜在攻击场景 通过反复发送指令，可以造成拒绝服务攻击：

• 阻止起飞：持续向无人机发送降落命令，可使遥控器发起的起飞动作失败。
• 阻止降落：持续向无人机发送起飞命令，可干扰遥控器或手机App发起的降落程序，使无人机无法正常降落。

结论 该案例表明，任何能够接入Parrot Anafi无人机Wi-Fi网络的设备，都可以通过发送未认证的UDP控制包来操控其起降。这凸显了对物联网设备网络协议进行安全分析和逆向工程的重要性，以发现并防范此类未授权控制风险。

Ruby-refrigerator: 冻结所有 Ruby 核心类

Refrigerator 是一个 Ruby gem，旨在提供一种简便的方法来冻结（freeze）所有 Ruby 核心类和模块。其设计目的是在生产环境和测试中使用，以确保在运行时没有代码会对核心类或模块进行意外的修改。

主要功能

1. freeze_core 方法

• 用途：在应用程序代码加载完成后调用，冻结所有核心类。
• 效果：冻结后，任何对核心类的运行时修改都会引发异常。
• 使用示例：

  require 'refrigerator'
  Refrigerator.freeze_core
  

• 排除特定类：可以通过 :except 选项传递一个类名数组来排除某些类不被冻结。

  Refrigerator.freeze_core(:except => ['BasicObject'])
  

• 适用场景：在基于 Rack 的应用程序中，可以在 config.ru 文件末尾调用。

2. check_require 方法

• 用途：用于检查某个库在加载时是否会修改核心类。它通过在冻结核心后尝试加载库，从而轻松发现哪些操作会失败，并提供选项来尝试避免异常。
• 主要选项：
  • :modules：在冻结前预定义给定的模块名（符号数组）。
  • :classes：在冻结前预定义给定的类名（符号数组或包含类名符号和父类名符号的二维数组）。
  • :exclude：从冻结中排除给定的类/模块名（字符串数组）。
  • :depends：在冻结核心前需要先加载的依赖库（字符串数组）。
• 使用示例：
  • 检查 open3 库：

    Refrigerator.check_require('open3', :modules => [:Open3])
    

  • 检查 sequel 库（包含依赖和模块）：

    Refrigerator.check_require('sequel',
      :depends => %w'bigdecimal date thread time uri',
      :modules => [:Sequel])
    

  • 检查 date 库（可能需要排除特定类）：

    Refrigerator.check_require('date',
      :classes => [:Date, [:DateTime, :Date]],
      :exclude => ['Time']) # 例如，因为 Time 类会被修改
    

3. bin/check_require 命令行工具

• 用途：提供从命令行访问 Refrigerator.check_require 的方式。
• 使用示例：

  # 基本用法
  bin/check_require open3
  # 使用选项：预定义模块
  bin/check_require -m Open3 open3
  # 使用选项：预定义类并指定依赖
  bin/check_require -c Roda -r rack,uri,fileutils,set,tmpdir,tempfile,thread,date,time roda
  

其他细节

• 支持新 Ruby 版本：gem 的仓库中，freeze_core 将冻结的常量列表按 Ruby 的次版本号存储在 module_names/*.txt 文件中。当新的 Ruby 次版本发布时，可以运行相应的 Rake 任务来生成新文件。
• 跳过的类/模块：内部的、已弃用的以及私有的类和模块不会被 freezer 冻结。
• 许可：MIT 许可证。
• 作者：Jeremy Evans (code@jeremyevans.net)。
• 源代码：托管在 GitHub (github.com/jeremyevans/ruby-refrigerator)。

本文介绍了作者如何通过搭建配备4块NVIDIA 4090 GPU的个人计算设备来本地训练大型语言模型（LLM），旨在深入理解模型原理并支持实验探索。

核心要点如下：

• 动机与目标：作者为深入理解LLM工作原理，决定从头训练模型，而非仅使用现有产品。该设备可训练参数达10亿的模型，但在5亿参数左右能获得更高的计算利用率（MFU）。
• 硬件配置与成本：
  • 总成本约12,000美元。作者承认云服务更经济，但为获得实践经验而选择自建。
  • 关键组件：
    • GPU：4块NVIDIA RTX 4090。选择原因包括：24GB显存、对BFloat16/Float8的优秀支持（330 TFLOPS）、16384个CUDA核心、支持Flash Attention等。使用延长线连接。
    • CPU：AMD Threadripper PRO 5955WX，提供128条PCIe通道以避免带宽瓶颈。
    • 主板：SuperMicro M12SWA-TF服务器主板，但建议更换其散热方案。
    • 电源：两个1500瓦电源（如Be Quiet），需30安培电路。一个负责主板和CPU，每个电源各为两块GPU供电。
    • 其他：128GB RAM，6TB NVMe SSD用于高速存储，8TB HDD用于归档。
• 软件与配置：
  • 使用Ubuntu等Linux系统。
  • 安装最新GPU驱动、CUDA和cuDNN。
  • 使用PyTorch等框架。
  • 应用了来自Tinygrad的定制内核以实现GPU间的P2P通信，提升性能。
• 训练与优化：
  • 涉及数据准备、模型选择（如Llama2、GPT架构）和训练监控。
  • 采用分布式数据并行（DDP）等技术进行多GPU训练。
  • 使用George Hotz的内核补丁来启用NVIDIA 4xxx系列GPU的P2P通信。
• 关键建议：
  • 消费级GPU（如4090）为注重成本的实验提供了高性价比方案。
  • 本地设备适合长期项目和实验，云服务适合短期任务。
  • 可参考Andrej Karpathy、Hugging Face等社区资源。

文章强调，搭建此类设备虽具挑战，但为探索AI和机器学习提供了强大且可深度定制的工具。

内容摘要

根据提供的内容，这是一个 404 Page not found 错误页面，而非一篇题为《BSD kqueue is a mountain of technical debt》的技术文章。

具体信息如下：

• 页面状态：请求的URL无法找到或已失效。
• 页面内容：仅显示标准的404错误提示信息：“Sorry, we've misplaced that URL or it's pointing to something that doesn't exist. Head back home to try finding it again.”
• 导航链接：页面包含指向 “Home”、“Archive” 和 “About” 的导航链接。

由于原始文章内容不可访问，无法对其技术观点（如关于BSD kqueue的技术债务分析）进行总结。如需获取该文章内容，建议检查URL的准确性或通过其他途径（如网站存档）查找。

Intel奔腾处理器FDIV浮点除法错误分析

事件概述
1993年Intel发布奔腾处理器，采用新型SRT除法算法提升浮点除法速度。1994年，数学教授Thomas Nicely在研究中发现奔腾处理器的浮点除法结果存在错误。Intel最初认为此问题微不足道，但事件经媒体发酵后引发广泛批评，最终Intel被迫召回所有问题芯片，损失达4.75亿美元。

技术原因
奔腾处理器使用SRT算法进行浮点除法，通过查找表选择商位以提高速度。该算法在基4下运行，每次迭代生成两位商，速度是传统二进制除法的两倍。查找表包含2048个条目，但因数学定义错误，共有16个条目缺失（而非Intel当时声明的脚本错误导致5个缺失）。其中5个缺失条目会触发错误，其余11个无影响。

查找表实现
查找表采用可编程逻辑阵列（PLA） 实现，通过晶体管模式编码逻辑函数。原设计中，PLA的顶部边界线错误地应用了进位保存加法器的偏移约束，导致部分应赋值为2的条目被设为0。当SRT算法访问这些错误条目时，会产生不正确的商。

错误罕见性
尽管缺失条目数量占比较大，但由于进位保存加法器的特性，错误触发条件极为苛刻，需连续多次产生“不利”结果。实际触发概率约为90亿次除法中出现一次，因此日常使用中极难察觉。

修复方式
Intel的修复方案并非简单补充缺失条目，而是重新设计PLA：将所有未使用条目赋值为2。此举简化了逻辑边界，使PLA行数从120行减至74行，反而减少了晶体管数量。新PLA的模式与原设计完全不同，无法直接对比具体修改点。

争议与影响

• Intel立场：认为错误对绝大多数用户无影响，典型用户约27,000年才会遇到一次。
• IBM反驳：通过分析声称用户可能数天内遇到错误，并暂停奔腾电脑出货（IBM当时拥有竞品PowerPC处理器）。
• 长期影响：事件损害了Intel声誉，但增强了“奔腾”品牌知名度。竞争对手AMD曾借此营销。事后Intel在奔腾Pro中引入可修补微码，便于未来类似问题的软件修复。

其他历史bug

• 386处理器：早期型号存在32位乘法错误，受温度/电压影响，Intel限制其仅用于16位市场。
• “F00F”错误：奔腾处理器执行特定指令序列会锁死，通过操作系统更新解决。

结论
FDIV错误揭示了复杂硬件设计中数学模型与实际实现间的细微差异可能引发重大缺陷。尽管该错误概率极低且影响有限，但其象征意义推动了处理器验证流程与错误响应机制的改进。

摄影师背景 芭芭拉·伊维恩斯（Barbara Iweins）是一位比利时摄影师，艺术生涯始于阿姆斯特丹。她自幼便是一名收藏家，始终致力于根据严格标准对摄影对象进行分类、收集和归档。她的作品常关注人类的脆弱性，并探索亲密关系的边界，代表作包括《街角》《早上七点/晚上七点》和《沐浴》等系列。返回布鲁塞尔后，她隐居生活，专注于其新项目《目录》（KATALOG），这是她首次以私人生活为研究案例。

项目《目录》详情

• 起因与动机：2015年经历多次搬家和突然离婚后，伊维恩斯带着三个孩子回到布鲁塞尔，渴望稳定。她决定通过深入审视和记录个人物品，来对抗生活中的不确定性，满足自身的神经质收藏欲与对美学秩序的追求。
• 执行方式：在四年时间里，她逐房间、逐抽屉地拍摄、索引并分类家中的所有物品，包括女儿的破袜子、儿子的乐高玩具、个人情趣用品及药物等私密物品。
• 项目规模：共拍摄了 12,795件物品的12,795张照片，完整呈现了其生活空间的全部细节。
• 核心意义：该项目体现了她在混乱中寻找秩序、在平凡中挖掘美学的创作理念，也将私人生活彻底转化为艺术研究的素材。

这篇文章提供了在OpenBSD 6.4系统上从零开始搭建个人邮件服务器的详细步骤。其目标是创建一个稳定、安全的自托管邮件解决方案。

核心软件栈包括：

• 操作系统：OpenBSD
• SMTP服务器：OpenSMTPD（系统自带）
• IMAP服务器：Dovecot
• 邮件签名：DKIMproxy
• 垃圾邮件防护：Spamd（文中提及但尚未配置）

主要步骤如下：

1. 服务器准备：

   • 获取一个支持OpenBSD的VPS（如Vultr）。
   • 检查服务器IP是否在黑名单上。
   • 基础系统配置：更换软件源、打补丁、设置时区、安装必要工具包（vim, zsh等）。
   • 安全配置：修改SSH端口（非22）、创建普通用户、禁用root直接登录、使用doas进行权限管理。

2. DNS配置：

   • 设置域名的AAAA（IPv6）和A（IPv4）记录指向服务器IP。
   • 设置MX记录指向该域名。

3. TLS证书：

   • 使用OpenBSD自带的acme-client工具为域名申请Let‘s Encrypt证书，用于加密通信。

4. 配置OpenSMTPD (/etc/mail/smtpd.conf)：

   • 配置TLS证书路径。
   • 设置监听规则：标准SMTP（端口587，需认证）、本地监听（用于DKIM）。
   • 定义邮件动作：本地投递（至~/.mail目录）、直接中继、经DKIM签名后中继。
   • 设置匹配规则，将邮件根据来源和目的地路由到相应动作。

5. 配置Dovecot：

   • 解决系统文件描述符限制问题。
   • 设置邮件存储位置为maildir:~/.mail。
   • 配置SSL证书参数。
   • 启动并启用Dovecot服务。

6. 配置DKIMproxy：

   • 生成RSA私钥和公钥（存储在/etc/mail/目录下）。
   • 配置DKIMproxy_out (/etc/dkimproxy_out.conf)，指定监听地址、中继地址、签名域名、密钥文件和选择器。
   • 启动并启用服务。公钥需添加到域名的DNS TXT记录中以完成验证。

7. 垃圾邮件防护 (Spamd)：

   • 文章作者提及此组件，但表示尚未在此配置中使用。

整个指南是作者为自用整理的备忘录，旨在为其他有相同需求的用户提供一个可复现的参考流程。

Duplex Web应用摘要

Duplex是一个Web应用，旨在为用户提供阅读拉丁文本的功能，并支持内联翻译。该应用基于现代HTML5标准构建，采用UTF-8字符编码，确保对多种语言和字符的兼容性。页面结构包括响应式设计（通过视口元标签实现）、自定义SVG图标、模块化JavaScript脚本（./assets/index-DC5mY_aK.js）和CSS样式表（./assets/index-D8_oEYVb.css），这些资源通过外部文件加载并设置了crossorigin属性以增强安全性。主体中的<div id="root">元素作为应用的主容器，表明这是一个单页应用，可能使用前端框架动态渲染内容，专注于拉丁文本的展示和翻译功能。整体设计简洁，旨在通过Web界面实现交互式文本阅读体验。

开源项目重新许可及其分支的影响研究

研究背景

许多流行的开源项目由单一公司拥有和驱动。在当前的经济压力下，这些公司面临更大的投资回报压力，一种应对策略是将项目重新许可为更严格的许可证以增加收入。这种重新许可有时会导致原项目的硬分叉，对使用和贡献这些项目的组织与个人产生干扰。

研究方法

CHAOSS项目研究了重新许可后开源项目组织动态的演变，比较了三个案例中的原始项目和分支项目：

• Elasticsearch与分支OpenSearch
• Redis与分支Valkey
• Terraform与分支OpenTofu

案例分析

Elasticsearch与OpenSearch

Elasticsearch：

• 原为Apache 2.0许可证，2021年2月重新许可为SSPL和Elastic许可证
• 重新许可前后，贡献者几乎全部是Elastic员工（超过95%）
• 重新许可对贡献者影响很小，但对用户影响较大

OpenSearch：

• 2021年4月从Elasticsearch分支，采用Apache 2.0许可证
• 初期由Amazon员工主导贡献（第一年占80-91%）
• 随着时间的推移，组织多样性逐渐改善
• 2024年9月转移至Linux基金会管理

Terraform与OpenTofu

Terraform：

• 原为MPL 2.0许可证，2023年8月重新许可为BSL
• 贡献者几乎全部是HashiCorp员工
• 重新许可对贡献者社区无实质影响，主要影响用户

OpenTofu：

• 2023年8月从Terraform分支，作为Linux基金会项目
• 贡献者完全来自新团队，无人曾贡献过Terraform
• 第一年有31人来自11个组织做出重要贡献
• Spacelift员工贡献超过半数，有一定组织多样性

Redis与Valkey

Redis：

• 原为BSD-3许可证，2024年3月重新许可为RSALv2和SSPLv1
• 重新许可前有显著的外部贡献者（来自多家公司的员工）
• 重新许可后，所有重要外部贡献者停止贡献

Valkey：

• 2024年3月从Redis 7.2.4分支，作为Linux基金会项目
• 由先前贡献Redis的人员推动，雇主公开支持
• 半年内有29名贡献者来自10家公司
• 18人曾为Redis做出贡献，组织多样性高

主要发现

1. 分支项目通常比原始项目具有更多的组织多样性，特别是当分支由中立基金会（如Linux基金会）托管时
2. 原始项目在重新许可后，外部贡献者往往会显著减少或消失
3. 组织多样性更高的项目通常更可持续，但尚不确定这些分支项目是否会长期成功
4. 这些项目的最终成功与否仍不确定，特别是考虑到公司持续面临投资者期望的压力

未来研究方向

CHAOSS数据科学工作组将继续扩大研究范围：

• 包括更多代码库和额外指标
• 可能扩展至其他重新许可后分支的项目
• 更好地理解这些项目的项目健康动态

该研究将于2025年2月在伦敦的State of Open Con会议上进一步探讨。

个人经历：与Forth及栈机器的渊源（2010）

本文作者讲述了与Forth编程语言及栈机器架构的亲身经历，其顺序是“先实现后使用”。文章开篇引用了Forth创始人Chuck Moore关于其VLSI设计工具仅用500行源代码的论述，突显了Forth的激进理念——它摒弃了语法、冗余、类型等传统编程要素，甚至没有文件系统和操作系统。

作者最初因读到Bruce Eckel对Forth“可扩展性”的描述而产生兴趣。阅读pForth源码时，他被Forth在编译期通过自修改代码定义注释词(和条件结构IF/THEN的能力所震撼。Forth代码以“执行令牌”数组的形式存储，解释器通过操作指令指针、数据栈和返回栈来运行。编译过程直观，例如: DRAW-RECTANGLE 2DUP UP RIGHT DOWN LEFT ;直接将函数地址追加到代码数组中。

作者深入探讨了CREATE/DOES>，这是用于“定义定义词”的机制。例如，用它定义CONSTANT、C语言风格的结构体乃至简单的对象系统，展示了Forth元编程的极致简洁。这些能力最初让作者着迷。

然而，作者随后将Forth搁置，认为它更适用于数值计算/系统编程，而脚本语言更容易作为进入组织的“特洛伊木马”。引用Forth社区成员Jeff Fox的批评，作者承认自己可能只是Forth的“解剖者”，而非真正用它解决实际问题。

后来，作者参与了一个接近Forth级DIY的项目：设计自定义硬件、操作系统和编译器。为配合项目中一个特殊的VLIW图像处理协处理器，他们决定设计一个栈机器CPU。作者在几小时内定义了其指令集，使其能直接映射到Forth单词。

作者为该栈机器编写了一个精简的Forth交叉编译器（约700行C++），但舍弃了所有迷人的元编程特性，仅保留基本冒号定义、RPN语法和内置控制流。编写实际程序的经历却极其痛苦。即使采用小定义进行分解，代码中仍充斥着DUP、SWAP、PICK等栈操作指令和大量注释来跟踪栈状态。作者发现，尽管栈能高效处理表达式树，但对于需要重复使用值的表达式图（即a dup b + *），代码会变得杂乱。

最终，作者转向了LLVM和C。优化的C后端生成的代码质量很快超过了手写Forth。这标志着该项目上Forth应用的终结。

文章最后反思了Forth哲学。作者指出，Forth的本质是追求最小、最简、最优系统的工程方法，通过尽可能削减需求来实现。其元编程的简洁性源于此。然而，这种方法要求同一人或紧密协作的小组同时精通问题域、软件和硬件，进行跨层全局优化。作者认为自己不具备这种能力，需要通过团队协作和妥协来工作，这不可避免会引入“垃圾”。

作者依然欣赏Forth，认为在资源受限的环境下，它在实现功能密度上仍无与伦比。但他无法采纳Forth那种要求彻底重构问题和算法的解决问题方式。文章以Jeff Fox的评论和对一次关于colorForth讨论的提及作为更新结束，再次强调了“活”的应用与“死”的代码研究之间的区别。

本文探讨了在数字化时代信任软件的困境与必要性。虽然安全专家认为“信任”在安全领域是个问题，但用户几乎无法避免要信任软件供应商。

核心困境

1. 验证的复杂性：用户几乎无法独立验证设备上运行的软件或下载的软件是否恶意。即使是开源软件，审查数百万行代码以寻找漏洞或恶意代码也极不现实。
2. 供应链风险：软件从源代码到用户手中的过程涉及多个第三方（如代码仓库、构建系统、内容分发网络），每个环节都可能被篡改。
3. 供应商的潜在恶意：最坏情况是供应商本身恶意，例如在加密通讯应用（如iMessage、Signal）中植入后门，而用户因信任其安全承诺而使用，却无法验证其是否如宣传所述工作。

现有的安全措施及其局限

1. 代码签名：操作系统通过签名验证软件来源，可确保软件来自声称的发布者。但问题在于：
   • 依赖用户检查发布者身份，而用户通常忽略警告。
   • 无法防止恶意发布者用自己的有效证书签名恶意软件。
   • 主要提供来源验证，而非安全性保证。
2. 应用商店与自动更新：
   • 应用商店（尤其在移动端）提供集中分发和审核，增加了用户信任的单一对象，但也使平台商成为单点信任方。
   • 自动更新利用首次安装时建立的信任，后续更新通过签名验证，但信任基础仍然是首次安装的发布者。
3. 包管理器（用于开源软件）：简化了安装，但使得包仓库服务器成为关键的信任点。尽管使用安全传输，但若仓库本身被攻破或账号被盗，仍可分发恶意软件。目前主流包管理器普遍缺乏真正保护用户免受仓库攻击的包签名机制。

迈向可信软件的长期方案

业界提出了一个旨在减少对供应商信任的“三部曲”路线图：

1. 可审查的源代码：允许第三方审查代码功能。但挑战在于：
   • 代码量巨大，审查耗时且需要专业知识。
   • 恶意代码可以隐藏为难以发现的漏洞（尤其在不安全的语言如C/C++中），而非明显恶意功能。
   • 依赖社区或付费审计，无法保证全面覆盖。
2. 可重复构建：确保从同一份源代码独立编译出的二进制文件与官方发布的完全一致。这需要解决编译过程中的非确定性因素（如时间戳、依赖版本、优化选项）。若实现，则第三方可验证官方构建未被篡改。
3. 二进制透明：类似“证书透明”，发布者将每次发布的二进制文件的哈希值记录到公开的、可审计的日志中。用户和审计者可验证其下载的文件在日志中存在且版本一致，从而防止供应商向不同用户分发不同的恶意构建（针对性攻击）。目前该技术尚处早期，应用有限（如Google为Android系统、Facebook为WhatsApp应用部署了相关系统）。

不同场景的挑战

• 移动应用：应用商店模式虽便捷，但用户必须完全信任平台商（如苹果、谷歌），且其系统封闭性可能限制用户自由。
• Web应用：浏览器作为可信计算基础，但Web应用交付的个性化、频繁更新以及依赖第三方脚本（如广告）等特性，使得验证“所有人获得相同程序”变得极其困难。Facebook的“Code Verify”浏览器扩展是一个初步尝试。

结论

尽管存在开源、代码审计、可重复构建和二进制透明等改进方向，但当前技术无法完全消除信任需求。用户运行他人编写的软件，就不可避免地需要信任包括供应商在内的多方。作者指出，应警惕任何声称能完全消除信任的方案，但强调仍有改进空间。在现有技术框架下，信任软件供应商（尤其是在没有可靠替代方案时）是数字生活中一个不可避免的现实。

New Glenn火箭发动机测试成功，为首次轨道发射铺平道路

测试关键信息 Blue Origin公司成功完成了其重型运载火箭New Glenn的最终重大地面测试。在佛罗里达州海岸有雾的条件下，公司于周五第五次尝试后，成功点燃了火箭的七台主发动机。本次动态点火测试的总时长为24秒，其中发动机在13秒内以全推力运行。

里程碑意义 此次成功测试被项目高级副总裁称为“纪念碑式的里程碑”。它验证了New Glenn火箭的推进系统设计与制造已达到预期状态，是公司近25年历史中，首次实现轨道级火箭发射准备就绪的最后关键一步。这为New Glenn在卡纳维拉尔角太空军基地36号发射复合体进行的首次轨道发射尝试扫清了障碍。

发射许可与时间表 在发动机测试进行的数小时前，美国联邦航空管理局（FAA）向Blue Origin颁发了为期五年的发射许可证。该许可授权New Glenn从卡纳维拉尔角执行轨道任务，并允许其尝试在大西洋的驳船上进行第一级回收。尽管官方未公布具体日期，但根据航行通知信息，首次发射最早可能于2024年1月6日进行。

公司背景与紧迫感 此次测试安排在圣诞节假期后仅两天进行，反映了公司内部注入的紧迫性。背景是，Blue Origin创始人杰夫·贝索斯在2023年秋季对公司领导层进行了重大调整，任命长期亚马逊高管戴夫·林普接替首席执行官职务，以加速推进包括New Glenn在内的关键项目。

这篇文章的作者基于其四十年的企业应用开发经验，明确表示不采用领域驱动设计（DDD）的核心实践，并阐述了其个人方法论与RADICORE框架的设计哲学。

作者的核心立场与对DDD的批评： 作者不将DDD的建议视为必须遵守的“规则”，而是选择性采纳或忽略。他认为DDD的许多概念（如聚合、工厂、仓储、CQRS、复杂的对象关联与继承体系）是面向对象理论的产物，而非从构建大型数据库驱动应用的实际经验中总结而来，它们会增加不必要的复杂性，降低开发效率。

作者的个人方法论与RADICORE框架的特点：

1. 以数据库为中心的设计：坚信“明智的数据结构和简单的代码”原则，认为数据库设计比软件设计更重要。采用标准的“收集需求-分析-设计”迭代流程，且设计过程独立于最终的软件实现。
2. 分层架构与MVC：采用表示层、业务层、数据访问层的三层架构，并结合MVC模式。控制器、视图、数据访问对象均由框架提供，作为可复用的服务。
3. 为每个数据库表创建一个类：这是其核心实践。每个表对应业务层中的一个实体类，该类继承自一个抽象的基类。这实现了大量代码复用（公共的CRUD方法），并利用模板方法模式，允许子类通过“钩子”方法注入自定义业务逻辑。
4. 重视复用与生产力：通过抽象和识别系统中的“相似性”（如所有表相同的CRUD操作、SQL查询模式、HTML页面结构、验证需求）来构建可复用的框架组件。同时，通过配置文件、屏幕结构脚本等机制来处理“差异性”（如特定表的元数据、屏幕布局、自定义验证规则）。
5. 忽略的DDD实践：
   • 聚合与组合：不采用单一的聚合根类，而是将层级关系视为独立的父子表关系对，使用标准代码处理。
   • CQRS：认为将读写模型分离违反了封装原则，坚持一个实体类包含所有操作。
   • 复杂的类层次结构与“IS-A”关系：反对通过深层继承来表达“IS-A”关系，而是使用外键关联类型表来处理分类。
   • 工厂与仓储：认为在不使用聚合的情况下，工厂并非必需；仓储的概念也与其实现方式不符。
   • 接口：认为在PHP中，接口对于实现多态是冗余的。
   • 特定的命名规范：不遵循DDD倡导的、反映业务动作的方法名（如createCustomer），而是使用通用的insertRecord、getData等，以保持控制器的通用性和多态性。
   • Getters/Setters与个别属性：不使用单独的属性和访问器方法，而是通过数组传递数据，以实现松耦合。
6. 框架支持的其他特性：
   • 基于角色的访问控制（RBAC）：用于管理用户对事务的访问。
   • 审计日志：记录所有数据库更改。
   • 工作流引擎：基于活动的工作流。
   • 数据字典：用于生成表类文件和事务脚本。

总结： 作者认为，对于开发数据库驱动的企业应用，其以数据库表为核心、利用框架最大化复用、采用模板方法模式处理业务差异的方法，比遵循他所理解的DDD实践更直接、更高效，能显著提升开发生产力。RADICORE框架便是这一理念的具体实现，旨在通过标准化处理共性（表结构、CRUD、SQL、HTML生成等）和简化差异性处理，来快速构建和运行企业应用。