Meiner Meinung nach ist der X-Server das einzige, was Windows den Linuxern voraus hat. Die Geschwindigkeit ist einfach abartig. Ich denke zu mindestens, dass es am X-Server liegt, dass du Oberfläche nicht so schnell ist wie unter Win.
Ich brauche es vielleicht nicht oft, aber wenn, dann bin ich froh, dass es diese Netzwerktransparenz gibt.
Das immer als einzigen Vorteil anzuführen ist natürlich lächerlich, aber es ist ein deutlicher Vorteil gegenüber Windows! Und etwas, das auf keinen Fall geopfert werden sollte, nur weil viele es nicht brauchen. Es gibt sicherlich genug, die es brauchen, und für die eben deswegen keine Alternative zu X existiert. VNC, NX und Konsorten leisten halt nicht das, was mit eben dieser Netzwerktransparenz möglich ist.
Die Performance ist in der Tat grausam. Ich dachte auch, dass es maßgeblich an Xorg/Treibern liegt, aber das ist nur sehr eingeschränkt wahr. Maßgeblich sind die Toolkits; inbesondere GTK ist grauenhaft langsam (ja ich weiss, nicht GTK sondern irgendwelche Engines, aber das ist Haarspalterei und irrelevant) und Qt ist auch nicht viel besser. Wer sich das Fox Toolkit zusammenbaut oder den auf EFL basierenden Enlightment E17 Desktop staunt, dass selbst bei schlechten Treibern die GUI flott ist wie Windows/Beos/Syllable/...
Unter Win gibt es eben einen Standardtoolkit, und das ist das was MS bereits mitliefert. Seit geraumer Zeit nun noch .net, was auch auf die normale API zurück greift.
Bei Linux hat man zig Toolkits, gtk, tk, qt, wx, ... dann kommen noch deren aufgebohrten varianten gnome, kde hinzu. wählt man seine programme nach funktion und nicht nach toolkit aus, hat man einen berg zusätzlichen kram der jeweils nur von einem kleinen tool genutzt wird.
> Bei Linux hat man zig Toolkits, gtk, tk, qt, wx, ...
Die gibt es alle unter Windows auch. Mit Toolkits hat das auch nichts zu tun. Eher damit, dass das Standard-API (Xlib) zu wenig bietet und deshalb fast jedes Toolkit das Rad neu erfindet.
Aber diese Modularität ist doch die ganz ganz grosse tolle Stärke von Windows. Und diese großartige einzigartige .net Framework ist doch Linux weit, ganz weit überlegen. Denk doch mal nach, vor 8 Jahren brauche man für so ein dicke fette CAD-Anwendung ganze 80 MB. Und das Teil war fett schnell. Is doch echt doof. Heute musst du erst .net saugen und kannst dann die CAD installieren. Das saugt dir erst mal 4GB weg und dann ist die Bildschirmanzeige absolut galaktisch (langsam). Dafür ist dein Proz. 10 mal so schnell. Machen das alle so, brauchen wir wieder mindestens 10 Atomkraftwerke mehr oder ???
Ist das nicht saucool?
Oder, vor ein paar Jahren konnte man Programme mal ganz eben schnell installieren. Sogar unter wine. Ausgeweint. .net und statt 10MB gleich mal 500MB installiert. Ist doch alles so schön bunt hier.
Ach da gibt es ein Standardtoolkit, warum sieht unter Windows dann jede Anwendung anders aus, verhält sich anders und lässt sich anders bedienen? MS-Office 2007, MS-Mediaplayer, Eingabeaufforderung, SAP, Lexware Reisekosten etc. etc., alles sieht anders aus, verhält sich anders und wird anders bedient, nicht einmal so simple Dinge wie der Schließen-Knopf ist immer an der selben Stelle.
Da lobe ich mir doch die Situation unter Linux, wo man immerhin die Möglichkeit hat die verschiedenen Toolkits ähnlich einzustellen, so dass das Aussehen, Verhalten und die Bedienung durchgängig sind.
Von Xavier Naidoo am Mo, 27. April 2009 um 11:09 #
Nicht die Toolkits sind das Problem, sondern X mit seiner übertriebenen Modularität und seinem komplexen Aufbau. Mal abgesehen davon, dass ein rohes X nur irgendwelche komischen Drawingbefehle kennt, ist es trotzdem noch komplizierter, als man meinen könnte...
Ja, denn wenn ich icewm-lite mit worker als dateibrowser und dillo2 laufen lasse, dann geht es wie geschmiert (sogar auf einem AMD 850 MHz, 64 MB RAM). Aber leider unterstuetzen diese Tools sehr oft kein UTF-8! Trotzdem koennte X.org ein bisschen Speed vertragen. Ich habe so das Gefuehl, dass sich da wenig tut. Gerade da sollten Canonical, Novel und andere mal Untestuetzung geben. Oder etwa nicht? Dann kauft ja keiner mehr neue Rechner ;).
Ach ja, und als ich von Sarge auf Etch gewechselt habe (demnach also von X11 zu X.org), wurde es um einiges langsamer.
Das stimmt so nicht. GTK1-Woody läuft doch hervorragend und rasend schnell, oder? Und jetzt aktualisiere einmal Woodys XFree86 4.1.0 mit einer aktuellen Version. Dir fällt dann in punkto Performance die Kinnlade herunter. K.O. in der ersten Runde.
Du meinst sicher das Fehlen eines X-Servers zugunsten der GDI-Schnittstelle. Du kannst natürlich ebensogut GGI oder Framebuffer als bevorzugte Grafikschnittstelle verwenden, musst dann aber auf einige Annehmlichkeiten verzichten.
Das halte ich für ein Gerücht. Der X-Server macht den grossen Vorteil aus, weil er eine wesentlich höhere Flexibilität erlaubt und die Geschwindigkeit ist eine Frage des PCs und des Toolkits. Windows kann nur eines gut, nämlich eine Low-Level-Grafik-Schnittstelle anbieten.
Nein, die aktuellen Probleme mit der Geschwindigkeit sind auf den X-Server und dessen Treiber direkt zurückzuführen. Die XOrg-Entwickler machen kein Geheimnis draus, dass der Code an vielen Stellen steinalt ist. Sie machen auch kein Geheimnis draus, dass Leute fehlen, die sich um den Source Code kümmern. Die Toolkits (zumindest Qt) sind den X-Servern konzeptionell in vielen Dingen weit voraus: Schreib' einfach mal ein Programm mit Qt, das (z.B. 2D) Grafik intensiv nutzt (z.B. viele große Pixmaps). Auf Windows oder Mac rennt Dir dann die Applikation davon, während sie unter Linux meist eher schlecht als recht läuft.
Momentan kommen z.B. mit dem aktuellen 1.6er X-Server noch massive Regressionen aufgrund der DRI2-Änderungen zum Tragen (zum Beispiel auf Intel). Letzteres führt dazu, dass ich inzwischen zig Leute kenne, die auf den 1.5-XOrg-Server auf aktuellen Distributionen (openSUSE 11.1, Ubuntu 9.04) downgraden, damit die Geschwindigkeit wieder akzeptabel ist. So kommt man trotz des Wunsches auf XOrg-Seite, mit DRI2 zeitgemäßere Konzepte zu etablieren trotzdem durch daraus resultierende temporäre Workarounds und Regressionen vom Regen in die Traufe.
Die ganze Netzwerktransparenz hat mit dem Thema leider rein gar nix zu tun (und die Benutzung von Remote-X-Servern ist immer noch ein Nischenfall -- wenn auch einer, der im Falle von Thin-Clients sehr wichtig sein kann).
@unten: Nein. Ich bin kein Troll. Ich benutzt privat ausschließlich Linux. Nur wenn ich alle 3 Monate mal mein Windows starte, dann sehe ich einfach den Leistungsunterschied.
Nun ja, die Ansteuerung von X unterscheidet sich signifikant zu der des Grafik Subsystems von Windows. Wo bei Windows die Zeichenroutinen direkt auf, teilweise sehr systemverwurzelte API Funktionen greifen, hast du bei X nunmal noch ein Transportprotokoll, wie zB TCP/IP dazwischen liegen über das erst auf die eigentlichen Zeichenroutinen zugegriffen wird. Aus _grober theorethischer_ Sicht, ist es dann klar, dass sich die Oberfläche unter Windows idR flüssiger anfühlt. Jedoch liegen die Vorteile eines Transportprotokolls zwischen Anwendung/Client und Grafik-Subsystem auf der Hand. Man hat ein Server-Client Modell. Man kann solche Dinge machen, wie die Verbindung zum XServer schließen, jedoch die grafischen Applikationen weiter laufen lassen. Dann kann man sich irgendow anders einloggen und hat wieder das gleiche Bild vor sich. Das ist nur eine von abertausenden Möglichkeiten die so ein Client-Server Modell bietet. Äquivalentes unter Windows zu implementieren ist eine Qual, wenngar unmöglich. Daher würde ich eher sagen, dass X dem Grafik-Subsystem von Windows meilenweit vorraus ist. Geschwindigkeit ist bei weitem nicht alles.
Was mich diesbezueglich interessieren wuerde: Nun gibt es doch inzwischen Loesungen wie FreeNX, welche das Protokoll um das gefuehlte hundertfache beschleunigen. Wieso implementiert man sowas nicht direkt rein? Abwaertskompatibilitaet? Oder noch besser. Wieso deaktiviert man die Netzwerktransparenz nicht einfach und laesst den User selber entscheiden, ob er sowas wie FreeNX nachinstallieren will? X ist nur (und da auch nur sehr beschraenkt) im lokalen Netz brauchbar.
Die Netzwerktransparenz ist in der Standardeinstellung deaktiviert. Bei OpenGL eh (direct rendering). Aber auch eine abgeschaltete Netzwerktransparenz ändert nichts daran, dass die Abstraktionsschicht erhalten bleibt. Jedes X-Programm wird runtergebrochen auf elementare netzwerktaugliche Befehle.
Naja, in der Praxis sehe ich trotzdem eher Nachteile. Unter Windows kann man sich auch Remote einloggen, was m.E. auch deutlich schmerzfreier funktioniert als unter Linux. Theoretisch gesehen ist es natürlich so, dass so ein Schichtenmodell viel sicherer sein soll. In der Praxis ist es aber so, dass X eher unsicher ist. Auf früheren Linuxinstallationen hatte ich darüber hinaus auch häufig mit Instabilitäten zu kämpfen - klar, eher wegen der Treiber, aber wozu dann diese ganze Komplexität, wenn sie sowieso nichts bringt?
Wie es bei solchen Installationen mit sehr vielen Clients ist, kann ich nicht beurteilen. Aber spätestens seit Windows for Workgroups gibt es doch Netzwerksupport. Einen gewissen Reifegrad sollte die Windowswelt in dieser Hinsicht dann doch auch haben, oder?
Ich meine das Teil erstmal einzurichten - und mit XDMCP, unter den Ubuntuversionen der letzten 2-3 Jahre ist übrigens ein Bug dabei, der es verhindert dies auf einfache Art und Weise zu bewerkstelligen.
Wer weiß, welche benutzt der Client unter Linux? Abgesehen davon gibt es ja für höhere Ansprüche VPN, aber über das Internet will man (ich^^) ja normal eh keinen Remoteclient benutzen, weil das viel zu langsam ist...
Dein Name scheint Programm zu sein. Du brauchst dazu überhaupt nichts einrichten, einfach den Befehl des Vorposters nutzen, ggf. noch mit -C für Kompression und schon kannst du jedes beliebige Programm remote über eine per SSH verschlüsselte Verbindung starten und es fügt sich perfekt in deinen lokalen Desktop ein, so als würde es lokal laufen.
Meiner Meinung nach ist die Netzwerktransparenz von X kein wirkliches Totschalgargument mehr, denn es gibt inzwischen genug andere Möglichkeiten einen Remotedesktop zu ermöglichen. Mit der Behauptung, dass X dem Windows-Grafiksystem überlegen ist wäre ich vorsichtig. Du vergisst das X etwas sehr entscheidentes nicht kann und das sind geräteunabhängige Grafikkontexte (IMHO viel wichtiger als Netzwerktransparenz). Windows kann über verschidene Kontexte auf alle möglichen Ausgabegeräte wie Drucker, Bildschirme, Offscreen-Speicherkontexte zeichnen. Für X sind das alles total unterscheidliche Sachen. Btw: Auch Apple hat etwas ähnliches aber noch viel ausgefeilteres. Nennt sich Display Postscript. Sie haben sich damals ganz bewusst gegen einen X-Server entschieden, wegen den oben genannten Nachteilen bei der Geräteabstraktion.
Es gab ja immer wieder Versuche die alte X-Architektur abzulösen. Zum Beispiel Wayland als schneller und schlanker Grafikserver. Leider sieht es so aus als sei das Projekt schon wieder eingeschlafen. Meiner Meinung sollte man bei einer Neuentwicklung auch mal eine einheitliche Widget-Rendering Engine etablieren auf die GTK, Qt usw. zugreifen können. Nie wieder Sprüche wie: "Meine Qt/GTK-Anwendungen sieht aber hässlich/globig/... unter GNOME/KDE aus. Lasst Toolkit XYZ endlich sterben ..."
Mit X werden wir wohl noch lange leben müssen. Der Dinosaurier hält sich wacker ...
> Meiner Meinung nach ist die Netzwerktransparenz von X kein wirkliches Totschalgargument mehr, > denn es gibt inzwischen genug andere Möglichkeiten einen Remotedesktop zu ermöglichen.
Die Netzwerktransparenz von X ist nicht mit einem Remotedesktop gleichzusetzen, dass ist es, was viele nicht verstehen. XDMCP ist nur einer der Vorteile, X ist auch auf Applikationsebene netzwerktransparent. Nenne uns doch eine einfachere und sicherere Alternative, als per ssh -X eine entfernte Applikation lokal darzustellen, welche sich sauber in den lokalen Desktop einfügt und keinen Fremdkörper darstellt.
Jaja, diese tolle Netzwerktransparenz. Es lohnt sich nicht über Features zu reden die üblicherweise eher selten genutzt werden, gegenüber Problemen und Unzulänglichkeiten die ständig bei X auftreten. Und was bringt mir die ach so tolle Applikationsintegration übers Netzwerk, wenn sich die meisten Toolkits, Desktop Environments immer noch kaum untereinander verstehen. Glücklicherweise gibt es ja Bestrebungen die Grafikkartenverwaltung wieder in die Hände des Betriebessystems zu legen - wo sie ja eigentlich auch hingehört. Das könnte alterativen Grafikservern endlich die Möglichkeit geben X zu beerben. Bisher scheiterte das ja vorallem an den Grafiktreibern.
Schließe mal nicht von dir auf andere, ich benötige die Netzwerktransparenz tagtäglich. Und welche Toolkits oder Desktopumgebungen sollen sich bitte nicht miteinander verstehen??
Ich weiß nicht warum du auf deiner Netzwerktransarenz so rumreitest. X hat zur Zeit ganz andere Probleme als das man immer hervorheben muss wie toll doch ssh -X ist. Mit "nicht verstehen" meine ich: Einstellungen zum Look&Feel, Schriftgrößen usw. Ja ich weiß dafür gibt es hacks aber es sind eben nur hacks.
Also ich habe kein Problem mit unterschiedlichen Toolkits, denn man kann sie gut und recht einfach konfigurieren. Ein Linux-Desktop mit verschiedenen Applikationen die mit unterschiedlichen Toolkits realisiert wurden sieht bereits heute um einiges einheitlicher aus, als dass was man unter Windows vorgesetzt bekommt (siehe meinen Kommentar weiter oben).
Zu den Zeiten von dummen Terminals und Mainframes war X die kostengünstigste Lösung. Die Anpassung an den Bedürfnissen von heute, ist aber ein einziges Gefrickel. Ohne Grafikbeschleunigung lässt sich heute (auf modernen DE) nicht mehr arbeiten. Und ich rede nicht vom spielen. Ich glaube auch nicht, dass das Aufschichten irgendwelche Performanzgewinne bringt. btw X war mal eine tolle Sache, bevor die Entwickler angefangen haben, Linux spez. Müll zu integrieren. Nun müssen wir uns alle damit rumschlagen. Mich würde es nicht wundern, wenn wir bald forks sehen werden. Und den X Leuten fehlt langsam die manpower um tiefgreifende Änderungen zu erreichen. Ständig werden Features verschoben. In dem Bereich werden bezahlte Vollzeitkräfte benötigt, die sich mit den Untiefen der Architektur auskennen und keine Gelegenheitsfrickler, die ein paar Hacks einbringen.
So sieht es aus. X ist ein uraltes Protokoll, das seit Jahren den gleichen Ballast mit sich rumschleppt. X wird fetter und fetter. Immer wieder Rumgefrickel an der Architektur und neue Module, die kompliziert in das Konzept vom letzten Jahrtausend eingepasst werden müssen. Zig tausende X-Aufrufe, nur wenn ich ein Fenster verschieben will. Dass wir von X nicht loskommen ist wirklich beschämend. Sobald ich etwas Zeit habe, werde ich ein Projekt ins Leben rufen "KDE ohne X". Wozu ein allgemeines Protokoll, wenn ich eh nur eine Desktop-Umgebung verwende. Wozu diese unsichtbare X-Schicht? Flexibilität in allen Ehren. Aber bitte auch nur dort, wo ich es brauche. Remote-Unterstützung kann High-Level viel performanter realisiert werden als mit solchen Kunstgriffen wie bei NX. Habe Erfahrung mit Grafikkartenprogrammierung und kenne mich im Qt- und X-Sourcecode aus. Ein Hardwaretreiber für ATI-Karten, der nicht X sondern direkt Qt zur Verfügung stellt wäre eine klasse Idee. Es ist ja schon alles da(X,mesa,dri,radeonhd,qt,KDE). Wenn man mal von vorne anfängt, kann man auf vieles schon zurückgreifen.
Danke! Wayland kannte ich nicht. Interessant. Ob man ohne Gtk auskomme, ist letztlich dem Entwickler überlassen. Oft ist es ja deren Privatvergnügen. Außerdem ist nicht Erfolg wichtig sondern Qualität.
Von Bitte nicht gleich schlagen am Mo, 27. April 2009 um 12:11 #
Interessantes Thema, und bitte sschlgt mich nicht, denn ich bin alles nur kein Programmierer, sondern der "ganz normale" Linux-User, der seine Spiele mit WINE ans laufen bekommt, der OpenOffice nutzt, usw.. Also Bürokram, Spielen, TV, im Internet surfen, und bissel Grafikbearbeitung mit GIMP.
Ist es denn nicht Möglich etwas auf dem "Standard" von OpenGL zu Programmieren ? - Ich meine die Grafikkarten an sich unterstützen das doch? (jedenfalls ATI und NVIDIA, soweit ich weis)... ?
Und eine Lösung wo nur ein QT oder GTK drauf läuft wäre mir zu "wenig" ich selbst nutze gerne je nach Tagesform GNOME, KDE, FWM95 oder andere, gerade wegen der vielfalt bin ich gewechselt :)
"würde Ich programmieren können, ich würde Helfen, aber meine Kentnisse beschränken sich allen darauf Leuten zu erklären wie man Linux installiert/einrichtet, WINE ans laufen bekommt, SAMBA und/mit LDAP zum laufen bekommt oder mittels BASH-Scripts abläufe "Automatisiert"..."
"würde Ich programmieren können, ich würde Helfen, aber meine Kentnisse beschränken sich allen darauf Leuten zu erklären wie man Linux installiert/einrichtet, WINE ans laufen bekommt, SAMBA und/mit LDAP zum laufen bekommt oder mittels BASH-Scripts abläufe "Automatisiert"..."
Du mußt halt einfach einmal anfangen, selbst wenn Du vielleicht schon 60 sein solltest. Niemand kam auf die Welt und konnte programmieren. Du bist ja anscheinend schon am Herumskripten, also, fang an.
Niemand kam auf die Welt und konnte programmieren. doch ich^^, Milch bekam ich sicherlich, wenn ich geschrien habe, also habe ich meine Eltern programmiert (nur wann fängt programmieren an ist wieder eine andere Frage, grob genommen war es eine Regelung^^)
Oh ja! Ich würde dem Kind dann auch einen Namen geben - "Framebuffer", ok? Und ich übernehme sogar die Qt-Portierung darauf!!11!!!
Und wenn wir schon dabei sind, sollten wir auch KDE abspecken! Wozu die ganzen Daemons und irgendwelche HW-Abstraction-Layers - braucht doch ein echter Kerl doch gar nicht! Sound gibt man aus, in dem man die Register der Soudkarte beschreibt, und nicht irgendwelche ogg-Files abspielt!!!
Ich kenne mich im Linux-Sourceode aus - das sagt doch schon alles!
Eben. Wozu einen fetten X-Server, wenn es im Framebuffer offensichtlich auch geht? Ich kenne die Embedded-Version von Qt. X wird nur verwendet wegen der vielen Module, die Fonts, OpenGL, Composition, Mauszeiger, Videos etc. darstellen. Aber der pure Kern von X ist kaum von Bedeutung.
Die Daemons sind schon ganz brauchbar. Wir haben sogar zu wenig davon. D-Bus, HAL etc ist alles noch am Anfang. Da sind andere System weiter.
Nein, es geht nicht darum, dass ich auf der Hardware direkt arbeite. Sinnvolle Abstraktionen sind wichtig. Aber bitte nicht X. Gucke dir mal das X-Protokoll an! Du programmierst in X fast genauso low-level wie in Assembler. Also warum sollte ich X verwenden? Wenn ich schon eine Schicht einziehe, dann soll es auch eine sinnvolle Abstraktion sein.
habt ihr eigentlich schonmal einen grafikkarten treiber mit ordentlicher 2d beschleunigung benutzt? zB einen treiber der 180er serie von nvidia?
die gtk performance ist damit sehr beeindruckend. dagegen sieht sogar windows in nahezu jeder aktuellen version alt aus. und nein, ich übetreibe nicht.
Du mußt es so sehen. Hier finden so etwas wie Grabenkämpfe statt. Wir zoffen uns hier aber nicht, weil wir uns zerfetzen wollen, sondern weil wir alle Argumente einmal sehen wollen und wir Meinungen austauschen wollen. Die Diskussionen hier sind nämlich in Wirklichkeit sehr fruchtbar. Warum die Linuxler dazu neigen so energisch zu argumentieren, kann ich dir allerdings auch nicht sagen. Wahrscheinlich, weil immer ein Schuss Philosophie mitschwingt. Wenn jemand aber nichts zu sagen hat und trotzdem seinen Senf dazu gibt, dann ist das überflüssig. Vielleicht magst du uns ja in einigen Punkten unsere Fehler aufzeigen.
> Meiner Meinung nach ist der X-Server das einzige, was Windows den Linuxern voraus hat. Die Geschwindigkeit ist einfach abartig.
Nicht nur Windows, OS X zeigt eindrucksvoll wie schnell ein Unix auf einem Eee PC sein kann. Zudem wird man mit funktionierenden Suspend beglückt und die Akkulaufzeit ist 1/2 -1 Std. länger. Wer natürlich in den Tiefen des Sourcecodes/Kernel wühlen möchte, wird mit OS X nicht glücklich. Aber meist ist das vernachlässigbar, wichtig ist das vorhandensein von Shell, Unixkommandos, usw... Das langsamste am OS X ist der X Server (falls man persönlich wirklich noch ein Programm benötigt, daß den X Server voraussetzt).
Ich habe geteilte Erfahrungen mit verschiedenen (nicht nur Debian-bassierten) Distries gemacht. Meistens war ein Suspend to RAM bei mir Problemlos. Ich sage meistens, und nicht immer, weil eben doch ab und an der Treiber das WLAN nicht mehr initializieren konnte, oder das System nach einigen Sekunden einfrohr (beides passierte aber selten). Suspend to Disk war bei mir interessanterweise meistens problematisch, wobei ich mir bei keiner Distrie die Mühe gemacht habe herauszufinden was die Ursachen sind.
Ich hab einen eeepc 900A, ein ansonsten für mich gutes Gerät. Wobei mich die Probleme mit Suspend to Disk auch nicht stören. Suspend to Ram hält mehr als lange aus, und ich habe nicht vor ihn Wochenlang im Suspend zu lassen, daher ist es für mich gleichgültig.
Von Christian Blaesing am Di, 28. April 2009 um 11:11 #
Ganz interessant ist vielleicht ein Kommentar von Raster, der erklärt, warum GTK und QT im verlgeich zu Eva so langsam unter X sind. GTK und QT sollten keine Pixmaps verwenden, da das ziemlich teuer unter X ist:
Carsten Haitzler (The Rasterman): >The real major problem is qt/qtopia and the x11 output. it is amazingly >inefficient. it does a whole set of no-no's when it comes to performance (like >uploading and downloading pixmaps and converting to/from image formats... >repeatedly). if you want things to work well in x11: > >1. only upload when you need a pixmap or data on screen... dont upload until >you need it. >2. never repeatedly upload if u can do it just once, so defer uploads of pixel >data as late as possible. >3. NEVER download (get images) from x. this will kill performance as it 1, >stalls your app into waiting on x, 2, needs to wait for data to be read from >video ram (slow - even on desktop systems), 3, causes yet more context >switching which is expensive on ARM. > >one reason EFL gets the performance it does is it has an almost 1 way pipeline >with everything deferred as much a possible. be it software rendering or >xrender etc. - everything happens as late as possible. it never downloads data >from x... and man all of this really helps.
Das Gleiche gilt für GTK? Kann X nicht angepasst werden, dass das Laden von Pixmaps besser geht? Dadurch würde man zwei Probleme mit einer Klappe schlagen.(zwei Toolkits)
Oh, warte.
Das immer als einzigen Vorteil anzuführen ist natürlich lächerlich, aber es ist ein deutlicher Vorteil gegenüber Windows! Und etwas, das auf keinen Fall geopfert werden sollte, nur weil viele es nicht brauchen. Es gibt sicherlich genug, die es brauchen, und für die eben deswegen keine Alternative zu X existiert. VNC, NX und Konsorten leisten halt nicht das, was mit eben dieser Netzwerktransparenz möglich ist.
Maßgeblich sind die Toolkits; inbesondere GTK ist grauenhaft langsam (ja ich weiss, nicht GTK sondern irgendwelche Engines, aber das ist Haarspalterei und irrelevant) und Qt ist auch nicht viel besser.
Wer sich das Fox Toolkit zusammenbaut oder den auf EFL basierenden Enlightment E17 Desktop staunt, dass selbst bei schlechten Treibern die GUI flott ist wie Windows/Beos/Syllable/...
Bei Linux hat man zig Toolkits, gtk, tk, qt, wx, ... dann kommen noch deren aufgebohrten varianten gnome, kde hinzu. wählt man seine programme nach funktion und nicht nach toolkit aus, hat man einen berg zusätzlichen kram der jeweils nur von einem kleinen tool genutzt wird.
Welches soll das sein? MFC? ;-)
> Bei Linux hat man zig Toolkits, gtk, tk, qt, wx, ...
Die gibt es alle unter Windows auch. Mit Toolkits hat das auch nichts zu tun. Eher damit, dass das Standard-API (Xlib) zu wenig bietet und deshalb fast jedes Toolkit das Rad neu erfindet.
Na dann ist doch alles klar: benutze Windoof und belästige uns nicht weiter!
- J
Denk doch mal nach, vor 8 Jahren brauche man für so ein dicke fette CAD-Anwendung ganze 80 MB. Und das Teil war fett schnell. Is doch echt doof. Heute musst du erst .net saugen und kannst dann die CAD installieren. Das saugt dir erst mal 4GB weg und dann ist die Bildschirmanzeige absolut galaktisch (langsam). Dafür ist dein Proz. 10 mal so schnell. Machen das alle so, brauchen wir wieder mindestens 10 Atomkraftwerke mehr oder ???
Ist das nicht saucool?
Oder, vor ein paar Jahren konnte man Programme mal ganz eben schnell installieren. Sogar unter wine. Ausgeweint. .net und statt 10MB gleich mal 500MB installiert. Ist doch alles so schön bunt hier.
Da lobe ich mir doch die Situation unter Linux, wo man immerhin die Möglichkeit hat die verschiedenen Toolkits ähnlich einzustellen, so dass das Aussehen, Verhalten und die Bedienung durchgängig sind.
Ach ja, und als ich von Sarge auf Etch gewechselt habe (demnach also von X11 zu X.org), wurde es um einiges langsamer.
GTK1-Woody läuft doch hervorragend und rasend schnell, oder?
Und jetzt aktualisiere einmal Woodys XFree86 4.1.0 mit einer aktuellen Version.
Dir fällt dann in punkto Performance die Kinnlade herunter.
K.O. in der ersten Runde.
Gruß, LX
Nein, die aktuellen Probleme mit der Geschwindigkeit sind auf den X-Server und dessen Treiber direkt zurückzuführen. Die XOrg-Entwickler machen kein Geheimnis draus, dass der Code an vielen Stellen steinalt ist. Sie machen auch kein Geheimnis draus, dass Leute fehlen, die sich um den Source Code kümmern.
Die Toolkits (zumindest Qt) sind den X-Servern konzeptionell in vielen Dingen weit voraus: Schreib' einfach mal ein Programm mit Qt, das (z.B. 2D) Grafik intensiv nutzt (z.B. viele große Pixmaps). Auf Windows oder Mac rennt Dir dann die Applikation davon, während sie unter Linux meist eher schlecht als recht läuft.
Momentan kommen z.B. mit dem aktuellen 1.6er X-Server noch massive Regressionen aufgrund der DRI2-Änderungen zum Tragen (zum Beispiel auf Intel). Letzteres führt dazu, dass ich inzwischen zig Leute kenne, die auf den 1.5-XOrg-Server auf aktuellen Distributionen (openSUSE 11.1, Ubuntu 9.04) downgraden, damit die Geschwindigkeit wieder akzeptabel ist. So kommt man trotz des Wunsches auf XOrg-Seite, mit DRI2 zeitgemäßere Konzepte zu etablieren trotzdem durch daraus resultierende temporäre Workarounds und Regressionen vom Regen in die Traufe.
Die ganze Netzwerktransparenz hat mit dem Thema leider rein gar nix zu tun (und die Benutzung von Remote-X-Servern ist immer noch ein Nischenfall -- wenn auch einer, der im Falle von Thin-Clients sehr wichtig sein kann).
Genau das wollte ich damit sagen.
@unten: Nein. Ich bin kein Troll. Ich benutzt privat ausschließlich Linux. Nur wenn ich alle 3 Monate mal mein Windows starte, dann sehe ich einfach den Leistungsunterschied.
Daher würde ich eher sagen, dass X dem Grafik-Subsystem von Windows meilenweit vorraus ist. Geschwindigkeit ist bei weitem nicht alles.
Nun gibt es doch inzwischen Loesungen wie FreeNX, welche das Protokoll um das gefuehlte hundertfache beschleunigen. Wieso implementiert man sowas nicht direkt rein? Abwaertskompatibilitaet? Oder noch besser. Wieso deaktiviert man die Netzwerktransparenz nicht einfach und laesst den User selber entscheiden, ob er sowas wie FreeNX nachinstallieren will?
X ist nur (und da auch nur sehr beschraenkt) im lokalen Netz brauchbar.
Wie es bei solchen Installationen mit sehr vielen Clients ist, kann ich nicht beurteilen. Aber spätestens seit Windows for Workgroups gibt es doch Netzwerksupport. Einen gewissen Reifegrad sollte die Windowswelt in dieser Hinsicht dann doch auch haben, oder?
Ist ja auch so schwer:
$ ssh -X remote-host
Welche Verschlüsselung verwendet der RDP-Client unter Windows?
Wer weiß, welche benutzt der Client unter Linux?
Abgesehen davon gibt es ja für höhere Ansprüche VPN, aber über das Internet will man (ich^^) ja normal eh keinen Remoteclient benutzen, weil das viel zu langsam ist...
Btw: Auch Apple hat etwas ähnliches aber noch viel ausgefeilteres. Nennt sich Display Postscript. Sie haben sich damals ganz bewusst gegen einen X-Server entschieden, wegen den oben genannten Nachteilen bei der Geräteabstraktion.
Es gab ja immer wieder Versuche die alte X-Architektur abzulösen. Zum Beispiel Wayland als schneller und schlanker Grafikserver. Leider sieht es so aus als sei das Projekt schon wieder eingeschlafen. Meiner Meinung sollte man bei einer Neuentwicklung auch mal eine einheitliche Widget-Rendering Engine etablieren auf die GTK, Qt usw. zugreifen können. Nie wieder Sprüche wie: "Meine Qt/GTK-Anwendungen sieht aber hässlich/globig/... unter GNOME/KDE aus. Lasst Toolkit XYZ endlich sterben ..."
Mit X werden wir wohl noch lange leben müssen. Der Dinosaurier hält sich wacker ...
> denn es gibt inzwischen genug andere Möglichkeiten einen Remotedesktop zu ermöglichen.
Die Netzwerktransparenz von X ist nicht mit einem Remotedesktop gleichzusetzen, dass ist es, was viele nicht verstehen. XDMCP ist nur einer der Vorteile, X ist auch auf Applikationsebene netzwerktransparent. Nenne uns doch eine einfachere und sicherere Alternative, als per ssh -X eine entfernte Applikation lokal darzustellen, welche sich sauber in den lokalen Desktop einfügt und keinen Fremdkörper darstellt.
Glücklicherweise gibt es ja Bestrebungen die Grafikkartenverwaltung wieder in die Hände des Betriebessystems zu legen - wo sie ja eigentlich auch hingehört. Das könnte alterativen Grafikservern endlich die Möglichkeit geben X zu beerben. Bisher scheiterte das ja vorallem an den Grafiktreibern.
Mit "nicht verstehen" meine ich: Einstellungen zum Look&Feel, Schriftgrößen usw. Ja ich weiß dafür gibt es hacks aber es sind eben nur hacks.
Zu den Zeiten von dummen Terminals und Mainframes war X die kostengünstigste Lösung. Die Anpassung an den Bedürfnissen von heute, ist aber ein einziges Gefrickel. Ohne Grafikbeschleunigung lässt sich heute (auf modernen DE) nicht mehr arbeiten. Und ich rede nicht vom spielen.
Ich glaube auch nicht, dass das Aufschichten irgendwelche Performanzgewinne bringt.
btw
X war mal eine tolle Sache, bevor die Entwickler angefangen haben, Linux spez. Müll zu integrieren. Nun müssen wir uns alle damit rumschlagen. Mich würde es nicht wundern, wenn wir bald forks sehen werden.
Und den X Leuten fehlt langsam die manpower um tiefgreifende Änderungen zu erreichen. Ständig werden Features verschoben. In dem Bereich werden bezahlte Vollzeitkräfte benötigt, die sich mit den Untiefen der Architektur auskennen und keine Gelegenheitsfrickler, die ein paar Hacks einbringen.
Was die Forks angeht, Xorg ist bereits ein Fork von XFree.
Und sieh Die einmal Wayland an.
Sobald ich etwas Zeit habe, werde ich ein Projekt ins Leben rufen "KDE ohne X". Wozu ein allgemeines Protokoll, wenn ich eh nur eine Desktop-Umgebung verwende. Wozu diese unsichtbare X-Schicht? Flexibilität in allen Ehren. Aber bitte auch nur dort, wo ich es brauche. Remote-Unterstützung kann High-Level viel performanter realisiert werden als mit solchen Kunstgriffen wie bei NX. Habe Erfahrung mit Grafikkartenprogrammierung und kenne mich im Qt- und X-Sourcecode aus. Ein Hardwaretreiber für ATI-Karten, der nicht X sondern direkt Qt zur Verfügung stellt wäre eine klasse Idee. Es ist ja schon alles da(X,mesa,dri,radeonhd,qt,KDE). Wenn man mal von vorne anfängt, kann man auf vieles schon zurückgreifen.
Ob man ohne Gtk auskomme, ist letztlich dem Entwickler überlassen. Oft ist es ja deren Privatvergnügen. Außerdem ist nicht Erfolg wichtig sondern Qualität.
Also Bürokram, Spielen, TV, im Internet surfen, und bissel Grafikbearbeitung mit GIMP.
Ist es denn nicht Möglich etwas auf dem "Standard" von OpenGL zu Programmieren ? - Ich meine die Grafikkarten an sich unterstützen das doch? (jedenfalls ATI und NVIDIA, soweit ich weis)... ?
Und eine Lösung wo nur ein QT oder GTK drauf läuft wäre mir zu "wenig" ich selbst nutze gerne je nach Tagesform GNOME, KDE, FWM95 oder andere, gerade wegen der vielfalt bin ich gewechselt :)
"würde Ich programmieren können, ich würde Helfen, aber meine Kentnisse beschränken sich allen darauf Leuten zu erklären wie man Linux installiert/einrichtet, WINE ans laufen bekommt, SAMBA und/mit LDAP zum laufen bekommt oder mittels BASH-Scripts abläufe "Automatisiert"..."
Du mußt halt einfach einmal anfangen, selbst wenn Du vielleicht schon 60 sein solltest.
Niemand kam auf die Welt und konnte programmieren.
Du bist ja anscheinend schon am Herumskripten, also, fang an.
doch ich^^, Milch bekam ich sicherlich, wenn ich geschrien habe, also habe ich meine Eltern programmiert (nur wann fängt programmieren an ist wieder eine andere Frage, grob genommen war es eine Regelung^^)
Und wenn wir schon dabei sind, sollten wir auch KDE abspecken! Wozu die ganzen Daemons und irgendwelche HW-Abstraction-Layers - braucht doch ein echter Kerl doch gar nicht! Sound gibt man aus, in dem man die Register der Soudkarte beschreibt, und nicht irgendwelche ogg-Files abspielt!!!
Ich kenne mich im Linux-Sourceode aus - das sagt doch schon alles!
Die Daemons sind schon ganz brauchbar. Wir haben sogar zu wenig davon. D-Bus, HAL etc ist alles noch am Anfang. Da sind andere System weiter.
Nein, es geht nicht darum, dass ich auf der Hardware direkt arbeite. Sinnvolle Abstraktionen sind wichtig. Aber bitte nicht X. Gucke dir mal das X-Protokoll an! Du programmierst in X fast genauso low-level wie in Assembler. Also warum sollte ich X verwenden? Wenn ich schon eine Schicht einziehe, dann soll es auch eine sinnvolle Abstraktion sein.
die gtk performance ist damit sehr beeindruckend. dagegen sieht sogar windows in nahezu jeder aktuellen version alt aus. und nein, ich übetreibe nicht.
Warum die Linuxler dazu neigen so energisch zu argumentieren, kann ich dir allerdings auch nicht sagen. Wahrscheinlich, weil immer ein Schuss Philosophie mitschwingt.
Wenn jemand aber nichts zu sagen hat und trotzdem seinen Senf dazu gibt, dann ist das überflüssig. Vielleicht magst du uns ja in einigen Punkten unsere Fehler aufzeigen.
Nicht nur Windows, OS X zeigt eindrucksvoll wie schnell ein Unix auf einem Eee PC sein kann. Zudem wird man mit funktionierenden Suspend beglückt und die Akkulaufzeit ist 1/2 -1 Std. länger.
(falls man persönlich wirklich noch ein Programm benötigt, daß den X Server voraussetzt).
Wer natürlich in den Tiefen des Sourcecodes/Kernel wühlen möchte, wird mit OS X nicht glücklich. Aber meist ist das vernachlässigbar, wichtig ist das vorhandensein von Shell, Unixkommandos, usw...
Das langsamste am OS X ist der X Server
Suspend to Disk war bei mir interessanterweise meistens problematisch, wobei ich mir bei keiner Distrie die Mühe gemacht habe herauszufinden was die Ursachen sind.
Ich hab einen eeepc 900A, ein ansonsten für mich gutes Gerät. Wobei mich die Probleme mit Suspend to Disk auch nicht stören. Suspend to Ram hält mehr als lange aus, und ich habe nicht vor ihn Wochenlang im Suspend zu lassen, daher ist es für mich gleichgültig.
Carsten Haitzler (The Rasterman):
>The real major problem is qt/qtopia and the x11 output. it is amazingly
>inefficient. it does a whole set of no-no's when it comes to performance (like
>uploading and downloading pixmaps and converting to/from image formats...
>repeatedly). if you want things to work well in x11:
>
>1. only upload when you need a pixmap or data on screen... dont upload until
>you need it.
>2. never repeatedly upload if u can do it just once, so defer uploads of pixel
>data as late as possible.
>3. NEVER download (get images) from x. this will kill performance as it 1,
>stalls your app into waiting on x, 2, needs to wait for data to be read from
>video ram (slow - even on desktop systems), 3, causes yet more context
>switching which is expensive on ARM.
>
>one reason EFL gets the performance it does is it has an almost 1 way pipeline
>with everything deferred as much a possible. be it software rendering or
>xrender etc. - everything happens as late as possible. it never downloads data
>from x... and man all of this really helps.
Kann X nicht angepasst werden, dass das Laden von Pixmaps besser geht? Dadurch würde man zwei Probleme mit einer Klappe schlagen.(zwei Toolkits)