Diskuze o vyvoji jadra (zmenen subject)

[Pavel Kankovsky]

Tak vidim, ze jsem uspesne rozpoutal pekny flame war. Takze je mozna na
case, abych take trochu prilozil. :)

Citovani pisatele:

MK> Milan Kerslager
CR> Cejka Rudolf
PJ> Ing. Pavel PaJaSoft Janousek
LH> Leo Hadacz
SM> Stanislav Meduna

-------

MK> CVS:
MK> ====
MK> Hlavnim argumentem pro jeho pouzivani je dle plena moznost sirsi
MK> spoluprace a to, ze jsou k dispozici ihned patche (tj. veci se nemusi
MK> strkat do ostre release).

Nejak mi uniklo, ze by hlavni problem bylo "to CVS or not to CVS".
Jestli chceme nejakou nalepku, tak je to spis "change management".

PJ> 1. Zaznam historie (to je tak asi vse k cemu lze to CVS pouzit) a
PJ> pripadny navrat at pouzijeme jakykoli evolucni model vyvoje projektu -
PJ> Changelog to skutecne nenahrazuje

Tedy...ja kdyz jsem chtel obcas najit informace o provedenych zmenach,
tak jsem mel casto potize najit i nejaky changelog, kde by byly ty zmeny
nejak vyjmenovany.

PJ> 3. Feature Freeze (to jedine se v Linuxu vyhlasuje, ale stejne je to
PJ> pouze formalni - a bohuzel se nedodrzuje) 

Feature freeze se vetsinou zvrhne v prazdne prohlaseni v situaci, kdy
stabilizace zmrazene verze trva prilis dlouho.

PJ> 4. Alfa a beta testovani (primo vyvojari) + patricne release

Terminologicka poznamka: alfa testovanim se vetsinou rozumi "in-house"
testovani, cili zde asi testovani provadene primo vyvojari, zatimco
u beta testovani se predpoklada ucast "externich" testeru, cili zde asi
ucast verejnosti.

PJ> 5. Zpetny feeback (opravy, patche, namety na zlepseni)

Feedback je jednoduchy. Staci napsat do l-k. Otazka je, jestli to nekdo
vezme na vedomi, nebo jestli se to mezi ostatnim bordelem nenavratne
ztrati (tedy ztrati...u nekterych jinych nejmenovanych projektu jsem
v nekterych pripadech ziskal dojem, ze prislusny nejmenovany vyvojar ci
vyvojari "prehledli" zaslane bugreporty a/nebo patche naprosto zamerne).

PJ> 6. QA

QA si v teto situaci delaji sami distributori. V ramci svych moznosti.

SM> Hlavnym argumentom je reprodukovatelnost (na jemnejsej urovni,
SM> ako su jednotlive verzie) a dalej informacia, kto, co a preco urobil.

Coz o to, bez detailni historie kodu mezi jednotlivymi verzemi by se
asi dalo celkem obejit, ale spis chybi popis zmen na ponekud vyssi urovni
abstrakce a take zaznam o jejich motivaci a smyslu (tedy obcas se to da
dohledat treba v l-k, ale dvakrat efektivni postup to neni).

SM> Commity jednotlivych dielov treba niecim spojit. Neviem, ci CVS
SM> pozna pojem "changesetu" - ide o zgrupovanie viacerych suvisiacich
SM> zmien. Ak nepozna, mal by sa hladat system, ktory to pozna -
SM> toto je naozaj u takehoto projektu dolezite.

CVS ten pojem primo nezna, ale da se celkem dobre emulovat pomoci
komentaru k jednotlivym commitum. Nebudu vsak tvrdit, ze vim, jak
moc je to "scalable" (pouzival jsem to jen na mensi projekty).

MK> (jadro neni jako ucetnictvi, kazda sebemensi chyba muze vets
MK> k nahodnym katastrofam, ktere nebudou mit primou pricinu).

A ci je to chyba? Ted se muzu zatvarit moudre jako Tannenbaum a rict,
ze za to muze monoliticka architektura jadra a bohuzel budu mit z velke
casti pravdu...navzdory Linusove antipatii vuci mikrokernelum.
(O tom, jaky ma znacna monoliticnost IMHO vliv na efektivitu vyvoje,
bude jeste rec.)

MK> Jadro neni treba KDE. Kdyz v KDE bude pul roku padat na drzku jedna
MK> komponenta, bude to neprijemne. Pokud by v jadre skripala pul roku jedna
MK> komponenta, muzem to zabalit.

Jak se jmenuje ta cast, co od vydani 2.4.0 porad blbne? Memory managemenent?
A to uz bude dobreho pul roku, ne? Tak to uz abychom to zabalili. :)

