Wayland -- der neue X-Server?

  • inkompatibel zu X (keine Chance auf Verbreitung)
  • Linux-spezifisch (nutzlos)
  • keine Netzwerktransparenz (XServer auf schwachen Clients ade)
  • braucht DRI fähige Treiber für *jede* exotische Karte (Matrox, Trident, ...)
  • GUI-Bibliotheken müssten angepasst werden. (Tk, XForms, Athena, Fox, FLTK, Motif)

Mit anderen Worten: Direkt in die Tonne.
 
Ich war begeistert, schon vor ein paar Tagen als ich es in einem Blog gelesen hab, bis da was von Linux-Kernel-Modesetting stand und ich mir sicher bin, dass das niemals portiert wird der Ramsch.

Aber Prinzipiell bin ich für eine Entkomplexisierung vom X-Kram. Ich brauche einfach keine Netzwerktransparenz. Wie wärs mit einem Grafischen Subsystem, welches auf sauberem 2D und OpenGL basiert, und nicht überall irgendein gefrickel. Is doch Mist.

Wahrscheinlich ist 90% vom jetzigen X.org gewrappe und Schusterei, damit das alles so toll Netzwerktransparent geht und auch ja von allem unterstützt wird.

Sorry, hab mal wieder meine 5min.
 
"for Linux".. Hmm komisch... War das viele Programme, die es auch für BSD gibt nicht so? :P

Ich persönlich bin auch nicht so angetan, gerade weil dann viele Umgebungen neu angepasst werden müssten. Außerdem sollte der X-Server nicht allzu viel übernehmen, da man sonst den WMs die (mögliche) Vielfalt nimmt.
 
Das was die Welt braucht ist nicht der zehnte, gutgemeinte Nachfolger zu X. X ist mit seiner komplett netzwerktransparenten Architektur und dem modularen Aufbau lange nicht so schlimm, wie immer alle sagen. Gut, es hat seine Probleme, das liegt aber vor allem an zwei Dingen:
- X11 ist uralt
- Xorg ist noch übleres Gefrickel als XFree86. Das wünscht man sich ja schon fast zurück.

Was wir wirklich bräuchten wäre ein X12, welches die Änderungen der letzten 20 Jahre berücksichtigt und eine dazugehörige, saubere Implementierung aus dem Jahr 2008. Meinetwegen dazu eine standardisierte Schnittstelle in den Kernel, ähnlich wie im Moment DRI. Dann könnte man auch /dev/mem und /dev/io mal begraben. Aber die Realität ist nunmal, dass sowas nie passieren wird, außer wir coden den Mist selbst. Xorg bauen viel lieber klicki-bunti Kram ein, ohne überhaupt ihre Hausaufgaben gemacht haben. Und eine stabile ABI zwischen X-Server und Kernel, mal ehrlich, sowas ist in Zeiten des Gnu kaum mehr umsetzbar. Ist im Moment in Mode alles mit jeder Unterversion umzufrickeln und sich dann über peinliche Fehler und ständige Inkompatiblitäten zu ärgen.

So, nun flamed mich an, aber das musste mal gesagt werden.
 
Und wieder so ein Thema, wo man sich denkt, dass es das beste wäre neu anzufangen. Eben das albekannte Proplem, dass sich die Meisten viel lieber jede Menge Ärger antun und ständig herumhacken, als mal vom Fundament an neu zu bauen, um sich und anderen jede Menge Ärger zu ersparen.

Meiner Meinung, ist die Kompatibilität relativ zu all dem alten Zeug nicht zwingend überall, ausnahmslos notwendig. Wenn's ansonsten solide ist, dann reicht das doch. Wenn man was neues macht, dann sollte man lieber in die Zukunft, als in die Vergangenheit blicken. Wenn man schön modular programmiert kann man ja wohl etwas machen, damit man all das legacy-Zeug unterstützt oder es findet sich eben ein Maintainer für den alten Kram.

Konkret zu diesem Projekt: Man muss einfach sehen, wie sich das entwickelt. Wir werden sehen, wie es sich in der Praxis schlagen wird. Wenn's gut genug ist, dann werden die "Macken", die hippodriver erwähnt hat auch ausgebügelt werden.
 
Die Rufe nach neuimplementierungen nerven mich langsam, muss ich ehrlich sagen.

SIcher, vieles ist veraltet in X und einiges könnte neuer, besser gemacht werden. Aber X hat sich sehr lange bewährt und alle Teile sind durch viele, viele Audits und Bigfixings gegangen.

"Lieber innovativ und neu, als rückwärtskompatibel" hört sich auch immer toll an, aber die Übergangsschmerzen bendenkt keiner.

Ich bitte euch einfach mal KDE4 zu betrachten. Die haben ihren kompletten Unterbau neuprogammiert, ohne Rücksicht auf alte Schnittstellen und ähnliches. Das hat in bestimmten Beriechen gut geklappt und ich weiß auch nicht ob es vermeidbar gewesen wäre.
Fakt ist aber, dass es seit fast zwei Jahren, keinen brauchbaren KDE-Desktop deswegen gibt. Bei KDE3 werden schon lange keine Sachen dazu entwickelt und KDE4 ist in bestimmten Punkten nichtmal ansatzweise auf dem Stabilitäts, Performance- und/oder Feature-level von KDE3.
Und KDE zählt als das Freie Software Projekt mit den meisten festen und regelmäßigen Commitern überhaupt.

Ich denke, sowas sollte man einfach berücksichtigen wenn man fordert, dass der Kern aller grafischen Benutzerinterkation aller freien unixartigen Betriebsysteme neugeschrieben werden soll.
 
Man merkt halt das Kommerzielle Interessen hinter vielen Dingen im OSS-Universum stehen, da geht es dann meist um die billigste Problemlösung .. und raus kommt son Krempel wie Xgl, ati vs. radeonhd, Ne Suse Std. Install mit 6GB. Find ich schade. Auch, und grade deswegen, weil so ein Projekt nicht einfach nochmal gestartet wird, denn es gibt ja schon eins.

Ach, ich hab keine Lust darüber nachzudenken. blurp
 
Meiner Meinung, ist die Kompatibilität relativ zu all dem alten Zeug nicht zwingend überall, ausnahmslos notwendig. Wenn's ansonsten solide ist, dann reicht das doch. Wenn man was neues macht, dann sollte man lieber in die Zukunft, als in die Vergangenheit blicken.
Zum Vergrößern anklicken....
Tatsächlich? Man sollte sich da nicht täuschen, wie wichtig Konstanz in der Kompatibilität ist. Gerade die Kompatibilität macht z.B. den Erfolg von Windows NT aus. Auch Unix-Systeme sind deshalb erfolgreich, weil sie sehr lange kompatibel sind. Wir haben auf Arbeit COBOL-Programme die heute noch laufen, auf neuen Mainframes wohlgemerkt! Und die COBOL-Programme sind über 20-30 Jahre alt und werden heute noch weiter entwickelt.

Ohne Kompatibilität ist im kommerziellen Bereich, wo die Firma nicht nach 5 Jahren wieder in der Versenkung verschwindet, sehr wichtig.

Natürlich kann man immer etwas neues entwickeln, aber dann nicht als Ersatz für das bewährte! Sondern nur zusätzlich als parallele API.

Da wo ich arbeite, gibt es z.B. folgende Regel bei strategisch wichtigen IT-Produkten (z.B. Datenbank-Server-Software): wenn die Firme jünger als 20 Jahre ist, wird deren Produkt nicht gekauft. Weil man einfach nicht weiß ob die morgen noch da sind. Deshalb wird z.B. bei uns nur DB2 und Oracle eingesetzt. Andere moderne DB-Produkte (wie z.B. von Intersystems) haben absolut keine Chance, selbst wenn sie uns den Support schenken würden: das Produkt ist nicht "alt" genug und somit ist keine Kontinuität garantiert.

Also, neue API und Produkte mögen technisch interessant sein, aber viele Firmen haben andere Prioritäten: es muß funktionieren und zwar (schon) lange!
 
Also ich meinte da oben nicht "reimplentieren". Ich meinte, dass man X.org lieber einmal sauber überarbeiten sollte. Eine neue Protokollversion, ein kompletter Codeaudit. Anstatt immer neuere Dinge einzubauen, lieber mal zwei oder drei Versionen Zeit nehmen, den vorhanden Kram zu modernisieren, zu verbessern und aufzuräumen. Wieso? Nun, da muss ich mir nur mein eigenes Xorg anschauen. Es leckt in 12h ungefähr 200 Megabyte Speicher und das auch noch, nachdem die Entwickler bereits etliche Speicherlecks identifiziert haben. XAA wurde kaputtgemacht, EXA läuft bis heute nicht. Was bringen mir Dinge wie tolle Automagie, wenn sie nicht funktioniert? Hier mit nv(4) kann da sogar ganz schnell mal die Grafikkarte abschmieren. Das System rennt weiter, gibt aber kein Bild mehr aus...
 
