Dlouhy Povzdech: Kde skonci vyvoj Jadra? (bylo: Re: Pozor na Mandrake 8.1!)

Milan Kerslager milan.kerslager na spsselib.hiedu.cz
Čtvrtek Říjen 11 00:46:02 CEST 2001


On Wed, 10 Oct 2001, Ing. Pavel PaJaSoft Janousek wrote:

> 	Na moji vytku tusim na Linuxworldu pred cca 2 mesicama, kdy nekdo
> (Milan?) tvrdil, ze RH jadra jsou testovana na obrovskem mnozstvi
> hardwarovych kombinaci a tudiz jsou lepsi nez Linusova jsem namital, ze
> Linusova na rozdil od RH jadra otestuje daleko vice lidi a tudiz i
> daleko vetsi mnozstvi kombinaci ruznych masin (po strance HW) a domnivam

Jenze pokud chcete "lepsi" jadro, nez je v distribuci, musite vzit
posledni od Linuse a v tom bude nejmene X chyb. Vetsina v te chvili uz
zminena v l-k. Mate naladu ty chyby zalepovat a cekat, az clovek Y.Z
napisena treti pokus patch, ktery opravdu funguje a neporusi funkcnost
veci A.B?

Pokud byste chtel pouzit "lepsi" jadro od Linuse, ale starsi (nebo temer
tak stejne stare, jako ma distributor), tak byste mel jadro, ktere ma 50x
tolik znamych chyb, nez posledni vydane. Takze tudy cesta take nevede.

Proto je lepsi pouzit distributorovo jadro, ktere je drobet starsi (treba
3 mesice) a ma v sobe 150+ zaplat, ktere sice jsou obvykle v Linusovych
novejsich (nebo u Alana), ale na rozdil od posledniho Linusova jadra
nemaji aplikovany zaplaty, ktere pri testovani pusobily potize (tj.
udelali za Vas to, co byste jako odpovedny jaderny prekladator mel udelat
taky, jenze se nelogicky vytahujete tim, ze na to kaslete).

Nebo mi chcete namluvit, ze Linus pred vydanim testuje jadro vic, nez
nejaky distributor? Nebo (zcela nelogicky) mi chcete vysvetlit, ze
Linusovo jadro otestuje 1000 lidi v konferenci a Linus na tomto zaklade
vyda verzi X+1, ktera nebude obsahovat ani jedinou chybu? [to by uz jadro
2.4.1 muselo byt uplne pefektni].

Jinymi slovy - zde (nejen Vase) argumenty kulhaji nejmene na jednu nohu.

Jak jsem zde jiz nekolikrat vysvetloval - model vyvoje jadra u Linuse je
jiny, nez model vyvoje distribuce. Oba maji sve opodstatneni a neni duvod
je menit. Preklad clanku o Bazaru a Katedrale je na serveru Zvonu:

http://www.zvon.org/ZvonHTML/Zvon/zvonTranslations_cs.html

Az budeme mit jadro 2.4 tak rok nebo skoro dva, bude mozne pokladat
vanilla jadra za stabilni (vice mene, zname zaplaty budou u Alana). Dnes
to mozne (zatim) neni. Je to dusledek modelu vyvoje, ktery se pouziva a
ktery je dostatecne dobry a ktery jednoznacne vede ke stabilizaci kodu.

Prekladat vlastni vailla jadro je mozna hrdinstvi, ale ve skutecnosti
praci neusetri. Na jakekoliv (vanilla) jadro lze snadno najit nekolik
bugreportu a vsadim se, ze nejmene jeden bude zavazny. Clovek, ktery se u
distributora stara o balicek s jadrem tohle vsechno sleduje, testuje a
dela za nas praci, kterou bysme se vsichni jen zbytecne zdrzovali.

Kdo chce, muze s jadry experimentovat, ale je potreba vedet o moznych
nasledcich, nezatajovat je a neuvadet logicky chybne argumenty (viz vyse).
Lze si tim snadno overit, ze vydat neco, co je alespon dobre, je *velmi*
tezke.

> se, ze lide spise jednoduseji najdou chybu v cistem jadre, nez v 1000x
> prepatchnutem, kdy jiz vlastne neni jasne, v cem je presne problem a
> zda-li Cox/Linus vubec akceptuji patch, protoze oni to maji v poradku,
> ale problem je v patchi A, ktery jadro upravil do stavu B a patch C na
> stavu B leti na drzku, protoze v tom skutecne Linus nema prsty...

Ano, Alan casto na dotazy o zaplate na vec X.Y odpovida strucne: Yes, it
breaks A.B. Na poznamku, ze jeho zaplata v -ac baliku rozbila naopak vec
C.D odpovi: Interesting. Chyby se opravi - jenze jako na potvoru opravene
chyby zvyrazni dalsi nedostaky....

...je to nekonecny vyvoj. V casech jader 2.2.x nebo 2.0.x jsme nemeli
tolik featur, ale chyb bylo porad stejne. Zive si vzpominam, jak jsem
zaplatoval jadra. Dnes (diky peclivejsimu QA u distributoru) to uz delat
nemusim, nebo "jen" na jejich vysledek aplikuju pozadovane rozsireni
(treba na LVM), coz je spolehlivejsi, nez zaciat od nuly na Linusove jadru
(Linus vyviji, distributori pouzivaji a jeden bez druheho byt nemuze, oba
dva tabory to vedi a take toho oba vyuzivaji).

Principem kolektivniho vyvoje GPL programu by melo byt vyuzivani cizi
prace a pridavani vlastni pridane hodnoty. Vymyslet kolo je (bohuzel)
_dost_ neproduktivni.

PS: Prosim, aby reakce neobsahovaly logicke rozpory ;-)

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




Další informace o konferenci Linux