文章摘要：Mozilla 将逐步停止 Pocket 和 Fakespot 服务

Mozilla 宣布，作为其独立非营利组织的战略调整，将逐步停止两项产品：Pocket 和 Fakespot，以便将资源更集中地投入到 Firefox 浏览器及其未来的核心功能开发上。

停止服务详情

1. Pocket（“稍后阅读”及内容发现应用）

• 关闭日期：2025年7月8日。
• 关键时间点：
  • 2025年5月22日起，无法再下载或订阅 Pocket Premium。
  • 付费订阅将自动取消，年度订阅用户将自7月8日起获得自动退款。
  • 用户需在2025年10月8日之前导出其保存的数据，之后数据将被永久删除。
  • API 用户同样需在此日期前完成数据导出，届时API的读写功能将停止。

2. Fakespot（在线产品评论真实性分析工具）

• 关闭日期：2025年7月1日。
• 关键时间点：
  • 从该日起，所有 Fakespot 的浏览器扩展、移动应用及网站将无法使用。
  • 内置在 Firefox 中的“评论检查器”功能将提前于2025年6月10日关闭。

决策原因

• 战略聚焦：Mozilla 旨在利用其独立性，将有限的时间和资源集中于能对未来互联网产生更大影响的核心产品上，即Firefox 浏览器。
• 产品匹配度：
  • Fakespot：尽管其利用AI和隐私优先技术帮助用户辨别虚假评论的理念受到关注，但未能找到一个可持续的商业模式。
  • Pocket：用户的网络内容保存和消费习惯已发生演变。Firefox 已内置了标签页分组和增强书签等管理阅读列表的新功能。此外，Pocket 曾为 Firefox 中的策展内容推荐体验做出贡献，该体验将持续改进。

未来展望

Mozilla 表示，此次调整将使公司能够专注于塑造互联网的下一个时代。未来 Firefox 将着重发展以下方向：

• 推出 垂直标签页、智能搜索 等新功能。
• 开发更多 AI 驱动的功能。
• 持续打造一个更个性化、更强大且保持独立的浏览器。

用 Zig 语言开发 Game Boy Advance 游戏心得

项目背景与平台选择

作者选择为 Game Boy Advance (GBA) 开发游戏，主要原因有二：其一，GBA 的硬件独特（32位ARM CPU 配合传统瓦片渲染器）；其二，作者对数字方块规则游戏（如Picross、扫雷）情有独钟，因此决定实现《2048》。

为何选择 Zig 语言

作者摒弃了常用的 C++ 和 devKitPro 工具链（依赖特定包管理器），转而采用 Zig 语言。Zig 在嵌入式开发中表现出以下显著优势：

1. 构建系统与交叉编译

• 跨平台编译简便：只需指定目标平台，无需配置复杂工具链。
• 集成化构建流程：在 build.zig 文件中，可依次完成编译ELF文件、使用 objcopy 提取ROM数据、添加GBA头信息等全部步骤，过程清晰且不易出错。
• 便捷的代码生成：支持在构建过程中编译代码生成程序（如将PNG图像转换为GBA像素数据），并能自动处理依赖与并行编译。

2. 语言特性

• Packed Structs：允许定义非对齐的紧凑结构体，完美映射GBA硬件寄存器（如 BGxCNT）的位域布局。相比C语言的位操作，可通过结构体字段名直接、清晰地访问寄存器位，极大提升了代码可读性与开发体验。
• Comptime (编译时计算)：可在编译时执行代码。作者利用此特性在编译阶段压缩精灵数据，减小ROM体积，而无需额外代码生成步骤或运行时开销。
• 灵活的内存分配器：标准库中所有涉及内存分配的函数都接受自定义分配器参数，便于开发者根据GBA资源限制选择最合适的分配策略（如固定缓冲区分配器）。虽然作者项目未实际使用，但这体现了语言的灵活性。

3. 标准库

Zig 的标准库基于泛型设计，更适应嵌入式环境。例如，作者利用自定义 io.Writer 实现了分数显示功能，并避免了在最终二进制文件中包含未使用的浮点处理代码。

遇到的问题与挑战

Zig 在特定场景下仍存在不足，主要与GBA硬件特性相关：

• 内联汇编限制：目前仅支持单个输出，而GBA的某些BIOS函数需要返回多个值到不同寄存器。
• 函数指令集切换：无法像C语言那样方便地通过属性指定函数为ARM或Thumb模式。要使用需要ARM模式的中断处理函数，需在单独的编译单元中定义并链接。
• 特殊内存区域处理：GBA的显存等区域有特殊的访问限制（如不能按8位单位写入），编译器优化有时会意外替换内存操作代码，需要开发者额外注意。

总结

Zig 语言凭借其强大的构建系统、贴合硬件的类型系统（如Packed Structs）以及编译时计算能力，成功简化了针对Game Boy Advance这类复古主机的嵌入式开发流程，尤其解决了工具链管理和硬件寄存器访问等痛点。尽管在极少数底层交互上存在局限，但其整体体验明显优于传统的C/C++开发方式。

文章总结：

在YouTube平台上，版权滥用投诉问题存在一定的普遍性。据YouTube官方数据，2023年7月至12月期间，约6%的内容删除请求属于滥用行为，而尝试滥用的请求量更是其十倍以上。由于部分用户担心因协助侵权而面临法律诉讼，可能不会主动举报滥用行为，因此实际滥用情况可能更为严重。

YouTuber创作者Neumayer在接到两份DMCA删除请求后，并未立即服从，而是进行了细致审查。他发现请求虽署名“任天堂法律部门的Tatsumi Masaaki”，但第二封邮件却来自一个加密邮箱服务商的个人账户“tatsumi-masaaki@protonmail.com”，这引起了他的警觉。

为维护自身权益，Neumayer展开质疑，最初成功恢复了被下架的视频。然而，冒牌律师随后升级施压，导致Neumayer迫于压力自愿删除了部分视频，同时他继续深入调查这起疑似恶意投诉事件。

Neumayer尝试直接联系任天堂公司以获取信息。根据《The Verge》报道，任天堂最终回复指出，该Proton邮箱地址“并非任天堂的合法邮箱，邮件内容所包含的细节也不符合美国任天堂公司的执法惯例。”这为Neumayer挑战删除请求提供了依据。

然而，事件仍存在未解之谜。调查发现，日本任天堂确实有一位姓名相似的专利律师，但无法确认是否为同一人；任天堂方面也未向《The Verge》证实Tatsumi Masaaki是否为其员工。

LineageOS 22.1 发布摘要

核心版本

• LineageOS 22.1 正式发布，基于 Android 15 QPR1。
• 版本命名更新：由于 Google 转向基于主干的开发并增加季度平台更新 (QPR)，LineageOS 恢复了点号版本号（如 22.1、22.2），以便用户区分 Android 的小版本。

主要更新与亮点

• 开发速度：得益于贡献者增加、项目领导更新以及前几个版本的适配经验，此次从 Android 15 的适配和设备适配速度均快于往年。
• 新应用：
  • Twelve：全新音乐应用，取代老旧的 Eleven。采用 Material You 设计，支持平板/横屏、主流流媒体服务（如 Subsonic、Jellyfin）、流媒体协议（HLS/DASH）、改进的搜索和 Android Auto 支持等。
  • Camelot：原生 PDF 阅读器，用于弥补 WebView 和浏览器应用对 PDF 支持不足的缺陷。
• 性能与工具优化：
  • 贡献者 demon000 重写了设备提取工具，使用 Python 重写后，提取时间大幅缩短（从约 180 秒降至约 30 秒，优化后可达 6 秒）。
  • 新增了对 virtIO（QEMU/crosvm/UTM 等）虚拟化目标的实验性支持。
• 安全与更新：合并了 2024 年 3 月至 11 月的安全补丁；更新了 SeedVault、Etar 和 WebView（至 Chromium 131）。
• 内核与兼容性：
  • 继续推广针对特定 SoC 的通用内核，以简化设备维护。
  • 将旧设备所需的“shims”（兼容性库）进行通用化，减少维护者重复工作。

设备支持

