[Berlin-wireless] Freifunk VM bei sys11 (Off-Topic: build Imagebuilder)

[Nick]

On 5/13/21 5:34 PM, Sven Roederer wrote:
> Am Samstag, 8. Mai 2021, 23:45:08 CEST schrieb Nick:
>>>> Aber das ja der Knackpunkt, dass einfach auf die OpenWrt Ressourcen zu
>>>> setzen, viel einfacherer, schneller und weniger Wartungsaufwand
>>>> bedeutet. Trotzdem benutzt z.B. gluon dies meines wissens auch nicht und
>>>> die Franken auch nicht. Das verstehe ich noch nicht so. Der einzige
>>>> usecase dafür sehe ich, dass wenn man OpenWrt spezifische Patches haben
>>>> möchte, oder kompatibilität für ältere Geräte weiter aufrecht erhalten
>>>> will. Aber diese Sachen kann man auch versuchen in den OpenWrt-Trunk
>>>> einzubringen, da dort ja auch viele Freifunker*innen unterwegs sind.
>>> Freifunk != OpenWrt und wie die Erfahrung halt gezeigt hat ist nicht alles
>>> was Freifunk hilft im Sinn von OpenWrt. Darum gibt's immer
>>> Freifunk-anpassungen, z.B. Einstellungen, Ergänzungen oder auch Backports
>> Das sehe ich irgendwie anders. Viele OpenWrt-Devs sind doch irgendwo bei
>> Freifunk mit aktiv? Oder waren es irgendwann mal. Natürlich kann auch
>> jeder irgendwas anderes benutzen als OpenWrt, aber es ist nunmal für
>> embedded Geräte gerade sehr gut zu benutzen.
>> Ich finde OpenWrt stellt eine gewisse Qulität für Lösungen sicher. Und
>> ich habe noch nie irgnedwie gesehen, dass die OpenWrt-Devs einen
>> auflaufen lassen. Kannst du einfach mal konkret nen Beispiel nennen,
>> außer die Abschaffung von " < 32 MB Ram" oder "< 16 MB Flash"?
> * porting GLinet ar750 to ath79 for openwrt-19-07) https://
> patchwork.ozlabs.org/project/openwrt/patch/20191213195046.13358-1-devel-
> sven at geroedel.de/)
> * moving 8/32 MB devices to tiny-subtarget (http://lists.openwrt.org/
> pipermail/openwrt-devel/2020-December/032575.html).
> * Aruba AP-303 for OpenWrt-19.07 (https://github.com/freifunk-gluon/gluon/
> commit/8df207c103d0ebc6e55d5ecd301e0f7348e647ce)
>
> Based on these cases I understand the arguments of the OpenWrt devs, even
> Adrian and David would benefit in Gluon from these changes

Naja das mit dem Backporting sind ja auch "rules" von OpenWrt selber. Da 
können sich ja die Core-Devs nicht wirklich drüber wegsetzen. Support 
für Devices wird meistens halt nicht mehr gebackported. Um trotzdem alle 
User abzuspeisen bieten wir Snapshot Builds an, wo die Targets dann 
drinne sind.

Ich finde den Vorschag mit "LOW_RESSOURCES" eigentlich ziemlich gut? 
Dort sind ja überwiegend die Kernel Flags wichtig. Packages kannst du ja 
hinzufügen und entfernen wie du willst. Die Kernelgröße halt nicht.

Also mit dem Backporting ist schon manchmal schade. Aber das ja nicht 
Freifunk spezifisch? Ich meine das betrifft ja jedes Projekt und OpenWrt 
an sich. Ich bin der Meinung, dass es mal irgendwann hieß, dass ein 
OpenWrt Release Cycle von 6 Monaten in Planung ist. xD

Für mich reicht das trotzdem nicht so ein komplett eigenes Ding zu 
machen. ;)

>> Selbst
>> Wien benutzt glaube ich die Stock-Firmware von irgendwelchen Herstellern
>> und führt darauf nur seinen olsrv2 daemon aus. Am Ende ist ja nur der
>> Mesh-Daemon wichtig.
>>
> Das ist jetzt ein Apfel mit Birnen-Vergleich: Wenn du komplett auf Vendor-
> Firmware setzt und dir etwas Code via SDK selbst bauen darfst ist das ein ganz
> anderer Ansatz als den kompletten Quellcode zu haben und den für dich nutzbar
> zu machen.
> Wenn man Freifunk nicht nur als Mesh-Netzwerk sieht, sondern als autonome
> Lösung, macht es schon sinn dir Software vollständig zu bauen - ohne
> Abhängigkeit zum Hersteller (egal ob Hersteller OpenWrt oder Firma X ist). Ich
> meine vor Urzeiten gabe es ein SDK von Ubiquiti für eigene Binaries, doch das
> wurde dann eingestellt. Das ist dann eine nicht kontrollierbare Abhängigkeit,
> die dir das Genick brechen kann.

Ich hätte gerne so viele offene Software wie möglich. Aber das geht halt 
einfach nicht auf Backbone-Strecken ohne Performance Verluste. Am Ende 
müsstet man überall auf ath9k setzen, wenn man es wirklich offen haben 
will. Das geht irgendwann einfach nicht mehr.

OpenWrt als Abhängigkeit zu bezeichnen finde ich halt diskussionwürdig. 
OpenWrt ist doch schon unglaublich modular? Man kann ein Mesh-Netzwerk 
auch so sehen, dass es sehr heterogen aufgebaut ist. :P

>>>> Wir
>>>> hatten auch letztens ne Diskussion über den Sinn ältere Geräte weiter
>>>> mitzuziehen. Dort ging es auch so weit dass der Flash und RAM des WR841
>>>> ausgetauscht werden sollte. Ich finde das aber einfach nicht mehr
>>>> zukunftsfähig, bzw. die älteren Geräte nehmen in Berlin auch wichtige
>>>> Ressourcen weg. Dort kann ruhig schonmal das 2.4 GHz wieder für 802.11ax
>>>> frei gemacht werden. xP
>>> Das alter Geräte-Problem ... läßt man den User mit seiner alten, zum Teil
>>> mit Sicherheitsproblemen behafteter Software stehen, zwingt sie zum
>>> "Sofortaustausch" oder findet einen Zwischenweg ...
>>> Der berühmte "WR841-Flash-Mod" .... ist unterwegs seit 4-5 Jahren ... aber
>>> ich hab noch von keiner größeren Verbreitung in Hardware gehört. Das
>>> Problem relativiert sich eh, denn auch 8/32MB Geräte sind mit OpenWrt
>>> 23.xx wohl nicht mehr sinnvoll nutzbar.
>> Naja was heißt den Soforttausch? Selbst die ollen Nanostations M5 sind
>> noch in OpenWrt 21.02 supported, was ja noch ein bisschen länger
>> supported wird. ;)
> Ja unterstützt schon als einfacher AP. Aber mit OpenWrt-21.02 laufen die im
> OLSR-netz mit LuCI i.d.R. 30 Minuten, bis sie wegen Speichermangel neustarten.
Ja, aber deswegen sollte man die vielleicht nicht mehr mit OLSR ins Netz 
hängen. :S
Ich häng die halt nur noch als AP ins Netz.
>> Hedy baut ja eh noch auf LEDE 17.04 auf? Am Ende würde ich mich freuen,
>> wenn die Leute nicht mega alte Hardware in das Netz hängen, da dies ja
>> auch irgendwie das ganze Netz beeinflusst. Dies wäre auch ganz nett,
>> wenn wir eine gewisse Qualität sicherstellen könnten und auch vor allem
>> die Erweiterbarkeit.
>>
>> Ich glaube wir haben auch einfach ein bisschen andere Sicht auf das
>> Thema. Wenn man natürlich einfach nur nen HotSpot betreiben will, wobei
>> wir dann die IP verschleiern, dann braucht man keine aktuelle Hardware.
> Beide Punkt sind halt die Abwägung zwischen "was wünscht sich der Entwickler"
> und "was wünscht sich die Community". Wenn die User bei ihrer bestehenden
> Hardware bleiben wollen, (verlängerte Hardware-Lebensdauer, Kostenersparnis,
> Inselbetrieb) können idR. auch noch so schöne Entwicklungsideen ein Upgrade
> fördern.
Naja die Community updatet ja eh nicht. xD
Kauft man sich einen zukunftsfähigen Router, dann werden wir das schon 
bestimm 5 Jahre supporten.
>> Versuchen wir aber ein dezentralisiertes vermaschtes Netz zu bauen, was
>> konkurrenzfähig zu ISPs bzw. Mobilfunkprovidern sein soll, sehe ich das
>> ein bisschen anders.
> Will Freifunk 5G Konkurrenz machen? 1GBit/s in der Luft sehe ich nicht als
> Freifunk-Kernziel. Ein unabhängiges Alternativ-Netz dagegen schon
Was bringt einem die alternative wenn sie nicht benutzt wird, bzw. nicht 
performed. Ich befürchte, dann werden die Leute ihre Sachen abbauen und 
das Netz wird kaputt gehen. Warum sollte wir uns nicht ambitionierte 
Ziele setzen. :D Andere Freifunk Communities bauen massiv 60 GHz aus ud 
haben unglaubliche Performance.
>> Zudem habe ich die Befürchtung, dass die
>> Standalone-Solutions irgendwann ehrlich gesagt keine Zukunft mehr haben.
>>
>> :/ Hab da auch schon letztens mit München drüber geredet. Aber mal
>>
>> sehen, hoffentlich habe ich unrecht. ;)
>>
> Was meinst du mit "Standalone-Solutions"?
Router die nur per Tunneldigger mit einem "Exit-Knoten" verbunden sind.

Viele Grüße
Nick