Nur funktioniert dies bei chrome (noch) nicht richtig.Zitat von Jesus_666
Viele User haben schon es geschaft, mit einem einzigen Javascript den kompletten Browser (und damit alle Tabs/Prozesse) zum Absturz zu bringen.
Nur funktioniert dies bei chrome (noch) nicht richtig.
Viele User haben schon es geschaft, mit einem einzigen Javascript den kompletten Browser (und damit alle Tabs/Prozesse) zum Absturz zu bringen.
--
Ich hab auch einen lustigen Fehler hier -> ich komme nicht auf die Optionen-Einstellung. Beim Öffnen dieser kommt das allseits bekannte "Es wurde ein Fehler festgestellt"-Fenster und der gesamte Browser stürzt ab.
Dafür kommt dann ein Fenster "Chrome ist abgestürzt, wollen sie erneut starten", welches beim Betätigen mit Ja den Browser wieder öffnet. Trotzdem doof, dass ich keine Einstellungen vornehmen kann... -.-
Also müssten ja die Tabs/Prozesse abhängig vom Hauptfenster sein.
Ergo ist die ganze "Ein Tab = ein Prozess"-Geschichte fürn Arsch, wenn eh alle Prozesse abhängig voneinander sind.
--
Nicht unbedingt. Falls tatsächlich ein Tab abschmieren kann, ohne daß der Rest vom Browser beeinträchtigt wird, dann ist das gut.
Ich denke, niemand erwartet ernsthaft, daß die Tabs weiterlaufen, wenn der Hauptprozeß abschmiert. Ich denke, das will auch niemand wirklich.
http://www.heise.de/security/Mehrere...meldung/115363
Ich sag nichts weiter.
Wieso nicht?
Wenn man schon so ein Murks programmieren will, will ich, dass es auch richtig funktioniert.
Wenn man schon damit rumposaunt, dass Ein Tab = ein Prozess so toll sein soll, weil die Tabs unabhängig voneinander arbeiten können, will ich auch, wenn der Hauptprozess abstürzt, dass alle anderen Prozesse normal weiterlaufen können. Denn im Grunde ist jeder Tab dann eine Kopie vom Hauptprozess.
Und chrome kann man auch komplett zum absturz bringen, wenn man einen x-beliebigen Tab zum Absturz bringt.
Wenn dann will ich wenigstens hier, dass die Prozesse weiterlaufen. Aber das tun sie auch nicht.
Dann kann man auch gleich wieder zur alten Variiante greifen und ein Hauptprozess laufen lassen, wo jede Seite als Child Window arbeitet.
--
Das heißt also, daß alle Tabs direkt unter init laufen sollen. Das hat den Nachteil, daß jegliche Kommunikation zwischen den Tabs und dem Hauptprogramm (und damit auch X/Aqua/GDI/WPF) über generisches message passing abgewickelt werden muß. Und dann sehen wir wirklich fiesen Overhead. Ganz zu schweigen davon, was passiert, wenn der neue Hauptprozess sich aus irgendeinem Grund nicht an die Tabs anhängen kann - dann hast du Prozessleichen im Speicher, die du manuell abschießen darfst. Ohne auch nur zu wissen, welche jetzt die Leichen sind.
Nur, weil eine Techologie nicht in jedem Feld perfekt ist, ist sie nicht gleich komplett zu ignorieren. Wir werfen ja auch nicht Unix weg, weil da der Rechner flach liegt, wenn init abstürzt.
@EULA: Was erwartet ihr? Das ist Google!
Der einzige Vorteil, den ich in Google Chrome sehe ist, dass durch Googles Marketing unerfahrenen User bewusst wird, dass der Internet Explorer nicht das einzige Tor zum Internet ist und diese sich auch Alternativen anschauen. Für Nutzer von Firefox 3 und Opera sehe ich (noch) keinen Grund, auf Chrome umzusteigen.
Den Grund gibt es - meiner Meinung nach - auch nicht. Firefox hat für Version 3.1 eine Art "Tempo-Upgrade" angekündigt, nachdem Chrome die anderen Browser vor allem in Punkto Geschwindigkeit abhängen konnte.
Womit Google vor allem aber bei Fans ihrer Produktpaletten punkten kann, ist die Implementierung einiger Google-Applikationen in Chrome (Gears zum Beispiel).
An sich sehe ich persönlich zum jetzigen Zeitpunkt, wo es sich noch um eine BETA handelt, keinerlei Veranlassung, mir den Google-Browser zu installieren.
Da bastel ich mir lieber meinen Feuerfuchs so zurecht, wie ich ihn haben will und bin damit glücklich.
Kleine Anmerkung am Rande: Vom Google-Browser hört mal interessanterweise im Fernsehen, in Nachrichten etc., sogar im Radio wurde es mal zur vollen Stunde genannt. Lustigerweise wurde im Radio von einem "Experten" ein Vergleich zwischen IE und Chrome aufgestellt, während von anderen Konkurrenten (bitte, Firefox hat doch wirklich genügend Marktanteil gerade in DE) nicht ein Sterbenswörtchen gefallen ist...
Ich für meinen Teil wünsche Chrome langfristig ein ähnliches Schicksal wie Google Answers, zumindest solange diese EULA existiert... Glücklicherweise wird in bisher ALLEN Medien auf Datenschutzbedenken hingewiesen, vielleicht reagiert da ein Großteil der Leute sensibler darauf...
Ich würde sagen, die Sache mit der EULA hat sich erledigt. Ich denke, es spricht für Google, dass sie so schnell reagiert haben.
--
Scheinen ja weitreichende Kontakte zu haben, die Jungs von Google... ich denke es gibt weitaus wichtigere Nachrichten als sowas...
@Über mir
Entweder das oder es war schlicht und ergreifend Berechnung. Erst die Standard-EULA reinklatschen und dann abwarten bis alle "Verrat" schreien. Stellt Google natürlich in ein gutes Licht.
Aber mal ganz ab davon:
Warum ist dieser Browser überhaupt so ein großes Thema? Kann ich irgendwie überhaupt nicht nachvollziehen. KMeleon hat z.B. auch kein großes Interesse erweckt.
Geändert von Junta (04.09.2008 um 15:42 Uhr)
Der Browsermarkt ist doch sehr, sehr überschaubar. Und da taucht was neues Auf.
Was gibts denn bisher für Windows, dass kein bloßer Firefox oder IE aufsatz/modifikation/aufsatz ist?
IE, Firefox, Opera, seid kurzem Safari. Jetzt den Google Browser.
Zwischen KMeleon und Firefox gibt es kaum/keine signifikaten Unterschiede.
Chrome bietet zumindest theoretisch neue Features, auch wenn das meiste (Google unterstützung) unnütz ist.
--
cats are not characteristically disposed toward voluntary aerobic exercise
Es ging ihm wohl eher darum, dass die Methode "Ein Prozess pro Tab" - von einer minimalen Geschwindigkeitssteigerung abgesehen - keinen merklichen Vorteil für den Benutzer bringt.
@init
Was ist eigentlich aus init-ng geworden?
Donnerwetter ^^
Wenn es richtig implementiert ist bringt es Vorteile – ein hängenbleibender Tab reißt nicht den gesamten Browser mit. Daß Google keine Erfahrung in Kerneldesign hat (denn das Chrome-Kernprogramm repliziert einiges an traditioneller Kernelfunktionalität) bedeutet nicht, daß das Konzept nicht funktionieren kann.
Nebenbei macht das ein-Tab-ein-Prozess-Paradigma den Browser eher langsamer als schneller, weil es zusätzlichen Overhead gibt. Das Ziel ist nicht Geschwindigkeits- sondern Stabilitätsoptimierung.
Chromes Geschwindigkeitsvorteil kommt von der Kombination Webkit/V8 – die Renderengine ist momentan als sehr schnell bekannt und die JavaScript-Runtime ist einfach eine der ersten am Markt, die JIT-Kompilierung verwendet. Mozilla hat sowas auch, Tamarin wird aber erst in Fx 4 zum Einsatz kommen.
Ist noch nicht stable, aber in den Paketmanagern aller großen Distros zu finden.
Hossa. Mozilla hat die erste Firefox 3.1-Beta rausgebracht - mit TraceMonkey, einer Weiterentwicklung der aktuelen JavaScript-Engine SpiderMonkey. TraceMonkey hat schon einen JIT-compiler und kann sich von der Geschwindigkeit her mit V8 messen.
In den unteren Grafiken sieht man, daß V8 in einigen Bereichen immer noch deutlich schneller ist, aber das liegt daran, daß Mozilla noch nicht dazu gekommen ist, diese Teile neu zu machen – mal sehen, wie's bei der Fx 3.1-Final aussehen wird.
Auf jeden Fall ein böser Rückschlag für Google – Chrome wird eine ganze Ecke unbesonderer.
Sollen sie sich nun in die Ecke setzen und rumheulen. Google hat nun seinen Spaß gehabt und langsam ist's auch gut. Ist's nicht eigentlich so ziemlich Gurke, welcher Browser nun 1µs schneller ist? Neue Funktionen, die nicht Anbietergebunden sind, wären etwas, das Interesse rechtfertigen würde. Schneller höher weiter haben wir schon im Mikroprozessormarkt.
Pssst! Du machst den Browserherstellern ihre schonen JavaScript-Geschwindigkeits-Schwanzvergleiche kaputt! Wenn sie die nicht hätten müßten sie wieder an Sachen wie DOM-Support, Sicherheit oder gar CSS3 arbeiten.
Nicht mal CCS2 beherrschen die Browser korrekt und da kommst du mit CSS3.
Schäm dich!
--
Berechtigungen
Zitieren