Die Ankündigung des X.Org-Forks XLibre Mitte Juni erregte aus zwei Gründen einiges Aufsehen in der Linux-Blase. Es stellte sich die Frage, ob ein Fork auf der völlig veralteten Codebasis des klassischen X-Servers eine gute Idee ist. Zudem wurde die Notwendigkeit eines solchen Forks infrage gestellt. Dann war da noch die nicht unumstrittene Person des Entwicklers Enrico Weigelt.
Vorschlag zurückgezogen
Bei Fedora wurde recht schnell der Vorschlag eingebracht, den Fork anstelle der X.Org-X-Server-Implementierung von X11 in Fedora 43 aufzunehmen. Dieser Vorschlag wurde aber vom Antragsteller wegen fehlender Zustimmung der Community zurückgezogen, bevor er beim Steuerungskomitee FESCo zur Entscheidung anstand.
Was ist Fedora COPR?
Wer XLibre unter Fedora dennoch ausprobieren möchte, kann den Fork jetzt über das COPr-Repository beziehen. COPR steht für Cool Other Package Repo und ist ein einfaches Build-System, das es Entwicklern und Nutzern ermöglicht, eigene Softwarepakete zu bauen, zu verwalten und zu teilen, die aus unterschiedlichen Gründen nicht im offiziellen Fedora-Repository zu finden sind. Ähnliche Repositories bieten auch Ubuntu mit PPA, openSUSE mit OBS und Arch Linux mit dem AUR.
Jetzt gab der ursprüngliche Antragsteller Kevin Kofler, ein aktiver Fedora-Entwickler und ehemals Betreuer von Fedoras KDE-Spin, bekannt, dass die jetzt in COPR bereitstehenden Pakete für XLibre bei einer Installation unter Fedora 42, Fedora 43 und der Entwicklerplattform Rawhide den herkömmlichen X.Org-Server ersetzen.
Völlig ungetestet
Kofler schreibt, die Pakete seien derzeit völlig ungetestet und er freue sich über Rückmeldungen. Aufgrund der Ablehnung aus der Community gegen eine Aufnahme in Fedora plant Kofler derzeit keinen weiteren Versuch einer Integration, schließt dies für die Zukunft aber auch nicht aus. Neben dem COPR ist XLibre auch im OpenMandriva Entwicklerzweig Cooker zu finden.
Kontroverse
Die Aufregung um dieses Thema ist der Tatsache zu verdanken, dass Wayland sich immer weiter durchsetzt, aber Teile der Community an X.Org festhalten möchten. Die teilweise aggressive Diskussion um dieses Thema lässt an die Einführung von systemd denken. In beiden Fällen steht der Vorwurf im Raum, hier werde Linux von Red Hat eine Technologie übergestülpt, um deren Einfluss und Kontrolle auf die Entwicklung von Linux und speziell den Linux-Grafik-Stack zu stärken.
Die Entfernung des alten, etablierten Xorg-Servers aus Red Hat Enterprise Linux 10 (RHEL 10) und das strikte Vorantreiben von Wayland werden von vielen Nutzern als ein Zwang empfunden, der wenig Rücksicht auf Nutzerwünsche und bestehende Kompatibilitätsprobleme nimmt und das Machtstreben von Red Hat über wichtige Linux-Komponenten weiter zementiert.
Ich finde diese Lösung für fedora recht angemessen.
Hier noch eine Liste wie sich andere Distributionen dazu entscheiden. https://github.com/X11Libre/xserver/wiki/Are-We-XLibre-Yet%3F
Der Streit um Interessen wird selten harmonisch geführt. Schön im Linuxuniversum ist jedoch, dass vieles neben einander existieren kann.
X wird in Zukunft nur noch für wenige user interessant bleiben.
Für diese Wenigen könnte die Weiterentwicklung von X wie sie sich XLibre auf die Fahne geschrienen hat, jedoch noch sehr wichtig werden.
Wir werden erst in ca. 2 Jahren beurteilen können, welcher fork dann z.B. ein LXDE oder ein Trinity besser unterstützt.
Aus meiner naiven Position heraus, stellt sich die Frage: Bring XLibre gegenüber X.Org Vorteile und Verbesserungen oder nicht. Wenn ja, kann man das doch machen, wenn nein, dann nicht. Die Qualität und Nützlichkeit einer Software kann man doch nicht am deren Autor festmachen. Oder ist es etwa nicht so einfach?
Das Unternehmen stets nach mehr Kontrolle streben und ihre Möglichkeiten nutzen, diese auch auszuüben, ist der Normalfall, das nicht zu wollen (meist) auch.
Ich denke, wenn der Autor einer potenziell wichtigen Software die Entwicklung derselben mit einer privaten und ideologisch gefärbten Agenda verbandelt, dann sollte man schon genauer hinsehen.
Sehe ich etwas Zwiegespalten. Als Nutzer muss ich das hinterfragen. Aber “der Nutzer” ist nur eine Interessengruppe. Es gibt mindestens noch den/die Entwickler.
Wenn ich mir für meinen privaten Anwendungszweck eine Software schreibe (ohne copyleft, ohne erlaubnis der Modifizierung und weiterverteilung)¹ und die in ein public git pushe, dann hat erstmal niemand das Recht, Anforderungen zu stellen, selbst wenn es plötzlich 100k user oder mehr geben sollte.
Natürlich ist die Perspektive eine andere, wenn sich jemand aktiv um Aufnahme in eine Distri bemüht, dann sind auch die Guidelines einzuhalten. Ich wollte nur der Verallgemeinerung entegen reden, nicht die Sinnhaftigkeit oder das Zutreffen der allgemeinen Aussage in diesem speziellen Fall in Abrede stellen.
¹Freiheit bedeutet eben auch die Freiheit, Rechte einzuschränken.