Anbieten von bereits kompilierten Programmen

[freddy4711]

Hi...

also ich halte die Idee auch für total überflüssig.

Ein Buildprozess von Grund auf dauert bei mir ca. 20 min. Danach habe ich ein Image, welches genau nach meinen Wünschen entspricht.

Ich sehe keine Vorteil durch deine beschriebene Methode.

Und ich war auch Windows-User. Aber mit ein bisschen Grips und Lesen kommt man da auch zurecht. Vor allem ist die Menüführung von make menuconfig eigentlich selbsterklärend...


Gruß Andreas

 

[RalfFriedl]

Lass doch die Disskusion mal losgelöst vom Gedanken wer das machen soll.

Die Erwähnung der Build-Service ging schon mal stark in die Richtung, wie es realisiert werden kann.
Du bist bisher nicht auf die technischen Einwände eingegangen (verschiedene uClibc Versionen, verschiedene Konfigurationen der Pakete).

1. solltest du damit aufhören User als blöd hinzustellen!

Ich würde eher sagen, Dein Vorschlag stellt die User als zu blöd hin, um die Programme selbst zu erstellen. Du sprichst es auch direkt an: "Ich denk da z.B. an Windows-DAU's ..."
Ansonsten sprechen einige Beiträge hier im Forum dafür, daß die Vermutung nicht ganz unberechtigt ist (das bezieht sich nicht auf Dich).

Außerdem bin ich mir nicht sicher, ob wir noch den Support für die Leute übernehmen wollen, die nicht einmal eine VM unter Windows laufen lasen können. Und Stinky ist sowieso nicht mehr die empfohlene Build-Umgebung. Soweit ich weiß, funktioniert es mit dem VM-Image von Silent-Tears ohne weitere Änderungen.

 

[cando]

Ich finde die Freetz Lösung schon ziemlich optimal.

Was den Build Prozess angeht, ich habe eine 384k DSL Leitung. Beim allerersten Mal dauert es lange, bis die VM heruntergeladen, Installiert und dann noch die ganzen Sourcen von überall her geholt werden.

Aber, für Erweiterungen, Rebuilds etc. geht es sehr schnell, weil nur die Änderungen nachgeladen werden. Außerdem kann man notfalls Dinge, die einem nicht gefallen, selber ändern und entsprechend compilieren (z.B. habe ich meinen cpmaccfg umgepatched, damit er "normal" im Split-Modus startet).

Die Integration mit dem Freetz UI und den Modulen funktioniert so auch recht gut. Das Problem, dass man eine Firmware flashen muss, bleibt, mann kann nicht einfach Pakete "nachbrennen" - auch bei einer binär-Pakete Lösung

Mit External, Symlinks und change-root etc. kann man sich ja behelfen, wenn man was Binäres vom Stick laufen lassen muss.

Man kann sogar freetz Pakete mit UI Erweiterungen auf dem Stick dynamisch einbinden. Es gibt 2 User Exits, die debug.cfd und die rc.custom mit deren Hilfe man den Kram auch noch Reset-Resistent bauen kann.

Dann gibt es auch noch das minifo, womit man den ROM "beschreibbar" machen kann. Dass man da nicht riesen Pakete lädt ist ja wohl klar, aber für ein paar fehlende Symlinks / Config Dateien auf dem USB / andere externe File Systeme sollte es reichen

Flexibler geht es doch wohl kaum noch.

 

[RalfFriedl]

Ich hatte vorhin noch vergessen zu erwähnen, daß man auch mit vorgefertigten Programmen nicht um eine Linux-Umgebung herum kommt, weil die Tools zum Auspacken und Einpacken der Firmware unter Linux laufen. Das einzige, was man sich spart, ist also etwas Zeit beim Anwender, in welcher der Rechner beaufsichtigt laufen kann. Auf der anderen Seite bedeutet es einiges an Arbeit für die Entwickler, das zu realisieren.

Bisher habe ich noch keine Bedarf dafür gesehen. Und wenn jemand das trotzdem für notwendig hält, sollte er auch die damit verbundene Arbeit übernehmen.

@cando
An Ergebnis ändert es gar nichts, speziell wird es nicht flexibler. Es ändert nur etwas an der Art, wie die Pakete vorbereitet werden.

 

[cando]

Ja, ist mir schon klar. Man kann dann auch mehr Unfug anstellen, da man ja vieles manuell irgendwie zusammenfrickeln muss, wenn das gewünschte in der vorkonfigurierten Server Lösung nicht so vorhanden ist. Dann braucht man doch wieder die Sourcen und eine Compilerumgebung - und schon fangen die Probleme an...

Auch wäre das eine Innovationsbremse. Bei freetz ist jeder User auch ein potentieller Entwickler, der was zu neuen Paketen beitragen kann. Alle haben eine funktionierend Build Umgebung inclusive svn zur Verfügung, und eine Qualitätsicherung beim Veröffentlichen durch die Sichtung der Pakete von den devs. Man kann seine "Erfindung" auch als Patch im Forum anbieten, um Feedback zu bekommen ohne eine Integration in den Trunk. Für den reinen Anwender gibt es den stable Bereich.

Bei einer reinen Binärlösung ist man nur noch Anwender und von den Devs abhängig.

Die Freetz Geschichte ist auch aus meiner Sicht die bessere Alternative.

Wenn astrapi so was mal bauen will, und der Allgemeinheit zur Verfügung stellt (mit Support), dann soll er doch...

Er wird sicher auch den einen oder anderen Fan für seine Lösung finden.

 

[astrapi]

Bei einer reinen Binärlösung ist man nur noch Anwender und von den Devs abhängig.

Dann schau dir erstmal den openSUSE Buildservice an, da ist man eben nicht von devs abhängig ....

 

[RalfFriedl]

Wie cando und andere bereits geschrieben haben:
Wenn Du das machen willst, dann tu es, denn sonst scheint keiner die Absicht zu haben, es zu machen.