initial import of some missing German xml translation, review(s) pending

Translation was done by Kurt Lettmaier (k . lettmaier @at@ onlinehome.de ), thank you!


git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@18569 b3059339-0415-0410-9bf9-f77b7e298cf2

1 files changed, 258 insertions, 0 deletions

diff --git a/DOCS/xml/de/users-vs-dev.xml b/DOCS/xml/de/users-vs-dev.xml
new file mode 100644
index 0000000000..afae76b0cb
--- /dev/null
+++ b/DOCS/xml/de/users-vs-dev.xml
@@ -0,0 +1,258 @@
+<?xml version="1.0" encoding="iso-8859-1"?>
+<!-- in sync with rev 1.17 $ -->
+<appendix id="users-vs-dev">
+<title>Aufschrei der Entwickler</title>
+
+<sect1 id="gcc-296">
+<title>GCC 2.96</title>
+
+<formalpara>
+<title>Der Hintergrund:</title>
+<para>
+Die GCC <emphasis role="bold">2.95</emphasis> Serie ist ein offizielles
+GNU-Release und Version 2.95.3 ist die fehlerfreieste dieser Serie.
+Wir haban niemals Compilier-Probleme beobachten können, die auf den GCC 2.95.3
+zurückzuführen gewesen wären.
+Angefangen mit Red Hat Linux 7.0 begann <emphasis role="bold">Red Hat</emphasis>
+eine stark veränderte CVS-Version des GCC mitzuliefern und nannte sie
+<emphasis role="bold">2.96</emphasis>.
+Red Hat hat diese Version in seine Distribution aufgenommen, weil GCC 3.0 zu diesem
+Zeitpunkt noch nicht fertiggestellt war und weil sie einen Compiler brauchten, der
+auf allen unterstützten Plattformen gut arbeitete, einschließlich IA64 und s390.
+Der Linux-Distributor <emphasis role="bold">Mandrake</emphasis> (jetzt Mandriva)
+folgte ebenfalls dem Beispiel Red Hat's und begann bald darauf GCC 2.96 mit seiner
+Linux-Mandrake 8.0 Serie auszuliefern.
+</para>
+</formalpara>
+
+<formalpara>
+<title>Die Stellungnahmen:</title>
+<para>
+Das GCC-Team dementierte jegliche Verbindung zu GCC 2.96 und publizierte
+eine <ulink url="http://gcc.gnu.org/gcc-2.96.html">offizielle Stellungnahme</ulink>
+auf GCC 2.96.
+Viele Entwickler weltweit trafen auf Probleme mit GCC 2.96 und
+verschiedene Projekte, darunter
+<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink>,
+fingen an, andere Compiler zu empfehlen.
+Weitere interessante Links sind der
+<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
+Linux kernel news flash about kernel 2.4.17</ulink>
+und das
+<ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>.
+<application>MPlayer</application> litt ebenfalls an zeitweiligen Problemen, die
+alle durch den Wechsel zu einer anderen Version von GCC gelöst waren.
+Verschiedene Projekte begannen daraufhin damit, Workarounds für einige der
+Probleme mit 2.96 zu implementieren, aber wir lehnten es ab, Fehler anderer
+Leute zu beheben.
+Dazu kommt, dass einige Workarounds zu Performance-Einbußen führten.
+</para>
+</formalpara>
+
+<para>
+GCC 2.96 erlaubt keine <literal>|</literal> (pipe-Zeichen) in
+Assembler-Kommentaren, weil er gleichermaßen die Intel- wie auch die
+AT&amp;T-Syntax unterstützt und das Zeichen <literal>|</literal>
+ein Symbol in der Intel-Variante darstellt.
+Das Problem liegt nun darin, dass der GCC den kompletten Assembler-Block
+<emphasis>stillschweigend</emphasis> ignoriert.
+Dieser Fehler wurde inzwischen angeblich behoben. GCC gibt eine Warnung
+aus anstatt den Block einfach zu überspringen.
+</para>
+
+<formalpara>
+<title>Die Gegenwart:</title>
+<para>
+Red Hat erklärt, dass GCC 2.96-85 und neuer keine Fehler mehr enthalten.
+Die Situation hat sich tatsächlich verbessert, jedoch sehen wir nach wie vor
+Problemberichte auf unseren Mailing-Listen, die mit Verwenden eines anderen
+Compilers verschwinden.
+Wie dem auch sei, es ist inzwischen nicht mehr von Bedeutung.
+Hoffentlich wird ein herangereifter GCC 3.x all dieses Problem ein für alle
+mal beheben.
+Wenn du wirklich mit 2.96 compilieren willst, füge <filename>configure</filename>
+die Option <option>--disable-gcc-checking</option> hinzu.
+Vergiss nicht, du bist auf dich allein gestellt und
+<emphasis role="bold">melde keine Bugs</emphasis>.
+Tust du dies trotzdem, wirst du nur aus der Mailing-Liste verbannt, da wir
+mehr als genug Flamewars wegen GCC 2.96 erlebt hatten.
+Lass dieses Thema bitte ruhen.
+</para>
+</formalpara>
+
+<para>
+Solltest du Probleme mit dem GCC 2.96 hast, bekommst du Pakete für die
+Version 2.96-85 auf
+<ulink url="ftp://updates.redhat.com">Red Hats FTP-Server</ulink>,
+oder benutze einfach die für Version 7.2 und neuer bereit liegenden Pakete
+für die Version 3.0.4.
+Du kannst auch Pakete für
+<ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-37/">gcc-3.2.3-37</ulink>
+herunterzuladen (inoffiziell, aber sie funktionieren einwandfrei)
+und du kannst diese analog zu deinem GCC 2.96 installieren.
+<application>MPlayer</application> wird es erkennen und Version 3.2 statt
+2.96 verwenden.
+Wenn du aus irgendeinem Grund die binären Pakete nicht anwenden willst oder kannst,
+lies hier eine kleine Anleitung, wie du GCC 3 aus der Source compilieren kannst:
+</para>
+
+<procedure>
+<step><para>
+  Gehe zur Seite mit den
+  <ulink url="http://gcc.gnu.org/mirrors.html">GCC-Mirrors</ulink>
+  und lade <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename>
+  herunter, wobei <replaceable>XXX</replaceable> die Versionsnummer bedeutet.
+  Dieses Paket beinhaltet den kompletten C-Compiler und reicht für
+  <application>MPlayer</application> aus.
+  Willst du darüber hinaus Unterstützung C++, Java oder einige der
+  erweiterten GCC-Features, ist
+  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> womöglich
+  besser für deine Bedürfnisse geeignet.
+  </para></step>
+<step><para>
+  Entpacke das Archiv mit
+  <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen>
+  </para></step>
+<step><para>
+  Der GCC ist nicht innerhalb der Quelltextverzeichnisses selbst eingebaut
+  wie andere Programme, sondern benötigt ein spezielles Build-Verzeichnis
+  ausserhalb des Quelltextbaumes.
+  Deshalb erstelle dieses Verzeichnis mit
+  <screen>mkdir gcc-build</screen>
+  </para></step>
+<step><para>
+  Danach kannst du mit dem Konfigurieren des GCC im Build-Verzeichnis
+  fortfahren, du brauchst aber das <filename>configure</filename>-Script
+  aus dem Quelltextverzeichnis:
+  <screen>
+cd gcc-build
+../gcc-3.<replaceable>XXX</replaceable>/configure</screen>
+  </para></step>
+<step><para>
+  Compiliere GCC mit folgendem Befehl im Build-Verzeichnis:
+  <screen>make bootstrap</screen>
+  </para></step>
+<step><para>
+  Jetzt kannst du GCC (als root) mit diesem Befehl installieren
+  <screen>make install</screen>
+  </para></step>
+</procedure>
+</sect1>
+
+
+<sect1 id="mplayer-binary">
+<title>Vorcompilierte (binäre) Pakete</title>
+
+<para>
+Früher enthielt <application>MPlayer</application> Quelltext des
+OpenDivX-Projekts, welches es verbietet, vorcompilierte Pakete zu verteilen.
+Dieser Code wurde in Version 0.90-pre1 entfernt und die verbliebene
+Datei <filename>divx_vbr.c</filename>, die noch auf den OpenDivX-Quellen
+aufbaut, wurde wie Version 0.90pre9 durch die Autoren unter die GPL gestellt.
+Du darfst jetzt also nach Herzenslust binäre Pakete bauen und verteilen.
+</para>
+
+<para>
+Ein weiteres Hindernis für Binärpakete waren Optimierungen der Compilierzeit für
+die CPU-Architektur.
+<application>MPlayer</application> unterstützt nun die CPU-Erkennung zur Laufzeit
+(übergib <command>configure</command> einfach <option>--enable-runtime-cpudetection</option>).
+Diese Option ist standardmäßig deaktiviert, weil es eine kleine negative
+Auswirkung auf die Geschwindigkeit mitbringt.
+Andererseits ist es mit ihr nun möglich, Binärpakete zu erstellen, die auf verschiedenen
+Mitgliedern der Intel-kompatiblen CPU-Familie laufen.
+</para>
+</sect1>
+
+
+<sect1 id="nvidia-opinions">
+<title>nVidia</title>
+
+<para>
+Uns misfällt die Tatsache, dass <ulink url="http://www.nvidia.com">nVidia</ulink>
+nur binäre Treiber (zur Verwendung mit XFree86) bereitstellt, die oft genug auch
+noch einige Fehler enthalten.
+Wir bekamen auf
+<ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink>
+viele Berichte über Probleme, die diese Closed-Source-Treiber
+und deren dürftige Qualität, Instabilität und armseligen User- und
+Experten-Support betreffen.
+Viele dieser Probleme/Sachverhalte treten nach wie vor immer wieder auf.
+nVidia hat letztens Kontakt mit uns aufgenommen und behauptet, diese Fehler
+würden nicht existieren, die Instabilität würden von schlechten AGP-Chips
+verursacht, und sie hätten keine Fehlerberichte (wie etwa die lila Linien)
+erhalten.
+Wenn du also ein Problem mit deiner nVidia-Karte hast, solltest du du auf
+jeden Fall deinen nVidia-Treiber aktualisieren und/oder ein neues Motherboard
+kaufen oder nVidia um die Bereitstellung von Open-Source-Treibern bitten.
+Wie dem auch sei, wenn du binäre nVidia-Treiber verwendest und Treiberprobleme
+auftreten, sei dir bitte bewusst, dass du von unserer Seite aus sehr wenig
+Hilfe erhalten wirst, weil wir da einfach wenig helfen können.
+</para>
+</sect1>
+
+
+<sect1 id="joe-barr">
+<title>Joe Barr</title>
+
+<para>
+Joe Barr wurde im Dezember 2001 durch das Verfassen eines für
+<application>MPlayer</application> mehr als üblen Berichts berüchtigt, genannt
+<ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>:
+The project from hell</ulink>.
+Er war der Meinung, <application>MPlayer</application> sei schwer zu installieren und
+kam zu dem Schluß, die Entwickler seinen unfreundlich und die Dokumentation
+unvollständig und beleidigend.
+Entscheide selbst, wie es damit steht.
+Er fuhr fort, Arpi negativ in seinen
+<ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002</ulink>
+zu erwähnen.
+In einem darauf folgenden Bericht von xine, genannt
+<ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for
+the rest of us</ulink>, machte er mit dem Hochrühren der Kontroverse weiter.
+Ironischerweise zitiert er am Ende dieses Artikels seine Konversation mit
+Günter Bartsch, dem Autor von <application>xine</application>,
+der die ganze Situation perfekt zusammenfasste:
+
+<blockquote><para>
+Seis drum, er sagte auch noch, er sei &quot;überrascht&quot; von meiner
+Kolumne zu <application>Mplayer</application> gewesen und meinte, sie sei
+unfair, während er mich daran erinnerte, es ein freies Software-Projekt.
+&quot;Wenn du ihn nicht magst,&quot; sagte Bartsch, &quot;steht es dir frei,
+ihn nicht zu nutzen.&quot;
+</para></blockquote>
+
+Fast zwei Jahre später im Oktober 2003 schrieb er einen anderen Bericht, genannt
+<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink>
+(falsche Rechtschreibung wurde beibehalten).
+Darin kam er zu folgenden Schlußfolgerungen:
+
+<blockquote><para>
+Ich würde gerne erzählen, es hätte bei der Anzahl der Features, in der Performance
+und in der Dokumentation Verbesserungen gegeben.
+Es ist nach wie vor nicht die leichteste Installation der Welt, speziell für
+Neulinge, aber es ist ein bisschen besser als es mal war.
+</para></blockquote>
+
+und
+
+<blockquote><para>
+Aber noch wichtiger, mir sind keinerlei neue Kommentare zum Missbrauch durch
+Nutzer aufgefallen. Ich denke, ich verdiene etwas von dem Ansehen dafür, auch
+wenn ich das selbst nicht so sage.
+Arpi und der Rest des Projektteams muss das auch so empfinden, da sie darauf
+bedacht waren, sich in einem speziellen, im Tarball enthaltenen Abschnitt
+der Dokumentation an mich zu erinnern.
+Wie ich anfangs schon sagte, die Dinge haben sich überhaupt nicht geändert.
+</para></blockquote>
+
+Wir konnten unsere Gefühle für Joe Barr nicht besser zusammen fassen:
+&quot;Es ist nach wie vor nicht der fairste oder am besten recherchierte
+Artikel der Welt, aber er ist besser als früher. &quot;Hoffentlich werden
+wir das nächste Mal jedermanns Erwartungen entsprechen. Wie auch immer,
+die Reife ist nur unserem wachsenden Alter gutzuschreiben und womöglich der
+Tatsache, dass wir der Flamewars müde sind.
+</para>
+
+</sect1>
+</appendix>