]> pere.pagekite.me Git - homepage.git/blobdiff - blog/index.html
Prepare to publish.
[homepage.git] / blog / index.html
index 15c4b94cfc530be0b77e33138ce5a01d4a7dfd75..26e8c2ac2c9e2b019f6648fefefc7a4fef845cbc 100644 (file)
 
 
     
+    <div class="entry">
+      <div class="title"><a href="http://people.skolelinux.org/pere/blog/Intervju_med_digi_no_om_Norge_Digitalt_og_Openstreetmap.html">Intervju med digi.no om Norge Digitalt og Openstreetmap</a></div>
+      <div class="date">11th May 2012</div>
+      <div class="body"><p>I går ble jeg kontaktet på epost av
+<a href="http://www.digi.no">digi.no</a>s Eirik Rossen som lurte på om
+jeg hadde noen kommentarer til
+<a href="http://www.statkart.no/statkart.ny.no/nor/Statens_kartverk/Om_Statens_kartverk/Pressesenter/Nyhetsarkiv/Nyheter_2012/mai/Norge+i+tet+på+digitale+kartdata.d25-SwZLMWg.ips">kartverkets
+pressemelding</a> om Norges tetplassering når det gjelder
+kart-tilgjengelighet.  Jeg svarte følgende, som resulterte i noen
+sitater i
+<a href="http://www.digi.no/895420/norge-i-tet-paa-digitale-kartdata#debatt">Digis
+dekning</a> av kartverkets pressemelding.</p>
+
+<p><blockquote>
+<p>Takk for muligheten til å kommentere.</p>
+
+<p>Pressemeldingen omhandler tilgjengeligheten av kart for aktører som er
+medlem i kartellet Norge Digitalt.  Det er ingen overraskelse for meg
+at tilgjengeligheten til kart hos disse medlemmene er god.  Men for
+oss på utsiden av kartellet er tilgjengelighet av det som burde være
+felleskapets og innbyggernes kart dårlig.</p>
+
+<p>Bruksvilkårene til kartene fra medlemmene i Norge Digital hindrer
+nyskapning og selv om en er villig til å betale den ublu prisen som
+forlanges får en fortsatt ikke tilgang til kartdata uten
+bruksbegresninger.  Derfor bruker jeg heller tid på å gjøre
+fribrukskartet OpenStreetmap bedre.  Der fremmer bruksvilkårene
+nyskapning og lar meg skape nye tjenester uten å måtte søke om
+tillatelse fra det offentlige.</p>
+
+<p>En annen problemstilling er jo sikkerhet til fjells og til sjøs.
+Mon tro hvor mange ulykker på sjøen som kunne vært unngått hvis
+sjøkartdata var tilgjengelig uten bruksbegrensninger, slik at enhver
+med GPS eller kartplotter tilnærmet kostnadsfritt kunne sikre seg mest
+mulig oppdaterte sjøkart?  Det hjelper jo ikke at offentlige etater
+har enkel tilgang til sjøkartene når det samme ikke gjelder hver
+båtkaptein og småbåtfører.  Jeg tror samfunnet som helhet hadde tjent
+på å unngå kostnadene ved disse ulykkene ved å tvinge sjøkartverket
+til å publisere sine kartdata på Internet uten bruksbegresninger.</p>
+</blockquote></p>
+</div>
+      <div class="tags">
+        
+        
+        Tags: <a href="http://people.skolelinux.org/pere/blog/tags/kart">kart</a>, <a href="http://people.skolelinux.org/pere/blog/tags/norsk">norsk</a>. 
+        
+        
+      </div>
+    </div>
+    <div class="padding"></div>
+    
     <div class="entry">
       <div class="title"><a href="http://people.skolelinux.org/pere/blog/Cutting_it_short___and_picking_the_right_tool_for_the_job.html">Cutting it short - and picking the right tool for the job</a></div>
       <div class="date">30th April 2012</div>
@@ -31,19 +82,19 @@ But the last ones have not really been up to the task.  My last
 cutter, some model from Braun, could only cut a few of my hairs at the
 time, and cutting my head took forever.  And the one before that did
 not work very well either.  We have looked for something better for a
-while, but it was not until I ended up visiting a hair dresser that we
+while, but it was not until I ended up visiting a hairdresser that we
 discovered that there are indeed better tools available.  But these
 are not marketed and sold to "regular consumers".  The hair saloons
 can get them through their suppliers, but their suppliers only sell
 companies.  The models they sell, are very different from the ones
 available from Elkjøp and Lefdal.  The main difference is their
 efficiency.  It would cut my hair in 5 minutes, instead of the 30-40
-minutes required by my impotent Braun.  The hair dresser I visited had
+minutes required by my impotent Braun.  The hairdresser I visited had
 a Panasonic ER160, which unfortunately is no longer available from the
 producer.  But I found it had a successor, the Panasonic ER1611.</p>
 
 <p>The next step was to find somewhere to buy it.  This was not
