64-bit time_t?
John Tobey
Which, if any, combinations of Sun hardware and anybody's OS produces
a system that is Year-2038-safe? (64-bit time_t in kernel and libc)
I am looking for a personal server to be colocated somewhere I hope
never to have to visit. I want it to run at least for the rest of my
life, and I intend to live past the 31-bit Unix time rollover in
2038. I hope to buy such a system within the next few weeks. My
preference is for a pizza-box server.
Y2K docs on Sun's (and MSFT's) sites talk about "works until 2038" as
if that were somehow reassuring. :-)
TIA
-John
--
John Tobey, late nite hacker <jto...@john-edwin-tobey.org>
\\\ ///
]]] With enough bugs, all eyes are shallow. [[[
/// \\\
Mason Ip
>Which, if any, combinations of Sun hardware and anybody's OS produces
>a system that is Year-2038-safe? (64-bit time_t in kernel and libc)
Solaris 7 and 8 are 64-bit capable already.
% uname -a
SunOS sunbox 5.8 Generic sun4u sparc SUNW,Ultra-5_10
And the following showed time_t is 64-bit!
% cat xx.c
#include <sys/times.h>
#include <stdio.h>
int main ( int argc, char **argv )
{
printf("size of time_t = %d bits\n",8 * sizeof(time_t));
}
% file xx
xx: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
linked, not stripped
% xx
size of time_t = 64 bits
Mason Ip
>I am looking for a personal server to be colocated somewhere I hope
>never to have to visit. I want it to run at least for the rest of my
>life, and I intend to live past the 31-bit Unix time rollover in
>2038.
You want to run a single OS for at least 37 years? You must be kidding!
With high competitions, OS vendors (like Sun, HP, IBM, etc) tend
to release new versions of OS'es every one or two years.
So, by 2038, Solaris probably will come to version 30+.
>Y2K docs on Sun's (and MSFT's) sites talk about "works until 2038" as
>if that were somehow reassuring. :-)
Y2K docs are now obsolete.
Maybe by 2038, there will be microprocessors implanted to humman brains.
Who knows?
Arthur Darren Dunham
John Tobey <jto...@john-edwin-tobey.org> wrote:
>Please help,
>
>Which, if any, combinations of Sun hardware and anybody's OS produces
>a system that is Year-2038-safe? (64-bit time_t in kernel and libc)
>
>never to have to visit. I want it to run at least for the rest of my
>life, and I intend to live past the 31-bit Unix time rollover in
>preference is for a pizza-box server.
So what happens when the hard drive fails in 4 years and the colo
facility goes under in 6?
Or, what happens when the colo tells you "We no longer provide Ethernet
connectivity for clients" in 21 years?
Let's see. PDP stuff is only 35 years old..... :-)
--
Darren Dunham ddu...@taos.com
Unix System Administrator Taos - The SysAdmin Company
Got some Dr Pepper? San Francisco Bay Area
< Please move on, ...nothing to see here, please disperse >
John Tobey
> Solaris 7 and 8 are 64-bit capable already.
>
> % uname -a
> SunOS sunbox 5.8 Generic sun4u sparc SUNW,Ultra-5_10
>
> And the following showed time_t is 64-bit!
>
> % cat xx.c
> #include <sys/times.h>
> #include <stdio.h>
> int main ( int argc, char **argv )
> {
> printf("size of time_t = %d bits\n",8 * sizeof(time_t));
> }
>
> % file xx
> xx: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
> linked, not stripped
>
> % xx
> size of time_t = 64 bits
I should have mentioned system binaries along with kernel and libc.
$ uname -a
SunOS euler 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
$ file /bin/sh
/bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically linked,
stripped
I'd feel a little uneasy with a 32-bit /bin/sh on the fateful day,
wouldn't you?
> You want to run a single OS for at least 37 years? You must be kidding!
No, just leery of the upgrade cycle. All I use my server for is
email, CGI, and stuff like that. My needs may change over 37 years,
especially if new and interesting technology requires newer systems.
But I don't *know* that they will, and the last thing I want is to
forget about the bug until it bites me.
> Maybe by 2038, there will be microprocessors implanted to humman brains.
> Who knows?
Or maybe not. If it's a simple choice between 2038-safe and unsafe
today, I'll go for the safe system on principle and to have one less
thing to worry about for the next 37 years. 37 years is a long time
to run a computer, but it's also a long time to live with a burdened
conscience.
Alas, it seems that there is no safe option from Sun today. Linux is
no better, judging by Alax Cox's cavalier attitude on the topic.
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0001.0/0371.html
I wonder if DEC makes low-end servers...
Thanks
Alan Coopersmith
|Which, if any, combinations of Sun hardware and anybody's OS produces
|a system that is Year-2038-safe? (64-bit time_t in kernel and libc)
A 64-bit system (Ultra running Solaris 7 or 8 in 64-bit mode) should be
mostly year-2038 safe, but I don't think anybody has performed
exhaustive tests, and there are almost certainly some bugs.
|I am looking for a personal server to be colocated somewhere I hope
|never to have to visit. I want it to run at least for the rest of my
|life, and I intend to live past the 31-bit Unix time rollover in
|2038. I hope to buy such a system within the next few weeks. My
|preference is for a pizza-box server.
You should probably go with Solaris 8 then, so you don't have to
reinstall in 10-20 years when IPv4 is finally dead and the world is
IPv6-only. (Assuming we're not migrating to IPv10 by then, and that
someone will still be making gigabit-ethernet compatible network routers
for legacy devices.)
Of course, given your requirments, I'd probably just go with a hosting
company that provides the server hardware, software, and system
maintenance for you -- that way you're not stuck with obsolete hardware
for thirty years by the time 2038 gets here, if it lasts that long.
--
________________________________________________________________________
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.
Mason Ip
>I should have mentioned system binaries along with kernel and libc.
>
>$ uname -a
>SunOS euler 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
>$ file /bin/sh
>/bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically linked,
> stripped
You have the same type of hardware as mine.
My system also have a 32-bit /bin/sh.
Note that Solaris 8, when installed as 64-bit kernel, has 32-bit as well as
64-bit files.
Are yours running 64-bit kernel?
% isainfo -b
64
Even if not, you can have a choice to boot to either 32-bit or 64-bit.
Check with Casper's Solaris FAQ for detail.
Mason Ip
>
>mas...@attachmate.co_ (Mason Ip) writes:
>
>> Solaris 7 and 8 are 64-bit capable already.
>>
>> % uname -a
>> SunOS sunbox 5.8 Generic sun4u sparc SUNW,Ultra-5_10
>>
>> And the following showed time_t is 64-bit!
>>
>> % cat xx.c
>> #include <sys/times.h>
>> #include <stdio.h>
>> int main ( int argc, char **argv )
>> {
>> printf("size of time_t = %d bits\n",8 * sizeof(time_t));
>> }
>>
>> % file xx
>> xx: ELF 64-bit MSB executable SPARCV9 Version 1, dynamically
>> linked, not stripped
>>
>> % xx
>> size of time_t = 64 bits
>
>I should have mentioned system binaries along with kernel and libc.
>
>$ uname -a
>SunOS euler 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
>$ file /bin/sh
>/bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically linked,
> stripped
You have the same type of hardware as mine. So your harware and software
are capable of running 64-bit Solaris 7.
BTW, my 64-bit Solaris 8 system also have a 32-bit /bin/sh.
Note that Solaris 7 & 8, when installed as 64-bit kernel, has both 32-bit
Mason Ip
>I should have mentioned system binaries along with kernel and libc.
>
>$ uname -a
>SunOS euler 5.7 Generic_106541-02 sun4u sparc SUNW,Ultra-5_10
>$ file /bin/sh
>/bin/sh: ELF 32-bit MSB executable SPARC Version 1, dynamically linked,
> stripped
>
>I'd feel a little uneasy with a 32-bit /bin/sh on the fateful day,
>wouldn't you?
You have the same type of hardware as mine. So your harware and software
are capable of running 64-bit Solaris 7.
BTW, my 64-bit Solaris 8 system also have a 32-bit /bin/sh.
Note that Solaris 7 & 8, when installed as 64-bit kernel, has both 32-bit
as well as 64-bit files. When installed as 32-bit kernal, has only 32-bit
files.
Are yours running 64-bit kernel?
% isainfo -b
64
Even if not, you can install as 64-bit and have a choice to boot
Casper H.S. Dik - Network Security Engineer
John Tobey <jto...@john-edwin-tobey.org> writes:
>Which, if any, combinations of Sun hardware and anybody's OS produces
>a system that is Year-2038-safe? (64-bit time_t in kernel and libc)
None. As long as we ship most executables in 32-bit only form,
the OS is not Jan 2038 proof.
You can build your executables to be 2038 proof, though.
(It is not unlikely your current software will run then;
it's very unlikely you will run our current hardware with
our current OS)
>I am looking for a personal server to be colocated somewhere I hope
>never to have to visit. I want it to run at least for the rest of my
>life, and I intend to live past the 31-bit Unix time rollover in
>2038. I hope to buy such a system within the next few weeks. My
>preference is for a pizza-box server.
This assumes rather a lot:
- the hardware will work for 38+ years (very unlikely)
- you swap the hardware and hope the OS will work on the new
hardware (at least as unlikely)
What is most important is that you can now develop and run software
that will survive 2038.
You will need to replace hardware and upgrade the OS several times
between now and 2038; one of those upgrades will be to a all 64 bit OS.
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.
Casper H.S. Dik - Network Security Engineer
John Tobey <jto...@john-edwin-tobey.org> writes:
>I'd feel a little uneasy with a 32-bit /bin/sh on the fateful day,
>wouldn't you?
/bin/date; yes; /bin/sh. Perhaps not to uneasy.
>I wonder if DEC makes low-end servers...
Since digital uses 32 bit timestamps internally even in 64 bit code,
your chances at digital are even lower.
Uhm, Compaq, of course.
Or perhaps they fixed this now?
Drazen Kacar
> Since digital uses 32 bit timestamps internally even in 64 bit code,
> your chances at digital are even lower.
>
> Uhm, Compaq, of course.
>
> Or perhaps they fixed this now?
Sorta, kinda. You can #define something and it will give you 64-bit
time_t on Tru64, but it's still 32-bit by default. The details are in
the release notes, if anyone is interested.
--
.-. .-. I don't work for my employer.
(_ \ / _)
| da...@srce.hr
| da...@fly.srk.fer.hr
Casper H.S. Dik - Network Security Engineer
da...@srce.hr (Drazen Kacar) writes:
>Sorta, kinda. You can #define something and it will give you 64-bit
>time_t on Tru64, but it's still 32-bit by default. The details are in
>the release notes, if anyone is interested.
But hopefully the kernel now ticks in 64 bit time?
Drazen Kacar
>
> >Sorta, kinda. You can #define something and it will give you 64-bit
> >time_t on Tru64, but it's still 32-bit by default. The details are in
> >the release notes, if anyone is interested.
>
> But hopefully the kernel now ticks in 64 bit time?
I don't know; I don't have it installed anywhere yet. With #define _TIME64_T
you get time64_t, time64() and friends and some macros for conversion.
I don't know if it's only library and headers magic or it's in the kernel.
The information should be somewhere in time(3) or gettimeofday(2) man
pages, but I can't access them yet.