Mozilla stellt "sparsamen" Firefox 7 fertig

Wann gibt's den endlich den Multithread- FF ?

Wie hoch ist denn der Verbrauch auf 100km?

sollt nicht die frage sein wieviel der so im monat ausgibt?

i komm gar net nach die ganzen Webpages zu testen ob noch funken. Den FF5 ist anders als 6, und beim 7 ist wieder alles anders

So ein Unsinn - die Versionsnummer wird hochgeschraubt, obwohl sich an der Layout-Engine nichts signfikant ändert. Da muss man nix testen. Es ist nur lästig für entwickler, weil sie _glauben_ es würde sich mit einer Major-Version irgendwas ändern, was die abwärtskompatiblität bricht. Dem ist aber nicht so, weil die Mozilla-Leute eben keine Ahnung von vernünftiger Versionierung haben. Da wird ohnhin jede 2. Version das Nummerierungsschema geändert. Und das trifft fast so sicher zu wie Moores Gesetz.

Das trifft sicherlich auf simple htmls zu aber nicht auf etwas komplexere sachen

Wenn die Layout- und JavaScript-Engine identisch ist, gibt es keine Unterschiede in der Darstellung.

Warum sollte sich also etwas ändern, wenn die an Gecko nix drehen? Und leider drehen sie jetzt die Gecko-Versionsnummer parallel mit der Firefox-Versionsnummer hoch - jetzt lässt sich nichtmal aus der Engine-Version die Kompatiblität ableiten.

War das nicht das Argument, dass die Firefox-Version nur für den Benutzer hochgedreht wird, für die Entwickler aber eigens versioniert wird? Wäre das nicht die Layout-Engine?

Ich arbeite bei einer großen Firma, und da kamen einige Anrufe weil Teile in den einzelnen Versionen angezeigt werden.

Dann hat aber jemand schleissig gearbeitet :)

Kann ich nicht bestätigen, auch der 7er klettert in der speicherbelegung zügig und zeigt sich hungrig, nach ein paar stunden mit ein paar offenen fenstern klettert er schon mal auf über 2GB, was man von außen daran merkt daß er beginnt langsamer zu werden, dann hilft nur mehr alles zu und neu einsteigen.

Selbst wenn (falls) er irgendwie schlanker geworden sein sollte, er leakt noch immer GEWALTIG.

http://slashdot.org/story/06/... -a-Feature

browser.sessionhistory.max_total_viewers = 0

Das hilft zumindest ein wenig.

Das wirkliche Problem ist IMHO, dass alles in einem Prozess läuft, der, je nach Speicherausstattung, irgendwann nicht mehr als Ganzes in den Hauptspeicher passt und teilweise ausgelagert wird.

Mein FF war gestern Abend wieder auf ca. 2.5 GB - 1 Fenster mit ca. 8 Tabs und ein paar Stunden seit dem Start. Wer's nicht glaubt, braucht nur mal ein Fenster mit Zeitungen dilbert.com aufmachen, ein paar Monate Dilbert-Folgen durchblättern und den FF-Prozess im Task-Manager beobachten.

Es ist nun mal so, dass viele ausgalagerte, vom aktuellen unabhängige Prozesse gar nicht negativ auffallen, während ein großer Blob-Prozess ab einer bestimmten Größe für's OS unhandlich wird.

Aber eine Aufteilung in einzelne Proz. soll ja auch bei FF geplant sein.

das kann ich hier auf beim durchblättern der comic strips dilbert.com nicht nachvollziehen - das ram niveau steigt bei jedem wechsel zwar kurzfristig an, fällt dann aber wieder auf das vorige maß zurück...

tritt das aufschaukeln des RAM auch auf, wenn Sie firefox mal testweise im abgesicherten modus starten? (firefox > hilfe > mit deaktivierten addons neu starten > weiterarbeiten)

Ich würde sagen beides ist ein problem, denn der Chrome schaukelt sich nicht so auf, sondern bleibt konstant im speicherbedarf, es kann also eher nicht nur am 1-task konzept liegen, imho.

Ja, natürlich ist nicht freigegebener Speicher auch IMMER ein Problem.

Das würde jedoch wahrscheinlich mit eigenen Prozessen für jedes Fenster oder noch besser für jedes Tab nicht so schnell schwerwiegend werden, da jeder einzelne beendete Prozess vom OS aufgeräumt wird, auch wenn der Programmierer schlampt.

Und wie gesagt, würden einzelne ausgelagerte Prozesse den gerade aktiven nicht behindern, solange dieser in den Speicher passt.

Vor allem wäre klar ersichtlich WELCHER prozess sich aufschaukelt, und der könnte dann individuell beendet werden.

Ich handhabe das einfach so daß ich nicht die einzelnen fenster schließe sondern per taskmanager den FF abwürge und dann beim neueinstieg und "recovery" wieder am status quo bin, mit dem initial geringeren speicherbedarf.

Hier 2 Anregungen für einen Artikel, was die nähere Zukunft vom Firefox so bringt:

https://wiki.mozilla.org/Features/... Compatible

(ab Firefox 10 sollen die meisten Addons automatisch mit einer neuen Version kompatibel sein)

und

http://www.ghacks.net/2011/09/2... r-firefox/

(ab Firefox 8 oder 9 soll es Extended Support Releases geben, für jene, die nicht alle 6 Wochen updaten können oder wollen; v.a. für Firmen)

Beides Dinge, die oft kritisiert wurden, wo die Rufe jedoch von Mozilla erhört werden.

Der extended Support ist aber Mist - ersetzt ohnehin wieder eine Schwelle für "kleinster gemeinsamer Nenner". Warum nicht Features in LTE-Releases als Minor-Updates nachschieben, wie das auch anderswo gemacht wird?

Weil gerade jene, die Extended Support Releases einsetzen, keine Feature-Updates wollen. Darum ging's ja bei der ganzen Kritik.

Dann könnten sie gleich alle 6 Wochen die normalen Updates installieren, wäre dann genau dasselbe.

Mit den ESRs brauchen sie nur alle 30-42 Wochen updaten, erhalten in dieser Zeit keine neuen Features, allerdings ggf. schon Security-Updates.

Das ist mir durchaus klar - aber damit haben wir dasselbe Problem wie jetz auch. Firmen brauchen Versionen die Lange stabil sind - damit bleiben viele Benutzer bei antiken Versionen hängen und bremsen die Entwicklung.

Gut < 1 Jahr ist ok, aber bleibts denn dabei? Da wirds dann heissen Firefox 8 LTS/ESR ist jetzt 1 Jahr gut gelaufen, lassen wir den halt noch ein Jahr drauf - den zuständigen Entscheidungsträgern ist doch meistens egal, wenn man sagt "in 1 Monat läuft der Support aus, wir müssen updaten" oder "vor 8 Monaten ist der Support ausgelaufen, wir müssen updaten" - das ist doch alles dasselbe.

... Dagegen ist kein Kraut gewachsen.

Dass alle 6 Wochen Updates mit neuen Features ein Problem für Firmen sind, ist ein legitimes Argument. Deswegen wird ihnen hier geholfen, dass sie nur mehr alle 30-42 Wochen updaten müssen, und trotzdem eine supportete Version haben. Dass sie updaten sollten, wenn diese Version end-of-life erreicht, sollte sich von selbst verstehen, aber wie gesagt, gegen blöde Entscheidungen ist auch Mozilla hilflos.

30-42 Wochen ist auch ein vernünftiger Zeitraum. Kürzer wäre wahrscheinlich für Firmen nicht vertretbar, und wenn's länger wäre, täte es fördern, dass technisch veraltete Versionen zu lange im Umlauf bleiben (das IE-Syndrom). Mit 30-42 Wochen sollte man aber gut leben können.

Das Problem ansich ist aber, dass Mozilla offenbar die Kompatiblität selbst nicht ausrechend sicherstellen kann - in jeder anderen Software ist es kein großes Problem, dass man neue Features mit Minor-Versionen veröffentlicht, die Kompatiblität erhalten ohne dass einem gleich alles um die Ohren fliegt.

Für Mozilla ist es aber einfacher einfach die Versionsnummer eins hochzudrehne und zusagen "geht nimma" und die Sache ist erledigt - dasselbe wird ja auch mit Gecko gemacht - wer soll den bitte die Engine ernsthaft in einer Drittsoftware verwenden wollen, wenn man aus der Versionsnummer nicht mehr ableiten kann, ob es prinzipiell gefahrenfrei funktioniert? [Weitere Teil folgt]

Wenn ich Gecko von 1.9.1 -> 1.9.2 update, kann ich davon ausgehen, dass nix "explodiert" und alles wie gewohnt funktioniert - wenn ich aber Gecko 2 zu 6 Update, muss ich erst durch Tonnenweise Changelogs wühlen, die ich nicht finde.

Die Versionsnummer _muss_ auf Entwicklerebene ein indiz dafür sein, ob ich mir die Mühe machen muss, das Changelog anzusehen.

Eine Änderung in der 3. Stelle heisst "keien Gefahr, kannst du updaten" - eine Änderung in der 1. Stelle heisst "nope, das geht nicht ohne viel herumgraben" und eine Änderung in der Mitte heisst "gibt ein paar neue Sachen, sollte aber problemlos funktionieren.

Niemand, der eine Drittsoftware in seinem Projekt nutzt, hat die Zeit sich alles genau anzusehen, wenn er nut updatet.