link? sehe da keinen offenen.
viele Gatways nutzen debian. Wenn fastd dort nicht mehr mit dem Kernel zurechtkommt, wird das auch ein gluon-Thema (sofern es wirklich bei einer simplen Ersetzung bleibt und keinen fallback gibt).
ob es fatal ist PRs nicht anzunehmen ist glaub ich auch so eine Sache. Manchmal ist ein bisschen weniger laut besser.
Und dann wäre da noch die Frage an neoraider: die Tests kommen aus der AA-Zeit. Meinst Du die sind jetzt noch gültig oder müsste jemand ™ das mal wiederholen?
PS: ich sehe gerade dass alle diese Punkte als Antwort an wusel gingen. Nur der erste war als direkte Antwort gedacht. Umgang mit dem Forum krieg ich auch irgendwann noch hin…
[quote=„Klaus_Dieter, post:22, topic:14863“]
viele Gatways nutzen debian.[/quote]
Und Millionen Fliegen können nicht irren: Scheiße schmeckt.
Beide Aussagen haben eines gemeinsam: mit fastd auf dem Knoten und wie fastd dort an »Zufall« herankommt, haben sie nichts zu tun.
Davon ab, Jessie kennt via Backports auch 4er Kernel, aber, nochmal: für fastd als Userspace-Anwendung ist die Version des Linux-Kernels egal (zumindest für Majors von 3 bis 5).
Und manchmal ist erst informieren, dann rumlabern, wirklich ein guter Ratschlag: in ffrn-lowmem-patches schlummerte in der Tat ein fieser Bug, wie auch im Dezember im dortigen Forum erkannt. Schön, daß er am 30.04. per Annahme des PR gefixt wurde (daher fand @rotanid keinen offenen PR mehr) und dank an @anon68922371 für den Hinweis. (Ich stehe ja auf gut abgehangene Software; daß das Problem im Dezember zwar erkannt, aber im Code noch nicht gefixt wurde, habe ich im Eifer des Gefechts bei der Übernahme auch übersehen Nunja, wurde so mein erster cherry-pick ;))
Vielleicht sollte der Titel auf »Strategien für eine Gluon-v2016.2-Firmware, die gut mit wenig RAM auskommt« geändert werden (in Anlehnung an Beitrag #3)? Denn, wie schon diskutiert, 4 MB Flash sind sehr knapp, aber im laufenden Betrieb schmerzt eher das kleine RAM.
Ja, ist Ok. Du hast recht und ich meine Ruhe. Das nicht mergen von bits in einem ff Projekt ist fatal, es können Menschen sterben. Abhängigkeiten von User space zu kernel existieren nicht, auch wenn Interfaces genutzt werden, die nicht in allen Kernels angeboten werden.
Das kann man natürlich so schreiben, dass es auch auf alten Kernels funktioniert und da auf /dev/random zurückfällt. Braucht man allein schon damit man nicht an Linux gebunden ist…
Aber mit der Anmerkung von Neoraider, dass die Linux-Entropieasammlung auf der Architektur ein bisschen buggy ist, hat sich das ja eh erledigt.
Die Antworten dort entsprechen ja im Fazit dem, was wir hier auch schon diskutiert haben.
Es gibt derzeit bei keinem Router ein Ram-Problem, was mit Verzicht auf einzelne Systemteile gelöst werden kann.
Die bei großen Domains auftretendenden Probeleme sind damit nicht zu lösen.
Entweder (mindestens) ein neuerer Batman und/oder ein 4er-Kernel. Oder gleich ein besseres Protokoll.
Nach einer Unterhaltung in #gluon mit @anon75826926 stellte sich raus: Es ist eigentlich nicht so gedacht, dass die RAM-Auslastung auf der Karte Buffer und Cache beinhaltet, denn beide Werte werden auf der Statusseite des Knotens herausgerechnet. Ist ja auch sinnvoller, die Werte herauszurechnen, weil der Kernel den freien RAM natürlich zum Cachen und Buffern nutzt, wie hier schon angeführt wurde, sodass die Auslastung dann immer recht nah am oberen Ende des insgesamt verfügbaren RAMs ist.
Der HopGlass-Server rechnet die Werte derzeit jedoch nicht heraus, sodass die Auslastung auf der Karte bei Communities, die den HopGlass-Server nutzen, immer höher angezeigt wird, als sie eigentlich ist.
Edit: Pull-Request erstellt, der diesen Umstand behebt