Cu câteva zile în urmă, la cumpăna anilor, am serbat o aniversare ciudată. Au trecut 25 de ani de la un eveniment sau non-eveniment care se anunța a fi apocaliptic. Este vorba despre noaptea în care omenirea a trecut din anul 1999 în anul 2000. În acea noapte s-ar fi putut petrece catastrofe de proporții: avioane care cad din cer, centrale nucleare care ies de sub control, baze de date care sunt șterse instantaneu, conturi bancare care dispar ca și cum nu ar fi existat, rețele de telefonie și comunicații digitale care încetează să funcționeze, sisteme de transport paralizate și încă tot ceea ce vă puteți imagina rău, cu condiția să fie vorba despre aparate sau instituții acționate, controlate, comandate sau bazate pe calculatoare numerice. Prevederile apocaliptice erau la modă, cam ca la orice sfârșit de secol sau cu prilejul altor date rotunde, dar de această dată ele se bazau pe calcule matematice, erau dezbătute în reviste științifice și emise nu de proroci religioși, ci de ingineri în calculatoare și experți IT. Evenimentul cunoscut sub numele de Y2K sau ‘Bug-ul mileniului’ a fost până la urmă un non-eveniment. El a generat însă panică în toată lumea și au fost investite sume imense pentru prevenirea problemelor potențiale. A fost vorba despre o panică falsă? Despre o campanie care a alimentat în mod intenționat o industrie lucrativă și a creat locuri de muncă pentru milioane de programatori, vreme de câțiva ani? Sau o reală catastrofă a fost evitată tocmai datorită măsurilor de prevenire care au urmat avertismentelor experților? Mai important – pot asemenea fenomene avea loc în viitor? Economia, viața socială și politică a întregii planete este astăzi digitalizata cu ordine de mărime mai intens decât acum 25 de ani, deci urmările unui eveniment similar ar fi și mai catastrofale. Pentru a răspunde acestor întrebări să ne întoarcem puțin în istoria nu prea îndepărtată.
(sursa imaginii: https://nypost.com/2023/10/28/lifestyle/y2k-bug-could-have-killed-heres-when-it-could-hit-again/)
Problema tehnică este relativ simplă. Până prin anii 1990, multe programe de calculator erau concepute pentru a reprezenta anii ca două cifre, în loc de patru. Primele două cifre erau considerate automat că fiind 1 și 9. Ca urmare, 98 era interpretat ca 1998, iar 00 că 1900, și nu ca 2000. Mulți se temeau că, atunci când ceasurile aveau să sune miezul nopții pe 1 ianuarie 2000, multe computere afectate ar folosi o dată incorectă. Consecințele ar fi putut fi foarte diferite: de la afișarea incorectă a anului pe display sau rapoarte tipărite, calcule financiare eronate și până la erori în inima sistemelor, dacă erau afectate ceasurile calculatoarelor. Alte programe de calculator nu țineau cont de faptul că anul 2000 era un an bisect, în timp ce 1900 nu fusese un bisect, anii care se termină în 00 fiind bisecți doar odată la 400 de ani. Chiar și înainte de zorii anului 2000, existau temeri că unele computere s-ar putea bloca pe 9 septembrie 1999 (9/9/99), deoarece programatorii timpurii foloseau adesea o serie de 9 pentru a indica sfârșitul unui program. Existau temeri că astfel de interpretări greșite ar duce la defecțiuni software și hardware în computerele utilizate în domenii importante, precum cele bancare, sisteme de utilități, registre guvernamentale și așa mai departe, cu potențialul unui haos general la 1 ianuarie 2000 și după această dată. Calculatoarele mainframe, inclusiv cele utilizate în mod obișnuit pentru a conduce companii de asigurări și bănci, au fost considerate a fi supuse celor mai grave probleme din categoria Y2K, dar și sistemele mai noi care foloseau rețele de computere desktop au fost considerate vulnerabile. Multe dispozitive care conțin cipuri de computer, de la lifturi sau sisteme de control al temperaturii din clădirile comerciale până la echipamente medicale erau considerate a fi de asemenea în pericol, ceea ce necesita verificarea acestor „sisteme integrate” pentru sensibilitatea la datele calendaristice.
(sursa imaginii: https://www.thoughtco.com/the-y2k-bug-1779442)
O concepție greșită răspândită și, probabil, încurajată de utilizarea cuvântului „bug” pentru a descrie fenomenul, este că scurtarea anilor la două cifre ar fi fost o greșeală de codare. Este adevărat că o mare parte din acest cod timpuriu fusese scris cu zeci de ani mai devreme de programatori care nu se așteptau niciodată ca software-ul lor să fie încă în uz în 2000. De fapt însă, stocarea anilor ca două cifre fusese un compromis deliberat făcut de programatori care încercau să economisească spațiu în zilele în care fiecare octet de stocare costa bani serioși. Memoriile magnetice din anii ’50 și ’60 costau până la 1 dolar pe bit. Atât pe computerele mainframe, cât și pe computerele personale ulterioare, memoria costa în 1975 de la 10 dolari pe kilooctet la mai mult de 100 dolari pe kilooctet. Multe dintre calculatoarele anilor ’60 și ’70 foloseau cartele perforate pentru introducerea datelor și acestea aveau un format fix cu 80 de caractere pe cartelă. Proiectul meu de diplomă, în 1977, includea un program care era stocat în două cutii de dimensiunile cutiilor de pantofi pline de cartele perforate. A economisi redundantele cifre 1 și 9 la scrierea fiecărei date părea o optimizare inteligentă.
Prima persoană cunoscută care a abordat public această problemă a fost Bob Bemer (1920 – 2004) de la IBM, care o observase în 1958, lucrând la un software genealogic. Și-a petrecut următorii douăzeci de ani încercând fără rezultat să crească gradul de conștientizare a problemei cu programatorii, IBM, guvernul Statelor Unite și Organizația Internațională pentru Standardizare. Problema a fost subiectul cărții ‘Computers în Crisis’ de Jerome și Marilyn Murray (Petrocelli, 1984; reeditată în 1996 de McGraw-Hill, sub titlul ‘The Year 2000 Computing Crisis’). Prima mențiune înregistrată pe Internet, pe un grup de știri Usenet, este din 18 ianuarie 1985. A devenit o preocupare publică abia după publicarea unui articol din 1993 în revista Computerworld, de către inginerul canadian Peter de Jager, intitulat apocaliptic „Doomsday 2000”. Acronimul Y2K1 este atribuit programatorului David Eddy din Massachusetts, într-un e-mail trimis pe 12 iunie 1995.
(sursa imaginii: www.linkedin.com/pulse/remembering-y2k-blast-from-past-modern-software-engineer-gary-jones-bfuae)
Ceea ce a urmat poate fi descris ca o adevărată, dar efemeră industrie Y2K. În majoritatea țărilor avansate, firmele comerciale și financiare mari (mai ales) sau mai mici, organizațiile guvernamentale și militare, spitalele, furnizorii de servicii, producătorii de echipamente cu control digital, practic orice organizație implicată în control digital a înființat departamente speciale, care s-au ocupat cu verificarea programelor software din produsele lor, aplicațiile și infrastructura care stăteau la baza operațiilor de zi cu zi. Unele dintre programe erau relativ noi și verificările Y2K au putut fi inserate cu relativă ușurință în procesele de verificare și introducere a noilor versiuni ale produselor. În alte cazuri, era vorba însă despre programe scrise cu mulți ani, uneori cu decenii în urmă. Produsele continuau să funcționeze fără probleme, dar oamenii care le scriseseră nu mai lucrau pentru firmele sau organizațiile respective. Uneori, programele erau scrise în limbaje de programare care nu mai erau folosite, fiind considerate de mult ‘depășite’. Primele generații de pensionari IT, cei care scriseseră programele prin anii ’60 și ’70, au fost rechemate (și plătite cu sume frumoase) pentru a revizui codul ale cărui secrete doar ei le puteau cunoaște. A apărut și o industrie a testării și certificării, care aplica ‘ștampile’ de genul ‘Y2K-ready’. Lucram în acea vreme pentru o mare firmă de telecomunicații americană și am văzut aceste procese din interior. Codul multor produse sau sistemul de operare al liniilor principale de aplicații se baza pe programe scrise cu 2-3 decenii în urmă și care evoluaseră incremental în timp, de la versiune la versiune. Era o muncă titanică, și nu foarte creativă sau atractivă pentru programatori și ingineri de software. În total, la nivel global, se estimează că au fost investiți între 300 și 500 de miliarde de dolari în activitățile Y2K, din ultimii ani ai mileniului doi. Nu totul a mers perfect. Chiar și înainte de 1 ianuarie 2000 au existat unele erori legate de timpul măsurat de calculatoare. O americancă de 104 ani a primit o invitație să se înscrie la grădiniță, deoarece sistemul credea că are doar patru ani. Cinci sute de locuitori din Philadelphia au primit citații ale juriului în 1999 pentru a se prezenta în instanță în anul 1900. Un magazin de închirieri video din New York a dat o factură de 91 250 de dolari unui client care părea să fi returnat un film cu John Travolta cu 100 de ani întârziere. Toate au fost minore.
(sursa imaginii: www.zerodayclothing.com/products/y2k38/y2k38.php)
S-ar mai putea petrece asemenea fenomene în viitor? Răspunsul este categoric da, mai ales în condițiile creșterii complexității programelor și intrării în ciclurile de creare de software a sistemelor de Inteligență Artificială (IA). Se vorbește mult despre ‘problema anului 2038’ sau Y2K38. Aceasta este o problemă de calcul a timpului care face ca unele sisteme informatice să nu poată reprezenta corect timpii după 03:14:07 UTC (Universal Time Clock – ora standard universală) pe data 19 ianuarie 2038. Problema există în sistemele care măsoară ‘timpul Unix’, care este exprimat ca fiind numărul de secunde scurse de la momentul zero al sistemelor Unix (ora 00:00:00 UTC la 1 ianuarie 1970) – și îl stochează într-un număr întreg semnat (adică cu semn +/-) de 32 de biți. Tipul de date este capabil doar să reprezinte numere întregi între −(2**31) și (2**31 − 1), ceea ce înseamnă că ultima oră care poate fi codificată corect este cea de la (2**31 − 1) secunde de la timpul zero. La ora 03:14:07 UTC pe 19 ianuarie 2038, încercarea de a crește la următoarea secundă (03:14:08) va determina depășirea întregului, setându-i valoarea la −(2**31), pe care sistemele o vor interpreta ca fiind cu 2**31 de secunde înainte de timpul zero, adică ora 20:45:52 UTC pe 13 decembrie 1901. 2**31 înseamnă 2 la puterea 31 sau 2 înmulțit cu el însuși de 31 de ori. Problema este similară ca natură cu problema anului 2000 (Y2K), diferența fiind că problema anului 2000 a avut de-a face cu numere în baza 10, în timp ce problema anului 2038 implică numere în baza 2. Sunt vulnerabile aplicațiile care folosesc anumite tipuri de reprezentare a timpului, bazele de date cu reprezentarea timpului în 32 de biți și limbaje de programare care au comenzi legate de timp. Cum sistemele de operare Unix sau derivate din Unix stau la baza multor aparate și aplicații, de la tablete și telefoane mobile până la supercomputere, pericolul este real. Avantajul este că, de această dată, comunitatea programatorilor și experților în computere are experiența acumulată în confruntările cu procesele Y2K și a început din timp implementarea unor soluții, de la schimbarea unor comenzi specifice cu referință la timp în limbaje de programare foarte populare, cum ar fi C sau SQL, până la exprimarea timpului folosind 64 de biți. Chiar dacă trecem la unități de măsură cu granulație mai fină, așa cum cer aplicațiile mai moderne, următoarea problemă de acest fel va apărea doar peste sute de mii de ani (mai exact 292 de mii de ani pentru timpi exprimați în microsecunde).
(sursa imaginii: https://monsterry.com/products/survived-y2k-lousy-90s-mens-t-shirt-back-HYiTzjzd33uy)
Fenomenul Y2K a determinat publicul să conștientizeze brusc cât de profund dependentă era societatea modernă de tehnologie. Deodată, s-a înțeles cum computerele nu erau totdeauna dispozitive elegante și perfecte, ci, în multe cazuri, erau aparate fragile, rezultate din compromisuri în procese de proiectare în care se fac greșeli sau se iau decizii oportuniste, susceptibile să eșueze în orice moment. Cineva făcea comparația că era ca și cum credeam că stăm pe un pod suspendat robust, apoi ne-am uitat în jos și ne-am dat seama că era o vorba despre o platformă slăbită, construită din scânduri putrezite, îmbinate cu lipici, bandă adezivă și speranță. După cum spunea o zicală informatică: „Dacă am construi case așa cum construim software, prima ciocănitoare care ar apărea ar distruge civilizația”. Lecțiile au fost importante și poate că au venit la momentul oportun. În opinia mea, Y2K a fost un non-eveniment, deoarece inginerii au muncit din greu pentru a face din el un non-eveniment. Noi, programatorii și inginerii de software și de sisteme, am făcut lumea sigură pentru acea noapte în urmă cu 25 de ani și pentru mulți ani care au urmat, și pe drum am învățat câteva lecții costisitoare despre proiectare optimă și proceduri de siguranță. A fost perfect? Era cu adevărat nevoie de tot ceea ce s-a făcut? Au fost toate procesele Y2K eficiente? Cu siguranță, nu – perfecțiunea este pentru îngeri, nu pentru ingineri și specialiști IT. Cu toate acestea, pericolul era clar și era la fel de imediat și de inevitabil ca venirea miezului nopții în noaptea de după ziua de 31 decembrie 1999. Apocalipsa digitală a fost atunci evitată, și sper că așa se va întâmpla și în ocaziile următoare.
(Articolul a apărut iniţial în revista culturală ‘Literatura de Azi’ – http://literaturadeazi.ro/)