lkml.org 
[lkml]   [2000]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: time_t size: The year 2038 bug?
On Fri, 7 Jan 2000, Alan Cox wrote:

> > and see how many of their microprosessors can be outrun by an 8086.
> > If were still using mid 70s technology what makes you think we will all be
> > using the latest in 30 years ?
>
> If there are actually any humans left in 30 years it will be a suprise, probably a nasty
> one.

Are you getting a little discouraged with the world? Actually,
considering how Y2K went, I'm impressed with the world. I don't
mean the technological aspects of Y2K. I really thought people
would panic and would we see bank runs and the like. Maybe a few
market crashes.

> Changing time_t on existing systems is a huge task that isnt going to happen until it needs
> too. For desktop machines the world will have moved on. Embedded boxes might need a
> recompile. Fortunately with open source your vendor can't screw you by going bust or
> charging you $1m for any updates

But you need to have staff, testing facilities, etc in order to do
this. A good deal of the software that we run on our mainframe is
kinda open source. Well, we at least have the source code to it.
It was still a major undertaking to test it for Y2K compliance.
Finding staff that understood the systems was a big problem. All
the new people program in C, write web pages and applets. There
aren't that many people in the building that know how to compile a
Cobol program on a mainframe left in this building. The same
situation will occur in 2038 (we'll be the old guys, then, by the
way).

Vendors didn't try to screw us with huge update costs. But, their
new releases use newer compilers or OSes, which means upgrades here
and there, and sometimes problems with incompatabilities.

Suppose you find in 2037 that you have had an old program that
works fine. It runs on some old 64 bit machine that hasn't been
made in 15 years, but it does the job. The system was never used
for developement, so it doesn't have the source code for the
operating system on it. Of course, since it runs an open source
operating system, it should be possible to find the source. And
eventually, you find it (5 hours work, 3 of which were spent
guessing the root password of the machine so you could even figure
out what OS/software is running there). The old operating system
isn't Y2038 compliant, time() still returns a long. You can't run
a new operating system because new open source operating systems
don't run on old 64 bit machines.

So, now you need someone that understands this old stuff. You're
21 years old and don't know what Unix is, or what all the crazy
flags to gcc and make do, etc. You can't touch this stuff and
assume it will work. The source code is of course 'Y2038'
compliant. A simple recompile will fix it because the programmer
understood that someday the format of time_t will change. Heck,
even the files it reads and writes are not dependant on the format
of time_t (they couldn't be dependant because this old machine has
been sending data to newer machines for years). This programmer
must have been a visionary. So, you hire some old guy for $120 an
hour, and he agrees to do it all for a grand total of $7,000 (year
2000 dollars) or so.

And then you have a meeting with the person you hired and the rest
of the staff. Someone pipes up: "Ooops...you mean someone still
uses that program? I deleted the source two years ago when I was
cleaning up the CVS repository." The "old guy" has a decompiler,
but he's gonna charge you about 5 times more, so now you've spent
about 20 hours and it's going to cost you $35,000 to get this thing
working. Maybe we should just replace it? Would that be cheaper?
Hmmm...6 man months (understanding the user's needs, designing,
coding, testing, deployment) or fixing the old code? Cost is about
the same...

You might think the above scenarios are stupid. They are, however,
exactly what we and many other mainframe sites found during the Y2K
testing (we didn't lose any source, but lots of other sites did).

Oh, and this ignores the high cost of testing software. Lots of
our software had no problems, but it needed to be tested so we
would know that. If there was no problem Y2K, or the problem had
been fixed 20 years ago, there would have been no reason to test,
and hence no expenses incurred for testing.

Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.114 / U:1.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site