Poul-Henning Kamp svarer på det åbne interview

Poul-Henning Kamp har besvaret spørgsmålene fra instituttets dataloger på Dikutal. Han er åbenmundet FreeBSD-udvikler med en blog på version2.dk, der ofte er til at finde med skarpe holdninger til IT-kultur og udviklingsfilosofi. Han er stærk kritiker af Datalogisk institut og mener blandt andet at fysikere generelt koder bedre end dataloger. Derudover er han i gang med et offentligt sagsanlæg mod Lenovo, fordi de ikke vil refundere licensen til et Windows-styresystem, som han ikke ønsker installeret.
Han har i sine svar givet DIKU gode råd om open-source udvikling ud fra hans egne erfaringer, samt et tilbud om at komme og undervise i god programmeringsteknik, såfrem nogen tør tage udfordringen op.

1.Indsendt af "Fairchild":
"PHK har stillet spørgsmålstegn ved DIKU kandidaters evner som programmører. Hvis han fik tilbuddet, ville han så være villig til at komme ud til os og undervise et kursus i programmering/BSD udvikling?"

PHK: Jeg har altid været en stor tilhænger af princippet "eat your own dogfood" og derfor har jeg i 15 år kørt FreeBSD-current på min primære arbejdsmaskine.

Så svaret er naturligvis et klart ja: Hvis jeg ikke mente at jeg havde noget at have det i, ville jeg heller ikke drømme om at kritisere datalogers evner og forståelse for programkode, som programkode beset.

2.Indsendt af "Munksgaard":
"Har PHK nogle gode forslag til hvordan man som ny datalogi-studerende kan blive involveret i open-source projekter som f.eks. BSD? Jeg er klar over at BSD og styresystemer generelt er ret avancerede emner inden for datalogien, men det er jo netop derfor vi er her på DIKU."

PHK: Jeg tror at den vigtigste forudsætning er at man brænder for et problems løsning.

Enten fordi man vil have sin scanner til at virke under et fornuftigt operativsystem, eller måske blot fordi man synes at MMP load-balancing er et hamrende interessant problem.

Der findes folk der vælger et OSS projekt efter kultur og vælger at interessere sig for projektets problemer fordi de ønsker at associere sig med projektet. Men de har aldrig hjertet helt med i det, der er på en eller anden måde lidt for meget "fanboy" over det og man bekræftes ofte i den mistanke, når de springer videre til et andet "mere cool" projekt.

Jeg vil råde dig til at lave en trigger for tankerne "Det kan jeg fandme gøre bedre!" og "Hvor svært kan _det_ lige være ?" Når CFL pæren lyser, går du bare igang...

3.Indsendt af "Troels Henriksen"
"I hvilket omfang er det nødvendigt med nye værktøjer (sprog, analysesystemer, osv) versus arbejdsgange for at sikre at fremtidens endnu mere komplekse datasystemer også vil være pålidelige i drift?

PHK: I kviksandet imellem Dijkstras observation: "Jeg har en meget lille hjerne og må leve med det" og Turings "halting-problem" findes der ingen nemme løsninger: Blot fordi vores teksteditor og compiler kan kapere 50.000.000 linie kildetekst bliver vi ikke i stand til det.

Vores værktøjer virker alene ved skalering: med en compiler kan vi skrive flere instruktioner udfra en mindre beskrivelse, men beskrivelsen skal stadig være rigtig til at begynde med.

Tænk på værktøjerne som en vægtstang: Hvis den lange arm skal bevæges over store distancer, kræver det stor udveksling, men hvis vi samtidig kræver at denne bevægelse skal være præcis, forudsættes en overmenneskelig præcision med den korte arm.

Tilbage i firserne løb "4GL-revolutionen" ud i sandet, fordi der er en naturlig øvre grænse for hvor stor forstærkning man kan implementere i værktøjerne, før selv meget små ujævnheder i den beskrivelse vi fordrer dem med, forstærkes helt ud af proportion.

Derfor tror jeg heller ikke en meter på "intentional programming" og andre tilsvarende ESP baserede ideer.

Jeg ved ikke om der findes en konkret øvre grænse for komplexe systemers størrelse, men med en erfaringsmæssig fejlrate på omkring en promille, bør enhver der hører om 50 mio kodelinier henfalde i eftertænksomhed.

Slaget skal derfor slås inden kravspecifikationen skrives, hvor opgaverne skal skæres ned og partitioneres til noget vi kan løse.

Rejsekortet er et kanon eksempel på et system hvor man havde et
selvskabt komplexitetsproblem, en unødvendig byzantin takststruktur,
og satte computere til at dække over problemet, fremfor at _løse_
problemet, ved at simplificere takststrukturen, og derefter implementere løsningen med computere.

Du skriver jo:
tilsyneladende selv mest i C, er det fordi du arbejder i en kontekst hvor ingen andre sprog er ydelsesmæssigt forsvarlige, eller kan C's svagheder opvejes af en tilpas arbejdsgang?

Faktisk har jeg skrevet i stort set alle programmeringssprog jeg nogensinde har kunnet komme i nærheden af og jeg har stadig en kopi af en S/34 disassembler skrevet i RPG/II til at bevise det med.

At jeg primært bruger C i FreeBSD og Varnish sammenhæng, er at det i begge tilfælde handler om rå performance. C udmærker sig ved at være maskinnært: det står ikke i vejen for anvendelsen af hardwaren.

Til mere abstrakte opgaver bruger jeg bla. Python. F.eks er jeg ved at dokumentere hele ledningsføringen i den GIER computer, vi er ved bringe i køreklar stand (i datamuseum.dk) og om det program kører på 10 eller 20 sekunder er inderligt ligegyldigt. Med Python slipper for at konstruere mine egne associative arrays.

En af de meget stærke ting ved C, er at det har en macroprocessor, (cpp), med hvilken man kan udvidde sproget temmelig drastisk og dermed dække over de mangler det har.

F.eks burde C efterhånden have fået en rudimentær objektstruktur og list/queue faciliteter, men med cpp kan vi implementere det nogenlunde acceptabelt. Se f.eks: http://svn.freebsd.org/viewvc/base/head/sys/sys/queue.h?view=markup

Jeg så gerne en modernisering af C, men i IT verdenen er vi mere bekymrede for kompabilitet med den endelige mængde programmer vi har skrevet, end den uendelige mængde programmer vi vil komme til at skrive, så alle radikale forslag er på forhånd dødsdømt.

4. Indsendt af "Robin Kaarsgaard"
"Nu bruger FreeBSD en licens der er noget mindre restriktiv omkring at dele ændringer i kildekoden end eksempelvis GPL-licensen. Hvor stor grad af velvillighed oplever PHK fra erhvervslivet om at give tilbage til eksempelvis FreeBSD-projektet på trods af, at dette ved licensen ikke er påkrævet?"

PHK: Historisk har ingen lønninger nogensinde været underkastet skarpere kritik og mere nøjagtigt eftersyn, end mejeribestyrens og brugsudelerens i andelsbevægelsens barndom. Deri lå meget af
bevægelsens success.

OSS bevægelsen lever på samme vilkår og kan man argumentere for at den indsats man yder for fælleskabet er penge værd, bliver man også betalt. Men der skal kæmpes for hver lønningspose, for erhvervslivet investerer kun hvad de tror kan betale sig for dem og kan de slippe for at bruge penge, gør de det.

På sin vis ville jeg da elske hvis folk kastede penge efter os i ublu mængder, men alle de substansløse guldgravere det ville tiltrække er jeg hellere foruden.

Man kan godt sige at manglen på penge er med til at sikre den åndelig renhed som skiller OSS fra kommerciel software: ingen er nogensinde blevet rig på OSS uden at arbejde for det.

5. Af Redaktionen:
"Hvilke af dine projekter er du mest stolt over?"

PHK: Jeg har noteret mig berømmelsens perversitet ingen ende kender, f.eks gav man Einstein en Nobelpris for den fotoelektiske effekt og berømmer James Watt for dampmaskinen, selvom deres største præstationer er nogle helt andre.

Jeg oplever selv at den trivielle kode jeg kastede sammen på en eftermiddag, mens min spæde søn kravlede rundt på gulvtæppet, beskytter et enormt antal passwords på internettet, mens den kode jeg selv synes er mest banebrydende, ikke har buzzwords nok til at blive opdaget.

