Vorschlag: ds-mod erstellen ohne ewiges kompilieren.

[Boyz]

Hallo,
ich hab mal eine Idee wegen ds-mod erstellen.
Zurzeit wird beim ds-mod erstellen erst Toolchain gebaut und dann die ausgewählte
Pakete kompiliert.
Ich finde es wäre besser, wenn man die ganzen Programmen und Libraries schon vorkompiliert und ins Netz stellt so dass man beim ds-mod erstellen nur die fertigen Programmen runterladet und ins Image intergriert.
Ein Toolchain braucht ja auch nicht jeder, das soll man beim menuconfig auswählen können ob man eins braucht oder nicht, wenn man eins braucht dann soll man auswählen und erst dann wird ein Toolchain gebaut.
Wenn das alles klappt dann würde ds-mod erstellen in 5-10 minuten fertig!
So müssen nur die 3-4 Leute die an ds-mod arbeiten alles kompilieren und die restlichen 1000 Leute die ds-mod erstellen schneller ds-mod erstellen können.
Ich würde das aufjeden fall so machen, wenn ich ds-mod erstellen würde.
So jetzt würde ich gerne wissen ob das sinnvoll ist und ob das möglich wäre.

Gruß
Boyz

 

[bodega]

Damals hatte die TC noch 3-4h gebraucht zum kompilieren. Heute geht das Ganze recht zügig (bei mir unter 1h). Das kann ich noch verschmerzen. Das Problem beim Vorkompilieren ist: es ist ein riesiger Pflegeaufwand. Bei jedem Release müsste man jedes Paket vorkompilieren und extra bereitstellen.
Hinzu kommt dann noch die größere Datenmenge an Binaries, die über die Leitung transportiert werden müssten. Die Idee ist nicht neu (cygwin), würde aber die Mod-Entwicklung bremsen.

 

[olistudent]

Ob ich jetzt das Package mit oder ohne Binary hochlade ist (für mich) kein zusätzlicher Aufwand. Da ich jedoch nur DSL 1000 habe würde sich der Upload doch um einiges verlängern. Außerdem würde natürlich das Transfervolumen auf den Mirrors um ein vielfaches steigen.

MfG Oliver

 

[bodega]

Wenn es für dich kein Aufwand ist... nur zu
Dann könnte man ja auch wieder eine cygwin Version auferstehen lassen.

 

[olistudent]

Es bringt ja aber auch nichts, wenn ich jetzt alle Pakete mit Binaries hochlade, weil die Libs dann noch fehlen. Dann gibt es noch einzelne Pakete für die es gar kein Download gibt (z.B. haserl).

MfG Oliver

 

[knox]

Ich denke, Binärpakete sind überflüssig.

Wenn mich jemand fragen würde, dann wäre ich mit einer reinen Scriptsammlung vollkommen zufrieden.

 

[Tarnkappe]

Ich finde es kann ruhig alles so bleiben wie es ist.

Mit Knoppix in einer virtuellen Maschine dauert das kompilieren bei mir rund 30 Minuten und finde das völlig ok. Lieber die Zeit in die Weiterentwicklung stecken!

 

[olistudent]

Ich hab mal nachgeschaut:

Anzahl Packages: 56
Größe mit Binaries: 6,655,269 Bytes
Größe ohne Binaries: 945,678 Bytes
Größe der zusätzlichen Libraries: 4,872,618 Bytes (ungepackt)

MfG Oliver

 

[Boyz]

Also an Größe wird das wohl nicht scheitern.
Beim erstellen soll ja auch nur das runtergeladen werden, was man halt im menuconfig auswählt.

Gruß
Boyz

 

[bofh]

das TC als binary aus meinersicht, nicht sinvoll, braucht einsparbare bandbreite

 

[kriegaex]

