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