blog/index.rss

   1 <?xml version="1.0" encoding="utf-8"?>
   2 <rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/' xmlns:atom="http://www.w3.org/2005/Atom">
   3         <channel>
   4                 <title>Petter Reinholdtsen</title>
   5                 <description></description>
   6                 <link></link>
   7                 <atom:link href="index.rss" rel="self" type="application/rss+xml" />
   8
   9         <item>
  10                 <title>Internet-sensur skal i retten på mandag</title>
  11                 <link>Internet_sensur_skal_i_retten_p___mandag.html</link>
  12                 <guid isPermaLink="true">Internet_sensur_skal_i_retten_p___mandag.html</guid>
  13                 <pubDate>Sat, 10 Oct 2009 22:00:00 +0200</pubDate>
  14                 <description>
  15 &lt;p&gt;&lt;a href=&quot;http://www.dagensit.no/bransje/article1757755.ece&quot;&gt;DagensIT&lt;/a&gt;
  16 melder at Telenor og Tono skal i retten på mandag for å diskutere
  17 hvorvidt Tonos krav om at Telenor skal blokkere for tilgang til The
  18 Pirate Bay er i tråd med norsk rett.  Det blir interessant å se
  19 resultatet fra den rettsaken.&lt;/p&gt;
  20
  21 &lt;p&gt;Jeg bet meg dog merke i en av påstandene fra Tonos advokat Cato
  22 Strøm, som forteller at &quot;Pirate Bay inneholder 95 prosent ulovlig
  23 utlagt materiale, og å stanse tilgangen til det kan ikke kalles
  24 sensur&quot;.  Jeg tok en titt på
  25 &lt;a href=&quot;http://thepiratebay.org/&quot;&gt;forsiden til The Pirate Bay&lt;/a&gt;,
  26 som forteller at det pr. i dag er 1 884 694 torrenter på trackeren.
  27 Dette tilsvarer antall filer en kan søke blant og hente ned ved hjelp
  28 av The Pirate Bay.  5% av dette antallet er 94 235.  Det kan dermed
  29 virke som om Tonos advokat mener at det ikke er sensur å blokkere for
  30 tilgang til nesten 100 000 lovlige filer.  Jeg lurer på om han er
  31 korrekt sitert.&lt;/p&gt;
  32
  33 &lt;p&gt;Lurer også på hvor 95%-tallet kommer fram.  Er det seriøs og
  34 etterprøvbar forskning på området som viser at dette er andelen
  35 ulovlige filer tilgjengelig via The Pirate Bay, eller er det
  36 musikkbransjenes egne tall?  De har
  37 &lt;a href=&quot;http://www.guardian.co.uk/music/2009/oct/06/edwyn-collins-sharing-music&quot;&gt;jo
  38 demonstrert&lt;/a&gt; at de ikke er i stand til å skille lovlig og ulovlig
  39 bruk av musikk.&lt;/p&gt;
  40 </description>
  41         </item>
  42
  43         <item>
  44                 <title>MVA på bøker med DRM, ikke MVA på bøker uten DRM?</title>
  45                 <link>MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html</link>
  46                 <guid isPermaLink="true">MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html</guid>
  47                 <pubDate>Wed, 23 Sep 2009 10:00:00 +0200</pubDate>
  48                 <description>
  49 &lt;p&gt;Elektroniske bøker diskuteres for tiden, etter at
  50 &lt;a href=&quot;http://www.aftenposten.no/kul_und/litteratur/article3280914.ece&quot;&gt;bokbransjen
  51 hevder&lt;/a&gt; det er usikkert om de kommer til å gi ut elektroniske
  52 bøker så lenge det er merverdiavgift på elektroniske bøker og ikke
  53 på papirbøker.  I den forbindelse så jeg et interessant forslag i
  54 en
  55 &lt;a href=&quot;http://www.digi.no/php/ny_debatt.php?id=823912&quot;&gt;digi-debatt&lt;/a&gt;
  56 jeg hadde sans for. &quot;einarr&quot; foreslo at DRM-infiserte elektroniske
  57 bøker bør ha merverdiavgift, da &quot;de ikke bidrar til
  58 kunnskapsspredning på samme måte&quot; som papirbøker og dermed går
  59 imot intensjonene bak mva-fritaket.  Bøker uten DRM derimot bør ha
  60 mva-fritak da de &quot;kan overføres mellom enheter, leses på ulike
  61 plattformer, lånes ut og siteres og kopieres fra&quot; slik en kan med
  62 papirbøker.&lt;/p&gt;
  63
  64 &lt;p&gt;En oppfølgerkommentar sier seg enig i dette, da DRM-infisert
  65 materiale må anses som leid og dermed en tjeneste, mens materiale uten
  66 DRM må anses som et kjøp.&lt;/p&gt;
  67 </description>
  68         </item>
  69
  70         <item>
  71                 <title>Sikkerhet til sjøs trenger sjøkart uten bruksbegresninger</title>
  72                 <link>Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html</link>
  73                 <guid isPermaLink="true">Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html</guid>
  74                 <pubDate>Sun, 23 Aug 2009 10:00:00 +0200</pubDate>
  75                 <description>
  76 &lt;p&gt;Sikkerhet til sjøs burde være noe som opptar mange etter den siste
  77 oljeutslippsulykken med Full City, som har drept mye liv langs sjøen.
  78 En viktig faktor for å bedre sikkerheten til sjøs er at alle som
  79 ferdes på sjøen har tilgang til oppdaterte sjøkart som forteller hvor
  80 det grunner og annet en må ta hensyn til på sjøen.&lt;/p&gt;
  81
  82 &lt;p&gt;Hvis en er enig i at tilgang til oppdaterte sjøkart er viktig for
  83 sikkerheten på sjøen, så er det godt å vite at det i dag er teknisk
  84 mulig å sikre alle enkel tilgang til oppdaterte digitale kart over
  85 Internet.  Det trenger heller ikke være spesielt kostbart.&lt;/p&gt;
  86
  87 &lt;p&gt;Både ved Rocknes-ulykken i Vatlestraumen, der 18 mennesker mistet
  88 livet, og ved Full City-ulykken utenfor Langesund, der mange tonn olje
  89 lekket ut i havet, var det registrert problemer relatert til
  90 oppdaterte sjøkart.  Ved Rocknes-ulykken var de elektroniske kartene
  91 som ble brukt ikke oppdatert med informasjon om nyoppdagede grunner og
  92 losen kjente visst ikke til disse nye grunnene.  Papirkartene var dog
  93 oppdaterte.  Ved Full City-ulykken hadde en kontroll av skipet noen
  94 uker tidligere konstatert manglende sjøkart.&lt;/p&gt;
  95
  96 &lt;p&gt;Jeg tror en løsning der digitale sjøkart kunne lastes ned direkte
  97 fra sjøkartverket av alle som ønsket oppdaterte sjøkart, uten
  98 brukerbetaling og uten bruksbegresninger knyttet til kartene, vil
  99 gjøre at flere folk på sjøen vil holde seg med oppdaterte sjøkart,
 100 eller sjøkart i det hele tatt.  Resultatet av dette vil være økt
 101 sikkerhet på sjøen.  En undersøkelse gjennomført av Opinion for
 102 Gjensidige i 2008 fortalte at halvparten av alle båteierne i landet
 103 ikke har sjøkart i båten.&lt;/p&gt;
 104
 105 &lt;p&gt;Formatet på de digitale sjøkartene som gjøræs tilgjengelig fra
 106 sjøkartverket må være i henhold til en fri og åpen standard, slik at
 107 en ikke er låst til enkeltaktørers godvilje når datafilene skal tolkes
 108 og forstås, men trenger ikke publiseres fra sjøkartverket i alle
 109 formatene til verdens skips-GPS-er i tillegg.  Hvis det ikke er
 110 kostbart for sjøkartverket bør de gjerne gjøre det selv, men slik
 111 konvertering kan andre ta seg av hvis det er et marked for det.&lt;/p&gt;
 112
 113 &lt;p&gt;Hvis staten mener alvor med å forbedre sikkerheten til sjøs, må de
 114 gjøre sitt for at alle båteiere har oppdaterte kart, ikke bare snakke
 115 om hvor viktig det er at de har oppdaterte kart.  Det bør være
 116 viktigere for staten at båtene &lt;strong&gt;har&lt;/strong&gt; oppdaterte kart
 117 enn at de er pålagt å ha oppdaterte kart.&lt;/p&gt;
 118
 119 &lt;p&gt;Sjøkartene er &lt;a href=&quot;http://kart.kystverket.no/&quot;&gt;tilgjengelig på web
 120 fra kystverket&lt;/a&gt;, men så vidt jeg har klart å finne, uten
 121 bruksvilkår som muliggjør gjenbruk uten bruksbegresninger.&lt;/p&gt;
 122
 123 &lt;p&gt;OpenStreetmap.org-folk er lei av mangel på sjøkart, og har startet
 124 på et dugnadsbasert fribrukskart for havet,
 125 &lt;a href=&quot;http://openseamap.org/&quot;&gt;OpenSeaMap&lt;/a&gt;.  Datagrunnlaget er
 126 OpenStreetmap, mens framvisningen er tilpasset bruk på sjøen.  Det
 127 gjenstår mye før en kan bruke dette til å seile sikkert på havet, men
 128 det viser at behovet for fribruks-sjøkart er til stedet.&lt;/p&gt;
 129 </description>
 130         </item>
 131
 132         <item>
 133                 <title>Relative popularity of document formats (MS Office vs. ODF)</title>
 134                 <link>Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html</link>
 135                 <guid isPermaLink="true">Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html</guid>
 136                 <pubDate>Wed, 12 Aug 2009 15:50:00 +0200</pubDate>
 137                 <description>
 138 &lt;p&gt;Just for fun, I did a search right now on Google for a few file ODF
 139 and MS Office based formats (not to be mistaken for ISO or ECMA
 140 OOXML), to get an idea of their relative usage.  I searched using
 141 &#39;filetype:odt&#39; and equvalent terms, and got these results:&lt;/P&gt;
 142
 143 &lt;table&gt;
 144 &lt;tr&gt;&lt;th&gt;Type&lt;/th&gt;&lt;th&gt;ODF&lt;/th&gt;&lt;th&gt;MS Office&lt;/th&gt;&lt;/tr&gt;
 145 &lt;tr&gt;&lt;td&gt;Tekst&lt;/td&gt; &lt;td&gt;odt:282000&lt;/td&gt; &lt;td&gt;docx:308000&lt;/td&gt;&lt;/tr&gt;
 146 &lt;tr&gt;&lt;td&gt;Presentasjon&lt;/td&gt; &lt;td&gt;odp:75600&lt;/td&gt; &lt;td&gt;pptx:183000&lt;/td&gt;&lt;/tr&gt;
 147 &lt;tr&gt;&lt;td&gt;Regneark&lt;/td&gt; &lt;td&gt;ods:26500     &lt;/td&gt; &lt;td&gt;xlsx:145000&lt;/td&gt;&lt;/tr&gt;
 148 &lt;/table&gt;
 149
 150 &lt;p&gt;Next, I added a &#39;site:no&#39; limit to get the numbers for Norway, and
 151 got these numbers:&lt;/p&gt;
 152
 153 &lt;table&gt;
 154 &lt;tr&gt;&lt;th&gt;Type&lt;/th&gt;&lt;th&gt;ODF&lt;/th&gt;&lt;th&gt;MS Office&lt;/th&gt;&lt;/tr&gt;
 155 &lt;tr&gt;&lt;td&gt;Tekst&lt;/td&gt; &lt;td&gt;odt:2480 &lt;/td&gt; &lt;td&gt;docx:4460&lt;/td&gt;&lt;/tr&gt;
 156 &lt;tr&gt;&lt;td&gt;Presentasjon&lt;/td&gt; &lt;td&gt;odp:299   &lt;/td&gt; &lt;td&gt;pptx:741&lt;/td&gt;&lt;/tr&gt;
 157 &lt;tr&gt;&lt;td&gt;Regneark&lt;/td&gt; &lt;td&gt;ods:187       &lt;/td&gt; &lt;td&gt;xlsx:372&lt;/td&gt;&lt;/tr&gt;
 158 &lt;/table&gt;
 159
 160 &lt;p&gt;I wonder how these numbers change over time.&lt;/p&gt;
 161
 162 &lt;p&gt;I am aware of Google returning different results and numbers based
 163 on where the search is done, so I guess these numbers will differ if
 164 they are conduced in another country.  Because of this, I did the same
 165 search from a machine in California, USA, a few minutes after the
 166 search done from a machine here in Norway.&lt;/p&gt;
 167
 168
 169 &lt;table&gt;
 170 &lt;tr&gt;&lt;th&gt;Type&lt;/th&gt;&lt;th&gt;ODF&lt;/th&gt;&lt;th&gt;MS Office&lt;/th&gt;&lt;/tr&gt;
 171 &lt;tr&gt;&lt;td&gt;Tekst&lt;/td&gt; &lt;td&gt;odt:129000&lt;/td&gt; &lt;td&gt;docx:308000&lt;/td&gt;&lt;/tr&gt;
 172 &lt;tr&gt;&lt;td&gt;Presentasjon&lt;/td&gt; &lt;td&gt;odp:44200&lt;/td&gt; &lt;td&gt;pptx:93900&lt;/td&gt;&lt;/tr&gt;
 173 &lt;tr&gt;&lt;td&gt;Regneark&lt;/td&gt; &lt;td&gt;ods:26500     &lt;/td&gt; &lt;td&gt;xlsx:82400&lt;/td&gt;&lt;/tr&gt;
 174 &lt;/table&gt;
 175
 176 &lt;p&gt;And with &#39;site:no&#39;:
 177
 178 &lt;table&gt;
 179 &lt;tr&gt;&lt;th&gt;Type&lt;/th&gt;&lt;th&gt;ODF&lt;/th&gt;&lt;th&gt;MS Office&lt;/th&gt;&lt;/tr&gt;
 180 &lt;tr&gt;&lt;td&gt;Tekst&lt;/td&gt; &lt;td&gt;odt:2480&lt;/td&gt; &lt;td&gt;docx:3410&lt;/td&gt;&lt;/tr&gt;
 181 &lt;tr&gt;&lt;td&gt;Presentasjon&lt;/td&gt; &lt;td&gt;odp:175&lt;/td&gt; &lt;td&gt;pptx:604&lt;/td&gt;&lt;/tr&gt;
 182 &lt;tr&gt;&lt;td&gt;Regneark&lt;/td&gt; &lt;td&gt;ods:186       &lt;/td&gt; &lt;td&gt;xlsx:296&lt;/td&gt;&lt;/tr&gt;
 183 &lt;/table&gt;
 184
 185 &lt;p&gt;Interesting difference, not sure what to conclude from these
 186 numbers.&lt;/p&gt;
 187 </description>
 188         </item>
 189
 190         <item>
 191                 <title>ISO still hope to fix OOXML</title>
 192                 <link>ISO_still_hope_to_fix_OOXML.html</link>
 193                 <guid isPermaLink="true">ISO_still_hope_to_fix_OOXML.html</guid>
 194                 <pubDate>Sat, 8 Aug 2009 14:00:00 +0200</pubDate>
 195                 <description>
 196 &lt;p&gt;According to &lt;a
 197 href=&quot;http://twerner.blogspot.com/2009/08/defects-of-office-open-xml.html&quot;&gt;a
 198 blog post from Torsten Werner&lt;/a&gt;, the current defect report for ISO
 199 29500 (ISO OOXML) is 809 pages.  His interesting point is that the
 200 defect report is 71 pages more than the full ODF 1.1 specification.
 201 Personally I find it more interesting that ISO still believe ISO OOXML
 202 can be fixed in ISO.  Personally, I believe it is broken beyon repair,
 203 and I completely lack any trust in ISO for being able to get anywhere
 204 close to solving the problems.  I was part of the Norwegian committee
 205 involved in the OOXML fast track process, and was not impressed with
 206 Standard Norway and ISO in how they handled it.&lt;/p&gt;
 207
 208 &lt;p&gt;These days I focus on ODF instead, which seem like a specification
 209 with the future ahead of it.  We are working in NUUG to organise a ODF
 210 seminar this autumn.&lt;/p&gt;
 211 </description>
 212         </item>
 213
 214         <item>
 215                 <title>Debian has switched to dependency based boot sequencing</title>
 216                 <link>Debian_has_switched_to_dependency_based_boot_sequencing.html</link>
 217                 <guid isPermaLink="true">Debian_has_switched_to_dependency_based_boot_sequencing.html</guid>
 218                 <pubDate>Mon, 27 Jul 2009 23:50:00 +0200</pubDate>
 219                 <description>
 220 &lt;p&gt;Since this evening, with the upload of sysvinit version 2.87dsf-2,
 221 and the upload of insserv version 1.12.0-10 yesterday, Debian unstable
 222 have been migrated to using dependency based boot sequencing.  This
 223 conclude work me and others have been doing for the last three days.
 224 It feels great to see this finally part of the default Debian
 225 installation.  Now we just need to weed out the last few problems that
 226 are bound to show up, to get everything ready for Squeeze.&lt;/p&gt;
 227
 228 &lt;p&gt;The next step is migrating /sbin/init from sysvinit to upstart, and
 229 fixing the more fundamental problem of handing the event based
 230 non-predictable kernel in the early boot.&lt;/p&gt;
 231 </description>
 232         </item>
 233
 234         <item>
 235                 <title>Taking over sysvinit development</title>
 236                 <link>Taking_over_sysvinit_development.html</link>
 237                 <guid isPermaLink="true">Taking_over_sysvinit_development.html</guid>
 238                 <pubDate>Wed, 22 Jul 2009 23:00:00 +0200</pubDate>
 239                 <description>
 240 &lt;p&gt;After several years of frustration with the lack of activity from
 241 the existing sysvinit upstream developer, I decided a few weeks ago to
 242 take over the package and become the new upstream.  The number of
 243 patches to track for the Debian package was becoming a burden, and the
 244 lack of synchronization between the distribution made it hard to keep
 245 the package up to date.&lt;/p&gt;
 246
 247 &lt;p&gt;On the new sysvinit team is the SuSe maintainer Dr. Werner Fink,
 248 and my Debian co-maintainer Kel Modderman.  About 10 days ago, I made
 249 a new upstream tarball with version number 2.87dsf (for Debian, SuSe
 250 and Fedora), based on the patches currently in use in these
 251 distributions.  We Debian maintainers plan to move to this tarball as
 252 the new upstream as soon as we find time to do the merge.  Since the
 253 new tarball was created, we agreed with Werner at SuSe to make a new
 254 upstream project at &lt;a href=&quot;http://savannah.nongnu.org/&quot;&gt;Savannah&lt;/a&gt;, and continue
 255 development there.  The project is registered and currently waiting
 256 for approval by the Savannah administrators, and as soon as it is
 257 approved, we will import the old versions from svn and continue
 258 working on the future release.&lt;/p&gt;
 259
 260 &lt;p&gt;It is a bit ironic that this is done now, when some of the involved
 261 distributions are moving to upstart as a syvinit replacement.&lt;/p&gt;
 262 </description>
 263         </item>
 264
 265         <item>
 266                 <title>Regjerningens oppsummering av høringen om standardkatalogen versjon 2</title>
 267                 <link>Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html</link>
 268                 <guid isPermaLink="true">Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html</guid>
 269                 <pubDate>Thu, 9 Jul 2009 14:40:00 +0200</pubDate>
 270                 <description>
 271 &lt;p&gt;For å forstå mer om hvorfor standardkatalogens versjon 2 ble som
 272 den ble, har jeg bedt om kopi fra FAD av dokumentene som ble lagt frem
 273 for regjeringen da de tok sin avgjørelse.  De er nå lagt ut på NUUGs
 274 wiki, direkte tilgjengelig via &quot;&lt;a
 275 href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&amp;do=get&amp;target=kongelig-resolusjon.pdf&quot;&gt;Referansekatalogen
 276 v2.0 - Oppsummering av høring&lt;/a&gt;&quot; og &quot;&lt;a
 277 href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&amp;do=get&amp;target=kongelig-resolusjon-katalogutkast.pdf&quot;&gt;Referansekatalog
 278 for IT-standarder i offentlig sektor Versjon 2.0, dd.mm.åååå -
 279 UTKAST&lt;/a&gt;&quot;.&lt;/p&gt;
 280
 281 &lt;p&gt;Det er tre ting jeg merker meg i oppsummeringen fra
 282 høringsuttalelsen da jeg skummet igjennom den.  Det første er at
 283 forståelsen av hvordan programvarepatenter påvirker fri
 284 programvareutvikling også i Norge når en argumenterer med at
 285 royalty-betaling ikke er et relevant problem i Norge.  Det andre er at
 286 FAD ikke har en prinsipiell forståelse av verdien av en enkelt
 287 standard innenfor hvert område.  Det siste er at påstander i
 288 høringsuttalelsene ikke blir etterprøvd (f.eks. påstanden fra
 289 Microsoft om hvordan Ogg blir standardisert og påstanden fra
 290 politidirektoratet om patentproblemer i Theora).&lt;/p&gt;
 291 </description>
 292         </item>
 293
 294         <item>
 295                 <title>Regjerningen forlater prinsippet om ingen royalty-betaling i standardkatalogen versjon 2</title>
 296                 <link>Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html</link>
 297                 <guid isPermaLink="true">Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html</guid>
 298                 <pubDate>Mon, 6 Jul 2009 21:00:00 +0200</pubDate>
 299                 <description>
 300 &lt;p&gt;Jeg ble glad da regjeringen
 301 &lt;a href=&quot;http://www.digi.no/817635/her-er-statens-nye-it-standarder&quot;&gt;annonserte&lt;/a&gt;
 302 versjon 2 av
 303 &lt;a href=&quot;http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf&quot;&gt;statens
 304 referansekatalog over standarder&lt;/a&gt;, men trist da jeg leste hva som
 305 faktisk var vedtatt etter
 306 &lt;a href=&quot;http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html&quot;&gt;høringen&lt;/a&gt;.
 307 De fleste av de valgte åpne standardene er gode og vil bidra til at
 308 alle kan delta på like vilkår i å lage løsninger for staten, men
 309 noen av dem blokkerer for de som ikke har anledning til å benytte
 310 spesifikasjoner som krever betaling for bruk (såkalt
 311 royalty-betaling).  Det gjelder spesifikt for H.264 for video og MP3
 312 for lyd.  Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
 313 Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
 314 fra statens websider gjøre dette uten å måtte bruke programmer der
 315 betaling for bruk var nødvendig.  Når det nå er gjort valgfritt for
 316 de statlige etatene å bruke enten H.264 eller Theora (og MP3 eler
 317 Vorbis), så vil en bli tvunget til å forholde seg til
 318 royalty-belastede standarder for å få tilgang til videoen og
 319 lyden.&lt;/p&gt;
 320
 321 &lt;p&gt;Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
 322 at alle standarder som ble valgt til å være påkrevd i katalogen skulle
 323 være uten royalty-betaling.  Jeg håper det ikke betyr at en har mistet
 324 all forståelse for hvilke prinsipper som må følges for å oppnå
 325 likeverdig konkurranse mellom aktørene i IT-bransjen.  NUUG advarte
 326 mot dette i
 327 &lt;a href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2&quot;&gt;sin
 328 høringsuttalelse&lt;/a&gt;, men ser ut til å ha blitt ignorert.&lt;/p&gt;
 329 </description>
 330         </item>
 331
 332         <item>
 333                 <title>Microsofts misvisende argumentasjon rundt multimediaformater</title>
 334                 <link>Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html</link>
 335                 <guid isPermaLink="true">Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html</guid>
 336                 <pubDate>Fri, 26 Jun 2009 15:30:00 +0200</pubDate>
 337                 <description>
 338 &lt;p&gt;I
 339 &lt;a href=&quot;http://www.regjeringen.no/upload/FAD/Vedlegg/Hoeringer/Refkat_V2/MicrosoftNorge.pdf&quot;&gt;Microsoft
 340 sin høringsuttalelse&lt;/a&gt; til
 341 &lt;a href=&quot;http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html?id=549422&quot;&gt;forslag
 342 til versjon 2 av statens referansekatalog over standarder&lt;/a&gt;, lirer
 343 de av seg følgende FUD-perle:&lt;/p&gt;
 344
 345 &lt;p&gt;&lt;blockquote&gt;&quot;Vorbis, OGG, Theora og FLAC er alle tekniske
 346   spesifikasjoner overordnet styrt av xiph.org, som er en
 347   ikke-kommersiell organisasjon.  Etablerte og anerkjente
 348   standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt
 349   innarbeidet vedlikeholds- og forvaltningsprosess av en standard.
 350   Det er derimot helt opp til hver enkelt organisasjon å bestemme
 351   hvordan tekniske spesifikasjoner videreutvikles og endres, og disse
 352   spesifikasjonene bør derfor ikke defineres som åpne
 353   standarder.&quot;&lt;/blockquote&gt;&lt;/p&gt;
 354
 355 &lt;p&gt;De vokter seg vel for å nevne den anerkjente
 356 standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP,
 357 IP og det meste av protokoller på Internet, og RFC-standardene som
 358 IETF står bak.  Ogg er spesifisert i
 359 &lt;a href=&quot;http://ietf.org/rfc/rfc3533.txt&quot;&gt;RFC 3533&lt;/a&gt;, og er uten
 360 tvil å anse som en åpen standard.  Vorbis er
 361 &lt;a href=&quot;http://ietf.org/rfc/rfc5215.txt&quot;&gt;RFC 5215&lt;/a&gt;.  Theora er
 362
 363 under standardisering via IETF, med
 364 &lt;a href=&quot;http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt&quot;&gt;siste
 365 utkast publisert 2006-07-21&lt;/a&gt; (riktignok er dermed teksten ikke
 366 skrevet i stein ennå, men det blir neppe endringer som ikke er
 367 bakoverkompatibel).  De kan være inne på noe når det gjelder FLAC da
 368 jeg ikke finner tegn til at &lt;a
 369 href=&quot;http://flac.sourceforge.net/format.html&quot;&gt;spesifikasjonen
 370 tilgjengelig på web&lt;/a&gt; er på tur via noen
 371 standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora
 372 og Vorbis også har involvert seg i Flac siden 2003, så ser jeg ikke
 373 bort fra at også den organiseres via IETF.  Jeg kjenner personlig lite
 374 til FLAC.&lt;/p&gt;
 375
 376 &lt;p&gt;Uredelig argumentasjon bør en holde seg for god til å komme med,
 377 spesielt når det er så enkelt i dagens Internet-hverdag å gå
 378 misvisende påstander etter i sømmene.&lt;/p&gt;
 379 </description>
 380         </item>
 381
 382         </channel>
 383 </rss>