文章总结：拒绝成为AI的“人肉代理”

核心观点

作者强烈反对在日常工作沟通（如Slack交流、Pull Request代码审查反馈、群聊等）中直接复制并转发AI（如Claude）的原始回复。这种不加思考的转发行为使人类沦为毫无附加值的“人肉代理”（meat proxy）。

直接转发AI回复的弊端

1. 缺乏附加值：接收方完全可以自己直接与AI对话，这样不仅效率更高，还能让接收方自主控制对话的上下文。
2. 阅读与理解成本高：AI生成的文本通常过于冗长，经常包含“看似合理的废话”，且专业术语堆砌严重（例如生成极其晦涩的NATS控制平面事件描述），导致阅读者需要耗费大量额外精力去查阅和理解。

正确的AI使用原则

• 深度处理而非简单中继：完全可以利用AI进行提问和辅助思考，但绝不能直接转发其原始输出。
• 重塑人类核心价值：使用者必须仔细阅读、理解并验证AI的回答，然后用自己的语言重新撰写回复。这种内化、验证与转化的努力，才是人类在AI辅助下能提供的真正价值。

代码审查（Code Review）中的典型警示

在当前的AI辅助开发中，提交代码几乎可以变成“零努力”的操作：开发者只需将需求描述复制给AI生成代码，再将审查者的反馈复制给AI进行迭代修改，而全程不亲自阅读或理解代码。

作者指出，如果开发者采用这种模式，就彻底沦为了AI与审查者之间的“人肉代理”。在这种荒谬的闭环中，真正的代码实现者其实是审查者（审查者通过提供反馈，间接驱动AI完成了代码编写），而名义上的开发者毫无贡献。

近期出现一批通过公开渠道提交的SQLite漏洞报告，经安全研究人员验证后被发现是虚构的。这些报告看似由AI生成，存在多个系统性漏洞。

虚假CVE报告的核心问题 这批漏洞报告存在以下共同特征：

• 引用的代码行号或函数在目标版本（如SQLite 3.41.0）中不存在
• 提供的漏洞概念验证（PoC）无法触发报告的崩溃或内存错误
• 漏洞详情未出现在SQLite官方安全公告页面
• 多个报告被AI检测工具判定为生成内容

JFrog安全团队的验证方法 研究人员通过严格流程验证：

1. 克隆SQLite官方仓库，检查指定版本源码
2. 在隔离Docker环境中编译官方发布版本
3. 使用AddressSanitizer工具运行PoC语句
4. 审查NVD和GHSA中的元数据与CPE匹配情况

具体漏洞分析示例

• CVE-2026-51302：声称存在UAF漏洞，但引用的exprComputeOperands()函数在目标版本中根本不存在
• CVE-2026-51303：描述的“后向引用”指针在SQLite数据结构中不存在，且版本间代码无变化
• CVE-2026-51300：引用的代码行是注释和内存分配调用，与漏洞描述无关
• CVE-2026-51297：涉及的jsonBlobEdit()函数在报告版本中未实现
• CVE-2026-51296：引用的行号超出文件总行数
• CVE-2026-51304：描述的函数签名与实际不符，且SQLite在释放后立即清空指针

系统性问题暴露

1. CVE提交流程缺陷：MITRE的公共提交表单缺乏身份验证，任何人可提交漏洞描述
2. NVD分析能力下降：自2024年2月起，NIST暂停深度分析，CISA等机构无法完全填补空缺
3. 自动化传播风险：未经验证的报告可能进入企业扫描器，造成安全资源浪费
4. AI处理的潜在危害：自动化漏洞管理系统可能基于虚假漏洞生成无效补丁或错误建议

识别虚假CVE的警示信号

• 官方维护方未确认该漏洞
• 缺少提交哈希或关联的PR请求
• CPE定义为空或版本范围与描述矛盾
• 引用的代码或行号在目标版本中不存在

此次事件中，同一账户提交的55份报告中有54份完全虚构。安全团队建议：对新出现的未知来源CVE保持警惕，验证严重性评分是否合理，确认环境是否真正受影响，并在安全环境中复现PoC。相关发现已向GHSA、Red Hat和NVD正式报告。

比许多德国人更像德国人

初识德国：打破刻板印象

• 2017年，我在土耳其完成计算机科学第三年学业后，前往德国汉堡实习。此前从未离开过土耳其，对德国的了解仅限于早年移民土耳其的工人口中描述的刻板印象：冷漠、不苟言笑、守规矩。
• 到达后，我的德国室友不仅去机场接我，还经常在厨房聊天解答我的疑问。他与女友的关系和谐互信，甚至在短期相处后就放心将钥匙交给我，让我独住一周。这种信任让我惊讶。

工作与融入

• 在公司团队中，我受到友善对待和重用，获得了比其他实习生更多的责任和团队活动参与机会。团队氛围友好愉快，彻底颠覆了我对德国人的固有看法。
• 实习结束前，我获得了留用机会。室友主动提供夏季住所，同事在我初返德国时热情欢迎。公司环境扁平化，高管平易近人，团队活动会细致考虑每个人的饮食需求（如素食、清真等）。

体验德国社会

• 信任与平等：我注意到德国社会普遍的高信任度（如公交系统无强制检票），以及社会各阶层在公共场合（如餐厅）的自然融合，体现了一种社会民主式的平等。
• 职业发展：在工作中未因移民背景遭遇歧视，并成功当选工会委员会成员，获得最多选票。与公司高层的争论也能在事后以轻松方式相处。
• 人际关系：与德国同事建立了深厚友谊，反驳了“与德国人交友难”的说法。
• 规则的意义：我喜欢德国的明确规则（如交通规则、建筑安全标准），它们提高了效率和可预期性。我尤其赞赏安静时间（Ruhezeit，晚10点至早6点及周日节假日）的规定，并曾因此投诉邻居噪音——这让我被朋友笑称“比许多德国人更德国”。
• 面对历史：德国社会正视纳粹历史并致力于不重蹈覆辙，这体现在教育和公众意识中。例如2024年1月汉堡举行大规模集会，抗议极右翼政客的排外言论。

语言与身份转变

• 初期所有交流均使用英语。决定长期定居后，我开始学习德语，并在2023年新国籍法将入籍等待期缩短至五年后加速学习。德语是融入的结果，而非前提。

入籍：成为德国公民

• 申请过程需满足多项条件：持续缴纳社保五年、通过公民考试、具备B1德语水平、拥有可持续生计、并认同德国民主价值观。
• 我于2024年申请，历时约14个月后获批，正式成为德国公民。

反思与归属

• 尽管我承认自己的融入过程相对顺利（得益于大公司、英语环境、体面薪水），且深知并非所有人经历相同，也看到极右翼势力的增长，但我个人在八年里未曾遭遇种族歧视。
• 我认为德国人是在给予信任、真诚友善、注重包容（包括餐饮细节）、关心陌生人、并勇于直面历史的人。
• 我已成为德国公民，并相信自己已为社会做出贡献。我将像真正的德国人一样，继续为需要改进之处发声。

