-<p>The last few days I have spent some time trying to add support for
-the <a href="http://www.open311.org/">Open311 API</a> in the
-<a href="http://www.fiksgatami.no/">Norwegian FixMyStreet service</a>.
-Earlier I believed Open311 would be a useful API to use to submit
-reports to the municipalities, but when I noticed that the
-<a href="http://fixmystreet.org.nz/">New Zealand version</a> of
-FixMyStreet had implemented Open311 on the server side, it occurred to
-me that this was a nice way to allow the public, press and
-municipalities to do data mining directly in the FixMyStreet service.
-Thus I went to work implementing the Open311 specification for
-FixMyStreet. The implementation is not yet ready, but I am starting
-to get a draft limping along. In the process, I have discovered a few
-issues with the Open311 specification.</p>
-
-<p>One obvious missing feature is the lack of natural language
-handling in the specification. The specification seem to assume all
-reports will be written in English, and do not provide a way for the
-receiving end to specify which languages are understood there. To be
-able to use the same client and submit to several Open311 receivers,
-it would be useful to know which language to use when writing reports.
-I believe the specification should be extended to allow the receivers
-of problem reports to specify which language they accept, and the
-submitter to specify which language the report is written in.
-Language of a text can also be automatically guessed using statistical
-methods, but for multi-lingual persons like myself, it is useful to
-know which language to use when writing a problem report. I suspect
-some lang=nb,nn kind of attribute would solve it.</p>
-
-<p>A key part of the Open311 API is the list of services provided,
-which is similar to the categories used by FixMyStreet. One issue I
-run into is the need to specify both name and unique identifier for
-each category. The specification do not state that the identifier
-should be numeric, but all example implementations have used numbers
-here. In FixMyStreet, there is no number associated with each
-category. As the specification do not forbid it, I will use the name
-as the unique identifier for now and see how open311 clients handle
-it.</p>
-
-<p>The report format in open311 and the report format in FixMyStreet
-differ in a key part. FixMyStreet have a title and a description,
-while Open311 only have a description and lack the title. I'm not
-quite sure how to best handle this yet. When asking for a FixMyStreet
-report in Open311 format, I just merge title an description into the
-open311 description, but this is not going to work if the open311 API
-should be used for submitting new reports to FixMyStreet.</p>
-
-<p>The search feature in Open311 is missing a way to ask for problems
-near a geographic location. I believe this is important if one is to
-use Open311 as the query language for mobile units. The specification
-should be extended to handle this, probably using some new lat=, lon=
-and range= options.</p>
-
-<p>The final challenge I see is that the FixMyStreet code handle
-several administrations in one interface, while the Open311 API seem
-to assume only one administration. For FixMyStreet, this mean a
-report can be sent to several administrations, and the categories
-available depend on the location of the problem. Not quite sure how
-to best handle this. I've noticed
-<a href="http://seeclickfix.com/open311/">SeeClickFix</a> added
-latitude and longitude options to the services request, but it do not
-solve the problem of what to return when no location is specified.
-Will have to investigate this a bit more.</p>
-
-<p>My distaste for web forums have kept me from bringing these issues
-up with the open311 developer group. I really wish they had a email
-list available via <a href="http://www.gmane.org/">Gmane</a> to use for
-discussions instead of only
-<a href="http://lists.open311.org/groups/discuss">a forum<a/>. Oh,
-well. That will probably resolve itself, one way or another. I've
-also tried visiting the IRC channel #open311 on FreeNode, but no-one
-seem to reply to my questions there. This make me wonder if I just
-fail to understand how the open311 community work. It sure do not
-work like the free software project communities I am used to.</p>
+<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>