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

Martin Hübner martin.hubner at web.de
Di Nov 24 12:22:51 CET 2020


Hallo Sven,

>> 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.
>
Dass der Buildbot komplett ausgefallen sei stimmt nicht. Der Buildbot
war die ganze Zeit über funktionstüchtig. Die Integration mit Github ist
kaputtgegangen. Ob das im Zuge der diversen Änderungen am Build-System
passierte, oder wegen der API-Änderungen bei Github, ist hinfällig. Ich
habe gestern viele Falter-Targets testweise bauen können. Funktioniert
großartig. :)

>>
>> 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).
>
Kannst du bitte nochmal ausführen, was du in diesem Fall mit Upstream
meinst? Wir haben in Falter keinen Upstream-Code in deinem Sinn. Wir
holen uns vorkompiliertes OpenWrt. Falls du die Falter-Pakete als
"Downstream" zu den Freifunk-berlin-packages siehst, kann ich dir
versichern, dass ich falter-packages als deren vollständigen Ersatz
sehe. Inzwischen gibt es da auch schon einige Unterschiede. :)

>> 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.
>

Genau dafür haben wir unseren eigenen Packagefeed. Kernel-Patches
sollten aber für eine Freifunk-Firmware definitiv nicht nötig sein.


>> >> 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.
>

Womit wir wieder beim Thema wären, dass der 30€-Router überhaupt von
OpenWrt unterstützt werden muss.


>>
>> > Ü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.
>
Den Firmware-Selector gibt es seit diesem Frühjahr. AFAICT wird er auch
Firmware-Selector für OpenWrt werden.

>>
>> 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.

Ich musste bei "klein" ziemlich Schmunzeln. :) Eigentlich entwickelt
doch nur noch einer an Hedy, du selbst. Vor einem Jahr hast du das
anderen Menschen vorgehalten. Es ist müßig darüber zu diskutieren, warum
Menschen keinen Bock mehr hatten, an hedy weiterzuentwickeln. Das ist
Vergangenheit.

Aber an Falter entwickeln gerade 4 Leute aktiv mit. "ziemlich kleine
Gruppe" ist im Vergleich zum aktuellen Hedy-Entwickler-Kreis also ein
bisschen, nunja, ich finde es amüsant. :D

Fakt ist, dass Viele die Prinzipien, die im Hedy-Projekt vertreten
werden, so nicht mehr teilen. Hedy krankt daran, dass Entscheidungen,
aufgrund von Unterschiedlichen Sichtweisen, nicht mehr möglich waren.*
Ein eigener Fork war die einzig logische Konsequenz. Übrigens eine
Wunderbare Anwendung des "jeder nach seiner Façon"-Prinzips. :)


Viele Grüße
Martin


* Beispiel: Anstatt ein favicon mit Freifunk-Logo einfach in die Images
einzubetten, ein komplett neues LuCI-Theme schreiben.
Und solcher Dinge mehr.



Mehr Informationen über die Mailingliste Berlin