In medias res

There are two major topic which always causes huge dispute and flame on the mplayer-users mailing list. Number one is of course the topic of the

GCC 2.96 series

Also read this text !!!

The background : there were/are the GCC 2.95 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's faultiness.

The action : RedHat started to include a GCC version of 2.96 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 (there is no RedHat distribution for s390..) .

The facts : MPlayer's compile process needs the --disable-gcc-checking to proceed upon detecting a GCC version of 2.96 (apparently it needs this option on egcs too. It's because we don't test MPlayer on egcs. Pardon us, but we rather develop MPlayer). If you know MPlayer, 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. MPlayer contained MMX/3DNow instructions in a syntax that all Linux compilers accept it... except RedHat's GCC (it's more standard compliant). It simply skips them. It doesn't give errors. It doesn't give warnings. And, there is Lame. With gcc 2.96, its quality check (make test after compiling) doesn't even run !!! But hey, it compiles bash on s390 and IA64.

The statements : 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.

Present age, present time : 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 RedHat will forget about 2.96 and turn towards 3.0. Towards a deep patched 3.0...

What I don't understand is why are we hated by RedHat users for putting warning messages, and stay-away documents in MPlayer . Why are we called "brain damaged", "total asshole", "childish" by RedHat users, on our mailing list, and even on the redhat-devel . They even considered forking MPlayer for themselves. RedHat users. Why? It's RedHat that made the compiler, why do you have to hate us? Are you that 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 we have to suffer from your unrightful wrath?

I'm closing this topic. Think over it please. I (Gabucino) personally begun with RedHat, then used Mandrake (sorry I don't know their URL), now I have LFS. Never held a grudge against RedHat or RedHat users, and I still don't. Hate is only comfortable. It won't bring you anywhere.

Binary distribution of MPlayer

Tons of users asked us about this. For example Debian users tend to say: Oh, I can apt-get install avifile, why should I compile MPlayer ? While this may sound reasonable, the problem lies a bit deeper than those-fuckin-MPlayer-developers-hate-gcc-2.96-and-RedHat-and-Debian.

Reasons: Law

MPlayer describes the sourcecode. It contains several files with incompatible licenses especially on the redistribution clauses. As source files, they are allowed to coexist in a same project.

Therefore, NEITHER BINARIES NOR BINARY PACKAGES OF MPlayer ARE ALLOWED TO EXIST SINCE SUCH OBJECTS BREAK LICENSES. PEOPLE WHO DISTRIBUTE SUCH BINARY PACKAGES ARE DOING ILLEGAL ACTIVITIES.

So if you know somebody who maintains a binary package then forward her/him this text and (ask him to) contact us. What (s)he is doing is illegal and IT IS NO LONGER MPlayer, but his/her mplayer. If it breaks, it is his/her fault. Don't come and cry on the MPlayer mailing lists, you will most likely be blacklisted.

For example that french guy called Christian Marillat who denied our request, and is still distributing binary Debian packages of MPlayer, despite the fact that there was at least one user who downloaded it and failed (of course compiling from source helped him). And there is Guillaume Rousse, who is doing the same, but making RPMs for Mandrake. Do not support criminals!

Reasons: Technical

• MPlayer's speed (MMX, SSE, fastmemcpy, etc) optimizations are determined during compilation. Thus a compiled binary contains very processor-specific code. An MPlayer binary compiled for K6 will die on Pentiums and vice versa. This has to be workarounded by runtime detection, which is not an easy thing to do becase it causes massive speed decrease. If you don't believe (it was explained in details 10000 times on mplayer-users, search the archive), solve it and send us a patch. Someone begun work on it, but disappeared since then.
• MPlayer's video/audio system is not plugin based. It is compiled into the binary, thus making the binary depend on various libraries (the GUI depends on GTK, DivX4 depends on libdivxdecore, SDL depends on libSDL, every SDL release contains an unique bug that has to be workarounded during compiletime, X11 output compiles differently for X3 and X4, etc). You may say: yes, let's make 30 versions of downloadable binaries! We won't. We will make these stuff pluggable in the future.