Re: Year 2000 & Debian
"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 (kahn@zk3.dec.com) 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
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: