© Denis Putilov / 123RF.com

Canonical ködert Hersteller von IoT-Geräten mit Ubuntu Core. Das Mini-Ubuntu steht für diverse SoCs zur Verfügung, kommt seitens des Herstellers mit etlichen Tools und Updates, vermag am Ende aber trotzdem nur eingeschränkt zu begeistern: Wer alle Funktionen wirklich nutzen möchte, zahlt kräftig drauf.

Eines kann man Canonical wirklich nicht nachsagen – nämlich dass der Hersteller nicht nach jedem Strohhalm greifen würde, sein Linux-Geschäft endlich profitabel zu machen. Seit Dekaden geht in der IT und besonders in der Open-Source-Community das Bonmot um, Canonical sei eigentlich nur eine Geldvernichtungsmaschine für Mark Shuttleworth, der entsprechend regelmäßig auch als Mäzen des Produkts betitelt wird, obwohl Eigentümer eigentlich näher dran wäre.

Ubuntu Core [1] ist für die kommerziellen Bestrebungen Canonicals ein gutes Beispiel: Früher als die Konkurrenz aus Nürnberg oder Raleigh nämlich war Canonical mit einer Linux-Distribution am Start, die speziell auf die Bedürfnisse der IoT-Klientel abzielt und diese mit einer umfassenden Plattform samt Managementwerkzeugen, Flottenverwaltung und einer ausgefuchsten Update-Strategie ködert.

In gewisser Weise geadelt haben Red Hat und Suse Canonical dadurch, dass sie Elemente und Prozesse von Ubuntu für ihre jeweiligen Mini-Distributionen übernommen haben. Galt Ubuntu Core vor ein paar Jahren noch als echte Innovation, handelt es sich heute eher um eine von vielen Kleindistributionen, die auf IoT-Geräte, Edge und ganz generell auf alle Einsatzbereiche abzielen, in denen man kein klassisches Linux mit allen Komponenten benötigt.

Dieser Artikel fühlt dem Produkt auf den Zahn und schaut, ob es weiterhin Alleinstellungsmerkmale gibt, was bei Ubuntu Core in besonderer Weise positiv oder negativ auffällt und ob das Produkt hält, was sein Hersteller verspricht.

Die Basics

Ein großer Unterschied zu den anderen Herstellern fällt sofort auf, wirft man auch nur einen flüchtigen Blick auf Ubuntu Core: Dessen Release-Zyklen laufen asynchron zu denen der Hauptdistribution. Während bei RHEL und Suse also eine Version der jeweiligen Mikrodistribution stets zusammen mit dem Hauptsystem erscheint, ist Ubuntu Core ein eigenes Produkt. Das Erscheinen eines neuen Ubuntu Linux bedeutet also nicht automatisch auch die Verfügbarkeit einer neuen Version von Ubuntu Core.

Unterschiede ergeben sich dadurch auch in Sachen Entwicklungsarbeit und Kompatibilität: Zwar enthält Ubuntu Core die nötigsten Komponenten, die man auch auf einem normalen Ubuntu-System erwarten würde. In Sachen Systemkonfiguration resultieren daraus allerdings große Unterschiede, sodass ein Ubuntu Core nicht einfach nur ein Ubuntu-Grundsystem mit weniger Paketen ist.

Was bekommen Unternehmen, wenn sie sich für Ubuntu Core entscheiden? Den Kern des Systems bildet eine stark abgespeckte Variante von Ubuntu Linux mit einem eigens für IoT und Edge-Geräte optimierten Kern (Abbildung 1). Der Core-Kern beherrscht etwa etliche Zusatzfunktionen für Real-Time-Computing, deren Existenz im klassischen Ubuntu-Kernel eher keinen Sinn ergäbe. Stark abgespeckt ist dabei wörtlich zu nehmen: Mit Ausnahme einiger weniger Werkzeuge, einer Laufzeitumgebung für Container im Snap-Format und Systemd enthält das Core-System nämlich nichts, was man auf typischen Ubuntu-Systemen erwarten würde.

