openSuSE a problem roku 2030

[darkhog]

Czytałem gdzieś że w okolicach roku 2030 we wszystkich unixowych systemach (a więc i w linuksie) przekręcą się zegary, gdyż jest to zapisywane jako liczba sekund od roku 1970 albo 72, nie pamiętam dokładnie. I stąd moje pytanie - czy openSuSE 11.2 jest odporny na ten problem?

[Małolat]

Martwisz się teraz co będzie w 2030 roku? Współczuję chłopie...

Nie masz się co bać, coś takiego raczej się nie stanie


PS masz zamiar używać 11.2 tak długo?

PS2 znalazłem coś o co CI chodziło:

http://en.wikipedia.org/wiki/Year_2038_problem

[Paweł Kraszewski]

Właśnie przez taką mentalność jak Małolata były (między innymi) następujące problemy:
* rok 2000
* rok 2038
* Różne limity rozmiarów dysku twardego (łącznie z najnowszym 2TB)
* Hocki-klocki z adresacją w systemach 16-bitowych, różne dziwne "łatki" w systemach 32-bitowych (PAE, Giant Pages)

O ile problemy typu limit dysku wymagają "tylko" zmiany BIOSa i ewentualnie poprawki sterowników dysku, to problemy związane ze strukturą danych (przede wszystkim pole daty/czasu) sprawiają kosmiczne problemy i koszty przy migracji danych i oprogramowania.

Problem 2038 dotknie nas szybciej, niż w roku 2038... Często trzeba używać dat "z przyszłości" (np. terminy wygaśnięcia polis, gwarancji, terminy przedawnienia certyfikatów). Te ostatnie mają często karencje rzędu 10 lat, więc problemy mogą pojawić się już w ciągu 18 lat... Albo i wcześniej...

Jednym z podstawowych grzechów projektantów struktur danych są niedocenienie szybkości rozwoju sprzętu ("nikt przecież nie zrobi dysku >504MB osiągalnego cenowo dla zwykłego człowieka"), przyrostu rozmiaru danych ("Przecież nie będziemy potrzebowali więcej niż 16 milionów kont GG!") oraz niedocenianie czasu życia ustanawianego standardu ("przecież za 20 lat nikt nie będzie już korzystał z plików DBF!").

Podsumowując: Nie chciałbym używać dłużej komercyjnie oprogramowania projektowanego przez ludków z podejściem Małolata...

[darkhog]

A wystarczyło by stworzyć klasę która może przechowywać nieskończoną liczbę (wiem, że tak można zrobić, bo np. Ruby może operować na zmiennych liczbowych o nieskończonej wielkości)

Wystarczy adresowanie 64-bitowe, a przy obecnym tempie rozwoju sprzętu niedługo o czystym x86 wszyscy zapomną i problem z głowy (Linux ma o tyle lepiej, że większość oprogramowania na "rynku" ma wersje x86_64 i już na takie daty jest ono odporne).
Faktem jest jednak stwierdzenie, że wielu projektantów czy to oprogramowania, czy sprzętu ma bardzo płytkie myślenie, przez co powstaje masa prowizorki, którą potem trzeba łatać. Moim zdaniem jednak tak będzie zawsze, bo po prostu mniej = taniej i ludzie oszczędzają jak mogą, zwłaszcza, jeżeli przewidywania nie są zbyt wygórowane.