[Mplayer-cvslog] CVS: main/DOCS users_against_developers.html,1.16,1.17

Winner of tha face compo gabucino at mplayerhq.hu
Wed May 8 20:00:29 CEST 2002 

Update of /cvsroot/mplayer/main/DOCS
In directory mail:/var/tmp.root/cvs-serv7630

Modified Files:
	users_against_developers.html 
Log Message:
applied Nilmoni Debian's (and Diego Burrick) patch


Index: users_against_developers.html
===================================================================
RCS file: /cvsroot/mplayer/main/DOCS/users_against_developers.html,v
retrieving revision 1.16
retrieving revision 1.17
diff -u -r1.16 -r1.17
--- users_against_developers.html	5 May 2002 05:04:54 -0000	1.16
+++ users_against_developers.html	8 May 2002 18:00:26 -0000	1.17
@@ -12,130 +12,172 @@
 
 <FONT CLASS="text">
 
-<P><B><I>In medias res</I></B></P>
+<P><B>In medias res</B></P>
 
-<P>There are two major topic which always causes huge dispute and flame on the
-<A HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">mplayer-users</A>
-mailing list. Number one is of course the topic of the</P>
-
-<A NAME=gcc><P><B><I>GCC 2.96 series</I></B></P>
-
-<P><B>Also read <A HREF="gcc-2.96-3.0.html">this</A> text !!!</B></P>
-
-<P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The
-best of them was 2.95.3 . Please note the style of the version numbering.
-This is how the GCC team numbers their compilers. The 2.95 series are good.
-We never ever saw anything that was miscompiled because of the 2.95.3's faultiness.</P>
-
-<P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
-with their distributions. Note the version numbering. This should be the GCC
-team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0)
-They patched it very deep, and used this version in the distrib because 3.0
-wasn't out at time, and they wanted IA64 support ASAP (business reasons).
-Oh, and GCC 2.95 miscompiles bash on the s390 architecture...</P>
-
-<P>The <I>facts</I> : <B>MPlayer</B>'s compile process needs the
-<CODE>--disable-gcc-checking</CODE> to proceed upon detecting a GCC version of
-2.96 (apparently it needs this option on <B>egcs</B> too. It's because we don't
-test <B>MPlayer</B> on egcs. Pardon us, but we rather develop <B>MPlayer</B>).
-If you know <B>MPlayer</B>, you should know that it has great speed. It
-achieves this by having overoptimized MMX/SSE/3DNow/etc codes, fastmemcpy, and
-lots of other features. <B>MPlayer</B> contained MMX/3DNow instructions in a
-syntax that all Linux compilers accept it... except RedHat's GCC (it's more
-standard compliant). It simply <B><I>skips</I></B> them. It doesn't give
-errors. It doesn't give warnings. <B>And</B>, there is Lame. With gcc 2.96, its quality check
-(<CODE>make test</CODE> after compiling) <I>doesn't even run !!!</I>
-But hey, it compiles bash on s390 and IA64.</P>
-
-<P>The <I>statements</I> : most developers around the world begun having
-bad feelings about RedHat's GCC 2.96 , and told their RedHat users to
-compile with other compiler than 2.96 . RedHat users' disappointment slowly
-went into anger. What was all good
-for, apart from giving headaches to developers, putting oil on anti-RedHat
-flame, confusing users? The answer, I do not know.</P>
-
-<P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above
-is fixed, and works properly. Note the versioning. They should have started
-with something like this. What about GCC 2.96.85 ? It doesn't matter now.
-I don't search, but I still see bugs with 2.96 . It doesn't matter now,
-hopefully now <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
-Towards a deep patched 3.0...
-</P>
-
-<P><I>What I don't understand</I> is why are we hated by RedHat users for
-putting warning messages, and stay-away documents in <B>MPlayer</B> .
-Why are we called "brain damaged", "total asshole", "childish" by
-<B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> .
-They even considered forking <B>MPlayer</B> for themselves. RedHat users.
-Why? It's RedHat that made the compiler, why do <U>you</U> have to hate us?
-Are you <U>that</U> fellow RedHat worshippers? Please stop it. We don't hold
-a grudge against users, doesn't matter how loud you advertise its contrary.
-Please go flame Linus Torvalds, the DRI developers (oh, now I know why
-there were laid off by VA!), the Wine, avifile. Even if we are arrogant,
-are we not the same as the previously listed ones? Why do <B>we</B> have
-to suffer from your unrightful wrath?</P>
+<P>There are two major topics which always cause huge dispute and flame on the
+<A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A>
+mailing list. Number one is the topic of the</P>
+
+<P><A NAME=gcc><B>GCC 2.96 series</B></A></P>
+
+<P><B>The background:</B> The GCC <B>2.95</B> 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, <B>Red Hat</B> included a heavily
+patched CVS version of GCC in their distribution and named it <B>2.96</B>. 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 <B>Mandrake</B>
+also followed Red Hat's example and started shipping GCC 2.96 with their
+Linux-Mandrake 8.0 series. </P>
+
+<P><B>The statements:</B> The GCC team disclaimed any link with GCC 2.96 and issued an
+<A HREF="http://gcc.gnu.org/gcc-2.96.html">official response</A> to GCC 2.96.
+Many developers around the world began having problems with GCC 2.96, and
+started recommending other compilers. Examples are
+<A HREF="http://www.apachelabs.org/apr-mbox/200106.mbox/%3c20010623194228.C25512@ebuilt.com%3e">Apache</A>,
+<A HREF="http://www.mysql.com/downloads/mysql-3.23.html">MySQL</A>,
+<A HREF="http://avifile.sourceforge.net/news-old1.htm">avifile</A> and
+<A HREF="http://www.winehq.com/news/?view=92#RH 7.1 gcc fixes compiler bug">Wine</A>.
+Other interesting links are 
+<A HREF="http://www.realtimelinux.org/archives/rtai/20017/0144.html">Real time Linux</A>,
+<A HREF="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html">
+Linux kernel news flash about kernel 2.4.17</A> and
+<A HREF="http://www.voy.com/3516/572.html">Voy Forum</A>.
+<B>MPlayer</B> 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.</P>
+
+<P>You can read about the other side of the story
+<A HREF="http://www.bero.org/gcc296.html">here</A>.
+GCC 2.96 does not allow | (pipe) characters in assembler comments
+because it supports Intel as well as AT&amp;T Syntax and the | character is a
+symbol in the Intel variant. The problem is that it <B>silently</B> ignores the
+whole assembler block. This is supposedly fixed now, GCC prints a warning instead
+of skipping the block.</P>
+
+<P><B>The present:</B> 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 <CODE>--disable-gcc-checking</CODE>
+flag to configure. Remember that you are on your own and <B>do not report any
+bugs</B>. 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.</P>
 
-<P><A HREF="mailto:willis_matthew at yahoo.com">Matt Willis</A> kindly submitted
-  a simple GCC-3.0.3 compiling howto, I'm copying it here:</P>
+<P>If you have problems with GCC 2.96, here is how you can get GCC 3.0.4 to work
+(submitted by <A HREF="mailto:willis_matthew at yahoo.com">Matt Willis</A>):</P>
 
-<P>
 <UL>
- <LI>Download gcc. Go to the <A
-  HREF="http://gcc.gnu.org/mirrors.html">http://gcc.gnu.org/mirrors.html</A>
-  page.
-   I downloaded the following, but you don't need everything:<BR>
-    <CODE>gcc-g++-3.0.3.tar.gz<BR>
-    gcc-objc-3.0.3.tar.gz<BR>
-    gcc-3.0.3.tar.gz<BR>
-    gcc-g77-3.0.3.tar.gz<BR>
-    gcc-testsuite-3.0.3.tar.gz<BR>
-    gcc-core-3.0.3.tar.gz<BR>
-    gcc-java-3.0.3.tar.gz</CODE>
+  <LI>Go to the
+    <A HREF="http://gcc.gnu.org/mirrors.html">GCC mirrors page</A>
+    page and download the following (you may not need everything):<BR>
+    <CODE>gcc-g++-3.0.4.tar.gz<BR>
+    gcc-objc-3.0.4.tar.gz<BR>
+    gcc-3.0.4.tar.gz<BR>
+    gcc-g77-3.0.4.tar.gz<BR>
+    gcc-testsuite-3.0.4.tar.gz<BR>
+    gcc-core-3.0.4.tar.gz<BR>
+    gcc-java-3.0.4.tar.gz</CODE>
   </LI>
+  <LI>Unpack the files, make a build directory, and build:<BR>
+    <CODE>tar -xvzf gcc-*3.0.4.tar.gz<BR>
+     mkdir gcc-build<BR>
+     cd gcc-build<BR>
+     ../gcc-3.0.4/configure --prefix=/opt --program-suffix=-3.0.4<BR>
+     make bootstrap; mkdir -p /opt; make install</CODE></LI>
+  <LI>Set your path to include <CODE>/opt/bin</CODE><BR>
+    <CODE>export PATH=/opt/bin:${PATH}</CODE></LI>
+</UL>
 
-  <LI>Unpack the files, make a build directory, and build<CODE><PRE>
-     tar xvzf gcc-*3.0.3.tar.gz
-     mkdir gcc-build; cd gcc-build
-     ../gcc-3.0.3/configure --prefix=/opt --program-suffix=-3.0.3
-     make bootstrap; mkdir -p /opt; make install</PRE></CODE>
-
-  <LI>Set your path to include /opt/bin<BR>
-     <CODE>export PATH=/opt/bin:${PATH}</CODE>
+<P><A NAME=binary><B>Binary distribution of MPlayer</B></A></P>
 
-  <LI>Now you can build MPlayer.</LI>
-</UL>
+<P>This was the second big problem but has been solved as of version
+0.90-pre1. <B>MPlayer</B> previously contained source from the OpenDivX project,
+which disallows binary redistribution. This code has been removed and you are now
+welcome to create binary packages as you see fit.</P>
+
+<P>Another impediment to binary redistribution was compiletime optimizations
+for CPU architecture.  <B>MPlayer</B> now supports runtime CPU detection.
+Although this implies a small speed sacrifice, it is now possible to create
+binaries that run on different members of the Intel CPU family. For optimum
+performance you may wish to disable runtime CPU detection before compilation
+(<CODE>configure --disable-runtime-cpudetection</CODE>).</P>
+
+<P><A NAME=nvidia><B>nVidia</B></A></P>
+
+<P>We dislike the fact that <A HREF="http://www.nvidia.com">nVidia</A>
+ only provides binary drivers (for use with XFree86), which are often buggy. 
+We have had many reports on
+<A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A>
+about problems related to these closed-source drivers
+and their poor quality, instability and poor user and expert support.
+Here is an example from the
+<A HREF="http://www.nvnews.net/forum/showthread.php?s=fda5725bc2151e29453b2da3bd5d2930&threadid=14306">
+nVidia Linux Forum</A>.
+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.</P>
+
+<P><A NAME=kotsog><B>Joe Barr</B></A></P>
+
+<P>Joe Barr became infamous by writing a less than favorable
+<A HREF="http://www.linuxworld.com/site-stories/2001/1214.mplayer.html">
+<B>MPlayer</B> review</A>. He found <B>MPlayer</B> hard to install, but then
+again he is not very fond of
+<A HREF="http://www.linuxworld.com/linuxworld/lw-2000-06/lw-06-exam.html">reading documentation</A>.
+He also concluded that the developers were unfriendly and the documentation
+incomplete and insulting. You be the judge.
+He went on to mention <B>MPlayer</B> negatively in his
+<A HREF="http://www.linuxworld.com/site-stories/2001/1227.predictions.html">10 Linux predictions for 2002</A>
+In a followup
+<A HREF="http://www.linuxworld.com/site-stories/2002/0125.xine.html">review of xine</A>
+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:</P>
+
+<BLOCKQUOTE>
+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." 
+</BLOCKQUOTE>
 </P>
 
-<A NAME=nvidia><P><B><I>NVidia</I></B></P>
+<P>He does not reply to our mails. His editor does not reply to our mails.
+Here are some quotes from different people about Joe Barr, so you can form your
+own opinion:</P>
 
-<P>We don't like nvidia's binary drives, their quality, unstability,
-non-existant user support, always appearing new bugs. And most users behave
-the same. We've been contacted by NVidia lately, and they said these bugs
-don't exist, unstability is caused by bad AGP chips, and they received
-no reports of driver bugs (the purple line, for example). So: if you have
-problem with your NVidia, update the nvidia driver and/or buy a new
-motherboard.</P>
-
-<A NAME=kotsog><P><B><I>Joe Barr</I></B></P>
-
-<P>He doesn't reply to our mails. His editor doesn't reply to our mails.
-The net is full with his false statements and accusitions (he apparently
-doesn't like for example the BSD guys, because of their different viewpoints
-[about what?]).</P>
-
-<P>Now some quotes from different people about Joe Barr (just for you
-understand why doesn't he matter at all):</P>
+<P>Marc Rassbach has <A HREF="http://daily.daemonnews.org/view_story.php3?story_id=2102">something to say</A>
+about the man
+</P>
 
-<P><I>"You may all remember the LinuxWorld 2000, when he claimed that Linus T said
+<BLOCKQUOTE>
+You may all remember the LinuxWorld 2000, when he claimed that Linus T said
 that 'FreeBSD is just a handful of programmers'. Linus said NOTHING of the
 sort. When Joe was called on this, his reaction was to call BSD supporters
-assholes and jerks."</I></P>
+assholes and jerks.
+</BLOCKQUOTE>
 
-<P><I>"He's interesting, but not good at avoiding, um... controversy.  Joe Barr
+<P>A <A HREF="http://www.mplayerhq.hu/pipermail/mplayer-users/2001-December/009118.html">quote</A>
+from Robert Munro on the
+<A HREF="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</A>
+mailinglist:</P>
+
+<BLOCKQUOTE>
+<P>He's interesting, but not good at avoiding, um... controversy.  Joe Barr
 used to be one of the regulars on Will Zachmann's Canopus forum on Compuserve,
-years ago.  He was an OS/2 advocate then (I was an OS/2 fan too).
-He used to go over-the-top, flaming people, and I suspect he had some hard
+years ago.  He was an OS/2 advocate then (I was an OS/2 fan too).<P>
+
+<P>He used to go over-the-top, flaming people, and I suspect he had some hard
 times, then. He's mellowed some, judging by his columns recently.  Moderately
-subtle humor was not his mode in those earlier days, not at all."</I></P>
+subtle humor was not his mode in those earlier days, not at all.</P>
+</BLOCKQUOTE>
 
 </HTML>

More information about the MPlayer-cvslog mailing list