ImHex：面向逆向工程师的十六进制编辑器

ImHex 是一款专为逆向工程师、程序员以及需要在深夜工作时保护视力的用户设计的高级十六进制编辑器。它提供了一套强大且全面的工具集，用于分析、编辑和理解二进制文件。

核心功能特性

1. 功能丰富的十六进制视图

• 编辑与导航：支持字节修补、补丁管理、无限撤销/重做、多种格式复制（如C/Python数组）、字符串与十六进制搜索、以及从文件起始/结束/当前光标位置的跳转。
• 数据高亮与显示：提供可配置的前景与背景高亮规则，并能以多种数据类型（如各种位宽的整数、浮点数、RGBA颜色、HexII等）显示数据。支持自定义编码（如UTF-8、ShiftJIS）解码。

2. 自定义模式语言

• 使用类似C语言的语法，允许用户定义结构、联合、枚举等来解析文件内容。
• 支持自动根据文件类型加载模式，能够可视化图像、音频、3D模型等多种数据。

3. 主题与界面

• 提供深色模式（默认）和浅色模式，支持通过可分享的主题文件自定义所有UI元素的颜色和样式。
• 现代界面支持多工作区、自定义布局和窗口分离。

4. 数据导入/导出与处理

• 支持从多种数据源加载数据，包括：本地大文件、原始磁盘/分区、GDB服务器（访问进程或设备内存）、Intel Hex/Motorola SREC、Base64编码数据、UDP数据包、进程内存、通过SSH/SFTP的远程文件。
• 提供数据检查器，能将选定字节解释为多种类型（整数、浮点数、时间、GUID等）。
• 节点数据预处理器允许在显示前对数据进行修改、解密或解码，而不改变原始文件。
• 支持导入/导出Base64、IPS补丁、Markdown报告及多种编程语言的数组。

5. 高级搜索与分析

• 数据搜索：支持字符串提取、序列搜索（忽略大小写）、正则表达式、二进制模式（含通配符）以及按数值范围搜索。
• 数据哈希：集成大量哈希算法（CRC系列、MD5、SHA系列、XXHash、Blake2等），可对文件区域或任意字符串计算哈希。
• 数据差异比较：可比较不同数据源的数据，并高亮显示差异。
• 数据可视化分析：提供基于文件魔数的解析器、字节分布图、熵图，并能检测加密/压缩文件。
• YARA规则支持：可扫描文件漏洞，并高亮显示匹配项。

6. 集成工具

• 反汇编器：支持所有Capstone架构（如ARM、x86、MIPS、RISC-V、PowerPC等）。
• 书签：支持带名称、颜色的书签，可快速跳转、添加注释。
• 实用工具集：包含多种工具，如名称修饰解析器、ASCII表、正则替换器、计算器、图形计算器、颜色选择器、进制转换、文件拆分/合并/碎纸、IEEE754浮点数可视化、TCP客户端/服务器、HTTP请求等。

7. 扩展性与易用性

• 内置内容更新器：可直接下载数据库中的模式文件、库、魔数文件等资源。
• 易于上手：支持多语言、为新手提供简化模式、有详尽文档、示例文件和交互式教程。

技术细节

• 模式语言：拥有独立的语法和文档，其数据库（包含格式模式、库等）托管在GitHub仓库。
• 系统要求：
  • 操作系统：Windows 7+，macOS Sequoia+（官方二进制文件），现代Linux（提供多种发行版官方包），FreeBSD。
  • 硬件：需要支持OpenGL 3.0的GPU（有无GPU的软件渲染版本可选）。CPU支持x86、AMD64、ARM64等小端架构。内存建议50MB以上，存储空间约100MB。
• 编译与安装：需要支持C++23的GCC或Clang编译器，MSVC和AppleClang不受支持。提供了详细的安装和编译指南。
• 插件开发：提供了插件模板和SDK，允许开发者扩展ImHex功能。可通过构建ImHex或使用GitHub Actions获取SDK。

许可与支持

• 许可证：主体采用GPLv2，但libimhex和ui插件库采用LGPLv2.1，以允许开发专有插件。
• 代码签名：由SignPath基金会提供免费代码签名。
• 开发与贡献：项目欢迎社区贡献，核心代码推送权由WerWolv等贡献者掌握。项目使用了众多优秀的开源库（如Dear ImGui、Capstone、YARA等）作为依赖。

这篇文章详细分析了游戏《异星工厂》（Factorio）中一个已修补的Lua安全漏洞，该漏洞允许恶意服务器在客户端实现远程代码执行。主要内容总结如下：

漏洞背景与影响 《异星工厂》是一款销量超过350万的热门游戏。游戏大量使用Lua语言实现游戏逻辑、地图和模组（Mod）。由于游戏采用“确定性锁步”网络同步机制，任何一方执行的Lua代码都必须在所有客户端上同步执行，这使得Lua解释器暴露在网络攻击面下。

攻击路径 攻击者可创建包含恶意Lua代码的自定义地图，并架设服务器。当客户端连接并下载该地图时，会执行其中的Lua代码。攻击者还可通过游戏内服务器列表吸引受害者。

漏洞技术原理

1. 字节码执行与验证缺陷：Lua代码先编译为字节码再执行。游戏虽禁用了如os.execute等危险模块，但基础模块中的load等函数允许加载并执行字节码。开发者虽尝试实现字节码验证器，但存在“Off-by-One”错误，可绕过检查，跳转到代码块外执行。
2. 类型混淆泄露地址：通过精心构造的字节码，可利用FORLOOP操作码中缺失的类型检查（因开发断言lua_assert默认禁用），将字符串对象的指针误读为浮点数，从而泄露内存地址。
3. 浮点数与整数转换：由于Lua仅使用双精度浮点数，需要将泄露的“伪浮点数”准确转换回指针整数地址。文章详细解释了IEEE 754编码，并提供了转换方法。
4. 构造伪造对象（Fake Objects）：获得地址泄露能力后，可通过控制函数原型（Proto）、上值（UpVal）等数据结构，构造伪造对象，进而获得任意内存读取（通过伪造字符串）和写入（通过伪造上值指向任意地址）的原语。
5. 控制指令指针：通过伪造一个指向任意地址的“轻量级C函数”（Light C Function），可以控制程序执行流程。

实际利用（以Linux为例）

1. 适配游戏修改：游戏对Lua的GC对象结构做了修改（双链表），需要调整内存偏移量。此外，游戏使用的sprintf库对%a格式字符串处理不同，因此需改用纯算术方法进行浮点数/整数转换。
2. 寻找利用函数：找到可从Lua调用且首个参数由攻击者控制的C库函数（如math.ldexp）。
3. 劫持GOT表：通过写入原语，在全局偏移表（GOT）中可写入区域构造一个伪造的TString，利用其读取原语泄露memcpy在libc中的地址，从而绕过ASLR，计算出system函数地址。
4. 执行系统命令：将GOT中ldexp的条目覆写为system的地址。将要执行的命令字符串写入可写内存段，最后调用math.ldexp（此时实际调用system）即可执行任意系统命令，文中演示了获取反向Shell。

总结 该漏洞结合了网络同步机制、字节码加载执行、验证器缺陷、类型混淆和内存操作原语，形成了一个完整的远程代码执行链。文章强调了对动态语言解释器进行安全加固（如严格验证字节码、启用安全断言、小心处理类型转换）的重要性，并提供了一个实践挑战。

LosslessCut：无损音视频编辑的瑞士军刀

核心定位与特点 LosslessCut 是一款跨平台的 FFmpeg 图形用户界面工具，专注于对视频、音频、字幕等媒体文件进行极其快速且无损的操作。其核心优势在于避免重新编码，通过近乎直接的数据复制实现高效处理，从而完美保留原始文件质量，同时大幅节省时间。

主要功能

• 无损剪切与裁剪：快速剪切视频/音频文件，用于剔除广告、提取精彩片段，非常适合处理来自摄像机、无人机等设备的大文件。
• 智能剪切（实验性）：支持更精确的剪切。
• 无损合并/拼接：合并来自同一设备、编码参数相同的多个文件。
• 多轨道编辑：可提取、添加、移除或替换视频、音频、字幕等单个轨道。
• 元数据编辑：查看并修改文件及各轨道的元数据。
• 工作流优化：支持键盘快捷键、项目文件保存切割片段、时间轴缩放与关键帧跳转、音频波形与视频缩略图显示、撤销/重做。
• 格式转换：可无损地将文件重新封装为不同的容器格式。
• 图像导出：从视频中导出全分辨率快照或一系列帧图像。
• 高级功能：包含场景检测、静音检测、文件分割（按时长/大小/数量）、改变播放速度、无损裁剪画面、基本的命令行与 HTTP API、显示嵌入式 GPS 轨迹、无损下载网络视频（如 HLS）、快速移除非关键帧等。

典型应用场景

• 剪切录制节目中的广告。
• 从视频中提取或替换音乐音轨。
• 合并不同来源的音视频。
• 为视频嵌入外挂字幕。
• 快速更改容器格式以适应不同设备播放。
• 根据编辑决策列表（EDL）或章节标记进行批量剪切。
• 修正视频错误的旋转方向。
• 将视频循环播放指定次数而不重新编码。
• 将视频片段分割为独立文件。
• 剪切掉音频中的静音部分。

格式支持与下载

• 支持格式：基于 Chromium 的 HTML5 播放器，原生支持 MP4、MOV、WebM、MKV、OGG、WAV 等容器，以及 H.264、VP9、H.265（需硬件解码）等常见编解码器。对于不支持的格式，可转换为支持格式进行预览，但最终导出操作仍作用于原始文件，确保无损。
• 获取方式：软件免费且开源。用户可通过应用商店（如 Mac App Store）获取以支持自动更新，也可在 GitHub 上直接下载适用于 macOS（Intel/Apple Silicon）、Windows 和 Linux（包括 ARM 架构）的独立安装包。

ETH Zurich 研究人员开发出最快网络流算法

瑞士苏黎世联邦理工学院（ETH Zurich）的研究人员开发出了近乎完美的网络流算法，能够以数学上几乎不可能更快的速度，为任何类型的网络（如铁路、公路、电网或互联网）计算最大传输流量与最小成本。

核心突破与性能

• 解决关键问题：该算法解决了理论计算机科学中的一个核心问题——如何在网络中同时实现最大流量和最小传输成本。
• 计算速度：算法计算时间与网络规模的增长近乎同步，实现了“近乎线性时间”的计算。此前，计算时间随网络规模增大而增长得远快于数据读取时间，而新算法使得找到解所需的额外计算时间变得可忽略。
• 理论里程碑：这项研究为未来高效计算超大且动态变化的网络奠定了基础，并改变了计算机处理复杂任务的方式。

算法演进与应用

• 从静态到动态：早期算法主要针对固定、静态的有向网络。近年来的算法已扩展至能处理随时间增量变化的网络（连接不断添加），以及连接增减的网络（如隧道关闭或道路损坏）。
• 实际应用示例：算法可快速计算因实际交通网络变化（如瑞士圣哥达基线隧道的关闭与重开、A13高速公路因山体滑坡部分损毁）后的最优路线。

技术创新

• 策略结合：团队融合了两种传统策略的优势：
  1. 铁路网络策略：每次迭代计算网络一部分的修改流量。
  2. 电网策略：每次迭代计算整个网络，但使用修改流量的统计平均值。
• 核心方法：“我们的方法基于许多小型、高效且低成本的计算步骤，它们组合起来远比少数大型步骤快得多。”
• 数据结构创新：开发了新的数据结构来组织网络数据，能极快地识别网络连接的任何变化，进一步加速了计算。

历史背景与影响

• 学科意义：网络流问题是1950年代最早用算法系统解决的问题之一，对理论计算机科学的建立起到了重要作用。此前的著名算法（如Ford-Fulkerson算法，以及Hopcroft、Karp和Tarjan因相关研究获图灵奖的工作）多只能高效解决特定子问题。
• 范式转变：2004年，Spielman等人将焦点从铁路网络转向电网，引入“部分重新路由”的概念。Kyng团队在此基础上，将其应用于早期方法，并发展出全新的混合策略，实现了速度上的飞跃。
• 广泛认可：该算法荣获2022年IEEE计算机科学基础年度研讨会（FOCS）最佳论文奖，并被《Quanta》杂志评为2022年计算机科学十大发现之一。

未来展望

该算法不仅解决了以往无法高效计算的大型问题，还为生物、社交网络等动态复杂系统的建模提供了更强大的工具。团队开发的新数据结构和算法工具预计将在更广泛的领域加速创新。

这篇文章探讨了撰写技术书籍的经济方面，揭示了作者如何从技术书籍中获得收入，以及不同出版选择如何影响收益。

核心原则 作者强调了几个关键原则：

• 规则零：如果安排中其他人赚钱，你也应该赚钱。
• 规则一：永远不要为了钱而写技术书籍（但这不意味着无法从中获利）。
• 规则二：你或许能靠一本书赚到10万美元，但不要指望在1年内实现。
• 规则三：永远不要计算写书的时薪。

收入来源与估算 书籍收入通常被视为被动收入（延迟收入），但前期需要投入大量工作。

• 达到10万美元收入所需的销量因出版方式而异：
  • 自出版电子书（零售价20美元，版税16美元）：约需售出6,000本。
  • 自出版纸质书（零售价30美元，版税10美元）：约需售出10,000本。
  • 传统出版书籍（零售价50美元，版税4美元）：约需售出25,000本。
• 现实销量：许多知名技术书籍销量巨大（如《设计模式》超50万本），但传统出版商认为售出10,000本即算成功。自出版书籍难以突破100,000本大关。作者提供了一个通过亚马逊评论数估算销量的公式：销量 ≈ 60 × 亚马逊评论数。
• 长期性：经典书籍（“常青书”）能持续销售数十年，而针对特定技术的书籍可能迅速过时。长期销售是收入的关键。

收益分成（版税） 收益分成比例差异巨大，取决于分销渠道：

• Gumroad: 88%（扣除信用卡费用后）。
• Leanpub: 80%。
• 亚马逊Kindle电子书：低于10美元的书版税65%，高于10美元则版税35%。
• 亚马逊KDP纸质书：零售价的60%减去印刷成本。
• 传统出版商：约5-8%的零售价（约为出版商净收入的15%）。

其他赚钱方式与定价

• 间接收入：书籍是强大的品牌工具，可以吸引咨询、付费演讲和高薪工作机会。一次付费工作坊的收入可能相当于卖出1000本书。
• 定价策略：自出版书通常定价（25-30美元）低于传统出版（40-80美元）。作者常采用渐进定价，初期低价以吸引早期读者并获得反馈。
• 支付周期：所有渠道都有支付延迟期（从7天到180天不等），以处理退款和聚合小额支付。

出版渠道选择 作者权衡了自出版（如Leanpub, Gumroad, Amazon）与传统出版的利弊：

• 自出版：收益分成高、控制权强，但需要作者自行负责所有制作、营销和发行工作（规则四：自出版即自营销）。工具支持程度不一。
• 传统出版：收益分成低、控制权弱，但提供全面的制作、编辑、设计、品牌信誉和广泛的发行与营销支持。
• 混合路径：作者常采用渐进方式，从博客开始，再到Leanpub，然后到亚马逊/Kindle，最终可能与传统出版商合作。

实用建议

• 营销至关重要：除了平台广告（可能昂贵），作者需通过博客、社交媒体和活动积极推广。
• 利用优惠券：在Leanpub等平台使用优惠券是有效的促销手段。
• 质量投资：自出版时，投资专业编辑和插图至关重要。
• 关注职业生涯：将书籍视为支持职业生涯（无论是求职、晋升还是成为独立顾问）的战略投资。

总而言之，撰写技术书籍可以带来可观收入，但通常需要长时间积累。成功取决于书籍质量、主题持久性、有效的出版渠道选择以及持续的营销努力。

微软高管称网络内容为“自由软件”引发的争议与思考

核心言论
微软AI首席执行官穆斯塔法·苏莱曼在采访中表示，自1990年代以来，公开网络上的内容遵循着一种“社会契约”：即这些内容是“公平使用”的，任何人都可以复制、改编和再创造，本质上已成为“自由软件”。

背景与讽刺
文章指出微软公司自身在1976年曾发表过著名的保护知识产权信函，这使得苏莱曼特意强调“自90年代以来”的说法显得颇具讽刺意味。作者调侃称，按此逻辑，Windows系统的盗版副本似乎也成了“自由软件”。

对生成式AI行业的分析
作者认为，这场采访反映了AI行业管理者思维模式的深刻变化。当前生成式AI模型面临多重困境：

• 财务不可持续：除非是提供基础设施的企业，否则大多数AI模型难以维持盈利。
• 质量遭质疑：“模型衰退”现象（指AI输出质量下降）揭示了工具无法真正“学习”或“获得灵感”的本质，公众开始将“AI生成”与低质、低效内容关联。
• 数据资源枯竭：可用于训练的有机内容正在迅速耗尽，AI发展可能即将触及天花板。

对“公平使用”论点的批驳
在伦理、财务、数学和法律层面均陷入困境后，生成式AI企业试图以“历来如此”为由，主张所有网络内容皆可用于训练。作者反驳了“聊天机器人等同于搜索引擎”的类比，指出关键区别：

• 搜索引擎会为内容提供来源链接，将流量导向原始页面。
• 聊天机器人则不提供来源，其生成的“幻觉”（不实信息）因缺乏审计轨迹而极具风险。作者认为，这两种工具的社会契约本质截然不同。

结论
作者将当前AI行业的狂热比作技术泡沫，并指出一个危险信号：行业推动者开始相信自己提出的“不合逻辑的论点”，这本身是另一种形式的“模型衰退”。

研究揭示彩裙蝶如何完成2600英里不间断跨大西洋飞行

2013年10月，昆虫学家杰拉德·塔拉维拉在法属圭亚那海滩发现约十只翅膀破损的彩裙蝶，该物种通常不分布于南美洲，这一发现引发了长达十年的科学调查。研究表明，这些蝴蝶很可能从西非出发，借助有利风力条件完成了横跨大西洋的壮举，全程约2600英里（约4180公里），这是首次记录到蝴蝶完成此类飞行。

多重证据链解开谜团

由于昆虫体型小、重量轻，难以安装追踪设备，研究团队采用了创新的多角度研究方法：

1. 气象数据分析：回溯蝴蝶到达前数周的天气记录，发现风向和风力条件支持从非洲到南美洲的飞行路径。
2. 基因组测序：对蝴蝶进行基因组测序，确认其与非洲、欧洲种群有亲缘关系，排除了从北美飞来的可能性。
3. 同位素分析：通过分析蝴蝶翅膀中的同位素，推断其出生地为西欧和西非。
4. 花粉DNA鉴定：对蝴蝶体表的花粉进行DNA测序，鉴定出两种西非特有灌木的花粉，这些植物仅在西非雨季结束时开花。

风力是关键因素

研究估计飞行耗时5至8天。蝴蝶主要依赖被称为“撒哈拉空气层”的大气环流——正是这股气流将撒哈拉沙漠的尘埃带到南美洲，滋养亚马逊河流域。科学家计算，若无风力辅助，蝴蝶仅能飞行约780公里（485英里）便会耗尽脂肪储备。

研究意义

该研究展示了跨学科方法在解开生物迁徙之谜中的价值。正如未参与研究的进化生态学家戴维·洛曼所言，这是一项“精彩的生物学侦探工作”。研究不仅揭示了彩裙蝶非凡的飞行能力，也表明撒哈拉空气层可能对昆虫迁徙具有重要生态意义。

Next.js App Router 使用复杂性增加

Next.js 的 App Router 相较于之前的 Pages Router，在开发者体验上面临两个主要挑战：

1. 完成基本任务需深入了解内部机制。例如，在服务器组件中获取 URL 这样的简单操作，也需要开发者理解框架如何分割工作、渲染优化等底层原理，而非直接提供直观的 API。
2. 许多容易出错的行为是默认开启的，而非由开发者主动选择。这增加了“意外行为”的风险，开发者常陷入“为什么这行得通/行不通？”的困惑中。

与 Pages Router 的对比：

• Pages Router 简单直观：路由类似文件系统，API 路由和 getServerSideProps 概念易懂，迁移自 Express 等现有知识成本低。
• App Router 引入强大但复杂的新特性：
  • 服务器组件：在服务端渲染 React 组件，减少客户端数据传输。
  • 布局：定义跨路由共享的 UI 部分，避免每次导航重新渲染。
  • 缓存机制变得更为复杂。 这些特性在追求性能优化的同时，牺牲了早期版本的简单性。

具体痛点举例：

• 访问请求对象受限：为了支持静态/动态渲染优化和流式传输等高级功能，App Router 不直接暴露完整的 request/response 对象，而是提供如 headers()、cookies() 等特定方法。这迫使开发者理解框架的启发式优化逻辑（例如，使用 headers 会自动选择动态渲染），增加了认知负担和重构代码的可能。
• 隐式行为与“陷阱”：例如，cookies().set() 在类型检查上无误，但在某些上下文（如流式开始后）运行时会失败。这种隐式规则容易导致 bug。
• 激进的默认缓存策略：许多开发者期望缓存是可选启用的功能，但 App Router 默认开启激进缓存，导致开发者需要查阅大量文档才能知道如何关闭。这常引发非预期的数据读取行为（如认为发起了新请求，实际读的是缓存）。

适用场景与选择考量：

• App Router 的复杂特性对性能敏感的应用（如电商平台）有价值：通过减少客户端数据、缓存和局部重渲染可加速页面加载，从而可能提升商业收益。
• 对于追求快速迭代的 SaaS 应用或内部仪表盘，复杂性可能成为开发负担：团队更关注功能交付速度，而非极致的渲染优化。
• 框架定位建议：React 官方文档将 App Router 描述为“前沿框架”，暗示其尚不完全成熟。开发者选择框架时，应意识到 App Router 仍存在粗糙之处，并根据项目具体需求和团队情况，考虑其他更简单或更适合的工具。