• 首发设备众多：发布了超过 100 款 支持设备的列表，包含从 LineageOS 21 迁移的设备以及部分新增设备（如多款 Google Pixel、三星 Galaxy、一加、小米等机型）。
• 分阶段支持：LineageOS 22.1 将首先为一批符合要求的设备启动构建，更多设备将在维护者确认准备好后陆续加入。
• 版本过渡：不再接受新的 LineageOS 20 设备提交；21 分支在功能和稳定性上已与 22.1 持平。

用户指南与社区资源

• 升级方式：现有官方用户通常无需清除数据即可按 Wiki 指南升级；从非官方版本升级则需按照全新安装流程操作。
• 下载门户改进：新增暗色模式、附加镜像下载和下载文件验证功能，确保镜像未被篡改。
• Wiki 扩展：设备列表支持按属性筛选，安装指南已分页优化。强烈建议用户严格按照各自设备 Wiki 页面的最新指南操作。
• 贡献呼吁：欢迎开发者提交新设备支持，也欢迎其他贡献者参与应用、翻译（支持多语言，如威尔士语）或 Wiki 改进。

通用目标与实验性构建

• 提供通用的模拟器 (Emulator) 和 GSI 构建目标，方便开发者或爱好者体验。
• 新增实验性 virtIO 构建目标，相关指南可在 Wiki 上找到。

注意事项

• 由于 AOSP 的重大架构变更（如动态分区、虚拟 A/B 分区），用户必须遵循设备特定的安装说明，切勿凭记忆操作旧流程。
• 设备可能在某个 QPR 版本中失去支持，维护者需要在每个 QPR 后检查设备兼容性。

软件设计即知识构建

案例概述

本文通过公司ORG的系统SVC案例，展示了软件开发中的一个常见困境：一个按时交付、功能正常的系统，在更换维护团队后迅速陷入难以维护的境地。关键转折点在于核心开发者X10离开公司，带走了对系统设计意图和业务背景的完整理解。

问题根源

SVC系统在代码层面没有明显缺陷，但新团队TEAM无法有效维护和修改系统，原因在于：

• 团队缺乏对系统设计意图和业务背景的理解
• 代码只展示了“如何实现”，未解释“为何如此设计”
• 团队只能通过逆向工程和猜测来理解系统，导致开发效率低下

理论支撑

1. David Parnas的“软件老化”理论

• 警告将软件交给不理解其设计的开发者
• 不了解原始设计概念的人进行的修改会导致程序结构退化
• 最终可能没有人真正理解被多次修改后的软件

2. Peter Naur的“理论构建”观点

• 编程活动本质上是程序员构建和持有“理论”的过程
• 软件设计的主要产物是将现实世界问题映射到系统的思维模型
• 具备理论的程序员能够：
  • 解释系统各部分与现实世界的对应关系
  • 为设计选择提供合理论证
  • 有效响应系统修改需求

3. Zach Tellman的解释性观点

• 软件开发可以归结为一种迭代的解释活动
• 理解软件是向自己讲述其故事
• 修改软件是向他人解释这些故事

系统“死亡”与“复活”

根据Naur的理论，当拥有系统理论的程序员团队解散时，系统就进入“死亡”状态，即使仍在运行。新团队的任务是通过重建理论来“复活”系统，这个过程极其困难。

实践启示

软件设计的最终目标应是构建组织知识。在日常开发决策中（如命名、项目结构、文档编写），应考虑这些决定将如何影响未来维护者构建系统、业务和现实世界的思维模型。良好的“副文本”（注释、文档、提交信息等）对知识传承至关重要。

文章摘要

原生应用的问题

• 过度普及与缺乏理由：智能手机热潮后，原生应用泛滥，但现代浏览器功能已强大（如通知、离线访问），使许多应用显得冗余。例如，Italki网站强制下载应用来接受移动课程请求，导致用户卸载，反映了普通用户对应用过载的不满。
• 高成本与笨重性：开发者面临应用商店费用、审核流程和跨平台维护负担；用户则承受频繁更新、存储占用和设备兼容性问题。应用商店的可发现性并不优于网站，营销方式相似。

网络应用的优势

• 跨设备可访问性：单一响应式网站可适配桌面、手机、平板等设备，并支持同步更新，灵活性远超原生应用。
• 现代浏览器功能：浏览器已支持通知、离线模式、安全支付等技术，结合WebAssembly、WebGPU和WebXR，性能接近或达到原生水平。

游戏领域的证明

• 技术进步：HTML5、WebGL和WebAssembly使浏览器游戏性能提升，如Meta的Oculus浏览器已能提供媲美原生应用的体验。
• 市场增长：平台如Poki和CrazyGames月活用户达9500万，显示网络游戏复兴；工作室如Pelican Party（代表作Narrow One）仅靠网络游戏实现可持续商业模式。
• 工具发展：Three.js推动3D网络内容，Rogue Engine作为游戏引擎专注于Web-first开发，并与Multisynq集成以简化多人游戏开发。

面临的挑战

• 浏览器用户体验：移动浏览器需改进导航和屏幕利用，以提供更顺畅的体验。
• 应用商店阻力：谷歌和苹果等巨头不会轻易放弃利益，但网络应用增长将逐渐削弱其主导地位。
• 数据收集动机：部分公司推动应用安装以获取更多权限和数据，绕过浏览器的安全透明控制。
• 风险投资忽视：VC低估网络游戏革命潜力，对工具和平台投资不足，需及时行动以避免错失机遇。

未来展望

• 网络为中心的趋势：WebGPU、WebAssembly等技术使网络成为通用平台，原生应用将局限于小众场景（如专业编辑）。
• 开发者机遇：拥抱网络技术可摆脱应用商店限制，创建跨设备体验，最终回归网络的开放本质。

魔法背后的时间原理

魔术师Teller表演过一个魔术：让观众选一张牌，然后带领观众走到附近公园，挖出一个埋藏已久的盒子，里面恰好是观众所选的牌。这一看似超自然的技巧，其秘密在于极端的时间投入：Teller提前数月在公园里埋藏多个对应不同牌的盒子，等待草地完全覆盖痕迹后才进行表演。

核心原理：
魔术的本质并非超能力，而是“一个人在某件事上花费了超出常人合理预期的时间”。Teller自己总结道：“有时魔法仅仅是有人在某件事上花费了超出常人合理预期的时间。”

延伸至其他领域：
这一原理同样适用于钢琴家（手指的异常灵活）、演讲者（极具感染力的表达）和画家（逼真到不可思议的作品）。他们的“魔法”都源于超常的时间投入。

实践启示：

1. 心理挑战：为一个目标投入极端的时间和注意力在心理上是困难的，因为“做不可能的事”本身感觉不可能。
2. 可行路径：
   • 从小处开始，逐步递增。
   • 通过行动创造改进的基础。
   • 积累重复练习。
   • 从一个简单可行的系统演化出复杂系统。
3. 结果：多年坚持后，终将迎来“一夜成名”的时刻——完成一件看似神奇甚至不可能的事。

总结：达成非凡成果的关键，不在于瞬间的灵感或天赋，而在于愿意投入超越常规的、漫长的时间去准备和积累。

本文介绍了通过内存转储技术在 Windows 11 (24H2) 上绕过 BitLocker 加密的方法，其核心是从内存中提取全卷加密密钥 (FVEK)。

背景与前提

• 攻击者需要物理接触设备，并在系统运行时突然重启以保留内存内容（RAM 中的数据会在断电后快速衰减）。
• 可通过短接主板重置引脚等方式实现突然重启，避免彻底断电。
• 安全启动 (Secure Boot) 是一种潜在障碍，但已有绕过方法。

关键步骤

1. 创建启动盘：使用一个容量大于目标系统内存的 USB 设备，并使用提供的 flashimage.sh 脚本创建可启动的应用程序。
2. 突然重启目标系统：在 Windows 加载期间（登录界面前）重启，此阶段找回 FVEK 密钥的成功率较高。
3. 从 USB 启动并转储内存：从 USB 启动进入 UEFI Shell，运行 app.efi 工具 Memory-Dump-UEFI 来转储内存。转储文件可能因 FAT32 文件系统 4GB 限制而分为多个。
4. 分析内存转储文件：
   • 使用 concatDumps 工具合并多个转储文件。
   • 使用 xxd 等工具查看原始数据，并用 searchMem 工具搜索特定十六进制模式。
   • 利用内存池标签 (Pool Tags) 定位密钥：这些标签标识了 Windows 内核内存池。
     • 在 Windows 11 中，FVEK 密钥可能在以下位置找到：
       • dFVE 标签（对应 dumpfve.sys）：这是最可靠的位置，密钥前通常有 0x0480 标头（表示 XTS-AES-128 算法）。
       • None 标签（对应 ExAllocatePool 调用）：密钥可能分段出现。

