是时候采用新嵌入式 Linux 构建系统了小团队开发难题或迎解决方案2026 年 6 月 11 日 · 战略,愿景过去 20 年开发者一直使用嵌入式 Linux 来开发产品。第一次尝试 OpenEmbeddedYocto 的前身时开发者感觉仿佛收到了一份大礼只需运行一条命令就能在 x86 工作站上构建出可启动的 ARM 镜像。但时代在变如今有了越来越多的组件包括硬件和软件还有了 AI 工具以及具备大量内存的强大处理器。小团队初创公司和生产中小批量联网产品的工业企业想做更大的事情却在整合所有组件的复杂性面前苦苦挣扎错过产品交付日期而且产品投入使用后维护这些系统也十分吃力。本文将探讨发生了哪些变化以及如何更高效地构建和维护嵌入式 Linux 系统。嵌入式系统的黄金时代当下正处于嵌入式系统工程的非凡时代拥有以下资源大量的 Linux 系统级模块SOM它们是工业产品理想的硬件构建模块。Zephyr一款用于在 MCU 平台上构建软件的优秀操作系统。成熟的工具编译器、构建系统等。大量可应用于这些系统的开源软件。快速且价格合理的原型制作PCB 组装、机械 3D 打印等。更多供应商将他们对 Linux 内核的支持贡献到上游。Yocto 强大的工具可用于构建镜像和系统的定制部分。所有这些资源对任何规模的公司来说都是可获取的。这有点像继承了一座豪宅开源为开发者提供了一座庞大的房子里面有许多自己永远无法建造的房间和功能为了保持竞争力必须在其中生活。问题在于没人给开发者维护这个地方的工具。除了开发者整合一切的能力没有什么能阻碍开发者。目前嵌入式 Linux 系统的构建方式嵌入式 Linux 构建系统解决了整合所有组件的问题现有的构建系统一直为开发者提供着良好的服务。Buildroot2001 年和 OpenEmbedded/Yocto2003 年如今已成为标准得到了大多数 SOC/SOM 供应商的支持有些团队也成功地在 Debian、Ubuntu 甚至 Arch如 Valve 在 Steam Deck 上的做法上进行产品交付。但情况正在发生变化……边缘设备开始表现得像云系统它们运行着日益复杂的软件栈频繁更新并且在整个生命周期内都可进行远程管理。长期的 LTS长期支持冻结和交叉编译模式已不再适用于这类新产品。一些软件已经超出了交叉编译模式的范畴。现代编程语言都有自己的包生态系统Python通过 NumPy 和 PyTorch 封装 C/C/CUDA、JavaScript链接到 C 库以及 vcpkg用于 C/C。其中大部分是为桌面/服务器编写的而非用于交叉编译。这就将交叉编译的负担完全压在了嵌入式开发者身上为数千个包维护配方也一直是 Yocto 社区的沉重负担。此外Yocto 在构建过程中会阻止网络访问因此语言包工具在没有复杂的 do_fetch 集成的情况下无法工作。这在必须控制每个源代码时很有用但对许多项目来说却是不必要的麻烦。在 Yocto 中从源代码构建所有内容意味着漫长的构建过程、大量的内存使用以及对强大工作站的需求。虽然有 各种尝试 使用 Debian 来构建嵌入式系统但没有一个能达到 Yocto 的工具水平和灵活性。而且供应商基于 4 年前的 Yocto 版本冻结的 BSP 使得集成现代软件变得十分困难。这样的问题还有很多但嵌入式 Linux 开发仍然困难重重。即使是有才华的团队也会遇到重大障碍因为这个问题本身就很复杂而且软件的构建难度也在不断增加。总结来说有三个方面发生了变化产品不断发展一些边缘设备现在表现得像云系统需要持续更新而不是多年冻结不变。某些领域的交叉编译变得更加困难特别是在 Python 和 Node.js 领域底层软件大多用 C/C 编写构建系统脆弱。不过像 Go 和 Zig 等语言的交叉编译正在变得更容易。旧的权衡仍然存在且更加明显从源代码构建Yocto速度慢且资源消耗大使用现成的发行版Debian则缺乏定制工具。旧的模式曾经很有效但真正的问题是它是否仍然适合正在开发的产品和所拥有的团队。小团队面临的问题不同而非问题更小开发者和很多开发产品的人交流过听到的信息始终一致。首先这仍然非常困难其次对大团队有效的方法并不总是适用于小团队。小团队和初创公司需要快速构建并交付产品。他们通常没有资源来维持多年的开发周期也没有专门的构建或平台工程师来创建复杂的构建基础设施并调试困难的构建问题。简单性和易于构建/部署通常比二进制可重现的构建或从源代码构建一切更为重要。为了利用新技术他们经常需要轻松部署最新的开源版本。这些团队通常会受到三个方面的阻碍供应商的 BSP 将他们锁定在旧版本的 Yocto 中调试周期令人沮丧关键组件无法构建以及反向移植所需组件的工作量巨大。大型组织可以聘请专门的专家并投入资源来解决这些问题但小组织则没有这样的优势。需要明确的是小团队并不等同于业余爱好者。这些通常是初创公司或中等规模100 到 1000 台生产的工业产品介于一次性的创客项目和大规模消费级生产之间。新的机遇Buildroot 和 OpenEmbedded 诞生于 ARM 计算机速度较慢的时代在强大的 x86 工作站上进行软件交叉编译是当时唯一可行的选择。当构建有限的基于 C/C 的应用程序时这些系统表现出色。然而近年来发生了一些变化应用开发转向现代语言如 Python、JS、Go、Rust、Zig 等。这些语言有自己的包生态系统、缓存机制等。构建系统的硬件情况发生了变化现在有了可用于构建的快速 ARM 计算机如 AWS Graviton、Hetzner CAX不再局限于 x86 工作站。AI 成为创建软件包括构建系统的强大工具。开发者可以利用这些变革因素重新思考联网产品的世界。关键的转变在于不仅要借鉴现代生态系统的 _技术_还要借鉴它们的 _流程_。当采用 Rust 或 Python 等语言却将其强制纳入旧的构建流程时就好比在铺好的道路上运行火车。真正的收获在于采用这些生态系统的构建、打包和缓存方式而不仅仅是它们的产出。现在开发者有机会重新思考嵌入式 Linux 构建系统。对开发者来说这变得很个人化。最近开发者意识到如果还要再做 20 年这个工作希望有不同的东西一个更适合开发者和客户实际要解决的问题的东西而不是与工具作斗争。所以开发者一直在进行实验。在过去的几个月里开发者一直在公开地构建这个系统的实际部分早期的结果令人鼓舞以前需要花一天时间与交叉编译作斗争的软件现在使用笔记本电脑和 CI 上的相同工具几分钟内就能从想法变为在目标硬件上运行。虽然还很粗糙处于早期阶段但足以让开发者相信这种方法值得探索。如果……如果能够更快地推向市场缩短从想法到产品可用的路径。能在几秒到几分钟内让想法在目标硬件上运行而不是几天或几周。无需交叉编译。利用现代语言生态系统Python、JavaScript、Rust、Go、Zig、pkgbuild 等。缓存构建结果避免重复构建软件。提供主流发行版预构建包的便利性同时具备 Yocto 的工具优势。小团队也能做更多事情整个团队包括 AI可以使用同一套工具无需专门的构建专家。为应用程序和系统软件提供统一的构建系统在笔记本电脑、云 CI 和构建农场使用相同的工具。易于人类和 AI 理解。包含与 AI 代理配合良好的工具。利用 AI 完成大部分底层工作。提供能明确指出问题的错误信息。让产品在实际使用中保持更新和可维护使用现代软件并在产品的整个生命周期内维护设备。轻松跟踪当前软件版本不受供应商 BSP 的限制。通过一致的工具在系统、应用程序和 CI 之间进行扩展。轻松将更新部署到已投入使用的设备上。这些问题看似普遍存在但对小团队的影响尤为严重因为这些团队很少有专门的资源来解决它们。这就是开发者在 下一代嵌入式 Linux 构建系统 中进行的实验。以下是这个工具让开发变得更轻松的一些例子Alpine、Debian 和 Ubuntu 都是受支持的基础发行版让开发者无需重新构建一切就能快速上手。集成 Python 和 JavaScript 原生包生态系统而不是与之对抗。提供一流的 AI 支持。终端用户界面TUI 速度快让开发者可以轻松监控运行情况并在需要时深入了解详细信息。一些关键功能仍在开发中如分布式缓存和远程构建运行器但这些很快就会实现。旧模式仍有其用武之地这并不意味着旧模式会消失或应该消失。对于深度嵌入式的受监管产品符合合规认证、二进制可重现、完全从源代码构建且有意多年冻结Yocto 经过了实战检验仍然是合适的工具。它能准确满足这些产品的需求并且做得很好。开发者以前也见过这种模式。Alpine Linux 并没有取代 Debian它满足了不同的需求提供最小化、适合容器的镜像。这两个发行版如今仍然存在服务于不同的设计需求。没有人将它们视为竞争关系它们只是为不同的工作而设计。这里也是同样的道理。使用现代语言构建的动态、联网且频繁更新的设备是不同的工作它们需要专门为此设计的工具。那么是时候了吗对于越来越多的实际团队和产品来说开发者认为答案是肯定的。[yoe]构建 是一个早期实验探索了这种可能性。它还处于 1.0 版本之前是开源开发的存在一些不完善的地方。这是一个赌注认为这个问题值得解决也是一个邀请邀请大家一起探索解决方案的形态。这取决于开发者开发产品的团队和支持它们的供应商。请提供反馈指出开发者遗漏了什么。亲自测试并告诉开发者使用情况。订阅 开发者的时事通讯。告诉供应商需要这样的工具。关注 GitHub 仓库。与可能感兴趣的人分享。贡献改进建议。资助开发或基础设施建设。许多小团队都需要这个工具这些小公司构成了全球经济的重要组成部分长尾效应。初创公司是创新的重要源泉。如果能形成一个可以利用现代 AI 工具的社区那么这一切就会实现。过去两个月的进展 证明了这是可行的。本页内容嵌入式系统的黄金时代目前嵌入式 Linux 系统的构建方式但情况正在发生变化……小团队面临的问题不同而非问题更小新的机遇如果……旧模式仍有其用武之地那么是时候了吗关注这个实验偶尔会发布关于进展、设计选择和有效方法的说明。无垃圾邮件可随时取消订阅。订阅[yoe] 下一代 * 2026 * Apache 2.0GitHub *讨论区 *博客 * RSS *infoyoebuild.org *Yoe 发行版
