Mercurial > mplayer.hg
comparison DOCS/users_against_developers.html @ 2867:a9a63f7e9ddc
nice new docu. read it.
TODO: place gcc 2.96 Q/A from FAQ to here.
| author | gabucino |
|---|---|
| date | Tue, 13 Nov 2001 16:19:48 +0000 |
| parents | |
| children | 56428bdf583e |
comparison
equal
deleted
inserted
replaced
| 2866:4f6190ab52e7 | 2867:a9a63f7e9ddc |
|---|---|
| 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>The <I>facts</I> : <B>MPlayer</B>'s compile process needs the | |
| 15 <CODE>--disable-gcc-checking</CODE> to proceed upon detecting a GCC version | |
| 16 of 2.96 (apparently it needs this option on <B>egcs</B> too. It's because we | |
| 17 don't test <B>MPlayer</B> on egcs. Pardon us, but we rather develop <B>MPlayer</B>). | |
| 18 If you know <B>MPlayer</B>, you should know that it has great speed. It | |
| 19 achieves this by having overoptimized MMX/SSE/3DNow/etc codes, fastmemcpy, and | |
| 20 lots of other features. | |
| 21 | |
| 22 <P>The <I>background</I> : there were/are the GCC <B>2.95</B> series. The | |
| 23 best of them was 2.95.3 . Please note the style of the version numbering. | |
| 24 This is how the GCC team numbers their compilers. The 2.95 series are good. | |
| 25 Noone ever saw anything that was miscompiled because of the 2.95's faultiness.</P> | |
| 26 | |
| 27 <P>The <I>action</I> : <B>RedHat</B> started to include a GCC version of <B>2.96</B> | |
| 28 with their distributions. Note the version numbering. This should be the GCC | |
| 29 team's versioning. They patched GCC 2.95.3 . They patched it very deep. | |
| 30 They patched it <B>bad</B>. RedHat saw it was bad, but decided to ship it | |
| 31 anyways (even with his "<I>Enterprise-ready</I>" distributions). After all, more | |
| 32 users try it, the more bugreports they get, thus bugfixing and development | |
| 33 goes faster. Development? GCC 2.95 was good enough, where did they want to | |
| 34 develop more? Develop GCC in parallel with the GCC team ? (the GCC team was | |
| 35 meanwhile testing their new <B>GCC 3.0</B>)</P> | |
| 36 | |
| 37 <P>The <I>result</I> : the first RedHat GCC 2.96's were so flawed, that nothing | |
| 38 above <I>hello_world.c</I> compiled. RedHat immediately began making | |
| 39 Service Packs - ups, so they immediately began patching the bugs. They | |
| 40 could have backed out to 2.95 if they wanted. Meanwhile major Linux programs' | |
| 41 like <B>DRI</B>, <B>avifile</B>, <B>Wine</B> and the <B>Linux kernel</B> | |
| 42 developers began wondering why do they receive these new interesting | |
| 43 bugreports. They obviously didn't consider it a good thing, they'd have | |
| 44 better things to do.</P> | |
| 45 | |
| 46 <P>The <I>statements</I> : most developers around the world begun having | |
| 47 bad feelings about RedHat's GCC 2.96 , and told their RedHat users to | |
| 48 compile with other compiler than 2.96 . RedHat users' disappointment slowly | |
| 49 went into anger. Some guy called Bero even put up a page that describes | |
| 50 that GCC 2.96 is not incompatible, but 2.95 was incompatible ! If we | |
| 51 assume this is the case, we should greet RedHat for upgrading our GCC, and | |
| 52 flame all who opposes. But I wonder : why didn't they help the GCC team | |
| 53 <B>to fix</B> their "incompatibilities", why did they instead fork, and | |
| 54 did it on their own? Why couldn't they wait for GCC 3.0 ? What was all good | |
| 55 for, apart from giving headaches to developers, putting oil on anti-RedHat | |
| 56 flame, confusing users? The answer, I do not know.</P> | |
| 57 | |
| 58 <P><I>Present age, present time</I> : RedHat says that GCC 2.96-85 and above | |
| 59 is fixed, and works properly. Note the versioning. They should have started | |
| 60 with something like this. What about GCC 2.95.3-85 ? It doesn't matter now. | |
| 61 Whether they still use kgcc for kernels, I have no information. I don't search, | |
| 62 but I still see bugs with 2.96 . It doesn't matter now, hopefully now <B>RedHat | |
| 63 will forget about 2.96</B> and turn towards <B>3.0</B>.</P> | |
| 64 | |
| 65 <P><I>What I don't understand</I> is why are we hated by RedHat users for | |
| 66 putting warning messages, and stay-away documents in <B>MPlayer</B> . | |
| 67 Why are we called "brain damaged", "total asshole", "childish" by | |
| 68 <B>RedHat users</B>, on our mailing list, and even on the <B>redhat-devel</B> . | |
| 69 They even considered forking <B>MPlayer</B> for themselves. RedHat users. | |
| 70 Why? It's RedHat that made the compiler, why do <U>you</U> have to hate us? | |
| 71 Are you <U>that</U> fellow RedHat worshippers? Please stop it. We don't hold | |
| 72 a grudge against users, doesn't matter how loud you advertise its contrary. | |
| 73 Please go flame Linus Torvalds, the DRI developers (oh, now I know why | |
| 74 there were laid off by VA!), the Wine, avifile. Even if we are arrogant, | |
| 75 are we not the same as the previously listed ones? Why do <B>we</B> have | |
| 76 to suffer from your unrightful wrath?</P> | |
| 77 | |
| 78 <P>I'm closing this topic. Think over it please. I (Gabucino) personally begun | |
| 79 with <A HREF="http://www.redhat.com">RedHat</A>, then used Mandrake (sorry I | |
| 80 don't know their URL), now I have <A | |
| 81 HREF="http://www.linuxfromscratch.com">LFS</A>. Never held a grudge against | |
| 82 RedHat or RedHat users, and I still don't. Hate is only comfortable. It | |
| 83 won't bring you anywhere.</P> | |
| 84 | |
| 85 <P><B><I>Binary distribution of MPlayer</I></B></P> | |
| 86 | |
| 87 <P>I'm too moody now for this.</P> | |
| 88 | |
| 89 </HTML> |