Data Archival (OT Long)

From: Jerome Fine <jhfine_at_idirect.com>
Date: Sat Dec 9 08:41:55 2000

>Don Maslin wrote:

> On Fri, 8 Dec 2000, Sellam Ismail wrote:
> > On Fri, 8 Dec 2000, Jerome Fine wrote:
> > > Many people have told me that I am crazy to even consider this
> > > possibility, let alone do the work, but why save data for 10,000 years?
> > > Does anyone have any advice as to how to handle the problem that
> > > the calendar can't be predicted exactly so far into the future?
> > I don't know...will it matter? Are you intending that people will still
> > be using these operating systems 8,000 years from now or are you only
> > concerned about the data itself?
> > Still, it wouldn't hurt to add another digit in the year field. Of
> > course, by that time you'll be dead, so what do you care? Let some future
> > genius figure it out :)
> But, of course, that is how we got into the Y2K problem originally.

Jerome Fine replies:

And that will continue to happen so long as the most important aspect
is short term revenue considerations. I understand that 2038 (or around
that date) is when 32 bit C subroutines will have a problem. Hopefully
by then, most code will be 64 bit and the problem will no longer exist.

The operating system that I am interested in did not get the Y2K patches
and the current version still costs $ US 1600 for the distribution media
and document set. And if the user does not have a license for the last
revision from 1992, a license is also specified for another $ US 900.

Since the old version from 1985 is a hobby version and free to use
under certain restricted conditions, I want to make a Y2K version
available for hobby users and it will not be that much more effort
to bring it to a Y10K level. The only real question is the calendar
which will likely have a leap year or two omitted in the next 8000 years.
But which one is still in question.

Sincerely yours,

Jerome Fine
Received on Sat Dec 09 2000 - 08:41:55 GMT