Yserver: 5 wichtige Punkte zum X11-Server in Rust

Yserver bringt etwas zurück in die Schlagzeilen, das viele Linux-Nutzende schon halb abgeschrieben hatten: einen neuen X11-Server. Das Projekt ist in Rust geschrieben, läuft bereits mit MATE, Xfce und Cinnamon, bleibt aber klar experimentell.

Ein Display-Server ist normalerweise dann gut, wenn niemand über ihn redet. Fenster erscheinen, Eingaben landen im richtigen Programm, Monitore wachen nach dem Standby wieder auf. Fertig. Und wenn doch darüber geredet wird, dann meistens, weil etwas flackert, ruckelt oder nach einem Update beleidigt auf schwarzem Bildschirm bleibt.

Genau deshalb wirkt Yserver auf den ersten Blick wie ein kleiner Anachronismus. Während große Linux-Desktops immer stärker in Richtung Wayland schieben, schreibt Entwickler Jos Dehaes einen neuen X11-Server von Grund auf. In Rust. Mit direktem Zugriff auf DRM/KMS und Vulkan. Ohne den Anspruch, X.Org nachzubauen. Das Terminal lügt selten: Manchmal ist ein neues Projekt nicht die Zukunft, sondern ein präziser Kommentar zur Gegenwart.

Nach unserer Recherche bei digital-magazin.de ist Yserver vor allem deshalb interessant, weil es zwei Debatten kreuzt, die sonst getrennt laufen: die mühsame Ablösung von X11 durch Wayland und die Frage, ob alte Unix-Architektur mit moderner Sprache und weniger Ballast noch einmal sauberer gedacht werden kann.

Yserver ist kein X.Org-Klon

Der wichtigste Satz steht direkt in der Projektbeschreibung: Yserver will nicht X.Org intern nachbauen. Das klingt wie eine Fußnote, ist aber der Kern des Ganzen. X.Org trägt Jahrzehnte an Kompatibilität mit sich herum. Vieles davon war historisch sinnvoll, heute aber eher Museum mit Stromanschluss.

Yserver setzt enger an. Laut dem offiziellen GitHub-Repository von Jos Dehaes soll der Server reale Desktop-Umgebungen, Window-Manager und Anwendungen auf modernen Linux-Systemen ausführen. Nicht alles. Nicht jede Altlast. Nicht jeden Sonderfall aus der Workstation-Geschichte. Sondern das, was aktuelle X11-Software im Alltag tatsächlich braucht.

Gestrichen werden unter anderem mehrere klassische X11-Baustellen: mehrere X11-Screens, nicht mehr relevante Visuals jenseits von TrueColor, indirektes GLX, die alte DDX-Treiber-ABI und endian-swapped Clients. Wer gerade nostalgisch auf eine alte Netzwerk-X11-Konfiguration schielt, wird wenig Freude haben. Wer einen schlankeren X11-Server für aktuelle Hardware sehen will, schon eher.

Das Projekt ist unter MIT-Lizenz veröffentlicht. Der Code ist Rust, der Fokus Linux. FreeBSD beziehungsweise GhostBSD stehen zwar in der Planung, sind laut Design-Dokumentation aber noch nicht umgesetzt. Sauberer Status, keine Zauberei.

Warum ein neuer X11-Server unter Linux überhaupt Sinn ergibt

Die naheliegende Frage ist natürlich: Warum jetzt? Wayland ist längst Standard bei GNOME, KDE Plasma arbeitet seit Jahren daran, Fedora drückt stark in diese Richtung, Ubuntu baut X11-Sitzungen schrittweise zurück. Wer nur die großen Desktop-Projekte betrachtet, könnte sagen: Thema erledigt.

Ganz so glatt ist es nicht. X11 hängt weiterhin in vielen Ecken des Linux-Alltags. Manche Window-Manager sind dort zu Hause. Manche Workflows verlassen sich auf Verhalten, das Wayland aus guten Gründen nicht mehr erlaubt. Screenreader, Remote-Tools, Automatisierung, Spezial-Hardware, Grafiktabletts, uralte CAD-Software, seltsame Kiosk-Setups: Linux ist nicht nur Notebook plus Browser, und gerade Ubuntus Abschied von der klassischen X11-Sitzung zeigt diesen Druck sehr klar.

Yserver behauptet nicht, diese Lücken alle zu schließen. Das wäre Quatsch. Aber es zeigt, dass X11 als Protokoll nicht zwingend mit der historischen X.Org-Codebasis identisch sein muss. Das ist der spannende Punkt. Man kann X11-Anwendungen ausführen und trotzdem alte Treibermodelle, verstaubte Renderpfade und kryptische Kompatibilitätsfälle beiseitelegen.

Für Admins ist diese Unterscheidung wichtig. X11 ist nicht plötzlich modern, nur weil Rust draufsteht. Aber ein moderner X11-Server kann für bestimmte Systeme reizvoll sein, wenn Wayland noch nicht passt und X.Org nur noch verwaltet wird. Das ist keine Romantik. Das ist Wartung mit Werkzeugkasten.

Wir bei digital-magazin.de sehen Yserver deshalb weniger als Angriff auf Wayland. Eher als Beleg dafür, dass die Linux-Grafikschicht noch nicht an einem sauberen Endpunkt angekommen ist. X11 stirbt nicht dramatisch. Es verliert langsam Zuständigkeiten.

X11, Rust und die direkte Hardware-Schiene

Technisch interessant wird Yserver beim Backend. Der standalone Server spricht DRM/KMS direkt an und nutzt Vulkan für das Rendering. Das ist keine kleine kosmetische Änderung. DRM/KMS ist die Kernel-Schicht, über die moderne Linux-Systeme Displays, Modesetting und Scanout behandeln. Vulkan liefert den Grafikpfad. Dazwischen sitzt bei Yserver bewusst weniger historischer Klebstoff.

In der High-Level-Design-Dokumentation des Projekts beschreibt Dehaes eine Architektur mit Single-Threaded-Core, libseat-Unterstützung und klar getrennten Crates. Das klingt trocken. Ist es auch. Gute Display-Server-Architektur ist selten Partybeleuchtung.

Der Single-Threaded-Core ist dabei kein Rückschritt aus Bequemlichkeit. Er soll die X11-Protokollzustände besser nachvollziehbar halten. Kein wildes Geflecht aus Mutexen, keine Client-Pump-Threads für jede Ecke. Ein Kern, der Ereignisse sauber abarbeitet. Wenn man schon ein altes Protokoll implementiert, ist „verständlich“ kein Luxus.

Yserver nutzt libseat beziehungsweise seatd, damit der Server ohne Root laufen kann und Zugriff auf Grafik- und Eingabegeräte sauber vermittelt bekommt. Alternativ gibt es einen direkteren Modus mit Zugriff auf /dev/dri/ und /dev/input/. Auf einem Produktivsystem würde ich damit nicht herumspielen, ohne vorher ein Rettungs-Login offen zu haben. Backup zuerst. Freier TTY auch.

Was Yserver heute schon kann

Für ein junges Projekt ist der praktische Stand erstaunlich weit. Laut README kann Yserver vollständige MATE-, Xfce- und Cinnamon-Sitzungen starten. Getestet wurden außerdem FVWM3, e16 und Window Maker. Das ist keine akademische „Fenster mit Demo-App“-Übung mehr, sondern schon ziemlich nah an realem Desktop-Alltag.

Auch bei den X11-Erweiterungen ist die Liste ordentlich. Unterstützt werden unter anderem Composite, DAMAGE, DPMS, DRI3, GLX, MIT-SHM, Present, RANDR, RENDER, SHAPE, SYNC, XFIXES, XInputExtension, XKEYBOARD und XTEST. Wer schon einmal einen Desktop ohne die passende RANDR-Unterstützung betrieben hat, weiß: Monitorverwaltung ohne diese Bausteine fühlt sich schnell nach Kellerfund an.

Die Hardwaretests lesen sich ebenfalls breiter, als man bei einem Ein-Personen-Projekt erwarten würde. AMD Ryzen/Radeon, Intel Kaby Lake iGPU, NVIDIA mit proprietärem Treiber, Snapdragon X1 mit Adreno-Grafik, Apple M1 und M2 unter Asahi Linux sowie virtio-gpu in virtualisierten Umgebungen tauchen in der Projektbeschreibung auf. Das heißt nicht, dass alles überall rund läuft. Aber es ist mehr als ein Screenshot auf dem Entwickler-Laptop.

Besonders hübsch: Yserver kann Compiz-Effekte ausführen, nachdem GLX_EXT_texture_from_pixmap implementiert wurde. Ein neuer X11-Server in Rust, der Compiz zeigt. Linux-Geschichte macht manchmal einen sehr trockenen Kreis.

Die Einschränkungen stehen aber direkt daneben. GLX_EXT_texture_from_pixmap funktioniert laut Projekt nicht mit dem proprietären NVIDIA-Treiber. VT-Wechsel hängen vom Startmodus ab. Einige Wege sind getestet, andere nicht. Das ist kein Fehler in der Kommunikation, sondern genau die Art Transparenz, die man bei frischer Infrastruktur braucht.

Die Sicherheitsfrage bleibt der dicke rote Marker

Jetzt der Teil, den man nicht wegmoderieren sollte: Der Sicherheitsmodell-Abschnitt ist noch unfertig. In der Design-Dokumentation steht ausdrücklich, dass Yserver aktuell keine Capability-Beschränkungen pro Client durchsetzt. Clients können andere Fenster lesen, globale Eingaben beobachten und die Zwischenablage inspizieren.

Wer X11 kennt, zuckt jetzt nicht völlig überrascht zusammen. Genau solche Schwächen gehören zu den Gründen, warum Wayland überhaupt so viel Schub bekommen hat. X11 vertraut Clients traditionell stark. Wayland schneidet diese Freiheiten stärker zu, was für Sicherheit gut und für alte Tools manchmal unbequem ist.

Bei Yserver bedeutet das: Nicht auf Produktionssystemen testen. Nicht auf Maschinen mit sensiblen Sessions. Nicht dort, wo Sie Passwortmanager, Banking, Kundenumgebungen oder interne Admin-Oberflächen offen haben. Ein frischer Testrechner, eine VM oder eine Spielwiese mit sauberem Snapshot sind die richtige Umgebung.

Das ist keine übertriebene Vorsicht. Ein Display-Server sitzt an einer heiklen Stelle: Eingabe, Fensterinhalte, Clipboard, Session-Lebenszyklus. Wenn diese Ebene wackelt, ist der Rest egal. Da hilft auch Rust nur begrenzt. Rust reduziert bestimmte Speicherfehlerklassen, ersetzt aber kein fertiges Rechtekonzept.

Genau hier wird Yserver am spannendsten und am riskantesten zugleich. Das Projekt kann zeigen, wie viel X11 man heute noch braucht. Es kann aber auch zeigen, warum X11-Designgrenzen nicht einfach verschwinden, wenn die Implementierung neu geschrieben wird.

Yserver gegen Wayland? Falsche Baustelle

Die Versuchung ist groß, daraus einen kleinen Kulturkampf zu bauen: hier Wayland, dort X11, dazwischen ein Rust-Projekt mit Schraubenschlüssel. Das wäre bequem, aber technisch dünn.

Wayland löst andere Probleme. Es verschiebt Verantwortung in den Compositor, zieht Sicherheitsgrenzen enger und passt besser zu moderner Grafik-Hardware. Dass diese Umstellung weh tut, liegt nicht nur an Wayland. Es liegt auch daran, dass Linux-Desktops jahrzehntelang Verhalten erlaubt haben, das aus heutiger Sicht eher freizügig war. Screensharing, global hotkeys, Farbmanagement, Remote-Desktop, Accessibility: Alles lösbar, aber selten ohne Reibung.

Yserver löst diese Wayland-Fragen nicht. Es bietet stattdessen einen neuen X11-Pfad für Systeme, die X11 weiterhin brauchen oder bewusst nutzen. Das kann für klassische Desktop-Umgebungen, historische Window-Manager oder spezielle Anwendungen interessant werden, zumal Fedora, GNOME und KDE Plasma den Wayland-Kurs inzwischen ziemlich konsequent fahren. Mehr nicht. Aber auch nicht weniger.

Wer heute GNOME oder KDE Plasma auf aktueller Hardware nutzt und keine Sonderfälle hat, wird durch Yserver kurzfristig wenig gewinnen. Wer Xfce, MATE oder Cinnamon in kontrollierten Umgebungen betreibt, könnte das Projekt im Auge behalten. Nicht als Ersatz am Montagmorgen. Eher als technisches Radarobjekt.

Rust hilft, aber Rust macht keinen fertigen Desktop

Dass Yserver in Rust geschrieben ist, ist mehr als ein Marketingdetail. Speicherfehler in Grafik- und Eingabestacks sind kein theoretisches Problem. Ein modernerer Sprachansatz kann hier helfen, Teile der Angriffsfläche zu senken und Code klarer zu strukturieren. Gerade bei Protokollparsern, Ressourcenverwaltung und Lebensdauern ist Rust attraktiv; auch Debians Rust- und Build-Themen zeigen, wie stark diese Sprache im Linux-Unterbau angekommen ist.

Aber: Rust ist kein Schutzhelm für Architekturentscheidungen. Wenn ein Client konzeptionell zu viel sehen darf, verhindert die Sprache das nicht. Wenn ein Treiberpfad auf bestimmter Hardware zickt, macht Ownership-Checking daraus keinen stabilen Desktop. Und wenn nur eine Hauptperson entwickelt, bleibt Bus-Faktor ein sehr reales Wort.

Interessant ist außerdem der KI-Aspekt. It’s FOSS weist darauf hin, dass im Repository Dateien wie CLAUDE.md und AGENTS.md liegen und Claude Code beim Projekt eine Rolle gespielt haben dürfte. Das passt zu einer Entwicklung, die wir bei digital-magazin.de seit Monaten beobachten: KI-Coding-Agenten beschleunigen nicht nur Webapps und kleine Tools, sondern greifen inzwischen in systemnahe Projekte hinein.

Das ist beeindruckend. Und es verlangt Disziplin. Ein Display-Server ist kein Todo-Listen-Experiment. Wer mit KI-Unterstützung an solch sensibler Infrastruktur arbeitet, braucht Tests, klare Designgrenzen und harte Reviews. Sonst bekommt man schnell Code, der beim Demo-Video glänzt und beim Randfall knirscht.

Bei Yserver gibt es immerhin Hinweise auf Regressionstests mit der X.Org X Test Suite und rendercheck. Das ist ein gutes Zeichen. Nicht ausreichend für Vertrauen im produktiven Betrieb, aber besser als reines „läuft bei mir“.

Für wen Yserver interessant ist

Realistisch betrachtet hat Yserver im Moment drei Zielgruppen. Erstens Entwickelnde, die verstehen wollen, wie ein X11-Server auf moderner Linux-Hardware aussehen kann. Zweitens Desktop-Bastelnde mit Lust auf MATE, Xfce, Cinnamon und ungewöhnliche Display-Stacks. Drittens Distributionen oder Projekte, die langfristig nicht jede X11-Altlast mitschleppen wollen, aber X11 auch nicht sofort abschalten können.

Für normale Nutzende ist die Antwort nüchterner. Wenn Ihr System stabil läuft, lassen Sie es laufen. Wenn Wayland bei Ihnen funktioniert, bleiben Sie dabei. Wenn Sie X11 brauchen, ist X.Org weiterhin der bekannte Pfad. Yserver ist heute Beobachtungsstoff, kein Wochenend-Migrationsplan.

Das heißt nicht, dass das Projekt kleinzureden ist. Im Gegenteil. Gerade weil der Linux-Desktop oft zwischen „alles ist fertig“ und „alles ist kaputt“ diskutiert wird, sind solche Experimente wertvoll. Sie zeigen, welche Teile alter Infrastruktur wirklich gebraucht werden und welche nur noch aus Gewohnheit mitreisen.

Linux lebt von solchen Nebenpfaden. Manche enden nach drei Releases. Manche verschwinden. Manche liefern eine Idee, die später anderswo landet. Yserver muss nicht der neue Standard werden, um nützlich zu sein.

Was jetzt zählt

Der nächste Prüfstein ist nicht die Versionsnummer, sondern Alltag. Startet Yserver zuverlässig aus LightDM? Wie verhält er sich bei mehreren Monitoren, Suspend/Resume, HiDPI, Grafiktreiber-Macken, Eingabegeräten, Compositing und längeren Sessions? Wie schnell werden Sicherheitsgrenzen konkret? Wie gut lassen sich Bugs reproduzieren?

Die Antwort darauf kommt nicht aus einem Launch-Artikel. Sie kommt aus Tests, Issues, Distributionsexperimenten und sehr wahrscheinlich aus ein paar kaputten Sessions. Willkommen im Linux-Grafikstack.

Als Signal ist Yserver trotzdem stark. X11 ist nicht tot, nur weil Wayland gewinnt. Rust ist nicht magisch, aber hilfreich. Und KI-unterstützte Entwicklung ist inzwischen auch dort angekommen, wo man früher eher C, Makefiles und sehr viel Kaffee vermutet hätte.

Mein pragmatischer Eindruck: Yserver ist kein Projekt, das Sie heute installieren müssen. Es ist ein Projekt, das man beobachten sollte. Denn wenn jemand in wenigen Monaten einen X11-Server baut, der echte Desktops startet, dann sagt das etwas über alten Ballast, moderne Werkzeuge und den Zustand des Linux-Desktops aus. Nicht alles davon ist bequem. Genau deshalb ist es interessant.