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>Relative popularity of document formats (MS Office vs. ODF)</title>
  11                 <link>Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html</link>
  12                 <guid isPermaLink="true">Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html</guid>
  13                 <pubDate>Wed, 12 Aug 2009 15:50:00 +0200</pubDate>
  14                 <description>
  15 &lt;p&gt;Just for fun, I did a search right now on Google for a few file ODF
  16 and MS Office based formats (not to be mistaken for ISO or ECMA
  17 OOXML), to get an idea of their relative usage.  I searched using
  18 &#39;filetype:odt&#39; and equvalent terms, and got these results:&lt;/P&gt;
  19
  20 &lt;table&gt;
  21 &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;
  22 &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;
  23 &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;
  24 &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;
  25 &lt;/table&gt;
  26
  27 &lt;p&gt;Next, I added a &#39;site:no&#39; limit to get the numbers for Norway, and
  28 got these numbers:&lt;/p&gt;
  29
  30 &lt;table&gt;
  31 &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;
  32 &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;
  33 &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;
  34 &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;
  35 &lt;/table&gt;
  36
  37 &lt;p&gt;I wonder how these numbers change over time.&lt;/p&gt;
  38
  39 &lt;p&gt;I am aware of Google returning different results and numbers based
  40 on where the search is done, so I guess these numbers will differ if
  41 they are conduced in another country.  Because of this, I did the same
  42 search from a machine in California, USA, a few minutes after the
  43 search done from a machine here in Norway.&lt;/p&gt;
  44
  45
  46 &lt;table&gt;
  47 &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;
  48 &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;
  49 &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;
  50 &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;
  51 &lt;/table&gt;
  52
  53 &lt;p&gt;And with &#39;site:no&#39;:
  54
  55 &lt;table&gt;
  56 &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;
  57 &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;
  58 &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;
  59 &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;
  60 &lt;/table&gt;
  61
  62 &lt;p&gt;Interesting difference, not sure what to conclude from these
  63 numbers.&lt;/p&gt;
  64 </description>
  65         </item>
  66
  67         <item>
  68                 <title>ISO still hope to fix OOXML</title>
  69                 <link>ISO_still_hope_to_fix_OOXML.html</link>
  70                 <guid isPermaLink="true">ISO_still_hope_to_fix_OOXML.html</guid>
  71                 <pubDate>Sat, 8 Aug 2009 14:00:00 +0200</pubDate>
  72                 <description>
  73 &lt;p&gt;According to &lt;a
  74 href=&quot;http://twerner.blogspot.com/2009/08/defects-of-office-open-xml.html&quot;&gt;a
  75 blog post from Torsten Werner&lt;/a&gt;, the current defect report for ISO
  76 29500 (ISO OOXML) is 809 pages.  His interesting point is that the
  77 defect report is 71 pages more than the full ODF 1.1 specification.
  78 Personally I find it more interesting that ISO still believe ISO OOXML
  79 can be fixed in ISO.  Personally, I believe it is broken beyon repair,
  80 and I completely lack any trust in ISO for being able to get anywhere
  81 close to solving the problems.  I was part of the Norwegian committee
  82 involved in the OOXML fast track process, and was not impressed with
  83 Standard Norway and ISO in how they handled it.&lt;/p&gt;
  84
  85 &lt;p&gt;These days I focus on ODF instead, which seem like a specification
  86 with the future ahead of it.  We are working in NUUG to organise a ODF
  87 seminar this autumn.&lt;/p&gt;
  88 </description>
  89         </item>
  90
  91         <item>
  92                 <title>Debian has switched to dependency based boot sequencing</title>
  93                 <link>Debian_has_switched_to_dependency_based_boot_sequencing.html</link>
  94                 <guid isPermaLink="true">Debian_has_switched_to_dependency_based_boot_sequencing.html</guid>
  95                 <pubDate>Mon, 27 Jul 2009 23:50:00 +0200</pubDate>
  96                 <description>
  97 &lt;p&gt;Since this evening, with the upload of sysvinit version 2.87dsf-2,
  98 and the upload of insserv version 1.12.0-10 yesterday, Debian unstable
  99 have been migrated to using dependency based boot sequencing.  This
 100 conclude work me and others have been doing for the last three days.
 101 It feels great to see this finally part of the default Debian
 102 installation.  Now we just need to weed out the last few problems that
 103 are bound to show up, to get everything ready for Squeeze.&lt;/p&gt;
 104
 105 &lt;p&gt;The next step is migrating /sbin/init from sysvinit to upstart, and
 106 fixing the more fundamental problem of handing the event based
 107 non-predictable kernel in the early boot.&lt;/p&gt;
 108 </description>
 109         </item>
 110
 111         <item>
 112                 <title>Taking over sysvinit development</title>
 113                 <link>Taking_over_sysvinit_development.html</link>
 114                 <guid isPermaLink="true">Taking_over_sysvinit_development.html</guid>
 115                 <pubDate>Wed, 22 Jul 2009 23:00:00 +0200</pubDate>
 116                 <description>
 117 &lt;p&gt;After several years of frustration with the lack of activity from
 118 the existing sysvinit upstream developer, I decided a few weeks ago to
 119 take over the package and become the new upstream.  The number of
 120 patches to track for the Debian package was becoming a burden, and the
 121 lack of synchronization between the distribution made it hard to keep
 122 the package up to date.&lt;/p&gt;
 123
 124 &lt;p&gt;On the new sysvinit team is the SuSe maintainer Dr. Werner Fink,
 125 and my Debian co-maintainer Kel Modderman.  About 10 days ago, I made
 126 a new upstream tarball with version number 2.87dsf (for Debian, SuSe
 127 and Fedora), based on the patches currently in use in these
 128 distributions.  We Debian maintainers plan to move to this tarball as
 129 the new upstream as soon as we find time to do the merge.  Since the
 130 new tarball was created, we agreed with Werner at SuSe to make a new
 131 upstream project at &lt;a href=&quot;http://savannah.nongnu.org/&quot;&gt;Savannah&lt;/a&gt;, and continue
 132 development there.  The project is registered and currently waiting
 133 for approval by the Savannah administrators, and as soon as it is
 134 approved, we will import the old versions from svn and continue
 135 working on the future release.&lt;/p&gt;
 136
 137 &lt;p&gt;It is a bit ironic that this is done now, when some of the involved
 138 distributions are moving to upstart as a syvinit replacement.&lt;/p&gt;
 139 </description>
 140         </item>
 141
 142         <item>
 143                 <title>Regjerningens oppsummering av høringen om standardkatalogen versjon 2</title>
 144                 <link>Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html</link>
 145                 <guid isPermaLink="true">Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html</guid>
 146                 <pubDate>Thu, 9 Jul 2009 14:40:00 +0200</pubDate>
 147                 <description>
 148 &lt;p&gt;For å forstå mer om hvorfor standardkatalogens versjon 2 ble som
 149 den ble, har jeg bedt om kopi fra FAD av dokumentene som ble lagt frem
 150 for regjeringen da de tok sin avgjørelse.  De er nå lagt ut på NUUGs
 151 wiki, direkte tilgjengelig via &quot;&lt;a
 152 href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&amp;do=get&amp;target=kongelig-resolusjon.pdf&quot;&gt;Referansekatalogen
 153 v2.0 - Oppsummering av høring&lt;/a&gt;&quot; og &quot;&lt;a
 154 href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&amp;do=get&amp;target=kongelig-resolusjon-katalogutkast.pdf&quot;&gt;Referansekatalog
 155 for IT-standarder i offentlig sektor Versjon 2.0, dd.mm.åååå -
 156 UTKAST&lt;/a&gt;&quot;.&lt;/p&gt;
 157
 158 &lt;p&gt;Det er tre ting jeg merker meg i oppsummeringen fra
 159 høringsuttalelsen da jeg skummet igjennom den.  Det første er at
 160 forståelsen av hvordan programvarepatenter påvirker fri
 161 programvareutvikling også i Norge når en argumenterer med at
 162 royalty-betaling ikke er et relevant problem i Norge.  Det andre er at
 163 FAD ikke har en prinsipiell forståelse av verdien av en enkelt
 164 standard innenfor hvert område.  Det siste er at påstander i
 165 høringsuttalelsene ikke blir etterprøvd (f.eks. påstanden fra
 166 Microsoft om hvordan Ogg blir standardisert og påstanden fra
 167 politidirektoratet om patentproblemer i Theora).&lt;/p&gt;
 168 </description>
 169         </item>
 170
 171         <item>
 172                 <title>Regjerningen forlater prinsippet om ingen royalty-betaling i standardkatalogen versjon 2</title>
 173                 <link>Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html</link>
 174                 <guid isPermaLink="true">Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html</guid>
 175                 <pubDate>Mon, 6 Jul 2009 21:00:00 +0200</pubDate>
 176                 <description>
 177 &lt;p&gt;Jeg ble glad da regjeringen
 178 &lt;a href=&quot;http://www.digi.no/817635/her-er-statens-nye-it-standarder&quot;&gt;annonserte&lt;/a&gt;
 179 versjon 2 av
 180 &lt;a href=&quot;http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf&quot;&gt;statens
 181 referansekatalog over standarder&lt;/a&gt;, men trist da jeg leste hva som
 182 faktisk var vedtatt etter
 183 &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;.
 184 De fleste av de valgte åpne standardene er gode og vil bidra til at
 185 alle kan delta på like vilkår i å lage løsninger for staten, men
 186 noen av dem blokkerer for de som ikke har anledning til å benytte
 187 spesifikasjoner som krever betaling for bruk (såkalt
 188 royalty-betaling).  Det gjelder spesifikt for H.264 for video og MP3
 189 for lyd.  Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
 190 Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
 191 fra statens websider gjøre dette uten å måtte bruke programmer der
 192 betaling for bruk var nødvendig.  Når det nå er gjort valgfritt for
 193 de statlige etatene å bruke enten H.264 eller Theora (og MP3 eler
 194 Vorbis), så vil en bli tvunget til å forholde seg til
 195 royalty-belastede standarder for å få tilgang til videoen og
 196 lyden.&lt;/p&gt;
 197
 198 &lt;p&gt;Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
 199 at alle standarder som ble valgt til å være påkrevd i katalogen skulle
 200 være uten royalty-betaling.  Jeg håper det ikke betyr at en har mistet
 201 all forståelse for hvilke prinsipper som må følges for å oppnå
 202 likeverdig konkurranse mellom aktørene i IT-bransjen.  NUUG advarte
 203 mot dette i
 204 &lt;a href=&quot;http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2&quot;&gt;sin
 205 høringsuttalelse&lt;/a&gt;, men ser ut til å ha blitt ignorert.&lt;/p&gt;
 206 </description>
 207         </item>
 208
 209         <item>
 210                 <title>Microsofts misvisende argumentasjon rundt multimediaformater</title>
 211                 <link>Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html</link>
 212                 <guid isPermaLink="true">Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html</guid>
 213                 <pubDate>Fri, 26 Jun 2009 15:30:00 +0200</pubDate>
 214                 <description>
 215 &lt;p&gt;I
 216 &lt;a href=&quot;http://www.regjeringen.no/upload/FAD/Vedlegg/Hoeringer/Refkat_V2/MicrosoftNorge.pdf&quot;&gt;Microsoft
 217 sin høringsuttalelse&lt;/a&gt; til
 218 &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
 219 til versjon 2 av statens referansekatalog over standarder&lt;/a&gt;, lirer
 220 de av seg følgende FUD-perle:&lt;/p&gt;
 221
 222 &lt;p&gt;&lt;blockquote&gt;&quot;Vorbis, OGG, Theora og FLAC er alle tekniske
 223   spesifikasjoner overordnet styrt av xiph.org, som er en
 224   ikke-kommersiell organisasjon.  Etablerte og anerkjente
 225   standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt
 226   innarbeidet vedlikeholds- og forvaltningsprosess av en standard.
 227   Det er derimot helt opp til hver enkelt organisasjon å bestemme
 228   hvordan tekniske spesifikasjoner videreutvikles og endres, og disse
 229   spesifikasjonene bør derfor ikke defineres som åpne
 230   standarder.&quot;&lt;/blockquote&gt;&lt;/p&gt;
 231
 232 &lt;p&gt;De vokter seg vel for å nevne den anerkjente
 233 standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP,
 234 IP og det meste av protokoller på Internet, og RFC-standardene som
 235 IETF står bak.  Ogg er spesifisert i
 236 &lt;a href=&quot;http://ietf.org/rfc/rfc3533.txt&quot;&gt;RFC 3533&lt;/a&gt;, og er uten
 237 tvil å anse som en åpen standard.  Vorbis er
 238 &lt;a href=&quot;http://ietf.org/rfc/rfc5215.txt&quot;&gt;RFC 5215&lt;/a&gt;.  Theora er
 239
 240 under standardisering via IETF, med
 241 &lt;a href=&quot;http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt&quot;&gt;siste
 242 utkast publisert 2006-07-21&lt;/a&gt; (riktignok er dermed teksten ikke
 243 skrevet i stein ennå, men det blir neppe endringer som ikke er
 244 bakoverkompatibel).  De kan være inne på noe når det gjelder FLAC da
 245 jeg ikke finner tegn til at &lt;a
 246 href=&quot;http://flac.sourceforge.net/format.html&quot;&gt;spesifikasjonen
 247 tilgjengelig på web&lt;/a&gt; er på tur via noen
 248 standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora
 249 og Vorbis også har involvert seg i Flac siden 2003, så ser jeg ikke
 250 bort fra at også den organiseres via IETF.  Jeg kjenner personlig lite
 251 til FLAC.&lt;/p&gt;
 252
 253 &lt;p&gt;Uredelig argumentasjon bør en holde seg for god til å komme med,
 254 spesielt når det er så enkelt i dagens Internet-hverdag å gå
 255 misvisende påstander etter i sømmene.&lt;/p&gt;
 256 </description>
 257         </item>
 258
 259         <item>
 260                 <title>Debian boots quicker and quicker</title>
 261                 <link>Debian_boots_quicker_and_quicker.html</link>
 262                 <guid isPermaLink="true">Debian_boots_quicker_and_quicker.html</guid>
 263                 <pubDate>Wed, 24 Jun 2009 21:40:00 +0200</pubDate>
 264                 <description>
 265 &lt;p&gt;I spent Monday and tuesday this week in London with a lot of the
 266 people involved in the boot system on Debian and Ubuntu, to see if we
 267 could find more ways to speed up the boot system.  This was an Ubuntu
 268 funded
 269 &lt;a href=&quot;https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint&quot;&gt;developer
 270 gathering&lt;/a&gt;. It was quite productive.  We also discussed the future
 271 of boot systems, and ways to handle the increasing number of boot
 272 issues introduced by the Linux kernel becoming more and more
 273 asynchronous and event base.  The Ubuntu approach using udev and
 274 upstart might be a good way forward.  Time will show.&lt;/p&gt;
 275
 276 &lt;p&gt;Anyway, there are a few ways at the moment to speed up the boot
 277 process in Debian.  All of these should be applied to get a quick
 278 boot:&lt;/p&gt;
 279
 280 &lt;ul&gt;
 281
 282 &lt;li&gt;Use dash as /bin/sh.&lt;/li&gt;
 283
 284 &lt;li&gt;Disable the init.d/hwclock*.sh scripts and make sure the hardware
 285    clock is in UTC.&lt;/li&gt;
 286
 287 &lt;li&gt;Install and activate the insserv package to enable
 288    &lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
 289    based boot sequencing&lt;/a&gt;, and enable concurrent booting.&lt;/li&gt;
 290
 291 &lt;/ul&gt;
 292
 293 These points are based on the Google summer of code work done by
 294 &lt;a href=&quot;http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/&quot;&gt;Carlos
 295 Villegas&lt;/a&gt;.
 296
 297 &lt;p&gt;Support for makefile-style concurrency during boot was uploaded to
 298 unstable yesterday.  When we tested it, we were able to cut 6 seconds
 299 from the boot sequence.  It depend on very correct dependency
 300 declaration in all init.d scripts, so I expect us to find edge cases
 301 where the dependences in some scripts are slightly wrong when we start
 302 using this.&lt;/p&gt;
 303
 304 &lt;p&gt;On our IRC channel for this effort, #pkg-sysvinit, a new idea was
 305 introduced by Raphael Geissert today, one that could affect the
 306 startup speed as well.  Instead of starting some scripts concurrently
 307 from rcS.d/ and another set of scripts from rc2.d/, it would be
 308 possible to run a of them in the same process.  A quick way to test
 309 this would be to enable insserv and run &#39;mv /etc/rc2.d/S* /etc/rcS.d/;
 310 insserv&#39;.  Will need to test if that work. :)&lt;/p&gt;
 311 </description>
 312         </item>
 313
 314         <item>
 315                 <title>Litt om valgfusk og problemet med elektronisk stemmegiving</title>
 316                 <link>Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html</link>
 317                 <guid isPermaLink="true">Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html</guid>
 318                 <pubDate>Wed, 17 Jun 2009 14:20:00 +0200</pubDate>
 319                 <description>
 320 &lt;p&gt;&lt;a href=&quot;http://www.aftenposten.no/nyheter/uriks/article3127058.ece&quot;&gt;Aftenposten
 321 melder&lt;/a&gt; at det kan se ut til at Iran ikke har lært av USA når det
 322 gjelder valgfusk.  En bør endre tallene før de publiseres, slik at en
 323 kandidat aldri får færre stemmer under opptellingen, ellers blir det
 324 veldig tydelig at tallene ikke er til å stole på.  I USA er det
 325 derimot &lt;a href=&quot;http://www.blackboxvoting.org/&quot;&gt;rapporter om at
 326 tallene har vært endret&lt;/a&gt; på tur mot opptellingen, ikke etter at
 327 tallene er publiserte (i tillegg til en rekke andre irregulariteter).
 328 En ting Iran åpenbart har forstått, er verdien av å kunne
 329 kontrolltelle stemmer.  Det ligger an til kontrolltelling i hvert fall
 330 i noen områder.  Hvorvidt det har verdi, kommer an på hvordan
 331 stemmene har vært oppbevart.&lt;/p&gt;
 332
 333 &lt;p&gt;&lt;a href=&quot;http://universitas.no/kronikk/48334/kan-vi-stole-pa-universitetets-elektroniske-valgsystem-/&quot;&gt;Universitetet
 334 i Oslo derimot&lt;/a&gt;, har ikke forstått verdien av å kunne
 335 kontrolltelle.  Her har en valgt å ta i bruk elektronisk stemmegiving
 336 over Internet, med et system som ikke kan kontrolltelles hvis det
 337 kommer anklager om juks med stemmene.  Systemet har flere kjente
 338 problemer og er i mine øyne ikke bedre enn en spørreundersøkelse, og
 339 jeg har derfor latt være å stemme ved valg på UiO siden det ble
 340 innført.&lt;/p&gt;
 341
 342 &lt;p&gt;Universitet i Bergen derimot har klart det kunststykket å aktivt gå
 343 inn for å gjøre det kjent at det elektroniske stemmegivingssystemet
 344 over Internet &lt;a href=&quot;http://nyheter.uib.no/?modus=vis_nyhet&amp;id=43404&quot;&gt;kan
 345 spore hvem som stemmer hva&lt;/a&gt; (det kan en forøvrig også ved UiO), og tatt
 346 kontakt med stemmegivere for å spørre hvorfor de stemte som de gjorde.
 347 Hemmelige valg står for fall.  Mon tro hva stemmesedlenne hadde
 348 inneholdt i Iran hvis de ikke hadde hemmelige valg?&lt;/p&gt;
 349 </description>
 350         </item>
 351
 352         <item>
 353                 <title>Standarder fungerer best når en samler seg rundt dem</title>
 354                 <link>Standarder_fungerer_best_n__r_en_samler_seg_rundt_dem.html</link>
 355                 <guid isPermaLink="true">Standarder_fungerer_best_n__r_en_samler_seg_rundt_dem.html</guid>
 356                 <pubDate>Tue, 19 May 2009 11:30:00 +0200</pubDate>
 357                 <description>
 358 &lt;p&gt;En standard er noe man samler seg rundt, ut fra ideen om at en får
 359 fordeler når mange står sammen.  Jo flere som står sammen, jo
 360 bedre.  Når en vet dette, blir det litt merkelig å lese noen av
 361 uttalelsene som er kommet inn til
 362 &lt;a href=&quot;http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2/horingsuttalelser.html?id=549423&quot;&gt;høringen
 363 om versjon 2 av statens referansekatalog over standarder&lt;/a&gt;.  Blant
 364 annet Abelia, NHO og Microsoft tror det er lurt med flere standarder
 365 innenfor samme område.  Det blir som å si at det er fint om Norge
 366 standardiserte både på A4- og Letter-størrelser på arkene, ulik
 367 sporvidde på jernbaneskinnene, meter og fot som lengemål, eller
 368 høyre- og venstrekjøring - slik at en kan konkurrere på hvilken
 369 standard som er best.  De fleste forstår heldigvis at dette ikke
 370 bidrar positivt.&lt;/p&gt;
 371 </description>
 372         </item>
 373
 374         </channel>
 375 </rss>