[Frage] Idee bezüglich der Remove-Patches

[MrTweek1987]

Hallo,
Ich habe mir mal Gedanken gemacht über diese "Remove-Patches"... (nicht die Replace-patches) ansich sind Sie ja eine tolle sache, wenn es darum geht Speicher freizuschaufeln, oder "eh nie" verwendete Funktionen zu entfernen. Beim letzteren ist eher nochmal die idee gekommen, dass man die Remove-patches vervollständigt (das man auch weitestgehend das Web-IF "fixt", ich meine was bringt es wenn man die binaries des Media-Services löscht, jedoch aber die Web-IF Menüs noch drin lässt. An sich ist das IF etwas komplex aber man sollte bedenken, dass man auch am Web-IF einiges an KB rausholen kann (pro seite eventuell 5 kb).

mit meinem Problem ticket #2201 wurde scheinbar etwas angerissen, was nun eher etwas an "tiefgründigeren" arbeiten reicht.

hier mal ein beispiel: remove-branding, dieser könnte auch (wenn er es nicht tut) das ganze 1und1 zeugs entfernen und in der rc.S, den teil der oem-config abendern:

##########################################################################################
## OEM spezifische Konfiguration
##########################################################################################
if [ "$OEM" = "avm" ]; then
export CONFIG_MULTI_COUNTRY="n"
export CONFIG_TR064="n"
export CONFIG_DSL_MULTI_ANNEX="n"
export CONFIG_MULTI_LANGUAGE="n"
export CONFIG_PROV_DEFAULT="n"
fi

if [ "$OEM" = "1und1" ]; then
export CONFIG_MULTI_COUNTRY="n"
export CONFIG_TR064="n"
export CONFIG_DSL_MULTI_ANNEX="n"
export CONFIG_PRODUKT_NAME="FRITZ!Box Fon WLAN 7270 v2 (UI)"
export CONFIG_MULTI_LANGUAGE="n"
export CONFIG_PROV_DEFAULT="n"
fi

zu

##########################################################################################
## OEM spezifische Konfiguration
##########################################################################################
export CONFIG_MULTI_COUNTRY="n"
export CONFIG_TR064="n"
export CONFIG_DSL_MULTI_ANNEX="n"
export CONFIG_PRODUKT_NAME="FRITZ!Box Fon WLAN 7270 v2"
export CONFIG_MULTI_LANGUAGE="n"
export CONFIG_PROV_DEFAULT="n"

is nur ne idee <.< ...

oder das 2te beispiel Aura scheint auch nicht fehlerfrei zu sein, in einem USB-RC-Script wird versucht nach usb-mount() das USB-aura zu starten obwohl der remove-aura-patch die datei "aura" bereits entfernt hat <.< ...

 

[SaschaBr]

Ich denke, es gibt gute Gründe dafür, warum das WebIf selten bis gar nicht angepasst wird. Ich könnte mir vorstellen, dass das eine Fummelarbeit ist, sich durch das WebIf oder die Scripte zu wuseln, und alle Stellen zu finden, um etwas zu löschen oder anzupassen, nur um noch ein "par" Bytes herauszuholen. Auch die Pflege dieser Anpassungen dürfte mit Sicherheit ziemlich Aufwändig sein.

 

[MrTweek1987]

Ich denke, dass da aber die Ursache liegt, dass die meisten Rev`s von Freetz irgendwie nicht mehr so stabil laufen, denn wenn man zb ein RC-Script nicht sauber patcht (man lässt sachen drine -> Aufrufen von anderen RC-Scripten, welche nicht mehr im Image sind), kommt es zu fehlern im ablauf oder es funktioniert eine sache nicht mehr so richtig, sind garnicht mehr einstellbar oder sachen werden sogar blockiert.

Ich meine ja nicht dass man das in einer Woche machen muss. Aber man sollte wenn man in zukunft eine neue Firmware "supported", auch den Remove-Patch anpassen, so dass er wenigstens Calls wie "/etc/init.d/rc-script-xy.rc start" oder "/etc/init.d/rc-script-xy.rc stop" nicht mehr ausführt. das machen nicht alle remove-patches ("Remove-aura" ist einer davon und das ticket wurde bereits erstellt) Ich will nicht das letzte Byte im Flash freiklopfen... aber ein RC-Script was nicht bereinigt ist, kostet auch wertvolle KB im RAM ein freetz-image sollte fehlerfrei starten und stabil laufen. klar steht im patch immer "kann zu fehlfunktion führen" aber mit der zeit muss man auch mal daran arbeiten, gerade an die "in die jahre gekommenden Remove"-patches indem sie an die neue API und Firmware angepasst werden. Ich möchte nicht, dass alle jetz an den Removern rumbauen nur weil nen feature nicht funktioniert XD, aber wir sollten alle wenigstens wenn die möglichkeit besteht, sich mal mit alten "removern" beschäftigen und nicht nur wenns brennt, nämlich davon lebt Freetz - damit es stabil läuft und auch das erfüllt was man damit auf seiner Fritzbox erreichen will. Klar ist es manchmal zeitaufwendig und alles läuft nicht immer glatt, wie zb wenn man Freetz kompatibel macht für eine 74XX, und dabei versehendlich die 7270 mit der nächsten revision unbrauchtbar macht weil sie nurnoch crash-loopt, das ist auch voll verständlich ... manchmal auch zum schmunzeln und zeigt auch immerwieder wie eine AVM-FIrmware arbeitet. Nur schade fand ich in manchen "Removern", dass man nur binaries löscht(e), aber im WebIF garnichts mehr macht, diese dann jahre im Archiv liegen weil sie seit 77000XXXXXXX sauber soweit funktionierten und in neueren Firmware eher mehr probleme machen als ihren eigentlichen Sinn. daher sollte man so finde ich, Remove-patches wie "Webdav","mediaserv" sowie "NAS" aus dem Satble-Branch entfernen und im devel-branch lassen, wo man weiß dass sie erstmal gefixt werden müssen.

 

[Joe82]

Hallo,

Ich denke, dass da aber die Ursache liegt, dass die meisten Rev`s von Freetz irgendwie nicht mehr so stabil laufen

Dem möchte ich mal ganz entschieden wiedersprechen. Selbst der Trunk läuft so gut wie in meinen Augen schon sehr lange nicht mehr. Und ich nutze einige der Remove Patches. Was ich an deinem Vorschlag gut finden würde ist, dass beim Ersatz einer AVM Version eines Dienstes durch einen Freetz eigenen, das Web-Interface von AVM angepasst würde. Das fällt mir insbesondere beim Samba immer wieder auf. Es wäre da passender, wenn man alles in Freetz machen würde und es im AVM Interface verschwinden würde.

Joe

 

[RalfFriedl]

Ich möchte nicht, dass alle jetz an den Removern rumbauen nur weil nen feature nicht funktioniert XD, aber wir sollten alle wenigstens wenn die möglichkeit besteht, sich mal mit alten "removern" beschäftigen

Gute Idee.
So wie es aussieht, hast Du Dich am meisten mit dem Thema befasst. Schick mal die Patches, damit diese Funktionen endlich mal angepasst werden können.

PS:
Ein bisschen Rechtschreibung und Grammatik würde den Beitrag noch viel verständlicher machen.

 

[olistudent]

Wie im Ticket schon geschrieben bin ich auch der Meinung, dass zu viel Zeitaufwand bei den remove-Patches vergeudete Zeit ist. Natürlich sollten die Abhängigkeiten stimmen und keine Fehler im Webinterface auftauchen. Der Rest ist nur Kosmetik.