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

[Sven Roederer]

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

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

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

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

> 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

> 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"?

Sven