Mercurial > mplayer.hg
comparison DOCS/Polish/users_against_developers.html @ 3523:dadab20dc2b4
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> |