PROMO MiNOLTA YEAR 2000 (cupos limitados)
BUENOS AIRES, 6 de marzo del 2000. SR.DIRECTOR: La división fotocopiadoras MINOLTA CO LTD, quiere hoy hacerle llegar a Usted, nuestro nuevo plan uno, dos y para siempre, el mismo consiste en un método agresivo que ha implementado nuestra dirección para ofrecerle a todos las empresas, estudios, consultoras, universidades y escuelas de la Ciudad de Buenos Aires y Gran Buenos Aires. El plan es muy sencillo, con solo desearlo usted y su empresa pueden contar con uno o varios equipos de prueba durante 30 días para que pueda experimentar por sus propios medios el comportamiento de una maquina MINOLTA, como así también como funciona nuestro servicio técnico. MINOLTA CO LTD. Le entrega una maquina a Usted sin cargo fijo durante 60 días* y solo a costo por copia, $0,029 *con todos los consumibles sin cargo(excepto papel), con servicio técnico full free, para que Usted la instale en su empresa. Creemos que sabrá interpretar esta oportunidad de probar nuestros productos, sin ningún tipo de inversión previa, algo que en los tiempos que corren es difícil de encontrar, es por esto, que esperamos se comunique con nosotros a: 4326-5883/4393-2612/4322-3735 o vía email [EMAIL PROTECTED] , en la red www.go.to/sumpex aprovecho la oportunidad para saludarle a Usted muy atte. (*)renovación automática por un periodo de doce meses con el cargo fijo de copias por Usted realizado mensualmente. (*)no incluye IVA. (*)plan promocional solo para las primeras cien empresas que adopten la promoción.- (solo valido Capital y gran Bs. As) Este mensaje se envía con la complacencia de la nueva legislación sobre correo electrónico: Por sección 301, parrafo (a)(2)(C) de S.1618 /// This Message was Composed using Extractor Pro Bulk E- Mail Software. If you wish to be removed from this advertiser's future mailings, please reply with the subject Remove and this software will automatically block you from their future mailings. Para ser removido de la lista renvie a esta direccion este mensaje y en subjet, titulo o asunto escriba REMOVE que automaticamente sera removido para futuros mensajes. -- This Message sent with Aureate Group Mail Free Edition http://groupmail.aureate.com
year-2000 problem already showing up in mirror
I recently noticed that for non-existent files, mirror (the Perl script)
now reports dates of 2069/12/31-19:00:00 instead of 1969/12/31-19:00:00 :
Compare src README.ftp (1): 1998/11/06-00:00:00 1301 f
dest README.ftp (): 2069/12/31-19:00:00 0 0
Oh, gross. I just looked at mirror.pl:
if( $year 70 ){
$year += 2000;
}
else {
$year += 1900;
}
But where exactly is the problem?
The 70 in the if statement looks like it is based on the Unix epoch's
starting in 1970 (and therefore should be correct).
But the 19:00 is a reminder that the epoch's start in local time was as
early as _noon_ on Dec. 31, 1969. Therefore, checking the local-time year
against (19)70 is erroneous.
I thought I heard that Perl represents the year as year number - 1900.
(So the year 2000 is represented as 100.)
Does that mean that the then part of the if statement above is completely
superfluous? (The four-digit year would always be 1900 + perl's year,
right?)
In fact, does that mean that the only thing that the $year += 2000;
part does it cause the 2069 error? (That is, the year can be less than
70 only for the local time of the first 12 hours of the epoch, right?)
I don't recall when mirror's dates for non-existent files changed from
1969 to 2069... (I don't know if it changed at a certain date
or if I upgraded something.)
Is that if statement a bit of supposed Y2K preparation that wasn't
quite prepared right?
(I recall reading that since Perl returns 99 for 1999, people think
Perl uses only two digits for the year, and don't realize that in
2000, Perl will return a year value of 100. To print a four-digit
year, they prepend 19 to the year; in 2000, that code will print
19100.)
Daniel
Year 2000 status of debian
According to http://www.debian.org/y2k/ about half the packages in the base Debian system are not known to be Year 2000 compliant. While I realise that the probably are, I am having a very hard time trying to get a Debian system installed due to it not being year 2000 compliant. (as compared to Redhat (http://www.redhat.com/corp/legal_statement.html#y2k) - whose statement is actually useless for knowing if the system will work in the year 2000, but is better for getting the system past a 'Year 2000 compliant' new system installation checklist item. In particular it would be very useful if someone who understands dpkg and the other debian specific bits could decide if they are y2k compliant and if they are, then to arrange an update to the web page. John Lines
Re: Year 2000 status of debian
Wait a while. In six months no-one will care.
Re: Year 2000 status of debian
On Mon, Jun 14, 1999 at 10:12:52 +0100, John Lines wrote: I am having a very hard time trying to get a Debian system installed due to it not being year 2000 compliant. (as compared to Redhat (http://www.redhat.com/corp/legal_statement.html#y2k) - whose statement is actually useless for knowing if the system will work in the year 2000, but is better for getting the system past a 'Year 2000 compliant' new system installation checklist item. You can find Debian's generic we don't expect problems statement at http://www.debian.org/News/1998/19980104 HTH, Ray -- UNFAIR Term applied to advantages enjoyed by other people which we tried to cheat them out of and didn't manage. See also DISHONESTY, SNEAKY, UNDERHAND and JUST LUCKY I GUESS. - The Hipcrime Vocab by Chad C. Mulligan
Re: Year 2000 compliance
On Wed, Jul 29, 1998 at 08:18:36AM -0700, Alexander wrote: Hi... Linux has no Y2K issues aside from the BIOS. It's that simple. However, sometime in the 2030s, it will have some time_t problems if not fixed by then. They should be, although you will probably need to upgrade your embedded system if you want it to keep running after then. actually...as I remember its 2038...and once it is fixed we will be good for another 2 million years I think. hmm... think that rembedded system will be used 2 million years form now? AFAIK its just a matter of changing time_t to a 64 bit integer (instead of 32 bit) and recompiling everything that uses it... actually...BTW there are (or were) some Y2K issues in linux applications. I know as shipping hamm has 1 in some cvs package...but thats the last one. It only really will effect databases which store dates in their own way -Steve Alex On Thu, 23 Jul 1998, Rick Fadler wrote: Hi, I'm assuming with all the year 2000 compliance hype that there must be a document somewhere describing the year 2000 issues related to specific Debian releases of linux. Specifically, we have built an embedded system using Debian version 1.3. Being an embedded system, we've stripped out most of the utilities and standard packages. We now need to verify that our system is year 2000 compliant. Does anyone have any information on this? Rick Fadler NetLeaf, Inc [EMAIL PROTECTED] 425-643-9610 -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- ** Stephen Carpenter ** ** ** ** ** ** ** ** ** ** ** ** [EMAIL PROTECTED] ** All authority is quite degrading. -- Oscar Wilde pgpXTRarZwmQ8.pgp Description: PGP signature
Re: Year 2000 compliance
Hi... Linux has no Y2K issues aside from the BIOS. It's that simple. However, sometime in the 2030s, it will have some time_t problems if not fixed by then. They should be, although you will probably need to upgrade your embedded system if you want it to keep running after then. Alex On Thu, 23 Jul 1998, Rick Fadler wrote: Date: Thu, 23 Jul 1998 10:21:29 -0700 (PDT) From: Rick Fadler [EMAIL PROTECTED] To: debian-user@lists.debian.org Subject: Year 2000 compliance Resent-Date: 23 Jul 1998 17:22:49 - Resent-From: debian-user@lists.debian.org Resent-cc: recipient list not shown: ; Hi, I'm assuming with all the year 2000 compliance hype that there must be a document somewhere describing the year 2000 issues related to specific Debian releases of linux. Specifically, we have built an embedded system using Debian version 1.3. Being an embedded system, we've stripped out most of the utilities and standard packages. We now need to verify that our system is year 2000 compliant. Does anyone have any information on this? Rick Fadler NetLeaf, Inc [EMAIL PROTECTED] 425-643-9610 -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Year 2000 compliance
Hi... Any and all UNIX systems are fully Y2K compliant, as long as the hardware they run on is. However, their time_t value (UNIX time is represented in seconds since 00:00 Jan 1 1970) will overflow sometime in the 2030s I think. After that time_t will have to be expanded to 64 bits and all programs using it recompiled. Not exactly as hard as rewriting billions of lines of code; instead just modifying a single library header and compiling some stuff. Alex On Thu, 23 Jul 1998 [EMAIL PROTECTED] wrote: Date: Thu, 23 Jul 1998 13:10:24 -0500 (EST) From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: debian-user@lists.debian.org Subject: Re: Year 2000 compliance Resent-Date: 23 Jul 1998 18:04:54 - Resent-From: debian-user@lists.debian.org Resent-cc: recipient list not shown: ; *-Rick Fadler (23 Jul) | | Does anyone have any information on this? | http://www.debian.org/news#19980104 -- Brian Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Year 2000 compliance
On Sat, Jul 25, 1998 at 09:17:51PM -0700, Alexander wrote: Any and all UNIX systems are fully Y2K compliant, as long as the hardware I think this statement is naive. Although the kernel may represent all time values as time_t, you cannot guarantee that all applications do, and since there are rather a lot of them you can assume that there are some which use other mechanisms. Anything that stores a string, for example. So Unix is by no means automatically Y2K-proof. Do you disagree? Hamish -- Hamish Moffatt, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Year 2000 compliance
Hi, I'm assuming with all the year 2000 compliance hype that there must be a document somewhere describing the year 2000 issues related to specific Debian releases of linux. Specifically, we have built an embedded system using Debian version 1.3. Being an embedded system, we've stripped out most of the utilities and standard packages. We now need to verify that our system is year 2000 compliant. Does anyone have any information on this? Rick Fadler NetLeaf, Inc [EMAIL PROTECTED] 425-643-9610 -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Year 2000 compliance
*-Rick Fadler (23 Jul) | | Does anyone have any information on this? | http://www.debian.org/news#19980104 -- Brian Mechanical Engineering [EMAIL PROTECTED] Purdue University http://www.ecn.purdue.edu/~servis -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null
Re: Year 2000
Arran, Although linux may be year 2000 safe, You also must assure that all application programs are also clean. It much more likely that an application program will will have the fatal hidden flaw that will bring you down. Ben Benjamin T. White, M.D. | [EMAIL PROTECTED] Dept of Neurosurgery| http://members.aol.com/benmd/home.html Bowman Gray SOM | On Sun, 2 Nov 1997, Bruce Perens wrote: There is a year-2000 problem we know of that is connected to your PC's BIOS and clock chip. The BIOS and clock chip of many systems store a two-digit year. This is a separate issue from the Linux kernel clock, which is all software. Linux uses a program to read the hardware clock into the software one at boot time, and then does not refer to the hardware clock again except to set it or to measure its drift over time and correct for that. A patch to the hardware clock reader is necessary to achieve year-2000 compliance even if your BIOS and clock chip think it's 1900. We expect to be distributing this with Debian 2.0 . Since we publish all source code, anyone can fix it sooner if necessary. Unix and Linux store time as a count of seconds since New Year's day 1970 in a signed 32-bit integer. This was chosen to make the system time-zone-independent. This form of time storage does not have a year-2000 problem, but it will overflow in the year 2036. By that time we expect to have converted to a 64-bit variable, which will not overflow for around 274877906944 years. Hopefully, by that time something better than Unix will have come along. Several other year-2000 issues have already been found and repaired. We've run our systems with the clock set to various future dates to test them. We can't guarantee there are not any problems left, but we are sure they would be minor ones, and rapidly repaired. Because we publish all source code, you are guaranteed that you can get any problems fixed quickly. Thanks Bruce Perens -- 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] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000
There is a year-2000 problem we know of that is connected to your PC's BIOS and clock chip. The BIOS and clock chip of many systems store a two-digit year. This is a separate issue from the Linux kernel clock, which is all software. Linux uses a program to read the hardware clock into the software one at boot time, and then does not refer to the hardware clock again except to set it or to measure its drift over time and correct for that. A patch to the hardware clock reader is necessary to achieve year-2000 compliance even if your BIOS and clock chip think it's 1900. We expect to be distributing this with Debian 2.0 . Since we publish all source code, anyone can fix it sooner if necessary. Unix and Linux store time as a count of seconds since New Year's day 1970 in a signed 32-bit integer. This was chosen to make the system time-zone-independent. This form of time storage does not have a year-2000 problem, but it will overflow in the year 2036. By that time we expect to have converted to a 64-bit variable, which will not overflow for around 274877906944 years. Hopefully, by that time something better than Unix will have come along. Several other year-2000 issues have already been found and repaired. We've run our systems with the clock set to various future dates to test them. We can't guarantee there are not any problems left, but we are sure they would be minor ones, and rapidly repaired. Because we publish all source code, you are guaranteed that you can get any problems fixed quickly. Thanks Bruce Perens -- 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] .
Year 2000
Hi all, Is there anyone out there can give me any information regarding linux or more specifically debian in relation to the Y2k problem? We run a couple of debian boxes in production and my manager has been asked to do an audit on how complient these machines are as far as year 2000. Any information or pointers to information greatly appreciated. cheers Arran ~~ My opinions, not necessarily the National Library's... Arran Price: Tapuhi Systems Administrator National Library of New Zealand, Wellington Ph: (04) 474 3000, x8954. Fax: (04) 474 3161 ~~ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
[gnu.misc.discuss,comp.software.year-2000] Re: GNU software Year 2000 Ready?
Something about Debian GNU/Linux being year-2000-ready, for those interested. -- Emilio C. Lopes mailto:[EMAIL PROTECTED] --- Start of forwarded message --- From: Duane Griffin [EMAIL PROTECTED] Newsgroups: gnu.misc.discuss,comp.software.year-2000 Subject: Re: GNU software Year 2000 Ready? Date: Tue, 28 Oct 1997 14:34:38 +1300 Organization: Massey University Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] The latest issue of UniForum NZ News (October, 1997, which I have no doubt everyone here is familiar with :) includes an article by Bill Parkin (Linux Lines, p. 7) on a basic Y2K test he did on a Linux system (Debian, recent release, disconnected from network, x86 machine(?)). In brief, aside from a small CMOS glitch that was easily resolved, everything seemed to work fine. The machine was told it was 2004, and rebooted, then left running for over two days, with periodic checks. Cron jobs ran fine; system logs showed no problems; no errors detected in any of the basic utilities; NTP (using xntpd) also stayed happy and healthy, aside from noting the rest of the world was missing. This test was far from complete, or rigorous (from what I read), but is still good news, worth noting. Bill has promised to do more testing, including tests on mail and usenet software using a couple of machines. Cheers, Duane. == I never could learn to drink that blood and call it wine - Bob Dylan (Tight Connection to my Heart) Duane Griffin #includestandard_disclaimers.h == --- End of forwarded message --- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
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] .
Debian and they Year 2000 problem
The Year 2000 problem has been discussed extensively, but when anyone asks about Linux the answer is always 'The kernel is OK up till 2038, other than that it is an application problem' It seems to me that the Debian distribution, by breaking up the applications into a large number of manageable packages, could help to address the year2000 problem for Linux users. If we knew the year 2000 status of every package then we could see which areas were OK and which ones needed work. Something along the lines of a database (flat file type) with package name and version and Year2000 status, with Year 2000 status being one of Unknown No date dependancies OK Not OK I would expect the majority of packages to be in the 'No date dependancies' or OK catagories without any work required. The database would only deal with that particular package, leaving the issues of dependancies on other packages to the normal Debian depandancy machanism. John Lines -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000
Syd Alsobrook wrote: Just a curious question, does anyone know if linux in general and Debian in particular are year 2000 compliant? We're OK until 2017 (and since I'll surely have a 64-bit system by then, 'til hell freezes over) for 32-bit systems. It would be a shame if we came down to the wire and had forgotten something Syd http://www.uc.edu/~alsobrsp How do you know you're having fun if there's no one watching you have it. Douglas Adams finger [EMAIL PROTECTED] for PGP public key! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000
Ralph Winslow wrote: Syd Alsobrook wrote: Just a curious question, does anyone know if linux in general and Debian in particular are year 2000 compliant? We're OK until 2017 (and since I'll surely have a 64-bit system by then, 'til hell freezes over) for 32-bit systems. It would be a shame if we came down to the wire and had forgotten something Syd http://www.uc.edu/~alsobrsp How do you know you're having fun if there's no one watching you have it. Douglas Adams finger [EMAIL PROTECTED] for PGP public key! Actually 32 bits will get us thru to 2037 but that only means that the number of seconds since midnight Dec 31, 1970 can be accumulated in a 32-bit variable without rollover to zero. That does NOT necessarily mean that programs (including the linux kernel, libc, etc.) that use that 32-bits do so correctly. The biggest problems seem to me to be with the thousands of applications that use dates. Even if the kernel and libraries work properly, that doesn't mean a given program uses time properly. An easy example: struct tm from time.h has the year field defined as the number of years since 1900 and is Y2K compliant since for the year 2000 it contains decimal 100. There could be an application out there that currently works but will crash in 2000 because incorrect assumptions were made about the range of year and say an array index is computed incorrectly. Clearly, bad things can happen when a program corrupts its stack or otherwise accesses memory outside the bounds of the array. I've read that bad things will happen to Windows95 at the midnight rollover Dec 31, 1999 but only if it's running! Duh, bad things can always happen when Windows95 is running. But seriously, I guess if you stop the machine _before_ midnight and restart _after_ midnight then all's well. Who knows what lurking out there in *nix that will go whacko when the rollover occurs. With all the attention that this problem is getting in some circles, it would be a major coup if somehow Debian packages could individually and collectively be certified Y2K compliant and a Y2K compliant Debian release prepared. IMHO no other linux distribution, commercial or otherwise, has the level of control available with Debian. Comments? --Bob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 and samba...
Thomas Baetzler wrote: I suppose this would work the same way as setting up any other remote printer: by creating a set of two spools. SDee the details in the LPR-HOWTO. Where is the lpr howto? I don't see it in the debian howto package. -- see shy jo -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Year 2000
Just a curious question, does anyone know if linux in general and Debian in particular are year 2000 compliant? It would be a shame if we came down to the wire and had forgotten something Syd http://www.uc.edu/~alsobrsp How do you know you're having fun if there's no one watching you have it. Douglas Adams finger [EMAIL PROTECTED] for PGP public key! -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 and samba...
As far as I've been told, though I haven't actually tried it, the Linux kernel functions up to the year 2037. How that works, I'm not entirely sure... Anyhow, I've got a question of my own: Has anyone successfully gotten a filter to use gs on a .ps file AND send it to a networked printer via smbclient? I've gotten as far as previewing a PostScripted file using gv, and I can print raw text through smbclient, but I've kind of stepped onto a stumbling block with this pairing. Ah well... Thanks anyways! -- James :) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 and samba...
James C. Carr wrote:
: As far as I've been told, though I haven't actually tried it,
:the Linux kernel functions up to the year 2037. How that works, I'm
:not entirely sure...
The Unix timestamp is represented as time_t, which is usually a signed
long value. A date is represented a the number of seconds elapsed since
January 1st 1970, 0:00:00. The easy way to figure out the wrap date is
by running the following code:
-snip-
#include stdio.h
#include limit.h
#include time.h
void main( int argc, char **argv )
{
time_t wrap = LONG_MAX;
printf(Wrap will occur at %s, asctime( gmtime(wrap_tm) ) );
}
-snip-
: Anyhow, I've got a question of my own: Has anyone successfully
:gotten a filter to use gs on a .ps file AND send it to a networked
:printer via smbclient? I've gotten as far as previewing a
:PostScripted file using gv, and I can print raw text through
:smbclient, but I've kind of stepped onto a stumbling block with this
:pairing. Ah well...
I suppose this would work the same way as setting up any other remote
printer: by creating a set of two spools. SDee the details in the
LPR-HOWTO.
Bye,
--
Thomas Baetzler, [EMAIL PROTECTED], [EMAIL PROTECTED]
A HREF=http://www.fh-karlsruhe.de/~bath0011/Visit my Homepage!/A
The cowards never came, and the weaklings died on the way - R.A.H.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: Year 2000 and samba...
[EMAIL PROTECTED] (Thomas Baetzler) writes:
James C. Carr wrote:
: As far as I've been told, though I haven't actually tried it,
:the Linux kernel functions up to the year 2037. How that works, I'm
:not entirely sure...
The Unix timestamp is represented as time_t, which is usually a signed
long value. A date is represented a the number of seconds elapsed since
January 1st 1970, 0:00:00. The easy way to figure out the wrap date is
by running the following code:
I think there were a couple of typos in the code you included. I
believe it should read
-snip-
#include stdio.h
#include limits.h
#include time.h
void main( int argc, char **argv )
{
time_t wrap_tm = LONG_MAX;
printf(Wrap will occur at %s, asctime( gmtime(wrap_tm) ) );
}
-snip-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: year-2000 testing
On Sun, 27 Apr 1997, Sam Ockman wrote: Message from Bruce Perens ([EMAIL PROTECTED]): If you can do so, please try running your system with the date in the year 2000 for a while. Richard Stallman asked if we had tested that GNU software is free of year-2000 problems, and I think it's a good idea. It seems like the problems, if any, would probably be more problems from the actual roll-over from the year 1999 to 2000, so probably the best thing would be to set your computer's date to Dec. 31, 1999, and see what happens to your processes when it hits midnight. That might test the kernel and the hardware/firmware, but I think plenty of problems in programs only surface during the next millenium. For example, some misfeatures of my own software concerned machine generated filenames that should collate in date order, but I didn't include the century (back in 1986) because I was squeezing it all into DOS-compatible filenames (and didn't think the instruments concerned would still be running into the next century...). -- David Wright, Open University, Earth Science Department, Milton Keynes MK7 6AA U.K. email: [EMAIL PROTECTED] tel: +44 1908 653 739 fax: +44 1908 655 151 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: year-2000 testing
Message from Bruce Perens ([EMAIL PROTECTED]): If you can do so, please try running your system with the date in the year 2000 for a while. Richard Stallman asked if we had tested that GNU software is free of year-2000 problems, and I think it's a good idea. Fortunately we don't have too many COBOL programs :-) . To do this, you'll probably need to run something like clock -u -w after resetting the date with the date command. It seems like the problems, if any, would probably be more problems from the actual roll-over from the year 1999 to 2000, so probably the best thing would be to set your computer's date to Dec. 31, 1999, and see what happens to your processes when it hits midnight. -Sam -- VA Research Linux Workstations Engineered like no other http://www.varesearch.com Sam Ockman - (415)934-3666, ext. 133 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: year-2000 testing
[EMAIL PROTECTED] (Bruce Perens) writes: If you can do so, please try running your system with the date in the year 2000 for a while. Richard Stallman asked if we had tested that GNU software is free of year-2000 problems, and I think it's a good idea. Fortunately we don't have too many COBOL programs :-) . Seriously, someone grab a copy of the Packages file for the alpha dist---all of those programs have run with the year past 2000 for several weeks on my AXP box. It comprises almost all of the GNU utils---or most of the fairly mainstream ones. You see, the standard clock executable didn't know about the fact that the firmware kept the time based from 1980... Mike. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: year-2000 testing
Michael Alan Dorman wrote: [EMAIL PROTECTED] (Bruce Perens) writes: If you can do so, please try running your system with the date in the year 2000 for a while. Richard Stallman asked if we had tested that GNU software is free of year-2000 problems, and I think it's a good idea. Fortunately we don't have too many COBOL programs :-) . Seriously, someone grab a copy of the Packages file for the alpha dist---all of those programs have run with the year past 2000 for several weeks on my AXP box. It comprises almost all of the GNU utils---or most of the fairly mainstream ones. You see, the standard clock executable didn't know about the fact that the firmware kept the time based from 1980... I had a similar experience. About 4 months ago, the /sbin/clock program kept setting the date to 2038 on my development machine. Whenever I noticed it, I would fix it, but everytime I rebooted, it would reset to 2038. I'm still finding files and emails that were written by me in the year 2038. 8) (I'm just glad /sbin/clock was fixed in the next util-linux package!) All in all, in the 4+ weeks I ran in the year 2038, the only major problem I had was with make(1) not recompiling the proper C files (due to there being a ~40 year difference in age between a lot of the source files). 8) I'm not saying I've formally tested the 500+ debian packages on my machine for the year 2000 problem, but the ones I did use seemed to work just fine. Does that help? Behan -- Behan Webster mailto:[EMAIL PROTECTED] (613) 224-7547http://www.verisim.com/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: year-2000 testing
Did anyone test _emacs_ for year-2000 problems? Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
year-2000 testing
If you can do so, please try running your system with the date in the year 2000 for a while. Richard Stallman asked if we had tested that GNU software is free of year-2000 problems, and I think it's a good idea. Fortunately we don't have too many COBOL programs :-) . To do this, you'll probably need to run something like clock -u -w after resetting the date with the date command. Thanks Bruce -- Bruce Perens K6BP [EMAIL PROTECTED] 510-215-3502 Finger [EMAIL PROTECTED] for PGP public key. PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3 -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
