-<p>Denne gang har jeg fått tak i en mangeårig unix-mann som etter
-mange år ved Universitetet i Oslo, der jeg først traff ham, har
-flyttet tilbake til vestlandet, og der bidratt til å revitalisere
-<a href="http://www.skolelinux.org/">Skolelinux</a>-oppsettet i
-Florø.</p>
-
-<p><strong>Hvem er du, og hva driver du med til daglig?</strong></p>
-
-<p>Sturle Sunde, ansvarleg for skulenettet i Flora kommune. Eg driv,
-vidareutviklar og er andrelinje brukarstøtte for datanettet ved
-skulane i Flora kommune. 10 skular og meir enn 700 maskiner med
-Linux, medrekna tynnklientar. Tidlegare jobba eg i mange år med
-unix-drift ved Universitetets senter for informasjonsteknologi ved
-Universitetet i Oslo.</p>
-
-<p><strong>Hvordan kom du i kontakt med Skolelinux-prosjektet?</strong></p>
-
-<p>Det er vanskeleg å svare konkret på. Eg har drive med Unix og Linux i
-alle år, og Skulelinux er eit godt kjent prosjekt i miljøet. Det var
-først i 2008, då eg tok til i min noverande jobb, at eg fekk bruk for
-Skulelinux for alvor.</p>
-
-<p>Jobben min skulle vere drift av eit nytt skulenett i Flora kommune,
-levert av eit firma eg ikkje vil reklamere for. Systemet skulle vere
-ferdig levert i september året før. Dette viste seg å ta mykje lenger
-tid, og i haustferien 2008 hadde dei endå ikkje klart å få opp ei
-fungerande løysing. Situasjonen var prekær for den største skulen i
-kommunen med meir enn 500 elevar på ungdomssteget. Skulen hadde brukt
-Skulelinux før, og var tilfredse med det. No hadde dei vore utan
-fungerande datasystem i nesten eit år. Difor fekk eg opp ein ny tenar
-utanfor prosjektet og installerte Skulelinux på den. Etter litt
-justering av konfigurasjonen med god hjelp av #skolelinux på IRC, var
-den nye tenaren oppe og gjekk med både tynne og halv-tjukke klientar.
-Autentisering gjekk mot det nye systemet, slik at elevar og lærarar
-framleis har same brukarnamn og passord over alt. Dette berre
-fungerte, og vi bestemte oss for å erstatte delar av løysinga vi
-skulle få levert med Skulelinux.</p>
-
-<p>Det høyrer med til historia at det nye systemet eg skulle drive frå
-januar 2008 endå ikkje er ferdig levert. Dei jobbar med saka, seier
-dei, og har von om å fullføre leveransen i løpet av 2011.</p>
-
-<p><strong>Hva er fordelene med Skolelinux slik du ser det?</strong></p>
-
-<p>Det er veldig mange. Eg skal ta nokre få.</p>
-
-<p>Den viktigaste fordelen er at det igrunn berre er ei maskin å passe
-på, og det er tenaren. Med andre løysingar har ein gjerne programvare
-og anna som skal vedlikehaldast på kvar enkelt maskin. Med Skulelinux
-kan alle feil rettast og alle program oppgraderast på alle maskiner
-samstundes ved å gjere endringa som må til på tenaren. Eg kan sitje
-på kontoret og passe på alle tenarane i kommunen derifrå.</p>
-
-<ul>
-
-<li>Tynne klientar gjer det mogleg å bruke eldre utstyr lenge, so lenge
-tenaren er sterk nok. Ein liten tenar med eit par halv-moderne CPUar
-og 2 GiB RAM held lenge for eit typisk klasserom med 30 tynnklientar,
-og det er lett å utvide med fleire.
-
-<li>Halvtjukke klientar gjer det mogleg å utnytte kapasiteten i litt
-nyare maskiner betre, og avlaste tenaren. Ingenting vert installert
-lokalt på desse heller, og harddisken kan gjerne koblast frå. Gode
-halvtjukke klientar kan kjøpast brukt for under 1000-lappen, og det er
-heile kostnaden. Ingen lisensar eller anna på toppen, og det er ikkje
-krav til kraftigare tenar heller.
-
-<li>Det er Linux. Vi har ikkje noko kluss med drivarar, dei berre er
-der. Heller ikkje med virus, dei finst i realiteten ikkje. Eller med
-elevar som klussar med installert programvare, for dei klarar ikkje å
-øydeleggje for nokon andre enn seg sjølve.
-
-</ul>
-
-<p>Skulelinux er lagt opp til å vere veldig lett å installere rett ut
-av boksen på ein heil skule av ein interessert lærar. Det er ofte ei
-god løysing for skulen. Å ha nokon til stades som kjenner systemet og
-kan forklare enkle ting eller løyse problem der og då, er uvurderleg
-viktig for ein stressa lærar fem minutt før det ringer inn.</p>
-
-<p><strong>Hva er ulempene med Skolelinux slik du ser det?</strong></p>
-
-<p>All den ferdige konfigurasjonen gjer det tungvint å tilpasse
-Skulelinux til eit system som skal fungere saman med mange andre
-installasjonar i eit felles datanett for skulane i ein kommune. Det
-heile er prekonfigurert for ein skule, og utviding til mange skular
-med eigne tenarar er ikkje berre enkelt.</p>
-
-<p><strong>Hvilken fri programvare bruker du til daglig?</strong></p>
-
-<p>Eg brukar mest alle små hjelpeprogram som føl med operativsystemet,
-samt scriptspråket perl. Elles er Firefox/Iceweasel, Gnome-terminal
-og ssh i kontinuerleg bruk. Av Linux-distribusjonar brukar eg både
-Debian, Ubuntu, SuSE og RedHat dagleg. Eg prøvar å finne det verktyet
-som passar best til kvar del av jobben.</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 to målgrupper ein må sikte mot. Det eine er alle skulane som
-manglar eller har eit lite tilfredsstillande opplegg i dag, og ikkje
-har råd til å kjøpe noko nytt og blankpussa opplegg. Der er det om å
-gjere å gjere det enkelt for skulane å finne Skulelinux, og gjere det
-enkelt for dei å få hjelp til installasjon på skulen. Gjerne med
-lokale kontaktpersonar. Her er det dugnadsinnsats som må til, for
-desse skulane har ikkje råd til å betale for dette.</p>
-
-<p>Den andre og kanskje viktigare målgruppa er dei meir eller mindre
-profesjonelle kundane. Alle store offentlege innkjøp, inkludert
-innkjøp av nytt datasystem for skular, må ut på offentleg anbod.
-Offentlege anbod er mykje meir lukka enn dei gjev inntrykk av, og både
-regelboka og boka med triks for å sminke tilbodet er tjukk. Det er
-vanskeleg å komme inn utan eit solid salsapparat i ryggen. Kanskje
-Skulelinux skulle prøve aktivt å få seg eit partnarskap med eit av dei
-store som gjerne vil sterkare inn på den offentlege IT-marknaden?
-Nokon som kjenner triksa og har krefter til å ta opp kampen mot både
-dårlege anbod og Rudolf Blostrupmoen IT AS. Leveranse til skulane i
-ein kommune er ein god måte å få ein fot inn døra som leverandør til
-ein lukrativ kommunemarknad som kjøper alle tenester. Ta kontakt med
-nokon som er passeleg store og ikkje er Microsoft-partnar, og fortell:
-«Vi har eit ferdig produkt som du kan selje. Nei vi skal ikkje ha for
-det. Du kan gjerne gjere kva du vil med det, berre vi får lov til å
-hjelpe deg. Målgruppa er alle kommunar, og det er noko dei vil ha.
-Det er eit godt produkt, brukt av mange og godt likt.»</p>
+<p>In the Debian boot system, several packages include scripts that
+are started from /etc/rcS.d/. In fact, there is a bite more of them
+than make sense, and this causes a few problems. What kind of
+problems, you might ask. There are at least two problems. The first
+is that it is not possible to recover a machine after switching to
+runlevel 1. One need to actually reboot to get the machine back to
+the expected state. The other is that single user boot will sometimes
+run into problems because some of the subsystems are activated before
+the root login is presented, causing problems when trying to recover a
+machine from a problem in that subsystem. A minor additional point is
+that moving more scripts out of rcS.d/ and into the other rc#.d/
+directories will increase the amount of scripts that can run in
+parallel during boot, and thus decrease the boot time.</p>
+
+<p>So, which scripts should start from rcS.d/. In short, only the
+scripts that _have_ to execute before the root login prompt is
+presented during a single user boot should go there. Everything else
+should go into the numeric runlevels. This means things like
+lm-sensors, fuse and x11-common should not run from rcS.d, but from
+the numeric runlevels. Today in Debian, there are around 115 init.d
+scripts that are started from rcS.d/, and most of them should be moved
+out. Do your package have one of them? Please help us make single
+user and runlevel 1 better by moving it.</p>
+
+<p>Scripts setting up the screen, keyboard, system partitions
+etc. should still be started from rcS.d/, but there is for example no
+need to have the network enabled before the single user login prompt
+is presented.</p>
+
+<p>As always, things are not so easy to fix as they sound. To keep
+Debian systems working while scripts migrate and during upgrades, the
+scripts need to be moved from rcS.d/ to rc2.d/ in reverse dependency
+order, ie the scripts that nothing in rcS.d/ depend on can be moved,
+and the next ones can only be moved when their dependencies have been
+moved first. This migration must be done sequentially while we ensure
+that the package system upgrade packages in the right order to keep
+the system state correct. This will require some coordination when it
+comes to network related packages, but most of the packages with
+scripts that should migrate do not have anything in rcS.d/ depending
+on them. Some packages have already been updated, like the sudo
+package, while others are still left to do. I wish I had time to work
+on this myself, but real live constrains make it unlikely that I will
+find time to push this forward.</p>
projects / homepage.git / blobdiff