总结：随着产品发展，框架为满足高级客户需求而变得复杂是常见趋势。Next.js App Router 引入了面向未来的强大架构和优化，但也带来了显著的开发复杂度。开发者需权衡其性能优势与学习成本，并考虑当前项目是否真正需要这些高级特性。

XAES-256-GCM 扩展 Nonce 的 AEAD 算法总结

XAES-256-GCM 是一个经过认证的加密与附加数据（AEAD）算法，它基于标准的 AES-256-GCM，并对其进行了 nonce（随机数）的扩展。它使用 256 位密钥和 192 位 nonce，旨在解决标准 AES-GCM 在高吞吐量场景下因 nonce 长度限制（96位）而产生的安全与使用复杂性问题。

主要设计目标

1. 安全性：支持足够大的 nonce（192位），使其可以安全地通过密码学安全的伪随机数生成器（CSPRNG）为每条消息随机生成，而无需用户担心 nonce 碰撞问题（理论上可安全支持高达 2⁸⁰ 条消息）。
2. 合规性：完全符合 FIPS 140 系列标准，使其适用于对合规性有严格要求的场景，而许多其他扩展 nonce 的 AEAD 方案（如 XChaCha20-Poly1305）可能不满足此要求。
3. 易实现性：能够在常见的加密库（如 OpenSSL）之上以简单的方式实现，降低采用门槛。

核心原理与实现

XAES-256-GCM 是一个 “派生密钥”构造。它使用原始的 256 位输入密钥 K 和 192 位输入 nonce N，通过算法派生出一个新的 AES-256-GCM 会话密钥 Kₓ 和一个 96 位的 nonce Nₓ，然后使用这个派生的参数调用标准的 AES-256-GCM 进行加密。

其内部算法过程简述如下：

1. 使用输入密钥 K 对一个固定的全零分组进行 AES-256 加密，得到一个中间值 L。
2. 根据 L 的最高位（MSB）是否为 0，通过左移和可能的异或操作（与多项式 0b10000111）派生出一个子密钥 K1。这实质上是一种高效的子密钥派生方法。
3. 构造两个包含输入 nonce 前 12 个字节的特定数据块 M1 和 M2。
4. 使用 K 分别对 M1 ⊕ K1 和 M2 ⊕ K1 进行 AES-256 加密，将两个结果拼接成 256 位的派生密钥 Kₓ。
5. 取输入 nonce 的最后 12 个字节作为派生 nonce Nₓ。
6. 使用 (Kₓ, Nₓ) 执行标准的 AES-256-GCM 加密。

该过程每条消息需要 3 次 AES-256 加密调用。然而，其中一次调用（生成 L）的结果对于相同的密钥可以预计算和缓存，从而提升性能。

合规性与标准化描述

XAES-256-GCM 的设计可以完全用现有 NIST 标准来描述和解释：

• 密钥派生函数（KDF）：使用 NIST SP 800-108r1 中定义的基于计数器的 KDF。
• KDF 的底层伪随机函数（PRF）：使用 NIST SP 800-38B 中的 CMAC-AES256。
• 底层 AEAD：直接使用 NIST SP 800-38D 和 FIPS 197 中定义的 AES-256-GCM。

通过精心选择 KDF 的参数（如将输入 nonce 的前 96 位作为 Context，ASCII 字母 ‘X’ 作为 Label），该派生过程在剥离 KDF 抽象层后，其计算复杂度与直接调用 AES 加密一个计数器相近，但同时具备了经过审核的标准合规性。这些参数也得到了 OpenSSL 高级 API 的支持。

与其他方案的区别与定位

• 放弃 “/11” 优化：文章作者最初设想的 “/11” 变体（可能指减少 AES 轮数以提升性能）被放弃，因为修改轮数会破坏 FIPS 140 合规性，而这正是 AES-GCM 的主要价值之一。
• 替代方案比较：如果不需要 FIPS 合规性，存在其他替代方案（如 AES-GCM-SIV 或基于 AES 核心的新 AEAD 构造）。XAES-256-GCM 规范中提供了详细的比较。
• 生态定位：XAES-256-GCM 被设计为一种 “安全、稳定、合规、可互操作” 的 AEAD。它旨在与 XChaCha20-Poly1305 和 AES-GCM-SIV 等方案并列，共同服务于那些希望在高级 API 中实现“无 nonce”（nonce-less）AEAD 接口的场景（即由系统自动处理 nonce 生成）。

实现与测试

文章提到了 Go 语言的参考实现，代码简洁（少于 100 行），并仅依赖标准库。截至写作时，已有第三方在 .NET 8+、pyca/cryptography 和 Web Cryptography API 上的实现。规范中提供了详细的测试向量，涵盖了算法的两个主要分支（基于 L 的 MSB）以及大规模随机迭代的累积测试向量。

总而言之，XAES-256-GCM 是一个为提升易用性和安全性（通过大 nonce），同时严格遵守现行标准（FIPS 140）而设计的加密方案，特别适合需要兼顾合规性与现代开发体验的系统集成。

FUTO Keyboard 摘要

核心理念：
FUTO Keyboard 是一款注重隐私与安全的现代键盘，其核心承诺是“键盘不应连接互联网”。它确保100%离线、100%私密，所有功能均在设备本地运行，不传输或存储用户数据。

主要功能：

• 离线语音输入：无需互联网连接，语音数据完全本地处理。
• 滑动输入：提供先进的滑动输入系统（FUTO Swipe），提升打字速度。
• 智能纠错：减少打字错误。
• 预测文本：输入时提供智能拼写建议。
• 个性化定制：支持多种主题，用户可自定义键盘外观。

开发与支持：

• 该键盘仍在积极开发中，可能缺少部分功能或语言支持，鼓励用户反馈和报告漏洞。
• 提供一次性付费许可证购买选项，以支持项目持续发展。购买可确保键盘保持无广告、全功能，并支持专注于隐私和用户体验的开发团队。
• 许可证为一次性支付，无订阅费用。

附加信息：

• 用户可在兼容的第三方键盘中使用 FUTO 语音输入 功能。
• 项目呼吁用户通过 swipe.futo.org 贡献滑动输入数据，以帮助构建用于算法开发的独立开放数据集（需移动设备参与）。

总结：FUTO Keyboard 以隐私为核心，提供完全离线的输入解决方案，结合语音输入、滑动打字等现代化功能，并通过一次性购买模式维持其无广告、注重用户体验的运营模式。

Neo Geo 架构分析摘要

市场定位与型号

Neo Geo 是第四代最昂贵的硬件，源于街机市场，设计目标是满足街机运营商和富裕家庭的需求。SNK 基于同一架构生产了两种主要型号：

• MVS（多视频系统）：针对街机设计，兼容 JAMMA 规范，具有投币支付功能，有多种修订版，部分可同时容纳六个游戏卡带。
• AES（高级娱乐系统）：简化版家用型号，体积更小，I/O 接口减少，但核心功能未妥协。
• 此外还有后续的 Neo Geo CD 型号，采用 CD-ROM 分发游戏。

核心处理器

系统采用双处理器配置：

• 摩托罗拉 68HC000：主 CPU，运行频率 12 MHz（比 Mega Drive 快 4 MHz），负责执行主程序（游戏）。采用 CMOS 工艺。
• 齐格洛 Z80：频率 4 MHz，专门负责音频管理。

支持芯片与系统特性

主板集成了大量专用控制器，减轻 CPU 负担并扩展功能，包括：

• 68k 控制器：自动切换向量表。
• Z80 控制器：缓解内存寻址限制。
• I/O 仲裁器：处理所有 I/O 操作，节省 CPU 周期。
• 视频显示控制器（VDC）：处理所有图形操作。
• 街机/家用专用控制器：如 MVS 的投币和计分板控制，AES 的视频编码器。

关键特性：

• 中断处理：利用 68000 的矢量中断表，通过 NEO-E0 芯片自动切换操作系统和游戏的中断表，提高 I/O 效率。
• 进程间通信（IPC）：通过 I/O 仲裁器芯片的 8 位寄存器实现 68000 与 Z80 通信。Z80 通过 NMI 中断响应，但 68000 需轮询读取数据。
• 看门狗定时器：集成在 I/O 仲裁器中，防止街机因软件崩溃停止运营。游戏需定期“喂狗”，否则系统将自动复位。
• 内存：68000 拥有 64 KB RAM，Z80 拥有 2 KB RAM。MVS 型号额外增加 64 KB 电池供电 RAM 用于存储游戏分数。系统无 DMA 控制器。

图形系统

图形基于瓦片（Tile） 构建，性能强大，以大量精灵著称，无需传统背景层。

• 分辨率：NTSC 为 320×224，PAL 为 320×256。
• 架构：
  • 主板内存：64 KB VRAM（分为快速和慢速，用于存储精灵属性和瓦片引用）、四条扫描线缓冲器、16 KB 调色板 RAM、64 KB L0 ROM（用于精灵缩放的查找表）。
  • 卡带内存（CHA Board）：C ROM 存储精灵瓦片，S ROM 存储固定层瓦片。
• 渲染流程：CPU 填充 VRAM → VDC 从 ROM 获取瓦片并存入行缓冲 → VDC 从行缓冲读取数据并访问调色板 RAM → 视频 DAC 输出信号。采用行缓冲系统，可在活动显示期间更新图形。
• 精灵：基础尺寸为 16×16 像素，可组合成最大 16×512 像素的尺寸。每扫描线最多 96 个精灵，每帧最多 381 个。支持翻转和缩放，属性存储在 VRAM 的精灵控制块（SCB）中。
• 固定层：320×256 像素的静态层，用于显示常驻信息（如 HUD），仅可使用 16 个调色板。

音频系统

由 Z80 控制，核心是雅马哈 YM2610 FM 合成芯片（与 YM3016 DAC 配合输出模拟音频）：

• 功能：
  • 4 个 FM 通道（每个 4 算子），带低频振荡器（LFO）。
  • 内置 YM2149 PSG（3 个方波通道加噪声）。
  • 7 个 ADPCM 通道：分为 ADPCM-A（6 通道，12 位，~18.5 kHz）和 ADPCM-B（1 通道，16 位，高达 ~55.56 kHz）。
• 音频数据：存储在卡带的 V ROM 中，受限于卡带容量。
• 控制：Z80 运行卡带 M1 ROM 中的音频驱动程序。

操作系统与游戏

• 系统 ROM：主板上的 128 KB BIOS，提供引导加载程序、自检、启动动画、配置菜单（仅 MVS）以及操作硬件的系统例程。
• 游戏：使用 68k 和 Z80 汇编语言编写。游戏需实现系统 ROM 要求的特定回调。
• 存储介质：采用大型卡带，内部分为 PROG Board（含 P ROM 程序、V ROM 音频）和 CHA Board（含 C ROM 图形、S ROM 固定瓦片、M1 ROM 音频程序及可能的映射器）。
• 存档：使用专有的电池供电内存卡（2 KB 至 16 KB SRAM）。

反盗版与自制软件

• 反制措施：游戏通过检测主板特定区域、交互专用芯片（如 PRO-CT0、NEO-CMC）或使用加密来防止在盗版硬件/卡带上运行。
• 后期自制：社区提供了硬件改装（如 MVS 主机化）、自定义固件（如 UniBIOS，支持模式/区域切换、作弊）和第三方闪存卡等工具。

结语

Neo Geo 凭借其强大的街机血统和无预算限制的设计，在图形（特别是精灵数量）和音频功能上领先于同期家用机。其独特的双市场定位、复杂的硬件支持和持久的生命周期（最后一款游戏发布于 2004 年）共同构成了其技术上的显著特点。

如何克服糖瘾：个人经历与关键方法

作者童年时的早餐充满糖分，包括含糖谷物、果酱吐司和巧克力奶昔，这导致全天能量水平剧烈波动和体重问题。在缺乏健康饮食榜样的环境中，作者逐渐形成对糖的依赖，并在成年后将糖作为应对压力的即时安慰剂，甚至深夜外出购买甜食。

关键转折点：二十岁出头时，作者意识到超重和疲惫与糖瘾有关，并决定彻底停止摄入添加糖。尽管过程中多次复发，但复发的频率和持续时间逐渐减少。

三个帮助克服糖瘾的核心方法

1. 改变环境
   参考1971年一项关于越战美军海洛因成瘾者的研究，发现只有12%的士兵在回国后三年内复发，表明剧烈的环境变化能显著降低复发率。作者效仿此原则，通过长假远离日常环境，打破原有饮食习惯，作为戒糖的第一步。

2. 移除接触糖分的可能性
   从假期返回后，作者清空家中所有含糖食品。缺乏即时获取的便利性大幅降低了屈服于欲望的概率，将持续的意志力消耗转化为一次性的清理挑战。

3. 建立具有积极连锁效应的习惯
   作者将习惯比作“溢出花瓶并填满周围花瓶的水”，认为某些习惯会带动整体生活改善。例如：

   • 规律进行力量训练：健身后身体更需要蛋白质和健康能量，自然降低对糖的渴望。
   • 保证充足饮水：增加饱腹感，减少总体进食量。
   • 保持活跃的生活方式：这些习惯形成良性循环，间接支持戒糖目标。

现状与鼓励

作者如今虽仍会在特殊场合偶尔摄入添加糖，但消费量已远低于过去。文章最后指出糖瘾非常普遍却常被忽视，鼓励有类似困扰的人采用上述方法，强调改变的可能。

SkyPath 是一款基于数据驱动的专业航空湍流管理工具，旨在通过实时数据和机器学习预测来提升飞行安全与运营效率。

其核心功能 OneLayer 将五个不同来源的湍流数据，通过先进的AI建模、过滤和标准化进行整合与处理，形成一个统一、直观的显示层，从而提升飞行员态势感知能力并减轻工作负荷。

关键数据与效益：

• 数据规模： 每年处理 3200万 次飞行员通知，基于 90亿 条众包报告，每日服务约 3.4万 用户。
• 主要优势：
  • 提升安全： 提供实时湍流观测与预测，允许飞行员提前调整航路，降低乘客与机组受伤风险。
  • 节约燃油： 通过精准数据帮助飞行员避开非必要湍流，优化航路，降低燃油消耗。
  • 优化预算与维护： 减少湍流相关损伤、优化燃油使用、降低维护及非计划检查成本，从而帮助运营商节约开支。
• 用户评价： 多位A320、A319、B737等机型的机长和副驾驶反馈，称赞其准确性、实时性，并表示该工具已帮助他们多次避开严重湍流，减少了向空管询问飞行状况报告的需求。

其他特性与技术：

• 尾迹层： 由Google AI驱动，在单一界面中同时显示实时凝结尾迹预报和湍流数据，支持在不影响安全的前提下做出对气候更友好的决策。
• 可靠定位： 支持多种位置源（如飞机系统Starlink、Gogo、FOMAX及自动WiFi定位），确保在各种驾驶舱环境下获得可靠的湍流感知与飞机位置精度。
• 企业级安全： 符合SOC 2 Type 2合规标准，确保数据安全与隐私保护。

根据2024年6月29日的报道，巴拿马法院已宣判在与“巴拿马文件”丑闻相关的洗钱案中受指控的所有28名被告无罪。此次审判于2024年4月开始。

法官巴洛伊萨·马尔基内斯裁定，法庭所考量的证据“不足以”确定被告的刑事责任。据当地新闻报道，审判历时85小时，听取了27名证人的证词，并审议了50多份证据文件。法官指出，从莫萨克丰塞卡律师事务所服务器收集的证据未按照法定程序获取，因此撤销了所有刑事指控。

获判无罪的被告中包括该律所创始人于尔根·莫萨克和已故的拉蒙·丰塞卡。检方曾寻求对两人判处12年监禁。两名被告均否认其本人、律所或雇员有任何非法行为。

“巴拿马文件”是史上最大规模的数据泄露事件，2016年，1100万份秘密财务文件被泄露给德国《南德意志报》并与国际记者团队共享。这些文件揭露了世界上一些最富有和最有权势的人如何利用避税天堂隐藏财富，涉及12位现任或前任国家元首及政府首脑。

2017年，莫萨克丰塞卡律所曾声称，该所是计算机黑客攻击的受害者，且泄露的信息遭到了歪曲。

文章摘要：《A Eulogy for DevOps》

本文回顾了DevOps理念的兴衰，剖析其初衷、实践中的问题以及当前演变趋势。

