Ukoliko želite direktan link na ovaj govor, molim vas koristite ovaj link.

Mitovi, laži i istine o Linux kernelu

Zdravo, kao što je Dejv rekao, ja sam Greg i ljudi iz OLS-a su mi dali vreme da vam malo pričam o kernel stvarima. Disktutovaću o određenom brojem laži koje ljudi uvek kažu za kernel i pokušati da ih razbijem; preći preko nekoliko istina koje nisu mnogo poznate i pričati o nekim mitovima za koje sam čuo da se veoma ponavljaju.

Kada kažem mit, mislim na nešto za šta se verovalo da u sebi ima nešto istine, ali kada ga stvarno razmotrite, vidite da se radi o fikciji. Nazovimo ih “urbanim mitovima” Linux kernela.

Pa, da počnemo sa veoma čestim mitom koji me zaista vrlo nervira:

Znam da je skoro svako ko ima veze sa Linuxom čuo nešto slično ovome. O tome kako Linuxu nedostaje podrška za uređaje ili stvarno treba da podrži više hardvera ili kako kasnimo u celom području drajvera. Video sam skoro isti citat od nekoga u OSDL-u pre par meseci, u svojim lokalnim novinama, i ekstremno me nervira.

Ovo je zaista mit, pa ljudi treba bolje da znaju pre nego što ovo kažu. Pa, ko je rekao ovaj citat?:

Opa.

U redu, on je to verovatno rekao pre mnogo vremena, onda kada Linux zaista nije podržavao mnogo različitih stvari i kada je “Plug&Play” bio velika stvar sa ISA basevima i ostalim stvarima:

Uh.

Okej, možda treba da posvetim malo vremena i stvarno razbijem ovaj mit, pošto stvarno više nije istinit.

Pa, šta je činjenica ovih dana u vezi Linuxa i uređaja. Ovo je:

Da, to je tačno, mi podržavamo više stvari neko bilo ko drugi. I više nego što je iko ikada u prošlosti. Linux ima veoma dugu listu stvari koje smo podržali pre bilo koga drugog. Ovo uključuje stvari kao što su:

• USB 2.0

• Bluetooth

• PCI Hotplug

• CPU Hotplug

• Hotplug memorije (u redu, neki stariji Unixi su podržavali CPU i hotplug memorije, ali nijedan desktop OS još uvek ovo ne podržava.)

• Wireless USB

• ExpressCard

I lista može da ide i dalje, embedovana arena je posebno puna drajvera koje niko drugi ne podržava.

Ali, postoji veoma veliki deo hardverske podrške koja ide iznad posebnih drajvera, a to je ovo:

Da, mi smo prešišali NetBSD ekipu pre nekoliko godina u broju različitih familija i tipova procesora koje podržavamo. Nijedan drugi “veći” operativni sistem ne može čak ni blizu da se poredi sa platformskom podrškom koju imamo u Linuxu. Linux se sada izvršava na svemu od mobilnih telefona do radiom kontrolisanih helikoptera, na vašem desktop računaru, serveru na Internetu, pa sve do ogromnih 73% TOP500 najvećih superkompjutera na svetu.

I setite se, skoro svaki različit drajver kojeg podržavamo se izvršava na svakoj od ovih različitih platformi. Ovo je nešto što niko nikada nije uradio u istoriji računarstva. Jednostavno je zadivljujuće koliko je Linux moćan i fleksibilan što se ovoga tiče.

Mi sada imamo najskalabilniji i najpodržaniji operativni sistem koji je ikada bio napravljen. Uspeli smo nešto što što je tako jedinstveno i fleksibilno tako da je potreba da se ponavalja mit “Linux ne podržava hardver” nešto što svi treba da prestanemo. To jednostavno više nije istina.

Da bismo bili iskreni prema Džefu Džafeu, kada je rekao originalni citat, upravo je bio postao CTO Novella i nije zaista imao mnogo iskustva sa Linuxom, pa nije shvatao stvarno stanje podrške uređaja kojeg pružaju moderne distribucije.

