Hallo zusammen,
wo ist der Unterschied bei der Firmware experimental oder stable?
MfG
Marcel
FF Harz
Hier sind die Release-Typen erklärt: Freifunk Aachen/Firmware – wiki.freifunk.net
In Kürze: Experimental sind Releases, die die Entwickler zum „Basteln“ und Ausprobieren nutzen. Dabei kann natürlich auch mal etwas schiefgehen, daher solltest Du Experimental nur verwenden, wenn Du wirklich weißt, was Du tust. Stable sind „fertige“ Releases, die normalerweise ohne Schwierigkeiten auf Deinen Routern laufen können (= Produktiveinsatz).
Das hab ich mir schon fast gedacht, das erklärt auch die häufigen Abstürze. Werde dann mal die Router mit der Anderen Firmware ausstatten. Vielen Dank für die schnelle Antwort.
Insbesondere sind „experimental“ solche, bei denen die Entwickler schonmal 2-3 mal in der Woche neue Versionen nachschieben.
Und abgesehen davon, dass das natürlich häufig zu den besten Abendstunden passiert, wenn dann beim Autoupdate-Flashen was schief geht, dann sollte man es
a) zeitnah bemerken (oder nicht auf den Knoten angewiesen sein)
b) überhaupt in der Lage sein, sich z.B. mittels Pushbutton-TFTP selbst zu helfen, wenn das denn geht bei dem Modell. Oder wissen, wie die serielle Console angeklemmt wird und was man da tippen muss.
Sprich: JedeR, der eine Experimental fährt, der hilft den Firmwarebauenden. Nur bedeutet das im Zweifelsfall auch, das Ding mal „debricken“, oder mindestens mal Powercyceln zu müssen.
Ich glaube, das unterscheidet sich auch ein wenig von Community zu Community. Manche Communities hauen im experiementellen Zweig gänzlich ungetestete Firmware raus. Es kann also passieren, dass man ab und zu mal den Router per tftp reparieren muss, wenn was kaputt geht.
Beta ist dahingegend schon vorgetestet und wird auf Langzeitstabilität untersucht.
Beides würde ich nur aktivieren, wenn ich an die Router halbwegs passabel rankomme, also nicht z. B. beim Nachbarn aufgestellt sind.
Beta ist immer eine gute idee, wenn man Freifunk auch selbst nutzt und Fehler berichten kann. Und zudem sich zutraut auch den Router zu reparieren, sollte er mal kaputt gehen.
Grüße
Matthias
1 „Gefällt mir“
Definitiv 
Bei uns (Kreis GT / Müritz-Region) gibt es »rawhide« (weil es einfach schön roh klingt ;)), das fällt direkt aus dem Compiler. Das kann durchaus so broken sein, daß danach die Erde eine Scheibe ist. Eigentlich ohne Autoupdater, hat sich gezeigt, daß jener auch dort praktisch sein kann. Wer das bei uns einsetzt, sollte wirklich wissen, was er/sie/es tut. Also, wirklich »wirklich« …
Nächster Level ist »experimental«, das hat dann zumindest den Status »keines der ersten Testsysteme ist direkt in einem Lögikwölkchen verschwunden« erreicht: sollte flash- und updatebar sein, prinzipiell funktionieren, aber es sind längst nicht alle Änderungen durchgetestet.
Wir nutzen das für einen ersten »Livetest«, d. h. es gibt so knapp 2% an Knoten im Netz, die gezielt auf diesen Zweig des Autoupdaters konfiguriert sind. Vorzugsweise als Uplink oder Client in Meshes, auch gerne durch die verschiedenen Hardware-Typen durch. Vorzugsweise gut erreichbare Systeme …
Dann kommt bei uns »testing«, das ist wohl das, was andere Communities »beta« nennen: eigentlich hinreichend abgehangen und die Kernfunktionen durchgetestet (das schließt bei uns auch Reflash auf >1 Hardware inkl. Configmode, möglichst alle Optionen auch mal durchgeklickt, ein). Auch hier haben wir ca. 2% partizipierende Knoten. In diesem Status wäre eine Firmware bei uns ein Release-Kandidat, der nächste Schritt, nach typisch einer Woche (faktisch meist mehr) wäre dann …
»stable«: eine Firmware, die das Netz nicht runterziehen sollte und den Möglichkeiten gemäß für den allgemeinen Einsatz getestet ist.
Bei uns sagt die Versionsnummer nichts über den Reifegrad aus; jede FW startet als »rawhide« und wenn die ersten Tests ok waren, wird aus eben jener Version eine »experimental« (und dann ggf. über »testing« eine »stable«). Dies stellt sicher, daß nicht ein Rekompilat als experimental/testing/stable versehentlich ein anderes Binary erzeugt und so die vorherigen Tests nihiliert (außerdem spart es Rechenzeit und Plattenplatz ;)). (FTR: Unser Buildprozeß legt die entsprechenden Manifest-Dateien jeweils an, ein Promote nach experimental/testing/stable ist faktisch ein rsync der *${version}*-Dateien aus dem »rawhide«- in das »experimental«- (testing/stable) -Verzeichnis und hinzugfügen der nötigen Signaturen zu den Autoupdate-Manifesten.)
Oder, wie wir es auf unserer Firmware-Download-Seite beschrieben haben:
Von der Verwendung der Rawhide-Firmware wird ganz ausdrücklich abgeraten, diese ist latent buggy und wirklich nur der erste Wurf für interne Tests … Rawhide-Images werden automatisch nach Codeänderungen erzeugt und hochgeladen, sie sind nicht vorher getestet worden!
Experimental-Firmware sollte nicht eingesetzt werden, außer, »Du weißt, was Du tust«
Firmwares aus den Reihen »stable«, »testing« und »experimental« können automatisch aktualisiert werden (voreingestellt ist die Aktualisierung auf eine »stable«-Version); »rawhide« bedingt immer manuelles Updating! (Konkret: es gibt keinen Autoupdater für »rawhide« und voreingestellt ist auch dort »stable«.)
Gut, der letzte Halbsatz gilt nicht mehr, aber »rawhide« sollte man wirklich nicht als Autoupdater-Quelle einsetzen. Nicht alles, was kompiliert, ist auch sinnvoller Code
Und bislang klappt es, wie gewünscht; für u. a. den 1043v4, kam, als die einzige Firmware noch die im »rawhide«-Zweig war, oft die Nachfrage rein, wann denn denn eine »stable« vorläge bzw. beim Verweis auf die »rawhide«-Version die verunsicherte Nachfrage, ob das unser Ernst sei
Um dem Themenstarter also zu antworten:
Wie der Name suggeriert, ist »stable« (»stabil«) das, was man normalerweise einsetzen will und sollte. Experimentierfreudige mit Zeit und Know-How sind die Zielgruppe aller anderen Firmware-Varianten, welche sinnvollerweise in Absprache mit der Community/deren Firmwaretüftlern zum Einsatz kommen sollten.
Oder, andersrum: »latest« ist hier mitnichten immer »greatest«