PDA

Bekijk Volledige Versie : Millennium Bug dood?



Johnny BravoNL
24-12-13, 11:39
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 (http://code.google.com/p/android/issues/detail?id=16899) 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:

http://www.visualdesign.ie/wp-content/uploads/2013/01/Year_2038_problem.gif

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

daisy
24-12-13, 12:42
Ik wilde het wel even proberen met mijn telefoon. Alleen kan ik hem niet verder zetten dan het jaar 2030.... dan is het klokje rond en begint hij weer op het jaar 2000.

daisy
24-12-13, 12:57
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 !

FincaInSpanje
24-12-13, 13:06
Dus we hebben tegen die tijd weer werk in de IT sector.:)

Johnny BravoNL
24-12-13, 13:10
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?

FincaInSpanje
24-12-13, 13:18
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?

Ik kan met mijn 32 bits windows computer gewoon naar 2038 en verder. Hoe verklaar je dat dan?

Johnny BravoNL
24-12-13, 13:51
Ik kan met mijn 32 bits windows computer gewoon naar 2038 en verder. Hoe verklaar je dat dan?

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!

Communicator
24-12-13, 14:01
Mijn (reserve) Samsung Gio komt niet voorbij de 2036 ... zelfs niet als ik hem instel op 31 dec 2036 23:59 ...

wodan
24-12-13, 14:09
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!
Heeft te maken met het feit dat men de datum anders opslaat onder windows... Was al "opgelost" denk ik sinds NT 4.0 ...

zwellever
24-12-13, 14:10
M'n samsung laptop op 1 oktober 2039 ingesteld,na twee minuten een vage storingsmelding en uitgelogd van een paar site's;toch maar weer gauw terug gezet op 2013 :)

jobs
24-12-13, 15:01
Het 32-bit probleem en tellen vanaf 1970 is veelal een UNIX-issue.
Gelukkig is men zich erg bewust van deze situatie en is er nog enige tijd om het te fixen.
64-bit architecturen helpen een beetje. :-)

Raycoupe
24-12-13, 15:31
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

jobs
24-12-13, 15:40
Hihi, zie http://en.wikipedia.org/wiki/Ext4#Features en dan Improved timestamps.
Een deel van het probleem is dus al opgelost...

martin
24-12-13, 17:30
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.

f150
24-12-13, 18:31
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;)

FincaInSpanje
25-12-13, 05:24
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.

vdwalle
25-12-13, 09:27
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