Zur Eröffnung des Ubuntu Summit 26.04 formulierten Canonical-CEO Mark Shuttleworth und Engineering-VP Jon Seager das Programm der nächsten Monate: Wie liefert man hochfrequent Software aus, ohne dabei Sicherheit und Auditierbarkeit zu opfern? Welche Rolle spielt eine Distribution wie Ubuntu in einem Ökosystem, das zunehmend von autonomen Agenten und proprietären Modellen geprägt wird? Ein Bericht aus dem ersten Konferenztag, und zugleich der Auftakt einer kleinen Serie zum Ubuntu Summit.

Eröffnung in London

Das Summit findet im Canonical-Büro direkt an der Tower Bridge statt, im Saal verteilen sich Vortragende, Crew und Pressevertreter; die eigentliche Community verfolgt das Geschehen über den Livestream und die LoCo-Watchparties, zu denen Ubuntu im Vorfeld weltweit aufgerufen hatte. Die beiden Eröffnungsredner: zunächst Canonical-CEO Mark Shuttleworth, anschließend Jon Seager, seit Februar 2022 VP of Engineering und seit Anfang 2025 für Ubuntu verantwortlich.

Inhaltlich liegt eine Klammer über den beiden Vorträgen, die schon Shuttleworth in seinen ersten Sätzen aufmacht: Open Source stehe im Zentrum einer Welle aus Beschleunigung und Umbruch, die jeden Bereich der Industrie erfassen werde. Diese Verantwortung, das Material zu definieren, aus dem die nächste Generation von Software entsteht, ist nach Shuttleworths Lesart die eigentliche Bühne, auf der Canonical und die Ubuntu-Community in den kommenden Jahren stehen. Wer den Saal an diesem Vormittag verlässt, soll drei Begriffe mitnehmen: Geschwindigkeit, Sicherheit und Community.

Canonical in Zahlen

Canonical-CEO Mark Shuttleworth

Bevor Shuttleworth zu seinen drei Leitthemen kommt, gibt er einen Überblick zur eigenen Firma. Canonical zähle inzwischen rund 1500 Beschäftigte in 80 Ländern, davon etwa 1000 in Softwareengineering-Rollen. Das Unternehmen sei in den vergangenen zwölf Monaten um knapp 20 Prozent gewachsen, damit doppelt so schnell wie die naheliegenden Konkurrenten im Open-Source-Markt, sagt er, ohne diese namentlich zu nennen. Die zurückliegenden sechs Monate seien anstrengend, aber spannend gewesen.

Als Highlights nennt er die jüngste Kooperation mit VMware rund um Kubernetes und Open-Source-Anwendungen für Unternehmen, die Zusammenarbeit mit Qualcomm im IoT-Bereich, eine Kooperation mit NVIDIA für sicherheitskritische Anwendungen, Stichwort Automotive und Industrie, sowie die Arbeit mit AMD, durch die ROCm direkt in Ubuntu eingebettet werde. Letzteres habe das Erlebnis für Entwickler verändert, die mit AMD-GPUs anspruchsvolle mathematische Workloads bauten.

Auffällig dabei: Shuttleworth verkneift sich die naheliegenden Superlative. Er stellt Ubuntu in eine Linie mit Anwendungsfeldern, in denen Robustheit und regulatorische Anforderungen das eigentliche Gewicht haben. Die Kunst sei, zwischen dem Wunsch nach neuester Software und dem Bedarf an Stabilität sauber zu vermitteln, ein Spannungsfeld, das er später konkretisiert.

Das „Curl-zu-Bash-o-Meter“

Den größten Lacher des Vormittags erntet Shuttleworth mit einem Begriff: dem „Curl-zu-Bash-o-Meter“. Es funktioniere wie die Doomsday-Clock: Wer wissen wolle, wie aufgeregt die Branche aktuell sei, müsse nur zählen, wie oft ihm im Netz Installationsanleitungen begegnen, die ein heruntergeladenes Shell-Skript ungeprüft an die Bash weiterleiten. „Right now, we are well on our way“, sagt er, frei übersetzt: Wir sind ziemlich weit vorne.

