Yocto vs Ubuntu vs Debian: welke Linux kies je voor een embedded product?

Linux is een logische keuze voor heel wat embedded devices. Industriële HMI’s, gateways, edge computers en connected machines hebben vandaag vaak voldoende rekenkracht om een volwaardig Linux-systeem te draaien.

Maar dan komt al snel de volgende vraag: kies je voor Yocto, Debian of Ubuntu?

Het antwoord is minder zwart-wit dan het lijkt. Alle drie kunnen een uitstekende keuze zijn. Het verschil zit in de hardware waarop je product draait, hoe snel je naar de markt wilt, hoeveel controle je nodig hebt, en wie het platform gedurende de volledige levensduur onderhoudt.

En precies daar verschilt een embedded product van een gewone Linux-server.

Eerst even dit: Yocto is geen Linux-distributie

Debian en Ubuntu zijn Linux-distributies. Je vertrekt van een bestaand operating system met een vooraf samengesteld pakketecosysteem en bouwt daar je applicatie bovenop.

Yocto werkt anders.

Het Yocto Project is een verzameling tools, metadata en buildsystemen waarmee je zelf een Linux-distributie voor je product samenstelt. Poky is de referentiedistributie van dat project, niet het product dat je hoort te shippen. Het resultaat is jouw image: kernel, bootloader, drivers, libraries, services en applicaties, samen opgebouwd vanuit één gecontroleerde build.

Dat onderscheid verklaart een groot deel van de voor- en nadelen. Het verklaart ook waarom “Yocto Linux” als term weinig zegt over wat er uiteindelijk op het device staat.

Voor eenvoudigere producten bestaat dezelfde filosofie in een lichtere vorm: Buildroot. De leercurve is kleiner, de vrijheid ook. Zodra de hardwareleverancier een Yocto-BSP als primair platform levert, is Yocto meestal het natuurlijkere vertrekpunt. Buildroot blijft relevant wanneer je een klein, overzichtelijk image wilt en de BSP dat toelaat.

De hardware komt vaak vóór de Linux-keuze

In embedded development begin je zelden met een blanco computer waarop je eender welk operating system installeert.

Je kiest een processor of System-on-Module op basis van performance, interfaces, beschikbaarheid, temperatuurgebied, kostprijs en verwachte levensduur. Daarna heb je een Board Support Package nodig om Linux correct op die hardware te laten draaien.

Zo’n BSP bevat veel meer dan een kernel. Denk aan de bootloader, kernelconfiguratie en patches, device trees, drivers, GPU- en VPU-ondersteuning, hardware acceleration, firmware en de configuratie van de platforminterfaces.

Het Yocto Project definieert een BSP als de verzameling informatie die nodig is om een specifiek hardwareplatform te ondersteunen. Voor veel embedded processoren en System-on-Modules is een Yocto-BSP een van de primaire softwareplatformen die de chip- of hardwareleverancier aanbiedt. Je kunt die laag gebruiken en je eigen product er bovenop bouwen.

Ook Debian-images worden door hardwareleveranciers aangeboden. Ubuntu draait op heel wat ARM- en x86-platformen, en Canonical heeft een hardware-certificatieprogramma.

De vraag is daarmee niet alleen of Linux op deze processor kan draaien. De belangrijkere vraag is welke softwarebasis de leverancier onderhoudt, welke hardware-specifieke aanpassingen daarin zitten, en hoe lang die combinatie ondersteund blijft.

Dat laatste punt wordt vaak onderschat. Veel SoM-BSP’s zijn geen mainline kernel, maar een vendor-fork: een oudere kernel, out-of-tree drivers, een GPU-blob, patches die nooit upstream raken. Zolang de leverancier die fork bijwerkt, is dat comfortabel. Stopt die ondersteuning na twee of drie jaar, dan erf je de CVE-achterstand op die fork. Welke distributie je ook koos.

Image of levend systeem

Voor je Debian, Ubuntu en Yocto vergelijkt, is er een keuze die door alle drie heen snijdt.

Werk je met een versieerbaar image, of met een systeem dat in het veld package per package evolueert?

Een klassieke Debian- of Ubuntu-installatie nodigt uit tot het tweede. apt is vertrouwd, een debuggingtool installeer je in seconden, en een device in het lab wijkt na een paar maanden af van zijn buurman. Voor een product dat jaren in het veld staat, wordt die flexibiliteit een vraag: welke packages stonden exact op dit serienummer, welke wijzigingen zijn na installatie uitgevoerd, en kun je die software opnieuw produceren?

