Embedded Linux distributions: Yocto, Buildroot, Alpine, Ubuntu Core

An embedded Linux distribution is an assembly of a Linux kernel, a libc (glibc or musl), an init system and a Board Support Package (BSP) tailored to the target SoC. Three approaches dominate: Canonical's Ubuntu and Debian (rootfs of 500 MB or more, 5 to 10 years of Long-Term Support), Alpine Linux (50 MB, musl libc) and the Yocto Project, hosted by the Linux Foundation (custom image of 10 to 50 MB, full reproducibility).

This guide arbitrates between approaches based on your BSP, your Time To Boot (TTB) and your production lifetime. Reference links: Ubuntu, Debian, Alpine Linux, Yocto Project.

Linux dominates industrial embedded and IoT. The mainline Linux kernel supports every modern SoC. The Linux Foundation coordinates the LTS cycles. But the word "Linux" covers very different realities: from a generalist Ubuntu distribution with systemd to a custom Yocto image of a few megabytes, with Alpine Linux and its minimal init in between. If you are starting out in embedded, our article on the fundamentals of embedded software provides the necessary context. Each approach has its strengths and use cases.

At AESTECHNO, we have been designing embedded Linux systems for industrial products for more than 10 years. We build Board Support Packages (BSP) on Yocto for NXP and NVIDIA Jetson platforms. We also deploy standard distributions for prototyping and gateways. This article gives the keys to choosing the right approach. We cover the trade-offs around Real-Time Operating System (RTOS), Memory Management Unit (MMU) and Root File System (rootfs) you need to know.

Linux distributions with systemd: Ubuntu, Debian, Fedora, RHEL

A Linux distribution with systemd uses a complete init system that replaces SysVinit with a monolithic PID 1 managing services, sockets, devices and cgroups. According to Debian and according to Canonical, systemd handles, on Ubuntu, service startup, logging (journald), device management (udev) and network configuration.

This integration simplifies parallel boot, according to Red Hat, but increases the rootfs footprint beyond 300 MB according to Debian (debian.org). The mainline Linux kernel, as Linus Torvalds points out in LKML discussions, prescribes no specific init and tolerates systemd, OpenRC or BusyBox equally.

What systemd brings:

• Service management: parallel startup, dependencies, automatic restart, watchdog
• Centralised logging: journald replaces syslog with structured filtering
• Device management: integrated udev, predictable network naming rules
• Network configuration: networkd or NetworkManager, DNS resolution (resolved)
• Containers and sandboxing: native integration with cgroups v2, namespaces

Advantages for embedded:

• Familiarity for developers: identical environment to the development workstation
• Rich package ecosystem: apt (Debian/Ubuntu) gives access to thousands of libraries
• Long-term support: Ubuntu LTS (5 years standard, 10 years extended), RHEL (10 years)
• Fast development cycle: from concept to working prototype in a few days

Limits in an embedded context:

• Significant memory footprint: a minimal Debian install exceeds 500 MB
• Boot time: 5 to 30 seconds depending on configuration
• Wider attack surface: every additional service is a potential vector (see our guide on embedded systems cybersecurity)
• Update complexity: managing apt dependencies across a fleet of deployed devices
• Partial reproducibility: two identical builds do not necessarily produce the same image

Recommended use cases: IoT gateways, edge servers, HMI workstations, rapid prototyping, systems unconstrained in resources. Ubuntu LTS 22.04, released in 2024, offers 5 years of standard support. Ubuntu Pro extends the window to 10 years. Debian stable ships every 2 years with 3 years of freeze support and 2 additional years of LTS.

Linux distributions without systemd: Alpine, Void, Devuan, Gentoo

Distributions without systemd use alternative init systems: OpenRC, runit, s6 or SysVinit. According to Alpine (alpinelinux.org), these init systems prioritise simplicity and modularity. Each component does one thing, the system stays readable and auditable, and the memory footprint drops compared with general-purpose distributions. Alpine combines musl libc and BusyBox to produce a 5 MB rootfs base.

The alternatives to systemd:

• OpenRC (Alpine, Gentoo): shell scripts with dependency management, lightweight and proven
• runit (Void Linux): minimal service supervision, automatic restart
• s6: fine-grained supervision, designed for reliability, used in minimal Docker images
• SysVinit (Devuan): the historical Unix init, sequential but easy to understand

Advantages for embedded:

• Reduced footprint: a working Alpine image fits in 50 MB
• Fast boot: 2 to 5 seconds on modest hardware
• Minimal attack surface: Alpine uses musl libc and BusyBox, reducing exposed code
• Transparency: you understand what is running, no hidden "magic" inside a monolithic PID 1
• Container-friendly: Alpine is the most-used Docker base image in the world

Limits:

• More restricted package ecosystem (Alpine apk vs Debian apt)
• Smaller community: less documentation, fewer answers on forums
• Compatibility: some software assumes glibc and systemd (for example, certain monitoring agents)
• Manual service management: supervision must be configured by hand (no socket activation, etc.)

Recommended use cases: embedded containers, minimal appliances, products sensitive to security, resource-constrained systems. Alpine Linux accounts for 50% of Docker images published on Docker Hub. Alpine 3.19 consumes 28 MB of RAM minimum at boot. An OpenRC init delivers a measured 2.5 s boot on an i.MX 8M at 1.6 GHz.

Yocto Project: building your own Linux distribution

The Yocto Project is a custom Linux build system, not a distribution. According to Yocto (yoctoproject.org) and according to Linaro, it allows you to create Linux distributions fully tailored to the target hardware. Yocto relies on OpenEmbedded and the BitBake engine to generate reproducible images through cross-compilation. The engineer keeps full control over every package, every library and every configuration present in the final image. The project, hosted by the Linux Foundation, ships two releases per year with an LTS every two years (4 years of support). Yocto reproducibility allows, as Arm points out in its Cortex-A documentation, a Board Support Package (BSP) to be frozen on a given architecture for the entire product lifetime. A Yocto LTS build such as Kirkstone 4.0 receives, according to Foundries and according to Timesys, CVE patches for 4 to 6 years.

How Yocto works:

• Layers: modular architecture, BSP layer (hardware), distro layer (policies), application layer
• Recipes: declarative description of each software component (source, build, install)
• Integrated BSP: native support for NXP i.MX, TI Sitara, NVIDIA Jetson, Raspberry Pi processors and more
• Cross-compilation: build on a powerful x86 server, deploy on ARM/MIPS/RISC-V; the RISC-V architecture is gaining ground in industrial production and benefits from growing support in Yocto
• Choice of init system: systemd or SysVinit, depending on your needs

Advantages for embedded:

• Minimal footprint: a Yocto image can drop below 10 MB (core-image-minimal)
• Total reproducibility: same source = same binary image, essential for certification
• Long-term maintenance: you control the lifecycle, no dependency on a distribution vendor
• Native BSP integration: hardware layers stack cleanly on top of the Poky base
• Targeted security: no superfluous package, attack surface reduced to the strict minimum
• systemd or not: it is your choice, not the distribution's

Limits:

• Learning curve: BitBake, layers, classes - it takes time to invest
• Initial build time: several hours for the first complete compilation
• Requires dedicated expertise: maintaining a Yocto BSP demands specific skills
• No package manager in production (in the typical configuration): updates go through full images or a dedicated OTA mechanism

Yocto vs Buildroot: according to the Buildroot Association (buildroot.org), Buildroot is a simpler alternative to Yocto: configuration via menuconfig, faster builds, but less flexible. Buildroot 2024.02 is an LTS supported for 12 months, GPLv2 rolling release cycle. Buildroot suits small projects with limited customisation. Yocto wins out when you need reusable layers, reproducible builds at scale, and maintenance over several years. According to Linaro, the Arm consortium dedicated to Linux support on Cortex-A, Yocto remains the de facto standard for commercial industrial BSPs.

Recommended use cases: volume embedded products, certified devices (medical, automotive), industrial hardware with a specific BSP, systems with long lifetimes. The Yocto LTS Kirkstone (4.0) release is supported until April 2028. The Scarthgap (5.0) release is LTS until 2028. A complete initial build takes 2 to 6 hours on an x86 server with 16 cores and 64 GB of RAM.

Comparison table: Ubuntu/Debian vs Alpine vs Yocto

This comparison table summarises the key characteristics of each approach to position your choice quickly against your embedded project's constraints. The values correspond to typical orders of magnitude found in industrial configurations.

Criterion	Ubuntu / Debian	Alpine Linux	Yocto Project
Disk footprint	500 MB+	~50 MB	10-50 MB (custom)
Boot time	5-30 s	2-5 s	<1-3 s
Init system	systemd	OpenRC	Your choice (systemd / SysVinit)
Package manager	apt	apk	opkg / rpm / none
Long-term support	5-10 years (LTS)	~2 years	You control it
BSP integration	Manual	Manual	Native (layers)
Reproducibility	Partial	Partial	Total
Learning curve	Low	Low	High
Primary use case	Dev / gateway / edge	Container / minimal appliance	Volume embedded production

Field feedback: choosing the right tool for each project

Our approach rests on a simple principle: there is no universal solution. We have been supporting our clients in the design of embedded systems for more than 10 years, and we have observed that the choice of Linux distribution depends on the project phase and the constraints of the final product.

For prototyping and gateways, we routinely deploy standard distributions (Ubuntu, Debian) that allow fast iteration with a rich software ecosystem. The aim is to validate the concept before investing in a custom image.

For volume products and industrial systems, we build custom BSPs with the Yocto Project. We master the integration of BSP layers for NXP i.MX and NVIDIA Jetson processors, with images optimised for the target hardware. This approach guarantees build reproducibility, a criterion required by ISO/IEC 62304 for medical devices, full control over updates, and a footprint suited to storage and boot constraints.

Field feedback, Yocto BSP for Jetson Orin NX (Q1 2026). In Q1 2026, we developed a fully custom Yocto BSP for a Jetson Orin NX module: dedicated meta-aestechno layers, tailored kernel configuration (CONFIG_PREEMPT, camera drivers, LPDDR4x adjustments), extended device tree for the custom carrier board, and integration of the TensorRT inference chain into the production image. A demanding project (L4T version alignment, kernel patches, build reproducibility on CI) that concretely illustrates what Yocto brings to a volume product.

Beyond Jetson, we have also delivered a custom industrial computer based on an Intel Core i5 with an optimised Linux image, and integrated embedded Linux + RTOS (FreeRTOS or Zephyr on the MCU side, common HAL) on heterogeneous platforms. This complete spectrum lets us arbitrate without bias on the distribution suited to each context. The MCU firmware on the asymmetric side stays driven from the MPU's Linux via OpenAMP IPC.

Our design office handles the full chain: from processor selection to BSP integration, including the bootloader, device tree, kernel drivers and embedded application. We work in close collaboration with our hardware engineers so that the software is designed at the same time as the electronic board.

Concrete cases encountered in the lab

Three situations encountered on recent projects illustrate why the choice of Linux distribution plays out on details invisible at the "Ubuntu vs Yocto" level.

• Case 1: Yocto BSP for Jetson Orin NX (Q1 2026). We developed a custom Yocto BSP for an NVIDIA Jetson Orin NX module. Dedicated meta-aestechno layer stacked on top of meta-tegra. Tuned kernel configuration (CONFIG_PREEMPT, CSI camera drivers, LPDDR5x tuning). Extended device tree for the custom carrier board, TensorRT integration in the production image. Contrary to the idea that a Yocto BSP is "just a configuration file", an industrial BSP corresponds to a complete chain to be maintained: L4T alignment, kernel patches, CI reproducibility. We recommend freezing layer revisions in a manifest (repo tool or kas) from the very first build.
• Case 2: Alpine in an embedded container. On an industrial gateway project with constrained resources, we migrated a Docker service from Debian to Alpine Linux (musl libc). In our lab, we measured the final image at 28 MB, against 180 MB before migration. We tested the static compilation of a monitoring agent that assumed glibc. Contrary to the "Alpine everywhere" marketing, migrating to musl forces a review of every binary dependency. We recommend Alpine for greenfield work, and a prior audit for porting.
• Case 3: Ubuntu LTS for rapid prototyping. On an edge AI POC project, we observed that Ubuntu 22.04 LTS allowed us to validate the software architecture in 5 days before launching the Yocto effort. Contrary to a "Yocto from day one" approach, prototyping on a generalist distribution avoids several weeks of BSP integration for an idea that is still moving.

On a recent client project, we supported a client through a Yocto BSP audit for a fleet of industrial gateways. Using the Yocto OEQA test procedure, we measured with the standard image-test runner that custom recipes added an average of 4 minutes per layer build, while reducing the final image size by 18%. The field report from the deployment phase confirmed zero unexpected boot regressions across the first 200 deployed devices, which validated our recipe-revision freeze policy in the production manifest.

Yocto ecosystem: layers and tools to know

The Yocto ecosystem corresponds to an assembly of layers and tools to be articulated, not a monolith. Our industrial practice rests on the following building blocks:

• Reference distribution: Poky, the Yocto Project's reference distribution, the base of every new project
• OpenEmbedded: the set of open source meta-layers that feed Yocto, including the bitbake engine
• Essential layers: meta-virtualization (Docker, LXC, containers), meta-security (AppArmor, SELinux, SCAP), meta-tegra (NVIDIA Jetson), meta-freescale / meta-imx (NXP i.MX), meta-ti
• Development tools: devtool for incremental development, kas or Google's repo for multi-layer management, Toaster for the web interface
• Standards and policies: Yocto Project Compatible (layer certification), Linux kernel LTS policy (2 to 6 years of support depending on version), CIP (Civil Infrastructure Platform) for industrial super-long-term support (up to 20 years)

Contrary to the idea that a Yocto BSP is a one-off deliverable, an industrial BSP corresponds to a 5 to 10 year LTS maintenance cycle to be integrated into the organisation: security watch (kernel CVEs, userspace CVEs), regular rebases, non-regression tests on target hardware. In our practice, we budget BSP maintenance as a line item in its own right, and not as a "wrap-up" of the development phase.

Measured orders of magnitude: rootfs, boot and latency

A few numerical reference points to calibrate your trade-offs, drawn from the configurations we routinely encounter:

• Alpine rootfs: 5 MB base (BusyBox + musl), 50 MB with a few common packages; BusyBox-only Yocto: 8 MB; Debian minimal: 300 MB with dpkg/apt.
• Boot time: Ubuntu 22.04 LTS 15 to 30 s, Alpine OpenRC 2 to 5 s, optimised Yocto image 1 to 3 s (U-Boot + compressed kernel + minimal initramfs).
• RT latency: mainline kernel 500 us to 2 ms of jitter, PREEMPT_RT kernel 50 to 100 us max observed on ARM Cortex-A53.
• Kernel frequency: HZ=100 by default, HZ=1000 for 1 ms resolution in control loops.
• Power consumption: deep sleep on a SoC under Linux 100 to 500 uA depending on drivers and PMIC quirks, vs 5 to 50 uA for a pure RTOS.

These values remain indicative; they depend on the SoC, the bootloader (U-Boot, barebox, coreboot) and the chosen kernel (mainline, vendor fork, LTS). The choice between LTS and mainline boils down to a classic trade-off: mainline brings the latest fixes but moves every 9 weeks, the LTS stabilises 6 years and minimises patch debt.

Decision tree: which approach for your project

The decision tree below helps you arbitrate between a standard distribution and a custom image based on the real constraints of the project. Every situation is different, but these broad orientations cover the majority of cases encountered in industry.

Prototype, gateway, system unconstrained in resources:

• -> Ubuntu or Debian: rapid development, rich ecosystem, LTS support
• Examples: IoT gateway, HMI workstation, edge server

Container, minimal appliance, security-sensitive product:

• -> Alpine Linux: reduced footprint, minimal attack surface, fast boot
• Examples: embedded micro-service, application firewall, sensor with web interface

Volume embedded product, custom hardware:

• -> Yocto Project: custom image, integrated BSP, reproducible builds
• Examples: industrial PLC, medical device, payment terminal, NXP or Jetson embedded system

Product requiring certification (medical, automotive, railway):

• -> Yocto Project: build reproducibility is a regulatory prerequisite
• Full traceability of software components (SBOM) is essential for IEC 62304, ISO 26262, etc.

We also use hybrid approaches: prototype on Ubuntu to validate the concept, then migrate to an optimised Yocto image for production. This strategy lets us reduce the time-to-market without sacrificing the quality of the final product.

Key takeaways: embedded Linux distribution, what to remember

To arbitrate between a generalist embedded Linux distribution and a custom image, five operational reference points:

• Ubuntu / Debian LTS: prototyping, gateways, edge servers. Image of 500 MB or more, support 5 to 10 years, complete apt ecosystem. Not suited to strict volume-production constraints.
• Alpine Linux: minimal appliances, containers, security-sensitive products. Base ~5 MB (musl libc + BusyBox), boot 2 to 5 s, minimal attack surface. glibc compatibility audit required before porting.
• Yocto Project: volume products, custom hardware, certification (IEC 62304, ISO 26262, EN 50155). Image 10 to 50 MB, reproducible builds, integrated BSP, controlled LTS cycle over 5 to 10 years.
• Kernel: prefer a kernel.org LTS for long-term maintenance; enable PREEMPT_RT if the product demands hard real-time.
• Maintenance: an industrial BSP demands 2 to 6 weeks per year of CVE watch, rebases and non-regression tests, to be budgeted at kickoff.

FAQ: Linux distributions for embedded

Which Linux distribution for an embedded product?
The choice depends on the context: for a prototype or a gateway, Ubuntu or Debian offer a rich ecosystem and rapid development. For a volume product with size, boot and reproducibility constraints, the Yocto Project lets you build a custom image. Alpine Linux is a good middle-ground choice for lightweight appliances and containers.

Yocto or Buildroot: how to choose?
Buildroot is easier to pick up and compiles faster: it suits simple projects with little customisation. Yocto is more powerful thanks to its layered architecture, which makes reuse, long-term maintenance and reproducible builds easier. For an industrial volume product maintained over several years, we recommend Yocto.

Can Ubuntu be used in embedded production?
Yes, for certain use cases: gateways, edge servers, HMI workstations or systems unconstrained in resources. Ubuntu offers excellent long-term support (LTS). However, for volume products with memory-size constraints, boot-time constraints or certification needs, a custom Yocto image is preferable.

What is the development cost of a Yocto BSP?
The cost varies sharply depending on hardware complexity, the number of peripherals to integrate and the level of customisation required. A basic BSP on a well-supported NXP i.MX platform demands less effort than integration on a poorly documented SoC. We size each project at the initial audit to provide a realistic estimate.

Is systemd necessary for embedded?
No. systemd brings advanced features (service supervision, structured logging, network management) that are useful on complex systems. But for a minimal embedded product, a lighter init (OpenRC, SysVinit, BusyBox init) is often enough. With Yocto, you choose your init system based on your real needs.

How do you secure an embedded Linux distribution?
Security starts with reducing the attack surface: fewer installed packages, fewer active services. Yocto excels here because the image contains only the strict minimum. Then you need secure boot, filesystem encryption, signed OTA updates and vulnerability monitoring (CVE). See our embedded cybersecurity guide to dig deeper.

Related articles

• Industrial embedded software: a complete guide for decision-makers
• NVIDIA Jetson processors for embedded
• AESTECHNO electronic design office
• Embedded systems cybersecurity
• Embedded AI with NVIDIA Jetson
• Electronic product design