Pogledajte u poslednje verzije Fedore, SuSEa, Ubuntua i drugih. Instalacija je kompletno laka (mnogo lakša nego za bilo koji drugi operativni sistem). Možete utaknuti nove uređaje i ispravni drajver će se automatski učitati, bez potrebe za lovom na disk sa drajverima, pa ste spremni za rad čak i bez potrebe da restartujete računar.

Kao primer ovoga, nedavno sam ubo novi USB štampač u svoj laptop i pojavio se prozor koji me je pitao da li želim da odštampam test stranicu. To je to, ništa više. A ukoliko to nije “plug and play”, onda ja stvarno ne znam šta je.

Ali nisu svi ignorisali uspeh Linuxa, kao što je očigledno po veličine ove konferencije. Mnogo ljudi vidi Linux i želi da ga koristi za svoje potrebe, ali kada počnu da gledaju dublje u kernel i kako se razvija, prva stvar na koju nalete je obično totalni nedostatak plana:

Ovo izluđuje mnogo ljudi svo vreme. Vidite pitanja kao što su “Linux nema planirani put, pa kako ja mogu praviti proizvod s njim”, i “Kako bilo ko uspe u ičemu pošto niko nikoga ne usmerava”, i druga pitanja slična ovima.

Pa, očigledno bazirano na činjenici da smo uspešni u nečemu što nikada do sad nije bilo urađeno, morali smo ovde doći nekako i morali smo raditi nešto ispravno, ali šta je to?

Tradicionalno, softver se stvara određivanjem zahteva koje mora da ispuni, pisanjem velikog specifikacionog dokumenta, njegovog pregleda do opšteg slaganja što se tiče dokumenta, implementiranja specifikacija, testiranja, itd. Na fakultetu uče metodologiju softverskog inžinjerstva kao metodu vodopada, metodu iterativnog procesa, metodu formalnog dokaza i druge. Onda postoje novi načini stvaranja programa kao što je ekstremno programiranje i dizajn s vrha nadole, i tako dalje.

Pa šta mi radimo ovde u kernelu?

Dr Baba proučava kako biznis funkcioniše i došao je do ovog zaključka posle istraživanja kako zajednice otvorenog koda funkcionišu i specifično kako se razvija i upravlja Linux kernel.

Mislim da ima smisla s obzirom da smo stvorili nešto što nikada pre nije bilo urađeno, uspeli smo to tako što smo radili nešto različito od svih drugih. Pa, šta je to? Kako se kernel dizajnira i stvara? Linus je odgovorio na ovo pitanje prošle godine kada je rekao sledeće grupi kompanija koje su od njega tražile da objasni proces dizajna kernela:

Ovo je zaista važna poenta koju izgleda ne razume dosta ljudi. U stvari, mislim da je oni razumeju, ali im se stvarno ne sviđa.

Kernel se ne razvija sa velikim dokumentima dizajna, traženim osobinama i tako dalje. On evoluira u vremenu bazirano na potrebi u datom momentu. Kada je nastao, podržavao je samo jednu vrstu procesora, i to je sve što se tražilo od njega. Kasnije, dodata je druga arhitektura, pa onda sve više i više kako je vreme prolazilo. I svaki put kada bismo mi dodali novu arhitekturu, programeri bi izvukli samo ono što je potrebno za podršku specifične arhitekture i uradili posao na tome. Nisu uradili posao na samom početku kako bi dozvolili neverovatnu fleksibilnost različitih tipova procesora koju imamo sada, pošto nisu znali da će to biti potrebno.

Kernel se menja samo kada mora, na način koji je potreban. Može se smanjiti do sitnih malih procesora kada se ta potreba pojavi i povećati koliko treba ukoliko neki ljudi to žele da urade. I svaki put kada se to desi, kod se vraća nazad u stablo da bi svi mogli da imaju koristi od promena, pošto je to licenca pod kojom je kernel izdat.

Prvog dana konferencije Džonatan vam je pokazao ogromnu količinu promena kojima je kernel izložen. Tone novih osobina se dodaju gigantskom brzinom, zajedno sa ispravkama greški i drugim stvarima kao što je poboljšanje koda. Ovo pokazuje koliko brzo kernel i dalje evoluira, skoro 15 godina nakon što je stvoren. On je morfovao u ovu stvar koje je veoma adaptabilna i ne liči ni blizu na ono što je bio čak pre par godina. I to je veliki razlog zašto je Linux tako uspešan i zašto će nastaviti da bude uspešan. To je zato što mi prihvatamo promenu, i volimo je, i dobrodošla je.

Ali jedan “problem” za dosta ljudi je što usled ovog konstantnog stanja evoluiranja, Linux kernel ne pruža nešto što pružaju “tradicionalni” operativni sistemi. Stvari kao što je stabilan API unutar kernela. Svi su ovo čuli pre:

Za one od vas koji ne znaju šta je API, u pitanju je opis načina na koji kernel priča unutar sebe kako bi uradio stvari. Opisuje stvari kao što su specifične funkcije koje su potrebne da urade određeni zadatak, i kako se te funkcije pozivaju.

Što se Linuxa tiče, mi nemamo stabilan interni API, a što se tiče ljudi koji bi želeli da imamo takav, to je budalaština. Skoro pre dve godine, kernel programeri su seli i napisali zašto Linux nema stabilan API unutar kernela i objavili to unutar kernela u fajlu:

Ukoliko imate bilo kakvo pitanje, pročitajte ovaj fajl. U njemu je objašnjeno zašto Linux nema stabilan API u kernelu i zašto ga nikada neće ni imati. Sve sve svodi na stvar evolucije. Ukoliko bismo zamrznuli unutrašnji način fukncionisanja kernela, ne bismo bili u stanju da evoluiramo onako kako bismo trebali.

Evo primera koji pokazuje kako ovo sve radi. Linuxov USB kod je ponovo napisan bar tri puta. Uradili smo ovo tokom vremena kako bi podržali stvari koje originalno nisu trebale da budu podržane, kao što su uređaji velike brzine, a i zato što smo naučili probleme prvog dizajna, kao i da se poprave greške i sigurnosni problemi. Svaki put kada bismo promenili naš API, popravili bismo sve kernelove drajvere koji koriste taj API, pa bi sve radilo. I obrisali smo stare funkcije pošto više nije bilo potrebe za njima i zato što su pogrešno radile stvari. Zbog ovoga, Linux sada ima najbrže USB brzine na basu kada ga testirate sa različitim operativnim sistemima. Pritisnuli smo hardver do njegove maksimalne brzine i vi to možete raditi iz jednostavnih programa na korisničkom nivou; nije vam potreban fensi kernel drajver.

S druge strane, Windows je takođe ponovo pisao svoj USB stek bar tri puta, sa Vistom može biti i četiri, nisam još stigao da obratim pažnju. Ali svaki put kada su ponovo pisali, dodavali nove funkcije i ispravljali stare, oni su morali da zadrže stare API funkcije, pošto su zauzeli stav da ne mogu prekršiti unazadnu kompatabilnost usled svoje odluke da imaju stabilan API. Oni takođe nemaju pristup kodu u svim različitim drajverima, te ih ne mogu popraviti. Pa Windowsov kernel sada ima tri seta API funkcija u sebi, pošto oni ne smeju da brišu stvari. To znači da oni održavaju stare funkcije i moraju ih celo vreme držati u memoriji, a za ovo je potrebno mnogo inžinjerskog vremena kako bi se ispratila ova dodatna kompleksnost. Njihova je poslovna odluka da to urade, i to je u redu, ali što se tiče Linuxa, mi nismo napravili takvu odluku usled čega smo uspeli da održimo manji, stabilniji i sigurniji kod.

A kada kažem sigurniji, to zaista i mislim. Često puta sigurnosni problem bude pronađen u jednom drajveru, ili u jednom delu kernela, pa ga kernel programeri isprave i isprave isti problem u svim ostalim drajverima koji imaju isti problem. Onda, kada se izda ispravka, svi korisnici svih drajvera su sigurni. Kada drugi operativni sistemi nemaju sve drajvere u svom stablu, ukoliko isprave sigurnosni problem, na strani je individualnih kompanija da osveže svoje drajvere i takođe poprave problem. A to se retko dešava. Pa ljudi koji kupuju uređaju koriste stari drajver koji dolazi u kutiji s njim, a koji je nesiguran. Ovo se nedavno desilo mnogo puta i stvarno pokazuje da postojanje stabilnog API-ja može ići na štetu korisnicima, iako je originalni cilj bio da se pomogne programerima.

Ono što se obično dešava kada ljudima pričam o nestabilnosti kernel API-ja, i načina na koji kernel funkcioniše, obično mi odgovore ovim:

Ovo jednostavno uopšte nije tačno. Mi imamo cele podarhitekture koje imaju samo dva korisnika u svetu. Imamo drajvere za koje ja znam da imaju samo jednog korisnika, pošto je to jedini hardver koji je za njega napravljen. To jednostavno nije tačno, mi ćemo uzeti drajvere za bilo šta u naše stablo, pošto ih zaista želimo.

Mi želimo još drajvera, bez obzira koliko su “neuobičajeni”, zato što nam to dozvoljava da vidimo šablone u kodu i pomaže nam da shvatimo kako se stvari mogu napraviti boljim. Ukoliko vidimo nekoliko drajvera koji svi rade istu stvar, obično uzmemo taj opšti kod i prebacimo ga u deljeni kod, čineći individualni drajver manjim i, obično, ulepšavajući ga. Takođe smo spajali cele drajvere zato što rade skoro istu stvar. Primer ovog je drajver za prihvatanje USB podataka kojeg imamo u kernelu. Postoji brdo uređaja za prihvatanje USB podataka u svetu, i jedna nemačka kompanija mi je pre nekoliko poslala drajver koji podržava njihove uređaje. Ispostavilo se da sam radio na različitom drajveru za različitu kompaniju koji je bio otprilike ista stvar. Stoga sam seo i spojio ovu dvojicu, pa mi sada imamo manji kernel. Ispostavilo se da je taj drajver proradio i za nekoliko uređaja drugi kompanija, pa su one jednostavno dodale svoje identifikacije uređaja u drajver i nikada nisu morale da pišu ni red koda kako bi dobile punu Linux podršku. Originalna nemačka kompanija je zadovoljna pošto su njihovi uređaji u potpunosti podržani, što su mušterije želele, a i druge kompanije su veoma srećne, pošto nisu morale ništa da rade. Svi pobeđuju.

Drugo pitanje koje mi ljudi postavljaju u vezi dodavanja koda kernelu je: “pa, mi želimo da zadržimo naš kod privatnim, zato što je vlasnički.”

Evo jednostavnog odogovora na ovo pitanje:

To je to, veoma je jednostavno. Imao sam nesreću da pričam sa mnogo različitih IP (Intellectual Property, intelektualno vlasništvo) advokata na ovu temu u toku prošlih godina, i svaki sa kojim sam pričao se slaže da ne postoji način da neko napravi Linux kernel modul, danas, koji može biti zatvorenog koda. To jednostavno krši GPL usled smešnih stvari kao što su izvedeni radovi i povezivanje sa drugim stvarima. Opet, vrlo je jednostavno.

Nijedan advokat neće ovo javno reći, pošto advokatima nije dopušteno da prave javne izjave ovog tipa. Ali ukoliko unajmite jednoga i pričate s njim kao advokat i klijent, on će vas ovako posavetovati što se ovog pitanja tiče.

Ja nisam advokat, niti želim to da budem, stoga me nemojte pitati ništa u vezi ovoga, molim vas. Ukoliko imate pravnih pitanja o licencama, pričajte sa advokatom, nikada nemojte to izneti na javne mejling liste kao što je linux-kernel u kojoj se nalaze samo programeri. Pitati programera da vas pravno posavetuje, javno, je kao da nas pitate za medicinski savet. To uopšte nema smisla.

Ali šta bi se desilo ukoliko bi jednog dana Linux kernel programeri odjednom odlučili da dopuste module zatvorenog koda u kernel? Kako bi to uticalo na način funkcionisanja kernela i njegovu evoluciju tokom vremena?

Izgleda da je Arjan van de Ven napisao odličnu mentalnu vežbu detaljno iznoseći tačno ono što bi se desilo u tom slučaju:

U ovom članku, koji se vrlo lako može pronaći u arhivi linux-kernel liste, on je opisao kako bi samo velike distribucije, Novell i Red Had, bile u stanju da podrže novi hardver koji bi izašao, ali bi polako stagnirale pošto ne bi smele da menjaju bilo šta što bi moglo pokvariti različite drajvere zatvorenog koda. I onda, ukoliko biste učitali više od jednog modula zatvorenog koda, podrška vašem sistemu bi bila praktično nemoguća. Čak i danas, ovo se lako može videti ukoliko pokušate da učitate više od jednog drajvera zatvorenog koda u vaš sistem, jer ukoliko se nešto loše desi, nijedna kompanija neće hteti da da podršku za vaš problem.

U članku se dalje opisuje kako bi distribucije bazirane na zajednici, kao što su Gentoo i Debian, polako postale nepotrebne i ne bi radile na novim hardverskim platformama, pa bi se presušile jer ih korisnici više ne bi mogli koristiti. I eventualno, za nekoliko kratkih godina, ceo kernel projekat bi došao do tačke u kojoj ne može nastaviti dalje, bez moći da inovira ili menja bilo šta.

Ovo je stvarno strašna priča, a i dobra je, molim vas potražite je ukoliko vas ova tema interesuje.

Ali, postoji još jedan apspekt problema modula zatvorenog koda kojeg zaista želim da istaknem, a to je onaj kojeg najveći broj ljudi ignoriše. To je:

Setite se, niko ne tera nikoga da koristi Linux. Ukoliko ne želite da napravite Linux kernel modul, ne morate to da uradite. Ali ukoliko vam to zahtevaju vaše mušterije i vi odlučite da ćete tako postupiti, morate igrati po pravilima kernela. Toliko je jednostavno.

A pravilo kernela je GPL, jednostavna licenca, sa standardnim oznakama vlasništva kopirajta, a mnogi advokati je razumeju.

Kada kompanija kaže da mora “zaštiti svoje intelektualno vlasništvo”, to je u redu, niti ja niti ijedan kernel programer nemam primedbi na to. Ali po istom pravilu, morate poštovati intelektualno vlasništvo i pravo kernel programera. Mi smo izdali naš kod pod GPL licencom, koja iznosi u veoma specifičnoj formi tačno koja su vaša prava kada koristite ovaj kod. Kada povežete drugi kod u telo našeg koda, primorani ste po licenci kernela da svoj kod takođe izadate pod istom licencom (kada ga distribuirate.)

Kada uzmete Linux kernel kod, pa ga povežete ili iskoristite heder fajlove za vaš kod, a ne povinujete se dobro dokumentovanoj licenci našeg koda, onda vi govorite da je iz nekog razloga vaš kod mnogo važniji od celog ostalog kernela. Ukratko, svakom kernel programeru koji je ikada izdao svoj kod pokazujete srednji prst.

Stoga se prisetite, individualne komanije nisu važnije od kernela, jer bez kernel programerske zajednice, komanije ne bi uopšte imale kernel za korišćenje. Endrju Morton je ovde zauzeo stav pre dve godine nazvavši pijavicama kompanije koje stvaraju module zatvorenog koda. Slažem se u potpunosti. Ono što oni rade je krajnje neetično. Neke kompanije pokušavaju da se sakriju ispod zakona zbog načina na koji redistribuiraju svoj zadvoren izvorni kod, terajući krajnjeg korisnika da kompajlira i linkuje, što ih tera da krše GPL ukoliko žele da daju već napravljen modul nekom drugom. Ove kompanije su jednostavno neetične i rade pogrešno.

Srećom, ljudi stvarno počinju ovo da shvataju i velike distribucije to više ne prihvataju. Evo šta je Novell javno izjavio ranije ove godine:

To znači da SuSE 10.1, SLES i SLED 10 neće imati nikakve kernel module zatvorenog koda u sebi. Ovo je veoma dobra stvar.

Red Hat takođe ima tekst sličan ovom u svom kernel paketu, ali nije istupio i dao neku sličnu javnu izjavu.

U redu, dosta depresivnih stvari. Nakon što kompanije shvate da stvarno treba da dodaju svoj kod u kernel stablo, brzo nalete na jedan veliki problem:

Ovo stvarno nije težak problem, kao što izgleda na prvi pogled. Setite se, dinamika promena je oko 6000 različitih pečeva po kernel izdanju, pa to znači da nekom ipak uspeva da ubaci svoj kod u stablo.

