Login
Newsletter
Werbung

Thema: Aaron Seigo kritisiert Canonical

13 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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 ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung