[firmware] Umstellung auf GLUON? (#7)

[Andreas Müller]

Hi,

ja, klingt gut. Ich wäre auf jeden Fall dabei!
Hast du Vorschläge wann und wo?

Viele Grüße
Andreas



> Am 28.10.2014 um 22:26 schrieb Tim Niemeyer <tim.niemeyer at mastersword.de>:
> 
> Hi
> 
> Wollen wir vielleicht einfach mal ein Hack-Treffen machen, wo wir uns
> das Thema dann mal in Ruhe annehmen?
> 
> Tim
> 
> Am Montag, den 27.10.2014, 22:11 +0100 schrieb Andreas Müller:
>> Hi,
>> 
>> 
>> wie schon auf GitHub erwähnt, jetzt nochmal in der Mailingliste: ich
>> kann zu dem Thema leider nicht wirklich viel sagen, weil ich mich noch
>> nicht wirklich damit beschäftigt habe.
>> Wenn ich bei der Entwicklung irgendwo gebraucht werde, würde ich gerne
>> mithelfen.
>> 
>> 
>> Viele Grüße
>> Andreas
>> 
>> 
>> 
>> 
>> 
>>> Am 27.10.2014 um 21:56 schrieb Tim Niemeyer
>>> <tim.niemeyer at mastersword.de>:
>>> 
>>> Hi
>>> 
>>> Bitte lasst uns das nicht in diesem unübersichtlichen Bug-Tracker
>>> bereden. Da gibt es keine Threads und nix..
>>> 
>>> 
>>> Meine Gedanken zum Gluon:
>>> 
>>> = Gluon =
>>> Die meisten Leute wissen gar nicht was Gluon ist. Die wenigen, die
>>> glauben zu wissen was es ist, behaupten häufig es wäre eine
>>> Freifunk-Firmware. Tatsächlich ist es nur ein Framework um etwas
>>> "vereinfachter" eine Freifunk Firmware zu bauen. Dabei ist Gluon
>>> aber
>>> eben nur eines von vielen.
>>> Tatsächlich haben wir in Franken das Framework im Einsatz, was
>>> damals in
>>> Oldenburg entwickelt und in Franken weiterentwickelt wurde. Dieses
>>> macht
>>> einige Dinge anders, manche Dinge sind nicht so weit entwickelt,
>>> manche
>>> sind weiter.
>>> 
>>> Gluon bringt einige Pakete mit, die man für eine Freifunk Firmware
>>> benutzen kann (und dank kaputter Abhängigkeiten, oft auch muss).
>>> Dazu
>>> zählen zum Beispiel:
>>> 
>>> * Der Config Mode
>>> Der Config-Mode erscheint auf den ersten Blick ein sinnvolles Tool
>>> zu
>>> sein. Man erwartet ein Webinterface, worüber man den Router zu jeder
>>> Zeit bearbeiten kann. Wir müssen uns aber erstmal im Klaren werden:
>>> Das
>>> Teil ist nur da, wenn der Router in den Modus gebootet wird! Jetzt
>>> können wir überlegen, ob wir Gluon so umbauen, dass das Ding immer
>>> da
>>> ist. Davon abgesehen sollte man wissen, was man dort überhaupt zum
>>> konfigurieren anbietet. Meiner Meinung ist es sinnvoll:
>>> ** Hood
>>> ** Passwort
>>> ** Router-Name
>>> ** Standort (spätestens hier gibt es das Problem, dass ein Router im
>>> normalen Config-Modus nicht mit der Außenwelt reden kann)
>>> ** Betreiber Kontakt
>>> 
>>> * Das Auto-Update
>>> Das Auto-Update ist extrem umstritten. Vielen wollen sich damit die
>>> Arbeit erleichtern, aber andere empfinden das zentral (durch eine
>>> Handvoll Leute) gesteurte Auto-Update eher wie ein
>>> "Drohnen-Kontroll-System". Mit dem Auto-Update werden aus allen
>>> Freifunk-Knoten plötzlich ganz dumme Knoten, die von einer zentralen
>>> Stelle aus ferngesteuert werden. Das Gegenargutment ist dann immer
>>> nur
>>> "Kann man ja abschalten". Darauf wird immer erwiedert: "Wir haben
>>> bereits eine offene Schnittstelle um ein Auto-Update zu
>>> implementieren.". Über diese Schnittstelle kann schnell ein
>>> Fernwartungssystem geskriptet werden, Tools gibt es da wie Sand am
>>> Meer
>>> (pssh, um nur eins zu nennen).
>>> Ich finde es wichtig von dieser Auto-Update Diskussion weg zu
>>> kommen.
>>> Wir wollen kein zentrales Update und es muss auch nicht zwingend
>>> automatisch sein. Wir wollen ein einfaches Update und was noch viel
>>> wichtiger ist, wir wollen die Kontrolle. Spätestens wenn wir uns mal
>>> ernsthaft _untereinander_ vernetzen wird Kompatibilität plötzlich
>>> eine
>>> super wichtige Rolle spielen. Da ist dann ein Update eventuell ein
>>> No-Go, so lange nicht alle Peerings mitspielen.
>>> 
>>> * Kein Switch-Support
>>> Mit Gluon verlieren wir die Möglichkeit die Knoten schnell mal per
>>> Kabel
>>> zu vernetzen und trotzdem Clients per Kabel anzuschließen. Dies ist
>>> ein
>>> seit langer Zeit nachgefragtes Feature, was aber vermutlich durch
>>> die
>>> schiere Masse an Routern nicht so leicht umsetzbar ist. Hier ist
>>> ständiges Nachjustieren und Testen wichtig, was eben nicht für alle
>>> unterstützen Geräte gewährleistet werden kann. Eventuell ist das für
>>> uns
>>> aber auch nicht wichtig, da bei größeren Setups eh eine individuelle
>>> Lösung her muss.
>>> 
>>> Leider ist es nicht möglich diese Gluon-Pakete über ein System an-
>>> und
>>> abzuwählen, welches auch Abhängigkeiten auflösen kann. Hier wurde
>>> ein
>>> gehyptes config-Format gewählt, welches aber technischerweise keine
>>> Abhängigkeiten auflösen kann. Die richtige Wahl wäre z.B. Kconfig
>>> gewesen. Natürlich spricht nichts dagegen die site-config durch ein
>>> ordentliches System zu ersetzen, muss man aber halt mal machen.
>>> 
>>> Tim
>>> -- 
>>> franken-dev mailing list
>>> franken-dev at freifunk.net
>>> http://lists.freifunk.net/mailman/listinfo/franken-dev-freifunk.net
>>> 
>> 
>> 
> 

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.freifunk.net/pipermail/franken-dev-freifunk.net/attachments/20141028/9ad5d1a0/attachment-0002.html>