[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sparc64 and sparc architecture -- any consensus?

Reviving an old thread as I update the sparc64 port pages...

"Collins M.  Ben " <bmc@visi.net> writes:
> On Tue, May 11, 1999 at 08:08:49AM -0600, Ward Deng wrote:
> > I think the argument was legitimate. However, 32-bit sparc systems will
> > soon be phased out just like 486 in x86 domain. There are virtually no
> > systems in production anymore. The only users that require Sun to provide
> > 32-bit sparc systems are those still use SunOS 4.x for their applications.
> > I do not think it will last very long. We cannot just make UltraLinux for
> > salvage hardware.
> Very true, maybe a well planned "move" to full 64bit is more in order than
> doing a "this way" or "that way" type of approach?

I don't think that 32-bit sparc is really going to disappear for 7
years, at least not in the Linux world.  Maybe in the corporate world
it will...

Ward Deng wrote:
| Yes. I was told that in many cases 32-bit binaries perform better on
| 64-bit architecture than 64-bit binaries. We probably need find a way
| to meet current needs as well as long-term goal.

Ideally, we can treat sparc64 as an "overlay".

I think this can be done now in apt.  Just install the 64-bit apps in
the sparc64 area, and have people define it first in sources.list:

deb http://http.us.debian.org/debian stable/sparc64 main contrib non-free
deb http://http.us.debian.org/debian stable/sparc main contrib non-free

Even if version numbers are the same, apt should favor the first line.

I'm not sure if this is as robust as it should be, though.  For
instance, if we decide to add a critical library into the sparc64
area, it wouldn't get immediately picked up unless we used NMU
numbering for the sparc64 part.


.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>

Reply to: