Mercurial > mplayer.hg

comparison DOCS/Polish/users_against_developers.html @ 3523:dadab20dc2b4

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
began updated translation by <nell@skrzynka.pl> (work-in-progress)
author gabucino
date Sun, 16 Dec 2001 11:51:02 +0000
parents
children 001c05d69f6c
comparison
equal deleted inserted replaced
3522:34df0f546afc 3523:dadab20dc2b4
1 <HTML>
2 <BODY BGCOLOR=white>
3
4 <FONT face="Verdana, Arial, Helvetica, sans-serif" size=2>
5
6 <P><B><I>In medias res</I></B></P>
7
8 <P>There are two major topic which always causes huge dispute and flame on the
9 <A HREF="http://www.MPlayerHQ.hu/cgi-bin/htsearch">mplayer-users</A>
10 mailing list. Number one is of course the topic of the</P>
11
12 <P><B><I>GCC 2.96 series</I></B></P>
13
14 <P><B>Also read <A HREF="gcc-2.96-3.0.html">this</A> text !!!</B></P>
15
16 <P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The
17 best of them was 2.95.3 . Please note the style of the version numbering.
18 This is how the GCC team numbers their compilers. The 2.95 series are good.
19 We never ever saw anything that was miscompiled because of the 2.95's faultiness.</P>
20
21 <P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B>
22 with their distributions. Note the version numbering. This should be the GCC
23 team's versioning. They patched the CVS version of GCC (something between 2.95 and 3.0)
24 They patched it very deep, and used this version in the distrib because 3.0
25 wasn't out at time, and they wanted IA64 support ASAP (business reasons).
26 Oh, and GCC 2.95 miscompiles bash on the s390 architecture (there is
27 no RedHat distribution for s390..) .</P>
28
29 <P>The <I>facts</I> : <B>MPlayer</B>'s compile process needs the
30 <CODE>--disable-gcc-checking</CODE> to proceed upon detecting a GCC version of
31 2.96 (apparently it needs this option on <B>egcs</B> too. It's because we don't
32 test <B>MPlayer</B> on egcs. Pardon us, but we rather develop <B>MPlayer</B>).
33 If you know <B>MPlayer</B>, you should know that it has great speed. It
34 achieves this by having overoptimized MMX/SSE/3DNow/etc codes, fastmemcpy, and
35 lots of other features. <B>MPlayer</B> contained MMX/3DNow instructions in a
36 syntax that all Linux compilers accept it... except RedHat's GCC (it's more
37 standard compliant). It simply <B><I>skips</I></B> them. It doesn't give
38 errors. It doesn't give warnings. <B>And</B>, there is Lame. With gcc 2.96, its quality check
39 (<CODE>make test</CODE> after compiling) <I>doesn't even run !!!</I>
40 But hey, it compiles bash on s390 and IA64.</P>
41
42 <P>The <I>statements</I> : most developers around the world begun having
43 bad feelings about RedHat's GCC 2.96 , and told their RedHat users to
44 compile with other compiler than 2.96 . RedHat users' disappointment slowly
45 went into anger. What was all good
46 for, apart from giving headaches to developers, putting oil on anti-RedHat
47 flame, confusing users? The answer, I do not know.</P>
48
49 <P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above
50 is fixed, and works properly. Note the versioning. They should have started
51 with something like this. What about GCC 2.96.85 ? It doesn't matter now.
52 I don't search, but I still see bugs with 2.96 . It doesn't matter now,
53 hopefully now <B>RedHat will forget about 2.96</B> and turn towards <B>3.0</B>.
54 Towards a deep patched 3.0...
55 </P>
56
57 <P><I>What I don't understand</I> is why are we hated by RedHat users for
58 putting warning messages, and stay-away documents in <B>MPlayer</B> .
59 Why are we called "brain damaged", "total asshole", "childish" by
60 <B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> .
61 They even considered forking <B>MPlayer</B> for themselves. RedHat users.
62 Why? It's RedHat that made the compiler, why do <U>you</U> have to hate us?
63 Are you <U>that</U> fellow RedHat worshippers? Please stop it. We don't hold
64 a grudge against users, doesn't matter how loud you advertise its contrary.
65 Please go flame Linus Torvalds, the DRI developers (oh, now I know why
66 there were laid off by VA!), the Wine, avifile. Even if we are arrogant,
67 are we not the same as the previously listed ones? Why do <B>we</B> have
68 to suffer from your unrightful wrath?</P>
69
70 <P>I'm closing this topic. Think over it please. I (Gabucino) personally begun
71 with <A HREF="http://www.redhat.com">RedHat</A>, then used Mandrake (sorry I
72 don't know their URL), now I have <A
73 HREF="http://www.linuxfromscratch.com">LFS</A>. Never held a grudge against
74 RedHat or RedHat users, and I still don't. Hate is only comfortable. It
75 won't bring you anywhere.</P>
76
77 <P><B><I>Binary distribution of MPlayer</I></B></P>
78
79 <P>Tons of users asked us about this. For example Debian users tend to say: Oh,
80 I can <CODE>apt-get install avifile</CODE>, why should I <B>compile MPlayer</B> ?
81 While this may sound reasonable, the problem lies a bit deeper than
82 those-fuckin-MPlayer-developers-hate-gcc-2.96-and-RedHat-and-Debian.</P>
83
84 <P>Reasons: <B>Law</B></P>
85
86 <P><B>MPlayer</B> describes the <U>sourcecode</U>. It contains several files with incompatible
87 licenses especially on the redistribution clauses. As source files, they are
88 allowed to coexist in a same project.</P>
89
90 <P>Therefore, <U>NEITHER BINARIES NOR BINARY PACKAGES OF <B>MPlayer</B> ARE ALLOWED TO EXIST SINCE
91 SUCH OBJECTS BREAK LICENSES</U>. PEOPLE WHO DISTRIBUTE SUCH BINARY PACKAGES ARE
92 DOING ILLEGAL ACTIVITIES.</P>
93
94 <P>So if you know somebody who maintains a binary package then forward her/him
95 this text and (ask him to) contact us. What (s)he is doing is illegal and IT IS
96 NO LONGER <B>MPlayer</B>, but <U>his/her</U> mplayer. If it breaks, it is
97 his/her fault. Don't come and cry on the <B>MPlayer</B> mailing lists, you will
98 most likely be blacklisted.</P>
99
100 <P>For example that french guy called <B>Christian Marillat</B> who denied our
101 request, and is still distributing binary Debian packages of <B>MPlayer</B>,
102 despite the fact that there was at least one user who downloaded it and failed
103 (of course compiling from source helped him). And there is <B>Guillaume
104 Rousse</B>, who is doing the same, but making RPMs for Mandrake. Do not support
105 criminals!</P>
106
107 <P>Reasons: <B>Technical</B></P>
108
109 <P>
110 <UL>
111 <LI><B>MPlayer's</B> speed (MMX, SSE, fastmemcpy, etc) optimizations are
112 determined during compilation. Thus a compiled binary contains very
113 processor-specific code. An <B>MPlayer</B> binary compiled for K6 will die
114 on Pentiums and vice versa. This has to be workarounded by runtime
115 detection, which is not an easy thing to do becase it causes massive speed
116 decrease. If you don't believe (it was explained in details 10000 times on
117 mplayer-users, search the archive), solve it and send us a patch. Someone
118 begun work on it, but disappeared since then.</LI>
119 <LI><B>MPlayer's</B> video/audio system is not plugin based. It is compiled
120 into the binary, thus making the binary depend on various libraries (the
121 GUI depends on GTK, DivX4 depends on libdivxdecore, SDL depends on libSDL,
122 every SDL release contains an unique bug that has to be workarounded during
123 compiletime, X11 output compiles differently for X3 and X4, etc). You may
124 say: yes, let's make 30 versions of downloadable binaries! We won't. We
125 will make these stuff pluggable in the future.</LI>
126 </UL>
127
128 </HTML>