Probablemente no necesitas Yocto, y eso está bien

• Yocto no es una distribución, sino una herramienta para ensamblar tu propia distribución Linux, y es difícil tomarlo como opción predeterminada si no necesitas ese nivel de control
• Una distribución propia implica mantenimiento propio, junto con regulaciones como la CRA y la responsabilidad de ofrecer actualizaciones de seguridad durante toda la vida útil del producto
• Adoptar Yocto implica compilaciones de varias horas, directorios de compilación de más de 100 GiB, una curva de aprendizaje de varias semanas y capas BSP de calidad irregular
• Si lo que necesitas es una base Linux sólida para ejecutar aplicaciones, Debian y herramientas de imágenes como mkosi, ELBE y debos pueden ser más que suficientes con mucho menos trabajo específico por proyecto
• Yocto solo gana cuando hay personalización intensa, restricciones de tamaño o tiempo de arranque, exclusión por licencias o soporte sólido del proveedor para Yocto; si tienes dudas, una distribución existente suele ser mejor

---

La verdadera naturaleza de Yocto y por qué se vuelve la opción predeterminada

• Yocto no es una “distribución Linux Yocto”, sino un conjunto de herramientas para crear tu propia distribución Linux
• El proyecto Yocto también ofrece Poky, una distribución de referencia construida con bitbake, openembedded-core y meta-yocto
• Yocto permite ensamblar con detalle el sistema Linux que necesita un proyecto embebido
  • Puede compilarse todo el espacio de usuario para la CPU de destino
  • Se pueden aplicar parches a cualquier componente
  • Se pueden activar o desactivar funciones de cada receta
  • Se pueden fijar o cambiar todas las versiones
• Muchos proveedores de SoC y socios de hardware ofrecen capas BSP (Board Support Package) listas para usar, que dan un punto de partida que funciona en hardware real
• Por la combinación de flexibilidad y soporte de proveedores, Yocto se convierte en la opción predeterminada, pero si no necesitas tanto control, la carga puede ser mayor que el beneficio

Una distribución propia significa mantenimiento propio

• Regulaciones como la Cyber Resilience Act (CRA) exigen que el proveedor del producto mantenga seguro el software distribuido y ofrezca actualizaciones de seguridad durante la vida útil del producto
• Una versión normal de Yocto se mantiene solo unos 7 meses, hasta que sale la siguiente versión
• Desde Yocto 5.0 Scarthgap, según la política actual, las versiones LTS reciben actualizaciones por un máximo de 4 años
• Una versión de Yocto está compuesta por un conjunto de recetas bitbake con versiones y metadatos específicos, además de la distribución de referencia Poky
• Durante el periodo de mantenimiento, los mantenedores de Yocto aplican correcciones de errores y seguridad a los componentes y a Poky, y las correcciones de los componentes de software normalmente se retroportan desde las versiones upstream más recientes
• En un producto real, es común que no se use Yocto tal cual, sino con cambios como estos
  • Aplicar parches no triviales o cambios locales a algunos componentes
  • Incluir componentes adicionales que Yocto no ofrece
  • Actualizar o fijar versiones para recibir correcciones o mantener un estado conocido como bueno
• Cada vez que aparece una versión de mantenimiento de Yocto, hay que verificar que los cambios locales sigan aplicándose limpiamente sobre el nuevo estado
• Como los mantenedores de Yocto no pueden conocer los componentes que agregaste o fijaste, también te toca verificar por tu cuenta que esos componentes sigan recibiendo correcciones
• Si usas Poky casi sin cambios, vale la pena reconsiderar por qué necesitas Yocto

El kernel de Linux y la dependencia del proveedor

• Yocto ofrece y mantiene un kernel de Linux como parte de cada versión, pero en productos reales rara vez se usa sin modificaciones
• Como mínimo, normalmente hay que aplicar parches del proveedor y usar un kernel suficientemente nuevo que incluya los drivers y correcciones necesarios
• Si además consideras el seguimiento de CVE, el kernel por sí solo ya representa una gran carga de mantenimiento, uses o no Yocto
• Para controlar esa carga, se recomienda construir sobre un kernel LTS de kernel.org y mantener todos los cambios en una cola de parches ordenada
• Para seguir las correcciones de seguridad, se avanza a una nueva versión stable y luego se vuelve a aplicar la cola de parches
• kernel.org mantiene los kernels LTS durante varios años, así que normalmente la cola de parches se aplica de forma limpia y el trabajo real solo aparece al pasar a una nueva versión LTS
• Según la configuración y los requisitos de seguridad, el mismo principio aplica al bootloader, que también suele tener una fuerte dependencia del proveedor
• En general, no es buena idea quedarse con el kernel que entrega el proveedor
  • El kernel del proveedor suele estar años atrasado respecto a kernel.org
  • Casi no recibe actualizaciones
  • Se pierde la mayoría de las correcciones de seguridad

El costo de adoptar Yocto

• Elegir construir una distribución propia requiere tiempo real de ingeniería

• Tiempo de compilación

  • Yocto compila prácticamente todo desde código fuente
  • Incluso una compilación limpia de una imagen no muy compleja toma varias horas en una workstation rápida
  • sstate-cache y un DL_DIR compartido aceleran las compilaciones repetidas, pero un cambio pequeño en una receta puede invalidar gran parte del caché

• Disco y costo de CI

  • Un directorio de compilación de Yocto puede crecer fácilmente a más de 100 GiB
  • Los runners de CI necesitan suficiente almacenamiento y alguna forma de compartir sstate entre trabajos
  • Reflejar sstate y DL_DIR puede reducir el dolor, pero esa infraestructura también la tienes que operar tú

• Curva de aprendizaje

  • Hay mucho que aprender: recetas de bitbake, capas, capas dinámicas, clases, overrides, archivos bbappend, PACKAGECONFIG, la diferencia entre DEPENDS y RDEPENDS, etc.
  • Integrar a un ingeniero en la base de código de Yocto no toma días, sino varias semanas

• Variación en la calidad de las capas BSP

  • Algunos proveedores de SoC entregan capas BSP limpias y bien mantenidas
  • Otros fijan un kernel o bootloader de hace 5 años, codifican recetas específicas de la máquina en la capa equivocada y entregan capas meta-vendor que se rompen cada vez que subes Poky
  • Un BSP que parece un buen punto de partida puede terminar siendo la peor parte de la compilación
  • Estos factores no son una razón para evitar Yocto por sí mismos, sino una razón para confirmar antes de adoptarlo que realmente lo necesitas

Alternativa: reutilizar una distribución probada

• Si solo necesitas una base Linux sólida para ejecutar una aplicación, una distribución existente como Debian GNU/Linux resuelve gran parte del mismo problema con mucho menos trabajo específico por proyecto
• Debian ofrece actualmente alrededor de 70,000 paquetes binarios
• Entre las arquitecturas soportadas están amd64, i386, arm64, armhf, riscv64, ppc64el y otras
• Muchos SoC probablemente puedan ejecutar binarios de Debian directamente sin recompilación
• Debian no es solo una distribución que ofrece un espacio de usuario moderno con systemd, udev y dbus
• El archivo también incluye elementos para construir sistemas Linux pequeños basados en init estilo SysV o en BusyBox
• Puedes elegir una base ligera e instalar solo los paquetes que necesita el producto, aprovechando al mismo tiempo el trabajo de los mantenedores de paquetes de Debian

Modelo de mantenimiento de Debian

• Debian stable recibe actualizaciones de seguridad del Debian Security Team durante unos 3 años
• Después, el proyecto comunitario Debian LTS extiende el soporte unos 2 años más en arquitecturas comunes
• En la práctica, eso permite alrededor de 5 años de soporte por versión, un nivel parecido al de Yocto LTS, pero con muchísimo menos trabajo por proyecto
• Para recibir las correcciones más recientes, basta con tomar los paquetes Debian más nuevos y reconstruir la imagen
• La naturaleza del trabajo es muy distinta a retroportar manualmente parches upstream en Yocto o verificar otra vez que los cambios locales sigan aplicándose sobre las versiones de mantenimiento

Cómo se construyen las imágenes embebidas

• Una imagen embebida basada en Debian no consiste en arrancar el SoC desde una memoria USB y ejecutar el instalador de Debian
• Se trata de generar una imagen grabable en el host de compilación y escribirla en el dispositivo
• Los componentes necesarios son los siguientes
  • Un bootloader normalmente específico del SoC, por ejemplo u-boot
  • Un kernel de Linux normalmente específico del SoC
  • Un sistema de archivos raíz basado en el espacio de usuario de Linux tomado directamente de Debian
  • Una herramienta de ensamblado de imágenes que combine esos tres elementos en una imagen grabable
