X-Git-Url: http://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/a593e0644a0d3790b6332b5bc9b3d4b42f7aa32c..60bf8a3f215da8c82ec727e3045793dea8edd5a8:/blog/archive/2009/03/03.rss diff --git a/blog/archive/2009/03/03.rss b/blog/archive/2009/03/03.rss index b78ed49a3d..fb3ed32434 100644 --- a/blog/archive/2009/03/03.rss +++ b/blog/archive/2009/03/03.rss @@ -314,5 +314,211 @@ skyskrapere. Takke meg til en tur til månen.</p> + + Hva er egentlig en åpen standard? + ../../../Hva_er_egentlig_en___pen_standard_.html + ../../../Hva_er_egentlig_en___pen_standard_.html + Sat, 28 Mar 2009 10:50:00 +0100 + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + +<p>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.</p> + + + + + Time for new LDAP schemas replacing RFC 2307? + ../../../Time_for_new__LDAP_schemas_replacing_RFC_2307_.html + ../../../Time_for_new__LDAP_schemas_replacing_RFC_2307_.html + Sun, 29 Mar 2009 20:30:00 +0200 + +<p>The state of standardized LDAP schemas on Linux is far from +optimal. There is RFC 2307 documenting one way to store NIS maps in +LDAP, and a modified version of this normally called RFC 2307bis, with +some modifications to be compatible with Active Directory. The RFC +specification handle the content of a lot of system databases, but do +not handle DNS zones and DHCP configuration.</p> + +<p>In <a href="http://www.skolelinux.org/">Debian Edu/Skolelinux</a>, +we would like to store information about users, SMB clients/hosts, +filegroups, netgroups (users and hosts), DHCP and DNS configuration, +and LTSP configuration in LDAP. These objects have a lot in common, +but with the current LDAP schemas it is not possible to have one +object per entity. For example, one need to have at least three LDAP +objects for a given computer, one with the SMB related stuff, one with +DNS information and another with DHCP information. The schemas +provided for DNS and DHCP are impossible to combine into one LDAP +object. In addition, it is impossible to implement quick queries for +netgroup membership, because of the way NIS triples are implemented. +It just do not scale. I believe it is time for a few RFC +specifications to cleam up this mess.</p> + +<p>I would like to have one LDAP object representing each computer in +the network, and this object can then keep the SMB (ie host key), DHCP +(mac address/name) and DNS (name/IP address) settings in one place. +It need to be efficently stored to make sure it scale well.</p> + +<p>I would also like to have a quick way to map from a user or +computer and to the net group this user or computer is a member.</p> + +<p>Active Directory have done a better job than unix heads like myself +in this regard, and the unix side need to catch up. Time to start a +new IETF work group?</p> + + + + + Returning from Skolelinux developer gathering + ../../../Returning_from_Skolelinux_developer_gathering.html + ../../../Returning_from_Skolelinux_developer_gathering.html + Sun, 29 Mar 2009 21:00:00 +0200 + +<p>I'm sitting on the train going home from this weekends Debian +Edu/Skolelinux development gathering. I got a bit done tuning the +desktop, and looked into the dynamic service location protocol +implementation avahi. It look like it could be useful for us. Almost +30 people participated, and I believe it was a great environment to +get to know the Skolelinux system. Walter Bender, involved in the +development of the Sugar educational platform, presented his stuff and +also helped me improve my OLPC installation. He also showed me that +his Turtle Art application can be used in standalone mode, and we +agreed that I would help getting it packaged for Debian. As a +standalone application it would be great for Debian Edu. We also +tried to get the video conferencing working with two OLPCs, but that +proved to be too hard for us. The application seem to need more work +before it is ready for me. I look forward to getting home and relax +now. :)</p> + + + + + Standardize on protocols and formats, not vendors and applications + ../../../Standardize_on_protocols_and_formats__not_vendors_and_applications.html + ../../../Standardize_on_protocols_and_formats__not_vendors_and_applications.html + Mon, 30 Mar 2009 11:50:00 +0200 + +<p>Where I work at the University of Oslo, one decision stand out as a +very good one to form a long lived computer infrastructure. It is the +simple one, lost by many in todays computer industry: Standardize on +open network protocols and open exchange/storage formats, not applications. +Applications come and go, while protocols and files tend to stay, and +thus one want to make it easy to change application and vendor, while +avoiding conversion costs and locking users to a specific platform or +application.</p> + +<p>This approach make it possible to replace the client applications +independently of the server applications. One can even allow users to +use several different applications as long as they handle the selected +protocol and format. In the normal case, only one client application +is recommended and users only get help if they choose to use this +application, but those that want to deviate from the easy path are not +blocked from doing so.</p> + +<p>It also allow us to replace the server side without forcing the +users to replace their applications, and thus allow us to select the +best server implementation at any moment, when scale and resouce +requirements change.</p> + +<p>I strongly recommend standardizing - on open network protocols and +open formats, but I would never recommend standardizing on a single +application that do not use open network protocol or open formats.</p> + + +