Firefox 47 Aurora verwendbar?

  • Hallo :)

    Ich habe mal Firefox 47 Aurora (wird ja am 25.04. zu Beta) getestet und muss sagen - bei der Geschwindigkeit scheint Mozilla endlich mal ordentlich zu schrauben.
    Aus diesem Grund würde ich gerne FF47 jetzt immer verwenden, aber Aurora ist ja eigentlich nur für Entwickler gedacht, daher wollte ich fragen, ob es gefährlich ist, FF47 fürs normale Surfen zu verwenden, wegen Sicherheitslücken o.ä. :D

    Thx in advance!

  • Zitat von Mettfox

    ob es gefährlich ist, FF47 fürs normale Surfen zu verwenden,

    Nö. Da werden immer alle Lösungen bekannter Lücken eingearbeitet.

    Eine andere Frage ist die bei dir gebotene Stabilität des Fx. Da könnten Probleme auftreten, denn es ist ja noch kein für stabil angesehener, abgenommener Fx.

  • Er läuft relativ stabil, nur das Starten dauert ein wenig lange, aber da ja am Montag bereits die erste stabile Beta erscheint, werde ich das bis dahin aushalten können :) Dankeschön!

  • Bezüglich Stabilität ist es immer interessant, die Notizen zu den Channel-Meetings jeden Dienstag und Donnerstag zu lesen (für den letzten Dienstag hier: https://wiki.mozilla.org/Firefox/Channe…04-19#Stability). Da gibt es nämlich ganz konkrete Zahlen zur Stabilität für Aurora, Beta und Stable. Da kannst du dann die Stabilitätsrate dieser Woche von 1,6 für die Developer Edition mit 0,94 für die finale Version von Firefox 45 vergleichen und hast so eine Relation.

  • Also je höher, desto schlechter oder wie? xD

    Irgendwie ist Firefox 47 jetzt sogar langsamer als Firefox 45, nachdem ich die Aurora aktualisiert habe xD
    Naja, kann auch sein, dass die 64-Bit-Variante auch iwie langsamer läuft :D

  • Wohei man bei FFX 47 Dev Edition E10 genauso gut deaktivieren kann in den Einstellungen. Ich nutze die Dev schon ne weile und bin einigermaßen zufrieden mit der Stabilität und Geschwindigkeit. Es kommen allerdings sehr viel häufiger Updates als bei der regulären Version.

  • Hallöchen zusammen!

    Ich möchte das jetzt nicht verallgemeinern, aber normaler Weise kann man bei den Mozillen (SeaMonkey, Firefox und Thunderbird) meistens sehr gut mit solchen Testversionen arbeiten. Das ehe ich hier bei mir, ich verwende eine inoffizielle Version des SeaMonkey:

    User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 SeaMonkey/2.43

    Klar kann das auch mal schief gehen, aber die Teams machen meiner Meinung nach ihre Arbeit sehr gut! :klasse:

  • Ich würde gerne auch unter Mac die Beta Nutzen, aber finde bei Firefox die Einstellung dafür nicht.
    Gibt es für Mac und Firefox auch die Beta?

    Sich das Rauchen abgewöhnen? Eine leichte Sache! Ich habe es schon hundertmal geschafft 8)

  • Ich verwende Aurora seit einigen Monaten als Standardbrowser und insgesamt eignet sich die Version durchaus für den alltäglichen Einsatz. Wenn es Probleme gibt, dann meist mit sehr umfangreichen Addons wie Al-in-One-Sidebar ;)

    Möchte e10s auch nicht mehr missen, es ist so viel flüssiger als der Ein-Prozess-Firefox. Da ich mittlerweile 16 GB Ram im Desktop habe, habe ich sogar bereits mehr Prozesse über die about:config aktiviert. Ist unoptimiert, aber es läuft soweit gut...

    Warum werden die Aurora und Nightly eigentlich beinahe jeden Tag geupdatet? Bei Chrome bekommt selbst Canary nur alle paar Tage mal ein Update...

  • Zitat von Lurtz

    Warum werden die Aurora und Nightly eigentlich beinahe jeden Tag geupdatet?

    Trotz der schrecklichen Wortbildung.

    Die Updates erfolgen darum, damit die eingeflossenen Veränderungen zeitnah bei den Testern ankommen. Jede Zeitverzögerung erschwert eine eventuell notwendige Fehlerverfolgung.

  • Laut Google-Webseite erscheinen auch die Canary-Builds von Chrome täglich.
    https://www.chromium.org/getting-involved/dev-channel

    Übrigens werden sehr, sehr viele Builds mehr erstellt als nur ein Firefox-Build pro Tag. Es gibt nach jedem Checkin von Änderungen neue Builds (https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound). Und das ist auch zwingend notwendig, andernfalls wäre es nachträglich kaum noch mit menschlichem Aufwand möglich, festzustellen, in welchem Zusammenhang bestimmte Probleme erstmals eingetreten sind, was eine Behebung erschweren bis praktisch unmöglich machen würde.

    Gerade vorhin erst konnte ich auf diese Weise einen Firefox-Bug vom 22. März auf das genaue Bugzilla-Ticket zurückführen, welches mit der verantwortlichen Änderung verknüpft ist, und Mozilla das Problem melden, und Mozilla konnte dem Ticket so direkt einen Mitarbeiter zur Behebung zuweisen.

  • Das steht auf der Website so, war bei mir aber tatsächlich noch nie der Fall. Jedenfalls kommen sie nicht über den Autoupdater von Canary.

    Sind schon sehr spannend diese rolling releases, ich kann mir die Arbeitsweise aber nach wie vor nur sehr schwer vorstellen. Hast du dazu zufällig mal einen Artikel geschrieben? :)

  • Ich hab dazu keinen Artikel geschrieben, aber man nennt sowas Continous Integration:
    https://de.wikipedia.org/wiki/Kontinuierliche_Integration

    Die Arbeitsweise ist nicht sehr kompliziert, da ja alles vollkommen automatisiert ist. Die Entwickler integrieren einen Patch in einen Integrationszweig, umgehend werden automatisch Builds kompiliert und die Testsuiten ausgeführt, welche beispielsweise testen, ob noch alles funktioniert, aber auch Dinge wie Performance. Wenn eine Änderung beispielsweise in einem Performance-Test für eine Verschlechterung von 20 Prozent sorgt, gibt es wahrscheinlich ein Problem, welches man so nicht ausliefern möchte. Und alle paar Stunden werden die Änderungen aus den Integrationszweigen dann in den Hauptentwicklungzweig integriert, aus dem schließlich die Nightly-Builds in der Regel einmal am Tag erstellt werden.

    Das Fehlerfinden ist dann auch einfach mit einem Tool wie mozregression:
    http://mozilla.github.io/mozregression/

    Man gibt das Datum vom letzten guten Nightly-Build ein und das Datum vom ersten schlechten Datum und weil es für jeden Checkin eigene Builds gibt, lädt das Tool dann die Builds herunter und erlaubt einem so, dass Problem auf den ersten Ursprung einzugrenzen, indem man nach jedem Build sagt: gut oder schlecht. Am Ende bekommt man dann einen Link und im Idealfall taucht da nur noch eine einzige mögliche Ursache auf. In meinem Fall heute war es:

    https://hg.mozilla.org/integration/mo…a2da12ca9534894

    Anbei ein Screenshot, wie mozregression in der Verwendung aussieht.

  • Danke, sehr interessant. Ich stelle mir das bei der Menge an Code, die Firefox jeden Tag bekommen muss, dennoch sehr komplex vor.

    Ich hoffe das ist nicht zu sehr off topic:
    Weiß man wie groß der Anteil an bezahlten Mozilla-Mitarbeitern dabei ist und wie groß derer, die sozusagen ehrenamtlich an Firefox als Open Source mitwirken?
    Und wie wird gelenkt, an welchem Projekt gezielt gearbeitet wird? Werden da auch schon die freien Mitarbeiter "reglementiert" oder passiert das erst ab Betaebene (oder schon früher)?
    Wer entscheidet letztlich was in eine finale Version kommt oder rausfliegt, wird das offen in Tickets diskutiert oder gibt es dafür gesetzte Entscheidungsträger?

  • Solche Systeme sind komplex, die Entwickler von Firefox haben mit der Komplexität aber nichts zu tun. Die Herausforderung ist, die Build-Systeme zu entwickeln, die alles automatisieren, damit für die Entwickler das Leben angenehm ist. Dafür hat Mozilla ganz eigene Mitarbeiter, die nichts anderes machen:

    https://wiki.mozilla.org/ReleaseEngineering#Team

    Bei den Mitarbeitern muss man unterscheiden. Es gibt die Mozilla Corporation und die Mozilla Foundation. Entwicklerin von Firefox ist die Mozilla Corporation. Die hatte im letzten Jahr 545 Mitarbeiter:

    https://static.mozilla.com/moco/en-US/pdf…-2015-EE0-1.pdf

    Die Gesamtzahl der bezahlten Mitarbeiter Corparation + Foundation liegt bei über 1000. Zu bedenken ist auch, dass nicht alle Mitarbeiter der Mozilla Corporation an Firefox arbeiten, Mozilla macht ja unzählige Dinge. Ich weiß nicht, wie viele ehrenamtlich an Firefox mitwirken. Insgesamt ist die Anzahl der ehrenamtlichen Unterstützer aber größer als die Anzahl der bezahlten Mitarbeiter. Aber ehrenamtliche Mitarbeit muss nicht Entwicklung bedeuten, darunter fällt auch Übersetzung, Support etc.

    Bei Mozilla gibt es auch Entscheidungsträger, auf verschiedenen Ebenen. Die oberste Führungsebene sowohl der Corporation als auch der Foundation findest du hier:
    https://www.mozilla.org/en-US/about/leadership/

    Jede einzelne Komponente von Firefox "gehört" aber auch jemandem, der die Verantwortung für diesen Teil von Firefox trägt. Die oberste Ebene trifft nicht jede Produkt-Entscheidung. Der allgemeine Fahrplan und Prioritäten, die werden natürlich ganz oben entschieden. Es gibt verschiedene Teams, die Teams haben ihre eigenen Manager, dem die Entwickler unterstehen, und die Manager müssen wiederum der Führungsetage berichten. Die Entwickler bekommen also durch ihre Manager Vorgaben, was die aktuellen Prioritäten sind und woran sie arbeiten sollen. Einen gewissen Teil der Zeit können sich die Entwickler meines Wissens frei einteilen. So würde ich das grob beschreiben. Im Detail mag es komplexer sein, aber so tief stecke ich nicht drin, um das genauer zu sagen.

    Die Sache ist eben auch, dass Software-Entwicklung keine Demokratie sein kann, das kann nicht funktionieren. Frag 100 Leute und du bekommst 98 verschiedene Meinungen. Deswegen muss es Leute geben, welche Entscheidungen treffen.

    Entscheidungen werden aber auch nicht willkürlich getroffen. Bei Mozilla trifft man sehr gerne begründete Entscheidungen auf Grundlage von Daten. Telemetrie spielt dabei eine wichtige Rolle, wieso das auch möglichst jeder aktiviert haben sollte. Mozilla setzt auch immer häufiger auf A/B-Tests in Firefox für den Desktop und für Android. Ansonsten gibt es natürlich auch immer wieder Usertests mit echten Nutzern und auch allgemeine Nutzerforschung:

    https://mozilla-foundation-research.herokuapp.com/ und
    https://mozilla-foundation-research.herokuapp.com/globalweb/

    Das ist jetzt Foundation und sicher nicht alles für Firefox relevant, aber das zeigt ganz gut, dass da doch sehr aktiv auch an der Schaffung notwendiger Hintergründe gearbeitet wird und nicht nur blind Dinge entwickelt werden.