- <title>Skolelinux-intervju: Kåre Nordby</title>
- <link>http://people.skolelinux.org/pere/blog/Skolelinux_intervju__K_re_Nordby.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Skolelinux_intervju__K_re_Nordby.html</guid>
- <pubDate>Mon, 12 Mar 2012 21:10:00 +0100</pubDate>
- <description><p>Første ut i serien med intervjuer av folk i
-<a href="http://www.skolelinux.org/">Skolelinux</a>-miljøet etter at
-<a href="http://lists.debian.org/debian-edu-announce/2012/03/msg00001.html">ny
-versjon av Skolelinux</a> ble lansert i helga, er nylig valgte
-styremedlem i foreningen
-<a href="http://www.friprogramvareiskolen.no/">Fri programvare i
-Skolen</a> (FRiSK) som organiserer
-Skolelinux-utviklingen og daglig leder i
-<a href="http://www.slxdrift.no/">Skolelinux Drift AS</a>, selskapet
-prosjektet opprettet som et tilbud til skoler som ønsket en
-kommersiell samarbeidsparter. Det bør nevnes at jeg er styremedlem i
-Skolelinux Drift AS og styreleder i selskapets hovedeier stiftelsen
-<a href="http://www.linuxiskolen.no/slxdebianlabs/">SLX Debian Labs</a>
-som beskytter verdiene til Skolelinux-prosjektet, og kjenner Kåre den
-veien.</p>
-
-<p><strong>Hvem er du, og hva driver du med til daglig?</strong></p>
-
-<p>Jeg har siden januar 2010 vært daglig leder i Skolelinux Drift AS,
-som leverer support, installasjon, tilpasning, drift, og opplæring på
-Debian Edu / Skolelinux. Fra 2012 er jeg valgt inn som styremedlem i
-FRiSK. Min forrige jobb var som KAM i Redpill Linpro (som er en av
-eierne i Skolelinux Drift). Før det var jeg daglig leder i et eget 7
-manns konsulent selskap som også startet med fri programvare mot
-slutten.</p>
-
-<p><strong>Hvordan kom du i kontakt med Skolelinux-prosjektet?</strong></p>
-
-<p>Jeg hørte om det først når jeg jobbet i Redpill Linpro. Men jeg
-har også en datter som går på en friskole, som også bruker Skolelinux.
-Som kjent har ikke friskoler de samme økonomiske rammebetingelsene som
-offentlige skoler, så for dem var det det absolutt beste alternativet.
-De anser også Skolelinux som et stabilt system, som bare går og går (i
-motsetning til det lille Windows-baserte nettverket de har på
-admin-siden).</p>
-
-<p><strong>Hva er fordelene med Skolelinux slik du ser det?</strong></p>
-
-<p>Sentralisert drift av tynne og diskløse arbeidsstasjoner. Således
-lydløse og raskere arbeidsstasjoner som er bedre i klasserommet.
-Lengre levetid på PC'er. Store besparelser på maskinvare og drift. Og
-så klart fjerning av alle lisenskostnader. Personlig synes jeg også at
-mange av programmene er bedre enn alternativene. Men dette er ofte en
-smakssak og avhengig om man må ha det man er vant til fra før.</p>
-
-<p><strong>Hva er ulempene med Skolelinux slik du ser det?</strong></p>
-
-<p>For lite kjentskap til løsningen. Noen ganger for dårlig
-kompatibilitet med arbeidsstasjoners/bærbare maskiner sine
-nettverksdrivere eller skjermkort. Men dette løser vi i skolene ved
-standardisering. Ellers er det få, om nesten ingen, av de kjente
-maskinvare / infrastruktur leverandørene til fylkes- / kommuner som
-tilbyr denne plattformen. Skal dette endre seg så må kommunene selv
-sette slike krav til leverandørene.</p>
-
-<p><strong>Hvilken fri programvare bruker du til daglig?</strong></p>
-
-<p>Har brukt OpenOffice.org siden starten (2001 ?), Kun Linux på
-desktop siden 2005. Bruker i dag Kubuntu, Libreoffice og ymse annet
-programvare til ulik kontorbruk som er lett å installere / teste via
-alle programarkivene som finnes.</p>
-
-<p><strong>Hvilken strategi tror du er den rette å bruke for å få
-skoler til å ta i bruk fri programvare?</strong></p>
-
-<p>Fortsette å presentere flere av de gode eksemplene hvor Debian Edu
-/ Skolelinux brukes i kommuner og enkeltskoler. Vi må få bedre frem
-at det er mulig tilknytte både Windows og Mac klienter på denne
-plattformen (selv om det vil øke driftskostnadene). Dette gjøres
-mange steder. Spesielt er det mange lærere som ønsker å bruke
-Windows/Mac-bærbare, gjerne som sin private PC også. Det er også mulig
-for kommunen å integrere med Active Directory i stedet for OpenLDAP
-som kommer med ut av boksen (selv om også dette øker kostnadene).
-Dette vil muligens bidra til å fjerne noe motstand hos noen
-potensielle brukere / driftpersonell for å ta i bruk noe
-nytt. Fremveksten av mobile brukere og nettbrett går i vår favør.
-Brukerne blir kjent og vant til flere nye operativsystemer /
-brukergrensesnitt. Så utviklerfellesskapet bør jobbe videre med å
-integrere flere nye klienttyper, som ultra lav-kostklienter og
-nettbrett (blant annet fri programvare-alternativet
-<a href="http://makeplaylive.com/">Spark</a> med
-<a href="http://www.merproject.org/">Mer OS</a> og
-<a href="http://plasma-active.org/">KDE Active Plasma</a>).</p>
+ <title>Why the KDE menu is slow when /usr/ is NFS mounted - and a workaround</title>
+ <link>http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html</link>
+ <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Why_the_KDE_menu_is_slow_when__usr__is_NFS_mounted___and_a_workaround.html</guid>
+ <pubDate>Fri, 6 Apr 2012 22:40:00 +0200</pubDate>
+ <description><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>