The reported incident was perhaps known to both the creators of UNIX from which LINUX decended later. The problem can be easily solved through 64-bit or higher OS versions. There is unfounded fear that how can all application softwares with millions of line of 'C' code be changed. All utilities and application programs use either proprietary or free C, C++ libraries that are shipped with all the variants of UNIX Operating Systems. So the underlying support for all the new utilities comes through new pathces of all UNIX O.S. Moreover, vendors involved in application development in C,C++ on UNIX/LINUX can always fix the problem in the regular patches they release. Year 2038 is still 32 years away. Till that time we can expect quantum jump in Hardware and O.S developments. So be cool and enjoy computing with Linux and UNIX.
That definitely is a problem..but can have a work-around like was done for y2k..
U know the date format: dd-mm-rr.the rr stands for new form of 2-digit year representation.
Elaboration: say I write date as 02-08-82.and current date is 11-05-05.
Rr treats the 50s as century boundaries, so 82 would have been treated as 2082 if we were living in 2050-2149.but if the current date is between 1950-2049, 82 would be treated as 1982.
So I guess u understand the work-around.
BUT the work-aournd is needed only if the trouble really comes into picture some day..we are rapidly switching to 64-bits..and so will the time-counter..and that would extend the roll-over interval some 2^32 times its current length which is around 70 yrs. I told the work-around, just cuz I wanted to tell abt the RR format..that really might not ever be needednor wud that be a gud soln in this case
Hi I dont think anybody is going physically and remodeling the 32 bit os for the year 2038. This is just a C limitation and by the year 2038 we will be better off using 64 + bit OS and the applications remodeled for the same. In no sense it can be related to Y2K problem.
I think back to 1999-2000, and how many doom-sayers there were. Nothing happened. Well, things did happen. As a part of regular servicing, parts were replaced. Most of the things that peopeol were worried about have regular maintenance. So do computer systems. They will be upgraded, or replaced.
Intel is already planning a 64 bit processor and with that 32-bit representation will become 64-bit representation. 2038 dead-end will become more than 2138 for Linux. Oh yea, and certainly new versions of Linux will have the bug fixed. Nobody will run a 2005 software in 2038. Do you work with Intel-8085?
Stop posting baseless crap. This certainly _is_ anti-linux promoted defamation. I appreciate linux for all good things they do.
Look, if you aren't educated on the subject, don't write about it. This is not an issue with Linux, this is an issue with any program written in C, which would include programs written on:
Mac OS Mac OS X Windows Solaris AIX SCO UNIX (I could go on and on with Unixes here.)
So why the hell do you blame this problem on Linux?
It is true that this D date is present in Linux but if we look at the date it is very very far off. Even the concerns about the embedded systems is not required. I dont think anybody would like to use the same instrument for so many years (33 years from now) keeping in view the rapid growth of hardware in past few years.
The only focus should be to fix this ASAP though the date is very very far.
