Login
Newsletter
Werbung

Thema: Aaron Seigo kritisiert Canonical

29 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von mgraesslin am Mo, 18. Februar 2013 um 13:35 #

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.

[
| Versenden | Drucken ]
  • 0
    Von KDE Fan am Mo, 18. Februar 2013 um 13:44 #

    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?

    [
    | Versenden | Drucken ]
    • 0
      Von mgraesslin am Mo, 18. Februar 2013 um 13:52 #

      Ja, nennt sich gdb und muss der Nutzer verwenden, wenn es blockiert ;-)

      [
      | Versenden | Drucken ]
      • 0
        Von iluminat23 am Mo, 18. Februar 2013 um 14:49 #

        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.

        [
        | Versenden | Drucken ]
        • 0
          Von KDE Fan am Mo, 18. Februar 2013 um 15:21 #

          Ja, finde selbst ich milde gesagt "bedenklich"...

          [
          | Versenden | Drucken ]
          • 0
            Von krake am Mo, 18. Februar 2013 um 15:55 #

            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.

            [
            | Versenden | Drucken ]
            • 0
              Von harrald am Mo, 18. Februar 2013 um 16:09 #

              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.

              [
              | Versenden | Drucken ]
              • 0
                Von krake am Mo, 18. Februar 2013 um 16:28 #

                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.

                [
                | Versenden | Drucken ]
                • 0
                  Von harrald am Mo, 18. Februar 2013 um 17:07 #

                  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.

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von krake am Mo, 18. Februar 2013 um 17:52 #

                    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.

                    [
                    | Versenden | Drucken ]
        0
        Von km am Mo, 18. Februar 2013 um 15:01 #

        Sorry, aber das ist alles andere als usable.

        [
        | Versenden | Drucken ]
    3
    Von harrald am Mo, 18. Februar 2013 um 14:40 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von krake am Mo, 18. Februar 2013 um 16:06 #

      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.

      [
      | Versenden | Drucken ]
    0
    Von Otto am Mo, 18. Februar 2013 um 15:01 #

    "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.

    [
    | Versenden | Drucken ]
    • 0
      Von krake am Mo, 18. Februar 2013 um 16:10 #

      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.

      [
      | Versenden | Drucken ]
      • 0
        Von iluminat23 am Mo, 18. Februar 2013 um 16:26 #

        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.
        [
        | Versenden | Drucken ]
        • 0
          Von mgraesslin am Mo, 18. Februar 2013 um 17:17 #

          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.

          [
          | Versenden | Drucken ]
          • 0
            Von harrald am Mo, 18. Februar 2013 um 17:36 #

            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.

            [
            | Versenden | Drucken ]
            0
            Von krake am Mo, 18. Februar 2013 um 18:30 #

            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?

            [
            | Versenden | Drucken ]
            0
            Von ac am Di, 19. Februar 2013 um 01:29 #

            > 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.

            [
            | Versenden | Drucken ]
          0
          Von krake am Mo, 18. Februar 2013 um 17:21 #

          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).

          [
          | Versenden | Drucken ]
          • 0
            Von harrald am Mo, 18. Februar 2013 um 18:15 #

            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.

            [
            | Versenden | Drucken ]
            • 0
              Von krake am Mo, 18. Februar 2013 um 18:48 #

              "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.

              [
              | Versenden | Drucken ]
    0
    Von Anonymous am Mo, 18. Februar 2013 um 23:04 #

    Aha, dann sind mehrere Medienplayer unmöglich?

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung