Re: Year 2000 Debian
Andy Dougherty wrote: Groff-1.10 had a couple of problems in some of the macro packages. [...] (This may all be corrected in 1.3.1 -- I don't have access to a 1.3.1 system now to check. I know it's been reported to the groff maintainer, but I haven't checked whether the groff-1.11 fixes the problem or not.) Not. groff-1.11a is a orphaned release with only a new documentation manual for pic. The author removed his name from some files and stated it as orphaned (on 11 August 1997). If you have any fix for those oddities, please put them in a bug report and send it to [EMAIL PROTECTED] . Fabrizio -- | [EMAIL PROTECTED][EMAIL PROTECTED][EMAIL PROTECTED] | Pluto Leader - Debian Developer Happy Debian 1.3.1 User - vi-holic | 6F7267F5 fingerprint 57 16 C4 ED C9 86 40 7B 1A 69 A1 66 EC FB D2 5E -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
On Wed, 22 Oct 1997, Bruce Perens 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. That's what they said when they wrote the PC BIOS nearly twenty years ago! :-) Rich. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Year 2000 Debian
Not sure if this has been thrashed out before: Is Debian (or Linux in general) year 2000 *safe*? I'm not even sure what that means precisely, but I'm responsible for finding out round here and wondered if it's been discussed on this group. 8---8 Richard Shepherd ([EMAIL PROTECTED]) Phone: 07-838-4764 8---8 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
I ran my system with the date in the year 2000 for a few weeks. I could not find any problems. Unix was never so dumb as to store the century as two digits. Richard Stallman and FSF have been testing this, too. The biggest problem that may happen has to do with the motherboard BIOS and the PC clock chip on some systems storing the century as two digits. The Linux program that reads the hardware clock into the software clock can make up for that. An update of this program was just released and will be well-deployed before it is needed. Thanks Bruce -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html Bruce Perens K6BP [EMAIL PROTECTED] NEW PHONE NUMBER: 510-620-3502 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
On Tue, Oct 21, 1997 at 08:15:00PM -0700, Bruce Perens wrote: I ran my system with the date in the year 2000 for a few weeks. I could not find any problems. Unix was never so dumb as to store the century as two digits. Richard Stallman and FSF have been testing this, too. The biggest problem that may happen has to do with the motherboard BIOS and the PC clock chip on some systems storing the century as two digits. The Linux program that reads the hardware clock into the software clock can make up for that. An update of this program was just released and will be well-deployed before it is needed. One local trade newspaper or magazine recently ran a story on the Unix 2038 problem. Really getting in early here folks ... Hamish -- Hamish Moffatt, StudIEAust [EMAIL PROTECTED], [EMAIL PROTECTED] Student, computer science computer systems engineering.3rd year, RMIT. http://hamish.home.ml.org/ (PGP key here) CPOM: [* ] 56% The opposite of a profound truth may well be another profound truth. --Bohr -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Year 2038 problem (was Re: Year 2000 Debian)
On Wed, 22 Oct 1997 19:51:07 +1000 Hamish Moffatt [EMAIL PROTECTED] wrote: On Tue, Oct 21, 1997 at 08:15:00PM -0700, Bruce Perens wrote: I ran my system with the date in the year 2000 for a few weeks. I could not find any problems. Unix was never so dumb as to store the century as two digits. Richard Stallman and FSF have been testing this, too. The biggest problem that may happen has to do with the motherboard BIOS and the PC clock chip on some systems storing the century as two digits. The Linux program that reads the hardware clock into the software clock can make up for that. An update of this program was just released and will be well-deployed before it is needed. One local trade newspaper or magazine recently ran a story on the Unix 2038 problem. Really getting in early here folks ... By that time everything will be 64-bit and the problem will disappear. We won't have to worry about it again until (bc calculation pending...) the year 292,271,023,045. I don't think I'll worry too much about that! Gary Hennigan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
There is some dispute over whether it's 2038 or later. In any case, one only need define time_t to be 64 bits and it will last until the heat-death of the universe. Bruce -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html Bruce Perens K6BP [EMAIL PROTECTED] NEW PHONE NUMBER: 510-620-3502 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
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. Thanks Bruce -- Can you get your operating system fixed when you need it? Linux - the supportable operating system. http://www.debian.org/support.html Bruce Perens K6BP [EMAIL PROTECTED] NEW PHONE NUMBER: 510-620-3502 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
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). -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
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 ([EMAIL PROTECTED])Phone: 603-884-2557 (DTN: 264-2557) Digital Equipment CorporationFax : 603-881-2257 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 Debian
On Wed, 22 Oct 1997, Richard L Shepherd wrote: Not sure if this has been thrashed out before: Is Debian (or Linux in general) year 2000 *safe*? I'm not even sure what that means precisely, but I'm responsible for finding out round here and wondered if it's been discussed on this group. Groff-1.10 had a couple of problems in some of the macro packages. For example, grep '19' in the troff macro directory yields the following oddities: tmac.e:.ds td \*(mo \n(dy, 19\n(yr tmac.gm:.el .ds cov*new-date \\*[MO\\n[mo]] \\n[dy], 19\\n[yr] while tmac.gs has the correct tmac.gs:.nr *year \n[yr]+1900 (This may all be corrected in 1.3.1 -- I don't have access to a 1.3.1 system now to check. I know it's been reported to the groff maintainer, but I haven't checked whether the groff-1.11 fixes the problem or not.) Now is this an operating system problem or an application problem? I don't really care, and the end user who gets the wrong answer probably won't care either. Is this particular example a big deal? Certainly not. However, I do hope it successfully illustrates that you shouldn't believe any blanket assertions that Linux is year 2000 safe unless those assertions include assurances that all the relevant library and macro support files have also been checked. Andy Dougherty [EMAIL PROTECTED] Dept. of Physics Lafayette College, Easton PA 18042 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
