Fenster sollten eigentlich nicht übereinander liegen. Das war zumindest die ursprüngliche Idee.

Als in den Siebzigerjahren darüber nachgedacht wurde, wie ein Bildschirm mehreren Dingen gleichzeitig Raum geben könnte, dachte niemand an ein Chaos überlappender Rechtecke. Man dachte an Partitionen. An Flächen, die sich aufteilen, sobald etwas Neues dazukommt — wie Tische, auf denen man Bücher nebeneinander legt, nicht übereinander stapelt. Die ersten Fenstersysteme auf den Lisp-Machines von Symbolics, im Andrew Project der Carnegie Mellon University, selbst Microsoft Windows 1.0 anno 1985: alle tile-basiert. Überlappende Fenster galten als Option, nicht als Normalfall.

Dann setzte sich die Überlappung durch. Apple machte sie mit dem Macintosh populär, Microsoft zog nach, X11 auf Unix folgte. Der Grund war nicht, dass Überlappung besser gewesen wäre — sie wirkte nur visuell eingängiger. Man konnte Fenster wie Papiere auf einem Schreibtisch behandeln, das oberste nach oben holen, andere verdecken. Die Metapher war greifbar. Die Effizienz war es nicht. Wer etwas sehen wollte, das verdeckt war, musste es erst hervorholen. Wer mehrere Dinge gleichzeitig betrachten wollte, musste sie von Hand anordnen. Der Preis der Metapher war ständige Handarbeit — ein Preis, den niemand mehr hinterfragte, weil es keine Alternative zu geben schien.

Wer heute einen Linux-Desktop nutzt, hat in der Regel die Wahl zwischen zwei großen Desktop-Umgebungen: GNOME und KDE Plasma. Beide sind hervorragend. Beide sind floating. Beide organisieren Fenster nach dem Paradigma, das 1984 populär wurde. Und fast niemand fragt, ob das Paradigma stimmt.

Was Tiling eigentlich ist

Tiling Window Manager arrangieren Fenster nicht überlappend, sondern kachelnd. Jedes neue Fenster erhält einen rechteckigen Bereich des Bildschirms; vorhandene Fenster verkleinern sich, um Platz zu schaffen. Nichts wird verdeckt. Jeder Pixel arbeitet.

Zwei Unterkategorien existieren. Manuelles Tiling — wie bei i3 — verlangt, dass man Fenster aktiv in Container splittet; der Manager verteilt den Raum entsprechend. Dynamisches Tiling — wie bei dwm, AwesomeWM oder xmonad — berechnet das Layout automatisch nach einem Algorithmus: Master-Stack, Spirale, Grid, wasauchimmer. Man öffnet ein Fenster, der Manager sortiert. Man schließt eins, die restlichen füllen die Lücke.

Das Ergebnis sieht nicht aus wie ein Schreibtisch. Es sieht aus wie ein Dashboard. Und es verändert, wie man mit dem Rechner arbeitet.

Die Dominanz des Floating

Reden wir über die Gegenwart. GNOME und KDE Plasma beherrschen den Linux-Desktop. Beide liefern komplette Desktop-Umgebungen: Panel, App-Menü, Benachrichtigungen, Dateimanager, Einstellungen, Themes, Bildschirmverwaltung, Session-Management. Sie sind rundum gesorgt. Wer sie installiert, hat einen funktionierenden Desktop — nicht einen Baustein, aus dem man sich einen basteln muss.

Das ist kein Makel. Es ist der Grund, warum die meisten Menschen dabei bleiben. Eine Desktop-Umgebung ist Infrastruktur. Sie soll funktionieren, nicht erforscht werden. Die meisten Nutzer — selbst die, die Linux aus Überzeugung gewählt haben — haben keinen Appetit darauf, einen Fenstermanager als Dauerprojekt zu betreiben.

Die Distributionen tun ihr Übriges. Fedora, Ubuntu, openSUSE, Arch — alle liefern standardmäßig eine Floating-Umgebung aus. Tiling-Window-Manager existieren in den Repos, aber sie liegen hinter einem bewussten Entschluss: man muss sie suchen, installieren, konfigurieren. Niemand stolpert zufällig über i3. Wer sie entdeckt, hat bereits danach gesucht — oder jemanden getroffen, der sie nutzt.

Und hier beginnt das Paradox. Dieselbe Community, die Distributionen vergleicht, Init-Systeme debattiert, Paketformate bekämpft und Editor-Heiligenkriege führt — die Community, die Choice als Wert hochhält —, behandelt die Wahl des Fensterparadigmas, als gäbe es nur eines. Dabei existiert eine Alternative, die mindestens so konsequent ist wie alles, was Linux sonst auszeichnet. Sie heißt Tiling. Und sie führt ein Schattendasein.

Was Tiling Window Manager bieten

Die Vorteile sind nicht romantisch. Sie sind mechanisch.

Tastaturzentrierung. In einem Tiling-Window-Manager navigiert man primär per Tastatur. Modi, Fokuswechsel, Split-Erstellung, Workspace-Sprung — alles Tastenfolgen, keine Mausbewegung. Wer täglich acht Stunden am Rechner sitzt und davon zwei Stunden mit der Maus Fenster verschiebt, verschwendet Zeit. Klingt marginal. Summiert sich.

Volle Flächenausnutzung. Floating-Layouts überlappen. Überlappung bedeutet, dass ein Teil des Inhalts verdeckt ist — und dass man aktiv nachfassen muss, um ihn sichtbar zu machen. Tiling zeigt alles, was offen ist, gleichzeitig. Auf einem Ultrawide-Monitor sind sechs Terminal-Fenster, ein Browser und ein Chat sichtbar nebeneinander — ohne Alt-Tab-Olympiade.

Skriptbare Konfiguration. i3, sway, Hyprland, AwesomeWM: alle Konfigurationen sind Textdateien. AwesomeWM geht weiter — seine Konfiguration ist Lua-Code. Wer will, kann Workspaces dynamisch generieren, Fenster anhand von Titeln automatisch auf bestimmte Arbeitsflächen verteilen, Layouts programmatisch wechseln. Dotfiles werden reproduzierbar. Ein Setup lässt sich committen, versionieren, auf einem zweiten Rechner clonen. Das ist Ops-Denken am Desktop.

Minimaler Fußabdruck. dwm belegt unter zwei Megabyte resident. sway, Hyprland, i3 — alle deutlich ressourcenschonender als eine volle Desktop-Umgebung. Auf alter Hardware, auf Thin Clients, auf Rechnern, die primär Terminalarbeit leisten, ist das kein Luxus — es ist relevanter Spielraum.

Fluss statt Fragmentierung. Wer in Terminals, Editoren, Browsern und Dokumentation gleichzeitig arbeitet, jongliert normalerweise Fenster. Tiling macht das Jonglieren zum Standardzustand: alles sichtbar, alles erreichbar, nichts verdeckt. Der mentale Kontextwechsel sinkt.

Ein Vormittag im Vergleich

Betrachten wir einen typischen Vormittag. Ein Administrator kommt ins Büro, Kaffee in der Hand, und der Rechner muss her.

In der Floating-Welt: Starter öffnen, Terminal anklicken — es erscheint mittig, verdeckt alles. Eck ziehen, in die Ecke schieben. Browser öffnen, daneben quetschen, überlappt das Terminal. Log-Viewer auf, wieder ein Fenster, das nirgends richtig hinwill. Nach zehn Minuten Alt-Tab-Jagd hat man sechs Fenster, drei davon halb verdeckt, und hat die Maus öfter bewegt als die Tastatur.

In der Tiling-Welt: Mod+Eingabe öffnet ein Terminal — linke Hälfte, automatisch. Mod+Eingabe noch einmal — rechte Hälfte, geteilt. Browser auf Workspace 2, Mod+2, da ist er, ganzflächig. Logs auf Workspace 3, Monitoring auf 4, Wiki auf 5. Sechs Arbeitsflächen, jeweils klar belegt, über Zifferntasten erreichbar. Die Hände verlassen die Heimatreihe nicht. Nach zehn Minuten hat man denselben Überblick — ohne ein einziges Fenster verschoben zu haben.

Der Unterschied wirkt im Einzelnen klein. Er summiert sich über acht Stunden, fünf Tage die Woche, Jahr um Jahr. Wer einmal in diesem Rhythmus gearbeitet hat, empfindet das Greifen nach der Maus als Unterbrechung — nicht als Werkzeug.

Die Landschaft

Die Tiling-WM-Landschaft ist nicht homogen. Eine Kurzfassung der Relevanten:

i3. Der Klassiker. Seit 2009, gepflegt von Michael Stapelberg und Community. Manuelles Tiling, exzellent dokumentiert, vorhersehbar. Wer einmal i3 gelernt hat, behält es. Der Goldstandard für Einsteiger.

sway. i3 für Wayland. Konfigurationskompatibel, Drop-in-Ersatz. Wer von i3 auf Wayland migrieren will, findet hier den direkten Pfad.

Hyprland. Der Neue. Wayland-nativ, GPU-beschleunigt, animiert, poliert. Schnelle Iteration, gelegentlich breaking Changes zwischen Releases. Wer Modernität über Stabilität stellt, ist hier richtig. Die Community ist groß, die Energie hoch, die Ecken noch rau.

AwesomeWM. Dynamisches Tiling, Lua-skriptbar, extrem flexibel. Wer programmieren will statt konfigurieren, findet hier sein Spielfeld. Die Lernkurve ist steiler, die Möglichkeiten grenzenlos.

dwm. Vom suckless-Projekt. Minimalistisch, C-Quellcode als Konfiguration, dynamisches Tiling. Wer philosophischen Purismus schätzt — hier. Keine Config-Datei; man patcht den Quellcode.

bspwm. Binary Space Partitioning. Fenster werden rekursiv in Hälften geteilt. Elegantes Konzept, konsequent durchgeführt.

xmonad. Haskell-konfiguriert. Für diejenigen, die funktionale Reinheit bis in den Fenstermanager tragen wollen.

Erwähnenswert bleiben herbstluftwm — manuelles Tiling, konfigurierbar über ein Kommandozeilen-Tool zur Laufzeit — und river, ein aufstrebendes Wayland-Projekt mit dynamischem Layout.

Keine dieser Lösungen ist falsch. Sie unterscheiden sich in Philosophie, Konfigurationsmethode und Reife. Aber sie teilen eine Eigenschaft: sie setzen voraus, dass man sich auf sie einlässt.

Die ehrlichen Barrieren

Tiling-Window-Manager sind nicht für jeden. Wer das verschweigt, betreibt Missionierung statt Beratung.

Lernkurve. Die ersten Tage sind unbequem. Man muss Tastenbindungen lernen, ein mentales Modell der Container-Hierarchie aufbauen, Workflows umstellen. Wer jahrzehntelang floating gearbeitet hat, greift reflexartig zur Maus — und die ist in einem Tiling-Setup oft nutzlos oder kontraproduktiv. Das vergeht, aber es vergeht nicht sofort.

Integration. Eine Desktop-Umgebung liefert polkit, Benachrichtigungen, Tray, Lockscreen, Display-Management, Barrierefreiheit, Eingabemethoden, Theme-Konsistenz. Ein nackter Tiling-Window-Manager liefert: Fenstermanagement. Alles andere muss man zusammensetzen. Wayland hat vieles verbessert, aber der Aufwand bleibt real. Wer ein rundum gesorgtes Erlebnis will, bekommt es nicht out-of-the-box.

Wartung. Dotfiles müssen gepflegt werden. Upgrades können Konfigurationen brechen — besonders bei Projekten mit schnellem Iterationstempo wie Hyprland. Wer ein Setup einmal baut und dann jahrelang nicht anfasst, mag frieren. Wer mitzieht, investiert periodisch Zeit.

Sparsame Defaults. Tiling-WMs liefern karge Voreinstellungen. Schön, wenn man minimalistisch denkt. Weniger schön, wenn man ein fertiges Erlebnis erwartet. Die Schönheit entsteht durch Konfiguration — und Konfiguration ist Arbeit.

Brüche im Ökosystem. Wayland hat das X11-Universum aufgebrochen. Einige Tiling-WMs sind Wayland-nativ (sway, Hyprland, river), andere bleiben X11-only (i3, awesome, bspwm, xmonad, dwm). Wer einen gemischten Workflow nutzt, muss Kompatibilität prüfen. XWayland hilft, ist aber nicht narrensicher.

Dotfiles: vom Nachteil zum Vorteil

Die Wartung von Dotfiles wurde eben als Barriere genannt — und sie ist eine, solange man sie allein betreibt. Ein einzelner Nutzer, der seine Konfiguration pflegt, hat niemanden außer sich selbst. Doch sobald mehr als ein Rechner im Spiel ist, verwandelt sich die vermeintliche Schwäche in den entscheidenden Vorteil.

Ansible — oder vergleichbare Templating-Werkzeuge — können Dotfiles als Jinja2-Templates vorhalten. Eine i3-Konfiguration, eine sway-Config, eine polybar-Leiste, eine Shell-rc: alles Templates mit Variablen. Hostname, Benutzername, Monitor-IDs, Tastaturbelegung, Farbpalette — pro Maschine eingesetzt, pro Team variiert. Ein Playbook, ein Repository, ein Aufruf — und der gesamte Desktop ist konfiguriert. Nicht auf einem Rechner. Auf hundert.

Idempotent. Wiederholbar. Versionskontrolliert. Dasselbe Playbook läuft auf dem Entwicklerlaptop, dem Rack-Server, dem Thin Client im Konferenzraum — und erzeugt jeweils die richtige Konfiguration aus demselben Template. Der Desktop wird Infrastructure as Code. Nicht als Buzzword, sondern als Praxis.

Versuchen Sie das Gleiche mit GNOME. GNOME speichert seine Einstellungen in dconf — einer binären Datenbank, die das GSettings-Backend bildet. Die Schnittstelle ist gsettings oder dconf auf der Kommandozeile, aber was dahinter liegt, ist kein Text. Man kann es nicht lesen, nicht diffen, nicht als Template vorhalten. Wer GNOME-Einstellungen automatisieren will, muss sie exportieren, in Skripte verpacken, per dconf load wieder einspielen — ein Umweg über Binärdaten, der sich jeder Templating-Logik widersetzt. Es funktioniert, aber es bleibt ein Fremdkörper im Infrastructure-as-Code-Workflow.

KDE ist in dieser Hinsicht etwas zugänglicher — viele Einstellungen liegen als INI-artige Textdateien vor —, aber die Konsistenz ist lückenhaft. Manche Werte wandern in plasmarc-Datenbanken, andere in rc-Dateien, die Struktur wechselt zwischen Major-Versionen. Wer ein KDE-Setup mit Ansible templaten will, kämpft gegen ein heterogenes Konfigurationsmodell, das nie für Automatisierung entworfen wurde.

Tiling-Window-Manager hingegen wurden dafür gebaut. Ihre Konfiguration ist von Anfang an Text, von Anfang an eine Datei, von Anfang an deterministisch. Keine Datenbank, kein Binärformat, kein Hidden State. Ein Template, das eine i3-Config erzeugt, ist so selbstverständlich wie ein Template, das eine nginx.conf erzeugt. Die Werkzeuge passen, weil das Material passt.

Für Teams bedeutet das: ein Administrator definiert ein Tiling-Setup — Workspaces, Tastenbindungen, Farben, Autostart — und deploys es per Ansible auf jeden Rechner. Neue Kollegen bekommen denselben Desktop am ersten Tag. Defekte Maschinen werden neu aufgesetzt und konvergieren zum Soll-Zustand. Ein Audit fragt: Wie ist der Desktop konfiguriert? Die Antwort liegt im Git-Repository. Nicht in einer binären Datenbank, die man erst auslesen muss.

Das ist kein Kosmetikargument. Es ist der Unterschied zwischen einem Desktop, den man verwaltet, und einem, der sich verwalten lässt.

Wer profitiert

Tiling-Window-Manager sprechen eine spezifische Sorte Nutzer an.

Entwickler, die in Editoren, Terminals, Browsern und Dokumentation simultan arbeiten. Sysadmins, die sechs SSH-Sessions, Logs, Monitoring und Wiki offen halten wollen. Data Scientists, die Notebook, REPL und Plot-Fenster nebeneinander brauchen. Power User, die ihren Desktop als Werkstatt verstehen, nicht als Konsumoberfläche.

Aber auch: Menschen, die Reproduzierbarkeit schätzen. Wer Dotfiles committet, hat einen Desktop, den man zerstören und wiederherstellen kann — in Sekunden, auf jedem Rechner. Das ist keine Spielerei. Es ist Backup-Strategie für den Arbeitsplatz.

Und Menschen, die alte Hardware beatmen. Ein Tiling-WM auf einem ThinkPad von 2015 läuft flüssig, wo eine volle Desktop-Umgebung stöhnt. Das ist ökonomisch und ökologisch relevant — Geräte leben länger, wenn die Software nicht mitwächst.

Umgekehrt: Wer primär in palettengesteuerten Grafikprogrammen arbeitet — Bildbearbeitung, Vektorgrafik, Videoschnitt, CAD —, für den ist Tiling oft die falsche Antwort. Diese Werkzeuge leben vom freien Arrangement großer Zeichenflächen, von schwebenden Paletten, von überlappenden Timelines. Sie in ein starres Raster zu pressen, schafft keinen Vorteil, sondern Friction. Tiling ist kein Dogma. Es ist ein Werkzeug für eine bestimmte Arbeitsform — und wer eine andere hat, sollte es bleiben lassen.

Eine Frage der Haltung

Tiling-Window-Manager verkörpern Werte, die die Open-Source-Bewegung im Kern ausmachen: Transparenz, Konfigurierbarkeit, Hackbarkeit, Reproduzierbarkeit. Die Konfiguration ist lesbar. Das Verhalten ist nachvollziehbar. Abhängigkeiten sind minimal. Niemand entscheidet über meinen Desktop, außer mir.

Das ist derselbe Impuls, der Menschen zu Linux bringt, zu Self-Hosting, zu offenen Standards. Nur halt am Desktop — dem Ort, den man täglich acht Stunden sieht, und den man dennoch am seltensten hinterfragt.

Hinzu kommt eine Kultur, die Tiling-WM-Nutzer teilen: die Dotfiles-Community. Konfigurationen werden öffentlich geteilt, committet, diskutiert — auf Plattformen, die ganzen Foren gleichen. Ein Setup ist kein Privatbesitz, sondern ein Entwurf, den andere studieren, adaptieren, verbessern. Das ist Open-Source-Denken im Kleinsten: Transparenz nicht als Pflicht, sondern als Selbstverständlichkeit. Wer so einen Desktop betreibt, betreibt ihn nicht als Konsument, sondern als Mitgestalter.

Wer KDE oder GNOME wählt, wählt nichts Falsches. Beide sind großartige Software. Aber wer sie wählt, ohne die Alternative je in Betracht gezogen zu haben, trifft keine Wahl. Er übernimmt ein Standardprodukt. Und das ist, angesichts einer Community, die sonst jeden Aspekt ihrer Infrastruktur diskutiert, erstaunlich.

Was libcom.de bedeutet

Seit fünfundzwanzig Jahren arbeite ich mit Linux-Desktops — in Einzelplatz-, Team- und Unternehmensumgebungen. Ich kenne beide Seiten: die gerundete Vollständigkeit einer Desktop-Umgebung und die puristische Konsequenz eines Tiling-Setups. Beide haben ihre Berechtigung. Die Frage ist nicht, welches besser ist. Die Frage ist, welches für wen besser ist.

Wer zu mir kommt, bekommt keine Standardempfehlung. Er bekommt eine Analyse: Wie arbeiten Sie? Welche Applikationen, welche Displays, welche Workflows? Wo sind Abhängigkeiten, die ein bestimmtes Setup erzwingen? Dann planen wir — stufenweise, dokumentiert, reversibel. Wer Tiling ausprobieren will, braucht keinen Sprung ins kalte Wasser. Man kann testen, pilotieren, evaluieren. Und wenn es nicht passt, kehrt man zurück — ohne Verlust.

Wenn Sie sich fragen, ob ein Tiling-Window-Manager für Sie oder Ihr Team infrage kommt, oder ob Sie einfach eine ehrliche Einschätzung Ihres aktuellen Desktop-Setups wollen: Schreiben Sie an contact@libcom.de. Wir machen eine ehrliche Bestandsaufnahme. Ohne Verkaufsdruck. Mit dem Blick auf das, was langfristig Bestand hat.

Fenster sollten nicht übereinander liegen. Das war die ursprüngliche Idee. Vielleicht ist es an der Zeit, sie wieder in Betracht zu ziehen.