În 2000, bug-ul Y2K a venit și a trecut fără prea multe probleme. În ciuda previziunilor de eșec generalizat, criza a fost evitată atât prin planificarea și intervenția pe termen lung, cât și prin intervenția de ultim moment, și niciun sistem critic nu a cedat. În anii care au trecut de atunci, acele câteva sisteme de operare și aplicații care au fost afectate au fost, în majoritatea cazurilor, actualizate, înlocuite sau retrase.
Dacă folosiți un sistem bazat pe Unix sau Linux, mai există un bug legat de date de care va trebui să vă faceți griji – în anul 2038.
Toate sistemele pe 32 de biți bazate pe Unix/Linux stochează intern ora ceasului de sistem ca număr de secunde de la Epoch, sau 00:00:00:00 la 1 ianuarie 1970. Acest tip de date interne, time_t, este, în majoritatea cazurilor, un întreg cu semn pe 32 de biți (4 octeți). Dacă sistemul în cauză respectă standardul POSIX (așa cum o fac majoritatea sistemelor Unix și Linux), cea mai recentă oră și dată care pot fi reprezentate ca secunde de la Epoch în acel întreg cu semn pe 32 de biți este 3:14:07 UTC marți, 19 ianuarie 2038.
După această oră și dată, reprezentarea internă a timpului sistemului va ajunge la 2147483647, cel mai mare număr stocabil într-un întreg cu semn pe 32 de biți. La o secundă după aceea, se va ajunge la un număr negativ, -2147483648. Aplicațiile actuale fie vor interpreta acest număr negativ ca fiind un an mai vechi (1901), fie vor îngheța ceasul de sistem la 03:14:07 pe 1/19/2038. Acest lucru va provoca, eventual, eșecul aplicațiilor și al sistemelor de operare, deoarece acestea nu sunt proiectate să funcționeze cu un ceas de sistem blocat sau cu unul care arată anul 1901.
Nu există soluții viabile (care să nu strice aplicațiile existente) pentru sistemele care utilizează procesoare pe 32 de biți sau pentru sistemele de operare și aplicațiile care rulează în modul pe 32 de biți pe procesoare pe 64 de biți. Multe sisteme de operare Unix/Linux actuale rulează deja în modul pe 64 de biți (cu un time_t „lung” corespunzător atunci când funcționează pe un procesor pe 64 de biți; în cele mai multe cazuri, acest lucru rezolvă problema.
Sistemele de operare care acceptă un time_t lung pe 64 de biți nu sunt, cel mai probabil, afectate de bug-ul Anul 2038 în ceea ce privește ceasul intern al sistemului. Cu toate acestea, aplicațiile care utilizează un time_t pe 32 de biți pot eșua în continuare, chiar dacă sistemul care rulează aplicația suportă funcționarea completă pe 64 de biți.
Iată o scurtă trecere în revistă a stadiului actual al suportului Unix 2038 în principalele versiuni Unix/Linux:
- Solaris 7 sau superior pe procesoarele UltraSPARC și SPARC64 pe 64 de biți, precum și Solaris 10 pe platformele x86-64, are un time_t pe 64 de biți.
- AIX versiunea 4.3.3 pe procesoare PowerPC și Power pe 64 de biți are un time_t pe 64 de biți.
- Kernelul Linux care rulează în modul pe 64 de biți pe procesoare IA64 sau x86-64 are un time_t pe 64 de biți.
- Mac OS X versiunea 10.4 și cele mai noi au un kernel pe 32 de biți, dar aplicațiile pot folosi un time_t pe 64 de biți atunci când rulează pe procesoare PowerPC G5 sau x86-64.
- FreeBSD 6.0 și versiunile ulterioare au un time_t pe 64 de biți atunci când rulează pe o platformă pe 64 de biți.
- OpenBSD 4.1 și mai noi suportă un time_t pe 64 de biți.
- NetBSD nu are încă un time_t pe 64 de biți, dar se fac eforturi pentru a rezolva problema pentru o versiune viitoare.
Chiar dacă sistemul dvs. de operare actual nu este încă sigur pentru Unix 2038, nu vă faceți griji! Oamenii sunt conștienți de această problemă de mulți ani și lucrează activ la soluții. În cele mai multe cazuri, problema va fi rezolvată prin faptul că sistemul de operare și aplicațiile vor rula în cele din urmă în modul complet pe 64 de biți.
Aștept ca toate sistemele majore de operare desktop să fie complet pe 64 de biți în următorii cinci până la zece ani. În plus, un efect de „trickle down” va ajuta la înlocuirea sistemelor actuale cu configurații pe 64 de biți acolo unde este aplicabil și rentabil.
Despre autor: Bill Bradford este creatorul și întreținătorul SunHELP și locuiește în Houston, Texas, împreună cu soția sa Amy.
.