MK> Problem existence chyb v ostrych releasech neni zavazny. Patche jsou k
MK> dispozici v l-k velmi brzo, vyvoj Linuxu neni zameren na vydani verze,
MK> ktera vydrzi pul roku.

Idea "pustime to do sveta s napisem Stabilni Verze, a kdyz to nebude
fungovat, tak vyrobime nejake patche" je naprosto zhoubna. To, ze jsou ty
patche k dispozici rychle (tedy jak kdy), onu zhoubnost ponekud zmirnuje,
ale rozhodne ji neodstranuje.

Takovy pristup vetsinu uzivatelu rozdeli do 5 skupin: 1. neopravili jsme to,
protoze nam to nahodou funguje, 2. neopravili jsme to, protoze jsme prilis
lini a/nebo blbi, 3. neopravili jsme to, protoze se bojime, co se udajnou
opravou rozbije misto toho (casty -- a ne zcela nesmyslny -- argument, proc
nekde nejsou SP na NT), 4. neopravili jsme to, protoze mame na praci lepsi
a/nebo dulezitejsi veci, 5. opravili jsme to, ale jsme pekne nasrani, ze
jsme neco takoveho museli vubec delat -- jak by se asi libilo auto, ktere
musi kazdy mesic (pokud ne casteji) k mechanikovi?

Pak je zde samozrejme ten problem, ze software, ktery se musi porad
opatrovat, aby fungoval, urcite porusuje nejaky patent vyrobce hracky
jmenem Tamagochi. :)

MK> Jadra by stejne meli pripravovat tii, kteri se aspon trochu
MK> orientuji, jinak je stabilita jen prazdny pojem (testovani je narocna
MK> cinnost).  

Neni tak trochu zbytecne pak mluvit o "stabilni rade", kdyz zadna
z ni obsazenych verzi neni "stabilni", ale je to pouze polotovar,
ze ktereho se neco "stabilniho" vyrobi?

CR> Vsiml jste si jednoho drobneho posunu? Drive byla jadra od Linuse
CR> dost dobre pouzitelna primo. V posledni dobe ale mam stale vetsi
CR> dojem, ze kazde nove jadro potrebuje vic a vic dokoncit. Jak to
CR> bude pokracovat dal? Muze to byt ale jen muj osobni dojem.

A jisty vyznamny diskuter dokonce otevrene nedoporucuje pouzivat
"vanilla kernel", ale jadro ozaplatovane od distributora. :P

MK> To je podle meho subjektivni nazor vyvolany tim, ze predchozi stabilni
MK> rada se udrzovala velmi dlouho. Soucasna stabilni rada se udrzuje od
MK> zacaku roku (kalendarniho) a myslim, ze pri hledani analogie 2.2.0 a 2.4.0
MK> bychom nasli podobne momenty (tj. spatny pocit z toho, ze predchozi
MK> stabilni rada byla [relativne] byla bez problemu).

Nepamatuji si, ze by s radou 1.2, pricemz nejstarsi mnou pouzivana verze
byla asi 1.2.3, byly nejake problemy (pominu fakt, ze si to nejak
nerozumelo s mou tehdejsi disketovkou, ale na ni padaly i Wokna).
Rada 1.2 skoncila u verze 1.2.13 nebo tak nejak. Rada 2.0 skoncila
u 2.0.38 resp. 39. Sem tam nejake potize byly, ale rekl bych, ze od
cca 2.0.10 se to dalo pouzit. Rada 2.2 je zatim u 2.2.19 a dost krute
potize se stabilitou byly az nekdy do 2.2.14-15. Ten pocit, ze nektere
veci jdou od desiti k peti, je asi dost subjektivni, ale nikoli uplne
neopodstatneny.

MK> Dale pak zaznely pripominky "na blbou nutnost deleni patche na
MK> male casti".
[...]
MK> Prestav si sebe, jak se staras o projekt s 1.5 milionu radku kodu.

"Someone comes and says, 'Here I have 30 million lines of code.'
What do you do? You give up." --Jason Hickey, Marktoberdorf 1998

Jeden a pul milionu neni zcela totez co 30 milionu, protoze jste neni
zcela akutni hrozba "gravitacniho kolapsu" projektu, ale uz je to dost o
hubu. Necemu tak velkemu proste nikdo nedokaze (do detailu) rozumet. Ani
Linus Torvalds -- pri vsi ucte k nemu. To, ze Linus lpi na rozmelneni
uprav na male "snadno stravitelne" casti je sice logicka obranna reakce,
ale neresi to podstatu problemu.

MK> Kdyz posles 20 jednoduchych fixu do NTFS a odstranis tim jeho
MK> soucasne nejvetsi problemy, tak prokazes, ze Tvoje nova implementace
MK> bude tezit ze zkusenosti a ze ses dobrej.

