On Mit, 2007-11-07 at 14:19 -0500, Lennart Sorensen wrote:
> On Wed, Nov 07, 2007 at 12:05:26AM +0100, Bernd Petrovitsch wrote:
> > Any real-world examples?
> > Even OpenOffice runs as 64bit since months.
> > The only which I remember rumors are "grub". But being a bootloader,
> > that probably doesn't hurt much.
> > Fact is that I run pure 64bit Linux since months on my home desktop
> > (though I'm not the typical desktop user;-).
> 
> I know people were working on openoffice, but it has been sufficiently
> unstable both 32bit and 64bit that it's hard to ever tell when
> openoffice is really working right. :)

I'm not an OOorg power user - it's more a .doc/.xls viewer for me.

> How is mplayer with w32codecs doing on 64bit?  How about java plugin?
> flash v9 plugin?

No "official flash" (which always everyone uses) but there is a free
replacement project somewhere which AFAIK works on 64bit. But I don't
know how good this (and I'm in no need for flash - I can live without
youtube;-).
The few movies I want to look ran with one of mplayer, totem or xine
(but seldom with all). I never looked in to though.

[...]
> > In short: FUD?!
> 
> No, theoretically you could have code with so many pointers that the
> doubling of size of pointers actually costs enough memory bandwidth to
> make a difference.  I hope nobody writes code like that.  I was just

ACK - in theory.
ACK - and since that software (also) needs to be fixed. Therefor I'm
counting this in practice as an non-issue.

> trying to be thorough on any disadvantages too.  Probably irrelevant on
> an AMD, but might hurt on a multi cpu intel since they still have much
> more limited memory bandwidth available.

Hmm, any better numbers on it (or links to places with them)?

> > Some browsers (konqueror, firefox as far as I've been told) allow to run
> > 32bit plugins from the 64bit version. Since the flash-plugin and others
> > is not really important for me, I don't really care.
> 
> Well they are important to a lot of people.  The new ability to run

Yes, very probably.

> 32bit plugins certainly helps too.

ACK.

> > Or install 32bit libs and run a 32bit browser/application on the x86_64
> > installation.
> 
> Except that is a bit of a pain and doesn't fit dpkg/apt very well.

On FC6 (IIRC) it took >80 i386 RPMS just to install OOorg.
The problem is not really the disk space for it (or the time and
resources OOorg needs to start) but that `yum upgrade` also pulls new
i386 packages which are not realy needed on the next update just because
the x86_64 version is upgraded. So unless you cleanup regularly you end
up with all of them (or you ignore "i386" in yum.conf and temporarily
add it if some dependency lib of OOorg wants to be updated - which is
awkward too).

> > Yes, but that implies "Vista" there and God knows how compatible (even
> > to pre-Vista Windoze) the result will be.
> 
> Well there was 64bit xp although few used it (often due to lack of
> drivers for their hardware.  Hooray for closed source drivers!), and

:-)

> certainly a number of programs do not officially support 64bit vista yet
> even though they support 32bit vista and 32 and 64bit XP.  I guess in a
> year or two when people start wanting to use 4 or 8GB ram on their
> desktops they won't have a choice anymore and things might start working
> in 64bit windows world.

That reminds me of a TYAN mainboard (Toledo i3100/S5207, Intel E6600 CPU
on it IIRC[0], Ubuntu + self-compiled kernel on it IIRC[0]) bought in
March 2007 which ran fine with 4GB but didn't even boot[1] with 8GB RAM
(and RAM is on their "recommend RAM" list for that board) and stopped
with an BIOS error not mentioned in the manual.
The third BIOS update - to a "beta" version - (since March) seems[1] to
make it work now.

        Bernd

[0]: It is not back online yes so I can't `ssh` into it.
[1]: To be more exact: It booted 5 times completely without any
         problems and then it stopped booting (when I was with at the
         hosters place to put it onthe Internet, God I was fed up with
         it and cursed it to hell!). So the "seems" needs probably some
         time and several more reboots to generate more confidence.
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to