Freetz-NG

Deine Meinung zu Freetz-NG?


  • Anzahl der Umfrageteilnehmer
    30
  • Umfrage geschlossen .

cuma

Aktives Mitglied
Mitglied seit
16 Dez 2006
Beiträge
2,756
Punkte für Reaktionen
7
Punkte
38
Freetz und Freetz-NG sind nicht mehr einfach mergebar durch commits von f-666. Da es nie meine Absicht war, "konkurrierende" Forks zu haben, beende ich hiermit Freetz-NG.
Mitstreiter fanden sich eh keine dafür, weshalb hab ich keine Problem damit habe und dadurch kein Verlust entsteht.
Die Verwaltung von Freetz konnte sich leider nicht zu irgendwas durchringen, um diese absehbare Situation zu vermeiden. Ob es überhaupt Nutzer von Freetz-NG gab bin ich nicht so ganz sicher. Außerdem geht es bei Freetz jetzt wieder mit Volldampf voran.
Das Beste daran ist aber dass ich so PeterPawn los bin. Wie kommt er überhaupt auf die, Idee für Freetz sprechen zu können? Meldung bei Moderatoren brachte nichts ausser "Ignoriere den User doch einfach" - ist natürlich schwer wenn mich jemand so penetrant nervt

Es wird einen SVN-Mirror von Hippie auf BoxMatrix.info geben
Ich bitte darum davon nichts nach freetz.org auf GitHub zu mergen!
Das letzte Statement auf der geheimen Freetz-Mailinliste war: Wir wollen nichts von dir, wir brauchen nichts von dir.
 
Zuletzt bearbeitet:
Ich bin zwar auch für ein Zusammenführen von diversen Repos, aber mit dem, was hier wieder als "flache Hierarchie" bei den Änderungen zu sehen ist (alles in einen einzelnen Branch, den man entweder "haben" will oder nicht - ansonsten muß man selbst das "cherry-picking" machen und man kann dabei nicht mal anhand der Commits (und deren Messages) ohne weiteres erkennen, wofür so ein Patch nun gut sein soll und ob man den braucht oder nicht), kann ich persönlich einfach nichts anfangen - daher hänge ich mich hier auch nicht dran.

Nach meiner Ansicht (da war aber schon mit @er13 keine Einigkeit zu erzielen) gehören die Änderungen für ein (bzw. jedes) Paket in einen separaten Branch (also das Prinzip der "feature branches" auf die Pakete in Freetz angewendet) und der kann dann mit dem Master gemischt werden oder eben auch nicht. Wer will, kann sich dann auch seinen eigenen Stand aus der "Basis" und den angebotenen Paketen zusammenmischen und den anstelle eines "masters" verwenden.

Sich hier jede einzelne Datei anzusehen (36 Commits mit 73 geänderten Dateien sind es im Moment, die da auf einen Schlag und in einem Branch vorgenommen wurden), um deren Änderungen nachzuvollziehen, bringt mir persönlich nichts (kostet nur Zeit), weil die Mehrzahl meiner Änderungen eben auf Abwandlungen von bereits vorhandenen Freetz-Paketen beruht (z.B. der Einbau der Unterstützung des RSA-Keys der Box in "dropbear") und ich daher bei jeder Änderung erst mal abchecken muß, ob sich diese mit meinen eigenen "beißt" oder nicht. Zumal ja @cuma oft genug bei neuen Sachen von mir festgestellt hat, daß das bei ihm schon lange so laufen würde ... also ist die Wahrscheinlichkeit von Inkompatibilitäten und damit das "Konfliktpotenzial" da ja besonders hoch und ich müßte sehr genau hinschauen.

======================================================================

Ich verstehe im Moment auch noch nicht so richtig, was ein "freetz-ng" jetzt bringen sollte (außer man WILL den gewaltsamen Fork, was auch ein legitimes Ziel ist, aber das kann man dann ja auch deutlich ansagen) oder warum es erforderlich sein sollte ... wenn mein (persönlicher) Eindruck nicht täuscht (ich hatte Oliver und Eugene parallel per E-Mail angeschrieben, nur Oliver hat geantwortet), daß @er13 auch keinen Bock mehr hat (von @Whoopie wurde das ja "offiziell" angesagt), dann müssen/können/sollten eben andere die entsprechenden Schreibrechte für das "originale Projekt" erhalten. Zu dem kann man dann auch wieder mit PRs entsprechend beitragen ... im Moment fehlt halt jemand, der das in das "offizielle Repo" integriert.

Ich selbst habe zugegebenermaßen jetzt auch keinen Bock, meinen Fork auf die Basis irgendeines anderen (Forks) umzustellen - zumal eben die automatischen Vorgänge bei PRs am besten dann funktionieren, wenn sie gegen das originale Repo arbeiten können (also das, von dem der Fork auch stammt) und irgendwelche Wege (z.B. per E-Mail) für den "Austausch" von PRs zwischen zwei Repos eher nervig (und für mich auch unnötiger Aufwand) sind. Daher wäre so ein "Umschalten" auf einen neuen Fork in meinen Augen ein "point of no-return" ... und das ist mir persönlich noch zu früh, hier unmittelbar die Flinte ins Korn zu werfen.

Sollte ich selbst jemals den Übergang zu einem anderen "Basis-Projekt" vollziehen mit meinem Fork, dann wäre das auch eines, was die "Grenzen" zwischen den vier Teilen, die das Freetz-Projekt in meinen Augen viel zu sehr miteinander verquickt (das wären für mich

  • Toolchain (Cross-Compiler, C-Library und Kernel)
  • Paketverwaltung
  • Firmware-Generator (fwmod)
  • Freetz-Mod (GUI + einige "framework files" für die Infrastruktur beim Starten/Stoppen von Diensten)

), einhält und das auch entsprechend aufteilt. Das Ergebnis wäre es dann, daß ein "version bump" für eine AVM-Firmware eben nur den "Firmware-Generator" tangiert (solange sich dabei nichts ändert, was Auswirkungen auf die Toolchain hätte) und eine neue Version für irgendein Zusatzpaket nur eine Änderung in der Paketverwaltung nach sich zieht.

