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