GitHub 存在永久可访问的已删除和私有仓库数据问题

核心问题： GitHub 的仓库网络设计导致已删除的仓库、分支以及私有仓库的特定数据可被永久访问，这是一个被称为 “跨仓库对象引用”（Cross Fork Object Reference, CFOR） 的重大安全漏洞。

关键发现与场景

1. 访问已删除的 Fork 数据

   • 用户在公共仓库的 Fork 中提交代码后删除该 Fork，这些提交数据仍然存在且可被访问。
   • 示例：对一个流行AI公司的三个公共仓库进行调查，轻易地从已删除的 Fork 中发现了40个有效的API密钥。用户模式通常是：Fork仓库、硬编码密钥、工作、删除Fork。
   • 即使原始上游仓库被删除，只要存在一个下游 Fork，整个仓库网络（包括原始提交）的数据依然可访问。

2. 访问已删除的仓库数据

   • 如果一个公共仓库被Fork后，原始仓库提交了新代码（未同步到Fork），然后删除原始仓库，这些新提交的数据仍能通过Fork访问。
   • 实际案例：某大型科技公司意外提交了拥有重要权限的员工GitHub账户私钥。尽管公司立即删除了仓库，但由于已有Fork存在，报告者仍能通过Fork访问包含敏感数据的提交。
   • 结论：任何提交到公共仓库的代码，只要存在至少一个Fork，就可能永久可访问。

3. 访问私有仓库数据

   • 这是一种常见的开源工作流程风险：创建私有仓库 -> Fork出一个私有内部版本并提交特有代码 -> 将上游仓库转为公开。
   • 在此流程中，从创建内部Fork到上游仓库转为公开期间提交到私有Fork的代码，会通过公开的上游仓库变得可访问。公开后新提交到私有Fork的代码则不受影响（因为仓库网络分离）。
   • 这导致组织的机密信息和密钥可能在无意中通过其公共GitHub仓库暴露。

如何访问这些“已删除”的数据？

• 通过提交哈希直接访问：知道某个提交的完整或短SHA-1哈希值，即可直接通过URL（https://github.com/<user>/<repo>/commit/<commit_hash>）访问，即使该提交不属于任何可见分支。
• 哈希值可被发现：
  • 暴力破解：Git协议允许使用短SHA-1值（最少4字符），键空间较小（65,536种可能），易于暴力破解。
  • 事件API：GitHub的公共事件API及第三方存档可能记录了这些提交哈希，即使在仓库删除后。

GitHub 的立场与政策

• GitHub的官方文档明确说明了仓库在删除或更改可见性后Fork的行为，这是其架构的设计方式。
• 然而，这种设计与用户的安全认知存在巨大差距：
  • 用户普遍认为私有仓库与公共仓库之间存在安全边界。
  • 用户认为“删除”操作会销毁数据，但实际上提交数据在网络中持续存在。

影响与建议

1. 数据永久性：只要一个Fork存在，对该仓库网络的任何提交（上游或下游）将永久存在。
2. 密钥泄露的唯一安全修复是轮换：一旦在公共GitHub仓库上泄露密钥，唯一彻底的补救措施是立即轮换该密钥。
3. 秘密扫描的挑战：需要扫描整个仓库网络（包括已删除的分支和Fork）的所有提交，这可能涉及非自身拥有的密钥，增加了分类处理的复杂性。
4. 用户认知差距：GitHub仓库网络的底层工作原理不为大多数用户理解，这直接导致了安全隐患。
5. 普遍性：虽然研究聚焦于GitHub，但其他版本控制系统产品也可能存在类似问题。

总结：GitHub的CFOR漏洞源于其仓库网络架构的固有设计，使得“删除”操作并非真正的数据销毁。组织和个人必须认识到，在公共仓库上提交的任何代码（包括通过Fork和私有仓库间接关联的数据）都可能永久存在且可被访问，必须采取密钥轮换和全面的秘密扫描等严格的安全措施。

AI在国际数学奥林匹克竞赛中达到银牌水平

总体成就

谷歌DeepMind开发的AI系统AlphaProof和AlphaGeometry 2在2024年国际数学奥林匹克竞赛（IMO）中，成功解决了6道题目中的4道，获得28分（满分42分），成绩相当于竞赛中的银牌水平。这是AI首次在IMO竞赛中达到人类银牌选手的表现。

系统介绍

AlphaProof

• 核心功能：基于强化学习的形式化数学推理系统。
• 工作原理：
  1. 将自然语言数学问题翻译成形式化语言（如Lean）。
  2. 结合预训练语言模型与AlphaZero强化学习算法，搜索并验证数学证明。
  3. 每次成功证明会强化模型，提升解决更复杂问题的能力。
• 训练过程：通过证明或反驳数百万个问题进行训练，覆盖不同难度和领域。

AlphaGeometry 2

• 核心功能：几何问题求解系统，是AlphaGeometry的升级版。
• 改进点：
  • 使用基于Gemini的语言模型，训练数据量增加一个数量级。
  • 符号引擎速度提升两个数量级。
  • 引入知识共享机制，支持复杂搜索树组合。
• 历史表现：能解决过去25年IMO历史几何题的83%（前代为53%）。

竞赛表现详情

• 问题解决：
  • AlphaProof解决了两道代数题和一道数论题（包括仅5名选手解出的最难题目）。
  • AlphaGeometry 2在19秒内解决了几何题。
  • 组合数学题未被解决。
• 评分：每道题最高7分，系统解出的题目均获满分，总分28分（金牌线为29分）。

技术意义与未来方向

• 形式化语言优势：避免自然语言推理中的“幻觉”错误，确保数学证明的正确性。
• 自然语言推理系统：基于Gemini的实验系统无需形式化翻译，展现潜力。
• 目标：未来AI工具将协助数学家探索假设、创新解法并高效完成证明，推动数学与AI的交叉发展。

项目团队与支持

• 项目由DeepMind团队领导，涉及形式化推理、几何求解及自然语言处理等多个领域。
• 依赖Lean和Mathlib等数学形式化社区的基础工作。

Node.js 实验性支持 TypeScript

Node.js 通过 GitHub Pull Request #35.8k 实现了对 TypeScript 的 实验性支持。该变更已获得 118k 星标，表明社区关注度较高。

该功能被标记为 experimental（实验性），属于 Node.js 模块系统（module） 的扩展，具体与 ESM（ECMAScript Modules） 实现相关。PR 已被标记为 notable-change，意味着这是一项重要的、值得关注的变更。

此项支持目前处于实验阶段，可能涉及对 .ts 文件或 TypeScript 语法的加载与处理，但具体实现细节（如是否内置编译器、是否依赖外部转译工具）未在提供的内容中明确说明。开发者可在相关讨论中跟进进展与用法。

文章摘要：《Reverse Engineering for Everyone》

本文介绍了名为《Reverse Engineering for Everyone》的逆向工程教程系列。教程旨在将逆向工程这一复杂领域简化，使其易于理解与学习。

核心内容与目标：

• 定义：逆向工程（亦称反向工程）是通过分解人造对象来揭示其设计、架构、代码或从中提取知识的过程，类似于科学研究但对象是人造物。
• 目的：教程集的目标是让逆向工程的学习过程“尽可能简单”。
• 覆盖范围：教程全面覆盖了 x86、x64、32位 ARM 以及 64位 架构。
• 适用人群：
  • 新手：可以从零基础学习，直至掌握逆向工程的中级基础知识。
  • 有经验者：可用于复习和巩固特定概念，可通过侧边栏快速定位内容。
• 重要性：该技能被认为是网络安全领域从业者应具备的核心能力。

资源获取：

• 教程提供完整的 PDF 和 MOBI 格式电子书下载。
• 这些电子书版本会随着新教程的添加而自动更新。

总结：这是一套面向广泛人群（从初学者到从业者）的、旨在降低学习门槛的综合性逆向工程教程，内容涵盖主流处理器架构，并提供持续更新的电子资源。

文章摘要：每家公司都应由其员工所有

本文以 Central States Manufacturing 公司为例，探讨了员工所有制在促进财富公平分配和实现企业与员工共同繁荣方面的显著优势。

核心案例：Central States Manufacturing

• 蓝领百万富翁：该公司拥有47名百万富翁员工，其中许多是司机或机械师等基层蓝领工人。
• 全员持股机制：公司由员工共同所有。员工除领取薪水外，还能获得按薪水一定比例分配的股票。股权分配广泛且均衡，不局限于管理层。许多工作15至20年的普通员工（如高中学历的机器操作员）账户资产已超100万美元。
• 业绩与目标：公司发展势头强劲，今年有望达成10亿美元营收和1500名员工的目标，成为全美少数高营收企业之一，且发展红利由全体员工共享。

宏观背景：财富分配与所有权缺失

• 贫富差距加剧：过去一个世纪美国经济增长产生的财富主要流向了少数企业所有者。1990年代的政策促使高管通过股票期权实现财富飙升，而普通员工因仅有固定薪水导致收入停滞。
• 所有权的决定性：缺乏企业所有权使普通人难以积累真正的财富。单纯提高最低工资无法解决这一结构性问题，因为财富最终总会流向资产（如住房、工作场所和消费品）的所有者。

发展趋势

文章强调，将劳动者转变为企业所有者是解决财富分配不均的有效途径。当前，推动员工所有制的社会运动正在日益壮大，旨在打破财富壁垒，让更多普通员工分享企业成长的红利。

调查损坏Winamp皮肤的奇异发现
2021年1月，作者在探索Winamp皮肤博物馆的档案时，发现一些损坏的皮肤文件。Winamp皮肤本质是ZIP文件（仅扩展名不同），通过解压这些文件，作者深入调查并揭露了一系列意外内容。调查依赖SQLite数据库存储皮肤数据，以便系统分析。

主要发现

1. 加密文件：多个皮肤包含加密ZIP档案，作者使用密码破解工具成功解密。例如，密码为“honda”和“nayane”的文件分别包含无关图像和一个有效皮肤。
2. 个人物品：一个泰国父亲为2岁半儿子设计的Winamp皮肤草图，附带私信，但未公开发布；另一个文件包含某人的电子邮件密码，暴露安全漏洞。
3. 隐藏内容：一个皮肤中的文本文件秘密记录了爵士音乐家Chet Baker的传记；另一个皮肤包含倒放的音频文件，后识别为滑板品牌“Alien Workshop Sovereign Sect 2001”的相关宣传。
4. 媒体文件：多个皮肤嵌入MP3音频，如游戏音效、滑板主题曲或搞笑片段。一个名为“cool.mp3”的音频仅五秒长，风格怪异。
5. 可执行文件：一个皮肤仅含“WORM.EXE”，运行后发现是类似贪吃蛇的小游戏，无恶意软件。
6. 图像资料：损坏皮肤中混杂随机图像，如婴儿照片、风景照（如苏格兰Kilmacolm Road Viewpoint），以及虚构人物“Ellie”的位图。
7. 嵌套皮肤：127个皮肤内包含其他皮肤，其中56个为博物馆未知资源，已上传补充收藏。

调查方法与背景
作者对Winamp和“拾得物品”充满热情，通过批量提取文件、使用密码破解工具及搜索关键词（如“password”）定位敏感数据。SQLite数据库帮助高效管理大量文件元数据，实现跨皮肤内容比对。

总结
调查展示了数字档案中隐藏的多样性：从个人情感到安全风险，再到文化碎片。这些损坏皮肤反映了真实用户的创造力与意外遗留，作者将此类发现视为数字考古的奇异之旅。

CrowdStrike将面临法国的损害赔偿责任

核心事件概述

CrowdStrike近期推送的有缺陷更新导致全球约850万台计算机瘫痪，造成超过54亿美元损失。该公司极可能需承担损害赔偿责任。

法律依据：OVH案例先例

文章通过法国OVH数据中心火灾诉讼案，确立了服务提供商在技术过失下需承担责任的法律原则：

• OVH事件：2021年3月火灾导致多个数据中心及备份同时损毁，造成客户数据永久丢失。
• 法院关键裁定：
  • 数据中心虽在物理上接近但布局不合理，未提供足够冗余。
  • 备份服务未按行业最佳实践（如异地存储）运营。
  • 法院明确指出供应商有责任以合理标准提供备份服务，而非将责任转嫁给客户。
• 归责逻辑：实际损害 + 过失或故意行为 = 赔偿责任。OVH因多项操作失误败诉。

CrowdStrike事件的技术过失分析

文章详细列举了CrowdStrike在此次事件中的多项疑似过失：

1. 高风险的部署方式：

   • 软件以内核驱动程序形式运行，具有极高系统权限。
   • 未实施分阶段更新（Staged Rollout），而是将错误更新一次性推送至数百万关键设备。
   • 拒绝客户关于控制更新节奏的请求，曾发送50页备忘录明确拒绝分阶段部署。

2. 严重缺失的测试与监控：

   • 更新明显未经充分测试，导致所有受影响计算机在启动时崩溃（蓝屏）。
   • 推送更新后近两小时才发现问题并停止推送，显示部署后缺乏有效监控。
   • 类似事故在数周前已在Linux版代理上发生，表明系统性问题。

3. 灾难性的恢复难度：

   • 故障导致计算机完全无法启动，用户无法自行修复。
   • 恢复需IT人员物理接触每台设备，进入安全模式手动删除驱动程序文件。
   • 对于机场终端、医疗设备、服务器等难以物理接触或加密的设备，恢复可能极其困难甚至不可能。

4. 目的失败与行业违规：

   • CrowdStrike作为旨在保护系统的安全软件，反而摧毁了它应该保护的系统。
   • 公司声称拥有多项安全认证，但其行为违反了相关开发和测试标准。
   • 这可能使使用其服务的客户（尤其在医疗、金融等受监管行业）自身面临合规风险。

结论与潜在后果

文章认为，CrowdStrike的过失明显（未经测试的更新、无分阶段部署、响应迟缓），并造成了与OVH案例类似的巨大损害（大规模服务中断、数据不可访问）。这使得该公司对受损害客户的赔偿责任“大门敞开”，客户甚至可能有权单方面终止合同。文中附录以BitLocker为例，强调了安全关键软件应有的严格测试流程，反衬出CrowdStrike实践的不合理性。

该内容仅为网站加载错误的技术提示，未包含欧盟议员遭以色列间谍软件攻击的具体信息。

本文探讨了在列表中查找中位数的算法，重点介绍了实现确定性线性时间 (O(n)) 复杂度的中位数的中位数方法。

1. 简单方法：排序 最直接的方法是先对列表进行排序，然后根据奇偶数情况返回中间元素或中间两元素的平均值。由于最快的比较排序时间复杂度为 (O(n \log n))，因此该方法效率不高。

2. 平均情况线性时间：快速选择算法 由 Tony Hoare 提出的快速选择算法可以平均在 (O(n)) 时间内找到任意第 k 小的元素（包括中位数）。其核心步骤如下：

• 随机选择基准点：从列表中随机选取一个元素作为基准点（pivot）。
• 分区：将列表分为三部分：小于基准点的元素、等于基准点的元素、大于基准点的元素。
• 递归选择：根据目标位置 k 与这三部分的大小关系，决定在哪个子列表中继续递归查找。 文章通过一个包含11个元素的例子，详细演示了该算法的执行过程。快速选择在实践中非常高效，但最坏情况下可能退化为 (O(n^2))。

3. 确定性线性时间：中位数的中位数算法 为了消除随机算法的不确定性，实现最坏情况下仍为 (O(n)) 的确定性算法，文章介绍了经典的“中位数的中位数”方法。该算法主要用于为快速选择算法选择一个足够好的基准点，其步骤如下：

• 分组：将输入列表按5个元素一组进行分割。
• 寻找每组中位数：对每组进行常数时间的排序，找出每组的中位数。由于每组大小固定（≤5），此步骤总体为 (O(n))。
• 递归寻找中位数的中位数：将上一步得到的所有“组中位数”作为一个新列表，递归调用本算法找到这个新列表的中位数。此递归过程的时间复杂度为 (O(n))（通过数学分析证明），最终找到的这个中位数即被选为快速选择的基准点。

为什么这是一个好的基准点？ 通过可视化分析（将元素按组排列成矩阵），可以证明该基准点至少能将剩余元素数量减少约30%。最坏情况下，后续需要处理的递归子问题规模分别为原问题的 (n/5) 和 (7n/10)。算法总运行时间 (T(n) = n + T(n/5) + T(7n/10))，通过数学归纳法可证明其为 (O(n))。

4. 实际应用与对比

• 在实践中，随机选择基准点通常足够快且实现简单。C++ 标准库采用的是介于两者之间的 introselect 算法，它在随机方法（快速）和确定性方法（保证最坏情况）之间取得平衡。
• 文章提供了一个比较图，展示了在快速选择过程中，使用“中位数的中位数”算法选定的基准点，相比于随机基准点，通常能考察更少的元素，从而验证了其作为基准点选择策略的有效性。
• 文末提及，2017年的一篇新论文已使中位数的中位数方法在性能上具备与其他选择算法竞争的能力。

生成数独的乐趣与研究

项目背景

作者出于为家人制作免费无追踪数独应用（sudoku.tn1ck.com）的初衷，在开发过程中深入研究了如何生成指定“人类感知难度”的数独，并进行了系统性分析。

数独求解器开发

为生成数独，首先需要求解器。求解器的迭代次数被用作衡量难度的基础。

算法演进

1. 暴力法：最基础的方法，逐一尝试填充，效率极低。
2. 改进暴力法：在填充过程中遇到无效配置立即跳过，大幅提升速度。
3. 最小剩余值启发：采用启发式策略，优先填充可选数字最少的格子，进一步减少迭代次数。
4. 约束满足问题（CSP）与弧相容性（AC3）：
   • 将数独建模为CSP问题（变量为格子，域为数字1-9，约束为行、列、宫内数字唯一）。
   • 利用AC3算法通过约束修剪每个格子的可能值域（弧相容）。
   • 对于复杂数独，仍需结合搜索策略（如最小剩余值）进行回溯。此方法最为高效和优雅。

数独难度评级

核心问题

如何自动评估数独对人类解谜者的难度？

研究方法

• 原理：使用不同求解器的迭代次数作为成本函数，迭代次数越多，难度越高。
• 数据来源：从 websudoku.com 和 sudoku.com 收集了不同难度等级（如简单、中等、困难、恶魔）的数独样本。
• 分析发现：
  • 迭代次数的对数近似正态分布，这符合数独求解属于NP难问题的特性。
  • 所有求解器（包括基础暴力法）的迭代次数与网站标注的难度等级都呈现极高的相关性（暴力法达到完美相关）。
  • 这引发了一个潜在问题：网站可能也使用类似迭代次数的方法评级，因此该指标是否真正代表人类感知的难度仍有待验证（需真人测试数据）。

生成特定难度数独

作者的方法

1. 初始化：从空网格开始，随机填入数字，生成一个有效且解唯一的完整数独。
2. 调整难度：通过删除或增加数字来调整难度，使其迭代次数接近目标值。
3. 处理极值：若无法再删除数字（达到最大难度）仍低于目标，则重新开始生成。
4. 迭代优化：重复过程直至迭代次数接近目标。

与论文算法的对比

• 论文算法（山丘爬升法）：
  • 从“包含随机数字的初始谜题”开始，通过随机增删改单个数字进行爬山搜索，以最小化与目标难度迭代次数的差距。
  • 缺点：初始配置可能无效（非唯一解），导致成本函数为无穷大，使算法效率极低，大部分时间浪费在寻找有效配置上。
• 作者方法的优点：
  • 先确保有效性：从一开始就生成有效且解唯一的数独，使后续难度调整更高效。
  • 约束引导：生成过程受数独逻辑约束引导，更加可靠和高效。

总结

该项目不仅构建了一个完整的数独应用，更深入探索了求解算法、难度量化模型和生成策略。研究表明，通过控制算法迭代次数可以有效地生成不同难度的数独，而作者提出的生成方法在效率上优于参考文献中的传统方法。整个分析过程的数据和代码均已开源。

本文讲述了作者通过逆向工程解决新购网络音箱音量控制不精准问题的全过程。

问题背景

作者新购的JBL智能音箱音量过大，在其公寓的安全听音范围内仅使用约10%的音量范围。常规控制方式（手机/电脑音量条或Spotify滑块）提供的调节精度不足，要么滑动范围太小，要么音阶跳跃过大，难以获得理想的中低音量。

探索与发现

作者发现音箱拥有一个未公开文档的Web管理界面。通过浏览器开发者工具逆向分析，找到了音箱的HTTP API：

• GET /api/getData：用于读取设备数据（如音量）。
• POST /api/setData：用于写入设备设置。

进一步探索发现，JBL与KEF等品牌（同属Harman/Samsung集团）的网络音箱可能共享部分代码。作者还从系统日志中发现了配置文件结构，并研究了settings:/mediaPlayer/attenuation和settings:/hostlink/maxVolume等参数，但遗憾的是这些参数并非用于设置最大音量上限的解决方案。

解决方案：自定义网页控制器

由于无法在音箱端设置最大音量，作者决定构建一个自定义的网页音量控制器，将可调节范围限制在自己需要的区间内（例如0-25）。

他使用 Bun 运行时创建了一个简单的本地Web服务器（server.ts），主要功能包括：

1. 提供网页：包含一个全屏宽度的音量滑块，样式经过优化（滑块轨道随音量变化显示渐变色）。
2. 代理API请求：网页通过fetch向本地服务器的/volume端点发送请求，服务器再将请求转发至音箱的API，从而避免浏览器直接请求时的跨域资源共享（CORS）问题。
3. 音量控制：
   • 获取音量：从音箱的player:volume路径读取当前音量并返回给网页。
   • 设置音量：接收网页发来的新音量值，在本地进行安全检查（防止设置过高音量），然后通过音箱API的/api/setData端点进行设置。

未来计划

作者表示目前的网页方案已可用，但最终目标是制作一个物理音量旋钮。计划使用ESP32开发板搭配旋转编码器，并配以精心设计的外壳和手感优良的旋钮，可能还会加入力反馈以实现音阶变化时的触觉提示。

Apple Maps 网页版（测试版）现已发布，用户可通过浏览器直接访问地图服务。

主要功能：

• 提供驾车和步行导航路线。
• 支持查找地点信息，包括照片、营业时间、评分和评论。
• 可直接通过地图地点卡片进行操作（如订购食物）。
• 提供精选“指南”，帮助用户探索世界各地的餐饮、购物和游览目的地。
• 未来几个月将推出更多功能，如“环顾四周”街景视图。

开发者支持：

• 所有开发者（包括使用 MapKit JS 的开发者）均可将链接定向到网页版地图，以便用户获取驾车路线和详细地点信息。

兼容性与语言：

• 目前仅支持英语界面。
• 兼容 Mac 和 iPad 上的 Safari 和 Chrome 浏览器，以及 Windows PC 上的 Chrome 和 Edge 浏览器。
• 未来将扩展对更多语言、浏览器和平台的支持。

注意：

• 服务可用性可能因地区而异。

X 将“水枪”表情符号重新设计为“真枪”

核心事件

• X（前 Twitter）将其 🔫（水枪/手枪）表情符号重新设计为真实的枪支（firearm）。
• 这一改动逆转了 2016 年至 2018 年间各大主流表情符号供应商将该表情从“真枪”统一改为“水枪”的跨平台趋势，与其他主要平台的设计背道而驰。

更新细节与平台差异

• 网页端：该更新于 2024 年 7 月 18 日（世界表情符号日之后）开始在 X 的网页客户端推出，网页端目前仍使用 Twemoji 表情集。随后在 8 月份，X 又发布了一版视觉效果更强烈的更新设计。
• 移动端：自 2023 年 2 月起，X 在移动端已停止使用 Twemoji，转而使用设备的原生表情符号（iOS 使用 Apple 原生，Android 使用系统原生），因此移动端用户目前无法看到这一更改。不过，负责此更改的 X 工程师表示，团队将“很快更新移动端的渲染”，并指出当前的设计并非最终版本。

历史背景与 Twemoji 现状

• 行业历史：Apple 于 2016 年率先将枪支表情改为水枪，其他主要供应商在 2018 年全面跟进完成转换。X 此次改动打破了这一行业共识。
• Twemoji 维护现状：这是 X 自 2023 年 7 月（更新了 😷、🥺 和 🥹 表情）以来，首次对其使用的原始 Twemoji 表情集进行更新。此外，由前 Twemoji 设计师在 GitHub 上维护的一个独立开源 Twemoji 分支（目前被 Discord 使用）中，该表情仍保留 2018 年的“水枪”设计。

《生物电路设计》是一本基于网络的书籍（目前仍在编写中），专注于生物学中细胞和发育系统的定量研究。书籍的核心内容是探讨控制微生物行为和多细胞发育的特定基因电路的架构，旨在通过深入学习，帮助读者理解系统生物学的关键原则，并培养建模与分析基因电路的实用技能。

需要注意的是，本书尚处于建设阶段。近期，作者团队切换了新的构建系统，这可能导致书中部分链接失效、图表显示异常等技术问题，敬请读者谅解。

在版权方面，本书版权归Michael Elowitz和Justin Bois所有（2017–2026年）。除特别标注来源的图片外，所有内容均依据知识共享署名-非商业性使用-相同方式共享4.0国际许可协议（CC BY-NC-SA 4.0）发布；书中包含的代码则采用MIT许可证授权。

互联网名称与数字地址分配机构（ICANN）已向运营“.top”顶级域名的中国注册商江苏邦宁科技有限公司发出最后通牒，要求其在2024年8月中旬前建立有效的网络钓鱼举报处理及滥用域名暂停机制，否则将面临经营许可被撤销的风险。该警告源于最新研究报告显示，”.top”已成为过去一年钓鱼网站第二常用的顶级域名后缀，仅次于”.com”。

事件核心

• ICANN的警告：ICANN于7月16日致信指出，江苏邦宁科技未能及时、全面地调查和处理涉及”.top”域名的网络钓鱼攻击报告，且该公司长期拖欠ICANN会员费，甚至未查看相关邮件通知。
• 数据支持：Interisle咨询集团的最新研究分析了近200万起网络钓鱼攻击，发现”.top”域名在2023年5月至2024年4月间，其新增域名中有超过4%被用于钓鱼网站。该顶级域名约有276万个注册域名，其中超过11.7万个在过去一年被用于钓鱼。

行业背景与趋势

• 历史问题：江苏邦宁科技长期与网络钓鱼相关。早在十多年前（“.top”顶级域名尚未推出时），该公司已是钓鱼网站的第四大常见来源。
• 钓鱼攻击新动态：
  • IPFS的利用：通过去中心化网络星际文件系统托管钓鱼页面的数量在过去一年激增1300%，达到约1.9万个站点，这使得钓鱼网站更难被关闭。
  • 域名迁移：此前最大的钓鱼域名注册商Freenom倒闭后，钓鱼者转向其他低成本顶级域名（如”.xyz”、”.info”等）以及允许匿名免费注册的子域名服务（如Google的blogspot.com、Weebly、GitHub.io等）。其中，blogspot.com上的钓鱼网站数量去年增长超过230%。
• 批量注册问题：研究报告指出，至少27%的钓鱼域名通过批量注册（即同一注册人在短时间内快速注册数百或数千个域名）方式获得。案例中，一名钓鱼者在8小时内注册了17,562个随机字母组成的”.lol”域名。

ICANN执法模式观察

• 公开执法趋势：ICANN通常优先通过私下方式解决合规问题，公开发布执法通知往往意味着注册商或注册局已无视私下的沟通尝试。
• 执法原因分析：对近年来ICANN执法通知的回顾显示，至少75%的案件中，“未能缴纳ICANN年度会费”是警告信的主要原因。ICANN前安全副总裁Dave Piscitello表示，绝大多数违约通知都源于欠费，并认为其他安全违规理由可能只是表面文章。
• ICANN回应：ICANN表示，在发出任何违约通知前，会对相关合同方的整体合规状况进行全面检查。未能履行合同义务（无论涉及DNS滥用、RDDS等）的当事方，往往也存在拖欠费用的情况。其大部分调查在非正式阶段通过要求合规方展示整改计划等方式解决。

结论：此次针对”.top”注册商的公开警告凸显了域名注册管理机构在防止域名滥用方面面临的持续挑战，以及ICANN在平衡合规执法与网络安全监管上的复杂性。钓鱼攻击者不断利用低成本顶级域名、子域名服务和去中心化技术，寻找新的“避风港”，这要求整个域名生态系统采取更主动、更有效的防御措施。

瑞士立法强制公共部门使用开源软件

核心要点

• 法律依据：瑞士通过《联邦电子手段履行政府任务法》（简称EMBAG），于2023年立法并于近期生效，成为全球范围内少见的强制公共部门采用开源软件的法律。
• 核心要求：所有公共部门机构必须公开其开发或委托开发的软件源代码。
• 例外情况：若涉及第三方权利冲突或安全问题，可不公开代码。
• 配套机制：法案第9条允许公共机构为公共利益提供维护、集成、基础设施安全等附加服务，并可获得相应报酬。

政策背景与影响

• 推动人物：伯尔尼大学公共部门转型研究所所长马蒂亚斯·斯图尔默博士是该政策的重要倡导者。
• 多重效益：
  • 政府可减少对单一供应商的依赖（供应商锁定）。
  • 企业可拓展数字化业务解决方案。
  • 纳税人能通过竞争和创新增加获得更优质、低成本的IT服务。
• 全球意义：此举被视为欧洲多国摆脱闭源软件依赖趋势中的突破性案例。

相关动态

• 德国某州已弃用微软产品，转向使用Linux和LibreOffice等开源替代方案，进一步显示欧洲公共部门对开源软件的接纳趋势。

汽车行业软件开发严重依赖C语言，但C本身能力有限，导致为弥补其缺陷而诞生了大量专有工具、领域特定语言（DSL）、文件格式和复杂流程。文章以汽车行业为例，剖析了这种现象背后的三个核心问题及产生的工具泛滥问题。

核心问题与工具泛滥 C语言缺乏强大的抽象能力和元编程功能，无法直接高效地解决：

1. 实时系统交互：需要与运行中的ECU（电子控制单元）交互、监控和调试，而C的编译-烧录-重启循环效率低下。
2. 高层抽象表达：C过于底层，难以表达系统级架构和业务逻辑，导致“只见树木不见森林”。
3. 开发流程组织：围绕C代码的构建、配置管理、需求同步、团队协作等流程复杂，需要额外工具支持。

这些问题催生了无数工具和DSL，各自形成“王国”：

• 工具链：如Vector公司的CANoe用于网络模拟与测试，CANape用于测量与标定。它们功能强大，但各自为政。
• 脚本语言：工具内嵌多种脚本语言（如CANoe的CAPL、CANape的CASL），语法虽类C，但仍是独立的DSL。
• 文件格式：为跨工具交换数据，诞生了众多非人类可读的专有格式，如DBC（CAN信号）、ODX（诊断）、A2L（标定内存地址）、ARXML（AUTOSAR配置）等。这些格式构成了工具间难以跨越的“鸿沟”。
• 代码生成：为了弥合DSL、配置文件与C代码间的鸿沟，广泛使用代码生成器，但这引入了新的复杂性和构建步骤。

行业标准与开发模式演变

• AUTOSAR标准：旨在通过标准化软件组件和接口实现代码复用。然而，它引入了极度复杂的架构、海量规范（超过13000页）和配套的GUI工具（如DaVinci）。开发者工作常变成配置工具和点击按钮，而非编写代码，导致开发体验不佳，争议巨大。
• 基于模型的设计：如Simulink等图形化建模工具允许用图形块（背后是MATLAB）构建系统，然后自动生成符合MISRA C规范的代码。这使领域专家可以不直接编写C代码，但本身形成了一个庞大复杂的新工具生态。
• 自动驾驶DSL：为描述驾驶场景和道路网络，行业又制定了如OpenSCENARIO和OpenDRIVE等新的DSL和XML格式。

结论与反思 汽车行业表面依赖C语言，实则构建了一个庞大、支离破碎的工具和DSL生态系统。这些工具旨在解决C的不足，但自身带来了新的复杂性、学习成本和集成难题。作者认为，像Lisp宏这样具有强大元编程能力的语言，从理论上可能避免这种工具泛滥，允许开发者在统一的语言内创建内部DSL和元编程。然而，在现实中，考虑到行业规模、成本、现有技术栈和人才储备，这种理想化的转变面临巨大挑战。汽车行业目前的状况，是编程语言能力不足与工业界复杂需求共同作用的结果。

文章探讨了设计工具Figma在AI时代可能面临的挑战，认为其可能成为设计流程中的“尴尬中间环节”。核心观点如下：

• 设计流程变化：许多会编程的设计师正减少在Figma中的时间，倾向于通过手绘或直接编写代码快速推进设计，跳过Figma的“高保真”绘制阶段。
• Figma的定位：Figma的流行源于编码耗时更长，设计师需在速度与保真度间权衡，但这种方式实质是“绘制漂亮图片”，并非真正高保真。
• 当前AI工具的局限：多数AI工具专注于从自然语言直接生成设计组件，跳过了关键的设计思考阶段，更像是面向非设计师的玩具，而非深刻影响设计流程的工具。
• 未来方向：AI的真正价值可能在于：1）将线框图转化为前端代码；2）灵活运用和扩展设计系统；3）从截图和情绪板生成视觉元素。设计师应聚焦于关键UX思考，而非被AI替代。
• 工具演进：未来可能需要介于Balsamiq与tldraw之间的工具，用于快速构思和结构化线框图，作为AI的输入。而基于矢量的Figma可能不再是软件开发过程中必要的环节。

纠正记录：人类 1，黑猩猩 0

2012年，作者因观看黑猩猩Ayumu的视频而撰文《黑猩猩 1，人类 0》。视频中，Ayumu能快速回忆屏幕上短暂闪现的数字及其位置，其表现远超作者（普通人类）的水平。Inoue和Matsuzawa（2007）在《当代生物学》上的研究记录了这一表现，并曾用于主张黑猩猩的工作记忆优于人类。该观点在媒体和网络中被广泛传播。

然而，作者后来发现，这一结论缺乏基础。Peter Cook和Margaret Wilson（2010a）在《科学》杂志指出关键方法论缺陷：Ayumu接受过大量练习，而与之比较的人类则完全没有练习。后续研究（Silberberg & Kearns, 2009）表明，人类经过适度练习后，即可达到Ayumu的水平。Cook和Wilson（2010b）甚至训练两名大学生达到超越Ayumu的表现。

更近期的文献综述（Read et al., 2022）指出，黑猩猩的工作记忆水平大致相当于4-5岁人类儿童，且约在两个数字（±1）的范围内，并未超越成人。该综述甚至质疑此类任务是否真正测试工作记忆。

结论：最初关于黑猩猩工作记忆优越的说法不成立。Ayumu的表现初看令人印象深刻，但经科学审视后，其优势主要源于训练差异而非先天认知优越性。这一误解的传播，干扰了对黑猩猩记忆更深入的研究，也影响了人类与灵长类进化相关的科学探索。

这篇文章基于历史学家克里斯汀·哈林的著作《业余无线电的技术文化》，深入探讨了业余无线电（ham radio）爱好者社群的历史、文化规范及其生活影响。核心内容如下：

社群基础与文化形成 业余无线电爱好者（常被称为“hams”）自20世纪10年代起，就通过无线电进行远距离通信。他们形成了一个独特的技术社群，拥有自己的会员资格、行为准则、价值观和专业术语。学习社群文化是成为该领域一员的关键，业余无线电出版物在传授技术知识的同时，也积极教导新人行为规范。

行为准则与自我监管 美国无线电中继联盟（ARRL）发布的《业余守则》是著名的行业行为规范，倡导爱好者具备绅士风度、忠诚、进取、友善、平衡和爱国等特质。社群通过同侪压力执行规则，对违规者进行批评、惩罚甚至驱逐。同时，爱好者也协助监管机构追踪无证操作者，以维护社群形象和边界。

许可证与技术等级 获取业余无线电执照是进入该社群的唯一官方门槛，考试内容涵盖电子理论、无线电法规及莫尔斯电码能力。执照呼号成为爱好者的技术身份象征。然而，联邦通信委员会（FCC）推行的“激励性执照”制度（根据技术水平划分不同等级）引发了社群内部关于技术分级的争议，部分爱好者认为这破坏了社群的团结。

莫尔斯电码的技术与身份意义 莫尔斯电码长期被视为业余无线电的核心通信方式，爱好者推崇其可靠性、精准性和独特美感。使用电码能体现操作者的个性（称为“fist”），并具有一定的私密性。尽管语音通信逐渐普及，但围绕代码与语音通信的优劣之争持续存在，反映了爱好者对技术纯粹性的不同追求。1991年FCC废除基础执照的电码要求后，引发了忠诚于电码的爱好者的强烈反对。

专业语言与沟通实践 社群通过独特的术语、缩写（如源自电报员的菲利普斯码和Q简语）和标准字母拼读法来强化身份认同和沟通效率。这些语言实践将电码元素融入日常交流，形成了只有内部成员能完全理解的“秘密语言”。爱好者强调通信中的语言精准性，并努力规范口语习惯。

社交与社群维系 无线电联系常延伸至线下。交换确认卡片（QSL卡片）是常见的后续联系形式，卡片设计体现发送者的个性或地域特色。俱乐部聚会（称为“eyeball contacts”）则进一步巩固了空中结识的友谊，俱乐部通过活动、会议和通讯刊物为爱好者提供归属感和文化濡化。

政治沉默与技术文化 由于无线电通信的公共性和政府监管，爱好者在无线电活动和社群交流中通常避免政治讨论，以防招致更严格的管制。

总结而言，业余无线电爱好者构建了一个以技术为基础的深厚文化体系，其行为规范、语言习惯、技术偏好和社交方式都紧密围绕无线电技术展开，并通过内部教育、自我监管和社群互动不断强化。

Toybox 项目概述

Toybox 是一个开源项目，旨在将众多常用的 Linux 命令行工具整合到一个符合 BSD 许可协议的单一可执行文件中。其设计原则是追求简单、小巧、快速，并力求遵循 POSIX-2008 和 LSB 4.1 标准。

核心目标

Toybox 的主要目标是让 Android 系统具备自我构建能力。具体而言，它通过改进 Android 的命令行工具集，使得在原生 Android 系统上能够完全从源代码构建出可安装的 Android Open Source Project (AOSP) 镜像。Google 自 Android Marshmallow (2015) 版本起，已将 Toybox 集成并应用于 AOSP 中。

设计理念与背景

1. 理论基础：Toybox 被视为构建一个理论上的“最小原生开发环境” 的四分之一。该环境由四个部分组成：
   • 一套类 POSIX 命令行工具集（即 Toybox 所提供的部分）
   • 一个编译器
   • 一个 C 库
   • 一个内核 这个环境的目标是能够从源码重建自身，并构建 Linux From Scratch (LFS) 和 AOSP。
2. 项目起源：Toybox 是在维护者之前项目 Aboriginal Linux 的经验基础上全新重写的。鉴于 BusyBox 的许可证与 Android 不兼容，Toybox 采用了与 Android 兼容的许可证从头开始实现。
3. 与 BusyBox 的对比：Toybox 并非 BusyBox 的分支，而是一个全新的设计。两者在设计理念和许可证上有所不同。

技术实现与标准

• 遵循标准：大多数命令的实现参考 POSIX-2008 (Single Unix Specification v4)。同时，也参考 Linux man pages、Linux Standard Base (LSB) 以及现有命令实现（包括 Android toolbox）的行为。
• 构建系统：Toybox 包含一个集成了最小原生开发环境的构建器。执行 make root 可创建一个 Toybox chroot 环境；通过指定 LINUX= 参数指向内核源码，可以创建一个可在 QEMU 模拟器下运行的可启动微型系统。
• 项目路线图：项目有一个明确的路线图，列出了为实现用 Toybox 构建 LFS 和 AOSP 而需要添加的所有命令及其理由。构建 LFS 所需的命令少于构建 AOSP 所需的命令。
• 配置：make defconfig 会启用所有功能完整的命令；allyesconfig 则会启用包括部分实现和调试功能在内的所有命令。

当前状态与资源

• 版本：当前发布版本为 0.8.13 (截至 2025年10月14日)。
• 命令状态：已实现和计划中的命令列表在项目的 status page 和 roadmap 中持续更新。
• 获取方式：项目通过 git 仓库维护，同时提供源码包和发布版的静态二进制文件。
• 追踪进展：可以通过维护者的开发日志和项目的邮件列表来跟踪项目动态。

MINT-1T 是一个开源的多模态交织数据集，包含一万亿文本标记（tokens）和34亿张图像，其数据规模比现有开源数据集扩大了约10倍。该数据集的一个重要特点是纳入了以往未被充分利用的数据来源，例如 PDF文档和ArXiv论文。

参考文献

@article{awadalla2024mint1t,
      title={MINT-1T: Scaling Open-Source Multimodal Data by 10x: A Multimodal Dataset with One Trillion Tokens}, 
      author={Anas Awadalla and Le Xue and Oscar Lo and Manli Shu and Hannah Lee and Etash Kumar Guha and Matt Jordan and Sheng Shen and Mohamed Awadalla and Silvio Savarese and Caiming Xiong and Ran Xu and Yejin Choi and Ludwig Schmidt},
      year={2024}
}

空间填充曲线的构造性探讨

历史背景与基本问题

• 1890年，朱塞佩·皮亚诺发现了一条正方形填充曲线；一年后，大卫·希尔伯特发表了其变体。原始论文极其简洁（皮亚诺3页，希尔伯特2页）。
• 核心问题：这些经典的曲线是否在构造性数学意义上具有满射性？即能否为正方形中任意点构造一个参数值？

希尔伯特曲线的性质与局限

• 经典构造：希尔伯特曲线 (\gamma : [0,1] \to [0,1]^2) 是一致连续映射序列 (\gamma_n) 的极限。
• 定理1（经典）：对于正方形中的任意点，其到希尔伯特曲线的距离为零。这意味着在经典数学中曲线是满射的。
• 构造性问题：希尔伯特曲线具有自相似性，由四个缩放因子为 (1/2) 的副本组成，覆盖单位正方形的四个象限。构造性地无法证明这四个恰好相邻的象限完全覆盖整个正方形，因此无法直接得出满射性。

构造性解决方案：广义希尔伯特曲线

• 方法：引入缩放因子 (\alpha)，定义广义希尔伯特曲线 (\gamma^\alpha)。
• 关键结果：
  • 当 (\alpha = 0.5) 时，即为经典希尔伯特曲线。
  • 当 (\alpha = 0.4) 时，曲线不能填满正方形。
  • 当 (\alpha > 0.5) 时，四个缩放副本会重叠而非仅仅相接。这使得在有限构造阶段就能确保覆盖整个正方形。
• 定理2（构造性满射）：假设依赖选择公理，对于 (1/2 < \alpha < 1)，广义希尔伯特曲线 (\gamma^\alpha) 是满射的。
  • 证明思路：定义四个变换 (T_0^\alpha, T_1^\alpha, T_2^\alpha, T_3^\alpha)，每个将单位正方形映射到边长为 (\alpha) 的小正方形。当 (\alpha > 1/2) 时，这些区域重叠并覆盖整个正方形。利用依赖选择公理，可为任意点 (p) 构造一个由这些变换组成的序列，从而找到参数 (t) 使得 (\gamma^\alpha(t) = p)。