密钥恢复与后续操作

• 找到的密钥前需要添加算法标头（如 0x0480）并以小端格式写入文件。
  • 例如，将 0480 + 原始密钥的十六进制字符串通过 xxd -r -p 写入 output.fvek 文件。
• 推荐使用 dislocker 等工具套件，结合获取的密钥文件来解锁受 BitLocker 保护的驱动器。

补充说明

• 作者通过内核调试（如使用 WinDbg）研究 Windows 启动过程和 BitLocker 行为，从而定位密钥。
• 尽管微软试图通过 SymCryptSessionDestroy 等函数销毁密钥，但仍有密钥残留在堆上。
• 文章提供了多个参考链接，包括密钥恢复历史、BitLocker 格式文档、dislocker 工具和内存池标签列表。

The request was rejected because it was considered high risk

本文介绍了如何使用Grafana Cloud将原始天气数据转化为直观的本地天气监控仪表板。Grafana是一个开源的数据可视化平台，能够连接多种数据源，将复杂数据以图表等可视化形式呈现。Grafana Cloud是其全托管的云服务版本，基于Grafana LGTM技术栈。

文章通过一个免费天气仪表板的构建实例，展示了Grafana的实际应用。该实例使用了美国国家气象局的免费API获取JSON格式的天气数据，并通过Grafana的Infinity数据源插件进行连接与可视化。教程适合初学者，大约耗时30分钟。

创建天气仪表板的主要步骤包括：

1. 注册Grafana Cloud账户（提供免费层级）。
2. 导入一个预先配置好的天气仪表板。
3. 使用国家气象局的网格点API，根据经度和纬度连接本地天气数据源。
4. 自定义仪表板，例如添加城市名称，并可将其保存为移动设备友好的格式以便随时查看。

文章最后提到，此示例仅是Grafana Cloud功能的一小部分，鼓励用户通过官方资源进一步探索其在处理指标、日志、追踪等观测数据方面的能力。

Linux上下文切换内部原理：进程状态与内存

本文是关于Linux上下文切换内部原理系列文章的第一篇，聚焦于两个基础概念：内核如何通过task_struct表示进程的执行状态，以及如何通过mm_struct管理进程的地址空间（内存状态）。理解这些是理解上下文切换如何安全地在进程间转移CPU控制权的关键。

一、进程的执行状态管理：task_struct

进程是程序运行时的实例，其状态在执行过程中不断变化。Linux内核使用庞大的task_struct结构体来代表和跟踪每一个进程。

1. 关键字段与功能

• thread_info 与调度触发：包含TIF_NEED_RESCHED标志。当进程耗尽时间片且存在其他就绪进程时，内核在处理定时器中断时会设置此标志。当内核从系统调用或中断返回用户空间前检查到该标志，便会调用调度器的schedule()函数触发上下文切换。
• __state 进程状态：定义进程在任一时刻必须处于以下五种状态之一：运行/可运行、可中断睡眠、不可中断睡眠、停止、僵尸。这些状态直接影响调度决策。
• stack 内核栈：每个进程拥有独立的内核栈，用于在CPU执行内核代码（如系统调用、中断处理）时管理函数调用和保存寄存器状态。用户态栈则由内存管理部分跟踪。
• mm 内存描述符指针：指向mm_struct，管理进程的虚拟地址空间，将在下一节详述。
• 调度信息 (sched_entity se)：
  • vruntime：记录进程在当前CPU时间片上经过加权后的虚拟运行时间。高优先级进程的vruntime增长较慢，从而获得更多的CPU时间。
  • deadline：当前执行片的虚拟运行时间上限。当进程的vruntime超过此值，即成为上下文切换的候选者。这是CFS（完全公平调度器）的核心机制。
• 架构特定状态 (thread_struct)：
  • sp (栈指针)：在上下文切换时保存和恢复CPU的栈指针寄存器（如x86-64的RSP）。
  • 段寄存器 (es, ds, fsbase, gsbase)：需要保存和恢复。fs/gs寄存器在用户空间用于实现线程本地存储（TLS），在内核空间用于实现per-CPU变量，确保多核环境下状态隔离。

二、进程的内存状态管理：mm_struct

进程执行需要内存来存放代码、数据和运行时信息。内核通过mm_struct来组织和管理进程的虚拟地址空间。

1. 虚拟内存基础

• 分页与地址转换：每个进程拥有独立的虚拟地址空间，由固定大小的“页”组成。CPU通过页表将虚拟地址转换为物理地址。页表的根目录地址（物理地址）存储在mm_struct的pgd字段中。
• 用户/内核页表：类似于栈，进程通常有独立的用户态和内核态页表。在用户态与内核态转换时，需要切换页表。引入独立的内核页表是为缓解Spectre/Meltdown等硬件漏洞的安全措施。

2. 内存布局

进程的地址空间包含多个逻辑段：

• 栈段 (start_stack)：用户态栈，用于函数局部变量管理，可动态增长。
• 代码段 (start_code, end_code)：存放可执行指令，页面权限为只读和可执行。多个进程运行同一程序时可共享此段。
• 数据段 (start_data, end_data)：存放非零初始化的全局和静态变量。
• BSS段：存放零初始化或未初始化的全局/静态变量。
• 堆区域：用于动态内存分配（如malloc），初始为空。

3. TLB管理 (mm_context_t)

• TLB：地址转换后备缓冲器，缓存最近使用的虚拟地址到物理地址的映射，以加速访问。
• 地址空间标识符 (ctx_id 和 ASID)：每个进程地址空间有一个唯一ID（ctx_id）和一个12位的伪唯一ASID。硬件使用ASID来标记TLB条目，使得切换进程时无需总是刷新TLB，提升了性能。当ASID耗尽被回收后，进程恢复时若使用新ASID，则需刷新TLB。
• TLB代数 (tlb_gen)：一个代数计数器。当内核修改页表映射时，会递增此值。CPU切换到某进程时，会比较自己记录的tlb_gen与mm_struct中的当前值，若不一致则必须刷新TLB，以确保不使用过时的翻译。

总结

Linux内核通过**task_struct（跟踪执行状态、调度信息、CPU状态）和mm_struct**（管理虚拟地址空间、页表、内存段、TLB元数据）这两个核心数据结构来完整地表示一个进程。上下文切换的本质就是操纵这两个结构体，以实现CPU控制权在进程间的转移。在下一篇文章中，将探讨CPU如何从用户态过渡到内核态，以及这些数据结构在该过程中的作用。

网页验证机制摘要

目的：该HTML页面是一个用于验证用户是否为人类的机制，通过proof-of-work挑战来防止自动化访问，可能用于网站访问控制或安全防护。

结构：

• HTML结构：页面包含标题"Are we human?"，主体部分有一个div元素，带有类"wicketkeeper"，用于显示验证组件，支持自定义输入和回调。
• CSS样式：采用响应式设计，根据不同屏幕尺寸（如桌面、平板、手机）调整验证组件的宽度、高度和字体大小，确保用户体验。
• JavaScript功能：包括外部脚本slow.js和内联脚本，内联脚本定义了solved函数，用于处理挑战解决后的逻辑。

关键功能：

• 验证流程：当用户完成proof-of-work挑战时，solved函数被调用，收集nonce、token和result数据。
• 服务器通信：函数通过fetch API向服务器端点/_labrador/pow/v0/verify发送GET请求，携带验证数据。
• 成功处理：如果服务器返回200状态码，页面在500毫秒后自动重新加载，表示验证通过；否则验证失败。

Gource 是一款开源的软件版本控制可视化工具，能够将代码仓库的历史以动态树形图的形式直观呈现。它以仓库根目录为中心，目录为分支，文件为树叶，代码贡献者以头像形式出现和消失，反映其活动轨迹。

核心功能与要求

• 渲染方式：基于 OpenGL，需配备 3D 加速显卡。
• 支持系统：可解析 Git、SVN、Mercurial、Bazaar 等版本控制系统的日志，也支持自定义格式或从标准输入读取。
• 主要用途：可视化代码变更历史，展示文件与用户的交互模式，支持录制视频或生成动画流。

关键命令选项

• 显示控制：可设置视口大小、全屏模式、背景颜色/图片、字体样式等。
• 时间与播放：通过 --seconds-per-day、--start-date、--stop-date 等调整时间轴速度与范围，支持暂停、循环播放。
• 内容过滤：可按文件名、目录名或用户名正则表达式过滤显示内容。
• 输出支持：可输出 PPM 图像流或自定义格式日志，便于后期处理。
• 交互控制：运行时可通过键盘快捷键调整视图、切换显示元素（如目录名、文件名、用户头像）。

使用示例

• 直接查看当前目录日志：gource
• 生成并使用日志文件：先通过 --log-command 导出日志，再用 gource <日志文件> 播放。
• 自定义日志格式：支持以管道分隔的文本输入，包含时间戳、用户名、操作类型、文件路径和可选颜色。

交互界面

• 空格键暂停/恢复，鼠标点击或拖动可查看细节、旋转视图。
• 快捷键可快速切换显示模式、调整播放速度或截图。

许可信息

• Gource 遵循 GNU 通用公共许可证 v3 发布。

中国计划于2025年在戈壁沙漠建造一座示范性钍基熔盐反应堆，这是在中断半个多世纪后钍燃料重返核能研究前沿的标志。该项目由中国科学院上海应用物理研究所管理，是一座10兆瓦的反应堆，预计2030年投入运行。此前，中国已于2021年完成并运行了一座2兆瓦的实验性熔盐反应堆，使中国在钍燃料增殖和熔盐反应堆技术上处于全球领先地位。

钍-232在地壳中的储量比常用的核燃料铀-235更丰富，但本身不可裂变，需先转化为可裂变的铀-233。熔盐增殖堆被认为是实现钍燃料利用最可行的设计：反应堆核心中，钍氟化物溶解在熔盐里，通过中子辐照将钍-232转化为铀-233并裂变产热，进而驱动涡轮发电。该项目的核心反应堆高3米，直径2.8米，运行温度700°C，热功率60兆瓦，发电功率10兆瓦。

中国发展钍基熔盐堆有多重动机。一方面，钍燃料有助于减少对进口铀的依赖，提升能源自给能力；另一方面，钍是中国庞大稀土采矿业的副产品，可提供近乎无穷的燃料供应。甘肃省已着眼于未来将该技术用于海事和航空航天领域。

然而，钍燃料面临显著挑战，尤其是核扩散风险。铀-233与钚类似，可直接用于核武器制造，而在运行期间循环进出堆芯的燃料可能增加铀-233被盗的风险。为此，丹麦哥本哈根原子能公司计划通过焊接密封反应堆来降低风险；美国Clean Core Thorium Energy公司则开发了钍与高纯度低浓缩铀的混合燃料，声称此类燃料无法用于武器。

全球范围内，多数熔盐反应堆项目短期内仍以铀或铀混合物为燃料，例如美国德克萨斯州的1兆瓦液态熔盐堆和田纳西州的氟化盐冷却高温堆。不过，中国并非唯一探索钍燃料的国家，印度、日本、英国和美国等也曾表示兴趣。尽管存在技术和政治障碍，钍燃料与熔盐反应堆研究已重新成为核能领域的重要方向。

Shmøergh Hog：一款简单模拟合成器的制作历程

设计理念与背景

Shmøergh Hog是一款为现场演出设计的模拟合成器，核心理念是"通过有意识的限制提供杀手级音效和极易操作性"，与当今追求"无限可能性"的合成器设计形成对比。其开发源于用户在使用原型机时发现切换可用音色过于繁琐耗时。该合成器由品牌Shmøergh的两位创始人——负责概念/视觉/电路的Peter和负责工业设计的Flame，在业余时间耗时两年开发而成。

主要特性概述

• 全模拟信号与控制电路
• 两个声部，支持三角波、锯齿波、方波
• 附加次谐波或噪声声部
• 声部1具备窄脉宽与可变脉宽
• 10八度精度，5八度开关
• 声部2支持±半八度及失谐
• 两个可选LFO用于自动哇音和颤音
• 可变调制路径的"游乐场"区域
• 自定义快速包络系统
• 滑音功能
• 可变门控模式（包络、门控、持续音）
• MIDI可升级
• 开源、可定制、可修改

开发过程与技术实现

1. 电路设计

• 基于经典的减法合成原理（振荡器产生丰富频率内容，经滤波器处理，再由压控工具塑形调制）。
• 灵感来源于Befaco模块和Moritz Klein的频道，但强调深入理解电路而非简单复制。
• 使用CircuitJS和LTSpice进行电路仿真与验证。
• 使用KiCad绘制原理图，并打印作为搭建原型的蓝图。
• 在面包板上逐一搭建并测试各模块，验证其可行性。

2. PCB设计策略演变

• 早期版本：采用模块化设计，每个模块独立PCB，类似预制接线的Eurorack系统。使用自制感光板蚀刻电路，但连接各模块的线缆繁杂且易受噪声干扰，每块板设计和制作耗时约3个月。
• 最终版本：为实现更快组装和更强稳健性，重新设计为接近单板方案，拆分为四个主要电路板：
  1. 电源板：独立以确保未来灵活性。
  2. 核心板：集成除滤波器外的所有核心模块，90%元件采用表面贴装并由JLCPCB进行PCBA。
  3. UI板：承载前面板的开关、旋钮、LED等界面元件，与核心板分离以便未来实现完全不同的交互概念。
  4. 滤波器板：独立设计，因其对最终音色至关重要（占80%），便于未来探索不同滤波器架构。
• 电路中加入了大量微调电位器，允许几乎调整合成器的所有声音参数，以实现每个用户的个性化定制。

3. 外壳设计与制造

• 原型：使用宜家金属花盆作为外壳，不仅美观，还能起到法拉第笼的作用，保护敏感电路。
• 探索性原型：尝试将相同电子元件放入不同盒子，但过程未显著简化。
• 最终定制外壳：
  • 采用不锈钢板（1mm厚），基于10x10mm网格设计，尺寸约为A4纸大小。
  • 结构由两个互补的U形上下部分组成，由Flame使用FreeCad设计。
  • 外观图形由Peter设计，追求统一感但每台合成器略有不同，以保证独特性。
  • 首批5台使用简单几何图形和基本色彩。
  • 外壳经过粉末喷涂（黑白）并使用UV打印图形，后覆以多层丙烯酸漆以提高耐磨性。

生产计划与未来展望

• 不追求大规模量产：认为量产涉及巨大的资金投入和分散精力的非设计工作（营销、销售、支持、合规等），且会破坏每台乐器独特的定制化理念。
• 当前计划：以工匠模式小批量生产，为少数朋友和感兴趣的用户手工打造独特的Hog合成器。
• 开源共享：完整的Hog设计已作为构建指南在shmoergh.com上公开。

与Linux初始Git提交SHA前缀的碰撞

问题背景

Linux内核中的“Fixes”标签传统上使用12字符的Git提交SHA前缀。随着提交数量增长，12字符前缀碰撞的概率持续增加，目前已存在11字符前缀碰撞的案例。有建议将最小前缀长度增至16字符，但遭到了一些反对意见。

现状与测试

作者Kees Cook认为这并非“未来可能出现”的理论问题，因此通过碰撞生成工具故意创建了一个与Linux内核第一个提交（1da177e4c3f4，即“Linux-2.6.12-rc2”）具有相同12字符前缀的新提交。该初始提交在“Fixes”标签中被频繁引用（约590次）。

工具缺陷暴露

许多自动化工具（如linux-next的“Fixes标签检查器”、Linux CNA的提交解析脚本以及CVE生命周期分析工具）在程序化解析“Fixes”标签时，并未考虑前缀碰撞的可能性。新创建的碰撞提交导致这些工具失效：

$ git show 1da177e4c3f4
error: short object ID 1da177e4c3f4 is ambiguous
hint: The candidates are:
hint:   1da177e4c3f41 commit 2005-04-16 - Linux-2.6.12-rc2
hint:   1da177e4c3f47 commit 2024-12-14 - docs: git SHA prefixes are for humans

实施细节

• 碰撞生成利用了lucky-commit项目，通过调整提交消息的尾部空白字符来寻找碰撞。
• 在配备OpenCL支持的RTX 3080 GPU上，生成12字符前缀碰撞耗时约6小时。
• 该碰撞提交（1da177e4c3f47）目前未合并到Linux上游代码库，以免破坏外部工具，但可作为测试用例供开发者提前修复解析逻辑。

意义

此次实践旨在证明前缀碰撞已是现实威胁，推动相关工具增强对碰撞情况的处理能力，为未来更长前缀或更复杂的碰撞场景做好准备。

Dog Aging Project（狗衰老项目）概述

Dog Aging Project 是一项大规模的长期研究，旨在理解基因、生活方式和环境如何影响狗的健康与衰老。该项目由美国国立卫生研究院（NIH）等机构资助，已招募超过 50,000 只来自全美各州的狗，涵盖不同品种、年龄和健康状况。其核心目标是通过收集和分析数据，为狗和人类的健康衰老做出科学发现。

主要研究领域与方法 项目的研究涵盖六个关键领域：

1. 健康：通过主人调查、兽医医疗记录和虚弱评估收集综合健康与饮食数据。
2. 遗传学：为部分队列的狗进行免费DNA测序，用于全基因组关联研究。
3. 环境：收集与狗共同生活环境的数据，包括家庭及居住地邮编对应的环境信息。
4. 生活方式：了解伴侣犬、工作犬等不同生活方式与健康、衰老的关系。
5. 认知：研究犬类认知衰退，类似于人类的阿尔茨海默病。
6. 活动：通过调查、家庭活动和可穿戴设备量化活动水平与健康指标的联系。

项目会从“狗群”中筛选出特定队列进行深入研究，包括基因组学研究的“基础队列”、生物化学研究的“精密队列”以及临床试验的“TRIAD队列”。

关键科学发现 近年来，项目研究团队发表了多项成果：

1. 共享的死亡率生物标志物：研究发现，狗和人类血液中预测死亡风险的代谢物高度重叠。这意味着两者具有相似的生物衰老模式，而且这些模式在狗身上仅需2-3年就能观察到，在人类则需要8-28年，表明狗是研究人类衰老的极佳模型。肾脏健康是其中的关键因素。
2. 血液中的蛋白质分解产物作为衰老标志：一项对“精密队列”约800只狗的血液分析发现，一种称为“翻译后修饰氨基酸”的蛋白质分解产物随狗年龄增长而增加，且不受饮食影响。其水平变化在很大程度上由肾功能介导。
3. CBD（大麻二酚）的使用模式与影响：对约47,000只狗的调查显示，约5-7%的狗使用了CBD产品，主要针对关节炎、癌症、癫痫等健康问题。长期使用CBD的狗，其攻击性行为随时间有所减轻，但需进一步研究证实其因果关系和安全性。
4. TRIAD临床试验：这是一项针对中年健康狗的双盲、安慰剂对照、多中心试验，旨在测试药物雷帕霉素是否能延长健康寿命、改善心脏健康和认知功能。该试验仍在招募参与者。

临床试验参与者体验 参与TRIAD试验的狗主人分享了他们的经历。他们普遍看重提升爱犬的生活质量与寿命。试验过程包括在合作兽医学院进行定期检查、血液检测和认知游戏。参与者表示，全面的筛查帮助他们发现了宠物未察觉的健康问题（如高血压、心脏杂音），并增进了与宠物的感情。尽管有些狗在试验后离世，但主人认为参与研究为它们留下了宝贵遗产。

项目规模与参与 项目已汇聚了庞大的数据和资源：超过 22,000 只纯种狗和 22,000 只混血狗参与，代表了超过 300 个AKC品种和 3,500 种混血组合。超过 200 名研究人员正在使用这些数据，并已产生 50 余篇研究出版物。主人可以通过完成年度调查、提供兽医记录等方式参与，并加入专属的“狗公园”在线社区。

总之，Dog Aging Project 通过其庞大的社区科学模式，正不断揭示狗衰老的生物学机制，其发现不仅有望改善伴侣犬的健康护理，也为理解人类衰老提供了重要见解。

文章核心观点

文章主张在单元测试中，应避免过度依赖数据库调用模拟，而应更多地采用真实数据库进行测试。虽然模拟更快、更简单，但真实数据库测试能提前暴露许多隐藏问题，从而提升应用健壮性并节省后期调试成本。

关键论据与示例

1. 揭示隐藏问题：模拟测试可能忽略唯一性约束、默认值处理、数据完整性及性能瓶颈。例如，创建用户的测试中，真实数据库方案能确保数据正确持久化并验证默认值，而模拟方案仅验证方法调用。

2. 未来兼容性：随着功能迭代和数据库模式变更（如新增验证、数据类型修改），模拟测试无法检测这些变化带来的兼容性问题。真实数据库测试能及时捕获此类错误。

3. 维护现实数据状态：在涉及账户余额、交易汇总等计算时，真实数据库测试能暴露并发、隔离及聚合计算问题，保证数据一致性。

4. 分层测试策略：

   • 数据访问层：必须使用真实数据库测试，以验证外键、引用完整性和数据库事务。
   • 服务层：推荐使用真实数据库测试，以验证业务逻辑与数据交互。
   • 控制器层：可以模拟服务调用，专注于参数处理和响应测试。
   • 用例/交互层：可以模拟其所编排的下级服务，以隔离逻辑错误。

结论

应在测试中平衡真实数据库测试与模拟测试。对于仓库方法、复杂数据关系和性能敏感场景，真实数据库测试至关重要。而对于高层编排逻辑和外部服务交互，模拟测试仍有其价值。关键在于针对不同测试层级采用合适的策略，确保测试既高效又能全面覆盖潜在风险。

美国陆军士兵因涉嫌参与AT&T、Verizon勒索案被捕

核心事件

美国联邦当局逮捕并起诉了一名20岁的美国陆军士兵，卡梅伦·约翰·瓦格纽斯。他被怀疑是网络犯罪分子“Kiberphant0m”，涉嫌在2024年早些时候窃取并泄露AT&T和Verizon的敏感客户通话记录。

案件细节

• 逮捕与指控：瓦格纽斯于12月20日在德克萨斯州胡德堡陆军基地附近被捕，被指控两项非法转移机密电话记录的罪名。
• 犯罪身份：他被指控使用的网络身份“Kiberphant0m”，是一名活跃的网络罪犯，曾声称入侵了包括AT&T和Verizon在内的至少15家电信公司。
• 军事背景：瓦格纽斯是一名通信专家，此前驻扎在韩国。其母亲证实他负责处理无线电信号和网络通信工作。

犯罪活动与威胁

• 关联犯罪分子：调查发现，瓦格纽斯与另一名已被捕的加拿大网络罪犯“Judische”（本名康纳·赖利·穆卡）有关联。Judische主要窃取存储在Snowflake云服务中的公司数据，并将倒卖工作外包给Kiberphant0m等人。
• 具体威胁与泄露：
  • 在Judische被捕后，Kiberphant0m在黑客论坛BreachForums上威胁AT&T，声称拥有当选总统特朗普和副总统哈里斯的通话记录，并威胁要泄露。
  • 他还发布过据称是从AT&T窃取的美国国家安全局的“数据模式”。
  • 在另一事件中，他提供从Verizon“即按即说”服务窃取的通话记录，该服务客户包括美国政府机构和应急响应人员。
  • 他还提供针对Verizon客户的“SIM卡交换”欺诈服务。
• 其他非法活动：据报道，Kiberphant0m曾运营用于DDoS攻击的大型僵尸网络，并在2023年出售过一家美国大型国防承包商的远程访问凭据。

调查与关联

• 网络安全公司Unit 221B的首席研究官艾莉森·尼克松协助追踪到了Kiberphant0m的真实身份。
• 调查显示，执法部门从11月10日发现其操作安全失误，到12月6日其最后一次Telegram活动，再到12月20日完成逮捕，整个过程非常迅速。尼克松称这是她职业生涯中见过的美国联邦网络案件最快办案速度。
• 瓦格纽斯的母亲表示，对儿子涉及黑客犯罪感到震惊，并透露他和哥哥从小就向往参军。

案件后续

• 针对瓦格纽斯的起诉书已在德克萨斯州提交，但案件已被移交至华盛顿西区联邦地区法院。
• 尼克松借此案警告其他网络犯罪分子，尤其是年轻人：停止愚蠢的行为并寻求律师帮助，因为执法部门正致力于将他们长期投入监狱。

文章摘要：Linux为何尚未准备好进入桌面领域

本文从普通用户（而非IT专业人士）的视角出发，系统阐述了Linux发行版在桌面环境中存在的根本性问题。作者认为，除非投入巨额资金进行改造，否则这些问题难以解决。

核心问题

1. 兼容性碎片化：与Windows或Android不同，Linux各发行版之间软件兼容性差，旧软件在新系统上常无法运行。尽管存在Flatpak、Snap等方案，但作者认为它们实为“轻量级虚拟机”，治标不治本，且增加了系统资源开销。每个发行版实质上是一个独立的操作系统。
2. 质量与稳定性堪忧：Linux开发处于不断变动中，回归错误频发。由于开发者缺乏对所有硬件的测试条件，系统更新常引入新问题。
3. 内核与驱动模型：Linux采用宏内核，驱动与内核捆绑。这意味着更新驱动可能需更新整个内核，而新内核可能带来不稳定，用户无法像在Windows中那样灵活地单独管理驱动程序。
4. 软件与游戏生态薄弱：绝大多数桌面软件和AAA游戏仅针对Windows开发。Linux缺乏原生支持，依赖Wine等兼容层运行Windows程序，但兼容性、性能和稳定性均无法保证。特别是需要内核级反作弊的在线游戏，在Linux上基本无法运行。
5. 图形子系统混乱：作者严厉批评了当前的Wayland显示协议。他认为Wayland缺乏统一标准，各桌面环境（如KDE、GNOME）实现不一致，导致功能缺失（如截屏、屏幕投射）。与Xorg不同，Wayland不提供标准渲染API，使得旧应用程序无法维护。Wayland加剧了Linux桌面生态的碎片化。
6. 其他系统性缺陷：
   • 本地网络共享：缺乏像Windows那样简单易用的文件共享解决方案，配置Samba或使用NFS等工具对普通用户极为复杂。
   • 资源投入不足：Linux在服务器领域资金充足，但在桌面端严重缺乏资助，导致音频、视频等子系统的漏洞修复迟缓，维护人员匮乏。
   • 硬件支持：新硬件（如特定笔记本的Wi-Fi、摄像头）在Linux上可能无法立即工作，依赖内核版本，且OEM厂商投入的Linux驱动开发资源远少于Windows。
   • 安全模型复杂：桌面Linux的安全常依赖于用户的专业知识（如正确使用sudo、设置权限），缺乏强大的本地杀毒软件，且Secure Boot与第三方驱动的兼容性常给用户带来困扰。
   • 软件更新延迟：安全补丁和错误修复依赖发行版维护者打包推送，对于非流行软件，更新可能严重滞后。
   • 企业管理功能缺失：缺乏类似Windows GPO、活动目录的开箱即用、易于使用的集中管理工具。
   • 游戏体验不佳：即使通过兼容层运行游戏，性能通常低于Windows，缺乏强大的性能监控和超频工具，GPU驱动功能也远不及Windows版本丰富。
   • 社区态度：当用户遇到问题时，Linux社区有时会给出“你使用了错误的发行版/内核/硬件”等建议，而非积极解决问题。

结论

作者强调，尽管Linux可以作为网页浏览器使用，或适合技术爱好者，但对于不愿接触命令行、只求“安装即用”的普通桌面用户而言，它存在诸多根本性障碍。这些问题涉及软件兼容性、系统稳定性、硬件支持、安全模型、图形栈、企业管理和游戏生态等多个层面。

根据知名分析师郭明錤的预测，Apple计划在2025年推出M5系列芯片（包括M5、M5 Pro、M5 Max和M5 Ultra），采用台积电N3P工艺节点制造，并可能在高端型号（M5 Pro、M5 Max、M5 Ultra）上引入重大架构变化。

核心变化：采用SoIC-mH封装，分离CPU与GPU

• 高端M5芯片将采用台积电的2.5D SoIC-mH封装技术。这是一种服务器级封装方案。
• 该技术允许Apple将CPU和GPU设计进行物理分离，这可能导致放弃目前Apple Silicon标志性的统一内存架构。分离设计旨在改善芯片良率和散热表现。
• SoIC是台积电的3D堆叠技术版本，其中SoIC-mH属于2.5D技术，可能通过CoWoS或InFO封装水平连接芯片。

生产时间线

• M5系列预计于2025年上半年至下半年开始生产，其中顶级的M5 Ultra版本则要到2026年才开始投产。

潜在影响与考量

• 统一内存架构是Apple Silicon高性能和高能效的关键因素之一，放弃它是否能在实际应用中带来性能提升，同时不导致功耗显著增加，是值得观察的问题。
• 这种分离式设计可能有助于提升AI推理性能。苹果的私有云计算服务有望成为高端M5芯片的最大受益者。

当前Apple最新的MacBook Pro搭载的是M4 Pro和M4 Max芯片，它们使用台积电N3E工艺。M5系列的传闻表明Apple正在探索下一代的芯片封装与集成方式。

苹果iPhone 16音视频实验室探秘：每秒十亿像素的背后

消声室：精密校准麦克风

苹果在总部设有长波消声室，墙壁、天花板和悬空网格地板下均覆盖大型楔形泡沫，几乎消除所有回声。该实验室用于测试和校准iPhone 16的四个微型麦克风。工程师通过旋转放置手机的基座，播放一系列钟声音调，记录麦克风在不同角度的拾音数据，生成球形声音特性图谱。这些数据为空间音频、降风噪功能以及Audio Mix技术奠定基础，使手机麦克风能模拟领夹麦克风或录音棚麦克风的效果。

Audio Mix：机器学习驱动的音频革新

• 技术挑战：手机麦克风体积小，无法物理靠近声源。苹果通过多年研发，结合机器学习算法和声学调校，使iPhone 16的麦克风能捕捉高品质声音。
• 功能特点：用户可在后期通过滑块调整视频音频，模拟领夹麦克风、摄影棚等效果，而无需专业设备。
• 测试验证：苹果通过感知音频测试，让多人对比评估不同音频轨道（如带风噪与降风噪版本），确保功能体验符合大众预期。

视频验证实验室：影院级画质校准

实验室配备杜比全景声影院级巨幕，用于校准iPhone视频在不同环境（暗光、办公室、户外阳光）下的回放效果。工程师通过环境光传感器自适应调节画面，并结合专家团的集体反馈优化画质。实验室还重点测试4K 120fps慢动作视频——每秒处理近10亿像素数据，确保降速播放时画面细节无失真。

核心技术与设计哲学

• 硬件基础：iPhone 16 Pro的麦克风采用新型元件，平衡尺寸与音质。
• 系统整合：音频与视频功能深度整合，如空间音频与Audio Mix协同工作。
• 用户导向：所有技术创新最终服务于简化操作——默认设置即可输出优质音视频，同时为专业用户提供精细调节空间。
• 竞争定位：面对三星、谷歌在视频领域的追赶，苹果通过消声室、感知测试、影院级实验室等全方位投入，巩固其视频性能标杆地位。

苹果工程师强调：“表面简单的用户体验背后，是异常复杂的工程努力。”从实验室的精密设备到最终手机中的一键调节功能，体现了其“技术隐形化”的产品哲学。

Lightstorm: 极简 Ruby 编译器概要

Lightstorm 是一个为验证特定假设而构建的极简 Ruby 提前编译（AOT）编译器项目。它源自一个更完整（完成度约90%）的 Ruby 编译器，目标是使用最少功能来测试核心想法。

动机与背景

项目团队正在开发一个面向独立开发者的跨平台游戏引擎 DragonRuby，该引擎混合使用 C 和 Ruby 编写，其中 Ruby 是主要用户界面。在游戏开发完成、代码趋于静态后，团队希望预编译 Ruby 代码为机器码以提升运行速度。

核心假设

团队的核心假设是：通过预编译/展开（unrolling） mruby 虚拟机（VM）的分发循环，可以消除大量的堆加载/存储操作和分支指令（及相关的分支预测错误），从而提升最终程序的性能。

技术实现与架构

• 编译目标：与直接生成机器码的完整编译器不同，Lightstorm 以 C 语言为目标。这大大简化了对不同操作系统和CPU的支持。
• 利用 MLIR：项目使用 MLIR（Multi-Level Intermediate Representation） 框架来连接 Ruby 字节码与代码生成。具体流程如下：
  1. 复用 mruby 的现有前端（解析器和抽象语法树）和运行时库。
  2. 构建一个自定义的 MLIR 方言（Rite） 来表示 mruby 虚拟机的字节码。
  3. 通过一系列 MLIR 内置方言（如 cf, func, arith, emitc）将自定义方言的中间表示（IR）转换为 C 代码。
  4. 最后，使用 Clang 编译器将生成的 C 代码与现有的 mruby 运行时库一起编译链接。
• 简化与限制：为验证假设，项目放宽了部分约束，因此仅支持 Ruby 语言的一个子集（例如，暂不支持块和异常）。主要优势在于用仅数千行代码就实现了一个功能性的编译器。

性能测试与发现

团队在 Apple M1 CPU 上使用修改过的 aobench 基准测试（接近游戏开发工作负载）进行了测试，并与 mruby 的字节码解释执行进行了对比。

• 关键指标改善：
  • CPU 周期数和总执行时间：下降约 30%。
  • 分支指令数量：减少约 17%。
  • 加载/存储操作数量：减少约 28%。
  • 分支预测错误率：降低约 55%。

这些结果证实了其初始假设，即通过消除解释循环中的间接跳转和冗余内存访问，可以获得显著的性能提升。

未来计划与链接

团队计划将游戏引擎中因性能原因而用 C 编写的关键部分，尝试替换为使用此编译器生成的 Ruby 代码，以权衡性能与维护便捷性。

• 编译器源码：https://github.com/DragonRuby/lightstorm
• 游戏引擎：https://dragonruby.org

错误页面内容总结

该页面显示一个404错误，表示请求的文件未找到。主要信息包括：

• 错误原因：站点配置可能存在问题，如文件名大小写与URL不匹配，或文件权限设置不正确。
• 解决建议：对于根URL（如http://example.com/），需确保提供`index.html`文件。
• 参考资源：建议查阅GitHub Pages的完整文档以获取更多使用信息，并检查GitHub状态页面（@githubstatus）了解服务状态。

页面内容简短，未涉及文章标题“Performance of LLMs on Advent of Code 2024”的实际主题，仅作为错误提示页面。

文章总结：Elektročas HH3 —— 世界上最精准的摆钟

项目背景与钟表来源

作者是钟表爱好者，于2021年底获得了一台Elektročas HH3主钟。该钟原本用于科研机构和实验室，设计精度约为每天0.1秒。钟表获得时状况不佳，外壳有水渍损坏，机芯积油。经专业钟表维修店彻底清洁、调整后恢复运行。

精度提升的核心想法

作者希望将HH3的摆钟与CERN实验室中由铯原子钟驯服的主动氢脉泽进行同步锁定，以实现远超其原设计的精度（目标是1.58亿年内误差不超过1秒）。

实现高精度同步的方法

作者摒弃了多种传统调节方式（如改变重力、温控），最终选择通过改变钟摆长度来调节周期。具体方法是通过在摆杆上添加配重，以改变摆锤的质心位置。

创新发明：链控振荡器

为了机械地、可控地实现配重调节，作者提出了链控振荡器概念。使用一条细链条作为可控配重，通过改变链条在摆杆上的悬挂长度（即参与摆动的质量部分）来线性、模拟地微调钟摆周期。

系统构建与控制

• 锁相环系统：利用光学传感器和32位计数器测量摆钟周期，计数来自氢脉泽的10MHz时钟脉冲。微控制器计算瞬时周期误差，并控制链控振荡器进行调节。
• 系统特性：通过阶跃响应测试了CCO的增益和系统的动态特性。

成果与验证

• 首次闭环成功：系统成功锁定，并能补偿频率偏移和施加的阶跃扰动。
• 地震检测：2023年2月，处于锁定状态的钟检测到了土耳其大地震引起的扰动，并能自动恢复。
• 性能比较：初步的阿伦方差比较显示，锁定后的钟表稳定性显著优于自由运行状态。
• 当前状态：截至文章写作时（2023年2月），系统已稳定锁定运行超过两周。

未来工作

当前锁相环仅控制频率（钟摆周期）。作者计划开发更复杂的控制器，以同时控制时间，确保从现在到1.58亿年后的累积时间误差也不超过1秒。

技术要点总结

1. 核心原理：利用摆钟周期公式，通过机械方式改变摆长来进行频率微调。
2. 关键创新：链控振荡器，以链条作为可控模拟配重，实现了非接触、线性的精密调节。
3. 同步源：CERN的铯原子钟驯服的主动氢脉泽，提供超高精度的10MHz频率参考。
4. 控制架构：基于光学传感和微控制器的锁相环。
5. 主要成果：实现了摆钟与原子钟的长期稳定同步，并展示了其对外部扰动（如地震）的敏感性及恢复能力。

RWKV（发音为RwaKuv）是一种结合了循环神经网络（RNN）与大型语言模型（LLM）高性能的架构，同时具备类似Transformer的可并行化特性。其最新版本RWKV-7 "Goose"专注于推理能力。

核心特点与优势 RWKV融合了RNN与Transformer的优点，具有以下特性：

• 高性能：在语言建模任务上表现优异。
• 高效计算：时间复杂度为线性，空间复杂度为常数（无需KV缓存），训练速度快。
• 无限上下文：理论上支持无限长度的上下文。
• 免费文本嵌入：提供无额外成本的文本嵌入功能。
• 完全无注意力：100%不依赖注意力机制。
• 开源与基金会支持：是一个Linux基金会AI项目。

生态系统与项目 围绕RWKV已形成丰富的生态系统，主要项目包括：

• 核心开发：RWKV-LM 用于训练RWKV模型及跟踪最新进展。
• 应用与推理：
  • RWKV App：适用于Android、iOS、PC、Mac和Linux的应用程序。
  • Albatross：高效推理引擎，可在5090上实现7B模型fp16精度下960批大小每秒10250+ token的吞吐。
  • RWKV-Runner：提供图形界面和API的桌面应用。
  • RWKV-server：支持WebGPU（NVIDIA/AMD/Intel）推理，兼容nf4、int8、fp16格式。
• 微调与工具：
  • RWKV-PEFT：参数高效微调方案，仅需9GB显存即可微调7B模型。
  • RWKV pip package：官方Python参考包（性能较慢）。
• 更多资源：已拥有600多个相关项目。

获取与使用

• 模型权重：提供RWKV-7最新权重、GGUF格式权重以及适配Ollama的GGUF权重。
• 知识与文档：
  • 可查阅RWKV wiki了解从v1到v7的版本历史（由AI编写）。
  • 相关论文已列出，包括对RWKV-7、RWKV-6的图解说明以及RWKV-8的解析。

类型是软件设计的基本工具（2018）

软件设计的核心在于类型而非函数细节。函数作为抽象边界，其内部实现应被隔离，而设计关注的是移除函数体后剩余的内容——这些本质上都是类型信息，即使在动态语言中也是如此。

类型是设计的核心

• 缺乏全局状态时，函数仅通过类型签名表达其操作内容。
• 诸如“德米特定律”等规则旨在清晰界定函数实际作用的范围。
• 为事物命名是人类理解世界的方式，编程中命名的对象均与类型关联。

类型在不同编程范式中的角色

• UML 设计的重点是确定类型、类型关系及其命名。
• C 语言设计方法可称为“表示优先”，更关注数据结构的表示。
• 函数式编程传统（如 Standard ML、Haskell）强调类型优先设计，允许先定义函数类型再实现。

类型系统的演进与价值

• 早期类型主要用于性能优化，现代静态类型系统旨在增强设计表达和正确性。
• 参数化类型（如泛型）不仅提高代码复用性，还带来更强的正确性属性。
• 类型能帮助实现自动化重构，提高代码机器可理解性。
• Rust 的类型系统管理生命周期，将资源管理等设计决策编码到类型中。
• 依赖类型研究支持从类型自动生成代码实现，提升 IDE 支持能力。

总结 类型是程序设计的机器可读描述，不仅关乎正确性，更是理解设计的关键。即使在动态语言中，程序结构也围绕类型展开。更强的类型系统能更好地辅助设计、增强正确性并自动化部分实现工作。

文章主要介绍了作者将自己2004年用C++编写的PDA游戏《Darklaga Cannonball Symphony》用现代网页技术重制的过程，并详细阐述了其技术实现、设计约束与考量。

项目背景与约束

作者在2022年找到了游戏的原始源码，但由于依赖专有库已无法编译，决定将其作为业余项目重制。项目设定了两个核心约束：

1. 技术长期性：仅使用预计在20年后（2044年）仍存在且向后兼容的技术。
2. 轻量与便携性：游戏应下载快、安装简单，支持尽可能多的开放平台。

技术实现与优化

重制版是一个网页游戏，核心文件仅有两个：

• darklaga.html：主页文件。
• darklaga.bin：包含所有资源（JavaScript代码、精灵图、音效）的二进制数据包。

关键技术与优化细节：

• 运行时依赖：主要依赖WebGL 1.0（2011年标准）进行渲染，确保广泛支持。全屏和音频权限非必需，遵循用户首次交互后自动授予的模式。
• 极致的文件大小控制：整个游戏体积为1433 KiB（压缩后1042 KiB）。资源被精心打包进darklaga.bin，包括：
  • JavaScript代码（未压缩，以保障未来可读性与兼容性）。
  • 合并的纹理图集（1024x1024 PNG）。
  • 原始关卡数据（二进制格式）。
  • 压缩为MP3的音频资源（最大部分，584.99 KiB）。
• 零第三方请求：页面无广告、无跟踪代码、不依赖CDN，仅通过作者的Nginx服务器提供两个静态文件，并使用gzip_static预压缩优化传输。

长期兼容性策略

作者为确保项目在20年后仍可运行，做出了以下决策：

• 避免使用不稳定的JavaScript特性：仅使用基础语法、ArrayBuffer/类型数组和WebGL 1.0等被视为未来安全的特性。
• 杜绝第三方包依赖：不引入任何npm包，避免因包生态系统剧烈变动导致的不兼容风险。
• TypeScript的谨慎使用：虽然使用了TypeScript以获得类型安全，但刻意避免了需要复杂代码转换的特性（如enum、降级ES6以下语法），确保其主要通过简单的“类型注解剥离”即可转为纯JavaScript。作者认为，即使未来编译器不兼容，手动编写一个简单的剥离工具也是可行的。
• 模块打包方案：将约8000行的TypeScript代码分为27个模块，但最终编译为单个AMD格式的JavaScript文件。作者选择AMD而非ES Modules，是因为其转换逻辑简单、可在浏览器文件协议下运行，且易于在未来手动重新实现。

开发心得与彩蛋

作者分享了重制过程中的体验：

• 移植的轻松感：与原创设计不同，移植工作只需严格遵循已有规范（常量、布局、动画），无需猜测，因此更省力。
• 难忘的细节：文中提到了一个有趣的技术坑——AudioContext.decodeAudioData()会“分离”传入的缓冲区，这导致作者不得不对整体数据缓冲区进行克隆。他还回忆了2004年开发时听的音乐（Muse的《Absolution》）和受启发的游戏（如《怒首领蜂》、《东方永夜抄》等）。
• 邀请挑战：文末邀请玩家尝试游戏，并挑战“极限模式”。

总结

这是一个关于技术考古、现代Web技术实现以及为长远未来进行软件设计的深度案例。项目不仅成功复活了一个经典小游戏，更在轻量化、无依赖和长期可维护性方面做出了详尽且深思熟虑的实践。

《西部往事》中杰克·埃拉姆与苍蝇的场景分析

场景描述

在电影开场约六分钟时，角色“Snakey”（杰克·埃拉姆饰）坐在火车站门廊的摇椅上。他撕掉电报机线路后试图小憩，此时一只苍蝇落在他脖子上。他先试图吹走苍蝇，后用手挥开，随后用手枪将苍蝇捕入枪管。他用手指堵住枪口，将枪贴近耳朵聆听苍蝇嗡鸣，最后在火车进站时松开手指放走苍蝇。场景结尾引出了他与口琴客（查尔斯·布朗森饰）的经典对白及随后的枪战。

拍摄技术

该场景在西班牙拍摄。最初尝试使用假苍蝇效果不佳，后改为在埃拉姆胡须上涂抹蜂蜜或果酱，吸引从镜头外容器中放出的真苍蝇，从而完成了这一镜头。

剧本创作与归属争议

• 创作过程：剧本由达里奥·阿根托、贝纳尔多·贝托鲁奇和塞尔吉奥·莱昂内共同撰写，但苍蝇场景的构思出现在后期塞尔吉奥·莱昂内与编剧塞尔焦·多纳蒂的头脑风暴会议中。
• 创意归属：多纳蒂在采访中明确表示该场景是他的创意，并强调其“莱昂内式”的讽刺感。但阿根托后来曾主张这是他的想法，多纳蒂对此进行了反驳。
• 剧本内容：相关剧本页（18-21页）详细描述了苍蝇的嗡鸣、埃拉姆的捕捉动作、倾听过程及火车汽笛声的叠加。

影评解读的两种主要方向

1. 情节功能性解读：认为苍蝇场景通过微型冲突预演了即将到来的枪战，增强了紧张感，并暗示了角色在更大对决中的命运。
2. 声音与音乐性解读：将苍蝇的嗡鸣与水滴声、指关节声、风车声、电报声等并置，视为影片开场声音蒙太奇的一部分，突出其音乐性特征。有评论家甚至将苍蝇喻为“歌唱家”，称其嗡鸣如“愤怒子弹的咏叹调”。

核心意义：对演员表演与导演风格的聚焦

文章作者提出，该场景的真正价值在于：

• 演员表演的展示：场景为杰克·埃拉姆提供了充分的面部特写机会，通过眼神、微笑和表情变化，突出其标志性的斜视眼和“反派气质”，实现了对演员银幕形象的致敬与戏仿。
• 导演风格的体现：场景契合了塞尔吉奥·莱昂内“手势与沉默的导演”的自我定位，通过无对白的视觉叙事，将日常动作转化为富有张力的电影时刻，体现了其“图像演说家”的特质。

结论

苍蝇场景不仅是技术上的巧妙设计，更成为影片开场段落中的标志性片段，通过聚焦于演员的表演与导演的视觉语言，超越了单纯的情节或声音设计功能，成为诠释《西部往事》艺术风格的经典例证。

文章内容分析摘要

目的

该HTML页面是一个Cloudflare安全挑战页面，用于网站访问控制。其主要目的是验证用户是否启用了JavaScript和cookies，以防止自动化机器人或恶意软件访问网站内容。原始文章（关于佛罗里达州法院对水污染权利的裁决）未显示，因Cloudflare的反爬虫机制拦截了请求。

结构

页面结构如下：

• HTML头部：包含元标签（如字符集、视口设置、内容安全策略），定义了资源加载规则（例如限制脚本来源仅限Cloudflare挑战平台）。
• 样式表：内联CSS用于页面布局，确保响应式设计。
• 主体内容：显示“稍等片刻...”标题和错误消息：“Enable JavaScript and cookies to continue”（启用JavaScript和cookies以继续）。
• 脚本：JavaScript代码处理Cloudflare挑战逻辑，包括参数传递、脚本加载和状态管理，用于用户验证。

关键功能

• 用户验证：通过执行Cloudflare的挑战脚本，检测用户环境是否支持JavaScript和cookies。
• 安全防护：作为网站防火墙的一部分，阻止未验证的访问，保护网站免受爬虫或DDoS攻击。
• 临时页面：用户需完成挑战后才能跳转到实际内容；页面元刷新设置为360秒，可能用于自动重试。

补充说明

• 原始文章标题“Floridians have no right to bodies of water 'free of pollution,' court rules”未在页面中出现，表明内容被安全层阻断。
• 页面技术细节突出，包括内容安全策略（CSP）、nonce值和Cloudflare参数，但无实际新闻文本。