blog/index.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
   2         "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
   3 <html>
   4  <head>
   5   <title>Petter Reinholdtsen</title>
   6   <link rel="stylesheet" type="text/css" media="screen" href="style.css">
   7   <link rel="alternate" title="RSS Feed" href="index.rss" type="application/rss+xml">
   8
   9  </head>
  10  <body>
  11
  12  <div class="title">
  13   <h1>
  14        <a href="">Petter Reinholdtsen</a>
  15
  16   </h1>
  17
  18  </div>
  19
  20
  21
  22  <div class="entry">
  23   <div class="title"><a href="MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html">MVA på bøker med DRM, ikke MVA på bøker uten DRM?</a></div>
  24   <div class="date">2009-09-23 10:00</div>
  25   <div class="body">
  26 <p>Elektroniske bøker diskuteres for tiden, etter at
  27 <a href="http://www.aftenposten.no/kul_und/litteratur/article3280914.ece">bokbransjen
  28 hevder</a> det er usikkert om de kommer til å gi ut elektroniske
  29 bøker så lenge det er merverdiavgift på elektroniske bøker og ikke
  30 på papirbøker.  I den forbindelse så jeg et interessant forslag i
  31 en
  32 <a href="http://www.digi.no/php/ny_debatt.php?id=823912">digi-debatt</a>
  33 jeg hadde sans for. "einarr" foreslo at DRM-infiserte elektroniske
  34 bøker bør ha merverdiavgift, da "de ikke bidrar til
  35 kunnskapsspredning på samme måte" som papirbøker og dermed går
  36 imot intensjonene bak mva-fritaket.  Bøker uten DRA derimot bør ha
  37 mva-fritak da de "kan overføres mellom enheter, leses på ulike
  38 plattformer, lånes ut og siteres og kopieres fra" slik en kan med
  39 papirbøker.</p>
  40
  41 <p>En oppfølgerkommentar sier seg enig i dette, da DRM-infisert
  42 materiale må anses som leid og dermed en tjeneste, mens materiale uten
  43 DRM må anses som et kjøp.</p>
  44 </div>
  45   <div class="tags">
  46
  47
  48
  49    Tags: <a href="tags/norsk">norsk</a>, <a href="tags/nuug">nuug</a>, <a href="tags/opphavsrett">opphavsrett</a>.
  50
  51   </div>
  52  </div>
  53  <div class="padding"></div>
  54
  55  <div class="entry">
  56   <div class="title"><a href="Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html">Sikkerhet til sjøs trenger sjøkart uten bruksbegresninger</a></div>
  57   <div class="date">2009-08-23 10:00</div>
  58   <div class="body">
  59 <p>Sikkerhet til sjøs burde være noe som opptar mange etter den siste
  60 oljeutslippsulykken med Full City, som har drept mye liv langs sjøen.
  61 En viktig faktor for å bedre sikkerheten til sjøs er at alle som
  62 ferdes på sjøen har tilgang til oppdaterte sjøkart som forteller hvor
  63 det grunner og annet en må ta hensyn til på sjøen.</p>
  64
  65 <p>Hvis en er enig i at tilgang til oppdaterte sjøkart er viktig for
  66 sikkerheten på sjøen, så er det godt å vite at det i dag er teknisk
  67 mulig å sikre alle enkel tilgang til oppdaterte digitale kart over
  68 Internet.  Det trenger heller ikke være spesielt kostbart.</p>
  69
  70 <p>Både ved Rocknes-ulykken i Vatlestraumen, der 18 mennesker mistet
  71 livet, og ved Full City-ulykken utenfor Langesund, der mange tonn olje
  72 lekket ut i havet, var det registrert problemer relatert til
  73 oppdaterte sjøkart.  Ved Rocknes-ulykken var de elektroniske kartene
  74 som ble brukt ikke oppdatert med informasjon om nyoppdagede grunner og
  75 losen kjente visst ikke til disse nye grunnene.  Papirkartene var dog
  76 oppdaterte.  Ved Full City-ulykken hadde en kontroll av skipet noen
  77 uker tidligere konstatert manglende sjøkart.</p>
  78
  79 <p>Jeg tror en løsning der digitale sjøkart kunne lastes ned direkte
  80 fra sjøkartverket av alle som ønsket oppdaterte sjøkart, uten
  81 brukerbetaling og uten bruksbegresninger knyttet til kartene, vil
  82 gjøre at flere folk på sjøen vil holde seg med oppdaterte sjøkart,
  83 eller sjøkart i det hele tatt.  Resultatet av dette vil være økt
  84 sikkerhet på sjøen.  En undersøkelse gjennomført av Opinion for
  85 Gjensidige i 2008 fortalte at halvparten av alle båteierne i landet
  86 ikke har sjøkart i båten.</p>
  87
  88 <p>Formatet på de digitale sjøkartene som gjøræs tilgjengelig fra
  89 sjøkartverket må være i henhold til en fri og åpen standard, slik at
  90 en ikke er låst til enkeltaktørers godvilje når datafilene skal tolkes
  91 og forstås, men trenger ikke publiseres fra sjøkartverket i alle
  92 formatene til verdens skips-GPS-er i tillegg.  Hvis det ikke er
  93 kostbart for sjøkartverket bør de gjerne gjøre det selv, men slik
  94 konvertering kan andre ta seg av hvis det er et marked for det.</p>
  95
  96 <p>Hvis staten mener alvor med å forbedre sikkerheten til sjøs, må de
  97 gjøre sitt for at alle båteiere har oppdaterte kart, ikke bare snakke
  98 om hvor viktig det er at de har oppdaterte kart.  Det bør være
  99 viktigere for staten at båtene <strong>har</strong> oppdaterte kart
 100 enn at de er pålagt å ha oppdaterte kart.</p>
 101
 102 <p>Sjøkartene er <a href="http://kart.kystverket.no/">tilgjengelig på web
 103 fra kystverket</a>, men så vidt jeg har klart å finne, uten
 104 bruksvilkår som muliggjør gjenbruk uten bruksbegresninger.</p>
 105
 106 <p>OpenStreetmap.org-folk er lei av mangel på sjøkart, og har startet
 107 på et dugnadsbasert fribrukskart for havet,
 108 <a href="http://openseamap.org/">OpenSeaMap</a>.  Datagrunnlaget er
 109 OpenStreetmap, mens framvisningen er tilpasset bruk på sjøen.  Det
 110 gjenstår mye før en kan bruke dette til å seile sikkert på havet, men
 111 det viser at behovet for fribruks-sjøkart er til stedet.</p>
 112 </div>
 113   <div class="tags">
 114
 115
 116
 117    Tags: <a href="tags/norsk">norsk</a>, <a href="tags/nuug">nuug</a>, <a href="tags/opphavsrett">opphavsrett</a>, <a href="tags/sikkerhet">sikkerhet</a>.
 118
 119   </div>
 120  </div>
 121  <div class="padding"></div>
 122
 123  <div class="entry">
 124   <div class="title"><a href="Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html">Relative popularity of document formats (MS Office vs. ODF)</a></div>
 125   <div class="date">2009-08-12 15:50</div>
 126   <div class="body">
 127 <p>Just for fun, I did a search right now on Google for a few file ODF
 128 and MS Office based formats (not to be mistaken for ISO or ECMA
 129 OOXML), to get an idea of their relative usage.  I searched using
 130 'filetype:odt' and equvalent terms, and got these results:</P>
 131
 132 <table>
 133 <tr><th>Type</th><th>ODF</th><th>MS Office</th></tr>
 134 <tr><td>Tekst</td> <td>odt:282000</td> <td>docx:308000</td></tr>
 135 <tr><td>Presentasjon</td> <td>odp:75600</td> <td>pptx:183000</td></tr>
 136 <tr><td>Regneark</td> <td>ods:26500     </td> <td>xlsx:145000</td></tr>
 137 </table>
 138
 139 <p>Next, I added a 'site:no' limit to get the numbers for Norway, and
 140 got these numbers:</p>
 141
 142 <table>
 143 <tr><th>Type</th><th>ODF</th><th>MS Office</th></tr>
 144 <tr><td>Tekst</td> <td>odt:2480 </td> <td>docx:4460</td></tr>
 145 <tr><td>Presentasjon</td> <td>odp:299   </td> <td>pptx:741</td></tr>
 146 <tr><td>Regneark</td> <td>ods:187       </td> <td>xlsx:372</td></tr>
 147 </table>
 148
 149 <p>I wonder how these numbers change over time.</p>
 150
 151 <p>I am aware of Google returning different results and numbers based
 152 on where the search is done, so I guess these numbers will differ if
 153 they are conduced in another country.  Because of this, I did the same
 154 search from a machine in California, USA, a few minutes after the
 155 search done from a machine here in Norway.</p>
 156
 157
 158 <table>
 159 <tr><th>Type</th><th>ODF</th><th>MS Office</th></tr>
 160 <tr><td>Tekst</td> <td>odt:129000</td> <td>docx:308000</td></tr>
 161 <tr><td>Presentasjon</td> <td>odp:44200</td> <td>pptx:93900</td></tr>
 162 <tr><td>Regneark</td> <td>ods:26500     </td> <td>xlsx:82400</td></tr>
 163 </table>
 164
 165 <p>And with 'site:no':
 166
 167 <table>
 168 <tr><th>Type</th><th>ODF</th><th>MS Office</th></tr>
 169 <tr><td>Tekst</td> <td>odt:2480</td> <td>docx:3410</td></tr>
 170 <tr><td>Presentasjon</td> <td>odp:175</td> <td>pptx:604</td></tr>
 171 <tr><td>Regneark</td> <td>ods:186       </td> <td>xlsx:296</td></tr>
 172 </table>
 173
 174 <p>Interesting difference, not sure what to conclude from these
 175 numbers.</p>
 176 </div>
 177   <div class="tags">
 178
 179
 180
 181    Tags: <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>, <a href="tags/standard">standard</a>, <a href="tags/web">web</a>.
 182
 183   </div>
 184  </div>
 185  <div class="padding"></div>
 186
 187  <div class="entry">
 188   <div class="title"><a href="ISO_still_hope_to_fix_OOXML.html">ISO still hope to fix OOXML</a></div>
 189   <div class="date">2009-08-08 14:00</div>
 190   <div class="body">
 191 <p>According to <a
 192 href="http://twerner.blogspot.com/2009/08/defects-of-office-open-xml.html">a
 193 blog post from Torsten Werner</a>, the current defect report for ISO
 194 29500 (ISO OOXML) is 809 pages.  His interesting point is that the
 195 defect report is 71 pages more than the full ODF 1.1 specification.
 196 Personally I find it more interesting that ISO still believe ISO OOXML
 197 can be fixed in ISO.  Personally, I believe it is broken beyon repair,
 198 and I completely lack any trust in ISO for being able to get anywhere
 199 close to solving the problems.  I was part of the Norwegian committee
 200 involved in the OOXML fast track process, and was not impressed with
 201 Standard Norway and ISO in how they handled it.</p>
 202
 203 <p>These days I focus on ODF instead, which seem like a specification
 204 with the future ahead of it.  We are working in NUUG to organise a ODF
 205 seminar this autumn.</p>
 206 </div>
 207   <div class="tags">
 208
 209
 210
 211    Tags: <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>, <a href="tags/standard">standard</a>.
 212
 213   </div>
 214  </div>
 215  <div class="padding"></div>
 216
 217  <div class="entry">
 218   <div class="title"><a href="Debian_has_switched_to_dependency_based_boot_sequencing.html">Debian has switched to dependency based boot sequencing</a></div>
 219   <div class="date">2009-07-27 23:50</div>
 220   <div class="body">
 221 <p>Since this evening, with the upload of sysvinit version 2.87dsf-2,
 222 and the upload of insserv version 1.12.0-10 yesterday, Debian unstable
 223 have been migrated to using dependency based boot sequencing.  This
 224 conclude work me and others have been doing for the last three days.
 225 It feels great to see this finally part of the default Debian
 226 installation.  Now we just need to weed out the last few problems that
 227 are bound to show up, to get everything ready for Squeeze.</p>
 228
 229 <p>The next step is migrating /sbin/init from sysvinit to upstart, and
 230 fixing the more fundamental problem of handing the event based
 231 non-predictable kernel in the early boot.</p>
 232 </div>
 233   <div class="tags">
 234
 235
 236
 237    Tags: <a href="tags/debian">debian</a>, <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>.
 238
 239   </div>
 240  </div>
 241  <div class="padding"></div>
 242
 243  <div class="entry">
 244   <div class="title"><a href="Taking_over_sysvinit_development.html">Taking over sysvinit development</a></div>
 245   <div class="date">2009-07-22 23:00</div>
 246   <div class="body">
 247 <p>After several years of frustration with the lack of activity from
 248 the existing sysvinit upstream developer, I decided a few weeks ago to
 249 take over the package and become the new upstream.  The number of
 250 patches to track for the Debian package was becoming a burden, and the
 251 lack of synchronization between the distribution made it hard to keep
 252 the package up to date.</p>
 253
 254 <p>On the new sysvinit team is the SuSe maintainer Dr. Werner Fink,
 255 and my Debian co-maintainer Kel Modderman.  About 10 days ago, I made
 256 a new upstream tarball with version number 2.87dsf (for Debian, SuSe
 257 and Fedora), based on the patches currently in use in these
 258 distributions.  We Debian maintainers plan to move to this tarball as
 259 the new upstream as soon as we find time to do the merge.  Since the
 260 new tarball was created, we agreed with Werner at SuSe to make a new
 261 upstream project at <a href="http://savannah.nongnu.org/">Savannah</a>, and continue
 262 development there.  The project is registered and currently waiting
 263 for approval by the Savannah administrators, and as soon as it is
 264 approved, we will import the old versions from svn and continue
 265 working on the future release.</p>
 266
 267 <p>It is a bit ironic that this is done now, when some of the involved
 268 distributions are moving to upstart as a syvinit replacement.</p>
 269 </div>
 270   <div class="tags">
 271
 272
 273
 274    Tags: <a href="tags/debian">debian</a>, <a href="tags/english">english</a>, <a href="tags/nuug">nuug</a>.
 275
 276   </div>
 277  </div>
 278  <div class="padding"></div>
 279
 280  <div class="entry">
 281   <div class="title"><a href="Regjerningens_oppsummering_av_h__ringen_om_standardkatalogen_versjon_2.html">Regjerningens oppsummering av høringen om standardkatalogen versjon 2</a></div>
 282   <div class="date">2009-07-09 14:40</div>
 283   <div class="body">
 284 <p>For å forstå mer om hvorfor standardkatalogens versjon 2 ble som
 285 den ble, har jeg bedt om kopi fra FAD av dokumentene som ble lagt frem
 286 for regjeringen da de tok sin avgjørelse.  De er nå lagt ut på NUUGs
 287 wiki, direkte tilgjengelig via "<a
 288 href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&do=get&target=kongelig-resolusjon.pdf">Referansekatalogen
 289 v2.0 - Oppsummering av høring</a>" og "<a
 290 href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2?action=AttachFile&do=get&target=kongelig-resolusjon-katalogutkast.pdf">Referansekatalog
 291 for IT-standarder i offentlig sektor Versjon 2.0, dd.mm.åååå -
 292 UTKAST</a>".</p>
 293
 294 <p>Det er tre ting jeg merker meg i oppsummeringen fra
 295 høringsuttalelsen da jeg skummet igjennom den.  Det første er at
 296 forståelsen av hvordan programvarepatenter påvirker fri
 297 programvareutvikling også i Norge når en argumenterer med at
 298 royalty-betaling ikke er et relevant problem i Norge.  Det andre er at
 299 FAD ikke har en prinsipiell forståelse av verdien av en enkelt
 300 standard innenfor hvert område.  Det siste er at påstander i
 301 høringsuttalelsene ikke blir etterprøvd (f.eks. påstanden fra
 302 Microsoft om hvordan Ogg blir standardisert og påstanden fra
 303 politidirektoratet om patentproblemer i Theora).</p>
 304 </div>
 305   <div class="tags">
 306
 307
 308
 309    Tags: <a href="tags/multimedia">multimedia</a>, <a href="tags/norsk">norsk</a>, <a href="tags/nuug">nuug</a>, <a href="tags/standard">standard</a>, <a href="tags/video">video</a>.
 310
 311   </div>
 312  </div>
 313  <div class="padding"></div>
 314
 315  <div class="entry">
 316   <div class="title"><a href="Regjerningen_forlater_prinsippet_om_ingen_royalty_betaling_i_standardkatalogen_versjon_2.html">Regjerningen forlater prinsippet om ingen royalty-betaling i standardkatalogen versjon 2</a></div>
 317   <div class="date">2009-07-06 21:00</div>
 318   <div class="body">
 319 <p>Jeg ble glad da regjeringen
 320 <a href="http://www.digi.no/817635/her-er-statens-nye-it-standarder">annonserte</a>
 321 versjon 2 av
 322 <a href="http://www.regjeringen.no/upload/FAD/Vedlegg/IKT-politikk/Referansekatalogen_versjon2.pdf">statens
 323 referansekatalog over standarder</a>, men trist da jeg leste hva som
 324 faktisk var vedtatt etter
 325 <a href="http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html">høringen</a>.
 326 De fleste av de valgte åpne standardene er gode og vil bidra til at
 327 alle kan delta på like vilkår i å lage løsninger for staten, men
 328 noen av dem blokkerer for de som ikke har anledning til å benytte
 329 spesifikasjoner som krever betaling for bruk (såkalt
 330 royalty-betaling).  Det gjelder spesifikt for H.264 for video og MP3
 331 for lyd.  Så lenge bruk av disse var valgfritt mens Ogg Theora og Ogg
 332 Vorbis var påkrevd, kunne alle som ønsket å spille av video og lyd
 333 fra statens websider gjøre dette uten å måtte bruke programmer der
 334 betaling for bruk var nødvendig.  Når det nå er gjort valgfritt for
 335 de statlige etatene å bruke enten H.264 eller Theora (og MP3 eler
 336 Vorbis), så vil en bli tvunget til å forholde seg til
 337 royalty-belastede standarder for å få tilgang til videoen og
 338 lyden.</p>
 339
 340 <p>Det gjør meg veldig trist at regjeringen har forlatt prinsippet om
 341 at alle standarder som ble valgt til å være påkrevd i katalogen skulle
 342 være uten royalty-betaling.  Jeg håper det ikke betyr at en har mistet
 343 all forståelse for hvilke prinsipper som må følges for å oppnå
 344 likeverdig konkurranse mellom aktørene i IT-bransjen.  NUUG advarte
 345 mot dette i
 346 <a href="http://wiki.nuug.no/uttalelser/200901-standardkatalog-v2">sin
 347 høringsuttalelse</a>, men ser ut til å ha blitt ignorert.</p>
 348 </div>
 349   <div class="tags">
 350
 351
 352
 353    Tags: <a href="tags/multimedia">multimedia</a>, <a href="tags/norsk">norsk</a>, <a href="tags/nuug">nuug</a>, <a href="tags/standard">standard</a>, <a href="tags/video">video</a>.
 354
 355   </div>
 356  </div>
 357  <div class="padding"></div>
 358
 359  <div class="entry">
 360   <div class="title"><a href="Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html">Microsofts misvisende argumentasjon rundt multimediaformater</a></div>
 361   <div class="date">2009-06-26-13:30</div>
 362   <div class="body">
 363 <p>I
 364 <a href="http://www.regjeringen.no/upload/FAD/Vedlegg/Hoeringer/Refkat_V2/MicrosoftNorge.pdf">Microsoft
 365 sin høringsuttalelse</a> til
 366 <a href="http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html?id=549422">forslag
 367 til versjon 2 av statens referansekatalog over standarder</a>, lirer
 368 de av seg følgende FUD-perle:</p>
 369
 370 <p><blockquote>"Vorbis, OGG, Theora og FLAC er alle tekniske
 371   spesifikasjoner overordnet styrt av xiph.org, som er en
 372   ikke-kommersiell organisasjon.  Etablerte og anerkjente
 373   standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt
 374   innarbeidet vedlikeholds- og forvaltningsprosess av en standard.
 375   Det er derimot helt opp til hver enkelt organisasjon å bestemme
 376   hvordan tekniske spesifikasjoner videreutvikles og endres, og disse
 377   spesifikasjonene bør derfor ikke defineres som åpne
 378   standarder."</blockquote></p>
 379
 380 <p>De vokter seg vel for å nevne den anerkjente
 381 standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP,
 382 IP og det meste av protokoller på Internet, og RFC-standardene som
 383 IETF står bak.  Ogg er spesifisert i
 384 <a href="http://ietf.org/rfc/rfc3533.txt">RFC 3533</a>, og er uten
 385 tvil å anse som en åpen standard.  Vorbis er
 386 <a href="http://ietf.org/rfc/rfc5215.txt">RFC 5215</a>.  Theora er
 387
 388 under standardisering via IETF, med
 389 <a href="http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt">siste
 390 utkast publisert 2006-07-21</a> (riktignok er dermed teksten ikke
 391 skrevet i stein ennå, men det blir neppe endringer som ikke er
 392 bakoverkompatibel).  De kan være inne på noe når det gjelder FLAC da
 393 jeg ikke finner tegn til at <a
 394 href="http://flac.sourceforge.net/format.html">spesifikasjonen
 395 tilgjengelig på web</a> er på tur via noen
 396 standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora
 397 og Vorbis også har involvert seg i Flac siden 2003, så ser jeg ikke
 398 bort fra at også den organiseres via IETF.  Jeg kjenner personlig lite
 399 til FLAC.</p>
 400
 401 <p>Uredelig argumentasjon bør en holde seg for god til å komme med,
 402 spesielt når det er så enkelt i dagens Internet-hverdag å gå
 403 misvisende påstander etter i sømmene.</p>
 404 </div>
 405   <div class="tags">
 406
 407
 408
 409    Tags: <a href="tags/multimedia">multimedia</a>, <a href="tags/norsk">norsk</a>, <a href="tags/standard">standard</a>, <a href="tags/video">video</a>.
 410
 411   </div>
 412  </div>
 413  <div class="padding"></div>
 414
 415  <div class="entry">
 416   <div class="title"><a href="Debian_boots_quicker_and_quicker.html">Debian boots quicker and quicker</a></div>
 417   <div class="date">2009-06-24 21:40</div>
 418   <div class="body">
 419 <p>I spent Monday and tuesday this week in London with a lot of the
 420 people involved in the boot system on Debian and Ubuntu, to see if we
 421 could find more ways to speed up the boot system.  This was an Ubuntu
 422 funded
 423 <a href="https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint">developer
 424 gathering</a>. It was quite productive.  We also discussed the future
 425 of boot systems, and ways to handle the increasing number of boot
 426 issues introduced by the Linux kernel becoming more and more
 427 asynchronous and event base.  The Ubuntu approach using udev and
 428 upstart might be a good way forward.  Time will show.</p>
 429
 430 <p>Anyway, there are a few ways at the moment to speed up the boot
 431 process in Debian.  All of these should be applied to get a quick
 432 boot:</p>
 433
 434 <ul>
 435
 436 <li>Use dash as /bin/sh.</li>
 437
 438 <li>Disable the init.d/hwclock*.sh scripts and make sure the hardware
 439    clock is in UTC.</li>
 440
 441 <li>Install and activate the insserv package to enable
 442    <a href="http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot">dependency
 443    based boot sequencing</a>, and enable concurrent booting.</li>
 444
 445 </ul>
 446
 447 These points are based on the Google summer of code work done by
 448 <a href="http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/">Carlos
 449 Villegas</a>.
 450
 451 <p>Support for makefile-style concurrency during boot was uploaded to
 452 unstable yesterday.  When we tested it, we were able to cut 6 seconds
 453 from the boot sequence.  It depend on very correct dependency
 454 declaration in all init.d scripts, so I expect us to find edge cases
 455 where the dependences in some scripts are slightly wrong when we start
 456 using this.</p>
 457
 458 <p>On our IRC channel for this effort, #pkg-sysvinit, a new idea was
 459 introduced by Raphael Geissert today, one that could affect the
 460 startup speed as well.  Instead of starting some scripts concurrently
 461 from rcS.d/ and another set of scripts from rc2.d/, it would be
 462 possible to run a of them in the same process.  A quick way to test
 463 this would be to enable insserv and run 'mv /etc/rc2.d/S* /etc/rcS.d/;
 464 insserv'.  Will need to test if that work. :)</p>
 465 </div>
 466   <div class="tags">
 467
 468
 469
 470    Tags: <a href="tags/debian">debian</a>, <a href="tags/english">english</a>.
 471
 472   </div>
 473  </div>
 474  <div class="padding"></div>
 475
 476  <p style="text-align: right;"><a href="index.rss"><img src="xml.gif" alt="RSS feed" width="36" height="14"></a></p>
 477
 478 <div id="sidebar">
 479
 480
 481
 482
 483
 484 <h2>Archive</h2>
 485 <ul>
 486
 487 <li>2009
 488 <ul>
 489
 490 <li><a href="archive/2009/01/">January (8)</a></li>
 491
 492 <li><a href="archive/2009/02/">February (8)</a></li>
 493
 494 <li><a href="archive/2009/03/">March (12)</a></li>
 495
 496 <li><a href="archive/2009/04/">April (10)</a></li>
 497
 498 <li><a href="archive/2009/05/">May (9)</a></li>
 499
 500 <li><a href="archive/2009/06/">June (3)</a></li>
 501
 502 <li><a href="archive/2009/07/">July (4)</a></li>
 503
 504 <li><a href="archive/2009/08/">August (3)</a></li>
 505
 506 <li><a href="archive/2009/09/">September (1)</a></li>
 507
 508 </ul></li>
 509
 510 <li>2008
 511 <ul>
 512
 513 <li><a href="archive/2008/11/">November (5)</a></li>
 514
 515 <li><a href="archive/2008/12/">December (7)</a></li>
 516
 517 </ul></li>
 518
 519 </ul>
 520
 521
 522
 523 <h2>Tags</h2>
 524 <ul>
 525
 526  <li><a href="tags/3d-printer">3d-printer (11)</a></li>
 527
 528  <li><a href="tags/amiga">amiga (1)</a></li>
 529
 530  <li><a href="tags/aros">aros (1)</a></li>
 531
 532  <li><a href="tags/debian">debian (14)</a></li>
 533
 534  <li><a href="tags/debian edu">debian edu (7)</a></li>
 535
 536  <li><a href="tags/english">english (17)</a></li>
 537
 538  <li><a href="tags/fiksgatami">fiksgatami (1)</a></li>
 539
 540  <li><a href="tags/fildeling">fildeling (3)</a></li>
 541
 542  <li><a href="tags/lenker">lenker (1)</a></li>
 543
 544  <li><a href="tags/ltsp">ltsp (1)</a></li>
 545
 546  <li><a href="tags/multimedia">multimedia (5)</a></li>
 547
 548  <li><a href="tags/norsk">norsk (53)</a></li>
 549
 550  <li><a href="tags/nuug">nuug (55)</a></li>
 551
 552  <li><a href="tags/opphavsrett">opphavsrett (7)</a></li>
 553
 554  <li><a href="tags/personvern">personvern (8)</a></li>
 555
 556  <li><a href="tags/reprap">reprap (10)</a></li>
 557
 558  <li><a href="tags/rss">rss (1)</a></li>
 559
 560  <li><a href="tags/sikkerhet">sikkerhet (3)</a></li>
 561
 562  <li><a href="tags/standard">standard (9)</a></li>
 563
 564  <li><a href="tags/stavekontroll">stavekontroll (1)</a></li>
 565
 566  <li><a href="tags/video">video (9)</a></li>
 567
 568  <li><a href="tags/vitenskap">vitenskap (1)</a></li>
 569
 570  <li><a href="tags/web">web (5)</a></li>
 571
 572 </ul>
 573
 574 </div>
 575
 576 <p style="text-align: right">
 577 Created by <a href="http://steve.org.uk/Software/chronicle">Chronicle v3.2</a>
 578 </p>
 579 </body>
 580 </html>