Login
Newsletter
Werbung

Thema: Aaron Seigo kritisiert Canonical

14 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von krake am Mo, 18. Februar 2013 um 16:19 #

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.

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

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

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

      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.

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

        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?

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

          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.

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

            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.
            [
            | Versenden | Drucken ]
            • 0
              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.

              [
              | Versenden | Drucken ]
              0
              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.

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

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

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

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

              [
              | Versenden | Drucken ]
              • 0
                Von Otto am Mo, 18. Februar 2013 um 21:44 #

                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.

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

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

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

      Das ist unvermeidbar.

      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.

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

        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.

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