Fins ara, si tenies una flota de dispositius Ubuntu repartits pel territori els podies actualitzar, vigilar i mantenir sota control des d’un sol lloc. Però quan baixaves al nivell dels microcontroladors (els xips que mouen sensors, vàlvules o ràdios amb només uns quants kilobytes de memòria) aquell model s’acabava i havies de muntar consoles i processos a part. Canonical va anunciar el 18 de juny de 2026 una integració amb Golioth que tanca aquest forat: la plataforma de gestió de microcontroladors de Golioth arriba empaquetada com a snap dins d’Ubuntu Core.
Com funciona: el patró gateway
Cada microcontrolador no parla directament amb el núvol. Un dispositiu Ubuntu Core fa de concentrador local per als nodes propers. El snap de Golioth s’executa com un procés de sistema aïllat i estrictament confinat, tradueix protocols (BLE, sèrie, Wi-Fi HaLoW, cablejat) i reenvia les dades xifrades al núvol de Golioth.
L’exemple que posa Canonical és aclaridor: un Qualcomm Dragonwing IQ9 pot allotjar alhora un model d’IA local exigent, executar les teves aplicacions de negoci com a snaps i actuar de gateway Golioth per a desenes de nodes Bluetooth propers. Tot a la mateixa màquina, amb la separació entre sistema base i càrrega de treball que ja coneixes d’Ubuntu Core.
Al costat dels microcontroladors, els exemples concrets són el Nordic nRF52840 (capaç de funcionar durant anys amb una pila petita i despertar-se en microsegons) i la sèrie STM32. Aquests xips executen Zephyr RTOS, que al post descriuen com “l’estàndard de facto” del desenvolupament de microcontroladors connectats, amb el seu kernel, la seva capa d’abstracció de maquinari i els paquets de suport de placa.
Què aporta Golioth
Les capacitats que s’esmenten són les que esperaries d’una gestió de flotes seriosa, ara estesa a xips diminuts:
- Actualitzacions OTA amb rollback. Pots enviar firmware a un dispositiu concret o a tota la flota, amb tornada enrere incorporada si alguna cosa falla.
- Seguretat per certificat. Cada dispositiu rep el seu propi certificat a fàbrica i s’usa TLS mutu amb rotació de certificats via PKI/OpenID Connect. Per als microcontroladors connectats s’usa CoAP sobre DTLS; per als nodes Bluetooth, el xifratge d’extrem a extrem de Pouch.
- Streaming de dades en temps real. LightDB Stream, la base de dades de sèries temporals de Golioth, juntament amb Pipelines per encaminar les dades.
- Logging remot. Els logs del dispositiu es transmeten per Golioth Pipelines a qualsevol destinació, sense cable sèrie pel mig.
El protocol Pouch i la qüestió de la memòria
La part més interessant a nivell tècnic és Pouch, un protocol de capa d’aplicació agnòstic del transport. Permet transmetre dades de manera segura i eficient entre nodes que estan desconnectats de forma intermitent i a través de diversos salts de xarxa. I ho fa en dispositius amb menys de 100 KB de flash i memòria, que és on la majoria de solucions de gestió es rendeixen.
Aquest límit no és teòric. El post llança una pregunta que resumeix bé el problema: com rotes certificats en un dispositiu amb 256 KB de flash? Quan treballes amb menys d’un megabyte de flash, cada byte compta i no hi pots encabir una pila de client pesada.
Per què t’importa
Si gestiones maquinari de camp, això vol dir que el mateix model operatiu d’Ubuntu Core (OTA, visibilitat de flota, seguretat estricta) baixa ara fins als microcontroladors sense haver de muntar un segon sistema de gestió en paral·lel. El post també emmarca l’anunci en la regulació: el Cyber Resilience Act europeu i els marcs de ciberseguretat d’IoT als EUA estan convertint la rotació de certificats i les actualitzacions de seguretat en requisits obligatoris, no en una cosa opcional.
Si vols entendre millor com encaixa el format snap en tot això, tenim una comparativa de Flatpak, Snap i AppImage que repassa el confinament i l’empaquetatge que aquí es donen per fets.
Font
Informació basada en el post original de Canonical a ubuntu.com/blog. Anunci i detalls tècnics: Canonical.