Messages in this thread | | | Date | Fri, 7 Jan 2000 10:55:36 -0500 (EST) | From | Mike Porter <> | Subject | Re: 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/
| |