A daji se opravy nejvetsich problemu NTFS atomizovat do 20 jednoduchych
patchu? Nejspis ne. A nebo mozna daji, ale budou to opravdu "zaplaty"
(tak trochu v intencich zminovane oblibene Arcangelliho konstrukce
"if (a==0) a=1") a "Olympane" to hodi zpatky s tim, ze to neni "hezka
oprava" (castecne zalozeno na vlastni zkusenosti).

MK> Napis patch na dokumentaci a posli ho do l-k. Budes ho muset poslat treba
MK> 10x. Pokud to neudelas, nenadavej, protoze co si neudelame sami, to tam
MK> proste *nebude*. Z vnejsiho pohledu spadas do stjne kategorie, na kterou
MK> nadavas (tj. taky nic nedelas a taky za to muzes).

Neco jineho je "udelat" a "udelat desetkrat". V druhem pripade lze jen
tezko od vetsiny lidi ocekavat, ze budou dost motivovani, aby vydrzeli
"hrach na stenu hazet" do te doby, nez je nekdo laskave vezme na vedomi.


---------

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

IMHO je kdb tak trochu "zastupny problem" (jak se ted casto rika).
Takovy debugger resp. ladici nastroj obecne totiz muze slouzit k mnoha
ruznym ucelum: od obligatniho trasovani, pres analyzu okamziteho stavu
ladeneho programu nazivo i post-mortem, az po ruzne sofistikovane
funkce slouzici napr. k tomu, aby se za behu programu testovalo, zda
nejakou vec provadi spravne (v souladu s predem stanovenymi pravidly).

Nejproblemovejsi je ta post-mortem analyza. "Ladit hlavou" je bezva vec,
ale kdyz prijdete rano k zamrzlemu pocitaci, na kterem je v lepsim pripade
nejaky "Oops" (ovsem s puvodnim mistem vzniku problemu nijak
nesouvisejicim), v horsim pak vubec nic, tak mi hlava moc nepomuze
(zamyslet se nad kodem jadra jako celkem asi moc lidi nedokaze).
Existence nejakeho ladiciho nastroje, at uz je KDB nebo jaderny coredump,
v takove situaci umoznuje ziskat aspon nejaka voditka a netapat v naproste
tme.


------

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

Take je to spatne z toho duvodu, ze casto neexistuje jednoznacny popis
toho, jak maji veci fungovat, "co tim chtel basnik rict." Stavajici kod
sice mozna funguje a jeho analyzou se leccos da zjistit, ale kdyz pomineme
otazku, zda neni ztrata casu, aby kazdy musel znovu vynalezt kolo, tak
samozrejme zakon schvalnosti rika, ze se novacci budou inspirovat tim
nejmene vhodnym prikladem, ktery se ve stavajicim kodu najde a ktery se
tam v Linusove slabe chvilce dostal.

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

Pekna Hlava 22. Vtip je v tom, ze zakladni dokumentace ma vzniknout jeste
pred tim, nez se neco naprogramuje -- vetsinou ve forme specifikace.
A takova dobre udelana specifikace, ta zarucuje nejen to, ze si neco
rozmyslim, nez zacnu opravovat, ale i to, ze si to poradne rozmyslim,
nez zacnu neco stavet na zelene louce, pripadne nez neco zacnu od zakladu
rekonstruovat. A take je to vec, ktera se da rozumne podrobit kritice,
ktera odhali pripadne chyby a chytaky jeste pred tim, nez se to
naprogramuje (kdo to nevyzkousel, neuveri :> ).


--------

MK> Proti binarni kompatibilite:
MK> ============================
MK> Binarni kompatibilita je brzda, zejmena nutnost jejiho udrzeni a zpetne
MK> kompatibility. To neumoznuje prizpusobit efektivne rozhrani potrebam
MK> novych veci (napr. VFS pro ext3 apod).

To neznamena, ze obecne nelze (v rozumne mire) nejakym zpusobem podporovat
i starsi verzi rozhrani. Ostatne na rozhrani kernel-userland se binarni
kompatibilita udrzuje a nikdo se nevzteka, ze to svazuje vyvojarum ruce.

MK> Navic by to vedlo k tomu, ze vendori by uvolnovali binarni drivery. Ty
MK> se nedaji zkontrolovat ani opravit. Neexistence binarni kompatibility
MK> vede take k tlaku na uvolneni kodu (nebo alespon jeho vetsi casti),
MK> cili velke plus pro Linux.  

K tlaku na uvolneni kodu vede hlavne to, kdyz lidi nebudou kupovat
veci, ke kterym bude binary-only driver. (Ovsem nejlepsi zarizeni je
pochopitelne takove, ktere zadny specialni driver nepotrebuje.)