Findet man dann noch einen Mechanismus, der bei der Paketverwaltung eine "selektive Auswahl" ermöglicht und nicht mehr - wie bisher - alle Pakete auf einmal enthält (im Moment gibt es 276 Pakete, dazu kommen noch "linux", "libs" und "mod", die weitere Abhängigkeiten haben), kann man auch die eigenen Aktivitäten beim Neuerstellen eines Images auf das Wesentliche beschränken ... wenn ich das Paket "lightppd" gar nicht im Image habe, interessiert es mich auch nicht, wenn sich dessen Version ändert und wenn ich mich nur (per E-Mail) über Änderungen an den von mir verwendeten Paketen informieren lassen kann (dafür gibt es ja Mechanismen in GitHub), dann ist es auch deutlich leichter für mich als "Freetz-Benutzer", den Überblick über die Änderungen zu wahren.

Eine solche "Umorganisation" wäre dann etwas, was in meinen Augen eher den Zusatz "-ng" (gemeinhin ja als "next generation" (oder "new gen") verstanden) verdient hat ... ein "weiter so", nur eben in einer anderen "Organisation", schreibt auch nur den Status Quo weiter fort - mit allen derzeit auch schon vorhandenen Unzulänglichkeiten.

======================================================================

Bislang hab ich bereits eingeladen aus den Bereichen: cable, fhem, toolchain, 2x bump und mich
Das ist z.B. ein Satz, den ich nicht mal im Ansatz verstehe bzw. wo es so viele "Interpretationsmöglichkeiten" für mich gibt, daß ich damit nichts anfangen kann. Was ist denn "2x bump" und warum hast Du den (oder die) eingeladen? Wer ist denn "mich" und warum mußte der (wenn das "Du" sein solltest, also @cuma) eingeladen werden und vor allem, wofür galt denn diese Einladung?

Gesetzt den Fall, @er13 macht nicht mehr weiter im "originalen Projekt" ... wärst Du denn daran interessiert, dort wieder Schreibrechte zu erhalten und dann - in Abstimmung mit anderen Mitstreitern - an Freetz weiterzuarbeiten und zwar in einer Richtung, die "abgestimmt" ist und im (unterstellten) Interesse der meisten (verbliebenen) Freetz-Benutzer wäre? Angesichts einiger Diskussionen in jüngster Zeit (u.a. zum Boot-Manager) gäbe es ja offenbar auch zwischen uns erhebliche Meinungsverschiedenheiten und wenn man diese nicht zuvor in einer (sachlichen) Diskussion ausräumt, endet das vielleicht doch wieder in einem "commit war".

So etwas bringt aber niemandem etwas und daher ist dann vielleicht eine strikte Trennung von Verantwortlichkeiten (z:B. wie bei der Kernel-Entwicklung, wo auch nicht einfach das Storage-Subsystem in den Netzwerk-Code eingreifen darf) notwendig, bei der sich jeder "um seins" kümmert, aber trotzdem die "große Linie" der anderen mit unterstützt - heißt konkret, auf die "Angebote" von anderen zurückgreift, wo es machbar ist, anstatt sein eigenes Süppchen zu kochen bzw. unbedingt seine eigene Implementierung hinlegen zu müssen, ohne genau darlegen zu können, warum das so sein muß bzw. welche Vorteile diese nun gegenüber etwas anderem hätte.

Wenn @er13 nicht weitermachen sollte, wäre ich jedenfalls auch an Schreibrechten interessiert (allerdings im originalen Projekt und nicht in "-ng"), wobei ich mein Hauptaugenmerk eben auf die Toolchain legen würde, denn die kann ich für YourFritz ganz gut brauchen. Das wäre dann auch der Teil, für den ich mich bereiterklären würde, die "Wartung" zu übernehmen. Ansonsten brauche ich noch ein paar (wenige) Pakete und da läge mein Fokus (wie bei einigen Änderungen, die dann keinen Einzug in das "offzielle" Freetz-Repo gefunden haben und von mir in getrennten Branches in meinem Fork verwaltet werden) auch darauf, daß diese Pakete "dual use" sind und sich sowohl in einem Freetz-Image als auch in anderen Umgebungen verwenden lassen.

