便宜的物联网板的普及意味着它不仅会控制应用程序，还会控制整个软件平台。 那么，如何构建一个针对特定用途的交叉编译应用程序的自定义发行版呢？ 正如 Michael J. Hammel 在这里解释的那样，它并不像你想象的那么难。
为什么要定制？以前，许多嵌入式项目都使用现成的发行版，然后出于种种原因，再将它们剥离到只剩下基本的必需的东西。首先，移除不需要的包以减少占用的存储空间。在启动时，嵌入式系统一般不需要大量的存储空间以及可用存储空间。在嵌入式系统运行时，可能从非易失性内存中拷贝大量的操作系统文件到内存中。第二，移除用不到的包可以降低可能的攻击面。如果你不需要它们就没有必要把这些可能有漏洞的包挂在上面。最后，移除用不到包可以降低发行版管理的开销。如果在包之间有依赖关系，意味着任何一个包请求从上游更新，那么它们都必须保持同步。那样可能就会出现验证噩梦。
然而，从一个现有的发行版中去移除包并不像说的那样容易。移除一个包可能会打破与其它包保持的各种依赖关系，以及可能在上游的发行版管理中改变依赖。另外，由于一些包原生集成在引导或者运行时进程中，它们并不能轻易地简单地移除。所有这些都是项目之外的平台的管理，并且有可能会导致意外的开发延迟。
一个流行的选择是使用上游发行版供应商提供的构建工具去构建一个定制的发行版。无论是 Gentoo 还是 Debian 都提供这种自下而上的构建方式。这些构建工具中最为流行的可能是 Debian 的 debootstrap 实用程序。它取出预构建的核心组件并允许用户去精选出它们感兴趣的包来构建用户自己的平台。但是，debootstrap 最初仅在 x86 平台上可用，虽然，现在有了 ARM（也有可能会有其它的平台）选项。debootstrap 和 Gentoo 的 catalyst 仍然需要从本地项目中将依赖管理移除。
一些人认为让别人去管理平台软件（像 Android 一样）要比自己亲自管理容易的多。但是，那些发行版都是多用途的，当你在一个轻量级的、资源有限的物联网设备上使用它时，你可能会再三考虑从你手中被拿走的任何资源。
系统引导的基石一个定制的 Linux 发行版要求许多软件组件。其中第一个就是工具链toolchain。工具链是用于编译软件的一套工具集。包括（但不限于）一个编译器、链接器、二进制操作工具以及标准的 C 库。工具链是为一个特定的目标硬件设备专门构建的。如果一个构建在 x86 系统上的工具链想要用于树莓派，那么这个工具链就被称为交叉编译工具链。当在内存和存储都十分有限的小型嵌入式设备上工作时，最好是使用一个交叉编译工具链。需要注意的是，即便是使用像 JavaScript 这样的需要运行在特定平台的脚本语言为特定用途编写的应用程序，也需要使用交叉编译工具链编译。
图 1. 编译依赖和引导顺序
交叉编译工具链用于为目标硬件构建软件组件。需要的第一个组件是引导加载程序bootloader。当计算机主板加电之后，处理器（可能有差异，取决于设计）尝试去跳转到一个特定的内存位置去开始运行软件。那个内存位置就是保存引导加载程序的地方。硬件可能有内置的引导加载程序，它可能直接从它的存储位置或者可能在它运行前首先拷贝到内存中。也可能会有多个引导加载程序。例如，第一阶段的引导加载程序可能位于硬件的 NAND 或者 NOR 闪存中。它唯一的功能是设置硬件以便于执行第二阶段的引导加载程序——比如，存储在 SD 卡中的可以被加载并运行的引导加载程序。
引导加载程序能够从硬件中取得足够的信息，将 Linux 加载到内存中并跳转到正确的位置，将控制权有效地移交到 Linux。Linux 是一个操作系统。这意味着，在这种设计中，它除了监控硬件和向上层软件（也就是应用程序）提供服务外，它实际上什么都不做。Linux 内核 中通常是各种各样的固件块。那些预编译的软件对象，通常包含硬件平台使用的设备的专用 IP（知识资产）。当构建一个定制发行版时，在开始编译内核之前，它可能会要求获得一些 Linux 内核源代码树没有提供的必需的固件块。