2026-02-22

摘要：关于安全许可申请表上不应填写的内容

背景： 这篇文章讲述了作者莱斯·厄内斯特（Les Earnest）童年时期因编写密码本而被联邦调查局（FBI）调查的经历，以及这如何影响了他日后获得安全许可的过程。

事件经过：

• 童年密码本： 1943年，莱斯·厄内斯特和朋友鲍勃（Bob）在阅读了关于密码学的书籍后，根据书中的频率分析方法（e-t-a-o-n-r-i），编写了一套简单的密码本。
• 丢失的眼镜盒： 莱斯在乘坐电车时，眼镜盒（内藏密码本）不慎遗失。一位爱国公民捡到眼镜盒，误以为密码本属于一名日本间谍，并将其交给了FBI。
• FBI调查： FBI 调查人员随后拜访了莱斯的母亲，询问其有关莱斯的各种信息。FBI 认为莱斯可能是一名间谍，并花费了大量资源调查此事。最终，FBI 将眼镜还给莱斯的母亲，但保留了密码本。
• 安全许可申请： 多年后，莱斯在大学期间申请海军电子实验室的暑期工作，需要进行安全许可审查。他如实填写了申请表，承认曾被FBI调查过，并说明了原因。
• 隐瞒过去： 安全审查官对莱斯的回答非常不满，撕毁了申请表，并要求莱斯重新填写，但必须隐瞒之前被FBI调查的经历。莱斯听从建议，最终获得了安全许可。

主要教训：

• 文章强调了在安全许可申请表上诚实填写的重要性，但同时也暗示了在某些情况下，隐瞒某些信息反而可能加快审查流程。
• 作者的经历也反映了二战期间美国社会对日本裔美国人的偏见和恐慌。

总而言之， 这篇文章讲述了一个因童年时期编写密码本而被FBI调查的个人经历，以及他为了获得安全许可而不得不隐瞒过去的故事，并揭示了当时社会背景对事件的影响。

中文翻译：关于安全许可申请表上不应填写的内容

背景: 这篇文章讲述了作者莱斯·厄内斯特（Les Earnest）小时候因编写密码本而被联邦调查局（FBI）调查的经历，以及这如何影响了他日后获得安全许可的过程。

事件经过:

• 童年密码本: 1943年，莱斯·厄内斯特和他的朋友鲍勃（Bob）在阅读了关于密码学的书籍后，根据书中的频率分析方法（e-t-a-o-n-r-i），编写了一套简单的密码本。
• 丢失的眼镜盒: 莱斯在乘坐电车时，装有眼镜和密码本的盒子意外遗失。一位爱国者捡到盒子，误以为密码本属于一名日本间谍，并将其交给FBI。
• FBI调查: FBI 调查人员随后拜访了莱斯的母亲，询问有关莱斯的信息。FBI 认为莱斯可能是一名间谍，并投入了大量资源进行调查。最终，FBI 将眼镜归还给莱斯的母亲，但保留了密码本。
• 安全许可申请: 多年后，莱斯在大学期间申请海军电子实验室的暑期工作，需要进行安全许可审查。他如实填写了申请表，承认曾被FBI调查过，并说明了原因。
• 隐瞒过去: 安全审查官对莱斯如实的回答非常不满，撕毁了申请表，并要求莱斯重新填写，但必须隐瞒之前被FBI调查的经历。莱斯听从建议，最终获得了安全许可。

主要教训:

• 文章强调了在安全许可申请表上诚实填写的重要性，但也暗示在某些情况下，隐瞒某些信息反而可能加快审查流程。
• 作者的经历也反映了二战期间美国社会对日本裔美国人的偏见和恐慌。

总结: 这篇文章讲述了一个因小时候编写密码本而被FBI调查的个人经历，以及他为了获得安全许可而不得不隐瞒过去的故事，并揭示了当时社会背景对事件的影响。

为什么编码代理无法取代原生应用？

本文探讨了在编码代理技术日益成熟的背景下，为什么原生应用仍然存在，以及为什么像Anthropic的Claude这样的AI领导者仍然选择使用Electron框架构建桌面应用。

核心观点：

• Electron框架的优势与劣势： Electron允许开发者使用HTML、CSS和JavaScript构建跨平台的桌面应用，简化了开发流程，方便代码共享，并且可以快速部署到Windows、Mac和Linux等多个平台。然而，Electron应用通常体积庞大、性能较差，且与操作系统集成度不高。
• 编码代理的潜力： 编码代理在实现跨平台、跨语言应用方面表现出色，能够根据规范和测试套件生成原生代码。理论上，这应该取代Electron的优势，为用户提供更流畅、更高效的原生应用体验。
• “最后一公里”的挑战： 尽管编码代理在开发过程的80%表现良好，但处理边缘情况、代码维护和持续支持仍然是困难的瓶颈。Anthropic的Rust-based C编译器项目就遭遇了这一点，在接近完成时，新增功能和修复bug频繁导致现有功能失效。
• 维护成本的增加： 使用原生应用意味着需要为每个平台（Mac、Windows、Linux）分别维护一个应用，这将显著增加bug修复和技术支持的难度，并且增加了维护成本。
• 开发团队的实际考量： Claude Code团队的工程师曾有Electron开发经验，习惯使用Electron，并且Electron可以保证Web和桌面应用在功能和外观上的统一性。最终，团队权衡了各种因素，认为Electron带来的便利性大于原生应用的潜在优势。

总结：

虽然编码代理技术的发展为构建原生应用提供了新的可能性，但开发过程中“最后一公里”的挑战、维护成本的增加以及开发团队的实际考量使得Electron等框架在短期内仍具有竞争力。 编码代理技术非常出色，但目前仍然无法完全取代原生应用，因为在实际开发和维护过程中，仍然需要大量的人工干预和决策。

Taalas 公司发布 ASIC 芯片实现极速 LLM 推理：总结

Taalas 公司最近发布了一种基于 ASIC (专用集成电路) 的芯片，该芯片运行 Llama 3.1 8B 模型（采用 3/6 位量化），推理速度高达每秒 17,000 个 token。 据称，这种芯片的拥有成本和能耗分别比基于 GPU 的推理系统低 10 倍，速度也比现有技术快 10 倍。

核心技术与优势：

• 硬布线模型权重: Taalas 的芯片将 Llama 3.1 8B 模型的 32 层权重直接“硬布线”到芯片上，即模型权重以物理晶体管的形式蚀刻在硅片上。
• 打破冯·诺依曼瓶颈: 传统的 GPU 在推理过程中，需要不断地从 VRAM (显存) 中读取权重，并将中间结果写回 VRAM，导致内存带宽瓶颈（冯·诺依曼瓶颈）。 Taalas 的芯片通过将权重直接集成到芯片上，避免了这种反复读取，实现了数据在芯片内部的连续流动。
• “魔法乘法器”: Taalas 声称发明了一种硬件方案，可以使用单个晶体管存储 4 位数据并执行相关的乘法运算，被称为“魔法乘法器”。
• 少量 SRAM: 虽然芯片没有外部 DRAM/HBM，但使用了少量片上 SRAM 来存储 KV 缓存（对话的临时内存/上下文窗口）和 LoRA 适配器（用于微调）。

芯片设计与制造：

• 通用逻辑门基础: Taalas 设计了一种具有巨大、通用的逻辑门和晶体管网格的基础芯片。
• 定制化顶层: 为了适配特定模型，Taalas 只需要定制芯片顶部的两层/掩码，这比从头开始构建芯片快得多。 针对 Llama 3.1 8B 模型，定制芯片仅用了两个月的时间。

总结:

Taalas 公司通过 ASIC 芯片的定制化设计，成功地将 LLM 推理速度提升到一个新的水平，并显著降低了能耗和成本。 该技术的核心在于将模型权重硬布线到芯片上，从而避免了传统 GPU 推理中的内存带宽瓶颈。 虽然定制芯片的成本仍然较高，但 Taalas 通过通用基础芯片和快速定制化流程，降低了整体成本。

CIA 多重测谎经历总结 (Chinese Summary)

本文记录了一位 CIA 分析师的个人经历，讲述了他申请 CIA 工作并经历多次测谎测试的整个过程。

申请与准备：

• 申请者在申请 CIA 工作时经历了测谎测试。
• 为了了解测谎测试的原理，他阅读了 David T. Lykken 的《血液中的震颤》(A Tremor in the Blood)，并学习了一些应对策略，但表示不打算使用。
• 他已经持有 CIA TS/SCI 安全等级，但测谎失败可能会导致失去这些等级和工作。

第一次测谎：

• 第一次测试中，他诚实回答问题，但由于身高体重信息上的小差异而被质疑，并被追问到个人生活中的敏感话题（癌症的担忧）。
• 测试结果为失败，但他坚持认为自己诚实回答了所有问题。

五和十年后的再测谎：

• 之后的五和十年后的再测验中，他发现测谎员的经验水平和测试方式不同。
• 他观察到，即使在通过测试的人群中，也经常出现测谎员对被测者进行不切实际的指控，例如指控从未接触过毒品的人是毒贩，指控不擅长电脑的人是黑客。
• 他认为这些指控往往与被测者的真实情况相差甚远，这反映了测谎测试的不可靠性。

对测谎的质疑与反抗：

• 他逐渐对测谎的有效性产生质疑，并阅读了美国国家科学院（NAS）2002 年的报告，进一步证实了测谎测试的无效性。
• 他开始注意到测谎员使用的套路，例如先表示同情，然后突然变换策略进行质询。
• 他通过阅读相关资料，认识到自己在测谎测试中被施加心理压力。
• 他最终拒绝接受 DIA (国防情报局) 的测谎测试，并因此面临被解雇的风险。

后续经历：

• 尽管拒绝了测谎，他仍然被允许继续在 FBI 项目中工作。
• 他向国会议员写信，呼吁禁止使用测谎测试。
• 他最终选择辞职，避免与公司就测谎问题发生进一步冲突。

总结：

本文揭示了 CIA 和其他政府机构中测谎测试的普遍存在和潜在问题。作者认为测谎测试缺乏科学依据，且容易受到测谎员主观判断的影响，对被测者造成心理伤害。他强烈建议避免从事需要接受测谎测试的职业。

Claude 代码开发工作流总结

本文详细描述了作者使用 Claude Code 进行开发时，与大众不同的工作流。作者认为，大多数开发者直接通过提示词和计划模式进行代码编写，结果往往一团糟。作者的工作流核心在于：在让 Claude 编写代码之前，先审查并批准一份书面计划。

核心理念： 计划与执行分离，强调规划的重要性。

工作流流程：

1. 研究 (Research):

   • 让 Claude 深入阅读相关代码库，理解其运作方式。
   • 将研究结果以 Markdown 文件 (research.md) 形式记录，便于作者审查和修正。
   • 使用明确的指令（如“deeply”、“in great details”）确保 Claude 进行深度阅读，而非表面扫描。
   • 这一阶段的目标是确保 Claude 真正理解了系统，避免后续出现“在隔离环境中工作但破坏了整个系统”的问题。

2. 计划 (Plan):

   • 基于研究结果，让 Claude 编写详细的实现计划，并保存在 Markdown 文件 (plan.md) 中。
   • 计划应包含方法说明、代码片段、修改的文件路径以及考量和权衡。
   • 作者使用自定义的 Markdown 文件，而非 Claude Code 内置的计划模式，以获得更大的控制权。
   • 可以提供开源代码作为参考，帮助 Claude 更好地理解和设计。

3. 标注循环 (Annotation Cycle):

   • 作者在 plan.md 文件中添加内联注释，修正 Claude 的假设、拒绝不合适的方案、添加约束条件或提供领域知识。
   • 注释的长度不一，可以是从两字到包含代码片段的长篇解释。
   • 作者会重复标注循环 1-6 次，确保计划的准确性。
   • 关键在于使用 “don’t implement yet” 明确指示 Claude 不要过早开始代码编写。

4. 待办事项列表 (Todo List):

   • 在计划最终确定后，让 Claude 生成详细的任务分解清单，作为进度追踪器。

5. 实现 (Implementation):

   • 当计划准备好后，发出实现指令，使用标准的提示词，确保 Claude 执行计划中的所有任务，并持续运行类型检查。

6. 反馈与迭代 (Feedback & Iterate):

   • 在实现过程中，作者扮演监督者的角色，提供简洁的反馈和修正。
   • 对于视觉问题，可以使用截图进行更精准的沟通。

关键要点：

• Markdown 文件作为共享的可变状态： 方便作者思考、标注和重新参与。
• “不要实现” 的保护机制： 防止 Claude 在计划不完善时就开始编写代码。
• 选择性地采纳 Claude 的建议： 作者根据自己的判断，决定是否接受、修改或忽略 Claude 的建议。
• 单次长会话： 将研究、计划和实现放在一个会话中进行，保持上下文连贯。

总结：

作者的工作流强调了规划的重要性，通过深入研究、详细计划、反复标注和严格的执行，最终实现了高效且高质量的代码开发。核心在于将思考与编写分离，确保代码符合项目需求和工程规范。

Cloudflare BYOIP 服务中断事件回顾 (Cloudflare BYOIP Service Outage Post-Mortem)

2026年2月20日 17:48 UTC，Cloudflare 出现服务中断，受影响的客户在使用 Cloudflare 的“自带 IP (BYOIP)” 服务时，其互联网路由被通过边界网关协议 (BGP) 撤回。

事件起因：

本次中断并非由网络攻击或恶意活动直接或间接引起。 而是由于 Cloudflare 在网络管理通过 BYOIP 管道接入的 IP 地址方式上进行的一次更改所导致，该更改导致 Cloudflare 意外地撤回了客户前缀。

事件影响：

• 受影响的 BYOIP 客户的服务和应用程序从互联网上无法访问，导致超时和连接失败。
• Cloudflare 递归 DNS 解析器 (1.1.1.1) 的网站显示 403 错误。
• 总中断时间为 6 小时 7 分钟，大部分时间用于将前缀配置恢复到更改前的状态。
• 约 1100 个 BYOIP 前缀被撤回。
• 受影响的服务包括：
  • 核心 CDN 和安全服务：流量无法被吸引到 Cloudflare。
  • Spectrum：BYOIP 上的 Spectrum 应用无法代理流量。
  • 专用出口：无法将流量发送到目的地。
  • 魔术传输：应用程序无法在互联网上被宣传。
  • Cloudflare DNS 解析器 (1.1.1.1) 网站显示 "Edge IP Restricted" 错误。 DNS 解析服务本身未受影响。

事件恢复：

• Cloudflare 工程师回滚了更改，停止了前缀撤回。
• 部分客户通过 Cloudflare 控制台重新广播其 IP 地址恢复了服务。
• Cloudflare 通过恢复所有前缀配置完成了事件的解决。
• 大约 800 个前缀通过控制台恢复，剩余约 300 个前缀由于软件错误导致服务配置从边缘服务器移除，需要工程师手动恢复。

事件根本原因：

• Cloudflare 的 Addressing API 是客户 IP 地址的权威数据集。
• 事件的根本原因是 Cloudflare 尝试自动化移除 BYOIP 服务前缀的流程时，一个子任务查询 API 时出现错误。
• 该子任务错误地将所有 BYOIP 前缀标记为需要删除，导致大量前缀和相关配置被意外删除。
• 测试环境和测试覆盖范围不足，未能发现该问题。

后续改进措施 (Code Orange: Fail Small):

为了防止类似事件再次发生，Cloudflare 将采取以下措施：

• API 模式标准化： 改进 API 模式，确保 API 调用能够正确解析。
• 配置与操作状态分离： 重新设计数据库配置，引入配置快照，以便快速回滚更改。
• 大范围撤销操作的仲裁： 改进监控，检测并阻止快速、大范围的前缀撤销操作。
• 实施逐步部署与健康监测： 遵循 "Code Orange: Fail Small" 计划，实施健康监测机制，确保配置更改的安全性。

Cloudflare 承认此次事件对客户造成的影响，并承诺通过改进网络稳定性和安全性来重建信任。

EDuke32 总结

EDuke32 是一个开源的、免费的 Duke Nukem 3D (Duke3D) 游戏引擎和源端口，旨在为 Windows、Linux、macOS、FreeBSD 以及其他平台提供增强的游戏体验。它由 Richard "TerminX" Gobeille 和 Evan "Hendricks266" Ramos、Pierre-Loup "Plagman" Griffais、Philipp "Helixhorned" Kutin 等人领导的 Duke4.net 社区开发，并借鉴了 Todd Replogle、Ken Silverman、Jonathon Fowler 和 Matt Saettler 的工作。

主要特点和功能：

• 兼容性: EDuke32 可以在各种操作系统上原生运行，包括 Windows、Linux 和 macOS。
• 图形渲染: 提供多种渲染选项，包括 Polymer 硬件加速渲染器（需要高性能显卡）和经典软件模式，支持高达 10240x4320 的分辨率。
• 错误修复和稳定性: 修复了 Duke3D 原版代码中的大量编程错误，显著提高了游戏稳定性。
• Shadow Warrior 支持: 内置 VoidSW，一个完整的 Shadow Warrior 移植版本，具有与 Duke3D 相同的优势。
• 长期维护: EDuke32 是 Duke3D 端口中唯一持续开发和维护超过二十年的项目。
• 脚本扩展: 提供了丰富的游戏脚本扩展，允许创建与现代游戏相媲美的模组。
• HRP 支持: 完整支持 HRP (High Resolution Pack)，这是 Duke3D 的高分辨率资源包，其他端口无法完全支持。
• 增强型控制台: 拥有功能强大的控制台，支持 Quake 风格的快捷键绑定、命令别名、高级自动补全、命令历史记录和彩色文本。
• 现代功能: 添加了现代化的状态显示/HUD、从启动窗口加载模组的支持、WSAD 键控制和改进的鼠标瞄准。
• 音频支持: 支持 Ogg Vorbis 和 FLAC 音频格式。
• 游戏支持: 允许玩家体验名为 "NAM" 的游戏，该游戏在 90 年代曾在廉价店面销售。
• 开源许可: EDuke32 采用 GNU GPL 许可，允许非商业用途的免费使用。BUILD 引擎技术由 Ken Silverman 创建，非 GPL 渲染和引擎技术使用 BUILDLIC 许可。

