@er13:
Alle Deine Erklärungsversuche klammern aber die Frage aus, warum es Dir nicht möglich gewesen sein sollte, sich darüber
zuvor mit mir zu verständigen bzw. abzustimmen. Das gilt genauso für jeden anderen Autoren irgendeiner Software, die Du in Freetz integrieren willst und die dabei nach Deinen Vorstellungen (die durchaus auch mal echte Bedürfnisse als Hintergrund haben können, auch wenn ich bestreiten würde, daß das tatsächlich für
jeden Änderungswunsch Deinerseits gilt) angepaßt wird.
Ich habe nicht unabsichtlich alle vorhergehenden Kontakte in dieser Angelegenheit so akribisch aufgelistet und erklärt - wenn Du einfach an die Stelle der Vermutungen, die nun Deinerseits auf "Annahmen" beruhen:
Meine Interpretation dieser Aussage war die folgende
wenigstens den Versuch der Kommunikation und die Nachfrage: "Und ... hast Du schon genauer ermittelt, was da bei der Berechnung des MD5-Hash an der 10 KB-Grenze schief geht?" gesetzt hättest, wären Dir 40 Minuten Arbeit erspart worden (von der Feststellung, wie genau AVM sich verrechnet, über den Patch bis hin zum Schreiben hier) und es hätte gar keine Chance für ein erneutes(!) "Mißverständnis" gegeben.
Selbst wenn ich Dein "ich wollte doch nur helfen" als Motivation anerkennen wollte, ist dieses "ungefragte bzw. ungebetene 'Helfen'" nach unserer gemeinsamen "Vorgeschichte" ja ohnehin nicht die schlaueste Vorgehensweise und nimmt dann zumindest billigend in Kauf, daß beim Gegenüber erneut derselbe, fatale Eindruck entsteht.
Schon Dein erstes Zitat in #38 ist ja auch einigermaßen merkwürdig. Es greift eine "Einleitung" meinerseits auf, ignoriert die dazwischen stehenden, weiteren Erklärungen in den folgenden drei Absätzen (inkl. der Frage mit den 10 KB-Grenzen, denn am Beginn hatte ich ja tatsächlich noch festgestellt, daß alle Dateien an (hex) 0x800 bzw. 0x000 enden - was auch für 2KB und 4KB sprechen könnte, bis man das tatsächliche Vielfache ermittelt hat) und zitiert dann erst wieder das "Egal ... ", was sich ja eindeutig auf die beschriebenen Probleme mit dem "Blick in die Vergangenheit" im Absatz davor bezieht - sofern man diesen eben nicht "ausblendet".
Die Erklärung, daß Du den dazwischen stehenden Teil beim Lesen übersprungen haben könntest, paßt auch nicht so recht, denn Deine (absolut korrekte) Feststellung, daß ich die
Wahrscheinlichkeit für das Problem fälschlicherweise als 1:19 angegeben habe (anstatt die negativen den positiven Fällen gegenüberzustellen), kann ja auch nur auf dem Lesen genau dieser Absätze basieren.
------------------------------------------------------------------------------------
Auch ist es nun mal der
übliche Weg, daß man
Vorschläge für Änderungen nicht dadurch "einreicht", daß man sie als Patch in Freetz - quasi als "stille Post" - an den Autoren übermittelt (und damit allen anderen Freetz-Usern exakt zu diesem Zeitpunkt bereits "aufs Auge drückt") ... der Freetz-Trunk sollte eben gerade
kein privates Repository sein.
Für Änderungsvorschläge bei fremder Software gibt es u.a. Pull-Requests in "git" (bzw. in GitHub), Du hast einen eigenen Fork vom YourFritz-Repository (
https://github.com/er13/YourFritz) und solltest wissen, wie man Branches erstellt oder fremde Commits auch in einen älteren Stand mischt, notfalls sogar, wie man einen weiteren Fork am aktuellen Commit erstellt ... und der große Vorteil von GitHub wäre es dann noch, daß man dort auch seine Motivation und/oder Begründung für einen Patch mitteilen kann/sollte/(bis hin zum "muß").
Schon die Feststellung, daß Du Dir zuvor die weiteren Konsequenzen aus der Anpassung des Signaturalgorithmus an den AVM-Fehler gar nicht überlegt hast (so verstehe ich jetzt mal Deine eigenen Worte - wenn das falsch sein sollte, korrigiere mich bitte,
wie weit genau Du Dir das überlegt hattest), sollte eigentlich für Dich selbst zu "STOP at this point" werden ... wieso checkst Du in den Freetz-Trunk solche Sachen dann trotzdem ein?
Ich brauche auch gar nicht darüber zu
spekulieren, was Dich dazu bewegen mag ... ich brauche nur Deine Reaktionen (und wäre es hier tatsächlich der erste Fall, könnte man mir vielleicht noch etwas mehr "Ruhe" im Umgang mit diesem Thema abverlangen, aber das ist er eben nicht) zu betrachten und die "Fakten", was wirklich geschehen ist.
Auch unverständlich für mich: Auf der einen Seite möchtest Du nicht, daß man zuviel (Negatives) in Deine Reaktionen "hineininterpretiert" und auf der anderen Seite erwartest Du, daß man Deine (positiven) Beweggründe "erraten" soll, während Du selbst auf jeden Hinweis auf dieselben verzichtest? Da rede ich auch noch von Deiner Motivation und noch gar nicht von den - eben auch komplett fehlenden - Begründungen und/oder Überlegungen, warum Du das überhaupt ändern möchtest, was Du da gerade - in Deinen Augen -
vorgeschlagen hast.
Schon eine etwas überlegtere Wortwahl (Warum muß es einen "Fix" für etwas geben, was gar nicht mehr länger "kaputt" ist - ja, es eigentlich nie war, wenn man einen AVM-Fehler darin sehen will, was ja auch Du nicht bestreitest?) hätte einiges an Eskalation vermeiden können und auch
fürs erst aktualisieren und erst danach die Analyse starten, hatte ich zu der späten Stunde schlicht und ergreifend keine Lust
ist irgendwie "putzig" ... Du hast keine Lust darauf, Dir die von mir vorgenommenen Änderungen anzusehen und startest stattdessen lieber (ungefragt und ungebeten) eine Analyse für ein Problem (und später für ein zweites, für welches noch einmal dasselbe gilt), was in meiner aktuellen
Form Version gar nicht mehr vorkommt?
Und das "korrigierst" Du dann auch gleich noch auf der Basis des alten und überholten Standes? Aber für diese Korrektur des alten Standes verwendest Du dann nicht etwa
s irgendeine andere Auswertung der Modulo-Division (wie z.B. "x % 20 == 18"), sondern genau dieselbe Formulierung, die ich in meiner Änderung (nach dem Stand auf dem Freetz-Trunk aber erst) benutzt habe?
Und das dann in der Summe zu allem Überfluß auch noch gleich - alleine im Zusammenhang mit diesem "Vorfall" hier - doppelt ... denn das gilt ja einerseits für Deine Änderung hinsichtlich des Signatur-Algorithmus (bzw. genauer der dort einzubeziehenden Daten, damit keine neuerlichen Mißverständnisse aufkommen) und andererseits auch noch für Deine - nun deutlich später als einen Tag nach meiner Änderung - vorgenommene Änderung bei "short reads" aus einer Pipe.
Hättest Du da einfach auf die neue Version zurückgegriffen (wie es normal gewesen wäre, wenn Du die Absicht hast, künftig wieder auf der Basis "des Originals" zu arbeiten - letztlich ist das ja auch der Punkt, der den Anlaß für meine "Schlußfolgerung" liefert, daß Du weiterhin Deine eigenen Änderungen in Freetz benutzten wirst), wäre Dir auch dort aufgefallen, daß die von Dir geänderte Zeile gar nicht mehr existiert und da liegt dann irgendwie der Schluß nahe, daß es den Patch dann auch nicht braucht.
------------------------------------------------------------------------------------
Was bleibt im Ergebnis (und ist das Einzige, was wirklich zählt)? Ein Freetz-Trunk, der einen alten Stand aus dem YourFritz-Repository benutzt und dazu dann Deine eigenen Patches. Das kannst Du gerne machen - zur (bisherigen) Lizenz habe ich schon genug geschrieben.
Ob das im Sinne der Freetz-Benutzer sein wird bzw. was Du machst, wenn ich Änderungen in das Repository einchecke, die andere Lösungen betreffen (z.B. "eva_tools") und wie Du diese dann "mischen" willst bzw. ob Du dann künftig der Ansprechpartner bei Problemen mit diesem alten Stand sein möchtest, wirst Du Dir sicherlich gründlich überlegt haben.
Es ist halt nur komisch, daß Du immer genau dann "in die Bresche springen" und "helfen" mußt oder willst, wenn irgendjemand anderes sich ein Thema vorgeknöpft hat und da zu ersten Ergebnissen gekommen ist. Das habe ich jetzt mehrfach erlebt (die "großen" Fälle habe ich weiter vorne im Thread schon angeführt) und es hatte durchaus seinen Grund, warum ich beim "decoder"-Projekt zunächst eine "Sperre" für die Verwendung in Freetz eingezogen hatte in der Lizenz:
https://github.com/PeterPawn/decoder/blob/773591fdf9655bdbc672f575a577528c2bf3cd16/README.md
Wenn das nicht "Warnung" (und deutlicher Standpunkt meinerseits) genug war, weiß ich auch nicht mehr ... aber ich wollte tatsächlich mal die Chance haben, etwas selbst im Zusammenhang mit FRITZ!Boxen bis zum Ende zu entwickeln (auch wenn der aktuelle Stand noch nicht "das Ende" sein soll), bevor da wieder jemand "dazwischengrätscht" (um mal bei Fußballspiel zu bleiben).
Ich überlege seit einiger Zeit, ob ich nicht einen passenden Daemon oder eine Library schreiben sollte, mit der man auch beim aktuellen FRITZ!OS dynamische Portfreigaben für Dienste auf der Box selbst einrichten kann - wie das gehen könnte, habe ich in irgendeinem anderen Thread (ggf. sogar in zwei)
man mal skizziert.
Wenn ich das tatsächlich in Angriff nehmen sollte, stehe ich wieder einmal vor dem Dilemma, ob ich das nun in einem "unfertigen" Zustand veröffentliche und zugänglich mache (was dann auch die Möglichkeit eröffnet, daß man sich über Alternativen und/oder Probleme austauscht(!)) oder ob ich das so lange unter Verschluß halte, bis es endgültig eine nutzbare Form angenommen hat. Ich habe tatsächlich die "Befürchtung", daß bei der erstbesten Gelegenheit, die sich z.B. mit einer "Frage" als Anregung zur Diskussion ergeben könnte, wieder ein anderer auf den fahrenden Zug aufspringt und die Ergebnisse (die ja auch auf Vorarbeiten beruhen, die teils sogar deutlich mehr Zeit in Anspruch nehmen, als solche Umsetzungen) für sich reklamiert - mit "auf Anregung von", wenn's gut läuft.
------------------------------------------------------------------------------------
Ich kann es auch nicht oft genug ansprechen ... erst die vollkommen fehlenden Style-Guides für Freetz ermöglichen es Dir immer wieder, irgendwelche eigenen "Verbesserungen" an fremdem Code vorzunehmen und nach Gutdünken zu schalten und zu walten, weil praktisch niemand irgendeine "Richtschnur" dafür hat, wie das in Freetz aussehen sollte - und zwar auch nicht nur nach Deiner Ansicht, sondern nach der Ansicht aller beteiligten Personen.
Schon die "Stille" von Deiner Seite, wenn es um den (tatsächlichen) Umzug von Freetz auf GitHub geht (was eben die verteilte Arbeit deutlich einfacher macht als das derzeit verwendete SVN), spricht für mich Bände.
Dort ist es nämlich auch deutlich leichter für weitere Interessierte, eigene Ideen umzusetzen und "anzubieten" und wenn diese dann tapfer ignoriert werden (wie es - trotz der zaghaften Versuche mit ein paar Änderungen - auch für die Puma6-Integration von
@f666 nach meiner Ansicht immer noch gilt), dann kann ein interessierter Freetz-Benutzer auch mit dem entsprechenden Fork sein Glück versuchen.
Wenn auch
@f666 seine Patches ständig nachbessern muß, liegt das einerseits daran, daß Du die notwendigen Änderungen im Trunk auch immer so einbaust, wie es gerade in Deiner eigenen Vorstellung paßt (das mag manchmal sogar zu begründen sein, auch wenn Du darauf auch dort eigentlich fast immer so weit verzichtest, daß nur jemand, der "im Thema steht", das einigermaßen verfolgen kann) und daß er gar keine realistische Chance erhielt, das selbst so zu machen, wie es (für Freetz) "richtig" wäre.
Das kannst nämlich offensichtlich nur Du und dann mußt Du Dich auch nicht wirklich wundern, wenn es gar nicht mehr vorwärts geht und sich Freetz nur noch im Ringelpiez aus aktualisierten Software-Paketen anderer Projekte und neuen AVM-Versionen im Kreise dreht.
------------------------------------------------------------------------------------
Alles das, was man ansonsten verbessern könnte (und sollte - die Zeit ist ja nicht stehengeblieben im Jahr 2013), lohnt sich für einen "Mitarbeiter" gar nicht wirklich, weil es keine wirklich funktionierenden Abstimmungen (genauer Absprachen, weil das nicht unbedingt "votes" sein müssen) für die künftigen Entwicklungsrichtungen gibt.
Wer sich an diesen Stellen engagieren will, kann das entweder für sich selbst machen (da reicht i.d.R. dann auch die "quick & dirty"-Lösung für die eigenen Bedürfnisse) oder er muß das selbst so weit "propagieren" und bekanntmachen, daß die Freetz-User davon Kenntnis erhalten und ggf. "mit den Füßen abstimmen" - das wäre dann der erwähnte "harte Fork" des Projekts, den eigentlich keiner ernsthaft wollen kann.
Ob und wann es irgendwelche "unabhängigen" Entwicklungsarbeiten jemals in den Freetz-Trunk schaffen werden, steht jedenfalls immer wieder aufs Neue vollkommen in den Sternen, wenn man mit solchen Sachen beginnen will - und wer arbeitet schon freiwillig für den Papierkorb bzw. wer macht sich schon gerne zum "Deppen", entwickelt eine passende Lösung und muß dann zusehen, wie diese von jemand anderem "verschönert" (um nicht zu sagen "okkupiert") wird?
Beispiel: Es würde vermutlich keine vier Stunden der Beschäftigung mit dem Thema brauchen, um Freetz so weit umzugestalten, daß es bei neuen Laborversionen von AVM (auf Wunsch) automatisch immer auf die aktuellste Version zurückgreift ... mit "juis_check" und "check_signed_image" wäre es ein Leichtes, die ständig notwendigen "version bumps" beim Labor für bereits unterstützte Modelle zu eliminieren (das macht "modfs" seit fast zwei Jahren so:
https://github.com/PeterPawn/modfs/commit/6808d89d332a4351de5d7d7ae4ad8bf9c3bedecd) und die daraus erwachsenden "Gefahren" einer Inkompatibilität durch Änderungen bei AVM sind dann immer noch genauso hoch wie beim derzeitigen Vorgehen (denn wirklich getestet wird so ein Patch ja dann auch nicht).
Dann erst kann man aber hingehen und den Leuten die (bequeme) Auswahl einer bereits vorhandenen, älteren Labor-Version als Basis für ein Freetz-Image überlassen - der bisherige Weg, bei dem der Benutzer erst noch den Hash für das Image ermitteln und es dann mit Namen und Hash-Wert in die Konfiguration eintragen muß, ist reichlich "old school" und für einige tatsächlich schon zu kompliziert (nicht umsonst ist diese Einstellung auch auf "Experten" beschränkt:
https://github.com/Freetz/freetz/blob/master/config/mod/download.in#L79).
Und wenn Dich jetzt die Frage plagen sollte, warum ich das dann noch nicht in Angriff genommen habe, wenn es doch so einfach wäre ... ich denke mal, die Antwort darauf liegt auf der Hand. Ich weiß schlicht nicht, wie ich das so umsetzen sollte, daß es nicht hinterher wieder von Dir "korrigiert" wird und alles andere, was ich bisher versucht habe als Diskussion "anzuschieben" (bis hin zu der Frage, wie sich "Freetz" eigentlich selbst sieht, denn meine "Theorie der vier Teile" ist ja nicht wirklich neu), wurde mit dem Vertrösten auf später dann abgewürgt (sofern es überhaupt eine Reaktion gab) ... überflüssig noch zu erwähnen, daß es dieses "später" bisher immer noch nicht gibt.
Das, was da bei Freetz im Moment geschieht, ist jedenfalls mehr das "Verwalten" einer alten Software (der Toolchain-Teil ist tatsächlich das, was aktuellen Ansprüchen standhalten kann und ein paar Pakete) als irgendeine "Vision" dessen, was man mit so einem Router noch machen könnte (und zwar auf sichere, zeitgemäße Art und Weise) und was ggf. sogar dem Hersteller "den Spiegel vorhält" und ihm zeigt, was die Kunden sonst noch haben wollen und was machbar wäre.
Das war mal anders - sicherlich ein Grund für die Popularität von Freetz in der Vergangenheit. Heute ist Freetz - nochmal: abseits der Toolchain - nur noch ein trauriger Abklatsch einstiger Größe ... das mag auch an zu wenigen Mitstreitern liegen (man
kann nicht alles alleine machen), aber man muß sich auch mal die Frage stellen, wo diese geblieben sein könnten und warum niemand mehr "nachkommt".
------------------------------------------------------------------------------------
Ich habe zwar in #36 noch ein EDIT vor der letzten Teilung stehen ... aber der danach folgende Text "unter dem Strich" war von Beginn an derselbe und sollte Dir - selbst wenn Du die E-Mail-Benachrichtigung nutzen solltest und diese keine nachträglichen Änderungen enthält - auch inklusive dieser Frage zugegangen sein ... diese steht auch absichtlich unter einer Trennlinie, weil ich die sachliche Frage, wie es weitergeht, von der "Meinung" darüber auch optisch trennen wollte ... als praktisch veranlagter Mensch, der auch sieht, daß es parallel zu einer Diskussion ja irgendwie weitergehen muß - was diese Diskussion aber keineswegs ersetzt oder obsolet werden läßt.
Die dort gestellte Frage, wie Du nun weiter verfahren möchtest, hast Du jedenfalls geflissentlich ignoriert (welche "Kommunikationskanäle" Dir zur Verfügung gestanden hätten, muß ich nicht erneut erläutern) und Deine einzige Reaktion darauf waren bis zum 09.09.2018 22:45 Uhr dann vier Patches in Freetz, wobei sich einer erneut auf den alten Stand von "signimage" bezog.
Hier im Thread war jedenfalls Deinerseits von Freitag, 07.09.2018 09:30 Uhr bis Montag mittag (12:13 Uhr) wieder das große Schweigen eingekehrt und für eine simple Aussage, wie Du weiter zu verfahren gedenkst, hättest Du garantiert nicht mehr Zeit benötigt als für die zusätzliche Änderung mit dem "head" und die drei anderen Patches in Freetz.
Aber wie Du Dir Deine Zeit einteilst und wo Du sie einsetzt, ist tatsächlich Deine Sache ... der Witz ist es halt nur, wenn man auf der einen Seite mit "knapper Zeit" argumentiert und sich auf der anderen Seite Arbeit aufhalst, die man gar nicht machen müßte - ich sehe hier schon ein paar Widersprüche.
Jedenfalls erscheint mir da die "Schlußfolgerung", daß Du Dich hier ebenso verhalten würdest, wie es in der Vergangenheit der Fall war, nicht so sehr aus der Luft gegriffen und nicht umsonst beginnt #37 mit dem Satz:
Ich ziehe hier mal für mich ein Fazit:
Du kannst/wirst ja Deine Position dann ebenfalls darstellen und da wir beide uns ohnehin nicht mehr einigen werden, können sich dann wenigstens andere anhand der hier vorgebrachten Argumente ein eigenes Bild machen ... solange beide Seiten bei der Wahrheit bleiben und Du wirst hoffentlich nicht bestreiten, daß ich hier nur Dinge angeführt habe (wenn auch ggf. aus meinem eigenen, nach Deiner Ansicht falschen, Blickwinkel), die tatsächlich stattgefunden haben.
Hätte ich jetzt auch nicht erwartet ... immerhin ist es kein "mit vorzüglichem Abscheu" geworden.
Nachtrag: Entgegen sonstiger Gewohnheiten suche ich oben jetzt nicht nach Tippfehlern - mir fehlt gerade die Zeit dafür und die Periode, in der mein Kabel-Anschluß wieder in die Knie geht, naht - damit muß ich den Text jetzt irgendwann auch mal loswerden und werde ihn ggf. später noch korrigieren (inhaltlich aber nicht wesentlich, soviel kann ich schon mal sagen).
------------------------------------------------------------------------------------
EDIT:
Ich muß auch noch mal kurz auf die "Frage" eingehen, warum ich auf Deine Frage in #31 nicht geantwortet hätte ... ich kann in diesem Beitrag gar keine gezielte Frage erkennen, die sich an mich gerichtet hätte.
Ich wüßte jetzt auch gar keine andere "Fehlerklasse" als einen "off-by-one bug", die plausibel ein Fehlerbild bewirken sollte, das dem von mir geschilderten Verhalten entspricht und damit ist das wohl eher eine rhetorische, denn eine ernsthafte (und obendrein irgendwie erkennbar an mich gerichtete) Frage.
Auch die Feststellung, daß ich in #30 schreibe:
ist die Vermutung naheliegend
kann kaum als Anlass für den eigenen "Verdacht" herhalten, ich hätte das gar nicht weiter untersucht ... denn wie man schon in #1 lesen kann:
Also liegt die Vermutung nahe, daß tr069fwupdate (welches wir ja aufgerufen haben) seinerseits firmwarecfg aufruft.
gehört dieser "Erzählstil" nun mal zu dem Mitteln, mit denen ich solche Lösungen beschreibe (als Prozess und nicht nur als Ergebnis) und da ich davon ausgehen darf, daß jemand, der mit mir über die "signimage"-Lösung diskutieren will, diesen Beitrag auch gelesen haben sollte, kann man auch die Kenntnis dieses Umstandes voraussetzen.
Und auch eine solche "offene Frage" erklärt dann ja immer noch nicht, warum Du an die Stelle der reinen "Feststellung", wo das Problem nun liegt, den eigenen Patch direkt im Freetz-Trunk setzt - und das auch noch, ohne über dessen Konsequenzen bis zum Ende nachgedacht zu haben, weil Du "keine Lust" hattest (oder keine Zeit oder was auch immer - Fakt ist ja, daß Du es nach eigenen Worten nicht getan hast).
Alles das erfolgte also nur aufgrund meiner fehlenden "Antwort" auf Deine Frage, ob das ein "off-by-one"-Fehler sein könnte ... es gibt schon merkwürdige Zufälle im echten Leben.