LH> Ten, kdo nedokaze byt dostatecne pruzny a reagovat na zmeny vnitrnich
LH> interfacu, zrejme nemuze byt vyvojarem jadra. Ale timto se dostavame asi
LH> uz nekam uplne jinam. K tomu by mohl rict neco nekdo, kdo nejaky ten
LH> driver (nebo subsystem) do jadra napsal a protlacoval.

Dejme tomu, ze udelam nejakou komponentu, ktera nema zadne extremni naroky
na casovou (a pripadne i prostorovou) efektivitu. Takovych veci je v jadre
spousta -- dost mozna, ze 3/4 vsech driveru a filesystemu jsou tohoto
charakteru. Takze je vlastne dobre, ze se musi pri kazde zmene vnitrnosti
predelat krome te kriticke 1/4 i zbylych 3/4 kodu? Spis ne, co?

Vysledek je takovy, ze jadro vlece na noze cim dal tim tezsi kouli tvorenou
vsim tim balastem, co se na nej nabalil, a ktery se musi neustale
prepisovat podle nejnovejsi "mody" a pak pochopitelne zase znovu ladit a
stabilizovat. Presne podle hesla "kazdy projekt roste tak dlouho, az
preroste svym tvurcum pres hlavu."


--------

MK> Budoucnost Linuxu je cerna:
MK> ===========================
[...]
MK> Krome toho - o uspechu Linuxu na "long run" pochybuje i Ken Thompson. Jiz
MK> dnes jsou myslenky Unixu prekonane (projekty Plan9, Inferno). Ale
MK> jednoznacne bude v budoucnosti na cem stavet.

Ovsem do Linuxu se ty nove myslenky jen tezko dostanou rozstrihane do
desetiradkovych patchu. :)


--------

Ruzne a obcas lehce off-topic:

PJ> 	A to je co za pojem? Software neni kus zdeforomovaneho plechy, ktery
PJ> neni mozno znovu vylestit bez ztraty presne  tloustky... Znam maximalne
PJ> pojem ze oprava je neefektivni vzhledem k vynalozene praci.

Urcite by se dnes nasla technologie, ktera umoznuje na plech osoupany
opakovanym lestenim vratit ztraceny material. Ale bude to pekne drahe.
A to je presne pripad toho softwaru.

MK> Je to podobne, jako kdyz ekologisti tvrdi, ze Temelin poskozuje zivotni
MK> prostredi, ze je nebezpecny. A presto je statisticky prokazano, ze
MK> kousnuti zralokem je vic pravdepodobne, nez smrt na Temelin.

O tom, jak je pravdepodobne, ze nekoho zabije Temelin, zadna prukazna
statisticka data asi neexistuji. Stejne jako nejsou (vetsinou) k dispozici
data o tom, ze nekoho kousne konkretni zralok. V obou pripadech jsou to
extrapolace z dat o jinych exemplarich, jenze u zraloku jsou mene
osemetne nez u jadernych elektraren.

MK> Linux je ted. Ocente ze se z nej muzete ucit, poucit, motivovat.
MK> Ale proc MK> na nej nadavat? Proc odsuzovat stare stavby ve meste?

Protoze nadavat a odsuzovat lze a vsichni to moc dobre umi. :)

PJ> 	Zkuste jako maly neznamy subjekt v dnesni dobe vyrobit spickovy HW a
PJ> zacit k nemu psat patricne softwarove zazemi... nebo jinak - jste firma,
PJ> ktera ma sve spickove (proc ne) softwarove oddeleni a je na trhu nekolik
PJ> let davno zapsana. A nyni chce portovat sve produkty na Linux -
PJ> podivejte se jake je ji poskytnuto zazemi - neni tu neco spatne?
PJ> (Mysleno v porovnani s jinymi OS a treba i HW platformami)

Mozna je v tomto pripade dulezite, kolik toho "zazemi" je potreba.
To, ze mam k dispozici 200 GB multimedialni dokumentace je fajn, ale
pokud je k tomu alternativa, ze vsechno, co potrebuji vedet, abych
mohl napsat svuj program pro danou platformu, se vejde na 1 stranku A4,
pak bych spis bral to druhe.

MK> Jinymi slovy - nadavas pekne, ale chybi to logicky dotahnout. Stavis se do
MK> pozice, kterou zesmesnovali uz stari Rimani - ze pry nova mladez stoji
MK> zaprd a svet se zhrouti :-)

A taky ze se pouhych cca 1000 let po zalozeni Rima svet zhroutil (pad
Zapadorimske rise urcite takovy dojem na mnoho jeho soucasniku udelal).


--Pavel Kankovsky aka Peak  [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."