# HG changeset patch # User diego # Date 1159117077 0 # Node ID e3ced2d5bc1322d7a83fa492c75479878f11271f # Parent 27187c1ac20b0016825da9c9061e5a8f8c1587eb Remove outdate, obsolete and inflammatory rants section. diff -r 27187c1ac20b -r e3ced2d5bc13 DOCS/xml/en/documentation.xml --- a/DOCS/xml/en/documentation.xml Sun Sep 24 16:15:47 2006 +0000 +++ b/DOCS/xml/en/documentation.xml Sun Sep 24 16:57:57 2006 +0000 @@ -196,4 +196,3 @@ &bugreports.xml; &bugs.xml; &skin.xml; -&users-vs-dev.xml; diff -r 27187c1ac20b -r e3ced2d5bc13 DOCS/xml/en/users-vs-dev.xml --- a/DOCS/xml/en/users-vs-dev.xml Sun Sep 24 16:15:47 2006 +0000 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,226 +0,0 @@ - - - -Developer cries - - -GCC 2.96 - - -The background: - -The GCC 2.95 series is an official GNU release and -version 2.95.3 of GCC is the most bug-free in that series. We have never -noticed compilation problems that we could trace to gcc-2.95.3. Starting -with Red Hat Linux 7.0, Red Hat included a heavily -patched CVS version of GCC in their distribution and named it -2.96. Red Hat included this version in the -distribution because GCC 3.0 was not finished at the time, and they needed -a compiler that worked well on all of their supported platforms, including -IA64 and s390. The Linux distributor Mandrake -(now Mandriva) also followed Red Hat's example and started shipping GCC 2.96 -with their Linux-Mandrake 8.0 series. - - - - -The statements: - -The GCC team disclaimed any link with GCC 2.96 and issued an -official response -to GCC 2.96. Many developers around the world began having problems with -GCC 2.96, and several projects, -avifile among them, -started recommending other compilers. -Other interesting links are - -Linux kernel news flash about kernel 2.4.17 -and -Voy Forum. -MPlayer also suffered from intermittent problems -that were all solved by switching to a different version of GCC. Several -projects started implementing workarounds for some of the 2.96 issues, but -we refused to fix other people's bugs, especially since some workarounds -may imply a performance penalty. - - - - -GCC 2.96 does not allow | (pipe) characters in assembler -comments because it supports Intel as well as AT&T Syntax and the -| character is a symbol in the Intel variant. The -problem is that it silently ignores the whole -assembler block. This is supposedly fixed now, GCC prints a warning instead -of skipping the block. - - - -The present: - -Red Hat says that GCC 2.96-85 and above is fixed. The situation has indeed -improved, yet we still see problem reports on our mailing lists that -disappear with a different compiler. In any case it does not matter any -longer. Hopefully a maturing GCC 3.x will solve the issue for good. If you -want to compile with 2.96 give the -flag to configure. Remember that you are on your own -and do not report any bugs. If you do, you will only -get banned from our mailing list because we have had more than enough flame -wars over GCC 2.96. Please let the matter rest. - - - - -If you have problems with GCC 2.96, you can get 2.96-85 packages from the -Red Hat ftp server, or just -go for the 3.0.4 packages offered for version 7.2 and later. You can also -get gcc-3.2.3-37 packages -(unofficial, but working fine) -and you can install them along the gcc-2.96 you already have. -MPlayer will detect it and use 3.2 instead of 2.96. -If you do not want to or cannot use the binary packages, here is how you can -compile GCC 3 from source: - - - - - Go to the - GCC mirrors page - page and download gcc-core-XXX.tar.gz - where XXX is the version number. This includes the complete - C compiler and is sufficient for MPlayer. If you also want - C++, Java or some of the other advanced GCC features - gcc-XXX.tar.gz may better suit your needs. - - - Extract the archive with - tar -xvzf gcc-core-XXX.tar.gz - - - GCC is not built inside the source directory itself like most programs, - but needs a build directory outside the source directory. Thus you need - to create this directory via - mkdir gcc-build - - - Then you can proceed to configure gcc in the build directory, but you - need the configure from the source directory: - -cd gcc-build -../gcc-3.XXX/configure - - - Compile GCC by issuing this command in the build directory: - make bootstrap - - - Now you can install GCC (as root) by typing - make install - - - - - - -Binary distribution - - -MPlayer previously contained source from the -OpenDivX project, which disallows binary redistribution.This code has been -removed in version 0.90-pre1 and the remaining file divx_vbr.c -that is derived from OpenDivX sources has been put under the GPL by its authors -as of version 0.90pre9. You are now welcome to create binary packages as you -see fit. - - - -Another impediment to binary redistribution was compiletime optimizations -for CPU architecture. MPlayer now supports -runtime CPU detection (pass the - to configure). -It is disabled by default because it implies a small speed sacrifice, but it is -now possible to create binaries that run on different members of the Intel -compatible CPU family. - - - - - -nVidia - - -We dislike the fact that nVidia -only provides binary drivers (for use with XFree86), which are often buggy. -We have had many reports on -mplayer-users -about problems related to these closed-source drivers -and their poor quality, instability and poor user and expert support. -Many of these problems/issues keep appearing repeatedly. -We have been contacted by nVidia lately, and they said these bugs do not -exist, instability is caused by bad AGP chips, and they received no reports -of driver bugs (like the purple line). So if you have a problem with your -nVidia card, you are advised to update the nVidia driver and/or buy a new -motherboard or ask nVidia to supply open-source drivers. In any case, if -you are using the nVidia binary drivers and facing driver related problems, -please be aware that you will receive very little help from our side -because we have little power to help in this matter. - - - - - -Joe Barr - - -Joe Barr became infamous in december 2001 by writing a less than favorable -MPlayer review called -MPlayer: The project from hell. -He found MPlayer hard to install, and concluded -that the developers were unfriendly and the documentation -incomplete and insulting. You be the judge of that. -He went on to mention Arpi negatively in his -10 Linux predictions for 2002. -In a followup review of xine called -A streaming media player for the rest of us -he continued stirring up controversy. Ironically at the end of that article -he quotes his exchange with Günter Bartsch, the original author of xine, -that perfectly summarizes the whole situation: - -
-However, he also went on to say that he was "surprised" by my column -about Mplayer and thought it was unfair, reminding -me that it is a free software project. "If you don't like it," -Bartsch said, "you're free not to use it." -
- -Almost two years later in october 2003 he wrote another review called -Mplayer revisited -(wrong spelling preserved). -In it he came to the following conclusions: - -
-I would have to say that there have been improvements in the number of -features, in performance, and in documentation. It's still not the -easiest install in the world, especially for newbies, but it's a -little better than it used to be. -
- -and - -
-But more importantly, I didn't notice any recent comments about user -abuse. I think I deserve some of the credit for that, even if I do say -so myself. Arpi and the rest of the project team must feel that way -too, because they have taken care to remember me in a special section -of the documentation included in the tarball. Like I said at the -start, some things haven't changed at all. -
- -We could not have summarized our feelings towards Joe Barr better: -"It's still not the fairest or best researched article in the world, -but it's better than it used to be." Hopefully the next time around -we will meet each other's expectations. However, the credit for maturity -goes to our increasing age only, and maybe to being weary of flame wars. -
- -
-