Irland overhaler dansk Rejsekort

Så sidder jeg herovre i Dublin og læser denne nyhed.
Det fremstår jo nærmest som om at RPA og Transport 21's IBM løsning er gået smertefrit og effektivt.
Det eneste vi har kunnet læse i aviserne om det projekt det seneste år er nu at det er ved at være 5 år forsinket, budgetet er overskredet med ca. €20 mil. De første tanker om det projektet startede i 1999 med en deadline sat til 2005, og skulle koste lige knapt €30 mil. Nu er det oppe på €50 mil.
Den historie er knap så rosenrød... men lad os da håbe at IBM kan gøre det effektivt for det trænger vi virkelig til herovre... det er dødens pølse at skulle skifte fra tog, bus, sporvogn osv. og købe nye billetter hvergang... eller at dit månedskort til sporvognen ikke duer på bussen, hvis nu man lige skal en anden retning den dag....
Et link hvis nogen er interaseret: http://archives.tcm.ie/ (...)

For nogle år siden, blev brugt magnetstribe på dankortet. Reelt, var den helt uden kryptering. Informationerne på magnetstriben, var de samme, som dem der stod på kortet - plus en ekstra tjek ciffer, der kunne regnes ud som for CPR numre. Magnetfeltet, kunne aflæses med en simpel aflæser.

Alligevel, blev hævdet at systemet var sikkert. Og det holdt da også mange år, inden systemet måtte udstyres med chip.

Nu kommer snart rejsekortet - der i sikkerhed, måske er over dankortet, da det havde magnetstrimmel. Vi har i mange år, kunnet klare os helt uden kryptering - er kryptering virkeligt så vigtigt?

Naturligvis, kan kryptering øge sikkerheden. Men, bør man ikke, gå efter at ikke satse på kryptering, men på et system, der vil have været sikkert, trods selveste koden kunne aflæses ved at oplæse cifrene på kortet? Kryptering, er hidtil altid blevet brudt.

Vi er i dag blevet vandt til, at computere er ustabile og fejler. Er dette virkeligheden? For mange år siden, programmerede vi i simpel Basic, og dette kunne sagtens løse problemer, der svarede til rejsekortet. Det tog kun få dage at kode, og det var ikke nødvendigt med fancy operativsystemer - basic kørte selv uden OS. Faktisk, havde de fleste computere basic som OS.

Hvad skal der egentligt til, for at få en chip til at fejle, og for at få aflæsningen til at gå galt i byen? Som jeg ser det, må det være pokkers besværligt at opnå, uden det ses af koden.

Naturligvis kan der være problemer med den trådløse overførsel - men så snart kortet er aflæst, burde der ikke være yderligere stabilitetsproblemer. Giver aflæseren således et "beep", skulle det være sikkert, at den er aflæst. Giver den ingen beep, ved kunden, at man skal føre den tættere på indtil den giver beep. Og så er det i orden.

Helt ærligt - hvad er problemet? Jeg tror, at de kære programmører hælder problemer i, der ikke eksisterer, alene for at gøre det kompliceret, og kan trække store summer ind på lønkontoen. Måske burde politiet undersøge dyre software skandaler?

Selvom der sættes store virksomheder til at kode "skidtet", så tvivler jeg ofte på deres kompetancer. Spørger du dem, hvad der sker, hvis du ændrer data i et register på CPU'en, lader den pludseligt hoppe til et tilfældigt sted, eller på anden måde "gør" noget, som kunne ske på grund af hardwaren ved en fejl - så har de sjældent klaret problemet. Tilbage i 80'erne, da der var 20 basic ordre indbygget i de industrielle systemer, havde fortolkeren indbygget fejlretning, således at en lampe lyste, hvis en indstruktion blev udført forkert, og vedblev at lyse permanent. Samtidigt blev fejlen rettet, evt. ved at søge at køre den pågældende stump kode igen. Og handlers, blev kaldt, for at tage hånd om eventuelle hardwarefejl, hvis personale skulle tilkaldes.

Når jeg taler med "nutidens" programmører, så er kompetancerne "java". De fatter ikke et hak, omkring hardware, omkring sikkerhed, og omkring hvordan der laves systemer, hvor bitfejl og ramfejl ikke går ud over udførslen. De går ikke udfor at anvende metoder der ikke fungerer, og har ingen kvalitetssans.

De færreste programmører, fatter meget, om datalogi, og jeg må indrømme at jeg tror det er noget helt galt indenfor undervisningen, og indenfor branchen. Selv dem der laver operativsystemer, og compilere, synes ikke at vide noget om hvordan en cache fungerer, hvad store O funktioner er, og hvordan man opbevarer data, på en måde, så de kan findes igen. Jeg skal tilbage til 80'erne, før jeg så, at der var angivet data såsom ramforbrug, og store O funktioner, for de indbyggede operationer og biblioteker til compilere. Dengang, var ikke tilladt med linære søgninger osv. i ordrene, da det ofte var for langsomt, f.eks. i forbindelse med strengbehandling. F.eks. brugte man ikke nulterminerede strenge, der viste sig ofte at have dårligere store O funktion.