annotate DOCS/xml/de/users-vs-dev.xml @ 19431:ac69ba536915

Explicitly include libmpcodecs/img_format.h and libvo/fastmemcpy.h.

<?xml version="1.0" encoding="iso-8859-1"?>
<!-- in sync with r15895 -->
<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 haben 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>,
und 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 zeitweilig an Problemen, die
alle durch den Wechsel zu einer anderen Version von GCC ausgelöst worden 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,
<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 haben, 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 der Version 7.2 und neuer bereitliegenden 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 das 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 den Quellen 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 für 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 des 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ürde 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, da wir in diesem Falle 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 darum 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 sei 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 Schlussfolgerungen:

<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>