Die vragen horen bij een mutable rootfs. Ze horen niet onlosmakelijk bij Debian of Ubuntu.

Van Debian of Ubuntu kun je evengoed een vast image bouwen, met tools als debos, mkosi of FAI. A/B-updates en rollback kun je daar bovenop zetten met RAUC of OSTree. snapshot.debian.org maakt het mogelijk een Debian-package-set jaren later opnieuw te bouwen, op voorwaarde dat je die set hebt vastgelegd.

Yocto vertrekt vanuit het image. De definitie van het systeem leeft naast de applicatie in versiebeheer, en een release is een combinatie van bootloader, kernel, drivers, libraries, configuratie en applicaties. Ook dat is geen automatische garantie. Exact reconstrueren lukt als layers gepind zijn, de buildhost vastligt, AUTOREV niet stilletjes nieuwere revisies binnenhaalt, en de sstate-cache bewaard blijft. Zonder die discipline is een Yocto-build over vijf jaar ook een benadering.

De distributiekeuze en het deploy-model zijn dus twee beslissingen. Ze beïnvloeden elkaar, en ze vallen niet samen.

Debian: vertrouwd, flexibel en pragmatisch

Debian kan een uitstekende basis zijn voor een embedded systeem.

Je krijgt een volwassen distributie, een enorm pakketecosysteem en een omgeving die developers kennen. Een library, een debuggingtool, SSH, een container: dat is aanwezig of één commando verwijderd. Voor industriële computers, gateways en edge devices met relatief krachtige hardware is dat aantrekkelijk. Zeker wanneer de hardwareleverancier zelf een onderhouden Debian-image levert. Je profiteert dan van hun integratie zonder zelf een distributie te bouwen.

Debian blijft in essentie een general-purpose distributie. Je vertrekt van een bestaand systeem en configureert dat tot jouw product.

Het releasebeleid is duidelijk. Een reguliere release krijgt ongeveer drie jaar volledige ondersteuning, gevolgd door twee jaar Long Term Support. Die tweede fase is smaller dan de eerste. Het security team draagt het werk over aan een apart LTS-team, point releases en nieuwe installer-images stoppen, de set architecturen krimpt, en lang niet elk package in het archief wordt nog even actief gevolgd. Embedded-specifieke packages vallen daar sneller buiten dan OpenSSH.

Daarboven bestaat Extended LTS, onder meer via Freexian. Voor Debian 13 (Trixie) loopt die verlenging tot 2035. Voor een product van tien of vijftien jaar is dat een reële optie, en meteen ook een onderhoudscontract: iemand moet bewaken wat binnen die scope valt en wat je zelf moet dragen.

Mensen die Debian kunnen onderhouden, vind je makkelijker dan mensen die een Yocto-buildsystem kunnen dragen. Voor een team dat jaren met hetzelfde product verder moet, telt dat.

Ubuntu: snel wanneer je binnen het ondersteunde platform past

Canonical positioneert Ubuntu als platform voor embedded en IoT, met gecertificeerde hardware, commerciële hardware-enablement en securityondersteuning als dienst.

Wanneer je hardware in dat ecosysteem past, lijkt de ervaring sterk op klassieke Linux-development. Developers werken in een bekende omgeving, packages zijn beschikbaar, en een groot deel van het onderhoud van de onderliggende stack wordt voor je gedaan. Dat verkort de tijd tot een eerste productie-image, omdat je de Linux-basis niet zelf hoeft samen te stellen.

De termijnen moet je daarbij precies lezen. Ubuntu 26.04 LTS krijgt vijf jaar standaard security-onderhoud, tot april 2031, voor packages in Main. Ubuntu Pro verlengt dat met Expanded Security Maintenance tot tien jaar, voor Main en Universe. Het Legacy add-on voegt daar nog vijf jaar aan toe, tot vijftien jaar in totaal. “Ubuntu” en “tien jaar ondersteuning” zijn dus niet hetzelfde. Zonder Pro stopt de standaardondersteuning na vijf jaar.

Voor x86-gebaseerde embedded computers en ondersteunde ARM-platformen kan dat een sterke match zijn. De afweging verandert zodra je eerst een vendor-BSP moet aanpassen om hem in die Ubuntu-basis te krijgen. Dan verdwijnt een deel van de tijdswinst waarmee je voor Ubuntu koos.

Ubuntu Core

Voor appliances biedt Canonical Ubuntu Core.

Ubuntu Core is geen klassieke Ubuntu-installatie. Het is een minimaal, immutable operating system. Het systeem en de applicaties zijn snaps, met signing, confinement en OTA-updates als onderdeel van het platform. Ubuntu Core 26, gebouwd op Ubuntu 26.04 LTS, positioneert Canonical met tot vijftien jaar security-onderhoud.

Een aantal problemen die je bij een eigen embedded platform zelf oplost, zoals atomische updates, confinement en een ondertekende keten, zitten hier al in het platform.

Canonical neemt daarbij verantwoordelijkheid op voor de core modules van het operating system: security-onderhoud, CVE-opvolging en een stuk van de CRA-plichten rond die OS-laag. Die grens is belangrijk. Jouw snaps, je device tree en een vendor-GPU-stack vallen erbuiten. De applicatie en de hardware-specifieke integratie blijven van jou.

Sluiten hardware en productarchitectuur aan op dat model, dan is de weg van prototype naar een onderhouden device kort. Sluiten ze niet aan, dan wordt de integratie met snaps, confinement en een afwijkende BSP het werk dat je hoopte te vermijden.

Wanneer de hardware afwijkt

Een embedded product is niet altijd een standaardcomputer waarop de hardware upstream ondersteund is.

Een specifieke displaycontroller, een aangepaste device tree, een vendor-GPU-stack, een custom bootloader, een camera-interface, patches van de SoM-fabrikant boven op de kernel: hoe meer van die elementen je nodig hebt, hoe bepalender de BSP wordt.

Canonical kan custom hardware enablement doen, en Ubuntu ondersteunt x86 en ARM. Ubuntu is niet beperkt tot standaardhardware. De economische afweging verschuift wel. Een BSP porteren naar een platform dat je koos omdat het werk uit handen nam, haalt die winst weer naar binnen.

Met Yocto is die vendor-BSP vaak het vertrekpunt. Hardware support en je eigen configuratie blijven dan relatief gescheiden, zolang de leverancier zijn laag onderhoudt.

Yocto: wanneer Linux onderdeel wordt van het product

Bij Yocto behandel je Linux als onderdeel van de productontwikkeling.

Je legt vast welke kernel gebruikt wordt, welke packages aanwezig zijn, welke services starten, welke configuratie geldt en welke eigen software in het image terechtkomt. Een productrelease is dan versie 2.3 van het geheel, niet alleen versie 2.3 van de applicatie.

Voor een industrieel device dat jaren in het veld staat, is dat een andere manier van werken dan een computer waarop packages individueel worden bijgewerkt. Het image kan klein blijven. Minder packages betekent een kleiner aanvalsoppervlak en minder CVE’s die voor jouw product relevant zijn. Dat voordeel bestaat alleen als die resterende componenten ook echt gepatcht worden. Een minimaal image dat stilvalt, is onveiliger dan een grotere distributie die iemand anders bijhoudt.

Yocto heeft zelf een ondersteuningsmodel. Om de twee jaar verschijnt een LTS-release, met vier jaar onderhoud voor de core layers. Scarthgap 5.0 loopt tot april 2028, Wrynose 6.0 tot april 2030. Tussenliggende releases leven ongeveer zeven maanden. Die vier jaar dekken het project, niet jouw BSP, niet je vendor-kernel en niet je applicatielayers. Die blijven van het team dat het product bouwt.

Daar zit de prijs.

BitBake, recipes en layers vragen een echte leercurve. Iemand moet de BSP en het buildsystem dragen, en die mensen zijn schaarser dan engineers die een Debian-systeem kunnen onderhouden. Een wijziging doorloopt recept, image en deploy. Dat is trager en zwaarder dan een package op een draaiend systeem zetten, ook wanneer een warme sstate-cache de incrementele build korter maakt dan een eerste cold build.

Je maakt ook meer architecturale keuzes zelf. Partitionering, A/B, rollback, applicatie-deploy, containers, keys, updatekanaal. Die vrijheid is bruikbaar wanneer het product ze nodig heeft. “Yocto geeft ons meer controle” is op zichzelf geen reden om Yocto te kiezen. De controle moet een concreet probleem van dit product oplossen: een vendor-BSP die je anders moet porten, een image waarvan de inhoud vast moet liggen, een updatepad dat je zelf wilt bepalen, een aanvalsoppervlak dat klein moet blijven.

OTA-updates

Software-updates maken de filosofieën zichtbaar, zonder dat één model aan één distributie vastzit.

Op een klassieke Debian- of Ubuntu-installatie werk je packages bij via de package manager. Dat is flexibel. Het risico is configuratiedrift: twee devices met hetzelfde versienummer zijn na een jaar onderhoud niet meer hetzelfde.

Ubuntu Core beheert operating system en applicaties binnen het snap-platform. OTA, signing en confinement horen bij het platform. Jij definieert de snaps en bewaakt wat daarin zit.

Met een eigen image kies je de update-architectuur. RAUC, SWUpdate en OSTree zijn gebruikelijke bouwstenen, vaak met een A/B-schema: het device draait van systeem A, de nieuwe software landt op B, en pas na een geslaagde boot wordt B actief. Faalt die boot, dan valt het toestel terug op A. Mender is de variant waarin een groter deel van die keten (client, backend en fleet) als product bestaat in plaats van als integratie die je zelf bouwt en test.

Je kunt die A/B-laag ook op een Debian- of Ubuntu-image zetten. Yocto maakt het model natuurlijk, niet exclusief. In alle gevallen ben je verantwoordelijk voor de integratie op jouw hardware: wat er gebeurt als de spanning wegvalt, hoe een mislukte boot wordt herkend, hoe je een fleet van honderden devices gefaseerd bijwerkt.

Security en lifecycle

De Linux-keuze stopt niet bij de eerste release.

Connected devices moeten hun hele levensduur onderhouden kunnen worden. Je moet weten welke componenten aanwezig zijn, welke kwetsbaarheden voor dat image relevant zijn, en updates gecontroleerd kunnen verspreiden. Reproduceerbare builds, een software-inventaris, SBOM’s, ondertekende software en een updatepad dat rollback aankan, worden producteisen.

De Europese Cyber Resilience Act maakt dat naast een engineeringvraag ook een productverantwoordelijkheid.

De drie opties verdelen dat werk anders.

Bij Ubuntu neemt Canonical een groot deel van het distributie-onderhoud op zich, binnen de termijn en de scope van het contract dat je afsluit. Bij Ubuntu Core geldt dat nadrukkelijk voor de core modules.

Debian biedt een community-basis met een vast release- en LTS-model, aangevuld met ELTS als je verder wilt dan vijf jaar. De dekking is breed, en smaller in de latere jaren.

Met Yocto bepaal je exact wat er in het image zit, en Yocto kan daar een SBOM en CVE-check aan koppelen. Patchen, opvolgen en releasen van die componenten blijft bij jou, inclusief de vendor-kernel wanneer de SoM-leverancier stopt. Een kleiner image vermindert het aantal kwetsbaarheden. Het vermindert het werk alleen als je de resterende set ook bijhoudt.

Van wie wil je afhankelijk zijn?

Ubuntu Core is een sterk geïntegreerd platform. Packaging, confinement, OS-updates en deployment zitten in het Ubuntu- en snap-ecosysteem. Wanneer dat aansluit, hoef je die problemen niet zelf op te lossen. Je kiest daarmee ook voor de architectuur en de diensten van Canonical, binnen een contract dat de termijn expliciet maakt.

Yocto legt minder vast. Updateframework, backend, partitionering, applicatie-deploy en securityarchitectuur kies je zelf, of je neemt een laag zoals Mender. Dat verplaatst werk naar je eigen team.

Ook dan ben je niet vrij van afhankelijkheden. De BSP, de kernelpatches en de binaire drivers van de SoC- of SoM-leverancier blijven een keten waar je in zit. Een mainline kernel verkleint die afhankelijkheid, op hardware die upstream voldoende ondersteund is. Een vendor-fork vergroot haar, welke distributie er ook bovenop staat.

Van welke partijen en technologieën willen we gedurende de levensduur van dit product afhankelijk zijn, en welk contract of welke engineeringcapaciteit dekt die afhankelijkheid af?

Het verschil merk je na de eerste release

Tijdens een proof-of-concept lijken de verschillen soms klein. Linux boot, ethernet werkt, de applicatie start, de HMI verschijnt.

Vijf jaar later zijn dit de vragen die tellen:

• Kunnen we exact reconstrueren wat er op serienummer 1847 draait?
• Welke libraries zitten in softwareversie 3.2, en ligt die lijst vast in een SBOM?
• Welke gekende kwetsbaarheden zijn voor dat image relevant?
• Kunnen we 500 machines veilig en gefaseerd op afstand updaten?
• Wat gebeurt er als tijdens de update de spanning wegvalt?
• Kunnen we automatisch terugrollen?
• Draait onze hardware op een kernel die over vijf jaar nog patches krijgt, en van wie komen die patches?
• Kunnen we van hardwareleverancier of updateplatform veranderen zonder het product opnieuw te bouwen?

Die vragen beantwoordt geen distributie vanzelf. Een image-gebaseerd proces maakt ze beantwoordbaar. Een team en een leverancier moeten ze daarna ook blijven beantwoorden.

Containers veranderen de as

Er is een tweede architectuur die de keuze verzacht.

Steeds vaker is de applicatie een container of een snap, en het operating system een dunne, stabiele laag daaronder. Torizon, balena, Ubuntu Core en Docker op een minimale Debian doen dat elk op hun manier. Het device lijkt dan weer meer op een computer: de applicatie heeft haar eigen lifecycle, het basisimage verandert trager.

Dat kan de druk op de distributiekeuze verlagen. Het heft ze niet op. De BSP, de kernel, de drivers en het updatepad van die basislaag blijven de levensduur van het product bepalen. Een container op een vendor-kernel zonder patches is nog steeds een vendor-kernel zonder patches.

Wanneer kies je wat?

Er is geen universele winnaar.

Debian past wanneer je een vertrouwde, flexibele omgeving wilt, de hardware goed ondersteund is, en het product dicht bij een industriële computer of edge gateway ligt. Bouw er een image van als je jarenlang dezelfde software moet kunnen reproduceren. Reken op drie plus twee jaar, met een smallere LTS-fase, en betrek ELTS er expliciet bij als het product langer meegaat dan vijf jaar.

Ubuntu past wanneer de hardware in het ondersteunde ecosysteem zit en time-to-market zwaar weegt. Een groot deel van het Linux-onderhoud kun je uitbesteden, binnen vijf, tien of vijftien jaar, afhankelijk van Pro en Legacy. Ubuntu Core gaat verder: een immutable appliance-platform, met Canonical als onderhouder van de core modules, en met jouw snaps en hardware-integratie als eigen verantwoordelijkheid.

Yocto past wanneer Linux een onderdeel van het product is. Je vertrekt van een vendor-BSP, je wilt bepalen wat er in het image zit, het aanvalsoppervlak moet klein blijven, of het updatepad moet van jou zijn. Reken op vier jaar Yocto LTS voor de core, en op je eigen team voor BSP, vendor-kernel en applicatielayers. Buildroot is het lichtere alternatief wanneer die BSP-wereld je niet dwingt naar Yocto.

Twee vuistregels helpen.

Hoe meer het device op een computer lijkt, hoe aantrekkelijker een standaarddistributie wordt. Hoe meer Linux zelf onderdeel van het product wordt, hoe interessanter een eigen image wordt, met Yocto of Buildroot.

En hoe beter een bestaand platform exact aansluit bij hardware, update-model en levensduur, hoe minder reden er is om die laag zelf te bouwen.

Begin met het product

De eerste vraag is niet welke Linux je wilt.

Welke hardware gebruiken we? Welke BSP levert de fabrikant, en is dat een mainline kernel of een vendor-fork? Hoe lang onderhoudt die leverancier die fork? Bouwen we een image of een levend systeem? Hoe lang moet het product meegaan, en wie patcht er na jaar vijf? Hoe zien OTA en rollback eruit? Hoe belangrijk is time-to-market? Welke mensen moeten dit over vijf jaar nog kunnen bouwen?

Pas daarna wordt de keuze tussen Yocto, Debian en Ubuntu duidelijk.

Bij Invisto bekijken we embedded Linux als onderdeel van de productarchitectuur: hardware en BSP, het image, de applicaties, security en remote updates.

Het product is niet de Linux-distributie. Het product is een device dat betrouwbaar gebouwd, geproduceerd, beveiligd, geüpdatet en onderhouden kan worden, gedurende zijn volledige levensduur.