Von Christopher Roy Bratusek am Do, 16. Juli 2009 um 13:08 #
... lernt doch noch springen, villeicht wäre es aber mal an der Zeit sich einen Welpen zu zulegen und groß zu ziehen, statt dem Rüden noch mehr Krücken und Schienen anzulegen.
Hoffentlich verschwindet /dev/mem dann auch mal. Unter Unix ist ja alles immer so toll designt; und dann kommt da ein Gerätetreiber her, der den Zugriff auf den gesamten physikalischen Adressraum ermöglicht und ein Programm namens X-Server greift darauf zu, sucht am Kernel vorbei nach PCI-Hardware und spricht diese direkt an. Ich kann nicht glauben, dass man bei der Entwicklung von Linux und anderen Unixen das Thema Grafik so weit außen vor gelassen hat. Wir könnten längst ganz wo anders sein...
Von Christopher Roy Bratusek am Do, 16. Juli 2009 um 14:27 #
Aus dem Wayland Wiki:
Why not extend the X server?
Because we for the first time we have a realistic chance of not having to do that. It's entirely possible to incorporate the buffer exchange and update models the Wayland is built on into X. However, we have an option here of pushing X out of the hotpath between clients and the hardware and making it a compatibility option. I'm not deluding myself that any general purpose desktop Linux distribution will stop shipping X as we know it or as a Wayland client anytime soon. Nor should they, there will still be X applications to run and people expect that from a Linux desktop. What's different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango etc) and there is very little left that has to happen in a central server process.
Was tun? Eine neue Spezifikation, ein neuer Server. Dazu sollten Novell, Ubuntu, KDE, GNOME, blah mal Entwickler abstellen, nicht für so einen frickelscheiss wie Banshee oder Restricted-Manager, davon würden alle profitieren:
- X11 ist von '87 -> 22 Jahre, so alt werden Hunde nur selten, der gehört eingeschläfert - Linux/BSD/blah stehen im Vergleich zu anderen Systemen, die neuere Grafischesubssysteme bereitstellen besser da - ...
Der neue Server sollte nur aus dem Kern bestehen, der ganze Rest, Rendering, Compositing, blah, sollte vom Kern komplett abgespalten werden, damit wir nicht erneut in so ein Problem hineinlaufen. X.Org stellt Dinge bereit, die in den 80ern hip waren, heute aber niemand mehr braucht, trotzdem entfenrt keiner diese Codezombies. Mit einer Generalmodularisierung (nicht nur die libs, protos, usw, sondern Rendering API, Server, usw) könnte man sowas bei kommen, da einzelne Module weniger Code hätte, damit einfacher wart-, entfern-, oder ersetzbar wären.
Poste doch mal dein Vorschläge auf der xorg-Mailingliste und lasse sie direkt von den Entwicklern kommentieren. Das bringt mehr, als sie hier versiegen zu lassen. Vielleicht ist ja wirklich etwas brauchbares dabei. Nur ein Vorschlag...
x11 ist ein Protokoll und das ist älter als 22 Jahre, aber deshalb ist nicht alles gleich 22 Jahre alt.
wenn du für erneuerung bist dann biste auch für abschaffung von ftp http snmp dns als älter als 15 jahre und das werden hunde kaum, und es sollte nur hunde in der IT geben
Menschen werden älter aber dürfen als vergleich nicht herhalten ebenso wie schildkröten
Also nur weil was alt ist muss es nicht schlecht sein
Richtig, andere Protokolle wie ftp sind auch alt. Aber du vergisst ein bisschen, das ftp im Vergleich zu X11 sehr sehr sehr viel trivialer ist.
Und X11 ist leider alt und zugleich schlecht. Die Nezuwerktransparent ist cool und sollte in einer neuen Lösung erhalten bleiben. Dazu gehören auf jeden Fall virtuelle Kanäle in einer Verbindung für Sound, Drucken, USB, etc.; eben so wie Citrix ICA.
Wie wäre es mit SSH bzw. eher SCP? Ist zudem noch sicherer und die Router können das wesentlich besser routen - kein passsive ftp blah. Für *nix gibts das sowieso und für Windows auch (WinSCP).
würdest Du anonymous FTP auch mit SSH ersetzen? Das ist der wichtigste Teil des Protokolls.
Wozu willst Du die Verschlüsselung machen? Weil Fileserver jetzt alle zig CPUs haben, oder wie? Ich finde das ist einfach Verschwendung für öffentliche Downloads.
Warum willst Du ein Caching durch Proxies gleich ganz unmöglich machen? Jetzt kann eine Firma transparent über einen FTP-Proxy dafür sorgen, dass nicht 10 Leute jeder einzeln sich eine Datei holen, sondern nur der erste, und dann kriegen es alle aus dem Cache. Das ist für das Internet sehr viel verträglicher.
Nur weil man mit fish:/ auch Dateien kopieren kann, heisst das nicht, dass es gleich die richtige für alle und immer ist.
Eines der ältesten Formate ist übrigends SMTP (Email), auch HTTP ist nicht ganz so jung, daher finde ich Alter schadet Protokollen nicht. Es hat einen Wert an sich, wenn ein Protokoll von vielen verstanden ist.
Und was X11 angeht, so gibt es eindeutig Nichts besseres. Seit die X-Server auch direkt VNC können, fällt mir auf der Ebene der Netzwerkfähigkeit und Transparenz Nichts ein, was auch nur fehlen könnte, allenfalls würde ich gerne die X-Verbindung von Prozessen suspenden und umziehen können.
Und sonst, was da so geleistet wird, im XOrg-Land ist zuletzt wahnsinnig schnell und gut geworden. Tastatur und Maus kann man jetzt ausserhalb erledigen lassen. Speichermanagement der Grafikkarte übernahm der Kernel, und auch das Modesetting, so dass XOrg endlich nicht mehr so viele Sachen enthält und sich auf X11 konzentrieren kann.
Wenn Intel mit seiner XOrg-Arbeit fertig ist, und viel fehlt nicht mehr, hat Linux den besten Grafikstack bekommen - und das innerhalb weniger Jahre, sehr sehr beeindruckende Arbeit.
Ein großer Nachteil von SSH ist, dass er einen Shellzugriff ermöglicht, was man je nach Nutzerkreis unbedingt vermeiden will. Es gibt zwar prinzipiell Möglichkeiten, den Shellzugriff einzuschränken. Deren sichere(!) Konfiguration ist jedoch nicht ohne und erfordert manchmal sogar den Wechsel des Betriebssystems, um z.B. Jails nutzen zu können.
Also, nur weil etwas alt ist, muss es nicht schlecht sein. Nicht alles neue ist auch gut.
Die CPU Architekturen auf denen wir heute arbeiten sind vom Prinzip her gut und gerne 40 Jahre alt.
Das Rad wurde vor ein paar tausend Jahren erfunden. Bisher hatte niemand eine bessere Idee im Bereich "Kutschen, Autos, Moped usw."
Ein Relikt aus der Steinzeit sind "Mauern", die ab und an schon sinnvoll sind ....
Natürlich, wurden die oben aufgezählten Dinge optimiert, erweiter usw. Die Basis, das Grundprinzip ist alt.
Surück su Ihx. Im Prinzip bin ich bei dir, X wurde für Großrechner der 80er Jahre designed. Aufm Desktop liegen die Schwerpunkte der Anwender-Anforderungen anders. Nicht umsonst, ist das GUI System in Windows zum Teil im Kern. Das ist bestimmt nicht die beste Lösung, aber dem Anwenderwunsch deutlich näher als X.
Dann erzähl doch mal bitte, was dich beim Xserver so extrem dermaßen stört. Und zwar bitte konkrete Anwendungsfälle, nicht nur irgendwelchen komischen Design- oder Theorie-Sch...s.
Von Anonymous Coward am Do, 16. Juli 2009 um 17:13 #
Das ist eine völlig blödsinnige Idee. Du hast nicht einen einzigen Aspekt am X11-Protokoll genannt, das es nötig machen würde, die vorhandene und funktionierende Lösung wegzuschmeißen. Stattdessen bashst Du auf dem Alter von X11 herum, natürlich ohne zu berücksichtigen, dass andere Technologien wie UNIX oder TCP/IP noch viel älter sind.
Fakt ist, dass die Nutzer schon genug von den Nebeneffekten der jüngsten Änderungen am Linux-Grafikstack genervt sind (z. B. von den Regressionen im Intel-Treiber usw.). Und jetzt willst Du *alles* wegschmeißen, damit für die nächsten 5 Jahre auch ja niemand in der Lage ist, Linux produktiv einzusetzen? Aua. Wenn Du wenigstens irgendeine konkrete Vision hättest, irgend etwas, das mit der aktuellen Architektur nicht zu bewerkstellen ist, dann könnte man ja drüber jeden. So ist es nur dämliches Gelaber.
??? Nur weil man statt Patches zu schreiben einen kompletten Neubeginn macht, so muss man doch nicht die Verbreitung von Xorg stoppen. Solange nix stabil ist, kann doch dennoch das alte genutzt werden.
Oder werden bei in der Stadt auch erst die alten Brücken abgerissen und dann 2 Jahre lang eine neue gebaut anstatt die neue zu bauen solange die alte noch geht?
Von PenguinFrickler am Fr, 17. Juli 2009 um 09:14 #
/offtopic an > Oder werden bei in der Stadt auch erst die alten Brücken abgerissen und dann 2 Jahre lang eine neue gebaut Ich weiss ja nicht wieviel Brückenbau Du schon so gesehen hast, aber ich würd mal sagen in 80% der Fälle ist das so. /offtopic aus
Ich habe vor 100 Jahren schon gesagt das alles was mit Grafikausgabe unter Unix/Linux zu tun hat ein Grauß ist. Das geht mit dem X-Server design los, über lahmarschige Toolkits mit schlecht lesbaren Widgets, häßlichen Fonts bis hin zur Usability. Aber anstatt diese völlig grundlegenden Issues erstmal anzugehen wird die 1000ste Desktop Umgebung programmiert die von besagten Punkten genauso betroffen ist wie 999 andere. Und dann wundert man sich, dass Linux auf dem Desktop nicht ankommt; die Lösung ist einfach uncool
Von Christopher Roy Bratusek am Do, 16. Juli 2009 um 15:37 #
Nur das es wirklich ein Konfigurationsproblem ist, ich kann unter GNOME die Schriften sogar explizit so hässlich aussehen lassen, oder eben nicht. GnomeCC -> Erscheinungsbild -> Schrift | für KDE weiss ich es jetzt nicht auswending, es lässt sich auch manuell einrichten, weiß aber nicht aus dem Kopf wie.
Die einzige Schrift, die auf einem *nix gut aussah, war ein Tahoma Font (Ja, von Windows) mit einer weiss ich nicht wie aufgeborten Rendering-Bibliothek. Es geht nicht nur um das Rendering, sondern auch um die Schriftart an sich. Im FOSS Umfeld haben wir keine einzige, die annähernd so gut aussieht wie das Zeug von MS oder Apple.
Von Christopher Roy Bratusek am Do, 16. Juli 2009 um 15:45 #
Das ist Geschmackssache. Und so furchtbar sind Dejavu und Co. auch nicht. Zekton z.B. find ich gut. Oder Final Frontier, gut die ist nicht OpenSource aber "free for personal use".
Stephanw hat Recht, es gibt viel zu wenig gute Schriften im FOSS-Umfeld. Da kann man wirklich nur neidisch zu Windows und MacOS rüberschauen. Und, Christopher..., das du hier dieses komische Zekton Font als Beispiel anführst kann doch wohl nicht dein Ernst sein, oder? Soll ich die als Bildschirmschriftart nehmen? Oder Dokumente damit erzeugen? Das ist eine billig-Schriftart wie es sie hunderttausendfach im Web gibt, und keine professionell gesetzte Type mit der man was sinnvolles anfangen kann.
und was ZUR HÖLLE hat das bitte mit der Architektur von X zu tun? Genau aus dem Grund wurde dir vorgeworfen du hast keine Ahnung. Wenn sich niemand hinsetzt und eine "schöne" Schrift entwirft, dann ist das natürlich ein konzeptionelles Problem der X-Architektur... ne ist klar nä! Zudem ist X11 != Linux. Daher ist es eben nicht trivial einfach alles in den Kernel zu schieben. Sane und Cups gehen den selben Weg, mit FUSE wurde erst vor kurzem etwas vorgestellt um das auch zu ermöglichen, also mal Ball bitte etwas flacher halten.
> Im FOSS Umfeld haben wir keine einzige, die annähernd so gut aussieht wie das Zeug von MS oder Apple.
Willst du einen Screenshot aus Word, der dir zeigt wie furchtbar Schriften unter Windows aussehen können? Abstände zwischen den Buchstaben (innerhalb eines Wortes), dass man Augenkrebs kriegen könnte - wenn MS gutes Schriftlayout beherrscht, dann können die das gut verstecken.
Du wirfst mit gleichermaßen lächerlichen wie schwachsinnigen Schlagworten um dich. Es gibt zwar Toolkits, die nicht so optimal sind, es gibt aber auch bessere. Fonts sind reine Konfigurations-Sache, und die usability vom Xserver finde ich insgesammt Top (Usability ist eh so ein Schwachsinn, da komplett subjektiv). Und was vom Xserver-Design stört dich im täglichen Einsatz so sehr?
Btw.: Zähl mal die Desktop-Umgebungen für den Xserver auf. Mehr als vier wird schwierig, nämlich KDE, Gome, XFce, LXDE. (Fenstermanager gibt es zwar ettliche, aber das sind keine Desktop-Umgebungen)
Der X-Server ist so eine grundlegende Komponente das man überhaupt nichts über seine Usability sagen kann, da er von selbst nicht mit dem Benutzer in Dialog.
> Usability ist eh so ein Schwachsinn, da komplett subjektiv.
Das ist falsch. Usability ("Gebrauchstauglichkeit") ist eine wissenschaftliches Gebiet, und da spielen subjektive Vorlieben keine Rolle.
Falsch. Usability ist subjektiv. Selbst die wissenschaftliche Disziplin fasst hier lediglich Benutzergruppen zusammen um dann vorsichtige Aussagen über diese tätigen zu können.
Für mich ist Usability, mit einem Kommando in der Shell Rechte auf alle Unterverzeichnisse vergeben zu können. Für einen Otto-Normaluser sollte ein gut aufgeräumter Dialog mit klaren Bezeichnungen und Informationen über die durchzuführende Aktion vorhanden sein.
aber da google chrome os plant, ein schnugglies os auf basis für linux können wir uns auf der grafik seite sicher auf was tolles freuen. den google wird unmöglich auf x zurückgreifen sondern etwas neues schreiben. schlieslich soll ihr os in 2s ins internet können.
bye the way, weis jemand wie die graphik unter android gelöst ist ?
Mit dem Framebuffer(-Treiber), den du wahrscheinlich meinst, kann man auf den Grafikspeicher zugreifen. Es geht um das zwischen dieser Schnittstelle und dem Browser.
EGL (Embedded OpenGl) und Java bzw. Dalvik auf dem Framebuffer. Gerade für Embedded-Anwendungen gibt es mehr als genügend funktionierende Lösungen im Linux-Umfeld.
Wer es etwas "konservativer" mag :
Qt und Gtk+ laufen auch problemlos direkt auf einem Framebuffer. Ein prominentes Beispiel dafür ist z.B. der Debian-Installer.
das klingt ja sehr optimistisch. Mein letzter Wissensstand ist, dass ausschließlich GPL Treiber die nötigen Schnittstellen für KMS benutzen können. Also muss nur NVidias Treiber geöffnet werden, oder das Nuveau Projekt einen benutzbaren Treiber ausbringen.
Das kann sich ja dann nur noch um Jahrzehnte handeln...
Na und? Dann wird eben eine BSD-lizensierte Schnittstelle für den binary-only Treiber geschrieben. Die Kommunikation ist dann: (GPL) Kernel (BSD) Schnittstelle (CS) Treiber
Und zack ist wieder alles möglich und auch noch völlig legal. Und wenn die Schnittstelle dann tatsächlich nur die Informationen einfach weiterleitet ist der Overhead auch praktisch Null.
(Ich dachte, NVidia macht das jetzt auch schon so...)
So funktioniert die GPL nicht. Alles was zusammengelinkt wird (egal ob statisch oder dynamisch) wird bei der GPL als eine Einheit betrachtet. Wenn ein Teil einer solchen Einheit unter der GPL steht muss das auch der Rest tun. Deswegen liefert ja auch niemand eine Linux Distribution mit den Nvidia Treibern aus. Das wäre illegal. Zur Zeit vollbringen die User, die den Nvidia Treiber installieren die illegale Handlung (und die scheißen eben da drauf).
Das mit der Kernel Schnittstelle hat einen anderen Sinn: Zumal ein Kernel Modul für einen gewissen kernel kompeliert sein muss, müsste Nvidia für all die 100.000 kernels von jedem patchlevel jeder Distribution ein Kompilat anbieten. Das geht natürlich nicht. Deswegen haben sie irgendwie einen Binärkompatibilitätslayer geschaffen. Dann muss nur dieser neu kompeliert werden und der ladet den Binärtreiber. Meiner Meinung nach sollte der Linux kernel sowas sowieso bieten. Ist ja arg das man alle Module neu kompelieren muss wenn sich garnix an der API geändert hat (wenn ich das richtig verstanden hab).
Von Anonymous Coward am Do, 16. Juli 2009 um 19:44 #
In der GPL steht nirgendwo etwas von "Linken", weder statisch noch dynamisch. In der GPL steht, dass auch ein "abgeleitetes Werk" unter der GPL stehen muss. Und was genau ein "abgeleitetes Werk" sein soll, weiß wohl niemand so richtig.
Doch. Wenn du linkst, verwendest du die Funktionalität und baust damit auf dieser auf: Ableitung. Das ist unstrittig. Ob dies auf Prozesse beschränkt ist, ist dagegen weiterhin strittig.
> Alles was zusammengelinkt wird (egal ob statisch oder dynamisch) wird bei der GPL als eine Einheit betrachtet.
Und was hat das jetzt mit dem Beispiel zu tun? Die BSD-Schnittstelle linkt gegen den Kernel (darf man machen, die GPL erlaubt das [-> BSD schränkt die Freiheiten der GPL nicht ein]). Der CS-Treiber linkt ausschließlich gegen die Schnittstelle (darf man machen, weil BSD [lol]).
Die Aussage, die User vollbrächten eine illegale Handlung ist völliger Schwachsinn. Mit dem GPL Code kann man machen was man will, solange man ihn nicht weitergibt. Deshalb gibt es ja auch die Affero (?) GPL. Damit Code auf Webservern auch offengelegt werden muss, wenn er nicht weiterverteilt wird.
> Zur Zeit vollbringen die User, die den Nvidia Treiber installieren die illegale Handlung (und die scheißen eben da drauf). Wo steht, dass das illegal ist? Ich darf das Kompilat nur nicht weitergeben, weil ich dem Empfänger nicht die vier Freiheiten gewähren kann.
Könnt ihr mir das mal mit setuid erklären? Wo sind solche Attribute gespeichert? Wenn ich startx als normalen Benutzer eingebe, startet X dann als root? Wenn ja, wie läuft das intern ab?
Von Hannes Halberg am Do, 16. Juli 2009 um 16:31 #
Kann man nicht dann gleich auf Wayland umsteigen? X macht doch mit dem Patch nichts anderes mehr als die Funktionen zum Zeichnen von Fenstern den Programmen zur Verfügung zu stellen, oder? Die ganze Hardwareansteuerung läuft ja jetzt im Kernel ab (also für Intel und ATI-Karten).
Gerüchteweise soll es Leute geben, die benutzen/brauchen im lokalen Netz die Netzwerkfähigten von X. Wayland kann dies nicht und SOLL das auch nicht können.
Und wo es X jetzt auch rootless gibt, spricht nur der riesige Codewust gegen Xorg - und ansonsten relativ wenig für Wayland.
NX und die Netzwerktransparenz von X11 sind zwei vollkommen verschiedene Paar Schuhe. NX kann hier bestenfalls im Terminalserverbereich punkten. Bei den restlichen Anforderungen (Graphische Desktops über mehrere Server, Remote Anzeige und Bedienung von einzelnen X11 Clients , etc.) kann man mit NX nichts anfangen.
Von phoronix leser am Do, 16. Juli 2009 um 20:51 #
Ich kann nicht verstehen, warum es keinen großen Distributor (Novell, Red Hat oder Canonical) gibt, der wirklich Ressourcen in die Weiterentwicklung von X steckt - momentan wird dieser Elementare Bestandteil der Linuxdistributionen hauptsächlich von Freiwilligen gepflegt, das nicht Einhalten des Releasetermins ist die Regel, und ich rede hier von Verzögerungen von einem halben Jahr und mehr. Nicht nur das, auch Features werden fallen gelassen und erst später implementiert, MultiPointerX sollte den PLanungen nach schon in Xorg 1.5(vor ca. einem Jahr) auftauchen, momentan sieht es so aus, als könnte es im nächsten Release auftauchen - das kommt wahrscheinlich im Herbst, geplant war gestern. Die Probleme der Rückständigkeit von X hängen zu großen Teilen daran, dass es kein Unternehmen gibt, dass sich darum kümmert. Ich schätze die Arbeit der Entwickler, die das alles in ihrer Freizeit machen sehr hoch, aber die haben nun mal auch andere Dinge zu tun, für die sie Geld bekommen.
Wie wäre es, wenn du dich mal informierst bevor du deine Vermutungen als Wahrheiten ins Netz bläst? Allein RH beschäftigt 8. Sicher mehr wären nie schlecht, nur entbehrt deine "These" wirklich jeder Grundlage.
finde es sehr gut dass das ding nichtmehr als root laufen muss - die gehen meiner meinung nach da den richtigen schritt.
gibt andere mobilgeräte distributionen die da leider eher nen schritt zurückgehen und bei denen dann alles als root läuft (openmoko default image...) sowas finde ich schade.
Nur meine Meinung.
... heißt das im Original.
Why not extend the X server?
Because we for the first time we have a realistic chance of not having to do that. It's entirely possible to incorporate the buffer exchange and update models the Wayland is built on into X. However, we have an option here of pushing X out of the hotpath between clients and the hardware and making it a compatibility option. I'm not deluding myself that any general purpose desktop Linux distribution will stop shipping X as we know it or as a Wayland client anytime soon. Nor should they, there will still be X applications to run and people expect that from a Linux desktop. What's different now is that a lot of infrastructure has moved from the X server into the kernel (memory management, command scheduling, mode setting) or libraries (cairo, pixman, freetype, fontconfig, pango etc) and there is very little left that has to happen in a central server process.
Was tun? Eine neue Spezifikation, ein neuer Server. Dazu sollten Novell, Ubuntu, KDE, GNOME, blah mal Entwickler abstellen, nicht für so einen frickelscheiss wie Banshee oder Restricted-Manager, davon würden alle profitieren:
- X11 ist von '87 -> 22 Jahre, so alt werden Hunde nur selten, der gehört eingeschläfert
- Linux/BSD/blah stehen im Vergleich zu anderen Systemen, die neuere Grafischesubssysteme bereitstellen besser da
- ...
Der neue Server sollte nur aus dem Kern bestehen, der ganze Rest, Rendering, Compositing, blah, sollte vom Kern komplett abgespalten werden, damit wir nicht erneut in so ein Problem hineinlaufen. X.Org stellt Dinge bereit, die in den 80ern hip waren, heute aber niemand mehr braucht, trotzdem entfenrt keiner diese Codezombies. Mit einer Generalmodularisierung (nicht nur die libs, protos, usw, sondern Rendering API, Server, usw) könnte man sowas bei kommen, da einzelne Module weniger Code hätte, damit einfacher wart-, entfern-, oder ersetzbar wären.
wenn du für erneuerung bist dann biste auch für abschaffung von ftp http snmp dns als älter als 15 jahre und das werden hunde kaum, und es sollte nur hunde in der IT geben
Menschen werden älter aber dürfen als vergleich nicht herhalten ebenso wie schildkröten
Also nur weil was alt ist muss es nicht schlecht sein
fridy
Und X11 ist leider alt und zugleich schlecht. Die Nezuwerktransparent ist cool und sollte in einer neuen Lösung erhalten bleiben. Dazu gehören auf jeden Fall virtuelle Kanäle in einer Verbindung für Sound, Drucken, USB, etc.; eben so wie Citrix ICA.
Absolut! Es ist kein wirklich guten Protokoll.
würdest Du anonymous FTP auch mit SSH ersetzen? Das ist der wichtigste Teil des Protokolls.
Wozu willst Du die Verschlüsselung machen? Weil Fileserver jetzt alle zig CPUs haben, oder wie? Ich finde das ist einfach Verschwendung für öffentliche Downloads.
Warum willst Du ein Caching durch Proxies gleich ganz unmöglich machen? Jetzt kann eine Firma transparent über einen FTP-Proxy dafür sorgen, dass nicht 10 Leute jeder einzeln sich eine Datei holen, sondern nur der erste, und dann kriegen es alle aus dem Cache. Das ist für das Internet sehr viel verträglicher.
Nur weil man mit fish:/ auch Dateien kopieren kann, heisst das nicht, dass es gleich die richtige für alle und immer ist.
Eines der ältesten Formate ist übrigends SMTP (Email), auch HTTP ist nicht ganz so jung, daher finde ich Alter schadet Protokollen nicht. Es hat einen Wert an sich, wenn ein Protokoll von vielen verstanden ist.
Und was X11 angeht, so gibt es eindeutig Nichts besseres. Seit die X-Server auch direkt VNC können, fällt mir auf der Ebene der Netzwerkfähigkeit und Transparenz Nichts ein, was auch nur fehlen könnte, allenfalls würde ich gerne die X-Verbindung von Prozessen suspenden und umziehen können.
Und sonst, was da so geleistet wird, im XOrg-Land ist zuletzt wahnsinnig schnell und gut geworden. Tastatur und Maus kann man jetzt ausserhalb erledigen lassen. Speichermanagement der Grafikkarte übernahm der Kernel, und auch das Modesetting, so dass XOrg endlich nicht mehr so viele Sachen enthält und sich auf X11 konzentrieren kann.
Wenn Intel mit seiner XOrg-Arbeit fertig ist, und viel fehlt nicht mehr, hat Linux den besten Grafikstack bekommen - und das innerhalb weniger Jahre, sehr sehr beeindruckende Arbeit.
Gruss,
Kay
und Du scheinst Dich ja auszukennen
dann hilf mir doch bitte bei der Konfiguration
Ich möchte meine Graka nur auf 120 Hz und 1280x720 stellen
die Karte ist dafür ausgerichtet
siehe Thread www.pro-linux.de/forum
Schlechtes Beispiel - die Mängel in SMTP sind mitverantwortlich für unser heutiges SPAM-Aufkommen (nicht umsonst steht das 'S' ja für "Simple").
alt!=schlecht
neu!=gut
Also, nur weil etwas alt ist, muss es nicht schlecht sein.
Nicht alles neue ist auch gut.
Die CPU Architekturen auf denen wir heute arbeiten sind vom Prinzip her gut und gerne 40 Jahre alt.
Das Rad wurde vor ein paar tausend Jahren erfunden. Bisher hatte niemand eine bessere Idee im Bereich "Kutschen, Autos, Moped usw."
Ein Relikt aus der Steinzeit sind "Mauern", die ab und an schon sinnvoll sind ....
Natürlich, wurden die oben aufgezählten Dinge optimiert, erweiter usw. Die Basis, das Grundprinzip ist alt.
Surück su Ihx. Im Prinzip bin ich bei dir, X wurde für Großrechner der 80er Jahre designed. Aufm Desktop liegen die Schwerpunkte der Anwender-Anforderungen anders. Nicht umsonst, ist das GUI System in Windows zum Teil im Kern. Das ist bestimmt nicht die beste Lösung, aber dem Anwenderwunsch deutlich näher als X.
Fakt ist, dass die Nutzer schon genug von den Nebeneffekten der jüngsten Änderungen am Linux-Grafikstack genervt sind (z. B. von den Regressionen im Intel-Treiber usw.). Und jetzt willst Du *alles* wegschmeißen, damit für die nächsten 5 Jahre auch ja niemand in der Lage ist, Linux produktiv einzusetzen? Aua. Wenn Du wenigstens irgendeine konkrete Vision hättest, irgend etwas, das mit der aktuellen Architektur nicht zu bewerkstellen ist, dann könnte man ja drüber jeden. So ist es nur dämliches Gelaber.
Oder werden bei in der Stadt auch erst die alten Brücken abgerissen und dann 2 Jahre lang eine neue gebaut anstatt die neue zu bauen solange die alte noch geht?
> Oder werden bei in der Stadt auch erst die alten Brücken abgerissen und dann 2 Jahre lang eine neue gebaut
Ich weiss ja nicht wieviel Brückenbau Du schon so gesehen hast, aber ich würd mal sagen in 80% der Fälle ist das so.
/offtopic aus
als Laie wuesste ich gerne ob das wirklich so gemacht wird? Faend ich erschreckend...
stephan@stephan-desktop:~$ sudo cat /proc/`pgrep X | head -n 1`/maps | grep "/dev/mem"
b76a3000-b76e3000 rw-s 000c0000 00:0f 730 /dev/mem
Ich habe vor 100 Jahren schon gesagt das alles was mit Grafikausgabe unter Unix/Linux zu tun hat ein Grauß ist. Das geht mit dem X-Server design los, über lahmarschige Toolkits mit schlecht lesbaren Widgets, häßlichen Fonts bis hin zur Usability. Aber anstatt diese völlig grundlegenden Issues erstmal anzugehen wird die 1000ste Desktop Umgebung programmiert die von besagten Punkten genauso betroffen ist wie 999 andere. Und dann wundert man sich, dass Linux auf dem Desktop nicht ankommt; die Lösung ist einfach uncool
Konfigurationsproblem.
Deine Antwort zeigt aber prima, dass du absolut keine Ahnung hast.
Und, Christopher..., das du hier dieses komische Zekton Font als Beispiel anführst kann doch wohl nicht dein Ernst sein, oder? Soll ich die als Bildschirmschriftart nehmen? Oder Dokumente damit erzeugen? Das ist eine billig-Schriftart wie es sie hunderttausendfach im Web gibt, und keine professionell gesetzte Type mit der man was sinnvolles anfangen kann.
http://www.pro-linux.de/news/2006/9206.html
http://www.pro-linux.de/news/2009/13960.html
Wenn man halbwegs ordentlich konfiguriert, dann sieht ein Linux mit RGB-Subpixelrendering und DejaVu viel besser aus, als Windows.
Bei mir in der Arbeit staunen übrigens auch die Graphiker (na, was werden die wohl verwenden) über das hübsche Schriftbild.
Wenn sich niemand hinsetzt und eine "schöne" Schrift entwirft, dann ist das natürlich ein konzeptionelles Problem der X-Architektur... ne ist klar nä!
Zudem ist X11 != Linux. Daher ist es eben nicht trivial einfach alles in den Kernel zu schieben. Sane und Cups gehen den selben Weg, mit FUSE wurde erst vor kurzem etwas vorgestellt um das auch zu ermöglichen, also mal Ball bitte etwas flacher halten.
Willst du einen Screenshot aus Word, der dir zeigt wie furchtbar Schriften unter Windows aussehen können? Abstände zwischen den Buchstaben (innerhalb eines Wortes), dass man Augenkrebs kriegen könnte - wenn MS gutes Schriftlayout beherrscht, dann können die das gut verstecken.
(WinXP, Office 2007, Standard-Systemschriften).
Es gibt zwar Toolkits, die nicht so optimal sind, es gibt aber auch bessere. Fonts sind reine Konfigurations-Sache, und die usability vom Xserver finde ich insgesammt Top (Usability ist eh so ein Schwachsinn, da komplett subjektiv). Und was vom Xserver-Design stört dich im täglichen Einsatz so sehr?
Btw.: Zähl mal die Desktop-Umgebungen für den Xserver auf. Mehr als vier wird schwierig, nämlich KDE, Gome, XFce, LXDE. (Fenstermanager gibt es zwar ettliche, aber das sind keine Desktop-Umgebungen)
Der X-Server ist so eine grundlegende Komponente das man überhaupt nichts über seine Usability sagen kann, da er von selbst nicht mit dem Benutzer in Dialog.
> Usability ist eh so ein Schwachsinn, da komplett subjektiv.
Das ist falsch. Usability ("Gebrauchstauglichkeit") ist eine wissenschaftliches Gebiet, und da spielen subjektive Vorlieben keine Rolle.
Für mich ist Usability, mit einem Kommando in der Shell Rechte auf alle Unterverzeichnisse vergeben zu können. Für einen Otto-Normaluser sollte ein gut aufgeräumter Dialog mit klaren Bezeichnungen und Informationen über die durchzuführende Aktion vorhanden sein.
Dann geh doch mal los und lasse nicht IT-Spezis mit Linux arbeiten. Diese Argumente hört man aus vielen Mündern.
Zum Thema eingeschossen sein, solltest du mal einen Spiegel aufsuchen. Bisher kam nur heiße Luft.
aber da google chrome os plant, ein schnugglies os auf basis für linux können wir uns auf der grafik seite sicher auf was tolles freuen. den google wird unmöglich auf x zurückgreifen sondern etwas neues schreiben. schlieslich soll ihr os in 2s ins internet können.
bye the way, weis jemand wie die graphik unter android gelöst ist ?
EGL (Embedded OpenGl) und Java bzw. Dalvik auf dem Framebuffer. Gerade für Embedded-Anwendungen gibt es mehr als genügend funktionierende Lösungen im Linux-Umfeld.
Wer es etwas "konservativer" mag :
Qt und Gtk+ laufen auch problemlos direkt auf einem Framebuffer. Ein prominentes Beispiel dafür ist z.B. der Debian-Installer.
Also muss nur NVidias Treiber geöffnet werden, oder das Nuveau Projekt einen benutzbaren Treiber ausbringen.
Das kann sich ja dann nur noch um Jahrzehnte handeln...
Einfach weiter im Takt: legal, illegal, scheißegal...
(GPL) Kernel (BSD) Schnittstelle (CS) Treiber
Und zack ist wieder alles möglich und auch noch völlig legal.
Und wenn die Schnittstelle dann tatsächlich nur die Informationen einfach weiterleitet ist der Overhead auch praktisch Null.
(Ich dachte, NVidia macht das jetzt auch schon so...)
Das mit der Kernel Schnittstelle hat einen anderen Sinn: Zumal ein Kernel Modul für einen gewissen kernel kompeliert sein muss, müsste Nvidia für all die 100.000 kernels von jedem patchlevel jeder Distribution ein Kompilat anbieten. Das geht natürlich nicht. Deswegen haben sie irgendwie einen Binärkompatibilitätslayer geschaffen. Dann muss nur dieser neu kompeliert werden und der ladet den Binärtreiber. Meiner Meinung nach sollte der Linux kernel sowas sowieso bieten. Ist ja arg das man alle Module neu kompelieren muss wenn sich garnix an der API geändert hat (wenn ich das richtig verstanden hab).
Und was hat das jetzt mit dem Beispiel zu tun?
Die BSD-Schnittstelle linkt gegen den Kernel (darf man machen, die GPL erlaubt das [-> BSD schränkt die Freiheiten der GPL nicht ein]).
Der CS-Treiber linkt ausschließlich gegen die Schnittstelle (darf man machen, weil BSD [lol]).
Ich kann die Lizenz also frei wählen.
Wo steht, dass das illegal ist? Ich darf das Kompilat nur nicht weitergeben, weil ich dem Empfänger nicht die vier Freiheiten gewähren kann.
Danke schonmal.
Wayland kann dies nicht und SOLL das auch nicht können.
Und wo es X jetzt auch rootless gibt, spricht nur der riesige Codewust gegen Xorg - und ansonsten relativ wenig für Wayland.
NX und die Netzwerktransparenz von X11 sind zwei vollkommen verschiedene Paar Schuhe. NX kann hier bestenfalls im Terminalserverbereich punkten. Bei den restlichen Anforderungen (Graphische Desktops über mehrere Server, Remote Anzeige und Bedienung von einzelnen X11 Clients , etc.) kann man mit NX nichts anfangen.
Die Probleme der Rückständigkeit von X hängen zu großen Teilen daran, dass es kein Unternehmen gibt, dass sich darum kümmert. Ich schätze die Arbeit der Entwickler, die das alles in ihrer Freizeit machen sehr hoch, aber die haben nun mal auch andere Dinge zu tun, für die sie Geld bekommen.
gibt andere mobilgeräte distributionen die da leider eher nen schritt zurückgehen und bei denen dann alles als root läuft (openmoko default image...) sowas finde ich schade.
Ist sehr begrüßenswert wenn X als User laufen kann.