X-Git-Url: https://pere.pagekite.me/gitweb/homepage.git/blobdiff_plain/fcba3ba6e38bd04d0d7b02fc13be3979a6c00f97..5479faa6204390247aa9c0bbce6074a9da483f3c:/blog/index.rss diff --git a/blog/index.rss b/blog/index.rss index 2c2f58ccaf..185c7f6bed 100644 --- a/blog/index.rss +++ b/blog/index.rss @@ -6,6 +6,51 @@ http://people.skolelinux.org/pere/blog/ + + Intervju med digi.no om Norge Digitalt og Openstreetmap + http://people.skolelinux.org/pere/blog/Intervju_med_digi_no_om_Norge_Digitalt_og_Openstreetmap.html + http://people.skolelinux.org/pere/blog/Intervju_med_digi_no_om_Norge_Digitalt_og_Openstreetmap.html + Fri, 11 May 2012 23:40:00 +0200 + <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> + + + Cutting it short - and picking the right tool for the job http://people.skolelinux.org/pere/blog/Cutting_it_short___and_picking_the_right_tool_for_the_job.html @@ -432,59 +477,5 @@ you would hardly need a strategy.</p> - - Why the KDE menu is slow when /usr/ is NFS mounted - and a workaround - http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html - http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html - Fri, 6 Apr 2012 22:40:00 +0200 - <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> - - -