Zilog Z80 CPU 现代、免费开源硅克隆项目

项目概述

该项目旨在为经典的8位Zilog Z80处理器开发一个现代、免费且开源（FOSSi）的硅克隆版本，作为Zilog在2024年4月宣布Z80停产后的替代品。目标是成为ZX Spectrum、RC2014等8位家用电脑和DIY电脑套件的直接替换芯片。

技术实现与工艺节点

• 核心设计：基于Guy Hutchison的TV80 Verilog核心。
• 设计流程：使用开源的OpenROAD流程，并结合多种开源PDK进行综合与布局布线，以生成可投产的硅设计。
• 支持的开源PDK：
  • SkyWater Technology Foundry的130nm SKY130节点。
  • IHP Foundry的BiCMOS 130nm SG13节点。
  • GlobalFoundry的180nm GF180节点。
• 流片与封装：
  • 已完成首次硅流片（130nm SKY130工艺），芯片面积为0.064 mm²。
  • 已交付采用QFN64封装、全部40个引脚引出的130nm SKY130芯片。
  • 已交付采用多路复用24引脚的130nm SG13g2芯片。
  • 正在进行中：开发经典DIP40封装形式（芯片板上封装，COB）的180nm GF180MCU版本。

当前状态与测试

• 已收到并测试：来自前两次流片的芯片已于2025年交付，功能正常，目前正在进行测试。
• 初步测试结果：Z80功能运行良好，可与作为RAM的RP2040/RP2350通信。修复了通过ZEXDOC/ZEXALL测试套件发现的DAA指令中的错误，但ZEXALL测试中仍有2个关于未文档化标志的测试失败。

未来计划

1. 测试与验证：
   • 对所有Z80指令（包括“非法”指令）进行全面的测试平台测试。
   • 对输入/输出信号进行严格的时序测试，并与原版Z80进行比较。
   • 将基于网表的Z80核心集成到测试平台中进行最终验证。
2. 硬件适配与生产：
   • 制作从QFN64到DIP40的PCB适配器。
   • 生产采用COB技术的DIP40 PCB。
3. 设计与社区：
   • 创建能模仿原始Z80布局的门级版图。
   • 设计项目的标识/“芯片艺术”。
   • 进行三种不同开源PDK的流片（SKY130、SG13、GF180）。

目标应用机器

项目将以下经典及现代DIY机器作为硬件替换的测试案例：

• 经典机器：ZX Spectrum、Amstrad CPC、MSX1/2、ColecoVision、TRS-80、Sinclair ZX80/ZX81等。
• 现代DIY套件：RC2014模块化计算机、Zeal 8-bit计算机、LiNC80微型计算机套件等。

如何贡献

• 加入Tiny Tapeout Discord论坛。
• 浏览项目议题。
• 代码结构：
  • 顶层模块：src/tt_um_rejunity_z80.v（包含Z80并符合Tiny Tapeout约束）。
  • 核心Verilog实现：src/tv80文件夹。
  • OpenROAD配置：src/config.tcl。
  • 测试平台：src/test/test.py。
• 可在本地按照Tiny Tapeout指南运行测试。

背景与相关资源

• Tiny Tapeout：一个旨在降低数字设计芯片制造成本的教育项目。
• 文档：提供了原始Z80的数据手册、用户手册、未文档化指令、操作码表和时序信息。
• 逆向工程：链接了关于Z80芯片逆向工程、架构解码和“陷阱”查找的详细研究。
• 其他实现：列出了TV80、A-Z80、Z80Explorer等多个现有的Z80软核或模拟器实现。

PostgreSQL 数据库模式变更常见错误

本文旨在列举在 PostgreSQL 数据库中进行模式迁移时应避免的常见错误，这些错误可能导致性能问题、停机或应用故障。作者受一篇关于 PostgreSQL 特性的文章启发，转而探讨“反特性”——即开发者在风险极高的“模式迁移”领域应避免的行为。作者还介绍了其开发的 Database Lab Engine 技术，该技术能实现数据库的快速薄克隆（例如，10 秒内克隆 10 TiB 的数据库），从而允许在部署前安全地测试模式变更，并将其集成到 CI/CD 管线中。文章主要面向 OLTP（在线事务处理）场景（如移动和 Web 应用），其中查询执行超过 1 秒通常被认为过慢。

关键概念定义

• 数据库迁移：本文特指满足以下条件的模式变更：
  • 版本化与自动化：每个变更都有唯一标识符，应用过程自动化。
  • 不可变性：一旦应用到生产环境，变更不可修改，只能在其上添加新变更。
  • 增量性：数据库模式逐步演进。

常见错误及解决方案

1. 添加带有 DEFAULT 和 NOT NULL 的列

   • 错误：在旧版 PostgreSQL（11 之前）中，此操作会重写整个表，长时间锁表。
   • 正确做法：分步进行：先添加带默认值的可空列，必要时更新现有行，最后（在 PG11+ 中）快速添加 NOT NULL 约束。

2. 创建索引时未使用 CONCURRENTLY

   • 错误：标准索引创建会获取排他锁，阻塞所有写入。
   • 正确做法：使用 CREATE INDEX CONCURRENTLY，虽然耗时更长，但不阻塞表访问。注意此操作不能在事务块内使用，且可能失败留下无效索引。

3. 直接删除列

   • 错误：直接在生产环境删除列，若应用代码仍引用该列会导致错误。
   • 正确做法：先部署不再使用该列的应用代码，等待旧实例全部替换后，再在单独迁移中删除该列。

4. 不安全地更改列类型

   • 错误：进行需要表重写或存在不兼容性的类型更改（如将 int 改为 bigint，缩短 varchar 长度），可能导致停机、数据丢失或应用错误。
   • 正确做法：采用多步过程，例如添加新列进行迁移，或事先检查数据。

5. 添加外键约束时未进行验证

   • 错误：直接在大表上添加外键约束，需要扫描整个表以验证现有数据，造成长时间锁表。
   • 正确做法：分两步：先使用 NOT VALID 快速添加约束（不验证现有数据），然后在低流量时段执行 VALIDATE CONSTRAINT 进行验证。

6. 未考虑事务大小

   • 错误：在单次事务中运行修改大量数据的迁移。大事务会导致锁竞争、内存占用高、恢复时间长和复制延迟。
   • 正确做法：将大规模数据迁移拆分成更小的批次。

7. 忽略对复制的影响

   • 错误：未考虑迁移如何影响只读副本和复制延迟。大迁移可能导致显著的复制延迟，影响副本性能。

8. 未在类生产数据上测试迁移

   • 错误：仅在小型开发数据集上测试迁移。在大数据集上性能特征可能完全不同。
   • 正确做法：使用如 Database Lab Engine 等工具，在生产规模的数据副本上进行测试。

9. 忘记依赖对象

   • 错误：未考虑依赖于被修改列/表的视图、函数、触发器或其他对象，可能导致级联故障或需要额外手动干预。

10. 没有回滚计划

    • 错误：未规划如何在出现问题时撤销迁移。当生产环境出现问题时，这可能导致长时间停机。
    • 正确做法：始终准备经过测试的回滚计划，特别是对于破坏性操作。

结论 模式变更是应用开发中风险最高的环节之一。避免错误的关键在于：使用 Database Lab Engine 等工具在生产规模数据上进行测试；为高风险操作规划多步方法；善用 PostgreSQL 特定功能（如 CONCURRENTLY 和 NOT VALID）；监控对性能和复制的影响；并始终准备回滚计划。采取额外步骤安全部署，远胜于因冒险捷径而导致生产中断。

伦敦交通局（TfL）通过售票机弹窗提示有效减少纸质车票销售

核心措施
伦敦交通局于2023年9月在伦敦地铁站的售票机上增加了一条弹窗提示。当乘客尝试购买单程或往返纸质车票（而非日票）时，机器会建议改用非接触式支付卡。

实施背景

• 原因：工作人员发现许多乘客购买纸质车票后，实际使用非接触式卡支付。
• 目的：鼓励乘客直接使用非接触支付，降低乘客出行成本，同时减少纸质磁条车票销售。
• 意义：非接触支付票价通常更低（例如，帕丁顿至金丝雀码头的非高峰时段票价，纸质票为6.70英镑，非接触支付仅2.80英镑）。

效果与数据

• 纸质车票销量一夜之间下降约三分之一，达到预期目标。
• 长远看，此举有助于减少售票机排队时间，吸引更多乘客使用公共交通，因为乘客更倾向于选择票价透明、成本较低的服务。

技术细节

• 弹窗仅针对支持非接触支付的目的地显示；随着更多国家铁路车站接入该系统，提示范围将逐步扩大。
• 该调整并未强制取消纸质票选项，仅通过提示引导乘客选择更经济的支付方式。

总结
这一低成本、低干预的技术调整，成功降低了纸质车票销量，减少了乘客出行费用，并提升了公共交通系统的使用效率。

《普林斯顿应用数学手册》由Nicholas J. Higham主编，Mark R. Dennis、Paul Glendinning、Paul A. Martin、Fadil Santosa和Jared Tanner担任副编辑，普林斯顿大学出版社于2015年出版。全书共994页，附16页彩图，为精装本。

该书内容广泛，涵盖应用数学的多个领域。样章示例包括：

• 应用数学研究的目标
• 不变量与守恒定律
• Lambert W函数
• 常微分方程
• 代数几何
• 数值天气预报
• 隐身技术
• 高尔夫球的飞行
• 演化社交网络、态度与信念及反恐应用
• 机场行李的X射线断层扫描筛查
• 实验应用数学

书中部分文章（如《如何撰写大众数学文章》及四篇关于应用数学教学的文章）被收录于《2016年最佳数学写作》文集。

相关资源包括：

• 作者在《Mathematics Today》期刊上介绍该书创作过程的文章
• 专属Twitter账号、Facebook页面及作者博客上的相关文章
• 书籍及样章的BibTeX引用条目
• 全书内容词云图

主编Nicholas J. Higham提供了概述，进一步说明本书的定位与价值。读者可通过普林斯顿大学出版社官网或亚马逊购买本书。

烧尽的时尚：阿塔卡马沙漠的服装垃圾危机

事件焦点：沙漠中的巨型服装堆火灾

2022年6月12日，智利北部阿塔卡马沙漠边缘的埃尔帕索德拉穆拉沙丘上，一处估算重量达1.1万至5.9万吨的巨型废弃服装堆发生火灾。现场浓烟滚滚，空气中弥漫着合成纤维燃烧产生的有毒塑料气味，并伴随小型爆炸。环保组织“Dress Desert”联合创始人安赫拉·阿斯图迭洛和时尚教授芭芭拉·皮诺带领学生目睹了这一景象。

问题根源：全球快时尚的终端废墟

• 物流链路：智利伊基克港是南美洲最大的二手服装进口港，每年经自由贸易区“Zofri”进口大量废弃衣物。估计约85%的进口二手衣物无法售出。
• 非法堆积：自2001年起，居民玛努埃拉·梅迪纳在政府土地上建立非法堆放场，接纳未售出衣物。由于阿塔卡马沙漠极端干燥（14年无降水），主要由不可降解的合成纤维制成的衣物无法分解，堆体积持续扩大。
• 产业链矛盾：衣物进口商只需售出40%即可盈利，剩余衣物被廉价卖给堆放场经营者。尽管智利法律禁止处置纺织品，但监管缺失。

环境与社会影响

• 生态破坏：焚烧产生有毒气体与灰烬，威胁居民健康。附近居民称“下午5点后不敢开窗”，衣物燃烧的石油和塑料气味成为日常。
• 贫困循环：阿尔托霍斯皮西奥是智利最贫困地区之一，部分居民依赖转卖废弃衣物维生，甚至有人接受报酬焚烧垃圾。
• 法律行动：2022年3月，环境律师宝琳·席尔瓦以居民身份起诉市政与中央政府不作为。但火灾后关键证据被毁，且证人未出庭，诉讼面临阻力。

解决方案尝试与困境

• 回收企业挫折：企业家弗兰克林·泽佩达曾创办纺织品回收厂“Procitex”，将废弃衣物加工成隔热板，但因经济不可持续于2021年关闭。
• 政策推进：智利2016年通过《生产者延伸责任法》（REP），计划将纺织品纳入监管，但进展缓慢。环境部正制定纺织品循环经济战略。
• 草根行动：
  • 非营利组织“Dress Desert”通过工作坊推广衣物升级改造。
  • 创始人阿斯图迭洛与进口商合作，将棉质衣物用于沙漠植树覆土，改善土壤保水性。
  • 时尚设计师弗朗西斯卡·加哈多推动用回收材料设计服装，拒绝使用原始材料。
• 国际借鉴：纽约、加州等地正效仿智利推行纺织品回收立法；捷克公司RETEX试图引进织物处理技术至智利，但谈判尚未成功。

当前现状

• 火灾后巨型服装堆已被推平，但小型非法堆积和焚烧仍在持续。市政部门安装摄像头并罚款，但收效甚微。
• 全球服装产量翻倍，单件衣物使用率下降36%，智利每年进口超过70万吨新旧衣物。专家指出：“即使全球停止生产服装，现有衣物已超出地球承载能力。”
• 问题核心在于快时尚消费模式、全球废弃物转移机制，以及缺乏有效的末端处理与责任追溯体系。

报道来源：Grist与El País联合调查，由Joan Konner新闻项目支持。

LoRA+：大模型的高效低秩适配方法

核心问题

原始LoRA方法在微调宽度较大（即嵌入维度高）的模型时效果次优。原因在于其适配器矩阵 A 和 B 使用相同的学习率进行更新，这阻碍了有效的特征学习。

解决方案：LoRA+

• 关键改进：为LoRA适配器矩阵 A 和 B 设置不同的学习率，并采用一个精心选择的学习率比率。
• 原理：通过缩放论证表明，区分A和B的学习率能更高效地学习特征，从而纠正原始LoRA的次优性。

实验结果

• 性能提升：在多项任务中实现 1-2% 的准确率提升。
• 速度提升：微调速度最高可提升约 2倍。
• 成本不变：保持与原始LoRA相同的计算开销。

核心价值

LoRA+ 提供了一种简单、低开销的改进方案，仅通过调整学习率分配策略，即可在不增加计算负担的情况下，显著提升大型模型的微调效率与最终性能。

pdf.tocgen 是一套用于自动提取和生成 PDF 文件目录 (ToC) 的命令行工具。它通过分析 PDF 中嵌入的字体属性和标题位置来推断文档的大致结构。

核心工作流程与工具

该工具集包含三个独立的程序，它们共同构成一个处理流程，但每个工具也可单独使用：

1. pdfxmeta：用于提取 PDF 中标题文本的元数据（如字体、大小、位置），并以此为基础构建一个 TOML 格式的“配方”文件。
2. pdftocgen：根据提供的配方文件，从 PDF 中自动识别和生成目录结构。
3. pdftocio：将生成的目录（或现有的目录）导入到 PDF 文件中，生成带有书签目录的新 PDF。

典型工作流程

以一份没有目录的 PDF 文档（如 Paul Graham 的《On Lisp》）为例：

1. 构建配方：使用 pdfxmeta 检查目标标题的字体等属性，并将其添加到 recipe.toml 文件中。可以使用 --auto 参数简化输出格式。

   pdfxmeta --auto 1 --page 14 onlisp.pdf "Extensible" >> recipe.toml
   

2. 生成目录：使用 pdftocgen 和配方文件生成目录。

   pdftocgen onlisp.pdf < recipe.toml > toc
   

   生成的 toc 文件是一种特殊的 CSV 格式，易于编辑。
3. 导入目录：使用 pdftocio 将目录导入到原始 PDF。

   pdftocio -o output.pdf onlisp.pdf < toc
   

   流程可以简化为管道命令：pdftocgen in.pdf < recipe.toml | pdftocio -o out.pdf in.pdf。

适用性与安装

