|
||||
2038.
Hiya.
Remember Y2K? Apparently POSIX has something better in store. It's probably not news to a programmer but I found it interesting. http://en.wikipedia.org/wiki/Year_2038_problem http://www.2038bug.com/ Quote:
I particularly like the FAQ page: http://www.2038bug.com/faq.html Time to buy more tinfoil. Best wishes. Last edited by diw; 27th March 2009 at 03:10 PM. Reason: Fixed superscript - 2³¹. |
|
|||
This is a well know problem, I suspect anyone using Unix for more then a year knows of it.
I suspect that when the decision was made to use a signed 32-bit integer for time_t, larger types were either unavailable or inefficient.. These days, some systems are switching to a signed 64-bit integer.. using an unsigned 32-bit integer would have caused considerable compatibility issues, like the inability to express time before the Unix epoch. OpenBSD still uses a signed 32-bit integer, which really won't be a problem.. they still have ~29 years until it'll be worth fixing. It just goes to show that the developers of Unix never expected people would be using it decades later.. 2038 in the 1970's is like, flying cars and aliens with super computers the size of a freckle. I'm not worried about this problem yet, I don't create any cron/at jobs that far into the future.. and, my pocket schedule isn't that well planned out. Take care. |
|
|||
Note; the designers of POSIX.1-2008 didn't address this issue either.. they simply state that time_t and clock_t shall be integer or real-floating types.
With operating systems like OpenBSD, 3rd party packages aren't usually in the wild.. when the change to a 64-bit time_t occurs, it won't be much of a problem.. for some things it'll be as simple as recompiling, others may only be slightly more involved. |
|
|||
Is it sad that I hope we still are?
|
|
||||
Hmm, I always thought what happened on integer overflow was purely a hardware dependent thing. (which I always hoped rolls over or segfaults on the majority of architectures lol)
I would reckon at the time, 32-bit integers would have been like picking a 64-bit integer today: be happy if you have it available, but don't bet on it to be a chorts.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. Last edited by TerryP; 27th March 2009 at 07:50 PM. |
|
|||
Quote:
The BSD's have evolved from being just a set of patches to AT&T's version(s) to a splintered assortment of open source projects which address the needs of those developing/extending them & their surrounding user communities. There is nothing stated that these operating systems will not continue to evolve as needs change & new technologies arise. In fact, the developers within the *BSD communities seem energized to adapt the source base to new problems/needs/technologies. What can be said with certainty is if the community does not continue to adapt, we won't be running Unix in 2038. |
|
||||
Of course not.
As long as we can still run without X how bad could it be? It is sad that the hardware doesn't age like cool bikes and cars. Everybody cranes their heads when a World War II vintage Harley Davidson goes putt putting down the road on a quiet saturday afternoon. It would be so nice for old 386s to be like that 20 years from now. "Ooh. Look. No fan!" "Yes. That's a genuine SGI sonny. Ahh. When I was a lad ..." I suppose that's the main reason that support for older architectures can be eventually dropped - attrition finally gets the most diehard machines. As long as the BSDs keep moving with the hardware (no matter how hard it is ) we should be fine. Best wishes. |
|
||||
Quote:
Perhaps they will become like one of those large corporations that used to be big in some other unrelated industry that nobody knows about. A move from software to cosmetics sounds okay. Best wishes. |
|
||||
Reading about porting NetBSD to a quantum computer ought to be interesting someday, if any of us are still alive.
__________________
My Journal Thou shalt check the array bounds of all strings (indeed, all arrays), for surely where thou typest ``foo'' someone someday shall type ``supercalifragilisticexpialidocious''. |
|
|||
About 3 years ago, I had said that Microsoft would not matter anymore in 5-10 years. Not saying they would be out of business. I meant programs would be written where MS would not be the goto company as to how things would work. Since then, Paul Graham and Wired both wrote articles saying the same thing. (I'm a genius!)
With the decline of Internet Explorer and all the "cloud computing" talk, along with the rise of Google, and even Amazon and others in this area, I stand by that statement. I do believe Unix and its variants will still be standing in 2038 but, of course, with all the improvements one would expect. It will be the machine that keeps on ticking and the preferred platform for all things. |
|
||||
Quote:
I figured Apple would rise and rise ... Unfortunately they seem to be too expensive for many. Please try the batch file in your Windows print thread. The suspense is killing me. Best wishes. |
|
|||
I didn't see your post over there. I'll make my comments there.
|
|
|||
By 2038 we'll probably already be moving beyond 64-bit.
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14) |
|
|||
Really? Why? I seriously doubt we'll need systems with >= 16384 Petabytes of memory.
There was an article about this somewhere, but.. 128-bit is probably the end of the line. |
|
|||
Quote:
Time will tell.
__________________
And the WORD was made flesh, and dwelt among us. (John 1:14) |
Tags |
2038, unix millenium bug, y2k38 |
Thread Tools | |
Display Modes | |
|
|