Diskuze o vyvoji jadra (zmenen subject)

[Milan Kerslager]

Ok,

z pocatku jsem se snazil poukazat na princip, ale neujalo se. Tak budu
konkretnejsi. Namodelujeme si pripad, kdy by to melo byt tak, jak
zaznivaji pozadavky z plena:

CVS:
====
Hlavnim argumentem pro jeho pouzivani je dle plena moznost sirsi
spoluprace a to, ze jsou k dispozici ihned patche (tj. veci se nemusi
strkat do ostre release). Dale pak zaznely pripominky "na blbou nutnost
deleni patche na male casti".

Proti CVS:
==========
Podivame-li se na vyvoj obecne, zjistime, ze kolem kazdeho open projektu
se pohybuji lide, kteri to delaji a) zadarmo a b) protoze jim to vyhovuje.
Soucasny Linuxu vyviji komunita, ktere to vyhovuje (+- fluktuace k tomu).
Volni vyvojari neexistuji, kdo je dobry, obcas akorat prejde k jinemu
projektu nebo odejde tam, odkud jiz nemuze vyvijet (open veci). Pokud
bychom zmenili dramatickym zpusobem model vyvoje, vetsine vyvojaru to
zacne vadit a odejdou. Mozna prijdou jini, ale jejich zacvik bude dlouhy a
bolestny.

Linusovo arogantni lpeni na drobeni patchu je hola skutecnost. CVS zde
nepomuze, protoze kvuli srozumitelnosti by se commity jednotlivych dilu
mely oddelovat. Jinak dojde k situaci, ze se budou tezko hledat
souvislosti a chyby (jadro neni jako ucetnictvi, kazda sebemensi chyba
muze vets k nahodnym katastrofam, ktere nebudou mit primou pricinu).
Jinymi slovy - CVS chce stejnou, mozna dokonce vetsi disciplinu vyvojaru.
Bohuzel, soucasni vyvojari na to nejsou zvykli, protoze aktivni vyvojari
to proste nepouzivaji. Linus funguje jako spolehlivy filtr a strazce.
Nemusi probirat CVS, staci jen kouknout a zaradit nebo nechat prepracovat.
Vysledkem bude pomerne konzistentni projekt s temer jednotnou kulturou.

Z toho vyplyva, ze CVS je sice varianta, ma sve vyhody, ale i nevyhody.
Jednoznacne CVS nic nevyresi, ale prinese problemy, ktere bude nutne
resit. Mozna k jeho nasazeni dojde, ale je potreba znat take cenu tohoto
kroku. Jadro neni treba KDE. Kdyz v KDE bude pul roku padat na drzku jedna
komponenta, bude to neprijemne. Pokud by v jadre skripala pul roku jedna
komponenta, muzem to zabalit.

Co se tyka problemu castych release, nemusi to byt problem. Jadro jednak
vychazi casto, jednak Alan Cox i Linus zverejnuji pre (resp. test) patche.
Je tak drzena vyrazna oficialni linie, v jadre je malo veci, ktere se
vzapeti vykopnou (doporucuji cist treba Alanovy poznamky - zahazovani
problemoveho kodu je na dennim poradku i pres to, ze Alan je dobry filtr).

Problem existence chyb v ostrych releasech neni zavazny. Patche jsou k
dispozici v l-k velmi brzo, vyvoj Linuxu neni zameren na vydani verze,
ktera vydrzi pul roku. Vyvojovy (uspesny) model vydava verze casteji, coz
je vyhodne, ale prinasi i tento drobny problem (rekl bych, ze v pripade
Linuxu je pozitivum evidentne prevazujici). Jadra by stejne meli
pripravovat tii, kteri se aspon trochu orientuji, jinak je stabilita jen
prazdny pojem (testovani je narocna cinnost).


KDB:
====
Argumentem pro jaderny debugger je snadnejsi ladeni jadra.

Proti KDB:
==========
Debugger prinasi pohodlnost a jasnou tendenci na maskovani chyb.
Netypictejsim prikladem je Andrea Arcangeli, ktereho Linus sprdaval
nejmene rok za to, ze dava do svych patchu: if (a==0) then a=1. Bez
debuggeru se vyvojar musi zamyslet nad kodem a uvedomit si situaci, ktera
prusvih zpusobuje. Je to obtiznejsi, ale vysledek je dobry - vydrzi jen ti
nejlepsi, kod je cisty.


Dokumentace:
============
Jadro nema dokumentaci. To je spatne, protoze se tim tretim stranam
ztezuje vstup na pole Linuxu.

Proti Dokumentaci:
==================
Jadro se vyviji zadarmo, bez naroku na odmenu a ve volnem case. Kdyz nekdo
neco napise, nelze ho nutit, aby delal dokumentaci. Neni za to placen (i
kdyz dokumentace se v jadre nachazi a je obvykle vyzadovana alespon v
minimalni podobe). Navic je vyvoj hodne rychly. Ve vyvojove rade se
vnitrnosti meni prilis rychle a nema cenu to prilis dokumentovat (a kdo by
to delal, kdyz ji nema ani stabilni rada). Ve stabilni rade vyznam uz ma,
ale muze se to zacit psat az vznikne. Nez se to napise (zase nekdo zadarmo
ve volnem case), bude stabilni rada stara a vyvojari bude stejne k nicemu,
protoze bude vyvijet pro vyvojovou radu.


Binarni kompatibilita:
======================
Duvody souvisi tesne s predchozim bodem - neni dokumentace, kdo to ma pak
udrzovat (drivery).

Proti binarni kompatibilite:
============================
Binarni kompatibilita je brzda, zejmena nutnost jejiho udrzeni a zpetne
kompatibility. To neumoznuje prizpusobit efektivne rozhrani potrebam
novych veci (napr. VFS pro ext3 apod). Navic by to vedlo k tomu, ze
vendori by uvolnovali binarni drivery. Ty se nedaji zkontrolovat ani
opravit. Neexistence binarni kompatibility vede take k tlaku na uvolneni
kodu (nebo alespon jeho vetsi casti), cili velke plus pro Linux.


Budoucnost Linuxu je cerna:
===========================
Zejmena pry diky stylu vyvoje. Jadro pry je dnes plne chyb (take diky
Linusovi), tvurci distribuci vetsinou maji v jadrech 50-100 patchu, ktere
neco opravuji, takze jadro je v krizi.

Proti cerne budoucnosti:
========================
Je to velmi diskutabilni. Linux je mozna tak uspesny prave proto, ze
vyuziva vyvojare, kterym to vyhovuje. Patche do jadra se pouzivaly i
drive. Presne si vzpominam, jak jsem sledoval pred 5-7 lety l-k, aplikoval
patche rucne (vetsinou opravy nebo ruzna rozsireni) a hledal zminky o
reseni mych problemu. Dnes to za nas delaji distributori, narocnost na
stabilitu jadra je vyssi, mnoztvi kodu je vetsi. I pres to je drtiva
vetsina patchu v distribucnich jadrech jen prevzata z aktualnich novejsich
verzi. Cele nove Linusovy tarbally se neprebiraji, protoze obsahuji krome
oprav i ne dost otestovane rozsahlejsi zmeny a ty je potreba nejprve
dukladne vyzkouset.

Krome toho - o uspechu Linuxu na "long run" pochybuje i Ken Thompson. Jiz
dnes jsou myslenky Unixu prekonane (projekty Plan9, Inferno). Ale
jednoznacne bude v budoucnosti na cem stavet.

-- 
                        Milan Kerslager
                        E-mail: milan.kerslager na spsselib.hiedu.cz
                        WWW:    http://www.spsselib.hiedu.cz/~kerslage/