distrobox: Fremde Distributionen als Container mit geteiltem HOME, D-Bus und Audio
Verwenden Sie eine beliebige Linux-Distribution in Ihrem Terminal. Ermöglichen Sie sowohl die Abwärts- als auch die Vorwärtskompatibilität mit Software und die Freiheit, die Distribution zu verwenden, mit der Sie sich am wohlsten fühlen. Spiegel erhältlich unter:.
Auf einen Blick
- Was ist das?
- Ein in Go geschriebener Satz Unterbefehle, der Podman, Docker oder lilipod zu Containern mit enger Host-Einbindung verdrahtet. Einordnung von Konfigurationsschlüsseln, Versionsstand und GPL-3.0-Lage.
- Für wen ist es gedacht?
- distrobox passt zu Nutzerinnen und Nutzern, die auf einem stabilen Wirtsystem gezielt Werkzeuge aus anderen Distributionen einsetzen wollen und die Einbindung von HOME, Grafik und Geräten brauchen. Weniger geeignet ist es als Trennwand für Software, der man nicht traut, weil genau diese Einbindung zum Konzept gehört.
- Darf ich es kommerziell nutzen?
- Ja, unter Bedingungen. GPL-3.0 ist eine Copyleft-Lizenz: Wenn Sie Software weitergeben, die sie enthält, müssen Sie deren Quellcode unter derselben Lizenz veröffentlichen. Wer sie nur intern betreibt, ohne sie weiterzugeben, löst diese Pflicht nicht aus.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 2 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Go, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 14. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Was distrobox im Terminal tut: Podman, Docker oder lilipod darunter
distrobox ist ein in Go geschriebener Satz Unterbefehle, der Container aus beliebigen Linux-Distributionen so in das eigene System einhängt, dass sie sich wie eine gewöhnliche Shell anfühlen. Das README bringt es selbst auf eine Formel: ein ausgefallener Wrapper um podman, docker oder lilipod, der Container erzeugt und startet, die eng mit dem Host verbunden sind.
Der Zweck ist im README klar benannt. Es geht um Vorwärts- und Rückwärtskompatibilität bei Software und um die Freiheit, die Distribution zu nutzen, mit der man besser zurechtkommt. Wer auf einem stabilen Wirtssystem ein Paket aus einer anderen Distribution braucht, bekommt dafür einen Weg, ohne das Wirtssystem selbst anzutasten.
Welche Container-Verwaltung zum Einsatz kommt, ist wählbar. Neben Docker und Podman nennt das README lilipod, ein weiteres Projekt desselben Autors. Damit hängt die Funktion an einer dieser drei Laufzeiten; ist keine davon vorhanden, bleibt distrobox wirkungslos.
Die Unterbefehle von distrobox: create, enter, export und host-exec
Das README führt die Unterbefehle in zwei Gruppen. Von außen, also vom Host aus, gibt es distrobox-create, distrobox-enter, distrobox-list, distrobox-rm, distrobox-stop, distrobox-upgrade, distrobox-ephemeral, distrobox-generate-entry und distrobox-assemble.
Von innen, also aus dem Container heraus, kommen drei Helfer hinzu: distrobox-export, distrobox-host-exec und distrobox-init. Diese Aufteilung gibt eine Richtung vor. Anlegen und Verwalten passiert auf dem Host, das Herausreichen von Programmen und das Ausführen von Befehlen auf dem Host passieren im Container.
Jeder Unterbefehl hat eine eigene Seite unter usage/. Für den Einstieg reicht distrobox-create, danach distrobox-enter. Für wiederholbare Aufbauten ist distrobox-assemble gedacht, das mehrere Container aus einer gemeinsamen Beschreibung erzeugt.
container_manager, container_image_default und die übrigen Schlüssel der Konfigurationsdatei
Wer nicht bei jedem Aufruf alles angeben will, legt Voreinstellungen in einer Konfigurationsdatei ab. Aus dem README gehen folgende Schlüssel hervor: container_manager legt die Laufzeit fest, container_image_default das Ausgangsbild und container_name_default den Standardnamen.
Hinzu kommen container_always_pull, das vor jedem Start ein frisches Bild holt, und container_generate_entry, das die Erzeugung von Startereinträgen steuert. Für abweichende Pfade gibt es container_user_custom_home, für eigene Schritte container_init_hook und container_pre_init_hook.
An Sonderfälle richten sich container_manager_additional_flags, das zusätzliche Argumente an die Laufzeit durchreicht, sowie container_additional_volumes für weitere Einhängepunkte. Das README nennt diese Schlüssel als Voreinstellungen, nicht als Pflicht; jede Angabe lässt sich beim einzelnen Aufruf überschreiben.
Was ein distrobox-Container vom Host erbt: HOME, D-Bus, udev-Datenbank und USB
Der eng verzahnte Teil ist der eigentliche Unterschied zu einem gewöhnlichen Container. Laut README teilt der Container das HOME-Verzeichnis des Nutzers, dazu externe Speicher, USB-Geräte, grafische Anwendungen über X11 oder Wayland sowie Audio.
Zur Umgebung gehören nach README-Angaben ein OCI-Bild als Grundlage sowie systemd-Journal, SSH-Agent, D-Bus, ulimits, /dev und die udev-Datenbank. Genau diese Liste erklärt, warum grafische Programme und Gerätezugriffe ohne weitere Handgriffe funktionieren.
In den Tipps des README tauchen weitere Fälle auf, die diese Verzahnung ausreizen: Docker, Podman, LXC und Waydroid innerhalb eines distrobox-Containers, ein Init-System im Container, GPU-Nutzung über nvidia-container-toolkit sowie SSH-X-Weiterleitung. Für alles davon liegen eigene Abschnitte in useful_tips.md bereit.
2.0.0-rc.4 und kein stabiles Release: was die Versionsliste zeigt
Die Releases geben zu denken. Eingetragen sind 2.0.0-rc.4 vom 25. Juli 2026, 2.0.0-rc.3 vom 29. Juni 2026 und 2.0.0-rc.2 vom 30. April 2026. Alle drei sind Veröffentlichungskandidaten, ein stabiles 2.0.0 erscheint in dieser Liste nicht.
Wer distrobox in einem Arbeitsablauf einsetzt, der nicht jeden Monat nachjustiert werden soll, sollte die Versionsnummer bewusst festhalten. Zwischen den Kandidaten liegen teils mehrere Wochen, und das README weist ausdrücklich darauf hin, dass die Dokumentation auf GitHub nur den Hauptzweig beschreibt.
Die offizielle Dokumentation liegt unter distrobox.it. Wer aus einer Paketquelle installiert, erhält womöglich eine andere Fassung als im Hauptzweig; das README verweist auf repology für einen Überblick über veröffentlichte Versionen.
1336 offene Issues und die getrennte Dokumentation zwischen GitHub und distrobox.it
Die Zahl der offenen Issues ist hoch: 1.336 bei 12.793 Sternen und 535 Forks, letzter Push am 25. Juli 2026. Bei einem Projekt, das auf so vielen Wirtdistributionen und Container-Laufzeiten läuft, ist ein Teil davon eher Ausdruck der Umgebungsvielfalt als der Fehlerdichte. Eine Zuordnung erlaubt das README nicht.
Hinzu kommt die geteilte Dokumentation. Das README trägt einen ausdrücklichen Hinweis, dass die Fassung auf GitHub ausschließlich den Code im Hauptzweig beschreibt, während die offizielle Dokumentation auf distrobox.it liegt. Wer Packagedokumentation und Repository nebeneinander liest, sollte diese Trennung im Kopf behalten.
Zur Einordnung hilft compatibility.md mit Abschnitten zu unterstützten Container-Verwaltungen, zu Host-Distributionen und zu Container-Distributionen. Für Sonderplattformen wie das Steam Deck gibt es eine eigene Anleitung unter posts/steamdeck_guide.md.
GPL-3.0 und die Sicherheitsfrage bei geteiltem HOME und SSH-Agent
distrobox steht unter GPL-3.0. Für die eigene Nutzung ändert das wenig; wer das Werkzeug verändert und weitergibt, muss den Quelltext unter derselben Lizenz offenlegen.
Die Sicherheitsfrage ist bei diesem Projekt von anderer Art als bei einem Serverdienst. Weil der Container das HOME-Verzeichnis, den D-Bus, den SSH-Agenten und die Geräte unter /dev mit dem Host teilt, ist er von sich aus keine Grenze gegen Code, dem man nicht traut. Das README führt einen Abschnitt zu den Sicherheitsfolgen, führt ihn an dieser Stelle aber nicht aus.
Sinnvoll bleibt deshalb die Einordnung als Komfortschicht: Sie trennt Paketstände und Bibliotheksversionen, keine Vertrauensbereiche. Wer fremde Software ausprobieren will, fährt mit einem Container ohne diese Einbindungen besser. distrobox lohnt sich dort, wo die Einbindung der eigentliche Zweck ist.
containers/toolbox statt distrobox: schmaler Zuschnitt, weniger Stellschrauben
Das nächste Gegenstück ist containers/toolbox. Dort ist die Zielrichtung enger gefasst, die Auswahl an Laufzeiten entsprechend kleiner, während distrobox drei Container-Verwaltungen nennt und in compatibility.md eine breite Matrix an Host- und Container-Distributionen aufführt.
Im Alltag fällt der Unterschied an zwei Stellen auf. Erstens bei der Zahl der Stellschrauben: Die Schlüssel für Bild, Name, Hooks und zusätzliche Einhängepunkte erlauben bei distrobox einen feineren Zuschnitt. Zweitens bei den Helfern im Container, mit denen sich Anwendungen nach außen auf den Host reichen lassen.
Für die Entscheidung hilft ein kurzer Test mit distrobox-ephemeral. Ein wegwerfbarer Container zeigt, ob HOME, Audio und Grafik auf dem eigenen Rechner durchkommen, ohne dass danach Reste bleiben. Danach lohnt der Blick in die Ausgabe von distrobox-list und in die eigenen Einträge der Konfigurationsdatei.
Redaktionelles Fazit
distrobox passt zu Nutzerinnen und Nutzern, die auf einem stabilen Wirtsystem gezielt Werkzeuge aus anderen Distributionen einsetzen wollen und die Einbindung von HOME, Grafik und Geräten brauchen. Weniger geeignet ist es als Trennwand für Software, der man nicht traut, weil genau diese Einbindung zum Konzept gehört. Geprüft werden sollten zuerst, welcher Container-Manager auf dem Rechner verfügbar ist, ein Lauf mit distrobox-ephemeral gegen ein kleines Bild, und die Versionsnummer, weil die letzten drei Veröffentlichungen mit 2.0.0-rc.4 durchweg Kandidaten sind.
Community-Notizen