diff options
Diffstat (limited to 'DOCS/xml')
| -rw-r--r-- | DOCS/xml/en/documentation.xml | 1 | ||||
| -rw-r--r-- | DOCS/xml/en/users-vs-dev.xml | 226 |
2 files changed, 0 insertions, 227 deletions
diff --git a/DOCS/xml/en/documentation.xml b/DOCS/xml/en/documentation.xml index 1b3592bfec..ffb00c8e2d 100644 --- a/DOCS/xml/en/documentation.xml +++ b/DOCS/xml/en/documentation.xml @@ -196,4 +196,3 @@ can be distributed under the terms of the GNU General Public License Version 2. &bugreports.xml; &bugs.xml; &skin.xml; -&users-vs-dev.xml; diff --git a/DOCS/xml/en/users-vs-dev.xml b/DOCS/xml/en/users-vs-dev.xml deleted file mode 100644 index 4c7abca34c..0000000000 --- a/DOCS/xml/en/users-vs-dev.xml +++ /dev/null @@ -1,226 +0,0 @@ -<?xml version="1.0" encoding="iso-8859-1"?> -<!-- $Revision$ --> -<appendix id="users-vs-dev"> -<title>Developer cries</title> - -<sect1 id="gcc-296"> -<title>GCC 2.96</title> - -<formalpara> -<title>The background:</title> -<para> -The GCC <emphasis role="bold">2.95</emphasis> 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, <emphasis role="bold">Red Hat</emphasis> included a heavily -patched CVS version of GCC in their distribution and named it -<emphasis role="bold">2.96</emphasis>. 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 <emphasis role="bold">Mandrake</emphasis> -(now Mandriva) also followed Red Hat's example and started shipping GCC 2.96 -with their Linux-Mandrake 8.0 series. -</para> -</formalpara> - -<formalpara> -<title>The statements:</title> -<para> -The GCC team disclaimed any link with GCC 2.96 and issued an -<ulink url="http://gcc.gnu.org/gcc-2.96.html">official response</ulink> -to GCC 2.96. Many developers around the world began having problems with -GCC 2.96, and several projects, -<ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink> among them, -started recommending other compilers. -Other interesting links are -<ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html"> -Linux kernel news flash about kernel 2.4.17</ulink> -and -<ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>. -<application>MPlayer</application> 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. -</para> -</formalpara> - -<para> -GCC 2.96 does not allow <literal>|</literal> (pipe) characters in assembler -comments because it supports Intel as well as AT&T Syntax and the -<literal>|</literal> character is a symbol in the Intel variant. The -problem is that it <emphasis>silently</emphasis> ignores the whole -assembler block. This is supposedly fixed now, GCC prints a warning instead -of skipping the block. -</para> - -<formalpara> -<title>The present:</title> -<para> -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 <option>--disable-gcc-checking</option> -flag to <filename>configure</filename>. Remember that you are on your own -and <emphasis role="bold">do not report any bugs</emphasis>. 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. -</para> -</formalpara> - -<para> -If you have problems with GCC 2.96, you can get 2.96-85 packages from the -Red Hat <ulink url="ftp://updates.redhat.com">ftp server</ulink>, or just -go for the 3.0.4 packages offered for version 7.2 and later. You can also -get <ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-37/">gcc-3.2.3-37 packages</ulink> -(unofficial, but working fine) -and you can install them along the gcc-2.96 you already have. -<application>MPlayer</application> 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: -</para> - -<procedure> -<step><para> - Go to the - <ulink url="http://gcc.gnu.org/mirrors.html">GCC mirrors page</ulink> - page and download <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename> - where <replaceable>XXX</replaceable> is the version number. This includes the complete - C compiler and is sufficient for <application>MPlayer</application>. If you also want - C++, Java or some of the other advanced GCC features - <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> may better suit your needs. - </para></step> -<step><para> - Extract the archive with - <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen> - </para></step> -<step><para> - 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 - <screen>mkdir gcc-build</screen> - </para></step> -<step><para> - Then you can proceed to configure gcc in the build directory, but you - need the configure from the source directory: - <screen> -cd gcc-build -../gcc-3.<replaceable>XXX</replaceable>/configure</screen> - </para></step> -<step><para> - Compile GCC by issuing this command in the build directory: - <screen>make bootstrap</screen> - </para></step> -<step><para> - Now you can install GCC (as root) by typing - <screen>make install</screen> - </para></step> -</procedure> -</sect1> - - -<sect1 id="mplayer-binary"> -<title>Binary distribution</title> - -<para> -<application>MPlayer</application> 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 <filename>divx_vbr.c</filename> -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. -</para> - -<para> -Another impediment to binary redistribution was compiletime optimizations -for CPU architecture. <application>MPlayer</application> now supports -runtime CPU detection (pass the -<option>--enable-runtime-cpudetection</option> to <command>configure</command>). -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. -</para> -</sect1> - - -<sect1 id="nvidia-opinions"> -<title>nVidia</title> - -<para> -We dislike the fact that <ulink url="http://www.nvidia.com">nVidia</ulink> -only provides binary drivers (for use with XFree86), which are often buggy. -We have had many reports on -<ulink url="http://lists.mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink> -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. -</para> -</sect1> - - -<sect1 id="joe-barr"> -<title>Joe Barr</title> - -<para> -Joe Barr became infamous in december 2001 by writing a less than favorable -<application>MPlayer</application> review called -<ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: The project from hell</ulink>. -He found <application>MPlayer</application> 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 -<ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002</ulink>. -In a followup review of xine called -<ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us</ulink> -he continued stirring up controversy. Ironically at the end of that article -he quotes his exchange with Günter Bartsch, the original author of <application>xine</application>, -that perfectly summarizes the whole situation: - -<blockquote><para> -However, he also went on to say that he was "surprised" by my column -about <application>Mplayer</application> 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." -</para></blockquote> - -Almost two years later in october 2003 he wrote another review called -<ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink> -(wrong spelling preserved). -In it he came to the following conclusions: - -<blockquote><para> -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. -</para></blockquote> - -and - -<blockquote><para> -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. -</para></blockquote> - -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. -</para> - -</sect1> -</appendix> |