社区和资源:

• Discord: https://discord.gg/ks5bHrH
• 论坛: https://forums.duke4.net/index.php?showforum=26
• Wiki (安装和配置): https://wiki.eduke32.com/wiki/Installation%5Fand%5Fconfiguration
• Wiki (常见问题解答): https://wiki.eduke32.com/wiki/Frequently%5FAsked%5FQuestions

相关项目:

• Ion Fury: EDuke32 技术支持的 Voidpoint 游戏。

https://www.science.org/doi/10.1126/science.adq7188

将验证推至编译时：Rust 中的类型驱动设计

本文探讨了在 Rust 编程中避免显式验证函数，并将不变式编码在类型级别的方法。作者以 Rust 为中心的方式解释了该概念，并与 Haskell 原文进行了对比，使其更易于 Rust 初学者理解。

核心问题：运行时错误与类型安全

文章以一个简单的除法函数为例，展示了在运行时可能发生的除零错误。虽然 assert! 可以缓解问题，但它仍然是在运行时触发，无法在编译时发现。作者指出，动态语言（如 Python）的常见问题是许多错误只能在运行时暴露。Rust 的强类型系统提供了一种将错误推迟到编译时的机会。

解决方案：新类型模式

作者介绍了新类型模式，通过创建新的类型来解决这个问题。例如，定义了一个 NonZeroF32 结构体，该结构体仅包含一个 f32 字段，但保证其值永远不为零。这种类型通过私有字段和公共构造函数来实现，构造函数会验证输入是否为零，如果为零则返回 None。

类型转变 vs. 验证

文章区分了“类型转变”和“验证”两种方法。将值转换为更具语义意义的新类型（如 NonZeroF32 或 NonEmptyVec）是一种类型转变，它将不变式编码到类型本身。而验证仅仅是在函数中检查值是否满足特定条件。类型转变将验证责任推给了调用者，并在编译时保证了不变性，而验证则将责任留在函数内部，可能导致运行时错误或冗余的检查。

实际案例：String 和 serde_json

作者引用了 String 类型，它本质上是一个 Vec<u8> 的新类型，通过 from_utf8 函数进行验证。此外，还讨论了 serde_json 的使用，指出通过类型转换（使用 serde derive）可以避免在多个地方进行冗余的验证。

类型驱动设计原则

文章总结了两种类型驱动设计的原则：

1. 使非法状态不可表示： 通过创建新类型来禁止非法状态的出现。
2. 尽早证明不变式： 将验证代码推迟到类型级别，而不是在函数内部进行。

结论

作者鼓励开发者充分利用 Rust 的类型系统，将验证编码到类型中，从而提高代码的清晰度和健壮性。虽然新类型模式并非万能，但它可以有效地提高代码质量，并使编译器帮助开发者编写更可靠的程序。作者还表达了对 Rust 类型系统进一步发展的期望。

总而言之，本文倡导一种“解析而非验证”的设计理念，通过类型系统将不变式编码到程序中，从而提高代码的可靠性和可维护性。

日本版画検索 (Ukiyo-e Search) 概要

Ukiyo-e Search 是一个强大的资源，允许用户通过拍摄现有版画的照片来搜索日本版画，并可以在多个收藏中查看相似的版画。

主要功能:

• 按图像搜索: 用户可以上传版画照片或粘贴图像 URL，以在多个收藏中查找相似的版画。
• 庞大的图像数据库: 该平台收录了 223,891 幅版画。
• 未来更新: 计划增加更好的数据、更多的图像和更强大的搜索功能。

按时间段划分的艺术家列表:

该网站按照版画发展的不同时期，列出了相关的艺术家，并附有他们的作品示例链接：

