Itt egy "időutazást" :-D bizonyító fotó.
http://www.freeweb.hu/oscon/idoutazas.jpg
Persze van hivatalos magyarázat.
Éjjel csak másodjára sikerült hibernálni, mivel valami oscon nevezetű vadbarom bentfelejtette mountolt állapotban a cd-t a kaszniban, így nem sikerült az ide_cd modult eltávolítani hibernálás előtt. Ami a powersave beállítások miatt a hibernálás (egyik) előfeltétele. de végül is ficsőrnek sem rossz. elkerülhető a cd-k kaszniban történő éjszakázása. :-)
Szóval másodjára aztán sikerült elhibernálni, csak mivel elsőre az ide-cd helyett néhány másik kernelmodult azért sikerült eltávolítani. közte a "rendszeridőéért" is felelős rtc modult, így aztán sikerült fals rendszeridővel hibernálni másodjára. :))
Hogy "gyakorlatban" mégsem okozott problémát az időanomália , az a powersave-nek közsönhető, mivel tartalmaz olyan ficsőrt, hogy hibernálás előtt kb. "elmenti a rendszeridőt". Amit éledéskor úm. visszatölt. Mint a kernellogból is látszik.
De poénnak nem volt rossz.
Ha az elméletem helyes és most megint elhibernálok, akkor most már gond nélkül vissza fog térni. :)
Bejegyzés szerkeztésre előkészítve: 11:39kor. :)
SZERK:
Nos 4szer hibernáltam el+vissza, de nem sikerült reprodukálni. (nem cd nem volt bent).
Még esetleg az lehetett (volna) hogy a CMOS elemecske merült le.
de mivel a proc/acpi/alarm-ot rendesen kezeli (=előírt időre magához tér ótómatán), ez is kizárható. ráadásul ha lemerült volna, akkor nem aug. 22kor hanem valszeg 1970 jan 1.kor vagy hasonló jan 1es időben kellett volna észhez térnie az "időutazásból". :)
Az esemény viszont a következő újraindításig (=következő debian kernelig), örök emlék marad, úgyanis az 5003napos uptimeról már nem tudom visszabillenteni a kb. igazságnak számító 8 napra.
- Oscon blogja
- A hozzászóláshoz be kell jelentkezni
- 1567 megtekintés
Hozzászólások
én is feltaláltam.
Most is előre utazok az időben, egy óra sebességgel óránként.
Hgy meg fogja szívni midnenki, ha szabadalmaztatom...
int getRandomNumber() {
return 4; //szabályos kockadobással választva. garantáltan véletlenszerű.
} //xkcd
- A hozzászóláshoz be kell jelentkezni
Nem mert én ezt már előtted is nyilvánosan csináltam, és a bíróságon visszavonattatom a szabadalmadat. :)
- A hozzászóláshoz be kell jelentkezni
És közben jól lebuktál, hogy "höwösövöt" olvastál és nem hup-ot! ;-)
Néha az is egy sci-fi, mint az időutazás! ;-)
- A hozzászóláshoz be kell jelentkezni
Nálam a Merlin (ami egy HP B132L) nevű gépem logja érdekes. Amíg nem indul el bootkor az ntp kliens, addig szerinte 1970. január 1 van. :-)
- A hozzászóláshoz be kell jelentkezni
Tényleg, ez minek a dátuma?
Sok UNIX(like) rendszer kapcsán találkoztam hasonlóval.
Itt nem találtam erre vonatkozó iránymutatást.
Szerk: Tudom, ez valahol az alapműveltség része.
Zopr miafene
- A hozzászóláshoz be kell jelentkezni
http://hu.wikipedia.org/wiki/Unix-id%C5%91
---
"... nem zsaru vagyok, hanem a rendorfonok."
- A hozzászóláshoz be kell jelentkezni
Ez jó, meg stimmt, csak eseményhez szerettem volna kötni.
Ezek szerint esemény nincs.
Zopr miafene
- A hozzászóláshoz be kell jelentkezni
a unix time ritka szar egy megoldas
gondolom azert, mert a hetvenes evekben talaltak ki es viszonylag hosszu idore szerettek volna biztositani, hogy eleg legyen (2038)
-. . - -... ... -..
- A hozzászóláshoz be kell jelentkezni
És mi is lesz 2038 után? Jó lenne már kitalálni egy megoldást, ami nem néhány 10 évre elég...
- A hozzászóláshoz be kell jelentkezni
mar kitalaltak.
ujabb glibckbe a time_t ifdefelve van egy 64bites unsigned intre AFAIK
- A hozzászóláshoz be kell jelentkezni
Ami, ha jól számolom, 9,75 milliárd évre elég. Vagy rosszul számolom?
- A hozzászóláshoz be kell jelentkezni
csak erdekesseg keppen:
time
-. . - -... ... -..
- A hozzászóláshoz be kell jelentkezni
Lehet hogy ez feature és előrevetíti, hogy 2038 után már úgyis máshogy fogjuk mérni az időt :)
Lám mikre nem gondoltak az "ősök".
--
http://kac.duf.hu/~balage/blog
- A hozzászóláshoz be kell jelentkezni