Der "Rest" (viele, viele Pakete, die kein Mensch wirklich braucht - so zumindest mein Eindruck - und "fwmod" zum Erstellen eigener Images) tangiert mich nicht so sehr ... daher würde ich meine Aktivitäten an dieser Stelle auch deutlich auf die Korrektur gefundener Probleme beschränken - und wenn sich tatsächlich wieder mehrere Leute zusammenfinden und die Verantwortung für Freetz übernehmen wollen, dann würde ich mich am liebsten aus diesem "Rest" auch komplett heraushalten. Höchstens für das "Drumherum" hätte ich noch ein paar Vorschläge (über einen haben ich mit @er13 vor nicht allzu langer Zeit ziemlich erbittert gestritten: https://github.com/Freetz/freetz/pull/55), die einige Aktivitäten beim Erscheinen neuer (Labor-)Versionen eher in die Hände der Freetz-Benutzer legen und damit auch den Arbeitsaufwand für das "Einarbeiten" solcher neuer Versionen in den Freetz-Master verringern. Das wären dann wieder Vorschläge, die sich auf den Teil "Firmware-Generator" beziehen - denn der ist dann ja auch für das Laden, Entpacken und Packen der jeweiligen Labor-Versionen verantwortlich.
 
  • Like
Reaktionen: NDiIPP
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Ich war immer gegen einen Fork und fand es besser wenn mehr Schreibzugriff aufs SVN bekommen hätten. Wie die letzten Jahre gezeigt haben herrscht Protektionismus. Wenn der letzte mit Schreibrechten einen ausgedehnten Urlaub macht geht mal für Monate nichts. So gibt es fast keine Community mehr die sich beteiligt, und wenn jemand was macht liegt es ewig irgendwo herum (zB "cable" Sachen brauchten 1 Jahr in den trunk).
Ich hatte er31 ein paar mal ne PM geschrieben, er beharrt aber störrisch auf seinem Standpunkt und will sonst niemandem Schreibzugriff geben. Mir gegenüber haben alle, auch die nicht wirklich aktiven Entwickler einstimmig gesagt, von mir wir nichts gebraucht, gewollt und sie könnten das alles eh viel besser (sinngemäß). Daher können meine Sachen auch nicht Upstream gehen. Dennoch hab ich er via github eingeladen, die Toolchain ist sein Sache.
Ansonsten, wenn es Unstimmigkeiten gibt, kann man die oft einfach ausräumen: Man macht den Streitpunkt optional, hatte ich eh immer schon so gemacht. Die Sachen von heute sind teilweise seit Jahren getestet, genaugenommen sind die aus meinem packages "branch"/Verzeichnis.
Bevor ich weitermache schaue ich mir zuerst mal an wie es sich entwickelt.
Wie man das Ganze irgendwann mal umbauen will hat Zeit, zuerst müssten alle Forks mal eingesammelt werden, da es sonst bei größeren Umbauten inkompatibel werden könnte (-> der Sinn der "Organisation"). Ausserdem ist die Frage ob es überhaupt irgend einen Nutzen hat und wer dazu Lust hat.
Das "einladen" bezieht sich auf die GitHub "Organisation"
Einen Firmwaregenerator für die Labors fänd ich auch gut, auch wenn ich NIE Labors verwende. Am besten wie die git/svn packages mit "last known good" bei der die Patches noch passen
EDIT: PR55 find ich witzig. Hab jetzt nicht alles durchgelesen, aber es spricht ja nichts dagegen eine neue Option aufzunehmen. Wers verwenden will machts, die anderen ignorieren es. Ich glaub aber du hast "menuconfig help" nicht erweitert
 
Zuletzt bearbeitet von einem Moderator:
Wollte mir grade das ng mal anschauen aber komme nicht sehr weit, Es fehlt kconfig-v4.12.2.tar.xz

Code:
freetz@debian-freetz:~/freetz-ng$ make menuconfig
tools/freetz_download dl kconfig-v4.12.2.tar.xz git_archive@git://repo.or.cz/linux-2.6.git,scripts/basic,scripts/kconfig,scripts/Kbuild.include,scripts/Makefile.build,scripts/Makefile.host,scripts/Makefile.lib

--2019-01-31 06:46:32--  http://freetz.magenbrot.net/kconfig-v4.12.2.tar.xz
Auflösen des Hostnamens »freetz.magenbrot.net (freetz.magenbrot.net)« … 31.172.113.113
Verbindungsaufbau zu freetz.magenbrot.net (freetz.magenbrot.net)|31.172.113.113|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2019-01-31 06:46:32 FEHLER 404: Not Found.

Download failed - "http://freetz.magenbrot.net/kconfig-v4.12.2.tar.xz"  ->  error code 8

--2019-01-31 06:46:32--  http://freetz.3dfxatwork.de/kconfig-v4.12.2.tar.xz
Auflösen des Hostnamens »freetz.3dfxatwork.de (freetz.3dfxatwork.de)« … 31.172.113.113
Verbindungsaufbau zu freetz.3dfxatwork.de (freetz.3dfxatwork.de)|31.172.113.113|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2019-01-31 06:46:33 FEHLER 404: Not Found.

Download failed - "http://freetz.3dfxatwork.de/kconfig-v4.12.2.tar.xz"  ->  error code 8

--2019-01-31 06:46:33--  http://freetz.wirsind.info/kconfig-v4.12.2.tar.xz
Auflösen des Hostnamens »freetz.wirsind.info (freetz.wirsind.info)« … 188.165.115.52
Verbindungsaufbau zu freetz.wirsind.info (freetz.wirsind.info)|188.165.115.52|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 404 Not Found
2019-01-31 06:46:33 FEHLER 404: Not Found.

Download failed - "http://freetz.wirsind.info/kconfig-v4.12.2.tar.xz"  ->  error code 8

Checking out files from the git_archive repository...
remote: fatal: no such ref: v4.12.2
remote: git upload-archive: archiver died with error
tar: Das sieht nicht wie ein „tar“-Archiv aus.
tar: Beende mit Fehlerstatus aufgrund vorheriger Fehler
tools/make/kconfig/kconfig.mk:10: die Regel für Ziel „dl/kconfig-v4.12.2.tar.xz“ scheiterte
make: *** [dl/kconfig-v4.12.2.tar.xz] Fehler 1
freetz@debian-freetz:~/freetz-ng$
 
Weil's hier nicht steht ... die Source-URL für Kconfig 4.12 wurde inzwischen angepaßt und man kann das nach einem "git pull" noch einmal probieren.
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Danke PeterPawn, hatte kein Forenpasswort mit. Die Datei lag bei mir noch im dl/, da fiel das nicht auf
 
Zuletzt bearbeitet von einem Moderator:
Gute Sache cuma.

Ich hab gehofft dass jemand forked.
Freetz ist seit fast 2 Monaten tot. Letzter commit 2.12.

Protektionismus ist noch viel zu nett ausgedrückt.
Mach aus Freetz wieder ein Community Projekt, weil das ist es definitiv nicht mehr.
Es wurde eher (zu Tode) einkassiert und alle Spuren der Herkunft verwischt.

In den 2 Monaten ist viel passiert. AVM schläft nicht.

Ich hab hier ne tagesaktuelle Liste generiert in der man immer nachsehen kann was an Source, Firmware und Labors so hinzukam. Über 50 Files seit Freetz totadministriert wurde:

> https://boxmatrix.info/wiki/Download-News#Firmware-News

Die Liste ist immer aktuell. Die Scans in jedes File hineinblicken zu können laufen allerdings morgens, auch wenn die Liste öfter aktualisiert wird. Pro Firmware wird jetzt das tar Image gelistet, jedes Filesystem (auch wrapped) und auch var.tar. Atom Listings also Zweitlinux noch nicht. Zudem kann man mit strings durch das entpackte Kernel und durch busybox sehen in jedem scan Resultat.

Man kann jetzt nicht nur in jede Firmware reinblicken, sondern auch in jeden Quelltext:

> https://boxmatrix.info/wiki/AVM-Tarballs

Nützlich wenn ein File fehlt und man es suchen gehen muss...

Wenn ich irgend etwas anderes nützliches generieren kann gerne anfragen.

Ich scanne mittlerweile alles täglich, und dauernd kommen neue generierte Infos raus.

Hier arbeite ich gerade dran: Eine History aller Releases aller Modelle, und man kann überall hineinblicken...

> https://boxmatrix.info/wiki/Firmware-History

Das ist noch Baustelle, aber man kann jetzt schon sehr viel sehen. Z.B welche Firmware noch telnet kann, debug.cfg, unsigned Firmware, WDS, weiteres wird folgen.

Gerade die Frage nach der letzten Firmware die noch Unsigned kann beantworte ich fast jeden Tag im ##fritzbox IRC-Channel...

Viel Glück für dein/euer Projekt, vor allem weil es Community gleich von Anfang an schätzt!
 
  • Like
Reaktionen: gnieder und stoney
Gerade die Frage nach der letzten Firmware die noch Unsigned kann beantworte ich fast jeden Tag im ##fritzbox IRC-Channel...
Mal aus reiner Neugierde ... wofür genau spielt diese Frage denn eine (wesentliche) Rolle?

Und was antwortest Du dann den Besitzern der neuen Modelle, für die es nichts vor 06.5x gibt?
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
@Hippie: Danke, aber zuerst mal schauen ob es was wird. Ist ja noch nicht so viel passiert. Hab keine Lust auf ne 1-Mann-Show...
Kann man auf Box-Matrix sehen, bei welchen Geräten&Firmware AVM sein Script für "reboot" hat? Hab das als "ab FOS7" gemacht, aber nicht jede einzelne Firmware untersucht. Zur Not bräuchte man per _HAS_ Symbol
PeterPawn hatte mal die Idee die aktuelle Labor dynamisch zu ermitteln, vielleicht kann man das mit der Datenbank machen?
Auch war vor Jahren mal angedacht die "_HAS_" Symbole durch Firmwareanalyse zu setzen. Vielleicht wird das ja auch was
Man könnte noch überlegen einen 4. Mirror zusätzlich in Freetz zu packen (auf BoxMatrix? oder YourFritz?). Wenn mal eine Origial-Quelle ausfällt, gibt es keinen zeitnahen Weg eine Datei hochzuladen. Wem die Mirrors gehören weiss eh niemand mehr, wer Zugriff hat ist auch nicht so ganz klar
@PeterPawn: Wie wäre es dein .config-cleanup zu pushen? Beim ursprünglichen Freetz wurde das ja abgelehnt und es wäre schade wenn die Arbeit verloren ginge. Das Problem gibt es ja definitiv
 
Zuletzt bearbeitet von einem Moderator:
@cuma:
Du kannst den Branch ja auch selbst mischen mit Deinem Repo ... weißt Du, wie das geht?

Wenn nicht, beschreibe ich es ggf. bei Gelegenheit mal ausführlicher - aber es ist eben "automatisch" nicht ohne weiteres machbar (jedenfalls soweit ich weiß), wie ich oben schon mal in #2 angedeutet hatte.

PRs gehen automatisch wohl nur gegen díe Quelle des Forks, andere Änderungen kann man dann ggf. per E-Mail verteilen (so fast immer in der Kernel-Entwicklung zu sehen) oder indem man das "fremde" Repo, aus dem man etwas in das eigene mergen will, als zusätzliches "remote" definiert und dann kann man (nach "fetch") von dort auch einzelne Branches mergen.

( Ich nehme jetzt mal den Anglizismus "mergen", weil mir "mischen" zu "aseptisch" klingt. )

Über einen Mirror auf yourfritz.de kann man ggf. auch mal nachdenken, allerdings hat der Server dort nicht so unmäßig viel Platz - da könnte ich nur ~ 60 GB "anbieten" und ich habe keine Ahnung, wieviel derzeit tatsächlich benötigt würde (erst recht, wenn da alle alten Versionen irgendwo mitgeschleppt werden, damit auch frühere Checkouts noch die passenden Dateien irgendwie finden).

Im Idealfall holt sich die Toolchain das alles aus dem Internet - die Zuverlässigkeit der Server ist ja inzwischen auch deutlich höher als vor 10-15 Jahren (bei korrekten Adressen braucht es also i.d.R. ohnehin keinen eigenen Mirror) und es gibt eigentlich für (fast) jedes Paket auch heute schon im Internet noch entsprechende alternative Quellen ... nur halt nicht unbedingt für irgendwelche Asbach-Versionen von Paketen.
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Ich hab keinen blassen Schimmer von GIT! Bin froh dass ich das soweit hab dass ich das commiten kann. Wenn du mich fragst, NG steht für "Nooo, GIT!" :)
Gibt es für "svn cp" einen Befehl für git? Das Dark-Skin hatte ich ursprünglich von einem anderen Skin kopiert. Im commit hätte man mit svn nur die diffs zum ursprünglichhen Skin gesehe, so aber leider nicht. Evtl könnte man das ganze auch auf den svn vom digital-elite-board packen, hab jetzt aber schon bisschen zeit in git gesteckt.
Auf GitHub kann man wenn man "new pull request" anklickt, oben links das Ziel auswählen. Ich hab da ne ganze Latte an repos. Vielleicht geht das?
Mein dl/ Verzeichnis ist [EDIT] 7GB gross (dl/fw/ 18GB) und geht zurück bis zu DS Zeiten, der Platz sollte also reichen. Mit "make mirror" kannst du vieles herunterladen. Mir gehts vor allem um Dateien die weg sind weil es evtl eine neue Version gibt und die alte gelöscht wurde. Aber noch nicht in Freetz aktualisiert sind. Aber eigentlich bräuchte man das was auf den anderen 3 Mirrors ist nicht nochmal
 
Zuletzt bearbeitet von einem Moderator:
  • Like
Reaktionen: gnieder
Vielleicht geht das?
Ich habe mal mit dem GitHub-GUI versucht, den Branch "clearconfig" aus meinem Fork als "Angebot" für Dein Repo zu platzieren.

Wie das mit der Kommandozeile ginge (wenn überhaupt, denn die kennt ja eigentlich die ganze "Verwandschaft" der anderen Repos nicht, sondern nur diejenigen, die als "remote" konfiguriert sind), weiß ich auch nicht ... aber "automatisieren" kann man das mit dem GitHub-GUI (zumindest solange man das im Browser benutzen will/muß) wohl nur schlecht.

Das mit dem Mirror durchdenke ich noch mal ... der macht natürlich auch nur dann Sinn, wenn er bei den "Benutzern" als alternative Quelle in der Liste steht - so als "Selbstzweck" braucht's den nicht. Gerade die "alten" Pakete will ich aber eigentlich auch nicht spiegeln ... wenn jemand sein Freetz-Image unbedingt mit einer uralten und verwundbaren OpenSSL-Implementierung bauen will (wie das bei < OpenSSL 1.0 fast zwangsläufig ist), dann soll er gefälligst auch selbst sehen, wo er diese verwundbare Version als Quell-Code findet.
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Sieht doch gut aus.
Die Fork-Abstammung sieht man bei "Insights" zB hier https://github.com/freetz-ng/freetz-ng/network/members
Kann man via commandline (theoretisch) nicht eine weitere origin angeben, evtl pullen, und dann dorthin pushen? Wie gesagt, bin GIT-Anfänger
Blöd dass man bei GitHub nicht sieht, ob die Dateien +x haben.
Hattest du eine GitHub-Organisation Einladung bekommen? Könnt sein dass die irgendwann ablaufen
Hab jetzt gesehen wie du das bei dir mit den branches gemacht hast, https://github.com/PeterPawn/freetz/commit/a773e811d87405b8dd87625e29b35f4e54b49829 finde ich interessant
 
Zuletzt bearbeitet von einem Moderator:
Ja gute Fragen, cuma, sowas wollt ich ja.

Ich schau mir das morgen genauer an, Ich bin da auch zuversichtlich dass es was wird mit ng, bist ja auch kein Anfänger in dem Genre. Hauptsache es geht weiter ohne synthetische Restriktionen.

@PeterPawn: natürlich sage ich den Leuten die Wahrheit dass es nix gibt, zeigt ja auch meine Firmware-History. und zeige ihnen dann Evatools. Und bisher kamen nur die hart gesottenen durch deine Doku durch :)
Ich hätte gerne ne Kompatiblitätsliste von deiner Arbeit, etwa wie das FIRMWARES File bei Freetz. Reden wir nochmal separat drüber, würde ich gerne einbauen und dann wo nötig und kompatibel empfehlen.

@cuma: Aber was anderes - ich hab nen Open Source Monitor der über 600 Projekte im 3-Stunden Takt überwacht, u.A. auch über die Github API.

> https://boxmatrix.info/wiki/OSS-News

Freetz ist einer der Suchbegriffe aber Github ist da auch krass mit Suchbegriffen, wenn jemand fritzboxes sagt findet der Term fritzbox es nicht - halt kalt gehasht.

Gestern hab ich den Suchbegriff freetz-ng hinzugefügt und auch dann wird es nicht gefunden - ist das noch irgendwie nonpublic geflaggt?

Ne direkte Anfrage für den Begriff an die API brachte kein Resultat...

Es würde auch genügen Topic Fritzbox einzubauen...

Irgendwas verhindert da noch die Suche...
 
Zuletzt bearbeitet:
Hattest du eine GitHub-Organisation Einladung bekommen? Könnt sein dass die irgendwann ablaufen
Ja, aber absichtlich ignoriert (siehe #2).

Wenn sich @er13 bis nach dem Superbowl nicht äußert (das wäre die Nacht von Sonntag auf Montag), versuche ich über Oliver an Schreibrechte für das andere Repo zu gelangen (davon weiß er auch schon, weil ich - wie gesagt - sowohl ihn als auch Eugene angeschrieben habe (schon am 23.01.2019, also eine Woche vor Deinem Fork hier) und er hat reagiert) - ich bin nach wie vor der Ansicht, man sollte das (solange man an der Struktur nichts ändert, denn das rechtfertigt dann auch in meinen Augen eine neue "Entwicklungsstufe" - wieder siehe #2) nicht unbedingt als Fork weiterführen, wenn es auch anders geht, weil sich @er13 verabschiedet hat.

Das wäre m.E. auch nicht im Sinne der verbliebenen Freetz-Benutzer ... wenn man hier im Board jedesmal bei einem Problem erst mit der Klärung beginnen muß, welcher Fork bzw. welcher Stand jetzt von demjenigen verwendet wurde, der ein Problem hat und/oder meldet, wird das auch für diejenigen, die Hilfestellungen leisten wollen, sehr schnell sehr mühsam.

Das läßt sich (zumindest im Moment) noch vermeiden nach meiner Ansicht ... ebensowenig, wie ich der Ansicht war, daß es als unmittelbare Antwort vor 1 1/2 Jahren ein neues Board brauchte, bin ich heute der Ansicht, daß es unbedingt einen Fork braucht, der im Prinzip genauso weitermacht wie bisher. Dann kann man auch "das Original" einfach fortführen ... wobei man sich dann auch als Maintainer schon noch ein paar Skript-Dateien bauen sollte/müßte, damit die Routineaufgaben (bis hin zur Integration neuer AVM-Releases) keine "Kreativität" mit Beschlag belegen.

Wobei man eben die Arbeitsweise mit "git" ohnehin überarbeiten müßte ... jeder Developer sollte sein eigenes Repository haben/betreiben (ggf. sogar lokal - ich habe jedenfalls neben den GitHub-Repos dieselben Daten auch noch mal lokal und kann darauf mit verschiedenen Systemen zugreifen (zum Testen) und erst wenn etwas "fertig" ist, landet es normalerweise im GitHub-Repo) und Änderungen erst einmal darin vornehmen, bevor er sie als PR für den Hauptzweig bereitstellt, die dann übernommen werden.

Das hat den unbestreitbaren Vorteil, daß man die zusammengehörenden Patches dann mit einem Kommando einbinden, aber auch wieder rauswerfen kann (über ein "rebase" mit "drop"-Zeilen) ... und man kann "Änderungsvorschläge" an so einem PR auch erst noch "diskutieren", bevor man die Commits auf die Freetz-Benutzer losläßt - wobei Interessierte eben auch mit einem "feature branch" testen/arbeiten können und nicht erst warten müssen, bis irgendwelche Patches (wie bisher in irgendwelchen Trac-Tickets) von jemandem mit Schreibrechten in den Hauptzweig übernommen wurden.

Das wäre jedenfalls eine Arbeitsweise, die zur Funktionsweise und zur Struktur von "git" (und GitHub) paßt und wo tatsächlich "parallel und verteilt" gearbeitet werden kann. Wie das mit "thematischen Pull-Requests" funktioniert, kann man sich z.B. ganz gut an dem von @f666 für die Puma-Boxen ansehen ... auch wenn der am Ende wg. diverser Änderungen bei der Integration nicht so übernommen wurde, wie er bereitgestellt wurde.

Das ist auch ein weiterer Punkt, der m.E. dringend geändert werden müßte ... wenn jemand einen PR bereitstellt und der hat keine funktionellen Probleme (sprich: der macht das, was er soll), dann gehört der erst einmal 1:1 übernommen, wenn es "etwas Neues" ist - selbst wenn man es anders implementieren würde. Genau das kann man dann nämlich in einem eigenen, aber zusätzlichen PR wieder aufzeigen und auch passend begründen, so daß andere das nachvollziehen und z.B. gemeinsam entscheiden können.

Solange eine "aktuelle Lösung" erst einmal funktioniert, verliert man damit rein gar nichts ... das Übernehmen eines PR, der keine Konflikte hat, erfordert vom Schreibenden keinen zusätzlichen Aufwand und wenn der dann denkt, daß er es besser (oder auch nur "anders") machen würde, dann kann er das erst einmal begründen und "zeigen" und damit auch weiteren Stimmen die Chance eröffnen, ihre Meinung dazu zu äußern. Trotzdem können andere Benutzer die Neuerungen dann bereits verwenden ... da muß nicht erst jemand kommen und das so "umschreiben", wie er es für richtig hält und erst dann "dürfen" die "normalen Freetz-Benutzer" auch davon profitieren.

Das sind natürlich die bekannten Kernpunkte der Kritik an der bisherigen Vorgehensweise von @er13 und man könnte das jetzt als "Nachtreten" interpretieren ... aber ich habe auch in der direkten Auseinandersetzung da ja kein Blatt vor den Mund genommen und so will ich "den Kardinalfehler", der nach meiner Ansicht bisher beim Freetz-Projekt gemacht wurde (zumindest in den letzten vier Jahren), einfach noch einmal ganz klar benennen. Denn sollte es in ähnlicher Weise weitergehen wie bisher, wechsele auch ich "mit fliegenden Fahnen" zu einem neuen Projekt, ggf. auch zu einer neuen Organisation ... aber das ist eben ein "was wäre wenn" und bisher hege ich noch die Hoffnung, daß sich vielleicht doch genug (neue und alte) Mitstreiter finden werden, um das bisherige Projekt zumindest fortzuführen oder vielleicht auch umzustrukturieren.

All das an Infrastruktur, was bereits existiert (bis hin zur Mailing-Liste, denn man muß nicht unbedingt alles öffentlich diskutieren - wobei ja inzwischen auch private Repositories in den kostenlosen GitHub-Accounts erlaubt sind und da kann man auch "geheim" tagen), muß man auch nicht unbedingt noch einmal erfinden ... mal ganz abgesehen von der Domain "freetz.org".

Das alles jetzt noch einmal doppelt zu verwalten, nur weil es einen (funktionell aber identischen) Klon gibt, ist (in meinen Augen) nicht wirklich zielführend und wäre nur dann als Alternative unabdingbar, wenn es mit den "originalen Ressourcen" nicht weiterbetrieben werden könnte, weil alte "Befindlichkeiten" einen Neubeginn (auf der Basis des aktuellen Standes, ich meine hier nicht "from scratch") be- oder gar verhindern. Für ein "Freetz ist tot, es lebe Freetz!" ist es in meinen Augen jedenfalls noch zu früh ...
 
Zuletzt bearbeitet:
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
@hippie2000: Hab in der Organisation nicht viel eingestellt, so viele Optionen gibt es auch nicht. Falls du einen GitHub Account hast schick mir den, kann dich dann auch hinzufügen und du kannst selbst schauen.
@PeterPawn Bin auch der Meinung dass man Neues aufnehmen sollte. Falls es nicht "perfekt" ist, kann man immer noch nachbessern. Nur weil man jetzt GIT verwendet heisst es ja nicht dass man gleich alle möglichen Features nutzen muss. Das wird sich mit der Zeit ergeben. Ich war mit SVN zufrieden und kenne mich damit aus. GIT hätte ich nicht gebraucht. Problematisch sehe ich eher, dass auf keinem Weg was ankam! Falls wirklich niemand Bock hat hier mitzumachen, kann es auch sein dass ich wieder auf SVN zB im DEB umschwenke.
Du bist also der Meinung, es wäre besser freetz-ng zu löschen und weiterhin abzuwarten bis sich sonstwas tut?

Domain freetz.org: Sehe da keinen Vorteil momentan. Das lief mal gut, aber da es eh nur auf github verlinkt kann man auch gleich dorthin gehn
Organisation "Freetz" auf GitHub: Weisst du, mit der bleibt der gleiche Mief wie die letzten 10 Jahre. Irgend welche Leute die seit Ewigkeiten nichts beigetragen haben, aber gerne "was zu sagen" haben. zB olis.: "Unter" dem irgendwas zu machen hab ich absolut keinen Bock! So "hintenrum" Leute kann ich nicht leiden, kannst ihn ja mal fragen was er mir gegenüber abgezogen hat. Das geht gar nicht
Ich finde es falsch eine geheime Mailingliste als Vorteil herauszustellen. Normalerweise sollte man Sachen öffentlich diskutieren. Selbst als ich noch nicht von der Freetz-NP-ML geworfen wurde fand ich das bereits
 
Zuletzt bearbeitet von einem Moderator:
Du bist also der Meinung, es wäre besser freetz-ng zu löschen und weiterhin abzuwarten bis sich sonstwas tut?
Das ist eine "Überinterpretation" dessen, was ich tatsächlich geschrieben habe.

Ich bin im Moment aber auch wirklich der Ansicht, daß es den Fork nicht unbedingt braucht - damit sage ich aber eben nicht, daß man sich hinsetzen und die Hände in den Schoß legen sollte, bis andere etwas tun.

Ich habe oben doch berichtet, was ich meinerseits bereits unternommen habe/hatte und wann das war ... das kann man ja nun schlecht als "abwarten und Tee trinken" mißverstehen.

Genauso solltest Du das, was ich tatsächlich geschrieben habe, noch einmal unter dem Aspekt:
Ich finde es falsch eine geheime Mailingliste als Vorteil herauszustellen. Normalerweise sollte man Sachen öffentlich diskutieren.
nachlesen.

Ich schreibe nämlich nicht, daß man ALLES im Geheimen besprechen sollte - und trotzdem gibt es Themen, die nicht direkt "in der Öffentlichkeit" mit x unbekannten Beteiligten besprochen (und dabei auch zerredet) werden müssen bzw. wo irgendwelche Pläne oder auch nur Absichten gleich breitgetreten werden müssen.

Manches gelingt einfach auch besser, wenn man es einfach "mal macht" (und zwar so lange, bis es fertig ist) und erst dann dürfen die "Meckerer" darauf einhacken. Auch wir beide hatten solche Diskussionen schon - vom Dekodieren der AVM-Verschlüsselung über das Signieren von Firmware bis zur Frage, was AVM nun bei den DOCSIS-Modellen alles "falsch macht", was man - zumindest partiell in Zitaten - auch heute noch nachlesen kann.

Allerdings erfolgte das eben unter Deinem anderen Pseudonym (denn Du bist ja wohl auch @opto) und die meisten der Beiträge unter diesem Pseudonym hast Du hier aus den diversen Threads auch im Nachhinein getilgt - sooo überwältigend ist das mit Deiner Offenheit im "public dispute" also auch nicht, denn viele meiner Antworten auf Deine "Nachfragen" stehen jetzt in diesen Threads etwas "verloren" da, weil ich eben gerade - entsprechend den Regeln des Boards hier - keine Vollzitate Deiner Texte verwendet habe.

Da wäre mir nun wieder eine Mailing-Liste mit einer entsprechenden Archivierung deutlich angenehmer (ein Mail-Wechsel mit mehr als zwei Adressaten ist irgendwann unhandlich - so zumindest meine Erfahrungen, die ich bei Freetz z.B. mit @er13 und Ralf Friedl machen durfte - und auch dem fehlt dann wieder dieser Aspekt der (unabhängigen) Archivierung) - zumindest im Vergleich zu dem, was dieses Board bei solchen Diskussionen leisten kann, wo leider ein "Autor" auch im Nachhinein noch Vandalismus betreiben kann, indem er sämtliche Äußerungen, die ihm "peinlich sind", nicht etwa (ersichtlich) korrigiert, sondern sie einfach ändert oder gar komplett löscht. Das hat dann nämlich mit "öffentlicher Diskussion" auch nicht mehr viel zu tun ...

Deine Ängste hinsichtlich der Einmischung von anderen beim originalen Freetz-Projekt kann ich nicht so richtig nachvollziehen ... warum sollten die Leute, die sich jetzt über Jahre nur sehr sporadisch überhaupt um das Projekt gekümmert haben, nun plötzlich ihre Leidenschaft wiederentdecken und irgendwelche Kräfte darauf verschwenden, denjenigen, die sich tatsächlich engagieren wollen, in deren Tun dazwischen zu reden?

Das macht (bis zum Beweis der Richtigkeit solcher Vorbehalte, der aber erst mal eine Chance bräuchte (zum "Beweis" zu werden) und die kann es nur geben, wenn man es wenigstens versucht) für mich keinen Sinn - beim Freetz-Projekt gab es offenbar (auch wegen der Beharrungskräfte einiger und weil die Egos sich wohl immer überbieten mußten) mehr Probleme mit der "Zusammenarbeit", als mit der Materie, die so ein Projekt eigentlich vor die größeren Herausforderungen stellen sollte. Wenn jeder der "Macher" der Meinung ist, nur er wäre der- oder diejenige, der/die wüßte, wie man es richtig macht (weil er macht es ja "beruflich"), dann KANN das nichts werden - zumindest nicht ohne klar abgegrenzte Zuständigkeiten (habe ich auch weiter oben schon mal angerissen).

So ein FOSS-Projekt kann zwar sehr hohe Qualitätsstandards erfüllen (die vermutlich viele der "Macher" aus dem beruflichen Umfeld kennen und daher für den einzig denkbaren Weg halten), wenn es klare Regeln gibt (angefangen bei Style-Guides, an die sich alle zu halten haben), aber das muß es für eine funktionierende Software gar nicht zwangsweise ... allerdings verlangt das dann auch von allen Beteiligten, daß man sich auch zurücknehmen kann und anderen nicht den eigenen Stil aufs Auge drücken will, nur weil man selbst nichts anderes kennt und sich für den Nabel der Welt hält.

Da hilft es schon unheimlich, wenn man auch mal zurückstecken und anderen ihren "Erfolg" gönnen kann ... das war bisher (so jedenfalls meine Beobachtungen und - teilweise auch sehr unangenehmen - Erfahrungen) der größte Knackpunkt, wenn es darum ging, die "Mitstreiter" auch mal zu Wort kommen zu lassen und das als "gemeinsames Projekt", bei dem man sich auch zusammenraufen und eine gemeinsame Haltung "erarbeiten"(!) muß, zu verstehen.

Alle Ansätze oder Vorstöße in dieser Richtung (auch per E-Mail im direkten Kontakt oder über die ML) endeten immer bei einem "Ich mache das schon irgendwann mal (ich kann das nämlich gut/besser/am besten)." oder einem "Könnte ich ja mal machen, habe ich aber gar keine Zeit für." und ähnlichen "Ausreden" - mit dem Erfolg, daß sich in Wirklichkeit schon seit Jahren bei Freetz nichts Substantielles mehr getan hat - die letzten Anstrengungen zur Integration weiterer Plattformen (die aber am Ende auch auf den Vorarbeiten anderer beruhten bzw. von AVM "erzwungen" waren, weil aus der MIPS/MIPSEL-Monokultur auf einmal eine bunte Mischung verschiedener Plattformen wurde) mal ausdrücklich ausgenommen.

Nur kann/darf/sollte es jetzt eben auch nicht in das genaue Gegenteil umschlagen und nun kehrt nach einer Zeit der Autokratie bei diesem Projekt die absolute Anarchie ein - zumindest über die grobe Entwicklungsrichtung und das weitere Vorgehen sollten sich eben die Schreibberechtigten wenigstens einig sein und da macht mir dann Deine Einladung (bzw. Dein Aufruf hier) praktisch "an alle", schon auch ein paar Sorgen. Wenn ich bei jeder Änderung erst mal nachsehen muß, ob da nicht jemand mir irgendeine Backdoor unterjubeln will (womöglich noch jemand, den man bisher gar nicht kennt und wo ein "Maintainer" dann irgendwelche Änderungen unbesehen übernommen hat, weil er es selbst gar nicht geprüft hat bzw. das vielleicht (fachlich) gar nicht konnte), dann bin ich als "Einzelkämpfer" mit eigenem Fork am Ende wieder besser dran.

Das ist auch ein weiterer Grund für meine Zurückhaltung, mich jetzt mit wehenden Fahnen auf die Seite der Organisation "freetz-ng" zu schlagen - wenn es nicht wenigstens ein paar Regeln gibt (z.B. hinsichtlich der Pflicht zum Signieren von Commits, damit man den Urheber auch tatsächlich eindeutig identifizieren kann und nicht nur auf die "Behauptung" der Urheberschaft im Commit angewiesen ist (die könnte man "fälschen") - das ist aber auch nur ein Beispiel), dann bleibe ich auch lieber "für mich" und baue mir aus dem alten Freetz-Projekt etwas, was meinen Bedürfnissen (bei den Ambitionen, die ich mit YourFritz eigentlich verfolgen möchte) besser entspricht.
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Hab mal ne Umfrage dazugemacht.
Keine ahnung wie man signiert, kenn mich mit git(hub) nicht osnderlich aus. Da man ein Passwort braucht seh die da kein wirkliches Sicherheitsproblem
Richtig ist dass ich @alle aufgefordert habe sich zu beteiligen, Github-Einladungen gingen aber nur an die von denen ich weiss dass öfter mal "gute" Sachen kommen.
Ich hab nicht geschrieben dass man private Kommunikation verbieten soll, sondern dass das von öffentlichem Interesse auch öffentlich diskutiert werden sollte. Aktueller Stand ist dass nicht einmal Ergebnisse kommuniziert werden oder gar klar ist wer wofür zuständig ist
Wenn du dir die Freetz-Organisation ansiehst, sind da 3 Personen, die eine hat 2014 zuletzt was beigetragen, eine andere 2010. Tolle Aussichten.

EDIT: Pushen zwischen verschiedensten Forks ist kein Problem. 3 Tests auf GITHUB
Allerdings muss man cherry-picken, ein komplettes Merge verändert den Author!
Fun-fact: Kann man natürlich nicht verwenden, da die Datei auf den MIrrors fehlt :D
 
Zuletzt bearbeitet von einem Moderator:
Hab mal ne Umfrage dazugemacht.

Wo ich aufgrund der derzeitigen Auswahlmöglichkeiten leider nicht teilnehme. Weder "Lösch es wieder" noch "Finde ich prima" passt 100%. Aber es ist mir auch nicht egal und eine Meinung dazu habe ich ebenfalls. Die Option die ich vielleicht gewählt hätte (wenn es sie geben würde): "Abwarten, dann sehen wir weiter".

Auf jeden Fall begrüße ich es, dass jemand überhaupt den Schritt gewagt hat (egal ob am Ende was daraus wird oder auch nicht, das wird sich ja zeigen) anstatt nur (wie bspw. hier: https://www.ip-phone-forum.de/threa...llte-es-für-freetz-k-einen-fork-geben.300477/) nur darüber zu lamentieren anstatt zu machen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.