Die Download-TC ist aus meiner Sicht sinnvoll, weil sie ja gerade das vermeidet, was Boyz nicht gefällt: TC bauen. Der Schritt entfällt also, wenn man die fertige TC einfach herunterlädt, somit kann von studenlangen Builds nicht mehr die Rede sein. Ein paar Pakete sind relativ schnell gebaut. Wer dann 30 Pakete auf der Box haben zu müssen glaubt, wartet halt ein paar Minuten länger.

Vorkompilierte Binaries wie zu Zeiten von ds-0.2.9 und Kernel 2.4 anzubieten, wäre möglich, würde aber mehr Arbeit machen als bisher erwähnt, denn wir benötigen Binaries Kernel-Module für die Kernel-Layouts ohio und ar7, also jedes Paket Modul doppelt. Dann gibt es Pakete mit Sub-Optionen, welche pro Option die Menge möglicher Kombinationen pro Paket jeweils um den Faktor zwei ansteigen läßt. Ein Extremfall wäre Nano mit zehn Optionen, also mal Faktor 2^10 (1024). Es ist klar, daß wir uns also auf eine Standard-Konfiguration pro Paket konzentrieren müßten, maximal zwei. Das muß man bauen, pflegen, hochladen, theoretisch auch noch einzeln testen. Dazu kommt, daß wir demnächst auch noch MD5-Prüfsummen für Pakete einbauen wollen, die dann auch jeweils mehrfach in den Makefiles aktuell gehalten werden müssen.

Boyz, bedeutet Dein Vorschlag, Du meldest Dich freiwillig, das alles zu übernehmen?

P.S.: Ich komme übrigens auf eine Größe von knapp 8 MB mit Binaries für alle Pakete (tar.bz2), aber die Größe wäre auch noch kein Problem. Das Problem ist wirklich der Aufwand.

 

[Boyz]

ja das ist schon viel Arbeit!
Ich hab mir halt gedacht man zieht das durch und dann die vielen Leute die einfach nur ds-mod erstellen haben das dann in paar minuten fertig haben.
Und es gäbe dann auch keine Probleme mehr beim ds-mod erstellen "make fehler............." hier im Forum wurde schon dumm und dämmlich über kleinigkeiten diskutiert, das halt auch wurde viel Zeit nimmt.

Ich hab noch nie an ds-mod erstellen gearbeitet sonst würde ich das sofort machen mir macht das nichts aus!

Gruß
Boyz

 

[kriegaex]

Wenn "man" (also Oliver und ich, wie ich das sehe) das also "durchzieht", könnte es dann aber sein, daß sich in der DS-Mod-Entwicklung nichts mehr tut. Ich komme sowieso kaum noch dazu. Das nennt man dann wohl "in Schönheit sterben". Sollen wir abstimmen, ob das eine gute Idee ist?

Trotzdem denken wir mal darüber nach, und wenn uns eine Idee kommt, wie man das weitgehend automatisieren kann oder mir jemand einen gut ausgestatteten Zweit-PC sponsort, auf dem ich regelmäßig und schnell Builds durchlaufen lassen kann, während ich auf meiner momentan einzigen Maschine (Notebook) arbeite, wäre das im Bereich des Möglichen. Irgendein Sponsor dort draußen?

 

[silberwolf]

Ich sehe das Problem mit dem momentanen Verfahren auch nicht wirklich, sondern eher noch Vorteile!

Schließlich darf man nicht vergessen, dass man Eingriffe in sehr systemnahe Routinen vornimmt, wenn man den ds-mod erstellt. In meinen Augen sollte jeder User sich vorher genauestens alles durchlesen und erst danach handeln.
Wenn dies wirklich passieren würde, dann gäbe es auch kaum Probleme. Und wer mit den - inzwischen gar nicht so schlechten Anleitungen - nicht klar kommt, der sollte sich ernsthaft gedanken machen, ob ein solcher Mod wirklich das Richtige für ihn/sie ist. Und ansonsten gibt es ja umfassende Hilfe hier im Forum.

Ferner würden auch die Möglichkeiten eingeschränkt selbst einige Dinge mit einfachen Quellcodeänderungen auszuprobieren, wenn die Pakete vorkompiliert wären und auch schnelle Bugfixes/Workarounds durch Abändern von Scripten würden auch nahezu unmöglich.

Und die Zeit? - Wer eine solche umfangreiche Firmware-Änderung durchführen will (ds-mod), der sollte sich auch die Zeit nehmen, die das kompilieren in anspruch nimmt. So lange ist es nun auch wieder nicht (mehr).

 

[DPR]

Ich gebe Silberwolf Recht und habe glaub ich schon mal in einem anderen Beitrag was ähnliches geschrieben. Wer nicht weiß was er tut, sollte tunlichst die Finger vom dsmod lassen !

Leider muss ich hier etwas "Offtopic" werden ...

Ich verfolge die Beiträge hier im Forum immer wieder und muss feststellen, dass viele Leute dabei sind, die keine Ahnung von dem haben, was sie da eigentlich tun und welche Konsequenzen es haben kann. Und dazu kommt noch, dass immer mehr Leute dabei sind, die anscheinend auch kein bisschen bereit sind sich in die Materie einzuarbeiten und anfangen rumzustänkern (nicht unbedingt jetzt auf diesen Beitrag bezogen). Statt sich den ersten Beitrag und die FAQ durchzulesen wird direkt gepostet, gemeckert oder um Hilfe geschriehen. Wer seinen Fernseher aufschraubt und an ihm herumlötet, ist auch selbst für das verantwortlich, was dabei herauskommt.

Mit der vorkompilierten Toolchain hat man die ganze Zeit zum Erstellen meiner Meinung nach schon ausreichend minimiert.

Mein Vorschlag wäre eher, den dsmod auf eine separate Homepage zu legen und ihn nicht mehr über das Board zu verbreiten. So werden momentan sonst einfach zu viele Leute dazu verleitet, einfach mal wild rumzuposten - weil man ja quasi zwangsweise für den Download über das Board "stolpert". Außerdem könnte man so etwas mehr "Struktur" in die ganze Sache bringen (Trennung Download und "Support") und jeden User über eine Zwangs-Seite leiten über den er nochmal aufgeklärt wird, was er da tut.

Zuletzt noch eine Anmerkung, die sich so manche vor Augen halten sollten: die Entwickler und Supporter des dsmod bekommen für ihre Arbeit keinen Müden Cent und dafür hat auch keiner beim Kauf der Box bezahlt. Jeder kann froh sein, dass das was einige wenige mit viel Mühe erzielt haben überhaupt der "Öffentlichkeit" zur Verfügung gestellt wird. Wer Probleme hat soll sich erstmal selber darum kümmern, kommt er gar nicht weiter, kann man immer noch posten. Meine Meinung - Punkt.

 

[RalfFriedl]

Da das Thema ja lautet "ds-mod erstellen ohne ewiges kompilieren" habe ich das komplette Verzeichnis source gelöscht und geschaut, wie lange make precompiled braucht.
Da ich übersehen hatte, daß ich auch "Build toolchain" ausgewählt hatte, hat es dann etwas über 40 Minuten gedauert.
Ich habe dann nochmal source gelöscht und mit "Download toolchain" make precompiled aufgerufen. Das hat dann knapp 10 Minuten gedauert, inkl. Auspacken der Download-Toolchain.
Das sind jetzt vielleicht nicht übermäßig viele Pakete, aber für viel mehr reicht der Flash-Speicher sowieso nicht.
Selbst wenn es auf einem langsameren Rechner doppelt so lange braucht, ist das noch vertretbar.

Wie inzwischen schon andere geschrieben haben, sollte man schon eine Vorstellung davon haben, auf was man sich einläßt, bevor man den ds-mod installiert.

Wenn ich Alexander richtig verstanden habe, hat er nichts dagegen, wenn jemand die Pakete zum Download bereitstellen will, solange er es nicht selbst tun muß.
Da ich es nicht sinnvoll finde, werde ich es auch nicht tun...