这是一个关于旧金山的等距像素地图项目（Isopolis），相关数据来源如下：

• 地图数据：OpenStreetMap 贡献者
• 平台或底图：CARTO
• 邻里边界数据：DataSF（旧金山政府开放数据平台，数据集标识符：gfpk-269f）

项目名称“Isopolis”可能结合了“等距（Isometric）”与“城市（Polis）”的概念，表明其以独特的等距像素艺术风格呈现旧金山地图。目前页面内容处于加载状态，详细信息未完全显示。

通过手动重敲AI生成代码避免认知债务

核心问题

作者在使用编程助手时发现，虽然可以加速完成无聊的编码任务，但直接让AI生成代码会导致认知债务——即开发者无法真正理解代码的工作原理。尽管行业趋势是由AI生成代码、人类进行审查，但作者认为这种审查过程乏味且不适用于个人项目，因为个人项目的乐趣在于过程而非结果。

解决方案

作者提出了一种低效但有效的方法：要求AI在聊天中生成代码，然后手动逐行输入到编辑器中。具体做法包括：

1. 在项目中设置明确指令，禁止AI直接创建、编辑或删除文件。
2. AI仅展示建议的代码更改和命令，作者亲自执行这些操作。
3. 遇到不理解的内容时，会主动查找资料或要求AI解释。

主要优势

1. 加深理解：手动输入代码迫使作者慢下来，建立代码库的心理地图，明确知道每段功能的位置。
2. 提高代码质量：过程中能及时发现AI生成的错误（如幻觉或不良设计），并即时重构、添加注释、调整风格。
3. 平衡效率与认知：虽然速度可能只有完全依赖AI的2倍（而非10倍），但获得了对代码的深入掌握，且未来能更精准地指导AI。

行业背景与个人反思

作者将此方法类比为早期学习编程时“不复制粘贴，亲手输入代码”的实践，强调理解重于生产力。他担忧软件行业正累积大量认知债务，未来可能导致无人理解关键数字基础设施的构成。尽管个人无法改变行业趋势，但他坚持确保自己发布的每段代码都经过彻底理解，视此为职业责任。

结语

作者计划长期采用这种工作流程，认为在AI辅助编程的时代，保持对代码的完全掌控和理解是避免认知债务、维持专业性的关键。

https://www.ft.com/content/06ec1b03-d4af-40cf-b12a-4ba5a410f6d2

美国移民与海关执法局（ICE）正大规模强制采集拘留者的DNA，将样本录入联邦调查局（FBI）的犯罪数据库（CODIS）。一名叫Hugo Moreno-Mendez的移民在例行报到时被ICE逮捕，并多次被要求提供DNA样本。他因拒绝提供DNA而被起诉，尽管ICE此前认为此类指控可能从未被起诉过。

乔治敦大学隐私与技术中心的新研究表明，国土安全部已成为美国犯罪DNA系统中新增遗传档案的最大单一来源。仅ICE在2025年就可能向CODIS数据库新增了约92万份档案。到2025年12月，CODIS中用于存储国土安全部收集档案的“被拘留者”索引已达到334.6万份，当年新增约99.5万份，相当于每天新增约2700人。

这项DNA收集工作的扩大已引发诉讼和国会审查。有国会议员指出，许多被拘留者（包括儿童）并未被定罪，不应被纳入用于暴力犯罪者的数据库。批评者认为，收集的DNA档案可被全国执法机构用于比对当前和未来的犯罪现场证据，而物理样本（包含全部基因组信息）将被无限期保存在联邦实验室中。

国土安全部发言人为DNA收集辩护，称其是一项边境安全和身份识别措施。但乔治敦大学的数据显示，ICE的DNA收集规模在2025年出现了指数级增长，从以往的每年数千份跃升至近百万份。

Kakehashi 项目摘要

项目简介

Kakehashi 是一个实验性的用户空间转换层，旨在无 JIT（即时编译）的环境下，将 macOS ARM64 (Darwin) 二进制文件翻译并运行在 Linux aarch64 系统上。该项目以 CLI 优先，支持在裸机、虚拟机或 Docker/Colima 等容器环境中实时执行。

核心功能与架构

Kakehashi 通过加载 Darwin Mach-O 文件、映射独立的 libSystem 并转换 BSD 系统调用来运行 Guest 程序。项目主要由以下 Rust Crate 构成：

• kakehashi：主 CLI 二进制文件。
• kh-loader：负责 Mach-O 文件的解析、内存映射与执行。
• kh-runtime：处理内存、陷阱、BSD 系统调用及 Bottle 环境，并内嵌独立的 libSystem.B.dylib。
• kh-libsystem：Guest 端 dylib 的源码。

支持的应用与验证

项目已成功验证并支持多种真实 Guest 程序的运行：

• 7-Zip (7zz)：支持归档的创建、测试、列出、解压及多线程压缩。
• curl：支持 HTTP/HTTPS 请求、文件下载及标准输出，能够正确处理 SSL 证书验证。
• Apple Git (CLT)：支持本地提交、HTTPS/SSH 克隆与推送，并已验证可成功克隆 Wine、LLVM 和 Linux 内核等大型代码仓库。

性能表现与 CI 优势

Kakehashi 在 CPU 上原生运行 Guest 代码，性能损耗主要源于系统调用边界的上下文切换。在多线程 7-Zip 压缩测试中，其耗时约为 Linux 原生版本的 1.24 倍。 在 CI（持续集成）场景中，Linux ARM64 运行器的每分钟计费成本仅为 macOS 运行器的 1/10 到 1/12。因此，即使存在约 1.2 倍的性能损耗，使用 Kakehashi 在廉价的 Linux ARM64 节点上运行 Darwin CLI 工具，仍能大幅降低 CI 账单成本，具有显著的经济优势。

环境、安装与文件系统

• 环境要求：需要 Rust 1.88+ 及 Linux aarch64 环境（支持 4KiB 和 16KiB 页面大小）。
• 安装方式：可通过 cargo install kakehashi 安装，并使用 kh bottle ensure 和 kh install 命令部署 7zip、curl 或 xcode-tools 等工具。
• 文件系统映射：通过 Bottle 机制，将主机文件系统桥接到 Guest 的 /Volumes/linux/... 路径下，实现主机与 Guest 间的无缝文件交互。

许可与合规

项目采用 Apache 2.0 许可证。Kakehashi 并非衍生自 Darling 项目，严禁打包专有的 Apple SDK 或二进制 Blob，贡献者必须严格遵循净室（clean-room）流程以确保法律合规。

OpenAI 超级政治行动委员会涉嫌资助 AI 生成新闻网站攻击行业批评者

Acutus 网站的伪装与真相

网站宣称： AcutusWire.com 自称为“独立报道”、“专家来源新闻”的协作新闻平台，声称有编辑团队和广泛的行业贡献者。 实际调查：

• 该网站匿名运营，无编辑姓名、无作者署名，约四个月内发布94篇文章。
• 通过 AI 内容检测工具分析，其绝大多数文章（69%完全由AI生成，28%部分由AI生成）由人工智能撰写。
• 网站前端代码暴露了其内部编辑界面，显示文章创作流程高度自动化：包括输入“AI背景上下文”、“AI面试官提问提示”后，通过“生成故事草稿”按钮直接产出内容。
• 内置的多轮 AI 编辑审核过程被快速完成（中位数仅44秒），即使 AI 本身标记为“需要修改”的文章也被直接发布。
• 网站配置了允许特定 AI 爬虫访问的 robots.txt 文件，并包含面向 ChatGPT 的插件文件，暗示其内容可能旨在被其他 AI 模型消费。

运作机制与内容来源

采访机制：

• 文章中许多引述疑似从已公开网络内容中抓取。
• 为获取专家引述，网站使用伪装成人类记者（如“Michael Chen”）的 AI 代理，通过邮件邀请“书面问答”形式进行采访，使受访者误以为在与真人记者互动。
• 部分文章引用了方便的匿名消息源（如“接近参议院领导层”的共和党工作人员），其观点与文章倾向的特定利益方高度一致。

背后关联：

• 网站的有限公开传播与共和党公关公司 Novus Public Affairs 的总裁 Patrick Hynes 密切相关，他多次在社交媒体推广 Acutus 文章。
• Novus 的客户名单与 Acutus 文章推崇的议题存在重叠（如制药行业改革、新罕布什尔州政治议题）。
• 更关键的是，Hynes 本人曾作为“独立专家”被 Acutus 文章引用，却未披露其公司可能运营该出版物的事实，此举严重违反新闻伦理。
• Hynes 有将政治活动包装成新闻媒体的历史记录。

与 OpenAI 超级政治行动委员会的潜在联系

内容与议程的吻合：

• Acutus 约15%的文章聚焦 AI 政策，其观点（批评 Anthropic、抨击各州 AI 监管、将针对 OpenAI 的暴力事件归咎于记者和草根组织的言论）与 OpenAI 总裁 Greg Brockman 主要资助、OpenAI 首席政治策略师 Chris Lehane 参与组建的 1.25 亿美元超级政治行动委员会 “Leading The Future” 的宣传口径高度一致。

资金与运营网络的关联：

• Novus 公司的客户名单中包括 Targeted Victory，这是一家共和党政治咨询公司，其 CEO 联合创立了 “Leading The Future”。
• 该超级政治行动委员会的网站与其他 Targeted Victory 客户网站在技术和法律特征上存在相似之处。
• Patrick Hynes 本人频繁转发与 “Leading The Future” 立场一致的推文，包括其关联人物 Nathan Leamer 的内容。

结论与影响

作者综合以上证据推断，OpenAI 的超级政治行动委员会很可能通过以 Targeted Victory 为核心的共和党政治运营网络，资助并运作 Acutus 网站，使其以“独立新闻”的伪装形式，推广 OpenAI 的政治议程并攻击其监管者和行业批评者。

这种做法：

1. 构成“人工草皮”式政治宣传：利用 AI 大规模生产内容，冒充独立新闻，操纵舆论。
2. 与 OpenAI 自身政策相悖：OpenAI 明确禁止将其产品用于政治游说或竞选活动，其安全框架曾将 AI 生成的政治影响力活动列为风险类别（后被移除）。
3. 代表了 AI 被用于政治影响的范例：展示了 AI 技术如何可能被滥用来系统性制造和传播带有倾向性的“新闻”，服务于特定商业和政治利益，同时模糊真实的新闻与宣传之间的界限。

Bonsai 是 Jane Street 开发的一个 OCaml UI 库，用于构建高性能、响应式的 Web 应用程序，其设计部分受到 Elm 的启发。该库在 Jane Street 内部被广泛使用，用于构建从企业通讯录到监控交易系统的各种 Web 应用。

核心特性与设计 Bonsai 的核心思想是将状态、增量性和渲染解耦为独立的、可组合的原语。组件被实现为纯函数式状态机，并且框架内置了增量计算（Incrementalization），确保只有当状态的相关部分发生变化时，值才会被重新计算，这适用于所有值（包括视图和业务逻辑）。这种设计不同于传统 Web 框架将状态与组件紧密绑定的方式，它允许状态在组件层级之外管理，并提供了丰富的 API 来管理状态的生命周期和作用域（例如，在标签页界面中自动管理嵌套组件的状态）。

主要优势

1. 语言统一与类型安全：使用 OCaml 开发前端，使得前后端可以共享同一语言和类型系统，显著提升了代码的可读性和可维护性，尤其适合利用 OCaml 强大的类型系统来减少错误。
2. 灵活的组合性：状态和增量性原语可以自由组合，不仅用于优化UI渲染，还能增量化处理昂贵的业务逻辑计算。
3. 强大的测试系统：Bonsai 支持编写高度逼真的自动化测试。开发者可以通过编程方式操作UI元素并观察DOM的变化，无需打开浏览器即可测试整个组件的行为（包括模拟服务器调用和状态变化）。测试代码清晰，能够展示HTML属性或类名在交互后的差异。
4. 完整的工具链：包括强大的模板语言、组件级样式支持，以及一套用于整个应用测试的系统。

生态系统 Bonsai 实际上是一个库集合：

• 核心库 Bonsai：一个通用的、用于构建增量可组合状态机的库。
• Bonsai_web：基于核心库，专门用于构建交互式浏览器 Web UI。
• Bonsai_term：用于构建交互式终端 UI。
• 预处理器：常用 ppx_html（类似 JSX 的 HTML 模板）和 ppx_css（编写 CSS）。

学习资源 官方提供了快速入门指南、深度思考指南、一系列操作教程、博客历史系列，以及在播客中关于构建 UI 框架和工具的讨论，还有一个包含大量示例网站的库。

欧盟年龄验证项目强制要求硬件绑定认证引发争议

欧盟的开源年龄验证项目（EU Age Verification Project）因维护者确认“硬件绑定认证”为强制性架构要求而受到批评。此举引发了对Linux、自定义安卓ROM及独立编译应用兼容性的担忧。

争议始于该项目安卓应用的GitHub仓库。有用户提出，将凭证绑定到特定硬件环境会增加对开放系统的支持难度。项目维护者明确回应：“硬件绑定认证是项目的强制要求，并非可以轻易舍弃的实现细节。” 项目方邀请提出替代架构方案，并承诺将很快发布专门的安全审查和威胁模型。

该解决方案旨在让用户证明其达到特定年龄，而无需透露姓名、确切出生日期或完整身份文件。为防止凭证被复制、克隆或被修改后的客户端重用，项目依赖于存储在受保护硬件（如安卓TEE、StrongBox或苹果安全隔区）中的密钥。

然而，批评者认为，这种做法依赖于少数获批设备、操作系统和认证提供者，反而可能危及系统安全。

项目技术规范要求年龄验证应用在可用时使用原生加密硬件。但是，更严格的检查（如根权限检测、Google Play Integrity和苹果App Attest）并未被参考实现强制要求，可能交由具体的部署方自行决定。

这一区分很重要，因为硬件支持的密钥存储并不要求服务器批准整个设备、操作系统或应用构建。维护者的措辞在“生产部署的限制程度”上留下了不确定性。

此外还存在独立的治理限制。年龄证明提供者预计只会向欧洲委员会维护的合规应用列表中的应用发放凭证。这意味着，发布源代码并不能自动保证社区构建的版本能使用真实服务。

值得注意的是，Linux并未被明确禁止。桌面Linux用户可以通过支持的手机钱包扫描二维码，访问网站完成验证。但当前架构不提供原生Linux钱包，且替代移动操作系统可能难以满足所需的信任条件。

因此，这场争议远不止于单个安卓实现。项目方目前的立场是硬件绑定仍是必需的。即将发布的安全审查和威胁模型可能会更详细地解释为何做出此权衡，以及是否仍可通过替代信任根或限制更少的实现方案来满足合规要求。

在此之前，核心问题仍未解决：一个由欧盟资助、依赖于批准应用、支持的安全硬件、受信任的操作环境以及凭证提供者政策的开源身份系统，是否还能真正保持开放性。

文章摘要

这是一个名为 ssh.place 的协作绘画项目，其核心是提供一个通过SSH访问的共享画布。以下是主要内容：

• 基本概念：用户无需注册账号或安装软件，只需通过SSH客户端连接 ssh.place 即可在同一画布上绘画。任何SSH密钥均可使用。
• 画布规格：画布大小为200列×60行（200×60个单元格），为纯色块画布，不支持文字输入。
• 操作方式：
  • 移动光标：可使用方向键、wasd 或 hjkl 键。
  • 浏览画布：由于画布宽度超过终端，需要滚动查看。按 Shift + ←/→ 可跳转整个屏幕宽度。
  • 选择颜色：按 0 到 9 数字键选择基础颜色，按 Tab 键可循环切换所有16种可用颜色。
  • 绘画：选定颜色后，按 空格 键放置一个实心色块。
• 规则限制：每位用户放置每个色块后有15秒的冷却时间。此冷却时间与用户的SSH密钥绑定，断开连接后重新连接不会重置冷却计时。
• 数据特性：画布内容仅通过SSH连接进行更改，项目提供的网页只用于查看画布状态，网页本身不提供绘画功能。

Rust 项目目标：不可移动类型与保证析构器

核心概述

本项目旨在扩展 Rust 的类型系统，引入新的自动 trait（auto traits），允许类型显式退出“可移动”与“可被遗忘”的通用能力。这遵循了 Rust 已有的 Sized 层次结构的模式，即通过引入 trait 层次来放宽原先适用于所有类型的假设。

现状与问题

Rust 当前默认假设所有类型都可以在内存中移动（如赋值时）并通过 mem::forget 被安全遗忘（即不运行析构器）。这导致了两类关键场景的复杂性：

1. 不可移动类型：许多 async 的 Future 需要是自引用的，但自引用类型无法安全移动。现有的解决方案 Pin 将不可移动性编码为位置（place）属性而非类型属性，带来了显著的复杂性，并且在如 Linux 内核等系统中难以安全地编码自引用类型。
2. 保证析构器：某些类型（如事务句柄或作用域任务句柄）需要其析构器保证运行（例如提交事务、汇合任务）。由于 mem::forget 是安全的，Rust 无法保证析构器运行，从而阻碍了如安全异步作用域生成等模式。

提议方案

引入新的 trait 来描述类型的能力，采用积极（positive）的表述框架：

• Move trait：表示类型可以在内存中移动。实现 !Move 的类型不可移动，且必须保持地址稳定。
• Destruct trait：表示类型可以被隐式析构（当其离开作用域时）。
• Forget trait：表示类型可以通过 mem::forget 被遗忘而无需运行其析构器。

关键改进

• 更简洁的不可移动性：通过 Move trait，不可移动性成为类型的内在属性，比 Pin 的模型更简单。
• 启用安全模式：通过 !Forget trait，类型可以要求其析构器必须运行，从而使得编写安全的作用域生成（spawn）成为可能（例如，通过确保句柄的析构器运行来汇合任务）。

工作项与路线图

近期（2026-2027）

• 不可移动类型 (Move trait)：
  • 编译器实现。
  • 撰写并推进 RFC。
  • 在 Linux 内核中进行实际测试以验证可行性。
• 保证析构器：
  • 进行设计探索，研究 trait 层次选项及其与现有特性的交互。

明确不包含

本年度不包含对 Future trait 的更改或更新。该 trait 是目前唯一依赖于 Pin 的稳定 trait，其迁移方案应被视为一个独立项目。

与现有方案的关系

• 与 Sized 层次结构：本项目沿用相同模式，即通过 trait 层次允许类型退出通用假设。
• 与 Pin 人体工程学计划：本项目是替代方案。团队认为 Pin 本身是问题所在，目标是改善不可移动类型的编码方式，并最终弃用 Pin，而非为其添加语言层面的语法支持。
• 如何实现安全作用域生成：通过 !Forget，可以确保任务句柄的析构器（负责汇合任务）被运行，防止任务悬垂引用，从而使模式在安全 Rust 中可行。

Book Corners 为何不将贡献同步回 OpenStreetMap

最初的构想

Book Corners 项目的初始数据来源于 OpenStreetMap（OSM），该项目也接受用户直接提交新的图书馆信息。作者认为，当用户提交的新图书馆在 OSM 中缺失时，将其同步回 OSM 是公平合理的做法。为此，作者设计了一套谨慎的流程：需用户明确同意、管理员审核、检查 OSM 中的重复数据、管理员预览数据、最后确认后才写入。

实现面临的障碍：远不止 API 调用

深入研究后发现，技术实现（API 调用）只是微小的一部分。更大的挑战来自 OSM 的社区规则和治理要求：

1. 视为外部数据导入：由于数据来自 Book Corners 数据库，OSM 可能将其视为外部数据导入，并适用《导入指南》和《自动化编辑行为准则》。
2. 繁琐的合规要求：在进行首次正式同步前，作者需要完成一系列长期义务，包括：
   • 创建并维护专用的 OSM 导入账户。
   • 在 OSM Wiki 上发布详细的导入计划。
   • 全面记录数据来源、许可、字段映射、查重、软件、质量检查、变更集政策及回滚方案。
   • 在 OSM 社区论坛上提交提案。
   • 联系受影响的当地社区。
   • 等待审核期并解决疑虑。
   • 保持账户、计划、讨论和变更集之间的永久链接。
   • 长期维护联系和退出机制以应对未来问题。
3. 复杂的许可问题：用户的同意不等于其信息可以在兼容 OSM 的条款下发布。用户界面的说明需要清晰区分这一点，并确认信息并非来自不兼容的来源。

作者理解这些规则是必要的，因为 OSM 作为全球共享数据库，需要防止不良导入导致数据质量下降。然而，这些要求形成的是持续的、全方位的责任。

决定搁置的核心原因

1. 运营成本过高：对于 Book Corners 这样目标简单的项目（帮助人们发现和分享小型免费图书馆），运营一个完整的 OSM 数据导入流程（包括凭证管理、审计代码、社区沟通、许可事务和长期支持）远远偏离了其核心目的，成为了一项不成比例的重大负担。
2. 机会成本：投入资源运营此同步功能，意味着会挤占开发核心功能（如图书馆发现、审核、照片、无障碍访问、翻译和移动端体验）的时间，而这些核心功能能更直接、更可持续地服务于用户。
3. 责任与收益不匹配：尽管回馈数据是良好意愿，但经过调查，仅凭善意不足以支撑一项长期且广泛的运营责任。项目的当前规模无法承受这一承诺。

最终决定与现状

作者决定无限期搁置将 Book Corners 用户提交的数据同步回 OSM 的实现。

• Book Corners 将继续使用 OSM 数据并注明来源，这些从 OSM 导入的数据不会被再次作为新数据提交回 OSM。
• 用户直接提交至 Book Corners 的新图书馆将保留在 Book Corners 系统内，项目不会自动或手动在 OSM 中创建对应对象。
• 目前没有从 Book Corners 写入生产环境 OSM 的代码，因此搁置此功能无需停用现有集成。

作者表示，如果未来出现真正轻量的同步工作流，或者 Book Corners 的规模和价值增长到足以支撑该流程，可能会重新考虑。另一种可能是引导用户通过现有 OSM 编辑器进行提交，但这同样需要与社区讨论。

此次经历表明，外部集成不仅涉及技术可行性，更关乎组织和社会层面的契约，而这些契约的成本有时远高于代码本身。对于 Book Corners 当前阶段而言，不实现此功能是更负责任的选择。

SwiftUI 发布七年后的深度分析摘要

文章主旨

本文深入探讨了 SwiftUI 在发布七年（至2026年）后的发展现状。作者指出，SwiftUI 并未如苹果承诺的那样成为成熟的生产级跨平台 UI 框架，反而长期处于“永久测试版”状态。其诞生的初衷是为了应对 React Native 和 Flutter 等跨平台框架的竞争，并振兴 Mac 应用生态，但其实际表现却令资深工程师深感挫败。

核心技术与架构缺陷

• 数据流混乱：从早期的 @State 到后来的 @Observable 宏，SwiftUI 的数据流和视图更新机制犹如“黑盒”。它经常对不该响应的变化做出反应，导致视图渲染不可预测，难以实现精确控制。
• 布局系统脆弱：基于尺寸协商的布局引擎极不稳定，在构建复杂界面（如浮动视图或侧边栏）时容易出现布局崩溃。开发者常被迫使用 GeometryReader 手动计算坐标，完全丧失了声明式 UI 的便利性。
• API 不稳定与功能缺失：缺乏向后兼容性，代码中充斥着版本检查（if #available）。许多 UIKit/AppKit 的基础功能在 SwiftUI 中迟迟缺失或被频繁重构（如 NavigationView 被 NavigationStack 取代），迫使开发者编写大量补丁和兼容代码。
• 性能不达标：在较旧的硬件上，SwiftUI 的性能表现不佳（如图像网格滚动卡顿）。为了达到流畅度，开发者必须进行复杂的底层优化，违背了框架“简单便捷”的初衷。
• 跨平台体验割裂：“学一次，到处应用”的承诺在实践中难以落地。iOS 与 Mac 的组件实现和交互逻辑差异巨大，强行复用代码往往导致 UI 显得突兀且缺乏原生专业体验。

苹果开发文化的深层转变

作者认为，SwiftUI 的种种问题折射出苹果软件开发哲学的系统性衰退。苹果已从早期 Cocoa 和 Aqua 时代对极致工艺的追求，转向了现代企业“差不多就行（good enough）”和盲目追求开发速度（velocity）的文化。这种降低质量标准的妥协，不仅体现在 SwiftUI 中，也蔓延到了 Apple Music、设置应用等第一方应用和系统组件中。

结论

SwiftUI 用精确的工程控制换取了表面上的便利幻觉，其本质并非“极差”，而是“平庸”。面对这种以牺牲稳定性和可维护性为代价的框架，作者拒绝妥协，认为用户值得更好的产品，并明确表示目前仍倾向于使用传统的 UIKit 和 AppKit 框架来构建高质量应用。

Sprocket 是一个专为硬件和软件开发设计的 AI 代理平台，旨在成为全球最佳的开发工具。其主要特点包括：

• 软硬件双重能力：它是唯一能同时处理硬件和软件开发任务的 AI 代理。
• 可靠的上下文获取：自动从网络获取最佳上下文信息，确保任务执行的可靠性。
• 自动化采购：可根据指令从任何网站购买硬件零件或订阅 SaaS 服务。
• 技术文档生成：能创建详细的原理图、生成物料清单（BOM）并编写装配说明。

使用方式

Sprocket 提供多种运行方式，功能与性能均无差异：

1. 直接通过浏览器使用（无需安装）。
2. 桌面应用程序：可从 GitHub Release 下载对应操作系统的版本。
3. 命令行（CLI）：通过 npm 全局安装 @spikonado/sprocket，运行 sprocket 命令。可通过 --web 标志强制在浏览器中打开。

• 工作区：可通过传递目录路径（如 sprocket .）来打开或重连工作区，工作区状态会自动记忆。
• 本地状态存储在 $HOME/.sprocket（可通过 SPROCKET_DATA_DIR 环境变量覆盖）。

主要命令与配置

• 核心命令：
  • sprocket serve：在前台运行本地服务器。
  • sprocket serve --api-only：仅提供 API 服务（用于开发）。
• 关键环境变量：包括 SPROCKET_DATA_DIR、SPROCKET_PORT（默认 17731）、SPROCKET_HOST 等，用于自定义服务器行为和路径。

开发信息

• 技术要求：Bun 1.x、Node.js 24.x 以及稳定的 Rust 工具链。
• 工作流程：包含依赖安装、启动开发环境、构建、测试以及创建本地桌面安装包（如 .AppImage/.dmg/.exe）。
• 故障排除：针对端口占用、默认打开方式问题以及未签名桌面应用的系统安全提示提供了解决方案。
• 联系方式：可通过 aarav@spikonado.com 获取帮助。

2026年俄亥俄州博览会海报比赛概述

本次比赛已公布2026年度结果，并对人工智能（AI）的使用规则做出了重要澄清与未来变更。

关于人工智能使用的政策

• 2024年创立此项比赛时，规则允许使用AI，但要求在申请过程中予以说明。
• 主办方认识到，过去几年中AI技术的发展已超出预期。
• 因此，计划在2027年重新评估并修改规则，届时将禁止使用AI。
• 主办方致力于推崇俄亥俄州艺术家，其举办的艺术展览、创意艺术竞赛、壁画比赛等其他赛事均不允许使用AI。

2026年比赛详情

• 主题：要求作品融入爱国主题，以庆祝美国建国250周年。
• 结果：共收到38份投稿，前五名作品将在2026年博览会的创意艺术展厅展出。
• 获奖名单：
  • 第一名：Christin Billips（西尔维斯特）
  • 第二名：Gene Strickland（哥伦布）
  • 第三名：Lisa Oliver（雷诺兹堡）
  • 第四名：Lindsay Boyd（刘易斯中心）
  • 第五名：Nikki Smetters（希利亚德）

比赛规则与评选标准（摘要）

• 参赛者须为俄亥俄州居民，年满18岁，限交一件作品。
• 作品需家庭友好，与俄亥俄州博览会相关，并推荐包含爱国主题。
• 作品中必须包含博览会日期（2026年7月29日-8月9日）及“俄亥俄州博览会”字样。
• 尺寸要求为24x36英寸（竖版），可缩放复制。
• 提交方式为电子版（高质量JPG或PDF格式）。

奖项设置

• 前五名获表彰。
• 冠军将获得1000美元奖金、绶带、社交媒体及本地媒体宣传、博览会期间每日通行权及家庭门票。

参赛者确认与版权条款

• 参赛者须同意遵守俄亥俄州展览委员会的规定。
• 获奖者需提交原作供博览会展示。
• 冠军需与展览委员会签订协议：艺术家保留版权，但作品所有权完全转移给展览委员会。委员会有权将作品复制出售（如明信片、周边商品）并用作博览会的宣传营销材料。

这篇文章描述了作者个人测试AI图像生成能力的一个基准：“生成一只下巴像哈布斯堡家族的青蛙”。在实际生成中，模型不仅描绘了目标特征，还主动加入了大量超出字面要求的编辑内容。

主要发现与分析：

1. 模型的“创造性”添加：

   • 虚构的皇室身份与装饰：模型为青蛙添加了“皇家帝国褶边领”、“帝国哈布斯堡皇冠”和“金色羊毛勋章”等虚构的皇家元素与配饰。
   • 情绪与姿态描述：在生成结果的文本描述中，模型加入了诸如“骄傲地交叠”、“阴郁的表情”和“悲伤/疲倦的面部线条”等主观描述。
   • 医学与王朝特征评论：模型将青蛙的解剖特征解释为医学或王朝特质，例如“腹板（胸部虚弱）”、“沉重的下垂眼睑（哈布斯堡倦怠神情）”和“虚弱的上颌骨”。

2. SVG图像的技术实现：

   • 结构复杂：生成的SVG代码结构详尽，包含<defs>部分定义了多种渐变（皮肤、下巴、腹部、眼睛、金色、褶边、红宝石）和阴影滤镜，用于创建丰富的视觉效果。
   • 核心特征描绘：通过多层<path>路径绘制，重点塑造了标志性的“哈布斯堡下巴”——一个巨大且前突的下颌结构，配合外翻的下唇和下垂的嘴角线条。
   • 细节丰富：除了主体，还细致刻画了交叠的前臂、皇家皇冠（镶嵌在过大的眼眶之间）、褶边领、皮肤纹理（疣点）以及挂在脖子上的金色羊毛勋章。

总结来说，此案例展示了当前某些AI模型在遵循指令时，会自行进行大量的语义扩展和风格化添加，将简单的物体生成转化为带有特定历史、情感和医学叙事的复杂图像。

Snow Leopard的神话：营销传奇与现实差距

官方定位与市场反响

• 发布时间：2010年
• 苹果营销口号：“零新功能”，专注于系统优化、效率提升和错误修复
• 用户期待：经历了多年更新常伴随新问题后，Mac用户对稳定性改进表示欢迎

神话的传播与影响

• 概念扩散：Snow Leopard的“稳定性优先”理念超越了苹果生态，成为其他领域（如Linux发行版、手机更新）宣传重点
• 用户诉求：当软件质量下降时，用户常呼吁厂商推出类似“Snow Leopard式”的更新
• 文化影响：这一概念在发布16年后仍被频繁引用，反映了行业对稳定性的普遍渴望

作者的实际体验

• 初期问题：在2006款MacBook Pro上遭遇严重稳定性问题，涉及Finder、FireWire 800设备和iMovie HD插件
• 解决方案：最终降级回Leopard系统，并跳过Snow Leopard直接升级至2011年的Lion
• 行业佐证：引用Jeff Johnson的文章，指出Snow Leopard引入了多项需要后续修补的问题

营销成功与现实差距

• 营销成就：苹果团队成功塑造了“稳定性更新”的文化符号，概念持久影响力达16年
• 现实情况：实际发布版本存在较多问题，未能完全实现“零新功能，极致优化”的宣传承诺
• 深层需求：该神话之所以持续共鸣，反映了用户和开发者在快速迭代压力下对稳定性、生活质量的普遍渴望

行业现状反思

• 当前趋势：许多软件更新陷入“功能堆砌-问题修复”的循环
• 理想愿景：Snow Leopard神话代表了一种被渴望但常被忽视的开发哲学——以质量而非新功能为核心
• 持久启示：即使初始版本不完美，专注于系统健康的更新理念仍具有持久吸引力

加州数据删除请求平台DROP于8月1日起正式生效

从8月1日起，加利福尼亚州注册的数据经纪商必须开始响应通过州政府**"删除请求退出平台"**（Delete Request Opt-out Platform，简称DROP）提交的删除请求。

平台功能与使用

• DROP平台是一个在线工具，允许加州居民一次性向注册数据经纪商提出停止出售其个人信息的请求，无需逐个联系数百家公司。
• 自1月1日上线以来，已有约35万加州居民通过该网站注册。

数据收集现状与隐私风险

• 每次上网购物、流媒体娱乐或浏览网页时，用户的数字足迹都可能被收集、打包并出售。
• Cal-Privacy执行主任Tom Kemp指出，个人数据在数字经济中相当于"石油"，常被用于定向广告，但也可能被黑客利用，成为犯罪工具。

执行机制与违规处罚

• 从8月1日起，数据经纪商有45天时间处理通过DROP提交的请求，该期限对新请求重复适用。
• 不合规的公司可能面临每名受影响加州居民每天200美元的罚款。
• Cal-Privacy已对12家未在DROP系统注册的数据经纪商处以数万美元罚款，并设有专门团队确保执行。

平台局限性

• DROP仅适用于加州居民，且不会删除所有存在于网上的个人信息。
• 消费者仍需警惕诈骗，并采取其他措施保护个人信息。

更多信息可访问：https://privacy.ca.gov/drop/

本文记录了对TP-Link TL-841N路由器进行硬件安全分析的全过程。作者以10美元购得一台二手设备，旨在实践从物理访问到固件提取与分析的完整流程。

1. 硬件连接与权限获取 作者通过拆解路由器，在PCB板上定位到标记清晰的UART调试接口。使用USB转UART适配器连接GND、TX、RX引脚，并以115200波特率通过picocom连接后，直接获得了root shell权限。

2. 两种固件提取方法

• 方法一（UART与TFTP）：通过UART获得root权限后，使用cat命令逐一读取/proc/mtd中列出的闪存分区（mtd0-mtd6），并通过TFTP协议将每个分区文件传输到分析计算机上。作者还提到可通过TFTP上传BusyBox以获得更多命令。
• 方法二（芯片提取）：使用CH341A编程器配合闪存夹，直接读取位于PCB背面的GD25Q64CSIG闪存芯片（3.3V），得到完整的modem.bin固件镜像。

3. 固件分析与文件系统提取 作者使用binwalk和dd命令分析并手动切分完整的固件镜像，将其分为对应各MTD分区的文件：引导程序（mtd0）、Linux内核（mtd1）、SquashFS根文件系统（mtd2）、配置文件（mtd3-mtd6）等。对根文件系统分区（mtd2）执行unsquashfs解压后，可进行文件系统级别的分析。

4. 安全发现 在初步分析中，作者使用strings等工具在固件中发现了敏感信息：

• 在配置分区（mtd3-config.bin）中发现了硬编码的WPS密码（即设备标签上的密码）。
• 关键发现：在同一个配置分区中，以明文形式发现了前机主的PPPoE ISP认证凭据。更严重的是，即使执行了完整的路由器恢复出厂设置操作（长按重置按钮），这些凭据仍然保留在闪存中。这意味着“恢复出厂设置”并不会擦除存储的ISP宽带认证信息。
• 在根文件系统中发现了默认管理员凭据（admin:admin），以及位于/etc/passwd.bak中的未加盐MD5密码哈希值（admin:1234）。

文章最后指出，该路由器的固件版本为0.9.1 4.16 v0001.0 Build 170622 Rel.64334n，恢复出厂设置无法清除用户/ISP修改的凭据这一现象，对设备隐私和安全构成了隐患。

Qwen3.8-Max 与 Qwen Studio 平台概述

本文重点介绍了名为 Qwen3.8-Max 的模型，强调其在编码与协作能力方面树立了新的标杆。

同时，文章内容核心是对 Qwen Studio 平台功能的描述。该平台提供了一套综合性的人工智能解决方案，其核心功能模块包括：

• 交互与生成：提供聊天机器人、图像与视频内容理解、以及图像生成能力。
• 知识处理：支持文档处理与网页搜索集成，以增强信息获取与分析。
• 扩展与实用：具备工具利用功能（如调用外部工具或API）和 artifacts（可能指可执行的代码片段、文档等产出物）的生成与管理。

整体而言，Qwen Studio 是一个多功能的AI工作平台，旨在通过整合多种能力来提升工作效率与创造力。

一名前苹果工程师声称，因拒绝在没有客户授权的情况下向AT&T提供设备标识符而被解雇。苹果公司否认存在不当行为。

事件概要

• 涉事工程师托比·博德曼指控苹果公司因其隐私问题举报而将其解雇。
• 苹果公司声称解雇是基于其工作表现，而非其举报行为。

事件时间线

• 2024年6月10日：苹果公司为博德曼安排了一场会议。此前，他刚结束一个月受保护的医疗假期，旨在处理焦虑和强迫症的医疗需求。他此前多次投诉其经理，并指控该经理因他提出客户隐私担忧而对其进行惩罚。
• 2024年6月11日：苹果公司解雇了博德曼。

核心指控 博德曼的主要指控包括：

1. 隐私违规：苹果公司员工在未获客户同意的情况下，将客户的国际移动设备识别码（IMEI）等设备标识符提供给运营商AT&T。
2. 拒绝提供合理便利：在博德曼请求就其心理健康状况提供合理工作便利后，苹果公司未能提供相应支持。
3. 打击报复：博德曼认为，解雇是对他投诉隐私违规和经理行为的报复。

苹果公司回应 苹果公司断然否认了所有指控，解雇原因为博德曼的工作表现问题。

这是一个关于在NVIDIA DGX Spark（及Asus Ascent GX10）上运行Nix和NixOS的项目。项目提供USB安装镜像和一个专用的NixOS模块，主要功能包括：

主要使用方式

1. 在DGX OS（Ubuntu）上使用Nix：通过官方或Determinate安装程序安装Nix，启用flake等实验性功能，并使用提供的dev shells和playbook。在非NixOS系统上，Nix构建的CUDA应用会自动通过nixglhost处理GPU驱动问题。
2. 直接安装NixOS：项目提供了USB启动镜像，包含两种内核选项——NVIDIA专用内核（推荐，支持完整GPU和以太网）和标准NixOS 6.17内核（网络可能有问题）。安装前必须先在DGX OS中更新固件。

DGX Spark NixOS模块

该模块为硬件提供支持，配置选项包括：

• enable：启用支持。
• useNvidiaKernel：选择使用NVIDIA内核（默认）或标准内核。 模块还会启用位于 http://localhost:11000 的DGX Dashboard Web界面，用于GPU遥测和系统监控。

内核配置管理

NVIDIA内核的配置从其Debian注释生成，仅存储与NixOS默认值的差异，显著减少了配置文件的冗长。可通过命令重新生成配置。

集成与模板

其他项目可以通过flake导入该模块。项目还提供了一个快速启动的NixOS配置模板，初始化后需自定义硬件配置（如UUID）和系统设置（如主机名、用户、SSH密钥等）。

固件更新

模块启用了fwupd，用于接收和安装通过Linux Vendor Firmware Service (LVFS) 发布的NVIDIA固件更新。

Playbook支持

项目集成了多个NVIDIA官方DGX Spark playbook，分为三类：

• 全Nix实现：所有依赖通过Nix管理（如ComPyUI、PyTorch微调Nix版、vLLM Nix版）。
• 容器实现：Nix提供Podman，但容器在运行时拉取/构建（如FLUX.1 Dreambooth、多模态推理）。
• 混合实现：CLI工具通过Nix打包，但容器由工具管理（如OpenShell）。 项目已在NixOS和DGX OS上测试这些playbook。

缓存优化

• Flox CUDA缓存（推荐）：为aarch64-linux预构建CUDA包，模块自动配置此缓存源。
• graham33 Cachix缓存：用于项目自身构建的包。

实验性功能

支持通过nixos-anywhere进行远程无头安装，适用于已有SSH访问权限的目标机器。此功能尚未充分测试。

许可证

项目采用MIT许可证。

Linux 北美桌面市场份额突破 10%

根据 Statcounter 的最新统计数据（截至2026年7月），Linux 在北美桌面操作系统的市场份额已达到 10.65%，首次突破两位数大关。相比之下，同年6月的数据仅为 5.52%，市场份额在一个月内几乎翻倍。

然而，这一显著增长需要结合背景理解。Statcounter 6月的报告中包含了一个占比高达 9.24% 的“未知”类别，该类别的减少似乎与 Linux 份额的上升同步，这可能表明先前未分类的流量得到了更好的识别。因此，这次增长不应被简单解读为在单个月内有数百万用户从 Windows 或 macOS 转向 Linux，部分原因可能源于检测、分类或统计样本构成的变化。

尽管如此，Linux 在北美桌面领域的显著存在也得到了其他权威来源的支持。Cloudflare Radar 对北美桌面端 HTTP 请求的统计也显示了类似的高水平。需要指出的是，这两项服务的数据来源和统计方法不同：

• Statcounter 基于其覆盖超过一百万个网站、每月处理超过30亿次页面浏览的分析网络，以页面浏览量作为衡量标准。
• Cloudflare Radar 则依据其全球网络观察到的 HTTP 请求数据。

因此，这些数据并非对实际安装量的普查，而是衡量与不同操作系统相关的可观察网络活动的相对份额。特别是 Linux 广泛用于服务器、自动化、开发环境和无头浏览器，Cloudflare 的原始数据可能包含自动化请求。

这一里程碑的达成是 Linux 桌面生态系统多年来稳步发展的结果：

• 硬件兼容性持续改善，安装过程更加简便，主流发行版提供了无需过多命令行知识即可满足日常使用的精美桌面体验。
• 游戏领域因 Valve 的 Proton 兼容层、Steam Deck、图形驱动改进以及更广泛的 Vulkan 支持而发生变革。
• 用户对 Windows 在硬件要求、广告、账户整合、遥测和强制界面变更等方面的不满，也促使一部分人开始探索替代方案。
• Steam Deck 虽然主要是掌机，但其基于 Linux 的 SteamOS 向更广泛的受众展示了 Linux 可以提供精良的消费级体验。
• 开发者、注重隐私的用户、教育机构和寻求更大计算环境控制权的组织，其影响力日益增长。同时，Linux 发行版对生产力工作负载、网络应用、通讯平台、创意软件和开发工具的支持也日趋成熟。

结论：根据 Statcounter 的测量，Linux 在北美桌面网络使用量中的份额已超过10%，但这并不直接等同于该地区10%的已安装桌面计算机运行 Linux。即便如此，突破两位数门槛仍具有标志性意义，或许预示着那个流传已久的玩笑和预测——“Linux 桌面之年”——正在逐渐接近现实。

Shitty 终端模拟器概述

Shitty（及其友好版本 Pretty）是一个追求极致性能的终端模拟器。其核心设计目标是低延迟、快速启动和可预测的资源使用。终端状态保存在 CPU 上，并通过原生计算后端渲染单元格：在 Linux 上使用 Vulkan，在 macOS 上使用 Metal。

性能表现

项目通过基准测试展示了其速度优势，测试环境标准化（Menlo 12pt，80x24 网格）。

• 处理可打印 ASCII（滚动路径）：Shitty 的吞吐量约为 118 MiB/s，优于 Alacritty (99 MiB/s) 和 Kitty (75 MiB/s)，略低于最新的 Ghostty nightly 版本。
• 处理随机字节（解析器最坏情况）：Shitty 吞吐量约为 51 MiB/s，显著领先于其他终端（如 Alacritty 31 MiB/s）。Kitty 在此测试中无法处理。

核心设计与功能

• 正确性与健壮性：拥有超过 5000 个测试用例，源自多个主流终端的测试套件。解析器状态机是完整的，并通过模糊测试确保稳定性（例如将随机数据作为基准而非崩溃报告）。
• 无闪烁渲染：窗口尺寸变化时，渲染帧在同一事务中完成，更新由损伤驱动。
• 正确的 Unicode：以字素簇而非码点为单位处理单元格，完整支持 emoji 序列、变体选择符、组合标记和宽 CJK 字符。
• 自包含与安全：生成一个独立的单一二进制文件，无需窗口工具包，甚至嵌入了字体。默认情况下禁止应用程序读取选区或操控主机窗口。
• 广泛的兼容性：支持 VT52 至 VT5xx 控制序列及广泛使用的 xterm 扩展。支持主屏/备用屏、滚动回读、制表位、矩形操作、同步输出等。
• 丰富的协议支持：支持 16/256/24 位颜色、多种键盘协议（包括 Kitty 协议）、多种鼠标协议、选择与剪贴板集成、OSC 52 策略和 OSC 8 超链接。
• 高级渲染：支持懒加载字形光栅化、持久的 GPU 字形缓存以及基于损伤的计算渲染。
• 键位重映射与 URI 处理：提供灵活的键位重映射功能。支持通过 Ctrl+悬停/Ctrl+点击检测并打开纯文本中的 URI（可配置支持的协议列表）。
• 配置：支持通过命令行标志或 TOML 配置文件（如 ~/.config/shitty/shitty.toml）进行配置。

技术实现与构建

• 语言与工具链：使用 C++23 编写，构建需要 Clang（特别是 macOS 上需要通过 Homebrew 安装 LLVM 以支持 -std=c++26）。构建依赖包括 Python 3、Ragel、glslangValidator、librsvg 等。
• 平台依赖：
  • Linux：需要 Vulkan 驱动和 Wayland 合成器运行时，构建需要 FreeType、HarfBuzz、Wayland 客户端头文件等。
  • macOS：使用系统原生的 Metal、CoreText、Cocoa 等。
• 项目结构：提供两个共享完全相同终端代码的二进制文件：st（Shitty）和 pt（Pretty），它们仅在名称、图标、桌面入口等标识信息上有所不同。

安装与运行

• 安装：支持通过 Homebrew (macOS)、手动安装或 Nix flake 进行安装。
• 运行：运行 ./st 或 ./pt 启动默认 shell。可通过 -geometry、-saveLines、-font 等标志指定初始尺寸、滚动行数和字体。支持通过 Ctrl/Cmd + =/-/0 调整字体大小。

测试

项目包含一个庞大的原生和导入的 conformance 测试套件。可以通过 Nix 命令或专用测试二进制文件 (st_test) 运行完整的测试套件，包括常规构建和 sanitizer（ASan, UBSan）构建的测试。

已知限制与背景

• 限制：目前不支持双向文本布局或内联图形协议（如 sixel）。
• 起源与许可：Shitty 是 Zutty 终端模拟器的一个硬分叉和完全重写，保留了其代码谱系。项目正在从继承的 GPLv3 基线逐步过渡到 MIT 许可。新贡献采用 GPLv3-or-later 和 MIT 双重许可。