-straight forward.  The list of suppliers I got from the hair dresser
+straight forward.  The list of suppliers I got from the hairdresser
 did not want to sell anything to me.  But searching for the model on
 the web we found a supplier in Norway willing to sell it to us for
 around NOK 4000,-.  This was a bit much.  We kept searching and
@@ -499,66 +550,6 @@ you would hardly need a strategy.</p>
     </div>
     <div class="padding"></div>
     
-    <div class="entry">
-      <div class="title"><a href="http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html">Why the KDE menu is slow when /usr/ is NFS mounted - and a workaround</a></div>
-      <div class="date"> 6th April 2012</div>
-      <div class="body"><p>Recently I have spent time with
-<a href="http://www.slxdrift.no/">Skolelinux Drift AS</a> on speeding
-up a <a href="http://www.skolelinux.org/">Debian Edu / Skolelinux</a>
-Lenny installation using LTSP diskless workstations, and in the
-process I discovered something very surprising.  The reason the KDE
-menu was responding slow when using it for the first time, was mostly
-due to the way KDE find application icons.  I discovered that showing
-the Multimedia menu would cause more than 20 000 IP packages to be
-passed between the LTSP client and the NFS server.  Most of these were
-
-NFS LOOKUP calls, resulting in a NFS3ERR_NOENT response.  Because the
-ping times between the client and the server were in the range 2-20
-ms, the menus would be very slow.  Looking at the strace of kicker in
-Lenny (or plasma-desktop i Squeeze - same problem there), I see that
-the source of these NFS calls are access(2) system calls for
-non-existing files.  KDE can do hundreds of access(2) calls to find
-one icon file.  In my example, just finding the mplayer icon required
-around 230 access(2) calls.</p>
-
-<p>The KDE code seem to search for icons using a list of icon
-directories, and the list of possible directories is large.  In
-(almost) each directory, it look for files ending in .png, .svgz, .svg
-and .xpm.  The result is a very slow KDE menu when /usr/ is NFS
-mounted.  Showing a single sub menu may result in thousands of NFS
-requests.  I am not the first one to discover this.  I found a
-<a href="https://bugs.kde.org/show_bug.cgi?id=211416">KDE bug report
-from 2009</a> about this problem, and it is still unsolved.</p>
-
-<p>My solution to speed up the KDE menu was to create a package
-kde-icon-cache that upon installation will look at all .desktop files
-used to generate the KDE menu, find their icons, search the icon paths
-for the file that KDE will end up finding at run time, and copying the
-icon file to /var/lib/kde-icon-cache/.  Finally, I add symlinks to
-these icon files in one of the first directories where KDE will look
-for them.  This cut down the number of file accesses required to find
-one icon from several hundred to less than 5, and make the KDE menu
-almost instantaneous.  I'm not quite sure where to make the package
-publicly available, so for now it is only available on request.</p>
-
-<p>The bug report mention that this do not only affect the KDE menu
-and icon handling, but also the login process.  Not quite sure how to
-speed up that part without replacing NFS with for example NBD, and
-that is not really an option at the moment.</p>
-
-<p>If you got feedback on this issue, please let us know on debian-edu
-(at) lists.debian.org.</p>
-</div>
-      <div class="tags">
-        
-        
-        Tags: <a href="http://people.skolelinux.org/pere/blog/tags/debian edu">debian edu</a>, <a href="http://people.skolelinux.org/pere/blog/tags/english">english</a>. 
-        
-        
-      </div>
-    </div>
-    <div class="padding"></div>
-    
     <p style="text-align: right;"><a href="index.rss"><img src="http://people.skolelinux.org/pere/blog/xml.gif" alt="RSS feed" width="36" height="14" /></a></p>
     <div id="sidebar">
       
@@ -578,6 +569,8 @@ that is not really an option at the moment.</p>
 
 <li><a href="http://people.skolelinux.org/pere/blog/archive/2012/04/">April (12)</a></li>
 
+<li><a href="http://people.skolelinux.org/pere/blog/archive/2012/05/">May (1)</a></li>
+
 </ul></li>
 
 <li>2011
@@ -709,7 +702,7 @@ that is not really an option at the moment.</p>
 
  <li><a href="http://people.skolelinux.org/pere/blog/tags/intervju">intervju (23)</a></li>
 
- <li><a href="http://people.skolelinux.org/pere/blog/tags/kart">kart (15)</a></li>
+ <li><a href="http://people.skolelinux.org/pere/blog/tags/kart">kart (16)</a></li>
 
  <li><a href="http://people.skolelinux.org/pere/blog/tags/ldap">ldap (8)</a></li>
 
@@ -719,7 +712,7 @@ that is not really an option at the moment.</p>
 
  <li><a href="http://people.skolelinux.org/pere/blog/tags/multimedia">multimedia (16)</a></li>
 
- <li><a href="http://people.skolelinux.org/pere/blog/tags/norsk">norsk (160)</a></li>
+ <li><a href="http://people.skolelinux.org/pere/blog/tags/norsk">norsk (161)</a></li>
 
  <li><a href="http://people.skolelinux.org/pere/blog/tags/nuug">nuug (124)</a></li>