(toiminnot)

hwechtla-tl: Debianin ideologia

Kierre.png

Mikä on WikiWiki?
nettipäiväkirja
koko wiki (etsi)
viime muutokset


Tämä sivu kertoo Debian-jakelun teknisestä ideologiasta kommentoimatta Debian-projektin poliittista ideologiaa.

Tämä on yksi uskonsota monista ATK-alan ihmisten uskonsodista. Se liittyy Linux-jakeluiden, erityisesti Debian- ja Red Hat -pohjaisten jakeluiden keskinäiseen paremmuuteen.

ATK-ihmisten tointa leimaa pyrkimys täydellisyyteen. Tietokoneet tekevät täydellisyyden mahdollisemmaksi kuin useimmilla aloilla. ATK-alan "kehityksessä" on kyse automaation rakentamisesta, kerros kerrokselta, vanhojen systeemien päälle. (Ehkä jotain vähäistä roolia on myös keksinnöillä, kuinka jokin tietty asia voidaan tehdä paremmin ja hohdokkaammin -- parempien konseptuaalisten mallien kehittämisellä.) Aikaa myöten lopputuloksena on se, että ihmisen vastuulle jäävät asiat ovat yhä korkeammalla ja korkeammalla tasolla. (Kuitenkaan tietokone ei yllä lähellekään tasoa, jolla se tekisi semanttisia päätöksiä ihmisen puolesta, kuten tekoäly-sivulla selitetään.)

Linux-jakelut jakautuvat karkeasti kahteen leiriin, joita kutsun kristallisoituneeksi ja amorfiseksi leiriksi. Kristallisoituneet jakelut pyrkivät siihen, että kaikki niissä olevat osaset -- ohjelmat, kirjastot, ohjelmien lisäosat, graafinen käyttöympäristö -- toimivat hyvin yhteen ja tuottavat kauniin, eheän kokonaisvaikutelman. Amorfinen leiri panostaa siihen, että jokainen osa toimii mahdollisimman nätisti ja että saadaan muodostetuksi standardit, jotka määrittävät, miten osasten pitää olla tekemisissä toistensa kanssa.

Kuulostaako kristallisoitunut ideologia hyvältä? Sääli, koska se on väärin. Kaikesta pinnallisesta hienoudestaan huolimatta se estää tärkeimmän edistyksen mahdollisuuden, automatisoinnin. Ei riitä, että ohjelma toimii hyvin jossain tietyssä ympäristössä. Sen pitää toimia yhtä hyvin jokaisessa ympäristössä, joka noudattaa samoja käytäntöjä. Jollei osasilla ole vakiintuneita, hyvin määriteltyjä vuorovaikutustapoja (rajapintoja), joudutaan huolehtimaan N:lle komponentille N*(N-1)/2:sta yhteistoimintatavasta. Jos komponentit tehdään yleisten rajapintastandardien mukaan, tarvitsee huolehtia vain N:sta yhteistoimintatavasta, nimittäin siitä, että jokainen komponentti täyttää oman rajapintastandardinsa.

Mitä käytännön väliä tällä on? No, aletaanpa luetella:

  1. amorfisessa järjestelmässä voi itse valita, mitä komponentteja käyttää.
  2. seurauksena, amorfisesta järjestelmästä voi suhteellisen pienellä vaivalla muodostaa oman kristallisoitumansa.
  3. amorfista järjestelmää voi päivittää pikku hiljaa, kristallisoitunutta vain hyppäyksittäin (eli aina, kun uusi kristalli on saatu tehdyksi).
  4. kristallisoitunutta järjestelmää on vaikeampaa laajentaa: jos hommaat paikasta X ohjelman x ja paikasta Y ohjelman y, jotka käyttävät samaa kirjastoa / ohjelmaa / daemonia / ytimen ominaisuutta, mutta eri tavalla, saattaa olla, ettet pysty asentamaan niitä molempia samaan järjestelmään.

RPM-pohjaiset jakelut (Red Hat, Suse, Fedora, ...) ovat tällä hetkellä kristallisoituneita, .deb-pohjaiset jakelut (Debian, Knoppix, Ubuntu, ...) ovat amorfisia. Kyse ei ole niinkään tekniikasta (RPM- ja .deb-pakettien erot ovat pienehköjä, vaikka noudattelevatkin eroa kristallisoidun ja amorfisen välillä) vaan kehittäjien asenteesta; siitä, mihin missäkin leirissä pääasiallisesti panostetaan. Esimerkiksi osasten asennuspakettien kunnolliset riippuvuus- ja konfliktideklaraatiot ovat välttämättömiä amorfiselle järjestelmälle, ja niistä huolehtiminen on usein retuperällä RPM-pohjaisissa jakeluissa; toisaalta helppo asennettavuus ja hieno oletusympäristö ovat tärkeitä kristallisoituneelle järjestelmälle, mutta jätettyinä usein huonolle huolehtimiselle amorfisissa järjestelmissä.

Loppukaneetti asiaa tunteville: onhan se näppärää, että saa haluamansa komponentin ladattuna asennettavana pakettina joltain www-sivulta, mutta aika paljon kätevämpää on etsiä ohjelmapaketti suoraan valtavasta pakettitietokannasta, asentaa se suoraan riippuvuuksineen, luottaa siihen, että se on rakennettu samalla infrastruktuurilla muiden komponenttien kanssa (esim. emacsin kirjastoissa tämä on tärkeää), ja saada siihen automaattisesti päivitykset ja varsinkin turvapäivitykset siitedes. Jollei näistä ole huolehdittu, ne edelleen aiheuttavat erillistä työtä, mikä käytännössä tarkoittaa, että laajennuksien hommaamiselle on aiheutuvan työmäärän asettama yläraja.


kommentoi (viimeksi muutettu 18.12.2008 13:10)