[Berlin-wireless] Firmware-binaries allgemein verfügbar machen

Sven Roederer freifunk at it-solutions.geroedel.de
Di Nov 24 00:33:12 CET 2020


Am Montag, 23. November 2020, 11:44:39 CET schrieb Martin Hübner:
> Hallo Sven,
> 
> > Gefühlt seit Mitte März lief die Installation nicht mehr rund und wurde
> > offensichtlich auch von niemandem gewartet. Was zum fehlen von aktuellen
> > builds und immer wieder aufkommenden Nachfragen von interessierten Unsern
> > bzgl. bekannter und beseitigter Problemen führte.
> 
> Die letzten dev-builds von Hedy datieren auf den 08.Juni 2020.[0] Soweit
> ich das bis jetzt überblicken konnte, liegt der Fehler alleine an einer
> disfunktionalen Verbindung mit Github, weshalb die wöchentlichen builds
> nicht mehr ausgeführt wurden. Also nichts, was sich nicht lösen ließe.

Zwischen den immer auffälligeren Problemen mit dem Buildbot, bis zu seinem 
völligen Ausfall verging einige Zeit. Und da sich offensichtlich niemand um 
den Betrieb kümmert, war eine alternative sinnvoll. Und kostenlose 
ausgelagerte Infrastruktur hat auch den Vorteil, dass sich niemand um die 
Administration so eines systems kümmern muss, die knappen Adminressourcen für 
wichtigere Systeme (Config, Monitor, OWM-alternative, ...) genutzt werden 
können.

> 
> Wir haben darüber tatsächlich diskutiert. Momentan denken die meisten
> der vier aktiven Falter-Entwickler so:
> Patches sollen, wie auch im README des hedy-buildsystems zu lesen ist,
> Upstream eingebracht werden. Tatsächlich passiert das kaum noch. Wir
> sehen die "Einschränkungen", die der Imagebuilder mit sich bringt, als
> Ansporn, die Sachen auch wirklich Upstream zu fixen und somit OpenWrt
> voran zu bringen. Selbst in der relativ kurzen Zeit, die wir Falter
> schon entwickeln, ist diese Taktik mehrmals aufgegangen.
> 

"Push upstream what upstream belongs" ist eine bekannte Prämisse, aber nicht 
alles gehört upstream und wird auch nicht immer akzeptiert. Und hier war es 
immer praktisch, einen Change für OpenWrt erstmal exakt genauso im Freifunk zu 
testen. (Ich glaube 95% meiner commits für OpenWrt sind so entstanden.)
Grad an dieser Stelle sehe ich das Konzept "wir kopieren uns die Upstream-
sourcen zusammen" kritisch. Denn so muss man jeden Change zweimal schrieben 
(einmal für das eigene repo, ein zweites mal für Upstream).

> Des weiteren denken die meisten von uns, dass Kompatibilität mit OpenWrt
> wichtig ist. Mit jedem abgefahren Patch entfernen wir uns weiter von
> OpenWrt und erhöhen unseren eigenen Wartungsaufwand. Das finden wir
> nicht so cool.
> 

Wie Holger mal sagte: Wir bauen Freifunk-Firmware, OpenWrt bau generisch 
Accesspoints und Router. Da wird es immer Änderungen geben, die Upstream nicht 
ankommen werden, für Freifunk aber wichtig oder mindestens hilfreich sind.

> Bisher haben wir alle unsere Probleme auch ohne Patches und
> neukompilieren gelöst bekommen.
> 

Wäre schön, wenn es so bleibt. Aber wie gesagt, QuellCode zur Laufzeit 
modifizieren - klingt für mich nicht wartungsfreundlich.

> >> Desweiteren kann man Falter dadurch nicht nur mit "mehr Routern",
> >> sondern mit allen (!) Routern nutzen, die OpenWrt von Haus aus
> >> unterstützt. (und die entsprechend Flash-speicher mitbringen...)
> > 
> > Die Ausrichtung der Freifunk-Berlin Firmware ist halt Router zu
> > unterstützen, die auch durch die Userbasis / Entwicklerbasis getestet und
> > supported werden. Denn was nutzt es am Ende, wenn ein neuer Freifunker
> > mit einem "EnGenius EPG5000" kommt, bei dem sich dann doch ein
> > unerwarteter Fehler herausstellt. Aber eine andere Definition der Ziele,
> > führt meist auch zu einem anderen Weg, diese zu erreichen.
> 
> Unbestritten ein sehr guter Punkt. :) Ich persönlich denke darüber
> folgendermaßen:
> 
> Für Freifunk-Einsteiger*innen sollten wir die Hürden niedrig halten.
> Natürlich ist es da ungünstig, wenn jemand™ mit einem seltenen Gerät
> ankommt (btw, EnGenius EPG5000 ist mit 185€ als Einstieg eher
> unwahrscheinlich...). Aber dafür kann man Kaufempfehlungen abgeben. Und
> das ist für mich der Casus cnactus:

War nur ein x beliebiges Beispiel aus der Geräteliste, Du kannst dir auch 
einen anderen 30€ Router raussuchen.

> 
> Einsteiger*innen brauchen Einfachheit. Und wenn du diese Leute erstmal
> auf nen Flohmarkt schicken musst, um steinalte Hardware zu kaufen, ist
> das nicht einfach, sondern erfordert Fachwissen und Sicherheit in dessen
> Anwendung. Beides fehlt Einsteigerinnen oft noch und die Vermittlung
> könnte überfordern.
> 
> MMn ist es bedeutend einfacher, Geräte verfügbar zu haben, sofort(!)
> nachdem sie in OpenWrt implementiert wurden. Das erhöht die Chancen,
> dass man aktuelle Hardware aus dem Laden beschaffen kann, immens.

Ja, Releaseziele und ggf. auch ein Releaseprozess wäre was feines. So hätte 
man sicherlich nicht die Umstellung von Lede-17.01 auf OpenWrt-18.06 und dann 
OpenWrt-19.07 verpaßt. Aber jetzt tut halt was er kann und so gab es neue 
Hardware nur in den Entwickler-firmwares in denen neue Issues schneller 
auftauschten, als bekannte beseitigt werden konnten, oder geeignete Konzepte 
fehlen / Designentscheidungen offen sind.

> > Siehe oben, das letzte halbe Jahr hat diese Infrastuktur Deutschland nur
> > ein kleines bisschen mehr vom erreichen der Klimaziele abgehalten.
> 
> Wenn du schmuddelig argumentieren möchtest, kann ich das auch tun. :)

ist nix schmuddelig. Ist halt Tatsache, dass die betroffenen Server nur 
rumstanden und Strom verbraucht haben.

> 
> > Über ASU (https://github.com/aparcar/asu) und download direkt aus dem
> > Router hab ich auch schon immer mal "geträumt".
> 
> Soweit ich weiß, unterstützt das Moritz' großartiger Firmware-Selector
> auch. :)
> 

Dann ist es schade, dass wir das bisher noch nicht implementiert hatten, als 
wir vor 2+ Jahren? vom damaligen System auf's Wiki umgestellt haben.

> 
> TL;DR: Ich habe nichts dagegen, zwei Firmwares zu haben. Jeder nach
> seiner Façon und so... Aber ich sehe auch, dass der Großteil der aktiven
> Community halt hinter Falter steht.
> 
User-Communityteil: Ich denke, denen ist es recht egal was die Firmware 
angeht, solanges es Click+Run ist. Und sobald es als offizielles Release 
verfügbar ist, rollt sich das dann halt langsam aus ...
Entwickler-Communityteil: ist eine ziemlich keine Gruppe, da sehe ich vom 
bisherigen Team eigentlich nur Perry, der jetzt auf der Spalter-Schiene wieder 
eingestiegen ist.

GRuss Sven




Mehr Informationen über die Mailingliste Berlin