.titleBar { margin-bottom: 5px!important; }

Freetz - Geschwindigkeit oder Speicherplatz

Dieses Thema im Forum "Freetz" wurde erstellt von olistudent, 14 Dez. 2008.

?

Welche Variante würdet ihr gerne in Freetz sehen?

Diese Umfrage wurde geschlossen: 4 Jan. 2009
  1. Variante 1 (make dirclean)

    14 Stimme(n)
    19.2%
  2. Variante 2 (unterschiedliche Verzeichnisse)

    59 Stimme(n)
    80.8%
  1. olistudent

    olistudent IPPF-Urgestein

    Registriert seit:
    19 Okt. 2004
    Beiträge:
    14,756
    Zustimmungen:
    1
    Punkte für Erfolge:
    0
    Beruf:
    Softwareentwickler
    Ort:
    Kaiserslautern
    Momentan haben wir in Freetz 2 Toolchains, die für die unterschiedlichen Versionen der uClibc genutzt werden. uClibc-0.9.29 wird von den Laborfirmwares sowie 3270, 7240 und 7270 genutzt. Die restlichen Firmwares verwenden uClibc-0.9.28. Inzwischen gibt es auch eine uClibc-0.9.30. Hier ist also nicht auszuschließen, dass AVM mal auch damit experimentieren wird.

    Für Freetz stellt sich hier die Frage:
    Was passiert wenn man zwischen Firmwares mit unterschiedlichen Versionen wechselt?

    Es gibt 2 Möglichkeiten, die wir intern schon diskutiert haben.
    1. Entweder werden, so wie es im Moment ist, alle Dateien unter source/ gelöscht (also quasi ein "make dirclean")
    2. Oder wir erzeugen 2 Unterverzeichnisse unter source (uClibc-0.9.28 und uClibc-0.9.29) und halten die Dateien darin "doppelt" vor. Darunter fielen z.B. die Target-Toolchain (falls selbst gebaut) und die Packages. Nicht dazu zählt der Kernel, da der nicht von der verwendeten uClibc abhängt.

    Während Variante 1 bei einem Wechsel also alles neu bauen muss spart Variante 2 hier viel Zeit. Benötigt dafür aber mehr Speicherplatz.

    MfG Oliver
     
  2. RalfFriedl

    RalfFriedl IPPF-Urgestein

    Registriert seit:
    22 Apr. 2007
    Beiträge:
    12,343
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ich bin für unterschiedliche Verzeichnisse.
    Bei unterschiedlichen Verzeichnissen kann man beim Wechsel der Version und Platzmangel immer noch von Hand ein "make dirclean" ausführen und hat damit vom Ergebnis das Gleiche wie bei der anderen Variante. Damit ist man also flexibler.
    Im anderen Fall ließen sich nicht einfach mehrere Versionen der Toolchain vorhalten.

    Als Bonus könnte man noch eine Option einbauen, die beim Erkennen des Wechsels automatisch "make dirclean" ausführt, wenn dafür Bedarf besteht.
     
  3. sf3978

    sf3978 IPPF-Promi

    Registriert seit:
    2 Dez. 2007
    Beiträge:
    7,629
    Zustimmungen:
    5
    Punkte für Erfolge:
    38
    Ich bin für Variante 1, weil ich mehr Zeit und weniger Speicherplatz habe ;). Ich baue immer alles neu. Mit einem schnellen Rechner ist das kein Problem.
     
  4. matze1985

    matze1985 Aktives Mitglied

    Registriert seit:
    17 Feb. 2007
    Beiträge:
    1,537
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    ich bin eher für die 2 Variante, da die die erste ja eigentlich beinhaltet. (Wenn man nen dirclean macht)
    Wenn man zu wenig Speicher hat, dann muss man halt regel mäßig mal nen dirclean ausführen.

    Der normal User wird eh nicht oft zwischen den uClibc's hin und herspringen. Da bleibt es dann bei einer Version.
    Dazu sollte man von Zeit zu Zeit auch mal neu auschecken und nciht nur svn up machen, dass bewahrt auch vor Fehlern.


    @sf3978
    Wenn man sowieso immer neu anfängt, dann ist es eigentlich egal.
     
  5. sf3978

    sf3978 IPPF-Promi

    Registriert seit:
    2 Dez. 2007
    Beiträge:
    7,629
    Zustimmungen:
    5
    Punkte für Erfolge:
    38
    OK, dann harren wir mal der Dinge, die da kommen mögen;).
     
  6. Silent-Tears

    Silent-Tears IPPF-Promi

    Registriert seit:
    3 Aug. 2007
    Beiträge:
    7,456
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    BI
    Ich plädiere eher zur Variante mit dem mehr an Speicherplatz, denn Zeit ist Geld, und Speicherplatz kostet kaum nohc was. Und da man als Dev häufiger hin und herspringt, ist Zeit sowieso noch einmal wichtiger.
     
  7. meilon

    meilon Neuer User

    Registriert seit:
    5 Jan. 2006
    Beiträge:
    149
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ein, Zwei Verzeichnisse mehr schaden nicht, und wenn man gerade wenig Platz hat, macht man halt nen make dirclean oder sichert sich die config und löscht alles und wenn man es wieder braucht, checkt man es aus neu und packt die config wieder hinein (so handle ich das auf meinem Notebook)
     
  8. McNetic

    McNetic Mitglied

    Registriert seit:
    7 Feb. 2007
    Beiträge:
    672
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    Aachen
    Ich plädiere dafür, Variante 2 zu implementieren, und zusätzlich eine Menuconfig-Option einzubauen, die, wenn gesetzt, dafür sorgt, daß vor dem Neubauen der neuen Toolchain usw. die alte komplett gelöscht wird. Wer also wenig Speicherplatz hat, macht das einfach an und hat dann wieder Variante 1.
     
  9. Darkyputz

    Darkyputz Aktives Mitglied

    Registriert seit:
    27 Juli 2005
    Beiträge:
    2,320
    Zustimmungen:
    0
    Punkte für Erfolge:
    36
    Ort:
    Newton, New Jersey
    version 2 auch hier...das leben iss so kurz ,-)
     
  10. wengi

    wengi Mitglied

    Registriert seit:
    3 Okt. 2006
    Beiträge:
    339
    Zustimmungen:
    1
    Punkte für Erfolge:
    18
    Ort:
    östlich Rhein-Main
    Hi,

    Variante 2.
    Ich compiliere auf einem älteren Notebook.
    Da lösche ich lieber per Hand und spare mir dafür viel Zeit.

    wengi
     
  11. ao

    ao Aktives Mitglied

    Registriert seit:
    15 Aug. 2005
    Beiträge:
    2,078
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Variante 2 - aus den guten Gründen, die RalfFriedl oben schon geschrieben hat
     
  12. JanGerrit

    JanGerrit Neuer User

    Registriert seit:
    24 Jan. 2006
    Beiträge:
    110
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ort:
    OWL
    Hallo Miteinander,

    ich bin auch der Meinung, dass die Version 2 vorzuziehen ist. Der Vorschlag von McNetic wäre ein guter Kompromiss.

    Viele Grüße, Jan Gerrit
     
  13. Miyamoto

    Miyamoto Neuer User

    Registriert seit:
    11 Nov. 2006
    Beiträge:
    121
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Das ist der sinnigste Vorschlag, finde ich - da können alle zufrieden sein. Mein source umfaßt schlappe 1,1 GB, das kann schon kritisch sein für Leute mit älteren Computern.

    Ist das aufwendig?
     
  14. Silent-Tears

    Silent-Tears IPPF-Promi

    Registriert seit:
    3 Aug. 2007
    Beiträge:
    7,456
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    BI
    Beides einzubauen ist natuürlich mehr Aufwand als nur eines daon. Logischerweise, oder? ;)
     
  15. rodeoflip2009

    rodeoflip2009 Neuer User

    Registriert seit:
    12 Dez. 2008
    Beiträge:
    2
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Punkt zwei ganz klar, die Vorteile wurden ja schon genannt.


    mfg
     
  16. frodo.

    frodo. Neuer User

    Registriert seit:
    9 Juli 2006
    Beiträge:
    168
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Ich bin für ein "make dirclean" in kombination mit verschiedenen Verzeichnissen pro Hardware.

    Ich verwende für meine Zwecke schon heute für jede Hardwareversion ein eigenes Verzeichnis und führe nach jedem svn update ein make dirclean aus.

    Ein Wechsel von verschiedener Hardwareversionen mit den selben bereits für eine andere Version verwendete Sourcen führte bei mir häufig zu nicht nachvollziehbaren Fehlern weshalb der Weg bisher nicht funktioniert.

    Meine Favorisierte Lösung wäre für Hardware spezifische Besonderheiten pro Hardware ein eigenes Unterverzeichnis welches bei einem make dirclean entfernt wird. Für alle übergreifende ungepatchten Sourcen ein Common Source Verzeichnis was dann bei einem make dirclean auch nicht gelöscht werden muss.

    Zusätzlich könnte man dann ein make dircleanall einbauen, welches alle Sourcen löscht.

    Wenn hierdurch ein fehlerfreies Compilieren mit einem Freetz-Source Verzeichnis für alle Hardwareversionen funktioniert fände ich das auch OK.

    Zur Zeit haben wir aber das Problem das man bereits kompilierte und anschliessend abgewählte Pakete nicht rückstandslos beseitigen kann, für eine Fritzbox mit weniger Flash-Speicher läst sich dadurch dann kein optimiertes Image mehr bauen...
     
  17. Silent-Tears

    Silent-Tears IPPF-Promi

    Registriert seit:
    3 Aug. 2007
    Beiträge:
    7,456
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    BI
    Nette Gedanken, aber ich denke, ein wenig Handarbeit ist schon noch drin. Für jede HW und jede uClibc ein eigenes Unterverzeichnis, dazu noch am besten extra für jedes Flashgrösse, falls variabel ist irgendwie oversized imho. Ich lass mich aber gern vom Gegenteil überzeugen.
    Die Sache mit den Rückstandslosen Dingen: Ein "make dirclean" tut seinen Zweck ;)
     
  18. ao

    ao Aktives Mitglied

    Registriert seit:
    15 Aug. 2005
    Beiträge:
    2,078
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Dafür gibt es m.E. "make config-clean-deps".

    Oder dies hier? Was ist da eigentlich der Unterschied?
     
  19. lxuser

    lxuser Mitglied

    Registriert seit:
    4 Nov. 2004
    Beiträge:
    287
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @ ao

    "make dirclean" bringt Frodo bei seinem Problem nichts. Überflüssige Libs... bleiben trotzdem in der Config und werden nach dem Löschen ja wieder mit "make" neu erstellt. Er braucht schon "make config-clean-deps" um die überflüssigen Abhängigkeiten aus der COnfig zu löschen als Lösung seines Problems.


    Zur eigentlichen Frage, da ich auf alle Boxen ein und das selbe Image aus dem stable Traunk mit USB-Root schmeisse und dass System für den USB-Root aus dem Trunk nehme und fast jedesmal mit "svn up" neu ausschecke und bei neuen Revisionen eh ein "make dirclean" durchführe, ist es für mich eigentlich völlig egal. Solange dauert ein "make" ja nicht mehr seitdem ich Linux wieder nativ laufen lasse und nicht mehr in einer VM. Aber auch da hatte ich dann eher ein Platz-Problem.

    Viele Grüss
    Mario