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 <div class="entry">
 242  <div class="title">
 243  <a href="../../Standarder_fungerer_best_n__r_en_samler_seg_rundt_dem.html">Standarder fungerer best når en samler seg rundt dem</a>
 244  </div>
 245  <div class="date">
 246   2009-05-19 11:30
 247  </div>
 248
 249  <div class="body">
 250
 251 <p>En standard er noe man samler seg rundt, ut fra ideen om at en får
 252 fordeler når mange står sammen.  Jo flere som står sammen, jo
 253 bedre.  Når en vet dette, blir det litt merkelig å lese noen av
 254 uttalelsene som er kommet inn til
 255 <a href="http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2/horingsuttalelser.html?id=549423">høringen
 256 om versjon 2 av statens referansekatalog over standarder</a>.  Blant
 257 annet Abelia, NHO og Microsoft tror det er lurt med flere standarder
 258 innenfor samme område.  Det blir som å si at det er fint om Norge
 259 standardiserte både på A4- og Letter-størrelser på arkene, ulik
 260 sporvidde på jernbaneskinnene, meter og fot som lengemål, eller
 261 høyre- og venstrekjøring - slik at en kan konkurrere på hvilken
 262 standard som er best.  De fleste forstår heldigvis at dette ikke
 263 bidrar positivt.</p>
 264
 265  </div>
 266  <div class="tags">
 267
 268
 269
 270   Tags: <a href="../../tags/norsk">norsk</a>, <a href="../../tags/nuug">nuug</a>, <a href="../../tags/standard">standard</a>.
 271
 272  </div>
 273 </div>
 274 <div class="padding"></div>
 275
 276 <div class="entry">
 277  <div class="title">
 278  <a href="../../Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html">Microsofts misvisende argumentasjon rundt multimediaformater</a>
 279  </div>
 280  <div class="date">
 281   2009-06-26-13:30
 282  </div>
 283
 284  <div class="body">
 285
 286 <p>I
 287 <a href="http://www.regjeringen.no/upload/FAD/Vedlegg/Hoeringer/Refkat_V2/MicrosoftNorge.pdf">Microsoft
 288 sin høringsuttalelse</a> til
 289 <a href="http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html?id=549422">forslag
 290 til versjon 2 av statens referansekatalog over standarder</a>, lirer
 291 de av seg følgende FUD-perle:</p>
 292
 293 <p><blockquote>"Vorbis, OGG, Theora og FLAC er alle tekniske
 294   spesifikasjoner overordnet styrt av xiph.org, som er en
 295   ikke-kommersiell organisasjon.  Etablerte og anerkjente
 296   standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt
 297   innarbeidet vedlikeholds- og forvaltningsprosess av en standard.
 298   Det er derimot helt opp til hver enkelt organisasjon å bestemme
 299   hvordan tekniske spesifikasjoner videreutvikles og endres, og disse
 300   spesifikasjonene bør derfor ikke defineres som åpne
 301   standarder."</blockquote></p>
 302
 303 <p>De vokter seg vel for å nevne den anerkjente
 304 standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP,
 305 IP og det meste av protokoller på Internet, og RFC-standardene som
 306 IETF står bak.  Ogg er spesifisert i
 307 <a href="http://ietf.org/rfc/rfc3533.txt">RFC 3533</a>, og er uten
 308 tvil å anse som en åpen standard.  Vorbis er
 309 <a href="http://ietf.org/rfc/rfc5215.txt">RFC 5215</a>.  Theora er
 310
 311 under standardisering via IETF, med
 312 <a href="http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt">siste
 313 utkast publisert 2006-07-21</a> (riktignok er dermed teksten ikke
 314 skrevet i stein ennå, men det blir neppe endringer som ikke er
 315 bakoverkompatibel).  De kan være inne på noe når det gjelder FLAC da
 316 jeg ikke finner tegn til at <a
 317 href="http://flac.sourceforge.net/format.html">spesifikasjonen
 318 tilgjengelig på web</a> er på tur via noen
 319 standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora
 320 og Vorbis også har involvert seg i Flac siden 2003, så ser jeg ikke
 321 bort fra at også den organiseres via IETF.  Jeg kjenner personlig lite
 322 til FLAC.</p>
 323
 324 <p>Uredelig argumentasjon bør en holde seg for god til å komme med,
 325 spesielt når det er så enkelt i dagens Internet-hverdag å gå
 326 misvisende påstander etter i sømmene.</p>
 327
 328  </div>
 329  <div class="tags">
 330
 331
 332
 333   Tags: <a href="../../tags/multimedia">multimedia</a>, <a href="../../tags/norsk">norsk</a>, <a href="../../tags/standard">standard</a>, <a href="../../tags/video">video</a>.
 334
 335  </div>
 336 </div>
 337 <div class="padding"></div>
 338
 339 <div class="entry">
 340  <div class="title">
 341  <a href="../../Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html">Regjerningen forlater prinsippet om ingen royalty-betaling i standardkatalogen versjon 2</a>
 342  </div>
 343  <div class="date">
 344   2009-07-06 21:00
 345  </div>
 346
 347  <div class="body">
 348
 349 <p>Jeg ble glad da regjeringen
 350 <a href="http://www.digi.no/817635/her-er-statens-nye-it-standarder">annonserte</a>
 351 versjon 2 av
 352 <a href="http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf">statens
 353 referansekatalog over standarder</a>, men trist da jeg leste hva som
 354 faktisk var vedtatt etter
 355 <a href="http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html">høringen</a>.
 356 De fleste av de valgte åpne standardene er gode og vil bidra til at
 357 alle kan delta på like vilkår i å lage løsninger for staten, men
 358 noen av dem blokkerer for de som ikke har anledning til å benytte
 359 spesifikasjoner som krever betaling for bruk (såkalt
 360 royalty-betaling).  Det gjelder spesifikt for H.264 for video og MP3
 361 for lyd.  Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
 362 Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
 363 fra statens websider gjøre dette uten å måtte bruke programmer der
 364 betaling for bruk var nødvendig.  Når det nå er gjort valgfritt for
 365 de statlige etatene å bruke enten H.264 eller Theora (og MP3 eler
 366 Vorbis), så vil en bli tvunget til å forholde seg til
 367 royalty-belastede standarder for å få tilgang til videoen og
 368 lyden.</p>
 369
 370 <p>Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
 371 at alle standarder som ble valgt til å være påkrevd i katalogen skulle
 372 være uten royalty-betaling.  Jeg håper det ikke betyr at en har mistet
 373 all forståelse for hvilke prinsipper som må følges for å oppnå
 374 likeverdig konkurranse mellom aktørene i IT-bransjen.  NUUG advarte
 375 mot dette i
 376 <a href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2">sin
 377 høringsuttalelse</a>, men ser ut til å ha blitt ignorert.</p>
 378
 379  </div>
 380  <div class="tags">
 381
 382
 383
 384   Tags: <a href="../../tags/multimedia">multimedia</a>, <a href="../../tags/norsk">norsk</a>, <a href="../../tags/nuug">nuug</a>, <a href="../../tags/standard">standard</a>, <a href="../../tags/video">video</a>.
 385
 386  </div>
 387 </div>
 388 <div class="padding"></div>
 389
 390 <div class="entry">
 391  <div class="title">
 392  <a href="../../Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html">Regjerningens oppsummering av høringen om standardkatalogen versjon 2</a>
 393  </div>
 394  <div class="date">
 395   2009-07-09 14:40
 396  </div>
 397
 398  <div class="body">
 399
 400 <p>For å forstå mer om hvorfor standardkatalogens versjon 2 ble som
 401 den ble, har jeg bedt om kopi fra FAD av dokumentene som ble lagt frem
 402 for regjeringen da de tok sin avgjørelse.  De er nå lagt ut på NUUGs
 403 wiki, direkte tilgjengelig via "<a
 404 href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&do=get&target=kongelig-resolusjon.pdf">Referansekatalogen
 405 v2.0 - Oppsummering av høring</a>" og "<a
 406 href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&do=get&target=kongelig-resolusjon-katalogutkast.pdf">Referansekatalog
 407 for IT-standarder i offentlig sektor Versjon 2.0, dd.mm.åååå -
 408 UTKAST</a>".</p>
 409
 410 <p>Det er tre ting jeg merker meg i oppsummeringen fra
 411 høringsuttalelsen da jeg skummet igjennom den.  Det første er at
 412 forståelsen av hvordan programvarepatenter påvirker fri
 413 programvareutvikling også i Norge når en argumenterer med at
 414 royalty-betaling ikke er et relevant problem i Norge.  Det andre er at
 415 FAD ikke har en prinsipiell forståelse av verdien av en enkelt
 416 standard innenfor hvert område.  Det siste er at påstander i
 417 høringsuttalelsene ikke blir etterprøvd (f.eks. påstanden fra
 418 Microsoft om hvordan Ogg blir standardisert og påstanden fra
 419 politidirektoratet om patentproblemer i Theora).</p>
 420
 421  </div>
 422  <div class="tags">
 423
 424
 425
 426   Tags: <a href="../../tags/multimedia">multimedia</a>, <a href="../../tags/norsk">norsk</a>, <a href="../../tags/nuug">nuug</a>, <a href="../../tags/standard">standard</a>, <a href="../../tags/video">video</a>.
 427
 428  </div>
 429 </div>
 430 <div class="padding"></div>
 431
 432  <p style="text-align: right;"><a href="standard.rss"><img src="../../xml.gif" alt="RSS Feed" width="36" height="14"></a></p>
 433
 434
 435
 436
 437 <div id="sidebar">
 438
 439 <h2>Archive</h2>
 440 <ul>
 441
 442 <li>2009
 443 <ul>
 444
 445 <li><a href="../../archive/2009/01/">January (8)</a></li>
 446
 447 <li><a href="../../archive/2009/02/">February (8)</a></li>
 448
 449 <li><a href="../../archive/2009/03/">March (12)</a></li>
 450
 451 <li><a href="../../archive/2009/04/">April (10)</a></li>
 452
 453 <li><a href="../../archive/2009/05/">May (9)</a></li>
 454
 455 <li><a href="../../archive/2009/06/">June (3)</a></li>
 456
 457 <li><a href="../../archive/2009/07/">July (2)</a></li>
 458
 459 </ul></li>
 460
 461 <li>2008
 462 <ul>
 463
 464 <li><a href="../../archive/2008/11/">November (5)</a></li>
 465
 466 <li><a href="../../archive/2008/12/">December (7)</a></li>
 467
 468 </ul></li>
 469
 470 </ul>
 471
 472
 473
 474 <h2>Tags</h2>
 475 <ul>
 476
 477  <li><a href="../../tags/3d-printer">3d-printer (11)</a></li>
 478
 479  <li><a href="../../tags/amiga">amiga (1)</a></li>
 480
 481  <li><a href="../../tags/aros">aros (1)</a></li>
 482
 483  <li><a href="../../tags/debian">debian (12)</a></li>
 484
 485  <li><a href="../../tags/debian edu">debian edu (7)</a></li>
 486
 487  <li><a href="../../tags/english">english (13)</a></li>
 488
 489  <li><a href="../../tags/fiksgatami">fiksgatami (1)</a></li>
 490
 491  <li><a href="../../tags/fildeling">fildeling (3)</a></li>
 492
 493  <li><a href="../../tags/lenker">lenker (1)</a></li>
 494
 495  <li><a href="../../tags/ltsp">ltsp (1)</a></li>
 496
 497  <li><a href="../../tags/multimedia">multimedia (5)</a></li>
 498
 499  <li><a href="../../tags/norsk">norsk (51)</a></li>
 500
 501  <li><a href="../../tags/nuug">nuug (49)</a></li>
 502
 503  <li><a href="../../tags/opphavsrett">opphavsrett (5)</a></li>
 504
 505  <li><a href="../../tags/personvern">personvern (8)</a></li>
 506
 507  <li><a href="../../tags/reprap">reprap (10)</a></li>
 508
 509  <li><a href="../../tags/rss">rss (1)</a></li>
 510
 511  <li><a href="../../tags/sikkerhet">sikkerhet (2)</a></li>
 512
 513  <li><a href="../../tags/standard">standard (7)</a></li>
 514
 515  <li><a href="../../tags/stavekontroll">stavekontroll (1)</a></li>
 516
 517  <li><a href="../../tags/video">video (9)</a></li>
 518
 519  <li><a href="../../tags/vitenskap">vitenskap (1)</a></li>
 520
 521  <li><a href="../../tags/web">web (4)</a></li>
 522
 523 </ul>
 524
 525 </div>
 526 </body>
 527 </html>