Mit dem Plasma-Design-Desaster von Seigo kann ich keine Aussage von ihm mehr ernst nehmen.
Wie kommt man auf die schwachsinnige Idee alle Plasma-Widgets in einem Prozess zu packen? Jedesmal wenn mir die Netzwerkverbindung abreißt und ich ein NFS-Share gemountet habe (z.B. nach dem Aufwachen aus dem Suspend) sind alle Plasma-Widgets blockiert.
Er soll erstmal den Scheiß den er verbrochen hat gerade biegen bevor er laute Kritik an anderen übt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Feb 2013 um 12:33.
Nicht nur das, nachdem er mit seinem Vivaldi-Disaster schon wer weiß wie oft in den Medien für Schlagzeilen sorgte und viele Fans vor den Kopf stieß, ist er eigentlich der letzte der sich da über Canonical das Maul zerreißen sollte. Seine vermeintliche Kritik, riecht hier ehe nach Neid. Die schaffen das was er nicht schaffte.
Was wäre denn anders, wenn jedes Plasmoid in einem separaten Prozess laufen würde und die Netzwerkverbindung zum NFS-Server würde dann abbrechen?
Verstehe ich das richtig, Du hast Dein home per NFS eingebunden, d.h. Dein .kde4, .local und .share liegen auf einem NFS-Share? Ich habe das noch nicht gemacht, da kein Bedarf, aber hast Du da nicht Performance Probleme mit Akonadi und Nepomuk, oder wie verhält sich das da?
Nein, ich habe nicht mein Home auf dem NFS-Share, sondern in /mnt/server. Kein plan was darauf zugreifen will aber alle Plasma-Widgets hängen, einschließlich dem Networkmanager-Widget.
Uuups, da habe ich mich dämlich ausgedrückt. Home liegt auf dem lokalen Dateisystem. Das NFS-Share ist nach /mtn/server gemountet somit sollte niemand damit probleme haben.
Da gibt es aber keinen Grund zu blockieren dann. Wenn das bei dir blockiert klingt das nach einem Bug in einem Plasmoid. Es wäre toll wenn du dem nachgehen könntest und dann einen Bug Report aufmachst -> bugs.kde.org
Naja, daß ein Bug in einem Plasmoid gleich alles blockieren kann, das bleibt aber ein Design-Fehler von Plasma.
Plasmoids, gerade von Dritten oder selbstgemachte, können nun mal Fehler haben (welcher Code ist schon fehlerfrei, jedenfalls von Beginn an). Es ist nicht verständlich, warum das alles in einem Prozeß laufen soll. Gibt es irgendwo eine mit Untersuchungsergebnissen unterfütterte Begründung, oder ist das mal so aus dem Blauen festgelegt worden und wird seitdem als Heiligtum behandelt, das nicht ohne vermeintlichen Gesichtsverlust verändert werden kann?
Ein gutes System muß in der Lage sein, auch mit fehlerhaften Komponenten weiterhin so gut wie möglich zu funktionieren.
für 3rd party propagieren wir die Verwendung von Scripting Technologien wie QML, JavaScript oder Python. Mit diesen sollte das nicht passieren.
Mit C++ kannst du das auf Grund der Sprache und der Möglichkeiten der Sprache einfach nicht verhindern. Wenn du dir von extern ein C++ Plasmoid installierst, musst du dir halt auch bewusst sein, dass es problematisch sein kann. Deshalb ist das ja auch nicht gerade einfach so was zu installieren. Es gibt Distributionen, die so etwas paketieren und dann ist es deren Aufgabe die Qualitätssicherung durchzuführen.
Im Falle von Plasmoiden, die von der KDE Community veröffentlicht werden, gilt natürlich, dass wir Bugs beheben und nicht herumprogrammieren. Wenn es einen blockierenden Zugriff gibt, dann muss der beseitigt werden und nicht ein kompliziertes Framework drumrumgebaut werden.
Also sorry mgraesslin, das ist der gleiche Witz wie damals unter OS/2 Warp. Sobald irgendein Programm blockiert, und da alles über eine einzige Message Queue lief, hing der komplette Desktop und man durfte den Rechner neu starten...
Das ist einfach sträflich. Alle Komponenten müssen "parallel" laufen, ohne dass es andere Teile blockieren kann. Wozu gibt es Multitasking?
Hallo. Also unter KDE3 war genau das der Fall. Der Desktop hat sich aus verschiedenen Prozessen zusammengesetzt. Einer für den Hintergrund, einer für die Taskleiste, einer für die Desktop-Widgets, usw.
Diese Design hat sich jedoch als Problematisch erwiesen da zum einem Unmengen an Synchronisation nötig war und die einzelnen Komponenten so weniger gemeinsame Basis hatten. Es gab auch entsprechende Performance -Analysen die zum Schluß gekommen sind, daß eine Reduzierung der Prozesse Performancevorteile bringt. Leider ist der entsprechende Artikel von Lubos Lunak über KDE Performance Analysis mittlerweile aus dem Internet verschwunden. Hat jemand zufälligerweise eine Kopie oder mehr Erfolg bei der Suche?
Ich habe hier das gleiche Problem. Es braucht nur irgendein NFS-Mount im System zu existieren, der gerade nicht erreichbar ist und schon steht hier der komplette plasma-desktop.
Bei mir sind einfach nur verschiedene Datenverzeichnisse in /mnt gemountet.
/home mitsamt den kde-eigenen oder sonstigen Config-Verzeichnissen (.kde4 / .local, etc) sind alle lokal und nicht auf NFS.
Wenn mein Rechner z.B. aus dem Suspend aufwacht, ist plasma-desktop solange unsichtbar (man sieht nur das Hintergrundbild und noch offene Fenster, die man auch schon bedienen kann), bis die Netzwerk-Verbindung wieder steht.
Ich kenne dies Phänomen von Samba. Wenn die Freigabe plötzlich nicht mehr existiert oder die Netzverbindung weg ist, dann friert mein Desktop für ca. 3 Minuten ein. Ähnlich muss es also auch mit NFS sein.
Liegt das wirklich an Plasma oder vielleicht doch eher an was anderem? Also wenn ich auf externe USB-Datenträger zugreife, ist während der gesamten Operation das System manchmal nicht mehr bedienbar. Und das liegt bei mir nicht an Plasma. Das hat mich schon immer sehr gestört.
Ich habe das gleiche Problem sowohl in GNOME als auch in Unity oder XFCE. Wenn ein Netzwerk-Share nicht ereichtbar ist, geht am Desktop praktisch nichts mehr. Das ist wohl eher kein KDE-Problem.
Jupp, wenn ein Samba share eingehängt ist, das nicht mehr erreichbar ist, ohne dass es ausgehängt wurde, hängen mindestens kwin und plasma-desktop ein paar Minuten. Das ist schon länger so, weshalb ich zum Beispiel davfs2 nicht verwende.
Wahrscheinlich bei *jeder* "blockierenden" Operation, wie Festplattenzugriff oder for-schleifen. KDE Plasma ist erschreckend ranzig. Windows 3.1. Feel für Linux.
OMG, was haben denn Festplattenzugriffe oder Programmiersprachenkonstrukte wie for-Schleifen mit Plasma zu tun? Kläre uns Unwissenden bitte mal auf. Was definitiv nicht toll ist, dass Dateioperationen auf Festplatten oder USB Speichermedien das ganze System extrem blockieren können, was aber wohl eher am Kernel liegt als an Plasma.
Na ganz einfach: KDE Plasmoids führen wie alle Anwendungen oder Plugins auch Code aus, sind jedoch per default in *einem* Thread, und setzten auf kooperatives multitasking, wie zu windows 3.1 Zeiten (oder Plugins in älteren? Firefox Versionen). Siehe hier: http://forum.kde.org/viewtopic.php?f=90&t=45255
Während ein Plasmoid läuft, blockieren alle anderen. Nimmt sich eines jetzt zu viel Zeit - wie etwa bei einer langen for-schleife, einem Netzwerk - oder Festplattenzugriff, "hängt" sich KDE für eine Weile auf. Sehr schade, denn abgesehen von Aarons(?) schwachsinniger Software Architektur scheint KDE eigentlich ganz vernünftig zu sein.
Aha, danke für die Info. interessant. Ist von 2009. Ich verwende auch Plasmoide, allerdings konnte ich das Phänomen noch nicht beobachten. Wäre mal interessant zu wissen, welche von Dir genutzten Plasmoide so eine Blockierung auslösen? Ansonsten ist es wohl abzuwägen, was besser ist, jedes Plasmoid in einen eigenen Prozess zu packen würde natürlich auch viel Overhead und damit Recourcenverschwendung mit sich bringen. Ich kann es nicht beurteilen, was da besser wäre.
es ist schlicht und einfach nicht möglich Plasmoide in eigene Prozesse zu packen, da sie zusammen zu die Grafik Ausgabe erstellen (das steht so auch in dem Thread).
Wenn etwas blockiert, dann muss man das identifizieren und den blockierenden Zugriff entfernen (Stichwort: Thread). Prozesse sind da keine Lösung.
Ok. Aber könnte man dann nicht eine Art Testroutine implementieren, die einen blockierenden Zugriff erkennen kann (Timeout, wie auch immer) und dann das blockierende Plasmoid pausieren und einen entsprechenden Dialog auf dem Bildschirm ausgeben?
Dir ist die Ironie in deinem Kommentar hoffentlich bewust. Jetzt muss man als anwender jedes Plasmoid, welches man von KDE-Look geladen hat debuggen und fixen.
Ich kenne sowas unter dem Ausdruck Broken-by-Design.
Was Martin damit ausdrücken versucht ist dass das Problem mittels menschlichen Zutuns behoben werden muss. Ein blockierender Aufruf kann leider oft nicht "von außen", z.B. durch einen anderen Thread, unterbrochen werden
Es ist daher notwendig, den blockierende Aufruf zu finden und durch etwas zu ersetzen, das eben nicht blockiert.
Hier helfen eventuell elementare Kenntnisse über Betriebssysteme weiter. Präemptives Multitasking erlaubt es, während ein Prozess/Thread blockiert (und nicht nur dann), einen anderen auszuführen. Komplizierter wird es mit unterschiedlichen Prioritäten, das ändert jedoch nichts am Grundprinzip. In der Regel werden innerhalb der gleichen Anwendung Threads gestartet, um zeitaufwändige oder semantisch voneinander unabhängige Aufgaben nebenläufig (blockadefrei) auszuführen. Menschliches Zutun wäre an dieser Stelle völlig unnötig hätte man eine vernünftige Architektur: separate Prozesse. Das von Dir beschriebene Problem tritt mit Plasma hingegen trotzdem auf, weil sich alle Plasmoids einen Prozess (nebenbei: auch Adressraum!) teilen müssen.
Das ist orthogonal zu dem was ich geschrieben habe.
Die ansich gute Idee, zu erkennen wenn etwas blockiert und dies dann zu beenden/unterbrechen, bzw. den Benutzer um eine derartige Entscheidung zu bitten, bedarf der grundsätzlichen Möglichkeit dies zu tun.
Nicht alle blockierenden Aufrufe können von einem anderen Thread oder Prozess aus unterbrochen werden.
Selbst im Falle, dass alle Plasma Applets in separaten Prozessen geführt werden würden könnte man daher nicht immer deren Blockaden unterbrechen.
Auch das ist nicht ganz korrekt. Hier helfen eventuell elementare Kenntnisse über Betriebssysteme weiter ;) Userspace Prozessen stehen abgesehen von Prioritäten nur wenige Möglichkeiten zur Verfügung das Scheduling zu unterbinden. Dies hat im Allgemeinen wenig mit irgendwelchen Nutzer-"Entscheidungen" zu tun. Selbst der Kernelspace ist heute mit zunehmender Anzahl von akzeptierten RT-Patches, und Threaded Interrupt handlern etc zu großen Teilen preemptive. Blockierendes Verhalten ist unerwünscht, und tritt bei sauberem Design selten auf. Was natürlich sein kann, ist das eine zwischen Prozessen gemeinsam genutzte Ressource ihre Kapazitäten erschöpft hat (Festplatten Bandbreite/, (KWIN / Xorg / DBUS)-CPU zu 100% ausgelastet,). Das ist jedoch *erheblich(!)* seltener der Fall, als ein temporärer Plasma-Freeze.
Nochmal: userspace Prozesse sind praktisch immer unterbrechbar (wenn Du anderer Meinung bist, bin ich gespannt mehr über entsprechende Beispiele zu erfahren), und wenn sie sich ohne Not gegenseitig blockieren ist es ein Bug.
Dies hat im Allgemeinen wenig mit irgendwelchen Nutzer-"Entscheidungen" zu tun.
Das war auch nur ein Beispiel für eine etwaige Reaktion des "Watch-Dogs". D.h. nicht immer ist eine automatische Unterbrechung erwünscht, z.B. habe ich schon bei mehreren Browsern gesehen, dass sie bei langen JavaScript Laufzeiten die Möglichkeit des Unterbrechens anbieten und es nicht einfach nach Gutdünken selbst tun.
Nochmal: userspace Prozesse sind praktisch immer unterbrechbar
Schon, aber meistens im Sinne von vorrübergehenend aus dem Scheduling genommen. Sicher, viele (vermutlich die meisten) Systemaufrufe sind ansich unterbrechbar, d.h. haben EINTR als mögliche Rückkehrursache.
Aber es gibt schon Gründe warum am Ende einer Systembeendigung zwei Stufen der Prozessbeendigung kommen, weil eben nicht alle Prozesse immer in der Lage sind auf das "BItte beenden" zu reagieren.
Es gibt sogar Fälle, wo selbst das Betriebsystem einen Prozess nicht vollständig und sauber entfernen kann, siehe Zombie-Prozesse.
Ja ähnliche Argumente gab es auch für Plugins innerhalb von Browsern. Tatsächlich startet z.B. Googles Chrome unzählige Prozesse - und dieser ist nicht gerade für "schlechte" Performance bekannt. Darüberhinaus ist es schon sehr lange möglich, mit mehreren Anwendungen Ausgaben auf dem gleichen X-Server/Monitor zu machen, ohne dass sie sich unverhältnissmässig stark blockieren. Zurück zu Plasma: In der Multicore - Ära gibt es ernsthaft noch die Vorstellung, dass eine single-threaded Anwendung performanter sein kann als mehrere Prozesse? Wegen Grafikoperationen, deren Zeitaufwand im Vergleich zu Massenspeicher/Netzwerkzugriffen etc verhältnissmäßig gering ausfällt, "Anwendungen" per default sequentiell auszuführen ist zumindest... *mutig*.
Stattdessen könnte man semantisch von einander unabhängige Plasmoide sauber in Prozesse trennen und nebenläufig ausführen... Der Desktop würde wegen einzelnen amok-laufenden Plasmoid nicht "stehen bleiben", crashende Plasmoide würden nicht den halben Desktop abschießen usw..
Aber viel besser ist natürlich sich darauf zu verlassen das alle Plasma Entwickler perfekten nicht blockierenden Code schreiben, der nie abstürzt - die KDE Welt ist nämlich perfekt.. Und im Zweifelsfall kann ja der Nutzer jederzeit den GDB anschmeißen, und prüfen welches der zahlreichen Plasmoide gerade alles andere lahmlegt.. Geil.
Es geht nicht um Performance, sondern um das Zusammenführen der Ausgabe.
Zum Beispiel dürfte jedem schon mal unter gekommen sein, dass Tastenkürzel des Browsers nicht mehr reagieren wenn das eingebettete Fenster des Flash-Plugins den Keyboard-Fokus bekommen hat (z.B. weil man auf etwas im Flash-"Fenster" geklickt hat.
Nicht umsonst wird daher auch von allen aktuellen Workspace Implementierungen einen anderen Ansatz für den "Systemtray" benutzen als den alten XEmbed Mechanismus.
Die zum Zeitpunkt des Designs von Plasma vorherrschenden Rahmenbedingungen haben gewissen Entscheidungen nötig gemacht. Eine Verbesserung der Umständen kann natürlich zu Verbesserungen im Design genutzt werden, ist aber nicht immer so einfach wie man das gerne hätte. Gibt ja auch sicher trifftige Gründe warum z.B. Firefox ebenfalls noch zentrales Rendering macht und WebKit erst in der zweiten Version davon gebraucht macht.
"es ist schlicht und einfach nicht möglich Plasmoide in eigene Prozesse zu packen, da sie zusammen zu die Grafik Ausgabe erstellen"
Es ist anerkennenswert, daß Sie die Entscheidungen der Plasma-Entwickler hier zu vertreten versuchen. Aber diese Aussage hier läßt mich wundern, ob Sie hier den richtigen Namen, den eines KWin-Entwicklers, nutzen, da dieser eigentlich weiß, daß man Grafikausgaben verschiedener Prozesse mischen kann.
Ich würde mal davon ausgehen, dass Martin besser als die meisten hier, mich eingeschlossen, weiß, welche Limitierungen dem Zusammenführen von Fensterinhalten gesetzt sind.
Vermutlich ist es schwierig bis nahe unmöglich mehrere Fenster synchron in Größe oder Position zu ändern, was z.B. bei Applet Fenstern in einem Leisten Fenster der Fall wäre.
Könnte mir auch vorstellen, dass das zwingend einen Compositor vorraussetzt.
Ok, alles was du schreibst sagt doch nur aus, dass das ganze Plasma-Design total kaputt ist. Wer ein Framework so plant, dass ein beliebiges Plasmoid alle anderen blockieren kann sollte die Finger von der S/W-Entwicklung lieber ganz lassen.
Ihre Art die KDE-Entwickler und im Speziellen Hr. Grässlin zuverteidigen grenzt an Götterverehrung. Mir konnte noch keiner erklären, warum dieses kaputte Design wirklich der einzige Weg sein sollte die Widgets zu Implementieren. In anderen DEs geht es ja auch, dass das UI durch einzelne Plugins/Erweiterungen/Apps/... nicht blockiert wird.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Feb 2013 um 16:27.
Mir konnte noch keiner erklären, warum dieses kaputte Design wirklich der einzige Weg sein sollte die Widgets zu Implementieren.
Ich bin mir ziemlich sicher, dass jeder Plasma Entwickler, jeder KWin Entwickler und auch andere Qt und KDE Entwickler, wie krake, in der Lage wären dir das zu erklären. Nur ist es schwierig und auf einer Plattform wie pro-linux nahezu unmöglich das korrekt zu erklären.
Was ich noch erwähnen will: interessanterweise wird das Design erst kritisiert, seit Chrome den Schwachsinn gestartet hat pro Tab einen eigenen Prozess zu starten. Ich betrachte das als falsches Design und nicht als Sicherheitsfeature, wie es oft dargestellt wird.
Klar wenn die Webseite WebKit crashen lässt, crashed nur ein Tab und nicht der ganze Browser. Nur WebKit sollte nicht crashen. Was Google hier im Design macht, ist eine Ermutigung das Backend nicht fehlerfrei zu haben - ist ja nicht so schlimm, dann stürzt halt ein Tab ab.
Meiner Meinung nach gehören Bugs gefixed und nicht herumgebaut. Was ich als valides Design ansehe, ist der WebKit 2 Ansatz, der die GUI in einem Prozess hält und das Laden/Rendern der Webseite in einen Prozess auslagert - ein Design wie es bei KDE übrigens seit Jahren üblich ist.
Dies ist auch ein Ansatz, der für libplasma2 angedacht ist um die DataEngines in eigene Prozesse auszulagern. Ob das wirklich umgesetzt wird, ist noch nicht entschieden, da es Vor- und Nachteile hat, die man gut gegeneinander abwägen muss.
Was das auch zeigt: das Design wie es dir vorschwebt, ist meiner Meinung total kaputt, wogegen du das Design das aktuell existiert als total kaputt bezeichnest. Du siehst hoffentlich, dass es nicht das eine perfekte Design gibt um Probleme umzusetzen.
Da sind wir wieder in der perfekten KDE Welt angekommen. Wie wärs wenn man die MMU Abschaltet, weil ein Zugriff auf den RAM über die TLB bis zu 30% Leistungseinbuße bringt? Wozu protected Memory wenn stattdessen einfach jeder fehlerfreie Software schreiben könnte oder gefälligst seine Bugs fixt? Als Musterbeispiel haben wir ja KDEs Single-Process Plasma, über das es sicher noch nie Beschwerden gab. Andere Erfolgreiche Vertreter dieser Utopie waren MSDOS und Windows 3.1. Zweifelsfrei sehr erfolgreich und ihrer Zeit wohl zu weit voraus, als dass diese Konzepte heute noch verfolgt werden könnten.
Man sollte einfach immer Sicherheit gegen Performance tauschen, und wenn die Software robust ist (ala chrome), also der Ausfall einer Teilkomponente nicht gleich alles zerschießt, ist es offensichtlich schlechtes Design, da fehlerfreie Software (die, wie wir alle von unseren geliebten Plasmoids gelernt haben, möglich ist!) nicht gefördert wird.
Schließlich befolgt KDE einfach das bewährte UNIX Design, alles mit Threads im gleichen Adressraum, KIO slaves anstelle von Dateisystemen und hört auf seine Nutzer denn im Mindstorm zu "Plasmoids as separate Processes" hat sich ja die überwiegende Mehrheit dagegen ausgesprochen. Aus .. technischen Gründen.
Hmm, Threads werden üblicherweise nicht als "bewährtes UNIX Design" betrachtet und werden auch noch nicht so häufig eingesetzt. KIO dagegen ist klassischer UNIX Ansatz mit spezialiserten Prozessen für bestimmte Aufgaben.
Klar wenn die Webseite WebKit crashen lässt, crashed nur ein Tab und nicht der ganze Browser. Nur WebKit sollte nicht crashen. Was Google hier im Design macht, ist eine Ermutigung das Backend nicht fehlerfrei zu haben - ist ja nicht so schlimm, dann stürzt halt ein Tab ab.
Ich denke das ist in diesem Fall schon OK, weil die Inhalte einfach aus so vielen verschiedenen Quellen kommen können und die Komplexität der Inhalte mitterweile ein Niveau erreicht hat, wo man Bugs praktisch garantieren kann.
Abgesehen davon setzt Chrome dafür doch auch den WebKit2 Ansatz ein, oder?
ich weiß nicht ob Chrome mittlerweile umgestellt hat. Als es initial veröffentlicht wurde, war es ein Design mit ein Prozess pro Tab. Der WebKit 2 Ansatz kam erst später (inspiriert von Chrome AFAIK).
Chromium verwendet nicht mehr 1 Prozess pro Tab sondern mehrere Tabs proo prozess das kannst du dir mit dem Chrome TaskManager (Umschalt + esc) ansehen bei schlechten Javascripten in einer Seite blockieren jetzt auch mehre Seiten und chrashen gemeinsam.
Von Entwickler-Schlumpf am Di, 19. Februar 2013 um 10:24 #
Chrome verwendet WebKit1. WebKit2 ist lediglich ein thin-layer über WebKit1 bzw WebCore der die Prozessabstraktion implementiert die in Chrome auf höhere Eben bereits gegeben ist. Man plant aber wohl langfristig auf WebKit2 zu wechseln.
Ok, alles was du schreibst sagt doch nur aus, dass das ganze Plasma-Design total kaputt ist.
Design ist nicht nur eine Frage der theoretischen Möglichkeiten sondern auch der real existierenden Rahmenbedingungen. Daher spricht man im allgemeinen auch von Designentscheidungen, d..h. auf Grund gewisser Tatsachen hat man sich für eine bestimmte Möglichkeit entschieden.
Solche Entscheidungen könnten zu einem späteren Zeitpunkt wieder neu bewertet werden, was aber nicht notwendigerweise bedeutet, dass sie anfangs falsch waren.
Wer ein Framework so plant, dass ein beliebiges Plasmoid alle anderen blockieren kann sollte die Finger von der S/W-Entwicklung lieber ganz lassen.
Praktisch fast keine Software ist derzeit so entworfen, dass Plugins in eigenen Prozessen laufen. Selbst Browser machen das noch nicht sehr lange und selbst da nicht bei allen Arten von Plugins (z.B. Extensions).
In anderen DEs geht es ja auch, dass das UI durch einzelne Plugins/Erweiterungen/Apps/... nicht blockiert wird.
Beispiele? Meines Wissens benutzt selbst Chrome nur Prozesse für Webinhalte und nur einen pro Tab (also keine Komposition aus Teilen, die von verschiedenen Prozessen geliefert werden).
Die Information über Chrome ist nicht ganz korrekt, siehe hierzu: "Browser plug-ins, such as Flash and Silverlight, are also executed in their own processes, and some plug-ins like Flash even run within Chromium's sandbox. " Quelle: http://www.chromium.org/developers/design-documents/process-models
Das die Entscheidung nicht "falsch" war sieht man ja alleine schon daran, dass KDE überhaupt funktioniert. Dass sie nicht "optimal" war sieht man an besseren Gegenbeispielen, über die es auch viel in einschlägiger Literatur zu lesen gibt.
"Browser plug-ins, such as Flash and Silverlight, are also executed in their own processes, and some plug-ins like Flash even run within Chromium's sandbox. "
Klar, Browserplugins out-of-process machte sogar Konqueror schon immer.
Ich meinte selbst Chrome benutzt nur einen Prozess pro Seite. D.h. selbst wenn z.B. ein Banner von einem anderen Server kommt als die Seite ansich, oder ein IFrame eingebettet ist, oder Inhalte in verschiedene CSS Boxen eingebunden wird, dann wir meines Wissens dennoch nur ein WebProcess dafür verwendet.
Ich denke das sogar mache Teile des UIs, selbst dann wenn sie über Plugins realisiert sind, als Teil der eigentliche Hauptanwendung gezeichnet werden, z.B. Toolbars, u.ä.
Ich beziehe mich da hauptsächlich auf meine Erfahrungen mit der WebKit2 Architektur, unter der Annahme, dass Chrome entweder darauf oder auf einen Vorgänger davon aufbaut.
Und dort zeichnet der Web Prozess den gesamten Inhalt und der UI Prozess stellt ihn lediglich dar. Für gewisse Sachen wird sogar lediglich eine Nachricht an den UI Prozess gesandt und der macht dann das entsprechende UI, z.B. JavaScript Dialoge, Dateiauswahl, usw.
Wenn der UI Prozess den Inhalt z.B. verschiebt und der Inhalt eine freischwebende Box enthält, muss der Web Prozess neu zeichnen, weil eben die Box kein eigenständiger Inhalt ist und daher nicht einfach vom UI Prozess neu positioniert werden kann.
Das liegt definitiv nicht am Kernel. Asynchrones IO / Forks & Threads waren schon immer möglich, es besteht Kernelseitig keine Notwendigkeit Anwendungen zu blockieren, die nicht auf die *gleiche* Ressource zugreifen müssen. Beim USB Beispiel, werden wahrscheinlich alle Anwendungen blockieren, die auf den USB Stick zugreifen - bei Plasma hingegen blockiert unnötigerweise *Alles*.
Nun, der Grund dafür könnte schlichtweg sein daß Operationen auf der graphischen Benutzeroberfläche streng sequentiell sein müssen, wenn man nicht das Chaos heraufbeschwören will. Dies lernt man bei der Qt- oder Java-Programmierung schnell. Direkte Zeichenoperationen aus nebenläufigen Prozessen schreien nach Abstürzen bzw. "komischen" Verhalten, gerade beim X-Server. Wenn dort ein anderer Prozess in die Zeichenoperationen "hereinquatscht" entstehen die merkwürdigsten Effekte. Aber richtig: besser wäre es schon, wenn man eine Art Warteschlangenverarbeitung einbauen würde, welche von nebenläufigen Prozessen bedient wird.
kleiner Hintergrund hierzu. Als Plasma designed wurde gab es in Qt noch nicht die raster Paint Engine. Eine QPixmap war an eine XPixmap gebunden und der zeichnende Zugriff auf eine QPixmap vom nicht-GUI Thread ist nicht erlaubt, da XLib multi threading nicht wirklich erlaubt. Man konnte zwar mit QImage in einem Hintergrundthread zeichnen, aber das bedeutet ständiges kopieren zwischen XServer und Anwendung.
Heutzutage sieht das anders aus: mit QtQuick 2 wird immer in einem Hintergrundprozess gezeichnet.
Das ist viel hilfreicher als die ganzen "Geht nicht. Es gibt Gründe." oder auch "Muss aber gehen. Habe ich gehört." Platitüden. Ich jedenfall freue mich jederzeit über solche Hintergrundinformationen, welche ja sogar noch einen positiven Ausblick für die Zukunft bieten
edesmal wenn mir die Netzwerkverbindung abreißt und ich ein NFS-Share gemountet habe (z.B. nach dem Aufwachen aus dem Suspend) sind alle Plasma-Widgets blockiert.
Ein wichtiger Punkt im Zusammenhang mit NFS und GUIs im Allgemeinen, also abgesehen vom Verbesserungspotential in der Applet Implementierung, ist, dass Kernel Mounts meistens die Asynchronität der Verbindung verstecken.
D.h. für einen Userland Prozess ist oft nicht erkennbar, dass eine Datei nicht lokal vorliegt und somit nicht mit dafür üblichen Annahmen benutzt werden kann.
Die meisten Anwendung greifen direkt auf lokale Dateien zu, d..h ohne dafür extra einen Thread zu starten, weil bei lokalen Dateien kurze Zugriffszeiten erwartet werden.
Das trifft dabei auch nicht nur GUI Anwendungen, in unterbrochener NFS Mount kann auch Systemprogramme wie cp oder mv hängen lassen (oft so, dass sie nicht mal mit CTRL+C abgebrochen werden können). Bei GUI Anwendungen fällt es in Regelfall nur schneller auf.
Das beobachtete Problem ist hier nicht, dass eine Anwendung von der Ressource (in diesem Fall eine über NFS mount zugänglich gemachte Datei) die sie benötigt blockiert wird. Das ist unvermeidbar. Vielmehr werden ohne Not *alle* Plasmoids blockiert unabhängig von ihren tatsächlich benötigten Ressourcen, obwohl im Zweifelsfall nur wenige (eine?) hiervon betroffen sein *müsste*. Aufgrund der gegenwärtigen Architektur ist es auch schwierig den Verursacher ausfindig zu machen, da jedes nicht kooperative plasmoid alle anderen auf gleiche Weise beeinträchtigt. Wir haben hier ein technisches Problem, kein Entwickler muss gesteinigt werden. Fehler by (unachtsamen) Design müssen aber nicht unnötig verteidigt werden; Sonst wird sich die Situation ja nie bessern
das ist aber wirklich ein leicht zu behebendes Problem. Gdb drauf, schauen wo es blockt, Plasmoid entfernen, bug aufmachen.
Wie ich jetzt schon mehrmals geschrieben habe: Bugs gehören gefixed, nicht workarounded. Ein Design bei dem ein Element blockieren darf, ist ein workaround. Der Zugriff muss asynchron erfolgen egal ob Framework blockiert wird oder nicht.
Diese Argumentation ist genauso als wolle man sagen, dass Webseiten, welche Fehlerhaften JavaScript-Code enthalten den ganzen Browser (also alle anderen Tabs) blockieren dürfen. Wenn sowas passiert, muss die Seite gefixt werden und nicht der Browser.
Auf kde-look.org werden nach was ich auf die schnelle sehe >580 Plasmoides angeboten. Dies wohl großenteils von Hobby-Programmierern erstellten Plasmoieden sollen also alle perfekt und fehlerfrei geschrieben sein? Wie soll ein Nutzer (ohne etwas von Programmierung zuverstehen) rausfinden welches Plasmoid für sein kaputten Desktop verantwortlich ist? Wie soll er es dann fixen? Was wenn der Entwickler des Plasmoids sich nichtmal im Stande sieht das Problem zu beheben weil ihm das KnowHow fehlt?
siehe anderer Kommentar hier im Thread. Auf kde-look sind hoffentlich keine C++ Plasmoide, sondern scripted Plasmoide, die Plasma nicht blockieren sollten (wenn das doch ist, dann ist das ein Bug im Framework).
Wir reden hier also nur von Plasmoiden, welche von der KDE Community herausgegeben wurden und ja da ist gdb die einzige valide Lösung.
Auf kde-look.org scheinen >260 Plasmoide als binary gelistet zu werden. Ich weiß jetzt nicht ob dies alle in C++ implementiert wurden oder ob es auch andere Möglichkeiten gibt ein Plasmid als binary bei kde-look zu platzieren.
Gibt es ein Regelwerk, welches besagt, dass Plasmiden nur dann in C++ implementiert werden dürfen/sollen wenn diese direkt von der KDE-Community im Rahmen des KDESC gepflegt werden?
Und wie schafft ihr es, dass bei gescripteten Plasmoiden dies nicht auftritt?
Wird für das gescriptete Plasmoid ein eigener Prozess gestartet (der Interpreter)? Wenn ja, wiso kann dieser dann ohne Probleme Zeichnen aber für ein als Prozess gestartetes (C++) Plasmoid sollte dies nicht möglich sein?
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Feb 2013 um 18:31.
Von Entwickler-Schlumpf am Di, 19. Februar 2013 um 10:55 #
Pakete wie rpm, deb sind binary, tar.gz auch. Da die meisten oder viele Plasmoids aus mehr als eine Datei bestehen werden sie wohl gepackt beim hochladen.
Von Entwickler-Schlumpf am Di, 19. Februar 2013 um 11:13 #
Und wie schafft ihr es, dass bei gescripteten Plasmoiden dies nicht auftritt?
Möglicher Ansatz; Ein eigener Prozess in dem scripted Plasmoids laufen, als kein eigener Prozess pro Script-Plasmoid weil zu teuer aber ein eigener Prozess für alle Script-Plasmoids. Das Ergebnis wird als eigene Anwendung(en) samt Fenster gezeichnet. Das Fenster ist fensterlos, durchsichtig und wird vor dem WM "versteckt". Ein Proxy Plasma-Applet, das im selben Prozess wie Plasma läuft, steuert das Fenster um es in die richtige Position zu bringen, Eingaben um-/weiterzuleiten, ...
Mit QtQuick wird sich sowieso so einiges ändern und hat aich schon geändert weil dort ein eigener Renderthread und Scenegraph zum Einsatz kommt. Damit stellt sich die Frage nach der Legitimität von Prozessplittung wenn Crashfrei als Voraussetzung angenommen wird die mit Scripten einfacher zu garantieren ist.
Hm, also dürfen nicht Core-KDE-Community-Menschen kein C++ verwenden, um z.B. DataEngines oder anderes zu schreiben? So toll Javascript sein kann, aber manche Sachen, die man einbinden möchte, liegen nur per C/C++-Lib zur Anbindung bereit. Noch ne Uhr oder einen RSS-Reader oder ne Wetter-App, nee, das sind die einfachen Sachen.
Und wieso dürfen dann Plasmoide überhaupt in C++ geschrieben werden? Denn der Traum von den Bug-freien Plasmoids, den kann ich nicht mitträumen, klar sollten Bugs gefixt werden, aber wie schnell geschieht das? Und wie schnell landet das auch beim Nutzer?
Die Argumentation, nur C++-Plasmoids hätten solche Probleme, und die würden auch gründlich geprüft bevor sie beim Anwender ankommen, finde ich sehr idealistsisch, aber leider realitätsfern Überzeugt mich nicht, würde mich freuen, wenn Ihr eine Möglichkeit findet, Plasmoids transparent in eigenen Prozessen laufen zu lassen, mindestens die "absturzgefährdeten". Denn was ist z.B. der Unterschied zwischen KCalc und dem Calculator Plasmoid? KCalc läuft auch in nem eigenen Prozess. Und könnte ähnlich eingebettet werden wie der Calculator Plasmoid. Entsprechende D-Bus API, um KCalc's Erscheinungsbild je nach Einbettung anzupassen, voilà.
C++ Plasmoide müssen kompiliert werden und an die richtige Stelle installiert werden. Sofern du nicht gerade weißt welche env Variablen du anpassen musst, läuft das auf installieren mit root-Rechten hinaus.
Im Endeffekt bedeutet das, dass ein Plasmoid von einer Distribution angeboten werden muss - ich hoffe doch sehr, dass du nicht einfach Pakete von $IRGENDWO mit root Rechten installierst (nein kde-look ist keine vertrauenswürdige Quelle).
Wenn eine Distribution das paketiert, dann erwarte ich zumindest eine gewisse QA die auch sein kann bei den Plasma Entwicklern nachzufragen: "schaut mal bitte drauf, ist das OK?"
Ich denke da vor allem an Inhouse-Plasmoids (nicht jeder will/muß seinen Spezialkram mit der Welt teilen, Teilen ist auch Verantwortung). Niemand kann garantieren, daß die nicht doch hier und ne Macke haben. Nun. daas gilt selbst für die von KDE ausgelieferten. Auch Profis schlampen mal, C++ ist da ungnädig. Als KDE-Community-Entwickler sollten Sie das ja wissen, all die bugs.kde.org-Einträgen schaffen einen kleinen Realitätsabgleich. Und im Produktiv-Einsatz ist es nicht akzeptabel, daß dann gleich die halbe Umgebung hängt. Da braucht man Stabilität. RAM ist billig im Vergleich zum Stundenausfall. Deswegen ist die derzeitige Umsetzung Mist. Welch historischen Gründe es auch gibt. Und dann ist ja auch nicht der ganze Workspace in einem Prozeß, das hatte ja sicher auch gute Gründe. Und diese Gründe sind für manche eben auch bei den Plasmoids wichtig. Niemand zwingt Euch. Ist nur ne Rückmeldung. Der Rest ist ja ziemlich nett (positiv gemeint). Aber das hier mit dem einen Prozeß ist und bleibt Mist, für mich und scheinbar ein paar andere.
Nicht notwendigerweise, wie du ja schon in deinem anderen Beitrag geschrieben hast (z.B. in Thread, unter Benutzung asynchroner I/O API). Nur wird derzeit meistens unter der Annahme gearbeitet, dass lokale Dateien mehr oder weniger blockadefrei benutzt werden können.
Fehler by (unachtsamen) Design müssen aber nicht unnötig verteidigt werden; Sonst wird sich die Situation ja nie bessern
Soweit ich das sehe wurde der Fehler auch nicht im geringsten verteidigt. Praktisch jeder Beitrag stimmt darin überein, dass was auch immer die Blockade auslöst auf nicht-blockierende Art und Weise zu ändern sei, also die Situation gezielt zu verbessern.
Ich würde jetzt auch nicht davon ausgehen, dass die Architektur für immer in Stein gemeisselt ist, aber man darf nicht aus den Augen lassen, dass die Komposition von Grafiken verschiedener Prozesse und die umgekehrte Eingabeverteilung keine so einfach Sache ist und auch nicht so weit verbreitet.
Klar, Wayland ist in der Lage das zu tun, aber auch viel neuer als der Startzeitpunkt der Plasma Entwicklung.
Klar, Wayland ist in der Lage das zu tun, aber auch viel neuer als der Startzeitpunkt der Plasma Entwicklung.
Das ist das zentrale Argument hier für alle, die meinen, dass man Plasmoide in eigenem Prozess haben könnte und das Grafikproblem irgendwie hinbiegen kann.
Das aktuelle Design von Plasma wurde etwa um 2006/2007 entworfen. Zum Vergleich (aus Wikipedia):
The first version of Compiz was released as free software by Novell (SUSE) in January 2006 in the wake of the (also new) Xgl.
Mal eben Fenster über einen Compositor zusammenzusetzen war damals noch nicht. KWin unterstützt OpenGL Compositing seit 2008, seit 2009 standarmäßig aktiviert, aber selbst heute hat man beim Startup zuerst einen nicht composited desktop und Compositing kann zur Laufzeit ausgeschaltet werden. Was man auch berücksichtigen muss: der WM müsste diese Plasma Fenster ignorieren. Klar kann man in KWin einbauen, aber was ist mit Nutzern anderer WMs?
Compositing unter X11 fällt daher mal für Grafikdarstellung einfach raus. Was bleibt: Xembedd? Eine Technologie, die bei allen verhasst ist. Shm? Will wohl auch hoffentlich keiner.
Erst Wayland ermöglicht es dass man aus mehreren Prozessen das zusammenbauen könnte. Ob das für die Usecases von Plasma sinnvoll ist, ist eine andere Frage, ich würde mal "nö" sagen, da wir da mit QtQuick2 eigentlich bekommen was wir wollen.
Mit dem Plasma-Design-Desaster von Seigo kann ich keine Aussage von ihm mehr ernst nehmen.
Wie kommt man auf die schwachsinnige Idee alle Plasma-Widgets in einem Prozess zu packen? Jedesmal wenn mir die Netzwerkverbindung abreißt und ich ein NFS-Share gemountet habe (z.B. nach dem Aufwachen aus dem Suspend) sind alle Plasma-Widgets blockiert.
Er soll erstmal den Scheiß den er verbrochen hat gerade biegen bevor er laute Kritik an anderen übt.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Feb 2013 um 12:33.Nicht nur das, nachdem er mit seinem Vivaldi-Disaster schon wer weiß wie oft in den Medien für Schlagzeilen sorgte und viele Fans vor den Kopf stieß, ist er eigentlich der letzte der sich da über Canonical das Maul zerreißen sollte. Seine vermeintliche Kritik, riecht hier ehe nach Neid. Die schaffen das was er nicht schaffte.
Was wäre denn anders, wenn jedes Plasmoid in einem separaten Prozess laufen würde und die Netzwerkverbindung zum NFS-Server würde dann abbrechen?
Verstehe ich das richtig, Du hast Dein home per NFS eingebunden, d.h. Dein .kde4, .local und .share liegen auf einem NFS-Share?
Ich habe das noch nicht gemacht, da kein Bedarf, aber hast Du da nicht Performance Probleme mit Akonadi und Nepomuk, oder wie verhält sich das da?
Nein, ich habe nicht mein Home auf dem NFS-Share, sondern in /mnt/server. Kein plan was darauf zugreifen will aber alle Plasma-Widgets hängen, einschließlich dem Networkmanager-Widget.
Uuups, da habe ich mich dämlich ausgedrückt. Home liegt auf dem lokalen Dateisystem. Das NFS-Share ist nach /mtn/server gemountet somit sollte niemand damit probleme haben.
Da gibt es aber keinen Grund zu blockieren dann. Wenn das bei dir blockiert klingt das nach einem Bug in einem Plasmoid. Es wäre toll wenn du dem nachgehen könntest und dann einen Bug Report aufmachst -> bugs.kde.org
Naja, daß ein Bug in einem Plasmoid gleich alles blockieren kann, das bleibt aber ein Design-Fehler von Plasma.
Plasmoids, gerade von Dritten oder selbstgemachte, können nun mal Fehler haben (welcher Code ist schon fehlerfrei, jedenfalls von Beginn an). Es ist nicht verständlich, warum das alles in einem Prozeß laufen soll. Gibt es irgendwo eine mit Untersuchungsergebnissen unterfütterte Begründung, oder ist das mal so aus dem Blauen festgelegt worden und wird seitdem als Heiligtum behandelt, das nicht ohne vermeintlichen Gesichtsverlust verändert werden kann?
Ein gutes System muß in der Lage sein, auch mit fehlerhaften Komponenten weiterhin so gut wie möglich zu funktionieren.
für 3rd party propagieren wir die Verwendung von Scripting Technologien wie QML, JavaScript oder Python. Mit diesen sollte das nicht passieren.
Mit C++ kannst du das auf Grund der Sprache und der Möglichkeiten der Sprache einfach nicht verhindern. Wenn du dir von extern ein C++ Plasmoid installierst, musst du dir halt auch bewusst sein, dass es problematisch sein kann. Deshalb ist das ja auch nicht gerade einfach so was zu installieren. Es gibt Distributionen, die so etwas paketieren und dann ist es deren Aufgabe die Qualitätssicherung durchzuführen.
Im Falle von Plasmoiden, die von der KDE Community veröffentlicht werden, gilt natürlich, dass wir Bugs beheben und nicht herumprogrammieren. Wenn es einen blockierenden Zugriff gibt, dann muss der beseitigt werden und nicht ein kompliziertes Framework drumrumgebaut werden.
Also sorry mgraesslin, das ist der gleiche Witz wie damals unter OS/2 Warp. Sobald irgendein Programm blockiert, und da alles über eine einzige Message Queue lief, hing der komplette Desktop und man durfte den Rechner neu starten...
Das ist einfach sträflich. Alle Komponenten müssen "parallel" laufen, ohne dass es andere Teile blockieren kann. Wozu gibt es Multitasking?
Hallo. Also unter KDE3 war genau das der Fall. Der Desktop hat sich aus verschiedenen Prozessen zusammengesetzt. Einer für den Hintergrund, einer für die Taskleiste, einer für die Desktop-Widgets, usw.
Diese Design hat sich jedoch als Problematisch erwiesen da zum einem Unmengen an Synchronisation nötig war und die einzelnen Komponenten so weniger gemeinsame Basis hatten. Es gab auch entsprechende Performance -Analysen die zum Schluß gekommen sind, daß eine Reduzierung der Prozesse Performancevorteile bringt. Leider ist der entsprechende Artikel von Lubos Lunak über KDE Performance Analysis mittlerweile aus dem Internet verschwunden. Hat jemand zufälligerweise eine Kopie oder mehr Erfolg bei der Suche?
die posts sind alle noch da, nur die Domain hat sich geändert. Ist jetzt blogs.kde.org
Ich habe hier das gleiche Problem. Es braucht nur irgendein NFS-Mount im System zu existieren, der gerade nicht erreichbar ist und schon steht hier der komplette plasma-desktop.
Bei mir sind einfach nur verschiedene Datenverzeichnisse in /mnt gemountet.
/home mitsamt den kde-eigenen oder sonstigen Config-Verzeichnissen (.kde4 / .local, etc) sind alle lokal und nicht auf NFS.
Wenn mein Rechner z.B. aus dem Suspend aufwacht, ist plasma-desktop solange unsichtbar (man sieht nur das Hintergrundbild und noch offene Fenster, die man auch schon bedienen kann), bis die Netzwerk-Verbindung wieder steht.
Ich kenne dies Phänomen von Samba. Wenn die Freigabe plötzlich nicht mehr existiert oder die Netzverbindung weg ist, dann friert mein Desktop für ca. 3 Minuten ein. Ähnlich muss es also auch mit NFS sein.
Liegt das wirklich an Plasma oder vielleicht doch eher an was anderem? Also wenn ich auf externe USB-Datenträger zugreife, ist während der gesamten Operation das System manchmal nicht mehr bedienbar. Und das liegt bei mir nicht an Plasma. Das hat mich schon immer sehr gestört.
Ich habe das gleiche Problem sowohl in GNOME als auch in Unity oder XFCE. Wenn ein Netzwerk-Share nicht ereichtbar ist, geht am Desktop praktisch nichts mehr. Das ist wohl eher kein KDE-Problem.
Jupp, wenn ein Samba share eingehängt ist, das nicht mehr erreichbar ist, ohne dass es ausgehängt wurde, hängen mindestens kwin und plasma-desktop ein paar Minuten. Das ist schon länger so, weshalb ich zum Beispiel davfs2 nicht verwende.
Ok, dir gefällt die Software von Seigo nicht.
Was hältst du aber von seiner Kritik an Canonical? Ist die berechtigt? Darum geht es doch hier.
Haha, dein Antwort macht zu viel Sinn um relevant zu sein in dieser Diskussion.
Ich habe unter den 95 Beiträgen tatsächlich keinen einzigen gefunden, der sachlich auf die Kritik an Canonical eingeht
Naja, ich kann heute Nacht trotzdem gut schlafen...
Wahrscheinlich bei *jeder* "blockierenden" Operation, wie Festplattenzugriff oder for-schleifen. KDE Plasma ist erschreckend ranzig. Windows 3.1. Feel für Linux.
OMG, was haben denn Festplattenzugriffe oder Programmiersprachenkonstrukte wie for-Schleifen mit Plasma zu tun?
Kläre uns Unwissenden bitte mal auf.
Was definitiv nicht toll ist, dass Dateioperationen auf Festplatten oder USB Speichermedien das ganze System extrem blockieren können, was aber wohl eher am Kernel liegt als an Plasma.
Na ganz einfach: KDE Plasmoids führen wie alle Anwendungen oder Plugins auch Code aus, sind jedoch per default in *einem* Thread, und setzten auf kooperatives multitasking, wie zu windows 3.1 Zeiten (oder Plugins in älteren? Firefox Versionen).
Siehe hier: http://forum.kde.org/viewtopic.php?f=90&t=45255
Während ein Plasmoid läuft, blockieren alle anderen. Nimmt sich eines jetzt zu viel Zeit - wie etwa bei einer langen for-schleife, einem Netzwerk - oder Festplattenzugriff, "hängt" sich KDE für eine Weile auf. Sehr schade, denn abgesehen von Aarons(?) schwachsinniger Software Architektur scheint KDE eigentlich ganz vernünftig zu sein.
Aha, danke für die Info. interessant. Ist von 2009. Ich verwende auch Plasmoide, allerdings konnte ich das Phänomen noch nicht beobachten. Wäre mal interessant zu wissen, welche von Dir genutzten Plasmoide so eine Blockierung auslösen? Ansonsten ist es wohl abzuwägen, was besser ist, jedes Plasmoid in einen eigenen Prozess zu packen würde natürlich auch viel Overhead und damit Recourcenverschwendung mit sich bringen. Ich kann es nicht beurteilen, was da besser wäre.
es ist schlicht und einfach nicht möglich Plasmoide in eigene Prozesse zu packen, da sie zusammen zu die Grafik Ausgabe erstellen (das steht so auch in dem Thread).
Wenn etwas blockiert, dann muss man das identifizieren und den blockierenden Zugriff entfernen (Stichwort: Thread). Prozesse sind da keine Lösung.
Ok. Aber könnte man dann nicht eine Art Testroutine implementieren, die einen blockierenden Zugriff erkennen kann (Timeout, wie auch immer) und dann das blockierende Plasmoid pausieren und einen entsprechenden Dialog auf dem Bildschirm ausgeben?
Ja, nennt sich gdb und muss der Nutzer verwenden, wenn es blockiert
Dir ist die Ironie in deinem Kommentar hoffentlich bewust. Jetzt muss man als anwender jedes Plasmoid, welches man von KDE-Look geladen hat debuggen und fixen.
Ich kenne sowas unter dem Ausdruck Broken-by-Design.
Ja, finde selbst ich milde gesagt "bedenklich"...
Was Martin damit ausdrücken versucht ist dass das Problem mittels menschlichen Zutuns behoben werden muss.
Ein blockierender Aufruf kann leider oft nicht "von außen", z.B. durch einen anderen Thread, unterbrochen werden
Es ist daher notwendig, den blockierende Aufruf zu finden und durch etwas zu ersetzen, das eben nicht blockiert.
Hier helfen eventuell elementare Kenntnisse über Betriebssysteme weiter. Präemptives Multitasking erlaubt es, während ein Prozess/Thread blockiert (und nicht nur dann), einen anderen auszuführen. Komplizierter wird es mit unterschiedlichen Prioritäten, das ändert jedoch nichts am Grundprinzip. In der Regel werden innerhalb der gleichen Anwendung Threads gestartet, um zeitaufwändige oder semantisch voneinander unabhängige Aufgaben nebenläufig (blockadefrei) auszuführen.
Menschliches Zutun wäre an dieser Stelle völlig unnötig hätte man eine vernünftige Architektur: separate Prozesse.
Das von Dir beschriebene Problem tritt mit Plasma hingegen trotzdem auf, weil sich alle Plasmoids einen Prozess (nebenbei: auch Adressraum!) teilen müssen.
Das ist orthogonal zu dem was ich geschrieben habe.
Die ansich gute Idee, zu erkennen wenn etwas blockiert und dies dann zu beenden/unterbrechen, bzw. den Benutzer um eine derartige Entscheidung zu bitten, bedarf der grundsätzlichen Möglichkeit dies zu tun.
Nicht alle blockierenden Aufrufe können von einem anderen Thread oder Prozess aus unterbrochen werden.
Selbst im Falle, dass alle Plasma Applets in separaten Prozessen geführt werden würden könnte man daher nicht immer deren Blockaden unterbrechen.
Auch das ist nicht ganz korrekt. Hier helfen eventuell elementare Kenntnisse über Betriebssysteme weiter ;)
Userspace Prozessen stehen abgesehen von Prioritäten nur wenige Möglichkeiten zur Verfügung das Scheduling zu unterbinden. Dies hat im Allgemeinen wenig mit irgendwelchen Nutzer-"Entscheidungen" zu tun.
Selbst der Kernelspace ist heute mit zunehmender Anzahl von akzeptierten RT-Patches, und Threaded Interrupt handlern etc zu großen Teilen preemptive. Blockierendes Verhalten ist unerwünscht, und tritt bei sauberem Design selten auf. Was natürlich sein kann, ist das eine zwischen Prozessen gemeinsam genutzte Ressource ihre Kapazitäten erschöpft hat (Festplatten Bandbreite/, (KWIN / Xorg / DBUS)-CPU zu 100% ausgelastet,). Das ist jedoch *erheblich(!)* seltener der Fall, als ein temporärer Plasma-Freeze.
Nochmal: userspace Prozesse sind praktisch immer unterbrechbar (wenn Du anderer Meinung bist, bin ich gespannt mehr über entsprechende Beispiele zu erfahren), und wenn sie sich ohne Not gegenseitig blockieren ist es ein Bug.
Das war auch nur ein Beispiel für eine etwaige Reaktion des "Watch-Dogs". D.h. nicht immer ist eine automatische Unterbrechung erwünscht, z.B. habe ich schon bei mehreren Browsern gesehen, dass sie bei langen JavaScript Laufzeiten die Möglichkeit des Unterbrechens anbieten und es nicht einfach nach Gutdünken selbst tun.
Schon, aber meistens im Sinne von vorrübergehenend aus dem Scheduling genommen.
Sicher, viele (vermutlich die meisten) Systemaufrufe sind ansich unterbrechbar, d.h. haben EINTR als mögliche Rückkehrursache.
Aber es gibt schon Gründe warum am Ende einer Systembeendigung zwei Stufen der Prozessbeendigung kommen, weil eben nicht alle Prozesse immer in der Lage sind auf das "BItte beenden" zu reagieren.
Es gibt sogar Fälle, wo selbst das Betriebsystem einen Prozess nicht vollständig und sauber entfernen kann, siehe Zombie-Prozesse.
Sorry, aber das ist alles andere als usable.
Ja ähnliche Argumente gab es auch für Plugins innerhalb von Browsern. Tatsächlich startet z.B. Googles Chrome unzählige Prozesse - und dieser ist nicht gerade für "schlechte" Performance bekannt. Darüberhinaus ist es schon sehr lange möglich, mit mehreren Anwendungen Ausgaben auf dem gleichen X-Server/Monitor zu machen, ohne dass sie sich unverhältnissmässig stark blockieren.
Zurück zu Plasma: In der Multicore - Ära gibt es ernsthaft noch die Vorstellung, dass eine single-threaded Anwendung performanter sein kann als mehrere Prozesse? Wegen Grafikoperationen, deren Zeitaufwand im Vergleich zu Massenspeicher/Netzwerkzugriffen etc verhältnissmäßig gering ausfällt, "Anwendungen" per default sequentiell auszuführen ist zumindest... *mutig*.
Stattdessen könnte man semantisch von einander unabhängige Plasmoide sauber in Prozesse trennen und nebenläufig ausführen... Der Desktop würde wegen einzelnen amok-laufenden Plasmoid nicht "stehen bleiben", crashende Plasmoide würden nicht den halben Desktop abschießen usw..
Aber viel besser ist natürlich sich darauf zu verlassen das alle Plasma Entwickler perfekten nicht blockierenden Code schreiben, der nie abstürzt - die KDE Welt ist nämlich perfekt.. Und im Zweifelsfall kann ja der Nutzer jederzeit den GDB anschmeißen, und prüfen welches der zahlreichen Plasmoide gerade alles andere lahmlegt.. Geil.
Es geht nicht um Performance, sondern um das Zusammenführen der Ausgabe.
Zum Beispiel dürfte jedem schon mal unter gekommen sein, dass Tastenkürzel des Browsers nicht mehr reagieren wenn das eingebettete Fenster des Flash-Plugins den Keyboard-Fokus bekommen hat (z.B. weil man auf etwas im Flash-"Fenster" geklickt hat.
Nicht umsonst wird daher auch von allen aktuellen Workspace Implementierungen einen anderen Ansatz für den "Systemtray" benutzen als den alten XEmbed Mechanismus.
Die zum Zeitpunkt des Designs von Plasma vorherrschenden Rahmenbedingungen haben gewissen Entscheidungen nötig gemacht. Eine Verbesserung der Umständen kann natürlich zu Verbesserungen im Design genutzt werden, ist aber nicht immer so einfach wie man das gerne hätte. Gibt ja auch sicher trifftige Gründe warum z.B. Firefox ebenfalls noch zentrales Rendering macht und WebKit erst in der zweiten Version davon gebraucht macht.
"es ist schlicht und einfach nicht möglich Plasmoide in eigene Prozesse zu packen, da sie zusammen zu die Grafik Ausgabe erstellen"
Es ist anerkennenswert, daß Sie die Entscheidungen der Plasma-Entwickler hier zu vertreten versuchen. Aber diese Aussage hier läßt mich wundern, ob Sie hier den richtigen Namen, den eines KWin-Entwicklers, nutzen, da dieser eigentlich weiß, daß man Grafikausgaben verschiedener Prozesse mischen kann.
Ich würde mal davon ausgehen, dass Martin besser als die meisten hier, mich eingeschlossen, weiß, welche Limitierungen dem Zusammenführen von Fensterinhalten gesetzt sind.
Vermutlich ist es schwierig bis nahe unmöglich mehrere Fenster synchron in Größe oder Position zu ändern, was z.B. bei Applet Fenstern in einem Leisten Fenster der Fall wäre.
Könnte mir auch vorstellen, dass das zwingend einen Compositor vorraussetzt.
Ok, alles was du schreibst sagt doch nur aus, dass das ganze Plasma-Design total kaputt ist. Wer ein Framework so plant, dass ein beliebiges Plasmoid alle anderen blockieren kann sollte die Finger von der S/W-Entwicklung lieber ganz lassen.
Ihre Art die KDE-Entwickler und im Speziellen Hr. Grässlin zuverteidigen grenzt an Götterverehrung. Mir konnte noch keiner erklären, warum dieses kaputte Design wirklich der einzige Weg sein sollte die Widgets zu Implementieren. In anderen DEs geht es ja auch, dass das UI durch einzelne Plugins/Erweiterungen/Apps/... nicht blockiert wird.
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 18. Feb 2013 um 16:27.Was ich noch erwähnen will: interessanterweise wird das Design erst kritisiert, seit Chrome den Schwachsinn gestartet hat pro Tab einen eigenen Prozess zu starten. Ich betrachte das als falsches Design und nicht als Sicherheitsfeature, wie es oft dargestellt wird.
Klar wenn die Webseite WebKit crashen lässt, crashed nur ein Tab und nicht der ganze Browser. Nur WebKit sollte nicht crashen. Was Google hier im Design macht, ist eine Ermutigung das Backend nicht fehlerfrei zu haben - ist ja nicht so schlimm, dann stürzt halt ein Tab ab.
Meiner Meinung nach gehören Bugs gefixed und nicht herumgebaut. Was ich als valides Design ansehe, ist der WebKit 2 Ansatz, der die GUI in einem Prozess hält und das Laden/Rendern der Webseite in einen Prozess auslagert - ein Design wie es bei KDE übrigens seit Jahren üblich ist.
Dies ist auch ein Ansatz, der für libplasma2 angedacht ist um die DataEngines in eigene Prozesse auszulagern. Ob das wirklich umgesetzt wird, ist noch nicht entschieden, da es Vor- und Nachteile hat, die man gut gegeneinander abwägen muss.
Was das auch zeigt: das Design wie es dir vorschwebt, ist meiner Meinung total kaputt, wogegen du das Design das aktuell existiert als total kaputt bezeichnest. Du siehst hoffentlich, dass es nicht das eine perfekte Design gibt um Probleme umzusetzen.
Da sind wir wieder in der perfekten KDE Welt angekommen. Wie wärs wenn man die MMU Abschaltet, weil ein Zugriff auf den RAM über die TLB bis zu 30% Leistungseinbuße bringt? Wozu protected Memory wenn stattdessen einfach jeder fehlerfreie Software schreiben könnte oder gefälligst seine Bugs fixt?
Als Musterbeispiel haben wir ja KDEs Single-Process Plasma, über das es sicher noch nie Beschwerden gab. Andere Erfolgreiche Vertreter dieser Utopie waren MSDOS und Windows 3.1. Zweifelsfrei sehr erfolgreich und ihrer Zeit wohl zu weit voraus, als dass diese Konzepte heute noch verfolgt werden könnten.
Man sollte einfach immer Sicherheit gegen Performance tauschen, und wenn die Software robust ist (ala chrome), also der Ausfall einer Teilkomponente nicht gleich alles zerschießt, ist es offensichtlich schlechtes Design, da fehlerfreie Software (die, wie wir alle von unseren geliebten Plasmoids gelernt haben, möglich ist!) nicht gefördert wird.
Schließlich befolgt KDE einfach das bewährte UNIX Design, alles mit Threads im gleichen Adressraum, KIO slaves anstelle von Dateisystemen und hört auf seine Nutzer denn im Mindstorm zu "Plasmoids as separate Processes" hat sich ja die überwiegende Mehrheit dagegen ausgesprochen. Aus .. technischen Gründen.
Hmm, Threads werden üblicherweise nicht als "bewährtes UNIX Design" betrachtet und werden auch noch nicht so häufig eingesetzt. KIO dagegen ist klassischer UNIX Ansatz mit spezialiserten Prozessen für bestimmte Aufgaben.
Ich denke das ist in diesem Fall schon OK, weil die Inhalte einfach aus so vielen verschiedenen Quellen kommen können und die Komplexität der Inhalte mitterweile ein Niveau erreicht hat, wo man Bugs praktisch garantieren kann.
Abgesehen davon setzt Chrome dafür doch auch den WebKit2 Ansatz ein, oder?
ich weiß nicht ob Chrome mittlerweile umgestellt hat. Als es initial veröffentlicht wurde, war es ein Design mit ein Prozess pro Tab. Der WebKit 2 Ansatz kam erst später (inspiriert von Chrome AFAIK).
Chromium verwendet nicht mehr 1 Prozess pro Tab sondern mehrere Tabs proo prozess das kannst du dir mit dem Chrome TaskManager (Umschalt + esc) ansehen bei schlechten Javascripten in einer Seite blockieren jetzt auch mehre Seiten und chrashen gemeinsam.
Chrome verwendet WebKit1. WebKit2 ist lediglich ein thin-layer über WebKit1 bzw WebCore der die Prozessabstraktion implementiert die in Chrome auf höhere Eben bereits gegeben ist. Man plant aber wohl langfristig auf WebKit2 zu wechseln.
> Nur WebKit sollte nicht crashen.
Wir gehen auch davon aus, sicher Auto zu fahren und schnallen uns trotzdem an. Nach deiner Logik sollten wir uns die Gurte sparen - kostet ja Sprit.
Design ist nicht nur eine Frage der theoretischen Möglichkeiten sondern auch der real existierenden Rahmenbedingungen.
Daher spricht man im allgemeinen auch von Designentscheidungen, d..h. auf Grund gewisser Tatsachen hat man sich für eine bestimmte Möglichkeit entschieden.
Solche Entscheidungen könnten zu einem späteren Zeitpunkt wieder neu bewertet werden, was aber nicht notwendigerweise bedeutet, dass sie anfangs falsch waren.
Praktisch fast keine Software ist derzeit so entworfen, dass Plugins in eigenen Prozessen laufen. Selbst Browser machen das noch nicht sehr lange und selbst da nicht bei allen Arten von Plugins (z.B. Extensions).
Beispiele?
Meines Wissens benutzt selbst Chrome nur Prozesse für Webinhalte und nur einen pro Tab (also keine Komposition aus Teilen, die von verschiedenen Prozessen geliefert werden).
Die Information über Chrome ist nicht ganz korrekt, siehe hierzu:
"Browser plug-ins, such as Flash and Silverlight, are also executed in their own processes, and some plug-ins like Flash even run within Chromium's sandbox. "
Quelle:
http://www.chromium.org/developers/design-documents/process-models
Das die Entscheidung nicht "falsch" war sieht man ja alleine schon daran, dass KDE überhaupt funktioniert. Dass sie nicht "optimal" war sieht man an besseren Gegenbeispielen, über die es auch viel in einschlägiger Literatur zu lesen gibt.
Klar, Browserplugins out-of-process machte sogar Konqueror schon immer.
Ich meinte selbst Chrome benutzt nur einen Prozess pro Seite. D.h. selbst wenn z.B. ein Banner von einem anderen Server kommt als die Seite ansich, oder ein IFrame eingebettet ist, oder Inhalte in verschiedene CSS Boxen eingebunden wird, dann wir meines Wissens dennoch nur ein WebProcess dafür verwendet.
Ich denke das sogar mache Teile des UIs, selbst dann wenn sie über Plugins realisiert sind, als Teil der eigentliche Hauptanwendung gezeichnet werden, z.B. Toolbars, u.ä.
Ich beziehe mich da hauptsächlich auf meine Erfahrungen mit der WebKit2 Architektur, unter der Annahme, dass Chrome entweder darauf oder auf einen Vorgänger davon aufbaut.
Und dort zeichnet der Web Prozess den gesamten Inhalt und der UI Prozess stellt ihn lediglich dar. Für gewisse Sachen wird sogar lediglich eine Nachricht an den UI Prozess gesandt und der macht dann das entsprechende UI, z.B. JavaScript Dialoge, Dateiauswahl, usw.
Wenn der UI Prozess den Inhalt z.B. verschiebt und der Inhalt eine freischwebende Box enthält, muss der Web Prozess neu zeichnen, weil eben die Box kein eigenständiger Inhalt ist und daher nicht einfach vom UI Prozess neu positioniert werden kann.
Zu den Kosten der Multiprozessarchitektur:
http://webkit.sed.hu/blog/20110120/webkit2-memory-consumption-process-models-vol-1
Aha, dann sind mehrere Medienplayer unmöglich?
Das liegt definitiv nicht am Kernel. Asynchrones IO / Forks & Threads waren schon immer möglich, es besteht Kernelseitig keine Notwendigkeit Anwendungen zu blockieren, die nicht auf die *gleiche* Ressource zugreifen müssen. Beim USB Beispiel, werden wahrscheinlich alle Anwendungen blockieren, die auf den USB Stick zugreifen - bei Plasma hingegen blockiert unnötigerweise *Alles*.
Nun, der Grund dafür könnte schlichtweg sein daß Operationen auf der graphischen Benutzeroberfläche streng sequentiell sein müssen, wenn man nicht das Chaos heraufbeschwören will.
Dies lernt man bei der Qt- oder Java-Programmierung schnell. Direkte Zeichenoperationen aus nebenläufigen Prozessen schreien nach Abstürzen bzw. "komischen" Verhalten, gerade beim X-Server. Wenn dort ein anderer Prozess in die Zeichenoperationen "hereinquatscht" entstehen die merkwürdigsten Effekte.
Aber richtig: besser wäre es schon, wenn man eine Art Warteschlangenverarbeitung einbauen würde, welche von nebenläufigen Prozessen bedient wird.
kleiner Hintergrund hierzu. Als Plasma designed wurde gab es in Qt noch nicht die raster Paint Engine. Eine QPixmap war an eine XPixmap gebunden und der zeichnende Zugriff auf eine QPixmap vom nicht-GUI Thread ist nicht erlaubt, da XLib multi threading nicht wirklich erlaubt. Man konnte zwar mit QImage in einem Hintergrundthread zeichnen, aber das bedeutet ständiges kopieren zwischen XServer und Anwendung.
Heutzutage sieht das anders aus: mit QtQuick 2 wird immer in einem Hintergrundprozess gezeichnet.
Danke für diese Erläuterung!
Das ist viel hilfreicher als die ganzen "Geht nicht. Es gibt Gründe." oder auch "Muss aber gehen. Habe ich gehört." Platitüden. Ich jedenfall freue mich jederzeit über solche Hintergrundinformationen, welche ja sogar noch einen positiven Ausblick für die Zukunft bieten
Ein wichtiger Punkt im Zusammenhang mit NFS und GUIs im Allgemeinen, also abgesehen vom Verbesserungspotential in der Applet Implementierung, ist, dass Kernel Mounts meistens die Asynchronität der Verbindung verstecken.
D.h. für einen Userland Prozess ist oft nicht erkennbar, dass eine Datei nicht lokal vorliegt und somit nicht mit dafür üblichen Annahmen benutzt werden kann.
Die meisten Anwendung greifen direkt auf lokale Dateien zu, d..h ohne dafür extra einen Thread zu starten, weil bei lokalen Dateien kurze Zugriffszeiten erwartet werden.
Das trifft dabei auch nicht nur GUI Anwendungen, in unterbrochener NFS Mount kann auch Systemprogramme wie cp oder mv hängen lassen (oft so, dass sie nicht mal mit CTRL+C abgebrochen werden können).
Bei GUI Anwendungen fällt es in Regelfall nur schneller auf.
Das beobachtete Problem ist hier nicht, dass eine Anwendung von der Ressource (in diesem Fall eine über NFS mount zugänglich gemachte Datei) die sie benötigt blockiert wird. Das ist unvermeidbar.
Vielmehr werden ohne Not *alle* Plasmoids blockiert unabhängig von ihren tatsächlich benötigten Ressourcen, obwohl im Zweifelsfall nur wenige (eine?) hiervon betroffen sein *müsste*.
Aufgrund der gegenwärtigen Architektur ist es auch schwierig den Verursacher ausfindig zu machen, da jedes nicht kooperative plasmoid alle anderen auf gleiche Weise beeinträchtigt.
Wir haben hier ein technisches Problem, kein Entwickler muss gesteinigt werden. Fehler by (unachtsamen) Design müssen aber nicht unnötig verteidigt werden; Sonst wird sich die Situation ja nie bessern
das ist aber wirklich ein leicht zu behebendes Problem. Gdb drauf, schauen wo es blockt, Plasmoid entfernen, bug aufmachen.
Wie ich jetzt schon mehrmals geschrieben habe: Bugs gehören gefixed, nicht workarounded. Ein Design bei dem ein Element blockieren darf, ist ein workaround. Der Zugriff muss asynchron erfolgen egal ob Framework blockiert wird oder nicht.
Diese Argumentation ist genauso als wolle man sagen, dass Webseiten, welche Fehlerhaften JavaScript-Code enthalten den ganzen Browser (also alle anderen Tabs) blockieren dürfen. Wenn sowas passiert, muss die Seite gefixt werden und nicht der Browser.
Auf kde-look.org werden nach was ich auf die schnelle sehe >580 Plasmoides angeboten. Dies wohl großenteils von Hobby-Programmierern erstellten Plasmoieden sollen also alle perfekt und fehlerfrei geschrieben sein? Wie soll ein Nutzer (ohne etwas von Programmierung zuverstehen) rausfinden welches Plasmoid für sein kaputten Desktop verantwortlich ist? Wie soll er es dann fixen? Was wenn der Entwickler des Plasmoids sich nichtmal im Stande sieht das Problem zu beheben weil ihm das KnowHow fehlt?
siehe anderer Kommentar hier im Thread. Auf kde-look sind hoffentlich keine C++ Plasmoide, sondern scripted Plasmoide, die Plasma nicht blockieren sollten (wenn das doch ist, dann ist das ein Bug im Framework).
Wir reden hier also nur von Plasmoiden, welche von der KDE Community herausgegeben wurden und ja da ist gdb die einzige valide Lösung.
Auf kde-look.org scheinen >260 Plasmoide als binary gelistet zu werden. Ich weiß jetzt nicht ob dies alle in C++ implementiert wurden oder ob es auch andere Möglichkeiten gibt ein Plasmid als binary bei kde-look zu platzieren.
Gibt es ein Regelwerk, welches besagt, dass Plasmiden nur dann in C++ implementiert werden dürfen/sollen wenn diese direkt von der KDE-Community im Rahmen des KDESC gepflegt werden?
Und wie schafft ihr es, dass bei gescripteten Plasmoiden dies nicht auftritt?
Wird für das gescriptete Plasmoid ein eigener Prozess gestartet (der Interpreter)? Wenn ja, wiso kann dieser dann ohne Probleme Zeichnen aber für ein als Prozess gestartetes (C++) Plasmoid sollte dies nicht möglich sein?
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 18. Feb 2013 um 18:31.Pakete wie rpm, deb sind binary, tar.gz auch. Da die meisten oder viele Plasmoids aus mehr als eine Datei bestehen werden sie wohl gepackt beim hochladen.
Und wie schafft ihr es, dass bei gescripteten Plasmoiden dies nicht auftritt?
Möglicher Ansatz; Ein eigener Prozess in dem scripted Plasmoids laufen, als kein eigener Prozess pro Script-Plasmoid weil zu teuer aber ein eigener Prozess für alle Script-Plasmoids. Das Ergebnis wird als eigene Anwendung(en) samt Fenster gezeichnet. Das Fenster ist fensterlos, durchsichtig und wird vor dem WM "versteckt". Ein Proxy Plasma-Applet, das im selben Prozess wie Plasma läuft, steuert das Fenster um es in die richtige Position zu bringen, Eingaben um-/weiterzuleiten, ...
Mit QtQuick wird sich sowieso so einiges ändern und hat aich schon geändert weil dort ein eigener Renderthread und Scenegraph zum Einsatz kommt. Damit stellt sich die Frage nach der Legitimität von Prozessplittung wenn Crashfrei als Voraussetzung angenommen wird die mit Scripten einfacher zu garantieren ist.
Hm, also dürfen nicht Core-KDE-Community-Menschen kein C++ verwenden, um z.B. DataEngines oder anderes zu schreiben? So toll Javascript sein kann, aber manche Sachen, die man einbinden möchte, liegen nur per C/C++-Lib zur Anbindung bereit. Noch ne Uhr oder einen RSS-Reader oder ne Wetter-App, nee, das sind die einfachen Sachen.
Und wieso dürfen dann Plasmoide überhaupt in C++ geschrieben werden? Denn der Traum von den Bug-freien Plasmoids, den kann ich nicht mitträumen, klar sollten Bugs gefixt werden, aber wie schnell geschieht das? Und wie schnell landet das auch beim Nutzer?
Die Argumentation, nur C++-Plasmoids hätten solche Probleme, und die würden auch gründlich geprüft bevor sie beim Anwender ankommen, finde ich sehr idealistsisch, aber leider realitätsfern
Überzeugt mich nicht, würde mich freuen, wenn Ihr eine Möglichkeit findet, Plasmoids transparent in eigenen Prozessen laufen zu lassen, mindestens die "absturzgefährdeten". Denn was ist z.B. der Unterschied zwischen KCalc und dem Calculator Plasmoid? KCalc läuft auch in nem eigenen Prozess. Und könnte ähnlich eingebettet werden wie der Calculator Plasmoid. Entsprechende D-Bus API, um KCalc's Erscheinungsbild je nach Einbettung anzupassen, voilà.
C++ Plasmoide müssen kompiliert werden und an die richtige Stelle installiert werden. Sofern du nicht gerade weißt welche env Variablen du anpassen musst, läuft das auf installieren mit root-Rechten hinaus.
Im Endeffekt bedeutet das, dass ein Plasmoid von einer Distribution angeboten werden muss - ich hoffe doch sehr, dass du nicht einfach Pakete von $IRGENDWO mit root Rechten installierst (nein kde-look ist keine vertrauenswürdige Quelle).
Wenn eine Distribution das paketiert, dann erwarte ich zumindest eine gewisse QA die auch sein kann bei den Plasma Entwicklern nachzufragen: "schaut mal bitte drauf, ist das OK?"
Ich denke da vor allem an Inhouse-Plasmoids (nicht jeder will/muß seinen Spezialkram mit der Welt teilen, Teilen ist auch Verantwortung). Niemand kann garantieren, daß die nicht doch hier und ne Macke haben. Nun. daas gilt selbst für die von KDE ausgelieferten. Auch Profis schlampen mal, C++ ist da ungnädig. Als KDE-Community-Entwickler sollten Sie das ja wissen, all die bugs.kde.org-Einträgen schaffen einen kleinen Realitätsabgleich.
Und im Produktiv-Einsatz ist es nicht akzeptabel, daß dann gleich die halbe Umgebung hängt. Da braucht man Stabilität. RAM ist billig im Vergleich zum Stundenausfall.
Deswegen ist die derzeitige Umsetzung Mist. Welch historischen Gründe es auch gibt. Und dann ist ja auch nicht der ganze Workspace in einem Prozeß, das hatte ja sicher auch gute Gründe. Und diese Gründe sind für manche eben auch bei den Plasmoids wichtig. Niemand zwingt Euch. Ist nur ne Rückmeldung. Der Rest ist ja ziemlich nett (positiv gemeint). Aber das hier mit dem einen Prozeß ist und bleibt Mist, für mich und scheinbar ein paar andere.
> Ein Design bei dem ein Element blockieren darf, ist ein workaround.
Nein, das ist sicherheitsbewußtes, defensives Design. Plasma ist insofern ein Ärgernis. Freezes und Abstürze des Desktops sind indiskutabel.
Nicht notwendigerweise, wie du ja schon in deinem anderen Beitrag geschrieben hast (z.B. in Thread, unter Benutzung asynchroner I/O API). Nur wird derzeit meistens unter der Annahme gearbeitet, dass lokale Dateien mehr oder weniger blockadefrei benutzt werden können.
Soweit ich das sehe wurde der Fehler auch nicht im geringsten verteidigt. Praktisch jeder Beitrag stimmt darin überein, dass was auch immer die Blockade auslöst auf nicht-blockierende Art und Weise zu ändern sei, also die Situation gezielt zu verbessern.
Ich würde jetzt auch nicht davon ausgehen, dass die Architektur für immer in Stein gemeisselt ist, aber man darf nicht aus den Augen lassen, dass die Komposition von Grafiken verschiedener Prozesse und die umgekehrte Eingabeverteilung keine so einfach Sache ist und auch nicht so weit verbreitet.
Klar, Wayland ist in der Lage das zu tun, aber auch viel neuer als der Startzeitpunkt der Plasma Entwicklung.
Das aktuelle Design von Plasma wurde etwa um 2006/2007 entworfen. Zum Vergleich (aus Wikipedia):
Mal eben Fenster über einen Compositor zusammenzusetzen war damals noch nicht. KWin unterstützt OpenGL Compositing seit 2008, seit 2009 standarmäßig aktiviert, aber selbst heute hat man beim Startup zuerst einen nicht composited desktop und Compositing kann zur Laufzeit ausgeschaltet werden. Was man auch berücksichtigen muss: der WM müsste diese Plasma Fenster ignorieren. Klar kann man in KWin einbauen, aber was ist mit Nutzern anderer WMs?
Compositing unter X11 fällt daher mal für Grafikdarstellung einfach raus. Was bleibt: Xembedd? Eine Technologie, die bei allen verhasst ist. Shm? Will wohl auch hoffentlich keiner.
Erst Wayland ermöglicht es dass man aus mehreren Prozessen das zusammenbauen könnte. Ob das für die Usecases von Plasma sinnvoll ist, ist eine andere Frage, ich würde mal "nö" sagen, da wir da mit QtQuick2 eigentlich bekommen was wir wollen.
Verstehe das ganze Gezicke in diesem Thread nicht. Out Of Process DataEngines für Plasma sind in Entwicklung für Plasma Workspaces 5.