Google: Warum uns Ubuntu zu träge war – und wie wir jetzt gLinux administrieren

Google erklärt die Gründe für das Ende der internen Linux-Distribution Goobuntu, wie man das neue gLinux verwaltet und warum man Rolling Releases bevorzugt.

In Pocket speichern vorlesen Druckansicht 230 Kommentare lesen
Open Source Summit Europe: Realtime-Erweiterungen bald im Linux-Kernel

(Bild: Siggy Nowak, gemeinfrei)

Lesezeit: 3 Min.

Google gewährt erstmals ausführliche Einblicke in das Management der intern genutzten Linux-Distribution gLinux. Diese basiert auf Debians "testing"-Zweig und ist die Nachfolgerin des zuvor eingesetzten, Ubuntu LTS-basierten, Goobuntu. Vor allem vom beim Wechsel etablierten rollenden Release-Zyklus sei man nach wie vor überzeugt, meint Google in einem Blog-Beitrag.

Wie viele Linux-Nutzer unter den Google-Angestellten sind, verrät das Unternehmen zwar nicht – wohl aber, dass bei jedem der zweijährigen Releases von Ubuntu LTS "über 100.000 Geräte" mit der neuen Version von Goobuntu auf Stand gebracht werden mussten. Die zweijährigen Release-Zyklen von Ubuntu LTS hätten dabei zu einer Reihe von Nachteilen geführt, wie Google in dem Blogpost beschreibt. Die vielfältigen Aufgabengebiete der Geräte im Unternehmen hätten dazu geführt, dass die "vollständige Anpassung der Rechner schwierig und zeitaufwändig sein konnte".

Auch wenn man den Prozess mit einem selbst entwickelten Tool automatisiert hatte, habe es regelmäßig hunderte Bug-Reports und Support-Anfragen von "Sonderfällen" (corner cases) gegeben. So habe ein vollständiges Update aller Systeme im Konzern oftmals ein ganzes Jahr in Anspruch genommen – bevor kurz darauf der nächste Update-Zyklus anstand.

Beim Design des Goobuntu-Nachfolgers gLinux Rodete (Rolling Debian Testing) habe man deshalb darauf abgezielt, die Arbeitslast mittels rollender Releases über die Zeit zu verteilen. Für Debian habe man sich vor allem wegen der relativ großen Ähnlichkeit zu Ubuntu und der großen Überschneidung der verwendeten Pakete entschieden.

Während Debian stable ebenfalls einen zweijährigen Zyklus verfolgt, setzt Debian testing auf die gewünschten kontinuierlichen Releases; Upstream-Updates stünden daher innerhalb weniger Tage bereit. Google-intern habe man sich inzwischen auf wöchentliche Updates für gLinux eingependelt – zunächst bei einer Test-Flotte von 1 Prozent aller Geräte, kurz darauf dann an alle internen Linux-Nutzer.

iX Newsletter: Monatlich spannende Hintergründe zur neuen Ausgabe

Kennen Sie schon den kostenlosen iX-Newsletter? Jetzt anmelden und monatlich zum Erscheinungsdatum nichts verpassen: heise.de/s/NY1E In der nächsten Ausgabe geht's ums Titelthema der August-iX: professionelle Hardware vom Refurbisher.

Zum Einsatz kommt dabei das eigens entwickelte Workflow-System Sieve. Für jede neue Version eines Debian-Pakets starte man einen neuen Build. Die Pakete führe man dann in Gruppen zusammen und teste sie gemeinsam an einer vollständigen Systeminstallation. Treten Fehler auf, prüfe man den Debian Bug Tracker und melde die Probleme im Zweifel auch selbst. Gleichzeitig könne die Sieve mit einer Toolbox auch auf eine Reihe von Tricks zurückgreifen, um die Quelle mithilfe von "educated guesses" möglicher Abhängigkeitsprobleme zu identifizieren.

Mit dem Umstieg auf gLinux hätten sich eine Reihe von Vorteilen ergeben: Die Zeit und Energie, die das Engineering-Team für Distributions-Updates aufbringen müsse, sei deutlich gesunken, beziehungsweise trete viel weniger konzentriert auf. Die neue zeitliche Nähe der Updates der Google-Linux-Flotte zu Upstream-Releases steigere zudem die Sicherheit der Systeme, weil bekannte Sicherheitslücken viel kurzfristiger automatisch geschlossen würden. Unter Goobuntu sei dafür zuvor viel mehr manuelle Handarbeit nötig gewesen.

Auch anderen empfiehlt der Blogpost, die eigene Distributionen mit Rolling Releases auszustatten: Nach wie vor sei man von den Vorteilen des Umstiegs, der bereits 2015 begann und erst Mitte 2020 mit Aufschließen an die damals aktuelle Debian-Variante abgeschlossen wurde, überzeugt.

(jvo)