"Darin Johnson" wrote: -> -> > Before 100 people jump to correct me, yes, time_t overflows after -> > Tuesday, January 19, 03:14:07 2038. Fixing this requires that time_t by -> > typedefed as a 64-bit quantity and then programs using it must be -> > recompiled. One would hope that the world can find something better -> > than POSIX, C, and Unix by 2038. -> -> Ok, the worst thing about the year 2000 problem, is that so few people -> understand it, yet think they do! People panic about things that -> probably won't break (Linux and utilities), yet ignore things that -> are more likely to break (user applications and data). -> -> 1) There is no quick fix! Yes, for the 2038 problem, you can just -> change time_t. But that only changes those applications that have -> been recompiled. The Y2K problem has almost always been about stuff -> that hasn't been recompiled and needs scrutiny before recompiling. -> The 2038 problem may be simpler in that the scrutiny can be done more -> automatically, but it's still a bigger job than just redefining -> time_t. -> -> 2) The sort of thinking that something else will be in common use -> before the problem comes around is exactly what has caused the problem -> in the first place. 2038 is 40 years in the future, but we have Y2K -> problems now for systems and programs that are 20 or 30 years old. -> People underestimate the longevity of code; the "if it ain't broke, -> don't fix it" philosophy is standard procedure (especially on -> mainframes, which is where Y2K will rear its ugly head, not on unix or -> wintel machines). -> -> 3) Setting a computer's date to 12/31/1999 and running it a few days -> does not test anything useful. The defects that this test will find -> are relatively trivial. For this to be more useful, it needs to be -> the same environment as you use in production (ie, you don't want to -> test the OS and utilities, you want to test your customer billing -> system, your automatic ordering system, your file archival system, -> your interest calculations, etc). Y2K problems are *complex*, they -> are usually not isolated to a few lines of code, and may not manifest -> themselves in a testing situation (ie, you may need to be on a network -> talking to a remote database server before a certain bug rears its -> head, etc). The real fix is to scrutinize all code. -> -> 4) Y2K problems have *already* happened, and we haven't hit 1/1/2000 yet. -> -> 5) I'm really glad no one has said "Y2K compliant" yet. There are a -> lot of poeple that use that term the same way they use "ISO 9000 -> compliant", as if there were a Y2K bugs clearning house, standards -> body, or certification program... -> -> 6) If you want to know if your system is going to have Y2K problems, -> then examine your own data and applications. UNIX in general will -> have few problems, and probably no major problems; however -> applications running on top of UNIX *will* have these problems. Same -> with Windows. Find out what's critical on your system and examine -> those components; if you do customer billing, then research the -> product that you use. If you have transactions (ie, databases) with -> other computers, then examine them as well. If you use commercial -> products, try to get upgrades to them; if you have data for those -> products, upgrade your data as well (it makes no sense to get new -> binaries, then forget that you have dates stored as character fields). -> -> 7) Finally - make backups, keep written records of all transactions, -> train your employees how to cope if the systems go down, and so forth. -> Ie, prepare for the worst. (I can't believe how inept some companies -> are; I was at a computer store whose point of sale system went down, -> and it took them ages to figure out what to do manually, and resulted -> in 4 people staffing each register). -> ->
blah blah blah blah... y2k this, y2k that. all that stuff just described above talks about the y2k problem according to the *applications* used. the >> original question << was whether or not the operating system (in this case, Debian Linux) has a problem with it. the OS doesn't. fixing applications is another story. --andy -- Andy Kahn ([EMAIL PROTECTED]) Phone: 603-884-2557 (DTN: 264-2557) Digital Equipment Corporation Fax : 603-881-2257 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .