PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,156
- Punkte für Reaktionen
- 1,705
- Punkte
- 113
Oh wie herrlich wäre es doch, wenn man anstelle solcher "salbungsvoller Worte", die komischerweise niemals konkret werden, einfach mal ein, zwei, drei (oder wieviele auch immer man dafür braucht) Anstriche in einer Aufzählung finden würde, die solchen Bockmist irgendwie untermauern.
Aber mit Zitaten und Links, um irgendwelche Behauptungen auch mal so zu untermauern, daß sich "der Leser" ein eigenes Bild machen kann, muß man halt auch umgehen können bzw. solche Stellen müssen erst einmal existieren, damit man sie zitieren oder als Beleg verwenden kann. Ist halt nicht ganz so einfach mit einer schlüssigen "Argumentation" (was das ist, kann man ja mal nachlesen: https://de.wikipedia.org/wiki/Argument), wenn die eigenen Behauptungen praktisch nur aus der Luft gegriffen sind und irgendwelche "Nachweise" höchstens noch in Zirkelschlüssen oder in selbstreferenzierenden Texten anzutreffen sind.
Besonders putzig ist ja immer wieder die postulierte Unabhängigkeit von "boxmatrix.info" und "freetz-ng" ... @hippie2000 bewirbt immer wieder alle Forks vollkommen "überparteilich" nach seinen eigenen Worten (vielleicht glaubt er ja tatsächlich daran?):
, aber gleichzeitig taucht immer wieder die These auf, beim nunmehr doch fortbestehenden Projekt unter "freetz/freetz" auf GitHub handele es sich um irgendetwas, was man unbedingt meiden sollte.
Sehe hier nur ich einen Widerspruch oder steht da doch wieder der schwedische Propagandaminister Lasse Reden (mir fällt da ein alter Film ein, der im Original "Rebel without a cause" heißt, auch wenn der deutsche Titel wohl ebenfalls passen könnte) auf der Matte? Wie "unbekümmert" muß man denn in seiner Argumentation sein, damit einem solche Beiträge nicht peinlich sind? Auch wenn das in den letzten zwei Jahren sogar in der Politik um sich gegriffen hat, daß morgens das eine und mittags etwas anderes erzählt wird - man muß sich nicht an jedem amerikanischen Präsidenten ein Beispiel nehmen.
Parallel dazu versucht @fda77 in GitHub dann wieder zu vermitteln, daß er keinen Einfluß auf "boxmatrix.info" hat: https://github.com/Freetz/freetz/issues/89#issuecomment-471120155 - gegen Ende des Beitrags.
Ehrlich ... es liegt doch ein Angebot zur "Zusammenarbeit" auf dem Tisch - das könnte man ja einfach mal diskutieren. Aber warum wohl konnte ich bereits am Beginn dieses (ja, in meinen Augen tatsächlich "merkwürdigen") Forks praktisch sicher prognostizieren, daß dieses Getöse von "Zusammenarbeit" am Ende alles nur leeres Geblubber ist? Wer's noch mal nachlesen will, schaut in diesen Thread und sieht sich die Entwicklung an: https://www.ip-phone-forum.de/threads/freetz-ng.302327/ - die Anzeichen für diese Entwicklung gab es bereits am 03.02.2019 und das war gerade mal vier Tage, nachdem das "freetz-ng" aus der Taufe gehoben wurde: https://www.ip-phone-forum.de/threads/freetz-ng.302327/page-2#post-2315731
Ich hätte da eine Glaskugel zu verkaufen, die offenbar ganz gut funktioniert ... und um auch das gleich noch einmal festzuhalten: Ich habe erst auf diese "Abnabelung" aufmerksam gemacht, als sie bereits erfolgt war - also komme bitte niemand an und erkläre nun, meine Kritik daran und am sonstigen Vorgehen von @cuma/@opto/@fda77 (oder wie auch immer sich "Rumpelstiltskin" gerade nennt) wäre der Auslöser dieser Abnabelung gewesen. Man sollte hier bitte schön zwischen Ursache und Wirkung unterscheiden.
Und ich kann versichern, daß ich mir immer die paar Minuten Zeit abringen werde, die es braucht, um gegen solches "Geblubber" zu opponieren ... da stört man dann doch gerne. Der einzige Weg, mich davon abzubringen, wäre es vermutlich, wenn man einfach auf solche "Sch***hausparolen" verzichtet ... hast Du diese Alternative schon mal in Betracht gezogen?
Ja, es ist nicht immer einfach mit allen handelnden Personen bei "freetz/freetz" zurechtzukommen ... aber so ist nun mal das Leben und man kann trotzdem immer noch versuchen, etwas zu Besseren zu bewegen (auch im "alten Freetz-Projekt") und selbst wenn man das nicht will, kann man bei seinen Behauptungen ja entweder bei der Wahrheit bleiben oder zumindest mal so tun, als wollte man seine "Anschuldigungen" mit irgendeinem, wie auch immer gearteten Beweis untermauern. Ansonsten wird's halt irgendwann auch mal langweilig und die Leute wenden sich wieder dem Kampf gegen Chem-Trails zu.
----------------------------------------------------------------------------------------------------------------------------
Aber wie auch immer ... wir sollten vielleicht auch nicht ganz aus den Augen verlieren, was hier der "Aufhänger" für die Frage von @frater und die sich dann anschließende Wiederaufnahme der Diskussionen war, denn wenn @hippie2000 konstatiert:
, dann stimmt das ja nur bedingt ... wobei man die Bestätigung, daß es beim "freetz-ng"-Fork diese "negativen Commits" ebenfalls gab/gibt (auch beim "originalen Freetz-Projekt" will ich die nicht bestreiten, nur ist da wieder das Problem mit dem Balken im eigenen Auge, wenn man den Splitter beim anderen ganz genau erkennt), durchaus "festhalten" sollte, wenn es das war, was von @hippie2000 zum Ausdruck gebracht werden sollte.
Schließlich war ja genau das Ersetzen einer vorhandenen und funktionierenden Lösung durch etwas "Marke Eigenbau" der eigentliche Auslöser für das Problem, vor dem @frater nun plötzlich stand. Denn auch wenn "check_signed_image" für den konkreten Fall noch nicht genutzt wurde, wurden andere Skripte aus "signimage" ja auch an weiteren Stellen durch die eigene und eben unzulängliche Lösung ersetzt und auch das Entfernen des (inzwischen wieder "zugelassenen") Erstellens des Images für den Start aus dem RAM war ein solcher "negativer Commit", für den es - da das rein optional war und noch nicht mal "Standardeinstellung" - erst recht keinen Grund gab, denn dessen Existenz hätte ja nicht verhindert, daß jemand mit der anderen Image-Datei und "push_firmware" arbeitet, wenn ihm danach ist. Aber dieser Widerspruch zwischen dem Versprechen der "maximalen Freiheit" und dem, was der Freetz-Benutzer dann bei den neuen Möglichkeiten in "freetz-ng" tatsächlich noch selbst entscheiden darf, ist ja ohnehin offensichtlich.
Denn es gibt in dem "freetz-ng"-Fork zwar tatsächlich einige neue Möglichkeiten, aber es ist beileibe nicht so, daß man dort eben auch dem Freetz-Benutzer die Wahl läßt, ob er eine Option, eine Einstellung oder einen "remove patch" nun haben will oder nicht. Das geht klar (in den allermeisten Fällen jedenfalls) nach dem Motto: "Friß, Vogel, oder stirb." - auch das sollte man eben als Freetz-Benutzer bei seiner Entscheidung, welche Basis man für sein Freetz-Image verwenden will, berücksichtigen. Putzig ist es aber, wenn @hippie2000 dann auch noch gleich alle neuen Ideen für "freetz-ng" reklamieren will, Zitat: "If you prefer new ideas and solutions while preserving all the past you are best served using the ng fork [...]" und nicht etwa "If you prefer fast (and often insufficient - take your time for truth) solutions for new ideas ..." - es ist halt nicht so leicht, mit so wenigen Worten die manchmal doch komplexeren Zusammenhänge wahrheitsgetreu wiederzugeben ... insofern sollte man auch mal Nachsicht üben.
Vieles von dem neu Hinzugekommenen bei "freetz-ng" ist jedenfalls so umgesetzt, daß man gar keine eigene Wahl mehr hat - auf den (bei kleinen Anschlüssen tödlichen) Patch für den PA bei einem Telefonat hatte ich als Beispiel schon einmal irgendwo hingewiesen: http://trac.boxmatrix.info/freetz-ng/changeset/15154/freetz-ng. Selbst wenn man den AVM-Wert von 65% Reduktion beim Telefonat für zu groß hält (der alte Patch änderte das auf 35%), ist die Änderung auf 1% (ohne daß der Freetz-Benutzer da ein "Mitspracherecht" hätte) vielleicht an der Mehrzahl der heutigen Anschlüsse machbar. Aber es sind eben gerade die "corner cases", die (ebenso wie oben bei der Signaturprüfung) bei solchen Schnellschüssen immer wieder durchs Raster fallen, wenn jemand das gesamte System immer nur unter dem Aspekt betrachtet, was er selbst haben will und für sinnvoll hält.
Wenn dann andere (und da verstehe ich die "alten" Freetz-Developer dann sogar wieder) auf die Bremse treten, muß man sich nicht wundern. Entweder man zeigt solche Einschnitte ganz klar an und macht sie auch als das Abschneiden alter Zöpfe kenntlich (das beißt sich dann halt wieder mit der Intention von jemand anderem, alles am besten so zu erhalten, wie es schon 2008 war) oder man muß dann eben solche Änderungen auch so überlegt ausführen (selbst wenn man dafür mehr Aufwand in Kauf nehmen muß), daß die Grenzfälle auch weiterhin berücksichtigt werden - soviel Über- und Voraussicht sollte man von jemandem erwarten können, der sich die "Wartung" so eines Projekts zutraut.
Erst recht dann, wenn jemand mit einer "commit ratio" argumentieren will ... wenn ich immer drei weitere Patches brauche, um die Fehler eines vorhergehenden auszubügeln, ergibt das natürlich auch eine beeindruckende Anzahl an Commits. Denkt man zuerst mal etwas nach und testet ggf. sogar (in verschiedenen Szenarien), bevor man etwas "für die Allgemeinheit" freigibt, muß man auf solche beeindruckenden Zahlen vielleicht verzichten ("git" erlaubt einem das, weil man kein Online-Repo für die eigene Arbeit braucht) ... dafür können die Benutzer dann aber damit rechnen, daß es tatsächlich weniger Fehler bis in den Zweig schaffen, mit dem sie arbeiten (und bei Mißerfolgen ihre Zeit verschwenden) müssen.
Andererseits argumentiert ja @fda77 selbst gar nicht mit solch einer "commit ratio" (jedenfalls habe ich noch nichts davon gelesen) ... hier kommt doch nicht schon wieder der - inzwischen über 150 Jahre - alte Schlachtplan eines preußischen Generalfeldmarschalls zum Einsatz, der mit "Getrennt marschieren, vereint schlagen." skizziert werden kann? Wenn doch, sollte man vielleicht auch noch beachten, daß Moltke gleichzeitig dem Motto folgte: "Erst wägen, dann wagen." ... der war also auch kein Freund voreiliger Entschlüsse und/oder Handlungen.
Zuletzt bearbeitet:
