Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/31/17 10:30 AM, Richard L. Hamilton wrote:



On May 31, 2017, at 13:01, Alan Coopersmith  wrote:

On 05/31/17 09:43 AM, Richard L. Hamilton wrote:

The alternative would be a large times analog of large file support; why that 
wasn't done when 64-bit began, I don't understand. :-)


It was considered at Sun in the late 90's but discarded as going full LP64
already provided a solution without combinatorial explosion of test matrices
for large files x large times.  The large files API was created before LP64
was an option on most Unixes, including Solaris.



Testing, yes; that makes sense.

How are the time conversion functions doing with regard to time_t past 
INT32_MAX?  I see that (with a 64-bit executable) at least ctime() seems to 
work enough beyond for usual life and commercial purposes (aside from 
radioactive waste :-) ):

13:15:32[13]monster:/home/rlhamil> ./maxtime
time overflow after Tue Jan 19 03:14:07 2038
 in 32-bit signed two's complement
timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
t=2147483647: Tue Jan 19 03:14:07 2038

t=4294967294: Sun Feb  7 06:28:14 2106

t=8589934588: Wed Mar 16 12:56:28 2242

t=17179869176: Wed May 30 01:52:56 2514

t=34359738352: Tue Oct 26 03:45:52 3058

t=68719476704: Sun Aug 20 07:31:44 4147

t=137438953408: Wed Apr  8 15:03:28 6325

t=274877906816: (null)


On Solaris, ctime() is defined as returning a string of exactly 26 characters,
so it gives up when the year requires a 5th digit and doesn't fit.

Converting to strftime and compiling with -std=c99 -m64 -D_XOPEN_SOURCE=700
gets a bit further here:

for (t=INT32_MAX;t<=INT64_MAX && t>=0L;t<<=1) {
char s[100] = "";
struct tm *l = localtime();
if (l != NULL)
strftime(s, sizeof(s), "%a %b %e %H:%M:%S %Y", l);
else
snprintf(s, sizeof(s), "localtime(%ld) == NULL", t);
printf("t=%ld: %s\n", t, s);
}

time overflow after Tue Jan 19 03:14:07 2038
 in 32-bit signed two's complement
timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
t=2147483647: Tue Jan 19 03:14:07 2038
t=4294967294: Sun Feb  7 06:28:14 2106
t=8589934588: Wed Mar 16 12:56:28 2242
t=17179869176: Wed May 30 01:52:56 2514
t=34359738352: Tue Oct 26 03:45:52 3058
t=68719476704: Sun Aug 20 07:31:44 4147
t=137438953408: Wed Apr  8 15:03:28 6325
t=274877906816: Wed Jul 14 06:06:56 10680
t=549755813632: Tue Jan 25 12:13:52 19391
t=1099511627264: Mon Feb 20 00:27:44 36812
t=2199023254528: Fri Apr 10 00:55:28 71654
t=4398046509056: Sat Jul 19 01:50:56 141338
t=8796093018112: Mon Feb  4 03:41:52 280707
t=17592186036224: Fri Mar  8 07:23:44 559444
t=35184372072448: Sat May 14 14:47:28 1116918
t=70368744144896: Tue Sep 25 05:34:56 2231866
t=140737488289792: Sun Jun 19 11:09:52 4461763
t=281474976579584: Wed Dec  5 22:19:44 8921556
t=562949953159168: Wed Nov 10 20:39:28 17841143
t=1125899906318336: Wed Sep 19 17:18:56 35680317
t=2251799812636672: Wed Jun  7 10:37:52 71358665
t=4503599625273344: Tue Nov 11 21:15:44 142715360
t=9007199250546688: Mon Sep 24 18:31:28 285428751
t=18014398501093376: Sat Jun 17 13:02:56 570855533
t=36028797002186752: Tue Dec  1 02:05:52 1141709096
t=72057594004373504: localtime(72057594004373504) == NULL
t=144115188008747008: localtime(144115188008747008) == NULL
t=288230376017494016: localtime(288230376017494016) == NULL
t=576460752034988032: localtime(576460752034988032) == NULL
t=1152921504069976064: localtime(1152921504069976064) == NULL
t=2305843008139952128: localtime(2305843008139952128) == NULL
t=4611686016279904256: localtime(4611686016279904256) == NULL
t=9223372032559808512: localtime(9223372032559808512) == NULL

I suggest anyone working with such precise timestamps more than a billion years
in the future use a system more oriented towards such scientific calculations
than the C standard library.  I'm sure it's timezone code does not account for
the changes in the Earth's rotation nor the tectonic plate migration that will
have occurred over that timespan.

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Richard L. Hamilton]

> On May 31, 2017, at 13:01, Alan Coopersmith  
> wrote:
> 
> On 05/31/17 09:43 AM, Richard L. Hamilton wrote:
>> The alternative would be a large times analog of large file support; why 
>> that wasn't done when 64-bit began, I don't understand. :-)
> 
> It was considered at Sun in the late 90's but discarded as going full LP64
> already provided a solution without combinatorial explosion of test matrices
> for large files x large times.  The large files API was created before LP64
> was an option on most Unixes, including Solaris.
> 

Testing, yes; that makes sense.

How are the time conversion functions doing with regard to time_t past 
INT32_MAX?  I see that (with a 64-bit executable) at least ctime() seems to 
work enough beyond for usual life and commercial purposes (aside from 
radioactive waste :-) ):

13:15:32[13]monster:/home/rlhamil> ./maxtime
time overflow after Tue Jan 19 03:14:07 2038
 in 32-bit signed two's complement
timestamp 9223372036854775807 (INT64_MAX) cannot be processed by ctime()
t=2147483647: Tue Jan 19 03:14:07 2038

t=4294967294: Sun Feb  7 06:28:14 2106

t=8589934588: Wed Mar 16 12:56:28 2242

t=17179869176: Wed May 30 01:52:56 2514

t=34359738352: Tue Oct 26 03:45:52 3058

t=68719476704: Sun Aug 20 07:31:44 4147

t=137438953408: Wed Apr  8 15:03:28 6325

t=274877906816: (null)
t=549755813632: (null)
t=1099511627264: (null)
t=2199023254528: (null)
t=4398046509056: (null)
t=8796093018112: (null)
t=17592186036224: (null)
t=35184372072448: (null)
t=70368744144896: (null)
t=140737488289792: (null)
t=281474976579584: (null)
t=562949953159168: (null)
t=1125899906318336: (null)
t=2251799812636672: (null)
t=4503599625273344: (null)
t=9007199250546688: (null)
t=18014398501093376: (null)
t=36028797002186752: (null)
t=72057594004373504: (null)
t=144115188008747008: (null)
t=288230376017494016: (null)
t=576460752034988032: (null)
t=1152921504069976064: (null)
t=2305843008139952128: (null)
t=4611686016279904256: (null)
t=9223372032559808512: (null)


However on a Mac, one gets quite a bit further with the doubling, with the last 
success in my sequence of tests at

t=36028797002186752: Tue Dec  1 02:05:52 1141709096


Here's the program, which I wrote mostly for giggles (the fate of the universe, 
let alone humans in a mere billion years to say nothing of nearly three hundred 
billion (INT64_MAX time_t), is very speculative at best).  It is of course not 
portable, since time_t doesn't have to even be an int, let alone 32 or 64 bit 
twos-compliment, although most are.

#include 
#include 
#include 
#include 

int
main(int argc, char **argv)
{

time_t t;

char *ct;

putenv("TZ=UTC0");

t = INT32_MAX;
printf("time overflow after %s in 32-bit signed two's complement\n",
ctime());

t = INT64_MAX;
if ((ct = ctime()) != NULL)
printf("time overflow after %s in 64-bit signed two's 
complement\n",ct);
else
printf("timestamp %lld (INT64_MAX) cannot be processed by 
ctime()\n", INT64_MAX);

for (t=INT32_MAX;t<=INT64_MAX && t>=0L;t<<=1)
printf("t=%ld: %s\n", t, ctime());

return 0;
}



signature.asc
Description: Message signed with OpenPGP
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/31/17 09:43 AM, Richard L. Hamilton wrote:

The alternative would be a large times analog of large file support; why that 
wasn't done when 64-bit began, I don't understand. :-)


It was considered at Sun in the late 90's but discarded as going full LP64
already provided a solution without combinatorial explosion of test matrices
for large files x large times.  The large files API was created before LP64
was an option on most Unixes, including Solaris.

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Richard L. Hamilton]

> On May 31, 2017, at 12:32, Alan Coopersmith  
> wrote:
> 
> On 05/31/17 09:19 AM, Richard L. Hamilton wrote:
>> Aside from executables that reference timestamps (given that a signed 
>> twos-complement will overflow after Tue Jan 19 03:14:07 2038 GMT), and for 
>> programs that will never need to manipulate files larger than 2GiB-1 (unless 
>>  they use large file support), is it necessarily desirable to upgrade 
>> user-space binaries at all?  On x86, ok you get more registers and such; but 
>> on SPARC, I've heard you may be better off with V8 (or V8+), given smaller 
>> binaries, better use of cache, etc.
> 
> Remember that any program that calls stat() on a file references timestamps
> and can get stat() failures with an out-of range timestamp.
> 
> Also as noted in the blogs various newer features either work better with 
> 64-bit
> pointers (like ASLR) or can only work with 64-bit pointers (like ADI on 
> SPARC).
> 
>> Ok, thinking about it, now that static libc is gone, with the time issues, a 
>> 32-bit libc would be an invitation to forget that it wouldn't work with 
>> something that used timestamps, not to mention whatever complications follow 
>> from maintaining support for 32-bit executables.
> 
> All very true too - at some point there's going to be little benefit in
> maintaining a second copy of every single shared library for all those
> 32-bit programs, plus all the translation layers in the kernel for 32-bit
> syscalls.   That point is probably years in the future, but certainly
> less than 20 years from now.

The alternative would be a large times analog of large file support; why that 
wasn't done when 64-bit began, I don't understand. :-)




signature.asc
Description: Message signed with OpenPGP
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/31/17 09:19 AM, Richard L. Hamilton wrote:

Aside from executables that reference timestamps (given that a signed 
twos-complement will overflow after Tue Jan 19 03:14:07 2038 GMT), and for 
programs that will never need to manipulate files larger than 2GiB-1 (unless  
they use large file support), is it necessarily desirable to upgrade user-space 
binaries at all?  On x86, ok you get more registers and such; but on SPARC, 
I've heard you may be better off with V8 (or V8+), given smaller binaries, 
better use of cache, etc.


Remember that any program that calls stat() on a file references timestamps
and can get stat() failures with an out-of range timestamp.

Also as noted in the blogs various newer features either work better with 64-bit
pointers (like ASLR) or can only work with 64-bit pointers (like ADI on SPARC).


Ok, thinking about it, now that static libc is gone, with the time issues, a 
32-bit libc would be an invitation to forget that it wouldn't work with 
something that used timestamps, not to mention whatever complications follow 
from maintaining support for 32-bit executables.


All very true too - at some point there's going to be little benefit in
maintaining a second copy of every single shared library for all those
32-bit programs, plus all the translation layers in the kernel for 32-bit
syscalls.   That point is probably years in the future, but certainly
less than 20 years from now.

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Richard L. Hamilton]

> On May 26, 2017, at 12:01, Alan Coopersmith  
> wrote:
> 
> On 05/26/17 04:26 AM, Harry Putnam wrote:
>> Jonathan Adams  writes:
>> 
>>> Much better than the Linux "file 'which file'" (with back ticks) ...
>>> 
>> 
>> sudo  file `which file`
>> /usr/bin/file:  ELF 32-bit LSB executable 80386 Version 1, dynamically
>> linked, not stripped, no debugging information available
>> 
>> Er... looks like one of the techniques has got it wrong
>> 
>> Or does something else explain this?
> 
> That works on Linux distros which have separate 32-bit & 64-bit versions
> and compile every binary in the OS to match.
> 
> That doesn't work on Solaris-derived distros which have a unified 32/64 bit
> version that supports binaries of either flavor, and which many programs are
> 32-bit so they can run on either 32-bit or 64-bit kernels.
> 
> As distros drop 32-bit kernel support, they'll likely convert more and more
> of their programs to 64-bit, but it can be a gradual process, not a flag day.
> 
> For the one I work on (not OI, but "Big Red"), we've been making this 
> conversion
> across 5+ years now, and are >90% done in our development trunk, though much
> less done in what's been released so far.  I've written far more about the
> topic for the terminally curious at:
> 
> https://blogs.oracle.com/alanc/moving-oracle-solaris-to-lp64-bit-by-bit
> https://blogs.oracle.com/observatory/oracle-solaris-113-progress-on-lp64-conversion
> 
>   -alan-

Aside from executables that reference timestamps (given that a signed 
twos-complement will overflow after Tue Jan 19 03:14:07 2038 GMT), and for 
programs that will never need to manipulate files larger than 2GiB-1 (unless  
they use large file support), is it necessarily desirable to upgrade user-space 
binaries at all?  On x86, ok you get more registers and such; but on SPARC, 
I've heard you may be better off with V8 (or V8+), given smaller binaries, 
better use of cache, etc.

Ok, thinking about it, now that static libc is gone, with the time issues, a 
32-bit libc would be an invitation to forget that it wouldn't work with 
something that used timestamps, not to mention whatever complications follow 
from maintaining support for 32-bit executables.



signature.asc
Description: Message signed with OpenPGP
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Harry Putnam]

Alan Coopersmith  writes:

> On 05/26/17 11:34 AM, Harry Putnam wrote:
>> Alan Coopersmith  writes:
>>
>>> For the one I work on (not OI, but "Big Red"), we've been making
>>> this conversion across 5+ years now, and are >90% done in our
>>> development trunk, though much less done in what's been released so
>>> far.  I've written far more about the topic for the terminally
>>> curious at:
>>
>> I guess it might be inappropriate here... but I'm not finding anything
>> with google on the terms Alan Coopersmith and Big Red.
>>
>> Is this slang or an insider name for an OS ... or what?
>
> It's a slang term referring to the color of my employer's logo/branding,
> much as IBM has long been "Big Blue"...
>
> https://www.google.com/#q=Big+Red+Oracle

OK, Got it, thanks for taking the time to reply ; and sorry about the
ill-informed questions.



___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/26/17 11:34 AM, Harry Putnam wrote:

Alan Coopersmith  writes:


For the one I work on (not OI, but "Big Red"), we've been making
this conversion across 5+ years now, and are >90% done in our
development trunk, though much less done in what's been released so
far.  I've written far more about the topic for the terminally
curious at:


I guess it might be inappropriate here... but I'm not finding anything
with google on the terms Alan Coopersmith and Big Red.

Is this slang or an insider name for an OS ... or what?


It's a slang term referring to the color of my employer's logo/branding,
much as IBM has long been "Big Blue"...

https://www.google.com/#q=Big+Red+Oracle

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Harry Putnam]

Alan Coopersmith  writes:

> For the one I work on (not OI, but "Big Red"), we've been making
> this conversion across 5+ years now, and are >90% done in our
> development trunk, though much less done in what's been released so
> far.  I've written far more about the topic for the terminally
> curious at:

I guess it might be inappropriate here... but I'm not finding anything
with google on the terms Alan Coopersmith and Big Red.

Is this slang or an insider name for an OS ... or what?


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Jonathan Adams]

>
>
> Jonathan Adams  writes:
>
> > Much better than the Linux "file 'which file'" (with back ticks) ...
> >
>
>
> sudo  file `which file`
> /usr/bin/file:  ELF 32-bit LSB executable 80386 Version 1, dynamically
> linked, not stripped, no debugging information available
>
> Er... looks like one of the techniques has got it wrong
>
> Or does something else explain this?
>
> On Illumos the "file" command is 32bit (as the kernel can run both 32 and
64 bit happily together), on Linux the above command is a sensible way of
working out what bit kernel you're running as it's more of a PITA to run
32bit and 64 bit side by side (or so I believe) ...

On Linux:

jadams@EID-4546:~$ file `which file`
/usr/bin/file: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux
2.6.32, BuildID[sha1]=ecc4d67cf433d0682a5b7f3a08befc45e7d18057, stripped
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/26/17 04:26 AM, Harry Putnam wrote:

Jonathan Adams  writes:


Much better than the Linux "file 'which file'" (with back ticks) ...



sudo  file `which file`
/usr/bin/file:  ELF 32-bit LSB executable 80386 Version 1, dynamically
linked, not stripped, no debugging information available

Er... looks like one of the techniques has got it wrong

Or does something else explain this?


That works on Linux distros which have separate 32-bit & 64-bit versions
and compile every binary in the OS to match.

That doesn't work on Solaris-derived distros which have a unified 32/64 bit
version that supports binaries of either flavor, and which many programs are
32-bit so they can run on either 32-bit or 64-bit kernels.

As distros drop 32-bit kernel support, they'll likely convert more and more
of their programs to 64-bit, but it can be a gradual process, not a flag day.

For the one I work on (not OI, but "Big Red"), we've been making this conversion
across 5+ years now, and are >90% done in our development trunk, though much
less done in what's been released so far.  I've written far more about the
topic for the terminally curious at:

https://blogs.oracle.com/alanc/moving-oracle-solaris-to-lp64-bit-by-bit
https://blogs.oracle.com/observatory/oracle-solaris-113-progress-on-lp64-conversion

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Predrag Zečević - Technical Support Analyst]

On 05/25/17 23:10, Harry Putnam wrote:

How can quickly tell what bit my Hipster 2017.04 is?


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss



I remember this from early days of 64 bit solaris:

$ optisa $(isainfo)
amd64

HTH
With best regards.
Predrag Zečević
--
Predrag Zečević
Technical Support Analyst
2e Systems GmbH

Telephone: +49 6196 9505 815, Facsimile: +49 6196 9505 894
Mobile:+49  174 3109 288, Skype: predrag.zecevic
E-mail:predrag.zece...@2e-systems.com

Headquarter:  2e Systems GmbH, Königsteiner Str. 87,
  65812 Bad Soden am Taunus, Germany
Company registration: Amtsgericht Königstein (Germany), HRB 7303
Managing director:Phil Douglas

http://www.2e-systems.com/ - Making your business fly!

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Nikola M]

On 05/25/17 11:18 PM, Alan Coopersmith wrote:
> On 05/25/17 02:13 PM, Will Brokenbourgh wrote:
>> On 05/25/17 14:10, Harry Putnam wrote:
>>> How can quickly tell what bit my Hipster 2017.04 is?
>>
>> Have you tried:
>>
>> uname -a
>
> The Solaris/openSolaris/illumos kernel doesn't change any of the values
> in uname between 32 & 64-bit kernels, much to the confusion of users of
> kernels which do.
>
> -alan-

Thanks Alan.

And that's because both 32-bit and 64-bit binaries works on the same
kernel at the same time.
That's why isainfo  gives both architectures:
$ isainfo
amd64 i386

$ isainfo -v
64-bit amd64 applications
ssse3 cx16 sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu
32-bit i386 applications
ssse3 ahf cx16 sse3 sse2 sse fxsr mmx cmov sep cx8 tsc fpu
(This is old E5200 without VT instructions)

And because of that, installation media was always able to install on
both 32-bit and 64-bit hardware, whereas today one should use 64-bit
hardware only it you want to be supported, but 32-bit and 64-bit
binaries continue to work.
Solaris kernel supported 64-bit since 1997, so it's about time :)

Interestingly, on amd64 x86, 64--bit apps are supposedly bit faster, but
also use more RAM.
but on SPARC, 32-bit apps are faster then 64bit (less bits to move).


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Harry Putnam]

Alan Coopersmith  writes:

> On 05/25/17 02:10 PM, Harry Putnam wrote:
>> How can quickly tell what bit my Hipster 2017.04 is?
>
> "isainfo -kv" will tell you which kernel is running.
>
And so it does... thanks:

sudo isainfo -kv
64-bit amd64 kernel modules

---   ---   ---=---   ---   --- 

jason matthews  writes:

> On 5/25/17 2:17 PM, Alan Coopersmith wrote:
>> "isainfo -kv" will tell you which kernel is running. 
>
> winner winner chicken dinner.
>
> isainfo is the most elegant way i know of.

I liked that show too.  That saying has stuck in my head ever since I
saw it... but cannot remember the name now, or the young actors name.

---   ---   ---=---   ---   ---

Jonathan Adams  writes:

> Much better than the Linux "file 'which file'" (with back ticks) ...
>


sudo  file `which file`
/usr/bin/file:  ELF 32-bit LSB executable 80386 Version 1, dynamically
linked, not stripped, no debugging information available

Er... looks like one of the techniques has got it wrong

Or does something else explain this?


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Jonathan Adams]

Much better than the Linux "file 'which file'" (with back ticks) ...


On 25 May 2017 22:21, "jason matthews"  wrote:

>
>
> On 5/25/17 2:17 PM, Alan Coopersmith wrote:
>
>> "isainfo -kv" will tell you which kernel is running.
>>
>
> winner winner chicken dinner.
>
> isainfo is the most elegant way i know of.
>
> j.
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[jason matthews]

On 5/25/17 2:17 PM, Alan Coopersmith wrote:
"isainfo -kv" will tell you which kernel is running. 


winner winner chicken dinner.

isainfo is the most elegant way i know of.

j.

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/25/17 02:13 PM, Will Brokenbourgh wrote:

On 05/25/17 14:10, Harry Putnam wrote:

How can quickly tell what bit my Hipster 2017.04 is?


Have you tried:

uname -a


The Solaris/openSolaris/illumos kernel doesn't change any of the values
in uname between 32 & 64-bit kernels, much to the confusion of users of
kernels which do.

-alan-


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Alan Coopersmith]

On 05/25/17 02:10 PM, Harry Putnam wrote:

How can quickly tell what bit my Hipster 2017.04 is?


"isainfo -kv" will tell you which kernel is running.

-alan-

___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to tell for sure what bit your OS is?

[Will Brokenbourgh]

On 05/25/17 14:10, Harry Putnam wrote:

How can quickly tell what bit my Hipster 2017.04 is?


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Have you tried:

uname -a

?

Sincerely,

Will Brokenbourgh
Oregon, USA

Sent from my OpenBSD desktop


___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss