Produktdokument
Innledning.
Fra
desember 2002 til mai 2003 har vi jobbet med en prosjektoppgave som har
omhandlet helt andre fagområder og problemstillinger enn vi har vært vant til.
Vår oppdragsgiver ble bestemt tidlig, og Skolelinux ble
den utvalgte. I denne innledningen vil vi beskrive hvordan vi kom fram til
løsningen på oppgaven, som er en del av et stort prosjekt. Vår del har vært å
utvikle en hjemmepc profil for Skolelinux
distribusjonen, som bruker Debian Linux som
plattform.
I
tillegg til den rene utvikling har oppgavene våre inneholdt testing,
dokumentasjonskriving, kursing av lærere og IT-ansvarlige, bug-fiksing,
diskusjoner når det gjelder verktøy, språk og teknologi. I denne
produktrapporten vil imidlertid kun utviklingen bli drøftet, de andre
elementene vil bli beskrevet i andre deler av den endelige rapporten.
Vår oppdragsgiver
Skolelinux er en idealistisk organisasjon som jobber for å fremme open-source programvare i norske skoler. Grunnskolen i
Norge bruker hvert år mangfoldige millioner på lisensiert programvare, som
nødvendigvis ikke møter de harde kravene til kvalitet man har behov for når man
skal sette opp, og drifte et stort nett. Skolelinux
drives i dag av engasjerte mennesker med stor dugnadsånd, og man får ikke lønn
for arbeidet man gjør. Prosjektet bruker styringsmodellen ”gjørokratiet”,
som innebærer at den som gjør noe, bestemmer, og det er ingen øvre instans som
må godkjenne teorier og forslag før det blir utprøvd.
Skolelinux’ prosjektleder og initiativtaker er Knut Yrvin,
og den ansvarlige for bygging av cd’en er Petter Reinholdtsen. Våre kontaktpersoner og veiledere internt i Skolelinux prosjektet har vært nettopp disse. I og med at
vi har utført et prosjekt for og med en organisasjon, og ikke en bedrift, kan
vi ikke regne med et jobbtilbud ved ferdigstillelse, som andre prosjektgrupper
kanskje får. Likevel vil vi framheve viktigheten av å jobbe i et felles
prosjekt der det eneste målet er å utvikle noe særegent, og ikke sin egen
vinning.
Oppdragsgivers mål
Skolelinux’ mål er derfor å utvikle et fullgodt alternativ til lisensiert
programvare, som i tillegg kan bidra til en bedre økonomisk situasjon for
skolene. I tillegg til dette vil Skolelinux sette
fokus på norsk programvare, og profilene skal oversettes til bokmål, nynorsk,
og samisk. Til slutt skal det legges stor vekt på pedagogisk programvare, som
enten må utvikles, eller oversettes.
Alle
engasjerte i prosjektet jobber mot det samme målet, selv om det har vært, og
er, forskjellige grupperinger som jobber med ulike ting. Eksempelvis har man
utviklere på sin side, og oversetterne på en annen. De jobber med forskjellige
ting, men alle elementer er like viktige for at det ferdigstilte produktet skal
oppfylle de kravene som er satt i utgangspunktet.
Våre mål
Vår del
av dette store prosjektet har vært å lage en HjemmePCprofil
for Skolelinux. Dette innebærer at elever som bruker Skolelinux på skolen, også skal få mulighet til å
installere den samme software hjemme. Per i dag finnes det kun profiler for installering
i et Skolelinux nettverk, og ikke for en
enkeltstående maskin. Den endelige versjonen skal kun være på 500 mb, og den
skal inneholde all programvare en elev trenger hjemme. Ved siden av det
pedagogiske skal det også tilbys en viss mengde annen programvare, til lek og
moro. Dette håper vi skal føre til at elevene selv ønsker å bli kjent med, og
bruke Skolelinux. I tillegg til denne utvelgelsen av
programvare skal cd’en fungere slik at man kan legge Skolelinux på toppen av et eventuelt annet operativsystem.
Slik Skolelinux fungerer på skolene i dag, så blir
harddisken tømt først, for å så installere Skolelinux.
Hjemme hos en elev må de få muligheten til å beholde det de har ved siden av, så hvordan partisjoneringen skal utføres har vært en utfordring. Til
slutt skal elevene selvsagt få mulighet til å koble seg til Internett.
For å få til dette må vi lage oppsett både for oppringte
forbindelser, og bredbånd/kabelnett.
Den
totale problemstillingen kan altså deles opp i følgende deler:
- max 500 mb
- partisjonering
-
nettilgang
-
pakkeutvelgelse
I dette
prosjektet har vi brukt flere forskjellige verktøy, både når det gjelder
utvikling og dokumentering. Gruppemedlemmene har forskjellig bakgrunn når det
gjelder forkunnskaper, så noen teknologier har vi kjent til, andre har vi
måttet lære oss fra bunnen. Særlig de spesifikke open-source
verktøyene har vært en utfordring for oss, men samtidig også veldig lærerikt.
Hva er opensource?
Fri programvare kan sammenliknes
med talefrihet, og ikke pris. Mange misforstår open-source
til å innebære at alt skal være gratis, men dette medfører ikke riktighet.
Fri programvare
referer til brukernes frihet til å kjøre, kopiere, distribuere, studere,
forandre på og forbedre programvaren. Man kan dele opp denne friheten i fire
deler, som beskriver begrepet:
·
Friheten
til å kjøre programmet, uansett hensikt.
·
Friheten
til å studere hvordan programmet virker, og tilpasse det til dine behov.
·
Friheten
til å redistribuere kopier.
·
Friheten
til å forbedre programmet, og gi det ut med dine forbedringer til offentlig
eie, slik at hele samfunnet kan få utbytte.
For at et program skal
være fritt må det tilfredstille disse fire kravene.
Man skal kunne benytte seg av disse frihetene uten å spørre om eller betale for
en tillatelse, og man skal kunne distribuere kopier til hvem som helst, hvor
som helst.
Du burde også ha
friheten til å lage modifikasjoner og bruke dem privat i ditt eget arbeid eller
hobby, uten å nevne at de eksisterer. Hvis du gir ut forandringene, skal du
ikke være nødt til å underrette noen som helst, på noen som helst måte.
Når det snakkes om fri
programvare, er det best å unngå å bruke setninger som ``gi bort'' eller ``helt
gratis'', fordi slike terminologier betyr at det det
gjelder om er prisen, og ikke friheten. Noen kjente slike ord som
``piratkopiering'' omfatter meninger vi håper du ikke må godkjenne.
(kilde: www.fsf.org)
Krav til maskin og programvare:
Linux i
skolen har som filosofi at man skal kunne kjøre Skolelinux
på gamle maskiner i skoleverket. Det er derfor satt forholdsvis lave krav til
maskinvare. Skolelinux skal kunne kjøre på maskiner
med følgende kravspesifikasjoner:
150 MHz
CPU
64 MB RAM
2 GB
Harddisk
CD-Rom
Diskettstasjon,
skjerm, tastatur og mus
Dette er
minimumskravene.
Beskrivelse av løsninger
Partisjonering
Alle operativsystem er avhengige av å kunne lagre data på et
sted. Dette gjøres normalt på en harddisk. For at operativsystemet skal vite hvor
og hvordan den skal lagre informasjonen må det lages egne partisjoner og
filsystemer. En partisjon er en del av en harddisk. Når en partisjonerer
en harddisk deles den opp i mindre biter logisk sett. Disse bitene oppfører seg
som separate harddisker. Filsystemet legges inne i en partisjon. Et filsystem
inneholder spesielle forutsetninger og regler for hvordan data skal lagres.
Disse reglene MÅ følges av operativsystemet for at det skal kunne lagre og
finne igjen dataene sine ved behov.
Hvert
operativsystem har sine egne regler for hvordan en partisjon skal være, og
hvordan et filsystem skal være. Hvis disse reglene ikke følges til punkt og
prikke vil hele systemet bryte sammen. Det er derfor viktig at hvert
operativsystem får ha sine egne partisjoner og filsystemer.
Når du
har valgt profil vil du få spørsmål om du vil autopartisjonere
harddiskene. Hvis ja velges vil alle filer du hadde på PCen
bli slettet. Dette gjøres med programmet “Autopartkit”.
Dette er et C program som automatisk detekterer harddisker, partisjonerer
disse og mounter dem. Dette er i seg selv meget
praktisk når en skal ha en ren Skolelinux maskin, men
dette vil neppe være tilfellet for majoriteten av hjemmepc-profil
brukerne. De vil typisk ha en versjon av MS Windows installert fra før, som
bruker filsystemet FAT 16, FAT 32 eller NTFS. For å la en PC beholde sitt
opprinnelige OS, kan i dag ikke Autopartkit benyttes
da den overskriver alle partisjonstabeller. Det vil da i framtiden være
ønskelig med et “AutoLVMkit”.
I første
omgang vil vi la brukeren velge mellom å benytte autopartkit
eller cfdisk. Hvis brukern
velger autopartkit vil den fungere som tidligere
beskrevet. I cfdisk må brukeren selv partisjonere diskene. I dette målet forutsettes det at det
er ledig plass på harddisken som ikke er partisjonert.
Dette er en en relativt stor begrensning i og med at
de fleste ikke har satt av plass på harddiskene sine til slikt. Det å benytte
en form for LVM vil da være en mye bedre løsning. Når du har valgt standalone profilen vil du bli presentert for to valg.
“Autopartisjoner” og “Manuell partisjonering”.
“Autopartisjoner” starter autopartkit, mens “Manuell partisjonering” starter cfdisk,
for deretter å mounte de nye partisjonene. Siden de
fleste ikke har satt av plass i partisjonstabellen for harddisken vil det være
en enorm fordel om det var mulig å forandre størrelsen på de andre partisjonene
på disken slik at det ble noe plass ledig. En kunne deretter lage de Linux
partisjonene som var nødvendig.
Det er
mulig å forandre størrelsene på diskene med LVM. Når det er laget ledig plass
på disken brukes cfdisk til å lage Linux
partisjonene. Når du har valgt standalone profilen
vil du bli presentert for to valg. “Autopartisjoner” og “Manuell partisjonering og LVM”. “Autopartisjoner” starter autopartkit, mens “Manuell partisjonering
og LVM” starter først GNU parted og/eller ntfsresize. Så startes cfdisk
slik at du kan lage partisjonene. Deretter mountes de
nye partisjonene. Den ideelle løsningen på partisjoneringsproblemet
vil være å ha en versjon av autopartkit som også kan
forandre størrelsene på andre partisjoner som eventuelt måtte være der fra før,
for så å lage sine egne partisjoner.
Denne
løsningen vil nok ligge langt fram i tid, fordi alle applikasjonene som skal ta
seg av LVM ikke er ferdig utviklet eller fungere ikke helt problemfritt med
hverandre enda. Når du har valgt standalone profilen
vil du bli presentert for tre valg. “Autopartisjoner”, “Manuell partisjonering og LVM” og “AutoLVM
og partisjoner”. De to første valgene gjør det samme som de gjorde i mål 2. Det
tredje valget starter et program som kan resize
partisjoner, opprette partisjoner og mounte dem.
De fleste
private brukere av PCer er ikke vant til tekstbaserte
systemer eller programmer. De er vant til å kunne trykke på ting med musa,
eller i verste fall bare kunne navigere med piltastene.
De er vant til at det finnes utfyllende hjelpetekster til alt de foretar seg
lett tilgjengelig med etv tastetrykk. Alle verktøyene
som vi har sett på har i dag ikke noe særlig brukervennlig grensesnitt. De er
tekstbaserte, og gir lite tilbakemeldinger og forklaringer. Det at programmene
gir lite tilbakemeldinger og forklaringer betyr ikke at de ikke at de ikke er
veldokumenterte, men at denne dokumentasjonen og forklaringen ikke ligger inne
i selve programmet. Det følger som oftest en utførlig beskrivelse av programmet
i manualsidene til Linux. Det er likevel å forvente for mye av brukerne å anta
at de kan benytte seg av manualsidene, og finne frem til hva de skal gjøre ved
hjelp av dem. Det bør utvikles et mer brukervennlig utseende på verktøyene vi
bruker, med utførlig hjelpetekst, og hva som er anbefalt å gjøre.
Pakkeutvelgelse
CDen
består av pakker som listet opp i følgende tekstfiler.
task-skolelinux-common.txt,
task-skolelinux-server.txt,
task-skolelinux-workstation.txt,
task-skolelinux-standalone,
task-skolelinux-extra.txt,
task-skolelinux-ltsp.txt og task-skolelinux-networked.txt.
Vi i hjemmeprofil
gruppen tar av oss task-skolelinux-standalone
filen. Og her vil du finne de pakkene som skal ligge i denne profilen. Vi vil
slette og evt. bytte ut pakker som er bedre. For å kunne bytte/slette pakker må
vi først vite hva elevene vil trenge av programmer. Og dette har lærere på
skoler som skal eller bruker skolelinux/linux svart på. Vi har også bruk for
task-skolelinux-commen.txt, fordi her ligger det pakker som man må ha for å få
installert skolelinux. Disse pakkene som ligger under
task-skolelinux-common må vi ha under installasjonen
for å få med nødvendig programvare for hardware-deteksjon.
Derfor må vi først installere commen pakkene så
installeres pakkene under standalone filen.
Standalone.txt
Her er en oversikt over tekstfilen standalone-filen. Denne listen vil bli oppdatert fortløpende. Og disse pakkene vil være med på cd`en. Og det er en liten beskrivelse på hver pakke. Vi måtte gå igjennom alle pakken som ligger under standalone filen og finne ut hvilke pakker som var viktige for elvene og hva de evt. vil ha bruk for i skolesammenheng.
Common.txt
Vi må også ha med pakkene som ligger under filen common.txt, og her er en oversikt over hvilke pakker som ligger under denne filen, og en beskrivelse på hver pakke.
Etter at pakkene (common & standalone) har blitt pakket ut skal den ikke ta mer plass en 500 mb på harddisken. Dette slet vi med å gjennomføre. Derfor lagde vi to pakker slik at den ene pakken er strippet for pakker og bare består av de viktigste pakkene, og det er denne som vil bli installert på maskinene. Og hvis elevene vil få bruk for andre pakker/program vil disse ligge på andre pakken.
Nettilgang
Beskrivelse av teknologi og verktøy
For å utføre
prosjektet har vi benyttet oss av flere forskjellige verktøy og tekonologier. Noen av disse har vi hatt kjennskap til,
andre har vi måttet lære oss fra starten. Spesielt open-source
verktøyene har vært forholdsvis nye for oss, men prosessen med å sette seg inn
i teknologi vi ikke har hatt kjennskap til har vært utfordrende og svært
lærerikt.
CVS
CVS
står for concurrent version
system og er en versjons kontroll system. Et versjonskontrollverktøy som er svært
nyttig når mange personer jobber på samme prosjektet. Alle endringer man gjør
må sjekkes inn i CVS, og på den måten har man til enhver tid informasjon om
alle forandringer som blir gjort. CVS lagrer endringene fra versjon til
versjon, slik at man når som helst kan gå tilbake og se hvilke endringer som er
gjort, når de ble gjort, og hvem som gjorde de. Ved å bruke dette systemet er
det mulig å alltid få tak i det siste versjonen av
kildekoden. Det fungerer på den måten at hver gang man har gjort en forandring
i kildekoden som man mener andre kan ha glede av så rapporteres dette inn. Når
du rapporterer inn i cvs er det også viktig å legge
med en beskrivelse av den forandringen du har gjort. Når dette blir lagret vil
det bli sjekket på mot den gamle koden og kun de linjene med kode som har avvik
fra den gamle koden blir lagret i en ny fil. Ved å bruke dette systemet vil
disse filene ikke ta så stor plass. En av de store fordelene med dette systemet
er at det er mulig å ha to personer som jobber på samme kildekode samtidig,
selv om dette ikke er å anbefalt. Det vil da bli en
konflikt, men dette er det mulig å løse ved å hente ned den nyeste kildekoden
og legger til sin forandring i den. Om man finner ut at den endringen som er
gjort i kildekoden ikke fungerer på den måten det var tenkt er det også mulig å
gå et skritt tilbake (rollback) til den gamle
kildekoden.
Bugzilla
Kort
sagt er Bugzilla et verktøy for å holde styr på feil
som oppstår underveis i en utviklingsprosess. Bugzilla
ble utviklet av Terry Weissman
som skrev programmet i et programmeringsspråk som heter ”TCL”. Senere ble Bugzilla skrevet i Perl, og det er den versjonen som per i
dag er i bruk. Bugzilla er et open-source
verktøy, i motsetning til utallige andre ”feil-søkende”
program, så det tok ikke lang tid før programmet ble svært populært.
Bugzilla
er en database program der det er mulighet for å rapportere inn feil (bug) man har funnet i Linux eller søke på statusen til bugs. De innrapporterte feilene blir så satt opp i en
prioritert liste slik at man får en slags to-do liste
over utviklingsarbeidet. Arbeidsoppgavene blir så tildelt forskjellige
utviklere etter deres ønske. På siden <http://bugs.skolelinux.no/>
har Skolelinux sin bugside.
Der er det mulig å følge med på hva som det jobbes med på prosjektet og hvem
som gjør dette.
Mailinglister
All informasjon som
blir utvekslet i Skolelinux prosjektet går gjennom en
mailingliste. Her er det mulighet til å stille
spørsmål angående prosjektet eller hjelpe andre med deres problemer. Dette
gjøres fordi dette er den beste måten å spre informasjon på. I tillegg så er
det stor sannsynlighet for at du får svar tilbake på dine spørsmål siden alle
utviklerne sjekker denne mailinglisten hver dag. Alle
som ønsker å delta i Skolelinux prosjektet kan melde
seg på denne mailinglisten, og dermed får man en unik
innsikt i hvordan prosjektet utvikler seg.
IRC
Står for Internet Relay Chat. Dette er en måte å kommunisere med andre på via
nettet. I motsetning til mail, og mailinglister
er man på irc koblet seg opp hele tiden, om man først
skal være der. Kommunikasjonen blir tilnærmet face to
face kommunikasjon, og man kan få svar med en gang,
siden alt foregår i nåtid. Man kan velge mellom utallige klienter for å koble
seg opp til et IRC nettverk, og et typisk skjermbilde viser en felles kanal der
alle deltakerne kan snakke sammen, eller man kan snakke privat med kun en annen
person om dette er ønskelig. Flere av utviklere i Skolelinux
miljøet er koblet til chatte kanalen #skolelinux på serveren irc.ifi.uio.no
og er dermed lett å få tak i hvis man skulle trenge hjelp til noe. I tillegg
finnes det andre nyttige kanaler der man får hjelp umiddelbart.
SSH
SSH (secure shell) lar deg koble deg
til en annen maskin via en sikker forbinelse, ofte
over usikre nettverk. Dette lar seg gjøre via autentisering og kryptering. SSH
kan bruke på tvers av plattformer, bare man har en klient. Eksempel på klienter
kan for Windows være Putty, og for Unix en fri
variant av SSH, OpenSSH. Teknologien har millioner av
brukere i over 80 land. SSH kan sies å være en sikrere versjon av RSH og
RLOGIN.
C/C++
Skolelinux er bygget på Debian
Linux, som igjen er skrevet i programmeringsspråket C. C og C++ er kanskje det
mest brukte programmeringsspråket i verden i dag. Språket må kompileres før det
kan eksekveres. Dette fører til at det må kompileres spesifikt for hver
plattform. Du kan for eksempel ikke kjøre en kode som er kompilert i Windows på
en Debian plattform.
Avslutning
Vår del
innenfor Skolelinuxprosjektet har vært en utfordring.
Vårt ferdigleverte produkt er ikke nødvendigvis ferdig om man tar den store
sammenheng i betraktning. Skolelinux ønsker
kontinuerlig å forbedre tjenestene sine. Om andre tar opp tråden vår, og
videreutvikler profilen, ser vi ikke på dette som et nederlag, heller tvert i
mot. Om vi har klart å lage et fundament som andre kan bygge videre på, har vi
nådd målet. Funksjonaliteten er der, og det er selvsagt at produktet vårt må
vedlikeholdes og forandres gjennom tiden, i takt med at teknologien utvikler
seg.
Videre utvikling
Skolelinux fortsetter arbeidet sitt med å utvikle open-source
programvare også etter at vårt prosjekt er ferdig. Når vi nå har fått innsikt i
hva prosjektet dreier seg om ønsker vi fortsatt å være en del av
utviklermiljøet. Om andre også vil ta del i utviklingen finnes all
dokumentasjon i CVS, der alle utviklere har tilgang. Igjen råder open-source tankegangen, man kan hente ut kildekoden,
forandre den, og legge den tilbake i CVS.
Fremtiden
Skolelinux har oppnådd en bred støtte både i næringslivet og i skoleverket. Flere
og flere skoler ønsker å teste Skolelinux, og
utviklingen er på rett spor.