blog/archive/2009/06/06.rss

   1 <?xml version="1.0" encoding="ISO-8859-1"?>
   2 <rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
   3         <channel>
   4                 <title>Petter Reinholdtsen - Entries from June 2009</title>
   5                 <description>Entries from June 2009</description>
   6                 <link>http://people.skolelinux.org/pere/blog/</link>
   7
   8
   9         <item>
  10                 <title>Litt om valgfusk og problemet med elektronisk stemmegiving</title>
  11                 <link>http://people.skolelinux.org/pere/blog/Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html</link>
  12                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Litt_om_valgfusk_og_problemet_med_elektronisk_stemmegiving.html</guid>
  13                 <pubDate>Wed, 17 Jun 2009 14:20:00 +0200</pubDate>
  14                 <description>&lt;p&gt;&lt;a href=&quot;http://www.aftenposten.no/nyheter/uriks/article3127058.ece&quot;&gt;Aftenposten
  15 melder&lt;/a&gt; at det kan se ut til at Iran ikke har lært av USA når det
  16 gjelder valgfusk.  En bør endre tallene før de publiseres, slik at en
  17 kandidat aldri får færre stemmer under opptellingen, ellers blir det
  18 veldig tydelig at tallene ikke er til å stole på.  I USA er det
  19 derimot &lt;a href=&quot;http://www.blackboxvoting.org/&quot;&gt;rapporter om at
  20 tallene har vært endret&lt;/a&gt; på tur mot opptellingen, ikke etter at
  21 tallene er publiserte (i tillegg til en rekke andre irregulariteter).
  22 En ting Iran åpenbart har forstått, er verdien av å kunne
  23 kontrolltelle stemmer.  Det ligger an til kontrolltelling i hvert fall
  24 i noen områder.  Hvorvidt det har verdi, kommer an på hvordan
  25 stemmene har vært oppbevart.&lt;/p&gt;
  26
  27 &lt;p&gt;&lt;a href=&quot;http://universitas.no/kronikk/48334/kan-vi-stole-pa-universitetets-elektroniske-valgsystem-/&quot;&gt;Universitetet
  28 i Oslo derimot&lt;/a&gt;, har ikke forstått verdien av å kunne
  29 kontrolltelle.  Her har en valgt å ta i bruk elektronisk stemmegiving
  30 over Internet, med et system som ikke kan kontrolltelles hvis det
  31 kommer anklager om juks med stemmene.  Systemet har flere kjente
  32 problemer og er i mine øyne ikke bedre enn en spørreundersøkelse, og
  33 jeg har derfor latt være å stemme ved valg på UiO siden det ble
  34 innført.&lt;/p&gt;
  35
  36 &lt;p&gt;Universitet i Bergen derimot har klart det kunststykket å aktivt gå
  37 inn for å gjøre det kjent at det elektroniske stemmegivingssystemet
  38 over Internet &lt;a href=&quot;http://nyheter.uib.no/?modus=vis_nyhet&amp;id=43404&quot;&gt;kan
  39 spore hvem som stemmer hva&lt;/a&gt; (det kan en forøvrig også ved UiO), og tatt
  40 kontakt med stemmegivere for å spørre hvorfor de stemte som de gjorde.
  41 Hemmelige valg står for fall.  Mon tro hva stemmesedlenne hadde
  42 inneholdt i Iran hvis de ikke hadde hemmelige valg?&lt;/p&gt;
  43 </description>
  44         </item>
  45
  46         <item>
  47                 <title>Debian boots quicker and quicker</title>
  48                 <link>http://people.skolelinux.org/pere/blog/Debian_boots_quicker_and_quicker.html</link>
  49                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Debian_boots_quicker_and_quicker.html</guid>
  50                 <pubDate>Wed, 24 Jun 2009 21:40:00 +0200</pubDate>
  51                 <description>&lt;p&gt;I spent Monday and tuesday this week in London with a lot of the
  52 people involved in the boot system on Debian and Ubuntu, to see if we
  53 could find more ways to speed up the boot system.  This was an Ubuntu
  54 funded
  55 &lt;a href=&quot;https://wiki.ubuntu.com/FoundationsTeam/BootPerformance/DebianUbuntuSprint&quot;&gt;developer
  56 gathering&lt;/a&gt;. It was quite productive.  We also discussed the future
  57 of boot systems, and ways to handle the increasing number of boot
  58 issues introduced by the Linux kernel becoming more and more
  59 asynchronous and event base.  The Ubuntu approach using udev and
  60 upstart might be a good way forward.  Time will show.&lt;/p&gt;
  61
  62 &lt;p&gt;Anyway, there are a few ways at the moment to speed up the boot
  63 process in Debian.  All of these should be applied to get a quick
  64 boot:&lt;/p&gt;
  65
  66 &lt;ul&gt;
  67
  68 &lt;li&gt;Use dash as /bin/sh.&lt;/li&gt;
  69
  70 &lt;li&gt;Disable the init.d/hwclock*.sh scripts and make sure the hardware
  71    clock is in UTC.&lt;/li&gt;
  72
  73 &lt;li&gt;Install and activate the insserv package to enable
  74    &lt;a href=&quot;http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot&quot;&gt;dependency
  75    based boot sequencing&lt;/a&gt;, and enable concurrent booting.&lt;/li&gt;
  76
  77 &lt;/ul&gt;
  78
  79 These points are based on the Google summer of code work done by
  80 &lt;a href=&quot;http://initscripts-ng.alioth.debian.org/soc2006-bootsystem/&quot;&gt;Carlos
  81 Villegas&lt;/a&gt;.
  82
  83 &lt;p&gt;Support for makefile-style concurrency during boot was uploaded to
  84 unstable yesterday.  When we tested it, we were able to cut 6 seconds
  85 from the boot sequence.  It depend on very correct dependency
  86 declaration in all init.d scripts, so I expect us to find edge cases
  87 where the dependences in some scripts are slightly wrong when we start
  88 using this.&lt;/p&gt;
  89
  90 &lt;p&gt;On our IRC channel for this effort, #pkg-sysvinit, a new idea was
  91 introduced by Raphael Geissert today, one that could affect the
  92 startup speed as well.  Instead of starting some scripts concurrently
  93 from rcS.d/ and another set of scripts from rc2.d/, it would be
  94 possible to run a of them in the same process.  A quick way to test
  95 this would be to enable insserv and run &#39;mv /etc/rc2.d/S* /etc/rcS.d/;
  96 insserv&#39;.  Will need to test if that work. :)&lt;/p&gt;
  97 </description>
  98         </item>
  99
 100         <item>
 101                 <title>Microsofts misvisende argumentasjon rundt multimediaformater</title>
 102                 <link>http://people.skolelinux.org/pere/blog/Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html</link>
 103                 <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Microsofts_misvisende_argumentasjon_rundt_multimediaformater.html</guid>
 104                 <pubDate>Fri, 26 Jun 2009 13:30:00 +0200</pubDate>
 105                 <description>&lt;p&gt;I
 106 &lt;a href=&quot;http://www.regjeringen.no/upload/FAD/Vedlegg/Hoeringer/Refkat_V2/MicrosoftNorge.pdf&quot;&gt;Microsoft
 107 sin høringsuttalelse&lt;/a&gt; til
 108 &lt;a href=&quot;http://www.regjeringen.no/nb/dep/fad/dok/horinger/horingsdokumenter/2009/horing---referansekatalog-versjon-2.html?id=549422&quot;&gt;forslag
 109 til versjon 2 av statens referansekatalog over standarder&lt;/a&gt;, lirer
 110 de av seg følgende FUD-perle:&lt;/p&gt;
 111
 112 &lt;p&gt;&lt;blockquote&gt;&quot;Vorbis, OGG, Theora og FLAC er alle tekniske
 113   spesifikasjoner overordnet styrt av xiph.org, som er en
 114   ikke-kommersiell organisasjon.  Etablerte og anerkjente
 115   standardiseringsorganisasjoner, som Oasis, W3C og Ecma, har en godt
 116   innarbeidet vedlikeholds- og forvaltningsprosess av en standard.
 117   Det er derimot helt opp til hver enkelt organisasjon å bestemme
 118   hvordan tekniske spesifikasjoner videreutvikles og endres, og disse
 119   spesifikasjonene bør derfor ikke defineres som åpne
 120   standarder.&quot;&lt;/blockquote&gt;&lt;/p&gt;
 121
 122 &lt;p&gt;De vokter seg vel for å nevne den anerkjente
 123 standardiseringsorganisasjonen IETF, som er organisasjonen bak HTTP,
 124 IP og det meste av protokoller på Internet, og RFC-standardene som
 125 IETF står bak.  Ogg er spesifisert i
 126 &lt;a href=&quot;http://ietf.org/rfc/rfc3533.txt&quot;&gt;RFC 3533&lt;/a&gt;, og er uten
 127 tvil å anse som en åpen standard.  Vorbis er
 128 &lt;a href=&quot;http://ietf.org/rfc/rfc5215.txt&quot;&gt;RFC 5215&lt;/a&gt;.  Theora er
 129
 130 under standardisering via IETF, med
 131 &lt;a href=&quot;http://svn.xiph.org/trunk/theora/doc/draft-ietf-avt-rtp-theora-00.txt&quot;&gt;siste
 132 utkast publisert 2006-07-21&lt;/a&gt; (riktignok er dermed teksten ikke
 133 skrevet i stein ennå, men det blir neppe endringer som ikke er
 134 bakoverkompatibel).  De kan være inne på noe når det gjelder FLAC da
 135 jeg ikke finner tegn til at &lt;a
 136 href=&quot;http://flac.sourceforge.net/format.html&quot;&gt;spesifikasjonen
 137 tilgjengelig på web&lt;/a&gt; er på tur via noen
 138 standardiseringsorganisasjon, men i og med at folkene bak Ogg, Theora
 139 og Vorbis også har involvert seg i Flac siden 2003, så ser jeg ikke
 140 bort fra at også den organiseres via IETF.  Jeg kjenner personlig lite
 141 til FLAC.&lt;/p&gt;
 142
 143 &lt;p&gt;Uredelig argumentasjon bør en holde seg for god til å komme med,
 144 spesielt når det er så enkelt i dagens Internet-hverdag å gå
 145 misvisende påstander etter i sømmene.&lt;/p&gt;
 146 </description>
 147         </item>
 148
 149         </channel>
 150 </rss>