- <title>Skolelinux-intervju: Frode Jemtland</title>
- <link>http://people.skolelinux.org/pere/blog/Skolelinux_intervju__Frode_Jemtland.html</link>
- <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Skolelinux_intervju__Frode_Jemtland.html</guid>
- <pubDate>Wed, 27 Jul 2011 08:50:00 +0200</pubDate>
- <description>
-<p>Neste mann ut i min serie med intervjuer av Skolelinux-relaterte
-personer er en tidligere styreleder i
-<a href="http://www.friprogramvareiskolen.no/">FRISK</a> som var med
-fra starten av
-<a href="http://www.skolelinux.org/">Skolelinux</a>-prosjektet.</p>
-
-<p><strong>Hvem er du, og hva driver du med til daglig?</strong></p>
-
-<p>Mitt navn er Frode Jemtland, og jeg jobber i Hedmark IKT, som er et
-driftsselskap for Grue, Hamar, Kongsvinger, Løten, Nord-Odal og Stange
-kommuner. Her er jeg leder for avdelingen Løsninger og Arkitektur. Vi
-har i hovedansvar for servere, infrastruktur og løsninger som
-helhet.</p>
-
-<p><strong>Hvordan kom du i kontakt med Skolelinux-prosjektet?</strong></p>
-
-<p>Jobbet i IBM fra 2000, og da spesielt med Linux. Dette var da et av
-de mest tydelige linux prosjektene i Norge, og her ønsket jeg å
-bidra. Var aktivt med i prosjektet i 4-5 år.</p>
-
-<p><strong>Hva er fordelene med Skolelinux slik du ser det?</strong></p>
-
-<p>Fordelene slik jeg ser det er den sentraliserte driftmodellen, og
-alle de vel gjennomtenkte løsningene som er inkludert i denne
-løsningen. Samtidig er det basert på en stabil, og godt kjent
-plattform. Dette vil si at man har en løsning som skal være mye
-tilgjengelig, og hvor det er relativt enkelt å få tak i personer som
-kan mye om den grunnleggende plattformen.</p>
-
-<p><strong>Hva er ulempene med Skolelinux slik du ser det?</strong></p>
-
-<p>De største utfordringene med en løsningen er at den er intensiv på f.eks
-nettverk. I seg selv ikke et problem for en enkelt skole, men skal løsningen
-kjøres i større skala, med sentraliserte servere, så gir dette noen
-utfordringer.</p>
-
-<p>Utifra hva jeg har sett på større installasjoner så er det ikke så
-enkelt å skjønne, hva som bør gjøres for at den skal skaleres opp, og
-da ta godt vare på alle sider av dette, ikke bare mer server å fordele
-last/trykk, men hvordan også beholde robustheten og fleksibiliteten i
-løsningen.</p>
-
-<p>En annen utfordring er at stadig flere produkter som skal brukes i
-skoleløsningen ikke er laget til å kunne brukes i en
-skolelinuxløsning. Det blir derfor fort mye skreddersøm i de
-forskjellige installasjonene, for å få diverse pedagogiske programmer,
-webløsninger, smartboards, m.m. til å fungere. Man er også en for
-liten kundebase til at leverandørene ønsker å gjøre noe med
-utfordringen. Problemet overlates til oss.</p>
-
-<p>Det er også en kontinuerlig utfordring rundt problemet med å holde
-programvare på stabile versjoner, kontra å få ny funksjonalitet. Dette
-er jo en konflikt mellom oss som ønsker å drifte en stabil, og
-kostnadseffektiv løsning, mot sluttbrukerne som ønsker seg funksjoner
-det er vant med fra andre løsninger, eller som de må ha for at et
-eller annet nytt produkt skal fungere i løsningen. Dette er en
-utfordring også for andre plattformer.</p>
-
-<p>En siste utfordring som ikke har noe med løsningen å gjøre, men med
-det omkringliggende miljøet denne skal kjøre i, er at de enhetene som
-skal drifte dataløsninger for kommuner og fylkeskommuner begynner å
-profesjonaliseres, og er da avhengig av å ha standard løsninger for å
-drifte store brukermasser. MS er selvsagt klar over dette, og har jo
-nå flere områder de begynner å bli veldig dominerende på. Den største,
-og mest problematiske er katalogtjenesten. Man får snart ikke tak i
-større løsninger som ikke krever en AD. Når man da har store enheter
-som drifter både kommunalt ansatte og skoler, så vil det være et
-stordriftargument å standardisere på en katalog tjeneste, og da har
-man ikke noe valg. Her er alle slike driftsenheter for små til å få
-gjort om på dette. Her burde konkurransemyndighetene kommet på
-banen. Men konkurransetilsynet i USA griper sjeldent (og ikke før det
-har gått veldig lang tid) inn i monopolsituasjoner så lenge
-monopolisten er et amerikansk firma, så da har vel ikke andre
-myndigheter så mye de skulle ha sagt....</p>
-
-<p><strong>Hvilken fri programvare bruker du til daglig?</strong></p>
-
-<p>Privat kjører jeg Debian på alle mine datamaskiner. Det gjør jeg
-også på min jobbmaskin. Vi har også 15-20 linux servere av typene
-SuSE, Debian, Redhat, CentOS m.m. Jeg bruker derfor mye fri
-programvare. Av enkelt programmer kan sikkert masse nevnes. Hvis vi
-skal begrense oss til daglig, så må jeg si: OpenOffice, Firefox,
-Kontact, Kopete, Amarok,
-<a href="http://gramps-project.org/">Gramps</a>, Kate, ssh, bash,
-rsync, backuppc m.m.</p>
-
-<p><strong>Hvilken strategi tror du er den rette å bruke for å få
-skoler til å ta i bruk fri programvare?</strong></p>
-
-<p>Det er et godt spørsmål, som jeg har lurt på selv.</p>
-
-<p>Argumentene som ofte har vært brukt om at ting koster mindre holder
-ikke mål når man ser på hva som faktisk koster penger. Det er de
-ansatte som er en kostnadsdriver. Det vil si at hvis man har et system
-som den ansatte kan, så vil en kostnad på dette systemet kunne
-forsvares ganske mye ved at den ansatte gjør dette raskere og
-effektivt. Også uten å måtte eventuelt leie inn folk.</p>
-
-<p>Jeg syns det er viktigere å fokusere på prinsippet med å velge fri
-programvare, men det er også et felt hvor man fort møter lite
-forståelse blant de ansatte i skolen.</p>
-
-<p>Her må nok strategien fortsette å være at de sentrale myndighetene
-må sende tydelige signaler for hva de ønsker at offentlige enheter
-skal gjøre. Det var mye positivt på gang ang. dette for et par år
-siden. Både med eNorge og eKommune planene, men dette syns jeg har
-stoppet opp. En del av dette kan jo kanskje være usikkerheten som
-etter hvert har blitt, når man har sett kompleksiteten i de
-prosjektene som har blitt igangsatt. Det har også blitt noe usikkerhet
-i markedet ref. Sun, Oracle, Novell, Microsoft m.m. Samtidig har jo
-også de proprietære programleverandørene sørget for å endre sine
-lisenser slik at man uansett ikke slipper unna kostnaden til deres
-produkter, selv om man skulle velge alternativer. Da er det økonomiske
-argumentet, som jeg nevnte tidligere, spilt ganske godt ut over
-sidelinjen.</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>
projects / homepage.git / blobdiff