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