Auf dem gerade zu Ende gegangenen Ubuntu Summit 2023 im lettischen Riga wurden in einem Vortrag von Produktmanager Oliver Smith und dem technischen Leiter Ken VanDine weitere Informationen zu Canonicals mit Ubuntu 24.04 LTS zu erwartenden Immutable-Distribution Ubuntu Core Desktop enthüllt.
Im Juni stellte Oliver Smith in einem ausführlichen Artikel Canonicals Bestrebungen vor, das bereits seit 2014 entwickelte, containerisierte Immutable-System Ubuntu Core mit einem Desktop auszustatten und als Canonicals Immutable-Variante zu veröffentlichen. Bisher ist Ubuntu Core hauptsächlich für den Bereich Internet of Things (IoT) konzipiert.
Durchgehend Snap
Während Distributionen wie unter anderem Fedora und SUSE bereits seit längerem Immutable-Distros herausgeben, weist der Neuankömmling Ubuntu Core Desktop einige interessante Aspekte auf. Dabei geht es um das Paketformat und die Aktualisierung des Systems, und da kann Canonical einige Vorteile gegenüber der Konkurrenz verbuchen.
Während man bei SUSE für transaktionale Updates und Rollback beim Dateisystem auf die Snapshots von Btrfs angewiesen ist, übernimmt bei Fedora, das ebenfalls Btrfs nutzt, das Git-ähnliche OSTree das Paketmanagement der RPMs und die Aktualisierung des Kernsystems. Für die Anwendungen ist dagegen Flatpak zuständig. Ubuntu Core Desktop hat es hier einfacher. Die Distribution setzt durchgehend auf das hauseigene Paketformat Snap. Das reicht vom Kernel bis zu den Applikationen.
Flexibles Konzept
Während die Konkurrenz bei der Aktualisierung das gesamte Image austauscht, plant Canonical mehr Flexibilität durch mehrere Schichten. Snaps verfügen dazu von Hause aus über mehrere Kanäle mit unterschiedlicher Aktualität: stable, candidate, beta, und edge. So soll man unter anderem den Kernel ebenso wie die Desktop-Schicht separat austauschen können, sodass ein Gamer etwa problemlos zu einem neuen Kernel mit besserer NVIDIA-Unterstützung oder einer alternativen Desktop-Umgebung greifen kann. Der ehemalige Canonical-Mitarbeiter Alan Pope zeigte an anderer Stelle der Konferenz ein Steam-Deck mit Ubuntu Core, ein ausführlicher Blogeintrag stellt sein Projekt näher vor.
LXD-Container
Weiterhin geplant ist ein LXD-Container zur abgekapselten Software-Entwicklung, in dem auch DEB-Pakete installiert werden können. Eine Anmeldung bei Microsofts Active Directory ist ebenso angedacht wie die Unterstützung für Canonicals Systemverwaltungstool Landscape. Auch Canonicals neue TPM-Verschlüsselung ist mit von der Partie.
Ubuntu Core Desktop hat noch einige Release-Blocker zu beseitigen, wie die Entwickler am Ende ihres Vortrags betonen. Wenn alles gut geht, so verspricht das Konzept ein spannendes Konkurrenzprodukt zu den bereits vorhandenen Angeboten im Bereich der unveränderlichen Distributionen.
Ja wer denkt er braucht so etwas, der solls nehmen.
Niotwenig ist es nicht wirklich, eher wieder ein Verkaufsanschub fuer die distrofirmen.
Ja, unbedingt noch mehr Container! Ach was! Lasst uns am besten alles statisch in einen riesigen Monolithen linken! Nennen wir ihn Uber-OneContainer-Linux!
Du willst ein 1 kB großes Skipt aktualisieren? Dann zieh Dir noch heute das neue Uber-OneContainer-Linux! Sind nur Drölfzig Gigabyte…
Dank unserem Komplexitätsverstärker “Immutable” muss sich auch niemand mehr Gedanken über so lästige Dinge wie Sicherheit, Architektur und Ressourcenverbrauch machen. Darum kümmern sich nämlich die Hersteller der Container, statt der Distributionsanbieter…
Mal im Ernst. Ich verstehe die Leute nicht, die Container auf ihren Servern einsetzen. Wer Container in Produktivsystemen einsetzt, hat in meinem Augen sein Leben nicht mehr im Griff. Container sind für einen schnellen Entwickler-Test gut, aber doch bitte nicht für komplette Produktivsysteme.
> Container sind für einen schnellen Entwickler-Test gut, aber doch bitte nicht für komplette Produktivsysteme.
Hast du schon mal verschiedene Webservices mit unterschiedlichen Ansprüchen an die Umgebung auf einer Hardware aufgesetzt? Ein Server, eine Umgebung, eine Aufgabe … und das mehrfach auf einer Hardware. “Hersteller der Container” wärst in dem Fall du selbst. Als OS für die Container nimmst du natürlich eins das du kennst. Schon hast du was du willst.
Eine Hardware mit Containern oder virtuellen Maschinen besser auszunutzen ist keine Schlechte Idee. Vielleicht sind andere Container-Konzepte üblerer Natur, aber nicht alle Anwendungsfälle oder “die Container” per se.
Du hat ja so Recht! Webservices sind was völlig anderes, was total neues. Wie konnte die Unix-Welt nur all die Jahre zig Services auf einem System hosten? Und auch noch für zig Anwender gleichzeitig? Und dazu noch performant. Heute braucht man für statische Webseiten bereits ein CMS mit dicker DB, PHP, JS, CDNs und noch drölfzig zusätzlichen Layern. Da werden Container sicher helfen…
🙂
> Wie konnte die Unix-Welt nur all die Jahre zig Services auf einem System hosten?
Irgendwie geht’s immer.
> Und dazu noch performant.
kommt auf die Last an.
> Heute braucht man für statische Webseiten bereits ein CMS mit dicker DB, PHP, JS, CDNs und noch drölfzig zusätzlichen Layern.
Du überziehst … obwohl, bei der “Fettigkeit” heutiger CMS/ERP Anwendungen …
> Da werden Container sicher helfen…
Nicht alle Anwendungsfälle sind der Art blödsinnig.
> Wie konnte die Unix-Welt nur all die Jahre zig Services auf einem System hosten?
Ich behaupte jetzt mal, dass die meisten System auf spezielle Aufgaben getrimmt waren und immer noch sind. Mailserver, Webserver, Socketserver, etc. Nicht ohne Grund.
Das machst Du doch selbst schon bei der Installation.
Ja, natürlich.
Wenn ich jetzt aber mehrere dieser Installationen unabhängig voneinander auf einer Hardware betreiben möchte, beispielsweise um Ressource besser auszunutzen, dann empfinde ich es als eine gute Lösung pro “Server” einen LXC aufzumachen. Gerade wenn der eine z.B. JAVA und Spring will, der andere aber PHP und MySQL.
Da wären wir bei dem Stichwort: Ressourcen. Früher war alles besser 🙂
Nee aber frueher herrschte eine andere coding kultur.
Man raeumte seinen code auf, optimierte ihn und entfernte nutzloses,
was nat. zur Folge hatte, das er weniger resourcen verbraucht.
Ausserdem integrierte man nicht jeden Scheissdreck in sein Programm.
In dem haste mit “Frueher war alles besser” schon recht.
…ich verstehe Leute nicht, die es *nicht* tun: Habt ihr nichts anderes zu tun? Wollt ihr wirklich für jeden fu..ing Dienst einen eigenen Host betreiben (und sei es auch nur eine VM), provisionieren, warten,backuppen und upgraden? Euch bei einem PHP- und Datenbank-Versionsupgrade jedesmal einen abkrampfen, um das mit dem Zoo an wählerischen Webservices lauffähig zu machen? Eure Dienste-Konfigurationen und Mountpoints auf unzählige Orte verteilen und den Überblick verlieren, wo ihr anno Dunnemals mal was angepasst habt? Nööö, natürlich nicht, lieber gleich für jeden Furz ein Ansible-Playbook schreiben… :-/
Nicht mit mir. Alleine schon aus Sicherheitsgründen laufen bei mir mehrere Dienste in isolierten Containern / Namespaces, meistens sogar in einer VM die den ganzen Containerpark gemeinsam hostet und Snapshots vor Upgrades ermöglicht. Ganz davon abgesehen, das containerisierte Services gewaltige Vorteile bieten, wenn es gilt, Dienste in kürzester Zeit zwischen unterschiedlichen Hostern / Hosting-Umgebungen zu migrieren…
Was bitte ist eine Cloudanwendung? oder generell cloud?
An der Stelle habe ich laut gelacht:
… Wollt ihr wirklich für jeden fu..ing Dienst einen eigenen Host betreiben…
Das ist in meinem Augen der Denkfehle heutiger ITler. Bitte nochmal nachdenken, worin der Unterschied zwischen einem Server und einem Service besteht. Hinweis: 1:n Beziehung.
…du wirst erst richtig zu lachen haben, wenn Du mehrere Dienste auf einem Host beteiben willst, die unterschiedliche PHP-Versionen erfordern. Oder wenn der Dienst eine bestimmte PHP-Version erfordert, die die von anderen Diensten auf dem selben Host verlangte Distro-Version gar nicht mitbringt. Oder wenn dein Hosting-System sicherheitstechnisch veraltet, weil der Dienst partout auf bestimmten Kernelversionen und -konfigurationen besteht. Das ist sowas von lustig, das brauch’ ich unbedingt jeden Tag…
Also in meine 30 Jahren Unix/Linux im bussiness ist mir das nicht begegnet, das sowas nicht loesbar war. ggf. haste es eben schnell reincompiliert, alles kein Thema.
Lass der hat garnichts begriffen 🙂
Eine Suchmaschine kann Dein PHP Problem in 5 sec lösen. Nennt sich PHP-FPM.
Und zum Rest: Wer abgeranzte OS/SW-Versionen ohne Support oder Hoster mit Sicherheitslücken verwendet, dem ist nicht zu helfen. Da bringen auch Container keine Sicherheit.
Klingt interessant. Immer mehr beliebte Apps kann man ja schon jetzt im Store finden. Jetzt muss Snap nur noch genauso gut funktionieren wie Flatpak. 23.10 jedenfalls ist deutlich ein Sprung nach vorne.