- <title>Initial notes on adding Open311 server API on FixMyStreet</title>
- <link>http://people.skolelinux.org/pere/blog/Initial_notes_on_adding_Open311_server_API_on_FixMyStreet.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Initial_notes_on_adding_Open311_server_API_on_FixMyStreet.html</guid>
- <pubDate>Fri, 29 Apr 2011 10:00:00 +0200</pubDate>
- <description>
-<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>
+ <title>Elektronisk stemmegiving over Internet og datalagringsdirektivet</title>
+ <link>http://people.skolelinux.org/pere/blog/Elektronisk_stemmegiving_over_Internet_og_datalagringsdirektivet.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Elektronisk_stemmegiving_over_Internet_og_datalagringsdirektivet.html</guid>
+ <pubDate>Sun, 7 Aug 2011 10:00:00 +0200</pubDate>
+ <description><p>I dag slo det meg hvordan Datalagringsdirektivet vil kunne gjøre
+det enklere å vite hvem som har stemt hva med elektronisk stemmegiving
+slik den planlegges gjennomført i Norge i høst.</p>
+
+<p>Litt bakgrunnsinformasjon er kanskje nødvendig. Siden før 2006 har
+<a href="http://www.regjeringen.no/nb/dep/krd/prosjekter/E-valg-2011-prosjektet.html">staten
+jobbet med å få på plass elektronisk stemmegiving</a> i Norge, der
+borgerne kan stemme via en datamaskin i et stemmelokale eller via en
+nettleser over Internet. Slike valg
+<a href="http://www.nuug.no/dokumenter/valg-horing-2006-09.pdf">er
+mindre demokratiske</a> enn de valgene vi har hatt i Norge de siste
+årene. En kan anta at for hver stemme som blir registrert i et slikt
+system vil det notert tidspunktet stemmen ble registrert.</p>
+
+<p>I mars i år vedtok stortinget å innføre
+<a href="http://bsdly.blogspot.com/2010/12/ikke-styrket-personvern-men-brev-og.html">elektronisk
+brev- og besøkskontroll av hele Norges befolkning</a>, da en vedtok at
+EUs datalagringsdirektiv skulle innlemmes i det norske lovverket.
+Denne kommunikasjonskontrollen innebærer blant annet at oppkoblinger
+med nettleser blir registert. Det som ble vedtatt i mars innebærer
+ikke at det blir registrert hvilken nettside en besøkte, men det vil
+bli registrert en forbindelse mellom datamaskinene som er involvert.
+Dvs. når en besøker http://www.nuug.no/aktiviteter/20110809-forgerock/
+fra sin maskin med adressen cm-84.208.83.178.getinternet.no (tilfeldig
+valgt adresse for Get-kunde), så vil tidspunktet, og adressene
+www.nuug.no og cm-84.208.83.178.getinternet.no bli registrert. En kan
+bruke adressen cm-*.getinternet.no til å identifisere
+kunde/husstand.</p>
+
+<p>Gitt at elektronisk stemmegiving via nettleser over Internet vil
+koble seg opp til datamaskinen som samler inn stemmer, så vil en altså
+ha et register over hver enkelt stemme knyttet mot tidspunkt, og et
+annet register som viser når kunder/husstander koblet seg opp mot
+datamaskinen som samler inn stemmer. Ved å koble disse registrene ved
+hjelp av tidspunktet registrert i begge vil det ofte være mulig å
+finne ut hva kunder/husstander har stemt, uten å måtte knekke
+kryptering involvert i selve stemmesankingsystemet. Det vil være
+mindre treffsikkert hvis flere stemmer blir registrert på samme
+tidspunkt, hvis stemmene er gitt til forskjellige partier, men en vil
+ha en viss ide hvilke partier det må ha vært ved å se hvilke partier
+som fikk stemmer på det aktuelle tidspunktet.</p>
+
+<p>Hvordan kan en vite at dette ikke blir gjort i dag? Det vil være
+umulig for en borger å kontrollere hva som skjer på datamaskinen som
+samler inn stemmer. De som står bak den norske elektroniske
+stemmegivingsløsningen har gitt ut kildekode som hevdes å være
+identisk med den som brukes til innsamling av stemmer, men det er ikke
+mulig for innbyggerne i Norge å kontrollere at den kildekoden er brukt
+til å lage programmene som brukes. Det vil f.eks. være trivielt for
+de som kontrollerer denne datamaskinen å legge inn ekstra kode som
+sender kopi av alle stemmer til en annen database utenfor valgstyrenes
+kontroll. Det påstås fra USA at det ble gjort med noen av de
+elektroniske stemmegivingsboksene der. Kanskje det påstås at
+stemmetellings-systemet ikke vil notere tidspunkt for hver enkelt
+stemme, men også dette vil det være umulig for oss innbyggerne å
+egenhendig kontrollere. Jeg vil ha valgsystemer som hver enkelt
+innbygger kan kontrollere, ikke et der vi må stole på påstander om
+systemet som ikke kan kontrolleres av hver enkelt innbygger.</p>
+</description>
+ </item>
+
+ <item>
+ <title>Et bilde på problemet med programvarepatenter</title>
+ <link>http://people.skolelinux.org/pere/blog/Et_bilde_p__problemet_med_programvarepatenter.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Et_bilde_p__problemet_med_programvarepatenter.html</guid>
+ <pubDate>Sat, 6 Aug 2011 21:45:00 +0200</pubDate>
+ <description><p>Via
+<a href="http://www.huffingtonpost.com/2011/08/04/patent-reform-congress_n_906278.html">en
+artikkel i Huffington Post om patentreform i USA</a> fikk jeg et
+interessant bilde på problemet med programvarepatenter. Problemet er
+at staten deler ut usynlige "eiendommer" med uklare eiendomsgrenser,
+som gjør det umulig å vite om en er på annen manns grunn hvis en ikke
+har kjennskap til at "eiendommen" finnes, og selv når en vet om den
+usynlige "eiendommen" er det umulig å vite på hvilken side av grensen
+en befinner seg.</p>
+
+<p>Hvis du er interessert i problemområdet programvarepatenter, så har
+NUUG en
+<a href="http://lists.nuug.no/mailman/listinfo/patent">epostliste om
+temaet</a>. Alle er hjertelig velkomne som abonnenter.</p>
+</description>
+ </item>
+
+ <item>
+ <title>How is booting into runlevel 1 different from single user boots?</title>
+ <link>http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/How_is_booting_into_runlevel_1_different_from_single_user_boots_.html</guid>
+ <pubDate>Thu, 4 Aug 2011 12:40:00 +0200</pubDate>
+ <description><p>Wouter Verhelst have some
+<a href="http://grep.be/blog/en/retorts/pere_kubuntu_boot">interesting
+comments and opinions</a> on my blog post on
+<a href="http://people.skolelinux.org/pere/blog/What_should_start_from__etc_rcS_d__in_Debian____almost_nothing.html">the
+need to clean up /etc/rcS.d/ in Debian</a> and my blog post about
+<a href="http://people.skolelinux.org/pere/blog/What_is_missing_in_the_Debian_desktop__or_why_my_parents_use_Kubuntu.html">the
+default KDE desktop in Debian</a>. I only have time to address one
+small piece of his comment now, and though it best to address the
+misunderstanding he bring forward:</p>
+
+<p><blockquote>
+Currently, a system admin has four options: [...] boot to a
+single-user system (by adding 'single' to the kernel command line;
+this runs rcS and rc1 scripts)
+</blockquote></p>
+
+<p>This make me believe Wouter believe booting into single user mode
+and booting into runlevel 1 is the same. I am not surprised he
+believe this, because it would make sense and is a quite sensible
+thing to believe. But because the boot in Debian is slightly broken,
+runlevel 1 do not work properly and it isn't the same as single user
+mode. I'll try to explain what is actually happing, but it is a bit
+hard to explain.</p>
+
+<p>Single user mode is defined like this in /etc/inittab:
+"<tt>~~:S:wait:/sbin/sulogin</tt>". This means the only thing that is
+executed in single user mode is sulogin. Single user mode is a boot
+state "between" the runlevels, and when booting into single user mode,
+only the scripts in /etc/rcS.d/ are executed before the init process
+enters the single user state. When switching to runlevel 1, the state
+is in fact not ending in runlevel 1, but it passes through runlevel 1
+and end up in the single user mode (see /etc/rc1.d/S03single, which
+runs "init -t1 S" to switch to single user mode at the end of runlevel
+1. It is confusing that the 'S' (single user) init mode is not the
+mode enabled by /etc/rcS.d/ (which is more like the initial boot
+mode).</p>
+
+<p>This summary might make it clearer. When booting for the first
+time into single user mode, the following commands are executed:
+"<tt>/etc/init.d/rc S; /sbin/sulogin</tt>". When booting into
+runlevel 1, the following commands are executed: "<tt>/etc/init.d/rc
+S; /etc/init.d/rc 1; /sbin/sulogin</tt>". A problem show up when
+trying to continue after visiting single user mode. Not all services
+are started again as they should, causing the machine to end up in an
+unpredicatble state. This is why Debian admins recommend rebooting
+after visiting single user mode.</p>
+
+<p>A similar problem with runlevel 1 is caused by the amount of
+scripts executed from /etc/rcS.d/. When switching from say runlevel 2
+to runlevel 1, the services started from /etc/rcS.d/ are not properly
+stopped when passing through the scripts in /etc/rc1.d/, and not
+started again when switching away from runlevel 1 to the runlevels
+2-5. I believe the problem is best fixed by moving all the scripts
+out of /etc/rcS.d/ that are not <strong>required</strong> to get a
+functioning single user mode during boot.</p>
+
+<p>I have spent several years investigating the Debian boot system,
+and discovered this problem a few years ago. I suspect it originates
+from when sysvinit was introduced into Debian, a long time ago.</p>