Pa, kako to uraditi? Srećom, kernel programeri su napisali sve što treba da znate da biste radili razvoj kernela. Sve je u jednom fajlu:

Molim vas, pokažite ovaj fajl svakome ko ima pitanja u vezi razvoja kernela. U njemu su odgovori na sve što je ikada bilo upitano, i nalaze se smerinice ka drugim mestima gde odgovori mogu biti pronađeni.

U njemu se priča o načinu razvoja kernela, kako da se napravi zakrpa, kako da se snađete u stablu kernela, kome slati zakrpe, o čemu se radi u različitim kernel stablima, pa čak i lista stvari koje nikada ne biste smeli reći na linux-kernel mejling listi ukoliko očekujete da neko ozbiljno pogleda vaš kod.

To je odličan fajl, a ako ikada budete imali nešto u čemu vam nije pomogao, molim vas javite autoru tog fajla i on će to dodati. On bi trebao biti nešto što ćete dati bilo kojem menadžeru ili programeru ukoliko žele više da nauče kako da ubace svoj kod u kernel stablo.

Jedna od stvari koje HOWTO fajl opisuje su razne zajednice koje mogu pomoći ljudima u razvoju kernela. Ukoliko ste novi u razvoju kernela, postoji:

projekat. Ovo je veoma dobar wiki, fina i mirna mejling lista u kojoj možete pitati osnovne stvari bez lošeg osećaja, a takođe postoji i IRC kanal u kome možete postavljati pitanja u realnom vremenu velikom broju različitih kernel programera. Ukoliko upravo počinjete, molim vas otiđite tamo, to je veoma dobro mesto za učenje.

Ukoliko stvarno želite početi sa razvojem kernela, ali ne znate šta da radite onda:

projekat je odlično mesto za počinjanje. Oni održavaju dugu listu različitih “domarskih” zadataka za koje su kernel programeri rekli da bi bili dobri za uraditi. Možete izabrati jedan od njih i naučiti osnove pravljenja zakrpe, podešavanja e-mail klijenta da ispravno pošalje zakrpu i, onda, videćete svoje ime u kernel logu promena kada vaša zakrpa uđe u njega.

Zaista preporučujem ovaj projekat svakome ko želi da počne razvoj kernla, a nije našao ništa specifično na čemu bi radio. Tražićete po kernel stablu, popravljati čudne stvari i radeći to, naćićete nešto što vas zanima, a što niko drugi ne radi, pa možete polako početi da preuzimate taj deo stabla kernela. Ne mogu dovoljno da preporučim ovu grupu.

I onda, tu je velika i ogromna mejling lista, u kojoj svi žive:

Ova lista dobija oko 200 e-poruka dnevno i može biti veoma teška nekome ko pokušava da je čita. Evo saveta, skoro niko, osim Endrjua Mortona, ne čita sve e-poruke u njoj. Mi ostali jednostavno koristimo filtere i čitamo stvari koje nas interesuju. Zaista savetujem da pronađete nekog programera za kog znate da daje interesantne komentare, pa da onda pratite diskusije na koje on odgovara. Ili jednostavno tražite temu koja vas interesuje. Ali nemojte pokušati sve da čitate, inače nikada nećete uspeti da uradite išta drugo.

Linux kernel mejling lista ima drugu vrstu primećenog problema. Mnogim ljudima reakcije programera na ovoj listi izgledaju veoma “grube” u nekim trenutcima. Oni stave svoj kod, a nazad dobiju pregled svega što su loše uradili. Obično oni koji pregledaju kritikuju sam kod, ali za većinu ljudi ovo može biti teško za primiti. Oni su upravo stavili nešto za šta su mislili da je savršena stvar, samo da bi videli to isečeno na zilion sitnih parčića.

Veliki problem je što mi, zaista, imamo samo malu grupu ljudi koji pregledaju kod u kernel zajednici. Pregledanje koda je teška, nezahvalna stvar za raditi. Stvarno te čini nervoznim i bezobraznim u veoma kratkom vremenskom periodu. Ja sam to pokušao celu nedelju, i na kraju sam pisao poruke kao što je ova:

Drugi ljudi koji pregledaju kod nisu ni izbliza fini kao što sam ja ovde bio.