• 早期 Ukiyo-e (1700 年代初期至中期): Okumura Masanobu, Hishikawa Moronobu, Torii Kiyomasu II, Nishikawa Sukenobu, Torii Kiyonobu II, Torii Kiyomasu I, Nishimura Shigenaga, Torii Kiyotada I, Torii Kiyonobu I, Okumura Toshinobu 等。
• 全彩色印刷的诞生 (1740 年代至 1780 年代): Katsukawa Shunsho, Suzuki Harunobu, Isoda Koryusai, Katsukawa Shunko, Katsukawa Shun'ei, Ippitsusai Buncho, Torii Kiyomitsu, Kitao Shigemasa, Utagawa Toyoharu, Ishikawa Toyonobu, Torii Kiyotsune, Torii Kiyohiro, Katsukawa Shunsen 等。
• Ukiyo-e 的黄金时代 (1780 年至 1804 年): Kitagawa Utamaro, Torii Kiyonaga, Toshusai Sharaku, Hosoda Eishi, Katsukawa Shuncho, Kubo Shunman, Eishosai Choki, Kitao Masayoshi, Katsukawa Shunzan, Chokosai Eisho, Utagawa Kunimasa, Ichirakutei Eisui 等。
• 版画普及化 (1804 年至 1868 年): Utagawa Kunisada, Utagawa Hiroshige, Utagawa Kuniyoshi, Utagawa Toyokuni I, Katsushika Hokusai, Utagawa Hiroshige II, Utagawa Kunisada II, Keisai Eisen, Utagawa Hirosada, Kikugawa Eizan, Totoya Hokkei, Utagawa Kuniyasu, Utagawa Kuniteru, Utagawa Kunikazu, Utagawa Yoshitsuya, Yashima Gakutei, Utagawa Yoshikazu, Utagawa Toyoshige, Utagawa Toyohiro, Utagawa Hirokage, Kano Shugen Sadanobu, Shunkosai Hokushu, Yoshifuji, Katsukawa Shuntei, Yanagawa Shigenobu, Gigado Ashiyuki, Hasegawa Sadanobu I, Toyokawa Yoshikuni, Teisai Hokuba, Shotei Hokuju, Torii Kiyomine 等。
• 明治时代 (1868 年至 1912 年): Toyohara Kunichika, Tsukioka Yoshitoshi, Toyohara Chikanobu, Ochiai Yoshiiku, Tsukioka Kogyo, Kobayashi Kiyochika, Utagawa Yoshitora, Mizuno Toshikata, Utagawa Yoshitaki, Ogata Gekko, Utagawa Kunisada III, Morikawa Chikashige, Utagawa Sadahide, Kawanabe Kyosai, Utagawa Hiroshige III, Utagawa Toyosai, Inoue Yasuji, Takeuchi Keishu, Adachi Ginko, Tomioka Eisen, Watanabe Nobukazu, Ikkei, Migita Toshihide, Shibata Zeshin, Utagawa Kuniaki, Miyagawa Shuntei, Imao Keinen, Kono Bairei, Kajita Hanko, Utagawa Kunimasa III, Torii Kiyosada, Utagawa Fusatane, Watanabe Shotei, Utagawa Kunitoshi, Seiko, Utagawa Yoshitoyo, Shibata Shinsai 等。
• 新版画 (Shin Hanga) 和创作版画 (Sosaku Hanga) 运动 (1915 年至 1940 年代): Kawase Hasui, Tsuchiya Koitsu, Kasamatsu Shiro, Yoshida Hiroshi, Ito Shinsui,

I2P匿名网络遭遇大规模水军攻击事件总结

2026年2月3日，I2P匿名网络遭受了前所未有的水军攻击，网络中涌入了70万个恶意节点。 正常情况下，I2P网络拥有15,000到20,000个活跃设备，此次攻击使恶意节点数量超过了正常节点数量39倍。

过去三年（2023年、2024年），I2P网络每年2月都会遭受水军攻击，攻击者使用恶意Floodfill路由器，但攻击者身份始终不明。 2026年的攻击开始时，普遍认为这是同一家国家支持的组织持续进行的年度破坏活动。

然而，经过调查，此次攻击的幕后黑手是Kimwolf僵尸网络，该网络在2025年底感染了数百万设备，包括流媒体盒子和消费级路由器。 Kimwolf僵尸网络正是2025年12月制造了创纪录的31.4太比特/秒DDoS攻击的组织。 攻击者在Discord上承认，他们试图将I2P网络用作备用命令与控制（C2）基础设施，但在安全研究人员摧毁了550多个其主要C2服务器后，意外地扰乱了I2P网络。

I2P开发团队在攻击开始后仅六天内发布了版本2.11.0。 该版本默认启用了混合ML-KEM加X25519后量子加密，使I2P成为首个向所有用户提供后量子密码学的生产级匿名网络之一。 此外，该版本还包含额外的水军缓解措施、SAMv3 API升级以及基础设施改进。

NTransformer 总结 (Summary of NTransformer)

NTransformer 是一个高性能的 C++/CUDA 大语言模型 (LLM) 推理引擎，旨在在消费级硬件上实现高效的 LLM 推理。它专注于 Llama 模型的优化，目标是在单个 RTX 3090 (24GB VRAM) 上运行 Llama 70B 模型。

核心特点：

• 高效率: 通过在 GPU 内存中流式传输模型层，并采用 PCIe 以及可选的 NVMe 直接 I/O，实现了显著的性能提升。
• 3-Tier 自适应缓存: 自动调整 VRAM 驻留层、pinned RAM 和 NVMe/mmap 缓存三层结构，以优化性能和内存使用。
• SLEP 流式传输: 双缓冲层管道，重叠 NVMe 读取、PCIe DMA 和 GPU 计算。
• gpu-nvme-direct 后端: 用户空间 NVMe 驱动程序将模型权重直接读取到 GPU 可访问的内存中。
• 层跳过 (Layer Skip): 通过余弦相似度校准，跳过冗余层，减少计算量，同时保持模型质量。
• 自推测解码 (Self-Speculative Decoding): 使用 VRAM 驻留层作为草稿模型，无需额外的模型。
• 零外部依赖: 除了 CUDA Toolkit 之外，没有其他依赖项 (如 PyTorch, cuBLAS)。

关键结果：

技术细节：

• 支持的模型格式: GGUF (Q4_0, Q8_0, Q4_K_M, Q5_K, Q6_K, F16, F32 量化)
• 架构: 包含 RoPE, GQA, SwiGLU, RMSNorm, KV 缓存等 Llama 架构组件。
• 数据路径: VRAM 驻留 > pinned RAM H2D > mmap pinned > CPU worker memcpy (自动选择)。
• 代码结构: 核心计算 (tensor, allocator, GPU 管理)、CUDA 内核、SLEP 流式引擎、模型加载、推理引擎、工具函数等。

系统要求：

• Linux (Ubuntu, kernel 6.17+)
• CUDA Toolkit 13.1
• gcc-14 / g++-14
• NVIDIA GPU (RTX 3090 经过测试)
• CMake 3.24+
• (可选) 独立的 PCIe 插槽上的 NVMe SSD + gpu-nvme-direct

代码和 HTML 示例摘要 (Summary of Code and HTML Example)

以下是对提供的 C++ 代码和 HTML 示例的摘要：

C++ 代码 (C++ Code):

该 C++ 代码使用 canvas_ity 库在 256x256 像素的画布上绘制一个星形图案，并将其保存为 TGA 图像文件 "example.tga"。

主要步骤 (Main Steps):

1. 画布初始化 (Canvas Initialization): 创建一个 256x256 像素的画布对象 context。
2. 星形路径构建 (Star Path Construction): 使用 move_to 和 line_to 函数定义一个星形的路径。close_path() 方法闭合路径。
3. 阴影效果 (Shadow Effect): 设置一个半透明的黑色阴影，set_shadow_blur, shadow_offset_y 和 set_shadow_color 函数用于设置阴影的模糊程度、偏移量和颜色。
4. 填充 (Filling): 使用浅黄色 (1.0f, 0.9f, 0.2f, 1.0f) 填充星形。
5. 描边 (Stroke): 使用粗红线 (0.9f, 0.0f, 0.5f, 1.0f) 描边星形，并设置 line_join 为 rounded 以获得圆角连接。
6. 虚线描边 (Dashed Stroke): 使用橙色虚线 (0.95f, 0.65f, 0.15f, 1.0f) 描边星形，设置虚线段长度 (segments)、偏移量 (line_dash_offset) 和线帽样式 (line_cap) 为 circle。
7. 移除阴影 (Remove Shadow): 将阴影颜色设置为透明 (0.0f, 0.0f, 0.0f, 0.0f)。
8. 光泽层 (Shine Layer): 创建一个从 (64, 0) 到 (192, 256) 的线性渐变，并添加颜色停止点，以创建一个光泽效果。 使用 global_composite_operation = canvas_ity::source_atop 将其叠加到画布上。
9. 图像数据获取 (Image Data Retrieval): 使用 get_image_data 函数从画布获取渲染后的 RGBA 像素数据。
10. TGA 图像写入 (TGA Image Writing): 将像素数据写入 TGA 图像文件 "example.tga"。 需要注意的是，在写入前，将红绿通道进行交换，因为 TGA 格式使用 BGRA 顺序。

HTML 示例 (HTML Example):

该 HTML 示例使用 JavaScript 在一个 <canvas> 元素中绘制与 C++ 代码类似的星形图案。

主要步骤 (Main Steps):

1. 获取 Canvas 上下文 (Get Canvas Context): 获取 <canvas> 元素的 2D 渲染上下文。
2. 星形路径构建 (Star Path Construction): 使用 moveTo 和 lineTo 函数定义一个星形的路径，closePath() 方法闭合路径。
3. 阴影效果 (Shadow Effect): 设置阴影模糊程度、偏移量和颜色。
4. 填充 (Filling): 使用浅黄色填充星形。
5. 描边 (Stroke): 使用粗红线描边星形，并设置 lineJoin 为 "round" 以获得圆角连接。
6. 虚线描边 (Dashed Stroke): 使用橙色虚线描边星形，设置虚线段长度、偏移量和线帽样式为 "round"。
7. 移除阴影 (Remove Shadow): 将阴影颜色设置为透明。
8. 光泽层 (Shine Layer): 创建一个线性渐变，并添加颜色停止点，以创建一个光泽效果。 使用 globalCompositeOperation = "source-atop" 将其叠加到画布上。

总而言之，C++ 代码和 HTML 示例都演示了如何使用不同的绘图技术（例如阴影、填充、描边、虚线、渐变和混合模式）来绘制一个星形图案。 C++ 代码将结果保存为图像文件，而 HTML 示例则在网页上显示该图案

丰田Mirai：氢动力汽车的兴衰

本文讲述了汽车领域氢动力汽车的曲折发展历程，指出基础设施不足以及电池电动汽车等竞争对手的崛起，使得氢动力汽车难以普及。文章以丰田Mirai为例，详细分析了这款氢动力汽车的现状、定价走势以及面临的挑战。

丰田Mirai概述

丰田Mirai是第一款量产的氢燃料电池汽车，于2014年底首次亮相，2015年开始销售。第一代Mirai配备一台电动机，由丰田自主研发的“丰田燃料电池系统”（TFCS）提供动力，包括燃料电池和氢气罐等关键部件。2020年，第二代Mirai推出，增加了氢气容量，续航里程提升30%，并升级了驾驶辅助和安全功能，以及信息娱乐系统。

主要参数对比：

Mirai的二手车价格暴跌

尽管丰田仍在生产Mirai，但二手车市场的价格却令人震惊地暴跌。2021款车型起售价为49,500美元，后续车型略高于50,000美元，而现在，即使是较新的二手Mirai也能低至1万美元左右成交。一些去年款的车辆，原起售价为50,190美元，如今仅售15,000至18,000美元。这种大幅贬值反映了氢动力汽车在美国和全球汽车市场中的衰退趋势。

价格暴跌的原因

Mirai价格下跌的主要原因是：

• 地理限制： 氢燃料基础设施主要集中在加利福尼亚州，Mirai只能在该州销售。
• 电池电动汽车的崛起： 电池电动汽车成为绿色交通的主要选择，挤压了氢动力汽车的发展空间。
• 潜在买家担忧： 由于氢动力汽车的特殊性，潜在买家对二手车可能存在的可靠性问题更加担忧。
• 基础设施缺乏： 美国仅有54座氢气加氢站，且主要集中在加利福尼亚州。政府对氢基础设施的投资远低于对电动汽车充电基础设施的投资。部分加氢站甚至已经关闭。
• 合成燃料的出现： 作为氢燃料的替代方案，合成燃料正在兴起，但目前生产成本高昂，供给不足。

未来展望

尽管氢动力汽车的前景不容乐观，丰田仍在积极研发氢动力技术，并设立了“北美氢能源总部”（H2HQ）进行相关研究。宝马也在测试氢燃料电池SUV iX5，并计划在2025年推出量产车型，丰田也参与了该项目的合作。氢动力汽车虽然面临诸多挑战，但仍具有一定的潜力，未来或许能在特定领域发挥作用。

总结

氢动力汽车的发展面临诸多挑战，尤其是基础设施的缺乏。虽然丰田等公司仍在积极研发，但氢动力汽车的未来仍然充满不确定性，电池电动汽车似乎已成为绿色交通的主流趋势。