中秋节的这三天假期，仿佛只是一个短暂的序章，因为明天，国庆节就要来了。对于本博客而言，这是建立以来第一个国庆节，这无疑是一个值得被特别纪念的节点。国庆节的假期时长远超中秋，这必然意味着各地景区的热闹程度会达到一个全新的高度。然而，我观察到，仍有许多人似乎存在一种路径依赖，选择回到老家度过这个长假，这种选择本身就带着一种难以言喻的惯性。在这样的假期背景下，我回想起了过去一年中那些充满技术挑战和意外机遇的时刻，这些经历都与我的个人项目和技术探索紧密相连。回溯到去年这个时候，我记得我曾尝试在闲鱼上开设了一家店铺，这次店铺的开业恰好赶上了国庆节。

当时，我手头需要的 MacBook Air 2020 Intel 二手电脑才刚刚到货，我花了整整三天的时间，才完成了配置环境的准备工作，最终，在最后一天的仓促中，我还是决定启动了这家店铺。就在国庆节的第一天，我就接到了一个大订单。订单的主人非常乐意，他不仅谈好了价格 200 块钱，还提出了一个特别的疑问：他想了解某个特定的软件是如何进行编译的。因为我在店铺中宣传的服务内容涉及到 Gentoo，而那个项目本身也与 Gentoo 有关联，所以订单的主人主动找上了我。这个订单的背景相当复杂：源自英伟达的社区开源作业，最终编译出来的成品，是能够在英伟达嵌入式设备上运行的精简系统。

订单的主人告诉我，他无论如何都无法成功编译出来，他甚至在网上寻找过其他编译好的成品，但依然想弄清楚这个项目到底应该如何进行编译。当时的我的技术水平还相当死板和固执，我没有想到应该采用更现代化的方式，比如将任务配置到云端运行的 GitHub Actions 中。我选择的方式是直接在我的 RTX 游戏本上安装了 WSL 的 Ubuntu 子系统尝试进行编译 后来花费了大量的时间去反复折腾网络和环境配置，试图让这个复杂的编译过程顺利进行。尽管我投入了巨大的精力，依然没有完成那个任务。它让我深刻体会到了在面对大型、复杂的开源项目时，仅凭个人本地环境的局限性是多么的脆弱。

我当时完全没有意识到，解决这种问题，需要的不仅仅是强大的硬件，更是一种更高效、更流程化的协作机制。后来我参与了一个 GitHub 开源笔记项目的开发工作，在加入了该项目的协作群之后，我开始尝试为它编写 GitHub Actions 流程进行实战练习。通过这次经历，我才惊觉到，GitHub Actions 这种工具的便捷性和强大之处，是远超我最初想象的。我再次尝试进行编译，这一次，我得到了一个明确的反馈：确实是英伟达团队的项目本身存在问题，这玩意儿就是代码出了错。在 GitHub Actions 编译失败后，日志中提示了一个非常细微的错误，它指出问题出在脚本中的地区命令格式上。

我当时感到非常不可置信，一个如此大的公司所发布的开源项目，竟然会存在这种基础的错误。我心想，嵌入式系统需要地区设置做什么？难道它们不都是使用英文的吗？最终，我决定删掉那行地区相关的代码，令人意外的是，这竟然成功地产出了预期的结果。可惜的一点是，我当时不知道，如何打包上传这么大的文件；要是换作现在的我，应该是直接删除所有源代码，将结果压缩成包再上传到下一个阶段进行拆分，最后把这拆分好的压缩包，全部上传到发行版页面供客户下载。我早些时候折腾 Linux 的使用，用的就是英伟达的显卡，当时用着顶多能用的驱动，就知道了英伟达对开源的支持是多么敷衍。