Morten Bøgh

Fem myndigheder under lup: Ingen efterlever minimumskrav til it-sikkerheden

Nordic Choice Hotels har ikke skiftet til Chrome OS. De har skiftet på client-siden (dvs. hotellerne) til Chrome OS, mens de centrale systemer (reserveringssystem etc.) stadig kører under Windows. Så de har dermed fundet et 21. punkt: Autorisations-systemer i client-siden bør være forskellig fra autorisation i de centrale systemer. Konkret at man skal undgå at almindelige brugere er oprettet i Windows Active Directory, så at phishing/malware kan komme ind via en sådan 'almindelig' brugerkonto i Active Directory, og derfra kan eskalere sine adgange indtil man har magt over systemet. Det er en mere radikal tilgang end de sædvanlige mere-af-det-samme punkter: Mere logning, mere virus-værn, etc. Det er i stedet ligesom mainframe-modellen, ifølge hvilken Windows-brugere (eller deres hackere) har meget svært ved at eskalere deres adgangsrettigheder ind i de centrale systemer (da disse på mainframe styres med RACF og ikke med Active Directory). 'Security by obfucation' kan også indgå: Hackere mod Nordic Choice Hotels får et sværere liv, når man først skal hacke ind i Chrome OS, og herfra hoppe til Windows. Hvis hackerne direkte vil ramme Active Directory, skal de lave social engineering mod udviklere og systemadministratorer, og ikke 'bare' mod brugere.

Det her er ikke bare noget Petter Stordalen og hans hoteller synes er smart at sige for at understrege deres seriøsitet : Det er den konkrete reaktion på en alvorlig phishing hændelse. Og der ligger ikke nogen antagelse om at Chrome OS er sikkerhedsmæssig bedre end Windows. Kan være så, men pointen er en anden.

Artiklen i digi.no anbefales også herfra.

18. januar kl. 14:49
Gudskelov det var 2020

Ubetinget tak for en skarp og rigtig vinkel på et emne som i forvejen har afstedkommet milliarder af synspunkter. Den positive vinkel , på et år som har været aldeles forfærdeligt, er ...

29. december 2020 kl. 16:29
Ambitiøs finanslov – umuligt it-projekt?

Version 2 har tidligere bragt en henvisning til et speciale fra IT-universistetet 'Service orienteret arkitektur eller fælles database'. De 34 sider handler også om meget andet, men der cirkles en del omkring it-arkitekturen bag Motorregistret (som ihvertfald ikke var præget af 'fælles database'). En stor fornøjelse at læse fordi den uskyldige studerende kan udtale sig frit om kejserens påklædning eller mangel på samme - i modsætning til os andre som har lært at udtrykke os mere diplomatisk og strategisk.

http://www.itu.dk/people/slauesen/Papers/ServiceOrienteretArkitekturEllerFaellesDatabase.pdf

Her kan man bl.a. læse, at kravspecifikationen på det oprindelige Motorregister udbud var på 16.000 sider. Og at den valgte arkitektur gav pænt store udfordringer. Det sidste kunne vel evt. fortsat spille ind.

10. december 2020 kl. 22:11
Skats it-værn mod milliardsvindel med udbytteskat har lange udsigter

‘Legacy’ systemet i denne forbindelse må være ‘Aktiehandels-systemet’ som er en del af Skats ‘TastSelv’-løsning overfor skatteyderne. Systemet blev lanceret i etaper omkring 2015, og det bygger på en DB2-database, som håndteres via kodning i Java og Cobol. Systemets kærne kører på mainframe. Systemet udgør Skats nuværende integration med VP-securities. Undertegnede var i sin tid med til at bygge det.

Men hvad betyder legacy? Begrebet stammer fra den hemmelige ‘Legacy Rapport’ som Skat fik udarbejdet i 2018 - men da den altså er hemmelig, har offentligheden ingen mulighed for at følge og kontrollere argumentationen. Dvs. hvad der gør ‘Aktiehandels-systemet’ til et legacy-system (og hvad Skats definitionen er på et legacy system er), kan man frit fabulere om, ordet kan betyde hvad som helst.

Men jeg kan komme med et hint: Et legacy-system er et system som ikke er blevet udviklet i en udbudssat proces. Følg blot forløbet som startede med ‘Computerworld’s 2015 - 2016-artikelserie om manglende udbud af de centrale systemer i Skat, og som fortsatte med Rigsrevisionens og Kammeradvokatens reaktioner herudfra i de følgende år, og denne konklusion fremstår som ganske åbenbar: EU’s udbudsregler udgør et alvorligt problem som Skat må håndtere. Og håndteringen må kun undtagelsesvis involvere knopskydning i eksisterende ikke-udbudsatte systemer. Der ligger formentlig andre tanker i Skats legacy-begreb, men det ændrer ikke denne konklusion.

Og ja, det er også for galt: 'Aktiehandels-systemet' blev i sin tid udviklet efter regning, og uden indledende udbudsfase. Sådan spiller klaveret ikke længere, og der kan dermed næppe videreudvikles på dette system.

Dvs. det reelle problem kan vel beskrives sådan: Udbudsprocesen er tidskrævende, og udbudssætning kræver at det nye system er løst koblet til det eksisterende, dvs. kommunikation bliver et væsentligt og tidskrævende problem. Det mest tidskrævende er dog, at den viden der ligger i den nuværende system (begrebsmodel etc.) skal tilbageføres til Skat, og herfra videreoverføres til den nye leverandør via udbudsprocesen. Beskrevet sådan, bliver Skatteministerens meget langagtige tidsramme her i artiklen forståelig. Men i mere it-faglige forsøg på at forstå legacy-begrebet, bliver det mystisk: Et system fra 2015 er næppe præget af hulkort og magnetbånd, og alle de systemer som Skat i dag betegner som ‘Legacy’ er vel næppe alle præget af samme kærlige forhold til spaghetti-kodning og forældede databasesystemer.

10. juli 2020 kl. 09:33
C blev årets programmerings­sprog i 2019

Bemærk at SQL sproget er off-topic i denne diskussionstråd og i Wikipedia artiklen om paradigmer:https://da.wikipedia.org/wiki/ProgrammeringsparadigmeEn tilsvarende engelsk Wikepedia artikel holder sig til nogenlunde samme opdeling. SQL er åbenbart hverken imperativt, funktionelt, objektorienteret eller logikbaseret. En interessant (men tung) artikel som får sagt noget om SQL ud fra dets slægtskab til og forskelle fra objektorienteret:https://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

Det hele siger noget om forskellen på teori og virkelighed: SQL er formentlig det vigtigste programmeringssprog i den del af IT-verdenen der tager sig af at håndtere virkelige ressourcer: Reservationer af lejligheder og biografbilletter, håndtering af penge og ting, fabrikation af biler og skumfiduser, klimaforskning, vindmølleoptimering, nummerpladeskanning… Alle steder hvor der bruges en database, og dermed er brug for et sprog der kan håndtere databasen: Nemlig SQL. Altså kærnesystemerne bag de grafiske brugergrænseflader. Men i ‘den datalogiske verden’ eksisterer SQL åbenbart kun som et irriterende fænomen som giver strukturkonflikter i forhold til objektorienteret programmering. Stort set...

SQL er et diktat-sprog: 'Giv mig saltet', 'Minsk lønnen for rødhårede med 10%'. Det kan således ikke stå alene, men indbages typisk i et sprog som er i stand til at beskrive en sekvens af handlinger og selektioner. Det gør SQL vanskeligt at begribe teoretisk: to sprog der filtres ind i hinanden. Men det fungerer i praksis.

17. januar 2020 kl. 18:25
Efter ti år med mikrotjenester gør chefudvikler status: Småt er godt, men ...

Jeg forsøgte i mit indlæg at komme et spadestik dybere end hr chefudvikleren, Tomer Gabel: De problemer han ser ved microservices hænger sammen med et ganske bestemt forhold i den fysiske virkelighed: Commit-spaces. Hvis vi skal endnu dybere - og det skal vi åbenbart - så rummer den fysiske virkelighed to måder at koble selvstændige commit-spaces sammen: nemlig asynkron og synkron sammenkobling. Her gælder kort fortalt at asynkron er absolut sikker, commit-mæssig, men er langsom, og umuliggør at brugeren ved skærmen får en bindende besked om hvad der er sket. Den synrone er ikke sikker, men er hurtig. 'Hurtig' har mindre med fysisk hastighed at gøre, men mere med det forhold, at den synkrone kommunikation muliggør en stribe logisk sammenhængende handlinger i den 'oprindelige' microservervice indenfor samme commit-space. Mens asynkron forudsætter at den 'oprindelige' microservice udfører commit inden underliggende microservices commit'er.

Ja, banker kobler i vore dage deres kontohåndtering i forskellige banker absolut sikkert sammen via asynkron sammenkobling. Nej, verden kan ikke køre på én stor mainframe, det er også rigtigt.

Et eksempel: Det viser sig at bankkonto 'Y' i vores microbank-2 blev lukket for 3 microsekunder siden. Kontooverførslen kan ikke gennemføres. Vi kører med asynkron kommunikation. Dvs microbank-1 committer at der er hævet 10 kr fra konto 'X', men erfarer så efterføgelgende at pengene er endt på en fejl-opsamlingskonto i microbank-2. Transaktionen er reelt ikke gennemført. Dette kan så efterfølgende sorteres ud, men dialogmæssigt er det noget rod. Hvis vi i stedet brugte synkron kommunikation ville dialogen kunne svare korrekt i situationen: Du prøver at overføre til en konto som er lukket, prøv noget andet. Men sikkerheden mangler: Hvis microbank-2 svarer 'ok', er dette ikke troværdigt: microbank-2 kan være gået i dørken efter svaret er givet, og inden pengene faktisk er sat ind på konto-X. Derfor bruger bankerne altid asynkron sammenkobling.

Mit uvenlige håndtering af 'nutidens IT-arkitekter' skyldes dog ikke, at de alle har misforstået ovenstående. Det har de sikkert ikke. Problemet er deres manglende evne til at skelne mellem kærnesystemer og garniture i brugergrænsefladen. Et 'stort' kærnesystem opbygget omkring en SQL-base med en fælles commit-manager, er eneste løsning på ovenstående dilemma. Kærnesystemer bør være en del af arkitektens værktøjskasse, men er det typisk ikke. Det synes jeg godt Tomer Gabel kunne tænke lidt over.

15. november 2019 kl. 06:56
Efter ti år med mikrotjenester gør chefudvikler status: Småt er godt, men ...

Ja, det er altid en god ide at observere fysikkens love: tyngdeloven etc. Hvorvidt man skal overholde dem, behøver man ikke overveje, det læres den hårde vej hvis man ignorerer dem. Referatet ovenfor cirkler rundt og rundt omkring det uløselige problem ved microservices: At services ikke kører i et fælles commit-space, og at der derfor ikke er styr på fx det klassiske bankproblem: Service A trækker 10 kr ud fra konto X, Service B skulle så have sat pengene ind på konto Y, men fejler. Resultatet: Banken vinder 10 kr. Det er 'bare et af livets fakta' ved distribuerede systemer, som det hedder i referatet ovenfor.

Rådet i referatet om for enhver pris at undgå SQL-databaser, fordi det binder services sammen - er grotesk. I stedet bør man åbenbart køre et kæmpe cirkus af logs for at checke at fejl er sket... Hvad med at erstatte alle disse logs med en veldesignet SQL-database som registrerer systemets hændelser (set i relation til systemets formål). Dels er det meget nemmere at håndtere, dels gør det at fejl kan forebygges (...fælles commit) i stedet for at kompenseres (eller undskyldes) i efterfølgende sagsbehandling.

Det hele afhænger af systemets og komponentens formål. En service som giver gode og dårlige råd om valg af den næste film i Netflix - den er så isoleret i scope, at den bør køre i sin egen microverden. Men et system som håndterer månedlig betaling i Netflix bør ikke bygges op af en stak af services.

Det er meget simpelt: Der er en afgrundsdyb forskel mellem et kærnesystem og diverse garniturer i brugergrænsefladen. Et kærnesystem handler om kontoføring af penge, og indgår derfor i de allerfleste IT-systemer. Det kan også være andre aspekter end penge, hvor absolut konsistens kræves. Et kærnesystem er bygget op omkring én og kun en sammenhængende SQL-database, dvs et system af SQL-tabeller. Ovenpå kærnesystemet kan man bygge så mange mikroservices man lyster, de skader ikke, og kan sikkert bidrage til en bedre brugeroplevelse og glade brugere.

Disse 'fysikkens love' har nutidens IT-arkitekter ofte forbavsende store vanskeligheder ved at forstå. Men: man lærer det før eller siden.

14. november 2019 kl. 17:10
Løsninger på problemer vi ikke burde have (længere)

Pointere i mainframe-programmel har sikkerhedsseler og airbags. Det havde maskinen allerede i 1980 da jeg startede med at arbejde med mainframe: Hvis en pointer ramte udenfor programmets 'adresseringsrum', dvs det område som trådens maskininstruktioner var blevet tildelt af operativsystemet, blev tråden slået ned af operativsystemet med en 0c4-exception. En overliggende tråd fik så kontrollen igen, men vejen i undertråden var spærret. Indenfor eget adresseringsrum er der fri leg, og et program der farer vild, kan smadre som det nu vil - indtil det bliver stoppet af en exeption. I de efterfølgende 40 år har forholdene inde i maskinen ændret sig radikalt. Tråde på mainframe kører i dag i sit eget adresseringsrum, og 0c4-teknikken er derfor lidt irrelevant. Omend man stadig kan have fornøjelse af en 0c4-exception hvis man roder i sine pointere. Man kan gerne på mainframe kalde ind i andre adresseringsrum, men dette er voldsomt reguleret af operativsystemet i form af services.

RACF sikkerhedssystemet på mainframe regulerer adgang til de data man måtte komme i kontakt med ved fx. at gå over i adresseringsrummet for DB2. Dette er i dag en mere væsenligt beskyttelse end 0c4-adresse-kontrollen.

Ovenstående gælder når man arbejder på mainframe med z/OS maskinkode. Man kan også køre mainframe under Unix og Linux, og så er man ude i det vilde vesten hvor pointere kan give eksotiske oplevelser, omend RACF stadig hersker.

12. november 2019 kl. 07:11
It-problemer for nyt skattesystem: Udskudt til 2024

Årsopgørelses-systemet - som er det største af legacy-systemerne, og som også er det mest omtalte i denne 'månelandingsårs-diskussion', har følgende tekniske karakteristika: Kærnesystemets grundlæggende design stammer fra 1992. Der er hvert år siden da er lavet et nyt (års) system med mere eller mere væsentlige ændringer, og dermed er det kun få principper fra 1992 der har overlevet til i dag. Systemet er programmeret i DB2 og COBOL. 95% af systemet er programmeret i COBOL-6, hvilket er nyeste COBOL version, lanceret ca. 2017, resten er i COBOL-4. Plus ca. 50 liniers assembler-kodning. Målt i maskintid, ligger dog langt den største del af kodningen i DB2. Der er ca. 1 million COBOL-kodelinier i systemet - pr år. Systemet kører på IBM mainframe. Ved siden af kærnesystemet kører en stor frontend ('TastSelv') programmeret i JAVA og DB2. Det er således ikke årsopgørelses-systemet der stammer fra månelandingsåret - det er Kildeskatteloven, som blev formuleret ved den lejlighed; ikke for at sende folk til månen, men for at muliggøre kildeskattesystemet. Og ja, dette forhold giver jo systemet nogle bindinger til hvad der var god latin i månelandingsåret.

11. november 2019 kl. 10:17
Brænd de offentlige udbud ned og start forfra

Jeg har haft fornøjelsen af at arbejde hos Datacentralen i en årrække. Det er en kær erindring om dengang , når Henrik Sørensen ovenfor forveksler 'Datacentralen' og 'Regnecentralen'. Ligesom dengang i 1980'erne: Hvis jeg stødte på venner og bekendtskaber efter nogen tids radiotavshed, så ventede jeg spændt på spørgsmålet: Hvordan har du det på Regnecentralen? Alternativ: Hvordan går det med dig på Kommunedata? Datacentralen var vel landets næst-største it-firma i perioder, og var alligevel helt utroligt anonymt. Hvem udviklede kildeskattesystemet, Danmarks mest revolutionerende it-system? Systemet som alle elskede at hade, Fremskridtspartiets grunddej? Svaret er: Datacentralen. Firmaet var 'Statens it'. Datacentralen levede godt og skjult. Privatisering af Datacentralen i form af CSC og senere DXC var et fornuftigt skridt i retning af fri konkurrence og større offentlig debat omkring hvad der foregår. Men juraen og poliitkernes unoder - og selvfølgeligt også vores egen, branchens, manglende evner til at ramme rigtigt på tastaturet når systemerne skal udvikles - har bragt nationen i det totale kaos hvor vi er nu. Fin debattråd her, meget relevant at harpe på udbudslovgivningen, den er noget skrammel i relation til IT.

Note til den yngre generation: Regnecentralen var et dansk firma som loddede transistorer sammen og byggede hardware plus basis-software. Firmaet havde en enorm offentlig bevågenhed og udgjorde op gennem 1970'erne Danmarks tro og håb om at indtræde i 'edb-alderen'.

5. november 2019 kl. 06:48
Tidligere skatteminister afviser kritik af gælds-system: »Rigsrevisionens faglighed er overraskende lav«

Det, jeg hører Karsten Lauritzsen sige, er at ganske vist er tidsplanerne for PSRM skredet i betænkelig grad, men ‘agile’ er en rigtig god måde at udvikle it-systemer på. Begge dele kan han have ret i, men argumentationen, sammenkædningen, er bagvendt: At fordi ‘agile’ er godt, er forsinkelser acceptable. Ude i samfundet ser man (forhåbentligt) mere på resultatet, end på karaktergivningen for kunstnerisk udførelse.

'Agile’ er ikke den hellige gral, eller er et begreb på niveau med opfindelsen af dåseøllet, men at rose metoden som legitimering af en forsinkelse, er et uskønt bagholdsangreb på metoden. Med sådanne venner…

Det hele bliver lidt Monte Python agtigt: Argumentationen er så snørklet, at man nok hellere skulle spole tilbage og finde en anden vinkel.

8. september 2019 kl. 09:28
Mainframen har for travlt til at dø

100.000 kr’s spørgsmålet er om mainframe kan noget som andre servertyper ikke kan. Jeg er tilbøjelig til at svare ‘ja’, men det er godt nok ikke nemt at komme med en dækkende argumentation. Og nedenstående er ikke en komparativ analyse af forskellige serverarkitekturer, men mere en vurdering af hvad mainframe kan - i et samspil med et matchende miljø omkring maskinen:

Mainframe er i min optik: En relativ stor SQL-database... At den er ‘stor’ ligger i at hele databasen arbejder under en fælles commit-mekanisme, med den sikkerhed i fejlhåndtering der ligger i dette. Dette i modsætning til en distribueret, serverbaseret database. Til at skabe procedural logik og forbinde de forskellige SQL-kald har man rådighed over et ikke-objektorienteret sprog: COBOL er her et udmærket bud. Grunden til at det bør være ikke-objektorienteret er, at ‘objekter’ er noget som findes i SQL-databasen, der er ikke klogt at opbygge egne applikations-specifikke datastores og objekthierarkier, og det er ikke klogt at køre filosofien ‘databasen er der hvor data befinder sig når lyset er slukket’. I et SQL fokuseret system befinder data sig altid i databasen, og under kontrol af commit-mekansimen, bortset fra i skabelsesøjeblikket: når den procedurale logik skaber eller modificerer objekter i databasen. Design af et godt mainframe system er meget fokuseret på design af databasen, alt andet underordnes denne. I øvrigt er syntaxen i SQL fremagende - i forhold til privatudviklede protokoller til acces af objekters egenskaber i et Java-setup.

Naturligvis kan man godt programmere i Java på mainframe hvis man overholder ovenstående. At arbejde i en service-orienteret arkitektur internt i sin procedurale kodning kan også have sine fordele, og her kan Java have sine styrker.

Helt fundamentalt er, at det der kører på mainframe, er kærnesystemet. Programmering af brugergrænsefladen bør af flere grunde ikke ske på mainframe: Det er for dyrt at køre det her, en server-baseret udviklingsplatform har bedre frameworks hertil, og det vigtigste: Processer i brugergrænsefladen har ikke glæde af at køre under én global commit-manager.

Under disse forudsætninger giver mainframe mening. Implicit i ovenstående ligger, at ens system bygger på et ‘stort’ sammenhængende kærnesystem. Kærnen i et sådant kærnesystem er næsten altid ‘financielle transaktioner’ altså at holde styr på pengestrømme.

Et alternativ til håndbyggede kærnesystemer er ERP-systemer, såsom SAP. Hvis ens logik passer perfekt ind i SAP er valget let, hvis ikke, kan det blive en kostbar oplevelse at vælge et ERP-system.

Så kan man i øvrigt mene hvad man vil desforuden: Fx at mainframe er for dyrt i afgifter til IBM, og at medarbejderne typisk både er for gamle og for dyre, og at værktøjssiden på mainframe er for gammel og for primitiv. Ja, jo, men…:

Prisen: IT som virker, er ofte dyrt. Pris er måske ikke altid helt afgørende, det afgørende er om systemet virker, og det afgørende dyre viser sig hvis det ikke virker. Erfaringer og statistik på dette område er et rædselskabinet.

Medarbejderne: Erfarne folk koster. Unge mennesker af bedste silicon valley aftapning koster også. Hvilke vidundere Google kan lave ved at tiltrække verdens bedste (unge) softwareingeniører har måske ikke så meget at gøre med hvordan man bør angribe udviklingen af kærnen i et administrativt system til Fiskeri og Kulturstyrelsen. Et mix af erfaring og ungdom er ofte et rimeligt bud. Herudover: Mainframe arbejder ikke med ‘full-stack’ udviklere. En mainframe er befolket af specialister, fx er database-tuning et emne for databaseadministratorer, ikke for systemudviklere. Et kostbart princip, men specialister ved ofte mere om deres emne end hvad generalister gør.

Værktøjssiden: Compuware og Chris O’Malley har sine bud på hvad der skal til. Muligvis fremragende, jeg ved det ikke. Selvudvikling af værktøjer har altid haft et betydeligt fokus i mit mainframe-liv. Hvilket ikke det billigste princip, men hvis det fungerer, kan man opnå stor parallellitet mellem problemer og løsningsmetoder. Og man kan i øvrigt komme meget på afstand af oplevelsen af mainframen som stiv, gammel og ufleksibel.

Konkluderende: Mainframe er et område for store modne organisationer med erhvervet fokus på just denne vinkel. Det lyder ikke umiddelbart spændende, men man kan ikke udelukke, at man på den måde kan udvikle IT som virker - også i de mere komplekse tilfælde. Men garantier gives ikke. Og mange mainframe systemer er i deres tilstand og videreudviklingsmuligheder ret langt fra ovenstående idealer.

12. juli 2019 kl. 23:32
Gamle it-systemer kan få nyt liv: Det har Rigspolitiet lært af Polsas og Polsag

Vi mangler en god forklaring på at ’Mainframe teknologi’ næppe kan vedligeholdes om 20 år. Alene tidsspændet i udtalelsen, gør det diffust. Hvis der kan konstateres et problem, må det da vise sig væsentlig hurtigere end ’om 20 år’. Modsat: Hvis der ikke er et problem i dag, hvorfor skulle der så dukke et op om 20 år? Er det ’de unge mennesker’ som i dag er lidt kræsne med hvad de vil beskæftige sig med; er de om 20 år blevet helt umulige? Er det den kritiske masse af mainframes som om 20 år har nået det lavpunkt hvor viden om systemet vil være ved at forsvinde? 85% af verdens finansielle transaktioner kører i dag på mainframe, Det kan ikke udelukkes at billedet er et helt andet om 20 år, men der er pt ikke meget som tyder på dette.

Det andet forklarings-problem er den rutinemæssige påstand om at mainframe er identisk med ’gammel teknologi’. Selve hardwaren i en mainframe er typisk ret ny. Det som så kører på denne teknologi: Mainframe operativsystemet (MVS) har aner som dateres tilbage til starten af 1970’erne. UNIX er af tilsvarende alder, hvilket ikke forhindrer Apple i at bruge UNIX som det grundlæggende operativsystem i sine computere. Det software som kører ovenpå hardware og MVS på en mainframe kan være af vekslende alder. Noget af det er i dårlig stand, fordi mange års rettelser har resulteret i den så omtalte ’spaghetti’: rodet kodning. Dette har intet med ’gammel teknologi’ at gøre. Brugergrænseflade-programmering hører ikke hjemme på en mainframe. Det er kærnesystemet som kan/bør være hjemmehørende her.

Man kan sammenligne med Windows: På Windows gælder som bekendt at hvis ens software ikke hopper med på de løbende Windows releases, så er man forbavsende hurtigt henvist til at køre sit system i et dos-vindue. Windows software forældes virkeligt hurtigt. Det forholder sig modsat på Mainframe: Software udviklet til mainframe i 1980’erne kan køre på maskinen i dag uden problemer. Dette lægger nærmest op til en modsat konklusion: Om 20 år er alle nutidens Windows programmer døde (og erstattet af noget andet), mens mainframen kører videre – med gammelt og nyt programmel. Og: Ud over gammelt og velprøvet programmel på mainframe, så kan rimeligt tidssvarende konstruktioner med J:son, XML og SQL køre i 64 bits adressering på en mainframe, gerne bundet sammen af Java-kodning, hvis man sværger til det. Det er muligt at man sværger til open source, fint nok, men det er ikke argument for at det vi andre arbejder med er ’gammel teknologi’.

2. juli 2019 kl. 16:50
Dansk center vil skabe værktøjer til fejlfri programmering

Kurt Gödel - matematiker, fra 1940’erne, kollega og ven med Albert Einstein i Princeton - mente (dvs. kunne matematisk bevise) at: Vi kan ikke på forhånd vide hvad den simplest mulige beskrivelse af et system er. Dvs man er velkommen til at opstille en hypotese, og søge at beskrive systemet ud fra denne, men der er ingen garanti for succes. Det kan vise sig at det som hidtil har krævet 2000 siders uoverskuelig beskrivelse, nu med den nye hypotese kræver 4000 sider beskrivelse, hvilket så bare er ærgerligt. Yderligere ærgerligt er at man ikke på forhånd kan sige at der må findes en eller anden hypotese i lyset af hvilken beskrivelsen af systemet bliver simplere. Super-eksemplet er Einsteins almene og generelle relativitetsteori hvor det lykkes for Einstein at samle en række fænomener (tyngde og acceleration samt masse og energi) under en fælles beskrivelse som har vist sig dækkende, trods en forbavsende simpel grundlæggende hypotese, nemlig den at lysets hastighed er konstant og udgør overgrænsen for udbredelsen af enhver information. ‘Moderne’ teoretisk fysik prøver at brodere dette anderledes, via andre grundlæggende hypoteser (nemlig streng-teori), men succesen er ikke åbenbar, og om der overhovedet eksisterer en simplere og mere dækkende teori end Einsteins, virker efterhånden tvivlsomt. Ordet ‘simpel’ kan erstattes med ‘ordnende’: Opgaven er at skabe orden via gode teorier udfra produktive hypoteser.

Kurt Gödel er for mig at se det tætteste man kommer på en indkredsning af det matematiske grundlag for korrekt programmering af it-systemer: Kvaliteten af et programmel må vurderes udfra den grad af orden som programmellets beskrivelse skaber. Det er bedre at udtrykke sig klart og kort, end langt og rodet. Programmellet skal være præget af nogle grundbegreber, som afgørende bidrager til at strukturere beskrivelsen af området, altså at skabe orden. I vore dage, dvs siden 1990’erne, sker en sådan begrebsdannelse fortrinsvis i databasedesignet og ikke i programmellet. Eller lidt mere korrekt sagt: Programmellet skal være præget af nogle fornuftige hypoteser omkring området, og disse skal afspejles i begrebsdannelsen i datagrundlaget.

Modsat gælder (jo) at der ikke er nogen overgrænse for hvor rodet et programmel og dets datagrundlag kan være - og at rod ikke nødvendigvis betyder at programmellet ikke virker. Rod betyder blot at testopgaven bliver så meget større, og fra et vist punkt uoverskuelig stor.

Som debattråden her er inde på, så er ‘programmellet’ lig det totale it-system: At programmere ovenpå et operativ-system som viser sig dårligt egnet til at bidrage til strukturering af den foreliggende opgave, er ikke positivt. At anvende programmel-biblioteker fx fra et open-source miljø (eller fx fra SAP) kan rumme lignende farer. Tro på hvad andre har lavet er oftest forudsætning for at komme igennem med opgaven, men vi kan ende langt fra ideen om at finde den maksimale grad af orden på området.

At programmere er at anvende sprog - og at skabe sprog - for at beskrive virkeligheden på et område. Ordet ‘sprog’ kan her erstattes af ord som ‘begreber’ og ‘beskrivelser’, men det er stort set det samme. Vi bør tro på at den perfekte beskrivelse ligger et sted derude i mørket, men vi har ingen garanti for at finde den. Spørgsmålet om hvorvidt vort programmel er fejlfrit, bliver et anden-ordens problem: Den primære opgave er at beskrive virkeligheden nogenlunde dækkende. Resten er et spørgsmål om rettidig omhu: At få programmeret samtlige exceptions, dvs. håndtere uventede situationer inden programmet farer vild. At udvikle i et samspil med test, grundigt og velplanlagt. At programmere løsningen to gange i to forskellige setup, fx i et prototypesprog og i en produktionsrettet løsning, og kun i sidstnævnte fokusere på brugergrænsefladen.

Kurt Gödels matematiske bevis handler om hvad man ikke kan. Det er alligevel interessant, fordi det så samtidig siger noget om hvad man bør stræbe mod: Den (matematisk) klare beskrivelse. Og dermed handler om noget som it-programmører og it-arkitekter burde have som ideal.

Kilde: Tor Nørretranders: 'Einstein, Einstein'.

22. april 2019 kl. 09:22
Minister: Krav om GDPR-samtykke til kirkeblade er absurd

At gifte sig via den danske folkekirke er i sin essens en offentlig og offentliggjort handling. Fra middelalderen og indtil for få år siden, blev der fra prædikestolen lyst for brylluppet et par uger inden, i form af at præsten rejser spørgsmålet om der var nogen i menigheden som havde noget lovformeligt at indvende mod giftermålet mellem A og B. Meningen var, at man skulle sladre til præsten, hvis man vidste at de to kommende ægtefæller var tæt beslægtede, eller hvis nogen af dem var gift i forvejen. Kommet vel forbi det punkt, og nået frem til brylluppet, så siger præsten i vielsesritualet noget i retning af at ’Jeg forkynder jer hermed for rette ægtefolk at være, overfor Gud og mennesker’.

At data om et kristent ægteskab som default skal være hemmelige, er i strid med kristendommen. Så GDPR er her kommet i konflikt med religionsfriheden: At folk frit må praktisere deres religion, dvs. de sædvaner som ligger i religionen (...så længe det ikke i væsentlig grad skader udenforstående eller dem selv).

Et mere generelt problem er at ’offentligheden’ kan have legitime behov for at offentliggøre oplysninger om borgerne. Fx hvis man fradømmes retten til at drive virksomhed, er det jo vanskeligt at håndtere forretningskontakter med vedkommende, hvis dommen ikke må offentliggøres. Det samme kan siges at gælde ægteskabsforhold, fødsel og død. Religiøse sædvaner rummer ind i mellem nogle ideer om hvad der kan være praktisk.

12. september 2018 kl. 08:13
Chrome vil markere alle HTTP-sider som usikre

Som web-master for 'Søllerød Petanque Klub' (www.sollerodpetanque.dk) finder jeg det her vanskeligt: Enten må medlemmerne holde op med at bruge Google Crome, eller også får de at vide at omgang med klubbens hjemmeside nærmest er kriminelt, og i hvert fald usikker (...er mit Dankort mon i fare?). Og jeg formoder at nogle tusinde andre foreninger ude i Forenings har samme problem

Problemet for Søllerød Petanque Klub er at hjemmesiden oprindeligt er bygget i ’Stones Webwriter’ og efterfølgende rettet via almindeligt klamphuggeri a la HTML for Dummies mv, og at den hostes hos en web-udbyder som indtil videre har gjort meget lidt for at flytte os over i HTTPS verdenen. Trods det udmærkede argument: At HTTPS giver bedre rating hos Google. Dvs. jeg fornemmer ikke at der er nogen der har fokus på at løse det her problem for os. Dvs. det falder tilbage på os amatør web-mastere – som ikke har den store lyst eller tid til at omskrive hjemmesiden med implementering af offentlig og privat nøgle etc.

13. februar 2018 kl. 08:05
Amazon: Lambdaer er det nye COBOL

Ja Amazon (altså boghandlen) kører med ‘eventual consistency’. De gør lageret op hver nat, og konstaterer ved den lejlighed hvilke bøger de har fået solgt to gange i løbet af dagen. Sådan er det bare med distribuerede systemer, hvis det er den verden man lever i: Den ene del af systemet ved ikke om en anden del har solgt det sidste eksemplar af bogen. Før dagen er gået.

Det er også korrekt at banker i dag kører distribueret: Visa-systemet accepterer en betaling uden sikker viden om indestående på den bagvedliggende konto i den kontoførende danske bank. Man bygger på formodninger, og først når dagen er gået, åbenbares det mulige overtræk.

Men: Banker bygger på ‘actual consistency’ indenfor deres kærnesystem. Hvis den pågældende danske bank accepter Visa’s træk på kontoen så nedskrives kontoen med trækket samtidig med at Visas konto i banken godskrives tilsvarende. Dette sker med et commit-rollback framework som sikrer at begge transaktioner gennemføres eller rulles tilbage. Sådan er det hele vejen, også i Visa’s eget system, og i eventuelle mellemliggende banksystemer. Moderne bankdrift bygger på kommunikation mellem enheder som kører ‘actual consistency’. Det forhindrer ikke overtræk, men giver alligevel sikker viden om hvor pengene er. At handle udfra formodninger er ikke nødvendigvis fatalt, men hvis flytningen af penge fra den ene skuffe til den anden i kasseapparatet svigter, så der puttes flere penge ned end der tages op, eller omvendt - så er det fatalt. ‘Ud med mainframe’ er logisk hvis man lever i den distribuerede verden - men det gør banker af gode grunde ikke. ‘Actual consistency’ er uforeneligt med distribuerede systemer - med mindre man bygger et centraliseret commit-rollback framework ovenpå den distribuerede løsning.

3. november 2017 kl. 12:53
Udvikler: Open source-kode kan erstatte milliondyrt projekt

Den oprindelige arktikel i digi.no er mere nuanceret (og længere...) end version2's meget positive resume. Digo.no skriver bl.a. om en afprøvning af systemet med scanning af nummerplader i realistiske omgivelser: "Med en suksessrate på omtrent 1/877 er det langt igjen før OpenALPR er på nivå hvor det kan være til særlig nytte." Så et eller andet sted mellem det australske politis hundedyre system, og en open source løsning til 1000 kr ligger den gode løsning måske.

12. september 2017 kl. 09:36
Analytiker: »Jeg har ikke set et blockchainprojekt, der ikke ville være bedre uden blockchain«

Ja, der tegner sig et mønster i ‘moderne IT’: Mistro til centrale SQL-databaser. Mens mantraet i 1990’erne, hvor jeg trådte i mine erfaringer med livet og iT, var det omvendte: IT (eller EDB) gik ud på at udmønte en problemstilling i en SQL-database: Vejen derhen var Dataanalyse, normalisering, IRM. Programmering var intet, databasen var alt.

Udover at alle religioner skal tages med et gran salt, således også datidens SQL-evangelium… så er det altså underligt det her. SQL er et fint sprog, og er et af de eneste programmeringssprog hvor der har været udvikling gennem alle år: SQL kan mere og mere. SQL rummer nogle produktive dekoblinger mellem dataadministratorer og programmører. SQL har en god ‘utility’ side hvor adhoc forespørgsler og rettelser håndteres udenom systemets programmel. Systemer som bygger på SQL har skabt rygraden i ‘den moderne økonomi’: banker, herunder betalingssystemer såsom VISA. Og hvis du vil holde styr på Maersk’s containere, så er der ingen vej udenom SQL. Også mindre organisationer end de her nævnte, har nok nogle data, de bør holde styr på.

Min private teori er, at problemet er, at SQL passer dårligt ind i JAVA syntaksen og hele tankegangen bag JAVA. Objektorientering hander dybest set om ‘data-stores’, at kunne gemme og genfinde data, objektorientering er en anden (ældre og mere primitiv) måde at håndtere data på end SQL. Du kan så lægge en SQL database ind bag objekterne i JAVA, men det bliver syntaksmæssigt rodet, og ikke kønt at læse. Men udover disse spark til JAVA, så er grundproblemet nok det der kan formuleres mere neutralt: Det er svært at dyrke to religioner samtidig, og med voldsom hype om objektorientering, så vil SQL blive nedtonet.

JAVA’s objekter er ganske uanvendelige til at opbygge firmaets operationelle databaser, det ved man godt. Derfor suppleres JAVA: ‘Databasen er der hvor data er når lyset er slukket' (no-SQL databasen), eller der ligger et lag af Hadoop bag objekterne. Eller altså indeværende hype: JAVA skal selvfølgeligt kombineres med blockchain, så får du en løsning med samme transaktionssikkerhed som den centrale SQL-database.

21. august 2017 kl. 09:07
WannaCry og NotPetya: Hvad vi har lært om it-sikkerhed i 2017

Når NotPetya var kommet ind på en Windows-pc, så afsøgte den pc'en for credentials - altså identitetsoplysninger for brugere med flere rettigheder.

Er der nogen derude, som kan sige lidt mere om det her? Er det virkeligt rigtigt, at man kan låne andre brugeres rettigheder på Windows platformen? Og ligger der overhovedet ‘credentials’ for andre brugere på en typisk Windows pc?

At køre ’som administrator’ kræver ikke de store håndgreb på en windows-pc, men det er tilsyneladende ikke det der er tale om. Og det giver vel næppe rettigheder nok til at man kan smadre andre maskiner i netværket.

Det er jo ellers almindelig praksis i gængse operativsystemer at man skal kende både brugerident og password for at skifte til at være en bruger med flere rettigheder. Og disse oplysninger ligger selvfølgeligt krypteret. Plus at der ikke er nogen mulighed for afsøge maskinen for at besvare spørgsmålet: Har vi nogle brugere her med gode rettigheder?

Artiklen taler senere om at man ’skal begrænse brugeres rettigheder’, og det lyder jo som god værkstedspraksis. Men hvis det er så nemt at sjæle credentials, så er det vel ganske forgæves.

Det hele lyder mystisk - det lyder for mig mere som om at opdateringsfunktionen til det ukrainske skatteprogram - af gode grunde - havde vide rettigheder på den enkelte maskine. Pga. et sikkerhedshul kunne disse rettigheder også bruges til at smadre andre maskiner. Men det er et gæt.

3. juli 2017 kl. 15:42