当前位置：首页 > news >正文

嵌入式 Linux 构建系统旧貌换新颜，小团队开发难题或可解决？

news 2026/6/24 4:35:24

是时候采用新嵌入式 Linux 构建系统了？小团队开发难题或迎解决方案

2026 年 6 月 11 日 · 战略,愿景

过去 20 年，开发者一直使用嵌入式 Linux 来开发产品。第一次尝试 OpenEmbedded（Yocto 的前身）时，开发者感觉仿佛收到了一份大礼，只需运行一条命令，就能在 x86 工作站上构建出可启动的 ARM 镜像。但时代在变，如今有了越来越多的组件（包括硬件和软件），还有了 AI 工具，以及具备大量内存的强大处理器。小团队（初创公司和生产中小批量联网产品的工业企业）想做更大的事情，却在整合所有组件的复杂性面前苦苦挣扎，错过产品交付日期，而且产品投入使用后，维护这些系统也十分吃力。本文将探讨发生了哪些变化，以及如何更高效地构建和维护嵌入式 Linux 系统。

嵌入式系统的黄金时代

当下正处于嵌入式系统工程的非凡时代，拥有以下资源：

大量的 Linux 系统级模块（SOM），它们是工业产品理想的硬件构建模块。
Zephyr，一款用于在 MCU 平台上构建软件的优秀操作系统。
成熟的工具（编译器、构建系统等）。
大量可应用于这些系统的开源软件。
快速且价格合理的原型制作（PCB 组装、机械 3D 打印等）。
更多供应商将他们对 Linux 内核的支持贡献到上游。
Yocto 强大的工具，可用于构建镜像和系统的定制部分。

所有这些资源对任何规模的公司来说都是可获取的。这有点像继承了一座豪宅：开源为开发者提供了一座庞大的房子，里面有许多自己永远无法建造的房间和功能，为了保持竞争力，必须在其中生活。问题在于，没人给开发者维护这个地方的工具。除了开发者整合一切的能力，没有什么能阻碍开发者。

目前嵌入式 Linux 系统的构建方式

嵌入式 Linux 构建系统解决了整合所有组件的问题，现有的构建系统一直为开发者提供着良好的服务。Buildroot（2001 年）和 OpenEmbedded/Yocto（2003 年）如今已成为标准，得到了大多数 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 工具的社区，那么这一切就会实现。过去两个月的进展证明了这是可行的。