On Dec 12, 11:17am, cswiger@mac.com (Chuck Swiger) wrote:
-- Subject: Re: amd64 stable for production ?

| While Solaris defaults to installing a 64-bit kernel and 32-bit  
| version of most userland utilities on modern SPARC hardware, 64-bit  
| versions of most packages should have been available as an option  
| starting around Solaris 7 back in 1999, and some third-party  
| utilities such as the GNU suite are also available compiled for  
| either m32 or m64:
|
| http://developers.sun.com/solaris/articles/64_bit_booting.html#Q3
| http://www.sunfreeware.com
| 
| ...at the very least, they include enough of the compiler toolchain  
| for you to be able to compile your own 64-bit versions of gawk or GNU  
| textutils.

I don't particularly care to replace 1/2 of the OS to suit my needs.
I am talking about what is sun is shipping out of the box, and yes
I know I can compile the gnu textutils. I can also run Nexenta.
 
| Counterexamples include Message-id  
| <274190120612100706jf397d37vcb1cd027024d9c5c@mail.gmail.com> which  
| states: "I'd be interested in seeing numbers for the syscall latency,  
| too."
| The latency of system calls involves a transition to kernel code by  
| definition.

This is not my message, I don't have a gmail account.

| Would you retract your claim, please?

I did not make any claims about syscall latency. My claim still
holds: I cannot use Solaris because the base utilities are 32 bit
and they do not fit my working set. I don't want to replace the
utilities because then I will not get any support.

Since you seem to selectively answer my questions, and the
ones you don't like you erase:

> Now, let's focus on the discussion: While on the sparc/sparc64
> model it probably made sense to have those utilities compiled in
> 32 bit mode because of performance/compatibility, did it really
> make sense on the x86/x86_64 environment? I think not.

christos