在特定拓扑斯中的限制

• 定理3：在单位正方形上的层拓扑斯 (\mathrm{Sh}([0,1]^2)) 中，不存在正方形填充曲线。
  • 原因：在该拓扑斯中，“(\gamma) 是满射”是一个极强的条件，意味着 (\gamma) 需具有局部截面。然而，由于域不变性定理，对于恒等映射这样的 (p)，不存在这样的连续截面（除非开集为空）。
  • 重要推论：尽管如此，定理1在该拓扑斯中仍然成立，即经典希尔伯特曲线在该框架下仍然“不留空隙”（即其像集稠密），但无法构造一个真正的满射函数。

总结

1. 构造性满射的实现：通过将希尔伯特曲线的缩放因子 (\alpha) 设为大于 (1/2) 的值，并依赖选择公理，可以构造出一条在构造性意义下满射的正方形填充曲线。
2. 根本限制：在某些数学框架（如特定的层拓扑斯）中，由于拓扑障碍（域不变性），构造一个具有真正局部满射性的曲线是不可能的。然而，曲线的稠密性依然成立。
3. 核心思想是，通过调整构造参数（使区域重叠），可以弥补经典构造中因“恰好相接”而在构造性数学中产生的逻辑缺陷。

《龙与地下城》如何教会我撰写alt text

从游戏经验中汲取灵感

作者在高中和大学期间沉迷于桌面角色扮演游戏《龙与地下城》，并采用“心灵剧场”模式（即纯口头描述，不依赖地图或微缩模型）。这种游戏方式强调口头叙事和想象力，为alt text写作提供了基础。作者通过订阅《龙》杂志，从建议专栏中学到关键技巧：描述时应优先突出最重要的信息，以避免混淆或冗长。

优先级原则的核心应用

• 示例对比：原描述可能将房间细节置于龙攻击之前，导致重点模糊；改进后先强调龙攻击的紧迫性，再补充环境细节，使描述更生动、相关。
• 信息层次：在alt text中，应首先传达图像的核心内容（如新产品标记只需简单“新！”），再根据上下文添加细节。这有助于用户快速理解关键信息，尤其当图像非主要焦点时。

上下文、语气与情绪

• 上下文决定详略：琐碎物品（如酒吧木杯）无需过度描述，以免偏离主题；重大事件（如龙攻击或NASA天文照片）则需丰富细节和情绪渲染，以增强沉浸感。
• 语气与情绪控制：alt text应通过语言选择（如感叹号、生动词汇）传递情绪。例如，描述无聊会议中突然出现的诡异小丑时，先建立沉闷氛围再突转恐惧，以强化叙事效果。

屏幕阅读器用户体验

• 线性阅读顺序：屏幕阅读器会从头到尾读取alt text，因此重要信息前置能让用户快速获取关键点，并决定是否继续收听细节。
• 避免干扰：alt text中不允许使用格式化标签（如加粗、链接），所以结构应简洁。非关键细节后置可节省用户时间，尤其在重复导航时。

alt text作为艺术与实践

• 权力与责任：alt text作者如同游戏主持人，通过描述塑造用户对图像的感知，应确保残障用户获得与视觉用户等价的体验，包括描述种族、性别等细节。
• 技能培养：撰写alt text需要练习，初始可能不熟练，但越写越精。作者推荐了多个资源（如WAI指南、BBC文章等）来帮助提升技能，强调alt text写作可以兼具信息性和愉悦性。

总结：从《龙与地下城》的叙事技巧中，作者学会了通过优先级、上下文和情绪控制来撰写有效的alt text，以提升辅助技术用户的体验。

本文详细介绍了在STM32H735微控制器与FPGA（如Xilinx Kintex-7或Artix/Kintex UltraScale+）之间建立内存映射接口的架构与实现。

架构选择
作者采用MCU+FPGA双芯片方案，而非SoC FPGA（如Zynq）。主要原因包括：

• 使用Cortex-M MCU更易于在无OS或轻量RTOS环境下编程。
• MCU内置大容量SRAM（564 kB）和Flash（1 MB），避免了为常用固件（<200 kB）设计DDR SDRAM的复杂性。
• 分离的封装（两个较小BGA）简化了PCB布线，并允许芯片间保持布局灵活性。
• 安全边界分离：FPGA可拒绝未经签名的比特流，MCU内存和外设不受FPGA直接访问。
• 可灵活搭配不同MCU与FPGA以优化成本与功能。
• STM32具备硬件AES和随机数生成器，而Zynq平台缺失这些特性。

内存映射接口
经过尝试Quad SPI后，最终选用**灵活内存控制器（FMC）**作为MCU侧桥接，将STM32的AXI总线与FPGA内部互联连接。选择FMC的主要原因：

• FMC本身无硬件缓存或预取，仅依赖Cortex-M7的L1缓存。其首个存储体（地址0xC000_0000）默认配置为强序、非缓存的设备内存，无需额外配置MPU。
• 采用同步PSRAM模式，提供自由运行时钟（可用于驱动FPGA内部逻辑）和硬件等待信号，允许FPGA在需要额外延迟时暂停总线。
• 使用26个LVCMOS33引脚（时钟、16位复用地址/数据、控制信号、字节写使能、片选及高位地址）可映射1 MB地址空间，占用约一半的I/O组。

硬件设计
为测试而设计了一款6层PCB测试板，采用低成本FR-4类材料。关键组件：

• STM32L431（QFN-48）作为监控与电源时序控制器。
• STM32H735（201-BGA）作为主处理器。
• Xilinx XC7S25 Spartan-7 FPGA（FTGB196）作为对端。
• MCU与FPGA通过FMC、OCTOSPI和10/100 RMII接口连接（当前固件仅使用FMC）。
• FPGA还连接千兆以太网PHY、PMOD扩展口、LED等。

集成平台视角
从MCU看，FPGA映射为64 MB地址空间（起始于0xC000_0000），其中仅1 MB已连接。支持32位读写访问（含等待状态传播），16/8位访问基本实现。不支持64位访问（因FPGA端总线为32位）。

FPGA内部设计
采用SystemVerilog实现，主要模块：

• 三速RGMII MAC（配内存映射收发FIFO）
• MDIO控制器
• 32位GPIO端口
• 系统健康监测模块

总线架构
在FPGA内部采用32位APB作为控制平面互联（而非AXI），因其更轻量且适合配置寄存器访问。设计使用树状APB桥接器：根桥划分两个64 kB段，再分别细分用于通用外设（1 kB段）和以太网FIFO（4 kB段）。桥接器为组合逻辑，便于通过寄存器切片调整时序。

FMC桥接器
将FMC总线双向转换为APB事务。内部PLL锁定FMC时钟（需自由运行），生成两个同频时钟用于数据捕获与发送，相位可调以优化时序余量。正确传播APB延迟至FMC的NWAIT信号。未来计划利用PSLVERR信号触发MCU中断。

性能测试
在FMC时钟125 MHz、PLL相位-30度配置下，使用iperf3进行UDP反向传输测试（STM32发送，PC接收）。驱动采用无DMA的忙等循环，数据置于DTCM中。测得持续吞吐率为284 Mbps，作者认为已满足需求。若提升FMC时钟至250 MHz可能更快，但当前已足够。

总结
该方案运行稳定，接口实现相对简单。虽提高时钟速率可能面临系统同步总线的时序挑战，但无需动态链路训练。未来可能扩展64位传输支持或改用AHB总线以提升连续传输效率，此架构将成为作者大型FPGA+MCU项目的基础。

Hooper：AI驱动的篮球数据统计与集锦生成应用

产品概述

Hooper 是一款专为篮球运动设计的智能手机应用，利用人工智能自动追踪比赛数据并生成视频集锦，旨在提升比赛分析与训练效率。

核心技术

应用基于计算机视觉与AI技术。无需特殊摄像头或手动标记，仅通过智能手机拍摄的视频，AI即可自动识别球员与关键赛事节点，完成数据统计、高光集锦生成及逐球分析。

核心功能

• AI 集锦生成 (AI Mixtapes)：自动剪辑精彩片段，便于回顾投篮细节与社交分享。
• 智能视频浓缩：自动剔除无效时间，将2小时比赛浓缩至约15分钟，支持快速定位高光时刻及重播进球与失误。
• 数据与进度追踪 (Game Stats & Profile)：详细记录比赛数据，监控个人成长轨迹，并支持与他人进行数据对比。
• 球队与赛事管理：支持添加球员以追踪团队数据；提供“野球群 (Pickup groups)”功能，便于好友组队、安排比赛并统计战绩。

使用流程

1. 架设手机进行实况录制或上传已有比赛视频。
2. 系统通过AI自动分析处理。
3. 查看并编辑比赛数据与视频集锦。

适用受众

广泛适用于篮球爱好者、家长、球队、联赛组织者及业余野球群体。

市场表现与用户反馈

• 运营数据：已累计追踪超100万次投篮，处理超1万场比赛，服务覆盖全球30多个国家。
• 用户评价：用户高度认可该应用在免除手动剪辑烦恼、提升社群互动及赛事录像分析方面的价值。应用让球员能更专注于打球本身，并通过快速过滤进球与失误显著提高了赛后复盘效率。

这篇文章介绍了在 PostgreSQL 中实现版本化有限状态机（FSM）的方法，其主要改进包括引入 FSM 版本控制、优化性能与存储以及增加防错保护。

核心改进包括：

1. 类型优化：将状态和事件从文本存储改为自定义的枚举类型（order_state 和 order_event），以减少存储空间。同时，将 order_id 的类型从整数改为 UUID。

2. 转换机制改进：使用一张映射表（order_events_transitions）来定义状态转换，取代了原先的 switch 语句。该表包含当前状态、触发事件和下一状态三列。通过一个 SQL 函数执行查询，如果找不到有效转换，则将状态置为 'error'。

3. FSM 图版本化：这是为了解决业务流程变化导致历史数据不一致的问题。

   • 创建了版本表（order_fsm_versions）来存储不同版本号及其状态（live、deprecated、obsolete）。
   • 在 order_events（记录事件）和 order_events_transitions（定义转换）表中添加了 version 字段，用于关联具体的 FSM 版本。
   • 相关函数和聚合也进行了修改，以接受版本号参数，默认使用当前生效的最新版本。
   • 通过触发器（order_events_trigger_func）校验插入事件的版本状态，禁止向已过时（obsolete）的版本插入事件。

版本化工作流程：当业务流程变化时，可以创建新的 FSM 版本（如版本 2），并废弃旧版本（将版本 1 状态设为 deprecated）。新事件默认使用最新生效的版本，从而确保新订单遵循新规则，而历史订单的事件流则基于其原有版本保持一致性。

文章最后指出，上述实现仍是一个实验性的概念验证（POC），尚未达到生产就绪状态。

Julia for Economists (2022) 课程摘要

本课程是针对经济学研究计算的 Julia 编程系列教学活动，由作者在斯坦福商学院（GSB）于 2022 年讲授。课程形式包括每月一次的讲座、实用示例和引导项目，每次时长约两到四小时。

课程结构

• 灵活性与独立性：每月课程覆盖不同主题，参与者可单独参加，但第一个课程介绍 Julia 基础知识，对不熟悉 Julia 的学习者可能有助于后续课程。
• 教学材料：每个课程均提供录音和讲义；部分课程还包括示例数据和项目解决方案。

课程主题详情

1. Session 1: Julia 基础

   • 内容：Julia 编程语言的基础知识。
   • 附带材料：录音、讲义、示例数据、项目解决方案。

2. Session 2: 并行化

   • 内容：并行计算技术在 Julia 中的应用。
   • 附带材料：录音、讲义。

3. Session 3: 优化与自动微分

   • 内容：优化方法和自动微分在经济学计算中的使用。
   • 附带材料：录音、讲义。

4. Session 4: 高性能 Julia

   • 内容：提升 Julia 代码性能的技巧和策略。
   • 附带材料：录音、讲义。

5. Session 5: 计算贝叶斯统计

   • 内容：使用 Julia 进行计算贝叶斯统计方法。
   • 附带材料：录音、讲义。

课程旨在通过实际项目和案例研究，帮助经济学研究者高效利用 Julia 进行数据分析和计算任务。

Tiny Moon Swift 库摘要

项目简介

Tiny Moon 是一个轻量级的 Swift 库，用于计算任意指定日期的月相。该库计算速度极快，支持完全离线运行，并兼容 iOS 和 macOS 平台。

安装与基本使用

通过 Xcode 的 Swift Package Manager (SPM) 引入 GitHub 仓库地址即可完成安装。使用时导入 TinyMoon，调用核心方法并传入目标 Date 和 TimeZone（默认使用系统当前时间）即可获取月相数据。

核心 API 设计

库的主入口为 TinyMoon 命名空间，提供两种计算模式：

• calculateMoonPhase (返回 Moon 对象)：以“天”为单位，优先返回当天发生的主要月相（如新月、上弦月、满月、下弦月）。若满月发生在当天任意时刻，查询该天任意时间均会返回“满月”。
• calculateExactMoonPhase (返回 ExactMoon 对象)：以“精确时间”为单位，始终返回传入具体时间点的精确月相状态（例如满月当天的凌晨会准确返回“盈凸月”）。

数据属性 (Moon Properties)

返回的 Moon 对象包含丰富的天文与月相属性：

• 基础展示：月相枚举 (moonPhase)、名称 (name)、表情符号 (emoji)、查询日期 (date)、满月俗称 (fullMoonName)。
• 时间与周期：儒略日 (julianDay)、月龄 (ageOfMoon)、朔望月周期已过天数 (daysElapsedInCycle)、距离下次满月/新月的天数。
• 物理与天文：照亮比例 (illuminatedFraction)、月相比例 (phaseFraction)、地月中心距离（公里）。

示例项目

作者提供了两个开源 Demo 以展示实际应用：

• macOS 端：在系统菜单栏以 Emoji 形式显示当前月相的工具栏应用。
• iOS 端：展示 Tiny Moon 基础 UI 绑定的简单移动应用。

算法与参考来源

库的核心月相计算公式提取自 John Walker 开源的 Moontool for Windows C 源码，具备极高的准确度。开发过程中还参考了 JavaScript 库 suncalc 以及 NASA 天文用户库等专业资源，以理解和验证底层的天文计算逻辑。