Is that possible to create a file larger than 2G on a Solaris 2.6
server? Will any software do that?
Thanks!
Wei
> Is that possible to create a file larger than 2G on a Solaris 2.6
Yes.
> server? Will any software do that?
No, it has to be large file aware (a reletively simple
recompile if you have the source will probably do it).
HTH,
--
Rich Teer
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
> max file size on 2.6 is ~800gb I think (the max filesystem size is 1tb
You think wrong. The maximum file size is 2 GB for apps that
aren't large file aware, and 1 or 2 TB for those that are
(limited by UFS file system size, IIRC).
> Hi,
>
> Is that possible to create a file larger than 2G on a Solaris 2.6
> server? Will any software do that?
No. Sadly SOLARIS is not a true 64-bit operating system. They have
kludges that claim to support so-called "large files" but, like all
kludges, they are lame and unreliable. If you want true 64-bit support,
you need to upgrade to a true 64-bit operating system such as COMPAQ
Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
its curious designation of files over 2GB as the curiously named "large
files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
discard the poseur altogether rather than be hamstrung by its limitations.
Hope this helps,
Don
--
*********************** You a bounty hunter?
* Rev. Don McDonald * Man's gotta earn a living.
* Baltimore, MD * Dying ain't much of a living, boy.
*********************** "Outlaw Josey Wales"
> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>kludges that claim to support so-called "large files" but, like all
>kludges, they are lame and unreliable. If you want true 64-bit support,
>you need to upgrade to a true 64-bit operating system such as COMPAQ
>Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
>its curious designation of files over 2GB as the curiously named "large
>files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
>discard the poseur altogether rather than be hamstrung by its limitations.
Sometimes, it helps to read manual to prevent you from writing such
false claims.
Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
than 3 years.
--
EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
schi...@fokus.gmd.de (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
> No. Sadly SOLARIS is not a true 64-bit operating system. They have
You couldn't be more wrong. Solaris has been fully 64-bit capable
OS since Solaris 7 was released, a few years ago.
> its curious designation of files over 2GB as the curiously named "large
> files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
It's not just Solaris; I think you need to read a few more books.
The Large File Summit addresses this issue quite well.
Glad to have cleared this up for you,
> W CUI wrote:
>
>> Hi,
>>
>> Is that possible to create a file larger than 2G on a Solaris 2.6
>> server? Will any software do that?
>
>
>
> No. Sadly SOLARIS is not a true 64-bit operating system. They have
> kludges that claim to support so-called "large files" but, like all
> kludges, they are lame and unreliable. If you want true 64-bit support,
> you need to upgrade to a true 64-bit operating system such as COMPAQ
> Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
This is comp.unix.admin, my misinformed young friend. VMS and pseudo
VMS operating systems are off-topic here, just as off-topic as Linux or
FreeBSD. This newsgroup is for for the discussion of UNIX operating
systems like SOLARIS from SUN on SPARC architecture, not for PeeCee
Psudo-UNIX operating systems.
[Followups set to comp.os.vms]
--
Happy to have cleared things up for you,
N
(couldn't resist mocking the mocker)
-----------------------------------
Nicholas Bachmann
nabac...@yahoo.com
http://hermie.freeshell.org
"To Boldly Go Where Angels Fear To Tread"
-From the Infocom Game "Stationfall"
-----------------------------------
>> Hi,
>>
>> Is that possible to create a file larger than 2G on a Solaris 2.6
>> server? Will any software do that?
>
> No. Sadly SOLARIS is not a true 64-bit operating system.
Once again, Don Fool gets it wrong. Solaris 7 and 8. Read about them, Don.
A certain flame war (hi, Casper :-) somewhere around the time of Solaris
2.6 release would be educational. Google Usenet search for the term "BSD
bigots" within comp.unix.solaris gives a hit at the top of the list.
--
.-. .-. Errors have been made. Others will be blamed.
(_ \ / _)
| da...@willfork.com
|
> A certain flame war (hi, Casper :-) somewhere around the time of Solaris
> 2.6 release would be educational. Google Usenet search for the term "BSD
> bigots" within comp.unix.solaris gives a hit at the top of the list.
Good point!
>> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>>kludges that claim to support so-called "large files" but, like all
>>kludges, they are lame and unreliable. If you want true 64-bit support,
>>you need to upgrade to a true 64-bit operating system such as COMPAQ
>>Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
>>its curious designation of files over 2GB as the curiously named "large
>>files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
>>discard the poseur altogether rather than be hamstrung by its limitations.
> Sometimes, it helps to read manual to prevent you from writing such
> false claims.
> Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
> than 3 years.
Hmm.
A 64 bit-machine is something that will output '64' when the following
program is run :
#include <stdio.h>
main()
{
void *p;
printf("%d \n",sizeof((void *)p));
}
And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
this, Irix tries to use 32 bit by default.
> --
> EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
> j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
> schi...@fokus.gmd.de (work) chars I am J"org Schilling
> URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
Peter Håkanson
IPSec Sverige (At the Riverside of Gothenburg, home of Volvo)
Sorry about my e-mail address, but i'm trying to keep spam out.
Remove "icke-reklam"and "invalid" and it works.
If that prints 64, pointers are 512 bits.
This is an incredibly silly exercise anyway - the answers to this
question, which pertains to Solaris, all seem to fall short of providing
any useful information.
Solaris 7 and later are indeed true fully-fledged 64-bit operating
environments. When hosted on a 64-bit (sparcv9) system, a 64-bit kernel
will load by default in most cases.
Even though a 64-bit kernel is in use, the system will be fully capable
of natively running 32-bit and 64-bit applications. Running "isainfo
-v" and "isalist" will show you exactly what types of applications the
system will run. You can determine what ISA a specific application
conforms to by using the "file" utility, which will extract the relevant
data from the ELF structures.
Sun is big on binary compatibility - from software release to release,
and across their hardware product line. This allows developers to
deploy a single binary for Solaris-on-SPARC regardless of
characteristics like kernel architecture and revision. Not limiting a
64-bit kernel to 64-bit applications is a tremendous win.
Most of the tools supplied with the system (and built for the system)
still use 32-bit executables. This is not a problem - these tools
typically don't need to be 64-bit to function properly. 64-bit
applications won't run any better or any faster than their 32-bit
counterparts, in fact, they'll typically run slightly slower, and they
won't run at all on a 32-bit kernel. The primary reasons for building a
64-bit application is to take advantage of a larger address space, or to
interact directly with a 64-bit kernel.
When run your little test program on one of my Solaris-on-SPARC systems,
I will see either 4 or 8, depending on how I compile it. The machines
are 64-bit and the kernels are 64-bit, but the applications can be
either 32- or 64-bit, and can conform to a number of SPARC-variant ISAs.
Mark
> Rev. Don Kool wrote:
>
>> W CUI wrote:
>>
>>> Hi,
>>>
>>> Is that possible to create a file larger than 2G on a Solaris 2.6
>>> server? Will any software do that?
>>
>>
>>
>> No. Sadly SOLARIS is not a true 64-bit operating system.
>> They have kludges that claim to support so-called "large files" but,
>> like all kludges, they are lame and unreliable. If you want true
>> 64-bit support, you need to upgrade to a true 64-bit operating system
>> such as COMPAQ Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as
>> SOLARIS maintains
>
>
>
> This is comp.unix.admin, my misinformed young friend. VMS and pseudo
> VMS operating systems are off-topic here, just as off-topic as Linux or
> FreeBSD. This newsgroup is for for the discussion of UNIX operating
> systems like SOLARIS from SUN on SPARC architecture, not for PeeCee
> Psudo-UNIX operating systems.
Perhaps you should attempt to comprehend the postings that you reply to,
my dyslexic young friend. The limitations of the SOLARIS UNIX operating
system is the subject of this thread.
> [Followups set to comp.os.vms]
[your error corrected]
Happy to have cleared things up for you,
Once again Gary "old enough to bleed, old enough to breed" Burnore misses
the point of the thread. The original poster was talking about SOLARIS
2.6, not SOLARIS 7 or 8.
Happy to have cleared things up for you,
> Rev. Don Kool <old...@home.com> wrote:
>>W CUI wrote:
>>
>
>> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>>kludges that claim to support so-called "large files" but, like all
>>kludges, they are lame and unreliable. If you want true 64-bit support,
>>you need to upgrade to a true 64-bit operating system such as COMPAQ
>>Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
>>its curious designation of files over 2GB as the curiously named "large
>>files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
>>discard the poseur altogether rather than be hamstrung by its limitations.
>>
>
> Sometimes, it helps to read manual to prevent you from writing such
> false claims.
>
> Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
> than 3 years.
Often times it is helpful to read at least the subject line of the thread
that you jump into. The original poster was asking about SOLARIS 2.6.
Happy to have cleared things up for you,
Mark takes quite a while to verify what I pointed out earlier; SOLARIS
is a 32-bit OS with tacked on kludges to emulate 64-bit operation. As
long as "man largefile" returns a page, SOLARIS will still be a 32-bit
OS. To a true 64-bit OS, a 2GB file is not a "largefile", it is just a
file and there are no such things as "large file aware" utilities on a
real 64-bit OS.
> On Sat, 17 Nov 2001, Rev. Don Kool wrote:
>
>
>> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>>
>
> You couldn't be more wrong. Solaris has been fully 64-bit capable
> OS since Solaris 7 was released, a few years ago.
>
>
>>its curious designation of files over 2GB as the curiously named "large
>>files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
>>
>
> It's not just Solaris; I think you need to read a few more books.
> The Large File Summit addresses this issue quite well.
>
> Glad to have cleared this up for you,
Read the subject of the thread or the original posting, Rick. "Is that
possible to create a file larger than 2G on a Solaris 2.6
server? Will any software do that?" The original poster was asking
about SOLARIS 2.6, not SOLARIS 7.
Happy to have cleared things up for you,
>> Sometimes, it helps to read manual to prevent you from writing such
>> false claims.
>
>> Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
>> than 3 years.
>
>Hmm.
>
>A 64 bit-machine is something that will output '64' when the following
>program is run :
>#include <stdio.h>
>main()
>{
> void *p;
> printf("%d \n",sizeof((void *)p));
>}
>
>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>this, Irix tries to use 32 bit by default.
False in two ways:
the program should output "8 " if run on a 64 bit OS _and_ if it
previously has been compiled into a 64 bit binary.
> A 64 bit-machine is something that will output '64' when the following
You meant 8, I presume.
> program is run :
> #include <stdio.h>
> main()
> {
> void *p;
> printf("%d \n",sizeof((void *)p));
> }
However, you did not specify how the program is to be compiled. A quick
trip to Unix 98 specs will reveal c89 and getconf man pages saying that
the correct incantation (one of them, actually) is:
c89 `getconf XBS5_LP64_OFF64_CFLAGS` file.c \
`getconf XBS5_LP64_OFF64_LDFLAGS` \
`getconf XBS5_LP64_OFF64_LIBS`
When the resulting a.out is run, on Solaris 7 and 8 the printed result is 8.
> And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
> this, Irix tries to use 32 bit by default.
If an operating system, or environment, as Sun would like to say, supports
more than one programming environment, they can't all be the default.
Which is why Unix 98 specifies how to determine the supported programming
environments and how to invoke them.
So Why the hell didn't you take the time to read the text from the original
poster?
> <pe...@icke-reklam.ipsec.nu.invalid> wrote:
>> Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>Sometimes, it helps to read manual to prevent you from writing such
>>>false claims.
>>>
>>>Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
>>>than 3 years.
>>>
>>Hmm.
>>
>>A 64 bit-machine is something that will output '64' when the following
>>program is run :
>>#include <stdio.h>
>>main()
>>{
>> void *p;
>> printf("%d \n",sizeof((void *)p));
>>}
>>
>>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>>this, Irix tries to use 32 bit by default.
>>
>
> False in two ways:
>
> the program should output "8 " if run on a 64 bit OS _and_ if it
> previously has been compiled into a 64 bit binary.
If it is a real 64-bit OS, it will only compile into a 64-bit binary.
That of course leaves SUN out. When compiled under SOLARIS 8 07/01 it
outputs "4".
$ file a.out
a.out:
ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
Take particular notice of "32-bit".
> Rev. Don Kool <old...@home.com> wrote:
>>Joerg Schilling wrote:
>>>Rev. Don Kool <old...@home.com> wrote:
>>>>W CUI wrote:
>>>>
>>>> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>>>>kludges that claim to support so-called "large files" but, like all
>>>>kludges, they are lame and unreliable. If you want true 64-bit support,
>>>>you need to upgrade to a true 64-bit operating system such as COMPAQ
>>>>Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
>>>>its curious designation of files over 2GB as the curiously named "large
>>>>files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
>>>>discard the poseur altogether rather than be hamstrung by its limitations.
>>>>
>>>>
>>>Sometimes, it helps to read manual to prevent you from writing such
>>>false claims.
>>>
>>>Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
>>>than 3 years.
>> Often times it is helpful to read at least the subject line of the thread
>>that you jump into. The original poster was asking about SOLARIS 2.6.
> So Why the hell didn't you take the time to read the text from the original
> poster?
I did, my reading comprehension challenged young friend. Notice my
answer, "No".
> > False in two ways:
> >
> > the program should output "8 " if run on a 64 bit OS _and_ if it
> > previously has been compiled into a 64 bit binary.
>
> If it is a real 64-bit OS, it will only compile into a 64-bit binary.
> That of course leaves SUN out.
That depends on the definition of "a real 64-bit OS." I do not know of a
standard or specification which defines that term, so it's not very useful
unless we can come to the common agreement on its meaning before we
proceed.
If you take it to mean "A real 64-bit OS has 64-bit pointers in the
default programming environment" then, indeed, Solaris would not qualify
as "a real 64-bit OS." However, that definition does not seem particularly
useful to me. It needlesly penalises operating systems which support more
than one programming environment.
Again a false claim:
Solaris _is_ a real 64 bit OS, but it allows to run 32 bit applications.
However, you cannot load 32 bit drivers into the 64 bit address space of
the kernel....
groggy~/Stuff[372] uname -a
SunOS groggy 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-60
groggy~/Stuff[373] cat 64.c
#include <stdio.h>
main()
{
void *p;
printf("%d \n",sizeof((void *)p));
}
groggy~/Stuff[374] cc 64.c -o 64
groggy~/Stuff[375] file 64
64: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
groggy~/Stuff[376] ./64
8
groggy~/Stuff[377] cc -V
cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
Looks like a 64 bit OS to me.
Maybe you used gcc, the compiler of choice for "hobbyists, students
and tinkerers(sic)". On real Unix systems, one should use real
compilers. ;-)
--
Stefaan (GPG Fingerprint 25D8 551B 4C0F BF73 3283 21F1 5978 D158 7539 76E4)
--
"Technically, Windows is an 'operating system,' which means that it
supplies your computer with the basic commands that it needs to
suddenly, with no warning whatsoever, stop operating." -Dave Barry
No, I took a while to point out that Solaris 7 and 8 are true 64-bit
operating environments that maintain backward compatibility by
supporting the 32-bit ISA and ABI. At no point is anything "emulated."
> As
> long as "man largefile" returns a page, SOLARIS will still be a 32-bit
> OS. To a true 64-bit OS, a 2GB file is not a "largefile", it is just a
> file and there are no such things as "large file aware" utilities on a
> real 64-bit OS.
Like I mentioned, the system supports both 32-bit and 64-bit
applications. The 32-bit compilation environment does not support large
files by default in order to maintain POSIX compatibility and
compatibility with previous releases. The 64-bit compilation
environment does support large files by default. Take a look at the
first sentence in the description section of "man lfcompile64".
Solaris 7 and 8 support multiple ISAs and ABIs, this is preferrable to
forcing everyone to rebuild all of their applications. There is no
default ISA or ABI, only a default compilation environment. The
appropriate ISA and ABI are selected at runtime based on the compilation
environment. Developers are expected to select the environment that
best suits the needs of the applications. This is hardly a kludge - in
fact, it's quite the opposite. Forcing users to rebuild all
applications just to take advantage of an operating environment upgrade
would be a kludge.
Mark
da...@willfork.com (Drazen Kacar) writes:
>A certain flame war (hi, Casper :-) somewhere around the time of Solaris
>2.6 release would be educational. Google Usenet search for the term "BSD
>bigots" within comp.unix.solaris gives a hit at the top of the list.
Flame war? Moi?
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
pe...@icke-reklam.ipsec.nu.invalid writes:
>Hmm.
>A 64 bit-machine is something that will output '64' when the following
>program is run :
You're missing a "CHAR_BIT" someplace/
>#include <stdio.h>
>main()
>{
> void *p;
> printf("%d \n",sizeof((void *)p));
>}
>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>this, Irix tries to use 32 bit by default.
The default is of no importance; systems which have a compilation
mode that allows the program to print "8" are 64 bit systems.
Just let Don rant in his own little corner. There is no need too play
with the troll.
--
Regards,
N
> old...@home.com wrote:
>
>> Mark takes quite a while to verify what I pointed out earlier; SOLARIS
>>is a 32-bit OS with tacked on kludges to emulate 64-bit operation.
>>
>
> No, I took a while to point out that Solaris 7 and 8 are true 64-bit
> operating environments that maintain backward compatibility by
> supporting the 32-bit ISA and ABI. At no point is anything "emulated."
translation: SOLARIS 7 & 8 are 32-bit operating systems that sometimes
exhibit 64-bit functionality. On a true 64-bit OS you would be able to
use "vi" or "mail" on a 2GB file.
>>As
>>long as "man largefile" returns a page, SOLARIS will still be a 32-bit
>>OS. To a true 64-bit OS, a 2GB file is not a "largefile", it is just a
>>file and there are no such things as "large file aware" utilities on a
>>real 64-bit OS.
>>
>
> Like I mentioned, the system supports both 32-bit and 64-bit
> applications. The 32-bit compilation environment does not support large
> files by default in order to maintain POSIX compatibility and
> compatibility with previous releases. The 64-bit compilation
> environment does support large files by default. Take a look at the
> first sentence in the description section of "man lfcompile64".
>
> Solaris 7 and 8 support multiple ISAs and ABIs, this is preferrable to
> forcing everyone to rebuild all of their applications. There is no
> default ISA or ABI, only a default compilation environment. The
> appropriate ISA and ABI are selected at runtime based on the compilation
> environment. Developers are expected to select the environment that
> best suits the needs of the applications. This is hardly a kludge - in
> fact, it's quite the opposite. Forcing users to rebuild all
> applications just to take advantage of an operating environment upgrade
> would be a kludge.
No Mark, it is a kludge. SUN decided to try and hop on the 64-bit
bandwagon with a tacked on effort. It feels tacked on because it is
tacked on. If SUN would step off the fence and create a true 64-bit
operating system, they would have a chance to regain some of the respect
that they lose everyday due to this SOLARIS kludge. Like I mentioned,
true 64-bit operating systems don't have any concept of a 2GB file being
a "large file" and needing special handling. SOLARIS 64-bit support is
spotty and ill conceived.
> Rev. Don Kool wrote:
>> Joerg Schilling wrote:
>>>False in two ways:
>>>
>>>the program should output "8 " if run on a 64 bit OS _and_ if it
>>>previously has been compiled into a 64 bit binary.
>>>
>>
>> If it is a real 64-bit OS, it will only compile into a 64-bit binary.
>> That of course leaves SUN out.
>>
>
> That depends on the definition of "a real 64-bit OS." I do not know of a
> standard or specification which defines that term, so it's not very useful
> unless we can come to the common agreement on its meaning before we
> proceed.
>
> If you take it to mean "A real 64-bit OS has 64-bit pointers in the
> default programming environment" then, indeed, Solaris would not qualify
> as "a real 64-bit OS."
Exactly! SOLARIS does not, in any sense of the term, qualify as a true
64-bit OS.
> However, that definition does not seem particularly
> useful to me. It needlesly penalises operating systems which support more
> than one programming environment.
Not really. It draws a distinction between operating systems
that are true 64-bit operating systems and operating sysetms such as
SOLARIS that have limited 64-bit support while claiming to be fully
64-bit operating systems.
Yours in Christ,
Wrong again, George. SOLARIS is a real 32-bit OS with limited 64-bit
support. Try to use "vi" or "mail" on a 2GB file; you can't. Try to
create a "cpio" archive that is over 8GB; you can't. SOLARIS can't cut
it in the 64-bit world.
> "Rev. Don Kool" <old...@home.com> wrote:
>>Joerg Schilling wrote:
>>> <pe...@icke-reklam.ipsec.nu.invalid> wrote:
>>>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
[...snip...]
>> If it is a real 64-bit OS, it will only compile into a 64-bit binary.
>>That of course leaves SUN out. When compiled under SOLARIS 8 07/01 it
>>outputs "4".
>>
>>$ file a.out
>>a.out:
>>ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped
>>
>> Take particular notice of "32-bit".
>>
>
> groggy~/Stuff[372] uname -a
> SunOS groggy 5.8 Generic_108528-10 sun4u sparc SUNW,Ultra-60
> groggy~/Stuff[373] cat 64.c
> #include <stdio.h>
> main()
> {
> void *p;
> printf("%d \n",sizeof((void *)p));
> }
>
> groggy~/Stuff[374] cc 64.c -o 64
> groggy~/Stuff[375] file 64
> 64: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
> groggy~/Stuff[376] ./64
> 8
> groggy~/Stuff[377] cc -V
> cc: Sun WorkShop 6 update 1 C 5.2 2000/09/11
>
>
> Looks like a 64 bit OS to me.
It would, but then you've never been too observant, Steve.
> Maybe you used gcc, the compiler of choice for "hobbyists, students
> and tinkerers(sic)". On real Unix systems, one should use real
> compilers. ;-)
Perhaps SUN uses "gcc", the compiler of choice for hobbyists, students
and tinkerers.
# cd /usr/bin
# file *
acctcom: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
acroread: executable shell script
adb: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
addbib: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
admintool: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
alias: executable /bin/ksh script
aliasadm: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
amiadmin: executable shell script
amicert: executable shell script
amicertify: executable shell script
amidecrypt: executable shell script
amiencrypt: executable shell script
amikeystore: executable shell script
amilogin: executable shell script
amilogout: executable shell script
amisign: executable shell script
amiverify: executable shell script
apm: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
appcert: executable /usr/perl5/bin/perl script
appletviewer: symbolic link to ../java/bin/appletviewer
apptrace: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
apropos: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
arch: executable /usr/bin/sh script
asa: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
at: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
atq: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
atrm: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
audioconvert: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
audioplay: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
audiorecord: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
auths: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
awk: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
banner: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
basename: executable /usr/bin/sh script
bash: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
batch: executable /usr/bin/sh script
bc: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
bdiff: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
.
.
.
uustat: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
uuto: executable shell script
uux: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
vacation: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
vax: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
vedit: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
vgrind: executable c-shell script
vi: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
view: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
vmstat: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
volcheck: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
volrmmount: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
vsig: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
w: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
wait: executable /bin/ksh script
wansungtojohap: executable /usr/bin/csh script
wc: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
wchrtbl: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
whatis: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
which: executable /usr/bin/csh script
who: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
whocalls: executable /bin/ksh script
whois: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
wracct: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
write: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
xargs: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
xgettext: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
xstr: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
ypcat: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
ypmatch: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
yppasswd: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
ypwhich: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
zcat: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
zip: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
zipcloak: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
zipinfo: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, not stripped
zipnote: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
zipsplit: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
zsh: ELF 32-bit MSB executable SPARC Version 1, dynamically
linked, stripped
It looks like a 32-bit OS, because it is.
Happy to have cleared things up for you,
> In comp.unix.admin Joerg Schilling <j...@cs.tu-berlin.de> wrote:
> > In article <3BF6E059...@home.com>, Rev. Don Kool <old...@home.com> wrote:
> >>W CUI wrote:
>
> >> No. Sadly SOLARIS is not a true 64-bit operating system. They have
> >>kludges that claim to support so-called "large files" but, like all
> >>kludges, they are lame and unreliable. If you want true 64-bit support,
> >>you need to upgrade to a true 64-bit operating system such as COMPAQ
> >>Tru64 UNIX, SGI IRIX or COMPAQ OpenVMS. As long as SOLARIS maintains
> >>its curious designation of files over 2GB as the curiously named "large
> >>files", it will remain a 32-bit OS posing as a 64-bit OS. Better to
> >>discard the poseur altogether rather than be hamstrung by its limitations.
Is this why IRIX has routines like "lseek()" and "lsee64()" calls in its API? Or
why OpenVMS has specialized "_64" versions of APIs? Or why Tru64 UNIX
has "time()" and "time64()" calls? Every one of these operating systems has
hacks to allow software written for 32-bit machines to inherit some additional
64-bit capabilities, so Solaris is certainly not the exception here.
If you are looking to differentiate these systems, note that Sun is the only vendor
who hasn't announced the end of life for their underlying processor architecture
in favor of a questionable and ever changing porting strategy to Itanium.
>
>
> > Sometimes, it helps to read manual to prevent you from writing such
> > false claims.
>
> > Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
> > than 3 years.
>
> Hmm.
>
> A 64 bit-machine is something that will output '64' when the following
> program is run :
> #include <stdio.h>
> main()
> {
> void *p;
> printf("%d \n",sizeof((void *)p));
> }
>
> And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
> this, Irix tries to use 32 bit by default.
I'm glad to see people actually run code before posting results...
A 64-bit machine is one who's integer register size is 64-bits. The Cray 1
was a 64-bit machine even though it had a 24-bit address space. The
CDC 6600 was a 60-bit machine even though it had an 18-bit address
space. The 8086 was a 16-bit machine even though it used 32-bit
pointers to address a 20-bit address space. The 80386 is a 32-bit
processor even though it can use 48-bit pointers to allow a process
a 46-bit address space. Even Morotola calls the 56002 a 24-bit
machine now, even though it has a 56-bit ALU and accumulators,
and three 16-bit address spaces.
In some cases a process can address more physical memory than the
machine has, and in others a process cannot address all physical memory.
In some cases a virtual address specifies more address space than the
machine actually supports. The latter case applies to every implementation
of Alpha, UltraSPARC, PA-RISC 2.0 and MIPS III/IV chip that I know of,
which support actual virtual address spaces in the 36-bit to 48-bit range.
These are reasons why people don't use address bits to determine the
"size" of an architecture family.
The register to register integer operations on a Version 9 SPARC
are much the same as they are on Alpha, PA-RISC 2.0 or MIPS III/IV
in the sense that they operate on 64-bit values and produce 64-bit
results (yes, there are corner exceptions like the MIPS use of the
HI/LO registers.) All of these architectures have some instructions
which perform operations where the lower 32-bits of the result are
sign extended before being written back into a 64-bit register. No
implimentation of these supports more than 48-bits of virtual address
space. All of them are considered 64-bit machines by all but the
most clueless, and all of them run more than one operating system
which provides differing levels of support for 64-bit code, which is
why you have to seperate the machine from the runtime environment.
(Doesn't Java always have 64-bit longs and 32-bit references
regardless of what it runs on?)
Had you given an answer of 8 for the code above, you would still be
assuming that 'char' was 8-bits. With the TI development tools I
last used on TI's 320C30, the output would have been 1 even though
it is a 32-bit machine because 'char' is 32-bits. Other distortions
include 36-bit machines with 9-bit characters.
-Steve
< Useless overly long output of the "file /usr/bin/*" command snipped.>
> It looks like a 32-bit OS, because it is.
You're confusing userland programs with the OS.
> "Rev. Don Kool" <old...@home.com> wrote:
>
>
> < Useless overly long output of the "file /usr/bin/*" command snipped.>
>
>> It looks like a 32-bit OS, because it is.
>>
>
> You're confusing userland programs with the OS.
Not at all, Steve. Get a Systems Administrator to log in as root and
show you the same exercise in "/usr/sbin". You will see that SOLARIS is
32-bit. It has some built in kludges to emulate a 64-bit environment
but at its heart, SOLARIS is a 32-bit OS.
It's the other way round: True64 is a limited 64 bit environment because
it _only_ gives you a 64 bit compile environment while Solaris allows
you to choose between a 32 and a 64 bit environment vie compile time
options.
It is much easier to only have 64 bit support than to have what wou get with
Solaris: full64 bit support AND full 32 bit support.
>Is this why IRIX has routines like "lseek()" and "lsee64()" calls in its API? Or
>why OpenVMS has specialized "_64" versions of APIs? Or why Tru64 UNIX
>has "time()" and "time64()" calls? Every one of these operating systems has
>hacks to allow software written for 32-bit machines to inherit some additional
>64-bit capabilities, so Solaris is certainly not the exception here.
It is a bit different.
True 64 was only 64 bit bit but there is a limited 64 bit environment that
did not have 64 bit time_t because DEC was so silly to change time_t to become
an int on their 64 bit alpha environment.
Later they discovered that they made a big mistake and so they needed to add
time64() for decent 64 bit support.
> Often times it is helpful to read at least the subject line of the thread
> that you jump into. The original poster was asking about SOLARIS 2.6.
What is this "SOLARIS" thing you keep wittering on about. I presume
you mean Solaris.
Also, you didn't qualify your statement with a version; you just said
that Solaris is a 32-bit OS. Given that that statement was written in
the present tense, it's fair to think that you're talking about the
current version, regardless of the title of the thread.
There's nothing stopping Sun from making cc produce 64-bit executables
by default on a 64-bit kernel, except backwards compatability. So if
anything, Solaris is a true 64-bit OS, with some 32-bit backwards
compatablity tacked on.
A 64-bit application does NOT use the transitional xxx64 interfaces
that are provided. The kernel is 64-bit clean. Therefore, Solaris
is a 64-bit OS.
Now, why don't you scurry back under that rock you've been hiding
for the last few months, and stop making a fool of yourself in public?
Happy to have cleared things up for you,
--
Rich Teer
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
> Rev. Don Kool <old...@home.com> wrote:
>>>However, that definition does not seem particularly
>>>useful to me. It needlesly penalises operating systems which support more
>>>than one programming environment.
>>>
>> Not really. It draws a distinction between operating systems
>>that are true 64-bit operating systems and operating sysetms such as
>>SOLARIS that have limited 64-bit support while claiming to be fully
>>64-bit operating systems.
> It's the other way round: True64 is a limited 64 bit environment because
> it _only_ gives you a 64 bit compile environment while Solaris allows
> you to choose between a 32 and a 64 bit environment vie compile time
> options.
>
> It is much easier to only have 64 bit support than to have what wou get with
> Solaris: full64 bit support AND full 32 bit support.
You are allowing yourself to become an apologist for SUN. That's never a
good thing. A real 64-bit OS (e.g. Tru64 UNIX) doesn't have
restrictions on how 2GB files are handled. SOLARIS does and that fact
alone makes it a 32-bit OS masquerading as a 64-bit OS. Don't fall for
SUN's hype.
> On Sun, 18 Nov 2001, Rev. Don Kool wrote:
>
>
>> Often times it is helpful to read at least the subject line of the thread
>>that you jump into. The original poster was asking about SOLARIS 2.6.
[...clueless newbie netcop attempts skipped...]
> Also, you didn't qualify your statement with a version;
The subject qualifies it.
> you just said
> that Solaris is a 32-bit OS. Given that that statement was written in
> the present tense, it's fair to think that you're talking about the
> current version, regardless of the title of the thread.
Regardless of the SOLARIS version, it isn't a real 64-bit OS.
> There's nothing stopping Sun from making cc produce 64-bit executables
> by default on a 64-bit kernel, except backwards compatability. So if
> anything, Solaris is a true 64-bit OS, with some 32-bit backwards
> compatablity tacked on.
>
> A 64-bit application does NOT use the transitional xxx64 interfaces
> that are provided. The kernel is 64-bit clean. Therefore, Solaris
> is a 64-bit OS.
SOLARIS treats 2GB files as special cases and doesn't support them in all
instances. Therefore SOLARIS is not a 64-bit OS.
Yours in the glory that is our Lord Jesus Christ,
> On Sat, 17 Nov 2001, Rev. Don Kool wrote:
>
>
>> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>>
>
> You couldn't be more wrong. Solaris has been fully 64-bit capable
> OS since Solaris 7 was released, a few years ago.
Actually, since the OP was asking about Solaris 2.6 (aka SunOS
5.6, aka Solaris 6, if anyone called it that), Don's answer may
be correct for the version they're asking about.
But yes, Rich is right for 2.7+ (as evidenced by the fellow I work
with who managed to create a 38-gig tar file the other night, then
found out that oh, 'scp' can't handle a file that big. Whoops).
-Dan
--
Available for Biz, Pics, Tech and Words - http://danbirchall.com/
Some opinions are at http://dbirchall.epinions.com/user-dbirchall
"You must be the change you wish to see in the world." - M Gandhi
Please read my address carefully if you're going to send me spam!
> Stefaan A Eeckels wrote:
>
> > "Rev. Don Kool" <old...@home.com> wrote:
> >
> >
> > < Useless overly long output of the "file /usr/bin/*" command snipped.>
> >
> >> It looks like a 32-bit OS, because it is.
> >>
> >
> > You're confusing userland programs with the OS.
>
>
> Not at all, Steve. Get a Systems Administrator to log in as root and
> show you the same exercise in "/usr/sbin". You will see that SOLARIS is
> 32-bit. It has some built in kludges to emulate a 64-bit environment
> but at its heart, SOLARIS is a 32-bit OS.
You're still confusing userland with the OS. Please learn to be
accurate. If your gripe is that many userland programs are still
only available in 32-bit mode, you have a point. If you maintain that
Solaris running in 64-bit mode on 64-bit hardware with 64-bit drivers
is not a 64-bit OS, you're only proving you're an ignoramus.
So it's only a TRUE 64-bit OS if you gratuitously break backward
compatibility with 32-bit binaries?
If you build a 64-bit executable, the largefile thing is a non-issue,
because 64-bit executables use a different API.
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
Solaris 7 and later can operate in two modes - the 32-bit with 64-bit
kludges you describe, or true 64-bit, in which there is no such thing
as "large file aware" hacks. If you compile a program in 64-bit mode,
you don't need the large-file aware changes, they are only there for
32-bit mode programs.
--
________________________________________________________________________
Alan Coopersmith al...@alum.calberkeley.org
http://soar.Berkeley.EDU/~alanc/ aka: Alan.Coo...@Sun.COM
Working for, but definitely not speaking for, Sun Microsystems, Inc.
>>>
>>> No. Sadly SOLARIS is not a true 64-bit operating system.
>>>
>>
>> Once again, Don Fool gets it wrong. Solaris 7 and 8. Read about them, Don.
> The original poster was talking about SOLARIS
> 2.6, not SOLARIS 7 or 8.
But YOU weren't, Don. Your comment would have been correct if you had
been specific.
> Rev. Don Kool <old...@home.com> wrote:
>>Mark takes quite a while to verify what I pointed out earlier; SOLARIS
>>is a 32-bit OS with tacked on kludges to emulate 64-bit operation. As
>>long as "man largefile" returns a page, SOLARIS will still be a 32-bit
>>OS.
> So it's only a TRUE 64-bit OS if you
Don't need to treat 2GB files as special cases.
> gratuitously break backward compatibility with 32-bit binaries?
A true 64-bit operating system doesn't have 32-bit binaries to be
compatible with.
> If you build a 64-bit executable,
If you are able to build anything but, it isn't a true 64-bit OS.
> the largefile thing is a non-issue,
> because 64-bit executables use a different API.
Tell SOLARIS "mailx" and "vi" that.
> On Sun, 18 Nov 2001 21:08:05 GMT
> "Rev. Don Kool" <old...@home.com> wrote:
>>Stefaan A Eeckels wrote:
>>>"Rev. Don Kool" <old...@home.com> wrote:
[...snip...]
>>Not at all, Steve. Get a Systems Administrator to log in as root and
>>show you the same exercise in "/usr/sbin". You will see that SOLARIS is
>>32-bit. It has some built in kludges to emulate a 64-bit environment
>>but at its heart, SOLARIS is a 32-bit OS.
> You're still confusing userland with the OS. Please learn to be
> accurate. If your gripe is that many userland programs are still
> only available in 32-bit mode, you have a point. If you maintain that
> Solaris running in 64-bit mode on 64-bit hardware with 64-bit drivers
> is not a 64-bit OS, you're only proving you're an ignoramus.
It is not the "userland [sic]" programs that make SOLARIS a 32-bit OS
with limited 64-bit 'support'. As recently as 07/01, SOLARIS can't
"mailx", "vi" or "lp" a 2GB file. A true 64-bit OS would not have that
problem. A true 64-bit OS doesn't share 32-bit OS's like SOLARIS'
idiocy of 2GB files as being "large files". SOLARIS is a poseur. Those
who parrot the SUN company line are brainwashed sycophants.
> Rich Teer wrote:
>> Rev. Don Kool wrote:
>>> No. Sadly SOLARIS is not a true 64-bit operating system. They have
>> You couldn't be more wrong. Solaris has been fully 64-bit capable
>> OS since Solaris 7 was released, a few years ago.
> Actually, since the OP was asking about Solaris 2.6 (aka SunOS
> 5.6, aka Solaris 6, if anyone called it that), Don's answer may
> be correct for the version they're asking about.
The "OP was asking about Solaris 2.6", and Don's answer was absolutely
accurate.
> But yes, Rich is right for 2.7+ (as evidenced by the fellow I work
> with who managed to create a 38-gig tar file the other night, then
> found out that oh, 'scp' can't handle a file that big. Whoops).
Actually no version of SOLARIS is really a 64-bit operating system. Even
as recently as SOLARIS 8 07/01, SOLARIS still treats 2GB files as
special cases. Real 64-bit operating systems make no distinction
between 2GB files and any other files. Do "man largefile" on a SOLARIS
system and it will detail its limitations.
Gary, my convicted child molesting friend, my comment about SOLARIS not
being a true 64-bit operating system is correct no matter which version
of SOLARIS you're speaking of.
Happy to have cleared things up for you,
> Actually no version of SOLARIS is really a 64-bit operating system. Even
> as recently as SOLARIS 8 07/01, SOLARIS still treats 2GB files as
A 64-bit application on Solaris 7 or later does NOT treat files > 2 GB
as a special case. All the file offsets are 64-bits.
Stop making a complete fool of yourself in public and get a clue
before you open you mouth in future.
Happy to have cleared things up for you,
--
> Actually, since the OP was asking about Solaris 2.6 (aka SunOS
> 5.6, aka Solaris 6, if anyone called it that), Don's answer may
Solaris 2.6 was never referred to as Solaris 6...
> be correct for the version they're asking about.
Agreed, but read Don's answer carefully. He says "SOLARIS is not
a 64 bit operating system". Despite incorrectly capilising the
name, he didn't limit his statement. He wrote in the present
tense, and hence it's reasonable to read that he's talking about
the current version (his later posts confirm this). The current
version of Solaris IS 64-bit. Whether or not a specific application
is 64-bit is a different kettle of fish altogether, something that
seems to escape the annoying reverand.
> It is not the "userland [sic]" programs that make SOLARIS a 32-bit OS
> with limited 64-bit 'support'. As recently as 07/01, SOLARIS can't
> "mailx", "vi" or "lp" a 2GB file. A true 64-bit OS would not have that
> problem.
mailx, vi and lp are userland programs. They are not the OS.
> A true 64-bit OS doesn't share 32-bit OS's like SOLARIS'
> idiocy of 2GB files as being "large files".
It doesn't treat >2GB files anyway special. 32-bit userland programs
do when compiled with the transitional compilation interface.
In any case, you've got the wrong OS in your sights. It was AIX
in the 4.3.x incarnations that was the 32-bit OS that supported
64-bit programs. It too has the transitional interface that allows
32 bit programs to support files larger than 2GB.
Remember the dash-dash-space. You were wrong then too.
> If that prints 64, pointers are 512 bits.
Yes ! sorry, i messed it up.
I'll re-phrase, if it prints '8' it's run on a 64-bit system (where generic
pointers are 8 bytes ( = 64 bits), if it prints '4' it's an plain-old
32 bit machine, and you are in a maze littered with fixes for
various shortcomins.
> This is an incredibly silly exercise anyway - the answers to this
> question, which pertains to Solaris, all seem to fall short of providing
> any useful information.
> Solaris 7 and later are indeed true fully-fledged 64-bit operating
> environments. When hosted on a 64-bit (sparcv9) system, a 64-bit kernel
> will load by default in most cases.
> Even though a 64-bit kernel is in use, the system will be fully capable
> of natively running 32-bit and 64-bit applications. Running "isainfo
> -v" and "isalist" will show you exactly what types of applications the
> system will run. You can determine what ISA a specific application
> conforms to by using the "file" utility, which will extract the relevant
> data from the ELF structures.
> Sun is big on binary compatibility - from software release to release,
> and across their hardware product line. This allows developers to
> deploy a single binary for Solaris-on-SPARC regardless of
> characteristics like kernel architecture and revision. Not limiting a
> 64-bit kernel to 64-bit applications is a tremendous win.
> Most of the tools supplied with the system (and built for the system)
> still use 32-bit executables. This is not a problem - these tools
> typically don't need to be 64-bit to function properly. 64-bit
> applications won't run any better or any faster than their 32-bit
> counterparts, in fact, they'll typically run slightly slower, and they
> won't run at all on a 32-bit kernel. The primary reasons for building a
> 64-bit application is to take advantage of a larger address space, or to
> interact directly with a 64-bit kernel.
> When run your little test program on one of my Solaris-on-SPARC systems,
> I will see either 4 or 8, depending on how I compile it. The machines
> are 64-bit and the kernels are 64-bit, but the applications can be
> either 32- or 64-bit, and can conform to a number of SPARC-variant ISAs.
> Mark
>>> Sometimes, it helps to read manual to prevent you from writing such
>>> false claims.
>>
>>> Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
>>> than 3 years.
>>
>>Hmm.
>>
>>A 64 bit-machine is something that will output '64' when the following
>>program is run :
>>#include <stdio.h>
>>main()
>>{
>> void *p;
>> printf("%d \n",sizeof((void *)p));
>>}
>>
>>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>>this, Irix tries to use 32 bit by default.
> False in two ways:
> the program should output "8 " if run on a 64 bit OS _and_ if it
> previously has been compiled into a 64 bit binary.
It shure will print '8' on a 64 bit machine. But the previous
history is irrelevant. 64 bit machine will simply use 8 bytes
as pointers
> --
> EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
> j...@cs.tu-berlin.de (uni) If you don't have iso-8859-1
> schi...@fokus.gmd.de (work) chars I am J"org Schilling
> URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
> > That depends on the definition of "a real 64-bit OS." I do not know of a
> > standard or specification which defines that term, so it's not very useful
> > unless we can come to the common agreement on its meaning before we
> > proceed.
> >
> > If you take it to mean "A real 64-bit OS has 64-bit pointers in the
> > default programming environment" then, indeed, Solaris would not qualify
> > as "a real 64-bit OS."
>
> Exactly! SOLARIS does not, in any sense of the term, qualify as a true
> 64-bit OS.
I suppose you are now using the term "true 64-bit OS" in the same sense as
you have previously used the term "a real 64-bit OS."
> > However, that definition does not seem particularly
> > useful to me. It needlesly penalises operating systems which support more
> > than one programming environment.
>
> Not really. It draws a distinction between operating systems
> that are true 64-bit operating systems and operating sysetms such as
> SOLARIS that have limited 64-bit support while claiming to be fully
> 64-bit operating systems.
I disagree. It merely draws a distinction between operating systems on
which you get 64-bit programming environment by default and those on which
you do not. For practical purposes, in my experience, the distinction is
irrelevant.
BTW, Solaris does not claim to be "a fully 64-bit operating system." As
standards(5) man page would tell you, it claims:
Solaris 7 also supports two application programming environments,
ILP32 (32-bit) and LP64 (64-bit).
However, a question which begs the answer is how would you call operating
systems which fully support 64-bit programming environment, although that
environment is not the default one. Unreal 64-bit operating systems?
Surreal 64-bit operating systems?
Let's take this a bit further and assume that Solaris for IA-64 would be
released in the near future. It could happen that on that architecture
Solaris would by default offer 64-bit programming environment, while stil
having 32-bit programming environment by default on SPARC and x86 systems.
How would you classify Solaris in that case?
--
.-. .-. Errors have been made. Others will be blamed.
(_ \ / _)
| da...@willfork.com
|
Oui, vous, monsieur.
A flamer is hiding and lurking in every one of us
Waiting for the right moment to come to pass.
With appologies to Dj. B. I can't translate and mutilate verses very good
without rhyming dictionary at hand.
Seriously though, that fl^H^Hdiscussion has been most educational for me.
Not because of large files, but because that was the first time I've seen
somebody arguing binary compatibility so consistently and stubbornly. I've
never had the chance to thank you for that. So, thank you.
> In comp.unix.admin Mark Mentovai <ne...@mentovai.com> wrote:
> > pe...@icke-reklam.ipsec.nu.invalid wrote:
> >> A 64 bit-machine is something that will output '64' when the following
> >> program is run :
> >> #include <stdio.h>
> >> main()
> >> {
> >> void *p;
> >> printf("%d \n",sizeof((void *)p));
> >> }
>
> > If that prints 64, pointers are 512 bits.
>
> Yes ! sorry, i messed it up.
>
> I'll re-phrase, if it prints '8' it's run on a 64-bit system (where generic
> pointers are 8 bytes ( = 64 bits), if it prints '4' it's an plain-old
> 32 bit machine, and you are in a maze littered with fixes for
> various shortcomins.
So you mean that adding '-xarch=v9' while compiling in some magical
way transmogrifies the "32 bit" sun box to 64 bits?
[snip]
>
> --
> Peter Håkanson
> IPSec Sverige (At the Riverside of Gothenburg, home of Volvo)
> Sorry about my e-mail address, but i'm trying to keep spam out.
> Remove "icke-reklam"and "invalid" and it works.
Thomas
> > I'll re-phrase, if it prints '8' it's run on a 64-bit system (where generic
> > pointers are 8 bytes ( = 64 bits), if it prints '4' it's an plain-old
> > 32 bit machine, and you are in a maze littered with fixes for
> > various shortcomins.
>
> So you mean that adding '-xarch=v9' while compiling in some magical
> way transmogrifies the "32 bit" sun box to 64 bits?
Please get a clue.
The UltraŹSparc is a 64 bit processor.
Solaris 7 and 8 both come with 64bit and 32 bit kernels, if you
have an Ultra it uses the 64bit kernel by default.
The 64 bit kernel supports both 32 and 64 bit applications.
Compiler switches allow you to make either 32 or 64 bit applications
so that you can build applications which will run on 64 only or
on both.
Solaris 2.6 and later allow you to build 32 bit applications which can
use 64 bit file pointers to allow files > 2Gb.
IOW, Solaris 7 and 8 on Ultra processors are fully 64 bit, with extras
to allow backward compatibility. 2.6 is a 32/64 hybrid which supports
large files.
Is that clear ?. Compatibility is a good thing.
> Actually no version of SOLARIS is really a 64-bit operating system. Even
>as recently as SOLARIS 8 07/01, SOLARIS still treats 2GB files as
>special cases. Real 64-bit operating systems make no distinction
>between 2GB files and any other files. Do "man largefile" on a SOLARIS
>system and it will detail its limitations.
While Solaris 7 and Solaris 8 _are_ true 64 bis os, True64 is _not_ a true 64 bit OS.
It still has a Y 2038 problem unless you use kludges for the time() interface.
>>> void *p;
>>> printf("%d \n",sizeof((void *)p));
>>>}
>>>
>>>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>>>this, Irix tries to use 32 bit by default.
>
>> False in two ways:
>
>> the program should output "8 " if run on a 64 bit OS _and_ if it
>> previously has been compiled into a 64 bit binary.
>
>It shure will print '8' on a 64 bit machine. But the previous
>history is irrelevant. 64 bit machine will simply use 8 bytes
>as pointers
Wrong: on a limited 64 bit OS you may be right, but Solaris is not a
limited 64 bit platform and supports a 32 bit environent in addition.
As it turns out that most programs are faster when compiled in 32 bit
mode, this is the default on Solaris.
> As it turns out that most programs are faster when compiled in 32 bit
> mode, this is the default on Solaris.
I think the default was much more influenced with the compatibility
considerations for the existing (although possibly incorrect) programs,
makefiles etc. than with the performance issues.
Sun has always been very conservative and cautious with respect to
compatibility and performance considerations usually had the second place.
pe...@icke-reklam.ipsec.nu.invalid writes:
>> the program should output "8 " if run on a 64 bit OS _and_ if it
>> previously has been compiled into a 64 bit binary.
>It shure will print '8' on a 64 bit machine. But the previous
>history is irrelevant. 64 bit machine will simply use 8 bytes
>as pointers
The previous history is very relevant.
Didn't Digital ship a runtime code translater that could run SunOS 4.x
and other binaries on Digital Unix?
All those 32 bit OS binaries would run on that 64 bit OS and print "4";
surely that doesn't make whatever-its-called-now a 32 bit OS?
Your statement seems to imply that any OS capable of running 32 bit binaries
is a 32 bit OS; I would argue that the "bitness" of on OS is the determined
by the "maximum bitness" of programs such an OS can run.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
> Thomas Tornblom wrote:
> >
> > pe...@icke-reklam.ipsec.nu.invalid writes:
>
> > > I'll re-phrase, if it prints '8' it's run on a 64-bit system (where generic
> > > pointers are 8 bytes ( = 64 bits), if it prints '4' it's an plain-old
> > > 32 bit machine, and you are in a maze littered with fixes for
> > > various shortcomins.
> >
> > So you mean that adding '-xarch=v9' while compiling in some magical
> > way transmogrifies the "32 bit" sun box to 64 bits?
>
> Please get a clue.
Are you telling me to get a clue?
I *know* how this works, I was asking how the poster explains that the
output of the crappy test program changes from 4 to 8 by compiling it
differently *if* it is a 32 bit system as he seemed to imply.
Thomas
Ooops - I'll take more care with my attributions in future.
>> In comp.unix.admin Mark Mentovai <ne...@mentovai.com> wrote:
>> > pe...@icke-reklam.ipsec.nu.invalid wrote:
>> >> A 64 bit-machine is something that will output '64' when the following
>> >> program is run :
>> >> #include <stdio.h>
>> >> main()
>> >> {
>> >> void *p;
>> >> printf("%d \n",sizeof((void *)p));
>> >> }
>>
>> > If that prints 64, pointers are 512 bits.
>>
>> Yes ! sorry, i messed it up.
>>
>> I'll re-phrase, if it prints '8' it's run on a 64-bit system (where generic
>> pointers are 8 bytes ( = 64 bits), if it prints '4' it's an plain-old
>> 32 bit machine, and you are in a maze littered with fixes for
>> various shortcomins.
> So you mean that adding '-xarch=v9' while compiling in some magical
> way transmogrifies the "32 bit" sun box to 64 bits?
No. Of course not. As all testprograms it gives a hint about something. In
this case what a compiler on a specific platform uses as a pointer.
An environment that has 64 bits "native" will tell you that by emitting '8',
an environment that has 32 bits will emit an '4'. But if you tweak your
compiler in some way all odds are off. You don't know for shure if
file offsets or general int's will be 32 or 64 ( or anything else).
I have alpha / openbsd specifically ( i have all reason to belive that
alpha/digitalunix ( i simply refuse to name it by silly pc-clones name))
in mind, here all "int" are 64 bits (unless specifically 32 or 16 is used),
all api uses 64bit arguments. It's a no-brainer to use file ( and file offset)
up to 64 bit in size. And in theory, time_t could equally well be 64 bits.
But as all testprograms it has limitations.
<SNIP>
___________________
/| /| | |
||__|| | Please do |
/ O O\__ NOT |
/ \ feed the |
/ \ \ the trolls |
/ _ \ \ ______________|
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ \ __||
/ / \ |____| ||
/ | | /| | --|
| | |// |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ // |
/ _ \\ _ // | /
* / \_ /- | - | |
* ___ c_c_c_C/ \C_c_c_c____________
--
SimonB
Nice, but why do you have "the" twice? Is it a bug or a feature? :-)
Bye, Dragan
--
Dragan Cvetkovic,
To be or not to be is true. G. Boole
>> Often times it is helpful to read at least the subject line of the thread
>> that you jump into. The original poster was asking about SOLARIS 2.6.
> What is this "SOLARIS" thing you keep wittering on about. I presume
> you mean Solaris.
Rich,
You're right, of course, but you're feeding the troll the attention that he
wants.
Dave Hinz
> Mark Mentovai <ne...@mentovai.com> wrote:
>>pe...@icke-reklam.ipsec.nu.invalid wrote:
>>
>>>A 64 bit-machine is something that will output '64' when the following
>>>program is run :
>>>#include <stdio.h>
>>>main()
>>>{
>>> void *p;
>>> printf("%d \n",sizeof((void *)p));
>>>}
>>>
>
>>If that prints 64, pointers are 512 bits.
>>
>
> Yes ! sorry, i messed it up.
>
> I'll re-phrase, if it prints '8' it's run on a 64-bit system (where generic
> pointers are 8 bytes ( = 64 bits), if it prints '4' it's an plain-old
> 32 bit machine, and you are in a maze littered with fixes for
> various shortcomins.
Indeed. On SOLARIS 8 it returns 4. 'nuff said.
Try to use "mail" or "vi" on a 2GB file under SOLARIS 7 or 8. It doesn't
work because they are still 32-bit operating systems with limited 64-bit
functionality.
> Is that clear ?. Compatibility is a good thing.
Yes, it's clear that SOLARIS is not a real 64-bit OS.
Unlike SPARC/SOLARIS, Tru64 UNIX on ALPHA is a true 64-bit environment.
No need for the SOLARIS kludge of so-called "large files". When an
operating system is truly a 64-bit operating system, 2GB files are not
special cases and there is no need to have a laundry list of utilities
that either support or don't support them.
> Rev. Don Kool wrote:
>> Drazen Kacar wrote:
[...snip...]
>> Exactly! SOLARIS does not, in any sense of the term, qualify as a true
>> 64-bit OS.
> I suppose you are now using the term "true 64-bit OS" in the same sense as
> you have previously used the term "a real 64-bit OS."
You are overly concerned with semantics. The real measure of a true
64-bit operating system is if it suffers from the limitations of 32-bit
operating systems. By kludging the handling of 2GB files, SOLARIS shows
itself to be a 32-bit operating system. SUN has built an entire house
of cards around nebulous terms such as "large file", "large file aware"
and "large file safe". To a real 64-bit operating system, 2GB files
require no special handling.
>>>However, that definition does not seem particularly
>>>useful to me. It needlesly penalises operating systems which support more
>>>than one programming environment.
>> Not really. It draws a distinction between operating systems
>> that are true 64-bit operating systems and operating sysetms such as
>> SOLARIS that have limited 64-bit support while claiming to be fully
>> 64-bit operating systems.
> I disagree.
Because you don't grasp the concept that a true 64-bit operating system
doesn't suffer from 32-bit limitations.
> It merely draws a distinction between operating systems on
> which you get 64-bit programming environment by default and those on which
> you do not. For practical purposes, in my experience, the distinction is
> irrelevant.
>
> BTW, Solaris does not claim to be "a fully 64-bit operating system."
Because, as I've pointed out on numerous occasions, SOLARIS is not a real
64-bit operating system.
> As standards(5) man page would tell you, it claims:
>
> Solaris 7 also supports two application programming environments,
> ILP32 (32-bit) and LP64 (64-bit).
>
> However, a question which begs the answer is how would you call operating
> systems which fully support 64-bit programming environment, although that
> environment is not the default one. Unreal 64-bit operating systems?
> Surreal 64-bit operating systems?
non-SOLARIS.
> Let's take this a bit further and assume that Solaris for IA-64 would be
> released in the near future. It could happen that on that architecture
> Solaris would by default offer 64-bit programming environment, while stil
> having 32-bit programming environment by default on SPARC and x86 systems.
> How would you classify Solaris in that case?
An also-ran.
Hope this helps,
under solaris, you can use isainfo:
http://www.science.uva.nl/pub/solaris/solaris2.html#q3.66
--
robert sherman
css, cee
georgia institute of technology
atlanta, ga, usa
> Rev. Don Kool <old...@home.com> wrote:
>>SOLARIS can't
>>"mailx", "vi" or "lp" a 2GB file.
> How many users have ever had any reasonable reason to send a 2GB e-mail,
> edit a 2GB text file using an ancient text editor, or printed an 2GB
> text file? Why should Sun spend time making these tools 64 bit clean
> instead of spending their resources on something that their users
> actually need?
So that they could reasonably claim to be offering a 64-bit operating
system. As it is, their claims don't mesh with reality.
> Sun spend time making sure that those tools for wich large files were
> important could handle large files even when running on older 32 bit
> hardware. The same tools running on thru64 can't even handle a 2KB
> file on older 32 bit hardware.
You still miss the point, Goron; a true 64-bit operating system doesn't
think of 2GB files as "large files". In a real 64-bit operating system,
there is nothing special about a 2GB file.
Happy to have cleared things up for you,
Don
> On Mon, 19 Nov 2001 03:12:06 GMT
> "Rev. Don Kool" <old...@home.com> wrote:
>> It is not the "userland [sic]" programs that make SOLARIS a 32-bit OS
>>with limited 64-bit 'support'. As recently as 07/01, SOLARIS can't
>>"mailx", "vi" or "lp" a 2GB file. A true 64-bit OS would not have that
>>problem.
> mailx, vi and lp are userland programs. They are not the OS.
>>A true 64-bit OS doesn't share 32-bit OS's like SOLARIS'
>>idiocy of 2GB files as being "large files".
> It doesn't treat >2GB files anyway special. 32-bit userland programs
> do when compiled with the transitional compilation interface.
>
> In any case, you've got the wrong OS in your sights. It was AIX
> in the 4.3.x incarnations that was the 32-bit OS that supported
> 64-bit programs. It too has the transitional interface that allows
> 32 bit programs to support files larger than 2GB.
>
> Remember the dash-dash-space. You were wrong then too.
Steve, a true 64-bit operating system doesn't have 32-bit utilities.
SOLARIS, like all 32-bit operating systems, has problems with 2GB files.
> Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>> <pe...@icke-reklam.ipsec.nu.invalid> wrote:
>>>Joerg Schilling <j...@cs.tu-berlin.de> wrote:
>>>
>
>>>>Sometimes, it helps to read manual to prevent you from writing such
>>>>false claims.
>>>>
>>>>Solaris (>= S 7 ) is a true 64 bit OS and it has been available for more
>>>>than 3 years.
>>>>
>>>Hmm.
>>>
>>>A 64 bit-machine is something that will output '64' when the following
>>>program is run :
>>>#include <stdio.h>
>>>main()
>>>{
>>> void *p;
>>> printf("%d \n",sizeof((void *)p));
>>>}
>>>
>>>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>>>this, Irix tries to use 32 bit by default.
>>>
>
>>False in two ways:
>>
>
>>the program should output "8 " if run on a 64 bit OS _and_ if it
>>previously has been compiled into a 64 bit binary.
>>
>
> It shure will print '8' on a 64 bit machine. But the previous
> history is irrelevant. 64 bit machine will simply use 8 bytes
> as pointers
Exactly, that's why it prints "4" on a SOLARIS system.
> <pe...@icke-reklam.ipsec.nu.invalid> wrote:
>>>> void *p;
>>>> printf("%d \n",sizeof((void *)p));
>>>>}
>>>>
>>>>And to my knowledge only alpha based ( digitalunix and net/open BSD ) will do
>>>>this, Irix tries to use 32 bit by default.
>>>>
>>>False in two ways:
>>>
>>>the program should output "8 " if run on a 64 bit OS _and_ if it
>>>previously has been compiled into a 64 bit binary.
>>>
>>It shure will print '8' on a 64 bit machine. But the previous
>>history is irrelevant. 64 bit machine will simply use 8 bytes
>>as pointers
>>
>
> Wrong: on a limited 64 bit OS you may be right, but Solaris is not a
> limited 64 bit platform and supports a 32 bit environent in addition.
> As it turns out that most programs are faster when compiled in 32 bit
> mode, this is the default on Solaris.
That's the "default" because SOLARIS is a 32-bit operating system. A
true 64-bit operating system doesn't create 32-bit code by default.
Happy to have cleared things up for you,
> [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]]
>
> pe...@icke-reklam.ipsec.nu.invalid writes:
>
>
>>>the program should output "8 " if run on a 64 bit OS _and_ if it
>>>previously has been compiled into a 64 bit binary.
>>>
>
>>It shure will print '8' on a 64 bit machine. But the previous
>>history is irrelevant. 64 bit machine will simply use 8 bytes
>>as pointers
>>
>
>
> The previous history is very relevant.
>
> Didn't Digital ship a runtime code translater that could run SunOS 4.x
> and other binaries on Digital Unix?
>
> All those 32 bit OS binaries would run on that 64 bit OS and print "4";
> surely that doesn't make whatever-its-called-now a 32 bit OS?
>
> Your statement seems to imply that any OS capable of running 32 bit binaries
> is a 32 bit OS; I would argue that the "bitness" of on OS is the determined
> by the "maximum bitness" of programs such an OS can run.
No, any OS that builds an entire fiction of "large files" being over 2GB
in size is a 32-bit operating system. 2GB files are not special cases
in a true 64-bit operating system.
> On Mon, 19 Nov 2001, Rev. Don Kool wrote:
>> Actually no version of SOLARIS is really a 64-bit operating system. Even
>>as recently as SOLARIS 8 07/01, SOLARIS still treats 2GB files as
>>
>
> A 64-bit application on Solaris 7 or later does NOT treat files > 2 GB
> as a special case. All the file offsets are 64-bits.
If SOLARIS 7 was a real 64-bit OS, there wouldn't be applications that
aren't 64-bit.
[...typical SUN worshipper ad hominem snipped...]
Yours in Christ,
Mail and vi are NOT an operating system. They are applications.
There is no sane need for either to be 64 bit.
Solaris 7 and 8 are 64 bit operating systems that allow you to run
either 32 or 64 bit applications. Many applications will remain
32 bit because that makes them smaller and faster. OTOH several
of my applications are now 64 bit because they need the space.
You are clearly a troll without a clue.
Voetsak.
> Rev. Don Kool <old...@home.com> wrote:
>> Actually no version of SOLARIS is really a 64-bit operating system. Even
>>as recently as SOLARIS 8 07/01, SOLARIS still treats 2GB files as
>>special cases. Real 64-bit operating systems make no distinction
>>between 2GB files and any other files. Do "man largefile" on a SOLARIS
>>system and it will detail its limitations.
>>
>
> While Solaris 7 and Solaris 8 _are_ true 64 bis os, True64 is _not_ a true 64 bit OS.
>
> It still has a Y 2038 problem unless you use kludges for the time() interface.
SUN worshipper envy at its finest. In reality, SOLARIS is not a true
64-bit operating system. If it was, it would not require special
treatment of 2GB files. End of story.
Happy to have cleared things up for you,
> On Sun, 18 Nov 2001, Dan Birchall wrote:
>
>
>>Actually, since the OP was asking about Solaris 2.6 (aka SunOS
>>5.6, aka Solaris 6, if anyone called it that), Don's answer may
>>
>
> Solaris 2.6 was never referred to as Solaris 6...
Sure it was. Dan just referred to it that way. It's just SUN that never
did. Of course, for normal people, the world doesn't revolve around
SUN's misrepresentations.
>>be correct for the version they're asking about.
> Agreed, but read Don's answer carefully.
Yes, please do.
> He says "SOLARIS is not a 64 bit operating system".
A perfectly accurate statement even concerning the newer versions of SOLARIS.
> Despite incorrectly capilising the
ROTFLOLASTD! There's nothing like a clueless newbie spelling flame that
contains a spelling error. LOL!
> name, he didn't limit his statement. He wrote in the present
> tense, and hence it's reasonable to read that he's talking about
> the current version (his later posts confirm this). The current
> version of Solaris IS 64-bit.
No, my misguided young friend, it is not. As long as SOLARIS treats 2GB
files as something unique, they will not have fielded a true 64-bit
operating system.
> Whether or not a specific application
> is 64-bit is a different kettle of fish altogether, something that
> seems to escape the annoying reverand.
A failing blind SUN worshippers are willing to ignore.
> That's the "default" because SOLARIS is a 32-bit operating system. A
>true 64-bit operating system doesn't create 32-bit code by default.
An operating system does not create code at all. That's a job for
the compiler, not the operating system.
> Drazen Kacar wrote:
>
>> Rev. Don Kool wrote:
>>
>>> Drazen Kacar wrote:
>>
>
>
> [...snip...]
>
>
>>> Exactly! SOLARIS does not, in any sense of the term, qualify as a
>>> true 64-bit OS.
>>
>
>> I suppose you are now using the term "true 64-bit OS" in the same
>> sense as
>> you have previously used the term "a real 64-bit OS."
>
>
>
> You are overly concerned with semantics. The real measure of a true
Now I've seen it all... Don Kool appears to be a hypocrite. :*)
--
Regards,
N
-----------------------------------
Nicholas Bachmann
nabac...@yahoo.com
http://hermie.freeshell.org
"To Boldly Go Where Angels Fear To Tread"
-From the Infocom Game "Stationfall"
-----------------------------------
> "Rev. Don Kool" wrote:
>
>>Chris Newport wrote:
>>
>>
>>>Thomas Tornblom wrote:
>>>
>>>>pe...@icke-reklam.ipsec.nu.invalid writes:
[...]
> You are clearly a troll without a clue.
Did someone hit you with a clue by four, did you see the "Don't Feed the
Trolls" ASCII art, read one of the "Leave Don along" posts, or did you
figure this out all by yourself?
> You are overly concerned with semantics.
Now _that's_ comedy, people.
--
Erik Max Francis / m...@alcyone.com / http://www.alcyone.com/max/
__ San Jose, CA, US / 37 20 N 121 53 W / ICQ16063900 / &tSftDotIotE
/ \ Laws are silent in time of war.
\__/ Cicero
Esperanto reference / http://www.alcyone.com/max/lang/esperanto/
An Esperanto reference for English speakers.
Of course I'm concerned with semantics. If we don't define the terms
first, we'll be talking about different things. That's not very useful.
> The real measure of a true
> 64-bit operating system is if it suffers from the limitations of 32-bit
> operating systems.
I've had some logic classes in high school. If my memory is still good, a
negative definition (ie. trying to talk define something by stating what
properties that something doesn't posess) is not a proper definition.
You've entered in the field of religion here and I don't intend to even
try to change your religious beliefs.
> By kludging the handling of 2GB files, SOLARIS shows
> itself to be a 32-bit operating system. SUN has built an entire house
> of cards around nebulous terms such as "large file", "large file aware"
> and "large file safe".
I believe Sun thought those terms would be useful. Some people agree with
that.
> To a real 64-bit operating system, 2GB files require no special handling.
And operating system is exactly what?
> >> Not really. It draws a distinction between operating systems
> >> that are true 64-bit operating systems and operating sysetms such as
> >> SOLARIS that have limited 64-bit support while claiming to be fully
> >> 64-bit operating systems.
>
> > I disagree.
>
> Because you don't grasp the concept that a true 64-bit operating system
> doesn't suffer from 32-bit limitations.
Please.
> > BTW, Solaris does not claim to be "a fully 64-bit operating system."
>
> Because, as I've pointed out on numerous occasions, SOLARIS is not a real
> 64-bit operating system.
Or because the term "real 64-bit operating system" doesn't make much
sense.
> > However, a question which begs the answer is how would you call operating
> > systems which fully support 64-bit programming environment, although that
> > environment is not the default one. Unreal 64-bit operating systems?
> > Surreal 64-bit operating systems?
>
> non-SOLARIS.
But Solaris supports exactly that. Why would you use "non-SOLARIS" as a
name for Solaris?
> An also-ran.
>
> Hope this helps,
It doesn't.
--
.-. .-. Errors have been made. Others will be blamed.
(_ \ / _)
| da...@willfork.com
|
apparently not "'nuff" since it hasn't sunk in to your newbie head:
% cat foo.c
#include <stdio.h>
main()
{
void *p;
printf("%d \n",sizeof((void *)p));
}
% gcc foo.c
% file a.out
a.out: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically linked, not stripped
% ./a.out
8
% uname -sr
SunOS 5.8
%
(gcc version egcs-2.93.01 "sparcv9-sun-solaris2.7")
you mean other than that 32-bit time_t?
>No need for the SOLARIS kludge of so-called "large files".
no, just a so-called "large time" kludge.
In article <3BF9A884...@home.com>, Rev. Don Kool <old...@home.com> wrote:
> Indeed. On SOLARIS 8 it returns 4. 'nuff said.
All this proves is that the system is capable of running a compiler
that can generate 32-bit code (every computer is -- even an 8-bit Atari
800 could generate 32-bit code if you wanted to write the compiler) and
the system is capable of running 32-bit code.
So, once again, are you saying that the ability to run 32-bit code
makes a system not truly 64-bit?
Or are you saying the fact that you chose to run a compiler that
generates 32-bit code makes it not a 64-bit system?
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
Solaris 7 and 8 are complete 64-bit operating systems, capable
of running binaries compiled as 32-bit executables, which
implement the ILP32 data model, or 64-bit binaries, which
comply with the LP64 data model. In ILP32, Integers, Longs
and Pointers a 32-bits wide. In LP64, Longs and pointers are
64 bits wide, integers are 32 bits wide. The Solaris 64-bit
kernel can run either. Obviously, a 32-bit kernel can only
execute 32-bit binaries.
64-bitness can be whittled down to 3 differnet areas;
- 64-bit data types; specifically integers
- 64-bit files
- 64-bit address space
The latter is what most folks think about when they think
in terms of 64 bits.
Solaris has supported 64-bit integers from the beginning, through
the "long long" data type (as declared in a 'C' program).
Large file support came in 2.6, where the file offset needed
to be changed from a 32-bit signed int (thus the 2GB file
size limit), to a 64-bit data type. The implementation of large
file support was done in compliance with a set of standards and
practices put forth by the Large File Summit. The implementation
needed to deal with binary and source compatibility of A TON
of existing code, and acomplished that.
With the implementation of a complete 64-bit kernel, beginning
with Solaris 7 and on through Solaris 8, a 64-bit binary is,
by definition, large file aware, capable, etc. It just works.
It's not a hack, or a bolt-on, or a kludge. It's a 64-bit
kernel from the ground up.
The aforementioned definition of "if 'man largefile' returns
something, the OS is not 64-bit" is just plain nonsense.
Solaris 7 and 8 ARE TRUE 64-bit kernel's. That is irrefutable
when the implementation is explained and understood. Please
try to ignore the demented ramblings of the technically challenged.
Cheers,
Jim
"Rev. Don Kool" <old...@home.com> wrote in message news:<3BF879D5...@home.com>...
> gbur...@databasix.com wrote:
>
> > In comp.unix.solaris Rev. Don Kool <old...@home.com> wrote:
> >
> >>gbur...@databasix.com wrote:
> >>
>
> >>>>
> >>>> No. Sadly SOLARIS is not a true 64-bit operating system.
> >>>>
> >>>>
> >>>Once again, Don Fool gets it wrong. Solaris 7 and 8. Read about them, Don.
> >>>
> >
> >
> >>The original poster was talking about SOLARIS
> >>2.6, not SOLARIS 7 or 8.
> >>
> >
> > But YOU weren't, Don. Your comment would have been correct if you had
> > been specific.
>
>
> Gary, my convicted child molesting friend, my comment about SOLARIS not
> being a true 64-bit operating system is correct no matter which version
> of SOLARIS you're speaking of.
> Try to use "mail" or "vi" on a 2GB file under SOLARIS 7 or 8. It doesn't
Here Don demonstrates his lack of computer science knowledge,
by confusing an application with the underlying OS. Perhaps
he's been using M$ "OSes" for too long, where the distinction
is blurred at times.
--
Rich Teer
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
> A failing blind SUN worshippers are willing to ignore.
Interesting; you should try reading a few more of my posts.
Yes, I think Sun makes great hardware and software, but I'm
also ready to criticise them (one only needs to read my Type 6
keyboard rants to know this). If there was nothing to criticise,
they'd be (by definition) perfect; and Sun are far from perfect.
But that doesn't stop them from being (IMHO) one of the best, if
not THE best all round computer company.
A true operating system doesn't create code. That's the job of the
compiler, which isn't part of Solaris. Most of the compilers for
Solaris do generate 32-bit binaries by default, but there's nothing
stopping anyone from making a compiler for Solaris default to 64-bit
mode.
--
________________________________________________________________________
Alan Coopersmith al...@alum.calberkeley.org
http://soar.Berkeley.EDU/~alanc/ aka: Alan.Coo...@Sun.COM
Working for, but definitely not speaking for, Sun Microsystems, Inc.
>eric the brave <simon...@ixion.org.uk> writes:
>>
>> ___________________
>> /| /| | |
>> ||__|| | Please do |
>> / O O\__ NOT |
>> / \ feed the |
>> / \ \ the trolls |
>> / _ \ \ ______________|
>> / |\____\ \ ||
>> / | | | |\____/ ||
>> / \|_|_|/ \ __||
>> / / \ |____| ||
>> / | | /| | --|
>> | | |// |____ --|
>> * _ | |_|_|_| | \-/
>> *-- _--\ _ \ // |
>> / _ \\ _ // | /
>> * / \_ /- | - | |
>> * ___ c_c_c_C/ \C_c_c_c____________
>>
>> --
>> SimonB
>
>
>Nice, but why do you have "the" twice? Is it a bug or a feature? :-)
>
>
> Bye, Dragan
oops. It was a cut and paste. Honest....
--
SimonB
> In reality, SOLARIS is not a true 64-bit operating system.
Solaris is a 64-bit kernel when running on 64-bit hardware.
> If it was, it would not require special treatment of 2GB files.
It does not have special treatment of >2GB files when running
the 64-bit kernel.
> End of story.
Indeed. A Koolish consistency is the hobgoblin of little minds.
--
Stefaan (GPG Fingerprint 25D8 551B 4C0F BF73 3283 21F1 5978 D158 7539 76E4)
--
"Object-oriented programming is an exceptionally bad idea which
could only have originated in California." --Edsger Dijkstra
>
> That's the "default" because SOLARIS is a 32-bit operating system.
When running on 32-bit hardware.
> A true 64-bit operating system doesn't create 32-bit code by default.
An operating system doesn't create code, it runs it. But because you
seem to confuse OS and applications, this additional inanity was to
be expected.
You're wrong on this one like you were wrong on the dash dash space
issue. Just admit defeat, and broaden your mind by getting rid of
one prejudice.
Words cannot express how happy I am to know that this is the case.
> > be correct for the version they're asking about.
>
> Agreed, but read Don's answer carefully. He says "SOLARIS is not
> a 64 bit operating system". Despite incorrectly capilising the
> name, he didn't limit his statement.
Which is why I used the phrase "for the version they're talking
about." Thus limiting things.
--
Available for Biz, Pics, Tech and Words - http://danbirchall.com/
"You must be the change you wish to see in the world." - M Gandhi
Please read my address carefully if you're going to send me spam!