Re: sparc64 and sparc architecture -- any consensus?
On Sat, May 29, 1999 at 03:27:02AM -0400, Adam Di Carlo wrote:
>
> 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...
It wont for a long while, but there will be the need/want for a fully
64bit OS.
> 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.
IMO, the binary-sparc64 port should be kept for a fully 64bit port. The
overlay libraries should be in binary-sparc, just like egcs64 is. That
way if people want sparc32 with 64bit libs on their Ultra, they can use
binary-sparc, and for full 64bit compiles, they use sparc64.
Reply to: