Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
nightmares, it's about this date and time. Immediately after that second
is crossed, current computer systems running on Linux will grind to a
halt or go into a loop. This will trip up a lot of databases. No, this
is not another hoax raised by some anti-Linux lobby. It is Linux's own
Y2K nightmare, says Businessworld.
If you ask what this 2038 bug is, you will have to put up some technical
argot. The bug has its origins in the way the C language, which has been
used to write Linux, calculates time. C uses the 'time_t' data type to
represent dates and times. ('time_t' is an integer that counts the
number of seconds since 12.00 a.m. GMT, January 1 1970.)
This data is stored in 32 bits, or units of memory. The first of these
bits is for the positive or negative sign, and the remaining 31 are used
to store the number. The highest number that these 31 bits can store
works out to 2147483647.
Calculated from the start of January 1 1970, this number would represent
the 2038 time and date given at the top. Problems would arise when the
system times of computers running on Linux reach this number. They can't
go any forward and their value actually would change to -- 2147483647,
which translated to December 13 1901! That will lead many programs to
return errors or crash altogether.
It's more damaging than the Y2K bug. That's because Y2K mostly involved
higher-level applications such as credit card payment and inventory
management. The 2038 bug, on the other hand, affects the basic
time-keeping function.
"I would guess the biggest issue would be in the embedded field, where
software isn't changed all that often, if at all. Process controllers,
routers, mobile phones, game consoles, telecom switches and the like
would be the biggest victims," says Raju Mathur, GNU and Linux
consultant and president of the Linux Delhi Users Group.
He, however, adds that the rate at which we are changing technology,
most systems are unlikely to use 32-bit processing by the time we get to
2038.
But what about the present? Many applications running on Linux could
soon be making calculations for dates 30 years away -- say, for mortgage
and insurance calculations -- and could start giving out error messages
well before D-day. The problem could be widespread because more and more
corporates today are migrating to Linux because of the better security
it offers.
"The problem is not on the radar of most people, except the techies,"
says Charles Assissi, editor, Chip magazine.
How can the problem be sorted? Modern Linux programs could use 64-bit or
longer time_t data storage to overcome the problem. As for the existing
systems, the way the C language stores time_t data could be changed and
then all the programs could be recompiled. All this is easier said than
done.
"There must be millions, if not billions of lines of C code floating
around that use the time_t value. Locating them, changing them, managing
programs for which source isn't available, updating embedded systems,
redeploying, is, in my opinion, an impossible task," says Mathur. Will
that be another lucrative opportunity for India's army of coders?
Srinivas G. wrote:
> Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
> nightmares, it's about this date and time. Immediately after that second
> is crossed, current computer systems running on Linux will grind to a
> halt or go into a loop. This will trip up a lot of databases. No, this
> is not another hoax raised by some anti-Linux lobby. It is Linux's own
> Y2K nightmare, says Businessworld.
>
> If you ask what this 2038 bug is, you will have to put up some technical
> argot. The bug has its origins in the way the C language, which has been
> used to write Linux, calculates time. C uses the 'time_t' data type to
> represent dates and times. ('time_t' is an integer that counts the
> number of seconds since 12.00 a.m. GMT, January 1 1970.)
>
> This data is stored in 32 bits, or units of memory. The first of these
> bits is for the positive or negative sign, and the remaining 31 are used
> to store the number. The highest number that these 31 bits can store
> works out to 2147483647.
>
> Calculated from the start of January 1 1970, this number would represent
> the 2038 time and date given at the top. Problems would arise when the
> system times of computers running on Linux reach this number. They can't
> go any forward and their value actually would change to -- 2147483647,
> which translated to December 13 1901! That will lead many programs to
> return errors or crash altogether.
>
> It's more damaging than the Y2K bug. That's because Y2K mostly involved
> higher-level applications such as credit card payment and inventory
> management. The 2038 bug, on the other hand, affects the basic
> time-keeping function.
>
> "I would guess the biggest issue would be in the embedded field, where
> software isn't changed all that often, if at all. Process controllers,
> routers, mobile phones, game consoles, telecom switches and the like
> would be the biggest victims," says Raju Mathur, GNU and Linux
> consultant and president of the Linux Delhi Users Group.
>
> He, however, adds that the rate at which we are changing technology,
> most systems are unlikely to use 32-bit processing by the time we get to
> 2038.
>
> But what about the present? Many applications running on Linux could
> soon be making calculations for dates 30 years away -- say, for mortgage
> and insurance calculations -- and could start giving out error messages
> well before D-day. The problem could be widespread because more and more
> corporates today are migrating to Linux because of the better security
> it offers.
>
> "The problem is not on the radar of most people, except the techies,"
> says Charles Assissi, editor, Chip magazine.
>
> How can the problem be sorted? Modern Linux programs could use 64-bit or
> longer time_t data storage to overcome the problem. As for the existing
> systems, the way the C language stores time_t data could be changed and
> then all the programs could be recompiled. All this is easier said than
> done.
>
> "There must be millions, if not billions of lines of C code floating
> around that use the time_t value. Locating them, changing them, managing
> programs for which source isn't available, updating embedded systems,
> redeploying, is, in my opinion, an impossible task," says Mathur. Will
> that be another lucrative opportunity for India's army of coders?
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I think the most time value aren't timestamps (it's slower than a timestamp but works). So don't worry.
Matthias-Christian Ott
On Fri, 13 May 2005, Srinivas G. wrote:
> Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
> nightmares, it's about this date and time. Immediately after that second
> is crossed, current computer systems running on Linux will grind to a
> halt or go into a loop. This will trip up a lot of databases. No, this
> is not another hoax raised by some anti-Linux lobby. It is Linux's own
> Y2K nightmare, says Businessworld.
>
[SNIPPED...]
It's simply not true. It's more FUD. Look at the date on this email.
Also, calculating 30-year mortgages doesn't use time_t. Code certianly
doesn't set the time 30 years ahead to see what the cost is. It's
just FUD.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Friday 13 May 2005 14:43, Srinivas G. wrote:
> But what about the present? Many applications running on Linux could
> soon be making calculations for dates 30 years away -- say, for mortgage
> and insurance calculations -- and could start giving out error messages
> well before D-day. The problem could be widespread because more and more
> corporates today are migrating to Linux because of the better security
> it offers.
...
> How can the problem be sorted? Modern Linux programs could use 64-bit or
> longer time_t data storage to overcome the problem. As for the existing
^^^^^^
Looks like someone is contemplating a mortgage which expire well beyond
Solar system lifetime.
--
vda
On Fri, 13 May 2005, Denis Vlasenko wrote:
> On Friday 13 May 2005 14:43, Srinivas G. wrote:
>> But what about the present? Many applications running on Linux could
>> soon be making calculations for dates 30 years away -- say, for mortgage
>> and insurance calculations -- and could start giving out error messages
>> well before D-day. The problem could be widespread because more and more
>> corporates today are migrating to Linux because of the better security
>> it offers.
> ...
>> How can the problem be sorted? Modern Linux programs could use 64-bit or
>> longer time_t data storage to overcome the problem. As for the existing
> ^^^^^^
> Looks like someone is contemplating a mortgage which expire well beyond
> Solar system lifetime.
> --
> vda
Yes. It's more FUD. The __real__ problem, ther everybody should
be concerned about is that today is Friday the 13th. My black cat
already walked under a ladder and broke my mirror.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
It would be good if the doom-sayers actually tried before then lied.....
Just in case anybody wants to try it:
int main()
{
int x = 0x7fffff00;
stime(&x);
}
Script started on Mon 18 Jan 2038 10:12:32 PM EST
[root@chaos root]# while true ; do date ; sleep 1 ; done
Mon Jan 18 22:12:44 EST 2038
Mon Jan 18 22:12:45 EST 2038
Mon Jan 18 22:12:46 EST 2038
Mon Jan 18 22:12:47 EST 2038
Mon Jan 18 22:12:48 EST 2038
[SNIPPED...]
Mon Jan 18 22:14:01 EST 2038
Mon Jan 18 22:14:02 EST 2038
Mon Jan 18 22:14:03 EST 2038
Mon Jan 18 22:14:04 EST 2038
Mon Jan 18 22:14:05 EST 2038
Mon Jan 18 22:14:06 EST 2038
Mon Jan 18 22:14:07 EST 2038
Fri Dec 13 15:46:09 EST 1901
Fri Dec 13 15:46:10 EST 1901
Fri Dec 13 15:46:11 EST 1901
Fri Dec 13 15:46:12 EST 1901
Fri Dec 13 15:46:13 EST 1901
Fri Dec 13 15:46:14 EST 1901
Fri Dec 13 15:46:15 EST 1901
Fri Dec 13 15:46:16 EST 1901
Fri Dec 13 15:46:17 EST 1901
Fri Dec 13 15:46:18 EST 1901
Fri Dec 13 15:46:19 EST 1901
[root@chaos root]# exit
Script done on Fri 13 Dec 1901 03:46:44 PM EST
As you can see, the machine still runs. There was a little
hickup in the 'sleep 1' it slept more than a second.
Remember to `rdate` your computer before you do any serious
work. The file-dates correctly show the new, before Unix, time and
date.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
Hi :)
* Srinivas G. <[email protected]> dixit:
> Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
> nightmares, it's about this date and time. Immediately after that second
> is crossed, current computer systems running on Linux will grind to a
> halt or go into a loop. This will trip up a lot of databases. No, this
> is not another hoax raised by some anti-Linux lobby. It is Linux's own
> Y2K nightmare, says Businessworld.
Do you mean we have less than 33 years to switch to a longer type
to store timestamps? I'm *seriously* frightened. I'm only 32, so I
think I will manage to spend another half of my life switching to 64
bits timestamps.
But we shouldn't worry, anyway, because the end of the world is
scheduled to be much sooner. I've heard rumours about a hyperspace
speedway that must pass *just* over this tiny little planet we call
home. Maybe the answer is 42.
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
On Fri, 13 May 2005 16:37:36 +0200 DervishD wrote:
| Hi :)
|
| * Srinivas G. <[email protected]> dixit:
| > Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
| > nightmares, it's about this date and time. Immediately after that second
| > is crossed, current computer systems running on Linux will grind to a
| > halt or go into a loop. This will trip up a lot of databases. No, this
| > is not another hoax raised by some anti-Linux lobby. It is Linux's own
| > Y2K nightmare, says Businessworld.
|
| Do you mean we have less than 33 years to switch to a longer type
| to store timestamps? I'm *seriously* frightened. I'm only 32, so I
| think I will manage to spend another half of my life switching to 64
| bits timestamps.
|
| But we shouldn't worry, anyway, because the end of the world is
| scheduled to be much sooner. I've heard rumours about a hyperspace
| speedway that must pass *just* over this tiny little planet we call
| home. Maybe the answer is 42.
but that begs the question, "to what question is 42 the answer?" 8;)
---
~Randy
Hi Randy :)
* randy_dunlap <[email protected]> dixit:
> | home. Maybe the answer is 42.
> but that begs the question, "to what question is 42 the answer?" 8;)
Don't worry, a planet-size computer has been built just for that
XDDDDDDDDDDDD
Ra?l N??ez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
http://www.pleyades.net & http://www.gotesdelluna.net
It's my PC and I'll cry if I want to...
On Wed, 1969-12-31 at 17:54 -0500, Richard B. Johnson wrote:
> On Fri, 13 May 2005, Srinivas G. wrote:
>
> > Tuesday, January 19 2038. Time: 03:14:07 GMT. If Linux programmers get
> > nightmares, it's about this date and time. Immediately after that second
> > is crossed, current computer systems running on Linux will grind to a
> > halt or go into a loop. This will trip up a lot of databases. No, this
> > is not another hoax raised by some anti-Linux lobby. It is Linux's own
> > Y2K nightmare, says Businessworld.
> >
> [SNIPPED...]
>
> It's simply not true. It's more FUD. Look at the date on this email.
> Also, calculating 30-year mortgages doesn't use time_t. Code certianly
> doesn't set the time 30 years ahead to see what the cost is. It's
> just FUD.
Please don't screw up thousands of people's inbox to make a point. Many
people sort their mail into folders by date.
Lee
There are bigger problems with the Unix clock than that already. Old
Unix used GMT, newer Unixen use UTC so the same timeval is several
seconds out between very old and modern systems.
Our 64bit time_t in the 64bit kernels seems to work well in testing too
(except older SuSE which segfaulted but thats just a libc glitch). The
next time Linux seems to fall apart is 2800AD, although the CMOS hits
problems rather earlier and would need a new driver/definition if still
used. Feb 29th 2800 seems to be when all hell breaks loose and thats
*not* *our* *fault* but because time hasn't been standardised
sufficiently at this point.
2038 is more likely to be boom time for old long running embedded
systems, machinery and control circuits than Linux.
Alan
Richard B. Johnson wrote:
>
> It would be good if the doom-sayers actually tried before then lied.....
>
> Just in case anybody wants to try it:
>
> int main()
> {
> int x = 0x7fffff00;
> stime(&x);
> }
>
> Script started on Mon 18 Jan 2038 10:12:32 PM EST
> [root@chaos root]# while true ; do date ; sleep 1 ; done
> Mon Jan 18 22:12:44 EST 2038
> Mon Jan 18 22:12:45 EST 2038
> Mon Jan 18 22:12:46 EST 2038
> Mon Jan 18 22:12:47 EST 2038
> Mon Jan 18 22:12:48 EST 2038
> [SNIPPED...]
> Mon Jan 18 22:14:01 EST 2038
> Mon Jan 18 22:14:02 EST 2038
> Mon Jan 18 22:14:03 EST 2038
> Mon Jan 18 22:14:04 EST 2038
> Mon Jan 18 22:14:05 EST 2038
> Mon Jan 18 22:14:06 EST 2038
> Mon Jan 18 22:14:07 EST 2038
> Fri Dec 13 15:46:09 EST 1901
^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
> Fri Dec 13 15:46:10 EST 1901
> Fri Dec 13 15:46:11 EST 1901
> Fri Dec 13 15:46:12 EST 1901
> Fri Dec 13 15:46:13 EST 1901
> Fri Dec 13 15:46:14 EST 1901
> Fri Dec 13 15:46:15 EST 1901
> Fri Dec 13 15:46:16 EST 1901
> Fri Dec 13 15:46:17 EST 1901
> Fri Dec 13 15:46:18 EST 1901
> Fri Dec 13 15:46:19 EST 1901
>
> [root@chaos root]# exit
>
> Script done on Fri 13 Dec 1901 03:46:44 PM EST
>
> As you can see, the machine still runs. There was a little
> hickup in the 'sleep 1' it slept more than a second.
>
> Remember to `rdate` your computer before you do any serious
> work. The file-dates correctly show the new, before Unix, time and
> date.
Good point. Given current firewalls, I wouldn't be surprised if rdate
fails and ntpdate is needed, or at least resetting the system clock from HW.
On Fri, 13 May 2005 16:36:23 EDT, Bill Davidsen said:
>
> > Mon Jan 18 22:14:07 EST 2038
> > Fri Dec 13 15:46:09 EST 1901
> ^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
The heck with leap seconds - why did it warp back to 1901 rather
than to 1969/1970? ;)
[email protected] wrote:
> On Fri, 13 May 2005 16:36:23 EDT, Bill Davidsen said:
>
>>>Mon Jan 18 22:14:07 EST 2038
>>>Fri Dec 13 15:46:09 EST 1901
>>
>> ^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
>
>
> The heck with leap seconds - why did it warp back to 1901 rather
> than to 1969/1970? ;)
Because that's what the maximum negative number gives?
Chris
On Fri, 13 May 2005 15:07:04 MDT, Chris Friesen said:
> Because that's what the maximum negative number gives?
Good, somebody's paying attention. :)
So what breaks if we change it to an 'unsigned int', and can we fix those
issues before 2038, and will any of us here now *care* when an unsigned 32-bit
overflows in 2106 or whenever it is? :)
On Gwe, 2005-05-13 at 21:47, [email protected] wrote:
> The heck with leap seconds - why did it warp back to 1901 rather
> than to 1969/1970? ;)
time_t is signed so it jumps back. 0:00 UTC is 0 not -MAXINT.
On Fri, 13 May 2005 [email protected] wrote:
> Date: Fri, 13 May 2005 17:22:27 -0400
> From: [email protected]
> To: Chris Friesen <[email protected]>
> Cc: Bill Davidsen <[email protected]>, [email protected],
> Srinivas G. <[email protected]>,
> linux-kernel-Mailing-list <[email protected]>
> Subject: Re: Y2K-like bug to hit Linux computers! - Info of the day
>
> On Fri, 13 May 2005 15:07:04 MDT, Chris Friesen said:
>
>> Because that's what the maximum negative number gives?
>
> Good, somebody's paying attention. :)
>
> So what breaks if we change it to an 'unsigned int', and can we fix those
> issues before 2038, and will any of us here now *care* when an unsigned 32-bit
> overflows in 2106 or whenever it is? :)
all values that are currently prior to Jan 1 1970 would become post 2038
dates
Guys, this isn't a new problem, it was discussed quite a bit in 1999 as
well, as were a lot of potential solutions.
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
[email protected] wrote:
>On Fri, 13 May 2005 16:36:23 EDT, Bill Davidsen said:
>
>
>>>Mon Jan 18 22:14:07 EST 2038
>>>Fri Dec 13 15:46:09 EST 1901
>>>
>>>
>> ^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
>>
>>
>
>The heck with leap seconds - why did it warp back to 1901 rather
>than to 1969/1970? ;)
>
>
because it look like the time is a signed number... but shall i ask how
counting something that increase can give a negative number?
second... is the counter on the software? until now i thought that the
counter is a clock on the hardware... so how is this related with Linux?
then the counter overflow... this will be a hardware issue... not a
software issue ( the software will have to support the bigger hardware
counter but to do that the bigger hardware has to exist first...)
BTW is there anyone that plan to use his embedded devise until 2038????
i would happy to see that :P any way embedded devises are there so they
will have sort life cycle... how long are you going to use them 6
months???? maximum 1-2 years....
so there is no any problem....
firstly lemme say im hardly any authority, so feel free to disregard
anything I have to say, lord knows everyone else does.
I would say that this is more or less a known issue, and not really an
issue- at least not as far as I can see- I would hope that by 2038 64b (or
larger) int's would be standard.
> but shall i ask how
> counting something that increase can give a negative number?
what would you expect MAX_INT+1 to yield?
as a short example:
submission$ cat test.c
int main(void) {
signed short int count = 0;
while(count >= 0 ) {
printf("count: %d\n", count++ );
}
printf("count: %d\n");
}
submission$ gcc -o test test.c
submission$ ./test
[...]
count: 32767
count: -1
> second... is the counter on the software? until now i thought that the counter
> is a clock on the hardware...
IIRC the software keeps track of the count, so even though its physically
a hardware clock, the software still has to count it- if a 32b int can
only represent 2^32-1, then we will hit a wall, for our purposes this will
be in 2038, unless by then linux switches to a 64b counter, which is quite
probably (and possibly already done under amd64 and the likes?)
> so how is this related with Linux? then the
> counter overflow... this will be a hardware issue... not a software issue (
> the software will have to support the bigger hardware counter but to do that
> the bigger hardware has to exist first...)
I could be wrong here, but I don't think the hardware even keeps track of
the clock ticks, rather it just ticks and lets the software keep track.
> BTW is there anyone that plan to use his embedded devise until 2038????
not exactly an embedded device however I have my feet resting on an ibm
ps/2 286 running minix. Some people hold onto things longer than other
people.
jnf wrote:
>submission$ cat test.c
>int main(void) {
> signed short int count = 0;
>
> while(count >= 0 ) {
> printf("count: %d\n", count++ );
> }
> printf("count: %d\n");
>}
>submission$ gcc -o test test.c
>submission$ ./test
>[...]
>count: 32767
>count: -1
>
>
>
correct but i didn't mean that... i mean how to become negative with out
an overflow...
>I could be wrong here, but I don't think the hardware even keeps track of
>the clock ticks, rather it just ticks and lets the software keep track.
>
>
>
it has to have hardware because if there is not so how the time is
updated then the system is turned off? ;)
it has to be hardware that keeps working...
On Sat, May 14, 2005 at 10:09:04AM +0100, christos gentsis wrote:
> BTW is there anyone that plan to use his embedded devise until 2038????
> i would happy to see that :P any way embedded devises are there so they
> will have sort life cycle... how long are you going to use them 6
> months???? maximum 1-2 years....
> so there is no any problem....
That depends on what you're building. If you're designing an ADSL router,
then yes, a few years are enough. If you're making a deep space probe,
considering that voyager and pioneer have been in space for more than
30 years, you might want to ensure there's no problem.
Regards,
Willy
On Sat, May 14, 2005 at 10:09:04AM +0100, christos gentsis wrote:
> BTW is there anyone that plan to use his embedded devise until 2038????
> i would happy to see that :P any way embedded devises are there so they
> will have sort life cycle... how long are you going to use them 6
> months???? maximum 1-2 years....
> so there is no any problem....
I assume you are thinking of 'consumer' devices here, ADSL routers,
Satelite 'Set top boxes' and the like that have short lives.
Embeded computing is much bigger than that. I've got a 20 year old
embedded processor controlled microwave oven. (It still knows how to
cook better than I do :-).
All sorts of Industrial machinery have embeded CPUs. I'm a train nut.
In just this field, railways - equipment is expected to have a 30 year
operational life span, and much of it is now driven by embeded
computers, from traffic control signaling systems that have to be
absolutely safe from 'wrong side failures', 'fly by wire' traction power
control to regulate the trains speed, to monitoring the temprature of
the air-conditioning. A train being built right at this very moment,
with a 'train operating system' computer controlling every aspect of
it's operation will probably still be in service in 2038.
With any luck however, the people writing the software for these
things are aware of this issue and are not blindly using signed 32 bit
absolute time values from 1970.
BTW, the machine i'm typing this on WONT have this problem. (Doubt
that it will be still around in 2038 anyway). It's a 64bit platform and
time_t is 64 bit.
It isn't just a linux problem either, it's a generic Unix/C library
problem. Any software system that uses a signed 32bit number from 1970
to represent time. I have a vague recolection that there was another
popular system around that also used signed 32bit time, only it's epoch
is 1980. Those systems will go belly up 10 years after all the ancient
Unix systems. :-)
Srinivas G. <[email protected]> wrote:
> But what about the present? Many applications running on Linux could
> soon be making calculations for dates 30 years away -- say, for mortgage
> and insurance calculations -- and could start giving out error messages
> well before D-day. The problem could be widespread because more and more
> corporates today are migrating to Linux because of the better security
> it offers.
time_t is for systems times only, and it is not to be manipulated directly.
If you'd do that, you'll miss leap seconds and have additional leap years.
Besides that, it's not portable to different EPOCHs.
Therefore, apllications MUST use their own time types.
--
A. Top posters
Q. What's the most annoying thing on Usenet?
Matthew Geier wrote:
>
> Embeded computing is much bigger than that. I've got a 20 year old
> embedded processor controlled microwave oven. (It still knows how to
> cook better than I do :-).
>
why anyone that refer to an embedded device mean a microwave???? this is
really annoying then you make a master in embedded systems :P:P
mououahahahahaha
> It isn't just a linux problem either, it's a generic Unix/C library
> problem. Any software system that uses a signed 32bit number from 1970
> to represent time. I have a vague recolection that there was another
> popular system around that also used signed 32bit time, only it's
> epoch is 1980. Those systems will go belly up 10 years after all the
> ancient Unix systems. :-)
>
which is that system??? if it is the well known system ;) there no
problem with and the available time... to counters are capable to count
more seconds that the life time of this OS :P
mouahahahaha
thanks
christos
On Sat, 14 May 2005 21:27:11 BST, christos gentsis said:
> Matthew Geier wrote:
>
> >
> > Embeded computing is much bigger than that. I've got a 20 year old
> > embedded processor controlled microwave oven. (It still knows how to
> > cook better than I do :-).
> >
> why anyone that refer to an embedded device mean a microwave????
Microwaves. Alarm clocks. Stereos. DVD players. Tivo units. Your car, most
likely, unless it's *so* ancient it predates fuel injection (my '87 Tercel
didn't have any once the radio died. My '94 Camry has at least 4 that I know
of).
Almost anything that has a display more intelligent than wiring one end of an
LED to ground, the other to +5V (with a 5K resistor in there), and using it as
a "power on" indicator. This includes essentially all multi-segment LED and all
LCD displays.
We *could* itemize all these things, or just generalize to "anything that's
at least as smart as a microwave probably has an embedded CPU".
On Saturday 14 May 2005 17:19, [email protected] wrote:
>On Sat, 14 May 2005 21:27:11 BST, christos gentsis said:
>> Matthew Geier wrote:
>> > Embeded computing is much bigger than that. I've got a 20 year
>> > old embedded processor controlled microwave oven. (It still
>> > knows how to cook better than I do :-).
>>
>> why anyone that refer to an embedded device mean a microwave????
>
>Microwaves. Alarm clocks. Stereos. DVD players. Tivo units. Your
> car, most likely, unless it's *so* ancient it predates fuel
> injection (my '87 Tercel didn't have any once the radio died. My
> '94 Camry has at least 4 that I know of).
>
>Almost anything that has a display more intelligent than wiring one
> end of an LED to ground, the other to +5V (with a 5K resistor in
> there), and using it as a "power on" indicator. This includes
> essentially all multi-segment LED and all LCD displays.
>
>We *could* itemize all these things, or just generalize to "anything
> that's at least as smart as a microwave probably has an embedded
> CPU".
Anecdotal evidence that microwave ovens aren't exactly new, or
computerized for all their life.
I have an old Norelco thats one of the originals, a year or so newer
than an Amana Radarange. All 100% mechanical pushbuttons and a
genuine electric clock timer. Works just fine yet, probably at least
35, maybe 40 years old. I've turned the nylon bearing around that
the aluminum fan blades shaft runs in, turned slowly by another small
clock motor to 'stir' the microwaves, once. Next time the fan blade
starts dragging I'll have to go to my lathe and make another bearing
and cut another new shaft I suppose.
I'd replace it, but the last time I tried that the missus wiped the
panel down with a wet rag about a month after the warranty expired &
that was the end of that fancy computerized panel. This one refuses
to die. No use fixing what ain't broke I guess. But I did have to
replace the light bulb just recently, I think that was the third
time...
Sorry, couldn't resist correcting the impression that microwaves are
all new enough to be computerized. Tain't so, by 25 years or more.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
The easy solution is 64-bit. It is particularly easy, considering that
64-bit hardware is mainstream already. Just get an amd processor,
available in both stationary and portable models. Even micoroft
has noticed those, and linux support is old.
32-bit will hang on for a while longer in the form of old hardware,
but not likely for another 33 years.
Helge Hafting
On Fri, 13 May 2005 [email protected] wrote:
> On Fri, 13 May 2005 16:36:23 EDT, Bill Davidsen said:
>>
>>> Mon Jan 18 22:14:07 EST 2038
>>> Fri Dec 13 15:46:09 EST 1901
>> ^^^^^ are UTC and GMT that far apart? Leap seconds? WTF?
>
> The heck with leap seconds - why did it warp back to 1901 rather
> than to 1969/1970? ;)
>
Negative time. Will go as far below Unix birthdate as above. That's why
there was a suggestion in the Y2K days of changing time_t to unsigned
and biasing it off the Unix birthdate. But the pedants complained that
Unix files, created before Unix existed, would have the wrong date.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Sun, 15 May 2005, Helge Hafting wrote:
> 64-bit hardware is mainstream already. Just get an amd processor,
> available in both stationary and portable models. Even micoroft
> has noticed those, and linux support is old.
> 32-bit will hang on for a while longer in the form of old hardware,
> but not likely for another 33 years.
You don't need 64bit hardware for a 64bit time_t. 64bit time_t is
perfectly viable on 32bit platforms.
regards,
--
Paul Jakma [email protected] [email protected] Key ID: 64A2FF6A
Fortune:
bureaucracy, n:
A method for transforming energy into solid waste.