“Es wäre sehr schön, wenn der X-Server direkt OpenGL benutzen könnte. Denn dann hätten wir hardwarebeschleunigte Effekte, die nicht nur gut aussehen sondern auch sinnvoll sind. Es gibt so ein Projekt, XGL.” So beginnt der KDE-Entwickler Aaron Seigo einen seiner jüngsten Blogeinträge. Doch im nächsten Satz nennt er das Problem dabei schon beim Namen: Die Entwicklung an der XGL-Architektur wurde kürzlich komplett hinter verschlossene Türen gesperrt. Somit bleibt der Community der Zugang zu einer der wichtigsten Technologien im Desktop-Bereich von nun an verwehrt.
Die Firma hinter dieser Aktion ist Novell, dasselbe Unternehmen also, das sich “a Linux Company” auf die Fahnen geschrieben hat. Seinen Anfang nimmt das Drama im November des Jahres 2004. Damals kündigte Dave Reveman, Novell-Mitarbeiter, erstmals an, dass er einen X-Server entwickelt habe, der auf der Xgl-Architektur aufsetzt. Mit ihm ist es möglich, Grafikaktionen – OpenGL-kompatible Hardware vorausgesetzt – hardwarebeschleunigt auszuführen. Das X-System wäre damit endlich gleichauf mit den Platzhirschen Windows und vor allem MacOS X. Die Community ist begeistert, Prominenz wie der Gnome-Entwickler Nat Friedman preisen Xgl als sehr zukunftsträchtig an. Xgl bekommt ein Heim auf Freedesktop.org. Es scheint, als würde der Durchbruch auf dem Desktop endlich gelingen.
Doch einige Monate später kommt die Ernüchterung; Jon Smirl, der an einem Xgl-X-Server arbeitet, kündigt an, die Entwicklung zu stoppen. Smirl ist frustriert darüber, dass sich in der Community niemand findet, der ernsthaft an der Weiterentwicklung und Modernisierung der X-Architektur arbeiten will. (siehe auch seinen ausführlichen Artikel zum Thema Linux-Grafik.)
Doch die Entwicklung an Xgl läuft weiter, vorerst. Denn mittlerweile ist Xgl kein klassisches freies Softwareprojekt mehr. Novell gewährt keinen Zugriff mehr auf den Quellcode. Die wenigen Programmierer, die Linux also noch zum raschen Durchbruch auf dem Desktop verhelfen könnten, werden ausgesperrt. Welches Ziel Novell damit verfolgt, ist nicht klar. Stellungnahmen gibt es nicht.
Doch Novells Schritt ist nicht das wirkliche Problem der Open-Source-Gemeinde. Denn wie Jon Smirl es im August bereits bemängelt hat, fehlen einfach die Programmierer, die sich um die dringend notwendigen Innovationen kümmern würden. Es gibt zwar viele Projekte, die der Grafik mit Linux (oder KDE oder Gnome) auf die Sprünge helfen wollen, doch bahnbrechende Resultate (die es durchaus schon gibt) bekommen die User kaum mit.
Der wichtigste Schritt ist also, den Entwicklern der Beteiligung an Projekten wie EXA oder Luminocity schmackhaft zu machen und für die Neuentwicklungen genug Marketing zu betreiben, dass auch Anwendungsprogrammierer und letztendlich die Anwender selbst auf den Zug aufspringen.
Grafikprogrammierer, vereinigt eucht! Damit wir im nächsten Jahr nicht nur ein paar nette Effekte haben, sondern den besten Desktop, den es je gegeben hat.
Hallo Max,
meiner Meinung nach ist Grafik nicht das entscheidende Problem von Linux. Ich denke die entscheidenden Punkte für Linux auf dem Desktop sind Hardware Unterstützung und Usability.
Da kann man dem grossen Monopolistern vorwerfen was man will, aber diese zwei Faktoren wurden stets berücksichtigt und haben zum Erfolg geführt.
Die bei einigen Grafikkarten fehlende Beschleunigung unter Linux ist schon fuer einige Linuxinteressenten ein Hemmnis. Am Konzept der Treiber muss in der Zukunft noch gearbeitet werden. Nach meiner Ansicht bei allen Betriegssystemen. Auf lange Sicht haben nur die Firmen eine Ueberlebenschance die es jetzt schaffen eine definierte Schnittstelle zu schaffen die fuer alle Betriebssysteme geeignet ist. Die Binaries (vor allem die proprietaeren), die in die Grafikkarte geladen werden, muessten eine standardiesierte Schnittstelle haben. Sie muessten von der Art sein, dass jedes Betriebssystem diese in den Grafikkartenspeicher laden kann und darf. Es muesste die Uebergabe der Daten an das Prgramm auf… Mehr »
Es gab mal das Projekt ‘UDI’ (Einheitstreiber über Betriebssystemgrenzen hinweg) es wurde aber von den Kernelentwicklern geblockt.
[1] http://projectudi.sourceforge.net/
es wurde aber von den Kernelentwicklern geblockt. Einspruch! Niemand kann eine Software „blocken” (was ist das überhaupt für ein Wort?), die er nicht selbst vertreibt. Es stand den Distributoren frei, UDI zu nutzen und in die Distributoren einzubauen. Einige haben es auch getan. Allerdings gab es keine Treiber, die auf UDI aufgebaut haben. Das Grundproblem ist, dass sich Anforderungen an die Software schneller ändern als die Doku dazu. Wenn das das alte Interface überfordert ist, wird eben ein neues Interface implementiert, statt die Daten „irgendwie” über ein antiquiertes Interface zu tunneln. Wer hat damals schon an PAE, NUMA, Direct I/O… Mehr »
Klar können die Kernelentwickler blocken. Was sollen denn die Distributoren machen wenn jede wichtige Funktion im Kernel als GPL-Only exportiert wird? Alles wieder ummodeln? Das wäre Dummsinn. Weil Du Dich ja anscheinend so gut im Kernel auskennst, wie würdest Du denn das Verhalten der ‘Kernelhalbgötter’ zu Hans Reiser bezeichnen? Klar ist der Typ schwierig aber sein neues Filesystem wird geblockt. Ob Dir das Wort gefällt oder nicht es ist so. Aber egal. Meiner Meinung nach wird es in absehbarer Zeit einen Fork geben. Wenn ich das Getue von GKH sehe, daß stößst einigen Leutchen ganz schön auf. Aber man wird… Mehr »
Du schmeißt hier meherere Dinge zusammen, die nicht zusammen passen. GPL-Symbole Niemand hindert einen Hersteller daran, seine Treiber unter GPL anzubieten, bzw. einen GPL-Wrapper zu schreiben, der nur aus calls auf GPL-Symbole besteht. Im Prinzip liegt das an der Grenze zum GPL-Verstoß, aber da es sich zu einer seit Jahren gängigen Praxis entwickelt hat, ist dagegen wohl auch nicht mehr viel zu sagen. Zuvorkommende Hersteller packen natürlich so viel wie möglich in den GPL-Teil, und nur die wirklich geheimen Dinge in das Binärmodul. Meist ist es wohl auch nicht der böse Willen der Firma, sondern die Vorsicht der Rechtsabteilung, die… Mehr »
Die Beweggründe, proprietäre Lösungen zu schaffen (nicht nur Schnittstellen, sondern über den IT- Bereich hinaus betrachtet) sind in der Regel mangelhafte Industrienormen. Möchte jemand etwas Innovatives entwickeln und ihm reichen Funktionen und Standards dabei nicht aus, muß er sich eine eigene Basis zur Umsetzung ausdenken. Ein gutes Beispiel hier für war einst HTML. Als das Internet für kommerzielle Zwecke und Privatanwender geöffnet wurde, waren benutzerfreundliche und schicke Webseiten mit Werbeeffekt gefragt. Mit dem damaligen W3C-Standard kam man nicht so weit und eine damals neue Lösung – Java Applets- diente dazu, Webseiten bunt und blinkend zu machen. Mitte der 90er Jahre… Mehr »
Hallo GoaSkin, Dein Artikel enthält einige gravierende Fehler, so scheinst Du Dich noch nie näher mit X beschäftigt zu haben, anders kann ich z.B. Deine Aussage “wobei X11 eigentlich schon eine fast tote Geschichte war, die wieder herausgekramt wurde.” nicht deuten. X war -und ist- die mit Abstand verbeitetste grafische Oberfläche für Unix-artige Betriebssysteme. In der Anfangszeit von Linux (ich habe mit Version 0.99.6 angefangen) existierte nicht “eine freie Implementierung namens XFree86”, sondern eine Portierung auf 80386-kompatible Prozessoren namens X386; die Sourcen des X Window Systems sind seit über 20 Jahren frei (MIT Lizenz). Die Versionsnummer wird nur dann geändert,… Mehr »
Wie viel würde das denn insgesamt Kosten? Mannjahre, Zeit, Entwickler?
Hallo Christian,
die Entwicklung von Open-Source-Software lässt sich, wie du ja sicher weißt, nur schwer in Mannjahre (oder Mannmonate o.ä.) umrechnen. Allerdings ist EXA AFAIK schon sehr weit gediehen. Auch Xgl war schon recht weit, bevor Novell den Code verschlossen hat.
Wie ich Novell kenne, würde es sehr helfen, wenn eine große Masse an Entwicklern und Anwendern eine Art Petition an Novell unterschreiben würde. Ich erinnere mich nur an Novells Entscheidung, KDE nicht mehr zu unterstützen. Nach massiven Protesten aus der Öffentlichkeit haben die Amerikaner dann eingelenkt [1].
Gruß,
Max
[1] https://www.linux-community.de/Neues/story?storyid=18272
Ja, schön, aber man muss doch ungefähre Vorstellungen haben, was man dabei investieren müsste um auf den Stand x zu kommen. Ist das ein Eimer ohne Boden wird man eine stabile Plattform sehen?
Wenn das Problem von XGL ist, dass es von Novell verschlossen wurde, dann ist für mich die Frage warum. Ich meine, was kann Novell damit “verschlossen” anfangen?
Bzgl. Petition: WER ist bei Novell dafür verantwortlich, wem obliegt die Entscheidung?
Eine schnelle Darstellungsgeschwindigkeit ist gut, aber mein olles XF86 4.x ist nie unannehmbar langsam gewesen. Mag ja sein, daß der Summit XIG-Server in einer hundertstel Sekunde 100 mal mehr Schriftzeichen glätten kann, aber ohne Kenntnis der genauen nVIDIA- und ATI-Hardware und an Heimanwender angepasste Preise wird XIG nie populär. Allgemein bin ich aber dafür, den bestehenden X-Server nur noch zu pflegen und an bestimmte Grafikkarten anzupassen, bis ein neuer Y-Server fertig ist. Wichtig ist dabei, dass der Server in der Grundversion schlank und modular aufgebaut ist. Mit einigen Rückwärtskompatibilitäten wird man wohl brechen müssen. Das Y-Server-Projekt ist leider noch nicht… Mehr »
Naja zunächst mal ist Grafik unter Linux im Allgemeinen und X11 im speziellen besser, als man aus deinem Posting entnehmen könnte insofern kann ich der Überschrift “Was Linux fehlt? Grafik!” nicht zustimmen. All die graphischen Anwendungen unter Linux haben genug Grafik. ;-) Momentan ist ihr größtes Problem nicht die Anzahl der Features und Eyecandy, sondern eine aufgeräumte und trotzdem nicht simplifizierende Oberfläche (DER große Fehler von vielen (System-)Programmen unter Windows, bei denen man das Gefühl hat irgendwie keine Kontrolle über das System zu haben). Zum anderen wundert es mich überhaupt nicht, dass Xgl (wie kdrive) keine große Priorität hat und… Mehr »
Hallo, bei den meisten X-Nachfolgern geht es gar nicht so sehr um Performance oder 3D-Fähigkeiten, sondern darum, die Einschränkungen des X-Protokolls endlich loszuwerden, das zwar schön netzwerktransparent ist, aber halt nur Tastatur, Maus und eben die Bildschirmdarstellung berücksichtigt. Beim Sound hört das Ganze schon auf, mehr als ein Konsolenpiep ist nicht drin. Dann möchte man auch noch Schnittstellen (z.B. USB) und, wo man schon dabei ist, die Übertragungsdaten komprimieren, Speicherressourcen anbinden und und und… Das geht zwar alles über andere Protokolle, aber man muß sich eben auch um jede Verbindung einzeln kümmern. Warum soll ich denn nicht einen dicken Server… Mehr »
Naja die Leute reden immer von Einschränkungen des X-Protokolls und dass es so asbach-uralt sei. Sicher gibt es Dinge die man heute anders lösen würde, aber erstens mal scheint das X-Protokoll ja unerwartet flexibel zu sein, dass man auf X basierend ohne bestehende Applikationen irgendwie anpassen zu müssen die beste Remotdesktoplösung schaffen konnte, nämlich NX [1] und zum anderen Linuxdesktops alles andere als trist sind. Ich bestreite konkret die Aussage, dass X derart kaputt ist dass man etwas komplett neues bräuchte (ja ich bestreite sogar, dass der konkrete X.Org-Server derart kaputt sei, dass es einfacher sei einen komplett neuen X-Server… Mehr »
Hallo Daniel, > Ich bestreite konkret die Aussage, dass X derart kaputt ist dass man etwas > komplett neues bräuchte (ja ich bestreite sogar, dass der konkrete > X.Org-Server derart kaputt sei, dass es einfacher sei einen komplett neuen > X-Server zu schaffen). Ich weiß nicht, wie “kaputt” der X.org oder XFree-Server ist. Was heißt, man “braucht” etwas Neues? Die aktuelle Grafik ist in Ordnung und sehr alltagstauglich, eben weil sie uralt und damit sehr ausgereift ist. Der Punkt, auf den ich hinauswollte, ist eher, daß seit einiger Zeit die Differenz zwischen dem, was technisch machbar ist und vorteilhaft erscheint,… Mehr »
Die Situation hat sich wohl etwas wieder entschärft. Xgl wird wieder der Community bereitgestellt[1]
[1] http://www.golem.de/0601/42457.html