• Las opciones comunes para la herramienta de ensamblado de imágenes son mkosi, ELBE y debos
• Las tres herramientas son software libre y generan imágenes deterministas que pueden grabarse en el hardware
• El trabajo de mantenimiento se reduce de forma importante, y la mayoría de las actualizaciones pasan a ser una renovación tipo apt de los paquetes dentro de la imagen, en lugar de reescribir recetas

Ejemplo de compilación Debian con debos

• debos lee recetas en YAML
• Una receta está compuesta por una lista de acciones, como ejecutar comandos, crear un sistema de archivos raíz o instalar paquetes Debian desde fuentes configuradas
• El flujo básico es este
  • Operar un mirror local de Debian con aptly que contenga copias de todos los paquetes Debian necesarios
  • Compilar el kernel de Linux y, si hace falta, el bootloader como paquetes Debian y agregarlos al mirror
  • Crear un snapshot del mirror y etiquetarlo
  • Esa etiqueta se convierte en la versión de lanzamiento
  • Escribir acciones de receta para que debos use ese mirror y construya la imagen de destino
  • Si hace falta, conservar junto con la imagen los paquetes fuente de Debian y el SBOM (Software Bill of Materials) de la imagen
• Conservar los paquetes fuente y el SBOM ayuda a cumplir con la obligación de ofrecer el código fuente bajo la GPL y con los requisitos de lista de materiales de la CRA
• Herramientas como debsbom generan un SBOM directamente desde un sistema Debian

Cuándo deberías elegir Yocto

• Yocto es adecuado cuando necesitas una distribución muy personalizada
  • Espacio de usuario personalizado
  • Flags de compilación personalizados
  • Cambios profundos en los componentes base
• También es adecuado cuando hay restricciones estrictas de tamaño o tiempo de arranque que una distribución preexistente no puede cumplir
• También aplica cuando existen restricciones de licencias que exigen excluir categorías habituales de software
  • En algunas industrias, como dispositivos médicos, automotriz o ciertos trabajos de defensa, no se distribuyen componentes GPLv3
  • El mecanismo INCOMPATIBLE_LICENSE de Yocto facilita excluir familias completas de licencias en toda la imagen
  • En una base Debian común, tendrías que auditar y reducir los paquetes manualmente
• También conviene cuando la ruta oficial de soporte del proveedor del SoC es Yocto y la calidad del BSP es sólida

Cuándo deberías evitar Yocto

• Si solo necesitas un Linux moderno sobre el cual desplegar y ejecutar una aplicación, quizá no necesites Yocto
• Si el presupuesto de almacenamiento y memoria puede soportar una imagen Debian típica, las ventajas de Yocto se reducen
  • Como referencia, hablamos de cientos de MB de flash y 256 MB o más de RAM
• Si la vida útil del producto es larga y prefieres depender del Debian Security Team antes que de mantenimiento propio, tiene sentido evitar Yocto

Cuándo deberías evitar Debian

• Si vas a modificar o recompilar muchos paquetes Debian, Debian sale perdiendo
  • Recompilar unos pocos paquetes es manejable
  • Cada paquete recompilado se convierte en trabajo de mantenimiento que asumes tú
  • Si parcheas decenas de paquetes upstream, básicamente recreas el trabajo que antes hacían los mantenedores de Debian
  • A esa escala, el modelo de recetas de Yocto lo maneja de forma más limpia
• Si necesitas una libc no glibc como musl o uClibc, Debian no es la opción correcta
  • El archivo principal de Debian usa glibc de forma generalizada
  • Reemplazarlo implicaría recompilar tú mismo gran parte del archivo
• Si necesitas software mucho más reciente que el que ofrece Debian stable, Debian también queda en desventaja
  • Los backports ayudan con algunos paquetes
  • Si el producto requiere compiladores o runtimes recientes, eso choca con Debian stable
  • Debian testing no está pensado para producción

Principios de decisión y conclusión

• La decisión sobre Yocto debe tomarse de forma consciente y al inicio del producto
• Es una elección fundamental difícil de revertir una vez que el producto ya fue desplegado en campo
• Si tienes dudas, es mejor comenzar con una distribución existente
• El costo de migrar más adelante a Yocto, cuando exista una razón real, es mucho menor que descubrir a mitad del proyecto que asumiste años de mantenimiento sin un beneficio tangible
• Yocto es una obra de ingeniería excelente que te permite construir exactamente el sistema Linux que necesitas, pero justamente ese control preciso se vuelve un problema cuando no lo necesitas
• La misma lógica aplica casi por completo a otras herramientas de compilación basadas en código fuente, como Buildroot
• En el momento en que ensamblas tu propia distribución, también pasas a ser dueño directo de su mantenimiento
• La conclusión central es clara
  • “Distribución propia” en realidad significa mantenimiento propio
  • Regulaciones como la CRA vuelven ese costo una carga real
  • Una compilación de Yocto muy modificada no hereda gratis las correcciones upstream
  • Cada versión de mantenimiento se convierte en revisión y retrabajo
  • Una distribución existente como Debian, convertida en imagen con mkosi, ELBE o debos, resuelve el caso general con mucho menos esfuerzo específico por proyecto
  • Cuando necesitas un control quirúrgico del sistema, Yocto gana
  • Cuando no lo necesitas, elegir Yocto es una forma larga y costosa de resolver un problema que no existe

[GN⁺]

Comentarios en Lobste.rs

• Si la ruta de soporte oficial del proveedor del SoC es Yocto, incluso si el BSP no es muy sólido, en general me parece mejor que un port de Ubuntu de baja calidad
  Los ports de Ubuntu hacen engorroso integrar RAUC o volver inmutable el sistema de archivos raíz. Realmente detesto Yocto y sus dialectos mutados de bash/python, pero al final uno queda atado a eso

• Hago bastante consultoría de Yocto, pero casi nunca me he topado con los problemas que lamenta el artículo. Normalmente pasa al revés: aun cuando Yocto es la mejor opción, el cliente insiste en evitarlo y toca convencer a la gerencia
  Aun así, se entiende que Yocto genere rechazo. Es difícil, confuso, lento, y las herramientas podrían ser mejores. Pero no sé si haya una alternativa real, y me da curiosidad si en el mundo BSD existe algo parecido

  • No sé qué tan parecido sea a Yocto, pero la forma general de crear imágenes para sistemas embebidos en FreeBSD es NanoBSD
    https://docs.freebsd.org/en/articles/nanobsd/
  • No lo he usado a fondo en producción y quizá esté menos pulido que Yocto, pero buildroot tiene varias cosas bastante buenas
    Principalmente lo he usado en el contexto de Nerves, que básicamente es una combinación de buildroot + fwup + la VM de Erlang y software de soporte. Me pareció bastante cómodo para desarrollar, empaquetar y desplegar sistemas Linux embebidos
  • No trabajo directamente con sistemas Linux/BSD embebidos, pero desde mi experiencia usando NetBSD, su sistema de compilación build.sh por sí solo parece suficiente
    Permite compilar de forma cruzada el kernel y el espacio de usuario con facilidad. Si al final necesitas agregar aplicaciones de pkgsrc o incluir un bootloader como u-boot en la imagen generada, quizá haga falta algo de scripting. Puede que no sea un flujo ya resuelto y personalizable de inmediato para una aplicación concreta, pero como base está bien
  • NetBSD está diseñado para facilitar la compilación cruzada hacia entornos limitados y, una vez que le agarras la onda, resulta bastante cómodo

• Por mi experiencia limitada, habiendo sufrido un poco los horrores del mundo embebido, NixOS me funcionó bastante bien para este tipo de uso, y sus herramientas de compilación eran mucho mejores que las de Yocto

  • Me pregunto si también será así en dispositivos ARM. Tenía la impresión de que el ecosistema de NixOS todavía estaba un poco verde para ese tipo de equipos

• Justo en la empresa empezamos a planear y construir un kernel y una distribución Linux personalizados para dispositivos basados en Rockchip, así que el artículo llega en buen momento
  El BSP parece tener bastante que mantener, y usar Debian “tal cual” se ve mucho más manejable que mis tareas de bitbake escritas de forma desastrosa. Aun así, el ecosistema de Yocto en sí está bastante bien, y hay herramientas como kas o isar que facilitan empezar

  • Por el README de isar, parece que no está basado en Yocto sino en Debian. Me pregunto si es común mezclar ambos
    En el artículo lo plantean como Yocto o Debian, no como un enfoque que combine los dos