mpv/DOCS/xml/de/users-vs-dev.xml

<?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<EFBFBD>ckzuf<EFBFBD>hren gewesen w<>ren.
Angefangen mit Red Hat Linux 7.0 begann <emphasis role="bold">Red Hat</emphasis>
eine stark ver<65>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<73>tzten Plattformen gut arbeitete, einschlie<69>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<65>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<62>en f<>hrten.
</para>
</formalpara>

<para>
GCC 2.96 erlaubt keine <literal>|</literal> (pipe-Zeichen) in
Assembler-Kommentaren, weil er gleicherma<6D>en die Intel- wie auch die
AT&amp;T-Syntax unterst<73>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 <20>berspringen.
</para>

<formalpara>
<title>Die Gegenwart:</title>
<para>
Red Hat erkl<6B>rt, dass GCC 2.96-85 und neuer keine Fehler mehr enthalten.
Die Situation hat sich tats<74>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<EFBFBD>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<69>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<61>ber hinaus Unterst<73>tzung f<>r C++, Java oder einige der
  erweiterten GCC-Features, ist
  <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> wom<6F>glich
  besser f<>r deine Bed<65>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<65>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<69>re) Pakete</title>

<para>
Fr<EFBFBD>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<69>re Pakete bauen und verteilen.
</para>

<para>
Ein weiteres Hindernis f<>r Bin<69>rpakete waren Optimierungen der Compilierzeit f<>r
die CPU-Architektur.
<application>MPlayer</application> unterst<73>tzt nun die CPU-Erkennung zur Laufzeit
(<28>bergib <command>configure</command> einfach <option>--enable-runtime-cpudetection</option>).
Diese Option ist standardm<64><6D>ig deaktiviert, weil es eine kleine negative
Auswirkung auf die Geschwindigkeit mitbringt.
Andererseits ist es mit ihr nun m<>glich, Bin<69>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<73>llt die Tatsache, dass <ulink url="http://www.nvidia.com">nVidia</ulink>
nur bin<69>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 <20>ber Probleme, die diese Closed-Source-Treiber
und deren d<>rftige Qualit<69>t, Instabilit<69>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<EFBFBD>rden nicht existieren, die Instabilit<69>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<69>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 <20>blen Berichts ber<65>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<6C>, die Entwickler seinen unfreundlich und die Dokumentation
unvollst<EFBFBD>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<72>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<68>hren der Kontroverse weiter.
Ironischerweise zitiert er am Ende dieses Artikels seine Konversation mit
G<EFBFBD>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;<EFBFBD>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<73>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<72>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<61>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 <20>berhaupt nicht ge<67>ndert.
</para></blockquote>

Wir konnten unsere Gef<65>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<66>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<6F>glich der
Tatsache, dass wir der Flamewars m<>de sind.
</para>

</sect1>
</appendix>