podman auf dem Desktop klingt erstmal nach einer Lösung, die ihr Problem noch sucht. Container gehören doch auf den Server. Auf dem eigenen Rechner gibt es schließlich apt, dnf, AppImage und flatpak. Trotzdem gibt es eine Handvoll Situationen, in denen der Umweg über einen Container die deutlich entspanntere Variante ist. Schauen wir uns das mal an.
Worum es hier ausdrücklich nicht geht
Vorweg die Einschränkung: Es geht nicht darum, jedes Programm in einen Container zu stecken. Firefox, Thunderbird oder der Texteditor sind in der Paketverwaltung bestens aufgehoben. Wer die Grundlagen zu den beiden Container-Managern nachlesen möchte, findet sie im Artikel Docker oder Podman.
Zwei Eigenschaften machen podman für den Desktop überhaupt erst interessant. Erstens läuft es rootless, also unter der normalen Benutzerkennung. Zweitens braucht es keinen Daemon. Ein Container ist schlicht ein Prozess, kein Auftrag an einen Hintergrunddienst mit Root-Rechten. Genau das macht den Einsatz auf einem Arbeitsrechner überhaupt vertretbar. Die Details dazu stehen in der offiziellen Dokumentation.
Alte Abhängigkeiten: wenn ein Programm Bibliotheken von gestern will
Das ist der Klassiker schlechthin. Ein Programm braucht eine ganz bestimmte Version einer Bibliothek. Das System bringt aber eine neuere mit. Nach einem Distributions-Upgrade kann so etwas schlagartig auftreten. Wie unangenehm das wird, habe ich beim Wechsel auf Debian Trixie erlebt, als Mastodon wegen einer ICU-Version nicht mehr starten wollte.
Ohne Container gibt es dafür nur unschöne Wege. Man zieht ein Paket aus dem Archiv der alten Release. Oder man bindet ein Fremdrepo ein und pinnt Versionen. Danach hat man dauerhaft zwei Bibliotheksstände auf dem System liegen, und beim nächsten Update grübelt man, welcher davon eigentlich noch gebraucht wird.
Im Container ist das Thema erledigt. Das Basis-Image bringt genau die Version mit, die das Programm erwartet. Das restliche System bleibt unangetastet. Zudem weiß man auch in zwei Jahren noch, warum diese alte Bibliothek überhaupt existiert: Sie steckt in genau einem Image und nirgendwo sonst.
Datenbanken sind der Paradefall
Besonders deutlich wird es bei Datenbanken. Debian 13 liefert MariaDB 11.8 und PostgreSQL 17 aus. Das ist aktuell und völlig in Ordnung. Nur interessiert das die Software herzlich wenig, die zwingend eine ältere Version erwartet.
Ein Beispiel: Ein selbst gehostetes Tool läuft laut Dokumentation nur mit MariaDB 10.11. Ein zweites will PostgreSQL 15 sehen. Über die Paketverwaltung wird das schnell mühsam. Man braucht Fremdrepos, unterschiedliche Ports, getrennte Datenverzeichnisse und muss aufpassen, dass sich die Init-Skripte nicht gegenseitig ins Gehege kommen.
Mit podman sind es zwei Container, zwei Ports, zwei Volumes. Fertig. Jede Datenbank bringt ihre eigene Umgebung mit und weiß nichts von der anderen. Beim Ablegen der Daten lohnt übrigens ein Blick auf bind-mounts und das SELinux-Label, sonst gibt es auf RHEL-Derivaten unnötigen Ärger.
Ein netter Nebeneffekt: Die Datenbankversion ist damit dokumentiert. Sie steht im Image-Tag und nicht in einer Notiz, die man vor drei Jahren geschrieben und längst verlegt hat. Was ein Distributions-Upgrade sonst mit einer nativ installierten Datenbank anstellen kann, habe ich beim PostgreSQL-Sortierfolgen-Problem beschrieben.
Closed-Source-Programme einsperren
Der zweite Punkt ist eher eine Frage der Datensicherheit. Zoom, Teams, Slack oder Discord sind praktisch, aber man hat keinerlei Einblick in den Quellcode. Dabei geht es gar nicht darum, den Anbietern böse Absicht zu unterstellen. Die relevante Frage ist eine andere: Was kann so ein Programm technisch überhaupt sehen?
Die Antwort fällt bei einer normalen Installation ernüchternd aus. Das Programm läuft mit den vollen Rechten des angemeldeten Benutzers. Damit sieht es das komplette Home-Verzeichnis. Also SSH-Schlüssel, Browserprofile, Steuerunterlagen, den synchronisierten Nextcloud-Ordner und alles andere. Ein AppImage ändert daran nichts, denn dort ist zwar die Anwendung gebündelt, die Rechte bleiben aber dieselben.
Bei US-amerikanischen Anbietern kommt eine rechtliche Ebene dazu. Der CLOUD Act verpflichtet US-Unternehmen, Daten auch dann herauszugeben, wenn diese außerhalb der USA gespeichert sind. Das betrifft primär die Server der Anbieter. Trotzdem ändert es die Perspektive darauf, wie großzügig man einem geschlossenen Programm Zugriff auf den eigenen Rechner einräumen möchte.
Im Container dreht sich die Logik um. Standardmäßig sieht das Programm nichts vom Home-Verzeichnis. Man gibt gezielt frei, was es wirklich braucht: vielleicht einen Ordner für Downloads, vielleicht auch gar keinen. Statt einer Blockliste hat man eine Erlaubnisliste, und die schreibt man selbst.
Der ehrliche Teil: fummelig wird es trotzdem
Genau bei diesen Apps wird es allerdings unbequem. Eine Videokonferenz braucht Kamera, Mikrofon und eine grafische Ausgabe. Die Kamera reicht man als Device durch, Audio läuft über den PipeWire- oder PulseAudio-Socket, und für die Oberfläche braucht es den X11- oder Wayland-Socket.
Jedes dieser Löcher kostet ein Stück Isolation. Unter X11 ist das besonders deutlich, denn X11 kennt kein echtes Rechtekonzept zwischen Fenstern. Wer den Socket durchreicht, öffnet mehr als nur ein Fenster. Unter Wayland läuft die Bildschirmfreigabe dagegen über das xdg-desktop-portal, was für abgeschottete Anwendungen deutlich sauberer gelöst ist.
Unterm Strich bleibt der Gewinn trotzdem bestehen, nur an anderer Stelle als erhofft. Kamera und Mikrofon sind freigegeben, das Home-Verzeichnis aber nicht. Und genau dort liegen die Daten, um die es eigentlich geht. Perfekte Isolation ist es nicht. Deutlich besser als die native Installation ist es allemal.
Einfach mal ausprobieren, ohne Spuren zu hinterlassen
Der dritte Punkt ist der unspektakulärste und im Alltag vielleicht der nützlichste. Man liest von einem interessanten Tool und möchte es kurz testen. Die Installationsanleitung sagt dann so etwas wie pip install, npm install oder cargo install.
Anschließend liegen zwölf zusätzliche Pakete im System, von denen elf nur wegen dieses einen Tools da sind. Nach drei Monaten weiß niemand mehr, welches Paket wozu gehört. Das Tool selbst ist längst vergessen, die Abhängigkeiten bleiben.
Im Container ist der Test folgenlos. Ein Aufruf mit --rm räumt den Container nach dem Beenden automatisch weg. Bleibt nur noch das Image, und das verschwindet mit einem podman rmi. Es gibt keine Konfigurationsreste unter /etc und keine verwaisten Abhängigkeiten.
Wer diesen Ansatz bequemer möchte, schaut sich Toolbx oder Distrobox an. Beide setzen auf podman auf und bauen eine Container-Umgebung, die sich fast wie das normale System anfühlt. Für schnelles Ausprobieren ist das oft der angenehmere Einstieg als ein handgeschriebenes Dockerfile.
Und was machen Entwickler damit?
Dieser Punkt taucht in jeder Container-Diskussion auf, deshalb der Vollständigkeit halber kurz dazu. Entwickler nutzen exakt dieselben Mechanismen, nur eben täglich statt gelegentlich. Projekt A läuft gegen PostgreSQL 15, Projekt B gegen PostgreSQL 17, beide parallel auf demselben Laptop.
Interessant daran ist für alle anderen vor allem das Warum. Container-Werkzeuge sehen deshalb so aus, wie sie aussehen, weil sie ursprünglich für genau diesen Fall gebaut wurden. Volumes, Tags und Netzwerke lösen Probleme, die zuerst in der Entwicklung aufgetaucht sind. Auf dem Desktop profitiert man einfach davon mit. Wer die Container anschließend dauerhaft betreiben möchte, findet in pod automatisieren den passenden Weg über systemd.
Wann podman auf dem Desktop keinen Sinn macht
Ebenso wichtig ist die Gegenrichtung. Software aus dem Distributions-Repo, die einfach funktioniert, gehört nicht in einen Container. Der Aufwand zahlt sich schlicht nicht aus.
- Programme mit tiefer Desktop-Integration: Dateimanager-Erweiterungen, Tray-Symbole und Autostart-Einträge machen im Container mehr Arbeit als Freude.
- Anwendungen, die ohnehin fast alle Geräte brauchen. Wenn am Ende Kamera, Mikrofon, USB und GPU durchgereicht sind, ist von der Isolation wenig übrig.
- Knapper Plattenplatz. Images belegen Speicher, und mehrere Basis-Images summieren sich schneller als gedacht.
- Reine Gewohnheit. Alles in Container zu stecken, nur weil es geht, ist Selbstzweck und kein Gewinn.
Wer lieber klickt als tippt, findet mit Podman Desktop übrigens eine grafische Oberfläche dafür. Die läuft auch gegen entfernte Systeme, wie im Artikel podman desktop – wenn die gui gar nicht auf dem server läuft beschrieben.
Fazit
podman auf dem Desktop ist kein Ersatz für die Paketverwaltung. Es ist ein Werkzeug für die Fälle, in denen die Paketverwaltung unangenehm wird. Drei davon tauchen im Alltag immer wieder auf: sperrige Abhängigkeiten, geschlossene Programme und kurze Tests.
Am deutlichsten ist der Gewinn dort, wo kein Gerät durchgereicht werden muss. Ein Datenbank-Container oder ein CLI-Tool lässt sich sauber abschotten. Bei einer Videokonferenz-App bleibt es ein Kompromiss, aber immer noch ein besserer als die native Installation.
Mein Rat wäre daher: nicht alles umstellen, sondern beim nächsten sperrigen Programm einfach mal die Container-Variante probieren. Der Unterschied fällt spätestens beim Deinstallieren auf.