在当今由物联网(IOT)驱动的互联嵌入式设备市场中，开发中的大部分设备都是以某种形式的Linux为基础的。具有现成Linux发行版的低成本电路板的普及应用是这方面的关键驱动因素。而获取硬件，构建自定义代码，将设备连接到其他硬件外围设备和互联网中，以及使用商业云提供商进行设备管理从未如此简单。开发人员或开发团队可以快速构建新应用程序的原型，并将设备提供给潜在用户。这是一件好事，将产生许多有趣的新应用，但也产生了许多不良的应用。
在规划超出原型设计阶段的系统设计时，事情变得更加复杂。本文主要对开发和维护基本操作系统(OS)映像的机制进行阐述。有许多工具可以帮助解决这个问题，但在此不会讨论各种工具。这里感兴趣的是维持和增强这种形象的基本模式，以及它将如何使人们的生活变得更好或更糟。
生成这些映像有两种主要模型：
- Centralized Golden Master
- 分布式构建系统
这些类别反映了源代码管理(SCM)系统的驱动模型，在讨论操作系统映像时，许多关于集中式和分布式的论点都是适用的。
Centralized Golden Master
业余爱好者和制造商项目主要使用Centralized Golden Master方法来创建和维护应用程序映像。这一事实使该模型具有速度和熟悉度的优势，允许开发人员快速设置这样的系统并使其运行。这一速度来自于许多设备制造商为其现成的硬件提供固定映像的事实。例如，来自BeagleBone和Raspberry Pi等系列的主板提供即用型操作系统映像和闪存。依靠这些映像意味着只需点击几下鼠标即可启动并运行系统。这些映像通常基于许多设备开发人员已经使用的桌面发行版，例如Debian。多年使用Linux可以直接转移到嵌入式设计，包括包装实用程序基本保持相同的事实，而且对于设计人员来说，获得他们需要的额外软件包很简单。
这种方法有一些缺点。首先，Centralized Golden Master的映像通常是一个瓶颈，导致原型设计阶段后开发人员的工作效率下降，因为每个人都必须等待轮到他们访问***映像并进行更改。在供应链管理(SCM)领域，这种做法相当于具有单独文件锁定的集中式系统。只有具有锁定的开发人员才能处理任何给定的文件。
这种方法的第二个缺点是映像再现性。通常通过人工登录目标系统，使用本机包管理器安装包、配置应用程序和点文件，然后就地修改系统配置文件来管理。完成此过程后，将使用dd命令的实用程序或等效工具对磁盘进行映像，然后进行分发。
同样，这种方法会造成潜在问题。例如，基于网络的软件包源可能不再存在，并且供应商映像提供的基础软件可能会更改。脚本可以帮助缓解这些问题。但是，当对配置文件格式或供应商的基本软件包进行更改时，这些脚本往往很脆弱并且会中断。
这种开发模式产生的***一个问题是依赖第三方。如果硬件供应商的映像更改不适合企业的设计，则可能需要投入大量时间进行调整。
分布式构建系统
这种为应用程序创建和维护映像的方法依赖于与目标硬件分离的目标映像的生成。这里的开发人员工作流程类似于使用供应链管理(SCM)系统的标准软件开发;映像可以通过工具完全构建，每个开发人员都可以独立工作。通过编辑元数据文件(脚本、配方、配置文件等)对系统进行更改，然后重新运行工具以生成更新的映像。然后使用供应链管理(SCM)系统管理这些元数据文件。各个开发人员可以将***的更改合并到他们的工作副本中，以生成他们的开发映像。在这种情况下，开发人员可以避免相关的瓶颈。
然后，构建系统使用标准供应链管理(SCM)技术生成发布映像，以从所有开发人员处获取更改。
以这种方式工作可以增加开发团队的规模，而不会降低开发人员的工作效率。所有工程师都可以独立工作。此外，这种设置可确保企业的构建可以重现。使用标准供应链管理(SCM)工作流可以确保在未来的时间重新生成特定的构建，从而允许长期维护，即使上游提供程序不再可用。与使用分布式供应链管理(SCM)工具类似，还需要有其他策略来实现可重现的候选映像。各个开发人员拥有自己的源代码副本，并且可以构建自己的测试映像，但是为了正确的发布工作，开发团队需要建立合并和分支标准，并确保所有针对发布的更改最终合并到明确定义中。许多上游项目已经为这种发布策略定义了明确的流程(例如，使用* -stable和* -next分支)。
这种方法的主要缺点是缺乏熟悉度。例如，向映像添加包通常需要创建某种配方，然后更新定义，以便包二进制文件包含在映像中。这与登录到正在运行的系统时运行apt非常不同。这些系统的学习曲线可能令人生畏，但结果更具可预测性和可扩展性，在考虑大规模生产的产品设计时可能是更好的选择。
OpenEmbedded和Buildroot等专用构建系统使用此模型，如debootstrap和multistrap等发行版打包工具。而Isar、debos和ELBE等新工具也使用这个基本模型。这样的选择还有很多，为企业的设计学习一个或多个这些包是值得投资的。这些系统的长期可维护性和可重复性将允许企业生成可重现的构建、跟踪所有源代码，并消除企业对第三方提供商的依赖性，从而降低设计风险。
结论
需要明确的是，分布式模型确实遇到了与Golden Maste模型相同的一些问题，尤其是对第三方的依赖。这是使用由他人设计的系统的结果，除非企业选择自己完全采用的方法，而这种方法在开发和维护方面会带来巨大的成本。
对于原型设计和概念验证级别设计，以及由少数开发人员组成的团队，Golden Master模型可能是正确的选择，因为在此阶段的开发中存在时间和预算限制。对于小批量、高接触设计，这可能是一个可接受的权衡生产使用。
对于一般生产用途，团队规模可扩展性、映像再现性、开发人员生产力方面的好处大大超过了实现分布式模型的系统的学习曲线和开销。板卡和芯片供应商的支持也在这些系统中广泛使用，降低了使用它们进行开发的前期成本。对于企业推出的新产品，建议在认真考虑用于生成基本操作系统映像的模型的情况下启动设计。如果企业选择使用Golden Master模型进行原型设计以转移到分布式模型，需要确保在企业的计划中为此工作提供足够的时间;根据企业选择的具体工具以及要求的范围，以及企业的代码所依赖的软件包的开箱即用的可用性，其估算值会有很大差异。
