diff options
| -rw-r--r-- | DOCS/xml/de/documentation.xml | 3 | ||||
| -rw-r--r-- | DOCS/xml/de/users-vs-dev.xml | 257 |
2 files changed, 1 insertions, 259 deletions
diff --git a/DOCS/xml/de/documentation.xml b/DOCS/xml/de/documentation.xml index 6a591021ac..2305f894a2 100644 --- a/DOCS/xml/de/documentation.xml +++ b/DOCS/xml/de/documentation.xml @@ -1,5 +1,5 @@ <?xml version="1.0" encoding="iso-8859-1"?> -<!-- in sync with r19738 --> +<!-- in sync with r19973 --> <bookinfo id="toc"> <title><application>MPlayer</application> - Movie Player</title> @@ -197,4 +197,3 @@ &bugreports.xml; &bugs.xml; &skin.xml; -&users-vs-dev.xml; diff --git a/DOCS/xml/de/users-vs-dev.xml b/DOCS/xml/de/users-vs-dev.xml deleted file mode 100644 index e58f41daeb..0000000000 --- a/DOCS/xml/de/users-vs-dev.xml +++ /dev/null @@ -1,257 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-1"?> -<!-- in sync with r19685 --> -<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://lists.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> |