[MPlayer-users] Quicktime playback on MPlayer/Linux --Somevideos play in ultra-slow-motion?

[The Wanderer]

Phil Rhodes wrote:

[that the Wanderer wrote:]

>> I have said, and I repeat, that the basic "obtain source tree ;
>> ./configure ; make ; make install" procedure works flawlessly for
>> me on every computer I've tried it on, without tweaking or
>> customization of either the computer or the source tree.
> 
> All I can say is that this is not my experience; my failure to
> respond directly on this point is based on a feeling of: is this guy
> serious? How can you take this position when it is so self-evidently
> not the case? Do you USE linux?

For me, this *is* the case. I have used Linux exclusively - except, in
the last two years, as required for work - for more than half a decade
(I think quite a bit longer, but I don't have exact dates), and have
rarely had anything near the kind of experience you are describing as
universal.

I could just as easily ask "how can he take this position when it is so
self-evidently not the case?" about the position you are arguing,
because it is so completely out of line with anything I have experienced
as the norm that I suspect some people would, in my place, accuse you of
simply making things up.

> I can only speak as I find.
> 
> My experience of the configure/make/install thing is that you type it
> in, it spews out page after page of incomprehensible error messages,
> and fails.

Question, for clarification: are you counting the compile commands
themselves as "error messages"? Because without that, even in cases
where the compilation fails I find it extremely rare for there to be
multiple pages of error messages.

Or... wait. How long is a "page" here? I run at a fairly high resolution
and compile in a full-screen-size terminal, so my usual page size is 89
lines by 250 columns. If you're compiling from the console or in a
standard-sized (non-resized, non-maximized) terminal, the limit will be
more like 40 lines and 80 columns, which will greatly decrease the
amount which will fit on one page.

Looks like I found an explanation for my own confusion. In that case, my
response is: are you saying that this is your experience with compiling
under Linux in general, or with MPlayer, or with specific other projects?

I do not experience this with MPlayer, which is what we are talking
about. The only times I get compilation failures with MPlayer are when
compiling from a broken SVN tree (which, as I said, is rare), when
compiling with bad configure options (which will not happen with the
standard './configure ; make ; make install' procedure), and when
recompiling after a sufficiently large SVN update but without running
'make distclean' or 'make depend' first (which will not apply to a user
compiling for the initial install).

I do not experience this with compiling under Linux in general, though
the general run of projects seem to have a somewhat lower standard and a
somewhat higher chance of such problems than is the case with MPlayer.

I have experienced approximately this with some specific other projects,
a few of which I have even failed to get to compile at all. The worst of
these have been those which don't provide a configure script, or in a
few cases even a Makefile. This is, however, absolutely not the general
rule for open-source projects in my experience; it is the exception, and
a somewhat unusual exception at that.

> So you do one command at a time, and spend anything from half an hour
> to two days fixing all the problems each one has.

When I have encountered the need to do "one command at a time" fixes,
which as I say has rarely if ever happened with MPlayer, it almost never
takes even as much as half an hour to fix (and "a couple of minutes" is
much more common); the exceptions are cases where the problems are so
severe that I end up not being able to get it compiled at all, which as
I say are quite rare.

> During this time you are roundly derided by the creators of the
> software - as I am being here -

You are not being derided here so far as I can see; you are being
disagreed with, and asked to support your position. Also, few if any of
the creators of the software have interposed themselves into this
discussion as yet.

> for being such a dunce as to make this happen, an insult given
> particular force by the tendency of Linux people, as here, to pretend
> that such problems are impossible and unthinkable and can never
> happen, as opposed to being absolutely the norm.

I find your description of it as "pretending" that these problems are
not the norm to be insulting. I have tried to avoid insulting or
otherwise attacking you, despite the consistently rude way you have
expressed your views; I would appreciate it if you made a similar effort
to avoid insulting other people.

> Almost invariably these issues are caused by hardcoded paths or
> missing library source

Are you talking about MPlayer here?

> (truly, Linux is the only OS in the world under which absolutely
> everything is monolithic and you end up needing a gig and a half of
> the source code to the universe to create any program whatsoever;
> then again, it is so poorly standardised that dynamic linking is
> pretty much infeasible).

I find it difficult to interpret this, coming in this place and in this
context, as anything other than trolling.

> It is my direct experience on the basis of at least several hundred
> attempts that the combined first-time success rate of all the various
> Linux software deployment strategies (apt, compilation, rpm, etc) is
> well down into the single digit percentages, and probably under 5%;
> a Windows deployment is probably exactly the inverse.

I find this ludicrous. I have had well over 95% success with everything
combined, nearly 100% success with apt, and at least 80% success with
compilation (I don't use RPM). It has rarely if ever taken more than the
trivial "just do it" commands to make it work that well. If you are
indeed seeing this kind of failure rater, I am inclined to think that
either you or your environment must be doing something very wrong.

> Linux is so bad, so hopelessly unreliable, so ludicrously abstruse
> and hard to work with that it's absolutely laughable and if this is
> not your experience then we simply seem to live on different planets,
> or you are suffering from a politically selective memory.

I think the answer would be somewhere closer to the former. I would find
the latter to be mildly insulting.

> Call it an "assertion" if you like. I can only report my experience,
> and that is what it is.

Report it as your experience, and we're fine.

Try to claim that it is the universal truth for everything everywhere,
which is what I see you as having done here, and we have a problem.

> I no longer specify Linux for any task where I don't know absolutely
> that the software I need comes preinstalled with the OS, because as a
> very practical matter, adding anything else is entirely in the lap of
> the gods.

If this is the case for you, then either you are exceedingly unlucky, or
you are doing something wrong. I have dozens if not hundreds of
non-preinstalled programs on my current computer, and thousands more are
available for installation at the drop of a hat; I could install any one
of those immediately with virtually zero chance of problems.

> It is not really possible to solve these problems because there is
> effectively no standardisation or consistency. The first thing that
> needs to happen to Linux is for all but two or three of the
> distributions to go away so it's actually possible to get things to
> conform.

Properly responding to this would take this discussion even further
off-topic than it already is, and I probably don't have the background
to be able to properly argue it anyway.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

Secrecy is the beginning of tyranny.