[prev in list] [next in list] [prev in thread] [next in thread] 

List:       suse-amd64
Subject:    Re: [suse-amd64] AMD64 and lib64
From:       Roy Butler <roy.butler () jpl ! nasa ! gov>
Date:       2004-06-03 16:38:16
Message-ID: 40BF53F8.4090900 () jpl ! nasa ! gov
[Download RAW message or body]

Sid,

Yeah, I think ISVs, 64-bit-unclean, and (additionally) end-users 
unwilling/unable to build from even 64-bit-clean source really hits the 
point - at least from the viewpoint of a commercial Linux distribution.


Roy


Sid Boyce wrote:
> It's a bit of a dilemma currently which I hope will melt away over time. 
> Unlike the Itanium, AMD designed for backwards compatibility, Intel have 
> seen the impact and heading the same way. As it stands, there are a 
> number of key apps that just won't build from sources on 64-bit without 
> modification. I also don't expect ISV's to be in much of a rush to build 
> 64-bit apps. I discussed 64-bit Crossover Office with codeweaver.com, 
> they said it should be easy, but they haven't tried yet - it may prove 
> more difficult than it looks from this side, like if Windows progs will 
> cooperate as 64-bit doesn't play with 32-bit modules.
> I'm prepared to play wait and see what happens when the mud settles, 
> happy that my 64-bit laptop leaves the 32-bit boxes behind speed-wise.
> Regards
> Sid.
> 
> Leif Sorensen wrote:
> 
>> I have to agree with you. It is just not logical to say that backwards 
>> compatibility is more important than being prepared for the new 
>> technology.
>> Leif
>>
>>
>>> From: Örn Hansen <orn.hansen@swipnet.se>
>>> To: suse-amd64@suse.com
>>> Subject: Re: [suse-amd64] AMD64 and lib64
>>> Date: Thu, 3 Jun 2004 15:14:22 +0200
>>>
>>> torsdag 03 juni 2004 01:54 skrev Roy Butler:
>>> > Örn,
>>> >
>>> > http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
>>> >
>>> > Read the rationale and you may agree it was the right thing to do.
>>> >
>>>
>>> I understand the rationale, but I hardly agree with it. As of current,
>>> 64bit systems require more memory and cpu power, just run the system 
>>> because
>>> of this rationale. You have both 32bit and 64bit libraries loaded and
>>> running at the same time. I see this implementation, as a handicap.
>>>
>>> Ideally, the system should be able to allow the same program to use 
>>> either
>>> 32bit or 64bit libraries at will. Of course, this isn't so easy to do 
>>> as you
>>> have 64bit values being passed to a program expecting 32bits. If it's a
>>> pointer to an int, the problem is solved by the architecture itself 
>>> (only the
>>> lower 32bits would be written by a 32bit program). I understand that 
>>> this
>>> ideal solution, is too hard to implement at this point in time. But on a
>>> native 64bit system, my opinion is that 32bit libraries should not be 
>>> the
>>> norm. Regardless of the amount of 32bit programs around. As all programs
>>> compiled for the architecture, will be 64bits unless otherwise 
>>> specified and
>>> this "otherwise specified" gives ample room for alternative library
>>> locations.
>>>
>>>
>>>
>>> -- 
>>> Check the List-Unsubscribe header to unsubscribe
>>> For additional commands, email: suse-amd64-help@suse.com


-- 
Check the List-Unsubscribe header to unsubscribe
For additional commands, email: suse-amd64-help@suse.com

[prev in list] [next in list] [prev in thread] [next in thread]