Von Sunny@unix.org am Mo, 1. November 2004 um 23:20 #
Das könnte der erste Schritt in eine _SCHNELLE_ UI-Welt sein, ganz wie MS das handelt. Wenn das Ding ordentlich im Userspace alles handhabt, wirds auch keine Probleme geben. Und bitte, erzähl mir keiner XFree sei schneller das die im Kernel integrierte UI von Windows. Vielleicht sicherer, transparenter, aber nicht schneller.
Du hast im Prinzip schon recht, GUI und OS sollten aber auch weiterhin im Alltagsbetrieb getrennt laufen, schon wegen der Stabilitaet wegen. Fuer Embedded-Systeme und vielleicht noch andere Spezialanwendungen ist ein integriertes Fenstersystem aber schon nicht schlecht.
> ich kappier das einfach nicht,wo das die leute herhaben..
Vielleicht kommt das von den Leuten, die in ihrem X11 die Beschleunigung deaktiviert haben. Oder vielleicht haben die auch nur eine alte oder zu moderne Grafikkarte, für die es noch keinen vernünftigen X-Treiber gibt. Dann ist X11 in der Tat langsam. Aber nur dann.
Oder wenn man zwar eine GeForce 4 Ti 4400 mit nvidia Treibern und 786 MB RAM und nen AMD Athlon XP 2000+ hat, und Mozilla total suckt, wobei er auf'm selben Rehner unter Windows sehr flüssig läuft (nicht so schnell wie IE, aber den kann man aus anderen Gründen vergessen). JA, ich habe antialisign der Fonts aktiviert, aber unter Windows auch!
Versteht mich nicht falsch, ich bin ein Linux/FOSS fan und ich bin der Meinung das ein UI System im Kernel ne riesen Gefahr sein kann, und IMHO ne schlechte Entscheidung ist (nungut, bei Linux muss man's net einkopelieren), aber Trotzdem läuft X noch langsamer als notwendig. Ob das jetzt an schlechter ausnutzung von Hardware, X-Roundtrips oder was weiß ich was liegt, X ist (heute noch) langsam! Ja mit blackbox und "GUI-armen" Anwendungen gehts recht schnell, aber bitte.
Ich hoffe und glaube auch, dass dies mit XOrg besser werden WIRD.
Wer etwas die Entwicklung von XOrg beobachtet hat (seit 1994 oder so als es noch das eigentliche X Consortium gab) der weiss eigentlich das von dort nicht viel zu erwarten ist.
hmm, auf freedesktop.org wird doch auch ein x server entwickelt? der hat aber ein anderes treibermodell: nvidias treiber werden da net gehn. aber hat der ansonsten vieleicht irgendwelche vorteile? ich weiß nur das ein paar features dieses x servers in den von xorg gemerged wurden.
also ich denke das man hier doch X und KDE/Gnome trennen sollte. Ich möchte mal behaupten, das X mit fvwm, twm oder nem ähnlich kleinen WindowManager kaum von Windows zu toppen ist.
Das KO-Kriterium bei nem Fenstermanager im Kernel ist einfach die Stabilität. Ich hab keinen Bock, das mir wie unter Windows eine Website den Rechner zum Absturz bringen kann. Natürlich für PDA's o.ä. ist das ok.
So sinnlos wie ein Kropf! Es gibt Gründe weshalb die GUI nicht im Kernel läuft, und das nennt sich "schlechtes Design" (und ich könnte es mir durchaus vorstellen, dass die Windows GUI genausowenig im Kernel läuft, nur fehlt unter Windows die möglichkeit das BS ohne GUI zu betreiben). Allein, dass die Anwendung im Kernelspace läuft, macht sie nicht notwendigerweise schneller. Und speziell im XFree Fall, liegt die empfundene Langsamkeit an Design und/oder Implementation, d.h. man würde den Stier an der falsche Stelle anpacken, wenn man durch miese Hacks probiert jetzt noch irgendwelche Quäntchen Speed rauszuholen!
Von A. Nonymous am Di, 2. November 2004 um 10:40 #
(und ich könnte es mir durchaus vorstellen, dass die Windows GUI genausowenig im Kernel läuft, nur fehlt unter Windows die möglichkeit das BS ohne GUI zu betreiben
Doch, bis NT war die GUI außerhalb des Kernels, da NT als Microkernelsystem konzipiert war. Mit 2000(?) haben sie die GUI dann in den Kernel integriert, weil ihre Schnittstelle (Systemaufrufe) zum Kernel zu lahm ist. Inzwischen kann man bei Windows das Microkernelkonzept bestenfalls noch erahnen, wenn man gezielt danach sucht. MS pappt allesmögliche irgendwo an den Kernel dran, weil sich die Permformance so einfacher erhöhen läßt sich, als wenn man ein vernünftiges Konzept entwickeln und umsetzen würde.
Woher kommt eigentlich das Märchen, dass ein GUI im Kernel schneller laufen würde als im Userspace? Die CPU macht in beiden Fällen das gleiche - Programmcode ausführen, und dies dann, wenn der Scheduler den Prozess bzw. das Stück Kernel zur Ausführung freigibt.
Natürlich kann man mit Prioritäten und "Low Latency" die Reaktionszeit verkürzen, aber dies ist nicht auf den Kernelmodus beschränkt. Und via Framebuffer oder hardwareangepasstem Grafiktreiber des X-Servers können auch Userspace-Prozesse (sofern sie dann mit Root-Rechten laufen) direkt mit der Grafikkarte kommunizieren.
XFree ist genauso wie diese Implementation nicht schneller wen nicht entsprechende Treiber zur Verfügung stehen. Außerdem vergisst Du das XFree86/X.org eine wesentlich höhere Funktionalität mit sich bringen als Du es hier in Deinen Vergleich siehst.
Ich selbst bin auch ein Beführworter von schlanken grafischen Oberflächen aber eine Implementierung im Kernel ist sicher nicht der richtige Weg!
Nein, zunächst ein Mal, schneller wird so was nicht per se (ein X greift schliesslich auch "nur" auf den Kernel zurück, schau dir doch mal den NVidia-Treiber an, da bekommst du es sogar mit, dass er sich im Kernel einklinkt), allerdings macht so eine Konstruktion das Ganze eher anfällig, wie man gerade bei Win sehen kann. Ohne guten Grund (hier wurde ja bereits der embedded Sektor erwähnt) sollte man es tunlichst vermeiden, alles in den Kernel zu verlagern.
Und zur Geschwindigkeit: was das X so "langsam" (Ansichtssache) macht, ist nicht, dass es im Userspace arbeitet, sondern, weil die ganze Struktur von X nicht auf Geschwindigkeit ausgelegt ist, sondern auf Netzwerktransparenz und Portabilität. Dort müsste man angreifen (und in letzter Zeit wird dort auch vermehrt gearbeitet), um die Darstellung zu beschleunigen. Allerdings würde man damit auch gleich alle Vorteile von X über Bord werfen. Es ist nun mal im Verbund mit mehreren Rechnern ein enormer Vorteil, dass die grafische Ausgabe nicht direkt in einen Speicher geschrieben wird, sondern noch ein Layer dazuwischengesetzt wurde (der das ganze natürlich etwas abbremst), mit dem man die Ausgabe fast nach Belieben umleiten kann.
Win ist nun mal ausschliesslich für den lokalen Desktop entworfen wurden (und man muss grosse Klimmzüge unternehmen, um ein Fenster "über's Netz" zu transferieren), und das merkt man in solchen Bereichen überaus. Aber es hat nichts damit zu tun, ob der Grafikserver oder gar noch der Winmanager im Kernel- oder im Userspace herumhängen.
Apropo Netzwerktransparenz, Portabilität und Abstraktionslayer: bekommt man es hin, eine laufende Xsession eines anderen Benutzers zu übernehmen und die eigenen "InputDevices" wie Tastatur, Maus auf den XServer des anderen zu lenken?
Bei Windows-Terminalservern kann der Adminstrator z.B. die komplette GUI eines jeden angemeldeten Benutzers übernehmen.
Sowas gibts bei X soviel ich weiss nicht generell oder standardmaessig. In KDE gibts jedoch die Moeglichkeit eine KDE - session zu uebernehmen, habs selber aber noch nie probiert weiss daher auch nicht wie vollstaendig diese Uebernahme ist. Ich arbeite hier an einer HPUX Workstation und hin und wieder arbeite ich auf fremden Rechnern (ich bleibe vor meiner Kiste sitzen und kriege das Fenster von der Remote Maschine geliefert). Die Kollegen die vor diesen Rechnern sitzen muessen selbst ja auch weiterarbeiten, daher ist es eher unerwuenscht wenn man immer gleich deren gesamte GUI uebernehmen muss. Bei Administratoren kanns da natuerlich anders ausschauen, die sind in UNIX bei uns aber eher nicht auf eine GUI aus. Ich glaube es hat jedes System seine Berechtigung, in einer Arbeitsgruppe hat das X - System aber doch deutliche Vorteile gegenueber dem was ich von MS Windows kenne. Gibt es unter Windows eigentlich ein System das so aehnlich funktioniert wie X?
Wenn ich mich recht entsinne, gibt es ein Programm xkibitz, mit dem zumindest ein xterm von mehreren Usern gleichzeitig benutzt werden kann. Ich bin mir nicht sicher, ob das wirklich nur auf xterm begrenzt war ...
Super! Was soll den ein GUI System im Kernel? Außer Systemabstütze verursachen.
Das ist nicht das einzige GUI, welches auf dem FrameBuffer aussetzt. Auf DirectFB: DirectFB Homepage läuft auch ein spezielles X-Window-System für den Fall das eine Application doch mal X benötigt. Und ausserdem ist auch OpenGL möglich.
Wollen wir hoffen das dieses Konzept nur eine Machbarkeitsstudie bleibt und niemals in einen offziellen Kernel einzughält. Das erinnert mich an das sinnlose Unterfangen mit dem kleinen HTTP-Server im Kernel, der zum Glück irgendwann rausgeflogen ist.
Ein Fenstersystem im Userspace mit genau der gleichen Implementierung wäre vermutlich nicht langsamer.
Von Captn Difool am Di, 2. November 2004 um 07:12 #
Davon abegesehen reißt dann eine abstürzende Anwendung das ganze System mit, hatten wir schon alles mit NT 4.0 und mit 5.0/1 ist es nicht viel sicherer.
Finde auch, ist ne nette Spielerei, aber gerade die Trennung von Kernel und Oberfläche ist für mich eine der entscheidenden Stärken von Linux/Unix. Das sollte bitte so bleiben.
Für Workstations oder gar Server ist das Kernel-GUI IMHO gar nicht gedacht, eher für Embedded-Anwendungen, z. B. ein Mobiltelefon oder einen portablen Videoplayer. Im Vergleich zu einem schlanken X-Server (TinyX) oder einem Framebuffer-GUI wie OPIE hält sich die Ersparnis an Speicherplatz allerdings in Grenzen.
Zitat: »Viele Entwickler schreiben ewigwachsende Software. Wenn man verhindern will, dass Programme ewig wachsen, muss man sie in Umgebungen platzieren, die das nicht zulassen: wie den Kernel!«
Analogismus: "Jeder Mensch macht irgendwann seine ersten, tollpatschigen Schritte. Wenn man verhindern will, dass er sich dabei verletzt, muss er diese in Umgebungen tun, die das nicht zulassen: auf dem Fesseltisch!"
"Viele Entwickler schreiben ewigwachsende Software. Wenn man verhindern will, dass Programme ewig wachsen, muss man sie in Umgebungen platzieren, die das nicht zulassen: wie den Kernel!" Na toll! Soll man jetzt jedes Programm, von dem man nicht will das es ewig wächst, in den Kernel packen? Vielleicht einen Browser oder Media-Player ;) Mir wäre ein lansameres Fenster-System lieber, als eins das beim Absturz das ganze System mit sich zieht.
Außerdem werden die PCs sowieso immer schneller und größer. Also was solls ...
Die Integration eines Fenstersystems in den Kernel macht - wenn überhaupt - nur Sinn in Embedded Devices (PDA, Handy) und vielleicht noch in Spielkonsolen, aber auf keinen Fall auf Desktop-PCs.
»Viele Entwickler schreiben ewigwachsende Software. Wenn man verhindern will, dass Programme ewig wachsen, muss man sie in Umgebungen platzieren, die das nicht zulassen: wie den Kernel!«
...und dann den MS-Weg gehen, und den Kram statt im userspace im kernel aufblähen? Die Trennung von Kernel- und Userspace hat schon ihren Sinn, und was ein GUI im Kernelspace zu suchen hat, ist mir ziemlich schleierhaft.
Hi zusammen, also ich finde es gar nicht so schlecht wenn man mal einfach neue Wege geht. Ok, auch mir ist der Sinn des unterfangens im Desktop-Bereich etwas schleierhaft. Aber Gründe dagegen wurden wohl mittlerweile genug aufgeführt. Dennoch sollte man so etwas unterstützen, denn nur so kann sich ein System weiterentwickeln und im Embedded-Bereich für Kleinstgeräte kann ich mir durchaus sinnvolle Einsatzmöglichkeiten vorstellen. Es muss ja nicht immer alles fester bestandteil des Kernels werden.
Achja zum Thema X, im 2D Bereich ist das mittlerweile wirklich schnell genug und hat zusätzlich eine Menge Vorteile gegenüber der MS-Lösung. Aber der 3D Bereich hängt echt hinterher obs nun an den Treibern der Hersteller liegt oder nicht, für User zählt doch nur das Resultat. Und die Spielkinder reden von Grafikpower doch eigentlich nur im 3D-Bereich.
Was bitte ist an einem primitiven, pixelbasierten Window System Grundlagenforschung? Davon gibt es seit den 60er Jahren hunderte von Variationen! Das jemand die saublöde Idee hatte das im Kernel zu implementieren?
X11 ist so furchtbar langsam (wegen Netzwerktransparenz etc).
Realität:
X11 allein ist trotz der Netzwerktransparenz ungemein schnell. Die meisten Applikationen und/oder Desktop Environments (Gnome/KDE) erzeugen hingegen massig Overhead und sind daher wesentlich langsamer. Die Lösung besteht also einfach darin, diese zu meiden. Die Netzwerktransparenz hat außerdem bestimmte Vorteile (VNC, ssh, etc).
Mythos 2:
X11 ist zu groß für die meisten Anwendungen.
Realität:
Wem das normale X11R6.8.1 zu groß ist, der sollte Keith Packards verkleinerten X Server (auf google nach KDrive tiny X Server suchen) verwenden. Auch der XServer läßt sich in verschiedene Richtungen optimieren.
Mythos 3:
Das GUI-Core gehört in den Kernel, damit alles schneller und flüssiger geht.
Realität:
Die Trennung von XServer und Kernel hat oftmals den Vorteil, daß man ein System, dessen GUI aus Treiber- oder sonstigen Problemen nicht läuft, immer noch im Textmodus kontrollieren kann. Welcher einigermaßen erfahrene Linux-Benutzer hat noch nie in seinem Leben [Alt]-[Strg]-[Backspace] gedrückt? Hand aufs Herz und die Wahrheit sagen!
Schließlich ist das Hauptproblem nicht beim Server, sondern bei den Applikationen. Die Programmierer bei der Hand zu nehmen und ihnen eine Hilfestellung zu geben, wie ihre Programme kleiner und schneller anstatt größer und langsamer werden, ist gut. Allerdings reicht ein vernünftiges GUI-Toolkit. Letztlich wird es genau darauf hinauslaufen, daß die Anzahl der verfügbaren wichtigen Applikationen (Webbrowser, Mailclient, Textbearbeitung, Tabellenkalkulation, Dateimanager, Bildbearbeitungssoftware, Medienwiedergabe, um nur die Wichtigsten zu nennen) darüber entscheiden, ob sich FBUI durchsetzen kann.
> Mythos 3: > > Das GUI-Core gehört in den Kernel, damit alles schneller und flüssiger geht. > > Realität: > > Die Trennung von XServer und Kernel hat oftmals den Vorteil, daß man ein System, dessen GUI > aus Treiber- oder sonstigen Problemen nicht läuft, immer noch im Textmodus kontrollieren kann. > Welcher einigermaßen erfahrene Linux-Benutzer hat noch nie in seinem Leben > [Alt]-[Strg]-[Backspace] gedrückt? Hand aufs Herz und die Wahrheit sagen!
Der Grund ist nicht Schnelligkeit sondern Sicherheit und Stabilität, warum FBUI nicht in den Kernel gehört. GUIs sollten prinzipiell im Userspace laufen egal ob Embedded oder nicht.
Die Desktopenviroments KDE/GNOME zu meiden ist aber für viele nicht die optimale Lösung :). Die Lösung ist die veraltete Xlib durch XCB zu ersetzten. Und genau das ist der Plan bei Xorg. Die geben da ja zu das die Probleme an der Xlib liegen (siehe Video von Daniel Stone bei der Akademy)
X11R6 hat derzeit genau ein Problem in Punkto Geschwindigkeit im Netz: es braucht zu viele Round-Trips. Das ist Designimmanent und an dem Punkt kann man ansetzen, etwas zu optimieren. LBX und dergleichen existieren seit Jahrzehnten, Remote X auf kleiner Bandbreite bleibt aber schwerfällig, weil immer noch zu viele Round Trips gebraucht werden.
Daß ein lokales X11 zwangsläufig nennenswert langsamer sein muß als ein Kernel-GUI, ist in der Tat eine Urban Legend. Die Geschwindigkeit eines Grafiksystems wird im Wesentlichen durch den Treiber für die Grafikkarte und deren Fähigkeiten bestimmt. Das ist bei X11 nicht anders wie bei Windows. Wenn Grafikkartenhersteller unfähig sind, funktionierende und schnelle X-Server für ihre Karten zu liefern, dann liegt das mit Sicherheit nicht daran, daß X11 im Userspace läuft.
Übrigens lieferte SGI Jahrzehntelang die anerkanntermaßen schnellsten Grafikcomputer überhaupt - mit einem X11-Frontend, das einfach nur um entsprechende Extensions (z.B. OpenGL) erweitert wurde.
Mit "Grundlagenforschung" hat das Ganze erst Recht nichts zu tun. Daß etwas so komplexes wie ein Grafik-Subsystem im Kernel nichts zu suchen hat, ist seit mehreren Jahrzehnten allgemeiner Konsens bei so gut wie allen halbwegs kompetenten Softwaredesignern. Diese Diskussion ist längst ausdiskutiert, man braucht sie nicht mehr aufzurollen, die Grundlagen dafür sind bekannt und akzeptiert.
Wer "Grundlagenforschung" im GUI-Bereich machen möchte, sollte sich lieber darauf konzentrieren, wie man z.B. dynamisch Intelligenz zwischen Grafik-Subsystem und CPU verteilen kann, so daß je nach verfügbarer Bandbreite transparent jeweils die optimale Leistung aus dem System geholt werden kann. Oder wie man wirklich skalierbare Oberflächen für hoch- und höchstauflösende Grafiksubsysteme bauen kann (wird wohl nur über Vektorgraphik gehen, Berlin macht z.B. was in die Richtung). Oder wie man es ermöglichen kann, daß Teile des Widget Set autonom auf dem X-Server ablaufen können, auch wenn der vielleicht eine ganz andere Architektur/Hardware hat als das Applikationssystem.
Es ist eines der schlechtesten Designvarianten, die man sich vorstellen kann. Aus Stabilitätsaspekten und Sicherheitsgründen sollte man so etwas nicht in den Kernel integrieren. Für mich klingt es eigentlich wie ein Aprilscherz.
Das Teil ist ja auch nicht für den offiziellen Kernel gedacht. Es ist eben eine Spielerei. Ich jedenfalls finde es toll, wenn jemand mal was neues macht. Es zeigt das grundsätzliche Potenzial eines offenen Systems.
Es muss auch keiner Angst um sein KDE/Gnome haben. Wenn überhaupt wird das Fenstern im Kernel wohl nur im Embedded-Bereich ersthaft verwendet.
Und für die US-Wahlmaschinen kommt es zu spät... aber keine Sorge, die stürzen auch so ab...
Von Jörg W Mittag am Di, 2. November 2004 um 11:59 #
Es geht nicht um "meckern" sondern um Kritik an der Begründung. Der Autor sieht sich selbst als Führer der "Bloat Liberation Front". Und dann will er den Kernel mit völlig unnötigen Features aufblähen, mit der Begründung, damit das unnötige Aufblähen von Programmen zu bekämpfen?
Die gleiche Funktionalität kann man genausogut im Userspace erreichen. Tatsächlich existieren mit svgalib, DirectFB, dem kdrive Tiny X Server u.s.w. bereits Projekte, die z.T. eine Unter-, z.T. eine Obermenge der Funktionalität von FBGUI im Userspace implementieren und beileibe nicht aufgebläht sind. Das 2-Disk X Window System (das nur noch aus historischen Gründen so heißt, weil es nämlich früher mal nicht auf eine Diskette gepasst hat) ist eine Linux-Distribution mit X Window System, Window Manager, grafischem Web-Browser und diversen Tools auf einer einzigen Diskette. Und das ganz ohne GUI im Kernel.
hi, vorteil sehe ich vor allem bei "kleinen" geräten: mit arm-prozessor laufende pda, handys oder spielekonsolen, da ist die ausführung im kernelspace auch nicht so sicherheitskritisch. Hauptnachteile: das Ding ist wohl keine x-Lib-API-Nachbildung, d.h. mächtige GUI-Toolkits wir QT oder GTK+ kann man da wohl nicht zur Entwicklung benutzen; wohl auch wegen der beschränkung im kernel-space Meine Vision: Ein Kernelmodul, dass nur x-Lib-API (ohne Netzwerktransparenz) und die X.org/XFREE- Treiberschnittstelle nachbildet; Fenstermanager und Desktop laufen im Userspace.
Wenn dann noch jemand den Emacs integrieren könnte, wäre der Linux-Kernel mit einem Schlag ein vollständiges Betriebssystem, mit allem was ein vernünftiger Mensch jemals am Computer brauchen wird!
IIRC gibt es das sowohl für Emacs, wie auch vi. Suche mal danach Es gibt jedenfalls einen Patch für die Türme von Hanoi im Linux Kernel. Dann brauchst du schonmal dafür keine kostspielige Implentierung im Userspace.
Vielleicht kommt das von den Leuten, die in ihrem X11 die Beschleunigung deaktiviert haben. Oder vielleicht haben die auch nur eine alte oder zu moderne Grafikkarte, für die es noch keinen vernünftigen X-Treiber gibt. Dann ist X11 in der Tat langsam. Aber nur dann.
JA, ich habe antialisign der Fonts aktiviert, aber unter Windows auch!
Versteht mich nicht falsch, ich bin ein Linux/FOSS fan und ich bin der Meinung das ein UI System im Kernel ne riesen Gefahr sein kann, und IMHO ne schlechte Entscheidung ist (nungut, bei Linux muss man's net einkopelieren), aber Trotzdem läuft X noch langsamer als notwendig.
Ob das jetzt an schlechter ausnutzung von Hardware, X-Roundtrips oder was weiß ich was liegt, X ist (heute noch) langsam! Ja mit blackbox und "GUI-armen" Anwendungen gehts recht schnell, aber bitte.
Ich hoffe und glaube auch, dass dies mit XOrg besser werden WIRD.
flüssig ..nicht mit Windows vergleichbar.
Das KO-Kriterium bei nem Fenstermanager im Kernel ist einfach die Stabilität. Ich hab keinen Bock, das mir wie unter Windows eine Website den Rechner zum Absturz bringen kann. Natürlich für PDA's o.ä. ist das ok.
Alex
Doch, bis NT war die GUI außerhalb des Kernels, da NT als Microkernelsystem konzipiert war. Mit 2000(?) haben sie die GUI dann in den Kernel integriert, weil ihre Schnittstelle (Systemaufrufe) zum Kernel zu lahm ist. Inzwischen kann man bei Windows das Microkernelkonzept bestenfalls noch erahnen, wenn man gezielt danach sucht. MS pappt allesmögliche irgendwo an den Kernel dran, weil sich die Permformance so einfacher erhöhen läßt sich, als wenn man ein vernünftiges Konzept entwickeln und umsetzen würde.
Mario
Natürlich kann man mit Prioritäten und "Low Latency" die Reaktionszeit verkürzen, aber dies ist nicht auf den Kernelmodus beschränkt. Und via Framebuffer oder hardwareangepasstem Grafiktreiber des X-Servers können auch Userspace-Prozesse (sofern sie dann mit Root-Rechten laufen) direkt mit der Grafikkarte kommunizieren.
/.
DocSnyder.
Ich selbst bin auch ein Beführworter von schlanken grafischen Oberflächen aber eine Implementierung im Kernel ist sicher nicht der richtige Weg!
Grüße
Sturmkind
Und zur Geschwindigkeit: was das X so "langsam" (Ansichtssache) macht, ist nicht, dass es im Userspace arbeitet, sondern, weil die ganze Struktur von X nicht auf Geschwindigkeit ausgelegt ist, sondern auf Netzwerktransparenz und Portabilität. Dort müsste man angreifen (und in letzter Zeit wird dort auch vermehrt gearbeitet), um die Darstellung zu beschleunigen. Allerdings würde man damit auch gleich alle Vorteile von X über Bord werfen. Es ist nun mal im Verbund mit mehreren Rechnern ein enormer Vorteil, dass die grafische Ausgabe nicht direkt in einen Speicher geschrieben wird, sondern noch ein Layer dazuwischengesetzt wurde (der das ganze natürlich etwas abbremst), mit dem man die Ausgabe fast nach Belieben umleiten kann.
Win ist nun mal ausschliesslich für den lokalen Desktop entworfen wurden (und man muss grosse Klimmzüge unternehmen, um ein Fenster "über's Netz" zu transferieren), und das merkt man in solchen Bereichen überaus. Aber es hat nichts damit zu tun, ob der Grafikserver oder gar noch der Winmanager im Kernel- oder im Userspace herumhängen.
bekommt man es hin, eine laufende Xsession eines anderen Benutzers zu übernehmen und die eigenen "InputDevices" wie Tastatur, Maus auf den XServer des anderen zu lenken?
Bei Windows-Terminalservern kann der Adminstrator z.B. die komplette GUI eines jeden angemeldeten Benutzers übernehmen.
Ich arbeite hier an einer HPUX Workstation und hin und wieder arbeite ich auf fremden Rechnern (ich bleibe vor meiner Kiste sitzen und kriege das Fenster von der Remote Maschine geliefert). Die Kollegen die vor diesen Rechnern sitzen muessen selbst ja auch weiterarbeiten, daher ist es eher unerwuenscht wenn man immer gleich deren gesamte GUI uebernehmen muss.
Bei Administratoren kanns da natuerlich anders ausschauen, die sind in UNIX bei uns aber eher nicht auf eine GUI aus.
Ich glaube es hat jedes System seine Berechtigung, in einer Arbeitsgruppe hat das X - System aber doch deutliche Vorteile gegenueber dem was ich von MS Windows kenne. Gibt es unter Windows eigentlich ein System das so aehnlich funktioniert wie X?
Gustl
Carsten
Beschreibung findest Du in easyLINUX 11/2004
Das ist nicht das einzige GUI, welches auf dem FrameBuffer aussetzt.
Auf DirectFB: DirectFB Homepage
läuft auch ein spezielles X-Window-System für den Fall das eine Application doch mal X benötigt.
Und ausserdem ist auch OpenGL möglich.
Ein Fenstersystem im Userspace mit genau der gleichen Implementierung wäre vermutlich nicht langsamer.
Finde auch, ist ne nette Spielerei, aber gerade die Trennung von Kernel und Oberfläche ist für mich eine der entscheidenden Stärken von Linux/Unix. Das sollte bitte so bleiben.
/.
DocSnyder.
»Viele Entwickler schreiben ewigwachsende Software. Wenn man verhindern will, dass Programme ewig wachsen, muss man sie in Umgebungen platzieren, die das nicht zulassen: wie den Kernel!«
Analogismus:
"Jeder Mensch macht irgendwann seine ersten, tollpatschigen Schritte. Wenn man verhindern will, dass er sich dabei verletzt, muss er diese in Umgebungen tun, die das nicht zulassen: auf dem Fesseltisch!"
;) FLoH.
(so versaut man sich seine Pointen, egal)
FLoH.
Na toll! Soll man jetzt jedes Programm, von dem man nicht will das es ewig wächst, in den Kernel packen? Vielleicht einen Browser oder Media-Player ;)
Mir wäre ein lansameres Fenster-System lieber, als eins das beim Absturz das ganze System mit sich zieht.
Die Integration eines Fenstersystems in den Kernel macht - wenn überhaupt - nur Sinn in Embedded Devices (PDA, Handy) und vielleicht noch in Spielkonsolen, aber auf keinen Fall auf Desktop-PCs.
...und dann den MS-Weg gehen, und den Kram statt im userspace im kernel aufblähen? Die Trennung von Kernel- und Userspace hat schon ihren Sinn, und was ein GUI im Kernelspace zu suchen hat, ist mir ziemlich schleierhaft.
Bei "Longhorn" wird alles anders.
Übrigens: Auch im Bereich Linux muss es Grundlagenforschung geben!
also ich finde es gar nicht so schlecht wenn man mal einfach neue Wege geht. Ok, auch mir ist der Sinn des unterfangens im Desktop-Bereich etwas schleierhaft. Aber Gründe dagegen wurden wohl mittlerweile genug aufgeführt. Dennoch sollte man so etwas unterstützen, denn nur so kann sich ein System weiterentwickeln und im Embedded-Bereich für Kleinstgeräte kann ich mir durchaus sinnvolle Einsatzmöglichkeiten vorstellen.
Es muss ja nicht immer alles fester bestandteil des Kernels werden.
Achja zum Thema X, im 2D Bereich ist das mittlerweile wirklich schnell genug und hat zusätzlich eine Menge Vorteile gegenüber der MS-Lösung. Aber der 3D Bereich hängt echt hinterher obs nun an den Treibern der Hersteller liegt oder nicht, für User zählt doch nur das Resultat. Und die Spielkinder reden von Grafikpower doch eigentlich nur im 3D-Bereich.
Grüße
Matthias
X11 ist so furchtbar langsam (wegen Netzwerktransparenz etc).
Realität:
X11 allein ist trotz der Netzwerktransparenz ungemein schnell. Die meisten Applikationen und/oder Desktop Environments (Gnome/KDE) erzeugen hingegen massig Overhead und sind daher wesentlich langsamer. Die Lösung besteht also einfach darin, diese zu meiden. Die Netzwerktransparenz hat außerdem bestimmte Vorteile (VNC, ssh, etc).
Mythos 2:
X11 ist zu groß für die meisten Anwendungen.
Realität:
Wem das normale X11R6.8.1 zu groß ist, der sollte Keith Packards verkleinerten X Server (auf google nach KDrive tiny X Server suchen) verwenden. Auch der XServer läßt sich in verschiedene Richtungen optimieren.
Mythos 3:
Das GUI-Core gehört in den Kernel, damit alles schneller und flüssiger geht.
Realität:
Die Trennung von XServer und Kernel hat oftmals den Vorteil, daß man ein System, dessen GUI aus Treiber- oder sonstigen Problemen nicht läuft, immer noch im Textmodus kontrollieren kann. Welcher einigermaßen erfahrene Linux-Benutzer hat noch nie in seinem Leben [Alt]-[Strg]-[Backspace] gedrückt? Hand aufs Herz und die Wahrheit sagen!
Schließlich ist das Hauptproblem nicht beim Server, sondern bei den Applikationen. Die Programmierer bei der Hand zu nehmen und ihnen eine Hilfestellung zu geben, wie ihre Programme kleiner und schneller anstatt größer und langsamer werden, ist gut. Allerdings reicht ein vernünftiges GUI-Toolkit. Letztlich wird es genau darauf hinauslaufen, daß die Anzahl der verfügbaren wichtigen Applikationen (Webbrowser, Mailclient, Textbearbeitung, Tabellenkalkulation, Dateimanager, Bildbearbeitungssoftware, Medienwiedergabe, um nur die Wichtigsten zu nennen) darüber entscheiden, ob sich FBUI durchsetzen kann.
Just my 2 1/2 ct.
Alex
> Mythos 3:
>
> Das GUI-Core gehört in den Kernel, damit alles schneller und flüssiger geht.
>
> Realität:
>
> Die Trennung von XServer und Kernel hat oftmals den Vorteil, daß man ein System, dessen GUI
> aus Treiber- oder sonstigen Problemen nicht läuft, immer noch im Textmodus kontrollieren kann.
> Welcher einigermaßen erfahrene Linux-Benutzer hat noch nie in seinem Leben
> [Alt]-[Strg]-[Backspace] gedrückt? Hand aufs Herz und die Wahrheit sagen!
Der Grund ist nicht Schnelligkeit sondern Sicherheit und Stabilität, warum FBUI nicht in den Kernel gehört. GUIs sollten prinzipiell im Userspace laufen egal ob Embedded oder nicht.
Daß ein lokales X11 zwangsläufig nennenswert langsamer sein muß als ein Kernel-GUI, ist in der Tat eine Urban Legend. Die Geschwindigkeit eines Grafiksystems wird im Wesentlichen durch den Treiber für die Grafikkarte und deren Fähigkeiten bestimmt. Das ist bei X11 nicht anders wie bei Windows. Wenn Grafikkartenhersteller unfähig sind, funktionierende und schnelle X-Server für ihre Karten zu liefern, dann liegt das mit Sicherheit nicht daran, daß X11 im Userspace läuft.
Übrigens lieferte SGI Jahrzehntelang die anerkanntermaßen schnellsten Grafikcomputer überhaupt - mit einem X11-Frontend, das einfach nur um entsprechende Extensions (z.B. OpenGL) erweitert wurde.
Mit "Grundlagenforschung" hat das Ganze erst Recht nichts zu tun. Daß etwas so komplexes wie ein Grafik-Subsystem im Kernel nichts zu suchen hat, ist seit mehreren Jahrzehnten allgemeiner Konsens bei so gut wie allen halbwegs kompetenten Softwaredesignern. Diese Diskussion ist längst ausdiskutiert, man braucht sie nicht mehr aufzurollen, die Grundlagen dafür sind bekannt und akzeptiert.
Wer "Grundlagenforschung" im GUI-Bereich machen möchte, sollte sich lieber darauf konzentrieren, wie man z.B. dynamisch Intelligenz zwischen Grafik-Subsystem und CPU verteilen kann, so daß je nach verfügbarer Bandbreite transparent jeweils die optimale Leistung aus dem System geholt werden kann. Oder wie man wirklich skalierbare Oberflächen für hoch- und höchstauflösende Grafiksubsysteme bauen kann (wird wohl nur über Vektorgraphik gehen, Berlin macht z.B. was in die Richtung). Oder wie man es ermöglichen kann, daß Teile des Widget Set autonom auf dem X-Server ablaufen können, auch wenn der vielleicht eine ganz andere Architektur/Hardware hat als das Applikationssystem.
Es muss auch keiner Angst um sein KDE/Gnome haben. Wenn überhaupt wird das Fenstern im Kernel wohl nur im Embedded-Bereich ersthaft verwendet.
Und für die US-Wahlmaschinen kommt es zu spät... aber keine Sorge, die stürzen auch so ab...
Die gleiche Funktionalität kann man genausogut im Userspace erreichen. Tatsächlich existieren mit svgalib, DirectFB, dem kdrive Tiny X Server u.s.w. bereits Projekte, die z.T. eine Unter-, z.T. eine Obermenge der Funktionalität von FBGUI im Userspace implementieren und beileibe nicht aufgebläht sind. Das 2-Disk X Window System (das nur noch aus historischen Gründen so heißt, weil es nämlich früher mal nicht auf eine Diskette gepasst hat) ist eine Linux-Distribution mit X Window System, Window Manager, grafischem Web-Browser und diversen Tools auf einer einzigen Diskette. Und das ganz ohne GUI im Kernel.
jwm
vorteil sehe ich vor allem bei "kleinen" geräten:
mit arm-prozessor laufende pda, handys oder spielekonsolen, da ist die ausführung im kernelspace auch nicht so sicherheitskritisch.
Hauptnachteile:
das Ding ist wohl keine x-Lib-API-Nachbildung, d.h. mächtige GUI-Toolkits wir QT oder GTK+ kann man da wohl nicht zur Entwicklung benutzen; wohl auch wegen der beschränkung im kernel-space
Meine Vision:
Ein Kernelmodul, dass nur x-Lib-API (ohne Netzwerktransparenz) und die X.org/XFREE- Treiberschnittstelle nachbildet; Fenstermanager und Desktop laufen im Userspace.
es gibt ja auch so gute Framebuffer apps(links -g, fbi)
Und wenn Kernelspace so viel schneller ist, sollten die lieber daran arbeiten, dass der Userspace genausoschnell wird.
Letztendlich haben wir dann einen 200mb kernel, mit allen wichtigen kde apps drin ;-)
Allo
Gruß
lamneth
also erst prahlen sie damit, wieveil kleiner ihre apps sind, bieten aber nicht einmal überlappende fenster.
also ein unbrauchbarer wm, der doch in größenmaßstaäben von ~500k in etwa das selbe ist twm.
denn über ~500k mehr wird sich heute kaum wer aufregen...
Allo
NikN