Želeo bih javno da zahvalim Kristofu Helvigu i Rendiju Danlapu. Obojica provode dosta vremena pregledajući kod na linux-kernel mejling listi, a Kristof posebno ima veoma lošu reputaciju što se toga tiče. Lošu u smislu da se ljudima ne sviđaju njegovi pregledi. Ali zaista se sviđaju ostalim kernel progamerima, zato što je u pravu. Ukoliko on kaže da je nešto loše, a vi treba to da ispravite, uradite to. Nemojte ignorisati njegov savet, zato što svi drugi posmatraju da li ćete zaista popraviti svoj kod na način na koji je on tražio. Treba nam više Kristofa u kernel zajednici.

Ukoliko bi svako mogao uzeti nekoliko sati nedeljeno i pregledati različite zakrpe poslate na mejling listu, to bi bila odlična stvar. Čak i ako se ne osećate kao veoma dobar programer, čitajte kod drugih ljudi i pitajte pitanja o njemu. Ukoliko ne mogu odbraniti svoj dizajn i kod, onda je nešto zaista loše.

To je takođe odličan način da se više nauči o programiranju i kernelu. Kada učite da svirate instrument, ne počinjete odmah pisanjem celih simfonija, nego provedete godine čitajući kompozicije drugih ljudi i učeći kako se stvari stavljaju zajedno i kako interaktuju. Posle počnete da pišete sopstvenu muziku, male kompozicije, pa tek onda, ukoliko želite, radite na većim komadima. Isto važi i za programiranje. Možete naučiti mnogo toga čitajući i razumevajući kod drugih ljudi. Proučavajte stvari koje su postavljene i pitajte zašto se stvari rade na određeni način i ističite probleme koje ste primetili. To je zadatak za koji kernelu treba pomoć.

U redu, ali šta ukoliko želite da pomognete sa kernelom, a niste programer? Šta možete uraditi? Prošle godine Dejv Džons je svima rekao kako se kernel raspada, sa mnogim greškama koje su pronađene, a kraj se ne vidi. Mnogi su imali ovakav odgovor:

Ovo je tačno, bilo bi dobro imati jednostavan set testova koje bi svi mogli pokrenuti za svako izdanje kako bi se osiguralno da ništa nije pokvareno i da je sve u redu. Ali, nažalost, mi nemamo još uvek takvo test okruženje. Jedini set pravih testiranja kojeg imamo je da svi pokrenu kernel na svojim mašinama i da nam jave ukoliko kod njih radi.

Pa, to je ono što savetujem ljudima koji žele da pomognu, a nisu programeri. Molim vas, pokrenite noćna izdanja iz Linusovog kernel stabla na vašoj mašini i glasno se bunite ukoliko se nešto polomi. Ukoliko niko ne bude obraćao pažnju, bunite se opet. Budite zaista uporni. Greške prijavite u:

Ljudi zaista prate šta se tu dešava. Ponekad ne izgleda tako, ali opet, budite uporni. Ukoliko se neko uporno žali na nešto, mi se osećamo loše i radimo na tome da popravimo stvar. Nemojte se plašiti da budete naporni, zato što nam treba mnogo takvih da bi održali u pripravnosti sve nas kernel programere.

A ukoliko ste zaista hrabri, koristite -mm kernel stablo Endrjua Mortona. Ono sadrži sva stabla različitih razvojnih stabala kernel programera koja su kombinovana u jednu veliku masu nestabilnosti. Ono je testno polje za sve što će eventualno ući u Linusovo kernel stablo. Pa su nam potrebni ljudi koji će testirati ovaj kernel i rano prijaviti probleme, pre nego što odu u Linusovo stablo.

Ne bih savetovao da izvršavate Endrjuove kernele na mašini koja sadrži vama bitne podatke, to ne bi bilo mudro. Nego ukoliko imate dodatnu mašinu, ili imate dobru politiku bekapa, molim vas, koristite ovaj kernel i javite nam ukoliko imate bilo kakvih problema.

Pa konačno, kao zaključak, evo glavnih stvari za koje se nadam da će ljudi zapamtiti:

Preveo: Nikola Kotur

kotnik @ ns-linux.org