Freetz-NG

[PeterPawn]

Pushen zwischen verschiedensten Forks ist kein Problem.

Das ist klar ... ist aber das genaue Gegenteil von dem, was ein Pull-Request wäre.

Daß sich jeder selbst aus den verschiedenen angebotenen Forks dann seinen Stand im eigenen Repo zusammensetzen kann, hilft zwar den Ungeduldigen beim Adaptieren/Testen neuer Angebote und ist einer der Vorteile von Git/GitHub.

Wenn aber jemand sagt: "Das habe ich fertig und ich denke, es ist so weit, daß es auch andere verwenden können.", ist das eben etwas anderes, als wenn jemand anderer (möglichst auch noch aus einem "working branch", der keineswegs "final" sein soll, wie das z.B. bei mir mit https://github.com/PeterPawn/YourFritz/tree/eva der Fall wäre) etwas Unfertiges interessant findet und sich schon mal ansehen will.

Ich würde jedenfalls für einen Branch, den ich nicht selbst als PR vorgeschlagen habe, keine "Verantwortung" übernehmen wollen, wenn ein anderer damit Probleme hat, solange die nicht absolut offensichtlich und einleuchtend nichts damit zu tun haben, daß das eben noch "unfertig" ist.

Am Ende steht hier für mich die Frage, wer "die Verantwortung" für so einen Commit dann übernimmt, der irgendeine Entwicklung der Allgemeinheit verfügbar macht und damit "offiziell".

Ich hab nicht geschrieben dass man private Kommunikation verbieten soll, sondern dass das von öffentlichem Interesse auch öffentlich diskutiert

Bist Du sicher, daß Du tatsächlich das geschrieben hast ... und wenn ja, woher nimmst Du die Vermutung, ich würde "Angelegenheiten von öffentlichem Interesse" nur noch privat "besprechen" wollen, wenn ich doch explizit schreibe:

denn man muß nicht unbedingt alles öffentlich diskutieren

Ich denke nicht, daß ich bisher "aus meinem Herzen eine Mördergrube gemacht habe" ... und wenn Du für das "originale Freetz" jetzt auch nur feststellst:

Wenn du dir die Freetz-Organisation ansiehst [...] Tolle Aussichten.

, dann hast Du (bzw. hat man) trotzdem auch hier noch zwei Optionen.

Man kann einerseits versuchen, dort die Organisation "zu übernehmen" (im Sinne von "etwas beitragen", nicht primär im Sinne einer (eher feindlichen) Übernahme, obwohl auch das nicht ganz ausgeschlossen ist) und das mit der vorhandenen Infrastruktur fortführen und ggf. sogar verbessern.

Oder man macht den eigenen Laden als Konkurrenz auf der anderen Straßenseite auf und läßt die Leute mit den Füßen abstimmen. Daß diese Abstimmung halt zugunsten des preiswerteren oder "gefälliger geöffneten" Ladens ausgehen wird, ist zwar einigermaßen selbstverständlich, aber das, was die Kundschaft von einer Zusammenarbeit hätte (auf der einen Seite schmeckt das Essen besser und auf der anderen der Kaffee), kommt dabei komplett unter die Räder (und der neue Laden braucht erst mal jede Menge Investitionen). Bevor man eine solche Entscheidung trifft (die einem ja auch etwas später niemand wirklich verwehrt), sollte man (in meiner Welt) eben erst einmal den Kompromiß suchen und ausloten, ob es nicht gemeinsam am Ende doch besser ginge, als nebeneinander oder sogar - im Extremfall - gegeneinander.

Jetzt stellt sich für mich halt die Frage, für welche Option man sich (warum) entscheiden sollte ... das ist etwas, was für mich absolut noch nicht "abschließend" geklärt ist.

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

Wie oben schon mal geschrieben ... ich möchte nicht bei künftigen Problemen von Freetz-Benutzern erst mal lang und breit klären müssen, mit welchem Fork die nun auftreten (da Du das DEB schon angesprochen hast - das ist ja sicherlich nicht Dein Code für "Debian", sondern eher ein anderes Board mit bekannter Ausrichtung und "Nachnutzung" von Freetz) und ob da der Maintainer nun bloß den aktuellen Patch aus einem anderen Fork vergessen hat zu übernehmen oder woran das sonst noch liegen könnte.

Das ist nämlich auch in meinen Augen ein riesiges Problem des DEB - wer übernimmt eigentlich für die dort veröffentlichten Images die Verantwortung, daß sich darin eben kein trojanisches Pferd verbirgt (ich zeige gerne am praktischen Beispiel, daß man auf diesem Weg auch Software hinzufügen kann, die ein "normales Update" schadlos übersteht)?

Wie soll das künftig bei Freetz-NG dann aussehen - wird es da auch "fertige Images" geben (mal abgesehen vom Sinn, den das ergeben mag)?

Ich bin eigentlich nicht wirklich bereit (und schon gar nicht begeistert), wenn solche Software irgendwie "anonym" verbreitet wird bzw. werden kann - meine "Warnungen" in dieser Richtung sind sicherlich bekannt und auch wenn ich selbst (zumindest partiell) solche Software bereithalte für andere, dann eben auch immer in einer Form, mit der ich die Verantwortung dafür übernehme, daß da auch tatsächlich das drin ist, was drauf steht. Da würde ich garantiert meinerseits keine Hand rühren, wenn das am Ende dazu führt, daß die Sicherheit der Freetz-Benutzer (noch mehr) leidet. Es wäre ja reichlich schizophren, bei AVM-Firmware auf die Suche nach Sicherheitslücken zu gehen und gleichzeitig (aktiv) dabei zu unterstützen, daß Software mit ungesichertem Urheber (bzw. unklarem Ursprung) ihren Weg auf die Boxen der Freetz-Benutzer findet, bei der der Benutzer auch keine eigene Möglichkeit der Kontrolle mehr hat. Wer so etwas bereitstellen will, der soll dann gefälligst auch mit seiner elektronischen Unterschrift (aka Signatur in einem solchen Image) dafür gerade stehen.

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

Solange es EIN Freetz-Projekt gibt, bin ich auch bereit, anderen für dieses Projekt Hilfestellung zu leisten, so ich das kann und ein Problem noch nirgendwo zuvor schon gelöst wurde. Zerfasert das am Ende in 1 bis n verschiedene Forks, bin ich meinerseits raus und kümmere mich dann auch nur noch um meinen eigenen (der dann auch nicht mehr regelmäßig gegen irgendeinen anderen als "master" "rebased" wird, wie das bisher der Fall ist), mit dem ich dann YourFritz weiter bauen kann bzw. das, was da als Binärdateien bereitgestellt wird (die GPL ist ja mein Antrieb, da überhaupt Quellen für die von mir bereitgestellten Binaries "liefern" zu müssen).

Erst dann, wenn das "alte Projekt" sich neuen (und nochmal: gerne auch alten) Mitstreitern verweigern oder entziehen will (bzw. würde), gäbe es in meinen Augen einen plausiblen Anlaß, dann doch endlich mal einen Schlußstrich zu ziehen und komplett etwas "Eigenes" auf die Beine zu stellen.

 

[cuma]

[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Es ging bei dem pushen zwischen "children" darum, ob das überhaupt geht und wie. Ich übernehm nichts von anderen, das sollen diese selbst pushen. Hab die Teste von heute auch wieder gelöscht. Deshalb nannte ich sie "Tests"
Bei DEB ging es nicht um fertige Images, sondern um einen SVN Server. Keine Ahnung wie du darauf kommst. Für Freetz brauch ich wie gesagt kein GIT sondern war mit SVN zufrieden.
Und wie auch schon geschrieben, eine Übernahme/Beteiligung ist ausgeschlossen, ich hatte er13 öfter per PM geschrieben und nichts oder gleiches gehört. Ausserdem gibt es ja noch die einstimmige Aussage aller Entwickler. Deshalb hatte ich er13 in die Organisation eingeladen ;-)
Am besten nicht immer soviel hineininterpretieren was da nicht steht (Eigene Realität <> die von anderen)

@NDiIPP: Hab die Umfrage erweitert. Den verlinkten Post kann man nicht ernst nehmen. Das ist nur ne Aufforderung das irgendjemand was für ihn machen soll

 

[gismotro]

[...]Das ist nämlich auch in meinen Augen ein riesiges Problem des DEB - wer übernimmt eigentlich für die dort veröffentlichten Images die Verantwortung, daß sich darin eben kein trojanisches Pferd verbirgt (ich zeige gerne am praktischen Beispiel, daß man auf diesem Weg auch Software hinzufügen kann, die ein "normales Update" schadlos übersteht)?

[off Topic an]
Image auf dem Teamserver : Hierzu kann ich nur sagen das die Image die man auf dem Teamserver (hxxp://freetz.digital-eliteboard.com/index.html) findet, 1:1 mit dem aktuellen GIT (hxxps://github.com/freetz/freetz.git) gebaut werden und das das DEB schon sehr drauf achtet wer dort auf dem FTP seine Image ablegen darf.
Was sonst so im DEB oder in anderen Boards angeboten wird, entzieht sich natürlich unserer Kontrolle.
Hier denke ich ist es eine Sache der Ehre ob man helfen will oder ob man illegale Anteile in Fritzboxen einbauen möchte. Aber auch hier unterstelle ich Euch bzw. freetz.org ja auch nicht das man mit freetz.org Hintertüren in aktuelle Fritzboxen einbauen möchte. Somit sollten wir diese Diskussion hier gleich beenden.

SVN im DEB : Meine Idee war nur mal zu Prüfen ob es ggf. eine Hilfe wäre wenn man das DEB als Plattform für einen neuen SVN nutzen könnte. Dieses Idee habe ich bis dato noch nicht mit der Bordführung des DEB abgesprochen weil es bis dato nur ein Gedankenspiel zwischen mir und cuma war bzw. eigentlich nur eine Frage war, was er von einer solchen Idee halten würde, wenn es im IPPF für Freetz keine Zukunft gibt.
Ich für meinen Teil nutze gerne Freetz und habe damals auch viel Zeit in die Erstellung des Freetz-Wikis gesteckt da ich nicht programmieren kann. Das war damals mein persönlicher Anteil am Projektes auch wenn das im IPPF in letzter Zeit anders gesehen wurde. [Off Topic off]

 

[PeterPawn]

Hab die Teste von heute auch wieder gelöscht. Deshalb nannte ich sie "Tests"

Keine Ahnung, wie man aus dem vorherigen Text:

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

darauf schließen sollte, aber sei's drum. Dann habe ich eben (umsonst) noch mal den Unterschied zwischen "ich ziehe mir mal was von Dir" und "Das habe ich fertig, andere können es benutzen." verdeutlicht - ich kann aber anhand dessen, was Du da schreibst, nicht wirklich auseinanderhalten, was Deinerseits "nur Test" ist, um Dich mit den Möglichkeiten von "git" bzw. GitHub vertraut zu machen und was Du als "normale Arbeitsweise" etablieren möchtest. Schreibst Du das deutlich hin (die drei Zeilen oben fallen m.E. nicht in die Kategorie "deutlich"), gibt es vielleicht weniger Mißverständnisse.

Keine Ahnung wie du darauf kommst.

Das war ja deutlich eine Frage und daß es bei DEB auch "fertige Images" mit einigen Zusätzen gibt, dürfte für Dich nicht wirklich neu sein.

Wenn ich das richtig "interpretiere" (vor einer definitiven und unmißverständlichen Aussage drückst Du Dich hier in meinen Augen ja), willst Du also unbedingt den eigenen Fork betreiben?

Sollte das so sein und es tut sich im originalen Projekt nichts, denke ich ggf. auch noch mal übers Forken nach (ob dann als Mitstreiter bei Deinem Angebot oder tatsächlich in einem eigenen, hängt u.a. auch von ein paar "Grundpositionen" ab, die Du eben mit dem Erwähnen von DEB (einen SVN-Server kann man ja nun überall aufsetzen und wenn Du Dich an DEB hängst, ist das für mich definitiv keine Option - die hast auch Du selbst - ohne Not - aufs Tapet gebracht und niemand anderes) für mich wieder in Nebel gehüllt hast.

Ich hatte Dir eigentlich auch nur auf Deine Frage(? - zumindest hatte ich es so verstanden) geantwortet, ob ich die Einladung erhalten habe und die damit für mich verbundene (unterschwellige) Frage, warum ich sie bisher nicht angenommen habe.

Ich hatte auch in der Vergangenheit meine Auseinandersetzungen mit @er13 (und auch mit @kriegaex), aber ich bin auch nicht so der Typ für "schlimm gekränkte Eitelkeiten", daß ich keinen Weg mehr sähe, das originale Projekt am Leben zu erhalten - man kann ja auch einzelne Leute einfach ignorieren.

Wenn Du das anders siehst (auch @hippie2000 war ja strikt gegen den Umzug zu GitHub, er wollte lieber zu GitLab ziehen oder sogar tatsächlich die alte Infrastruktur weiter betreiben, so man ihm dafür die (Hardware-)Ressourcen zur Verfügung stellt), kann ich es nicht ändern ... warum ich (zumindest im Moment, was die Zukunft bringen wird, kann ich nicht sagen) dem Ganzen (als Freetz-NG) eher skeptisch gegenüber stehe, habe ich versucht zu vermitteln. Das KANN man vielleicht verstehen, man MUSS aber meine Position selbstverständlich nicht teilen.

Ich halte mich dann hier einfach wieder raus ... wenn Dein Vorhaben, das Projekt zu forken und keinesfalls in der alten Infrastruktur weiter zu machen, so weit feststeht, wie es jetzt zum Ausdruck gekommen ist:

Und wie auch schon geschrieben, eine Übernahme/Beteiligung ist ausgeschlossen, ich hatte er13 öfter per PM geschrieben und nichts oder gleiches gehört. Ausserdem gibt es ja noch die einstimmige Aussage aller Entwickler.

(wobei auch das irgendwie von der Zeitform her nicht stimmt, außer Dein "ich hatte ... öfter per PM geschrieben" bezieht sich auch auf die Zeit "nach dem Umzug zu GitHub" (denn da ergab sich ja erst die derzeitige Situation, als auch noch @Whoopie ausstieg) und was nun die von Dir angetextete "einstimmige Aussage aller Entwickler" inhaltlich war und von wann diese stammte, muß man auch wieder "raten"), dann mußt Du das eben genau so auch machen - ich werde Dir da aber nicht sofort folgen, zumindest nicht ohne Versuche, das auf der Basis des "alten Freetz" mit neuen handelnden Personen vielleicht doch noch einmal mit Leben zu erfüllen.

@gismotro:
Das glaube ich Dir sogar ... nur erklärt das für mich eben immer noch nicht, warum es dort keine Diskussionen gerade zu diesem "Sicherheitsaspekt" gibt. Die Werkzeuge, um die eigenen Images so zu signieren, daß man zumindest bei der Installation über das GUI (und mit anderen Tools auch vor einer Installation über den Bootloader) auch sicher sein kann, daß diese Images von dem stammen, der sie angeblich bereitgestellt hat (und nun sage mir nicht, daß die Zugriffsrechte beim DEB 100% sicher sind, sonst fühle ich mich noch herausgefordert, das Gegenteil unter Beweis zu stellen - das DEB wäre nicht das erste und vermutlich auch nicht das letzte Board, dem die Zugangsdaten der Nutzer abhanden kommen, ohne daß es jemand bemerkt), existieren jetzt schon seit mehr als zwei Jahren - man kann ja mal "grob" abzählen, wieviele Images seitdem schon über das DEB bereitgestellt wurden, die aber trotzdem nicht signiert waren.

So eine digitale Signatur ist eben auch eine "Unterschrift", daß man "persönlich" dafür gerade steht, was in der Software enthalten ist und nicht nur "daß man darauf geachtet hat, wer da schreiben darf". Nach meiner Erfahrung (und eben nicht nur nach meiner eigenen, such einfach mal nach entsprechenden Stories im Netz) ist es i.d.R. sogar so, daß die Zugangsdaten gerade der Leute, die es eigentlich besser wissen müßten, immer noch am leichtesten "zu knacken" sind und obendrein auch häufig genug mehrfach verwendet werden.

Eine elektronische Signatur ersetzen eben auch die besten "gut weggepackten" Zugangsdaten zum FTP-Server nicht (keine Ahnung, ob der FTP-Server dort wenigstens mit 2FA beim Schreiben arbeitet - aber auch das sichert ja den Transportweg zum Interessenten dann noch nicht ab und KANN damit gar nicht sicherstellen, daß beim Benutzer auch 1:1 die Datei ankam, die er haben wollte bzw. die ein anderer (dem er vertraut) ihm bereitstellen wollte) und wenn sich jemand mit einem ähnlich geschriebenen Servernamen für den FTP-Server ausgibt und das entsprechend im DEB verlinkt, fällt das garantiert auch nur den alleraufmerksamsten Beobachtern auf. Und das "ein wenig Zwielichtige" des DEB an sich fällt sicherlich auch nicht nur mir auf ... selbst wenn ich mich genauso wie jeder andere (ich habe eine Vu+ Ultimo) für CS und weitere dort behandelte Themen interessiert habe (zumindest in der Vergangenheit).

Für mich gibt es eben gute Gründe, mich aus solchen Boards herauszuhalten und daher wäre ein "Umzug" des Freetz-Projekts auf eine Ressource des DEB ein Schritt (den hat ja auch @cuma als Option ins Spiel gebracht), bei dem für mich eine Grenze überschritten würde, die ich selbst nicht bereit bin einzureißen. Muß man auch nicht verstehen ... hat etwas mit Prinzipien zu tun. Nicht umsonst befasse ich mich auch so viel mit Lizenzbestimmungen und ihren Folgen ... und die Weitergabe einer veränderten AVM-Firmware ist eben (bei allen Rechten, die durch die GPLv2, GPLv3 und LGPL eingeräumt werden) in meinen Augen immer noch ein Copyright-Verstoß - da beißt die Maus keinen Faden ab und ich habe bisher auch noch keinen "Argumentationsversuch" gesehen, der das wenigstens versucht hätte zu "verharmlosen". Hier lebt das DEB irgendwie davon, daß es der Ansicht ist, nicht dem deutschen Urheberrecht zu unterliegen bzw. die Leute dort gehen vermutlich davon aus, daß sie ohnehin "nicht zu fassen" wären.

 

[cuma]

[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Du schreibst immer Romane...!
Steht doch da dass man es "nicht verwenden" kann. Außerdem war der "Test" im Fork meines Account, und nicht in Freetz-NG
Was es im DEB alles gibt weiss ich nicht vollumfänglich. Frag meine Oma und die wird dir sagen dass "im Internet" nur "Betrüger und Gauner" sind. Wenn da jemand Images anbietet werd ich sie nicht benutzen da ich mir liebr selbst was zusammenpatche ;-)
Dass ich das IPPF nicht so berauschen finde kommt aus der Zeit bevor Andreas es and 3CX verkaufte, damals war hier noch so mancher berüchtigte zensur-ban-Moderatoren unterwegs. Scheint sich gelegt zu haben. Und falls es hier keine Resonanz gibt, hab wie gesagt keine Lust allein was zu machen, gäbe es keinen Grund hier zu bleiben und hätte ich kein Problem mit einem Wechsel zum DEB. Da sind immerhin auch ein paar Freetz-Benutzer. Bis jetzt gibts aber nur die Idee von Gismotro.
Dass ich keinen Weg sehe das "original" am Leben zu erhalten liegt wie gesagt nicht an mir, schrieb ich ja schon (mehrfach). Um die Frage zu Beantworten: Die PMs schrieb ich im laufe der letzten Jahre! Grundsätzlich fänd ich es gut wenn er13 sich weiter im die Toolchain kümmert wie bisher, ist aber nicht von seiner Seite aus. Daher brauch ich mir über diese Option keine Gedanken zu machen
Aber wenn du unbedingt vermitteln willst: Hab keine Lust wenn da welche mit Adminrechten sind die eh nichts machen, Heimi ist/war glaub ich eh nur ein Arbeitskollege vom oli oder irgendwie sowas Ich würde als Admin annehmen ralf und/oder alex (auch wenn sie sonst nichts machen). Von denen weiss ich dass die keinen Unsinn veranstalten

 

[PeterPawn]

Wie gesagt ... das hat sich dann auch für mich erledigt, weil ich das als deutliche Absage Deinerseits verstehe (nun aber hoffentlich richtig), mit den alten Ressourcen einen Neustart zu versuchen, weil da dann weiterhin ein paar Leute dabei wären (und ggf. als Admin für die Organisation eingetragen wären), mit denen Du nicht klar kommst.

Auch wenn ich immer "Romane" schreibe, sind das wenigstens vollständige Sätze und nicht nur "Andeutungen" in Halbsätzen (Beispiel für so etwas: siehe oben) - und daß Du das Original in keinem Falle als Alternative akzeptieren würdest, hast Du (zumindest nach meinem Verständnis, denn ich finde vor #24 keine definitive Aussage in dieser Richtung) eben bisher noch nicht so klar zu erkennen gegeben.

Mir ist es auch ziemlich gleich, wer Dir hier schon alles "etwas Böses" angetan hat (auch ich hatte meine Zusammenstöße mit aktuellen und ehemaligen Moderatoren) - entweder man schafft es, das dann auch mal als "vergangen" abzuhaken oder man ignoriert diese Leute eben nach Kräften. Deshalb jetzt des IPPF oder auch die alte "Freetz-Organisation" auf GitHub "irgendwie abzulehnen", ist eine Entscheidung, die Du für Dich offenbar final getroffen hast, die man aber nicht unbedingt nachvollziehen muß.

Zusammengefaßt habe ich Dich jetzt so verstanden:

• Du wirst in jedem Falle mit einem eigenen Fork weitermachen.
• Sollte Dir die Resonanz auf diese Idee hier im IPPF nicht ausreichen, würdest Du mit dieser Idee ins DEB wechseln, wenn man Dich dort "haben will".
• Am alten Freetz würdest Du nur dann wieder mitarbeiten wollen, wenn einer von zwei Dir genehmen Personen (@hippie2000 oder @kriegaex) da die Administration übernehmen würde (die beide schon recht lange nichts mehr wirklich gemacht haben - wobei ich die letzten Bemühungen von @kriegaex um die Änderungen im Wiki jetzt nicht ignorieren will, aber das war wohl auch eher "Langeweile", die sich zeitnah wieder gegeben hat), weil alle anderen Dir in der Vergangenheit mal "etwas getan haben" (vermutlich war das dann diese ominöse "einstimmige Aussage aller Entwickler" - wobei da dann ja @hippie2000 und @kriegaex auch bei so einem "Rundumschlag" dabei gewesen sein müßten, wenn es "einstimmig" und "alle Entwickler" waren).
• Diese Weigerung, in einem neuen Team am Freetz in der alten Infrastruktur mitzuarbeiten, liegt aber auch nicht an Dir - Du hast gar keine andere Chance, als Deinen eigenen Fork aufzumachen.

Ist irgendetwas davon falsch zusammengefaßt? Wie gesagt ... mir scheinen hier die Egos der Beteiligten deutlich mehr eine Rolle zu spielen, als objektive Probleme, die eine Zusammenarbeit in jedem Falle verhindern würden.

Ich fände es nur eher schwach, wenn man @er13 mit dem "Selbstbild" des Autokraten jetzt im Nachhinein noch dadurch legitimiert, daß man nach seinem (bisher ja nur vermuteten) Ausscheiden nun alles beim "alten Freetz" sang- und klanglos in sich zusammenbrechen läßt - das würde ja schon irgendwie zeigen, daß es ohne ihn und seine "zentrale Rolle" eben doch nicht funktioniert und würde alle bisherige Kritik, daß es eben gerade wegen dieser Einstellung und dem daraus abgeleiteten Verhalten nur so wenige Mitstreiter gab, im Nachhinein noch ad absurdum führen.

Ich hatte gute Gründe, warum ich MIT ihm nicht arbeiten wollte (und konnte) ... wenn er sich jetzt tatsächlich ausgeklinkt hat, sollten sich aber zumindest seine Kritiker soweit versuchen zusammenzuraufen, daß sie wenigstens den Versuch unternehmen, es (ohne ihn) besser zu machen.

Wenn sich auch dafür keine Mitstreiter finden lassen (und Du hättest eben jetzt die Chance dazu), dann kann man dem Projekt ohnehin nicht mehr helfen und dann kann ich meine eigene Zeit, die ich mit Freetz-basierten Problemen und Themen verbringe, auch für eigene Ziele deutlich besser nutzen.

 

[Master SaMMy]

freetz@debian-freetz:~/freetz-ng$ make menuconfig
Cannot open include file make/ppp/external.in in make/external.in.generated
No such file or directory at tools/parse-config line 22, <$fh> line 108.
Cannot open include file make/ppp/external.in in make/external.in.generated
No such file or directory at tools/parse-config line 22, <$fh> line 108.
Makefile:440: die Regel für Ziel „config/.cache.in“ scheiterte
make: *** [config/.cache.in] Fehler 2
freetz@debian-freetz:~/freetz-ng$


denn fehler bekomme ich seit denn ich ein update gemacht habe
git pull

 

[gismotro]

kann ich bestätigen :

freetz@Freetz-Serever:~/74$ make
Cannot open include file make/ppp/external.in in make/external.in.generated
No such file or directory at tools/parse-config line 22, <$fh> line 108.
Cannot open include file make/ppp/external.in in make/external.in.generated
No such file or directory at tools/parse-config line 22, <$fh> line 108.
Makefile:440: recipe for target 'config/.cache.in' failed
make: *** [config/.cache.in] Error 2
freetz@Freetz-Serever:~/74$

unter git clone https://github.com/freetz/freetz.git gibt es den Fehler nicht

 

[gnieder]

...ich muss hier jetzt def. in die Kerbe von cuma schlagen!

Gibt es einen einfachen Weg, auf einen älteren commit zurück zu gehen, wenn gerade mal ein Poblemen auftritt,
(für Leute wie mich, die wirklich nicht unbeholfen im Linux unterwegs sind, aber eben doch keine Programmierer sind,
die im git-hub leben) um ähnlich schnell und einfach, wie mit SVN, auf eine ältere Revision zurück zu kommen, wo es noch läuft?

Alleine das Auffinden des passenden commit im git, ging über das Journal im SVN für meinen Geschmack um Längen einfacher.

Ich glaube durchaus, dass es viele User gibt (und ich rede jetzt nicht von den "ganz einfachen" Usern), die es bedauern, dass es kein
SVN von freetz mehr gibt.

Ich glaube es ja, dass git mit seinen unzähligen Möglichkeiten, optimal für Programmierer ist, die das einfach aus dem Handgelenk
heraus, alles nutzen können und vermutlich auch tun.

Aber die Zielgruppe von freetz, so wie ich sie seit DS Zeiten kenne, sind ja doch die "etwas fortgeschritteneren Enduser" und nicht
nur die Devs alleine. Oder ist das inzwischen nicht mehr so?

Ich jedenfalls und ich weiß alleine in meinem näheren Umfeld noch einige mehr, die sich wünschten,
es gäbe noch ein übersichtliches SVN von freetz!

 

[PeterPawn]

Jeder Stand im "git" (GitHub als Oberfläche spielt dabei gar keine Rolle) hat eine eindeutige Kennzeichnung in Form eines SHA-Wertes.

Diesen kann man jederzeit mit einem "git reset --hard <hash>" wiederherstellen.

Wieso das "Auffinden" eines solchen (Aus) Aufsetzpunktes innerhalb einer Liste der Commits (die man im GitHub sehen kann (Beispiel: https://github.com/PeterPawn/freetz/commits/YourFritz) oder sich mit "git log" anzeigen läßt) jetzt anders aussehen sollte, nur weil die Commits nicht mehr "durchnummeriert" sind (warum das sinnvoll ist, habe ich an anderer Stelle versucht zu erklären - bei wirklich verteilter Programmierung kann es nämlich keine sequentiellen Commits geben und somit würden sich die Kennzeichnungen der Commits in den dezentralen und im zentralen Repository dann unterscheiden - ein Durcheinander, bei dem am Ende niemand mehr durchblicken kann/würde), müßte mir mal jemand erklären.

Auch bei SVN-Nutzung muß ich (wenn ich ein Rollback machen will) immer noch wissen, bis zu welchem Punkt ich zurück muß oder will - das Einzige, was sich daran bei der Benutzung von "git" ändert, ist die Art der "Nummerierung". Im GitHub hat man zusätzlich noch die Chance, das mit einem "verkürzten" SHA-Wert zu verbinden ... das ist der rechte der beiden Werte in dieser Liste:


Gerade der geringere Aufwand beim Integrieren von unabhängigen, verteilten Entwicklungen (die eben von mehreren Leuten kommen können) ist es ja, der überhaupt zur Entwicklung von "git" (als OpenSource-Nachfolger einer Software, die deren Autoren anfangs für die Linux-Kernel-Entwicklung kostenfrei lizensierten und wo sie nachträglich die Lizenzbestimmungen dann änderten) geführt hat.

Und mal noch eine Frage an die "fortgeschrittenen End-Nutzer" (Hr. Waalkes hat diese mal als "runaways" bezeichnet) ... seid ihr tatsächlich der Überzeugung, daß die vielen anderen Projekte, die inzwischen "git" für ihre Verwaltung verwenden (dabei lasse ich mal dahingestellt, ob das bei GitHub, GitLab oder gar self-hosted erfolgt), alle keine Ahnung haben bzw. daß deren Benutzer vor unüberwindbaren Hürden stehen, weil die dortigen Verantwortlichen sich gar nicht darum scheren, wie ihre "Zielgruppe" damit zurechtkommt?

Ich sehe hier eher ein "Beharrungsvermögen" auch bei den Benutzern ("Das haben wir schon immer so gemacht.") ... und vielleicht auch bei den Programmierern, denn man kann eben auch in "git" einen definierten Stand mit einem "tag" versehen - dann wird der z.B. so aussehen und für "End-Nutzer" entsprechend leicht auffindbar sein: https://github.com/PeterPawn/freetz/releases/tag/v0.1

Die "Unsitte", daß die "End-Nutzer" anstelle von definierten und getesteten Ständen immer mit dem "trunk" (der eben ursprünglich die Entwicklerversion sein sollte) arbeiten (sollen), hat nämlich auch mit einer sinnvollen Versionsverwaltung nur noch sehr wenig zu tun und ist bei Freetz auch nur das Ergebnis der Tatsache, daß es seit Jahren keinen "definierten Stand" als Release mehr gab.

Aber die Zielgruppe von freetz, so wie ich sie seit DS Zeiten kenne, sind ja doch die "etwas fortgeschritteneren Enduser" und nicht
nur die Devs alleine. Oder ist das inzwischen nicht mehr so?

Es ist eben schon ein erheblicher Widerspruch, wenn sich jemand selbst nur als "fortgeschrittenen End-Nutzer" sehen will (der einen entsprechenden "Komfortanspruch" hat) und parallel dazu will (bzw. muß) er aber mit einem Software-Stand arbeiten, für dessen (unfallfreie) Benutzung er eine andere Qualifikation (nämlich die des Entwicklers) bräuchte.

Da wäre es in meinen Augen eben "schlauer", wenn man sich für eine "Position" in der "Nahrungskette" eines solchen Projektes entscheidet - und sich ansonsten dafür "stark macht", daß es eben nicht für jede neue Labor-Version von AVM auch einen neuen Software-Stand im Projekt geben muß, solange es nicht andere Gründe als eine geänderte URL und einen geänderten Hash-Wert des originalen Firmware-Images gibt.

Im "Normalfall" sollte nämlich ein "fortgeschrittener End-Nutzer" gar nicht in die Verlegenheit kommen (zumindest nicht regelmäßig), wegen eines nicht funktionierenden Software-Standes auf einen früheren Checkpoint zurück zu müssen ... und schon stellt sich das Problem aus #29 nicht mehr.

Das SVN und seine Arbeitsweise ist eben auch nicht unbedingt für eine gemeinsame und verteilte Arbeit an einem Projekt geeignet (wie das bei einem FOSS-Projekt wohl unumgänglich ist) und eher für eine "zentralisierte Verwaltung" innerhalb einer Organisation gedacht. Damit gibt auch diese Software in gewisser Weise eine "Organisationsstruktur" vor (wenn die auch nicht so aussehen muß, wie das bei Freetz bisher der Fall war) und diese paßt eben nicht zu solchen Projekten, wo mehr als ein Entwickler sich aktiv beteiligen will (oder soll). Da muß man dann auch mal als "fortgeschrittener End-Nutzer" die Kröte schlucken und "umdenken" oder man beharrt auf den alten Strukturen - damit kriegt man aber auch die alten Abläufe, mal ganz abgesehen von den anderen Problemen wie "reliability" und allem, was ansonsten noch mit dem Betrieb einer eigenen Infrastruktur zusammenhängt.

Offenbar sind hier die "down-times" des SVN-Repos (bzw. des Trac-Servers) aus der jüngeren Vergangenheit schon komplett in Vergessenheit geraten - wer das wieder so haben will, der muß sich dann tatsächlich dafür stark machen, daß der "Rückschritt" (in meinen Augen ist es einer) zu Subversion wieder vollzogen wird.

Ob man das dann auf der eigenen Infrastruktur macht (auch so etwas will eben "gewartet" werden, was "End-Nutzer" auch nur allzu gerne vergessen bzw. wo sie i.d.R. keine Vorstellung davon haben, was zur Administration einer sicheren(!) Plattform alles gehört und daß auch diese mit "Arbeit" verbunden ist) oder einen der vielen(?) Anbieter von (kostenfreien?) Subversion-Repositories im Internet benutzt (da fällt dann der eigene Administrationsaufwand eben nicht an), ist erst die zweite Frage nach einer solchen "grundlegenden" Entscheidung.

Es gibt (und gab) - zumindest in meinen Augen und da verliere ich die "Benutzer" eher nicht aus den Augen - soviele Argumente für eine Umstellung von Subversion auf "git", daß diese schon seit Jahren vollzogen sein müßte und die Tatsache, daß es so lange gebraucht hat, ist auch eher dem "Beharrungsvermögen" der handelnden Personen zuzuschreiben und dem Umstand, daß es (nach ein paar Unregelmäßigkeiten) immer mal wieder noch eine Zeitlang lief (wenn auch "mit Ansage", daß das nicht mehr lange so sein würde - trotzdem kam der Umstieg auf "git" nicht in die Gänge, bis der Server dann endgültig weg war) ... wer sich diese "Historie" noch einmal in Erinnerung rufen will (vielleicht ändert er ja dann seine Meinung doch noch), braucht nur mal hier im IPPF etwas zu suchen.

Ich hatte vor 1 1/2 Jahren mal den Versuch gestartet, Pull-Requests per GitHub als reguläre Alternative zu irgendwelchen irrlichternden Patch-Files in einem Trac-Ticket zu etablieren: https://github.com/Freetz/freetz/pull/11 (einen Mechanismus analog zu den "pull requests" stellt nämlich "trac" (bzw. "svn") m.W.(!) auch nicht zur Verfügung) ... ich empfehle den "Kritikern" von "git", die lieber bei Subversion bleiben woll(t)en einfach mal, sich im Internet etwas umzuschauen und sich den Überblick zu verschaffen, welche (heute noch aktiv weiterentwickelten) (FOSS-)Projekte mit mehreren Developern weiterhin mit einem Subversion-Repository arbeiten.

Wer dann immer noch behaupten will, daß sich all die Projekte, die den Umstieg auf "git" ebenfalls vollzogen haben, genauso auf einem "Irrweg" befinden, muß eben die Initiative ergreifen und das Ganze erneut auf SVN-Basis aufziehen - ob man dann Trac oder eine andere Oberfläche verwendet (das ist nämlich das nächste Problem, daß "End-Nutzer" häufig beides synonym sehen und keine Ahnung haben, daß man Trac auch auf einem "git"-Repo betreiben kann), ist am Ende auch egal. Fakt ist (und bleibt), daß auch diese Installation jemanden braucht, der (a) die dafür benötigten Ressourcen bereitstellt (ein "ganz kleiner" virtueller Server wird vermutlich eher nicht reichen) und (b) auch dabei sich jemand um die Administration kümmern muß (bis hin zum DSGVO-gerechten Verhalten, wenn man dabei E-Mail-Adressen speichert, was bei einen "non-open system" (das ansonsten aber schlicht zugespammt wird) auch einigermaßen unumgänglich ist), was man (zumindest als Laie) auch nicht "mal nebenbei" erledigen kann.

 

[gismotro]

Mir persönlich ist es egal wo Ihr freetz weiter entwickelt. Ich für meinen Teil hätte nur gerne eine Info bzw. eine Möglichkeit zu erkennen wann sich was am "Freetz-Git" geändert hat bzw. eine Möglichkeit zu erkennen welche Firmware für welche Box aktuell genutzt werden kann.

1.) Dieser Link wurde mir mal als Ersatz für die alte timeline genannt : https://github.com/Freetz/freetz/commits/master Ist das noch aktuell oder wo muß man schauen ?

2.) Ist das hier die aktuelle Liste der von Freetz-GIT unterstützten Boxen : https://github.com/Freetz/freetz/blob/master/FIRMWARES ?

 

[PeterPawn]

Ist das noch aktuell oder wo muß man schauen ?

JEDES Git-Repository hat auf GitHub diese Möglichkeit der "Ansicht".

Wenn Du über Änderungen eines Repos auf dem Laufenden gehalten werden möchtest, legst Du Dir einen eigenen Account zu (man muß dazu keine anderen Repositories forken und es gibt dort auch keine Klarnamen-Pflicht - wer eine "anonyme" E-Mail-Adresse verwendet (z.B. von posteo.de), ist also auch für GitHub (Vorsicht: Microsoft hat GitHub gekauft ... böse Falle - nur hängt bei GitLab sogar ganz offiziell die Google-Mutter Alphabet über die Finanzierung mit drin und nun kann jeder selbst entscheiden, vor wem er "mehr Angst" hat oder haben sollte) nicht ohne weiteres als "Person" zu identifizieren.

Mit diesem eigenen Account geht man dann im "zu überwachenden Repository" auf den Button "Watch" oben in der Webseite und kann sich dann aussuchen, welche "Neuigkeiten" für dieses Repository man per E-Mail erhalten möchte.

 

[cuma]

[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Das gemeldete Problem liegt am caching! Tritt bei einem neuen "clone" nicht auf, nur bei "pull". Freetz packt alle ".in" Dateien in 1 damit nach dem 1. menuconfig Aufruf jeder nächste schneller geht. In Zeiten von SSDs eigentlich überflüssig
Deshalb den Cache leeren mit:

 rm make/*.in.generated config/.cache.in

Ich finde die Übersicht bei GitHub auch nicht toll und hab mir ein Trac installiert. Sind verschieden Repos unter 1 Oberfläche. Läuft auf einem 5 Watt Computer ohne reverse-proxy und ist somit nur für 1 Benutzer brauchbar. Könnte man natürlich theoretisch auch auf freetz.org packen


@gismotro: deine Links stimmen soweit. Die entsprechenden für freetz-ng hatte ich gestern im 1. Post ergänzt
@PeterPawn: Deine 3 Seiten lese ich später

 

[PeterPawn]

Nun (nachdem man mal sieht, wie "Trac" auf einem "git"-Repo dann aussieht und das jeder selbst "vergleichen" kann), bin ich erst recht gespannt auf die Erklärung, worin genau sich die Trac-Ansicht der Commits von der in GitHub unterscheidet und was daran "besser" oder "schlechter" sein soll. Das müßten (in meinen Augen) schon gewaltige Vorteile sein, damit sich der Betrieb des zusätzlichen Servers (Trac braucht einen HTTP-Server und eine Datenbank) irgendwie lohnt.

EDIT:

Deine 3 Seiten lese ich später

Nicht nötig ... ich bin ohnehin raus. Ich drücke Dir die Daumen, daß Du genug Mitstreiter für Dein Vorhaben findest, aber ich werde definitiv nicht dazugehören.

So, wie ich das im Moment verfolge, machst Du nichts anderes, als es @er13 machte - nur halt jetzt im eigenen Repo mit eigener Organisation.

Beispiel gefällig?

Bei diesem Commit: https://github.com/freetz-ng/freetz-ng/commit/8dd67af44d8b46fbed3d2cea470969029755590f weißt wieder nur Du, was Du Dir dabei gedacht hast oder wofür bzw. wogegen der nun gut sein soll.

Alle anderen, die das lesen, müssen raten, warum diese Änderung wohl notwendig sein sollte und was damit am Ende bezweckt wird bzw. welches Problem (wo gemeldet?) damit behoben sein soll.

Das KANN nicht funktionieren, wenn man mit anderen zusammenarbeiten will ... und wenn das "der Stil" der früheren Commits gewesen sein sollte bzw. häufiger vorkam (ich will jetzt auch nicht in der Vergangenheit wühlen, falls man die überhaupt noch sehen könnte), würde ich auch wieder eine "gemeinsame Reaktion" der anderen Developer in der Vergangenheit verstehen.

Aber das entscheidest Du, wie Du das künftig in diesem Fork handhaben möchtest ... nimm das einfach als "Einwurf von der Seitenlinie" von mir und nicht als "Beschwerde" (zu der ich kein Recht habe - und auch keines haben will).

PPS:
Und vielen wird es vermutlich nicht auffallen, aber mit dem "Neuaufsetzen" des Repos als "nicht-Fork" im GitHub hast Du ja (ich unterstelle mal absichtlich) auch alle Brücken zum alten Projekt abgebrochen und jeden mit einem eigenen Freetz-Fork der Möglichkeit beraubt, mit dem Mitteln der GitHub-Oberfläche einen Pull-Request für Dein neues Repository zu erstellen, solange sein eigenes Repository nicht ebenfalls ein Klon von Deinem eigenen ist. Das ist auch definitiv "neu", denn als ich das weiter vorne in diesem Thread ausprobiert habe, war Dein Repo noch ein "echter" Fork (im SCM-Sinne) von "Freetz/freetz" und das ist es jetzt nicht mehr.

 

[cuma]

[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Auch gut, erspart mit viel Zeit. Wäre vermutlich auf eine Wiederholung von Post 1 hinausgelaufen. Dort steht was der aktuell Stand ist und wie ich hoffe dass es weitergeht..
Meiner Meinung nach hätten auch Sachen von dir wie Erweiterung von push_firmware für neue Boxen schon längst in den Trunk gehört, aber sei es d'rum
Der genannte commit bezieht sich auf r13500, in dessen Kommentar steht das entsprechende Ticket. Hab mir aber erspart das anzugeben da es eh keine Tickets und Revisionen mehr gibt, und nicht mehr öffentlich nachzulesen ist
Pullrequests sind kein Problem, siehe meine "Tests" über die du dich auch schon aufgeregt hast. Origins anpassen und gut

 

[PeterPawn]

Pullrequests sind kein Problem, siehe meine "Tests" über die du dich auch schon aufgeregt hast.

Ich habe mich nicht "aufgeregt", ich habe den Unterschied zwischen einem Pull-Request (dessen Autor übernimmt die Verantwortung) und einer (heimlichen) Code-Übernahme durch den Eigner des Repo (dann übernimmt der die Verantwortung und der ursprüngliche Autor kriegt das nicht einmal mit, daß da jemand seinen Code in ein fremdes Repo kopiert hat) versucht zu erklären.

Das eine ist eine "freiwillige Preisgabe" des Codes und das andere ist eine "Übernahme" (die auch nur funktioniert, solange das Source-Repo "public" ist) und dabei werden dann hoffentlich auch die jeweiligen Lizenzbestimmungen berücksichtigt (denn dafür ist dann derjenige verantwortlich, der den Code übernimmt).

Das Ganze hat dann natürlich auch Auswirkungen darauf, wie bzw. wen der ursprüngliche Autor bei Änderungen an seinem Code benachrichtigt - die "Arbeit", die ganzen Quell-Repos zu überwachen, aus denen man sich sein eigenes Repo zusammenkopiert hat, muß dann ja auch wieder jemand übernehmen.

Origins anpassen und gut

Das solltest Du dann vielleicht mal etwas genauer "erläutern" und nicht nur in Deinen (unverständlichen) Halbsätzen. Dabei solltest Du - sofern Du andere zur "Mitarbeit" anstiften möchtest - vielleicht auch den Aspekt im Auge behalten, daß nicht jeder Dir sofort "mit Haut und Haaren" zu Deinem neuen Projekt folgen wird (vermutlich jedenfalls) und das dann schon so funktionieren sollte (bisher machte es das, solange "freetz-ng" noch ein (GitHub-)Fork war), daß man (und zwar ohne größere Kopfstände) auch mit dem "alten Projekt" die Änderungen austauschen kann.

 

[cuma]

[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Erfinde doch nicht irgendwas und unterstell mir dies dann. Habe bereits auf das "aneignen von commits" geantwortet.
Ich denke du weisst besser wie man mit git arbeitet, hab da wenig Erfahrung. Die die unbedingt von SVN auf GIT wechseln wollten sollten es den Anfängern erklären ;-) Jedenfalls solange der Wunsch nach GIT nicht auf "will ich, ist geiler" beruht.
Außerdem bist du doch eh "raus". Damit ist es doch überflüssig dass du das weisst. Falls jemand ernsthaft Interesse hat ist das was anderes.
Du erfandest doch ein Konstrukt wie, dass der Code nur dafür da wäre um ein Image zu bauen und dann zu veröffentlichen.

 

[PeterPawn]

Du erfandest doch ein Konstrukt wie, dass der Code nur dafür da wäre um ein Image zu bauen und dann zu veröffentlichen.

Du solltest den Aluhut mal absetzen ... ich habe ja nun schon deutlich erklärt, daß das meine Reaktion auf Deine Absichten war, mit Deinem "neuen Freetz" nach DEB umziehen zu wollen.

Wenn Du nicht verstehst (oder nicht sehen willst), daß das der Todesstoß für Freetz im Hinblick auf künftige "Erwähnungen" in der "deutschen Presselandschaft" (bis hin zu den Bloggern, die wissen, wie weit sie gehen dürfen) wäre, dann kann man Dir eben auch nicht helfen. Ich gehe mal davon aus, daß Du das Urteil des EuGH vom 08.09.2016 (C-160/15) kennst. Wenn also auf einer Seite erkennbar Urheberrechtsverletzungen begangen werden (und das Bereithalten modifizierter Firmware-Images für AVM-Boxen wäre - zumindest dem Buchstaben nach - ein solcher, selbst wenn AVM den vielleicht bisher nicht konsequent verfolgt - was sie aber bei den Namensrechten durchaus machen, man kann also nicht ausschließlich auf "Blindheit" bauen), dann sollte sich jeder "Publizist" (von Zeitschrift über Online-Magazin bis zum erwähnten Blogger) das noch ein paarmal mehr überlegen, ob er dorthin verlinkt - daher auch meine (offenbar überneugierige) Frage(!), wie Du das künftig halten willst - von einer Behauptung meinerseits, Du hättest entsprechende Pläne, steht da gar nichts. Also komm einfach mal wieder runter ... aus einem Satz:

Wie soll das künftig bei Freetz-NG dann aussehen - wird es da auch "fertige Images" geben (mal abgesehen vom Sinn, den das ergeben mag)?

kannst auch Du keine "Behauptung" meinerseits zaubern, solange man die "normalen Regeln der deutschen Sprache" darauf anwendet.

Damit ist es doch überflüssig dass du das weisst.

Und weil das dann überflüssig ist, daß ich das weiß, verweigerst Du Deine "Erfahrungen" in dieser Richtung auch den anderen, die hier mitlesen bzw. läßt alle diejenigen, die ihrerseits Freetz (erfolgreich) geforkt haben und darauf aufbauend eigene Änderungen/Verbesserungen vorgenommen haben, weiterhin im Dunklen, warum das für sie "kein Problem" wäre, jetzt einen PR so zu erzeugen, daß Du den übernehmen könntest?

Ehrlich ... irgendwo weiter vorne phantasierte ich noch von einem "miteinander" und hatte die Hoffnung, daß daraus max. ein "nebeneinander" würde und nicht direkt ein "gegeneinander". Dieses "Unterbrechen" der Vererbung führt aber für die anderen "Forker" (und davon gibt es einige, wie Du Dir beim "alten Projekt" im "Insight" ansehen kannst) zu den von mir erwähnten Problemen (und zwar auch genau in dem Kontext, den ich oben beschrieben habe - ich bestreite nicht, daß diese "zu Dir überlaufen" könnten, so sie das wollen) und Deine "Weigerung", Deine Behauptung "kein Problem" passend zu untermauern (ist das vielleicht "geheim"?), soll am besten jeder selbst bewerten.

Ich sehe jedenfalls mit dem Kappen der "Abstammung" auch schon so etwas wie einen "Krieg" (oder zumindest einen Konkurrenzkampf, wie ich ihn weiter oben auch schon beschrieben habe) eröffnet ... so nach dem Motto: "Wer nicht für mich ist, ist automatisch gegen mich." - anders kann ich mir jedenfalls diese (mutwillige) Abtrennung nicht erklären und solange Du die Erklärung für "kein Problem" verweigerst (wieso sollte ich Dir das eigentlich erklären können, wie das dennoch funktioniert - ich habe ja diesen "Graben" nicht aufgerissen und Dich nur auf dessen Konsequenzen hingewiesen, die Du ja - wie durch Zauberhand - irgendwie umgehen willst), sehe ich auch keinen Grund, von dieser Einschätzung abzuweichen.

 

[cuma]

[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Nach der 1. Zeile hatte ich schon genug mit lesen
- Aluhut mal absetzen -> Käse
- Deine Absichten -> ebenso
Der Rest ist vermutlich nicht besser
Da du klar gesagt hast dass du wegen deiner Annahmen keine Lust dich einzubringen, ists ja gut. Weiss jetzt sicher jeder und hab ich kein Problem damit

 

[PeterPawn]

Wow ... das ging ja ziemlich rasant zum "ad hominem" über. Aber Du hast recht und Dir den (mindestens vorläufigen) Platz auf meiner "ignore"-Liste dann redlich verdient. Wenn die einzigen Reaktionen solche kindischen Feststellungen sind, wie in #39, ist einfach jedes weitere Wort verschenkte Zeit.

Over and out.