-----Opprinnelig melding-----
Fra: jonivar skullerud <jonivar@bigfoot.com>
Til: klassekampen-forum@aksess.no <klassekampen-forum@aksess.no>
Dato: 1. desember 1999 12:12
Emne: Re: Tosiffertabbe til 5000 Giga
>On Tue, 30 Nov 1999 at 11:53:30 +0100, Lars Staurset wrote:
>> Bjarne Naerum wrote:
>> Å forske på kva slags avgjerdsprosessar som var i funksjon den gongen,
>> og som i mange tilfelle gav dårlege resultat, kan vere interessant,
>> særleg dersom vi kan lære noko av det. 19. januar 2038 kjem mange
>> datasystem til å få problem, fordi det teljeverket som tel sekund etter
>> 1. januar 1970 går fullt på den dagen. (Sjå f.eks.
>> http://www.howstuffworks.com/question75.htm.) Når passar det å ta *det*
>> problemet alvorleg?
>
>Nå. Og det blir tatt alvorlig. Men problemet har en helt annen
>karakter enn y2k. Det løser seg selv, nesten automatisk, med det
>samme en oppgraderer fra 32bit til 64bit mikroprosessor. (Ja, det vil
>fremdeles være et innebygd tidsproblem -- år 2514-problemet. Når
>passer det å ta det alvorlig?)
>
>Det er kun nødvendig å forandre én linje i én fil for hver maskin.
>
><teknisk>
>Såvidt jeg kan se, trenger jeg kun å forandre
>
> typedef long int __time_t;
>til
> typedef long long __time_t;
>
>i /usr/include/gnu/types.h på gnu-linux-pcen min for å unngå
>problemet, selv om jeg har 32bits prosessor (jeg er ikke helt sikker
>på dette, siden jeg ikke er sikker på hvordan long long blir håndtert
>av alle andre rutiner). Om jeg installerer gnu/linux på en 64bits
>prosessor vil problemet automatisk være løst ettersom long int da er 8
>bytes istf 4 bytes som her.
></teknisk>
>
>Y2k er innebygd i massevis av obskur kildekode som det kan ta
>evigheter å lete igjennom. Overalt hvor problemet forekommer må
>kildekoden forandres. 2038-problemet er til sammenligning uhyre
>gjennomsiktlig. Jeg regner faktisk med at det vil løse seg selv
>innen vi kommer så langt. Hvor mange sitter nå med 16bits
>mikroprosessorer? Hvor mange vil gjøre det om 10 år? Hvor mange vil
>fortsatt ha 32bits prosessor om 40 år?
>
2000 problemet ligger ikke i hvor mange bit prosessoren har.
Problemet ligger/lå hos de som skriver/skrev programmene.
Det er ikke noe problem å lage et 2000 sikkert system med 16bits prosessorer.
Jeg var på slutten av 60-tallet med på å lage programdeler for kjærnekjemikere.
De trenger svært stor nøyaktighet i beregningene sine.
Det avr unektelig letter å få til dette på maskiner med 60bits ordlengde enn på
maskiner med 16 og 20 bits ordlengder.
Men det var mulig.
Det er klart at det er svært enkelt å sette et nullpunkt for tidsregningen, og så
representere tiden ved å telle i ett tall f.eks. millisekunder fra nullpunktet.
Men det finnes mange andre måter å gjøre det på også.
Ottar Solberg
This archive was generated by hypermail 2b29 : Thu Jan 13 2000 - 15:17:44 MET