Mercurial > mplayer.hg
view DOCS/xml/de/users-vs-dev.xml @ 19689:b187da3ed321
fix charset issues and a little wording
author | kraymer |
---|---|
date | Tue, 05 Sep 2006 16:09:49 +0000 |
parents | 3630818b288e |
children | cf29467223c7 |
line wrap: on
line source
<?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&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 "überrascht" 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. "Wenn du ihn nicht magst," sagte Bartsch, "steht es dir frei, ihn nicht zu nutzen." </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: "Es ist nach wie vor nicht der fairste oder am besten recherchierte Artikel der Welt, aber er ist besser als früher. "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>