Es gibt zwei Themen, die immer zu großen Streitereien und Beschimpfungen +auf der mplayer-users +Mailingliste führen. Das erste Thema dreht sich um den...
+ + +Zum Hintergrund: Die Serie 2.95 des GCC ist der offiziell +GNU-Release, und Version 2.95.3 ist die stabilste und fehlerfreieste aus +dieser Serie. Wir haban niemals Probleme beobachten können, die auf den +GCC 2.95.3 zurückzuführen waren. Beginnend mit RedHat Linux 7.0 +begann Red Hat damit, eine stark veränderte CVS-Version des GCC +mitzuliefern. Diese Version nannten sie 2.96. Red Hat hat diese +Version aufgenommen, weil sie einen Compiler brauchten, der auf all ihren +unterstützten Plattformen lief (welche auch IA64 und s390 einschloss), +und weil der offizielle GCC 3.0 zu diesem Zeitpunkt noch nicht fertiggestellt +war. Der Linuxdistributor Mandrake folgte bald darauf Red Hats Beispiel +und lieferte ab Linux-Mandrake 8.0 ebenfalls den GCC 2.96 aus.
+ +Die Aussagen zu dem Thema: Das GCC-Team hat jegliche Verbindung zu +der Version 2.96 bestritten und dazu eine offizielle Stellungnahme abgegeben. Viele Entwickler auf der +ganzen Welt trafen auf Probleme mit dem GCC 2.96 und empfahlen deswegen +andere Compilerversionen. Beispiele dafür sind MySQL, avifile und Wine. Andere interessante Links sind der + +Linux kernel news flash über den Kernel 2.4.17 und das +Voy-Forum. +MPlayer war ebenfalls von vorrübergehenden Problemen betroffen, +die sich alle lösten, sobald eine andere Version des GCC benutzt wurde. +Viele Projekte begannen daraufhin damit, um einige der Probleme mit dem GCC 2.96 +herumzuarbeiten, aber wir lehnten es ab, die Probleme zu beheben, die andere +Leute durch vorschnelles Handeln verursacht hatten. Dazu kommt, dass einige +dieser Workarounds zu Performanceeinbußen führten.
+ +Du kannst dir auch die andere Seite der Geschichte auf dieser Seite durchlesen. GCC 2.96 erlaubt keine | (Pipezeichen) in +Assemblerkommentaren, weil er sowohl die Intel- als auch die AT&T- +Assemblersyntax unterstützt und das |-Zeichen ein Symbol in der +Intelvariante darstellt. Das Problem lag nun darin, dass der GCC +kommentarlos den kompletten Assemblerblock ignoriert hat. Dieser +Fehler wurde inzwischen angeblich behoben. GCC gibt eine Warnung aus, anstatt +den kompletten Block einfach unter den Tisch fallen zu lassen.
+ +Die Gegenwart: Red Hat behauptet, dass GCC Version 2.96-85 und
+neuer keine Fehler mehr enthalten. Das Verhalten dieser Version hat sich
+tatsächlich deutlich verbessert. Nichts desto trotz werden auf unseren
+Mailinglisten noch immer Probleme berichtet, die verschwinden, sobald ein
+anderer Compiler verwendet wird. Sei wie es ist, es ist inzwischen einfach
+nicht mehr wichtig. Hoffentlich löst eine gereifter GCC 3.x all dieses
+Problem ein für alle mal. Wenn du wirklich mit dem GCC 2.96 compilieren
+möchtest, dann benutze die Option --disable-gcc-checking
+bei configure. Denk aber daran, dass du dann auf dich allein
+gestellt bist. Schick keine Fehlerberichte! Solltest du das doch tun,
+so wirst du nur von der Mailingliste verbannt, weil wir wirklich mehr
+Flamewars wegen des GCC 2.96 erlebt haben als nötig wär. Lass
+dieses Thema bitte ruhen.
Wenn du Probleme mit dem GCC 2.96 hast, so kannst du Pakete für die +Version 2.96-85 auf Red Hats FTP- +Server finden. Andererseits kannst du auch einfach die Pakete für +die Version 3.0.4 benutzen, die Red Hat für Red Hat Linux 7.2 und neuer +anbietet. Eine weitere Möglichkeit besteht darin, Pakete für A +HREF="ftp://people.redhat.com/jakub/gcc/3.2-10/">gcc-3.2-10 +herunterzuladen (inoffiziell, aber sie funktionieren trotzdem einwandfrei). +Sie lassen sich neben dem GCC 2.96 installieren, den du bereits hast. +MPlayer wird automatisch Version 3.2-10 finden und diesesn GCC +anstelle der Version 2.96 benutzen. Wenn du aus irgendeinem Grund die +binären Pakete für den GCC nicht benutzen kannst oder willst, dann +folgt hier eine kleine Anleitung, wie du den neuesten GCC compilieren +kannst:
+ +gcc-core-XXX.tar.gz von einem der GCC-Mirrorseiten herunter,
+ wobei XXX die Versionsnummer darstellt. Dieses Paket
+ beinhaltet den kompletten C-Compiler und reicht für MPlayer
+ aus. Wenn du darüber hinaus Unterstützung für C++, Java
+ oder andere Features des GCC benötigst, dann ist gcc-
+ XXX.tar.gz besser für dich geeignet.tar -xvzf gcc-core-XXX.tar.gzmkdir gcc-buildconfigure-Script liegt natürlich im
+ Quelltextverzeichnis:cd gcc-build
+ ../gcc-XXX/configuremake bootstrapmake installFrüher enthielt MPlayer Teile des Quelltextes des OpenDivX-
+Projektes, welches es verbietet, vorcompilierte Pakete zu verteilen. Diese
+Codeabschnitte wurden aber in Version 0.90pre1 entfernt, und die letzte noch
+verbleibende Datei divx_vbr.c, die noch auf den OpenDivX-Quellen
+aufbaut, wurden von den Authoren unter die GPL gestellt (Version 0.90pre9).
+Du darfst jetzt also nach Herzenslust binäre Pakete bauen und
+verteilen.
Ein weiteres Hindernis für Binärpakete waren die bei der
+Compilierung automatisch erkannten Optimierungsmöglichkeiten seitens der
+CPU-Architektur (MMX, 3DNOW etc.). MPlayer unterstützt inzwischen
+aber auch die Erkennung der CPU-Features beim Starten von MPlayer,
+wenn configure mit der Option --enable-runtime-
+cpudetection aufgerufen wurde. Diese Option ist
+standardmäßig deaktiviert, weil sie 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-CPU-Familie beschleunigt laufen.
Uns misfällt die Tatsache, dass nVidia nur binäre Treiber für +XFree86 zur Verfügung stellt, die oft genug auch noch einige Fehler +enthalten. Auf mplayer-users sehen wir viele Fehlermeldungen, die mit diesen +Closed-Source-Treibern zusammenhängen: über die allgemein schlechte +Qualität der Treiber, über Instabilitäten und über den +schlechten Support der Endbenutzer durch nVidia. Einige Beispiele dafür +kannst du im nVidia-Linux-Forum finden. Viele +dieser Fälle sind wiederkehrende Probleme. nVidia hat letztens Kontakt +mit uns aufgenommen und behauptet, dass ihre Treiber keine Fehler enthielten, +sondern dass die Instabilitäten von schlechten AGP-Chips verursacht +würden, und dass sie keinerlei Fehlerberichte von Nutzern erhalten +hätten (wie z.B. die lila Linien). Wenn du also ein Problem mit deiner +nVidia-Karte hast, dann solltest du auf jeden Fall die neuesten nVidia- +Treiber ausprobieren und/oder ein neues Motherboard kaufen oder aber nVidia +darum bitten, dass sie OpenSource-Treiber veröffentlichen. Wie dem auch +sei - wenn du die binären nVidia-Treiber benutzt und Treiberprobleme +auftreten, dann sei gewarnt, dass du von uns nur sehr wenig Hilfe erhalten +wirst, weil wir da einfach nichts tun können, um dir zu helfen.
+ + +Joe Barr wurde dadurch berüchtigt, dass er einen mehr als schlechten + +Bericht über MPlayer veröffentlichte. Er war der Meinung, +MPlayer sei schwierig zu installieren, aber andererseits mag er auch + +keine Dokumentation lesen. Er schloß auch damit, dass die +MPlayer-Entwickler unfreundlich und die Dokumentation +unvollständig seien. Entscheide selber, wie es damit steht. Er schreib +weiter negativ über MPlayer in seinen +10 +Vorhersagungen zu Linux für 2002. In einem folgenden +Bericht +über xine hat er weiter versucht, Rivalität zu schühren. +Ironischerweise zitiert er am Ende dieses Artikels seine Konversation mit +Günter Bartsch, dem Author von xine, der die ganze Situation perfekt +zusammengefasst hat:
+ ++ Er sagte auch noch, dass er von meiner Kolumne über MPlayer + "überrascht" war und dachte, dass sie unfair sei. Er erinnerte mich + daran, dass es sich dabei um freie Software handele. "Wenn du sie nicht + magst", sagte Bartsch, "dann hast du die Freiheit, sie nicht zu benutzen." ++ +
Er antwortet auch nicht auf unsere Mails. Sein Editor antwortet ebenfalls +nicht auf unsere Mails. Hier sind ein paar Zitate von verschiedenen Personen +über Joa Barr, sodass du dir deine eigene Meinung bilden kannst:
+ +Marc Rassbach hat etwas über +den Kerl zu sagen:
+ ++ Vielleicht erinnert ihr euch an die LinuxWorld 2000, bei der er behauptete, + Linus T. habe gesagt: 'FreeBSD besteht nur aus einer Handvoll Programmierer.' + Linus hat NICHTS dergleichen gesagt. Als Joe dazu zur Rede gestellt wurde, + bestand seine Reaktion darin, die BSD-Unterstützer Arschlöcher + und Idioten zu nennen. ++ +
Ein Zitat von Robert Munro von der mplayer-users +Mailingliste:
+ +++ + +Er ist interessant aber nicht besonders gut darin... hmm... Konflikte zu + vermeiden. Joe Barr war vor Jahren ein regelmäßiger Besucher von + Will Zachmanns Canopus-Forum bei Compuserve. Er war damals ein + OS/2-Bfürworter (ich war damals ebenfalls ein OS/2-Fan).
+ +Damals hat er ständig überreagiert, Leute beschimpft, und ich + vermute, dass es für ihn damals ziemlich hart gewesen sein musste. + Er hat sich seitdem ein wenig beruhigt, wenn man sich seine letzten + Kolumnen durchliest. Subtiler Humor war aber auch damals schon nicht sein + Fall - ganz und gar nicht.
+