Yamagi schrieb:
Nun, da muss ich mir nur mein eigenes Xorg anschauen. Es leckt in 12h ungefähr 200 Megabyte Speicher und das auch noch, nachdem die Entwickler bereits etliche Speicherlecks identifiziert haben. XAA wurde kaputtgemacht, EXA läuft bis heute nicht. Was bringen mir Dinge wie tolle Automagie, wenn sie nicht funktioniert? Hier mit nv(4) kann da sogar ganz schnell mal die Grafikkarte abschmieren. Das System rennt weiter, gibt aber kein Bild mehr aus...
Zum Vergrößern anklicken....

Kann ich nicht bestätigen. Bei mir rennt EXA, die auto-erkennung läuft super, so dass ich nurnoch das deutsche tastaturlayout eintragen muss ind die xorg.conf, sonst nichts...
Lediglich das DRM ist unter FreeBSD kaputt, so dass ich keine Spiele spielen kann ohne das FreeBSD einfriert. Das funktioniert unter GNU/Linux aber tadellos.

Also ich meinte da oben nicht "reimplentieren". Ich meinte, dass man X.org lieber einmal sauber überarbeiten sollte. Eine neue Protokollversion, ein kompletter Codeaudit. Anstatt immer neuere Dinge einzubauen, lieber mal zwei oder drei Versionen Zeit nehmen, den vorhanden Kram zu modernisieren, zu verbessern und aufzuräumen.
Zum Vergrößern anklicken....
Das passiert doch die ganze Zeit. Von 6.8 auf 7.0 wurde xorg modularisiert, seit einer Weile gibt es ein neues xrandr (was zumindest bei mir super funktioniert!), man arbeitet an besser hotplug-unterstützung für eingabegeräte, ein DRI2 ist auch in entwicklung...
 
Ich habe auch eine Verbesserung beim Umstieg von FreeBSD 6.2 auf 6.3 respektive 7.0. Das Xorg hat wirklich genial automatisch meinen Breitbildmonitor erkannt und die korrekte Auflösung (1440x900) eingestellt. Das war unter FreeBSD 6.2 noch echt ein Krampf. Ich mußte nur das dt. Keyboard-Layout einstellen (Und das kann man ja auch grafisch in Gnome und sicherlich KDE machen).
 
Ein Rewrite bei einem Monster wie xorg hat einen entscheidenden Haken: Die Unterstützung neuer HW. Wenn sich die Jungs auf den Hintern setzen und den Krempel komplett überarbeiten, dann gibts über einen langen Zeitraum keine Unterstützung mehr für neue HW, weil die Entwicklerkräfte gebunden sind. Durch das modulare Design ist es ein mörderischer Verwaltungsaufwand, weil die Treiber-Leute warten müssen, bis Schnittstellen aus dem überarbeiteten Core zur Verfügung stehen und dann erst anfangen können ihre alten Sachen zu überarbeiten und zu portieren.

Da die OSS-Welt anscheinend als oberste Priorität ansieht den Erzfeind MS plattzumachen, nächstes Jahr der Durchbruch von *nix auf dem Desktop kommt und dannach die Weltherrschaft von freier SW beginnt, glaube ich nicht einen Moment daran, dass so etwas in annehmbarer Zeit passieren wird.
 
In meinen Augen braucht eine moderne graphische Oberfläche mehr Abstraktion.

Also nicht nur Bildschirm und Eingabegeräte, sondern auch Sound und dynamische Datenträger. Will heißen die Anwendungen auf dem Server sollten über Xorg auf dynamische Datenträger und Soundkarte zugreifen, damit man nicht mehr für jede Komponente eine eigene Lösung frickeln muss (siehe Soundserver) und man an einem Thin-Client Zugriff auf lokale Daten bekommt.
 
Amin schrieb:
Also, neue API und Produkte mögen technisch interessant sein, aber viele Firmen haben andere Prioritäten: es muß funktionieren und zwar (schon) lange!
Zum Vergrößern anklicken....

Ja, ist mir schon klar. Mit dem ganzen wird absolut keine Rücksicht auf kommerzielle Interessen genommen und war mehr theoretisch gemeint. Ich bin in letzter Zeit öfters in einer Bibliothek, wo man sich viel theoretisches Wissen aneignen kann und da kommt man auf solche Gedanken.

Das Problem (wenn man es so nennen will) ist eben, dass ohne "komplette" Neustarts die Entwicklung logischweiße viel langsamer von statten geht. Die Überlegung war also eher theoretischer Natur. So ein Neustart könnte aber wirklich einen ordentlichen Stoß nach vorne bringen.
 
Kamikaze schrieb:
In meinen Augen braucht eine moderne graphische Oberfläche mehr Abstraktion.

Also nicht nur Bildschirm und Eingabegeräte, sondern auch Sound und dynamische Datenträger. Will heißen die Anwendungen auf dem Server sollten über Xorg auf dynamische Datenträger und Soundkarte zugreifen, damit man nicht mehr für jede Komponente eine eigene Lösung frickeln muss (siehe Soundserver) und man an einem Thin-Client Zugriff auf lokale Daten bekommt.
Zum Vergrößern anklicken....

Solid? Phonon? Schon da! (siehe QT/KDE) :D

Aber im X-Server hat das nichts verloren. Der ist so schon fett genug...
 
Warum brauche ich eigentlich einen Soundserver? Sinn haben die Dinger nur in zwei Fällen, ich will entweder Sound über das Netzwerk übertragen oder ich muss um ein absolut kaputtes Soundsystem eines gewissen anderen Betriebssystems drum herumfrickeln. Da die wenigsten Nutzer ersteres kaum wollen und wir BSDler außerdem funktionierende Soundsysteme ohne Konstruktionsfehler besitzen, sind die Dinger ein völlig sinnloser Overhead.
 
Für mich sind externe Datenträger und Sound Benutzerschnittstellen, und die gehören für mich in den Zuständigkeit des XServers.
 
Also Sound kann ich als UI akzeptieren. Aber externe Speichermedien sind für mich normale Speichermedien. Ob die jetzt im PC-Gehäuse sind oder draussen, ist doch nur Kosmetik. Immerhin kann ich auch meine 3,5zoll interne SATA-HDD im Betrieb auswechseln... soll die jetzt auch über den X11 erreichbar sein?
 
Ja, finde ich schon. Schließlich kann ich die Leute nicht zum Server schicken um ihre USB-Sticks da rein zu stecken.
 
Moin,

Kamikaze schrieb:
Ja, finde ich schon. Schließlich kann ich die Leute nicht zum Server schicken um ihre USB-Sticks da rein zu stecken.
Zum Vergrößern anklicken....
Wer sagt das denn? Deine Client-Rechner haben keine USB-Ports?

Es wäre ganz gut, wenn sich die Entwickler mal wieder an die Philosophie von Unix erinnern würden: Für jedes Problem ein Tool und das darauf optimal abgestimmt.

Der X-Server ist für die Fensterverwaltung, Event-Management, Grafikprimitive (2D und 3D), Fonts und X-Protokoll zuständig. Für USB-Sticks und dergleichen ist bitteschön immer noch das Betriebssystem verantwortlich und so soll es auch bleiben. Wenn jemand einen Automounter für USB haben möchte, dann soll er sich Gedanken machen, wie man das ins Betriebssystem implementieren kann und nicht in den XServer.

Ich sehe schon, wir leben im Zeitalter der eierlegenden Wollmilchsäue mit Hybridturbo oder auf denglisch "big is beautiful". Es kann doch nicht das Ziel sein. Es wäre wirklich besser wieder zu kleinen, schnellen, funktionierenden, leicht zu wartenden Applikationen zurück zu kommen.
Man macht sich über Windows lustig, weil es immer mehr Speicherplatz benötigt, aber eine KDE- oder Gnome-Installation für einen Desktopuser steht dem in nichts nach.

Anstatt sich den Kopf über Wayland zu zerbrechen, sollte man sich überlegen, wie man das X-Protokoll und XOrg entrümpeln kann und so eine Beschleunigung erreicht.

Krank, nur noch krank...

JueDan
 
juedan schrieb:
Moin,


Wer sagt das denn? Deine Client-Rechner haben keine USB-Ports?
Zum Vergrößern anklicken....
Eben, die Client-Rechner mit dem X-Server haben USB-Ports. Blöderweise laufen die Applikationen auf dem Server und können die USB-Ports nicht erreichen.

Also muss man einen USB-Stick in den Server stecken. Dann haben aber alle Clients/X-Server darauf Zugriff.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben