Søren Hersdorf

Kan science fiction guide os i udviklingen af kunstig intelligens?

Starwars universet er fyldt med rumskibe, blasters, lyssværd og andre sci-fi gadgets. det mest interessante er dog interaktionen mellem kunstige intelligenser/robotter (AI) og diverse organiske intelligenser, herunder mennesker (OI). Hvordan lærer et menneske at kommunikere med en R2 enhed, hvor hver intelligens afsender på sit eget sprog og tilsyneladende bliver forstået. En asymmetrisk protokol, hvor mennesket snakker engelsk og robotten udstøder fløjtelyde. Og hvor kommunikationen tilsyneladende indeholder både følelser, frygt/glæde og mere kompleks kode som ironi og underforståede budskaber. Ligeledes er det interessant at de 2 hovedrobotter vælger at bruge samme kommunikationsform, når de er alene. Man skulle dog tro, at det første man ville installere i en robot er en superhurtig trådløs kommunikation. Hvorfor har R2 enheden en lile robot arm, som fysisk skal kobles sammen med og drejes rundt, for at kommunikere med en central computer. Man kunne argumentere for at det for at forstærke den cinematiske effekt, men det kunne også være fordi uovervåget kommunikation mellem robotter kan føre til et AI overherredømme. Iøvrigt er der megen teknologi i Starwars som er uhyggelig sårbar, fx er det helt fatalt at den samlede robothær falder fra hinanden, da den centrale styringsenhed eksploderer. Med AIer på niveau med R2 enheden, skulle man tro at en robothær kunne arbejde autonomt, ned til den enkelte enhed. Måske skal vi ikke spekulere så meget over videnskabelig korrekthed , men bare nyde fortællingen, også nå C-3PO genkender sin skaber efter mange års adskillelse.

16. juli 2019 kl. 16:01
Mainframen har for travlt til at dø

Den eneste grund til at mainframes ikke kan dø, er det ekstreme politiske pres fra inkompetente, omskolede udviklere fra 1970’erne som stadig ikke ved hvad internettet er.

Nemlig, os fra 70'erne har magt over både direktion og bestyrelse.

Hvis man tvang mainframes væk fra banker og forsikringsselskaber ville man kunne spare 90% af udviklingsbudgettet, nemt. Den rabat burde ryge direkte til forbrugerne.

Jeg tror ikke, du er helt klar over hvad det vil koste at omlægge en større finansiel instituition fra MF til X86. Eller hvad det koster at vedligeholde de 2 platforme.

Intet brugbart standardbibliotek til Cobol og PL/1 (tænk simple ting som strengformatering, websockets, json parsing, bufferedreader, alt hvad alle moderne sprog har)

Det kommer efterhånden som efterspørgslen kommer, feks har nyeste COBOL version en JSON parser og CICS understøtter mapping mellem MF sprogstrukturer og XML/JSON

Ingen deployment pipelines til at køre integration- og unit tests. Faktisk ingen testframeworks til automatiserede test overhovedet, alle tests blev lavet af mennesker kl 6 om morgen efter release til prod.

Sludder, det laver man bare, det er op til den enkelte installation

Elendig performance sammenlignet med ethvert moderne sprog der udførte en normal, standard opgave (dvs ikke benchmark af math.pow, som cobol eller PL/1 i øvrigt heller ikke har)

Sludder, MF outperformer X86, som har svært ved at scalere ved meget store datamængder

Ingen moderne versionskontol af koden, til pull requests, code review, dokumentation etc.

Opgaven ligger i IDE'et og der findes adskillige værktøjer.

Ingen moderne IDE (glem det, Eclipse-elskere, 10 GB ram for at åbne en fil er ikke moderne)

Eclipse virker nu ganske fint. En tidligere undersøgelse viste i øvrigt at uanset sproget og platformen, så arbejder udviklere stort set med samme hastighed, når de kender sproget og IDE'et. Eneste undtagelse er assembler, som er langsommere at kode på alle platforme.

Ingen organisering af de faktiske filer og/eller koden i et program. Alle programmer var begrænset til én fil med et navn på maks 8 tegn, caps selvfølgelig. Fx “ZBTS1000.CBL” - så regn selv ud hvad det gør.

Sludder, koden til et MF program kan opdeles i masser af filer og iøvrigt genbruges på tværs, både på kildekode og på objekt niveau.

Det lyder som om din erfaring stammer fra en meget begrænset periode og et enkelt arbejdssted. Der er meget stor forskel på hvordan de enkelte installationer vælger at køre deres mainframe.

Jeg har set meget rod på MF, men man skal vist være meget naiv, hvis man tror, at der ikke findes rod på X86 platformen. mht til IT-Gæld, så er det min spådom, at gælden på X86 platformen vil være væsentligt større, når den har levet lige så længe og integreret i forretningen som MF. Det er min erfaring at X86 udviklere finder et nyt sprog og IDE hver 18 måneder og de kigger sig ikke tilbage.

Platformsbashing er en yndet sport for den, der kun kender den ene side, men når man har arbejdet seriøst på flere, så erkender man styrker og svagheder. Så forstår man, hvordan den rigtige kombination af platforme og væktøjer skaber meget stærke løsninger.

16. juli 2019 kl. 15:26
Mainframen har for travlt til at dø

Der har tidligere, i vide kredse, været en bred enighed om at MF platformen er dyrere at drifte. Det er dog ved at ændre sig, flere og flere software leverandører på X86 platformen går over til forbrugberegning, dvs man betaler software licens efter størrelse på maskinen og antallet af brugere mv. Software leverandører på MF platformen er samtidig ved at ændre deres prisstrukturer, herunder stærkt reducerede priser på transaktioner afviklet via requests fra webklienter.

16. juli 2019 kl. 14:51
Brute force, lyd-analyse og gætteleg: Sådan klarede Politikens udvikler FE's hackertest

Efterretningstjenesten bemærkede, at den vej, Emil tog i det tredje lag, ikke var den korrekte. Ansøgere med ’det rette mindset’ ville have brugt tiden på at ’disassemble’ det lukkede program, og analysere sig frem til, at nøglen netop var logoet på hjemmesiden.

Et ofte overset problem, er at dem der skal beskytte systemer, ikke har fantasi til at forestille sig de alternative metoder og adgangsveje en uvedkommende kan vælge. Her er der en omhyggeligt og meget kompliceret opgave, designet til kun at slippe dem med det rigtige "mindset" igennem og alligevel kommer der andre igennem.

11. april 2016 kl. 15:03
Mainframes: Back to the future

Lad os vende bøtten på hovedet.

Hr. Kamp skriver:

Alle seriøse installationer jeg kender til har opgivet ACLs som primær sikkerhedsfacilitet.</p>
<p>I stedet slår man idag en jernring om installationen, stoler (nogenlunde) på dem indenfor og bruger ACL-lignende gateway faciliteter imellem "inde" og "ude": Firewalls, DMZ osv.

Venligst angiv hvilke installationer, så vi kan lære af dem?

Bellovins og Cheswicks bog, der fastslog dette princip, udkom i 1994.

Jeg går ud fra at der refereres til "Firewalls and Internet Security: Repelling the Wily Hacker." En bog som ikke rigtigt beskæftiger sig med andet end at afvise sorte hatte.

Bonus info Citat fra bogen: "It is also true that UNIX is an administrative nightmare. Vital files are scattered over numerous directories. Setuid programs can change the rules in unexpected ways if the capability is misused."

11. februar 2015 kl. 10:21
Mainframes: Back to the future

Hvorfor svarer du ikke på de andre ting :-)

Jeg synes ikke at have set nogle spørgsmål. Hvad vil du gerne vide ?

9. februar 2015 kl. 16:07
Mainframes: Back to the future

Der er en grund til at lastvogne stort set har overtaget al godstrafik i Danmark fra jernbanen: De løser simpelthen opgaven bedre.

Godstransport med lastvogn er decentral trafik til små ladninger. De store transporter foregår med containerskibe og de bliver hele tiden større og mere effektive.

9. februar 2015 kl. 15:46
Mainframes: Back to the future

Tag CSC's mainframe som eksempel:

Et fint eksempel og din beskrivelse af omstændighederne viser da også, at sikkerhedsbristen i høj grad skyldtes en utilstrækkelig forvaltning og ikke Z-arkitekturen eller RACF.

Og dit spørgsmål om konsistenscheck på RACF viser også, at der er mulighed for at foretage dette, men det op til administrationen at vælge intervallet. Igen er det ikke værktøjet eller arkitekturen der sætter begrænsningen, men måden hvor på man vælger at forvalte.

9. februar 2015 kl. 10:02
Mainframes: Back to the future

Constrained RBAC.

Desværre ikke. Hr . Kamp afviste allerede i det oprindelige indlæg at anvende Rolle Baseret Access Control.

Iøvrigt kan man nemt implementere rollebaseret adgange i RACF, hvilket praktiseres flere steder

9. februar 2015 kl. 09:11
Mainframes: Back to the future

Så har man helt sikkert ikke haft styr på sin IT-arkitektur og dermed heller ikke IT-sikkerhed i de senste 10-20 år...

Men jeg er sikker på at lederne af IT "divisionen" eller hvad det nu kaldes, praler højlydt med alle de store tal i powerpoint præsentationer.

På mig virker det som en temmelig nedladende, undvigende og arrogant måde at svare på et meget rimeligt spørgsmål: "Hvad er så en god intern sikkerhedsmodel ?"

Det statistiske antal af fejl i kode ? Hvad har det med sikkerhedsmodellen at gøre og er der færre fejl i decentral kode ?

Hvis man gerne vil tages alvorligt, specielt som "sikkerhedsekspert" på en platform man ikke kender, så skal man nok finde en anden tone og tilgang.

9. februar 2015 kl. 09:02
Mainframes: Back to the future

At beskytte fortolige oplysninger imod udefrakommende skal iflg. vores lovgivning have en højere prioritet end at gennemføre den daglige drift.</p>
<p>Det er faktisk forudsætningen for at man overhovedet må gennemføre den daglige drift.</p>
<p>Loven giver ingen undtagelser for arkaiske sikkerhedsarkitekturer eller holdninger.

Enig, men det var ikke det der var pointen. Fortrolighed er kun én af forudsætningerne, og der en hel del andre, som også skal være opfyldt. Kompleksiteten er ikke skabt af systemet, værktøjet eller administrationen, men af kravene til sikkerhed.

Det er klart af en "jernringstaktik" er mere simpel og virker besnærende for en ikke "insider", men den opfylder bare ikke de komplekse nuværende krav til tilstrækkelig sikkerhed. Det er også værd at bemærke (igen!), at det ikke er den velprøvede arkitektur eller værktøjsbegrænsninger, som skaber diverse sikkkerhedsbrist. Det er den lemfældige omgang med sikkerhed, som kun kan bekæmpes med rettidig omhyggelighed, uanset arkitekturen.

6. februar 2015 kl. 15:39
Mainframes: Back to the future

RACF er et værktøj som styrer adgang til alle ressourcer på z/OS, men det er kun så sikkert som anvenderen evner eller ønsker at bruge det. Det er en dårlig snedker, som skyder skylden på høvlen.

Sikkerheds administration er meget andet en afvisning af sorte hatte og det virker ikke som om det originale indlæg rigtig formidler (forstår?) den kompleksitet, som er hverdagen i en stor mainframe installation. De fleste større installationer supplerer RACF med andre adgangssystemer, som er målrettet forretningsbehovet og de krav som bla. stilles af myndigheder, intern og ekstern revision.

Mange installationer bevæger sig mod en arkitektur med mainframe som backend data- og serviceprovider. Dette er primært drevet af et ønske om en mere moderne brugergrænseflade end den traditionelle 3270. I den proces opstår et behov for at genoverveje hvor sikkerheden bedst placeres, men indtil denne transition fuldt gennemført, er det svært at forstille sig, at en "jernrings" strategi skulle være mere sikkert, med mindre man lever i sort-hvid verden, hvor sikkerhed bare er et spørgsmål om at undgå, at ukendte henter fortrolige oplysninger

6. februar 2015 kl. 12:57
Danmark har ikke brug for flere programmører

Anders Lisdorf har ret: Danmark har ikke brug for flere programmører, dvs personer der kun kan programmere, ligesom der heller ikke er brug for folk, der kun kan stave og regne. Programmering er i dag en grundlæggende færdighed, på linie med stavning og regning. Der er brug for folk der kan lave løsninger og jo flere færdigheder der er til stede, desto mere alsidige og praktiske bliver løsningerne. Kendskab til programmering giver evnen til at gennemskue hvilke opgaver, der kan løses med et program og i særdeleshed hvilke opgaver, der ikke kan løses med et program. Det er meget længe siden man stoppede med at ansatte programmører (selvom der måske stadig er nogen tilbage med denne jobtitel). I dag ansætter man systemudviklere, som netop er kendetegnet ved at kunne analysere, designe, programmere og teste systemer. Det kræver (selvklart) kendskab til analyse, design, programmering og test, samt en forståelse for de forretningsområder og brancher, som man udvikler løsninger til. Kort sagt: Systemudviklere, og dem er der masser af brug for.

6. januar 2015 kl. 12:39
Krypto-professor: Derfor døjer politiet med krypteret laptop i hackersag

øvrigt kunne de jo få manden her til at udlevere kodeordet selv:
De skal bare fortælle ham at maskinen har været hos en prof kodebryder som har fået den åbnet, og afsløret at hans harddisk var fyldt med børneporno og nu står han til livsvarigt fængsel.
Så må han ud med kodeordet, så han kan dokumentere at det ikke passer...

Lad os et øjeblik antage (bare for sjov og helt urealistisk) at det rent faktisk var lovligt for politiet at lyve for en sigtet og forfalske beviser. Hvis politiet har brudt krypteringen, behøver de ikke sigtedes password og han behøver således ikke at opgive det. Med andre ord, der er ingen som helst god grund til at sigtede nogensinde skulle opgive passwordet på noget tidspunkt.

12. september 2014 kl. 11:13
NemID2: Gør det nu rigtigt 5/5

Lovgivningen er for længst gennemført. F.eks skal du emaile "en kopi af pas og sygesikringsbevis" hvis du skal købe fast ejendom.

Det ændrer ikke på vigtigheden af at forhindre dårlig lovgivning.

Iøvrigt er det ikke nødvendigt at emaile noget i forbindelse med køb af fast ejendom, loven sikrer kun at identiteten på køber er entydigt kendt. Dette kan løses på flere måder, herunder gennem mail af diverse indscannede dokumenter, hvilket desværre kun giver en teoretisk sikkerhed.

27. august 2014 kl. 15:33
NemID2: Gør det nu rigtigt 5/5

Er du utilfreds med hvad politikerne vedtager må du bruge stemmeblyanten eller stille op selv.

Man kan også tage debatten og forklare hvorfor man synes privatlivet er vigtigt og hvorfor man meget nødigt vil have alle sine personlige oplysninger distribueret ud på mere eller mindre sikre elektroniske devices. Det vil nok være det nemmeste hvis vi kan forhindre uigennemtænkt, overflødig og besværlig lovgivning i at blive gennemført, fremfor at fjerne den igen, efter at den er fejlet.

27. august 2014 kl. 15:09
NemID2: Gør det nu rigtigt 5/5

Der er ingen fordele, hverken teknisk, praktisk eller privatlivsmæssigt ved at bygge to separate systemer.

Jeg håber, at dem der skal designe Nemid2 har et mere nuanceret syn på fordele og ulemper ved at udvikle seperate systemer.

27. august 2014 kl. 11:53
NemID2: Gør det nu rigtigt 5/5

Jesper Louis Andersen: "Ideen er at vende det om. Dørmanden har lovmæssig hjemmel til at afvise Signe på 17 men godkende Ida på 18. Så vi giver dørmanden en læser certificeret til at svare på Myndig spørgsmålet. Det betyder at læseren har et kryptografisk certifikat så den kan bevise at den er en myndig-læser.</p>
<p>Ida's borgerkort kan checke at dørmandens læser har et lovligt certifikat, og fordi det kun accepterer "Myndig", så er det kun den oplysning kortet giver. Det logger også at dørmandens læser bad om denne oplysning.</p>
<p>Det er ikke perfekt i den forstand at en kompromiteret læser kan få andre oplysninger. Men så bliver det logget på borgerkortet og man kan tage affære. Desuden er det sådan ca. 1000 gange bedre end den nuværende løsning og alle løsninger der kom før dette.</p>
<p>Hvis det ikke er borgerkortet der laver denne afgørelse, så mister du som person alt kontrol med dine data. Desuden kan vi passende være lidt mere påpasselig med certifikater der lader dig hente samtlige oplysninger fra kortet. Et simplere spørgsmål om myndighed er til en hvis grad mindre afgørende."

Super beskrivelse af mulighederne i et borgerkort. Nemid2 er slet ikke nævnt, måske fordi Nemid2 ikke er nødvendig for den beskrevne løsning. Hvis Nemid2 skal bruges i denne sammenhæng, så er det KUN for at verificere at den der anvender kortet også har koden til det.

27. august 2014 kl. 10:22
NemID2: Gør det nu rigtigt 5/5

"Så bliver du nok nødt til at læse blogindlægget igen." Super argumentation :-((

Det er en stor misforståelse at sammenblande borgerkort og Nemid2. Nemid2 skal KUN validere en given person identitet. Nemid2 skal ikke formidle borgernes personlige data. Det betyder at services (private eller offentlige) som vil forspørge på brugerens data, alder, foto, skostørrelse med mere, med brugerens accept, kun kan få valideret identiteten af en person fra Nemid2. At borgeren giver en serviceudbyder lov til at se vedkommenes persondata, skal ske uafhængigt af Nemid2. Nemid2 hverken skal eller kan administrere persondata, adgange og/eller roller. Det skal varetages af andre services. Derfor: Lad være med at blande Nemid2 og et evt. borgerkort sammen i en integreret løsning, det ødelægger funktionaliteten af begge dele. Begge dele skal designes til at fungere uden den anden.

27. august 2014 kl. 09:23