“There are two major products that came out of Berkeley: LSD and UNIX. We do not believe this to be a coincidence.”
Funny. De vraag is, welk hebben ze eerst uitgevonden? Ik gok op LSD en dan in een stoned mindset het andere ;-).
Tag: UNIX
Daarnet heb ik nog geschreven over mijn meest recente “probleem” en enkele uurtjes later kan ik na een hoop geëxperimenteerd en getest met veel blijdschap melden dat er een oplossing is. Misschien is er natuurlijk nog een betere oplossing, waarmee u mij altijd mag lastig vallen in de comments :-).
Bon. Mijn oplossing.
- De betreffende schijf / partitie omzetten naar een RAW-data image met behulp van een opensource tool (geport van UNIX) genaamd Disk Image van Dubaron (DD voor de vrienden). Hier te downloaden.
- Daarna de RAW-data image converteren naar een *.VMDK bestand (oftewel een virtuele VMWare harde schijf) met LiveView. Eveneens voor niks te downloaden. Hierzo.
- Tot slot de betreffende VDMK file “mounten” met behulp van een gratis (maar unsupported) tooltje van VMWare zelf: VMWare Diskmount Utility.
- Klaar is kees. Vanaf nu heb je de schijf in Windows als een lokale disk gemapt staan en zou het probleem opgelost moeten zijn.
Neen ik ben geen “Klingons” aan het spreken. Epoch is het begin van de tijd. Althans voor UNIX / POSIX computer systemen en vele andere varianten die daarna ontstaan zijn. Epoch houdt de tijd bij door middel van het tellen van het aantal verstreken seconden sinds de startdatum, zijnde middernacht, op 1 januari 1970. Op dat moment was het in “Epoch” dus 000000000 “uur”. Wetende dat een dag exact 86.400 seconden duurt (met uitzondering van “leap seconds” die heel af en toe voorkomen om de telling synchroon te houden met de rotatiesnelheid van moeder Aarde) zou het in Epoch uitgedrukte tijd nu dus op het moment dat ik dit schrijf 1194383797 “Epoch” zijn. Ik vind dat trouwens serieus veel gelijken op de gekende “star dates” uit Star Trek, waarmee onder andere Captain Picard elke aflevering begon. Klik hier om zelf data te converteren naar Epoch.
Ik had hier in feite nooit eerder bij stilgestaan en vandaag door een opmerking van een collega daarop uitgekomen en verder onderzocht op het wereldwijde web bij thuiskomst. Enorm boeiende materie zeg ik u!
Wat ik dus ook ontdekt heb, is dat het u alom bekende Y2K-probleem een opvolger heeft. Indien u nog nooit gehoord heeft van de befaamde Y2K-bug: voor de eeuwwisseling hadden programmeurs de “gewoonte” om een jaartal weg te schrijven in een tweecijferig getal, dit om geheugen te besparen (dat in de beginjaren van computers veel beperkter en vooral veeeeeeeel duurder was dan vandaag de dag). Op die manier was het jaar 1970 voor een computer gelijk aan 70, 1995 gelijk aan 95 en zo verder. U ziet de brui al hangen? In het jaar 2000 (Y2K) zou de computer het uur opslaan als 00, wat ook gelijk staat aan 1900… althans op computer niveau. Het heeft handen vol geld en tijd gekost om voor de eeuwwisseling zo veel mogelijk software aan te passen om allerhande problemen te voorkomen.
En blijkbaar is er in de (niet zo nabije, maar ook niet zo verre) toekomst een gelijkaardig probleem, genaamd Y2K38. Met die benaming doelt men op het jaar 2038. Exact op 19 januari 2038, om 3u14 gaan we een gelijkaardig probleem tegenkomen. Die “secondentelling” die men in Epoch gebruik, is namelijk maximum 32-bit groot. En op de eerder vermelde datum zijn al die 32 bits volledig gevuld en gaat het getal beginnen flippen en negatief worden. Ik moet u niet uitleggen dat dit voor een grote catastrofe kan zorgen daar zo goed als elk computer systeem dat de mens gebruikt deze telling (of een variant) gebruikt?
Niet dat ik paniek wil zaaien of zo, maar een gewaarschuwd man (en vrouw) is er toch twee waard eh?
Recente Comments