Mplayer Revisited

Joe Barr writes "It's been two years since I first wrote about Mplayer. Maybe the fury of the developers/community reaction to the fact that I dared to criticize them for their treatment of users kept me away. Whatever. Now Mplayer has a pre1 version of release 1.0 out there and it's time for another look." Newsforge and Slashdot are both part of OSDN.

Comments

Re:Great for OSX

[Fred IV]

VLC is pretty good too, better for me because my mac is an older machine and the OS X version of mplayer doesn't always work well with my hardware (iBook 500).

Why review only the beta version?

[TheOrquithVagrant]

MPlayer 0.92 is the current stable release where everything works as expected.

MPlayer 1.0-pre1 has some nice new stuff, but even though it has one thing (support for input from v4l devices with hardware MJPEG support) which I've wanted ofr a long time, the current pre-release is much too flakey for me to use, and I've gone back to 0.92.

MPlayer 1.0-pre1 is for writing bug-reports, not reviews.

Unless Mr. Barr had a conscious or subconscious WISH to find things that didn't work right, i don't see why he wrote his review for the pre1 version.

MPlayer has matured...

[Valar]

MPlayer has matured, both in code and attitude over the last year or so, or at least I've found it to be true. I never really had trouble installing it in the first place (all you had to do was *gasp* read the directions and follow them), but the install has gotten easier. I find that it also works better on my PC now. Additionally, their teams seems to had lost a bit of the attitude-- a quick glance over the docs doesn't reveal any references to how stupid the average mplayer user is :). Maybe they finally realized that attitude was offending some people,and hurting the project, so they got over themselves.

Don't flame the devs

[arvindn]

Doesn't the author understand how the Linux/OSS community works, or what? Its not the devs' job to make shiny installation druids that you can click through. That's what distros are for. If you want to compile software, be prepared to do your homework. If not wait for the .deb to become available or subscribe to RedHat network etc.

Gimme a break.

Re:Don't flame the devs

[pgrdsl]

Once upon a time, many years ago, free software was wild and untamed. When you downloaded a tar-file, it may, or may not, unpack in ".". Sometimes it was a shar(k) and you had to hope it didn't eat any of your files when you ran it.

And then, once you had your nice shiny sources, you could compile it. After, of course, hand editing the Makefile. Oh, and the other one. And, damn, that silly config file. And then you would fix all the compilation problems because it had been developed on a different version of Unix, and used strdup.

But, in those days, men were real men, and hackers were real hackers.

People complained, whinged, sent patches, and things improved.

And then, miracle of miracle, automated configure and build scripts came. There was the perl one, which asked lots of questions that nobody ever knew the answers to. Then there was the GNU configure scripts, which tried out things and found what worked.

And, yea!, verily, time was saved all round the world. Things started to work. Porting to other platforms became simpler. Installation was tamed, and things went were you expected them to.

What I'm trying to get at is: the same argument about "be prepared to do your homework" was used years ago pre-autoconf. Nobody would even think of going back to hand-editing all those Makefiles.

It doesn't take a vast amount of effort to get a sane build and installation process, and the amount of time it saves everyone (including the developers themselves) is massive.

With distros it is less of an issue for mere mortals, but the benefit any open source project will get from being easy to configure and install is that developers who are willing to chase bugs will do so - because it takes no pain to build.

Re:Of course you were criticised!

[curne]

Much amused.

But I cannot say I agree. I find it refreshing that a development team develops a high end program that requires some seriousness of people to use. It is becoming a widespread myth that free software developers are little Tele-tubbie-happy people just sitting on their asses coding for hundreds of idiots that luckilly flock to their mailing lists.

MPlayer is a fantastic program (along with other fantastic media programs running on Linux & Co) so many users want it to work for them. And I think that the MPlayer core team acknowledge that but when you for time number 796 get an email reading 'I problem compiling, Please help!!! Is it bug?' with no log or dump... well the coding gets sour. So I can understand that criticism is difficult to take. Especially when it seems as unfounded as the first review.

Re:Of course you were criticised!

[squiggleslash]

Barr was criticised for quoting the FAQ out of context (an obviously tongue-in-cheek comment was quoted as some sort of flame of end-users) and criticising a pre-release program for faults also present, at the time, in Xine which he subsequently gave a rave review (the faults in this case concerned dependencies - Xine and MPlayer had more or less the same dependencies, but he ignored them in Xine's case and made a big deal of having to find them in MPlayer's case.)

I fully understood the frustration the MPlayer community, which in my experience has always been very helpful and very proactive trying to create something that'll be ideal at the end of it (they may be wrong in some of the directions they've taken, but I don't doubt their motives), and really found the Barr article and his apologists somewhat disappointing. Barr really seemed to write the article in order to fire up a storm, certainly the quote out of context, an aggressive maneuver which it's hard to believe wasn't deliberate, backs this up.