Das "Erweitern" der Firmeware scheint noch seine Berechtigung zu haben:
Ich habe nichts Gegenteiliges behauptet, sondern ich schrieb explizit (was Du ja auch zitierst), daß es immer weniger attraktiv wird (wobei sich das "weniger werden" darauf beziehen sollte, daß der Kreis derer, die das letztlich auch verwenden, immer kleiner wird - warum das so ist (nach meiner Ansicht), begründe ich ja auch gleich danach noch) ... es kommt halt auch immer darauf an, WAS man da genau erweitert.
Ich würde eben keine OwnCloud-Instanz oder irgendwelche anderen Services, die eine komplette LAMP-Installation brauchen (wobei das P gerne auch für Python oder Perl stehen mag, obwohl es ursprünglich m.W. mal PHP war), auf eine FRITZ!Box packen, die nebenbei noch DECT-Geräte zu bedienen hat (wo m.W. das TDMA immer noch software-basiert gesteuert wird bzw. die eintreffenden Pakete rechtzeitig(!) vorliegen und/oder abgeholt werden müssen - zumindest legen das ein paar Messages in der Firmware/Console nahe) oder was die Leute auch immer sonst noch so auf ihren Boxen machen.
Schon bei PiHole oder einem Tor-Proxy (alles auf einer FRITZ!Box) wird das aber auch ganz schnell wieder kritisch (und mir muß jetzt auch niemand unbedingt schreiben: "bei mir aber nicht" - das ist eben auch immer eine Frage, was die Box sonst noch so machen soll). Und auch nicht jedes AVM-Modell kommt "im Vollausbau" daher und wenn da eine Box ohnehin schon nur 128 MB RAM hat, sollte man da nichts anderes installieren, was entsprechend speicherhungrig ist ... und so weiter und so fort.
Geht man das hingegen mit Augenmaß an und hat eine Box, die eben nicht schon "auf Anschlag" läuft (VPN und SMB nicht zu nutzen, ist da schon mal ein guter Einstieg), macht das sogar wieder sehr viel Sinn ... nur kennen sich die meisten eben mit FRITZ!Boxen nicht so gut aus und ehe man sich da - aus reinem "Unvermögen", was bitte niemand wieder persönlich nehmen sollte - ein paar Löcher in seinen Edge-Router reißt, sollte man sich zumindest mal überlegen, ob ein ausgelagertes Gerät nicht doch besser ist für die eigenen Ansprüche.
Ich bin auch sicherlich der (Vor-)Letzte, der jemandem den Spaß an der Modifikation der AVM-Firmware verbieten oder auch nur vermiesen möchte - das würde ja irgendwie auch nicht zu meinen sonstigen Aktivitäten passen (und da passe ich meine Angebote für andere ja auch einigermaßen regelmäßig an, wenn AVM neue Release-Versionen herausgibt). Aber man sollte eben - in jedem Falle - auch wissen, was man da macht - es ist ein wenig wie die Reparatur der Bremsen am PKW. Auch da interessiert es kein Schwein, wenn man einen Reifen wechselt, das Teil komplett neu lackiert (aber schön eintragen lassen) oder einen prolligen Spoiler auf die Kofferklappe baut (obwohl auch der wieder gefährlich wird, wenn er sich bei 250 km/h auf der Autobahn dazu entschließt, das weitere Zusammenwirken mit dem PKW spontan zu beenden und lieber eigene Wege zu gehen).
Und so, wie die Sicherheit nach einer Reparatur der Bremsen noch vorhanden sein sollte (da interessiert mich auch weniger der Baum/die Brücke, die ansonsten als nächstes Ziel anvisiert werden könnten, sondern eher die Schulkinder am FGÜ oder die Seniorin an der Ampel), sollte auch bei der FRITZ!Box nach den eigenen Änderungen noch gegeben sein, daß die niemand einfach kapern und für Angriffe auf Dritte benutzen kann.
Und das mit der zweiten BusyBox ... ja, das ist sicherlich auch eine Möglichkeit. Ich würde trotzdem (solange ich mir sicher sein kann, daß meine eigene BusyBox zum Rest der AVM-Firmware paßt) hingehen und die im originalen System ersetzen - es ist schon nervig, wenn man vor jedes weitere Kommando dann den Pfad zur eigenen BusyBox schreiben muß, weil ansonsten (auch ein wenig in Abhängigkeit von den Einstellungen, mit denen die BusyBox erstellt wurde) irgendwo ein (Sym-)Link auf die originale BusyBox existieren könnte, der dann wieder dazu führt, daß ein Applet aus dieser originalen BusyBox verwendet wird, was ggf. wieder ein paar Einstellungen/Optionen gar nicht kennt.
Ich habe das z.B. im "modfs" erst im Nachhinein implementiert und bis ich da alle Applet-Aufrufe so abgeändert hatte, daß die auch definitiv die mit "modfs" "gelieferte" BusyBox benutzen und nicht die von AVM, dauerte es schon eine Weile. Das kann man also für "abgeschlossene Projekte" machen, wenn man dabei sorgfältig genug ist, aber so für die Benutzung in einer Shell würde bei zwei BusyBoxen vermutlich öfter die "originale" verwendet, als man auf den ersten Blick denkt (außer man mountet dann die eigene über die von AVM, was aber wieder andere Probleme mit sich bringt, weil man das nie wieder los wird, ohne einen Neustart zu machen).
Ein sehr schönes Beispiel für den Unterschied zwischen einer selbstgebauten BusyBox und der originalen von AVM ist häufig das
wget-Applet - das versteht seit einiger Zeit auch HTTPS, wenn man es entsprechend baut, was sehr angenehm ist, wenn es ums Nachladen von Paketen oder um den Abruf von Webseiten geht (immer mehr Server setzen eben auf TLS). Nur gibt es bei AVM eben das "hauseigene"
httpsdl und daher kann das
wget in der AVM-BusyBox praktisch nichts davon. Wer jetzt aber (selbst in einer Shell, die mit der eigenen BusyBox läuft) hingeht und einfach nur ein
wget aufruft, wird häufig stattdessen das AVM-Applet erwischen, solange er seine eigene BusyBox nicht mit
PREFER_APPLETS (
https://git.busybox.net/busybox/tree/Config.in#n287) erstellt hat - wobei das dann ohnehin wieder gegen ein Ersetzen der AVM-BusyBox spräche, denn die würde dann auch wieder auf irgendwelche Applets abfahren, während es ggf. noch ein ganz anderes Programm gäbe.
Solche "Verwirrungen" hatten wir bei Freetz-NG ja gerade erst wieder vor kurzem ... da wurde dann das
kmod (und die darin enthaltenen Applets, denn das ist auch ein Multicall-Binary, wie die BusyBox) nicht genutzt (oder doch, so genau weiß ich das nicht mehr) und das war letztlich die Ursache für die Probleme mit der fehlenden Entropie beim Start der 07.24/07.25 auf einer GRX-Box (
https://github.com/Freetz-NG/freetz-ng/issues/120) - was sich wohl auch auf den
untrustedd auswirkte (
https://github.com/Freetz-NG/freetz-ng/issues/28), denn das alles hat sich mit dem Verwenden der
kmod-Applets wohl auch erledigt. Das ist also irgendwo auch wieder ein gutes Beispiel für mein Credo, daß man sich überlegen sollte, was man da wie ändert oder sich das zumindest nach (einigermaßen tiefgreifenden) Änderungen durch den Hersteller alles noch einmal genauer ansehen muß.
