Az OpenBSD megszabadult a Y2038 problémától

OpenBSD

Year 2038 probléma
forrás: Wikipédia

A DragonFly BSD Digest (egyebek mellett) megjegyezte, hogy az OpenBSD - a 64 bites time-nak köszönhetően - megszabadult a Y2038 problémától.

( szalonna | 2013. 08. 22., cs – 10:20 )

Megszabadult vagy elodázta?

---
hack the planet

A DEC annak idején a 64 bites Alpha processzorait úgy reklámozta, hogy 64 biten az ismert világegyetem összes objektuma megcímezhető.
Csak hát a megismerés egyre gyorsabb. Lehet, hogy azóta már a 64 bitet is kinőttük! :-)
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Soha sem volt eleg :)

Assuming the mass of ordinary matter is about 1.6×10^53 kg (reference previous section) and assuming all atoms are hydrogen atoms (which in reality make up about 74% of all atoms in our galaxy by mass, see Abundance of the chemical elements), calculating the total number of atoms in the universe is straight forward. Divide the mass of ordinary matter by the mass of a hydrogen atom (1.6×10^53 kg divided by 1.67×10^−27 kg). The result is approximately 10^80 hydrogen atoms.

ami 266 biten irhato le :)

--
Live free, or I f'ing kill you.

( traktor | 2013. 08. 22., cs – 10:42 )

Azert ez nem ilyen egyszeru, vagy de? Ez nem csak azt jelenti, hogy OS szinten (kernel szinten?) bevezettek a 64 bites time-ot, de aztan hogy ki hasznalja ki nem, az mar mas kerdes. Vagyis ez biztosan nem jelenti azt, hogy minden OpenBSD-re epulo dologban megoldodott a problema. Sot, abban sem vagyok biztos, hogy az OpenBSD-ben nem maradt e valahol egy kis toolocska, ami meg mindig hordozza a problemat.

Tevedek?

Nem néztem meg alaposabban, de gondolom a kernelt és a libc-t érinti a módosítás. Ha így van, akkor aki gyári libc függvényeket használ, annak csak újra kell fordítania a programot 2038-ig :), és a probléma megoldódott. Aki újraimplementálta az időkezelést lib vagy program szinten, azoknál ez a megoldás nem javít semmit.

( bra | 2013. 08. 22., cs – 17:08 )

vlab01# date -f '%s' 253402300799
Fri Dec 31 23:59:59 UTC 9999
vlab01# date -f '%s' 253402300800
Segmentation fault
vlab01# echo OMG, now we have another problem. | rot13
BZT, abj jr unir nabgure ceboyrz.
vlab01# date
Sat Jan 1 00:00:21 UTC 10000
vlab01# echo or not | rot13
be abg
vlab01# date -f '%s' 9223372036854775807
Segmentation fault
vlab01# date
Sat Nov 7 09:47:56 UTC 3170843
vlab01# date -f '%s' 9223372036854775808
Failed conversion of ``9223372036854775808'' using format ``%s''
date: illegal time format
usage: date [-jnu] [-d dst] [-r seconds] [-t west] [-v[+|-]val[ymwdHMS]] ...
[-f fmt date | [[[[[cc]yy]mm]dd]HH]MM[.ss]] [+format]
vlab01# date -f '%s' 9223372036854775807 ; date ; sleep 10 ; date
Segmentation fault
Sat Nov 7 09:49:37 UTC 3170843
Sat Nov 7 09:49:47 UTC 3170843
vlab01# touch zzz
vlab01# stat zzz
3748871279 397313 -rw-r--r-- 1 root wheel 4294967295 0 "Nov 7 09:55:56 3170843" "Nov 7 09:55:56 3170843" "Nov 7 09:55:56 3170843" "Nov 7 09:55:56 3170843" 131072 1 0 zzz

Phew.
--
zsebHUP-ot használok!

( Replaced | 2013. 08. 23., p – 10:48 )

"DANGER: ABI incompatibility. Updating to this kernel requires extra work or you won't be able to login: install a snapshot instead. Upgrading by source is for the insane only."

lol

--
NetBSD - Simplicity is prerequisite for reliability

( dblaci | 2013. 08. 23., p – 22:55 )

Nem értem, hogy ugorhat 1901 re, mikor a 2038as a 32 bit előjeles miatt van, és 1970 a 0, nem 1901. Hogy jön ki 1901 egyáltalán 32 biten? Ezt nem értem. Ha mégis, akkor miért december?