Hinter dem Witz steht eine ernsthafte These. Die etablierten Prozesse zur Auslieferung von Software, jene Sorgfalt, die Debian seit Jahrzehnten auszeichnet, sind seinem Empfinden nach nicht mehr im Takt mit dem Tempo, in dem Software heute publiziert wird. Schon vor Jahren habe Canonical genau aus diesem Grund nach Alternativen für die Lieferkette gesucht. Das Ergebnis, wenig überraschend an diesem Vormittag, sind Snaps und der Snap Store.

Shuttleworth zeigt einen Screenshot von „Snap Store Updates“, einem unabhängigen Webdienst von Alan „Popey“ Pope, der ebenfalls vor Ort ist. Das Werkzeug synchronisiert alle 15 Minuten den vollständigen Katalog über die öffentliche Snap-Store-API, aktuell über 10.000 Snaps, und protokolliert, was neu hinzukommt und was sich ändert. Stand des gezeigten Screenshots: drei neue und 71 aktualisierte Snaps am laufenden Tag. Der Punkt ist nicht die Zahl an sich, sondern was sie symbolisiert: ein durchgehend signierter Weg vom Publisher zum Endgerät, mit automatischen Updates und konsistentem Verhalten über mehrere Architekturen hinweg. Wer sudo snap install tippe, vertraue zwar weiterhin Fremden mit dem eigenen System, aber mit Signaturen, automatisierten Updates und einem nachvollziehbaren Publisher.

Dass Reddit das, wie Shuttleworth einräumt, „mit zahlreichen Meinungen“ begleitet, ist ihm bekannt. Snaps blieben dennoch der seiner Ansicht nach sicherste Weg, Bits an die Fingerspitzen eines Entwicklers oder eines Anwenders zu bringen, „für jede Linux-Distribution dieses Planeten, Punkt“. Andere containerisierte Mechanismen wie Docker oder Kubernetes adressierten andere Schichten des Problems.

Enterprise Version Control statt Stagnation

Ein Detail in seinem Vortrag ist neu für viele im Publikum. Shuttleworth nennt es Enterprise Version Control: das eingebaute Spannungsfeld zwischen Publishern, die immer das neueste Bit ausliefern möchten, und Konsumenten, die selbst entscheiden wollen, wann eine Veränderung in der Produktion ankommt. Snaps böten dafür ein konsistentes Modell aus Channels (edge, beta, candidate, stable), Hotfix-Branches und schrittweisen Rollouts. Ein Hersteller könne damit zum Beispiel definieren, dass ein Update zunächst nur an ein Prozent der Anwender ausgespielt werde.

Im Default-Fall laufe ein Snap zudem in strikter Confinement, also in einem vom Kernel durchgesetzten Container, dessen Berechtigungen über das Schnittstellenmodell von snapd verhandelt würden. „Strict confinement“, betont Shuttleworth, sei das zentrale Argument für die Containerisierung von Endanwender-Software überhaupt.

Wenn Confinement im Weg steht

Es gebe allerdings Situationen, in denen das Confinement nicht das gewünschte Verhalten sei. Diese Stellen markiert Shuttleworth ebenso deutlich. Wer ein Paket mit snap install <name> --classic installiere, müsse wissen, dass es sich faktisch um eine Form von „curl pipe to bash“ handle, wenn auch mit den anderen, mitlaufenden Eigenschaften des Snap-Modells. Die Software laufe dann ohne Sandbox.

Genau diese Möglichkeit werde im Zusammenspiel mit Coding-Agenten relevant. Wer einen Coding-Agenten produktiv einsetzen wolle, müsse ihm Zugriff auf das System geben. „You unleash the agent“, sagt Shuttleworth, „Sie lassen den Agenten von der Leine.“ Mit snap install opencode --classic tue man genau das: sowohl dem Code als auch dem zugrunde liegenden Modell sage man damit, „du hast die Kontrolle über dieses System“.

Safety: Werkzeugkasten fürs Sandboxing

Sandboxing, so Shuttleworth, sei in einer Welt delegierter Agenten die entscheidende Disziplin. Allerdings wehrt er sich gegen das, was er als Herdenverhalten in sozialen Medien beschreibt: die Tendenz, jedes Problem mit demselben Werkzeug lösen zu wollen. Ubuntu wolle stattdessen einen Werkzeugkasten anbieten, der für jeden Anwendungsfall die passende Form der Isolation bereithält.

Auf einer Folie sortiert er die verfügbaren Schichten:

• Docker-Container für klassische OCI-Workloads
• Snaps für Endanwender-Software mit feingranularen Berechtigungen
• LXD und LXC für System-Container, die einem Agenten ein vollständiges Betriebssystem-Erlebnis vorgaukeln, ohne dessen Ressourcenbedarf zu reproduzieren
• klassische VMs (etwa via Multipass) dort, wo selbst eine kernel-erzwungene Container-Grenze nicht ausreicht
• und, als jüngste Ergänzung, sogenannte microVMs, die Eigenschaften von Containern und VMs miteinander verbinden

Vor allem letztere stellt Shuttleworth in den Vordergrund. In den vergangenen Wochen habe man eng mit NVIDIA an dieser Technologie gearbeitet. Vorbild ist Firecracker im Public Cloud Computing: kleine, schnell startende VMs mit harter Hardware-Virtualisierungsgrenze. Wer heute schon damit experimentieren wolle, könne snap install openshell ausführen. OpenShell stelle microVMs auf Abruf bereit und enthalte vorkonfigurierte agentische Umgebungen, etwa für Claude, Copilot oder eigene Setups.

Agentic Workspaces und „Workshop“

Die meiste Zeit widmet Shuttleworth einem Werkzeug, das viele im Saal noch nicht kennen: Workshop. Hintergrund sei ein Dilemma, das beim Einsatz von Agenten in der Entwicklung zwangsläufig entstehe. Eine Entwicklerumgebung enthalte typischerweise Schlüssel, Zugangsdaten, persönliche und betriebliche Informationen. Genau das wolle man einem Agenten, der an einem externen Modell hänge, eher nicht uneingeschränkt geben.

Workshop sitzt deshalb auf LXD auf und stellt System-Container bereit, die mit einer kuratierten Auswahl an Schlüsseln, Datensätzen und Capabilities bestückt werden. Das Repository enthalte eine entsprechende Konfigurationsdatei, man klone das Repo und tippe workshop launch. Damit, so Shuttleworth, sei der Sprung von null auf produktiv in einer komplexen Codebase nur noch eine einzige Operation.

Das Werkzeug stehe als snap install workshop bereit, derzeit in Version 0.9. Bereits jetzt unterstütze Workshop ein SDK-Konzept: unabhängige Softwareanbieter (ISVs) könnten ihre Werkzeuge als signierte SDKs veröffentlichen, die in einem dedizierten Store verfügbar seien und sich von Workshop in die jeweilige Sandbox einklinken ließen.

Bemerkenswert ist die historische Einordnung, die Shuttleworth liefert. Workshop sei nicht für Agenten erfunden worden, sondern für eine Welt, in der proprietäre und freie Software in derselben Toolchain laufen. Ein Beispiel: Wenn ein Startup eine spannende, aber geschlossene Datenanalyse-Bibliothek ausliefere und man dieses Stück Software als Root auf dem eigenen Laptop ausführe, übergebe man faktisch die Kontrolle an dieses Unternehmen und alle Beteiligten in dessen Build-Pipeline. Genau dieses Szenario verlange seit Jahren nach einer sauberen Sandbox, Agenten seien lediglich der jüngste Anwendungsfall.

Community: Open Source und Open Weights

Den letzten Akzent seiner Keynote setzt Shuttleworth bei der Frage, was Ubuntu in einer Welt ausmacht, in der Produktivität zunehmend an Tokens und damit an die finanziellen Möglichkeiten der einzelnen Nutzer geknüpft ist. Es sei ein Anliegen, das ihn ernsthaft umtreibe, sagt er: Sowohl die wohlhabendsten Anwender, etwa Engineers an einem Hedgefonds, als auch jene, die sich in einem Vorort von Kolkata oder in einer anderen marginalisierten Lage Open Source aneigneten, sollten denselben Zugang zur Plattform haben.

Daraus leite sich eine klare Prioritätensetzung ab: Canonical werde sich beim Thema KI primär auf Open-Source-Coding-Assistenten und sogenannte Open-Weight-Modelle stützen. Proprietäre Werkzeuge blieben relevant, ohne sie sei Wettbewerb und Vielfalt nicht zu haben, aber sie dürften nicht zum Nadelöhr für jene werden, die sich keinen Token-basierten Zugriff leisten könnten. „Wir können beides“, lautet seine Formulierung sinngemäß. Man werde an der vordersten Front mit kommerziellen Partnern arbeiten und gleichzeitig dafür sorgen, dass eine neue Generation von Technikern aufschließen könne.

Jon Seager: zwei Klassen von KI in Ubuntu

Seager übernimmt mit einem Verweis auf einen längeren Blogpost, den er rund zwei Wochen zuvor veröffentlicht hat und der seither, wie er selbstironisch bemerkt, „durch SEO zu Tode optimiert“ worden sei. Wer eine ausführliche Lesart seiner Position suche, finde sie dort. Im Saal sortiert er sie in einer Unterscheidung, die er als noch nicht ganz ausformuliert beschreibt: implizite versus explizite KI-Funktionen in Ubuntu.

Implizite Funktionen seien jene, die in Ubuntu längst existierten und durch den Zugriff auf moderne Modelle still und leise besser werden könnten. Er nennt Accessibility-Funktionen, Screenreader, Sprache-zu-Text, die Verbesserung des Kamerabilds, die Verbesserung von Mikrofonsignalen. Diese Funktionen brauchten keine Trillionen-Parameter-Modelle und keine Cloud-Inferenz; sie ließen sich heute schon auf einem Laptop, oft sogar nur auf der CPU, effizient ausführen.

Bei den expliziten KI-Funktionen sei Vorsicht geboten. Seine Linie: Lieber später als plump. Ein Modell in Ubuntu einzubauen, nur um schneller als die Konkurrenz „da“ zu sein, hält er für wenig sinnvoll. Stattdessen werde Canonical darauf achten, dass eine integrierte KI-Funktion sichtbar einen Nutzen liefere.

Lokale Inferenz und die Rolle der Silicon-Partner

Im Hintergrund werde Canonical, so Seager, weiter auf das Thema lokale Inferenz setzen. Der Abstand zwischen einem leistungsfähigen Vier-Milliarden-Parameter-Modell, er nennt Gemma als Beispiel, und einem cloud-gehosteten Modell mit einer Billion Parametern sei real, werde sich aber in den kommenden Jahren deutlich verkleinern. Die Geschwindigkeit, in der die Silizium-Industrie sich auf allen Größen wandle, sei enorm. Ubuntu wolle gemeinsam mit seinen Hardwarepartnern dafür sorgen, dass Käufer von neuer, oft teurer Hardware deren Fähigkeiten auch ausschöpfen könnten.

Auch beim Thema interner Produktivität bezieht Seager eine klare Position. Er habe nicht vor zu messen, wie viel KI die Mitarbeiter verwendeten, sondern wie es immer schon gemessen worden sei: am Output, an der wahrgenommenen Produktivität, an der Qualität der Arbeit. „I don’t really understand that craze“, sagt er über den Wettlauf um maximalen Tokenverbrauch.

Agenten, Open Source und das nächste Kapitel

Dass Canonical die KI-Konversation nicht vermeiden könne, ist ein zentraler Punkt seines Vortrags. Es werde Stimmen geben, die sich enttäuscht zeigten, dass das Unternehmen sich an dieser Stelle einmische. Aber das Gegenteil sei der Fall: Es wäre für die Open-Source-Welt deutlich riskanter, wenn ein Akteur wie Canonical sich aus moralischen Gründen heraushielte. Über zwei Jahrzehnte hinweg habe man bewiesen, dass man im Sinne von Open Source handle.

Gleichzeitig erkennt Seager die realen Probleme rund um KI-Beiträge in Open-Source-Projekten an. Er verweist auf die bekannten Beispiele sogenannter Slop-Pull-Requests, tausende Zeilen Code, eingeworfen von Personen, die ihren Beitrag nicht mal selbst gelesen hätten. Maintainer spürten den daraus entstehenden Druck zu Recht. Doch der Druck werde nicht weniger, wenn die erfahrenen Akteure das Feld räumten. Es brauche eine neue Generation von Beitragenden, die verstehe, wie konstruktive Mitarbeit funktioniere, und dazu brauche es die etablierte Open-Source-Welt als sichtbares Vorbild.

Sein Bild für die kommenden Jahre: Aktuell sei die Aufregung groß; an allen Ecken prasselten Pull Requests auf die beliebten Projekte ein. Sobald die anfängliche Euphorie über das eigene Bauen abklinge, werde sich das Feld erfahrungsgemäß wieder auf ein Set hochwertiger Open-Source-Komponenten zusammenziehen. Genau in dieser Konsolidierungsphase sei die Anwesenheit eines Akteurs wie Canonical entscheidend.

Ziele für 26.10: Sprache und Accessibility

Konkret werde, so Seager, in der nächsten Veröffentlichung 26.10 eine Funktion auftauchen, die seine Unterscheidung zwischen impliziter und expliziter KI gut illustriere. Standardmäßig solle es möglich sein, einen beliebigen Eingabe-Bereich auf dem Desktop mit einem Knopfdruck zu diktieren statt zu tippen. Im Hintergrund ein kleines Modell wie Whisper. Das Sprache-zu-Text-Stück sei der einfachere Teil; der eigentliche Aufwand liege darin, diese Funktion in die unzähligen Stellen auf einem modernen Desktop zu integrieren, an denen Text eingegeben werden könne.

Für die meisten Anwender sei das eine reine Komfortfrage, warum, fragt Seager unter Gelächter, solle man wie ein Tier zu seinem Agenten tippen, wenn man auch sprechen könne? Für Menschen mit visueller Einschränkung dagegen sei es weit mehr. Klassische Screenreader, befindet Seager unverblümt, „suck“, also, dezent eingedeutscht: lägen heute weit unter dem, was möglich sei. Wenn man dagegen einen Bildschirminhalt oder ein Kamerabild in ein LLM schicke, könne das Modell sehr viel zuverlässiger artikulieren, was auf einem Bildschirm zu sehen und was eine sinnvolle nächste Handlung sei. Hier sieht Seager den Anfang einer wirklich neuen Stufe in Ubuntus Accessibility-Geschichte.

Ein weiterer Hinweis bleibt bewusst vage. Es werde, kündigt Seager an, in 26.10 „neue Wege“ geben, mit einer Ubuntu-Maschine zu interagieren, mehr will er bewusst nicht verraten. Spannend ist die Argumentation dahinter: Linux sei ein Mosaik aus unzähligen Stellschrauben, an denen sich der eigene Workflow präzise einstellen lasse, sofern man die nötigen 20 Jahre Erfahrung mitbringe. Jetzt aber habe fast jeder etwas zur Hand, das dieses Know-how besitze. Anders gesagt: Ein LLM vermittelt zwischen den unzähligen Schaltern und Konfigurationsdateien und einem Nutzer, der einfach nur eine Aufgabe erledigen will. Snaps mit ihrem Confinement-Modell seien übrigens wie geschaffen, um die einzelnen Werkzeuge für so einen Aufbau bereitzustellen, ergänzt Seager, jedes Werkzeug bringe sein Berechtigungsprofil mit, ohne dass es zusätzliche Arbeit brauche.

Rückblick: 26.04 LTS „Resolute Raccoon“

Im Anschluss richtet Seager den Blick zurück. Er sei stolz auf das, was sein Team in den vergangenen sechs Monaten mit dem LTS-Release „Resolute Raccoon“ geliefert habe. Es war die erste Langzeitversion unter dem von ihm formulierten Engineering-Anspruch, den er selbst unter das ironische Motto „the beatings will continue until morale improves“ stellt. Das Team sei nicht nur gewachsen, sondern habe sich auch in seiner Arbeitsweise verändert. An Ubuntu sei zuletzt kaum vorbeizukommen gewesen, ein gewollter Effekt, der auf höhere Frequenz in Blogs, Mastodon-Posts, Podcast-Auftritten und Community-Interaktionen zurückgehe.

Auch der Releaseprozess sei umgebaut worden. Die Ankündigung, künftig monatliche Snapshots aus dem Entwicklungszweig zu veröffentlichen, habe das Release-Team zunächst kollektiv erblassen lassen. Tatsächlich sei dann aber kein einziger Snapshot-Termin verpasst worden. Im Hintergrund stehe eine in Go geschriebene, auf Temporal aufbauende Pipeline. Die etablierten Schutzmechanismen, Stable Release Updates, Developer Membership Board, MIR-Prozesse, blieben in Kraft, würden aber so umgebaut, dass sie nicht im Weg stünden. In den letzten sechs Monaten habe Ubuntu mehr neue Core Developer hinzubekommen als in den drei Jahren zuvor.

Rust überall, ohne Religion

Mit 26.04 LTS habe man Sylvestre Ledru und das Team von UUtils dabei unterstützt, eine Rust-Implementierung von mv, cp, rm, ls und Konsorten in Ubuntu als Standard auszuliefern, flankiert von zwei durch Canonical finanzierten Security-Audits. Das wichtigste Rust-Werkzeug sitze allerdings tiefer: sudo-rs ist seit 26.04 die Standardimplementierung an der Privilegiengrenze jeder Ubuntu-Installation. Es verzichte bewusst auf einige Features des klassischen sudo, von denen sich rückblickend gezeigt habe, dass sie nicht gut gealtert seien.

Damit ist die Arbeit aus Seagers Sicht jedoch nicht abgeschlossen. Er kündigt drei weitere Großbaustellen für die kommenden Zyklen an:

Mit upki entstehe ein Werkzeug, das einen blinden Fleck im Linux-Userland adressieren soll. Dass der Aufruf von curl an der Kommandozeile Certificate Revocation Lists schlicht ignoriere, sei den meisten nicht bewusst. Auch fehlende Zwischenzertifikate, die im Browser problemlos nachgeladen würden, brächten die klassische Toolchain ins Stolpern. Canonical finanziere bei den Rustls-Entwicklern, der Rust-TLS-Implementierung, ein Utility, das Certificate Revocation, Intermediate Preloading und perspektivisch auch moderne post-quantum-fähige Algorithmen mitbringe. Das „U“ stehe übrigens für „universal“, nicht für „Ubuntu“, upki sei ausdrücklich als Beitrag an das gesamte Linux-Ökosystem konzipiert. Parallel würden die Anbindungen in OpenSSL, GnuTLS und curl ergänzt.

ntpd-rs soll mit einer einzigen Binärdatei und einer einzigen Konfigurationsdatei NTP, das authentifizierte NTS und das hochpräzise PTP abdecken, „no messing around“, wie Seager es formuliert. Wer schon einmal präzise Zeitsynchronisation unter Linux aufgesetzt habe, wisse, warum das eine erhebliche Erleichterung sei.

Bei den Kompressionsbibliotheken kommt zu Memory Safety ein weiteres Argument hinzu: Energieeffizienz. Eine Rust-Implementierung von bzip2 sei bis zu 50 Prozent effizienter als die bisherige Variante. Im laufenden Release-Cycle solle bzip2 ersetzt werden, bis 28.04 sollen zlib und zstd folgen. Bei der Skalierung auf alle Maschinen, die diese Bibliotheken einsetzen, sei das ein signifikanter Beitrag zum Energieverbrauch.

GPU-Stack, FDE und Authentifizierung

Mit apt install cuda beziehungsweise apt install rocm lassen sich seit 26.04 die jeweiligen GPU-Stacks von NVIDIA und AMD direkt aus dem Archiv installieren, eine Vereinfachung, die ihm zufolge bei Kundengesprächen regelmäßig auf Erstaunen stoße. Beide Hersteller hätten dazu eng mit den Canonical-Partnerteams zusammengearbeitet.

TPM-gestützte Full Disk Encryption sei in 26.04 erstmals allgemein verfügbar auf dem Desktop und werde in den nächsten Zyklen auf Server-Installationen ausgerollt. Anwender bekämen eine Erfahrung analog zu BitLocker oder FileVault; für Administratoren biete Canonical in Landscape einen Recovery-Key-Escrow an.

Bei der Authentifizierung gehe Canonical mit AuthD einen Schritt weiter. Wer eine Identity Provider Suite wie Entra ID, Google Cloud, Okta, Ping oder Duo betreibe, könne seine Anwender per OIDC direkt an einer Ubuntu-Maschine anmelden lassen.

Eine eher technische, aber wirkmächtige Ergänzung sind die Architektur-Varianten. Mit AMD64v3 enthält 26.04 erstmals ein für neuere Prozessor-Generationen optimiertes Build der Distribution; ARM- und RISC-V-Varianten sollen folgen. Diese Optimierung erstrecke sich auf das gesamte Ubuntu-Universum: Debs, Snaps, Rocks, Charms.

Schließlich kündigt Seager an, dass Ubuntu Core jetzt in den drei großen Public Clouds, AWS, Azure und Google Cloud, als Preview verfügbar sei. Argumentation: Warum sollte man kubelet oder ein eng zugeschnittenes Cloud-Workload nicht auf einem konfinierten, immutable Betriebssystem laufen lassen?

Den Abschluss bildet ein Detail, das Seager als „wirklich aufwändiges Stück Arbeit“ beschreibt: Wenn ein Snap an die Grenzen seines Confinement stoße, etwa die Kamera abfragen wolle, ohne dafür autorisiert zu sein, könne der Stack jetzt einen Berechtigungsdialog anzeigen, vergleichbar mit iOS oder Android. Die Pipeline laufe vom Kernel über AppArmor in snapd und weiter über GDM in eine kleine Userspace-Anwendung. Auf Servern stehe das Pendant noch aus, „Notifications im TTY ist überraschend kompliziert“, sagt er und bekommt dafür den letzten Lacher des Vormittags.

Einordnung

Die beiden Eröffnungs-Keynotes haben das Summit auf eine Linie eingeschworen, die in Teilen längst bekannt ist, Snap als Auslieferungsweg, monatliche Snapshots, Rust statt C an sicherheitskritischen Schnittstellen, die aber ungewohnt offen mit der Frage verzahnt wird, wie sich Ubuntu zur agentischen Welle stellt. Shuttleworth liefert dafür eine Bauanleitung: schnelle Auslieferung über signierte Snaps, Sandboxing in unterschiedlichen Härtegraden für unterschiedliche Vertrauensgrade und ein klares Bekenntnis zu Open Source und Open Weights als Gegengewicht zu einer rein token-getriebenen Ökonomie.

Seager liefert die Engineering-Sicht. Sein Vortrag hat zwei Stoßrichtungen, die sich nicht ohne Weiteres trennen lassen: Erstens die fortgesetzte Modernisierung an den sensiblen Stellen, sudo, NTP, Kompression, PKI, die Ubuntu unspektakulär aber methodisch sicherer und effizienter machen soll. Zweitens die vorsichtige Annäherung an explizite KI-Funktionen, mit Sprache-zu-Text als bewusst kleinem und nützlichem Anfang und einer offenen Stelle für die in 26.10 erwarteten „neuen Interaktionsformen“.

Was bei beiden Vorträgen auffällt: Der Ton ist sachlich. Es gibt keinen Versuch, sich als Pionier der KI-Welle zu inszenieren. Das passt zu einer Distribution, deren Markenkern Stabilität, Vorhersagbarkeit und langfristige Wartbarkeit ist, und es macht die Behauptung, beide Welten unter einem Dach halten zu können, glaubwürdiger, als es ein lautes Versprechen täte.

Marius Quabeck war im Rahmen des Ubuntu Summit 26.04 für das Linux-Magazin in London vor Ort. Er wurde von Canonical eingeladen; Canonical trägt die Reisekosten der eingeladenen Teilnehmer.