mboost-dp1
newz.dk
Det sjove ved Y2K er hvad nu hvis man ikke havde gjort noget, hvor meget ville der så være sket. Jeg er ikke et sekund i tvivl om at der blev lavet mange test setups, mange opdateringer osv. inden "braget"...
Til newz crew...
Kunne man ikke lave et link, så man kunne se alle nyheder der var skrevet i den uge for alle de seneste år, så man lige hurtigt kan få et overblik?
Til newz crew...
Kunne man ikke lave et link, så man kunne se alle nyheder der var skrevet i den uge for alle de seneste år, så man lige hurtigt kan få et overblik?
Ang. Y2K, så har jeg læst flere beretninger på www.digg.com om programmører og andre godtfolk, som er lidt trætte af, at Y2K bliver kaldt for 'pjatværk' osv.
For de brugte alle flere hundreder timer på at patche systemer, og gøre alt klar til skiftet, de burde få noget mere credit.
For de brugte alle flere hundreder timer på at patche systemer, og gøre alt klar til skiftet, de burde få noget mere credit.
SlettetBruger (8) skrev:Y2K er ikke før 2048 drenge ^^ 1K = 1024
Der kommer en før: 19. januar 2038!
For der render signed integer i unix timestamp ind i "muren", nemlig 2147483647.
Der var en y2k10 ved nytår faktisk.
Visse windows mobiles modtager nu SMSer fra 2016, Nintendo Wii der var tændt nytårs aften ved skiftet crashede og genstartede. samt flere lign. ting.
Hvorfor har jeg glemt men der var en nyhed om det.
Men som #9 siger så får vi først rigtigt et problem i 2038, et virkeligt stort problem :P
Visse windows mobiles modtager nu SMSer fra 2016, Nintendo Wii der var tændt nytårs aften ved skiftet crashede og genstartede. samt flere lign. ting.
Hvorfor har jeg glemt men der var en nyhed om det.
Men som #9 siger så får vi først rigtigt et problem i 2038, et virkeligt stort problem :P
#y2k
Der var et problem. Og det problem blev løst. Hvis man ikke havde gjordt noget, så havde der været et hav af rapporter som sagde 1900 i.s.f. 2000, et hav af utilfredse brugere som var rasende over at deres form blev ved med at fortælle dem at årstallet ikke var validt o.s.v..
Det der gøres nar af er at problemet blev blæst op til at kunne betyde den civilizationens undergang. Alt kunne bare holde med at fungere. De virkelige problemer var noget mere trivielle. Men det var rigtigt godt for beskæftigelsen blandt konsulenter med Cobol & PL/I ekspertise.
Der var et problem. Og det problem blev løst. Hvis man ikke havde gjordt noget, så havde der været et hav af rapporter som sagde 1900 i.s.f. 2000, et hav af utilfredse brugere som var rasende over at deres form blev ved med at fortælle dem at årstallet ikke var validt o.s.v..
Det der gøres nar af er at problemet blev blæst op til at kunne betyde den civilizationens undergang. Alt kunne bare holde med at fungere. De virkelige problemer var noget mere trivielle. Men det var rigtigt godt for beskæftigelsen blandt konsulenter med Cobol & PL/I ekspertise.
#12 well synes da også resume også underdriver det, synes da vi stod med reelle store problemer, både i den virksomhed jeg supporterede og når man så at sygehuses systemer gik ned, så har det da berettigelse - og helt enig i at hvis det ikke var blevet omtalt, så var det da helt sikkert gået meget værre end det gjorde.
Men for at citere i en anden newz tråd, så havde folk måske også lidt overdrevet frygt hehe
Men for at citere i en anden newz tråd, så havde folk måske også lidt overdrevet frygt hehe
http://newz.dk/ti-aar-med-uheldige-teknologiske-oejeblikke skrev:Y2k var en tossestreg; jeg har ikke hørt om en eneste vaskemaskine, som gik postal og begyndte at æde småbørn,
#10 Jep, det var der.
Et større problem end SMSer er at mange brugere af betalingskort i Tyskland og Australien, her opdaget at deres kort bliver afvist fordi det er udløbet. Og problemer at systemerne der håndtere betalingskort ikke håndtere årstal efter 2009 korrekt.
Jeg kunne forestille mig at der var mange der stod med tømmermænd og forsøgte at betale taxaen eller betale for pizzaen i starten af dette år. Og så ikke var i stand til det. Og de kunne ikke engang låne penge af andre fordi alle betalingskort er udløbet.
Heldigvis er det lettere at distribuere opdateringer i dag, sammenligner med mange systemer man brugte for 10 år siden. Dengang var der rigtig mange systemer der krævede fysisk adgang af en teknikker for at opdatere. I dag kunne de fremstille og distribuere et midlertidig patch i løbet af 3 dage.
Et større problem end SMSer er at mange brugere af betalingskort i Tyskland og Australien, her opdaget at deres kort bliver afvist fordi det er udløbet. Og problemer at systemerne der håndtere betalingskort ikke håndtere årstal efter 2009 korrekt.
Jeg kunne forestille mig at der var mange der stod med tømmermænd og forsøgte at betale taxaen eller betale for pizzaen i starten af dette år. Og så ikke var i stand til det. Og de kunne ikke engang låne penge af andre fordi alle betalingskort er udløbet.
Heldigvis er det lettere at distribuere opdateringer i dag, sammenligner med mange systemer man brugte for 10 år siden. Dengang var der rigtig mange systemer der krævede fysisk adgang af en teknikker for at opdatere. I dag kunne de fremstille og distribuere et midlertidig patch i løbet af 3 dage.
#17
Det der egentligt er til grin heri, er at udviklerne simpelthen ikke havde hjerne nok til at gennemskue at det er rimeligt skidt at gemme aar i 2 cifre.
Helt aerligt, det blev blaest op fordi folk slamkodede fuldstaendigt vildt -.-
Unix timestamps og 19. nov. 2038, det er et problem jeg kan forstaa, men igen - et problem der naturligt afloeses naar time_t skifter til 64bit ;)
Y2K .. LOL :D
Det der egentligt er til grin heri, er at udviklerne simpelthen ikke havde hjerne nok til at gennemskue at det er rimeligt skidt at gemme aar i 2 cifre.
Helt aerligt, det blev blaest op fordi folk slamkodede fuldstaendigt vildt -.-
Unix timestamps og 19. nov. 2038, det er et problem jeg kan forstaa, men igen - et problem der naturligt afloeses naar time_t skifter til 64bit ;)
Y2K .. LOL :D
fidomuh (22) skrev:
Unix timestamps og 19. nov. 2038, det er et problem jeg kan forstaa, men igen - et problem der naturligt afloeses naar time_t skifter til 64bit ;)
Hvorfor er det lige at Unix får problemer lide denne specifikke dato?
ysangkok (24) skrev:fordi det er 2147483647 sekunder siden 1. januar 1970. Og der kan ikke være mere i 32-bit registre
signed 32 bit
ysangkok (24) skrev:så tiden vil wrappe rundt og du vil ikke kunne se forskel på 1970 og 2038
Den wrapper ikke til 0 men til -2147483648, så enten giver det fejl eller bliver opfattes som 1902.
fidomuh (22) skrev:
Det der egentligt er til grin heri, er at udviklerne simpelthen ikke havde hjerne nok til at gennemskue at det er rimeligt skidt at gemme aar i 2 cifre.
Helt aerligt, det blev blaest op fordi folk slamkodede fuldstaendigt vildt -.-
Hvem har bildt dig ind at plads ikke var et problem dengang mange af 2 cifre i år programmerne blev skrevet?
fidomuh (22) skrev:Unix timestamps og 19. nov. 2038, det er et problem jeg kan forstaa, men igen - et problem der naturligt afloeses naar time_t skifter til 64bit
De fleste *nix systemer har allerede skiftet til 64 bit time_t (ihvertfald i 64 bit mode).
Men der skal nok være en enkelt eller to MySQL tabel med en INT kolonne som gemmer unix tid.
#26
Paastaar du at plads var et problem af den stoerrelse tilbage i '98?
Eller i win2000, fx?
- Det var ikke i 1995 det her skete - og selv jeg havde plads paa min davaerende Amiga.
Exactly.
Joda, det goer utroligt mange udviklere i hvert fald, heldigvis er det 100% ligegyldigt, da integer meget, MEGET nemt tolkes til 64bit.
Fx:
32bit integer: 2147483647
64bit integer: 2147483648
Easy peasy.
Selvfoelgelig skal der laves om i den maade det lagres paa, men det er samme system der fortolker dataen der skal ud ( i MySQL tilfaelde ), saa det er utroligt nemt faktisk.
Og i langt de fleste tilfaelde, boer det vaere utroligt nemt :)
Uanset om 64bit integers fylder mere eller ej :P
Hvem har bildt dig ind at plads ikke var et problem dengang mange af 2 cifre i år programmerne blev skrevet?
Paastaar du at plads var et problem af den stoerrelse tilbage i '98?
Eller i win2000, fx?
- Det var ikke i 1995 det her skete - og selv jeg havde plads paa min davaerende Amiga.
De fleste *nix systemer har allerede skiftet til 64 bit time_t (ihvertfald i 64 bit mode).
Exactly.
Men der skal nok være en enkelt eller to MySQL tabel med en INT kolonne som gemmer unix tid.
Joda, det goer utroligt mange udviklere i hvert fald, heldigvis er det 100% ligegyldigt, da integer meget, MEGET nemt tolkes til 64bit.
Fx:
32bit integer: 2147483647
64bit integer: 2147483648
Easy peasy.
Selvfoelgelig skal der laves om i den maade det lagres paa, men det er samme system der fortolker dataen der skal ud ( i MySQL tilfaelde ), saa det er utroligt nemt faktisk.
Og i langt de fleste tilfaelde, boer det vaere utroligt nemt :)
Uanset om 64bit integers fylder mere eller ej :P
fidomuh (28) skrev:
Paastaar du at plads var et problem af den stoerrelse tilbage i '98?
Eller i win2000, fx?
- Det var ikke i 1995 det her skete - og selv jeg havde plads paa min davaerende Amiga.
Nej.
Problemet ville slå til i 2000.
Men årsagerne til problemet lå meget tidligere. Tidligere end 2000 og tidligere end 1995.
Flade filer, ISAM filer, databaser oprettet i 70'ene og 80'erne brugt af Cobol, PL/I of Fortran programmer.
Dengang 64 KB var meget memory og en 2.5 MB disk var dyr.
Fidomuh 2010:
s/32bit/2 cifre/w
s/64bit/4 cifre/w
s/2147483647/99/w
s/2147483648/100/w
s/MySQL/VSAM/w
Cobol programmør L. Iste 1985:
Joda, det goer utroligt mange udviklere i hvert fald, heldigvis er det 100% ligegyldigt, da integer meget, MEGET nemt tolkes til 64bit.
Fx:
32bit integer: 2147483647
64bit integer: 2147483648
Easy peasy.
Selvfoelgelig skal der laves om i den maade det lagres paa, men det er samme system der fortolker dataen der skal ud ( i MySQL tilfaelde ), saa det er utroligt nemt faktisk.
Og i langt de fleste tilfaelde, boer det vaere utroligt nemt :)
Uanset om 64bit integers fylder mere eller ej :P
s/32bit/2 cifre/w
s/64bit/4 cifre/w
s/2147483647/99/w
s/2147483648/100/w
s/MySQL/VSAM/w
Cobol programmør L. Iste 1985:
Joda, det goer utroligt mange udviklere i hvert fald, heldigvis er det 100% ligegyldigt, da integer meget, MEGET nemt tolkes til 4 cifre.
Fx:
2 cifre integer: 99
4 cifre integer: 100
Easy peasy.
Selvfoelgelig skal der laves om i den maade det lagres paa, men det er samme system der fortolker dataen der skal ud ( i VSAM tilfaelde ), saa det er utroligt nemt faktisk.
Og i langt de fleste tilfaelde, boer det vaere utroligt nemt :)
Uanset om 4 cifre integers fylder mere eller ej :P
#29
Jow, vi kunne ogsaa stadig koere systemer fra 1971, det giver bare ikke saa meget mening.
Saa igen, hvilke systemer er det, der ikke burde faa den slags ting fikset, henover tiden?
OG hvilke systemer fik det IKKE fikset?
Ja, det er ( som min kammerat paapegede ) ofte et spoergsmaal om ligegyldighed, men hvis man tager sit softwareudvikling bare lidt serioest, burde man vel runde den slags problemer.
Det er nemt at sige den teknisk ansvarlige burde se det som et problem, men jeg skal da gerne indroemme at jeg i aar 1999 aldrig nogensinde ville forudse at det ville vaere et problem - enhver slamkoder kan da taenke sig til at 2 cifre i aarstal vil give problemer ved aartusindeskiftet ;)
#30
Hvordan er det nu, man ser software levetid idag?
Jeg forventer ikke at koere en uopdateret version af fx Debian Etch, om 10 aar.
Eller i 2038, for den sags skyld.
Faktisk tvivler jeg paa at jeg koerer Debian Etch nogen steder her om 3-4 maaneder, naar Sid kommer :P
Ja, det kan vaere svaert at opgradere en AS/400 bare saadan lige, men idag ( og for 10 aar siden ) burde man serioest have set det som en stoerre noedvendighed at faa noget der var mere fremtidssikret.
Jow, vi kunne ogsaa stadig koere systemer fra 1971, det giver bare ikke saa meget mening.
Saa igen, hvilke systemer er det, der ikke burde faa den slags ting fikset, henover tiden?
OG hvilke systemer fik det IKKE fikset?
Ja, det er ( som min kammerat paapegede ) ofte et spoergsmaal om ligegyldighed, men hvis man tager sit softwareudvikling bare lidt serioest, burde man vel runde den slags problemer.
Det er nemt at sige den teknisk ansvarlige burde se det som et problem, men jeg skal da gerne indroemme at jeg i aar 1999 aldrig nogensinde ville forudse at det ville vaere et problem - enhver slamkoder kan da taenke sig til at 2 cifre i aarstal vil give problemer ved aartusindeskiftet ;)
#30
Hvordan er det nu, man ser software levetid idag?
Jeg forventer ikke at koere en uopdateret version af fx Debian Etch, om 10 aar.
Eller i 2038, for den sags skyld.
Faktisk tvivler jeg paa at jeg koerer Debian Etch nogen steder her om 3-4 maaneder, naar Sid kommer :P
Ja, det kan vaere svaert at opgradere en AS/400 bare saadan lige, men idag ( og for 10 aar siden ) burde man serioest have set det som en stoerre noedvendighed at faa noget der var mere fremtidssikret.
fidomuh (31) skrev:Jow, vi kunne ogsaa stadig koere systemer fra 1971, det giver bare ikke saa meget mening.
Der er masser af systemer som har design eller endda kode fra 70'erne og 80'erne.
fidomuh (31) skrev:Saa igen, hvilke systemer er det, der ikke burde faa den slags ting fikset, henover tiden?
fidomuh (31) skrev:OG hvilke systemer fik det IKKE fikset?
De fleste fik det fixet i løbet af 98 og 99.
Mere eller mindre fikst. Der var enkelte som fik problemer her til nytår fordi de havde hacket en løsning som bare flyttede problemet fra 2000 til 2010.
fidomuh (31) skrev:Hvordan er det nu, man ser software levetid idag?
Kode og design forventer man typisk vil eksistere i 20-40 år.
fidomuh (31) skrev:
Jeg forventer ikke at koere en uopdateret version af fx Debian Etch, om 10 aar.
Eller i 2038, for den sags skyld.
Faktisk tvivler jeg paa at jeg koerer Debian Etch nogen steder her om 3-4 maaneder, naar Sid kommer :P
Opdateret software er ikke nok til at undgå den slags problemer. Man redesigner ikke alt og omskriver al kode for hver ny version.
Hvis du prøver at kigge lidt på indholdet af seneste Debian, så vil du finde en masse meget gammelt design og gammel kode.
De centrale dele af kernel API er fra 1991.
Low level GUI API og protokol er fra 1985.
De fleste af dine shell kommandoer og utilities fra to sæt switche - de korte som er tilbage fra først i 70'erne (da Unix kørte på PDP-7 og PGP-11) - og de lange som jeg mener stammer fra GNU sidst i 80'erne.
Din Emacs editor har design tilbage fra 1976 og kode tilbage fra 1985.
Problemer bliver først med over i nye versioner indtil nogen fixer dem.
#32
Design er ligegyldigt ( medmindre designeret er snaevertsynet ), kode? Joh. Kode der breaker ved aarsskifte? Naeppe.
Mit bud er, at langt de fleste fik det fikset langt tidligere.
Navnligt at stort set alt kode produceret efter 95 havde det fikset fra foedslen.
Failtastic :)
OK, det var saa en del over hvad jeg forventer.
Design, mjoh, kode? Haaber jeg ikke.
Der staar ikke 1985 paa kalenderen idag, btw :)
Selvfoelgelig ikke, min pointe er, at problemer som disse, boer loeses som en naturlig del af software opdateringen - ikke som et "ZOMG NOBODY THOUGHT OF THAT!"-hack, som falder fra hinanden 10 aar efter ...
Og hvor meget af det doede ved aar 2000-skiftet?
SMTP er aeldre, btw.
Jada, fundamentale problemer bliver typisk fikset loebende, eller udskiftet med afloesende software.
Design holder fint i lang tid, naar der ikke er design-fejl som fx aar 2000 skiftet, min pointe er at software skal vaere designet ordentligt fra starten af, at genbruge crap der falder fra hinanden imorgen, er bare dumt. :)
Jeg er desvaerre ikke saerligt kyndig som programmoer, men selv jeg ved da, at der er nogen ting man bare ikke maa springe over det laveste gaerde med :P
Der er masser af systemer som har design eller endda kode fra 70'erne og 80'erne.
Design er ligegyldigt ( medmindre designeret er snaevertsynet ), kode? Joh. Kode der breaker ved aarsskifte? Naeppe.
De fleste fik det fixet i løbet af 98 og 99.
Mit bud er, at langt de fleste fik det fikset langt tidligere.
Navnligt at stort set alt kode produceret efter 95 havde det fikset fra foedslen.
Mere eller mindre fikst. Der var enkelte som fik problemer her til nytår fordi de havde hacket en løsning som bare flyttede problemet fra 2000 til 2010.
Failtastic :)
Kode og design forventer man typisk vil eksistere i 20-40 år.
OK, det var saa en del over hvad jeg forventer.
Design, mjoh, kode? Haaber jeg ikke.
Der staar ikke 1985 paa kalenderen idag, btw :)
Opdateret software er ikke nok til at undgå den slags problemer. Man redesigner ikke alt og omskriver al kode for hver ny version.
Selvfoelgelig ikke, min pointe er, at problemer som disse, boer loeses som en naturlig del af software opdateringen - ikke som et "ZOMG NOBODY THOUGHT OF THAT!"-hack, som falder fra hinanden 10 aar efter ...
Hvis du prøver at kigge lidt på indholdet af seneste Debian, så vil du finde en masse meget gammelt design og gammel kode.
Og hvor meget af det doede ved aar 2000-skiftet?
De centrale dele af kernel API er fra 1991.
Low level GUI API og protokol er fra 1985.
SMTP er aeldre, btw.
Problemer bliver først med over i nye versioner indtil nogen fixer dem.
Jada, fundamentale problemer bliver typisk fikset loebende, eller udskiftet med afloesende software.
Design holder fint i lang tid, naar der ikke er design-fejl som fx aar 2000 skiftet, min pointe er at software skal vaere designet ordentligt fra starten af, at genbruge crap der falder fra hinanden imorgen, er bare dumt. :)
Jeg er desvaerre ikke saerligt kyndig som programmoer, men selv jeg ved da, at der er nogen ting man bare ikke maa springe over det laveste gaerde med :P
fidomuh (33) skrev:Design er ligegyldigt ( medmindre designeret er snaevertsynet )
Det er ofte designet som fastlægger datastrukturene.
fidomuh (33) skrev:Mit bud er, at langt de fleste fik det fikset langt tidligere.
Det var først da det kom tæt på, at flertallet gik i gang med at rette gammel kode.
fidomuh (33) skrev:Kode og design forventer man typisk vil eksistere i 20-40 år.
OK, det var saa en del over hvad jeg forventer.
Design, mjoh, kode? Haaber jeg ikke.
Jeg har allerede givet adskillige eksempler på design som har overlevet i mange mange år.
Kode bliver også ældre end man tror.
fidomuh (33) skrev:Og hvor meget af det doede ved aar 2000-skiftet?
Ingen af de ting jeg nævner gav så vidt jeg ved anledning til y2k problemer.
Det var kun eksempler på gammelt design/kode.
Så vidt jeg ved havde Linux kernel ikke brug for y2k patches.
Men en del af de applikationer som kommer med en Debian distro fik lavet fixes.
fidomuh (33) skrev:min pointe er at software skal vaere designet ordentligt fra starten af, at genbruge crap der falder fra hinanden imorgen, er bare dumt.
Det er lidt mere komplekst end bare "gør det ordentlig". Der er nogen gange tradeoffs. Dem der said i 80'erne og lavede en Cobol app skulle vælge om de skulle bruge ekstra disk og memory eller have et potentielt problem om 10-20 år.
Man kan ikke tage højde for alt.
Skal man f.eks. tage højde for http://en.wikipedia.org/wiki/Year_10,000_problem ?
Næppe men hvor sætter man så grænsen ?
Opret dig som bruger i dag
Det er gratis, og du binder dig ikke til noget.
Når du er oprettet som bruger, får du adgang til en lang række af sidens andre muligheder, såsom at udforme siden efter eget ønske og deltage i diskussionerne.
- Forside
- ⟨
- Forum
- ⟨
- Nyheder
Gå til bund