Ga naar inhoud
GENEGEERD

Millennium Bug dood?


Johnny BravoNL
 Share

Recommended Posts

Neen, hij is nog springlevend.

 

Ik ben geen computer expert, maar door mijn werk heb ik er (zijdelings) toch veel mee te maken. Maar wellicht dat anderen hier er nog wat nuttigs over kunnen roepen.

 

Wat is nu het probleem? Welnu:

 

Het softwareprobleem van het jaar 2038 is een probleem dat machines en computers zullen hebben op 19 januari 2038. Een 32-bits computer houdt de tijd bij als het aantal seconden sinds middernacht op 1 januari 1970. Dus hij telt de seconden al sinds die dag.

 

Dit getal wordt bijgehouden in een 32-bits integer. Een soort kladblokje zeg maar waar elke seconde wordt opgeschreven. Deze integer, of beter nog, het kladblokje, kan waardes bevatten tussen -2147483648 en 2147483647. M.a.w. het kladblokje is vol als de teller 2147483647 bereikt.

 

Op 19 januari 2038 om 03:14:07 UTC zal de integer de maximale waarde bereiken. Hierna zal de integer resetten naar het minimum. Omdat dit een negatieve waarde is zal de datum worden aangegeven als 1901 in plaats van 2038.

 

Het probleem ligt dus bij dat 32-bits dingetje. Makkie! Het lijkt of dat het gehele probleem is opgelost door een upgrade te doen van bestaande systemen met naar een 64 bits processor, in plaats van de huidige 8- of 16- of 32- bits processoren.

 

Het grote probleem is, dat veel van de 8-bit, 16-bits processoren in zgn. “embedded” systemen zitten. Systemen die soms al wat jaartjes oud zijn. En dan is het niet zo gemakkelijk om even een update te doen. De “embedded” systemen zijn ontworpen om net zo lang mee te gaan als de apparatuur waarin het systeem zit ingebouwd (rare zin). Denk aan processoren in vliegtuigapparatuur, auto’s, kerncentrales? elektriciteitscentrales? Schakelkasten? Who knows? Nu zullen er ook genoeg systemen zijn die nergens last van hebben, simpelweg omdat de processoren geen tijd bij te hoeven houden.

 

De wel kwetsbare apparatuur zijn bijvoorbeeld internet routers en wifi access points, die allemaal nauwkeurig de tijd bij moeten houden vanwege hun werking. Theoretisch gezien zouden die, wanneer ze op “oude” processoren werken, stoppen met werken, een zgn. “Time out” geven.

 

Mensen hier met een Android toestel daag ik uit om de datum in te stellen op een datum later dan 19 januari 2038. Het is bekend dat sommige Android apparaten dan crashen, en niet meer opstarten. Iemand die durft?

 

2038?: Tijd zat! Helaas, dit probleem doet zich kennelijk veel eerder voor dan we hopen. Eveneens blijkt er geen directe oplossing voor te zijn. Volgens wikipedia althans. Wiki roept ook: “Op 19 januari zijn er 231 (2 147 483 648) seconden voorbij sinds de UNIX Epoch, 1 januari 1970. Als de systeemklok van UNIX-systemen dan nog steeds 32 bits gebruikt voor het bijhouden van de timestamp, zal deze klok overlopen naar 13 december 1901 en een vergelijkbare situatie ontstaan als bij de millenniumbug.”. Aan de andere kant lees is ook weer: "This problem is somewhat easier to fix than the Y2K problem on mainframes, fortunately. Well-written programs can simply be recompiled with a new version of the library that uses, for example, 8-byte values for the storage format. This is possible because the library encapsulates the whole time activity with its own time types and functions (unlike most mainframe programs, which did not standardize their date formats or calculations). So the Year 2038 problem should not be nearly as hard to fix as the Y2K problem was." No problemo dus!

 

Aan de andere kant, gebruik je software gebaseerd op Unix voor bijvoorbeeld het berekenen van rente percentages op de lange termijn, of voorspellingen moet doen op basis van historische gegevens en tracht om een inschatting te geven over 30 jaar, dan heb je een probleem.

 

Meer info hier: http://2038bug.com/

 

Overigens gaan de meeste spullen in mijn huis binnen 5 jaar stuk, dus het zal wel meevallen... Toch?

 

Enfin, bovenstaande was nieuw voor mij. Nu weet u het ook.

 

En hier is de teller:

 

Year_2038_problem.gif

 

EN WIE IS ZO DAPPER OM DIT TE PROBEREN MET ZIJN ANDROID TELEFOON? (Gelukkig heb ik een iPhone...)

Link naar reactie
Share on other sites

Begin nu je eigen moestuin. Bekijk de zadenpakketten Op zoek naar waterfilters, messen, tools of lang houdbaar eten? Ga dan naar www.prepshop.nl!

Heb mijn telefoon op de laatste tijds- en datuminstelling gezet die mogelijk is:

 

23:59 31-12-2030

 

om te kijken wat er na deze minuut gebeurt. Heel geklooi, want de wifi stond nog aan waardoor hij steeds terug op 2013 sprong. Duurde even voordat ik dat door had.

 

Resultaat... hij staat nu op 1-1-2031 !

Link naar reactie
Share on other sites

Heb mijn telefoon op de laatste tijds- en datuminstelling gezet die mogelijk is:

 

23:59 31-12-2030

 

om te kijken wat er na deze minuut gebeurt. Heel geklooi, want de wifi stond nog aan waardoor hij steeds terug op 2013 sprong. Duurde even voordat ik dat door had.

 

Resultaat... hij staat nu op 1-1-2031 !

 

Wow, dapper! Bedankt voor de test! Maar het blijkt dus dat je hem niet handmatig op een tijdstip kan zetten dat na 19 januari 2038 ligt... Wellicht een trucje van de producent om te voorkomen dat je je telefoon naar de knoppen helpt?

Link naar reactie
Share on other sites

Ach ja, die Y2K bug was ook zwaar overdreven.

 

Had die nacht dienst bij een bank waar ik toen werkte als systeemspecialist. Nog nooit zo'n rustige avond gehad. :)

Het timestamp probleem is voor de architectuur meestal simpel op te lossen, voor zover die er al is, want in die tijd was er geen mainframe die het jaartal met twee decimalen bijhield.

Een enkele archaïsche applicatie deed dat wel en dat was van te voren simpel op te lossen. Daar was de avond dat ook het spannendst, bij de applicatie jongens, of ze hun werk wel goed hadden gedaan.

 

Tegenwoordig is er een grote diversiteit van OS-en in al die kleine gadgets die wellicht niet allemaal met evenveel aandacht gecodeerd zijn. Die hebben gelukkig geen lange levensduur.

Voor de belangrijke systemen, het internet, financiële systemen, etc, verwacht ik geen enkel probleem.

 

Dit is al even bekend en ze hebben nog een kwart eeuw(!) om er iets aan te doen. :o

Link naar reactie
Share on other sites

Geen idee, ik ben geen computer expert, maar wellicht dat het iets te maken heeft met het feit dat het besturingssysteem van Windows niet op UNIX gebaseerd is. @wodan? @martin? @f150? Hellup!

 

 

@Johnny BravoNL

 

Om hier iets zinnigs op te kunnen posten moet ik eerst een lap tekst neerzetten tussen de verschillen van soft en hardware, en de verschillen tussen een datumnotatie, een zogenaamde timestamp, en het mogelijke probleem van een berekening met datums als je dit uitvoer zonder hier over na te denken.

 

Ik ga het proberen, en niet in slaap vallen aub :)

 

Ten eerst even iets over het overdrijven van de milleniumbug

Achteraf is het makkelijk praten maar er zijn wel degelijk flinke aanpassingen nodig geweest om de millenniumbug voor te zijn.

En uiteraard zijn het alleen de falende zaken geweest die men in het nieuws heeft vernomen, maar er zijn honderden, zo niet duizenden problemen voorkomen doordat er vooraf aanpassingen zijn gemaakt in softwaresystemen.

Voor details zie http://en.wikipedia.org/wiki/Year_2000_problem en lees nog even de bugs door die men NIET had gefixed.

 

Hardware/Software

Als programmeur moet je zorgen dat je gegevens worden opgeslagen in het geheugen (ram) en om er later nog iets mee te kunnen in het ROM.

Vanaf de eerste CPU bestaat geheugen uit bits en bytes.

1 byte is 8 bits, 1 byte kan een waarde tussen 0 en 255 bevatten

Om een tijdsmoment (datum) op te slaan zou je dit kunnen doen door de seconde/minuten/uur/dag/maand/jaar op te slaan als tekst.

Dus dan krijg je iets van “25-12-2013 18:15” en als we de spaties en scheidingstekens wegdenken en gelijk zo slim zijn om het jaartal eerst te zetten, dan de maand, dan de dag, dan het uur, dan de minuten, en als we toch bezig zijn gelijk maar de secondes dan krijg je dit

“20131225181500”

dit zijn in totaal 14 tekens, en eigenlijk zijn we dus 14 bytes kwijt aan geheugen om dit op te slaan.

 

Als je cijfermatig ga rekenen dan zou je ipv deze 14 tekens ook een interval kunnen registreren ipv deze 14 bytes, en dan zou je veel zuiniger omgaan met dit (kostbaar) geheugen

(en je kan er hierna ook een stuk makkelijker berekeningen toepassen)

Dus is men gaan nadenken over een “timestamp” ipv 14 bytes opofferen.

En natuurlijk kan je nu in paniek gaan roepen “maar wat doen je dan met datums die voorbij deze grens zitten”, maar dat is nu niet relevant.

 

Binair rekenen is best wel makkelijk, en met iedere bit erbij krijg je een exponentiële toename van het oorspronkelijk getal.

8 bits = 256, 16 bits = 65535 (256*256), 32 bits = 4294967295 (256*256*256*256)

Dus heeft men bedacht dat je met een 32 bits notatie de meeste zaken ruimschoots kan voorzien van een zogenaamde timestamp.

 

32/64 bits

Of je nu een 8,16,32 of 64 bits cpu gebruik staat helemaal los van het opslaan van een timestamp. Zelfs een 8 bits cpu is keurig in staat op een 64 bits getal op te slaan.

 

 

En wat is dan het probleem?

Op zich is er helemaal niks mis met deze notatie, en er hoeft ook geen probleem te zijn MAAR, het kan ook een enorm probleem opleveren indien je als programmeur niet goed nadenkt over deze notatie.

 

Fictief voorbeeld

(compleet fictief, niet zeuren dat er niks van klopt, het gaat om het voorbeeld)

Stel je bent in 2012 aangenomen als applicatieontwikkelaar voor medische toepassingen en er is een applicatie ontwikkeld die berekend hoeveel morfine je bij pijnbestrijding moet toedienen in geval van een langdurige onthouding.

en je code ziet er ongeveer zo uit:

(even in versimpelde vorm)

 

{

shot=15mg

ask, input_datum laatste morfine

onthouding={today}-{input_datum}

toshot=shot*onthouding

}

 

Ja, het is fictief, en natuurlijk hoor je als ontwikkelaar diverse zaken af te vangen die onmogelijke waardes tevoorschijn zal toveren, maar kijk nog even naar de lijst met onderschepte en niet onderschepte “bugs” en ga dan pas piepen.

 

Maar stel dat je door een foute verwerking van de programmeeromgeving waar je gebruik van heb gemaakt een waarde krijgt die gelijk is aan 5000ml en je door de bezuinigingen een verzorger aan het bed heb staan die te dom is om tot 10 te tellen dan ben je toch mooi de pineut.

 

Samenvattend.

Persoonlijk denk ik dat het wel mee zal vallen, maar aan de andere kant kan deze instelling er juist voor zorgen dat het helemaal niet zal meevallen.

Je ziet steeds meer domme fouten die gemaakt worden in de ontwikkeling van software. Door tijdsgebrek en druk zal een programmeur steeds minder tijd stoppen in het afvangen van onmogelijke uitkomsten. Dat er nog wat bugs naar voren zullen komen dat is 100% zeker.

Dat een computer/telefoon/tablet (mogelijk) keurig om kan gaan met deze datum staat los van het (mogelijke) probleem dat het kan opleveren als het om het rekenen gaat met deze getallen.

Link naar reactie
Share on other sites

Mochten we 2038 op een normale manier met deze wereld halen, vermoed ik dat het probleem tegen die tijd geminimaliseerd is. Best kans dat oude electronische apparatuur en software (die gebruikt maken van de beperkte timestamp functies) tegen die tijd nog niet vervangen zijn, maar niet alle toepassingen zijn tijd-kritisch.

 

De huidige doorloopsnelheid van applicaties en apparatuur ligt een stuk hoger dan 10-20 jaar geleden. En er is nu meer bewustwording voor de '2038 bug' dan er in 1986 voor de millennium bug was. Maar ongetwijfeld zal het een spannend moment worden, waarbij net als bij Y2K een leger ontwikkelaars de kerstdagen in 2037 mag doorwerken. Blokkeer het maar vast in je agenda;)

Link naar reactie
Share on other sites

Ik denk dat het niet zo'n probleem zal worden in 2038. Ik kan me nauwelijks voorstellen dat we dan nog programma's draaien lager dan 32 bits. Misschien zitten we dan al op 256 bits of zijn we technisch nog veel verder. De gemiddelde telefoon gaat een aar jaar mee, dus niemand zal een Iphone 5 meer gebruiken in 2038.

 

Ik heb ruim 9 jaar voor een Bank\Verzekeraar gewerkt en heb honderden applicaties gemigreerd. Ik ben eigenlijk maar 1 applicatie tegen gekomen waarvoor dit een probleem zou kunnen zijn. De polissen die hier in zitten lopen tot 2035 maar zodra het aantrekkelijk wordt deze af te kopen (naarmate er minder inzitten) dan sterft de applicatie uit. Alle nieuwe polissen werden nl. al in een ander systeem opgenomen.

 

Er zullen zeker anderen uitdagingen komen op IT vlak te zijner tijd, maar 'millennium problemen' zoals in 2000 zie ik niet snel meer voor me.

Link naar reactie
Share on other sites

yep 2038 het unix epoch

misschien dat ik dan van pensioen moet terug komen voor fixes, maar dat denk ik niet...

24 jaar nog. Dan zijn alle applicaties die nu nog op native solaris 8 en aix 4.3 draaien wel weg.

 

bijna alles is nu een java app op een applicatie servers. behoudens wat transactie verwerkende systemen. Maar bij gebrek aan reserve onderdelen zullen die de komende jaren echt wel over moeten naar virtuele servers en probleem opgelost.

hmmm alleen die black box applicatie dingen laten we maar hopen dat die tegen die tijd weg zijn, vooral in de nuts bedrijven

Link naar reactie
Share on other sites

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Reageer op dit topic...

×   Geplakt als verrijkte tekst.   Herstel opmaak

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

 Share

×
×
  • Nieuwe aanmaken...