Mercurial > mplayer.hg
annotate DOCS/xml/en/users-vs-dev.xml @ 14113:4c91818a371c
link updates
author | diego |
---|---|
date | Sun, 05 Dec 2004 23:54:49 +0000 |
parents | 7895a1b73828 |
children | 1a16342f11a2 |
rev | line source |
---|---|
9675 | 1 <?xml version="1.0" encoding="iso-8859-1"?> |
10913
49b1a67e7381
Add revision keyword to english xml files, to ease translation synchronization
lumag
parents:
10144
diff
changeset
|
2 <!-- $Revision$ --> |
9675 | 3 <appendix id="users-vs-dev"> |
4 <title>Developer cries</title> | |
5 | |
6 <sect1 id="gcc-296"> | |
7 <title>GCC 2.96</title> | |
8 | |
9 <formalpara> | |
10 <title>The background:</title> | |
11 <para> | |
10111 | 12 The GCC <emphasis role="bold">2.95</emphasis> series is an official GNU release and |
9675 | 13 version 2.95.3 of GCC is the most bug-free in that series. We have never |
14 noticed compilation problems that we could trace to gcc-2.95.3. Starting | |
10111 | 15 with Red Hat Linux 7.0, <emphasis role="bold">Red Hat</emphasis> included a heavily |
9675 | 16 patched CVS version of GCC in their distribution and named it |
10111 | 17 <emphasis role="bold">2.96</emphasis>. Red Hat included this version in the |
9675 | 18 distribution because GCC 3.0 was not finished at the time, and they needed |
19 a compiler that worked well on all of their supported platforms, including | |
10111 | 20 IA64 and s390. The Linux distributor <emphasis role="bold">Mandrake</emphasis> also |
9675 | 21 followed Red Hat's example and started shipping GCC 2.96 with their |
22 Linux-Mandrake 8.0 series. | |
23 </para> | |
24 </formalpara> | |
25 | |
26 <formalpara> | |
27 <title>The statements:</title> | |
28 <para> | |
29 The GCC team disclaimed any link with GCC 2.96 and issued an | |
30 <ulink url="http://gcc.gnu.org/gcc-2.96.html">official response</ulink> | |
10111 | 31 to GCC 2.96. Many developers around the world began having problems with |
14113 | 32 GCC 2.96, and started recommending other compilers like |
33 <ulink url="http://avifile.sf.net/news-old1.htm">avifile</ulink> and others. | |
12229 | 34 Other interesting links are |
9675 | 35 <ulink url="http://www.atnf.csiro.au/people/rgooch/linux/docs/kernel-newsflash.html"> |
36 Linux kernel news flash about kernel 2.4.17</ulink> | |
37 and | |
38 <ulink url="http://www.voy.com/3516/572.html">Voy Forum</ulink>. | |
39 <application>MPlayer</application> also suffered from intermittent problems | |
40 that were all solved by switching to a different version of GCC. Several | |
41 projects started implementing workarounds for some of the 2.96 issues, but | |
42 we refused to fix other people's bugs, especially since some workarounds | |
43 may imply a performance penalty. | |
44 </para> | |
45 </formalpara> | |
46 | |
47 <para> | |
48 GCC 2.96 does not allow <literal>|</literal> (pipe) characters in assembler | |
49 comments because it supports Intel as well as AT&T Syntax and the | |
50 <literal>|</literal> character is a symbol in the Intel variant. The | |
51 problem is that it <emphasis>silently</emphasis> ignores the whole | |
52 assembler block. This is supposedly fixed now, GCC prints a warning instead | |
53 of skipping the block. | |
54 </para> | |
55 | |
56 <formalpara> | |
57 <title>The present:</title> | |
58 <para> | |
59 Red Hat says that GCC 2.96-85 and above is fixed. The situation has indeed | |
60 improved, yet we still see problem reports on our mailing lists that | |
61 disappear with a different compiler. In any case it does not matter any | |
62 longer. Hopefully a maturing GCC 3.x will solve the issue for good. If you | |
63 want to compile with 2.96 give the <option>--disable-gcc-checking</option> | |
64 flag to <filename>configure</filename>. Remember that you are on your own | |
10111 | 65 and <emphasis role="bold">do not report any bugs</emphasis>. If you do, you will only |
9675 | 66 get banned from our mailing list because we have had more than enough flame |
67 wars over GCC 2.96. Please let the matter rest. | |
68 </para> | |
69 </formalpara> | |
70 | |
71 <para> | |
72 If you have problems with GCC 2.96, you can get 2.96-85 packages from the | |
73 Red Hat <ulink url="ftp://updates.redhat.com">ftp server</ulink>, or just | |
74 go for the 3.0.4 packages offered for version 7.2 and later. You can also | |
14113 | 75 get <ulink url="ftp://people.redhat.com/jakub/gcc/errata/3.2.3-37/">gcc-3.2.3-37 packages</ulink> |
9675 | 76 (unofficial, but working fine) |
11540 | 77 and you can install them along the gcc-2.96 you already have. |
78 <application>MPlayer</application> will detect it and use 3.2 instead of 2.96. | |
79 If you do not want to or cannot use the binary packages, here is how you can | |
80 compile GCC 3 from source: | |
9675 | 81 </para> |
82 | |
83 <procedure> | |
84 <step><para> | |
85 Go to the | |
10111 | 86 <ulink url="http://gcc.gnu.org/mirrors.html">GCC mirrors page</ulink> |
87 page and download <filename>gcc-core-<replaceable>XXX</replaceable>.tar.gz</filename> | |
88 where <replaceable>XXX</replaceable> is the version number. This includes the complete | |
89 C compiler and is sufficient for <application>MPlayer</application>. If you also want | |
90 C++, Java or some of the other advanced GCC features | |
91 <filename>gcc-<replaceable>XXX</replaceable>.tar.gz</filename> may better suit your needs. | |
9675 | 92 </para></step> |
93 <step><para> | |
94 Extract the archive with | |
10111 | 95 <screen>tar -xvzf gcc-core-<replaceable>XXX</replaceable>.tar.gz</screen> |
9675 | 96 </para></step> |
97 <step><para> | |
98 GCC is not built inside the source directory itself like most programs, | |
99 but needs a build directory outside the source directory. Thus you need | |
100 to create this directory via | |
101 <screen>mkdir gcc-build</screen> | |
102 </para></step> | |
103 <step><para> | |
104 Then you can proceed to configure gcc in the build directory, but you | |
105 need the configure from the source directory: | |
106 <screen> | |
107 cd gcc-build | |
10111 | 108 ../gcc-3.<replaceable>XXX</replaceable>/configure</screen> |
9675 | 109 </para></step> |
110 <step><para> | |
111 Compile GCC by issuing this command in the build directory: | |
112 <screen>make bootstrap</screen> | |
113 </para></step> | |
114 <step><para> | |
115 Now you can install GCC (as root) by typing | |
116 <screen>make install</screen> | |
117 </para></step> | |
118 </procedure> | |
119 </sect1> | |
120 | |
121 | |
122 <sect1 id="mplayer-binary"> | |
123 <title>Binary distribution</title> | |
124 | |
125 <para> | |
126 <application>MPlayer</application> previously contained source from the | |
127 OpenDivX project, which disallows binary redistribution.This code has been | |
128 removed in version 0.90-pre1 and the remaining file <filename>divx_vbr.c</filename> | |
129 that is derived from OpenDivX sources has been put under the GPL by its authors | |
130 as of version 0.90pre9. You are now welcome to create binary packages as you | |
131 see fit. | |
132 </para> | |
133 | |
134 <para> | |
135 Another impediment to binary redistribution was compiletime optimizations | |
10111 | 136 for CPU architecture. <application>MPlayer</application> now supports |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
137 runtime CPU detection (pass the |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
138 <option>--enable-runtime-cpudetection</option> to <command>configure</command>). |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
139 It is disabled by default because it implies a small speed sacrifice, but it is |
9675 | 140 now possible to create binaries that run on different members of the Intel |
11450
3c42df11d60e
Intel --> Intel compatible, inspired by Maciej Paszta <paszczi@go2.pl>
diego
parents:
11290
diff
changeset
|
141 compatible CPU family. |
9675 | 142 </para> |
143 </sect1> | |
144 | |
145 | |
146 <sect1 id="nvidia-opinions"> | |
147 <title>nVidia</title> | |
148 | |
149 <para> | |
150 We dislike the fact that <ulink url="http://www.nvidia.com">nVidia</ulink> | |
12815 | 151 only provides binary drivers (for use with XFree86), which are often buggy. |
9675 | 152 We have had many reports on |
153 <ulink url="http://mplayerhq.hu/pipermail/mplayer-users/">mplayer-users</ulink> | |
154 about problems related to these closed-source drivers | |
155 and their poor quality, instability and poor user and expert support. | |
156 Many of these problems/issues keep appearing repeatedly. | |
157 We have been contacted by nVidia lately, and they said these bugs do not | |
158 exist, instability is caused by bad AGP chips, and they received no reports | |
159 of driver bugs (like the purple line). So if you have a problem with your | |
160 nVidia card, you are advised to update the nVidia driver and/or buy a new | |
161 motherboard or ask nVidia to supply open-source drivers. In any case, if | |
162 you are using the nVidia binary drivers and facing driver related problems, | |
163 please be aware that you will receive very little help from our side | |
164 because we have little power to help in this matter. | |
165 </para> | |
166 </sect1> | |
167 | |
168 | |
169 <sect1 id="joe-barr"> | |
170 <title>Joe Barr</title> | |
171 | |
172 <para> | |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
173 Joe Barr became infamous in december 2001 by writing a less than favorable |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
174 <application>MPlayer</application> review called |
11540 | 175 <ulink url="http://www.linuxworld.com/story/32880.htm"><application>MPlayer</application>: The project from hell</ulink>. |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
176 He found <application>MPlayer</application> hard to install, and concluded |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
177 that the developers were unfriendly and the documentation |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
178 incomplete and insulting. You be the judge of that. |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
179 He went on to mention Arpi negatively in his |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
180 <ulink url="http://www.linuxworld.com/story/32887.htm">10 Linux predictions for 2002</ulink>. |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
181 In a followup review of xine called |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
182 <ulink url="http://www.linuxworld.com/story/32716.htm">A streaming media player for the rest of us</ulink> |
9675 | 183 he continued stirring up controversy. Ironically at the end of that article |
10144 | 184 he quotes his exchange with Günter Bartsch, the original author of <application>xine</application>, |
9675 | 185 that perfectly summarizes the whole situation: |
186 | |
187 <blockquote><para> | |
12229 | 188 However, he also went on to say that he was "surprised" by my column |
189 about <application>Mplayer</application> and thought it was unfair, reminding | |
190 me that it is a free software project. "If you don't like it," | |
191 Bartsch said, "you're free not to use it." | |
9675 | 192 </para></blockquote> |
193 | |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
194 Almost two years later in october 2003 he wrote another review called |
12229 | 195 <ulink url="http://www.newsforge.com/article.pl?sid=03/10/02/0343200">Mplayer revisited</ulink> |
196 (wrong spelling preserved). | |
11290 | 197 In it he came to the following conclusions: |
9675 | 198 |
199 <blockquote><para> | |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
200 I would have to say that there have been improvements in the number of |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
201 features, in performance, and in documentation. It's still not the |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
202 easiest install in the world, especially for newbies, but it's a |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
203 little better than it used to be. |
9675 | 204 </para></blockquote> |
205 | |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
206 and |
9675 | 207 |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
208 <blockquote><para> |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
209 But more importantly, I didn't notice any recent comments about user |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
210 abuse. I think I deserve some of the credit for that, even if I do say |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
211 so myself. Arpi and the rest of the project team must feel that way |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
212 too, because they have taken care to remember me in a special section |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
213 of the documentation included in the tarball. Like I said at the |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
214 start, some things haven't changed at all. |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
215 </para></blockquote> |
9675 | 216 |
11278
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
217 We could not have summarized our feelings towards Joe Barr better: |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
218 "It's still not the fairest or best researched article in the world, |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
219 but it's better than it used to be." Hopefully the next time around |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
220 we will meet each other's expectations. However, the credit for maturity |
ff78d7ceecaa
Dead links updated or removed, Joe Barr section rewritten taking into
diego
parents:
10913
diff
changeset
|
221 goes to our increasing age only, and maybe to being weary of flame wars. |
9675 | 222 </para> |
223 | |
224 </sect1> | |
225 </appendix> |