Re: Bug#176267: ITP: mplayer -- Mplayer is a full-featured audioand video player for UN*X like systems
#include <hallo.h>
* Arpi [Mon, Jan 27 2003, 01:44:58AM]:
> Sorry for not replying to teh thread, i'm not subscribed to this list.
> Gabu FWD'ed the thread and it seems that so many debian ppl thinks and
Sure. And I have to open your eyes now. Please note that there is no
official Debian Opinion unless we have a clear consens among the
developers and DPL officialy speaks to you. This mail does also not
officialy represent the Debian project.
> says very false statements. So I have to tell you some comemnts and the
> truth.
Truth? Which truth? Yours? Truth is also defined by a human person.
> it seems that debian is not only speech...
> and we'll see that debian is also not free...
Debian is free, as much as possible. Why do you think people buy
Debian, and CD distributors sell it? Because you can rely on its
freedom. If SuSE is sued by someone, they can call their lawyer, and
then either fix the problem, or find a diplomatical solution, and
eventually replace all flawed CD media in the stores. This is not that
bad since they produce a new release every 3..6months.
> but debian is actually a new OS/2 (half OS) edition.
> it contains thousands of programs but only half of each one, the other half
> was moderated out due to legality reasons :)
Bullshit. Complete bullshit, and you know it. Please wake up, look
around from you small world and try to understand how the software
distribution works.
> so the users have to download the missing half from the net, breaking the
> law. debian's law.
We do not forbid anyone the downloads from the net.
> > > That doesn't prevent the binaries from working, using several packages
> > > with different cpu optimisations. Many packages in Debian already work
> > > this way.
> > We call that method "hack".
> And it's a big waste of space. Think of different binaries for the possible
If you would work on proper software design, it would be very easy to
make partial optimisation, without duplication of the size.
> combinations of MMX, MMX2, SSE, SSE2, 3Dnow, 3Dnow2. and then C code
> compiled for i386, i586, i686, k6 etc. and then think of non-x86 archs.
> and then debian can introduce the one-program-one-cd concept.
Bullshit. I can bed you have slept in the lecture about hardware
systems. Or you just dream about the compiler beeing beeing able to
create always code that runs with double speed if you optimise. Please
do a reality check. In most cases, you can do a good compromise and ship
software that is optimised enough for the most architectures. Marillat
made an acceptable decission, and before you try to critisize his
decission about the choosen set of flags, come with some REAL
BENCHMARKS.
> > No, true. I am not talking about the present. xine was (is?:) just a buggy
> > piece of hunk that threw sig11s every minute, when MPlayer was the stablest
> > movie player.
> :)
Hahaha. Two-three years ago. And in that time, there were faster
alternatives for common used systems, Ogle, iirc.
> > > There have been several movie players around, which are much less
> > > painful to install and which comply with the DFSG - and they are
> > > included in the main Debian distribution.
> > Amen.
> And they don't play any modern media file, but since debian is well known
> for many years old application versions and 'i'm using debian since 20
> years' users it shouldn't be a problem...
20 years? Nice exxageration, but misplaced. What is your problem with
not-the-latest version of some application? I think you are using Gentoo
on your own system just to be proud of its bleeding-edge state, but
could you explain where you actually need the features?
> users (and mplayer developers) want an app which is able to play the films,
> trailers, advertisements, pron, whatever they download from the net.
Such users _allways_ compiled Mplayer manually, I do not see a problem
here. Debian STABLE serves users that want quality software, that
installs without problems and runs acceptably. You just follow some
braindead statements of known kernel developers: "Release fast, release
often, lets the users test". This may work for single parts of hardware.
But you cannot do this with a big distribution (FYI: the same can be
said for SuSE). You do not sell the stuff on media. You do not think
about users that cannot fetch the latest version. You give a fsck on
proper testing. This is something you can do with one single
application, but not with a big distribution system. Here, you need
quality. Software quality with STABLE code, and you seem not to be able
to bring this things together. To Stability also belongs some freeze
phase, some QA work, public bug tracking system, etc.
> > Then what does it use? Win32 codecs? XVID? Have you ever used libavcodec?
>
> all of them.
>
> the strange thing is that they are legal in xine (and avifile and others)
> but illegal in mplayer. so wonder why i'm disappointed by debian rules?
> even if god debian-legal it's illegal, i'm interested in what' sthe
> difference between mplayer and others, why are you discriminative to us?
> i sugegst you removing all codecs and demuxers and everything related to
> characters MPEG from any media player of debian. then it's fair...
Wrong. If someone sues you, you just take the problematic software from
the net and then you can find a sane solution with the lawyers. But we
cannot. What should our parners and CD sellers do? Burn all printed
media to ashes? And SuSE cannot (though, they are willing to risk more,
see KDE1 case), for example. Please open your eyes. Bleeding edge
software may promise you better software quality, but it does not
allways. You do not separate development and frozen branches, so there
is allways risk when using MPlayer.
Oh, I already see you screaming "but we want the most perferct software
for version 1.0". Forget it. Wont work. WINE guys, for example, gave up
that idea a long time ago. Either you make a clear line, freeze (read:
no new features, only bugfixes) the software for 1-2months and release
it as is, or you admit officially that Mplayer is unstable development
software and should not be packaged by anyone.
> > > You have indeed proven that someone wanting to package mplayer will have
> > > a hard time dealing with upstream.
> > Interesting, Dominik (our "official" RPM packager) works in close contact with
> > us, and never faced any hardships.. In fact, he is a developer with CVS write
> > access.
> yes, and i like the way he works, after negotiate with us and the users
> he makes usable, working packages. i expected teh same from debian but they
So what, and are his packages in the official Redhat distribution?
> never asked us about what is experimental and what should be there in the
> package and what are the recommended options for binary distribution.
> (since the defaults are for source distrib.)
If that is the truth, blame Marillat but in private mails. Do not throw
this flamewar on debian-devel, there are already to many of them.
> even worse: they start the packaging procedure with the heavy usage of
> the 'rm' command to strip down things they think illegal...
Illegal? You cannot prove that they are legal, so why should they not be
illegal?
> and at the end they wonder why is it unusable, and finally drop it.
> or even more worse: put the unusable package into the distro and then
> wonder why (or even worse: redirect to us) the users keep complaining.
I would include a crippled package into Debian, with a Debconf (that is
the setup thingie) message telling the user about the legality
situation. I wonder why you try to fight a such solution.
> > Just as Linus said on dri-devel, it would be better to go and _include_ things
> > with unclear legality (S3TC), and see if it matters to anyone, than go and
> > whine in the corner.
See above. You can meet such decissions for one single software project,
not distributed on hard media. For software systems, the situation is
different. Or why don't you complain about others not including Acrobad
Reader in their distros? They have to deal with the same shit, braindead
software licenses. And your case is not much better.
> I usually don't like Linus but it was very very true and good advice.
> Note that several linxu distros follow this approach, they include
> apps like mplayer, with all teh features (i know some shipping even
> libdvdcss) and then wait for reactions. _nothing_ was removed due to
> legal answer up to this moment.
Haha. Show me that distribution. Someone shipping on CD media and not
fetching Mplayer stuff from the net during the installation.
Gruss/Regards,
Eduard.
--
Am besten ist, man macht sich einen Knoten ins Notizbuch.
-- Heinz Erhardt
Reply to: