"" I've ran x86_64 on my laptop from 2004-2006 without ever needing what you're asking for. I couldn't play all weird codecs out there, but most of them and all I really wanted to see worked OOTB. Stop spreading FUD please. ""
I ran 32bit for a long time and almost decided to run XP or Slackware again, because mplayer did not play all the formats I wanted to play under 64bit Ubuntu. I used to make a 32bit binary on Slackware, since Ubuntu did not allow for cross-compiling, these days I use a 32bit machine in my living room. The first thing friends who decided to test Linux wants me to do, is to install something which will play all their media files. They don't care if they can run a Beryl cube even, PCs are mostly for entertainment these days. Lately everyone has been using .flv and things mplayer can play, not .wmv or .rm though .flv did not work 100% for quite some time, which is why I just use mplayer svn, Ubuntu has failed its users in providing 100% media support, instead settling for 70% which is just not good enough. On 9/8/07, Nafallo Bjälevik <[EMAIL PROTECTED]> wrote: > Hi Ralf, > > On Wed, 2007-09-05 at 12:55 +0000, Ralf Nieuwenhuijsen wrote: > > Since when did the 64-bit version of Ubuntu become the new free ubuntu > > version? > > It is not. Just because we are not willing to incorporate time-consuming > tweaks for supporting non-free x86-code on x86_64 does not make it any > less Gubuntu. > > > 1) I don't really see, why there should be differences in policies > > regarding closed-source codecs between 368 and x64. Either remove it > > from the 386 repositories (and loose about half of the users) or add it > > to the amd64 (so the majority of the users that have 64-bits chips will > > actually choose to run a 64-bit os) > > There isn't at the moment. What you are trying to gain here is change in > policies thou. Multiarch isn't going to happen anytime soon from what > I've seen. > > > 2) Everybody that needs this (90% of all 64-bit ubuntu users?) is doing > > this manually now on amd64 anyway. How is that more stable? > > I've ran x86_64 on my laptop from 2004-2006 without ever needing what > you're asking for. I couldn't play all weird codecs out there, but most > of them and all I really wanted to see worked OOTB. Stop spreading FUD > please. > > > 3) The technical details do not seem that complex, concerning we are all > > doing this manually now ANYWAY. Are we are not the experts here. > > So you are building those debs under x86_64 buildds or what? So you > already have a patch to make .debs like this for us? Then please show > them to us... > > > In other words: the reasoning that is used to not do this, is both flawed > > and in conflict with the official policy. > > There are currently four problems for the AMD64 desktop to become usuable > > without MANDATORY annoying tweaks by the end-user. > > More FUD already answered above. > > > Two of these three have a good workaround, one does not, because the free > > solution keeps crashing. > > > > 1. There is no java-applet support. Blackdown used to work, but since > > Feisty it has been crashing consistently when invoked. Yes, there are > > bug-reports about this since Feisty. No developper involvement though. > > Does not belong in this bugreport. > > > 2. Wine32. There are wine32 packages specially for 64-bit ubuntu > > thanks to WineHQ. Maybe it's a good idea to just move those packages > > into the standard repositories, since Ubuntu refuses to do the same, and > > wineHQ is the official distrobutor of Wine. (i.e. its a trusted source). > > Bugs have been filed about this since forever. No developper involvement > > though. > > Does not belong in this bugreport. Basically you're asking for multiarch > (again). From what I've seen wine for Win x86_64 is about to happen or > something... > > > 3. Flashplugin-support. The 64-bit repository does contain a > > flashplugin-nonfree package, and it installs the 32-bit version of > > flash. They just forgot to do nspluginwrapper. Bugs have been filed > > about this since forever. No developper involvement though. > > Does not belong in this bugreport. > BEARD! I've seen asac upload stuff to that extent. > > > 4. Mplayer32/gstreamer0.10-pitfalldll . We don't need 32-bit mplayer or > > 32-bit gstreamer plugins, we just need them to work with 32-bit codecs. > > Since totem-gstreamer is the default browser-plugin and video-player, > > what we need is 32-bit pitfalldll. Shouldn't be too complicated. There > > have been mplayer32 packages (and firefox32 packages) floating around > > all over the internet. Estimated gues about a hundred. Yet zero in the > > repositories. Are you intentionally blocking them? > > No. We just doesn't believe in that solution. I'm sure you can find more > on the subject in the archive for the ubuntu-devel mailinglist. > > > 5. Popular games and applicaties that offer both source-code and 32-bit > > binaries on their website are not in the repositories. Flock, Songbird, > > Urban Terror, World of Padman. Current solution getdeb.net (why you > > never made this guy a motu is beyond me, he packages more by himself > > than half the repo's) > > What licence are those under? If that guy wants to become a MOTU he's > free to. It's way beyond our rights to force him. > > > So, what's up with the systematic 64-bit sabotage? > > There is none... > -- > Nafallo Bjälevik <[EMAIL PROTECTED]> > > -- > The 64bit mplayer binary/package can't use the 32bit win32codecs to play *wmv > files. > https://bugs.launchpad.net/bugs/571 > You received this bug notification because you are a direct subscriber > of the bug. > -- The 64bit mplayer binary/package can't use the 32bit win32codecs to play *wmv files. https://bugs.launchpad.net/bugs/571 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
