[Thread debugging using libthread_db enabled] [New Thread 0x7f8c4e0cf6f0 (LWP 777)] [KCrash handler] #5 0x00007f8c43dcf4f1 in gdk_pixbuf_new_from_data () from /usr/lib/libgdk_pixbuf-2.0.so.0 #6 0x00007f8c43dd6b43 in gdk_pixbuf_from_pixdata () from /usr/lib/libgdk_pixbuf-2.0.so.0 #7 0x00007f8c43dd6e8c in gdk_pixbuf_new_from_inline () from /usr/lib/libgdk_pixbuf-2.0.so.0 #8 0x00007f8c450ee9a7 in ?? () from /home/crissi/download2/flashplayer11_rc1_install_lin_64_090611/libflashplayer.so #9 0x00007f8c450eea8d in ?? () from /home/crissi/download2/flashplayer11_rc1_install_lin_64_090611/libflashplayer.so #10 0x00007f8c450ec0b5 in ?? () from /home/crissi/download2/flashplayer11_rc1_install_lin_64_090611/libflashplayer.so #11 0x00000000004149df in NSPluginClass::initialize (this=0x1) at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/nsplugin.cpp:1442 #12 0x0000000000416b8b in NSPluginClass (this=0x698400, library=@0x7fffe00d90b0, parent=0x697d30, name=) at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/nsplugin.cpp:1381 #13 0x000000000041b332 in NSPluginViewer::newClass (this=0x697d30, plugin= {static null = {static null = , d = 0x62ce20, static shared_null = 0x62ce20}, d = 0x7fffe00d90b0, static shared_null = 0x62ce20}) at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/nsplugin.cpp:1311 #14 0x000000000041d508 in NSPluginViewerIface::process (this=0x697db0, fun=, data=, replyType=, replyData=@0x7fffe00d93e0) at NSPluginClassIface_skel.cpp:36 #15 0x00007f8c4ac19cc7 in DCOPClient::receive (this=0x6ade60, objId=@0x7fffe00d9420, fun=@0x7fffe00d9410, data=@0x7fffe00d9400, replyType=@0x7fffe00d93f0, replyData=@0x7fffe00d93e0) at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:1643 #16 0x00007f8c4ac1eddf in DCOPProcessInternal (d=0x68bca0, opcode=2, key=10434, dataReceived=@0x7fffe00d9560, canPost=true) at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:520 #17 0x00007f8c4ac1f779 in DCOPProcessMessage (iceConn=0x65bc30, clientObject=0x68bca0, opcode=2, length=246, replyWait=, replyWaitRet=0x7fffe00d95d8) at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:432 #18 0x00007f8c4ac2aa2b in KDE_IceProcessMessages (iceConn=0x65bc30, replyWait=0x0, replyReadyRet=0x0) at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/KDE-ICE/process.c:326 #19 0x00007f8c4ac11043 in DCOPClient::processSocketData (this=0x6ade60, fd=) at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:2014 #20 0x00007f8c4ac1f45d in DCOPClient::qt_invoke (this=0x6ade60, _id=2, _o=0x7fffe00d9720) at ./dcopclient.moc:176 #21 0x00007f8c4b67736c in QObject::activate_signal (this=0x68ada0, clist=, o=0x7fffe00d9720) at kernel/qobject.cpp:2359 #22 0x00007f8c4b677a24 in QObject::activate_signal (this=0x68ada0, signal=, param=) at kernel/qobject.cpp:2452 #23 0x00007f8c4b69134b in QSocketNotifier::event (this=0x68ada0, e=0x7fffe00d9ac0) at kernel/qsocketnotifier.cpp:261 #24 0x00007f8c4b621953 in QApplication::internalNotify ( this=, receiver=0x68ada0, e=0x7fffe00d9ac0) at kernel/qapplication.cpp:2638 #25 0x00007f8c4b622668 in QApplication::notify (this=0x7fffe00d9b70, receiver=0x7f8c4c462730, e=0x7fffe00d9ac0) at kernel/qapplication.cpp:2361 #26 0x00007f8c4b023c62 in KApplication::notify (this=0x7fffe00d9b70, receiver=0x68ada0, event=0x7fffe00d9ac0) at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./kdecore/kapplication.cpp:550 #27 0x00007f8c4b617663 in QEventLoop::activateSocketNotifiers ( this=0x7fffe00d9ec0) at kernel/qapplication.h:523 #28 0x0000000000413f97 in QXtEventLoop::processEvents (this=0x7fffe00d9ec0, flags=0) at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/qxteventloop.cpp:459 #29 0x00007f8c4b636001 in QEventLoop::enterLoop (this=0x7f8c4c6939e0) at kernel/qeventloop.cpp:201 #30 0x00007f8c4b635eb2 in QEventLoop::exec (this=0x7f8c4c6939e0) at kernel/qeventloop.cpp:148 #31 0x00000000004191d0 in main (argc=3, argv=) at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/viewer.cpp:307
Wie auch immer man das deuten soll? Ich finde es mehr als beachtenswert was das KDE Projekt da auf die Beine gestellt hat. Die können einfach nicht alle alten Versionen bis ultimo pflegen, wo sollen die ganzen Entwickler denn herkommen? Zumal viele KDE Devs Hobbyentwickler sind. Du kannst ja mal versuchen den Anfang zu machen..., oder mal drüber machdenken wieso es bei Trinity so düster aussieht.
Immer dieses Gejammer, ach was war mein altes KDE 3 so super, wie sch... ist doch KDE 4, genauso aktuell mit GNOME. Zwingt dich wer das zu nutzen und dich nicht z.B. bei Xfce umzugucken? Ich hatte mit KDE 4 anfangs meine Lasten, bin aber mittlerweile von Xfce wieder zu KDE, weil KDE mittlerweile für meinen Geschmack echt klasse ist.
> Wie auch immer man das deuten soll? Ich finde es mehr als beachtenswert was das KDE Projekt da auf die Beine gestellt hat. Das ist wohl wahr. Sie haben den schwierigsten Weg gewählt, den es gab (zu KDE4).
> Die können einfach nicht alle alten Versionen bis ultimo pflegen Naja, solange KDE4 nicht alle Fähigkeiten von KDE3, nach viele Fehler vorhanden sind und noch unterstützte Distributionen mit KDE3 im Umlauf sind...
> Immer dieses Gejammer, ach was war mein altes KDE 3 so super, wie sch... ist doch KDE 4, Ich kenne KDE seit 1.0Beta1 und nutze auf anderen Rechnern u.a. KDE 4.7.x. Leider ist KDE4 immernoch nicht da, wo es sein sollte... Ich würde mir wünschen, dass KDE4 bald den Reifegrad erreicht, der seiner Versionsnummer würdig ist (ich persönlich würde KDE4.5 als 4.0, 4.6 als 4.1 und 4.7 als 4.2 einstufen). Ich will KDE (und die Entwickler dahinter) nicht schlecht machen. Jedoch ist es traurig zu sehen, wielange KDE4 gebraucht hat, um ein würdiger Nachfolger von KDE3 zu werden. Eine Zeit lang konnte ich u.a. Windowsumsteigern kein KDE4 empfehlen, da es wirklich in einem sehr schlechtem Zustand war. Das Release von 4.0 war viel zu früh und hätte meiner Meinung nach erst mit dem Stand von 4.5 released werden sollen. Nun kommen sicherlich einige auf die Idee, dass es ja irgendwann endlich mal released werden musste. Das mag zwar sein, aber schuld daran sind die QT-/KDE-Entwickler selber. Sie haben sich die Inkompatibilität von Qt4 und das Rewrite von KDE4 selber ausgesucht. Hätte man die Sourcecodekompatibilität von Qt4 zu Qt3 behalten, wäre das Ganze etwas einfacher ausgefallen. Dinge wie Plasma oder Phonon wären auch unter KDE3 denkbar gewesen. Die Mehrzahl der Benutzer hätte sich sicher ein fehlerfreieres KDE anstellen von vielen Leidenstagen und fehlenden Fähigkeiten gewünscht. In den Jahren hätte man sehr viele Fehler reparieren können. Die Chance auf dem Desktop war gut (Vista war eine Kastrophe für viele Windowsnutzer), leider ist sie jetzt mit Windows 7 wieder ziemlich weit weggerückt.
Ich möchte mich nicht als Ewiggestrigen verstanden wissen, sondern eher als ein Befürworter von KDE. Leider kommt es mir (und vielen anderen Nutzern) so vor, als wenn die Nutzer vergessen wurden und ihre Meinung nicht ernst genommen wird. Viele von Ihnen hatten keine Wahl und mussten zwangweise auf KDE4 wechseln (z.B. Distributionswechsel).
> Zwingt dich wer das zu nutzen und dich nicht z.B. bei Xfce umzugucken? Das ist jetzt wohl ein schlechter Scherz. Wer KDE3 sehr intensiv nutzt (und viele bestimmte spezielle Dinge, nicht nur Standardanwendungen wie Konqueror), der wird nicht auf Xfce oder Gnome wechseln wollen.
Wieso war das mit Xfce ein Scherz? Das hängt vom User selbst ab und ich kenne einige die jetzt mit Xfce sehr glücklich sind. Ich hab nur gesagt dass man sich da mal umschauen kann.
Von dgdggfhfdhgfdghdhg am So, 18. September 2011 um 21:19 #
Ich sehe das ähnlich.
Als ehemaliger KDE3-Nutzer habe ich unter Debian Squeeze Xfce und LXDE angetestet und habe beide GUIs wieder weitgehend verworfen. Speziell Thunar war beim Durchstöbern von Ordnern mit sehr vielen Dateien unglaublich langsam. Ich benutze jetzt Icewm (dank pmount und usbmount mit wenigstens demselben Komfort unter mc/rox-filer wie unter Thunar oder Pcmanfm) mit einigen "externen" Programmergänzungen (u.a. Xfburn, Leafpad, Evince-gtk, Geeqie usw.).
Trinity ist leider keine Option, da es ein "ubuntu-gestyltes" sudo in Squeeze einführt und das debianeigene sudo ersetzt. Auch geben mir einige Aussagen des kde.org-KWin-Entwicklers im Hinblick auf Trinity stark zu denken.
KDE ist auch keine GUI, die man so auf die Schnelle für sich allein auf einem dafür in keinster Weise angepassten Linux ohne viel Aufwand kompilieren und installieren kann. Hinzu kommt, dass selbst Qt3 quasi am Ende ist. Dann lieber einen harten Schnitt.
Dein Vorposter ist mit seinen Problemen nicht allein. Es kommt nicht von ungefähr, dass KDE 3.5.10 in openSUSE 12.1 wieder komplett im openSUSE-OSS-Repo angeboten wird. KDE 3.5.10 ist noch nicht abgekündigt, man kann ihn problemlos benutzen, unter openSUSE in wildem Durcheinander mit einer parallelen KDE4-Installation, da er komplett nach /opt installiert wird und einen anderen Namensraum belegt.
Die Installation ist so alt nicht, es ist ein Debian Lenny.
Dir ist aber schon bekannt, dass Squeeze die aktuelle Version von Debian ist? Und wenn du KDE3 weiterbenutzen möchtest, kannst du die Trinity-Quellen einbinden.
Das der Code von Adobe fehlerhaft ist.
Ich würde eher auf ein Problem mit Konqueror tippen. Benutze einfach einen aktuelleren Browser und das Problem wird mit 100% Sicherheit verschwinden.
Sicherheits- und anwendungstechnisch ergibt sich durch die Einbindung der KDE3-Trinityquellen in Squeeze kein Vorteil gegenüber der Benutzung von KDE3 in Debian Lenny. Debian Lenny hat noch Support bis Februar 2012. Vielleicht zeigen ja Iceweasel 3.0 oder Epiphany-Gecko nicht den gleichen Fehler wie KDE 3.5.9-Konqueror.
Sicherheits- und anwendungstechnisch ergibt sich [..]
Das letzte (Sicherheits-)Update für Konqueror unter Debian Lenny stammt vom April 2010. Ich will nicht behaupten, dass diese alte Version generell unsicher ist, aber einem Browser der seit über einem Jahr kein Update mehr erhalten hat, würde ich nur noch bedingt vertrauen.
Vielleicht zeigen ja Iceweasel 3.0 oder Epiphany-Gecko nicht den gleichen Fehler wie KDE 3.5.9-Konqueror.
Da bin ich mir sogar ziemlich sicher:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596530 (Anmerkung ganz unten im Bug-Report).
"Das letzte (Sicherheits-)Update für Konqueror unter Debian Lenny stammt vom April 2010. Ich will nicht behaupten, dass diese alte Version generell unsicher ist, aber einem Browser der seit über einem Jahr kein Update mehr erhalten hat, würde ich nur noch bedingt vertrauen."
Das weiß ich ebenfalls nicht. Die Bugliste für Lennys KDE3-Konqueror ist auch direkt auf die KDE4-Konqueror-Fehlerberichteseite für Unstable verlinkt: http://packages.debian.org/de/lenny/konqueror (einfach auf Fehlerberichte klicken)
Der Hauptbrowser in Debian Lenny ist ohnehin Iceweasel 3.0.x und der wird über das zugrundeliegende Xulrunner-Paket immer noch im Gleichtakt mit den mozilla.org-Updates gefixt. Iceweasel 3.0 in Lenny entspricht somit zur Zeit einem Firefox 3.0.31: http://packages.debian.org/changelogs/pool/main/x/xulrunner/xulrunner_1.9.0.19-13/changelog Da Epiphany-Browser und Galeon das gleiche Xulrunner-Paket benutzen, sind diese auch noch problemlos benutzbar. Von daher haben KDE3-Nutzer in Lenny noch gute Konqueror-Webbrowseralternativen.
Von daher haben KDE3-Nutzer in Lenny noch gute Konqueror-Webbrowseralternativen.
Deshalb ja auch mein Vorschlag weiter oben es mit einem anderen Browser zu versuchen.
Den Wechsel auf Debian Squeeze habe ich nur deshalb vorgeschlagen, weil ich übersehen hatte, dass auch in Lenny KDE 3.5.10 vorliegt (Obwohl die Versionsnummer im Crash-Dump 3.5.9 lautet) und Trinity ebenfalls für Lenny verfügbar ist.
Kann mich/uns jemand ueber all die Frameworks mal aufklaeren? Wem was gehoert? Welche Software welches FW unterstuetzt? Welches FW welche Funktionen unsterstuetzt bzw. beschleunigt?
das sind alles begriffe für hardwarebeschleunigung mit der Grafikkarte. Sowas wie Dxva für Windows. bloß gibts für Linux keinen wirklichen standart weshalb jedes Uternehmen sein eigenes Süppchen kocht. Vaapi ist von Intel entwickelt worden und könnte vielleicht mal das Dxva für Linux werden, da es so weit ich weiß auf die anderen aufsetzt. vdpau ist von nvidia. und xvba von AMD/ATI. crystal hd ist glaub ich für son speziellen grafikchip von broadcom der manchmal in netbooks zu finden ist.
vdpau gabs zuerst und scheint anhand der Verbreitung auch recht brauchbar zu sein. Die Ergebnisse davon sind recht ansehnlich. dann kam intel und hat va-api an den Start gebracht (vdpau ignoriert) - vdpau kann auch als backend von va-api benutzt werden.
va-api auf Intel ist sogar einigermassen benutzbar inzwischen wenn man Versionen einsetzt die neu genug sind (aktuelles git/svn/etc) - einzig deinterlacen will noch garnicht gehen auf der Grafik, die Formate die beschleunigt werden sind gegenüber nvidia und vdpau stark begrenzt. Richtig nützlich wird das bei Intel auch nur wirklich wenn die Hardware neu genug ist ( Core iX)
va-api mit AMD (dann wohl XvBA als backend (?)) ist so gut wie noch nicht benutzbar, noch ist daran zu denken das es irgendwas beschleunigt.
va-api mit vdpau als Backend ist nicht brauchbar, da etliche Funktionen von vdpau darin nicht genutzt werden können.
Wenn sie vdpau unterstützen und crystalhd, dann unterstützen sie alles was auf einer normalen heutigen Installation funktionieren könnte. Wer nach va-api schreit, ist unrealistisch oder benutzt nichts davon wirklich und mag gerne jammern.
VA-API und VDPAU sind soweit als Open Source Projekte verfügbar. Im Mesa Projekt finden sich auch noch Implementierungen die aber noch nicht fertig sind für beide APIs.
Für XvBA gibt es nur die Header und einige Samples und was Crystal HD angeht kann ich leider mangels Interesse nicht sagen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Sep 2011 um 15:33.
XvBA gab es zuerst allerdings nur gegen eine NDA und war ursprünglich für den ebedded Markt gedacht.
> dann kam intel und hat va-api an den Start gebracht (vdpau ignoriert)
Wenn die eigenen API fast fertig ist warum soll man dann wieder alles über den Haufen werden und eine neue API Implementieren. Neben bei unterstützt auch VA-API das encoding.
> va-api mit AMD (dann wohl XvBA als backend (?)) ist so gut wie noch nicht benutzbar, noch ist daran zu denken das es irgendwas beschleunigt.
Das VA-APPI frontend für XvBA funktioniert inzwischen super deine Infos sind wohl etwas älter.
Von Splash-1st am Do, 8. September 2011 um 10:50 #
> Das VA-APPI frontend für XvBA funktioniert inzwischen super deine Infos sind wohl etwas älter.
Kannst Du mir erklären oder einen Link liefern wie ich dann die Videobeschleunigung mit einer ATI Graka zum laufen bekommen? Im Moment ist nämlich mit einer standard openSUSe Installation nix mit brauchbarer Videobeschleunigung und ATI.
Einfach einen Aktuellen fglrx installieren und die VA-API Pakete. Ich nutze meist Ubuntu daher keine Ahnung wo du für dich die Pakete am besten hernimst.
Hier ist die Website für Va-API
http://www.freedesktop.org/wiki/Software/vaapi
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 08. Sep 2011 um 11:53.
Obwohl ich einen starken PC habe (Core i7), bleiben bei mir Flash-Videos einfach stehen (Flash 10.3) und ich muss mit Strg+Alt+F1 den Prozess killen, um den Desktop wieder benutzen zu können.
Aus diesem Grund habe ich bei mir die HW-Beschleunigung aktiviert - das ist möglich, indem man eine Datei /etc/adobe/mms.cfg anlegt und dort "EnableLinuxHWVideoDecode=1" einträgt. Jedoch bringt diese Beschleunigung den NVidia-Treiber gerne zum Absturz und ich kann mich nur noch per SSH auf dem Rechner einloggen, da alles stehenbleibt.
Keine der Lösungen ist zufriedenstellend und ich glaube auch nicht, dass es sich mit Version 11 verbessern wird. Nutze deswegen z.B. auf YouTube den HTML5-Player - der hat zwar keine Hardware-Dekodierung, bleibt bei der Wiedergabe nicht stehen und stürzt auch nicht ab.
Also bei mir läufts flüssig, da bleibt nix stehen, egal ob mit oder ohne Hardwarebeschleunigung. Was bei mir Ärger macht ist es, wenn ich unter Suse 11.4 64 Bit den 32 Bit Flashplayer nutze, der geht gerne über die Wupper. Unter Arch geht das aber prima, keine Ahnung wo da der Bug ist.
Dann wird Adobe bei Intel wohl bald in Ungnade fallen.
[Thread debugging using libthread_db enabled]
[New Thread 0x7f8c4e0cf6f0 (LWP 777)]
[KCrash handler]
#5 0x00007f8c43dcf4f1 in gdk_pixbuf_new_from_data ()
from /usr/lib/libgdk_pixbuf-2.0.so.0
#6 0x00007f8c43dd6b43 in gdk_pixbuf_from_pixdata ()
from /usr/lib/libgdk_pixbuf-2.0.so.0
#7 0x00007f8c43dd6e8c in gdk_pixbuf_new_from_inline ()
from /usr/lib/libgdk_pixbuf-2.0.so.0
#8 0x00007f8c450ee9a7 in ?? ()
from /home/crissi/download2/flashplayer11_rc1_install_lin_64_090611/libflashplayer.so
#9 0x00007f8c450eea8d in ?? ()
from /home/crissi/download2/flashplayer11_rc1_install_lin_64_090611/libflashplayer.so
#10 0x00007f8c450ec0b5 in ?? ()
from /home/crissi/download2/flashplayer11_rc1_install_lin_64_090611/libflashplayer.so
#11 0x00000000004149df in NSPluginClass::initialize (this=0x1)
at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/nsplugin.cpp:1442
#12 0x0000000000416b8b in NSPluginClass (this=0x698400,
library=@0x7fffe00d90b0, parent=0x697d30, name=)
at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/nsplugin.cpp:1381
#13 0x000000000041b332 in NSPluginViewer::newClass (this=0x697d30, plugin=
{static null = {static null = , d = 0x62ce20, static shared_null = 0x62ce20}, d = 0x7fffe00d90b0, static shared_null = 0x62ce20})
at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/nsplugin.cpp:1311
#14 0x000000000041d508 in NSPluginViewerIface::process (this=0x697db0,
fun=, data=,
replyType=, replyData=@0x7fffe00d93e0)
at NSPluginClassIface_skel.cpp:36
#15 0x00007f8c4ac19cc7 in DCOPClient::receive (this=0x6ade60,
objId=@0x7fffe00d9420, fun=@0x7fffe00d9410, data=@0x7fffe00d9400,
replyType=@0x7fffe00d93f0, replyData=@0x7fffe00d93e0)
at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:1643
#16 0x00007f8c4ac1eddf in DCOPProcessInternal (d=0x68bca0, opcode=2,
key=10434, dataReceived=@0x7fffe00d9560, canPost=true)
at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:520
#17 0x00007f8c4ac1f779 in DCOPProcessMessage (iceConn=0x65bc30,
clientObject=0x68bca0, opcode=2, length=246,
replyWait=, replyWaitRet=0x7fffe00d95d8)
at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:432
#18 0x00007f8c4ac2aa2b in KDE_IceProcessMessages (iceConn=0x65bc30,
replyWait=0x0, replyReadyRet=0x0)
at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/KDE-ICE/process.c:326
#19 0x00007f8c4ac11043 in DCOPClient::processSocketData (this=0x6ade60,
fd=)
at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./dcop/dcopclient.cpp:2014
#20 0x00007f8c4ac1f45d in DCOPClient::qt_invoke (this=0x6ade60, _id=2,
_o=0x7fffe00d9720) at ./dcopclient.moc:176
#21 0x00007f8c4b67736c in QObject::activate_signal (this=0x68ada0,
clist=, o=0x7fffe00d9720) at kernel/qobject.cpp:2359
#22 0x00007f8c4b677a24 in QObject::activate_signal (this=0x68ada0,
signal=, param=)
at kernel/qobject.cpp:2452
#23 0x00007f8c4b69134b in QSocketNotifier::event (this=0x68ada0,
e=0x7fffe00d9ac0) at kernel/qsocketnotifier.cpp:261
#24 0x00007f8c4b621953 in QApplication::internalNotify (
this=, receiver=0x68ada0, e=0x7fffe00d9ac0)
at kernel/qapplication.cpp:2638
#25 0x00007f8c4b622668 in QApplication::notify (this=0x7fffe00d9b70,
receiver=0x7f8c4c462730, e=0x7fffe00d9ac0) at kernel/qapplication.cpp:2361
#26 0x00007f8c4b023c62 in KApplication::notify (this=0x7fffe00d9b70,
receiver=0x68ada0, event=0x7fffe00d9ac0)
at /home/jmm/kdelibs/kdelibs-3.5.10.dfsg.1/./kdecore/kapplication.cpp:550
#27 0x00007f8c4b617663 in QEventLoop::activateSocketNotifiers (
this=0x7fffe00d9ec0) at kernel/qapplication.h:523
#28 0x0000000000413f97 in QXtEventLoop::processEvents (this=0x7fffe00d9ec0,
flags=0)
at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/qxteventloop.cpp:459
#29 0x00007f8c4b636001 in QEventLoop::enterLoop (this=0x7f8c4c6939e0)
at kernel/qeventloop.cpp:201
#30 0x00007f8c4b635eb2 in QEventLoop::exec (this=0x7f8c4c6939e0)
at kernel/qeventloop.cpp:148
#31 0x00000000004191d0 in main (argc=3, argv=)
at /home/thijs/debian/sec-up/kdebase/kdebase-3.5.9.dfsg.1/./nsplugins/viewer/viewer.cpp:307
Das kommt bestimmt von Deiner uralten KDE3-Installation.
Oder was wolltest Du Deinem Lesepublikum mit Deinem unkommentierten Exzerpt mitteilen?
und dann noch KDE3.5.9 - peinlich solch ein Post
Ich finde es irgendwie lustig.
Noch einer, der den Wechsel von KDE3 auf "etwas anderes" immer noch hinauszögert.
Das ist nicht peinlich für mich sondern eher für die Unfähigkeit/Unwilligkeit einiger KDE-Entwickler...
Du weißt schon, dass KDE 3.x schon seit langem nicht mehr maintained wird!?!
Wie auch immer man das deuten soll? Ich finde es mehr als beachtenswert was das KDE Projekt da auf die Beine gestellt hat. Die können einfach nicht alle alten Versionen bis ultimo pflegen, wo sollen die ganzen Entwickler denn herkommen? Zumal viele KDE Devs Hobbyentwickler sind. Du kannst ja mal versuchen den Anfang zu machen..., oder mal drüber machdenken wieso es bei Trinity so düster aussieht.
Immer dieses Gejammer, ach was war mein altes KDE 3 so super, wie sch... ist doch KDE 4, genauso aktuell mit GNOME. Zwingt dich wer das zu nutzen und dich nicht z.B. bei Xfce umzugucken? Ich hatte mit KDE 4 anfangs meine Lasten, bin aber mittlerweile von Xfce wieder zu KDE, weil KDE mittlerweile für meinen Geschmack echt klasse ist.
> Wie auch immer man das deuten soll? Ich finde es mehr als beachtenswert was das KDE Projekt da auf die Beine gestellt hat.
Das ist wohl wahr. Sie haben den schwierigsten Weg gewählt, den es gab (zu KDE4).
> Die können einfach nicht alle alten Versionen bis ultimo pflegen
Naja, solange KDE4 nicht alle Fähigkeiten von KDE3, nach viele Fehler vorhanden sind und noch unterstützte Distributionen mit KDE3 im Umlauf sind...
> Immer dieses Gejammer, ach was war mein altes KDE 3 so super, wie sch... ist doch KDE 4,
Ich kenne KDE seit 1.0Beta1 und nutze auf anderen Rechnern u.a. KDE 4.7.x. Leider ist KDE4 immernoch nicht da, wo es sein sollte...
Ich würde mir wünschen, dass KDE4 bald den Reifegrad erreicht, der seiner Versionsnummer würdig ist (ich persönlich würde KDE4.5 als 4.0, 4.6 als 4.1 und 4.7 als 4.2 einstufen). Ich will KDE (und die Entwickler dahinter) nicht schlecht machen. Jedoch ist es traurig zu sehen, wielange KDE4 gebraucht hat, um ein würdiger Nachfolger von KDE3 zu werden. Eine Zeit lang konnte ich u.a. Windowsumsteigern kein KDE4 empfehlen, da es wirklich in einem sehr schlechtem Zustand war. Das Release von 4.0 war viel zu früh und hätte meiner Meinung nach erst mit dem Stand von 4.5 released werden sollen. Nun kommen sicherlich einige auf die Idee, dass es ja irgendwann endlich mal released werden musste. Das mag zwar sein, aber schuld daran sind die QT-/KDE-Entwickler selber. Sie haben sich die Inkompatibilität von Qt4 und das Rewrite von KDE4 selber ausgesucht. Hätte man die Sourcecodekompatibilität von Qt4 zu Qt3 behalten, wäre das Ganze etwas einfacher ausgefallen. Dinge wie Plasma oder Phonon wären auch unter KDE3 denkbar gewesen. Die Mehrzahl der Benutzer hätte sich sicher ein fehlerfreieres KDE anstellen von vielen Leidenstagen und fehlenden Fähigkeiten gewünscht. In den Jahren hätte man sehr viele Fehler reparieren können. Die Chance auf dem Desktop war gut (Vista war eine Kastrophe für viele Windowsnutzer), leider ist sie jetzt mit Windows 7 wieder ziemlich weit weggerückt.
Ich möchte mich nicht als Ewiggestrigen verstanden wissen, sondern eher als ein Befürworter von KDE. Leider kommt es mir (und vielen anderen Nutzern) so vor, als wenn die Nutzer vergessen wurden und ihre Meinung nicht ernst genommen wird. Viele von Ihnen hatten keine Wahl und mussten zwangweise auf KDE4 wechseln (z.B. Distributionswechsel).
> Zwingt dich wer das zu nutzen und dich nicht z.B. bei Xfce umzugucken?
Das ist jetzt wohl ein schlechter Scherz. Wer KDE3 sehr intensiv nutzt (und viele bestimmte spezielle Dinge, nicht nur Standardanwendungen wie Konqueror), der wird nicht auf Xfce oder Gnome wechseln wollen.
Wieso war das mit Xfce ein Scherz? Das hängt vom User selbst ab und ich kenne einige die jetzt mit Xfce sehr glücklich sind. Ich hab nur gesagt dass man sich da mal umschauen kann.
Ich sehe das ähnlich.
Als ehemaliger KDE3-Nutzer habe ich unter Debian Squeeze Xfce und LXDE angetestet und habe beide GUIs wieder weitgehend verworfen. Speziell Thunar war beim Durchstöbern von Ordnern mit sehr vielen Dateien unglaublich langsam. Ich benutze jetzt Icewm (dank pmount und usbmount mit wenigstens demselben Komfort unter mc/rox-filer wie unter Thunar oder Pcmanfm) mit einigen "externen" Programmergänzungen (u.a. Xfburn, Leafpad, Evince-gtk, Geeqie usw.).
Trinity ist leider keine Option, da es ein "ubuntu-gestyltes" sudo in Squeeze einführt und das debianeigene sudo ersetzt. Auch geben mir einige Aussagen des kde.org-KWin-Entwicklers im Hinblick auf Trinity stark zu denken.
KDE ist auch keine GUI, die man so auf die Schnelle für sich allein auf einem dafür in keinster Weise angepassten Linux ohne viel Aufwand kompilieren und installieren kann. Hinzu kommt, dass selbst Qt3 quasi am Ende ist.
Dann lieber einen harten Schnitt.
Dein Vorposter ist mit seinen Problemen nicht allein.
Es kommt nicht von ungefähr, dass KDE 3.5.10 in openSUSE 12.1 wieder komplett im openSUSE-OSS-Repo angeboten wird.
KDE 3.5.10 ist noch nicht abgekündigt, man kann ihn problemlos benutzen, unter openSUSE in wildem Durcheinander mit einer parallelen KDE4-Installation, da er komplett nach /opt installiert wird und einen anderen Namensraum belegt.
Die Installation ist so alt nicht, es ist ein Debian Lenny.
> Oder was wolltest Du Deinem Lesepublikum mit Deinem unkommentierten Exzerpt mitteilen?
Das der Code von Adobe fehlerhaft ist.
Sicherheits- und anwendungstechnisch ergibt sich durch die Einbindung der KDE3-Trinityquellen in Squeeze kein Vorteil gegenüber der Benutzung von KDE3 in Debian Lenny.
Debian Lenny hat noch Support bis Februar 2012.
Vielleicht zeigen ja Iceweasel 3.0 oder Epiphany-Gecko nicht den gleichen Fehler wie KDE 3.5.9-Konqueror.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=596530 (Anmerkung ganz unten im Bug-Report).
"Das letzte (Sicherheits-)Update für Konqueror unter Debian Lenny stammt vom April 2010. Ich will nicht behaupten, dass diese alte Version generell unsicher ist, aber einem Browser der seit über einem Jahr kein Update mehr erhalten hat, würde ich nur noch bedingt vertrauen."
Das weiß ich ebenfalls nicht.
Die Bugliste für Lennys KDE3-Konqueror ist auch direkt auf die KDE4-Konqueror-Fehlerberichteseite für Unstable verlinkt:
http://packages.debian.org/de/lenny/konqueror
(einfach auf Fehlerberichte klicken)
Der Hauptbrowser in Debian Lenny ist ohnehin Iceweasel 3.0.x und der wird über das zugrundeliegende Xulrunner-Paket immer noch im Gleichtakt mit den mozilla.org-Updates gefixt.
Iceweasel 3.0 in Lenny entspricht somit zur Zeit einem Firefox 3.0.31:
http://packages.debian.org/changelogs/pool/main/x/xulrunner/xulrunner_1.9.0.19-13/changelog
Da Epiphany-Browser und Galeon das gleiche Xulrunner-Paket benutzen, sind diese auch noch problemlos benutzbar.
Von daher haben KDE3-Nutzer in Lenny noch gute Konqueror-Webbrowseralternativen.
Den Wechsel auf Debian Squeeze habe ich nur deshalb vorgeschlagen, weil ich übersehen hatte, dass auch in Lenny KDE 3.5.10 vorliegt (Obwohl die Versionsnummer im Crash-Dump 3.5.9 lautet) und Trinity ebenfalls für Lenny verfügbar ist.
https://addons.mozilla.org/en-US/firefox/addon/flashvideoreplacer/
Wäre ein Versuch Wert.
Was willst du damit? Geht laut Homepage bei Youtube und einigen Pornoseiten. Also unbrauchbar.
Was macht denn Gnash?
Das gleiche wie immer: 50 : 50.
Die eine Hälfte wird nicht angezeigt, bei der anderen Hälfte stürzt es ab.
Es funktioniert halbwegs...
Mit den Cookies spinnt er manchmal rum bei Youtube, aber an sich geht der ganz gut. Auf anderen Seiten geht der garnicht.
Kann mich/uns jemand ueber all die Frameworks mal aufklaeren? Wem was gehoert? Welche Software welches FW unterstuetzt? Welches FW welche Funktionen unsterstuetzt bzw. beschleunigt?
das sind alles begriffe für hardwarebeschleunigung mit der Grafikkarte. Sowas wie Dxva für Windows. bloß gibts für Linux keinen wirklichen standart weshalb jedes Uternehmen sein eigenes Süppchen kocht. Vaapi ist von Intel entwickelt worden und könnte vielleicht mal das Dxva für Linux werden, da es so weit ich weiß auf die anderen aufsetzt. vdpau ist von nvidia. und xvba von AMD/ATI. crystal hd ist glaub ich für son speziellen grafikchip von broadcom der manchmal in netbooks zu finden ist.
wer Fehler finden bitte korrigieren.
vdpau gabs zuerst und scheint anhand der Verbreitung auch recht brauchbar zu sein. Die Ergebnisse davon sind recht ansehnlich. dann kam intel und hat va-api an den Start gebracht (vdpau ignoriert) - vdpau kann auch als backend von va-api benutzt werden.
va-api auf Intel ist sogar einigermassen benutzbar inzwischen wenn man Versionen einsetzt die neu genug sind (aktuelles git/svn/etc) - einzig deinterlacen will noch garnicht gehen auf der Grafik, die Formate die beschleunigt werden sind gegenüber nvidia und vdpau stark begrenzt. Richtig nützlich wird das bei Intel auch nur wirklich wenn die Hardware neu genug ist ( Core iX)
va-api mit AMD (dann wohl XvBA als backend (?)) ist so gut wie noch nicht benutzbar, noch ist daran zu denken das es irgendwas beschleunigt.
va-api mit vdpau als Backend ist nicht brauchbar, da etliche Funktionen von vdpau darin nicht genutzt werden können.
Wenn sie vdpau unterstützen und crystalhd, dann unterstützen sie alles was auf einer normalen heutigen Installation funktionieren könnte. Wer nach va-api schreit, ist unrealistisch oder benutzt nichts davon wirklich und mag gerne jammern.
Vielleicht sieht es in einem Jahr ja anders aus.
Liegt irgendeine dieser Technologien in Form freier Software vor?
VA-API und VDPAU sind soweit als Open Source Projekte verfügbar. Im Mesa Projekt finden sich auch noch Implementierungen die aber noch nicht fertig sind für beide APIs.
Für XvBA gibt es nur die Header und einige Samples und was Crystal HD angeht kann ich leider mangels Interesse nicht sagen.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Sep 2011 um 15:33.> vdpau gabs zuerst
XvBA gab es zuerst allerdings nur gegen eine NDA und war ursprünglich für den ebedded Markt gedacht.
> dann kam intel und hat va-api an den Start gebracht (vdpau ignoriert)
Wenn die eigenen API fast fertig ist warum soll man dann wieder alles über den Haufen werden und eine neue API Implementieren. Neben bei unterstützt auch VA-API das encoding.
> va-api mit AMD (dann wohl XvBA als backend (?)) ist so gut wie noch nicht benutzbar, noch ist daran zu denken das es irgendwas beschleunigt.
Das VA-APPI frontend für XvBA funktioniert inzwischen super deine Infos sind wohl etwas älter.
> Das VA-APPI frontend für XvBA funktioniert inzwischen super deine Infos sind wohl etwas älter.
Kannst Du mir erklären oder einen Link liefern wie ich dann die Videobeschleunigung mit einer ATI Graka zum laufen bekommen? Im Moment ist nämlich mit einer standard openSUSe Installation nix mit brauchbarer Videobeschleunigung und ATI.
Einfach einen Aktuellen fglrx installieren und die VA-API Pakete. Ich nutze meist Ubuntu daher keine Ahnung wo du für dich die Pakete am besten hernimst.
Hier ist die Website für Va-API
http://www.freedesktop.org/wiki/Software/vaapi
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 08. Sep 2011 um 11:53.WP8 und WEBM?
Obwohl ich einen starken PC habe (Core i7), bleiben bei mir Flash-Videos einfach stehen (Flash 10.3) und ich muss mit Strg+Alt+F1 den Prozess killen, um den Desktop wieder benutzen zu können.
Aus diesem Grund habe ich bei mir die HW-Beschleunigung aktiviert - das ist möglich, indem man eine Datei /etc/adobe/mms.cfg anlegt und dort "EnableLinuxHWVideoDecode=1" einträgt. Jedoch bringt diese Beschleunigung den NVidia-Treiber gerne zum Absturz und ich kann mich nur noch per SSH auf dem Rechner einloggen, da alles stehenbleibt.
Keine der Lösungen ist zufriedenstellend und ich glaube auch nicht, dass es sich mit Version 11 verbessern wird.
Nutze deswegen z.B. auf YouTube den HTML5-Player - der hat zwar keine Hardware-Dekodierung, bleibt bei der Wiedergabe nicht stehen und stürzt auch nicht ab.
Also bei mir läufts flüssig, da bleibt nix stehen, egal ob mit oder ohne Hardwarebeschleunigung. Was bei mir Ärger macht ist es, wenn ich unter Suse 11.4 64 Bit den 32 Bit Flashplayer nutze, der geht gerne über die Wupper. Unter Arch geht das aber prima, keine Ahnung wo da der Bug ist.
Als weitere Neuerung kam G.711-Audio-Kompression für Telefonie im Player hinzu
Wer zum Henker nutzt sowas?
lg
Erik
Chatroulette?
Tinychat?