Na zum Beispiel die Tatsache, dass ein Fehler in so ziemlich jedem Userspace Programm dazu führen kann, dass XVideo (oder jede andere Video Extension) abstürzt, gefolgt von einem kompletten X-Server Absturz, gefolgt von der prompten Beendigung ALLER Programme, die etwas mit dem X-Server zu tun haben, z.B. Evolution, OpenOffice, Firefox, oder was auch immer. Ergebnis: im Zweifelsfall kompletter Arbeitsverlust. So etwas leisten sich Windows oder OS X nicht, und das aus guten Grund, denn hier ist Produktivität und Stabilität im Vordergrund und nicht die möglichst schnelle Adaption von möglichst vielen tollen neuen GPU Features auf einer schönen alten Architektur aus den 80ern, die immer noch die Grundlage von XOrg bildet.
Mein letzter X-Absturz ist eine Woche her. Und es kommt alle 1 bis 2 Monate vor. Das war schon bei der letzten Distri so und ich befürchte es wird auch bei der nächsten passieren. Allerdings gelingen mir diese Abstürze nur mit Spielen. Mit Anwendungen kam es noch nicht vor.
Das ändert natürlich nichts daran dass dieses Absturzverhalten vollkommen schlecht ist. Wenn ein Programm abstürzt dann hat das die darunter liegende Plattform, in dem Fall den X-Server, nicht in Mitleidenschaft zu ziehen. Wir sind doch schon lange raus aus der Steinzeit. Warum nicht bei der GUI?
> Allerdings gelingen mir diese Abstürze nur mit Spielen. Das liegt in diesem Fall vermutlich weder an den Spielen noch am X-Server. Ich denke, Du kannst Dich bei NVidia dafür bedanken. Ich habe mit dem freien nv-Treiber seit Jahren keinen Absturz des X-Servers erlebt. Mit dem nvidia-Treiber hingegen schon. NVidia lebt eben noch in der "Steinzeit" der proprietären Treiber. Zu ATI kann ich keine Erfahrungen beisteuern.
Der "freie" nv-Treiber ist genauso proprietär. Niemand außer NVIDIA-Mitarbeitern kann diesen pflegen.
Dass du mit nv noch keinen Absturz erlebt hast, könnte daran liegen, dass für den Absturz Funktionen verantwortlich waren, über die nv gar nicht verfügt.
Von Kevin Krammer am Di, 1. September 2009 um 20:27 #
Ergebnis: im Zweifelsfall kompletter Arbeitsverlust.
Das liegt aber vermutlich eher daran, dass der Verlußt der Verbindung zum X-Server den Applikationsentwicklern nicht gut genug signalisiert wird. D.h. ich zum Beispiel wüsste nicht, auf welches Application Signal ich verbinden müsste, bzw. welcher Callback zu implementieren wäre.
Sonst könnte man einfach den Status speichern, so wie das ja auch bei anderen Anlässen, z.B. Fenster schließen, gemacht wird.
Von Jörg Zweier am Di, 1. September 2009 um 21:03 #
Erinnert mich auch an die ganzen Anti-SQL-Injection-Proxies. Reine Zeit- und CPU-Verschwendung. Einfach sichere Programme schreiben und schon kann man die komplett weglassen.
Von Anonymous Coward am Di, 1. September 2009 um 22:17 #
Blödsinn, die Verbindung zum X-Server kann jederzeit getrennt werden. X ist netzwerktransparent, da muss nur mal die Raumpflegerin übers Netzwerkkabel stolpern.
"dass ein Fehler in so ziemlich jedem Userspace Programm dazu führen kann, dass XVideo (oder jede andere Video Extension) abstürzt"
Das ist keine "Tatsache" in eigentlichem Sinne. Bitte ganz konkret: Welche Userspace-Programme oder Grafiktreiber verursachen einen derartigen Xorg-Komplettabsturz? Sehr wahrscheinlich hast Du ja zumindest eine entsprechende Erfahrung selbst machen müssen.
Von Jörg Zweier am Di, 1. September 2009 um 23:03 #
Der MPlayer-Bug ist mittlerweile geschlossen. Weiß aber nicht, ob die einen Workaround eingebaut haben, damit X.org nicht abstürzt.
Bei Wine ist X.org beim Spiel 0.A.D. abgestürzt. Den Bug habe ich nicht gemeldet, weil ich mich nicht noch bei einem anderen Dienst anmelden möchte, nur um mal eben einen Bug zu melden. Bei anderen Projekten bin ich ins IRC gegangen, wo dann allerdings die Bugs ignoriert wurden. Motivierend ist das jedenfalls nicht. Ich weiß, dass es nicht im Sinne von Open Source ist, jedoch wird der Bug sicherlich nicht nur bei diesem Spiel auftreten. Zumal das Spiel sehr bekannt ist, dürften sich schnell Wine-Entwickler finden, die mehr Zeit haben, sich damit auseinanderzusetzen.
Es kann ja aber nicht sein, dass ein kaputtes Anwenderprogramm das gesamte grafische Subsystem abschießt - sowas ist mir weder bei Mac noch bei Windows jemals passiert.
Oh bei Windows schon. Aber das ist schon eine ganze Weile her. Ansonsten ist das heute wirklich ein Unding. Und es ist wirklich so, dass über Wine genutzte Spiele wesentlich mehr Abtürze verursachen als beispielsweise ein natives Spiel. Aber auch da habe ich Komplettabstürze. Ich ergoogle mal dieses Wayland. Ich kenne das garnicht.
Mittlerweile habe ich das leider auch erfahren müssen. Ich hatte noch gestern abend versucht, das Spiel Astromenace (von Packman) unter openSuse 11.1 zu starten. Einmal hat es kurz geblitzt und ich fand mich vor dem Displaymanager wieder (Radeon-Treiber).
0 A.D. in WINE? Jetzt wirds kurios, das kannst du ja auch nativ kompilieren...achja, der Installer den da einer im Forum gebastelt hat, ich erinnere mich...es gibt nicht umsonst noch kein einziges Binär-Paket von 0 A.D..
Von Jörg Zweier am Mi, 2. September 2009 um 17:00 #
Ja, aber Kompilieren ist zeitaufwändig und der Code ist noch nicht komplett GCC konform gewesen. Solange es keine Pakete im AUR gibt, bevorzuge ich grundsätzlich Wine.
Von Jörg Zweier am Di, 1. September 2009 um 21:00 #
Selbiges habe ich auch schon häufiger beobachtet. Besonders nervig, wenn man MPlayer aus Versehen mit dem falschen Video-Output (-vo ...) als Root startet. Das hat schon des Öfteren meinen X-Server komplett zum Absturz gebracht.
Mit dem Framebuffer sieht es leider auch nicht besser aus, sollten daher m.E. komplett aus dem Kernel raus.
> Selbiges habe ich auch schon häufiger beobachtet. Besonders nervig, wenn man MPlayer aus Versehen mit dem falschen Video-Output > (-vo ...) als Root startet.
Wer MPlayer oder andere Userprogramme als 'root' startet ist es selber schuld. Es gibt nur ganz wenig Programme die wirklich auf den User 'root' angewiesen sind.
Außerdem werden hier Äpfel mit Birnen verglichen, wenn wieder das 'Windows ist besser' Argument kommt: der Xserver basiert auf einem Netzwerkprotokoll und kann daher jede einzelne Applikationen die auf ihm installiert ist jedem Xclient im Netzwerk zur Verfügung stellen. Windows hat diese Funktionalität nicht. Einen Workaround gibt es: Windows Terminal Server und Citrix XenApp ehemals Presentation Server. Ist aber teuer und wesentlich komplexer in der Administration.
> der Xserver basiert auf einem Netzwerkprotokoll und kann daher jede einzelne Applikationen die auf ihm installiert ist jedem Xclient im Netzwerk zur Verfügung stellen.
Hast du hier nicht was verwechselt? Die Anwendungen sind die X-Clients. Für den "modernen" Desktop interessante X-Erweiterungen (GLX, X-Video) sind AFAIK nicht netzwerkfähig.
Von Jörg Zweier am Di, 1. September 2009 um 22:49 #
> Wer MPlayer oder andere Userprogramme als 'root' startet ist es selber schuld. Warum? Programme dürfen also voll verbuggt sein. Nicht der Entwickler ist Schuld, sondern der Anwender, weil er dem Programm zu viele Priviliegien gibt (mehr besagt root nicht).
Wie du schon siehst, hinkt dein Vergleich bis ins Unermessliche.
> Außerdem werden hier Äpfel mit Birnen verglichen, wenn wieder das 'Windows ist besser' Argument kommt: der Xserver basiert auf einem Netzwerkprotokoll und kann daher jede einzelne Applikationen die auf ihm installiert ist jedem Xclient im Netzwerk zur Verfügung stellen. Windows hat diese Funktionalität nicht. Genau deshalb gefällt mir X.org auch nicht. Es ist unnötig überladen mit Funktionen, die nur sehr wenige der Anwender wirklich benötigen.
Netzwerktransparenz gehört zwischen Toolkit und Anzeige. Am besten durch eine Art "Proxy" schleifen, der das Fenster als Netzwerkdienst anbietet. Das wäre die ultimative Lösung. In einem Grafikserver hat Netzwerktransparenz absolut gar nichts zu suchen, außer man löst das so wie Plan9, wo man kinderleicht Soundkarten von einem anderen Rechner über Netzwerk lokal verwenden kann. Unter Linux ist dieses geniale Konzept leider nicht umsetzbar.
Von Jörg Zweier am Mi, 2. September 2009 um 17:04 #
In der Schule lernen wir leider so etwas nicht.
PS: Was müssen wir tun, oh Meister, dass du uns dein Antlitz wieder voller Gnade zuwendest? Anstatt dich über andere lächerlich zu machen, wäre es nett, wenn du meine Aussage wenigstens richtig stellen würdest. Ich sehe nämlich keinen Fehler.
Deine aussage ist echt der beweiß dafür, das die Diskusion nicht sachlich geführt wird. Vidix, directfb, fbdev2 etc greifen direkt aus dem mplayer auf die graka zu. Sollte dabei ein x laufen, ist es doch echt kein Problem von xorg, wenn alles zusammenstürzt. vo=xv in die ~/.mplayer/config und du hast ruh. Über wine muß ich ja nichts sagen oder?
Von Anonymous Coward am Di, 1. September 2009 um 22:22 #
Ach, wieso nicht? Es sollte nicht möglich sein, X zum Absturz zu bringen, egal ob mit wine oder sonstwie. Denn was wine kann, das kann jedes andere Programm auch.
Von Jörg Zweier am Di, 1. September 2009 um 22:52 #
++
Ich kann auch nie nachvollziehen, warum immer alles schön geredet werden muss. X.org ist nun mal buggy und das wird auch immer so bleiben, solange es nicht von Grund auf neu designed wird.
Und das Verlagern von Code in den Kernel ändert genau was, außer daß statt "nur" des X-Servers und der darauf zugreifenden Apps die gesamte Maschine crasht?
Ja...genau...unter Windows reißt ein einziges 'Explorer' (Datei-Browser) Fenster gleich die halbe Desktop-Umgebung mit wenn es Hobs geht und Programme erscheinen nicht mehr im SysTray oder in der Taskbar. Und jetzt erzähl mal wie das ist unter Windows, wenn dir die grafische Oberfläche dort einfriert, wechselst du dann mal so locker auf tty/oder drückst Strg+Druck+K und startest die neu? Und es gibt genug Windows-Programme die das gesamte System mit nehmen wenn sie abstürzen.
Und das alle Programme mit dem XServer beendet werden ist logisch, wenn man mal versteht das jeder Prozess einen Mutter-Prozess hat (okey, bis auf init...) von dem er abhängt.
> Und jetzt erzähl mal wie das ist unter Windows, wenn dir die grafische Oberfläche dort einfriert, wechselst du dann mal so locker auf tty/oder drückst Strg+Druck+K und startest die neu?
Das hat bei mir unter Linux auch noch nie funktioniert, wenn der X-Server eingefroren ist. Da ist die Tastatur einfach tot. Nicht mal auf Ctrl-SysRq-B reagiert der Rechner dann noch, obwohl Magic SysRq aktiviert ist.
Das hat dann aber nichts mehr mit dem XServer zu tun, wenn der Kernel nicht mehr reagiert. Wenn nur der XServer einfriert, reagiert der Kernel sehr wohl noch auf seine Tastatur-Kommandos.
Es muss wohl 10 jahre her sein, dass du das letzte mal Windows benutzt hast. Selbst wenn der Explorer abstürzt oder einfriert laufen alle anderen Programme weitere - dann rufst du eben mit ctrl+alt+del den Task Manager auf und startest den explorer neu/schießt den eingefrorenen Explorer ab. Kein anderes Programm ist davon betroffen. Ob ich den XServer neu starte oder den Rechner läuft in der regel aufs selbe hinaus. Welches Windows Programm kann denn das ganze System mit runterreißen?
Korrekt. Seit Windows NT passiert so etwas wirklich nicht mehr. Dass die ganze grafische Oberfläche abstürzt ist eine Kuriosität, die ich nur von X kenne. Hier wird auch wieder eine große Schwäche der Open Source Community offenkundig. Man nimmt wieder alles persönlich, so kann sich ja nix verbessern. Aussage: Der X Server kann von Programmen in den Abgrund gerissn werden Antwort 1.: Ist mir schon lange nicht mehr passiert. (na und? mir schon) Antwort 2.: Das ist die Schuld von X, darfst du halt nicht benutzen... (huch, warum können Programme dann nur unter Linux so wunderbar alles mitreißen, wenn das System es nicht verhindern kann? Der Fehler liegt a) im Kernel, das die Programme nicht korrekt voneinander abschottet b) in X. aber definitiv nicht im Userprogramm. (Programme _haben_ Bugs, und davon soll das System auch ausgehen)
Welches Programm legt denn keine Sicherheitskopien an? Zumindest OO.o und Firefox stellen abgebrochene Sessions bzw. Dateien wieder her, wenn man X neu startet. Ich seh da keinen signifikanten Verlust. Ansonsten ist das ein Fehler im Programm nicht in X - schließlich kann auch der Strom ausfallen oder jemand versehentlich über den Netzwerkstecker stolpern.
gehe in dich und denk noch mal nach :-). Bei einem absturz unter windows darfst du den ganzen rechner neustarten. Das hat sich bis heute auf keinen fall geändert. Bei einem x absturz uß du dich lediglich nochmal einloggen. BTW. Meine erfahrungen zeigen, das oft fehlerhafte graka treiber für die Probleme verantwortlich sind. fglrx ist so ein kandidat dem ich alles mögliche an den hals wünsche.
Da kenn ich aber anderes. Das neu einloggen funktioniert bei mir nur in 20%, in 80% reagiert die Maschiene gar nicht mehr.(Was zum teil daran liegt, dass das System nicht abstürzt, sondern nur so unglaublic langsam wird... aber auch das ist ein Fehler im System) Windows nervt, aber es ist definitiv stabiler, bei einem Absturz unter Windows darf man den ganzen Rechner neustarten, aber ich glaube das ist mir seit XP noch nie passiert(mit Ausnahme von Abstürzen auf Grund von Hardwareschäden)
Das war schon bei der letzten Distri so und ich befürchte es wird auch bei der nächsten passieren. Allerdings gelingen mir diese Abstürze nur mit Spielen. Mit Anwendungen kam es noch nicht vor.
Das ändert natürlich nichts daran dass dieses Absturzverhalten vollkommen schlecht ist. Wenn ein Programm abstürzt dann hat das die darunter liegende Plattform, in dem Fall den X-Server, nicht in Mitleidenschaft zu ziehen. Wir sind doch schon lange raus aus der Steinzeit. Warum nicht bei der GUI?
Das liegt in diesem Fall vermutlich weder an den Spielen noch am X-Server. Ich denke, Du kannst Dich bei NVidia dafür bedanken.
Ich habe mit dem freien nv-Treiber seit Jahren keinen Absturz des X-Servers erlebt. Mit dem nvidia-Treiber hingegen schon.
NVidia lebt eben noch in der "Steinzeit" der proprietären Treiber.
Zu ATI kann ich keine Erfahrungen beisteuern.
Dass du mit nv noch keinen Absturz erlebt hast, könnte daran liegen, dass für den Absturz Funktionen verantwortlich waren, über die nv gar nicht verfügt.
Das liegt aber vermutlich eher daran, dass der Verlußt der Verbindung zum X-Server den Applikationsentwicklern nicht gut genug signalisiert wird.
D.h. ich zum Beispiel wüsste nicht, auf welches Application Signal ich verbinden müsste, bzw. welcher Callback zu implementieren wäre.
Sonst könnte man einfach den Status speichern, so wie das ja auch bei anderen Anlässen, z.B. Fenster schließen, gemacht wird.
Das ist keine "Tatsache" in eigentlichem Sinne.
Bitte ganz konkret: Welche Userspace-Programme oder Grafiktreiber verursachen einen derartigen Xorg-Komplettabsturz?
Sehr wahrscheinlich hast Du ja zumindest eine entsprechende Erfahrung selbst machen müssen.
Bei Wine ist X.org beim Spiel 0.A.D. abgestürzt. Den Bug habe ich nicht gemeldet, weil ich mich nicht noch bei einem anderen Dienst anmelden möchte, nur um mal eben einen Bug zu melden. Bei anderen Projekten bin ich ins IRC gegangen, wo dann allerdings die Bugs ignoriert wurden. Motivierend ist das jedenfalls nicht. Ich weiß, dass es nicht im Sinne von Open Source ist, jedoch wird der Bug sicherlich nicht nur bei diesem Spiel auftreten. Zumal das Spiel sehr bekannt ist, dürften sich schnell Wine-Entwickler finden, die mehr Zeit haben, sich damit auseinanderzusetzen.
Ich ergoogle mal dieses Wayland.
Ich hatte noch gestern abend versucht, das Spiel Astromenace (von Packman) unter openSuse 11.1 zu starten. Einmal hat es kurz geblitzt und ich fand mich vor dem Displaymanager wieder (Radeon-Treiber).
Mit dem Framebuffer sieht es leider auch nicht besser aus, sollten daher m.E. komplett aus dem Kernel raus.
> (-vo ...) als Root startet.
Wer MPlayer oder andere Userprogramme als 'root' startet ist es selber schuld. Es gibt nur ganz wenig Programme die wirklich auf den User 'root' angewiesen sind.
Außerdem werden hier Äpfel mit Birnen verglichen, wenn wieder das 'Windows ist besser' Argument kommt: der Xserver basiert auf einem Netzwerkprotokoll und kann daher jede einzelne Applikationen die auf ihm installiert ist jedem Xclient im Netzwerk zur Verfügung stellen. Windows hat diese Funktionalität nicht. Einen Workaround gibt es: Windows Terminal Server und Citrix XenApp ehemals Presentation Server. Ist aber teuer und wesentlich komplexer in der Administration.
Hast du hier nicht was verwechselt? Die Anwendungen sind die X-Clients. Für den "modernen" Desktop interessante X-Erweiterungen (GLX, X-Video) sind AFAIK nicht netzwerkfähig.
Warum? Programme dürfen also voll verbuggt sein. Nicht der Entwickler ist Schuld, sondern der Anwender, weil er dem Programm zu viele Priviliegien gibt (mehr besagt root nicht).
Wie du schon siehst, hinkt dein Vergleich bis ins Unermessliche.
> Außerdem werden hier Äpfel mit Birnen verglichen, wenn wieder das 'Windows ist besser' Argument kommt: der Xserver basiert auf einem Netzwerkprotokoll und kann daher jede einzelne Applikationen die auf ihm installiert ist jedem Xclient im Netzwerk zur Verfügung stellen. Windows hat diese Funktionalität nicht.
Genau deshalb gefällt mir X.org auch nicht. Es ist unnötig überladen mit Funktionen, die nur sehr wenige der Anwender wirklich benötigen.
Netzwerktransparenz gehört zwischen Toolkit und Anzeige. Am besten durch eine Art "Proxy" schleifen, der das Fenster als Netzwerkdienst anbietet. Das wäre die ultimative Lösung. In einem Grafikserver hat Netzwerktransparenz absolut gar nichts zu suchen, außer man löst das so wie Plan9, wo man kinderleicht Soundkarten von einem anderen Rechner über Netzwerk lokal verwenden kann. Unter Linux ist dieses geniale Konzept leider nicht umsetzbar.
zurück auf die Schulbank...
PS: Was müssen wir tun, oh Meister, dass du uns dein Antlitz wieder voller Gnade zuwendest? Anstatt dich über andere lächerlich zu machen, wäre es nett, wenn du meine Aussage wenigstens richtig stellen würdest. Ich sehe nämlich keinen Fehler.
Vidix, directfb, fbdev2 etc greifen direkt aus dem mplayer auf die graka zu.
Sollte dabei ein x laufen, ist es doch echt kein Problem von xorg, wenn alles zusammenstürzt.
vo=xv in die ~/.mplayer/config und du hast ruh.
Über wine muß ich ja nichts sagen oder?
Ich kann auch nie nachvollziehen, warum immer alles schön geredet werden muss. X.org ist nun mal buggy und das wird auch immer so bleiben, solange es nicht von Grund auf neu designed wird.
Und das alle Programme mit dem XServer beendet werden ist logisch, wenn man mal versteht das jeder Prozess einen Mutter-Prozess hat (okey, bis auf init...) von dem er abhängt.
Das hat bei mir unter Linux auch noch nie funktioniert, wenn der X-Server eingefroren ist. Da ist die Tastatur einfach tot. Nicht mal auf Ctrl-SysRq-B reagiert der Rechner dann noch, obwohl Magic SysRq aktiviert ist.
Selbst wenn der Explorer abstürzt oder einfriert laufen alle anderen Programme weitere - dann rufst du eben mit ctrl+alt+del den Task Manager auf und startest den explorer neu/schießt den eingefrorenen Explorer ab. Kein anderes Programm ist davon betroffen.
Ob ich den XServer neu starte oder den Rechner läuft in der regel aufs selbe hinaus.
Welches Windows Programm kann denn das ganze System mit runterreißen?
Seit Windows NT passiert so etwas wirklich nicht mehr. Dass die ganze grafische Oberfläche abstürzt ist eine Kuriosität, die ich nur von X kenne.
Hier wird auch wieder eine große Schwäche der Open Source Community offenkundig. Man nimmt wieder alles persönlich, so kann sich ja nix verbessern.
Aussage: Der X Server kann von Programmen in den Abgrund gerissn werden
Antwort 1.: Ist mir schon lange nicht mehr passiert. (na und? mir schon)
Antwort 2.: Das ist die Schuld von X, darfst du halt nicht benutzen... (huch, warum können Programme dann nur unter Linux so wunderbar alles mitreißen, wenn das System es nicht verhindern kann? Der Fehler liegt a) im Kernel, das die Programme nicht korrekt voneinander abschottet b) in X. aber definitiv nicht im Userprogramm. (Programme _haben_ Bugs, und davon soll das System auch ausgehen)
Bei einem absturz unter windows darfst du den ganzen rechner neustarten.
Das hat sich bis heute auf keinen fall geändert.
Bei einem x absturz uß du dich lediglich nochmal einloggen.
BTW. Meine erfahrungen zeigen, das oft fehlerhafte graka treiber für die Probleme verantwortlich sind. fglrx ist so ein kandidat dem ich alles mögliche an den hals wünsche.
Das neu einloggen funktioniert bei mir nur in 20%, in 80% reagiert die Maschiene gar nicht mehr.(Was zum teil daran liegt, dass das System nicht abstürzt, sondern nur so unglaublic langsam wird... aber auch das ist ein Fehler im System)
Windows nervt, aber es ist definitiv stabiler, bei einem Absturz unter Windows darf man den ganzen Rechner neustarten, aber ich glaube das ist mir seit XP noch nie passiert(mit Ausnahme von Abstürzen auf Grund von Hardwareschäden)