- <title>Voteringsdata fra stortinget på plass, mye igjen</title>
- <link>http://people.skolelinux.org/pere/blog/Voteringsdata_fra_stortinget_p___plass__mye_igjen.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Voteringsdata_fra_stortinget_p___plass__mye_igjen.html</guid>
- <pubDate>Thu, 21 Jul 2011 12:10:00 +0200</pubDate>
- <description>
-<p>Arbeidet med et nettsted som viser frem hva hver enkelt av våre
-folkevalgte har stemt går sakte fremover. Det har gått to måneder
-siden
-<a href="http://people.skolelinux.org/pere/blog/Hvem_stemte_hva_p___Stortinget_.html">jeg
-skrev om prosjektet</a>. Siden sist har vi fått kontakt med
-organisasjonen <a href="http://www.holderdeord.no">Holder De Ord</a>
-som holder på med et lignende prosjekt, samt fått tilgang til endel
-voteringsinformasjon fra Stortinget.</p>
-
-<p>Har fått tilgang til to datasett fra Stortinget. Det ene er en CD
-med voteringsdetaljer mellom 1990 og 2009, det andre er tilgang til
-stortingets kommende data-API der en kan hente ut informasjon om
-representanter, saker og voteringer. Jeg har ikke rukket se nok på
-noen av dem til å laste dem inn i min prototype, men jeg håper begge
-datasettene kan brukes.</p>
-
-<p>Det første datasettet er kopiert og publisert
-<a href="http://www.nuug.no/pub/stortingsinnsyn/">på NUUGs
-filtjener</a>, og består av to filer pr. votering. En fil med
-tidspunkt og hver enkelt stemme, og en annen med hvem som stemte og
-hvilket parti og fylke de representerte. Tegnsettet er så vidt jeg
-kan se Codepage 865, og jeg håper det er enkelt å koble sammen person
-og stemme. Har ikke rukket forsøke dette ennå. Jeg tror en god
-strategi her er å parse råfilene fra Stortinget og sammenstille dem
-med databasen over representanter, og ved hjelp av denne koble de
-unike ID-ene til representantene med hver enkelt stemme og publisere
-resultatet i XML-format. Antar det er en par dagers programmering,
-men har ikke funnet tid til det.</p>
-
-<p>Hvis du vil bidra, ta kontakt med meg på IRC (#nuug på
-irc.freenode.net) eller bli med på epostlisten
-<a href="http://lists.nuug.no/mailman/listinfo/aktive">aktive@nuug</a>.
-Det trengs både manne-timer for skraping og finansiering av
-utviklingstimer for å en norsk portal på plass.</p>
+ <title>What should start from /etc/rcS.d/ in Debian? - almost nothing</title>
+ <link>http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html</guid>
+ <pubDate>Sat, 30 Jul 2011 14:00:00 +0200</pubDate>
+ <description><p>In the Debian boot system, several packages include scripts that
+are started from /etc/rcS.d/. In fact, there is a bite more of them
+than make sense, and this causes a few problems. What kind of
+problems, you might ask. There are at least two problems. The first
+is that it is not possible to recover a machine after switching to
+runlevel 1. One need to actually reboot to get the machine back to
+the expected state. The other is that single user boot will sometimes
+run into problems because some of the subsystems are activated before
+the root login is presented, causing problems when trying to recover a
+machine from a problem in that subsystem. A minor additional point is
+that moving more scripts out of rcS.d/ and into the other rc#.d/
+directories will increase the amount of scripts that can run in
+parallel during boot, and thus decrease the boot time.</p>
+
+<p>So, which scripts should start from rcS.d/. In short, only the
+scripts that _have_ to execute before the root login prompt is
+presented during a single user boot should go there. Everything else
+should go into the numeric runlevels. This means things like
+lm-sensors, fuse and x11-common should not run from rcS.d, but from
+the numeric runlevels. Today in Debian, there are around 115 init.d
+scripts that are started from rcS.d/, and most of them should be moved
+out. Do your package have one of them? Please help us make single
+user and runlevel 1 better by moving it.</p>
+
+<p>Scripts setting up the screen, keyboard, system partitions
+etc. should still be started from rcS.d/, but there is for example no
+need to have the network enabled before the single user login prompt
+is presented.</p>
+
+<p>As always, things are not so easy to fix as they sound. To keep
+Debian systems working while scripts migrate and during upgrades, the
+scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency
+order, ie the scripts that nothing in rcS.d/ depend on can be moved,
+and the next ones can only be moved when their dependencies have been
+moved first. This migration must be done sequentially while we ensure
+that the package system upgrade packages in the right order to keep
+the system state correct. This will require some coordination when it
+comes to network related packages, but most of the packages with
+scripts that should migrate do not have anything in rcS.d/ depending
+on them. Some packages have already been updated, like the sudo
+package, while others are still left to do. I wish I had time to work
+on this myself, but real live constrains make it unlikely that I will
+find time to push this forward.</p>