Y2038 ``bug'' Linux, UNIX szemszögből

sun ultra 10 (64 bites), linux-szal:

urbnet:~# uname -a

Linux urbnet 2.4.26-grsec #1 SMP Mon Jul 12 13:07:33 CEST 2004 sparc64 GNU/Linux

urbnet:~# perl ./epoch.pl

Tue Jan 19 03:14:01 2038

Tue Jan 19 03:14:02 2038

Tue Jan 19 03:14:03 2038

Tue Jan 19 03:14:04 2038

Tue Jan 19 03:14:05 2038

Tue Jan 19 03:14:06 2038

Tue Jan 19 03:14:07 2038

Tue Jan 19 03:14:07 2038

Tue Jan 19 03:14:07 2038

Tue Jan 19 03:14:07 2038

Annyira nem vészes a dolog. Mire teljesen elterjednek az asztali 64 bites processzorok, szerintem a Linux és a FreeBSD is váltani fog.

Utóbbi a 64 bites SPARC-oknál már meg is lépte:

$ date -r 2147483648

Tue Jan 19 04:14:08 CET 2038

$ uname -a

FreeBSD cache0.cache.xxx.hu 5.3-STABLE FreeBSD 5.3-STABLE #4: Mon Feb 21 10:07:42 CET 2005 root@cache0.cache.xxx.hu:/usr/obj/usr/src/sys/CACHE sparc64

Ki akarom cseréltetni a testemet SPARC-ra és Linuxot akarok rá!

Örökifjú leszek! :))

Fel kell rá most készülni és akkor nem lesz gond.

Nem hinném egyébként, hogy túl sok ilyen lenne :)))

Persze. Sőt, szerintem még C64 kompókat is fognak rendezni :)

Lesznek, és két 32 bites változóban fogják a 64 bites értéket tárolni.

:-D

" hanem nem másik időponttól kezdve számítják."

Ezt javítsd ki, hogy szép legyen az oldalad. :D

A 32 bites unsigned int nem 2szer akkora értéknél fordul át mint a 32bites signed int?

Régi rendszerek áthelyezése új vasra, meg új sysre mindent megold, nem?

Ilyen komoly kérdéseket senki sem szeret múzeumba való gépeken megoldani.

uh és ráadásul még péntek 13. is lesz..... :D

a számítási eredmények pillanatnyi állását lehet freezelni és áttérni az új architektúrára. Legfeljebb a kiesett időt megy /dev/null-ba nem ?

elméletileg :)

ja és ha valakinél a fenti '*****' feleslegessé vált akkor csak dobjon meg vele. csak ne szó szerint :)

OK, akkor egy érdekes tecnikai (futurisztikus) kérdés a valós problémákon kívül:

A "2048 node bol allo 32 bites x86 vas" 2038-ban múzeumba való lesz-e szerinted, vagy nem?

33 éve még sehol sem volt x86, 33 év múlva mekkorát fog fejlődni a technika?

Baromira don't care hogy hány bites a processzor. 32 bites rendszeren is röhögve meg lehetne csinálni a 64 bites időábrázolást (mint ahogy a fájlhosszra már működik, sőt az időt is nagyon gyakran 64 biten ábrázolják, ebből 32 a másodperc és 32 azon belüli a nanosec) és 64 bites procin is lehetne 32 bites az idő (bár az eléggé elkefélt dolog volna). Itt egy átállást gyerekjáték 2-3 év leforgása alatt teljesen, kompatibilitási problémák nélkül végigvinni. Szóval nem a processzoron fog állni vagy bukni az egész.

Ahol nagyon oda kell figyelni, azok a különféle kommunikációs és adattárolási formák. Időcímkék tárolása ext3, reiser, jfs, xfs, iso9660, ntfs, vfat, fat12 :-) stb. fájlrendszereken, különféle archiválási formátumukban (tar, cpio, zip, rar, arj...), speciális alkalmazások speciális formátumaiban (például naplóban), időcímkék továbbítása nfs, smb, rsync, ntp stb. protokollokon és biztos van még csomó ehhez hasonló terület. Itt félő hogy sokkalta cinkesebb lesz az átállás, hiszen valszeg új adatformátum- vagy protokollverzióra lesz szükség, ami jobb esetben megoldható a régivel kompatibilisebb módon, rosszabb esetben nem, és protokoll esetén azt mindkét végpontnak támogatnia kell.

Például a nanosec tárolását is több fájlrendszer még mindig nem támogatja, holott napjainkban sokkalta nagyobb gyakorlati szükség volna rá, mint arra hogy 33 év múlva is tudjuk ábrázolni a másodperceket.

hány éves örök ifjú is leszel 2038-ban? :)))

Viszont az ilyen programokban van checkpoint/resumw (programallapot elmentes-betoltes) funkcio, hogy hardver hiba eseten ne kelljen az egesz szimulaciot ujrafuttatni. Ebben az esetben egyszeruen atpakoljak egy megfelelo gepre a futo szimulaciot, ami nem erintett a hibaban.

Ebben egyetértünk :-)

Tartok töle, hogy lesz még akkor 32 bite-s proceszorok , addigra nem, hogy 32 bites de meg 128 bites sem lessz . A 32 bites processzor addigra , olyan számba fog menni mint ma egy 4 bites. :)

Hát ha 4bitest talán nem is, de 8 bites processzorokat manapság igenis használnak, valszeg sokkal több van belőle, mint 32 és 64 bitesből együttvéve, és ez sokáig így is fog maradni. Ezek a mikrovezérlők, amik ma már gyakorlatilag minden háztartási gépben, ipari berendezésben stb. megtalálhatóak; van kb 8-10 lábuk (némelyiknek csak 3-4) és van olyan, amelyik csak annyit fogyaszt hogy egy gombelemről hónapokig is elmegy. Ezeknél nem kell nagy programmemória, nagy számítási teljesítmény és nagy számábrázolás; az a fontos kicsi legyen és olcsó, és bármilyen készülékbe könnyen beépíthető legyen. 2038-ra nem tudom, hogy hogyan fog változni a ré*****ányuk, talán akkor már többnyire 32 bitesek lesznek, de biztos vagyok benne hogy fognak használni még 8 biteseket is. Csak azt nem tudom, hogy hol. Talán emberi sejtek belsejében...

nem hiszem, hogy egy mosógépet érdekelné, hogy hanyadika van most, és milyen év.

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Érti valaki, hogy a túlcsordulás után miért nem nő a másodperc értéke?

Jé, ez se nem jó ám, beragad a másodperc 07-en mint atom!

snitt__ sparc64 gépén is beragad. Lehet hogy perl bug?

Ez a thread eleg vicces bocsi ;) Nem hiszem hogy ijen idotartomany szimulacional a rendszer beepitett orajat hasznalnak fel ;] Szimulacio kicsit gyorabban/lassabban is haladhat, mint a valos ido ;) De inkabb lassabban ;)

Az én kerékpárom kilométerórájában 4 bites proci van, pedig nem a leggagyibb óra.

Tue Jan 19 03:14:01 2038

Tue Jan 19 03:14:02 2038

Tue Jan 19 03:14:03 2038

Tue Jan 19 03:14:04 2038

Tue Jan 19 03:14:05 2038

Tue Jan 19 03:14:06 2038

Tue Jan 19 03:14:07 2038

Tue Jan 19 03:14:08 2038

Tue Jan 19 03:14:09 2038

Tue Jan 19 03:14:10 2038

Linux i13pc90 2.6.4-52-smp #1 SMP Wed Apr 7 01:58:54 UTC 2004 x86_64 x86_64 x86_64 GNU/Linux

Viszont a 64 bittel úgymond magától meg kellene oldódnia a problémának, mert:

/usr/include/linux/types.h:typedef __kernel_time_t time_t;

/usr/include/asm/posix_types.h:typedef long __kernel_time_t;

Szóval a 64 bites sparc-os eredmény az egyre érdekesebb (;

"ré*****ányuk"

(;

pont mosógépből reklámoznak olyat a tv -ben, ami kiírja, hogy mikor lesz kész a feladat. Nem, nem azt, hogy mennyi idő múlva, hanem mint az mkisofs...

Jah, annyira nem. Viszont ha 32 bites rendszeren szimulaciokat vagy olyan szamitasokat vegeznek amit most inditanak, de a vege 2038 utan van akkor az talan gaz lehet.

Ez alatt mit is ertesz? Egy evtizedekig futo szimulaciot? Vagy olyan szimulaciot, ami az ido fuggvenyeben vizsgal valamit?

Ha az elobbit, azt enyhen szolva is nehez elkepzelni. Marmint hogy van olyan orult, aki evtizedekig akar futtatni valami programot. (l. Galaxis utikalauz..., 42 stb.).

Az utobbinal pedig teljesen lenyegtelen, hogy a UNIX hogyan szamolja az idot, es milyen valtozoban tarolja. Az ilyen szimulacioknal az ido egy fuggetlen valtozo az egyenletekben, egyenletrendszerekben, es semmi koze a rendszeridohoz.

b

uh bazze! és télleg ! :D

"The Unix System Colock Proudly Presents The New Apocalipse"

aka "This Is The Biggest Y2038 Unix BugI have ever seen"

ez a második mondat nagy hangsúlyt fog kapni a következő Get The Facts kampányban :D

ugy -70, atfordulas utan:)

Úgy, hogy 2005.05.08 10:32:30???

$ uname -svap

OpenBSD larva.portable.wooh.hu 3.7 GENERIC#110 i386 Genuine Intel(R) CPU 2.80GHz ("GenuineIntel" 686-class)

Tue Jan 19 03:14:01 2038

Tue Jan 19 03:14:02 2038

Tue Jan 19 03:14:03 2038

Tue Jan 19 03:14:04 2038

Tue Jan 19 03:14:05 2038

Tue Jan 19 03:14:06 2038

Tue Jan 19 03:14:07 2038

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Fri Dec 13 20:45:52 1901

Funny. Gondolom addigra javitjak. :-)

Windows Vilag ban ez Y2099 lesz :)

mert utana at fordul 1980-ra :)))))))))))))))

úgy érted, Y2079 (vagy Y2080), nem? Mert valahogy így "hackelték" megy a Y2K-t....

Micskó Gábor wrote:
> PS: Mondjuk egy 2048 node bol allo 32 bites x86 vasat nem neveznek szarnak
> meg most sem.
Nem 2048, hanem 1911 :)