Slo-Tech - Naslednji računalniški konec sveta bo leta 2038, ko se bo 19. januarja iztekel Unixov čas. Vse od začetka Linux čas shranjujejo kot predznačeno 32-bitno število, ki je 1. januarja 1970 ob polnoči znašalo natanko 0. Natanko 231 sekund pozneje bo spremenljivka time_t dosegla najvišjo možno vrednost, nato pa bo skočila nazaj na začetek. To predstavlja težavo, ki se je razvijalci dobro zavedajo in jo bodo v novi verziji Linuxovega jedra rešili.
V Linuxu 5.6 bo spremenljivka time_t 64-bitna tudi v 32-bitni inačici jedra, torej tudi v musl-1.2 in glibc-2.32. To pomeni, da bodo aplikacije, ki bodo to razumele, pravilno delovale tudi po letu 2038. Programi, ki neposredno kličejo sistemske funkcije, bodo morali uporabljati sistemske klice time64, ki so bili dodani v jedru 5.1. Kjer 64-bitne spremenljivke time_t ne bo možno uporabiti, bodo programi morali uporabiti CLOCK_MONOTONIC.
Večina že dandanes uporablja 64-bitne sisteme, kjer je time_t 64-biten in težave ne bo (oziroma bo v letu 29.227.702.659). A od leta 2000 smo se naučili, da sistemi, za katere smo prepričani o zamenjavi v doglednem času, pogosto trmasto ostanejo desetletja. Zlasti pri vgradnih (embedded) sistemih je 32-bitnih verzij Linuxa še res veliko in ti še danes čas zapisujejo v 32-bitni predznačeni celoštevilski spremenljivki. Od jedra 5.6 ga bodo v 64-bitni.
Najbrž so računali, da bomo v letu 2038 že vsi surfali po galaksiji z kvantnimi računalniki, pa so rekli "eh, what the heck škoda časa za implementacijo".
There will be chutes!
It came from the lab.
Like tears in rain. Time to die. v_1 2012-21
Nič niso računali. registri so bili samo 32 bitni in zato se je uporabilo obstoječe zadeve. Sicer pa še vedno velja, da rešiš problem za 50 let, potem te pa itak ne bo več v službi ali pa boš že mrtev in naj se s tem ukvarjajo mlajši rodovi.
Hm... a kar isti time_t bo zdaj 64-biten?! A niso s tem podrli kompatibilnost za nazaj s celotnim ABIjem jedra?
time_t je 64-biten že dolgo na vseh 64-bit OSih. Na 32-bit OSih pa se itak pogovarjaš z glibc in musl in ne s kernelom. Tako da moraš gledati njihove spremembe - glibc ima idejo da bi time_t zamenjal samo za novo prevedene programe, musl pa je mnenja da je treba čimprej polomiti software in prisiliti maintainerje da se zmigajo do 2038.
Najbrž so računali, da bomo v letu 2038 že vsi surfali po galaksiji z kvantnimi računalniki, pa so rekli "eh, what the heck škoda časa za implementacijo".
V sedemdesetih, ko so prvič počeli te reči, je bil bit precej dražji. Vem, nepismeni in neizobraženi razvajenci si te reči težko predstavljate, morda si pa lahko razširite obzorja.
Vse od začetka Linux čas shranjujejo kot predznačeno 32-bitno število, ki je 1. januarja 1970 ob polnoči znašalo natanko 0. Natanko 231 sekund pozneje bo spremenljivka time_t dosegla najvišjo možno vrednost, nato pa bo skočila nazaj na začetek.
Po eni strani omenjas vrednost 0 kot zacetno, po drugi strani pa integer overflow predznacenega stevila. To dvoje ne gre skupaj.
Skocila bo na najbolj negativno mozno vrednost (kar z offsetom 1. 1. 1970 pomeni nekam na zacetek 20. stoletja) in ne na zacetek (0; kjer je bila 1. 1. 1970).
Nekako jih razumem, ker so imeli čas do 2038. Ampak bi si lahko že tedaj izmislili neko rudimentalno podatkovno strukturo za zapis časa, ki te omejitve ne bi imela.
Tedaj je večina mislila, da je zapis leta kot "99" več kot dovolj. Sploh, ker je (kot že omenjeno) vsak bit bil drag (malo poglej, koliko so takrat koštali pomnilniki).
Motiti se je človeško.
Motiti se pogosto je neumno.
Vztrajati pri zmoti je... oh, pozdravljen!
aja, sem že mislil da bo takrat linux prenehal obstajat...
"Namreč, da gre ta družba počasi v norost in da je vse, kar mi gledamo,
visoko organizirana bebavost, do podrobnosti izdelana idiotija."
Psiholog HUBERT POŽARNIK, v Oni, o smiselnosti moderne družbe...