Abbildung 1: Ubuntu Core verspricht fertige Golden-Master-Abbilder für typische IoT-Geräte wie Intels NUC. Quelle: Intel

Böse Zungen bezeichnen Ubuntu Core als Distribution, die gerade so vermag, Container zu starten. Was wie ein mickriger Funktionsumfang wirkt, ist de facto allerdings genau so gewollt. Um das nachvollziehen zu können, hilft es, sich einige der klassischen Probleme vor Augen zu halten, die auf IoT und Edge gemünzte Distributionen regelmäßig haben. Derer gibt es in der Tat einige.

Wie IoT herausfordert

Mit zu den größten Problemen gehört, dass der Hersteller eines IoT-Geräts nicht mehr davon ausgehen kann, unmittelbaren administrativen Zugriff auf Systeme zu haben, nachdem diese an Kunden ausgeliefert wurden. Das erschwert Updates in mehrerlei Hinsicht deutlich: Einerseits stellt sich die Frage, wie sich Updates für eine Flotte von über die Welt verstreuten IoT-Geräten technisch überhaupt bewerkstelligen lassen.

Push oder Pull – sollen die Geräte also regelmäßig beim Hersteller nachfragen, ob es Updates gibt, oder soll dieser die Geräte informieren? Variante 1 ist schon deshalb schwierig, weil viele Nutzer sehr zu Recht äußerst allergisch darauf reagieren, wenn einzelne Geräte unter ihren Fittichen ungefragt nach Hause telefonieren. Variante 2 ist aus Anbietersicht deutlich komplexer zu implementieren, schon weil etwa Systeme hinter Firewalls oder NAT-Routern sich von außen gar nicht so einfach erreichen lassen. Notgedrungen verwenden viele Unternehmen deshalb den Pull-Mechanismus und bitten ihre Anwender in irgendeiner Form um Erlaubnis.

Das Permission-Thema ist allerdings nur eines von vielen. Selbst wenn der Nutzer zustimmt – wie stellt der Anbieter sicher, dass er Updates in der Breite sinnvoll auf die Straße bekommt? Wie implementiert er einen Modus Operandi, der im Falle eines Falles auch ein Rollback ermöglicht? Ein fehlgeschlagenes Update, das dazu führt, dass abertausende IoT-Geräte irgendwo in der Welt nicht mehr funktionieren, ist schließlich für jeden Anbieter nicht weniger als ein mittelschwerer Alptraum, der im Zweifelsfall sogar zum Ruin führen kann.

Gar keine Updates sind indes auch keine Lösung: Auf Sicherheitsaktualisierungen kann man heute nicht verzichten, damit Ganoven aus dem Netzwerk smarter Geräte nicht ein riesiges Botnet bauen. Zudem schadet es auch nicht, einen Weg zu haben, über den sich funktionale Updates ausrollen und Fehler in bestehender Software beseitigen lassen.

Snaps für alles

Vergleicht man die oben beschriebenen Anforderungen mit der Realität, die Admins bei der Administration ihrer Systeme jeden Tag erleben, erkennt man schnell Differenzen. Zwar beherrschen die allermeisten Distributionen mittlerweile Updates für laufende Pakete im Rechenzentrum, doch eine Garantie dafür gibt es nicht. Wer schon einmal Pakete für eine Linux-Distribution gepflegt hat, der weiß zudem, dass Fehler sich an den absurdesten Stellen einschleichen und trotzdem riesige Nachwirkungen haben können.

Ubuntu Core geht deshalb einen radikalen Weg. Im Herzen des Systems läuft zwar weiterhin der bereits beschriebene Linux-Kernel, doch wird das gesamte Userland rundherum in Form von Snap-Paketen ausgeliefert. Zur Erinnerung: Snap ist Canonicals eigenes Format für ausführbare Container (Abbildung 2). Die unterscheiden sich von klassischen Paketen vor allem dadurch, dass sie vollständig “self-contained” sind, also ohne externe Abhängigkeiten auskommen.

Abbildung 2: Snaps sehen von außen aus wie normale Pakete; de facto handelt es sich jedoch um Container-Abbilder, die neben den Programmen auch die benötigten Bibliotheken enthalten.

Anhand eines Beispiels lässt sich das besser verdeutlichen: Ein MariaDB-Snap enthält neben der Datenbank selbst auch alle Bibliotheken, die für ihren Betrieb nötig sind. Die Installation eines MariaDB-Snap-Pakets genügt mithin, um auf dem Server eine echte Datenbank zu betreiben. Soll die Datenbank ein Update erhalten, kann man einfach den alten Snap löschen und einen neuen installieren. Den Pfad für die persistente Speicherung von Daten hängt die Laufzeitumgebung für Snap-Container der Datenbank beim Start einfach dynamisch in das lokale Dateisystem innerhalb des Snaps ein.

Neu ist all das freilich nicht: Im Kern greift Snap dieselben Ideen auf, die auch Docker einst nutzte, um Container unter Linux salonfähig zu machen. Ubuntu Core treibt das Spiel allerdings noch einige Stufen weiter, denn hier besteht ja fast das gesamte System aus einzelnen Snaps. Die lassen sich zwar lokal nicht verändern, wohl aber aus der Ferne aktualisieren und schaffen so eine unveränderliche (immutable) Umgebung.

Ein Kessel Buntes

Rundherum verspricht Canonical ein Füllhorn an Funktionen. Für etliche IoT-Geräte und SoCs (Abbildung 3), wie sie in IoT- und Edge-Anwendungen typischerweise zum Einsatz kommen, stellt der Anbieter fertige Abbilder von Ubuntu Core zur Verfügung. Diese sind kuratiert, haben beim Hersteller also eine Vielzahl spezieller Tests durchlaufen und dürfen deshalb als sicher und zuverlässig gelten. Allerdings bietet Canonical auch die Möglichkeit, modifizierte Abbilder zu bauen, die als Artefakt aus einem CI/CD-System herausfallen. Das betreibt auf Wunsch der Hersteller oder das jeweilige Unternehmen selbst.

Abbildung 3: Auch für das klassische SoC-System Raspberry Pi stehen fertige Abbilder in etlichen Versionen für Ubuntu Core bereit; die RasPis sind eine Zielplattform der Distribution. Quelle: Raspberry Pi

Canonical lässt allerdings auch wenig Zweifel daran, dass das nicht die Art und Weise ist, wie Unternehmen Ubuntu Core eigentlich nutzen sollen. Das Zauberwort in der Dokumentation des Anbieters lautet stattdessen Custom Brandstores, mit denen Unternehmen eigene Snaps für Ubuntu Core anbieten können.

Mit Versprechen geizt Canonical insgesamt also nicht. Überfliegt man nur flüchtig das Marketing-Material zu Ubuntu Core, stößt man auf Begriffe wie “zehn Jahre Support für das System” und “eigene Snap-Stores für externe Unternehmen”. Liest sich doch hervorragend: Ubuntu Core ist kostenlos, bietet eine stabile Plattform inklusive Updates für die Entwicklung einer eigenen IoT-Distribution und auf Wunsch sogar noch die nötige Infrastruktur dafür. Firmen setzen sich ins gemachte Nest und genießen.

Licht und Schatten

Wer im vorangegangenen Absatz leichten Sarkasmus erkannt zu haben glaubt, liegt nicht ganz falsch, denn das beschriebene Prinzip wäre für Canonical ohne kommerziellen Nutzen. Und das wiederum würde dem eingangs beschriebenen Ansinnen des Unternehmens diametral entgegen stehen, Gewinn zu erwirtschaften. Wie üblich gilt daher: Wo Licht ist, ist auch Schatten – und Ubuntu Core kommt mit einigen Schatten daher, die sich allerdings erst mit der Zeit offenbaren.

Zum größten Problem wird für Unternehmen dabei regelmäßig eine Funktion, die man im ersten Augenblick eigentlich als herausragendes Feature von Ubuntu Core ansieht, nämlich das strikt in sich geschlossene Ökosystem der Distribution. Es ist zuvor schon angeklungen: Ubuntu räumt Unternehmen zwar grundsätzlich die Option ein, auch eigene Abbilder zu erstellen und zu verteilen, wünscht sich aber eigentlich, dass Firmen Drittanbietersoftware in Form von eigenen Snap-Paketen beisteuern. Praktisch alles in Ubuntu Core ist darauf ausgelegt, zusätzliche Snaps zu installieren und in Snaps als Software zu laufen. Das allerdings geht mit etlichen Problemen einher.

Eines davon ist der Umstand, dass nicht alle Anwendungen gleich gut dafür ausgelegt sind, überhaupt in Containern zu laufen. Ein gutes Beispiel bieten klassische Mehrbenutzeranwendungen wie Own- oder Nextcloud, besonders dann, wenn sie mit Dateien im Filesystem und deren Berechtigungen herumhantieren. Wie schon gesagt, ist es zwar nicht grundsätzlich ein Problem, externe Datenquellen über Bind-Mounts in Snaps einzubinden. Dafür muss jedoch in Ubuntu Core das offizielle Ubuntu-Tooling zum Einsatz kommen, das längst nicht jede denkbare Funktion mitbringt, die eine externe Software vielleicht benötigt. Kleinigkeiten wie das Verwalten von Rechten innerhalb und außerhalb eines Snaps werden dabei zum Problem. Das ließe sich im Kern zwar lösen, was allerdings voraussetzt, dass das Snap-Paket mit einer Anwendung ganz erhebliche Beiträge zur Integration ins System leistet.

Zankapfel Snap

Überhaupt dürfte Snap einer der Hauptgründe dafür sein, dass viele Admins Ubuntus IoT-Distribution eher skeptisch gegenüberstehen. Snap ist per se zwar ein offener Standard, doch die Software für den Betrieb eines App Stores für Snap (Abbildung 4), ist weder frei noch kostenlos zu bekommen. Technisch wäre es zwar möglich, in Ubuntu Core auch Paketverzeichnisse zu aktivieren, die nicht zum offiziellen Ubuntu-Store gehören. Praktisch scheitert das daran, dass andere Firmen als Ubuntu schlicht keinen kompatiblen Store starten können.

Abbildung 4: Snap gilt als geschlossenes System, weil die Server-Software nicht zur Verfügung steht. Ubuntu-Core-Anwender bekommen das zu spüren, weil sie einen Brand Store bei Canonical mieten müssen, ohne den Ubuntu Core nur ausgesprochen mühsam zu modifizieren ist. Quelle: Canonical

In der Community und insbesondere der Open-Source-Gemeinde war Snap aus eben diesem Grund sehr schnell unten durch – umso mehr, weil eine leistungsfähige Alternative in Form des Flatpak-Formats samt Store-Anwendung unter freier Lizenz zur Verfügung steht. Canonical und Mark Shuttleworth hat alle Kritik bisher allerdings gänzlich unbeeindruckt gelassen. Das Unternehmen setzt seit vielen Jahren auf Snap und erzwingt dessen Verwendung immer weiter dadurch, beliebte Apps wie Chromium nur noch als Snap auszuliefern.

Anders formuliert: Canonical nagelt seine Anwender auf ein Paketformat fest, das nur Canonical anbieten kann, sodass es sich um nichts anderes handelt als einen waschechten Lock-in. Unternehmen, die sich für Ubuntu Core als Rückgrat ihrer IoT-Infrastruktur entscheiden, liefern sich Canonical ohne Option auf einen Wechsel zu einer anderen Lösung aus. Und gerade weil Ubuntu Core aus Funktionalitäts- und Sicherheitsgründen so strikt beschränkt ist, lässt das Problem sich kaum umgehen.

Und das ist noch nicht die letzte schlechte Nachricht im Hinblick auf die Art und Weise, wie der Hersteller sich das Zuliefern von Software für Ubuntu Core wünscht. Damit es für einen Hersteller überhaupt Sinn ergibt, Ubuntu Core auf seinen IoT- und Edge-Geräten zu verwenden, benötigt er mehr als das nackte Mini-Betriebssystem. Das weiß selbstredend auch Canonical und räumt Unternehmen die Möglichkeit ein, einen eigenen Brand Store auf den Servern für Ubuntu zu bekommen. Der dient dann explizit dazu, spezielle Snaps einzelner Hersteller für eben deren IoT-Geräte zu verteilen. Das klingt zunächst wieder einmal toll, kommt aber eben auch mit einem eher nicht dezenten Preisschild von knappen 30 000 US-Dollar daher. Damit sich der Kauf der Funktion für Firmen überhaupt finanziell lohnt, müssen sie also schon einige IoT- oder Edge-Geräte unters Volk bringen.

Die Sache mit den Updates

Einen weiteren separaten Blick verdient zudem das Thema Updates. Auf dem Papier leistet Canonical hier Großartiges und verspricht “bis zu zehn Jahre Updates” – man beachte das “bis zu”. Liest man das Kleingedruckte, holt einen schnell die Realität ein. Dann stellt man nämlich fest, dass die zehn Jahre Support überhaupt nur im Rahmen eines erweiterten Support-Vertrags für Brand Stores verfügbar sind.

Das Grundsystem muss sich hingegen mit maximal fünf Jahren Support begnügen, wenn man den Brand Store hinzunimmt. Ansonsten reduziert der Support-Zeitraum sich sogar auf drei Jahre. Dass es wirtschaftlich kaum machbar ist, alle drei Jahre ein komplett neues Ubuntu-Core-Release auf hunderttausende IoT-Geräte auszurollen, liegt auf der Hand. Auch hier steht man ohne den Einwurf von vielen Münzen letztlich also im Regen.

Beispiel NextBox

Dass alle diese Bedenken praktisch relevant und nicht nur bloße Theorie sind, zeigt das Beispiel NextBox (Abbildung 5) des Herstellers Nitrokey eindrücklich. Deren Entwickler haben in einem ausführlichen Blog-Eintrag [2] erläutert, warum sie sich zuerst für Ubuntu Core und später doch gegen das Produkt entschieden haben – zu einem Zeitpunkt wohlgemerkt, als bereits erhebliche Mittel in die Kommunikation mit Canonical und die Entwicklung geflossen waren.

Abbildung 5: Die NextBox-Entwickler begannen die Arbeit an ihrem Produkt mit Ubuntu Core, landeten später jedoch bei einer eigens gebauten Mikrodistribution auf Debian-Basis. Quelle: NextBox

Die Idee hinter NextBox war relativ simpel: Geplant war ein IoT-Gerät auf Basis eines Raspberry Pi, das ein vorkonfiguriertes und vorpaketiertes Nextcloud enthalten und den Betrieb einer Nextcloud-Instanz in heimischen Gefilden möglich machen sollte. Ein Speichermedium sollten Anwender selbst beisteuern, was freilich den Vorteil mit sich bringt, dass der Endanwender Art und Größe des Speichermediums selbst bestimmen kann. Zumindest auf dem Papier fallen die Kosten für das Laufwerk damit nicht ins NextBox-Budget, was es ermöglichte, das Gerät zu einem relativ günstigen Preis anzubieten.

Als Nitrokey auf die Suche nach einer geeigneten Softwarelösung für das geplante Produkt ging, landete der Hersteller schnell bei Ubuntu. Einerseits war Ubuntu als Betriebssystem für Server im Unternehmen etabliert und entsprechendes Fachwissen vorhanden. Andererseits versprach insbesondere Ubuntu Core im Gegensatz zu einer selbstgebauten Lösung auf Basis von Debian GNU/Linux eine deutlich kürzere Spanne bis zum Marktstart. Den größten Teil des Benötigten, so glaubte man bei Nitrokey, hätte Ubuntu ja ohnehin an Bord. Ein fertiger Snap für Nextcloud findet sich im offiziellen Snap-Store ebenfalls. Nitrokey würde also bloß noch die Konfiguration und einige spezielle Funktionen beisteuern müssen.

Technische Probleme

Bald allerdings geriet das Projekt in schwieriges technisches Fahrwasser. War man einerseits bereit, sich an etliche Vorgaben von Ubuntu Core anzupassen, gab es andererseits technische Notwendigkeiten, die die Nitrokey-Leute beim besten Willen nicht umgehen konnten.

Also schmiedete man einen Plan: Canonical ermöglicht es grundsätzlich, Änderungen am Grundsystem von Ubuntu Core vorzunehmen, wenn diese in Form eines sogenannten Gadget Snaps daherkommen. Hat eine Firma einen solchen Gadget Snap erst einmal in Canonicals Snap-Store hochgeladen, lässt er sich in modifizierte Abbilder von Ubuntu Core integrieren, die Canonicals Build-System auf Zuruf durch Nutzer oder Hersteller generiert.

Nachdem Nitrokey einen entsprechenden Gadget Snap erstellt und in den Snapstore hochgeladen hatte, klärte Canonical das Unternehmen darüber auf, dass solche Pakete nur mit Brand Stores möglich seien. Unter der Prämisse, 30 000 US-Dollar pro Jahr allein für diese Zusatzfunktion erwirtschaften zu müssen, hätte NextBox als Projekt allerdings seinen kommerziellen Reiz verloren.

Für den PoC entschied man sich bei Nitrokey um und tat, was Open-Source-Firmen in solchen Fällen eben tun: Man baute ein modifiziertes Ubuntu-Core-Abbild, das früh im Boot-Vorgang den Zugriff auf sämtliche Systemressourcen als Root erlaubte und mithin einen großen Teil der Ubuntu-Core-Einschränkungen umging. Das verbesserte die Situation allerdings kaum, denn im Nachgang geschahen gleich mehrere Dinge: Einerseits meldete sich Canonical bei Nitrokey und versprach Hilfe. Was daraus letztlich wurde, war bis Redaktionsschluss nicht herauszufinden; zumindest am Ende des Blog-Eintrags von 2021 war in Sachen Kooperation zwischen Canonical und Nitrokey jedenfalls nicht viel weitergegangen.

Andererseits aber, und das war das größere Problem, kamen durch den – in den Augen Canonicals – kruden Hack von Nitrokey mehrere Schwachstellen des Produkts zum Vorschein. Ein Update von Ubuntu Core 18, das seinerzeit aktuell war, auf Ubuntu Core 20 wäre im Feld etwa nicht ohne Weiteres möglich gewesen. Obendrein sorgte die technische Änderung dafür, dass Canonicals Verwaltungssystem für Flotten von Ubuntu-Core-Geräten alle NextBox-Geräte weltweit als ein und dasselbe System erkannt hätte, was die Managementwerkzeuge letztlich nutzlos macht.

Notbremse

Schließlich zog Nitrokey die Notbremse und verwarf sämtliche Überlegungen zum Thema Ubuntu Core. Das ist eingedenk der Arbeit, die zu diesem Zeitpunkt bereits in das Projekt geflossen war, durchaus bemerkenswert, führte aber auch zu einer verblüffenden Erkenntnis.

Wegen des vorhandenen Ubuntu- und Debian-Wissens im Unternehmen entschied man sich dafür, eine eigene Mini-Distribution zu bauen, die auf die Bedürfnisse von Nextcloud perfekt abgestimmt sein sollte. Das gelang schnell, zum Teil auch, weil man sich am Ubuntu-Core-Design orientieren konnte, dessen nervige Details aber ausließ.

Statt Snaps kommt in der für die NextBox entwickelten Linux-Distribution auf Debian-Basis etwa Docker zum Einsatz; andere Werkzeuge wie eine CI/CD-Umgebung liefert Debian ebenfalls mit. A priori festgelegt war Nitrokey nach dem Scheitern mit Ubuntu Core übrigens nicht. Alternativ hatte das Unternehmen sich auch BalenaOS und OpenEmbedded angesehen, fand diese aus verschiedenen Gründen allerdings ungeeignet.

Der Vollständigkeit halber sei erwähnt, dass sich die Erkenntnisse aus der Causa NextBox freilich nicht eins zu eins auf beliebige andere Projekte umlegen lassen. Debian GNU/Linux funktionierte für NextBox am Ende auch deshalb, weil die Distribution seit vielen Jahren eine Portierung auf die diversen Raspberry-Pi-Modelle pflegt, der Hardwareplattform von NextBox. Andere Embedded Devices mit unterschiedlichen SoCs unterstützt Debian vermutlich schlechter als etwa Ubuntu Core, sodass es in der Regel auf einen Versuch ankommen dürfte.

Fazit

In Summe fällt das Fazit zu Ubuntu Core gespalten aus. Klar ist, dass es sich bei Ubuntu Core nicht um eine Fortsetzung der Distribution mit reduzierten Mitteln handelt, wie es bei den Mini-Distributionen von Red Hat und Suse der Fall ist. Ubuntu Core richtet sich also nicht als Container-Betriebsplattform auch an jene Admins, die ein möglichst schlankes Grundsystem für den Betrieb ihrer Container benötigen. Dafür eignen sich andere Ansätze besser, zum Beispiel Open Suse Leap Micro oder auch CoreOS von Red Hat.

Im Gegensatz zu diesen ist Ubuntu Core klar auf IoT-Umgebungen gemünzt. Tatsächlich bietet Canonical hier viel Funktionalität. Im Gegenzug müssen Firmen allerdings auch in Kauf nehmen, sich dauerhaft und praktisch irreversibel an Canonical zu binden. Ein gewisses Risiko ist dabei durchaus gegeben: Über das Fortbestehen von Canonical und dessen einzelne Produkte lassen sich zuverlässige Aussagen kaum treffen, wenn sie Jahre oder Jahrzehnte in die Zukunft reichen sollen. Gleichzeitig lässt sich absehen, dass sich im Falle eines Falles Ubuntu Core auf betroffenen Zielgeräten nicht ohne Weiteres durch ein anderes System ersetzen ließe.

Völlig uninteressant ist das Produkt darüber hinaus für Projekte etwa aus der Open-Source-Community, die die horrenden Gebühren für einen Branded Snapstore nicht zahlen können. Ohne diesen lassen sich die meisten Funktionen von Ubuntu Core gar nicht erst sinnvoll nutzen. Wer unbedingt Ubuntu Core einsetzen möchte, ist dann auf die Großzügigkeit des Herstellers angewiesen, entsprechende Ressourcen kostenlos zur Verfügung zu stellen.

Insgesamt entpuppt sich Ubuntu Core mithin als zweischneidiges Schwert. Wer auf der Suche nach der Basis für eigene IoT- oder Edge-Entwicklung ist, sollte jedenfalls auch mögliche Alternativen in die eigene Auswahl einbeziehen. Nitrokey hat es ja bereits vorgemacht: Was anfänglich nach sehr viel Entwicklung aussieht, kann sich finanziell und technisch am Ende durchaus lohnen. (jcb)