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