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">
4 <title>Petter Reinholdtsen
</title>
5 <description></description>
7 <atom:link href=
"index.rss" rel=
"self" type=
"application/rss+xml" />
10 <title>Kartverket
"frigjør
" data men er fortsatt ikke interessante
</title>
11 <link>Kartverket__frigj__r__data_men_er_fortsatt_ikke_interessante.html
</link>
12 <guid isPermaLink=
"true">Kartverket__frigj__r__data_men_er_fortsatt_ikke_interessante.html
</guid>
13 <pubDate>Thu,
12 Nov
2009 10:
10:
00 +
0100</pubDate>
16 <a href=
"http://www.statkart.no/Gratis+karttjenester.d25-SwJfY1-.ips
">kartnyhet
</a
>
17 er at kartverket gir ikke-kommersiell tilgang til
18 en WMS-tjeneste der en til privat bruk kan hente ut bilder av
19 kartutsnitt så lenge disse ikke lagres lokalt, brukes i begrenset
20 oppløsning og ikke skader kartverket og rettighetshavernes omdømme og
23 <p
>I går publiserte Ivan Sanchez
24 <a href=
"http://www.opengeodata.org/
2009/
11/
11/
921/
">kaketesten
</a
>
25 som et forslag til en (av forhåpentligvis flere) måter å teste om kart
26 eller kartdata er fritt tilgjengelige på. Testen er enkel, og sier
27 enkelt (oversatt av meg): Et sett med geodata, eller en kart, er kun
28 fritt tilgjengelig hvis none kan gi deg en kake med det karte på
29 toppen, som en gave. Kartverkets publisering av kart feiler så vidt
30 jeg kan se denne testen fullstendig. En kan slik jeg leser vilkårene
31 ikke be en konditor om å lage en kake (brudd på kravet om
32 ikke-kommersiell bruk) med kartverkets kart.
</p
>
34 <p
>De som vil lage karttjenester basert på denne nye tjenesten fra
35 kartverket vil gjøre det på kartverkets nåde og med sterke bindinger
36 og begresninger. Det blir dermed helt uinteressant for meg. Jeg vil
37 nok fortsette å bruke data fra
38 <a href=
"http://www.openstreetmap.org
">OpenStreetmap.org
</a
>, der jeg
39 har kontrollen med tilgang til kartdataene, og kan endre på de
40 underliggende dataene som jeg ønsker.
</p
>
42 <p
>Som et eksempel, så trenger vi til en norsk
43 <a href=
"http://www.fixmystreet.com/
">FixMyStreet-installasjon
</a
>
44 tilgang til vektorutgaven av kommunegrensene. Denne nye karttjenesten
45 er ubrukelig til dette.
</p
>
50 <title>Internet-leverandører er ikke vokterne av sine kunders nettbruk
</title>
51 <link>Internet_leverand__rer_er_ikke_vokterne_av_sine_kunders_nettbruk.html
</link>
52 <guid isPermaLink=
"true">Internet_leverand__rer_er_ikke_vokterne_av_sine_kunders_nettbruk.html
</guid>
53 <pubDate>Fri,
6 Nov
2009 18:
45:
00 +
0100</pubDate>
55 <p
>Det er svært gledelig å se at
56 <a href=
"http://www.aftenposten.no/nyheter/iriks/article3360796.ece
">retten
57 fant at Telenor ikke skal fungere som Internet-voktere
</a
> på vegne av
58 opphavsrettsmafiaen. TONO påstår ikke overraskende
"rettighetshaverne
59 er rettsløse
". De burde jo vite alt om hvordan rettighetshaverne blir
61 <a href=
"http://www.ballade.no/nmi.nsf/doc/art2009042008430427192492
">nektet
62 å hjelpe et av sine medlemmer i en plagiatsak
</a
> mot Universal i
65 <p
>Ved opphavsrettsbrudd så er det jo den som offentliggjort
66 kulturuttrykk ulovlig som må stilles til ansvar, og ikke noen andre.
67 Hverken Telenor eller Pirate Bay publiserer innholdet. Telenor lager
68 en Internet-tjeneste som brukes av borgerne til sitt daglige virke,
69 det være seg å holde kontakt med barnebarn, skaffe medisinsk viten
70 eller holde seg orientert i samfunnsdebatten. Det bør de gjøre uten å
71 tvinges til å være overvåkningsinstans. Og Pirate Bay lager en
72 katalog over hvor lovlig og ulovlig innhold på Internet er å få tak i.
73 De publiserer ikke innholdet, de lager kun en katalog over det. Hvis
74 en ikke liker det som blir publisert, så må det tas opp med den som
75 publiserer, ikke noen andre.
</p
>
77 <p
>Personlig velger jeg å stort sett bruke kulturuttrykk som
78 publiseres med mer brukervennlige vilkår, som CC-BY og lignende.
</p
>
83 <title>Endelig operativt webbasert medlemsregister for Fri programvare i skolen
</title>
84 <link>Endelig_operativt_webbasert_medlemsregister_for_Fri_programvare_i_skolen.html
</link>
85 <guid isPermaLink=
"true">Endelig_operativt_webbasert_medlemsregister_for_Fri_programvare_i_skolen.html
</guid>
86 <pubDate>Mon,
2 Nov
2009 22:
40:
00 +
0100</pubDate>
88 <p
>Under helgens utviklersamling i
89 <a href=
"http://www.skolelinux.no/
">Skolelinux
</a
> fikk jeg endelig
90 satt meg ned sammen med Ronny Aasen i styret for å få et webbasert
91 medlemsregister tilbake på plass for foreningen som passer på
92 skolelinuxprosjektet. Etter flere års knot og problemer, er nå
93 memberdb satt opp og klart til bruk. Import av det gamle
94 medlemsregisteret har vist seg vanskelig, så alle medlemmer bes om å
95 registrere seg på nytt. Hvis du støtter FRiSKs formål så er du
96 hjertelig velkommen til
97 <a href=
"http://medlem.friprogramvareiskolen.no/
">å melde deg
98 inn
</a
>. Formålet lyder:
</p
>
100 <blockquote
>Linux i skolen skal tilrettelegge for og informere om bruk
101 av fri programvare, i henhold til Debian Free Software Guidelines av
102 2002-
02-
03, i den norske skolen, slik som f.eks. Linux og
103 GNU.
</blockquote
>
108 <title>Jeg vil ikke ha BankID
</title>
109 <link>Jeg_vil_ikke_ha_BankID.html
</link>
110 <guid isPermaLink=
"true">Jeg_vil_ikke_ha_BankID.html
</guid>
111 <pubDate>Fri,
30 Oct
2009 13:
05:
00 +
0100</pubDate>
113 <p
>Min hovedbankforbindelse,
114 <a href=
"http://www.postbanken.no/
">Postbanken
</a
>, har fra
1. oktober
115 blokkert tilgangen min til nettbanken hvis jeg ikke godtar vilkårene
116 for
<a href=
"https://www.bankid.no/
">BankID
</a
> og går over til å
117 bruke BankID for tilgangskontroll. Tidligere kunne jeg bruke en
118 kodekalkulator som ga tilgang til nettbanken, men nå er dette ikke
119 lenger mulig. Jeg blokkeres ute fra nettbanken og mine egne penger
120 hvis jeg ikke godtar det jeg anser som urimelige vilkår i
121 BankID-avtalen.
</p
>
123 <p
>BankID er en løsning der banken gis rett til å handle på vegne av
124 meg, med avtalemessig forutsetning at jeg i hvert enkelt tilfelle har
125 bedt banken gjøre dette. BankID kan brukes til å signere avtaler,
126 oppta lån og andre handlinger som har alvorlige følger for meg.
127 Problemet slik jeg ser det er at BankID er lagt opp slik at banken har
128 all informasjon og tilgang som den trenger for å bruke BankID, også
129 uten at jeg er involvert. Avtalemessing og juridisk skal de kun bruke
130 min BankID når jeg har oppgitt pinkode og passord, men praktisk og
131 konkret kan de gjøre dette også uten at min pinkode eller mitt passord
132 er oppgitt, da de allerede har min pinkode og passord tilgjengelig hos
133 seg for å kunne sjekke at riktig pinkode og passord er oppgitt av meg
134 (eller kan skaffe seg det ved behov). Jeg ønsker ikke å gi banken
135 rett til å inngå avtaler på vegne av meg.
</p
>
137 <p
>Rent teknisk er BankID et offentlig nøkkelpar, en privat og en
138 offentlig nøkkel, der den private nøkkelen er nødvendig for å
139 "signere
" på vegne av den nøkkelen gjelder for, og den offentlige
140 nøkkelen er nødvendig for å sjekke hvem som har signert. Banken
141 sitter på både den private og den offentlige nøkkelen, og sier de kun
142 skal bruke den private hvis kunden ber dem om det og oppgir pinkode og
146 <p
>I postbankens
147 <a href=
"https://www.postbanken.no//portalfront/nedlast/no/person/avtaler/BankID_avtale.pdf
">vilkår
148 for BankID
</a
> står følgende:
</p
>
151 <p
>"6. Anvendelsesområdet for BankID
</p
>
153 <p
>PersonBankID kan benyttes fra en datamaskin, eller etter nærmere
154 avtale fra en mobiltelefon/SIM-kort, for pålogging i nettbank og til
155 identifisering og signering i forbindelse med elektronisk
156 meldingsforsendelse, avtaleinngåelse og annen form for nettbasert
157 elektronisk kommunikasjon med Banken og andre brukersteder som har
158 tilrettelagt for bruk av BankID. Dette forutsetter at brukerstedet
159 har inngått avtale med bank om bruk av BankID.
"</p
>
162 <p
>Det er spesielt retten til
"avtaleinngåelse
" jeg synes er urimelig
163 å kreve for at jeg skal få tilgang til mine penger via nettbanken, men
164 også retten til å kommunsere på vegne av meg med andre brukersteder og
165 signering av meldigner synes jeg er problematisk. Jeg må godta at
166 banken skal kunne signere for meg på avtaler og annen kommunikasjon
167 for å få BankID.
</p
>
169 <p
>På spørsmål om hvordan jeg kan få tilgang til nettbank uten å gi
170 banken rett til å inngå avtaler på vegne av meg svarer Postbankens
171 kundestøtte at
"Postbanken har valgt BankID for bl.a. pålogging i
172 nettbank , så her må du nok ha hele denne løsningen
". Jeg nektes
173 altså tilgang til nettbanken inntil jeg godtar at Postbanken kan
174 signere avtaler på vegne av meg.
</p
>
176 <p
>Postbankens kundestøtte sier videre at
"Det har blitt et krav til
177 alle norske banker om å innføre BankID, bl.a på grunn av
178 sikkerhet
", uten at jeg her helt sikker på hvem som har framsatt
179 dette kravet. [Oppdatering: Postbankens kundestøtte sier kravet er
180 fastsatt av
<a href=
"http://www.kredittilsynet.no/
">kreditttilsynet
</a
>
181 og
<a href=
"http://www.bbs.no/
">BBS
</a
>.] Det som er situasjonen er
182 dog at det er svært få banker igjen som ikke bruker BankID, og jeg
183 vet ikke hvilken bank som er et godt alternativ for meg som ikke vil
184 gi banken rett til å signere avtaler på mine vegne.
</p
>
186 <p
>Jeg ønsker mulighet til å reservere meg mot at min BankID brukes
187 til annet enn å identifisere meg overfor nettbanken før jeg vil ta i
188 bruk BankID. Ved nettbankbruk er det begrenset hvor store skader som
189 kan oppstå ved misbruk, mens avtaleinngåelse ikke har tilsvarende
190 begrensing.
</p
>
192 <p
>Jeg har klaget vilkårene inn for
<a
193 href=
"http://www.forbrukerombudet.no/
">forbrukerombudet
</a
>, men
194 regner ikke med at de vil kunne bidra til en rask løsning som gir meg
195 nettbankkontroll over egne midler. :(
200 <title>Internet-sensur skal i retten på mandag
</title>
201 <link>Internet_sensur_skal_i_retten_p___mandag.html
</link>
202 <guid isPermaLink=
"true">Internet_sensur_skal_i_retten_p___mandag.html
</guid>
203 <pubDate>Sat,
10 Oct
2009 22:
00:
00 +
0200</pubDate>
205 <p
><a href=
"http://www.dagensit.no/bransje/article1757755.ece
">DagensIT
</a
>
206 melder at Telenor og Tono skal i retten på mandag for å diskutere
207 hvorvidt Tonos krav om at Telenor skal blokkere for tilgang til The
208 Pirate Bay er i tråd med norsk rett. Det blir interessant å se
209 resultatet fra den rettsaken.
</p
>
211 <p
>Jeg bet meg dog merke i en av påstandene fra Tonos advokat Cato
212 Strøm, som forteller at
"Pirate Bay inneholder
95 prosent ulovlig
213 utlagt materiale, og å stanse tilgangen til det kan ikke kalles
214 sensur
". Jeg tok en titt på
215 <a href=
"http://thepiratebay.org/
">forsiden til The Pirate Bay
</a
>,
216 som forteller at det pr. i dag er
1 884 694 torrenter på trackeren.
217 Dette tilsvarer antall filer en kan søke blant og hente ned ved hjelp
218 av The Pirate Bay.
5% av dette antallet er
94 235. Det kan dermed
219 virke som om Tonos advokat mener at det ikke er sensur å blokkere for
220 tilgang til nesten
100 000 lovlige filer. Jeg lurer på om han er
221 korrekt sitert.
</p
>
223 <p
>Lurer også på hvor
95%-tallet kommer fram. Er det seriøs og
224 etterprøvbar forskning på området som viser at dette er andelen
225 ulovlige filer tilgjengelig via The Pirate Bay, eller er det
226 musikkbransjenes egne tall? De har
227 <a href=
"http://www.guardian.co.uk/music/
2009/oct/
06/edwyn-collins-sharing-music
">jo
228 demonstrert
</a
> at de ikke er i stand til å skille lovlig og ulovlig
229 bruk av musikk.
</p
>
234 <title>MVA på bøker med DRM, ikke MVA på bøker uten DRM?
</title>
235 <link>MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html
</link>
236 <guid isPermaLink=
"true">MVA_p___b__ker_med_DRM__ikke_MVA_p___b__ker_uten_DRM_.html
</guid>
237 <pubDate>Wed,
23 Sep
2009 10:
00:
00 +
0200</pubDate>
239 <p
>Elektroniske bøker diskuteres for tiden, etter at
240 <a href=
"http://www.aftenposten.no/kul_und/litteratur/article3280914.ece
">bokbransjen
241 hevder
</a
> det er usikkert om de kommer til å gi ut elektroniske
242 bøker så lenge det er merverdiavgift på elektroniske bøker og ikke
243 på papirbøker. I den forbindelse så jeg et interessant forslag i
245 <a href=
"http://www.digi.no/php/ny_debatt.php?id=
823912">digi-debatt
</a
>
246 jeg hadde sans for.
"einarr
" foreslo at DRM-infiserte elektroniske
247 bøker bør ha merverdiavgift, da
"de ikke bidrar til
248 kunnskapsspredning på samme måte
" som papirbøker og dermed går
249 imot intensjonene bak mva-fritaket. Bøker uten DRM derimot bør ha
250 mva-fritak da de
"kan overføres mellom enheter, leses på ulike
251 plattformer, lånes ut og siteres og kopieres fra
" slik en kan med
252 papirbøker.
</p
>
254 <p
>En oppfølgerkommentar sier seg enig i dette, da DRM-infisert
255 materiale må anses som leid og dermed en tjeneste, mens materiale uten
256 DRM må anses som et kjøp.
</p
>
261 <title>Sikkerhet til sjøs trenger sjøkart uten bruksbegresninger
</title>
262 <link>Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
</link>
263 <guid isPermaLink=
"true">Sikkerhet_til_sj__s_trenger_sj__kart_uten_bruksbegresninger.html
</guid>
264 <pubDate>Sun,
23 Aug
2009 10:
00:
00 +
0200</pubDate>
266 <p
>Sikkerhet til sjøs burde være noe som opptar mange etter den siste
267 oljeutslippsulykken med Full City, som har drept mye liv langs sjøen.
268 En viktig faktor for å bedre sikkerheten til sjøs er at alle som
269 ferdes på sjøen har tilgang til oppdaterte sjøkart som forteller hvor
270 det grunner og annet en må ta hensyn til på sjøen.
</p
>
272 <p
>Hvis en er enig i at tilgang til oppdaterte sjøkart er viktig for
273 sikkerheten på sjøen, så er det godt å vite at det i dag er teknisk
274 mulig å sikre alle enkel tilgang til oppdaterte digitale kart over
275 Internet. Det trenger heller ikke være spesielt kostbart.
</p
>
277 <p
>Både ved Rocknes-ulykken i Vatlestraumen, der
18 mennesker mistet
278 livet, og ved Full City-ulykken utenfor Langesund, der mange tonn olje
279 lekket ut i havet, var det registrert problemer relatert til
280 oppdaterte sjøkart. Ved Rocknes-ulykken var de elektroniske kartene
281 som ble brukt ikke oppdatert med informasjon om nyoppdagede grunner og
282 losen kjente visst ikke til disse nye grunnene. Papirkartene var dog
283 oppdaterte. Ved Full City-ulykken hadde en kontroll av skipet noen
284 uker tidligere konstatert manglende sjøkart.
</p
>
286 <p
>Jeg tror en løsning der digitale sjøkart kunne lastes ned direkte
287 fra sjøkartverket av alle som ønsket oppdaterte sjøkart, uten
288 brukerbetaling og uten bruksbegresninger knyttet til kartene, vil
289 gjøre at flere folk på sjøen vil holde seg med oppdaterte sjøkart,
290 eller sjøkart i det hele tatt. Resultatet av dette vil være økt
291 sikkerhet på sjøen. En undersøkelse gjennomført av Opinion for
292 Gjensidige i
2008 fortalte at halvparten av alle båteierne i landet
293 ikke har sjøkart i båten.
</p
>
295 <p
>Formatet på de digitale sjøkartene som gjøræs tilgjengelig fra
296 sjøkartverket må være i henhold til en fri og åpen standard, slik at
297 en ikke er låst til enkeltaktørers godvilje når datafilene skal tolkes
298 og forstås, men trenger ikke publiseres fra sjøkartverket i alle
299 formatene til verdens skips-GPS-er i tillegg. Hvis det ikke er
300 kostbart for sjøkartverket bør de gjerne gjøre det selv, men slik
301 konvertering kan andre ta seg av hvis det er et marked for det.
</p
>
303 <p
>Hvis staten mener alvor med å forbedre sikkerheten til sjøs, må de
304 gjøre sitt for at alle båteiere har oppdaterte kart, ikke bare snakke
305 om hvor viktig det er at de har oppdaterte kart. Det bør være
306 viktigere for staten at båtene
<strong
>har
</strong
> oppdaterte kart
307 enn at de er pålagt å ha oppdaterte kart.
</p
>
309 <p
>Sjøkartene er
<a href=
"http://kart.kystverket.no/
">tilgjengelig på web
310 fra kystverket
</a
>, men så vidt jeg har klart å finne, uten
311 bruksvilkår som muliggjør gjenbruk uten bruksbegresninger.
</p
>
313 <p
>OpenStreetmap.org-folk er lei av mangel på sjøkart, og har startet
314 på et dugnadsbasert fribrukskart for havet,
315 <a href=
"http://openseamap.org/
">OpenSeaMap
</a
>. Datagrunnlaget er
316 OpenStreetmap, mens framvisningen er tilpasset bruk på sjøen. Det
317 gjenstår mye før en kan bruke dette til å seile sikkert på havet, men
318 det viser at behovet for fribruks-sjøkart er til stedet.
</p
>
323 <title>Relative popularity of document formats (MS Office vs. ODF)
</title>
324 <link>Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html
</link>
325 <guid isPermaLink=
"true">Relative_popularity_of_document_formats__MS_Office_vs__ODF_.html
</guid>
326 <pubDate>Wed,
12 Aug
2009 15:
50:
00 +
0200</pubDate>
328 <p
>Just for fun, I did a search right now on Google for a few file ODF
329 and MS Office based formats (not to be mistaken for ISO or ECMA
330 OOXML), to get an idea of their relative usage. I searched using
331 'filetype:odt
' and equvalent terms, and got these results:
</P
>
334 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
335 <tr
><td
>Tekst
</td
> <td
>odt:
282000</td
> <td
>docx:
308000</td
></tr
>
336 <tr
><td
>Presentasjon
</td
> <td
>odp:
75600</td
> <td
>pptx:
183000</td
></tr
>
337 <tr
><td
>Regneark
</td
> <td
>ods:
26500 </td
> <td
>xlsx:
145000</td
></tr
>
340 <p
>Next, I added a
'site:no
' limit to get the numbers for Norway, and
341 got these numbers:
</p
>
344 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
345 <tr
><td
>Tekst
</td
> <td
>odt:
2480 </td
> <td
>docx:
4460</td
></tr
>
346 <tr
><td
>Presentasjon
</td
> <td
>odp:
299 </td
> <td
>pptx:
741</td
></tr
>
347 <tr
><td
>Regneark
</td
> <td
>ods:
187 </td
> <td
>xlsx:
372</td
></tr
>
350 <p
>I wonder how these numbers change over time.
</p
>
352 <p
>I am aware of Google returning different results and numbers based
353 on where the search is done, so I guess these numbers will differ if
354 they are conduced in another country. Because of this, I did the same
355 search from a machine in California, USA, a few minutes after the
356 search done from a machine here in Norway.
</p
>
360 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
361 <tr
><td
>Tekst
</td
> <td
>odt:
129000</td
> <td
>docx:
308000</td
></tr
>
362 <tr
><td
>Presentasjon
</td
> <td
>odp:
44200</td
> <td
>pptx:
93900</td
></tr
>
363 <tr
><td
>Regneark
</td
> <td
>ods:
26500 </td
> <td
>xlsx:
82400</td
></tr
>
366 <p
>And with
'site:no
':
369 <tr
><th
>Type
</th
><th
>ODF
</th
><th
>MS Office
</th
></tr
>
370 <tr
><td
>Tekst
</td
> <td
>odt:
2480</td
> <td
>docx:
3410</td
></tr
>
371 <tr
><td
>Presentasjon
</td
> <td
>odp:
175</td
> <td
>pptx:
604</td
></tr
>
372 <tr
><td
>Regneark
</td
> <td
>ods:
186 </td
> <td
>xlsx:
296</td
></tr
>
375 <p
>Interesting difference, not sure what to conclude from these
381 <title>ISO still hope to fix OOXML
</title>
382 <link>ISO_still_hope_to_fix_OOXML.html
</link>
383 <guid isPermaLink=
"true">ISO_still_hope_to_fix_OOXML.html
</guid>
384 <pubDate>Sat,
8 Aug
2009 14:
00:
00 +
0200</pubDate>
386 <p
>According to
<a
387 href=
"http://twerner.blogspot.com/
2009/
08/defects-of-office-open-xml.html
">a
388 blog post from Torsten Werner
</a
>, the current defect report for ISO
389 29500 (ISO OOXML) is
809 pages. His interesting point is that the
390 defect report is
71 pages more than the full ODF
1.1 specification.
391 Personally I find it more interesting that ISO still believe ISO OOXML
392 can be fixed in ISO. Personally, I believe it is broken beyon repair,
393 and I completely lack any trust in ISO for being able to get anywhere
394 close to solving the problems. I was part of the Norwegian committee
395 involved in the OOXML fast track process, and was not impressed with
396 Standard Norway and ISO in how they handled it.
</p
>
398 <p
>These days I focus on ODF instead, which seem like a specification
399 with the future ahead of it. We are working in NUUG to organise a ODF
400 seminar this autumn.
</p
>
405 <title>Debian has switched to dependency based boot sequencing
</title>
406 <link>Debian_has_switched_to_dependency_based_boot_sequencing.html
</link>
407 <guid isPermaLink=
"true">Debian_has_switched_to_dependency_based_boot_sequencing.html
</guid>
408 <pubDate>Mon,
27 Jul
2009 23:
50:
00 +
0200</pubDate>
410 <p
>Since this evening, with the upload of sysvinit version
2.87dsf-
2,
411 and the upload of insserv version
1.12.0-
10 yesterday, Debian unstable
412 have been migrated to using dependency based boot sequencing. This
413 conclude work me and others have been doing for the last three days.
414 It feels great to see this finally part of the default Debian
415 installation. Now we just need to weed out the last few problems that
416 are bound to show up, to get everything ready for Squeeze.
</p
>
418 <p
>The next step is migrating /sbin/init from sysvinit to upstart, and
419 fixing the more fundamental problem of handing the event based
420 non-predictable kernel in the early boot.
</p
>