summaryrefslogtreecommitdiffstats
path: root/DOCS
diff options
context:
space:
mode:
authordiego <diego@b3059339-0415-0410-9bf9-f77b7e298cf2>2006-09-24 16:57:57 +0000
committerdiego <diego@b3059339-0415-0410-9bf9-f77b7e298cf2>2006-09-24 16:57:57 +0000
commit8f8276e366535759a8058f67471eb0847fa92ec4 (patch)
tree1276d302d73c337d4279b549655add0f5e3fe6a1 /DOCS
parent74727dc564db81e4748423668ba618e6c69c2070 (diff)
downloadmpv-8f8276e366535759a8058f67471eb0847fa92ec4.tar.bz2
mpv-8f8276e366535759a8058f67471eb0847fa92ec4.tar.xz
Remove outdate, obsolete and inflammatory rants section.
git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@19973 b3059339-0415-0410-9bf9-f77b7e298cf2
Diffstat (limited to 'DOCS')
-rw-r--r--DOCS/xml/en/documentation.xml1
-rw-r--r--DOCS/xml/en/users-vs-dev.xml226
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&amp;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 &quot;surprised&quot; by my column
-about <application>Mplayer</application> and thought it was unfair, reminding
-me that it is a free software project. &quot;If you don't like it,&quot;
-Bartsch said, &quot;you're free not to use it.&quot;
-</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:
-&quot;It's still not the fairest or best researched article in the world,
-but it's better than it used to be.&quot; 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>