Y2038 – az új armageddon ?

Túléltük az Y2K -t, aztán jött a maja naptár szerinti 2012 -es világvége, de még mindig élünk.

Hipp-hipp hurrá!!! Mondhatnánk… csakhogy, van itt egy kis bökkenő !

Az Y2038.

Na, szépen vagyunk, de miről is szól a legújabb idő probléma.

Nem új keletű dologról van szó és már jó ideje folynak a javítások, szóval egyenlőre pánikra semmi ok, de azért mégis érdekes jelenségről van szó.

Idézet Wikipédiából, a szabad enciklopédiából:

A problémát bemutató animáció. A felső dátum (angolul Date) a kiszámolt érték, az alsó a valóságos

A számítástechnikában a 2038-as év problémája néhány szoftver meghibásodását okozhatja 2038-ban vagy akörül. A probléma a POSIX időábrázolást használó programokat érinti elsősorban, amely az időt az 1970. január 1. óta eltelt másodpercek számával ábrázolja. Ez az ábrázolási mód számít szabványnak a Unix típusú operációs rendszereknél, de érinti az egyéb operációs rendszerekre fejlesztett programok nagy részét, mivel a széles körben használt C programozási nyelv is ezt az ábrázolási módot használja. A legtöbb 32 bites rendszerben, a time_t adattípus, melyet a másodpercszámláló tárolására alkalmaznak, egy előjeles, 32 bites integer (egész szám) formátumú adat. A legkésőbbi időpont, amely még ábrázolható ebben a rendszerben a POSIX szabvány szerint 2038. január 19., kedd, 03:14:07 (UTC szerinti idő). Ezt követően az időpontok „körbefordulnak”, és belsőleg negatív számként jelennek meg, amely helyzet a programok meghibásodásához vezet. Mivel az időpontokat nem 2038-ra fogják tenni, hanem 1970-be vagy 1901-be, ez okból kifolyólag hibás számításokat és hibás döntéseket fog hozni a program.

Tehát itt inkább arról beszélünk, hogy ez egy emberi, mégpedig programozás technikai hiba, amit orvosolni lehet, többek között a 64 bites architektúrára történő váltással, de miért nem megy ez sitty – sutty, mint egy suhanó nyilvessző?

A gond valódi forrása a rendszerek belső mechanizmusában keresendő.

A feladatok ütemezésétől elkezdve a fájlok tárolásán át a digitális tévé adásokig nagyon sok eljárás alkalmazza a 32 bites időbélyegek használatát, tehát nem elsősorban csak a 64 bites gépek használata jelent majd megoldást, hanem a teljes struktúra átprogramozása, kezdve az alapvető rendszerfolyamatok átírásától, ahol az egyik kulcs persze a time_t változó, de ez csak a jéghegy csúcsa, ahogy mondani szokás…

Vegyük sorra ezeket kicsit:

  • Beágyazott rendszerek – itt a legroszabb a helyzet, nagyon sok esetben nem lehet egészen egyszerűen megváltoztatni a rendszert, ráadásul sok esetben hosszú évek óta működnek, így senki sem nyúl hozzá szívesen. Egy urbánus legenda szerint az Y2K esemény bekövetkeztekor az amerikai rendőrök nem tudtak bemenni a garázsba, mivel a rendszeróra 1900 -ra fordult, így az RFID tokenjeik dátuma érvénytelenné vált  🙂
  • Windows – most sokan meglepődnek, de a standard windows C kódok bizony 32 bites unix időbélyegeket használtak, az alábbi linken olvashatunk a microsoft javításáról, ami lényegében azt jelenti, hogy ha valaki már Visual Studio 8 és annál újabb rendszeren fordított, annak a probléma már megoldott, a többieknek lehetnek nehéz pillanatai 🙂
    https://blogs.msdn.microsoft.com/mthree/2008/04/21/another-look-at-the-year-2038-problem/
  • Digital Video Broadcasting (DVB) – a dátumot 16 bites számláló állítja elő a dátumot az elektronikus műsorújsághoz (EPG) és ezek elvileg Április 22 -én 2038 -ban szintén fordulnak egyet 🙂
  • Fájlrendszerek – egyértelmű a helyzet, új fájlrendszert kell használni, migrálni, átmásolni a fájlokat, mielőtt érvényüket vesztik az időbélyegek, hiszen a fájlrendszer nem képes lekezelni az újabb dátumot. A legtöbb hagyományos, régi fájlrendszer ugyanis 32 bites időbélyeget használ, függetlenül attól, hogy adott esetben 64 OS van felette.
    A gond ugyanakkor az, hogy például egy 64 bites ext4 partíción egyszerűen elhasalnak az úgynevezett legacy, tehát örökölt, azaz a régi linuxos alkalmazások, programok és jelenleg elég sok hibát okoznak jelenleg és persze még ott van a kérdés, hogy mi lesz a 2038 előtt formázott USB -s és egyéb tárolóval? Hát, annyi biztos, hogy majd óvatosan kell backupolni róluk a jövőben…
  • Minden rendszerfolyamat, ami a klasszikus 32 bites változót használja: – utolsó fájlhozzáférés, cache érvényesség lejárata, processzek és szálak szinkronizálása, felhasználó tevékenységek mérése vagy akár egy új kernel és library fordítása 32 bites OS alatt vagy 64 bites de 32 bites kompatibilitási módban fordító rendszeren
  • Ja, és az okostelefonok ! Gyakorlatilag a 32 bites, régi androidos telefonokat akár el is dobhatjuk, ha csak nem tudjuk frissíteni a gyári rendszert, ami ugye sok modell esetén fennáll…     Ami viszont jó hír, hogy addigra már ezek a telefonok és ez a 32 bites technológia és technikai eszköztár jó eséllyel a szemétben landol, még valószínűbb viszont, hogy lelkes gyűjtők padlásán és a bolhapiacok forgatagában és lomtalanításkor kell keresnünk, minthogy még addig van bő 22 évünk.

Itt a munkálatok terheit elsősorban a nagy cégek és ipari berendezések, szerverek és hatalmas adatbázisok, valamint nagyvállalati struktúrák szintjén kell elképzelnünk és azt a hatalmas munkát, amivel minden egyes bevált, ezer éve használt alkalmazást szépen meg kell írni, letesztelni, aztán migrálni a meglévő adatainkat az új, modern rendszereinkre.

Ez a valódi kihívás a szakemberek számára és természetesen  szinte  minden cég és rendszer már valamilyen módon felkészült erre a problémára, azért nem árt odafigyelni a következő 22 évben, mert az ördög nem alszik !

 



Vélemény, hozzászólás?

Translate »