Så på det altid urimelige spørgsmål, "hvem af dine børn elsker du mest ?" vil jeg idag vælge at svare: konfigurations API'et til GEOM.

Det indeholder en banebrydende indsigt, der vil kunne simplificere ethvert interface til komplekse kernefaciliteter, med mindre kode og bedre og mere præcise fejlmeddelelser til følge.

Og nej, jeg forventer ikke at I har hørt om det, for ideen strider imod POSIX-filosofien om den gudommelige balsamering af UNIX system III's API.

6. Af Redaktionen:
"Har du haft andre konflikter med tvungen propitær software end med Lenovo?"

Konflikter kan man altid skaffe sig og min retssag imod Lenovo er et rent aftalemæssigt økonomisk mellemværende, jeg agter nemlig ikke at bruge den software der er tale om.

Mere abstrakt kan jeg sige at det var elendig closed source software der fik mig til at blive OSS aktivist, på grund af sin elendighed og den konflikt er ikke stoppet.

7. Af Redaktionen:
"Hvilke features fra det unix-lignende freeBSD kunne linux drage mest nytte af, som endnu ikke er implementeret?"

PHK: Nu er vi jo nogen der fastholder at FreeBSD er den sidste rigtige UNIX på markedet, vores kildetekst kan spores tilbage til Kens og Dennis oprindelige arbejde, mens Linux "kun" er et "unix-lignende operativsystem" der er skrevet fra bunden :-)

Jeg er næppe den rette til at fortælle Linux hvad de skal gøre, men det er mit klare indtryk at Linux kernen slæber rundt på nogle områder med helt unødvendig mange historiske løvefødder og gesvejsninger, hvor en hastigt taget og uoplyst beslutning var unødvendig dogmatisk, f.eks i hele DEVFS fiaskoen.
Det binder lidt ind i det der "bagud vs forud kompatibel" spørgsmål jeg nævnte ovenfor: Linux har ikke (mere ?) evnen til at foretage en radikal forandring, så de fleste af de ting jeg ville foreslå er ikke realistiske. FreeBSD kan stadig, men det bliver også der tungere og tungere.

Det der virkelig er brug for, er at droppe POSIX helt og designe et nyt OS-API, hvor vi tænker over hvordan vi bruger programmer og computere nu om dage, istedet for hvad vi kan klemme ned i en PDP-11.

Hvorfor har vi f.eks ikke et API kald der siger "kopier fil herfra og dertil", som kernen kunne forwarde til en filserver, frem for at læse filen over netværket og skrive den tilbage over netværket igen?

Ja, det er der kerner der har, men vi har ingen _standard_ for det, vi har faktisk ikke engang en standard for et bibliotekskald der kopierer en fil, så alle mulige programmer implementerer deres egen version med deres egne fejl og sikkerhedsproblemer.

8. Af Redaktionen:
"Hvad er din mening om det nye Windows 7?"

PHK: Jeg ved ikke om jeg har nogen. Jeg har ikke prøvet at bruge det til noget og kommer heller ikke til det, med mindre jeg skal låne en browser et sted en dag, og så kan OS'et nedenunder være godt det samme.

9. Af Redaktionen:
"Hvordan ser du fremtiden udvikle sig på operativsystem-området? opensource vs. propitær?"

Med både OS/X og Solaris ude i kildetekstform er det slag vundet: Propitære OS er døde, for hvis du ikke kan få folk til at skrive programmer til dit OS har du ikke nogen fremtid.

Mere abstrakt frygter jeg at vi også i fremtiden sidder og fedter rundt i en programmeringsmodel og et API der er forældet.
Et godt eksempel er at de fleste programmører stadig ikke aner hvad Virtual Memory er eller hvordan de skal bruge det. (Til orientering er VM en 40 år gammel opfindelse.)

Sålænge det er drømmen om at blive "den næste Bill Gates" der er den primære drivkraft i IT verdenen, (jvf. f.eks Ministeren eller IT factory) kommer vi aldrig vidrere.

10. Af Redaktionen:
"Hvad udvikler du om ti år?"

PHK: Aner det ikke.

Kursusmaterialer der skal forklare datalogistuderende hvorfor alt
hvad de har lært indtil da om programmering er forkert ? :-)

Poul-Henning