Aaron Griffin
Introduksjon
Det er ikke lenge siden vi tok en prat med utvikleren bak den unge, men lovende Linux-distribusjonen Draco Linux.
Hva som får Draco Linux til å skille seg ut fra de brukervennlige Linux-distribusjonene vi vanligvis tester her på Hardware, er at Draco fokuserer på å gi deg full kontroll over ditt operativsystem, uten at du skal trenge en doktorgrad i Linux for å klare det.
Vi kan trygt betegne Draco Linux, og lignende distribusjoner, som KISS-distribusjoner (Keep it simple, stupid). En av de mest populære KISS-distribusjonene for øyeblikket heter Arch Linux, som i forhold til Draco, har et vesentlig større miljø og antall utviklere.
For å få en bedre forståelse av distribusjonen har vi stilt sjefen selv - Aaron Griffin - noen spørsmål.
Artikkelen er også tilgjengelig i en engelsk versjon.
Intervju - Del 1
Hvem er du og hva er din rolle i Arch Linux?
Jeg begynte opprinnelig med Arch i 2003. Du kan si at jeg vokste opp på Arch, siden jeg tilegnet mesteparten av min tunge tekniske kunnskap på en Arch-maskin. Senere ble jeg spurt om å bli en av kjerne-utviklerne for distroen, hvor jeg etter hvert ble hoved-utvikleren bak pacman, samtidig som jeg jobbet på noen verktøy som f.eks. mkinitcpio.
Nå om dagen har Judd, den tidligere "eieren" av Arch, gitt seg, og jeg har tatt hans plass. Men tro meg når jeg sier at det høres mer prestisjefullt ut enn det egentlig er. Arch er en god distribusjon fordi vi har et fantastisk utviklerteam som jobber med den. Ikke pga. hva jeg gjør.
Hva er Arch Linux?
Arch Linux er en distro som setter brukeren i kontroll. Det er en distribusjon designet for å være en plattform - en "base" for brukeren til å gjøre hva han/hun vil med. Andre distribusjoner, som f.eks. Ubuntu, har en tankegang om at datamaskinen skal ta vare på seg selv og brukeren skal bare bruke den. Det er en helt grei tankegang å ha, og det fungerer også veldig godt for de aller fleste. Men ikke for meg. Jeg vil ha full kontroll og det er derfor jeg bruker Arch.
Arch er lett på systemressursene, og er simpelt, som leire - muligheten til å bli formet av brukerne etter deres ønsker. Dette betyr at vi ikke prøver å tvinge noen til å gjøre hva vi vil, med våre konfigurasjonsverktøy og ideer. Utviklere foreslår ting, og dytter på i enkelte retninger, men når alt kommer til alt lar vi brukerne gjøre som de vil.
Hvor mange utviklere jobber med Arch?
Ifølge denne siden har vi 27 utviklere, alle med forskjellige oppgaver. Selv om jeg ser for meg at dette tallet vil øke i fremtiden, tror jeg først vi må finne ut nøyaktig hva alle gjør, og hvilke hull vi må fylle.
Hva med brukermiljøet rundt Arch? Hva er deres rolle i utviklingen og hvordan kan de bli en av kjerne-utviklerne?
Arch-miljøet er og har alltid vært fantastisk. Mange av de populære programvarene idag er laget og brukt av brukerne selv, som f.eks. yaourt, kdemod, alunn og mye, mye annet.
I tillegg har vi det vi kaller for Trusted Users (TU) som styrer vår [community] pakkebrønn. Her finner du mindre populære pakker, pakker som utviklerne egentlig ikke bruker men som miljøet liker og bruker mye. Den beste måten for noen å hjelpe til med utviklingen av Arch på er å bli en TU.
Intervju - Del 2
Etter hva vi forstår ble pacman skrevet spesifikt for Arch. Hvorfor lage deres egen pakkebehandler?
Pacman kom til verden fordi, alt annet var bare for komplekst. Andre løsninger trengte gjerne syv verktøy og hadde et komplekst pakkeformat. Pacman var et forsøk på å lage noe enkelt og oversiktlig, noe jeg mener vi har lyktes med.
AUR lar hvem som helst laste opp sine egne PKGBUILDs slik at andre kan laste de ned. Når kom ideen om AUR på bordet?
AUR kom til verden for lenge siden. Opprinnelig ble det kalt TUR eller Trusted-User Repository, hvor vi hadde en gruppe mennesker som hver hadde sin pakkebrønn som ble støttet offisielt av Arch. Det var egentlig ikke noe web-basert grensesnitt eller noe slikt før vi begynte å diskutere muligheten for å kombinere disse pakkebrønnene i en sentral pakkebrønn, [community].
AUR er nå i full utvikling og det er vanligvis mye aktivitet på vår aur-dev mailing list, hvor folk helper til med å forbedre AURs grensesnitt og den generelle AUR opplevelsen.
Ved bruk av AUR og et alternativt brukersnitt til pacman som f.eks. yaourt, får du muligheten til å installere programvare på en enkel måte selv om de ikke er offisielt støttet av Arch. Hvorfor har ikke pacman muligheten for å kompilere programvare fra AUR? Eller hvorfor legges ikke pakker som yaourt til de offisielle pakkebrønnene?
For det første så vil pacman aldri kompilere programvare fra kildekode. Det er rett og slett ikke pacmans oppgave. Å inkludere den muligheten hadde vært som å gi cp - kommando for å kopiere filer - muligheten til å vise innholdet i en mappe. Det har ingenting for seg. For å nevne litt Unix-filosofi: ett verktøy for jobben.
For det andre så er det for mange sikkerhets-risikoer med verktøy som automatisk kompilerer programvare på denne måten. Dette betyr ikke at vi anser våre brukere som dumme. Vi tror på at hvis du har lyst å ta den risikoen, så skal du for all del gjøre det. Men, det skal være en liten hindring å passere for å ta de risikoene. En skal ikke kunne skru på automatisk installasjon fra [unsupported] ved et uhell.
Å ha verktøy som tillater slik automatisk installasjon i de offisielle pakkebrønnene, er det samme som at vi nikker hodet til alle PKGBUILD-filer i [unsupported]. Det er som at vi i kjerne-teamet sier "For all del, gjør det. Det er greit". Problemet er, det er ikke greit. Det er en sikkerhets-risiko som alle skal være oppmerksom på.
Hvordan er pakkebrønnene satt opp, og hva er restriksjonene på de ulike?
[core] pakkebrønnen inneholder "kjernen av Arch Linux". Det betyr, at det inneholder alle pakkene som MÅ være perfekt for at distribusjonen fortsetter å fungere. Dette er de absolutt system-kritiske pakkene. Vi er veldig kritiske angående hvilke pakker som ender opp i [core].
[extra] derimot, er veldig anderledes. [extra] inneholder alle pakkene vi føler et operativsystem bør støtte, men som igjen ikke er system-kritiske. Selvfølgelig, enkelte av disse pakkene, som apache, kan være viktige for enkelte brukere, men de er ikke viktige for ALLE brukerne. Vi prøver å begrense antall pakker som er i [extra], rett og slett fordi vi kanskje kommer til å ende opp med for mange pakker som ingen får tid til å vedlikeholde.
I [unstable] finner vi programvare vi gjerne vil ha i [extra], men som er for ustabilt for øyeblikket. Av og til støtter vi også programvare hentet gjennom versjon-kontroll systemer som SubVersion og CVS. I øyeblikket tror jeg du finner en svn-versjon av mplayer i [unstable].
[testing] er hvor vi tester alle pakkene våre før de blir lagt til i [core] eller [extra]. Vi krever at alle [core] pakker får litt tid i [testing], så vi kan være sikre på at det er helt stabilt før vi sender det videre til alle Arch brukerne. Når det gjelder pakker som skal til [extra] lar vi den som er ansvarlig selv bestemme om den først skal i [testing].
Og så har vi [community] som er vedlikeholdt av TUene og AUR-miljøet. Pakker som ender opp i [community] har vanligvis fått en del stemmer i AUR, eller er noe en TU liker og bruker.
Hvorfor ikke kombinere [extra] og [community]?
De er vedlikeholdt av to helt forskjellige grupper mennesker, og på forskjellige måter. Jeg har faktisk tenkt på dette, men med vår nåværende infrastruktur er det umulig. En kul ide ville vært å flytte pakkebrønnene over til et SVN-basert system, og brukt et AuthZ-basert sikkerhetssystem for å hindre TU-er å endre pakker som håndteres av kjerne-teamet og omvendt. F.eks. ville det ikke blitt populært om en TU hadde gjort endringer som hadde skapt problemer i apache-pakken.
Noen fremtidsplaner for å forbedre pacman?
Nå er ikke jeg sjefen for utviklingen av pacman lenger. Dan McGee er sjefen der nå, og han gjør en fantastisk jobb. Vi har også mange aktive utviklere som jobber med spennende ting, så det er vanskelig å si nøyaktig hvor pacman kommer til å være i tiden fremover. Men jeg regner med at det kommer til å bli mer kode-orientert enn noe annet. Det hadde vært flott å se et oversiktelig og intuativt grensesnitt til libalpm ("backenden" av pacman), slik at andre får en lettere jobb med å utvikle alternative brukersnitt. Akkurat nå er det ikke så enkelt som det burde være.
Intervju - Del 3
Vi antar du selv bruker Arch?
Selvfølgelig! Jeg har brukt Arch på alle maskinene mine de siste fem årene. Jeg hadde en maskin for å teste andre operativsystem på, men pga. feil med maskinvaren kjører den 64-bit Arch nå. Dessverre måtte jeg nettopp installere Windows for første gang på tre år her i huset. Jeg bruker den bare for å kunne streame filmer fra Netflix, da deres programvare kun støtter Windows grunnet noe DRM tull.
Så hva er planen videre for Arch?
Hmm, planene er alltid i bevegelse. Jeg har mine egne personlige mål, men ingen store fancy ideer. Det er veldig flytende sånn sett. Personlig ville jeg likt å se støtte for flere arkitekturer, kanskje tilogmed BSD- og cygwin-kompitable pakker. Også bedre automatikk for å bygge pakker, og bedre verktøy for å håndtere pakkebrønnene hadde vært flott! Hvis du ser bort i fra det, så er vi stort sett hvor jeg vil at vi skal være.
Sammenlignet med andre distribusjoner, hva er Archs største svakhet?
Jeg har vanskelig for å besvare dette spørsmålet, hovedsaklig fordi jeg ikke bruker andre distribusjoner nok. Men Eliott, en av de andre utviklerne, tok opp et ganske godt poeng da jeg spurte ham.
Det at Arch baserer seg på et rullerende utgivelsessystem gjør at vi er veldig avhengig av utviklerne av programvaren vi pakker inn i distribusjonen vår. F.eks. hvis vi bestemmer oss for å oppdatere en pakke av et bibliotek eller verktøy, så må vi være veldig sikre på at alt annet fungerer med den nye versjonen av det verktøyet eller biblioteket. Enkelte programvareutviklere er ikke så veldig raske på å oppdatere programvaren sin for å bruke nye versjoner av diverse bibliotek eller verktøy, og det holder oss tilbake.
Andre distribusjoner venter uker eller måneder før de oppdaterer programvaren i pakkebrønnen sin, og da er det større sjanse for at programvareutviklerne har oppdatert programvaren, eller at noen har laget en patch for gjeldende program.
Hva bør nybegynnere gjøre for å lære seg Arch Linux?
Vi har en begynner-guide i wikien, og det er et godt sted å begynne. Hvis du vil lære deg hvordan det hele er satt sammen, så er den beste måten å lese diverse skript. Hvis du ikke kan lese skript, så bør du lære deg det.
Vi er ikke interessert i å holde hender. Hvis du vil lære noe, bør du være forberedt på å lære deg det selv istedenfor å få noen til å forklare det for deg.
Hvordan er det å utvikle Arch? Er det bare for moro skyld eller finnes det en skjult grunn vi ikke vet om?
Det er bare for moro skyld. I virkeligheten prøver jeg å lage den perfekte distro for mine datamaskiner, og resultet er tilfeldigvis noe som andre også liker, ellers hadde vi ikke hatt et så godt team med utviklere eller et så fantastisk miljø rundt distribusjonen.
Etter å ha lest et månedlig nyhetsbrev på deres hjemmesider må jeg spørre... Er det sant at du kan løfte en bil over hodet!?
Alderen trekker på, så jeg kan ikke løfte en bil alene lenger. Jeg trenger ihvertfall en ekstra person for å hjelpe meg, dessverre.
Det er forresten bare en spøk, du burde ikke ta hva som står i de nyhetsbrevene for alvorlig.
Og vi er ferdig. Når du tenker tilbake, er det noe du gjerne vil si som du føler du ikke har fått sagt?
Ikke som jeg kommer på, nei. Jeg vil gjerne takke alle som har lest dette, jeg håper å se noen av dere prøve Arch i nær fremtid.
Vi takker Aaron for hans tid og tålmodighet, og ønsker ham lykke til videre.
Avsluttende ord
Vi har i dette intervjuet fått frem filosofien bak Arch Linux, pakkehåndteringen, miljøet og hvordan du kan bli en utvikler for distribusjonen.
Hvis du har lyst å begynne med Arch Linux, er som nevnt wikien et godt sted å starte.
Etter vårt intervju med utvikleren bak Draco Linux, har vi mottatt mange ønsker om en test av Draco, eller en lignende KISS-distribusjon. Med dette i tankene, ser vi nå på muligheten for en test av Arch Linux.
Siden dette vil bli vår første test av en distribusjon uten et grafisk brukersnitt, vil vi gjerne vite hva du vil se i en slik test. Kom gjerne med ønskene dine i forumtråden under, eller send oss en e-post.
