]> pere.pagekite.me Git - homepage.git/blob - blog/tags/standard/index.html
5578b4230bc6926e482a827be83e1de74f2cb928
[homepage.git] / blog / tags / standard / index.html
1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
2 "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
3 <html>
4 <head>
5 <title>Petter Reinholdtsen: Entries Tagged standard</title>
6 <link rel="stylesheet" type="text/css" media="screen" href="../../style.css">
7 <link rel="alternate" title="RSS Feed" href="standard.rss" type="application/rss+xml">
8 </head>
9 <body>
10
11 <div class="title">
12 <h1>
13 <a href="../../">Petter Reinholdtsen</a>
14
15 </h1>
16
17 </div>
18
19 <p>Entries tagged "standard".</p>
20
21
22
23
24 <div class="entry">
25 <div class="title">
26 <a href="../../Hva_er_egentlig_en___pen_standard_.html">Hva er egentlig en åpen standard?</a>
27 </div>
28 <div class="date">
29 2009-03-28 10:50
30 </div>
31
32 <div class="body">
33
34 <p>Jeg møter alle slags interessante mennesker på min vei, og et møte
35 jeg lærte mye av var å treffe på en svært kompetent IT-fyr som
36 benektet ting jeg anser som åpenbart og selvfølgelig når det gjelder
37 standarder. Det var interessant, da det fikk meg til å tenke litt
38 nøyere på hvilke mekanismer som ligger til grunn for at noe oppfattes
39 som en standard. Det hele startet med arbeid rundt integrering av NSS
40 LDAP mot Active Directory, og problemer som oppstår pga. at Active
41 Directory ikke følger LDAP-spesifikasjonen som dokumentert i RFCer fra
42 IETF (konkret, AD returnerer kun et subset av attributter hvis det er
43 mer enn 1500 atributter av en gitt type i et LDAP-objekt, og en må be
44 om resten i bolker av 1500). Jeg hevdet måten dette ble gjort på brøt
45 med LDAP-spesifikasjonen, og henviste til hvor i LDAP-spesifikasjonen
46 fra IETF det sto at oppførselen til AD ikke fulgte
47 LDAP-spesifikasjonen. AD-spesialisten overrasket meg da ved å
48 fortelle at IETF var ikke de som definerte LDAP-spesifikasjonen, og at
49 Active Directory ikke brøt den virkelige LDAP-spesifikasjonen som han
50 mente lå til grunn. Jeg ble spesielt overrasket over denne
51 tilnærmingen til problemstillingen, da til og med Microsoft så vidt
52 jeg kan se anerkjenner IETF som organisasjonen som definerer
53 LDAP-spesifikasjonen. Jeg fikk aldri spurt hvem han mente sto bak den
54 egentlige LDAP-spesifikasjonen, da det var irrelevant for problemet vi
55 måtte løse (få Linux og AD til å fungere sammen). Dette møtet
56 fortalte meg uansett at det ikke er gitt at alle aktører er enige om
57 hva en standard er, og hva som er kilden til en gitt standard. Det er
58 vanskelig å enes om felles standarder før en først enes om hvem som
59 bestemmer hva en gitt standard innebærer.</p>
60
61 <p>Hva er så en standard? I sin abstrakte form er det noe å samles
62 om. På engelsk er en av betydningene fane brukt i krig, du vet, den
63 type fane en samlet seg rundt på kamplassen i riddertiden. En
64 standard definerer altså et felleskap, noen som har noe felles. Det
65 er naturligvis mange måter å utgjøre et felleskap på. En kan
66 f.eks. enes om å gjøre alt slik som Ole gjør det, og dermed si at Oles
67 oppførsel er standard. Hver gang Ole endrer oppførsel endrer også
68 standarden seg uten noe mer organisering og prosedyre. En variant av
69 dette er å gjøre slik som Ole har gjort det i stedet for slik Ole til
70 enhver til gjør noe. Dette er ofte litt enklere å forholde seg til,
71 da en slipper å sjekke med Ole hver gang for å vite hvordan ting skal
72 gjøres nå, men hvis det Ole gjorde noe dumt den gang en bestemte seg
73 for å følge Ole, så er det vanskeligere å få endret oppførsel for å
74 unngå dette dumme.</p>
75
76 <p>En kan også ta det et skritt videre, og istedet for å basere seg på
77 enkeltpersoners oppførsel sette seg ned og bli enige om hvordan en
78 skal gjøre ting, dvs. lage et felleskap basert på konsensus. Dette
79 tar naturligvis litt mer tid (en må diskutere ting i forkant før en
80 kan sette igang), men det kan bidra til at den oppførselen en
81 planlegger å benytte seg av er mer gjennomtenkt. Det ender også
82 typisk opp med en beskrivelse av ønsket oppførsel som flere kan forstå
83 - da flere har vært involvert i å utarbeide beskrivelsen.</p>
84
85 <p>Dette er dessverre ikke alt som trengs for å forstå hva en åpen
86 standard er for noe. Der alle kan se på hvordan folk oppfører seg, og
87 dermed har valget om de vil oppføre seg likt eller ikke, så er det
88 endel juridiske faktorer som gjør det hele mer komplisert -
89 opphavsretten og patentlovgivningen for å være helt konkret. For å gi
90 et eksempel. Hvis noen blir enige om å alltid plystre en bestemt
91 melodi når de møtes, for å identifisere hverandre, så kan
92 opphavsretten brukes til å styre hvem som får lov til å gjøre dette.
93 De har standardisert hvordan de kjenner igjen alle som følger denne
94 standarden, men ikke alle har nødvendigvis lov til å følge den.
95 Musikk er opphavsrettsbeskyttet, og fremføring av musikk i
96 offentligheten er opphavsmannens enerett (dvs. et monopol). Det vil i
97 sin ytterste konsekvens si at alle som skal plystre en
98 opphavsrettsbeskyttet melodi i det offentlige rom må ha godkjenning
99 fra opphavsmannen. Har en ikke dette, så bryter en loven og kan
100 straffes. Det er dermed mulig for opphavsmannen å kontrollere hvem
101 som får lov til å benytte seg av denne standarden. En annen variant
102 er hvis en standard er dokumentert, så er dokumentet som definerer
103 standarden (spesifikasjonen) beskyttet av opphavsretten, og det er
104 dermed mulig for rettighetsinnehaver å begrense tilgang til
105 spesifikasjonen, og slik styre hvem som kan ta i bruk standarden på
106 den måten.</p>
107
108 <p>Der opphavsretten innvilger et monopol på kunstneriske uttrykk med
109 verkshøyde, innvilger patentlovgivningen monopol på ideer. Hvis en
110 slik patentert idé (fortrinnsvis uttrykt i en teknisk innretning, men
111 det er kompliserende faktorer som gjør at det ikke er et krav) trengs
112 for å ta i bruk en standard, så vil den som innehar patent kunne styre
113 hvem som får ta i bruk standarden. Det er dermed ikke gitt at alle
114 kan delta i et standard-felleskap, og hvis de kan delta, så er det
115 ikke sikkert at det er på like vilkår. F.eks. kan rettighetsinnehaver
116 sette vilkår som gjør at noen faller utenfor, det være seg av
117 finansielle, avtalemessige eller prinsipielle årsaker. Vanlige slike
118 vilkår er "må betale litt for hver kunde/bruker" som utelukker de som
119 gir bort en løsning gratis og "må gi fra seg retten til å håndheve
120 sine egne patentrettigheter ovenfor rettighetshaver" som utelukker
121 alle som ønsker å beholde den muligheten.</p>
122
123 <p>En åpen standard innebærer for meg at alle kan få innsikt i en
124 komplett beskrivelse av oppførsel som standarden skal dekke, og at
125 ingen kan nektes å benytte seg av standarden. Noen mener at det
126 holder at alle med tilstrekkelig finansiering kan få tilgang til
127 spesifikasjonen og at en kun har finansielle krav til bruk.
128 Pga. denne konflikten har et nytt begrep spredt seg de siste årene,
129 nemlig fri og åpen standard, der en har gjort det klart at alle må ha
130 komplett og lik tilgang til spesifikasjoner og retten til å gjøre bruk
131 av en standard for at en standard skal kunne kalles fri og åpen.</p>
132
133 </div>
134 <div class="tags">
135
136
137
138 Tags: <a href="../../tags/norsk">norsk</a>, <a href="../../tags/nuug">nuug</a>, <a href="../../tags/standard">standard</a>.
139
140 </div>
141 </div>
142 <div class="padding"></div>
143
144 <div class="entry">
145 <div class="title">
146 <a href="../../Standardize_on_protocols_and_formats__not_vendors_and_applications.html">Standardize on protocols and formats, not vendors and applications</a>
147 </div>
148 <div class="date">
149 2009-03-30 11:50
150 </div>
151
152 <div class="body">
153
154 <p>Where I work at the University of Oslo, one decision stand out as a
155 very good one to form a long lived computer infrastructure. It is the
156 simple one, lost by many in todays computer industry: Standardize on
157 open network protocols and open exchange/storage formats, not applications.
158 Applications come and go, while protocols and files tend to stay, and
159 thus one want to make it easy to change application and vendor, while
160 avoiding conversion costs and locking users to a specific platform or
161 application.</p>
162
163 <p>This approach make it possible to replace the client applications
164 independently of the server applications. One can even allow users to
165 use several different applications as long as they handle the selected
166 protocol and format. In the normal case, only one client application
167 is recommended and users only get help if they choose to use this
168 application, but those that want to deviate from the easy path are not
169 blocked from doing so.</p>
170
171 <p>It also allow us to replace the server side without forcing the
172 users to replace their applications, and thus allow us to select the
173 best server implementation at any moment, when scale and resouce
174 requirements change.</p>
175
176 <p>I strongly recommend standardizing - on open network protocols and
177 open formats, but I would never recommend standardizing on a single
178 application that do not use open network protocol or open formats.</p>
179
180 </div>
181 <div class="tags">
182
183
184
185 Tags: <a href="../../tags/debian">debian</a>, <a href="../../tags/english">english</a>, <a href="../../tags/nuug">nuug</a>, <a href="../../tags/standard">standard</a>.
186
187 </div>
188 </div>
189 <div class="padding"></div>
190
191 <div class="entry">
192 <div class="title">
193 <a href="../../Hvorfor_jeg_ikke_bruker_eFaktura.html">Hvorfor jeg ikke bruker eFaktura</a>
194 </div>
195 <div class="date">
196 2009-04-23 23:00
197 </div>
198
199 <div class="body">
200
201 <p>Telenors annonsering om å kreve 35 kroner i gebyr fra alle som
202 ønsker papirfaktura har satt sinnene i kok, og pressedekningen så
203 langt snakker om at eldre og folk som ikke behersker data vil få en
204 urimelig ekstrakostnad. Jeg tror ikke jeg passer inn i noen av de
205 kategoriene, men velger å holde meg unna eFaktura - som er det
206 Telenor ønsker å få folk over på - pga. systemets egenskaper.</p>
207
208 <p>Slik jeg har sett eFaktura til forbrukere så langt, så sender
209 selger en elektronisk beskjed til kundens bank, som legger ut
210 informasjon om fakturaen i nettbanken for godkjenning. Personlig
211 ville jeg sett det som mer naturlig at det gikk en elektronisk beskjed
212 fra selger til kunde, dvs meg, og at jeg så kunne bruke den videre
213 mot banken eller andre hvis jeg ønsket dette. Mine innkjøp og
214 regninger er jo en sak mellom meg og mine leverandører, ikke en sak
215 mellom min bank og mine leverandører. Kun hvis jeg ønsker å betale
216 fakturaen skal banken involveres. En faktura bør jo inn i
217 regnskapet, og jeg ønsker mulighet til å legge det inn der. Når
218 fakturaen sendes til banken i stedet for meg, blir det vanskeligere.
219 Hele eFaktura-modellen virker på meg som en umyndiggjøring av meg
220 som kunde.</p>
221
222 <p>I tillegg har jeg ikke vært i stand til å finne
223 eFaktura-formatets spesifikasjon, og det ser ut til at utsending av
224 slike krever dyre avtaler med bankene for å få lov til å sende ut
225 eFaktura til kunder. Jeg ser vel helst at fakturering på
226 elektroniske formater kan gjøres f.eks. via epost eller HTTP uten å
227 måtte betale mellommenn for retten til å lever ut en faktura, og
228 liker rett og slett ikke dagens faktureringsmodeller.</p>
229
230 </div>
231 <div class="tags">
232
233
234
235 Tags: <a href="../../tags/norsk">norsk</a>, <a href="../../tags/nuug">nuug</a>, <a href="../../tags/standard">standard</a>.
236
237 </div>
238 </div>
239 <div class="padding"></div>
240
241 <p style="text-align: right;"><a href="standard.rss"><img src="../../xml.gif" alt="RSS Feed" width="36" height="14"></a></p>
242
243
244
245
246 <div id="sidebar">
247
248 <h2>Archive</h2>
249 <ul>
250
251 <li>2009
252 <ul>
253
254 <li><a href="../../archive/2009/01/">January (8)</a></li>
255
256 <li><a href="../../archive/2009/02/">February (8)</a></li>
257
258 <li><a href="../../archive/2009/03/">March (12)</a></li>
259
260 <li><a href="../../archive/2009/04/">April (7)</a></li>
261
262 </ul></li>
263
264 <li>2008
265 <ul>
266
267 <li><a href="../../archive/2008/11/">November (5)</a></li>
268
269 <li><a href="../../archive/2008/12/">December (7)</a></li>
270
271 </ul></li>
272
273 </ul>
274
275
276
277 <h2>Tags</h2>
278 <ul>
279
280 <li><a href="../../tags/3d-printer">3d-printer (10)</a></li>
281
282 <li><a href="../../tags/amiga">amiga (1)</a></li>
283
284 <li><a href="../../tags/aros">aros (1)</a></li>
285
286 <li><a href="../../tags/debian">debian (6)</a></li>
287
288 <li><a href="../../tags/debian edu">debian edu (6)</a></li>
289
290 <li><a href="../../tags/english">english (10)</a></li>
291
292 <li><a href="../../tags/fiksgatami">fiksgatami (1)</a></li>
293
294 <li><a href="../../tags/fildeling">fildeling (2)</a></li>
295
296 <li><a href="../../tags/ltsp">ltsp (1)</a></li>
297
298 <li><a href="../../tags/multimedia">multimedia (2)</a></li>
299
300 <li><a href="../../tags/norsk">norsk (37)</a></li>
301
302 <li><a href="../../tags/nuug">nuug (36)</a></li>
303
304 <li><a href="../../tags/personvern">personvern (5)</a></li>
305
306 <li><a href="../../tags/reprap">reprap (10)</a></li>
307
308 <li><a href="../../tags/rss">rss (1)</a></li>
309
310 <li><a href="../../tags/standard">standard (3)</a></li>
311
312 <li><a href="../../tags/stavekontroll">stavekontroll (1)</a></li>
313
314 <li><a href="../../tags/video">video (6)</a></li>
315
316 <li><a href="../../tags/vitenskap">vitenskap (1)</a></li>
317
318 <li><a href="../../tags/web">web (4)</a></li>
319
320 </ul>
321
322 </div>
323 </body>
324 </html>