Hans Klein <hansi.klein@net-con.net> wrote:
Tuesday, January 19th 2038, 03:14:07 UTC: Are YOU Ready?
No, I'm not, but I think [translate] das noch rechtzeitig ein Kernel rauskommt, mit dem man sicher ist.
Kernel allein reicht nicht. Auch libc und alle Anwendungen muessen mitmachen.
da sollte man aber langsam anfangen, damits nicht wieder eng wird, anfang 2038 !
Das Problem liegt ja darin, dass in Linux bzw. Unix die Zeit intern in Sekunden seit dem 01.01.1970, 0.00 Uhr gezaehlt wird. Dazu werden bisher vorzeichenbehaftete 32-Bit-Zahlen genutzt -- zu dem genannten Zeitpunkt ist bei denen Schluss. Haette man statt dessen z.B. einen 64-Bit-Zaehler, waere erstmal fuer die naechsten knapp 300 Milliarden Jahre Ruhe. In 38 Jahren werden 64-Bit-Maschinen laengst ueberholt sein, der Zaehler wird lange vorher vergroessert und alle Programme werden bis dahin etliche Male neu kompiliert worden sein (schon allein wegen neuer Prozessoren). Man muss nur irgendwann den entsprechenden Datentyp time_t (den natuerlich jeder Programmierer fuer die Systemzeit verwenden sollte...) aendern. Naheliegenderweise koennte man das vielleicht einfach bei der Portierung auf neue Hardware mit erledigen, wenn ohnehin alles (Kernel, Bibliotheken, Anwendungen) neu kompiliert werden muss. Ich denke, es wird in 38 Jahren keine gravierenden Probleme mehr dadurch geben, weil die sich (bei ordentlicher Programmierung) bis dahin grossenteils "von selbst" loesen werden. Es geht ja anders als bei dem Y2K-Problem (ausdrueckliche Entscheidung fuer zweistellige Jahreszahlen; voelliges Verlassen auf dieses Datumsformat...) nicht um ein grundsaetzliches Darstellungsproblem, sondern nur um die Breite einer Variable. Im Idealfall (vielleicht gibt's Probleme bei unsauber programmierten Anwendungen) kann man die Loesung weitestgehend den Compilern ueberlassen. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Eilert Brinkmann schrieb am 03.01.2000 um 19:47:58 +0100: Hallo Eilert,
Hans Klein <hansi.klein@net-con.net> wrote:
Tuesday, January 19th 2038, 03:14:07 UTC: Are YOU Ready?
No, I'm not, but I think [translate] das noch rechtzeitig ein Kernel rauskommt, mit dem man sicher ist.
Kernel allein reicht nicht. Auch libc und alle Anwendungen muessen mitmachen.
da sollte man aber langsam anfangen, damits nicht wieder eng wird, anfang 2038 !
Das Problem liegt ja darin, dass in Linux bzw. Unix die Zeit intern in Sekunden seit dem 01.01.1970, 0.00 Uhr gezaehlt wird. Dazu werden bisher vorzeichenbehaftete 32-Bit-Zahlen genutzt -- zu dem genannten Zeitpunkt ist bei denen Schluss. Haette man statt dessen z.B. einen 64-Bit-Zaehler, waere erstmal fuer die naechsten knapp 300 Milliarden Jahre Ruhe.
eit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor. Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. Wer zweifelt mit? Bis denne, Michael -- "Bootsie!" "Yeah, Bootsie's cool. Huh, huhhuhuh." "Bootsie! He's from outer space. Heh, henh, henh, henh." Beavis & Butthead --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Michael Schulz wrote:
seit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor. Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. Wer zweifelt mit?
Ich nicht ;-) Wenn wir eins aus dem Y2k-Problem gelernt haben dann das, daß man sich nicht darauf verlassen soll, daß sich die Probleme von selbst lösen. Das Problem hat IMHO nichts mit der Bitbreite der CPU zu tun (zB die 32Bit-CPU Intel Pentium mit MMX hat 64 Bit, MMX eben), sondern ist lediglich ein Problem, der darstellung im Speicher. Sobald Zeitpunkte in Datenbständen (also nicht Programme, sondern Nutzdaten) als 32Bit-Werte (in sec seit 1.1.1970) abgelegt sind, kann es zu Problemen kommen. Dieses Problem ist überschaubar und in 38 Jahren sicherlich leicht zu lösen. Gruß Raphael Becker -- Online-Doku: http://home.pages.de/~online-doku Gesucht - Gefunden: Linux-Anleitungen Fehlt was? Dann nix wie her mit dem URL mailto:online-doku@gmx.de --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, Raphael Becker wrote:
Sobald Zeitpunkte in Datenbständen (also nicht Programme, sondern Nutzdaten) als 32Bit-Werte (in sec seit 1.1.1970) abgelegt sind, kann es zu Problemen kommen. Dieses Problem ist überschaubar und in 38 Jahren sicherlich leicht zu lösen.
Aber nur, wenn man sich auch drum kuemmert und nicht alles dem zufall oder anderen leuten ueberlaesst. Hat hier eigentlich jemand (ausser mir ;-) ) mal im alten Jahrtausend seine Kiste auf 2000 gestellt und mal gekuckt was so passiert ? IMHO, wenn das mehrere gemacht haetten waere das Geschrei schon vorher losgegangen. Sich aber jetzt wundern ... naja ... -- MfG, M.Stahn + The WWW is exciting because Microsoft doesn't own it, and therefore,+ + there's a tremendous amount of innovation happening. -- Steve Jobs + --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Raphael Becker schrieb am 04.01.2000 um 13:01:39 +0100: Hallo Raphael,
Michael Schulz wrote:
seit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor. Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. Wer zweifelt mit?
Ich nicht ;-)
Wenn wir eins aus dem Y2k-Problem gelernt haben dann das, daß man sich nicht darauf verlassen soll, daß sich die Probleme von selbst lösen.
Das Problem hat IMHO nichts mit der Bitbreite der CPU zu tun (zB die 32Bit-CPU Intel Pentium mit MMX hat 64 Bit, MMX eben), sondern ist lediglich ein Problem, der darstellung im Speicher.
Vielleicht falsch ausgedrückt. main() { printf("%d %d\n",sizeof(int),sizeof(long int)); } ergibt auf Intel: 4 4 ergibt auf Alpha: 4 8 Bis denne, Michael -- B: Now we're getting somewhere. BH: It's like you can say what you want about Maiden, but when it comes to making videos they don't screw around. (Beavis and Butthead about Iron Maiden Fear of the Dark: 'From here to eternity') --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On Mon, 03 Jan 2000, Eilert Brinkmann wrote:
Ich denke, es wird in 38 Jahren keine gravierenden Probleme mehr dadurch geben, weil die sich (bei ordentlicher Programmierung) bis dahin grossenteils "von selbst" loesen werden. Es geht ja anders als
Und genau das haben die Entwickler (diejenigen, die das Problem auch damals schon erkannt haben) nämlich auch geglaubt :-) Carsten --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, Eilert schrieb:
Das Problem liegt ja darin, dass in Linux bzw. Unix die Zeit intern in Sekunden seit dem 01.01.1970, 0.00 Uhr gezaehlt wird.
Ich dachte erst MIllisekunden...
Dazu werden bisher vorzeichenbehaftete 32-Bit-Zahlen genutzt -- zu dem genannten Zeitpunkt ist bei denen Schluss. Haette man statt dessen z.B. einen 64-Bit-Zaehler, waere erstmal fuer die naechsten knapp 300 Milliarden Jahre Ruhe.
Wartum eigentlich nicht. Sind ja schliesslich letztendlich nur 64 1en bzw 0en, also 8 Byte --- wenn ich von den ganzen Zeugs mehr Ahnung hätte, würde ich intelligentere Sätze loslassen...
In 38 Jahren werden 64-Bit-Maschinen laengst ueberholt sein, der Zaehler wird lange vorher vergroessert und alle Programme werden bis dahin etliche Male neu kompiliert worden sein (schon allein wegen neuer Prozessoren).
In 38 Jahren ist es aber schon zu spät.... Nur was passiert, wenn die Zahl erreicht ist? Abstürzen garantiert nicht. Es ist geradezu absurd, dass alles nur wegen der Zeit hängren bleibt. Bei mir falle ich immmer wieder aufs alte Datum zurück, dh. die Zeit bleibt stehen--- Michael Schulz schrieb:
seit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor.
*heul* Ich will auch in 38 Jahren nicht auf meinen heißgeliebten 486er DX 4 mit 100 MHz verzichten :-(
Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal.
da ist sowas antik... (Deswegen behalte ich ja meinen 8087, meine beiden 286, meinen 386 SX und meinen 486DX4) Ich bezweifle aber, das es da noch Steckplätz für diese geben wird... Hans Klein:
PS: wenn der Thread OT wird sagts einer ;-)
Glaub, das isser... Trotzdem, man kann das Problem ja auch ohne die Erweiterung des Datentyps (oder wie das in korrekter Programmierersprache heiszt) man brauch IMHO den Zähler doch nur von 1.1.2000 0:00 Uhr zählen lassen, und dann jhat sich das bei 32-Bit Systemen auch erstmal wieder rund 67 Jahre gelegt... ODer liege ich da falsch? ciaociao Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
On 04-Jan-00 Stephan Beyer wrote:
Dazu werden bisher vorzeichenbehaftete 32-Bit-Zahlen genutzt -- zu dem genannten Zeitpunkt ist bei denen Schluss. Haette man statt dessen z.B. einen 64-Bit-Zaehler, waere erstmal fuer die naechsten knapp 300 Milliarden Jahre Ruhe. Wartum eigentlich nicht. Sind ja schliesslich letztendlich nur 64 1en bzw 0en, also 8 Byte --- wenn ich von den ganzen Zeugs mehr Ahnung hätte, würde ich intelligentere Sätze loslassen...
Weil 32 Bit zu der Zeit, als Unix konstruiert wurde, die übliche Wortlänge der benutzten (damals noch recht "großen") Maschinen war. Das heißt, 32 Bit war die Breite, die die Hardware optimal schnell verarbeiten konnte. Und Speicherplatz war auch noch nicht so wertlos wie heute (binäre Darstellungen sind diesbezüglich effizienter als z.B. BCD-Codierung).
In 38 Jahren werden 64-Bit-Maschinen laengst ueberholt sein, der Zaehler wird lange vorher vergroessert und alle Programme werden bis dahin etliche Male neu kompiliert worden sein (schon allein wegen neuer Prozessoren).
In 38 Jahren ist es aber schon zu spät.... Nur was passiert, wenn die Zahl erreicht ist? Abstürzen garantiert nicht. Es ist geradezu absurd, dass alles nur wegen der Zeit hängren bleibt. Bei mir falle ich immmer wieder aufs alte Datum zurück, dh. die Zeit bleibt stehen---
Das hängt davon ab, was mit dem Datum gemacht wird. Wird das Datum einfach nur gespeichert und wieder ausgegeben und weiß man, wie man diese Ausgabe interpretieren muß, dann ist das ja auch bei 2 Dezimalstellen kein Problem. Schwierig wird es, wenn verschiedene Datumsangaben verglichen oder Differenzen gebildet werden (dann bist Du z.B. auf einmal 100 Jahre oder auch 68 Jahre mit Mahngebühren in Verzug <g>).
Michael Schulz schrieb:
seit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor. *heul* Ich will auch in 38 Jahren nicht auf meinen heißgeliebten 486er DX 4 mit 100 MHz verzichten :-(
Kein Problem. time_t als long long definieren und alles (Kernel, libc, Anwendungen, ...) neu compilieren.
Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal. da ist sowas antik... (Deswegen behalte ich ja meinen 8087, meine beiden 286, meinen 386 SX und meinen 486DX4) Ich bezweifle aber, das es da noch Steckplätz für diese geben wird...
Trotzdem, man kann das Problem ja auch ohne die Erweiterung des Datentyps (oder wie das in korrekter Programmierersprache heiszt) man brauch IMHO den Zähler doch nur von 1.1.2000 0:00 Uhr zählen lassen, und dann jhat sich das bei 32-Bit Systemen auch erstmal wieder rund 67 Jahre gelegt... ODer liege ich da falsch?
Dazu müßte man alle Programme, die diese Angabe interpretieren, entsprechend verändern. Der Aufwand ist wesentlich größer, und Neucompilieren des gesamten Systems ist genauso angesagt. -- Erhard Schwenk <eschwenk@fto.de> - http://www.fto.de **** Jetzt neu: http://www.akkordeonjugend.de **** --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Stephan Beyer wrote:
Hi,
Eilert schrieb:
Das Problem liegt ja darin, dass in Linux bzw. Unix die Zeit intern in Sekunden seit dem 01.01.1970, 0.00 Uhr gezaehlt wird.
Ich dachte erst MIllisekunden...
Tja, so kann man sich täuschen. Mit Millisekunden hätte der Spaß ganze 24 Tage 20 Stunden und knapp 32 Minuten gehalten ...
Dazu werden bisher vorzeichenbehaftete 32-Bit-Zahlen genutzt -- zu dem genannten Zeitpunkt ist bei denen Schluss. Haette man statt dessen z.B. einen 64-Bit-Zaehler, waere erstmal fuer die naechsten knapp 300 Milliarden Jahre Ruhe.
Wartum eigentlich nicht. Sind ja schliesslich letztendlich nur 64 1en bzw 0en, also 8 Byte --- wenn ich von den ganzen Zeugs mehr Ahnung hätte, würde ich intelligentere Sätze loslassen...
In 38 Jahren werden 64-Bit-Maschinen laengst ueberholt sein, der Zaehler wird lange vorher vergroessert und alle Programme werden bis dahin etliche Male neu kompiliert worden sein (schon allein wegen neuer Prozessoren).
In 38 Jahren ist es aber schon zu spät....
Naja, zwei Wochen haben wir dann noch Zeit ;-)
Nur was passiert, wenn die Zahl erreicht ist? Abstürzen garantiert nicht. Es ist geradezu absurd, dass alles nur wegen der Zeit hängren bleibt. Bei mir falle ich immmer wieder aufs alte Datum zurück, dh. die Zeit bleibt stehen--- Nun ja, meinst Du mit Abstürzen den ganzen Rechner oder nur Anwendungen?
Michael Schulz schrieb:
seit glibc 2.1 ist das immerhin schon ein long. Also gilt das Problem nur noch für 32bit Prozessoren. Alle 64-bittigen sind seitdem aussen vor.
*heul* Ich will auch in 38 Jahren nicht auf meinen heißgeliebten 486er DX 4 mit 100 MHz verzichten :-( Mußt Du ja auch nicht. Du must nur dafür sorgen, daß die Zeiten intern in längeren Variablen abgespeichert werden.
Und ob es in 38 Jahren noch sowas gibt. Ich zweifel mal.
da ist sowas antik... (Deswegen behalte ich ja meinen 8087, meine beiden 286, meinen 386 SX und meinen 486DX4) Ich bezweifle aber, das es da noch Steckplätz für diese geben wird...
Hans Klein:
PS: wenn der Thread OT wird sagts einer ;-) Vermutlich in 38 Jahren ;-)
Glaub, das isser...
Trotzdem, man kann das Problem ja auch ohne die Erweiterung des Datentyps (oder wie das in korrekter Programmierersprache heiszt) man brauch IMHO den Zähler doch nur von 1.1.2000 0:00 Uhr zählen lassen, und dann jhat sich das bei 32-Bit Systemen auch erstmal wieder rund 67 Jahre gelegt... ODer liege ich da falsch? Das würde aber gleichzeitig bedeuten, daß Du die Zeiten auch umrechnen mußt. Es reicht also nicht, einfach nur einen Datentypwechsel durchzuführen, der IMHO schneller ablaufen dürfte (insbesondere von int nach long). Außerdem must Du dann auch die Berechnung des Datum umstellen. Die müßte man jedoch unangetastet lassen können, wenn nur der Datentyp geändert wird.
-- Heiner Lamprecht Philosophenweg 79 D - 72076 Tuebingen email: heiner@kijumfo.de http://www.kijumfo.de GnuKontor: http://agenda21.ggi.uni-tuebingen.de/heiner/gk/ KFLog: http://agenda21.ggi.uni-tuebingen.de/heiner/kflog/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hi, Eilert! Trying to kill the keyboard, Eilert Brinkmann (eilert@Informatik.Uni-Bremen.DE) produced 2,3K in 45 lines:
In 38 Jahren werden 64-Bit-Maschinen laengst ueberholt sein,
640 K sollten fuer jeden reichen ... auch heute werden 8-Bitter eingesetzt.
Man muss nur irgendwann den entsprechenden Datentyp time_t (den natuerlich jeder Programmierer fuer die Systemzeit verwenden sollte...) aendern.
Ja. Und das macht keinen Unterschied, ob das dann auf 8-Bit- oder auf 8-KBit-Maschinen laeuft. (auch 32-bit Maschinen koennen long long verstehen.) -Wolfgang --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (9)
-
beckerra＠rumms.uni-mannheim.de -
cmeyer＠mail.com -
eilert＠informatik.uni-bremen.de -
eschwenk＠fto.de -
heiner＠kijumfo.de -
martin.stahn＠sskm.de -
micha28＠gmx.de -
PH-Linex＠gmx.net -
weissel＠ph-cip.uni-koeln.de