Wayland verschiebt das Rendering von X auf den jeweiligen Window Manager (kwin, mutter, ...). Somit ist dieser dann unabhängig von X und zeichnet die Fenster selbst. Dieser Ansatz ist vom Prinzip her einfacher (da direkter) als zunächst Kommunikation mit X aufzubauen, welches dann die Fenster zeichnet.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 11:55 #
Ja, aber rechtfertigt das, ein so bewährtes und stabiles System wie X komplett zu ersetzen? Mit dem Argument "es geht auch einfacher" könnte man z.B. auch den kompletten Linuxkern u.v.m. neu schreiben. Wo sind die komkreten Vorteile von Wayland? Linux auf dem Desktop hat ja schließlich weiß Gott andere Probleme als ein angeblich veraltetes Grafiksystem.
Die Grafik ist eine der größten Baustellen unter Linux, wo sich seit gefühlter Ewigkeit nichts getan hat. X11 ist im Wachkoma und Xorg hängt auch in alten festgefahrenen Schienen fest. Wenn durch Wayland etwas Innovation und neuer Schwung kommt ist es nur gut. Wer spezielles von X noch benötigt, für den bleibt es doch noch bestehen.
Man muss das Ganze etwas historischer betrachten. X entstand zu einer Zeit und in einem Umfeld bei der viele Infrastrukturen zu einem großen Teil aus Rechnern und Großrechnern bestanden und das Konzept verfolgt wurde, dass möglichst alle Arbeiten vom Hauptrechner erledigt wurden und die Clients und deren Arbeit minimal gehalten wurden. Da bot es sich natürlich an auch die komplette grafische Darstellung einer Arbeitsumgenug auf dem Großrechner machen zu lassen. Der hatte ja genügend Arbeitsspeicher und ausreichende Grafikhardware um das umzusetzen. Beides war damals nämlich teuer.
Über die Zeit verändern sich Dinge nun aber auch. Nicht nur die Hardware an sich, sondern auch die Konzepte. Heute hat jeder Rechner genügend Resourcen um problemlos sich selbst für die grafische Darstellung zu kümmern. Auch die heute gängige Grafikhardware ist für solche eine historische Art der Anwendung gar nicht ausgelegt. Das Konzept der Rechner/Großrechner Infrastruktur wie damals kommt immer weniger, fast gar nicht mehr zum Einsatz. Das sieht man auch daran, dass die heutigen Toolkits alle Zeichenoperationen selbst übernehmen. Das Problem daran ist, dass diese vom X Protokoll nicht gedekt werden. Die neuste Protokollversion ist 11 (20 Jahre alt?) und danach war Schluss. Und bevor eine Version 12 kommt, die eh keiner nutzen wird, fallen Ostern und Weihnachten zusammen, da wegen des ganzen xfree86-xorg Hick Hacks da sowiso kaum einer mehr durchblickt. Zwar haben die X Leute nötige Optimierungen vorgenommen um den Overhead bestmöglich zu vermeiden, aber diese ganzen Syncs zwischen Client und Server lassen sich dennoch kaum vermeiden. Heißt also, es gibt immer weniger reine X Anwendungen die wirklich nur die Zeichenoperationen aus der xlib verwenden. Damit wird auch die Netzwerktranzparenz irgendwo obsolet. Zwar erzählen hier immer wieder irgendwelche, dass die ja ach so sehr gebraucht wird, aber wenn ich erlich bin, wüsste ich nicht wo die Netzwerktranzparenz noch *effektiv* zum Einsatz kommt. Und wenn ich von Linux irgendwo remote zugreifen muss, dann über ssh, nfs, über die verschiedenen eigenen Server Funktionen einzelner Anwendungen (emacs, rxvt-unicode, tmux ...), oder wenn es sein muss über FUSE. Ich wüsste nicht aus welchem Grund ich *heute* eine grafische Anwendung von einem entfernten Rechner mir über X hier herholen müsste. Ich kenne diverse Leute die da sogar lieber VNC nehmen würden.
Und hier kommt die Crux an der Sache, die jeder schon mal gemerkt hat der mit der xlib gearbeitet hat. Man hat mit einem extrem schwierigen historischen Rattenschwanz zu kämpfen. Ja, das funktioniert alles aber der zeitliche Aufwand, der letzten Endes damit auch ein wirtschaftlicher ist, ist enorm.
Und selbst jetzt und zukünftig wo wieder Client/Mainserver Konzepte am kommen sind (Cloud, Apps usw.) werden die Anforderungen und technischen Gegenheiten sich so dermaßen von der damaligen unterscheiden, dass der Glaube eines 'Wiederauflebens' des klassischen X Server pure Blasphemie ist.
Daher ärgern mich auch diese EXTREM KURZ gedachten Ausrufe a la "Die schmeißen gut bewährtes einfach weg!". Solch Leute sollten sich klar machen, dass nur weil etwas aktuell funktioniert nicht in irgendeiner Weise optimal sein muss. Man sollte über den eigenen Schatten springen und einfach akzeptieren, dass nicht aus Hype sondern wirklich technischen wie konzeptionellen Gründen ein Neuanstrich nötig wird.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 13:18 #
> Damit wird auch die Netzwerktranzparenz irgendwo obsolet. Zwar erzählen hier immer wieder irgendwelche, dass die ja ach so sehr gebraucht wird, aber wenn ich erlich bin, wüsste ich nicht wo die Netzwerktranzparenz noch *effektiv* zum Einsatz kommt. Und wenn ich von Linux irgendwo remote zugreifen muss, dann über ssh, nfs, über die verschiedenen eigenen Server Funktionen einzelner Anwendungen (emacs, rxvt-unicode, tmux ...), oder wenn es sein muss über FUSE. Ich wüsste nicht aus welchem Grund ich *heute* eine grafische Anwendung von einem entfernten Rechner mir über X hier herholen müsste. Ich kenne diverse Leute die da sogar lieber VNC nehmen würden.
In jeder größeren Unixumgebung kommt X11-Weiterleitung noch zum Einsatz. Und was haben nfs und FUSE bitteschön damit zu tun?
> In *jeder* größeren Unixumgebung Eben nicht! Höchstens in welchen, die seit Jahren nicht mehr angetastet wurden, da man es sich nicht leisten kann, das laufende System umzustellen. Ansonsten sind mir genug Linux Umgebungen bekannt, bei denen auf den Clients der Workgroup X lokal läuft. Würden die X Forward verwenden würde wegen den ganzen Qt und GTK Fenstern das Netzwerk bis zum erbrechen ausgelastet sein. Da laufen dann mal zig Millionen Syncs drüber. Da hilft auch Pufferung kaum noch.
> Und was haben nfs und FUSE bitteschön damit zu tun? Wenn wir von Konzepten bei Client/Server Architekturen reden, sehr viel. Was ist denn das X Forwarding in der Praxis? Nichts weiter als Informationen von einem Rechner zum anderen zu bringen. Im Falle des X Servers wird die Information am Server (grafisch) aufbereitet, so dass sich der Client nicht mehr darum kümmern muss. Letzten Endes ist das aber nichts weiter als Daten von Maschine A zu Maschine B zu bringen. Nehmen wir mal Gnuplot als Beispiel. Ich würde heute nie im Leben auf die Idee kommen, mir vom Hauptrechner die Plotergebnisse per X Forwarding rübergeben zu lassen. Ich mounte das Laufwerk auf dem die Datensätze liegen per NFS oder sonstwas und lasse mir das Ergebniss lokal von gnuplot darstellen. Das hat den Vorteil, dass ich die grafische Ausgabe auch komplett selbst einstellen kann, ohne ggf. durch Restriktionen am Server eingegrenzt zu sein. Wenn ich heute Informationen von einer remote Maschine haben will, dann interessieren mich nur die reinen Daten, die ich vom Server mit der speziell dafür vorhandenen Serversoftware erhalte. Für die Darstellung kümmert sich die lokale Maschine.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 15:09 #
Willst du mir jetzt erzählen, dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps (die sich dank allgegenwärtiger Farbverläufe und unscharf gemachter Schriften auch noch schlecht komprimieren lassen)?
Zu deinem 2. Absatz: Es geht bei Remote-Anwendungen ja vor allem darum, die Resourcen entfernter Rechner zu nutzen (sei es nun per X, VNC, Webanwendung oder ...), und nicht darum, entfernt liegene Daten lokal zu verarbeiten. Das sind zwei Paar Stiefel. Insofern ist dein Verweis auf NFS & co. völlig fehl am Platz.
> dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps Nein! Nochmal der Kontext: > Würden die X Forward verwenden würde wegen den ganzen **Qt und GTK Fenstern** Xlib klassich: Zeichne primitive, Zeichne primitive, ..., Synce (geht, da die Queue die primitives kennt) Toolkits die über xlib Bitmaps senden: Zeichne bitmap, synce, zeichne bitmap, synce ... (muss sein, da die queue die primitve der bitmaps nicht kennt)
Die Beispiele sind grob, aber sie sollen nur konzeptionell Zeigen, welche Schwierigkeiten dahinter stecken. Das mag zwar lokal noch einigermaßen gut gehen und lässt sich zu einem gewissen Grad optimieren, jedoch führt das bekanntermaßen in Netzwerken zu enormen Latenzen.
> die Resourcen entfernter Rechner zu nutzen Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Man könnte vielleicht noch argumentieren, dass sämtliche Software an einem Platz ist und man sich bei den Clients nicht darum zu kümmern braucht, aber auch das hat heute nicht wirklich mehr Gewicht.
Das Ganze würde ja komplett anders aussehen, wenn das X Protokoll weiter entwickelt worden wäre, sodass die heutigen Toolkits die lokalen Zeichnungen auf ein Minimum reduzieren könnten. Ist aber nicht der Fall. Auch aus oben genannten technischen Gründen. Das heißt wir haben heute eine Form der Resourcennutzung auf die X eigentlich gar nicht ausgelegt ist.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 17:00.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 17:48 #
> Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Du übersiehst, dass zwischen Bereitsstellung und Darstellung noch ein Schitt fehlt...
Da fehlen viele Schritte. Nicht nur einer. Aber was tut das zur Sache bei einer reinen Konzeptdebatte zwischen der damaligen Terminal/Mainframe und der heutigen Client/Server Welt? Aufbereitung, Verarbeitung, Darstellung ... das wird heute nicht mehr alles an einer zentralen Maschine gemacht wie es damals in Rechenzentren Gang und Gebe war und vor allem nicht für eine komplette grafische Shell. Es macht aus technischer Sicht einfach kaum noch Sinn. Man siehe zum Beispiel mal nur RDP besonders ab Version 7. Mich schmerzt es zwar das sagen zu müssen, aber was AFAIK die Leistungsfähigkeit angeht sieht es für vergleichbares unter Linux ziemlich Mau aus. Die Diskussion gab es hier schonmal. Und dort kommuniziert die lokal ausgeführte Software auch nicht über ein Protokoll mit einem Server der Zugriff auf die Grafiksubsysteme hat. Da wird die Ausgabe einfach umgeleitet sobald RDP angefordert wird. Sprich, das gesamte Display Management bietet Netzwerktranzparenz (was es bei RDP im gewissen Umfang ist), jedoch nur optional und baut nicht von Grund auf darauf für seine Darstellungen auf.
>Daher ärgern mich auch diese EXTREM KURZ gedachten Ausrufe a la "Die schmeißen gut bewährtes einfach weg!".
Da ist aber eine Menge dran. Wayland wirft viel zu viel von dem weg, was an X durchaus ganz gut ist, und macht sich in in der aktuellen Protokollfassung in vielerlei Hinsicht die Sache zu einfach bzw. verschiebt die Verantwortung für viele Aufgaben in andere Teile des Stacks. Löst das die mit diesen Verantwortungen verbundenen Probleme? Natürlich nicht!
Kurz gedacht finde ich da eher einige Designentscheidungen seitens der Wayland-Entwickler.
Wenn's so weitergeht, wird der erste Kontakt mit Wayland für viele Nutzer mit massiven funktionalen Regressionen und schlechter Performance begleitet werden. So wie mit PulseAudio vor einigen Jahren, nur zehnfach schlimmer.
Wayland lässt nix weg. Wayland stellt ein eigenes Protokoll zur Verfügung. Wenn dir das nicht reicht, dann beteilige dich an der Entwicklung oder benutze halt Xorg.
Es existieren jede Menge Thin-Clients da draußen, die genau diese Netzwerkstransparenz von X nutzen.
Diese Art der Client-Verwaltung ist günstig, zuverlässig und stabil. Updates werden nur am Server eingespielt, User pfuschen nicht auf vollwertigen PCs herum.
Das ist nicht alt, das ist die modernste Art ein grafisches System mit vielen Teilnehmern zu verwalten.
Die Fähigkeiten des X-Servers werden in produktiven Umgebungen sehr intensiv genutzt. Die schwächen, die diese Architektur bzgl. 3D mit sich bringt, werden eh schon speziell gelöst - siehe zB. Android/MeeGo/etc. Alles fbdev o.ä.
Momentan arbeite ich auf einem Windows-Client. Ohne die Netzwerkstransparenz von X11 würde ich einen enormen Aufwand treiben müssen. So aber: XMing runterladen, Linux-Server connecten, loslegen.
Wie wichtig ein Ersatz für diese Architektur ist, sieht man an der Manpower, die hinter Wayland steckt....
> Konzept verfolgt wurde, dass möglichst alle Arbeiten vom Hauptrechner > erledigt wurden und die Clients und deren Arbeit minimal gehalten wurden. > Da bot es sich natürlich an auch die komplette grafische Darstellung einer > Arbeitsumgenug auf dem Großrechner machen zu lassen. Der hatte ja > genügend Arbeitsspeicher und ausreichende Grafikhardware um das > umzusetzen. Beides war damals nämlich teuer.
Dumm nur dass du keine Ahnung von X11 hast Der X-SERVER läuft nämlich auf dem CLIENT und nicht am Grossrechner
> Damit wird auch die Netzwerktranzparenz irgendwo obsolet. > Zwar erzählen hier immer wieder irgendwelche, dass die ja > ach so sehr gebraucht wird, aber wenn ich erlich bin, wüsste > ich nicht wo die Netzwerktranzparenz noch *effektiv* zum > Einsatz kommt. Und wenn ich von Linux irgendwo remote > zugreifen muss, dann über ssh
Ja genau Und deswegen verflucht nochmal ist X-Forwarding nützlich
ssh -C -X root@meinekiste kate /etc/grosses-config-file STRG+Z bg
* Config in einem brauchbaren Editor bearbeiten * Im Terminal dahinter Kommandos absetzen
Abgesehen davon laufen auch Dinge wie NX letztlich über X-Forwarding und sind um Welten effektiver als dein dämliches VNC, das aber nur am rande weil mein beispiel oben zeigt wie man sich EINE ANWENDUNG des Rmeote-Rechners auf den Schirm holt ohne sich den Klotz eines kompletten Desktops ans Bein zu binden
Deine restlichen Ausführungen bezüglich X11 darfst du dir auch sonst wo hin stecken wenn du wie schon gesagt nichtmal verstanden hast was im Konzept von X11 Client und Server sind
Von Sie haben vergessen, Ihren Nam am Sa, 28. Juli 2012 um 13:22 #
Genau, und nun machen wir das gleiche nicht mit einem popeligen Texteditor, sondern mit Anwendungen, die richtig Speicher und Rechenleistung brauchen. Du kannst natürlich an jedem Arbeitsplatz einen entsprechend fetten Rechner hinstellen, oder das ganze zentralisieren. Und komm mir jetzt nicht mit "solche Umgebungen gibt es doch heutzutage nicht mehr".
> Das ist nun das letzte, wofür man X-Forwarding bräuchte. > kate fish://root@meinekiste:/etc/grosses-config-file > und fertig ist der Lack...
Bruhaha ja klar dann spielen wir das Ganze halt mit einem 2 GB grossen Logfile Wenn ich das direkt auf der Remote-Msschine öffne und mir im Editor nur den Ausschnitt zu dem ich scrolle per Netzwerk schicken lasse hat das eine ganz andere Klasse als ich zieh mir das Teil erstmal komplett übers Netz, vor allem wenn ich an einem Notebook sitze wo kate verreckt wenn es das File sieht während es die Remote-Kiste nichtmal kratzt
Der Textedtor war EIN Beispiel Kind
Es gibt dutzende programme die simple Oberflächen haben und mit RIESIGEN Datenmengen arbeiten können, da ist es IMMER effektiver dir nur die Oberfläche per X-Forwarding zu holen als die kompletten Daten zumal du das bei ECHTZEIT-Analysen nicht kannst
Und genau das ist das Problem bei vielen "Drp-In-Replacements": Die Vögel die das zusammencoden haben keine AHnung von dem was sie eigentlich ersetzen und sehen nur die 5% die sie mal benutzt haben, dumm nur wenn sich dann rausstellt dass teile davon dich rein müssen weil die dann dran geflansch werden und schon ist es mit dem sauberen Code der mal Grundgedanke war vorbei und es entwicklelt sih in Richtung "Machden wir doch einen Neustart mit einer sauberen Codebasis"
So wie im Vorjahr das komplett kaputte Replacement des sftp-kio-slave in KDE Null Ahnung die Pfeife die das geschrieben hat, nicht mal ansatzweise einen Überblick welche gängigen Optionen es gibt und geführt hat es dazu dass bei seinem sftp://user@host/ wenn dein Zertifikat auch für root güktig war die verbindung als root gemacht wurde auch wenn tausendmal dein Username angeziegt wurde - In Kombination mit dem nächsten Bug des schönen rewirte wurden beim Speichern Owner/Group/Permissions NICHT beibehalten sondern plötzlich war eine Configdatei am Webserver für selbigen nicht mehr readable
Wenn Du diskutieren willst, solltest Du Deinen Diskussionspartner mit Respekt behandeln. So werde ich meine Zeit ganz gewiss nicht mit Dir verschwenden.
Ich hab nichts davon DIR den Sinn von X-Forwarding zu erklären Ich kenne ihn und nutze es tagtäglich exzessiv über diverse LAN und WAN Strecken Ja bei uns gibts schon 100MBit auch im WAN.....
Es wird immer Menschen geben, die gegen alles Neue wettern.
Aber solange inovative Menschen durch die Kongregation für die Glaubenslehre nicht auf dem Scheiterhaufen landen und der Fortschritt weiter geht, ist alles gut.
Dass ein so von mangelnder Sachkenntnis geprägter Beitrag die Zustimmung des versammelten Pro-Linux-Publikums erhält, sagt einiges über letzteres aus.
Man muss das Ganze etwas historischer betrachten. X entstand zu einer Zeit und in einem Umfeld bei der viele Infrastrukturen zu einem großen Teil aus Rechnern und Großrechnern bestanden und das Konzept verfolgt wurde, dass möglichst alle Arbeiten vom Hauptrechner erledigt wurden und die Clients und deren Arbeit minimal gehalten wurden. Da bot es sich natürlich an auch die komplette grafische Darstellung einer Arbeitsumgenug auf dem Großrechner machen zu lassen. Der hatte ja genügend Arbeitsspeicher und ausreichende Grafikhardware um das umzusetzen. Beides war damals nämlich teuer..
Das ist Unsinn. Die grafische Darstellung läuft in diesem Modell eben nicht auf dem Großrechner, der im Regelfall auch nicht über Grafikhardware verfügte, sondern auf einem X-Terminal. Das Rendering erledigt der X-Server auf genau diesem Terminal.
Über die Zeit verändern sich Dinge nun aber auch. Nicht nur die Hardware an sich, sondern auch die Konzepte. Heute hat jeder Rechner genügend Resourcen um problemlos sich selbst für die grafische Darstellung zu kümmern. Auch die heute gängige Grafikhardware ist für solche eine historische Art der Anwendung gar nicht ausgelegt. Das Konzept der Rechner/Großrechner Infrastruktur wie damals kommt immer weniger, fast gar nicht mehr zum Einsatz. Das sieht man auch daran, dass die heutigen Toolkits alle Zeichenoperationen selbst übernehmen. Das Problem daran ist, dass diese vom X Protokoll nicht gedekt werden.
Du postulierst hier Zusammenhänge, die es nicht gibt. Dass heute clientseitig gerendert wird hat nichts mit aktueller Grafikhardware oder irgendwelchen Client/Server-Konzepten zu tun, sondern ausschließlich damit, dass das X-Protokoll nicht die Rendering-Möglichkeiten bereitstellt, die man für moderne Applikationen benötigt. Das ist kein prinzipielles Problem, im Grunde könnte man das X-Protokoll entsprechend erweitern mit Features wie z. B. Display PDF, wie es von Mac OS X bekannt ist. Allerdings wären umfangreiche Änderungen an den Clients nötig, um von solchen Protokollerweiterungen zu profitieren, daher hat man sich entschieden, voll auf clientseitiges Rendering zu setzen und nur noch das Compositing im Server zu erledigen.
Die neuste Protokollversion ist 11 (20 Jahre alt?) und danach war Schluss.
Formal mag das korrekt sein, dennoch ist diese Aussage äußerst irreführend. Das X11-Protokoll wurde erweiterbar konzipiert und über die Jahre wurden zahlreiche Protokollerweiterungen eingeführt, darunter GLX, Render, Composite, MIT-SHM und viele andere mehr.
Und bevor eine Version 12 kommt, die eh keiner nutzen wird, fallen Ostern und Weihnachten zusammen, da wegen des ganzen xfree86-xorg Hick Hacks da sowiso kaum einer mehr durchblickt.
XFree86 ist tot, und das seit Jahren. Es wird wohl Dein Geheimnis bleiben, wie Du auf die Idee kommst, dass da "keiner mehr durchblickt".
Ehrlich gesagt habe ich gerade weder Zeit noch Lust, mich durch den Rest Deines ziemlich wirren Postings zu kämpfen. Es sei nur gesagt, dass auch in diesem Rest nicht viel mehr sinnvolles zu finden ist als in den Absätzen, die ich hier kommentierte. Ich bin sicher kein X-Fan, aber so ein ahnungsloses Gequatsche konnte ich hier nicht einfach so stehen lassen.
Jupp. Wo was *dargestellt* wird habe ich vertauscht. Ich hätte es eigentlich besser wissen müssen. Immerhin hast du mich darauf aufmerksam gemacht. Wobei das eigentlich immer noch nicht die erwähnten Schwierigkeiten löst und ich zu folgendem nochwas hinzufügen möchte: > X-Protokoll nicht die Rendering-Möglichkeiten bereitstellt, die man für moderne Applikationen benötigt. Genau das ist ein Problem, dass ich ja schon erwähnt habe. Und genau darin liegt die (bzw. und nicht "eine" wie du mich in Sachen GPU korrigiert hast) Konsequenz, dass eben vom (und jetzt müsste es mit den Begriffen passen) X-Client zum einem entfernten X-Server auf dem das X-Terminal läuft, nicht mehr einfache Zeichenoperationen für Primitive gesendet werden sondern ganze Bitmaps. Zumindest mit den aktuellen GUI Toolkits.
> Allerdings wären umfangreiche Änderungen an den Clients nötig [...] daher hat man sich entschieden, voll auf clientseitiges Rendering zu setzen Auch da meine ich, eben das erläutert zu haben.
> Es wird wohl Dein Geheimnis bleiben, wie Du auf die Idee kommst, dass da "keiner mehr durchblickt". Mir wurde mal vor einer ganzen Weile auf einer Anfrage wegen eines bestimmten C Code Teils den ich zu xkb hatte (ja ich weiß, ist nur ein Teil von X) irgendwann von zwei Leuten gesagt, dass da ohnehin keiner der Entwickler durchblickt, mit Erwähnung zu der auch wenn schon Jahre alten xfree86-xorg Geschichte. Wenn du sagst das ist Unsinn, dann glaube ich das mal.
> Ich bin sicher kein X-Fan Als Fan würde ich mich jetzt auch nicht bezeichnen, aber auch nicht in purer Abneigung dazu. Dennoch halte ich Wayland für angebracht.
Ich widerspreche dir keineswegs, aber das ist wie ich schon sagte das Rad immer wieder neuerfinden. Die enormen Herausforderungen die entstehen wenn man das Grafische Subsystem auszutauschen versucht sieht man ja an den vielen Stabilisierungsversionen. Was wird aus den Treibern der Hersteller? Die Funktionieren dann nicht mehr. Und was tut man wenn es für die Grafikkarte keinen freien Treiber gibt? Was wird Compiz? Was wird aus Nouveau? Ja viele wm's und Treiber sind für Weston noch nicht bereit. und so weiter
JA SOFORT UMSTEIGEN, WIEDER MUSS DER EINFACHE USER DIE UPDATE GIER EINIGER AUSBADEN DIE ES NICHT ERWARTEN KÖNNEN, DAS EINE SOFTWARE BEI IHNEN WIE EINE BANANE NACH REIFT.
Das können am ehesten die Entwickler, die täglich mit X in Kontakt kommen beurteilen. Es gibt wohl inzwischen eine Menge Entwickler, die sich täglich über X ärgern und der Meinung sind, das wäre alles nicht mehr zeitgemäß. Ich denke, die können das schon beurteilen. Die Diskussionen hier im Forum bezieht sich oft nur auf die Anwendersicht. Aus Anwendersicht sind jedoch kaum nennenswerten Unterschiede zu erwarten. Daher geht es hier im Forum auch immer hoch her. Wirkliche Experten und Entwickler tummeln sich hier kaum.
Wayland soll den netzwerktransparenten X-Server ersetzten, so dass Frameworks wie GTK+ und QT dann portiert werden müssen. Warum nicht gleich auf den plattformunabhängien Standard HTML5 setzen wie es z.B. Mozillas "Boot to Gecko" macht? HTML5 funktioniert bereits mit GTK+ und QT.
Zitat aus dem Artikel: "Während viele Anwendungen in absehbarer Zeit nativ unter Wayland laufen werden, weil die zugrundeliegenden Toolkits - darunter Qt und GTK+ - auf Wayland portiert werden, wird es weiterhin viele native X-Anwendungen geben."
Kann das bitte mal einer auseinanderklamüsern? Ich krieg da einen Gehirnkrampf.
Ich finde den Satz eigentlich nicht kompliziert. Qt und GTK+ Software läuft nativ auf Wayland. Klassische X Anwendungen wie http://www.boomerangsworld.de/worker laufen in einem lokal gestarteten X-Server, der sein Display in einem Wayland Fenster hat.
Von Sie haben vergessen, Ihren Nam am Do, 26. Juli 2012 um 13:06 #
Übersetzt heißt das: Es wird in Zukunft ein riesen Chaos geben. Distributionen werden ein halbfertiges Wayland vorschnell aufnehmen, ein Teil der Anwendungen wird Wayland, ein Teil X verwenden ("this might cause minor glitches at first"), und Linux auf dem Desktop wird wieder einen Schritt nach hinten machen.
Nein es macht einen Schritt nach vorne! Verwendet doch einfach LTS und enterprise Distributionen und ihr bekommt die "glitches" nicht mit. Wenn man aktuelle Software haben will muss man halt mit ein paar "glitches" oder backports auskommen!
Im Prinzip geht es nur darum, dass vermutlich nicht alle Toolkits und Libraries portiert werden. Einerseits weil das Interesse fehlt oder andererseits, weil diese sehr stark an X11-Support gebunden sind.
Aber um ehrlich zu sein, wer die typischen x* Anwendungen nutzt (xedit, xterm o.ä.), der hat vermutlich auch noch nie eine der Alternativen getestet, die in den meisten Fällen stabiler, schneller und benutzerfreundlicher sind. Mehr als eine Art "Fallback" stellen die eh nicht dar und selbst in der Funktion habe ich die nie genutzt.
Es geht einfach darum: GTK+ uund Qt werden auf Wayland portiert, was folgendes (vereinfacht) heißt: Im Quellcode wird Qt oder GTK+ gesagt es soll ein Fenster zeichnen - im Moment nutzen beide Toolkits eben noch X und sorgen dafür dass das Fenster eben auf dem XServer erscheint. Wenn sie portiert wurden, werden sie bei dem Befehl "Fenster zeichnen" eben nicht mehr den XServer Befehl nutzen, sondern einen der ein Fenster ins Wayland zeichnet - Punkt!
Das ist ja im Endeffekt der große Vorteil von Toolkits - ich brauch mich als Entwickler (kaum) drum scheren wie das Fenster gezeichnet wird, weil ich einfach meinem Toolkit sage, es soll eben diese Aufgabe für mich übernehmen.
Allerdings wird es noch andere Anwendungen geben, die nicht mit diesen Toolkits laufen, sondern mit anderen, oder komplett "selbst" geschrieben sind und nie portiert werden - also weiter XServer brauchen - was mit Wayland aber egal ist, weil der auch Fenster/Anwendungen mit X laufen lassen/anzeigen kann.
Für den normalen Nutzer dürfte es kaum größere Änderungen geben.
Doch, hat er, seine Aussage ist hanebüchener Unfug. Softwareentwicklung besteht immer auch daraus, dass man verschiedene Ziele gegeneinander abwägt. Hier musste man sich zwischen Portabilität und einfacher Implementierung durch Nutzung Linux-spezifischer Features entscheiden. Die Entscheidung wurde zugunsten von letzterem gefällt, und daraus zu schlussfolgern, dass es sich um "blutige Anfänger" handle, ist totaler Bullshit.
Abgesehen davon ist Schily ein jämmerlicher Troll, den man nicht wirklich ernst nehmen sollte. Mag sein, dass seine Software brauchbar ist, aber charakterlich ist er leider trotzdem ein Arschloch.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 22:39.
Volle Zustimmung! Immer diese Portabilitätsleier, ich kanns nicht mehr hören. Wenn man in der Linuxwelt immer auf andere Unices warten würde wäre man wohl heute noch in der Steinzeit. Innovation besteht aus Fortschritt und dem Abschneiden alter Zöpfe, nur so kann man sich konkurrenzfähig auf dem MArkt positionieren.
Was für ein Blödsinn. Wenn Software entwickle mit dem Zusatz UNIX oder portabel etc. kann, ich nicht im Kleingedruckten darauf hinweisen, dass: (*) keine Entwicklung abseits von Linux stattfindet, aber theoretisch wären wir portabel (*) man auf Abstraktionsschichten verzichtet oder darauf setzt irgendwer wird den Linux Kram schon portieren (*) ohnehin keine Ahnung hat, was auch anderen Systemen wichtig ist
Linux Projekte sind im besten Fall portabel zwischen den Distributionen, wenn nicht erzwingt man das durch, Quasistandards wie Systemd bei den bald ohnehin keiner mehr herumkommen wird.
Bin ich froh kein Feigling zu sein und das aussprechen zu können: Einige Linuxuser sind mittlerweile arroganter und ignoranter als MacOS Jünger.
Was für ein Blödsinn. Wenn Software entwickle mit dem Zusatz UNIX oder portabel etc
Das hat niemand getan, es war von Anfang an klar, dass die derzeitige Wayland-Implementierung nicht portabel ist. Das gleiche gilt übrigens für systemd.
Linux Projekte sind im besten Fall portabel zwischen den Distributionen, wenn nicht erzwingt man das durch, Quasistandards wie Systemd bei den bald ohnehin keiner mehr herumkommen wird.
Junge, lern Deutsch.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 27. Jul 2012 um 13:06.
Genau das ist doch der Punkt, Wayland ist nicht portabel weil es ein Designziel war, sondern weil die Programmierer es nicht besser wussten/konnten. Systemd ist ein Monster was alles vereinen will und widerspricht so ziemlich jede UNIX-Philosophie.
Genau das ist doch der Punkt, Wayland ist nicht portabel weil es ein Designziel war, sondern weil die Programmierer es nicht besser wussten/konnten.
Wenn Du ernsthaft diskutieren willst, dann lerne, sinnvolle deutsche Sätze zu bilden. Solange Du Dir nicht die Mühe machst, Deine Gedanken in eine sinnvolle Form zu bringen, werde ich mir nicht die Mühe machen, auf Deine Postings zu antworten.
Systemd ist ein Monster was alles vereinen will und widerspricht so ziemlich jede UNIX-Philosophie.
Abgesehen davon, dass die sogenannte Unix-Philosophie mittlerweile mehrere Jahrzehnte alt ist und gewiss nicht uneingeschränkt als Richtlinie für die Entwicklung moderner Software taugt, fehlt hier jede Begründung für Deine Behauptung. Entsprechend sinnlos wäre es, darauf zu antworten.
Systemd ist ein Monster was alles vereinen will und widerspricht so ziemlich jede UNIX-Philosophie. Nein, es will nicht alles vereinen, sondern nur die Dinge bei denen es Sinn macht, um das bestmögliche Ergebnis zu erhalten.
Dinge nach einer Philosophie zu entwickeln ist schön und gut, aber es muss weder bedeuten, dass dabei etwas brauchbares herauskommt noch, dass es sinnvoll ist, nach diesem Konzept vorzugehen. Mich stört es immer wieder, dass man sich auch im Unix-Bereich so sehr auf "Traditionen" und "Philosophien" setzt.
Auf solche Dinge lege ich nicht speziell Wert. Es ist schön, wenn es so Sinn macht, das daran auszurichten, aber das sollte kein Dogma sein. Wenn also das bisherige Init System das ist was dabei heraus kommt, wenn man strikt nach Unix-Philosophie entwickelt, dann gute Nacht, darauf kann ich wahrlich verzichten.
Damit will ich nicht behaupten, dass systemd extrem toll ist, aber im Vergleich zu den bisherigen Alternativen ist das ein riesiger Schritt nach vorne, in fast allen Bereichen.
Ob das bei Wayland ähnlich sein wird kann ich noch nicht vollständig beurteilen, da ich mir die Architektur noch nicht im Detail angeschaut habe, dass aber X11 so nicht bestehen kann wie das aktuell der Fall ist, ist auch recht klar, denn der wirkt inzwischen immer mehr wie ein riesiger, träger Dampfer dessen Rumpf durchlöchert ist.
Was die Netzwerktransparenz angeht verstehe ich die Aufregung irgendwo nicht. Erstens kann ja jeder, der darauf angewiesen ist, das weiterhin nutzen, denn Wayland kann ja einen normalen X-Server starten und zweitens ist eine entsprechende Erweiterung o.ä. von Wayland ja nicht ausgeschlossen, war nur eben kein Designziel und ist aktuell nicht vorgesehen.
Was die Thin-Clients angeht, die hier angesprochen wurden... Ich weiß, dass noch vor 10-15 Jahren das an vielen Stellen geplant war, solche Dinger einzusetzen, in Realität habe ich die aber nie (richtig: Nie!) mal irgendwo gesehen. Linux, oder Unix-PCs (meistens Solaris) hingegen schon, aber das waren immer "vollwertige" PCs. Ist natürlich nicht ausgeschlossen, dass Thin-Clients wirklich irgendwo eingesetzt werden, dennoch ist das wohl eher die Ausnahme als die Regel.
Wenn dich die Unix-Tradition stört, dann benutz' kein Unix und werbe nicht damit, PUNKT. Und bei Linux ist wohl das kein Dogma, immer alles neu und anders zu machen? Möglichst wenig Zeit in Design und Absprachen stecken?
Für Desktopnutzer mag systemd nützlich sein, mir imponiert kein Feature zumal auf dem Server kontraproduktiv und zumeist irrellevant sind.
Mein Gott, wenn man Dein Geseier hier liest, kommt man ums Fremdschämen ja kaum herum. Was ist so schwer daran, mal ein paar korrekte deutsche Sätze zu bilden? Dann könnte man Dich in einer Diskussion auch ernst nehmen. Korrekte Orthografie und Interpunktion verlange ich ja gar nicht mehr...
Wenn dich die Unix-Tradition stört, dann benutz' kein Unix und werbe nicht damit, PUNKT.
Mich stört nicht die Unix-Tradition, sondern mich stört das beharren auf diesen Traditionen. Es nervt einfach, wenn Menschen (übrigens nicht nur im Unixbereich) sich auf etwas festlegen, nicht, weil es Sinn macht (oft ist genau das Gegenteil der Fall), sondern einfach nur, weil es Tradition ist. Stupider geht es wirklich nicht mehr.
Es kommt darauf an, dass man sich eingehend mit Inhalten, Konzepte und Ideen beschäftigt und diese bestmöglichst umsetzt. Wenn diese mit Traditionen vereinbar sind, ok, falls nicht, dann kann es eben notwendig sein mit diesen Traditionen zu brechen. Wie viele machst du den Fehler Traditionen als Argument zu verwenden, genau das sind sie aber nicht.
Und bei Linux ist wohl das kein Dogma, immer alles neu und anders zu machen?
Nein, ein Dogma ist das nicht, aber es ist sehr beliebt. Ich habe nicht behauptet, dass ich damit grundsätzlich einverstanden bin, denn ich bin absolut kein Fan von Aktionismus. Aber es gibt ja nicht nur die beiden Extrema, man kann auch Zwischenwege gehen und wenn eben etwas erneuert werden sollte, dann sehe ich nicht, wieso man das nicht auch machen soll. Dabei ist es selbstverständlich möglich, dass das "Neue" dann im Vergleich zum "Alten" schlechter abschneidet, aber das kann man nur im Einzelfall bewerten.
Desktopnutzer mag systemd nützlich sein, mir imponiert kein Feature zumal auf dem Server kontraproduktiv und zumeist irrellevant sind.
Dann hast du dir das offensichtlich nicht sonderlich gut angeschaut. Es gibt nämlich durchaus Features, die auf Servern sehr wohl von Vorteil sind. Zum Beispiel die konsequente Nutzung von cgroups. Wenn du nämlich Server administrierst auf denen zum Beispiel ein Apache läuft und dieser irgendwie anfängt zu spinnen, dann kann es notwendig werden diesen abzuschießen. Mit SysVinit hast du da aber das Problem, dass Skripte evtl. weiter laufen können, da diese unter Umständen nicht mehr Apache zugeordnet werden können. Insbesondere kann das vereinzelt auch von Angriffen auf den Server genutzt werden. Mit systemd kannst du alles abschießen was von Apache gestartet wurde, eben über die zugeordnete cgroup. Genauer ist das hier beschrieben: http://0pointer.de/blog/projects/systemd-for-admins-4.html
Aber wie immer gilt eben auch, dass nur verstehen kann wer verstehen will...
> Für Desktopnutzer mag systemd nützlich sein, mir imponiert kein Feature > zumal auf dem Server kontraproduktiv und zumeist irrellevant sind.
Genau genommen braucht auf dem Desktop keine Sau systemd und auf dem Server macht es dann Sinn wenn endlich die systemd-units auch von den Vorteilen gebraucht macehn und alle Dienste umgestellt sind
Nur dass du unter /etc/systemd/system/ beestehende Units erweitern oder ersetzen kannst während dir /etc/init.d/-Files bei jedem Update überschreiben werden
Bau mal das Unit unten mit sysvinit nach, vor allem das "Restart=always" ohne einen massiven Skriot-Zirkus zu veranstalten den du dann bei jedem Dienst neu implementieren darfst und dann kannst du wieder diskutieren kommen
Und ja ich finds fein wenn mein ganzes Netzwerk an einem VPN-Server hängt, sich die Verbidnung verabschiedet, openvpn abfliegt und binnen einer Sekunde AUTOMATISCH neu gestartet wird und ein reporting ist anhand /var/log/messages FÜR ALLE so neu gestarteten Dienste in 10 Minuten sauber implementiert, viel Spass mit sysvinit
Genau genommen braucht auf dem Desktop keine Sau systemd
Naja, das stimmt so auch nicht.
Gerade im Bereich Pluq&Play erlaubt systemd noch viel bessere Möglichkeiten. Mit bisherigen Systemen (Upstart inbegriffen) war das immer ein riesen Krampf...
Ich finde OS X hat den besseren X Nachfolger (auch stolz im Namen). Das funktioniert ähnlich wie Wayland und hat sich bewährt. Wer mal unter OS X das olle X nutzen musste (Gimp, Inkscape…) weiß wovon ich rede. Klar kann man das nun nicht von Apple übernehmen, aber vielleicht sollte man da Anregungen für die API holen. Erprobt und stabil!
Meine Güte, was sind das hier für Kommentare. Wollt ihr in 20 Jahren immer noch X haben?
* Ihr dürft gerne mal eine X-Anwendung warten, dann seht ihr, was das für ein Krampf ist.
* Zu Netzwerktransparenz: Ich wollte Netzwerktransparenz letztens zum Konfigurieren von MythTV verwenden. Das war selbst über eine 100mbit Direktverbindung zu langsam zum Gebrauchen. Warum taugen VNC oder RDP nicht auch? Seit ihr zu faul, das zu konfigurieren? Wir können doch hier nicht User-Meinungen berücksichtigen wie "Ich benutzer x remote und will es auch weiter remote benutzen, weil ich von VNC und RDP nichts verstehe." Es gibt VNC und RDP. Warum soll X diese Funktionalität auch noch bereitstellen?
* Immer die gleichen Kommentare, es würde doch gut funktionieren. Guckt euch doch mal an, wie es funktioniert! Schaltet mal die Desktop-Effekte (z.B. Wabernde Fenster) ein und ändert die Größe von einem Fenster (z.B. Firefox) Es ruckelt, spring, es gibt Grafikfehler. Nicht einmal die Netzwerktransparenz funktioniert noch ordentlich. Es funktioniert eben nicht. Punkt.
Von Sie haben vergessen, Ihren Nam am Mo, 30. Juli 2012 um 19:15 #
> Meine Güte, was sind das hier für Kommentare. Wollt ihr in 20 Jahren immer noch X haben?
Warum nicht?
> [...] weil ich von VNC und RDP nichts verstehe.
könnte genauso heißen, "weil ich von X11 nichts verstehe".
> [...] Es gibt VNC und RDP. Warum soll X diese Funktionalität auch noch bereitstellen? [...]
Weil VNC und RDP einen ganzen Desktop samt Windowmanager zur Verfügung stellen, X11 jedoche einzelne Anwendungen transparent auf den lokalen Desktop bringen. Beide Ansätze haben ihre Berechtigung.
Wer bereit ist, für ein paar Effekte ein komplettes Grafiksystem auszutauschen hat doch einen Schaden. Das ist schließlich ein anderes Kaliber als mal eben den Webbrowser o.ä. zu ersetzen.
Was sind jetzt genau die Probleme von X, die Wayland behebt?
Wayland verschiebt das Rendering von X auf den jeweiligen Window Manager (kwin, mutter, ...). Somit ist dieser dann unabhängig von X und zeichnet die Fenster selbst. Dieser Ansatz ist vom Prinzip her einfacher (da direkter) als zunächst Kommunikation mit X aufzubauen, welches dann die Fenster zeichnet.
Ja, aber rechtfertigt das, ein so bewährtes und stabiles System wie X komplett zu ersetzen? Mit dem Argument "es geht auch einfacher" könnte man z.B. auch den kompletten Linuxkern u.v.m. neu schreiben. Wo sind die komkreten Vorteile von Wayland? Linux auf dem Desktop hat ja schließlich weiß Gott andere Probleme als ein angeblich veraltetes Grafiksystem.
Das Grafiksystem ist veraltet.
Die Argumentation, alles alte muss ersetzt werden, ist veraltet.
Die Grafik ist eine der größten Baustellen unter Linux, wo sich seit gefühlter Ewigkeit nichts getan hat. X11 ist im Wachkoma und Xorg hängt auch in alten festgefahrenen Schienen fest. Wenn durch Wayland etwas Innovation und neuer Schwung kommt ist es nur gut. Wer spezielles von X noch benötigt, für den bleibt es doch noch bestehen.
Ich will nichts neues, Xorg ist ausgereift. Mit Verlaub aber das Rad immer und immer wieder neuerfinden zu wollen ist das größte Problem.
Man muss das Ganze etwas historischer betrachten. X entstand zu einer Zeit und in einem Umfeld bei der viele Infrastrukturen zu einem großen Teil aus Rechnern und Großrechnern bestanden und das Konzept verfolgt wurde, dass möglichst alle Arbeiten vom Hauptrechner erledigt wurden und die Clients und deren Arbeit minimal gehalten wurden. Da bot es sich natürlich an auch die komplette grafische Darstellung einer Arbeitsumgenug auf dem Großrechner machen zu lassen. Der hatte ja genügend Arbeitsspeicher und ausreichende Grafikhardware um das umzusetzen. Beides war damals nämlich teuer.
Über die Zeit verändern sich Dinge nun aber auch. Nicht nur die Hardware an sich, sondern auch die Konzepte. Heute hat jeder Rechner genügend Resourcen um problemlos sich selbst für die grafische Darstellung zu kümmern. Auch die heute gängige Grafikhardware ist für solche eine historische Art der Anwendung gar nicht ausgelegt. Das Konzept der Rechner/Großrechner Infrastruktur wie damals kommt immer weniger, fast gar nicht mehr zum Einsatz. Das sieht man auch daran, dass die heutigen Toolkits alle Zeichenoperationen selbst übernehmen. Das Problem daran ist, dass diese vom X Protokoll nicht gedekt werden. Die neuste Protokollversion ist 11 (20 Jahre alt?) und danach war Schluss. Und bevor eine Version 12 kommt, die eh keiner nutzen wird, fallen Ostern und Weihnachten zusammen, da wegen des ganzen xfree86-xorg Hick Hacks da sowiso kaum einer mehr durchblickt. Zwar haben die X Leute nötige Optimierungen vorgenommen um den Overhead bestmöglich zu vermeiden, aber diese ganzen Syncs zwischen Client und Server lassen sich dennoch kaum vermeiden. Heißt also, es gibt immer weniger reine X Anwendungen die wirklich nur die Zeichenoperationen aus der xlib verwenden. Damit wird auch die Netzwerktranzparenz irgendwo obsolet. Zwar erzählen hier immer wieder irgendwelche, dass die ja ach so sehr gebraucht wird, aber wenn ich erlich bin, wüsste ich nicht wo die Netzwerktranzparenz noch *effektiv* zum Einsatz kommt. Und wenn ich von Linux irgendwo remote zugreifen muss, dann über ssh, nfs, über die verschiedenen eigenen Server Funktionen einzelner Anwendungen (emacs, rxvt-unicode, tmux ...), oder wenn es sein muss über FUSE. Ich wüsste nicht aus welchem Grund ich *heute* eine grafische Anwendung von einem entfernten Rechner mir über X hier herholen müsste. Ich kenne diverse Leute die da sogar lieber VNC nehmen würden.
Und hier kommt die Crux an der Sache, die jeder schon mal gemerkt hat der mit der xlib gearbeitet hat. Man hat mit einem extrem schwierigen historischen Rattenschwanz zu kämpfen. Ja, das funktioniert alles aber der zeitliche Aufwand, der letzten Endes damit auch ein wirtschaftlicher ist, ist enorm.
Und selbst jetzt und zukünftig wo wieder Client/Mainserver Konzepte am kommen sind (Cloud, Apps usw.) werden die Anforderungen und technischen Gegenheiten sich so dermaßen von der damaligen unterscheiden, dass der Glaube eines 'Wiederauflebens' des klassischen X Server pure Blasphemie ist.
Daher ärgern mich auch diese EXTREM KURZ gedachten Ausrufe a la "Die schmeißen gut bewährtes einfach weg!". Solch Leute sollten sich klar machen, dass nur weil etwas aktuell funktioniert nicht in irgendeiner Weise optimal sein muss. Man sollte über den eigenen Schatten springen und einfach akzeptieren, dass nicht aus Hype sondern wirklich technischen wie konzeptionellen Gründen ein Neuanstrich nötig wird.
+1
Sehr guter informativer Beitrag.
Bravo (und danke)!
> Damit wird auch die Netzwerktranzparenz irgendwo obsolet. Zwar erzählen hier immer wieder irgendwelche, dass die ja ach so sehr gebraucht wird, aber wenn ich erlich bin, wüsste ich nicht wo die Netzwerktranzparenz noch *effektiv* zum Einsatz kommt. Und wenn ich von Linux irgendwo remote zugreifen muss, dann über ssh, nfs, über die verschiedenen eigenen Server Funktionen einzelner Anwendungen (emacs, rxvt-unicode, tmux ...), oder wenn es sein muss über FUSE. Ich wüsste nicht aus welchem Grund ich *heute* eine grafische Anwendung von einem entfernten Rechner mir über X hier herholen müsste. Ich kenne diverse Leute die da sogar lieber VNC nehmen würden.
In jeder größeren Unixumgebung kommt X11-Weiterleitung noch zum Einsatz. Und was haben nfs und FUSE bitteschön damit zu tun?
> In *jeder* größeren Unixumgebung
Eben nicht! Höchstens in welchen, die seit Jahren nicht mehr angetastet wurden, da man es sich nicht leisten kann, das laufende System umzustellen. Ansonsten sind mir genug Linux Umgebungen bekannt, bei denen auf den Clients der Workgroup X lokal läuft. Würden die X Forward verwenden würde wegen den ganzen Qt und GTK Fenstern das Netzwerk bis zum erbrechen ausgelastet sein. Da laufen dann mal zig Millionen Syncs drüber. Da hilft auch Pufferung kaum noch.
> Und was haben nfs und FUSE bitteschön damit zu tun?
Wenn wir von Konzepten bei Client/Server Architekturen reden, sehr viel. Was ist denn das X Forwarding in der Praxis? Nichts weiter als Informationen von einem Rechner zum anderen zu bringen. Im Falle des X Servers wird die Information am Server (grafisch) aufbereitet, so dass sich der Client nicht mehr darum kümmern muss. Letzten Endes ist das aber nichts weiter als Daten von Maschine A zu Maschine B zu bringen. Nehmen wir mal Gnuplot als Beispiel. Ich würde heute nie im Leben auf die Idee kommen, mir vom Hauptrechner die Plotergebnisse per X Forwarding rübergeben zu lassen. Ich mounte das Laufwerk auf dem die Datensätze liegen per NFS oder sonstwas und lasse mir das Ergebniss lokal von gnuplot darstellen. Das hat den Vorteil, dass ich die grafische Ausgabe auch komplett selbst einstellen kann, ohne ggf. durch Restriktionen am Server eingegrenzt zu sein. Wenn ich heute Informationen von einer remote Maschine haben will, dann interessieren mich nur die reinen Daten, die ich vom Server mit der speziell dafür vorhandenen Serversoftware erhalte. Für die Darstellung kümmert sich die lokale Maschine.
Willst du mir jetzt erzählen, dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps (die sich dank allgegenwärtiger Farbverläufe und unscharf gemachter Schriften auch noch schlecht komprimieren lassen)?
Zu deinem 2. Absatz: Es geht bei Remote-Anwendungen ja vor allem darum, die Resourcen entfernter Rechner zu nutzen (sei es nun per X, VNC, Webanwendung oder ...), und nicht darum, entfernt liegene Daten lokal zu verarbeiten. Das sind zwei Paar Stiefel. Insofern ist dein Verweis auf NFS & co. völlig fehl am Platz.
> dass ein paar Zeichen- und Sync-Befehle mehr Netzlast verursachen als das Übertragen kompletter Bitmaps
Nein! Nochmal der Kontext:
> Würden die X Forward verwenden würde wegen den ganzen **Qt und GTK Fenstern**
Xlib klassich: Zeichne primitive, Zeichne primitive, ..., Synce (geht, da die Queue die primitives kennt)
Toolkits die über xlib Bitmaps senden: Zeichne bitmap, synce, zeichne bitmap, synce ... (muss sein, da die queue die primitve der bitmaps nicht kennt)
Die Beispiele sind grob, aber sie sollen nur konzeptionell Zeigen, welche Schwierigkeiten dahinter stecken.
Das mag zwar lokal noch einigermaßen gut gehen und lässt sich zu einem gewissen Grad optimieren, jedoch führt das bekanntermaßen in Netzwerken zu enormen Latenzen.
> die Resourcen entfernter Rechner zu nutzen
Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Man könnte vielleicht noch argumentieren, dass sämtliche Software an einem Platz ist und man sich bei den Clients nicht darum zu kümmern braucht, aber auch das hat heute nicht wirklich mehr Gewicht.
Das Ganze würde ja komplett anders aussehen, wenn das X Protokoll weiter entwickelt worden wäre, sodass die heutigen Toolkits die lokalen Zeichnungen auf ein Minimum reduzieren könnten. Ist aber nicht der Fall. Auch aus oben genannten technischen Gründen. Das heißt wir haben heute eine Form der Resourcennutzung auf die X eigentlich gar nicht ausgelegt ist.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 17:00.> Die Bereitstellung der Daten ist *auch* eine Resource. Und wie ich bereits beschrieben hab, ist die momentane Situation die, dass im Gegensatz zu früheren Terminal/Mainframe Zeiten, die *Bereitstellung* und *Dartstellung* auf Client und Server aufgeteilt werden. Und das wird sich auch so schnell nicht ändern. Selbst rasberry pi besitzt genug Speicher und eine GPU um nicht auf eine remote Grafikresource (Sprich Server der eine GPU zur Darstellung nutzt) angewiesen zu sein.
Du übersiehst, dass zwischen Bereitsstellung und Darstellung noch ein Schitt fehlt...
> Schitt
Ich hoffe das war ein Tippfehler :).
Da fehlen viele Schritte. Nicht nur einer. Aber was tut das zur Sache bei einer reinen Konzeptdebatte zwischen der damaligen Terminal/Mainframe und der heutigen Client/Server Welt? Aufbereitung, Verarbeitung, Darstellung ... das wird heute nicht mehr alles an einer zentralen Maschine gemacht wie es damals in Rechenzentren Gang und Gebe war und vor allem nicht für eine komplette grafische Shell. Es macht aus technischer Sicht einfach kaum noch Sinn. Man siehe zum Beispiel mal nur RDP besonders ab Version 7. Mich schmerzt es zwar das sagen zu müssen, aber was AFAIK die Leistungsfähigkeit angeht sieht es für vergleichbares unter Linux ziemlich Mau aus. Die Diskussion gab es hier schonmal. Und dort kommuniziert die lokal ausgeführte Software auch nicht über ein Protokoll mit einem Server der Zugriff auf die Grafiksubsysteme hat. Da wird die Ausgabe einfach umgeleitet sobald RDP angefordert wird. Sprich, das gesamte Display Management bietet Netzwerktranzparenz (was es bei RDP im gewissen Umfang ist), jedoch nur optional und baut nicht von Grund auf darauf für seine Darstellungen auf.
>Daher ärgern mich auch diese EXTREM KURZ gedachten Ausrufe a la "Die schmeißen gut bewährtes einfach weg!".
Da ist aber eine Menge dran. Wayland wirft viel zu viel von dem weg, was an X durchaus ganz gut ist, und macht sich in in der aktuellen Protokollfassung in vielerlei Hinsicht die Sache zu einfach bzw. verschiebt die Verantwortung für viele Aufgaben in andere Teile des Stacks. Löst das die mit diesen Verantwortungen verbundenen Probleme? Natürlich nicht!
Kurz gedacht finde ich da eher einige Designentscheidungen seitens der Wayland-Entwickler.
Wenn's so weitergeht, wird der erste Kontakt mit Wayland für viele Nutzer mit massiven funktionalen Regressionen und schlechter Performance begleitet werden. So wie mit PulseAudio vor einigen Jahren, nur zehnfach schlimmer.
Wayland lässt nix weg. Wayland stellt ein eigenes Protokoll zur Verfügung.
Wenn dir das nicht reicht, dann beteilige dich an der Entwicklung oder benutze halt Xorg.
Da muss ich Dir wohl den Horizont erweitern.
Es existieren jede Menge Thin-Clients da draußen, die genau diese Netzwerkstransparenz von X nutzen.
Diese Art der Client-Verwaltung ist günstig, zuverlässig und stabil. Updates werden nur am Server eingespielt, User pfuschen nicht auf vollwertigen PCs herum.
Das ist nicht alt, das ist die modernste Art ein grafisches System mit vielen Teilnehmern zu verwalten.
Die Fähigkeiten des X-Servers werden in produktiven Umgebungen sehr intensiv genutzt. Die schwächen, die diese Architektur bzgl. 3D mit sich bringt, werden eh schon speziell gelöst - siehe zB. Android/MeeGo/etc.
Alles fbdev o.ä.
Momentan arbeite ich auf einem Windows-Client. Ohne die Netzwerkstransparenz von X11 würde ich einen enormen Aufwand treiben müssen. So aber: XMing runterladen, Linux-Server connecten, loslegen.
Wie wichtig ein Ersatz für diese Architektur ist, sieht man an der Manpower, die hinter Wayland steckt....
Grundsätzlich guter Beitrag
> Konzept verfolgt wurde, dass möglichst alle Arbeiten vom Hauptrechner
> erledigt wurden und die Clients und deren Arbeit minimal gehalten wurden.
> Da bot es sich natürlich an auch die komplette grafische Darstellung einer
> Arbeitsumgenug auf dem Großrechner machen zu lassen. Der hatte ja
> genügend Arbeitsspeicher und ausreichende Grafikhardware um das
> umzusetzen. Beides war damals nämlich teuer.
Dumm nur dass du keine Ahnung von X11 hast
Der X-SERVER läuft nämlich auf dem CLIENT und nicht am Grossrechner
> Damit wird auch die Netzwerktranzparenz irgendwo obsolet.
> Zwar erzählen hier immer wieder irgendwelche, dass die ja
> ach so sehr gebraucht wird, aber wenn ich erlich bin, wüsste
> ich nicht wo die Netzwerktranzparenz noch *effektiv* zum
> Einsatz kommt. Und wenn ich von Linux irgendwo remote
> zugreifen muss, dann über ssh
Ja genau
Und deswegen verflucht nochmal ist X-Forwarding nützlich
ssh -C -X root@meinekiste
kate /etc/grosses-config-file
STRG+Z
bg
* Config in einem brauchbaren Editor bearbeiten
* Im Terminal dahinter Kommandos absetzen
Abgesehen davon laufen auch Dinge wie NX letztlich über X-Forwarding und sind um Welten effektiver als dein dämliches VNC, das aber nur am rande weil mein beispiel oben zeigt wie man sich EINE ANWENDUNG des Rmeote-Rechners auf den Schirm holt ohne sich den Klotz eines kompletten Desktops ans Bein zu binden
Deine restlichen Ausführungen bezüglich X11 darfst du dir auch sonst wo hin stecken wenn du wie schon gesagt nichtmal verstanden hast was im Konzept von X11 Client und Server sind
kate fish://root@meinekiste:/etc/grosses-config-file
und fertig ist der Lack...
Genau, und nun machen wir das gleiche nicht mit einem popeligen Texteditor, sondern mit Anwendungen, die richtig Speicher und Rechenleistung brauchen. Du kannst natürlich an jedem Arbeitsplatz einen entsprechend fetten Rechner hinstellen, oder das ganze zentralisieren. Und komm mir jetzt nicht mit "solche Umgebungen gibt es doch heutzutage nicht mehr".
> Das ist nun das letzte, wofür man X-Forwarding bräuchte.
> kate fish://root@meinekiste:/etc/grosses-config-file
> und fertig ist der Lack...
Bruhaha ja klar dann spielen wir das Ganze halt mit einem 2 GB grossen Logfile
Wenn ich das direkt auf der Remote-Msschine öffne und mir im Editor nur den Ausschnitt zu dem ich scrolle per Netzwerk schicken lasse hat das eine ganz andere Klasse als ich zieh mir das Teil erstmal komplett übers Netz, vor allem wenn ich an einem Notebook sitze wo kate verreckt wenn es das File sieht während es die Remote-Kiste nichtmal kratzt
Der Textedtor war EIN Beispiel Kind
Es gibt dutzende programme die simple Oberflächen haben und mit RIESIGEN Datenmengen arbeiten können, da ist es IMMER effektiver dir nur die Oberfläche per X-Forwarding zu holen als die kompletten Daten zumal du das bei ECHTZEIT-Analysen nicht kannst
Und genau das ist das Problem bei vielen "Drp-In-Replacements": Die Vögel die das zusammencoden haben keine AHnung von dem was sie eigentlich ersetzen und sehen nur die 5% die sie mal benutzt haben, dumm nur wenn sich dann rausstellt dass teile davon dich rein müssen weil die dann dran geflansch werden und schon ist es mit dem sauberen Code der mal Grundgedanke war vorbei und es entwicklelt sih in Richtung "Machden wir doch einen Neustart mit einer sauberen Codebasis"
So wie im Vorjahr das komplett kaputte Replacement des sftp-kio-slave in KDE
Null Ahnung die Pfeife die das geschrieben hat, nicht mal ansatzweise einen Überblick welche gängigen Optionen es gibt und geführt hat es dazu dass bei seinem sftp://user@host/ wenn dein Zertifikat auch für root güktig war die verbindung als root gemacht wurde auch wenn tausendmal dein Username angeziegt wurde - In Kombination mit dem nächsten Bug des schönen rewirte wurden beim Speichern Owner/Group/Permissions NICHT beibehalten sondern plötzlich war eine Configdatei am Webserver für selbigen nicht mehr readable
Geh mir weg mit solchem Rotz!
Ja dann lass es doch bleiben
Ich hab nichts davon DIR den Sinn von X-Forwarding zu erklären
Ich kenne ihn und nutze es tagtäglich exzessiv über diverse LAN und WAN Strecken
Ja bei uns gibts schon 100MBit auch im WAN.....
+1 Super Beitrag!
Es wird immer Menschen geben, die gegen alles Neue wettern.
Aber solange inovative Menschen durch die Kongregation für die Glaubenslehre nicht auf dem Scheiterhaufen landen und der Fortschritt weiter geht, ist alles gut.
Dass ein so von mangelnder Sachkenntnis geprägter Beitrag die Zustimmung des versammelten Pro-Linux-Publikums erhält, sagt einiges über letzteres aus.
Das ist Unsinn. Die grafische Darstellung läuft in diesem Modell eben nicht auf dem Großrechner, der im Regelfall auch nicht über Grafikhardware verfügte, sondern auf einem X-Terminal. Das Rendering erledigt der X-Server auf genau diesem Terminal.Du postulierst hier Zusammenhänge, die es nicht gibt. Dass heute clientseitig gerendert wird hat nichts mit aktueller Grafikhardware oder irgendwelchen Client/Server-Konzepten zu tun, sondern ausschließlich damit, dass das X-Protokoll nicht die Rendering-Möglichkeiten bereitstellt, die man für moderne Applikationen benötigt. Das ist kein prinzipielles Problem, im Grunde könnte man das X-Protokoll entsprechend erweitern mit Features wie z. B. Display PDF, wie es von Mac OS X bekannt ist. Allerdings wären umfangreiche Änderungen an den Clients nötig, um von solchen Protokollerweiterungen zu profitieren, daher hat man sich entschieden, voll auf clientseitiges Rendering zu setzen und nur noch das Compositing im Server zu erledigen.Formal mag das korrekt sein, dennoch ist diese Aussage äußerst irreführend. Das X11-Protokoll wurde erweiterbar konzipiert und über die Jahre wurden zahlreiche Protokollerweiterungen eingeführt, darunter GLX, Render, Composite, MIT-SHM und viele andere mehr.XFree86 ist tot, und das seit Jahren. Es wird wohl Dein Geheimnis bleiben, wie Du auf die Idee kommst, dass da "keiner mehr durchblickt".Ehrlich gesagt habe ich gerade weder Zeit noch Lust, mich durch den Rest Deines ziemlich wirren Postings zu kämpfen. Es sei nur gesagt, dass auch in diesem Rest nicht viel mehr sinnvolles zu finden ist als in den Absätzen, die ich hier kommentierte. Ich bin sicher kein X-Fan, aber so ein ahnungsloses Gequatsche konnte ich hier nicht einfach so stehen lassen.
Jupp. Wo was *dargestellt* wird habe ich vertauscht. Ich hätte es eigentlich besser wissen müssen. Immerhin hast du mich darauf aufmerksam gemacht. Wobei das eigentlich immer noch nicht die erwähnten Schwierigkeiten löst und ich zu folgendem nochwas hinzufügen möchte:
> X-Protokoll nicht die Rendering-Möglichkeiten bereitstellt, die man für moderne Applikationen benötigt.
Genau das ist ein Problem, dass ich ja schon erwähnt habe. Und genau darin liegt die (bzw. und nicht "eine" wie du mich in Sachen GPU korrigiert hast) Konsequenz, dass eben vom (und jetzt müsste es mit den Begriffen passen) X-Client zum einem entfernten X-Server auf dem das X-Terminal läuft, nicht mehr einfache Zeichenoperationen für Primitive gesendet werden sondern ganze Bitmaps. Zumindest mit den aktuellen GUI Toolkits.
> Allerdings wären umfangreiche Änderungen an den Clients nötig [...] daher hat man sich entschieden, voll auf clientseitiges Rendering zu setzen
Auch da meine ich, eben das erläutert zu haben.
> Es wird wohl Dein Geheimnis bleiben, wie Du auf die Idee kommst, dass da "keiner mehr durchblickt".
Mir wurde mal vor einer ganzen Weile auf einer Anfrage wegen eines bestimmten C Code Teils den ich zu xkb hatte (ja ich weiß, ist nur ein Teil von X) irgendwann von zwei Leuten gesagt, dass da ohnehin keiner der Entwickler durchblickt, mit Erwähnung zu der auch wenn schon Jahre alten xfree86-xorg Geschichte. Wenn du sagst das ist Unsinn, dann glaube ich das mal.
> Ich bin sicher kein X-Fan
Als Fan würde ich mich jetzt auch nicht bezeichnen, aber auch nicht in purer Abneigung dazu. Dennoch halte ich Wayland für angebracht.
Ich widerspreche dir keineswegs, aber das ist wie ich schon sagte das Rad immer wieder neuerfinden.
Die enormen Herausforderungen die entstehen wenn man das Grafische Subsystem auszutauschen versucht sieht man ja an den vielen Stabilisierungsversionen.
Was wird aus den Treibern der Hersteller? Die Funktionieren dann nicht mehr.
Und was tut man wenn es für die Grafikkarte keinen freien Treiber gibt?
Was wird Compiz?
Was wird aus Nouveau?
Ja viele wm's und Treiber sind für Weston noch nicht bereit.
und so weiter
JA SOFORT UMSTEIGEN, WIEDER MUSS DER EINFACHE USER DIE UPDATE GIER EINIGER AUSBADEN DIE ES NICHT ERWARTEN KÖNNEN, DAS EINE SOFTWARE BEI IHNEN WIE EINE BANANE NACH REIFT.
Keith Packard steht auch hinter Wayland und der ist ein feste Größe bei X.Org.
Das können am ehesten die Entwickler, die täglich mit X in Kontakt kommen beurteilen. Es gibt wohl inzwischen eine Menge Entwickler, die sich täglich über X ärgern und der Meinung sind, das wäre alles nicht mehr zeitgemäß. Ich denke, die können das schon beurteilen.
Die Diskussionen hier im Forum bezieht sich oft nur auf die Anwendersicht. Aus Anwendersicht sind jedoch kaum nennenswerten Unterschiede zu erwarten. Daher geht es hier im Forum auch immer hoch her. Wirkliche Experten und Entwickler tummeln sich hier kaum.
Wayland soll den netzwerktransparenten X-Server ersetzten, so dass Frameworks wie GTK+ und QT dann portiert werden müssen. Warum nicht gleich auf den plattformunabhängien Standard HTML5 setzen wie es z.B. Mozillas "Boot to Gecko" macht? HTML5 funktioniert bereits mit GTK+ und QT.
hm hat das was mit wayland zu tun? ich kann jetzt auch schon statt gtk und qt programme html5 schreibn.
Weil dass dann noch langsamer als X11 ist und es das Ziel ist es schneller wie X11 zu machen
warum fällt die weg, ich benutze diese recht oft.
es passiert immer wieder, das ich mich per ssh auf einen anderen rechner verbinde und dort grafische programme starte.
- ssh host:22 -l user
- firefox &
dann geht bei mir lokal der firefox auf, welcher auf dem entfernten rechner installiert ist.
und das geht damit nicht?
kann man dann fernwartung nurnoch über vnc oder (ssh)konsole machen?
Bestandsaufnahme:
Dank clientseitigem Rendering wird X11-Weiterleitung immer häufiger unbenutzbar. Schon mal einen aktuellen Acroread mit ssh -X benutzt?
VNC hat viele Nachteile: ein sperriges Fenster, extra Passwort, keine Verschlüsselung. Ok, manches geht mit dem kommerziellen RealVNC.
xpra wäre an sich eine gute Sache, scheint aber kaum weiterentwickelt zu werden.
Acroread ist per se ziemlicher binärer Abfall. Ist hier Blacklisted.
Jojo
Das hier (untere Hälfte) ist zu dieser Thematik interessant: Fedora To Eventually Move to Wayland, Too
Zitat aus dem Artikel: "Während viele Anwendungen in absehbarer Zeit nativ unter Wayland laufen werden, weil die zugrundeliegenden Toolkits - darunter Qt und GTK+ - auf Wayland portiert werden, wird es weiterhin viele native X-Anwendungen geben."
Kann das bitte mal einer auseinanderklamüsern? Ich krieg da einen Gehirnkrampf.
Ich finde den Satz eigentlich nicht kompliziert. Qt und GTK+ Software läuft nativ auf Wayland. Klassische X Anwendungen wie http://www.boomerangsworld.de/worker laufen in einem lokal gestarteten X-Server, der sein Display in einem Wayland Fenster hat.
Übersetzt heißt das: Es wird in Zukunft ein riesen Chaos geben. Distributionen werden ein halbfertiges Wayland vorschnell aufnehmen, ein Teil der Anwendungen wird Wayland, ein Teil X verwenden ("this might cause minor glitches at first"), und Linux auf dem Desktop wird wieder einen Schritt nach hinten machen.
Nein es macht einen Schritt nach vorne! Verwendet doch einfach LTS und enterprise Distributionen und ihr bekommt die "glitches" nicht mit. Wenn man aktuelle Software haben will muss man halt mit ein paar "glitches" oder backports auskommen!
Im Prinzip geht es nur darum, dass vermutlich nicht alle Toolkits und Libraries portiert werden. Einerseits weil das Interesse fehlt oder andererseits, weil diese sehr stark an X11-Support gebunden sind.
Aber um ehrlich zu sein, wer die typischen x* Anwendungen nutzt (xedit, xterm o.ä.), der hat vermutlich auch noch nie eine der Alternativen getestet, die in den meisten Fällen stabiler, schneller und benutzerfreundlicher sind. Mehr als eine Art "Fallback" stellen die eh nicht dar und selbst in der Funktion habe ich die nie genutzt.
Es geht einfach darum: GTK+ uund Qt werden auf Wayland portiert, was folgendes (vereinfacht) heißt: Im Quellcode wird Qt oder GTK+ gesagt es soll ein Fenster zeichnen - im Moment nutzen beide Toolkits eben noch X und sorgen dafür dass das Fenster eben auf dem XServer erscheint. Wenn sie portiert wurden, werden sie bei dem Befehl "Fenster zeichnen" eben nicht mehr den XServer Befehl nutzen, sondern einen der ein Fenster ins Wayland zeichnet - Punkt!
Das ist ja im Endeffekt der große Vorteil von Toolkits - ich brauch mich als Entwickler (kaum) drum scheren wie das Fenster gezeichnet wird, weil ich einfach meinem Toolkit sage, es soll eben diese Aufgabe für mich übernehmen.
Allerdings wird es noch andere Anwendungen geben, die nicht mit diesen Toolkits laufen, sondern mit anderen, oder komplett "selbst" geschrieben sind und nie portiert werden - also weiter XServer brauchen - was mit Wayland aber egal ist, weil der auch Fenster/Anwendungen mit X laufen lassen/anzeigen kann.
Für den normalen Nutzer dürfte es kaum größere Änderungen geben.
GB
Warum meldet sich eigentlich Schily nicht zu diesem Thema? Hier wäre seine Unterstützung wirklich mal wichtig.
Was hat der damit zu tun?
Frag ich mich auch, es geht nicht um Open Solaris, auch nicht um cdrecord, star, smake oder BerliOS...
Na immerhin entfernt sich Linux mit der Aufgabe von X wieder ein Stück weiter von klassischen Unixsystemen. Da könnte er doch was draus machen.
Umso besser! Man kann nicht ewig an verstaubten Sachen festhalten nur weils Tradition ist. Hoffentlich fliegt X bald in die Tonne.
Hat er schon.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 18:44.Damit hat er aber auch nicht unrecht.
Doch, hat er, seine Aussage ist hanebüchener Unfug. Softwareentwicklung besteht immer auch daraus, dass man verschiedene Ziele gegeneinander abwägt. Hier musste man sich zwischen Portabilität und einfacher Implementierung durch Nutzung Linux-spezifischer Features entscheiden. Die Entscheidung wurde zugunsten von letzterem gefällt, und daraus zu schlussfolgern, dass es sich um "blutige Anfänger" handle, ist totaler Bullshit.
Abgesehen davon ist Schily ein jämmerlicher Troll, den man nicht wirklich ernst nehmen sollte. Mag sein, dass seine Software brauchbar ist, aber charakterlich ist er leider trotzdem ein Arschloch.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 26. Jul 2012 um 22:39.Volle Zustimmung! Immer diese Portabilitätsleier, ich kanns nicht mehr hören. Wenn man in der Linuxwelt immer auf andere Unices warten würde wäre man wohl heute noch in der Steinzeit. Innovation besteht aus Fortschritt und dem Abschneiden alter Zöpfe, nur so kann man sich konkurrenzfähig auf dem MArkt positionieren.
Was für ein Blödsinn. Wenn Software entwickle mit dem Zusatz UNIX oder portabel etc. kann, ich nicht im Kleingedruckten darauf hinweisen, dass:
(*) keine Entwicklung abseits von Linux stattfindet, aber theoretisch wären wir portabel
(*) man auf Abstraktionsschichten verzichtet oder darauf setzt irgendwer wird den Linux Kram schon portieren
(*) ohnehin keine Ahnung hat, was auch anderen Systemen wichtig ist
Linux Projekte sind im besten Fall portabel zwischen den Distributionen, wenn nicht erzwingt man das durch, Quasistandards wie Systemd bei den bald ohnehin keiner mehr herumkommen wird.
Bin ich froh kein Feigling zu sein und das aussprechen zu können: Einige Linuxuser sind mittlerweile arroganter und ignoranter als MacOS Jünger.
Junge, lern Deutsch. Dieser Beitrag wurde 1 mal editiert. Zuletzt am 27. Jul 2012 um 13:06.
Genau das ist doch der Punkt, Wayland ist nicht portabel weil es ein Designziel war, sondern weil die Programmierer es nicht besser wussten/konnten. Systemd ist ein Monster was alles vereinen will und widerspricht so ziemlich jede UNIX-Philosophie.
> Systemd ist ein Monster was alles vereinen will und widerspricht so ziemlich jede UNIX-Philosophie.
Da hat es ja etwas mit X11 gemein
Systemd ist ein Monster was alles vereinen will und widerspricht so ziemlich jede UNIX-Philosophie.
Nein, es will nicht alles vereinen, sondern nur die Dinge bei denen es Sinn macht, um das bestmögliche Ergebnis zu erhalten.
Dinge nach einer Philosophie zu entwickeln ist schön und gut, aber es muss weder bedeuten, dass dabei etwas brauchbares herauskommt noch, dass es sinnvoll ist, nach diesem Konzept vorzugehen.
Mich stört es immer wieder, dass man sich auch im Unix-Bereich so sehr auf "Traditionen" und "Philosophien" setzt.
Auf solche Dinge lege ich nicht speziell Wert. Es ist schön, wenn es so Sinn macht, das daran auszurichten, aber das sollte kein Dogma sein.
Wenn also das bisherige Init System das ist was dabei heraus kommt, wenn man strikt nach Unix-Philosophie entwickelt, dann gute Nacht, darauf kann ich wahrlich verzichten.
Damit will ich nicht behaupten, dass systemd extrem toll ist, aber im Vergleich zu den bisherigen Alternativen ist das ein riesiger Schritt nach vorne, in fast allen Bereichen.
Ob das bei Wayland ähnlich sein wird kann ich noch nicht vollständig beurteilen, da ich mir die Architektur noch nicht im Detail angeschaut habe, dass aber X11 so nicht bestehen kann wie das aktuell der Fall ist, ist auch recht klar, denn der wirkt inzwischen immer mehr wie ein riesiger, träger Dampfer dessen Rumpf durchlöchert ist.
Was die Netzwerktransparenz angeht verstehe ich die Aufregung irgendwo nicht.
Erstens kann ja jeder, der darauf angewiesen ist, das weiterhin nutzen, denn Wayland kann ja einen normalen X-Server starten und zweitens ist eine entsprechende Erweiterung o.ä. von Wayland ja nicht ausgeschlossen, war nur eben kein Designziel und ist aktuell nicht vorgesehen.
Was die Thin-Clients angeht, die hier angesprochen wurden... Ich weiß, dass noch vor 10-15 Jahren das an vielen Stellen geplant war, solche Dinger einzusetzen, in Realität habe ich die aber nie (richtig: Nie!) mal irgendwo gesehen. Linux, oder Unix-PCs (meistens Solaris) hingegen schon, aber das waren immer "vollwertige" PCs.
Ist natürlich nicht ausgeschlossen, dass Thin-Clients wirklich irgendwo eingesetzt werden, dennoch ist das wohl eher die Ausnahme als die Regel.
Wenn dich die Unix-Tradition stört, dann benutz' kein Unix und werbe nicht damit, PUNKT. Und bei Linux ist wohl das kein Dogma, immer alles neu und anders zu machen? Möglichst wenig Zeit in Design und Absprachen stecken?
Für Desktopnutzer mag systemd nützlich sein, mir imponiert kein Feature zumal auf dem Server kontraproduktiv und zumeist irrellevant sind.
Mein Gott, wenn man Dein Geseier hier liest, kommt man ums Fremdschämen ja kaum herum. Was ist so schwer daran, mal ein paar korrekte deutsche Sätze zu bilden? Dann könnte man Dich in einer Diskussion auch ernst nehmen. Korrekte Orthografie und Interpunktion verlange ich ja gar nicht mehr...
Es kommt darauf an, dass man sich eingehend mit Inhalten, Konzepte und Ideen beschäftigt und diese bestmöglichst umsetzt. Wenn diese mit Traditionen vereinbar sind, ok, falls nicht, dann kann es eben notwendig sein mit diesen Traditionen zu brechen.
Nein, ein Dogma ist das nicht, aber es ist sehr beliebt. Ich habe nicht behauptet, dass ich damit grundsätzlich einverstanden bin, denn ich bin absolut kein Fan von Aktionismus.Wie viele machst du den Fehler Traditionen als Argument zu verwenden, genau das sind sie aber nicht.
Aber es gibt ja nicht nur die beiden Extrema, man kann auch Zwischenwege gehen und wenn eben etwas erneuert werden sollte, dann sehe ich nicht, wieso man das nicht auch machen soll. Dabei ist es selbstverständlich möglich, dass das "Neue" dann im Vergleich zum "Alten" schlechter abschneidet, aber das kann man nur im Einzelfall bewerten.Dann hast du dir das offensichtlich nicht sonderlich gut angeschaut. Es gibt nämlich durchaus Features, die auf Servern sehr wohl von Vorteil sind.
Zum Beispiel die konsequente Nutzung von cgroups. Wenn du nämlich Server administrierst auf denen zum Beispiel ein Apache läuft und dieser irgendwie anfängt zu spinnen, dann kann es notwendig werden diesen abzuschießen. Mit SysVinit hast du da aber das Problem, dass Skripte evtl. weiter laufen können, da diese unter Umständen nicht mehr Apache zugeordnet werden können. Insbesondere kann das vereinzelt auch von Angriffen auf den Server genutzt werden.
Mit systemd kannst du alles abschießen was von Apache gestartet wurde, eben über die zugeordnete cgroup.
Genauer ist das hier beschrieben:
http://0pointer.de/blog/projects/systemd-for-admins-4.html
Aber wie immer gilt eben auch, dass nur verstehen kann wer verstehen will...
> Für Desktopnutzer mag systemd nützlich sein, mir imponiert kein Feature
> zumal auf dem Server kontraproduktiv und zumeist irrellevant sind.
Genau genommen braucht auf dem Desktop keine Sau systemd und auf dem Server macht es dann Sinn wenn endlich die systemd-units auch von den Vorteilen gebraucht macehn und alle Dienste umgestellt sind
Nur dass du unter /etc/systemd/system/ beestehende Units erweitern oder ersetzen kannst während dir /etc/init.d/-Files bei jedem Update überschreiben werden
Bau mal das Unit unten mit sysvinit nach, vor allem das "Restart=always" ohne einen massiven Skriot-Zirkus zu veranstalten den du dann bei jedem Dienst neu implementieren darfst und dann kannst du wieder diskutieren kommen
Und ja ich finds fein wenn mein ganzes Netzwerk an einem VPN-Server hängt, sich die Verbidnung verabschiedet, openvpn abfliegt und binnen einer Sekunde AUTOMATISCH neu gestartet wird und ein reporting ist anhand /var/log/messages FÜR ALLE so neu gestarteten Dienste in 10 Minuten sauber implementiert, viel Spass mit sysvinit
[Unit]
Description=OpenVPN
After=syslog.target network.target network-wlan-bridge.service
[Service]
Type=forking
ExecStart=/usr/sbin/openvpn --daemon --cd /etc/openvpn/ --config openvpn.conf
Restart=always
RestartSec=1
ExecStartPost=-/sbin/sysctl -e -w net.ipv4.conf.br0.proxy_arp=1
ExecStartPost=-/sbin/sysctl -e -w net.ipv4.conf.eth0.proxy_arp=1
ExecStartPost=-/sbin/sysctl -e -w net.ipv4.conf.wlan0.proxy_arp=1
ExecStartPost=-/bin/sleep 5
ExecStartPost=-/sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.242 dev tap0
ExecStopPost=-/sbin/route del -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.0.242 dev tap0
[Install]
WantedBy=multi-user.target
Gerade im Bereich Pluq&Play erlaubt systemd noch viel bessere Möglichkeiten. Mit bisherigen Systemen (Upstart inbegriffen) war das immer ein riesen Krampf...
Ich finde OS X hat den besseren X Nachfolger (auch stolz im Namen). Das funktioniert ähnlich wie Wayland und hat sich bewährt. Wer mal unter OS X das olle X nutzen musste (Gimp, Inkscape…) weiß wovon ich rede.
Klar kann man das nun nicht von Apple übernehmen, aber vielleicht sollte man da Anregungen für die API holen. Erprobt und stabil!
Meine Güte, was sind das hier für Kommentare. Wollt ihr in 20 Jahren immer noch X haben?
* Ihr dürft gerne mal eine X-Anwendung warten, dann seht ihr, was das für ein Krampf ist.
* Zu Netzwerktransparenz: Ich wollte Netzwerktransparenz letztens zum Konfigurieren von MythTV verwenden. Das war selbst über eine 100mbit Direktverbindung zu langsam zum Gebrauchen. Warum taugen VNC oder RDP nicht auch? Seit ihr zu faul, das zu konfigurieren? Wir können doch hier nicht User-Meinungen berücksichtigen wie "Ich benutzer x remote und will es auch weiter remote benutzen, weil ich von VNC und RDP nichts verstehe." Es gibt VNC und RDP. Warum soll X diese Funktionalität auch noch bereitstellen?
* Immer die gleichen Kommentare, es würde doch gut funktionieren. Guckt euch doch mal an, wie es funktioniert! Schaltet mal die Desktop-Effekte (z.B. Wabernde Fenster) ein und ändert die Größe von einem Fenster (z.B. Firefox) Es ruckelt, spring, es gibt Grafikfehler. Nicht einmal die Netzwerktransparenz funktioniert noch ordentlich. Es funktioniert eben nicht. Punkt.
> Meine Güte, was sind das hier für Kommentare. Wollt ihr in 20 Jahren immer noch X haben?
Warum nicht?
> [...] weil ich von VNC und RDP nichts verstehe.
könnte genauso heißen, "weil ich von X11 nichts verstehe".
> [...] Es gibt VNC und RDP. Warum soll X diese Funktionalität auch noch bereitstellen? [...]
Weil VNC und RDP einen ganzen Desktop samt Windowmanager zur Verfügung stellen, X11 jedoche einzelne Anwendungen transparent auf den lokalen Desktop bringen. Beide Ansätze haben ihre Berechtigung.
> [...] Desktop-Effekte (z.B. Wabernde Fenster) [...]
Wer bereit ist, für ein paar Effekte ein komplettes Grafiksystem auszutauschen hat doch einen Schaden. Das ist schließlich ein anderes Kaliber als mal eben den Webbrowser o.ä. zu ersetzen.