起源与初衷 DevOps于2007年左右兴起，旨在打破开发与运维之间的“筒仓”，通过紧密协作来提升软件发布速度和安全性。早期实践借鉴了NASA的严谨流程，强调周密的发布手册和分阶段部署，但这一过程高度依赖人力协调，且发布周期漫长。

转向与真正动机 企业向DevOps模式转变的表面原因是提升效率，但深层原因包括：减少对难以替代的专业技术人员的依赖、降低招聘成本、使销售需求能更快融入产品周期，以及适应当时云计算平台和SaaS服务的兴起。在“免费”资本和云预算的驱动下，速度被置于优先地位。

实践模式与初期问题 DevOps的核心是合并开发与运维职责，让开发者能自主频繁部署。典型流程包括Git分支、代码审查、CI/CD流水线构建容器镜像、通过Kubernetes等平台部署，并依赖实时指标监控。然而，问题很快出现：

1. 环境差异：开发者本地环境与生产Linux服务器配置的不一致，导致“在我机器上能运行”的问题。
2. 职责模糊：当生产环境出现非应用层面的平台问题时，责任归属不明确。
3. 开发者抵触：开发者不愿处理底层系统细节，其绩效通常只与交付的功能挂钩。

容器技术的双刃剑 容器（如Docker）和编排工具（如Kubernetes）的普及解决了部分环境一致性问题，并简化了服务器管理，使得部署频率大幅提升。然而，它们并未解决所有问题，反而引入了新的复杂性和专业性要求。

遗留的核心挑战 尽管部署速度加快，但软件运行的根本难题依然存在：

• 运维复杂性：管理Kubernetes集群、升级系统、配置网络等任务需要专门的、往往更昂贵的云平台专业技能。
• 可观测性成本：实现有效的监控、日志和追踪系统变得复杂且昂贵，商业可观测性服务（如Datadog）的账单可能超过基础设施本身成本。
• 知识共享失效：开发与运维团队之间因激励机制不同，有效的跨领域知识共享并未实现。
• 规划混乱：缺乏协调导致功能开发无序，在微服务架构中尤为明显，常造成重复建设。

经济压力与“回归基础” 随着经济环境变化、预算缩减和裁员潮，无限制的云支出和庞大的团队规模变得不可持续。许多组织开始重新评估技术选型，出现“回归基础”的趋势，例如放弃复杂的Kubernetes，转向更简单、易于排查的部署方式。

当前趋势：平台工程 作为DevOps的继任者，“平台工程”旨在通过提供抽象化的内部开发者平台，让开发者只需提交容器即可，将底层平台的所有权集中于专门的平台团队。然而，文章质疑这可能是行业为了持续增长而制造的新概念，并指出它实际上可能进一步扩大了开发者和运维人员的技能要求。

结论 作者认为，DevOps的许多核心改进（如自动化、协作文化）值得保留，但整个行业需要从对“无限增长”和“全球规模”的盲目追求中清醒过来。未来的方向应是简化与稳定，组织需更务实地评估自身实际需求，而非追随被炒作起来的技术潮流。

LlamaAgents 概述

LlamaAgents 是一个开源的 Python 框架，专注于构建和部署以文档为中心的智能体（agents）。它旨在解决文档工作流中常见的复杂性问题，例如整合 OCR、LLM、结构化提取、分类、自定义验证和人工审核等多个环节。

核心架构与特性

该框架的核心是 Agent Workflows，一个事件驱动的编排库。其关键特点包括：

• 异步与事件驱动：工作流步骤是异步 Python 函数，通过发出和消费事件来交互。
• 灵活性与可扩展性：支持分支、循环、并行化、状态持久化和故障恢复，全部在纯 Python 中实现，无需特定领域语言（DSL）。
• 适应不同规模：设计用于应对从原型验证（如笔记本中解析几份合同）到大规模生产部署（如每月处理百万份发票）的各种工作负载，无需重写代码。

主要使用方式

LlamaAgents 提供了多种部署路径，以适应不同开发阶段和需求：

1. 作为库使用：

   • 最简单的方式是通过 pip install llama-index-workflows 安装。
   • 可以直接在脚本、笔记本或服务器中定义和运行工作流。
   • 耐久性（Durability）是可插拔的，支持从文件或数据库保存和恢复运行状态。

2. 集成到现有应用：

   • llama-agents-server 包可以将任何工作流包装为带有流式传输、持久化和人工介入（human-in-the-loop）支持的 REST API。
   • 可以嵌入到现有的 Starlette/FastAPI 应用中，或独立运行。
   • llama-agents-client 包提供了用于从其他服务调用工作流的异步客户端。

3. 作为可部署的智能体：

   • llamactl 是一个 CLI 工具，用于端到端地构建和部署智能体应用。
   • 支持从模板初始化、本地开发（带热重载）以及部署到多种环境（如 LlamaParse、AWS Bedrock AgentCore 或自定义基础设施）。
   • 部署形式可以是无头工作流服务、MCP 服务器或带有用户界面的全栈应用。

与 LlamaParse 的集成

LlamaAgents 建议将 LlamaParse 用于繁重的文档处理基础功能（如 OCR、结构化提取、分类和分割）。开发者可以将这些功能作为步骤集成到工作流中，从而让 LlamaParse 负责文档理解，而智能体代码专注于编排、业务逻辑和审核逻辑。框架还提供了通过 llamactl 使用的预构建模板以简化开发。

OpenLoco：经典运输模拟游戏的现代开源版本

OpenLoco是一个致力于通过用C++语言重新实现，创建Chris Sawyer’s Locomotion游戏的现代、开源版本的项目。该项目旨在提供一个更现代的体验，同时保持原作的经典元素。更多信息和下载选项可在相关资源中获取。