-
Jeg møter alle slags interessante mennesker på min vei, og et møte
-jeg lærte mye av var å treffe på en svært kompetent IT-fyr som
-benektet ting jeg anser som åpenbart og selvfølgelig når det gjelder
-standarder. Det var interessant, da det fikk meg til å tenke litt
-nøyere på hvilke mekanismer som ligger til grunn for at noe oppfattes
-som en standard. Det hele startet med arbeid rundt integrering av NSS
-LDAP mot Active Directory, og problemer som oppstår pga. at Active
-Directory ikke følger LDAP-spesifikasjonen som dokumentert i RFCer fra
-IETF (konkret, AD returnerer kun et subset av attributter hvis det er
-mer enn 1500 atributter av en gitt type i et LDAP-objekt, og en må be
-om resten i bolker av 1500). Jeg hevdet måten dette ble gjort på brøt
-med LDAP-spesifikasjonen, og henviste til hvor i LDAP-spesifikasjonen
-fra IETF det sto at oppførselen til AD ikke fulgte
-LDAP-spesifikasjonen. AD-spesialisten overrasket meg da ved å
-fortelle at IETF var ikke de som definerte LDAP-spesifikasjonen, og at
-Active Directory ikke brøt den virkelige LDAP-spesifikasjonen som han
-mente lå til grunn. Jeg ble spesielt overrasket over denne
-tilnærmingen til problemstillingen, da til og med Microsoft så vidt
-jeg kan se anerkjenner IETF som organisasjonen som definerer
-LDAP-spesifikasjonen. Jeg fikk aldri spurt hvem han mente sto bak den
-egentlige LDAP-spesifikasjonen, da det var irrelevant for problemet vi
-måtte løse (få Linux og AD til å fungere sammen). Dette møtet
-fortalte meg uansett at det ikke er gitt at alle aktører er enige om
-hva en standard er, og hva som er kilden til en gitt standard. Det er
-vanskelig å enes om felles standarder før en først enes om hvem som
-bestemmer hva en gitt standard innebærer.
-
-
Hva er så en standard? I sin abstrakte form er det noe å samles
-om. PÃ¥ engelsk er en av betydningene fane brukt i krig, du vet, den
-type fane en samlet seg rundt på kamplassen i riddertiden. En
-standard definerer altså et felleskap, noen som har noe felles. Det
-er naturligvis mange måter å utgjøre et felleskap på. En kan
-f.eks. enes om å gjøre alt slik som Ole gjør det, og dermed si at Oles
-oppførsel er standard. Hver gang Ole endrer oppførsel endrer også
-standarden seg uten noe mer organisering og prosedyre. En variant av
-dette er å gjøre slik som Ole har gjort det i stedet for slik Ole til
-enhver til gjør noe. Dette er ofte litt enklere å forholde seg til,
-da en slipper å sjekke med Ole hver gang for å vite hvordan ting skal
-gjøres nå, men hvis det Ole gjorde noe dumt den gang en bestemte seg
-for å følge Ole, så er det vanskeligere å få endret oppførsel for å
-unngå dette dumme.
-
-
En kan også ta det et skritt videre, og istedet for å basere seg på
-enkeltpersoners oppførsel sette seg ned og bli enige om hvordan en
-skal gjøre ting, dvs. lage et felleskap basert på konsensus. Dette
-tar naturligvis litt mer tid (en må diskutere ting i forkant før en
-kan sette igang), men det kan bidra til at den oppførselen en
-planlegger å benytte seg av er mer gjennomtenkt. Det ender også
-typisk opp med en beskrivelse av ønsket oppførsel som flere kan forstå
-- da flere har vært involvert i å utarbeide beskrivelsen.
-
-
Dette er dessverre ikke alt som trengs for å forstå hva en åpen
-standard er for noe. Der alle kan se på hvordan folk oppfører seg, og
-dermed har valget om de vil oppføre seg likt eller ikke, så er det
-endel juridiske faktorer som gjør det hele mer komplisert -
-opphavsretten og patentlovgivningen for å være helt konkret. For å gi
-et eksempel. Hvis noen blir enige om å alltid plystre en bestemt
-melodi når de møtes, for å identifisere hverandre, så kan
-opphavsretten brukes til å styre hvem som får lov til å gjøre dette.
-De har standardisert hvordan de kjenner igjen alle som følger denne
-standarden, men ikke alle har nødvendigvis lov til å følge den.
-Musikk er opphavsrettsbeskyttet, og fremføring av musikk i
-offentligheten er opphavsmannens enerett (dvs. et monopol). Det vil i
-sin ytterste konsekvens si at alle som skal plystre en
-opphavsrettsbeskyttet melodi i det offentlige rom må ha godkjenning
-fra opphavsmannen. Har en ikke dette, så bryter en loven og kan
-straffes. Det er dermed mulig for opphavsmannen å kontrollere hvem
-som får lov til å benytte seg av denne standarden. En annen variant
-er hvis en standard er dokumentert, så er dokumentet som definerer
-standarden (spesifikasjonen) beskyttet av opphavsretten, og det er
-dermed mulig for rettighetsinnehaver å begrense tilgang til
-spesifikasjonen, og slik styre hvem som kan ta i bruk standarden på
-den måten.
-
-
Der opphavsretten innvilger et monopol på kunstneriske uttrykk med
-verkshøyde, innvilger patentlovgivningen monopol på ideer. Hvis en
-slik patentert idé (fortrinnsvis uttrykt i en teknisk innretning, men
-det er kompliserende faktorer som gjør at det ikke er et krav) trengs
-for å ta i bruk en standard, så vil den som innehar patent kunne styre
-hvem som får ta i bruk standarden. Det er dermed ikke gitt at alle
-kan delta i et standard-felleskap, og hvis de kan delta, så er det
-ikke sikkert at det er på like vilkår. F.eks. kan rettighetsinnehaver
-sette vilkår som gjør at noen faller utenfor, det være seg av
-finansielle, avtalemessige eller prinsipielle årsaker. Vanlige slike
-vilkår er "må betale litt for hver kunde/bruker" som utelukker de som
-gir bort en løsning gratis og "må gi fra seg retten til å håndheve
-sine egne patentrettigheter ovenfor rettighetshaver" som utelukker
-alle som ønsker å beholde den muligheten.
-
-
En åpen standard innebærer for meg at alle kan få innsikt i en
-komplett beskrivelse av oppførsel som standarden skal dekke, og at
-ingen kan nektes å benytte seg av standarden. Noen mener at det
-holder at alle med tilstrekkelig finansiering kan få tilgang til
-spesifikasjonen og at en kun har finansielle krav til bruk.
-Pga. denne konflikten har et nytt begrep spredt seg de siste årene,
-nemlig fri og åpen standard, der en har gjort det klart at alle må ha
-komplett og lik tilgang til spesifikasjoner og retten til å gjøre bruk
-av en standard for at en standard skal kunne kalles fri og åpen.
+
There are two software projects that have had huge influence on the
+quality of free software, and I wanted to mention both in case someone
+do not yet know them.
+
+
The first one is valgrind, a
+tool to detect and expose errors in the memory handling of programs.
+It is easy to use, all one need to do is to run 'valgrind program',
+and it will report any problems on stdout. It is even better if the
+program include debug information. With debug information, it is able
+to report the source file name and line number where the problem
+occurs. It can report things like 'reading past memory block in file
+X line N, the memory block was allocated in file Y, line M', and
+'using uninitialised value in control logic'. This tool has made it
+trivial to investigate reproducible crash bugs in programs, and have
+reduced the number of this kind of bugs in free software a lot.
+
+
The second one is
+Coverity which is
+a source code checker. It is able to process the source of a program
+and find problems in the logic without running the program. It
+started out as the Stanford Checker and became well known when it was
+used to find bugs in the Linux kernel. It is now a commercial tool
+and the company behind it is running
+a community service for the
+free software community, where a lot of free software projects get
+their source checked for free. Several thousand defects have been
+found and fixed so far. It can find errors like 'lock L taken in file
+X line N is never released if exiting in line M', or 'the code in file
+Y lines O to P can never be executed'. The projects included in the
+community service project have managed to get rid of a lot of
+reliability problems thanks to Coverity.
+
+
I believe tools like this, that are able to automatically find
+errors in the source, are vital to improve the quality of software and
+make sure we can get rid of the crashing and failing software we are
+surrounded by today.