Und dann willst du uns erzählen das du "zufällig" eine der alten heißen Diskussionen wieder entflammen willst? Ach komm schon
Wobei das Thema zum Glück älter als die Steinkohle ist. Früher war das sicher ein großes Thema, heute gibt es wichtigeres unter Linux als zwei alte Editoren.
Vim ist als reiner Texteditor toll, aber zum Programmieren in C/C++ ist er nicht gut, weil der Debugger saumäßig schlecht integriert ist.
Es gibt z.B. standardmäßig keine Variablen Watchlist, man kann das über Plugins zwar nachinstallieren, aber out of the Box geht das nicht. Und den gdb immer per Kommandozeile händisch bedienen ist auch mehr umständlich als angenehm.
Deswegen nutze ich unter Linux Eclipse für C/C++, da ist der Debugger wenigstens gut mit einer Watchlist zum Variablen überwachen integriert.
EMacs selbst habe ich nie benutzt, ich mag das auch nicht, wenn ein Editor den ich zum Programmieren einsetzen will, auch zum Tetris spielen und E-Mail abrufen geeignet ist. Denn mehr ist nicht besser. Das steigert nur den Lernaufwand und sorgt für Unübersichtlichkeit. In diesem Sinne ist Vim dann schon deutlich besser, aber halt nur als Editor, nicht als IDE.
...wie schnell man sich im Lizenzwirrwar verirren kann.
Wenn ich einfach nur mal eine Applikation nehme, welche externe Bibliotheken nutzen will und selbst nicht unter der GPL steht, dann darf diese für die Bibliothek unterscheiden:
- LGPL - dynamisches Linken geht - GPL - diese Bibliothek darf nicht benutzt werden - GPL mit linking exception - diese wiederum darf benutzt werden - BSD etc. - kein Problem, es darf gelinkt werden
Wirklich übel wird es allerdings, wenn im Laufe der Jahre irgend eines der Projekte seine Lizenz ändert und man das nicht mitbekommt, weil man eben nicht in 42 unterschiedlich uninteressanten Mailinglisten eingetragen ist...
Schon ein wenig ironisch, dass ausgerechnet Emacs gegen die GPL verstößt. QM-mäßig scheint's ja nicht zu klappen. Aber spätestens mit der nächsten Version können die Emacs-Jünger die Papptüten von den Köpfen wieder runternehmen
ist das ein echtes Problem oder so ein politisches Ding.
Normal sollte es langen, wenn die Entwickler den Code für die betreffenden Teile nicht direkt mitliefern aber bei Anforderung zur Verfügung stellen. Entsprechend können die Cedet ohne Source ausgeliefert werden, so lange diese selbst unter GPL stehen. Problem wär nur, wenn Cedet unter einer nicht mit GPL kompatiblen Lizenz ständen.
So sieht es für mich eher nach einem typischen Stallmann aus, bei extremer politischer Auslegung der GPL ohne Praxisbezug.
Wenn ich das richtig verstanden habe, dann ist der den veröffentlichten Binaries entsprechende Sourcecode gar nicht mehr vorhanden bzw. muss erst noch gefunden werden. Die haben zur Zeit also nichts Vollständiges, was sie auf Anfrage überhaupt zur Verfügung stellen könnten.
CEDET ist ein System zur Quellcodeanalyse. Hierfür benutzt es eine Grammatik die in bison geschrieben ist und dann vom bison(1) Programm in C-Code umgewandelt wird. Der generierte C-Code ist dann das wogegen EMACS gelinkt wird. Im tarball sind nun aufgrund eines Versehens zwar die generierten C Dateien vorhanden, nicht aber die ursprünglichen bison Grammatiken, darum ist das auch bisher keinem aufgefallen.
Die GPL besagt aber ausdrücklich, das die präferierte Form der Modifikation mit angeboten werden muss (also die bison Dateien und nicht der generierte C-Spaghetticode). Sollten diese tatsächlich verloren gegangen sein muss man hier natürlich etwas unternehmen.
Streng genommen verstößt auch EMACS selbst (von der GNU Homepage) nicht gegen die GPL, da ja die FSF das komplette Copyright am Code hat und diesen somit verteilen kann wie sie will. Jede Linux-Distri die EMACS anbietet verstößt aber in diesem Fall gegen die GPL, da sie nicht den kompletten Code anbieten (können). Damit könnten theoretisch Distris und GNU-Mirror von der FSF verklagt werden, was dann wohl doch eher unwahrscheinlich ist. (Und da die FSF der Ursprung des Problems ist, kann man dagegen dann wohl auch locker mit "entrapment" argumentieren 8).)
> Streng genommen verstößt auch EMACS selbst (von der GNU Homepage) nicht gegen die GPL, da ja die FSF das komplette Copyright am Code hat und diesen somit verteilen kann wie sie will.
Vorsicht bei dieser Art der Argumentation.
Es gilt im Blick zu haben was freie Software eigentlich erreichen will und warum sie das mittels Lizenzen tut. Es geht hierbei um REchtsverbindlichkeit, denn eine Abhängigkeit vom Wohlwollen der FSF etwas zu tun (was sie kann, aber nicht muss) ist genauso eine Abhängigkeit wie die von Softwarekonzernen.
Die FSF ist inzwischen ohnehin mit einiger Kritik zu sehen denn sie ist bemüht andere in Abhängigkeit zu bringen und betreibt fragwürdige Lobbyarbeit.
Beispielsweise hat die Documentfoundation (Der 'Träger' von LibreOffice) der FSF Einfluss in ihren REihen verschaft (Stimmrechte) als offensichtlichen DAnk dafür das sich die FSF gegen OOo unter Apache-Lizenz und für LO unter LGPL aussprach , OBWOHL beides freie Lizenzen sind und die Apache-Foundation kein Gegner freier Software ist.
Im realen Leben nennt sich das was FSF und Documentfoundation hier tun 'Klüngel' und auch die Community sollte sowas nicht dulden sondern solches Handeln kritisch würdigen und der FSF und der Documentfoundation nötigenfals gehörig auf die Finger klopfen.
> Es gilt im Blick zu haben was freie Software eigentlich erreichen will und warum sie das mittels Lizenzen tut.
Deswegen gibt es ja das Schisma zwischen "free software" und "open source". Nicht jeder ist mit dem ideologischen Überbau der FSF glücklich.
> Beispielsweise hat die Documentfoundation (Der 'Träger' von LibreOffice) der FSF Einfluss in ihren REihen verschaft (Stimmrechte) als offensichtlichen DAnk dafür das sich die FSF gegen OOo unter Apache-Lizenz und für LO unter LGPL aussprach , OBWOHL beides freie Lizenzen sind und die Apache-Foundation kein Gegner freier Software ist.
Interessant. Hast du einen Link o.ä. dazu?
> Im realen Leben nennt sich das was FSF und Documentfoundation hier tun 'Klüngel' und auch die Community sollte sowas nicht dulden sondern solches Handeln kritisch würdigen und der FSF und der Documentfoundation nötigenfals gehörig auf die Finger klopfen.
Für viele sind FSF und GPL doch heilige Kühe, die man nicht kritisieren darf.
Details wirst Du Dir auf Mailinglistzen anlesen müssen, denn es sollte klar sein das es hier um ZUsammenhänge geht von denen die Beteiligten nicht wollen das sie breit öffentlich werden.
In die selbe Kategorie fallen auch Dinge wie solche mails von offiziellen Vertretern der Documentfoundation und LibreOffice:
denn jedem der das Geschehen aufmerksam beobachtet ist natürlich sofort klar das der Anlass zu dieser Mail nur die Tatsache war das man einige Tage vor der offiziellen Verlautbarung wußte das OOo zu Apache wechseln würde und somit als Projekt wieder auf festem Boden steht. Man hoffte wohl das diese Info in der Öffentlichkeit lange genug verborgen bleiben würde so das man weitere Leute 'überzeugen' könnte von OOo Abstand zu nehmen.
Auch heutige Ankündigungen des ERscheinens einer neuen LibreOffice-Version mit der augenscheinlich komisch überzogenen Betonung das diese Versioin 'für den Geschäftseinsatz' geeignet sei, bemühgen sich weiterhin Territorium zu sichern solange das OOo-Projekt unter Apache-Regie noch nicht wieder völlig arbeisfähig ist, denn man weiß die Luft wird, sobald OOo wieder zur Arbeitsfähigkeit findet, dünn für LO werden.
Die Liste ließe sich fortsetzen, beispielsweise blicke man mit Sorgfalt hinter die Kulissen und Absichten von: http://wiki.documentfoundation.org/Hackfest2011
Insgesamt gilt: Die Documentfoundation ist nicht unabhängig, auch wenn sie es behauptet, im Gegenteil versuchen hier radikal-extremistische Teile der freien Softwarebewegung ein Projekt in ihrem Sinne zu beeinflussen/unterwandern, in der langfristigen Hoffnung ihre politischen Ziele beser umsetzen zu können.
Eines muß man LO/TDF in jedem Falle bescheinigen: in Fragen der öffentlichen Meinungsbeeinflussung ist man inzwischen ähnlich geschickt und subtil wie z.B. Microsoft.
> Details wirst Du Dir auf Mailinglistzen anlesen müssen, denn es sollte klar sein das es hier um ZUsammenhänge geht von denen die Beteiligten nicht wollen das sie breit öffentlich werden.
Danke für die Links, das passt auch zu meinem Eindruck.
Dass die Document Foundation bei Beteiligung von Firmen wie Google, Red Hat oder Novell/Suse etwas Schlagseite Richtung Linux hat, war mir durchaus bewusst. Wenn nun noch weitere Akteure aus dem Linux/GNU-Umfeld dazu kommen, wird das nur noch deutlicher.
"bemühen sich weiterhin Territorium zu sichern solange das OOo-Projekt unter Apache-Regie noch nicht wieder völlig arbeisfähig ist, denn man weiß die Luft wird, sobald OOo wieder zur Arbeitsfähigkeit findet, dünn für LO werden."
Diese Konkurrenzsituation wird wohl auf der Windows-Plattform entschieden und hier wird sich sehr wahrscheinlich IBMs Apache-OpenOffice durchsetzen, wahlweise als freies Apache OpenOffice oder freies bzw. vielleicht auch proprietäres IBM Lotus Symphony.
Libre Office hingegen wird ein fast reines Linux Office werden, dank gewählter Lizenz und Struktur wie Herkunft der meisten Unterstützer.
> Die GPL besagt aber ausdrücklich, das die präferierte Form der Modifikation mit angeboten werden muss (also die bison Dateien und nicht der generierte C-Spaghetticode). Sollten diese tatsächlich verloren gegangen sein muss man hier natürlich etwas unternehmen.
Die Sourcen sind da, der zuständige Entwickler konnte sie sofort benennen, sie sind nur nicht im Emacs-Tarball. Dafür gab es Gründe, u.a. weil in den generierten Lisp-Dateien selber Änderungen gemacht wurden. Da verschwimmt also die Trennung zwischen Source und Object Code.
Wieso steht das nicht in der Meldung? Stattdessen stehen da Sätze wie "Der Ur-Autor und ehemalige Betreuer des Editors fordert deshalb die umgehende und rückwirkende Freigabe der betroffenen Quelltexte. Sollen jene nicht mehr auffindbar sein, so müssten die betroffenen Versionen aus dem Verkehr gezogen werden. " und führen zu völlig falschen Schlüssen bei den Lesern.
>>>Sollten diese tatsächlich verloren gegangen sein muss man hier natürlich etwas unternehmen. >Sind sie aber nicht. >> http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01182.html
Oh, soweit war der Thread noch nicht, als ich das vor ein paar Tagen gelesen hab :). Dann ist das ja mit reintegrieren der Quellen getan.
Ich benutze seit vielen Jahren vim. Was sind die Vorteile von Emacs demgegenüber, bzw. ist Emacs irgendwie besser als Vim?
Vim ist wirklich nur ein Texteditor.
Emacs ist eine eierlegende Wollmilchsau.
Emacs ist ein Betriebssystem - Vim nur ein Editor
Genau Emacs ist ein Betriebsystem... nur ein guter Editor fehlt darin
XKCD-Comic zu Emacs Überlegenheit
Generell muss jeder selber wissen was man mag. Emacs ohne lisp zu verstehen macht jedoch viel weniger Spass...
"Ich benutze seit vielen Jahren vim"
Und dann willst du uns erzählen das du "zufällig" eine der alten heißen Diskussionen wieder entflammen willst? Ach komm schon
Wobei das Thema zum Glück älter als die Steinkohle ist. Früher war das sicher ein großes Thema, heute gibt es wichtigeres unter Linux als zwei alte Editoren.
Bleib' einfach bei Vim, da kannst du nix falsch machen
Vim ist als reiner Texteditor toll, aber zum Programmieren in C/C++ ist er nicht gut, weil der Debugger saumäßig schlecht integriert ist.
Es gibt z.B. standardmäßig keine Variablen Watchlist, man kann das über Plugins zwar nachinstallieren, aber out of the Box geht das nicht.
Und den gdb immer per Kommandozeile händisch bedienen ist auch mehr umständlich als angenehm.
Deswegen nutze ich unter Linux Eclipse für C/C++, da ist der Debugger wenigstens gut mit einer Watchlist zum Variablen überwachen integriert.
EMacs selbst habe ich nie benutzt, ich mag das auch nicht, wenn ein Editor den ich zum Programmieren einsetzen will, auch zum Tetris spielen und E-Mail abrufen geeignet ist.
Denn mehr ist nicht besser.
Das steigert nur den Lernaufwand und sorgt für Unübersichtlichkeit.
In diesem Sinne ist Vim dann schon deutlich besser, aber halt nur als Editor, nicht als IDE.
...wie schnell man sich im Lizenzwirrwar verirren kann.
Wenn ich einfach nur mal eine Applikation nehme, welche externe Bibliotheken nutzen will und selbst nicht unter der GPL steht, dann darf diese für die Bibliothek unterscheiden:
- LGPL - dynamisches Linken geht
- GPL - diese Bibliothek darf nicht benutzt werden
- GPL mit linking exception - diese wiederum darf benutzt werden
- BSD etc. - kein Problem, es darf gelinkt werden
Wirklich übel wird es allerdings, wenn im Laufe der Jahre irgend eines der Projekte seine Lizenz ändert und man das nicht mitbekommt, weil man eben nicht in 42 unterschiedlich uninteressanten Mailinglisten eingetragen ist...
http://de.wikipedia.org/wiki/GPL_linking_exception
Schon ein wenig ironisch, dass ausgerechnet Emacs gegen die GPL verstößt. QM-mäßig scheint's ja nicht zu klappen. Aber spätestens mit der nächsten Version können die Emacs-Jünger die Papptüten von den Köpfen wieder runternehmen
Und ich dachte immer es gibt ein Tastenkürzel für die Lizenzprüfung.
War das nicht die mit den Libellen? C-x M-c M-dragonfly?
Siehe Link oben:
C-x M-c M-butterfly
Schon klar ;)
Die hat aber eine andere Funktion
Stimmt, Butterfly liest die Daten nicht aus, sondern schreibt sie nur. Das hätte ich erkennen müssen
ist das ein echtes Problem oder so ein politisches Ding.
Normal sollte es langen, wenn die Entwickler den Code für die betreffenden Teile nicht direkt mitliefern aber bei Anforderung zur Verfügung stellen. Entsprechend können die Cedet ohne Source ausgeliefert werden, so lange diese selbst unter GPL stehen. Problem wär nur, wenn Cedet unter einer nicht mit GPL kompatiblen Lizenz ständen.
So sieht es für mich eher nach einem typischen Stallmann aus, bei extremer politischer Auslegung der GPL ohne Praxisbezug.
Wenn ich das richtig verstanden habe, dann ist der den veröffentlichten Binaries entsprechende Sourcecode gar nicht mehr vorhanden bzw. muss erst noch gefunden werden.
Die haben zur Zeit also nichts Vollständiges, was sie auf Anfrage überhaupt zur Verfügung stellen könnten.
Das ganze ist eher ein akademisches Problem...
CEDET ist ein System zur Quellcodeanalyse. Hierfür benutzt es eine Grammatik die in bison geschrieben ist und dann vom bison(1) Programm in C-Code umgewandelt wird. Der generierte C-Code ist dann das wogegen EMACS gelinkt wird. Im tarball sind nun aufgrund eines Versehens zwar die generierten C Dateien vorhanden, nicht aber die ursprünglichen bison Grammatiken, darum ist das auch bisher keinem aufgefallen.
Die GPL besagt aber ausdrücklich, das die präferierte Form der Modifikation mit angeboten werden muss (also die bison Dateien und nicht der generierte C-Spaghetticode). Sollten diese tatsächlich verloren gegangen sein muss man hier natürlich etwas unternehmen.
Streng genommen verstößt auch EMACS selbst (von der GNU Homepage) nicht gegen die GPL, da ja die FSF das komplette Copyright am Code hat und diesen somit verteilen kann wie sie will. Jede Linux-Distri die EMACS anbietet verstößt aber in diesem Fall gegen die GPL, da sie nicht den kompletten Code anbieten (können). Damit könnten theoretisch Distris und GNU-Mirror von der FSF verklagt werden, was dann wohl doch eher unwahrscheinlich ist.
(Und da die FSF der Ursprung des Problems ist, kann man dagegen dann wohl auch locker mit "entrapment" argumentieren 8).)
Der bisher einzig sinnvolle Kommentar zu dieser Nachricht...
> Streng genommen verstößt auch EMACS selbst (von der GNU Homepage) nicht gegen die GPL, da ja die FSF das komplette Copyright am Code hat und diesen somit verteilen kann wie sie will.
Vorsicht bei dieser Art der Argumentation.
Es gilt im Blick zu haben was freie Software eigentlich erreichen will und warum sie das mittels Lizenzen tut.
Es geht hierbei um REchtsverbindlichkeit, denn eine Abhängigkeit vom Wohlwollen der FSF etwas zu tun (was sie kann, aber nicht muss) ist genauso eine Abhängigkeit wie die von Softwarekonzernen.
Die FSF ist inzwischen ohnehin mit einiger Kritik zu sehen denn sie ist bemüht andere in Abhängigkeit zu bringen und betreibt fragwürdige Lobbyarbeit.
Beispielsweise hat die Documentfoundation (Der 'Träger' von LibreOffice) der FSF Einfluss in ihren REihen verschaft (Stimmrechte) als offensichtlichen DAnk dafür das sich die FSF gegen OOo unter Apache-Lizenz und für LO unter LGPL aussprach , OBWOHL beides freie Lizenzen sind und die Apache-Foundation kein Gegner freier Software ist.
Im realen Leben nennt sich das was FSF und Documentfoundation hier tun 'Klüngel' und auch die Community sollte sowas nicht dulden sondern solches Handeln kritisch würdigen und der FSF und der Documentfoundation nötigenfals gehörig auf die Finger klopfen.
> Es gilt im Blick zu haben was freie Software eigentlich erreichen will und warum sie das mittels Lizenzen tut.
Deswegen gibt es ja das Schisma zwischen "free software" und "open source". Nicht jeder ist mit dem ideologischen Überbau der FSF glücklich.
> Beispielsweise hat die Documentfoundation (Der 'Träger' von LibreOffice) der FSF Einfluss in ihren REihen verschaft (Stimmrechte) als offensichtlichen DAnk dafür das sich die FSF gegen OOo unter Apache-Lizenz und für LO unter LGPL aussprach , OBWOHL beides freie Lizenzen sind und die Apache-Foundation kein Gegner freier Software ist.
Interessant. Hast du einen Link o.ä. dazu?
> Im realen Leben nennt sich das was FSF und Documentfoundation hier tun 'Klüngel' und auch die Community sollte sowas nicht dulden sondern solches Handeln kritisch würdigen und der FSF und der Documentfoundation nötigenfals gehörig auf die Finger klopfen.
Für viele sind FSF und GPL doch heilige Kühe, die man nicht kritisieren darf.
> Interessant. Hast du einen Link o.ä. dazu?
Ja, sicher:
http://www.fsf.org/news/openoffice-apache-libreoffice
http://www.heise.de/open/meldung/Document-Foundation-besetzt-Advisory-Board-1260843.html
Details wirst Du Dir auf Mailinglistzen anlesen müssen, denn es sollte klar sein das es hier um ZUsammenhänge geht von denen die Beteiligten nicht wollen das sie breit öffentlich werden.
In die selbe Kategorie fallen auch Dinge wie solche mails von offiziellen Vertretern der Documentfoundation und LibreOffice:
http://openoffice.org/projects/de/lists/dev/archive/2011-05/message/80
denn jedem der das Geschehen aufmerksam beobachtet ist natürlich sofort klar das der Anlass zu dieser Mail nur die Tatsache war das man einige Tage vor der offiziellen Verlautbarung wußte das OOo zu Apache wechseln würde und somit als Projekt wieder auf festem Boden steht.
Man hoffte wohl das diese Info in der Öffentlichkeit lange genug verborgen bleiben würde so das man weitere Leute 'überzeugen' könnte von OOo Abstand zu nehmen.
Auch heutige Ankündigungen des ERscheinens einer neuen LibreOffice-Version mit der augenscheinlich komisch überzogenen Betonung das diese Versioin 'für den Geschäftseinsatz' geeignet sei, bemühgen sich weiterhin Territorium zu sichern solange das OOo-Projekt unter Apache-Regie noch nicht wieder völlig arbeisfähig ist, denn man weiß die Luft wird, sobald OOo wieder zur Arbeitsfähigkeit findet, dünn für LO werden.
Die Liste ließe sich fortsetzen, beispielsweise blicke man mit Sorgfalt hinter die Kulissen und Absichten von:
http://wiki.documentfoundation.org/Hackfest2011
Insgesamt gilt: Die Documentfoundation ist nicht unabhängig, auch wenn sie es behauptet, im Gegenteil versuchen hier radikal-extremistische Teile der freien Softwarebewegung ein Projekt in ihrem Sinne zu beeinflussen/unterwandern, in der langfristigen Hoffnung ihre politischen Ziele beser umsetzen zu können.
Eines muß man LO/TDF in jedem Falle bescheinigen: in Fragen der öffentlichen Meinungsbeeinflussung ist man inzwischen ähnlich geschickt und subtil wie z.B. Microsoft.
> Details wirst Du Dir auf Mailinglistzen anlesen müssen, denn es sollte klar sein das es hier um ZUsammenhänge geht von denen die Beteiligten nicht wollen das sie breit öffentlich werden.
Danke für die Links, das passt auch zu meinem Eindruck.
Dass die Document Foundation bei Beteiligung von Firmen wie Google, Red Hat oder Novell/Suse etwas Schlagseite Richtung Linux hat, war mir durchaus bewusst. Wenn nun noch weitere Akteure aus dem Linux/GNU-Umfeld dazu kommen, wird das nur noch deutlicher.
"bemühen sich weiterhin Territorium zu sichern solange das OOo-Projekt unter Apache-Regie noch nicht wieder völlig arbeisfähig ist, denn man weiß die Luft wird, sobald OOo wieder zur Arbeitsfähigkeit findet, dünn für LO werden."
Diese Konkurrenzsituation wird wohl auf der Windows-Plattform entschieden und hier wird sich sehr wahrscheinlich IBMs Apache-OpenOffice durchsetzen, wahlweise als freies Apache OpenOffice oder freies bzw. vielleicht auch proprietäres IBM Lotus Symphony.
Libre Office hingegen wird ein fast reines Linux Office werden, dank gewählter Lizenz und Struktur wie Herkunft der meisten Unterstützer.
> Die GPL besagt aber ausdrücklich, das die präferierte Form der Modifikation mit angeboten werden muss (also die bison Dateien und nicht der generierte C-Spaghetticode). Sollten diese tatsächlich verloren gegangen sein muss man hier natürlich etwas unternehmen.
Sind sie aber nicht.
> http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01182.html
Die Sourcen sind da, der zuständige Entwickler konnte sie sofort benennen, sie sind nur nicht im Emacs-Tarball. Dafür gab es Gründe, u.a. weil in den generierten Lisp-Dateien selber Änderungen gemacht wurden. Da verschwimmt also die Trennung zwischen Source und Object Code.
Wieso steht das nicht in der Meldung?
Stattdessen stehen da Sätze wie
"Der Ur-Autor und ehemalige Betreuer des Editors fordert deshalb die umgehende und rückwirkende Freigabe der betroffenen Quelltexte. Sollen jene nicht mehr auffindbar sein, so müssten die betroffenen Versionen aus dem Verkehr gezogen werden. "
und führen zu völlig falschen Schlüssen bei den Lesern.
>>>Sollten diese tatsächlich verloren gegangen sein muss man hier natürlich etwas unternehmen.
>Sind sie aber nicht.
>> http://lists.gnu.org/archive/html/emacs-devel/2011-07/msg01182.html
Oh, soweit war der Thread noch nicht, als ich das vor ein paar Tagen gelesen hab :). Dann ist das ja mit reintegrieren der Quellen getan.
Ergo, "Nothing to see here, move along!"