nicht angemeldet
(off-topic) Y2K 035
Da lese ich gerade wieder soviel ueber Y2K...
kaufe also schnell etwas Zwieback und Kondensmilch, Vitamintabletten (falls die Hungersnot ausbricht im Januar) :-) ... und plötzlich sagt jemand zu mir, "Tja, bei Unix reichen ja 2035 die long integer zahlen nicht mehr aus für die sekunden seit 1970...".
Schockiert über diesen angeblichen Mangel des von mir als Windows-Feind vergötterten Betriebssystems erstarre ich wie von der Medusa geschlagen...
Müssen wir 2035 (schon wieder) alle sterben? Gibt es Arbeit für Programmierer bei der Y2K035 Umrüstung? Werden möglicherweise andere sekundenzählende Mikrocontroller auch versagen? Oder funktionieren dann die meinsten Geräte schon wieder mechanisch? (Nachdem eventuell Menschen von 'Back-Orifice for Jini' -ferngesteuerten Schuhputzgeräten angegriffen worden sein werden?)
Ja. Wie ist das eigentlich. Ihr müsstet es doch wissen :-)
Bio
-
Hi,
kaufe also schnell etwas Zwieback und Kondensmilch, Vitamintabletten (falls die Hungersnot ausbricht im Januar) :-) ... und plötzlich sagt jemand zu mir, "Tja, bei Unix reichen ja 2035 die long integer zahlen nicht mehr aus für die sekunden seit 1970...".
2038, und zwar IIRC Anfang Januar. Das dürfte aber kein Problem sein, weil man bei Linux "nur mal eben schnell" die Zeit 64Bit statt 32Bit kodieren und den Kernel neu kompilieren muß. Ich schätze mal, ab etwa S.u.S.E. 7.0 (zeitlich betrachtet) dürfte das Thema keins mehr sein.
Kein Grund also, einer Sekte beizutreten und auf den Weltuntergang zu warten :-)
Cheatah
-
2038, und zwar IIRC Anfang Januar. Das dürfte aber kein Problem sein, weil man bei Linux "nur mal eben schnell" die Zeit 64Bit statt 32Bit kodieren und den Kernel neu kompilieren muß.
Hi,
das dachte ich auch mal und hatte deswegen mal in de.alt.jahr2000 nachgefragt, aber anscheinend ist das Problem doch noch etwas komplexer:
----schnipp----
Juergen Ernst Guenther schrieb am 14 Mar 1999 23:30:53 GMT:xs.bion@ndh.net (Stefan) writes:
Deshalb ist der 7.2.2036 6:28:15 GMT tragischer.
Ab dann wird naemlich das timed-Protokoll die
Hufe streichen, das uebertraegt naemlich nicht
die Zeit seit EPOCH, sondern die Zeit seit
1.1.1900 00:00:00 als unsigned 32-bit-Integer.wie gesagt (gestriges Posting), das gilt eben nur für 32-Bit-Integer.
Aber ob man in 32 Jahren noch mit 32 Bits rechnet??Wenn die Werte in C z.B. einfach nur als
int sekunden;
definiert wurden, müßte doch ein einfaches Recompilieren mit einem
64-Bit-Compiler unter einem 64-Bit-Betriebssystem ausreichen, um diese
Problematik zu lösen, oder sehe ich das falsch?Ja. Das siehst du falsch.
Das timed-Protokoll uebertraegt nur 32 bit.
Das ist _kein_ Kernel-Interna. Wuerde man es einfach
mit 64 bit kompilieren, wuerde es nicht mehr funktionieren,
da keine Gegenstellen da waeren, die das verstuenden.
Es ist in diesem Falle eben _kein_ interner Wert, sondern
eine Protokolldefinition.In 30 Jahren werden wir das Problem haben, dass es da
n verschiedene Ansaetze gibt, die teilweise sofort,
teilweise nach dem 7. 2. 2036 inkompatibel sind.Meine Hoffnungen liegen bei NTP/SNTP. Das ist zwar
wesentlich komplexer als timed, und fuer beispielsweise
diskless Workstations voellig ueberzogen, aber wenigstens
bis 2038 ok. FYI: Hier werden 64-bit-Werte uebertragen,
aber nur die obersten 32 Bit koennen Sekunden zugeordnet
werden. Wenn wir Glueck haben, sind sie uint, und damit
zumindest bis 2106 zuzuordnen..m.
Juergen Ernst Guenther
This news-posting has been powered by vi.----schnapp----
Gruß,
Stefan-
Das timed-Protokoll uebertraegt nur 32 bit.
Das ist _kein_ Kernel-Interna. Wuerde man es einfach
mit 64 bit kompilieren, wuerde es nicht mehr funktionieren,
da keine Gegenstellen da waeren, die das verstuenden.
Es ist in diesem Falle eben _kein_ interner Wert, sondern
eine Protokolldefinition.Das beweist mal wieder meine These: nicht propreritäre Betriebsysteme sind das Problem, sondern propreritätre Datenstrukturen (an die Internas bestimmter Programme gebundene Datenstrukturen). *)
Deshalb: XML, XML und nochmal XML!
*) dies gilt imho übrigens mit Einschränkungen auch für den CORBA / OMG Ansatz
-
-
-
Gibt es Arbeit für Programmierer bei der Y2K035 Umrüstung?
Oder funktionieren dann die meinsten Geräte schon wieder mechanisch?
Nun, ich schätze, daß
a) auch 2035 ettliche von-Neumann-Rechner in betrieb sein werden und
b) auf diesen U*x das meistverbreitetste Betriebssystem "klassische" sein wird (.. seit über 50 Jahren ;-)
c) daß sich nur die gaaanz alten Hacker an dieser Bude von Hobby-Programmierern aus Redmond erinnern (wie hießen die gleich "Winzigweich" oder so ähnlich)
und last not least
d) alle von-Neumann-Rechner > 64 bit sein werden.Ich weiß es nicht genau, aber durch die Umstellung auf 64 Bit wird doch auch die Y2K35 (ich dachte, es war 38 ..) im Vorfeld gelöst, ... oder bin ich mal wieder der ignorante Optimist?
-
Ich weiß es nicht genau, aber durch die Umstellung auf 64 Bit wird doch auch die Y2K35 (ich dachte, es war 38 ..) im Vorfeld gelöst, ... oder bin ich mal wieder der ignorante Optimist?
Diese Umstellung (und die Anpassung von Betriebssystem- und Standardsoftware) löst das Problem eben genau für solches Standard-Zeug.
Wenn (D)eine Firma aber eigene, proprietäre Software betreibt, die 32-bit-Datumswerte speichert, muß sie das Problem selbst lösen.
-
-
Hi!
Der Y2K-Bug wurde gesichtet:
<img src="http://www.infa.tuwien.ac.at/images/Y2kbug.jpg" alt="">
;-)
mfG
BRAND -
Hi Bio,
das Problem ist der time_t Datentyp, in dem die Sekunden seit 1970 (oder so) gespeichert sind. Benutzt wird es von den Funktionen time (Holt die Systemzeit) und mktime (Konvertiert die Zeit). Zuschlagen wird der Bug am 18.1.2038, und das nicht nur unter Unix. Es ist ein Typ definiert in ANSI-C, es betrifft alle Programme in C oder C++, die direkt oder indirekt diesen Datentype verwenden. Auch Windows.
Falls jemand unter Windows mit der MFC programmiert: tm wird in CTime verwendet, also auch hier Obacht. Eine Lösung ist es die Strukturen des Systems zu verwenden, oder COleDateTime.
Zwei Links zum Thema: http://msdn.microsoft.com/library/welcome/dsmsdn/msdn_090798a.htm und http://msdn.microsoft.com/library/welcome/dsmsdn/msdn_093098a.htm, zusätzlich kann man auch das Archiv nach 2038 durchsuchen ;-)
Gruss,
Martin