Das andere Argument ist, daß dadurch möglicherweise die Support-Anfragen weniger werden. Das könnte so sein, aber genauso gut könnte es sein, daß sich die Probleme nur auf einen anderen Bereich verlagern. So in dem Stil "Ich habe jetzt auf Knopf X gedrückt und meine Box funktioniert nicht mehr."

Die Anfragen halten sich im Moment in Grenzen und betreffen überwiegen echte Probleme, wie USB, AVM vfat Modul usw.
Und bei den Leuten, die mit Fragen kommen, die schon in der Anleitung stehen, die haben mehr davon, wenn sie sich doch zum durchlesen entschließen können, denn wenn sie die Anleitung nicht gelesen haben, ist es nur eine Frage der Zeit, bis das nächste Problem auftaucht.
als wenn man sie mit einer schnellen Antwort zum nächsten Problem

 

[klez]

Meine Meinung ist (bei allem Respekt vor der Arbeit), dass der DS-Mod allgemein in die falsche Richtung entwickelt wird. Der proprietäre AVM Kram wird beibehalten, inklusive den damit verbundenen Problemen. Siehe z.B. IP-Tables/Netfilter (DAS Feature eines Linux Routers), was bis heute nicht richtig funktioniert... Auf der Box laufen 2 Webserver für 2 verschiedenen Web-GUIs -> unsauber. dnsmasq läuft auch nur halbwegs, weil es sich den DHCP Port VOR dem proprietären AVM Dienst schnappt -> unsauber. usw, usw. Dazu kommt, dass bei jeder neuen Firmware ein neuer DS-Mod gebaut werden muss, inkl. Bug-Fixing und dem damit verbundenen Aufwand bzgl. Tests, neukompilieren, Support im Forum leisten...

Ich finde ws wäre besser dafür zu sorgen, dass z.B. vorkompilierte OpenWRT Pakete auf der Fritzbox betrieben werden können. Sprich: AVM Kernel (wegen closed treiber), im OpenWRT Rahmen. Die Auswahl an OpenWRT Paketen ist groß, der Support wird von den OpenWRT Jungs geleistet... Idealer gehts kaum noch. Es gab hier mal jemanden, der OpenWRT "virtuell" auf der Box betrieben hat. Das war ein interessanter Ansatz, dem kaum beachtung geschenkt wurde -> schade.

Ich wollte mich vor geraumer Zeit schonmal an die Arbeit machen, aber mir fehlt Arbeitsbedingt einfach die Zeit dafür. Ehrlichgesagt nervt es mich mittlerweile das die Fitzbox lediglich in Deutschland so verbreitet ist. Europaweit wäre OpenWRT / DDWRT usw. längst darauf lauffähig.

 

[kriegaex]

Na, dann mach mal, wenn Du Zeit hast. ;-)

P.S.: Kleine Korrektur zu meinem dummen Geschwätz aus Beitrag #11: Wir brauchen keine doppelten Pakete für die zwei Kernel-Layouts, sondern doppelte Kernel-Module - mein Fehler. Danke an olistudent für die private Frage, wieso ich das schrieb. Das brachte mich darauf, daß es falsch war. Commander Data wäre das wieder nicht passiert... ;-) Ich korrigiere den Beitrag oben gleich mal.

 

[klez]

Na, dann mach mal, wenn Du Zeit hast.

Mit keiner anderen Antwort hatte ich gerechnet...
Hat sich aber schon seit geraumer Zeit erledigt, da ich ich die Fritzbox gegen einen vernünftigen Router ausgetauscht habe. Verwende sie nur noch als TK Anlage / Voip Gateway.

 

[kriegaex]

Dann ist ja gut. ;-) Und ich habe mit keinem anderen Vorschlag gerechnet als "macht Ihr doch mal, ich habe keine Zeit, sonst würde ich ja".