Wie beim Y2K-Bug, der daraus resultierte, dass viele Programme Jahreszahlen nur zwei- statt vierstellig verarbeiteten, sorgt die Sparmentalität, die bei den Programmierern im letzten Jahrhundert aufgrund vergleichsweise hoher Speicher- und Medienkosten verbreitet war, auch in Zukunft für Schreckensszenarien.
Ich seh dem Datum aus zwei Gründen gelassen entgegen: zum einen ist dank dieses Bugs fast sichergestellt, dass ich auch im hohen Alter noch eine Möglichkeit habe, mir ein Zubrot als Y2K38-Fixer auf den dann noch im Betrieb befindlichen Legacy-Unix-Systemen zu verdienen, zum anderen liegt das Datum dann wenigstens so, dass ich Sylvester 2037 genießen kann... den Abend des 31. Dezember 1999 hab ich nämlich damit verbracht, vor einem Rechner den Weltuntergang zu erwarten (nicht aus Überzeugung, sondern dienstlich in meiner Funktion als Qualitätssicherer und Y2K-Beauftragter bei einem aufstrebenden ISP). Na, dafür ist damals wenigstens ein Diensthändi abgefallen.
Was ich allerdings nicht erwartet hätte, ist, dass der Bug sich jetzt schon bemerkbar macht. The Daily WTF berichtet vom ersten Auftreten in der freien Wildbahn (via Schneier on Security):
The system that crashed was a vendor application and failed as a result of the database shutting down. Easy enough to fix, Casper restarted the database. It came back up, then went down again. He restarted it again, it came up, then went down. Up, down, up, down. The log files revealed the problem was in the vendor’s startup script, which went something like this:
start oracle
sleep 1000000000
stop oracle
Mehr Info zum Jahr-2038-Problem.