• 适用性：最适合由软件（如 LaTeX、troff、Adobe InDesign、Word）生成的 PDF，不适合扫描版的 PDF。
• 安装：通过 pip install -U pdf.tocgen 安装。支持 Python 3.7 - 3.11。
• 注意事项：工具面向的是读者，用于为现有 PDF 添加导航目录。LaTeX 作者应使用 hyperref 包来生成目录。

处理复杂标题（如含数学符号）

配方文件可以配置 greedy = true 选项，使其能够提取标题中字体属性不一致的文本（如数学符号），这是推荐的方法。也可以使用正则表达式匹配多种字体，或为同一级别的标题设置多个过滤器。

配置文件（Recipe）详解

配方是 TOML 文件，包含一系列标题过滤器。每个过滤器指定匹配标题所需的属性：

• level：标题级别。
• greedy：是否启用贪婪模式。
• font.name、font.size：字体名称和大小。
• font.size_tolerance、bbox.tolerance：允许的容差。
• 其他属性如 font.color, bbox.* 等。

各工具独立用法示例

• pdftocio：可单独用于查看、复制或修改 PDF 现有目录。
• pdftocgen：可单独使用已有配方生成目录。
• pdfxmeta：可单独用于在 PDF 中搜索文本并查看其元数据。

开发与许可

• 开发：使用 poetry 管理依赖，需运行测试。
• GUI 前端：有 Emacs 的 toc-mode 包可用作前端。
• 许可：工具本身采用 GPLv3 许可。recipes/ 目录下的示例配方文件采用 CC BY-NC-SA 4.0 许可，以防止商业用途。

Zed编辑器的核心数据结构并非传统字符串，而是基于自定义的SumTree构建的Rope。其设计旨在解决字符串在处理大型文件时效率低下的问题，并满足Zed对高性能和并发访问的需求。

为何不用字符串？

字符串作为连续内存块，在插入或删除时需要移动大量后续文本，操作复杂度为O(n)，处理大文件时性能差。此外，查找特定行号或计算滚动条位置等操作也需要线性扫描。

Rope的优势

Rope是一种二叉树，其叶节点存储文本片段。编辑操作（如插入、删除）主要通过修改树节点（调整指针）而非移动文本实现，复杂度为O(log n)。更重要的是，其节点通过引用计数实现持久化，支持高效的并发访问和快照，这对Zed的多线程架构至关重要。

Zed的实现核心：SumTree

Zed的Rope并非经典二叉树，而是其SumTree数据结构的特化应用。SumTree是一个并发友好的B+树变体：

• 叶节点：存储称为Chunk的文本片段（最大长度为128字节）。
• 内部节点：包含子树中所有节点的摘要信息。
• 摘要：每个节点都携带TextSummary，包含UTF-8/UTF-16长度、行数/列数、最长行信息等。内部节点的摘要是其子节点摘要的聚合。

SumTree的强大功能

SumTree的关键能力在于可以沿不同维度高效遍历。例如：

1. 偏移转点：给定一个字符绝对偏移量，通过在树中沿len维度遍历，可O(log n)时间找到对应的行号和列号。
2. 点转偏移：给定行号和列号，沿lines维度遍历，可快速找到对应的绝对偏移量。
3. 多维度查询：可以同时沿多个维度（如偏移和点）进行查找，并聚合其他维度的摘要信息。

这种能力源于Summary和Dimension的巧妙设计，使得一次树遍历能完成复杂的坐标转换。

为何选择Rope（及其SumTree实现）？

1. 性能：编辑操作始终高效。
2. 并发与快照：基于Arc的引用计数使得创建文本快照几乎零开销，支持语法高亮、异步保存等后台任务。
3. 灵活性：SumTree不仅用于Rope，还是Zed众多组件的基石。

SumTree的普遍性

SumTree是Zed的“灵魂”，其应用远超文本处理：

• 文件列表、Git blame信息、聊天消息、诊断信息等均用SumTree存储。
• Zed的DisplayMap（管理文本显示：折叠、换行、内联提示等）也完全构建在一系列SumTree之上。

Zed的创始人并非在Rope、Gap Buffer或Piece Table之间做选择，而是先构建了通用且强大的SumTree，再在其上实现Rope。这种基础设计使得Zed能以高性能、高并发的方式处理文本及各类有序数据。

本文作者分享了从最初接触 Makefiles 到逐渐欣赏其价值的心路历程，并通过多个实际案例展示了其在现代开发工作流中的实用性。

Make 的核心功能与优势 Make 是一个基于依赖关系来编排任务、执行命令以生成并更新目标文件的构建工具。它擅长检测文件变化、管理依赖、定义变量、支持并行构建、进行操作系统检测，且工具本身小巧（如作者系统中仅16kB）、跨平台可用。

实用案例一：Postfix 服务器配置管理 在配置 Postfix 服务器时，需要将文本格式的别名、传输规则等文件索引为 Berkeley DB 格式。手动更新容易遗漏，导致配置不生效。使用 Makefile 可以自动化此过程：定义各数据库文件（如 aliases.db）依赖于其源文件（如 aliases），并执行相应的生成命令（如 postalias），最后自动重新加载 Postfix 服务，确保所有更改生效。

实用案例二：Python 项目管理 Python 项目的依赖管理和测试流程可能因工具（如 pip, Poetry, Pipenv）和环境（如系统 Python, pyenv）而异。简单的 Makefile 可以标准化这些操作：自动创建虚拟环境、安装依赖、运行测试（如 make test），使开发者无需记忆具体步骤。

实用案例三：Terraform 多环境部署 对于 Terraform 基础设施即代码项目，Makefile 可以简化多环境（如 dev, prod）的管理。通过变量区分环境，定义通用的任务（如 init, plan, apply），并针对特定环境创建别名任务（如 dev-plan, prod-apply），方便地切换不同的 AWS 凭证和状态文件配置。

实用案例四：Hugo 博客构建与部署 作者为 Hugo 静态博客使用了 Makefile，它集成了网站生成、清理、本地预览、图片优化以及多种部署方式（SSH, rsync, Dropbox, FTP, S3, CloudFiles, GitHub Pages）。通过 make 命令即可完成复杂的工作流，如压缩静态文件、优化图片并上传到指定位置。

总结 作者认为，Makefiles 是一个强大且被低估的工具，其简单的“配方”（recipes）能有效自动化各种日常任务，避免人为错误。尽管初看可能显得“过时”，但其简洁性和实用性使其在多种现代开发场景中依然极具价值。

流场寻路

文章作者在1990年代整理寻路笔记，2010年代转向制作交互式教程。多年来经常有人询问“流场寻路”，作者在确认相关概念后对此进行了阐述。

作者对流场寻路的理解如下：

• 核心定义：流场是一个向量场，它能指示任何位置的智能体前往单一目的地应移动的方向。
• 可选特性：
  1. 智能体若位于寻路图节点之间，可对其在流场中的向量进行插值计算。
  2. 可使用粗粒度和细粒度步长的层级场来加速寻路过程。
• 与距离场的关系：距离场本身在Roguelike游戏的“Dijkstra地图”、策略游戏的“影响力地图”及3D建模等领域有应用。在向量微积分中，距离场的梯度即生成流场。
• 与传统算法的联系：作者在A*页面中介绍的基于图的寻路算法，其输出（如 cost_so_far 和 came_from）实质上分别对应了距离场和流场。

作者已更新其早期的寻路笔记和塔防寻路页面，加入了关于流场与距离场的内容。文章虽提及层级寻路，但未作深入探讨，作者表示网页形式允许其持续学习并更新内容，无需像教科书或论文一样等待完全成熟才发布。

论文标题：Let's Think Dot by Dot: Hidden Computation in Transformer Language Models

研究核心：探究Transformer语言模型中链式思维（Chain-of-Thought）响应带来的性能提升，是源于类似人类的任务分解，还是仅仅因为额外的token提供了更多的计算资源。

主要发现：

1. 无意义填充词的有效性：实验证明，Transformer模型可以使用无意义的填充词（如“......”）来替代链式思维，从而解决两个复杂的算法任务；而在没有中间token时，模型无法解决这些任务。
2. 学习难点：实证表明，模型学习使用填充词是困难的，需要特定且密集的监督才能收敛。
3. 理论分析：论文从一阶逻辑的量词深度角度，刻画了填充词有效的问题类别。对于满足此类特征的问题，链式思维token无需提供多token计算中涉及的中间计算步骤信息。

结论与意义：研究结果表明，额外的token能够提供与具体token选择无关的计算收益。中间token可以充当填充词这一事实，引发了人们对大型语言模型进行不可审计的隐藏计算的担忧，这种计算可能越来越与观测到的链式思维token脱节。

塞斯纳185“不可失速”飞机失速事故摘要

事故概况

一架注册号为OH-CVT的塞斯纳185 Skywagon水上飞机（浮筒改装型），于2003年6月25日在芬兰拉普兰地区的奥纳斯湖起飞时坠毁。事故导致一名前排乘客溺亡，飞机全毁。该机配备了罗伯逊STOL（短距起降）套件、浮筒、下挂货包和三叶螺旋桨，最大起飞重量为1520公斤，事发时重量为1460公斤，重心在允许范围内。

起飞与事故过程

飞行员是一名拥有2176小时水上飞机经验的持证商业飞行员。起飞时湖面风速约3节，浪高10厘米。飞机滑跑约500米后离水，随后在约15米高度突然向右急剧偏航和滚转。飞行员尝试使用全左副翼和左舵修正，但飞机右偏超过90度，右翼尖先触水，随后发生翻滚，最终以倒扣姿态漂浮于湖中。飞行员和一名中排乘客成功逃生，但前排乘客因安全带缠绕脚踝且未佩戴肩带被困溺亡。

关键调查发现

1. 飞行员操作与失速识别

• 飞机离水后，飞行员未降低机头以积累速度，而是任其自动爬升，导致迎角增大。
• 飞行员从未在塞斯纳185上进行过失速练习，并坚信该机型不会失速。因此，在飞机失速时他未能识别并采取正确的改出操作（推杆减迎角），而是错误地使用反向副翼和舵面，加剧了失速。

2. STOL套件引发的失速特性

• 调查通过复飞实验和羊毛线流场可视化发现，飞机安装的罗伯逊STOL套件在起飞构型下，副翼与襟翼联动使副翼向下偏转，导致机翼上表面形成尖锐折角。
• 这引发了右翼尖突然失速，气流迅速从前缘分离，造成剧烈的右滚转。标准塞斯纳的失速通常从翼根开始，但改装后特征改变。
• 该失速现象在实验中仅约三分之一的情况下发生，原因未完全明确，但机翼几何扭转角的维修调整可能影响了失速速度。

3. 维护与文档缺失

• 事故前飞机曾因机库坍塌进行维修，并纠正了右翼的几何扭转缺陷（此前导致飞机有滚转倾向）。飞行员确认维修后飞机滚转倾向消失。
• 但维修后未重新测试失速速度，飞行员填写的试飞文档中失速速度栏为空白，仅标注“OK”。维修单位在未验证慢速飞行和失速特性的情况下签发了适航证书。
• 翼面角度变化影响了失速速度，但无人知晓具体数值。

4. 安全设备使用

• 机上无人穿戴救生衣或前排肩带。若乘客佩戴肩带，可能在飞机倒扣后仍保持清醒并及时逃生。芬兰当时未强制要求水上飞机乘客穿戴救生衣。

事故结论

直接原因：

1. 飞行员在飞机离水后未控制俯仰以增加速度，导致迎角过大引发失速。
2. STOL套件与副翼设计的组合导致右翼尖在起飞构型下易发生突然失速。
3. 飞行员未能识别失速并采取正确恢复操作（推杆），反而错误操纵加剧失控。

间接原因：

• 飞行员缺乏失速训练与认知，从未练习过该机型的失速恢复。
• 飞机维修后未重新验证失速特性，文档记录不完整。
• 前排人员未佩戴肩带，影响逃生。

调查建议

1. 向塞斯纳185飞行员通报罗伯逊STOL套件的失速特性，通过飞行手册补充页和航空当局进行教育。
2. 修订芬兰法规，强制要求水上作业时所有机上人员穿戴救生衣，而非仅存放。

报告来源：芬兰安全调查局英文版事故报告。

Google Quantum AI 量子计算进展概要

Google Quantum AI 团队近期宣布了两项重要进展，标志着其在构建实用化、大规模量子计算机的道路上迈出了关键一步。

1. 可验证量子优势的突破

Google在其最新的 Willow 量子处理器上，发布了一种名为 “Quantum Echoes” 的新算法。该算法实现了 首次可验证的量子优势。这意味着量子计算机在解决特定问题时，其性能不仅超越了经典超级计算机，而且这种优势是可被验证的。这是量子计算从理论演示迈向实际世界应用的一个重要里程碑。

2. 新一代量子芯片 Willow

Google Quantum AI推出了其最新一代的尖端量子芯片——Willow。该芯片被视为开发大规模、可纠错量子计算机过程中的一个重大飞跃。Willow芯片的设计和成就代表了该公司在量子硬件上的最新技术突破。

总结而言，Google Quantum AI当前的进展聚焦于两方面：一是在其硬件平台（Willow芯片）上实现了算法层面的重大突破（Quantum Echoes），证明了可验证的量子优势；二是通过Willow芯片本身的迭代，继续推动量子硬件向更强大、更可纠错的方向发展。这两项工作共同指向了构建能够解决实际问题的容错量子计算机的长远目标。

如何改进RISC-V规范

本文指出RISC-V规范当前处于“不健康状态”，主要问题在于其四个核心组成部分——非特权/特权指令集手册（PDF）、测试套件、Sail可执行模型和Spike模拟器——彼此完全独立，未相互关联或自动生成。这导致同一架构特性需以四种不同格式手动编写和维护，一致性检查困难，且整个生态系统（硬件设计、验证、工具链等）也需手动重写代码以适配新扩展，效率低下且易出错。

主要问题

1. 规范分散且冗余：四个独立的组成部分维护在不同仓库中，未从共同的机器可读数据源自动生成，导致重复工作和潜在的不一致。
2. 自然语言描述不够精确：PDF文档主要依赖自然语言，描述有时不精确且无法被其他部件（如测试套件、Sail模型）直接验证。
3. 测试套件配置性不足：RISC-V架构高度可配置，但测试套件难以全面检查所有允许的配置和行为，且缺乏统一的机器可读配置描述。
4. Sail规范可读性与集成度问题：
   • Sail规范对非编程语言研究人员（如硬件工程师、OS/编译器开发者）可读性差，其语法受学术研究语言影响较深。
   • Sail规范未被有效整合到官方手册中，无法为自然语言描述提供精确补充。

核心改进建议

1. 建立统一的机器可读格式：
   • 将指令编码、控制/状态寄存器等架构信息统一用简单的格式（如JSON/YAML/XML）描述，包含名称、描述、位域、配置约束、使用权限、语法等信息。
   • 重构现有部件：修改手册、Spike、测试套件和Sail规范，使其围绕这些机器可读文件自动生成代码和数据，确保一致性并为未来扩展提供基础。
2. 优化Sail语言的可访问性：
   • 简化Sail的语法，为常见情况提供合理默认值，减少类型系统带来的冗余，使其更接近传统ISA规范的风格（如参考ASL-1.0语法）。无需移除高级特性（如Liquid类型），但需降低普通用户的认知门槛。
3. 深度集成Sail规范：
   • 将Sail规范（尤其是指令语义部分）直接嵌入到官方手册的自然语言描述旁边，实现精确形式化描述与易懂自然语言的相互增强。
   • 利用已有工具（如Sail-to-ASCIIdoc工具）实现此集成。
   • 探索从Sail规范自动生成Spike模拟器对新扩展的支持代码，减少双重维护。

结论

RISC-V规范的现状源于其早期快速发展的学术风格，适合仅有基础指令集的小规模架构。随着ISA扩展不断增多，缺乏统一、机器可读、可自动化的规范源已成为关键瓶颈。通过建立统一的机器可读数据源，并以此自动生成所有相关部件，是解决规范分散、提高一致性、并支持整个生态系统高效发展的根本途径。

Cognita：开源模块化RAG框架

⚠️ 项目状态

此项目已不再积极维护。

核心定位

Cognita 是一个面向生产环境的开源RAG框架，旨在解决将LangChain/LlamaIndex等库从实验环境（如Jupyter Notebook）迁移到生产环境时面临的挑战。它通过提供模块化、API驱动和可扩展的代码组织结构，使RAG系统更易于在本地开发和生产部署。

主要优势与特点

• 模块化架构：将RAG的各个组件（如数据加载器、解析器、嵌入模型、检索器）设计为独立、可替换的模块。
• 生产就绪：提供无代码UI界面、API驱动、易于水平扩展，并支持增量索引以减少重复计算。
• 灵活部署：支持本地Docker一键部署，也兼容Truefoundry平台进行规模化生产部署。
• 功能丰富：
  • 支持多种检索策略（相似性搜索、查询分解、文档重排序）。
  • 集成最新开源嵌入和重排序模型（如mixedbread-ai）。
  • 支持通过Ollama使用本地LLM。
  • 最新版本支持音频和视频解析（基于Whisper）。

系统架构与核心组件

1. 数据源：文档存储位置（如S3、本地磁盘）。
2. 元数据存储：存储集合（Collection）的配置信息，如关联的向量库、数据源、解析和嵌入配置。现支持基于Prisma和Postgres的自有存储。
3. AI网关：统一代理请求到不同提供商的嵌入模型和LLM，支持OpenAI、Ollama及Truefoundry网关。
4. 向量数据库：存储文档嵌入和元数据。目前支持Qdrant和SingleStore。
5. 索引作业：异步任务，负责扫描数据源、增量更新向量库。可通过手动或定时任务触发。
6. API服务器：处理用户查询请求。它根据查询控制器的配置，调用检索器获取相关文档块，并利用LLM生成答案。

快速启动（本地Docker部署）

1. 前提：安装Docker和Docker Compose（版本25+）。
2. 配置模型：复制 models_config.sample.yaml 为 models_config.yaml，根据需要配置模型提供者（如本地Ollama/Infinity或远程OpenAI）。
3. 启动服务：运行 docker-compose --env-file compose.env up。这将启动数据库、向量库、后端和前端服务。
4. 访问界面：启动后可通过浏览器访问前端UI（默认端口5001）进行文档管理和问答测试。

自定义与扩展

Cognita 鼓励定制化，核心组件均可替换：

• 数据加载器：继承 BaseDataLoader 并注册。
• 解析器：继承 BaseParser 并注册。
• 嵌入模型：在 models_config.yaml 中配置兼容OpenAI的API。
• 向量数据库：继承 BaseVectorDB 并注册。
• 查询控制器：创建自定义类，使用 @query_controller 和 @post 等装饰器定义API端点，实现个性化的问答逻辑。

与Truefoundry平台集成

通过Truefoundry平台可以简化生产环境的部署、管理和扩展流程，提供日志、指标和反馈机制。部署步骤包括注册平台、创建集群、存储集成、ML仓库、工作区，最后通过应用目录部署RAG应用。

未来发展方向（欢迎贡献）

• 支持更多向量数据库（如Chroma, Weaviate）。
• 支持标量和二进制量化嵌入。
• 增加RAG评估和可视化功能。
• 支持带上下文的对话机器人。
• 集成RAG优化的小模型（如stable-lm-3b）。
• 支持图数据库。

这是一个国际空间站（ISS）的3D追踪网站项目，其主要特点和功能包括：

• 3D地球可视化：在一个精美渲染的3D地球上展示国际空间站的实时位置与飞行轨迹。
• 实时视频流：集成了国际空间站的直播视频，用户可以观看宇航员视角或舱外实况。
• 准实时云图：叠加了准实时更新的全球云层数据，提供更真实的地球视觉背景。
• 交互式体验：用户可以通过旋转、缩放地球来自由探索，近距离观察空间站的动态。

该项目通过网页应用的形式，将多源数据（位置、视频、气象）整合到一个直观的交互界面中，为太空爱好者和教育用途提供了一个生动、沉浸式的观察工具。

当前提供的内容与标题“44% Unicorn Startups in the US were founded by foreign workers”不匹配。正文显示的是网站错误信息（x.com 因隐私相关扩展导致加载问题），未包含标题所指的具体文章内容。

如需获取关于美国独角兽企业与外国创始人相关文章的准确摘要，请提供正确的文章正文。

Microsoft At Work 项目总结

Microsoft At Work (MAW) 是微软于1993年夏季推出的一项雄心勃勃的计划，旨在将Windows系统集成到各类办公设备（如传真机、打印机）中，构建所谓的“无纸化数字办公室”架构。该项目本质上是一个统一的通信协议和操作系统环境，目标是让PC能无缝地与这些“智能”办公机器交互。

核心内容与失败结局：

• 实际产品匮乏：MAW被宣传为一种“架构”或“环境”，但首款产品（理光传真机）直到1995年才上市。市场反应冷淡，产品寥寥无几，且因高昂的Windows授权费导致价格缺乏竞争力。
• 宣传与现实脱节：微软将MAW设备描述为“类似传真机的产品”，刻意避免被视为普通办公电器。然而，产品功能有限，性能不佳，最终项目团队被重组，计划悄然终止。

相关技术项目：

1. Windows打印系统：早于MAW，这是一个通过主机进行打印光栅化以降低打印机成本的技术。它为MAW提供了基础，但并非其核心部分。该系统在商业上也不算成功，但其理念（如主机处理打印、TrueType字体支持）为后来的廉价“WinPrinter”奠定了基础。
2. 操作系统探索：
   • 嵌入式RTOS：传闻MAW包含一个用于设备的嵌入式实时操作系统，但相关资料极少，其存在性存疑。有迹象表明它可能是16位Windows 3.1的精简版。
   • WinPad：这是MAW中更知名的部分，一个为触摸屏手持设备设计的操作系统，旨在同步文档、邮件和传真。它基于Windows 3.1，试图提供类似Windows 95的界面，但因性能差、耗电高而失败。WinPad是Windows CE的前身。

与世嘉土星的关联疑云：

• 曾有报道称微软为世嘉土星游戏机提供操作系统，可能与MAW的嵌入式OS相关，并计划将其移植到Hitachi SH处理器。
• 后续证据和分析表明，微软最终可能仅提供了与CD驱动器相关的固件，而非完整系统。且土星的CD-ROM固件代码中并未发现微软版权，该传闻可能源自媒体的夸大或误解。

项目遗产： MAW及其分支WinPad和Pegasus项目均告失败。然而，这些尝试直接催生了Windows CE的开发，该系统后来成为微软嵌入式和移动操作系统的重要基础。MAW的故事体现了微软在90年代中期试图将Windows生态扩展到传统计算设备之外的努力，但因技术不成熟、市场需求模糊和执行不力而未能成功。

本文介绍了在Linux内核中直接嵌入并执行用户空间程序的机制，突破了传统依赖文件系统路径加载程序的方式。主要内容如下：

1. 背景与动机
   通常，内核执行用户空间程序（如模块加载器/sbin/modprobe、802.1d桥/STP助手/sbin/bridge-stp）是通过execve系统调用从文件系统读取并启动。但在某些场景下（如BSP供应商、网络存储挂载等），文件系统不可用导致无法运行辅助程序。为此，内核提供直接将程序嵌入镜像并启动的机制，以确保在任意时刻都能执行所需助手程序。

2. 嵌入程序的构建要求
   选择无文件系统依赖的程序，建议静态链接。以Go语言为例，介绍了一个每五秒输出“Hello, world!”的小程序（hello.go），通过strace验证其仅访问/proc或/sys（虚拟文件系统），确保不会因根文件系统不可用而异常。

3. User Mode Helper API与User Mode Driver机制 传统的call_usermodehelper函数通过文件路径启动程序（int call_usermodehelper(const char *path, char **argv, char **envp, int wait)），需要文件实际存在。Linux v4.18引入user mode driver API，允许针对嵌入内容直接通过内存缓冲区加载并执行：

• umd_load_blob(struct umd_info *info, const void *data, size_t len) 创建程序上下文；
• fork_usermode_driver(struct umd_info *info) 启动程序。

此API还能建立管道，实现内核与用户程序的高效通信。

4. 将Go程序嵌入到内核镜像
   利用GNU assembler（gas），构建汇编文件eprog_user_blob.S，实现将Go二进制嵌入到内核只读内存段：

.section .init.rodata, "a"
.global embedded_umh_start
embedded_umh_start:
.incbin "drivers/misc/embedded_prog/eprog_user"
.global embedded_umh_end
embedded_umh_end:

通过符号embedded_umh_start和embedded_umh_end定位程序，驱动内调用umd_load_blob及fork_usermode_driver实现启动。

驱动核心代码示例：

struct umd_info eprog_ctx = {
    .driver_name = "eprog_user",
};
umd_load_blob(&eprog_ctx, &embedded_umh_start, &embedded_umh_end - &embedded_umh_start);
fork_usermode_driver(&eprog_ctx);

nm命令可验证符号在内核或模块中被正确注册。

5. 构建流程与Makefile连接
   Makefile支持在内核编译过程中构建Go程序并将其嵌入，流程包括：

• 编译hello.go为eprog_user（二进制）
• 通过eprog_user_blob.S嵌入到对象文件eprog_user_blob.o
• 与eprog_kern.c一起链接为内核模块/主内核。

示意Makefile片段：

$(obj)/eprog_user_blob.o: $(obj)/eprog_user
$(obj)/eprog_user: $(srctree)/drivers/misc/embedded_prog/gohello/hello.go
    go build -o $(obj)/eprog_user $(srctree)/drivers/misc/embedded_prog/gohello/hello.go
obj-$(CONFIG_EMBEDDED_PROG) += eprog.o
eprog-objs += eprog_kern.o eprog_user_blob.o

6. 加载与运行效果
   加载模块后（insmod eprog.ko），系统产生新进程eprog_user（不是内核线程），每五秒从用户空间通过管道向内核发送“Hello, world!”消息，并被记录到内核日志（dmesg）。模块卸载则终止进程。

7. 总结与应用注意
   通过汇编文件与User Mode Driver机制，可以将任何可执行程序嵌入内核镜像并执行，适合需要完全独立于文件系统的场景。静态链接（如Go程序）为最佳选择。应用时需明确程序对文件访问的要求，嵌入程序会让内存占用永久增加，适用场景需谨慎评估。完整驱动示例已开放于git.kernel.org。