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

[Milan Kerslager]

On Thu, 11 Oct 2001, Ing. Pavel PaJaSoft Janousek wrote:

> > udelali za Vas to, co byste jako odpovedny jaderny prekladator mel udelat
> > taky, jenze se nelogicky vytahujete tim, ze na to kaslete).
>
> Milane, stejne dobre jako ja vite, ze je treba sledovat ceho se opravy
> tykaji, co se tim zlepsi (resp. jaky je zamer), pominu-li tragicky obsah
> dokumentace ke kernelu, informaci nikdy moc neni, ale pokud se v jadre
> objevi zavaznejsi chyba v jakemkoli subsystemu (ano, uznavam, ze

Vazeny kolego, pokud se otirate o lidi kvuli prekladu vlastniho jadra a
pak argumentujete radou 2.2.x, pak jste JISTE necetl muj mail. Rada 2.2.x
je dnes stara bez 3 mesicu 3 roky. NENI MOZNE argumentovat stabilitou
takoveho jadra a srovnavat ji se soucasnou radou 2.4.x (tenkrat stala rada
2.2.x taky za prd, soucasna za tu dobu bude take kvalitni).

Soucasna jadra 2.4.x, ktera pochazi od Linuse (ok, bez 2 poslednich, kde
je jiny VM) MAJI problemy se stabilitou a vykonem, zejmena pri vyssi
zatezi. Bez zaplat si je na stroj da pouze blazen a doporucovat to nekomu
je krajne *nevhodne* a *neprofesionalni*, zejmena pokud se opakovane
ohanite "zamernou seleci" a "povysenim kvality", protoze to je BLBOST
(kterou ostatne vzapeti uznavate). Tomu rikate LOGIKA? Kdyz VIM, ze je
PROBLEM, tak ho bud RESIM nebo NEMOHU prohlasit, ze jsem ho vyresil. Jen
jste pred nim zavrel oci a doufate, ze nebude pruser (a jeste se kasate,
ze si setrite cas).

Chci videt cisla o zvyseni vykonu vlastnich jader a chci videt argumenty,
ze pouzite "optimalizace a selece" zvysi stabilitu. V opacnem pripade je
to jen sarlatanstvi a mazani medu kolem huby (novackum samozrejme) a prani
je otcem tvrzeni.

Ok, pokud budu predpokladat (i kdyz to z predchozich mailu jasne
nevyplyva), ze jste tim chtel rict, ze zustavate u jader 2.2.x, prekladate
si je a mate je lepsi, nez distributori, pak se PROSIM podivejte do
Alanovych oprav a na verzi jadra kterou distributori maji. OPET dospejeme
k poznani, ze ve vanilla jadru se chyby najdou (viz dale).

> Sam vis, ze Linusovo a Alanovo kernel-ac se podstatne lisi a ja se
> domnivam, ze konkretne Alanovo se daleko vice priblizuje tomu, ze
> pouziva RH jako dvorni...

Alan NENI dvorni ... Zkus mu to napsat a slusne Te posle nekam. Je
naprosto nezavisly a na vyvoji balicku s jadry se NEPODILI. Pokud tedy
nepocitam jeho nekolikaslovne komentare, ktere jsem uz zminoval a ktere
ale chodi i do l-k, tak je tohle oskliva pomluva a nepripustny argument.

> Jak jsi k cisle 1000 dosel? Opacim podobne zcestnym argumentem - kolik
> lidi otestuje kernel-2.2.19*.rpm z updates?

RH maji Beta team, kteremu se aktualizace nabizeji. Ma kolem 150 clenu,
kteri jsou aktivni. Testovanim se zabyvaji interni vyvojari, v RH jsou k
dispozici testovaci stroje s ruznym HW, na kterych se poctive dela QA.
Samotne QA je vazane na pruchod mnoha testovacimi kroky vcetne zatezovych
a stress testu. Normalni jadra proste neprojdou (zatim, az bude rada 2.4.x
stara rok nebo vice, bude to jiste a stejne jako u 2.2.x tato debata
ztrati smysl). Cislo 1000 jsem si vymyslel jako priklad, proces QA jsem
zde jiz nekolikrat prezentoval.

> ??? Neni __duvod__, zaznamenavam (pokud nejsi slepy, musis taky) cim
> dal vetsi vlny kritiky (nepopiram, ze jsem na druhe strane barikady nez
> Ty), tudiz neni neco shnileho ve state Danskem?

Ne, shnile je uvazovani a naivni predstavy kritiku, kteri navic nenabizeji
lepsi variantu. Argumenty jsem zde uz nekolikrat predkladal.

> Dotaz uplne mimo, zaznamenal jsem celkem 3 oznaceni, vis neco o tom jak
> vznikly?:
> 1. Oficialni Linus kernel - celkem jasny termin
> 2. Linus tallbar - pravdepodobne odvozenina od 'oficialnich' buildu
> Mozily?
> 3. Vanilla jadro - slysel jsem nekolikrat, vubec nevim co to znamena?

Vsechny oznacuji totez. Jsou to referencni jadra od Linuse, ktery ma na
starosti smerovani vyvoje a strategicka rozhodnuti. Jeho ukolem NENI
vydavat jadra, ktera vyhovuji distributorum a distributori to ani
nechteji. Ukol kazdeho je uplne jiny (on udrzet nepretrzity vyvoj a ti
druzi vyladit distribuci, ktera vyjde 2x rocne).

Vanilla je slangove 'zaklad'. I z prekladu vyplyva, ze na ten zaklad je
povoleno vystavet dum. Tarball je zatarovany strom (tj. tarova koule),
cili to, co si fyzicky jako soubor stahujeme (tj. Linusuv tarball obsahuje
zatarovany vanilla strom jadra).

> > 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
>
> Vsadit se muzes, sazku beru, rekni mi zavazny bug na 2.2.19 od Linuse,
> ktery znehodnocuje mnou vyrobene kernely, ktere v ostrem provozu
> provozuji nekolik mesicu na (skutecne!) nekolika desitkach stroji ruzne
> po republice - od obstaroznich i286SX az po Pentium III - Katmai, v
> mnoha HW konfiguracich?

http://lwn.net/2001/0913/a/ac-2.2.20-pre10.php3

Muzes se podivat a svuj si najit. Mozna nebude zavazny (tj. mas sice
"lepsi" jadro, ale s chybou), ale jak jsem uz rikal - argumentace pomoci
2.2.19 je zcestna, protoze:

a) distributori maji (temer) to same, takze vlastnim prekladem
   neziskam vubec nic (krome toho, ze oni na rozdil od Tebe pouziji
   nektere Alanovy overene opravy), spise ziskam to, ze vec X a Y
   nebude fungovat a budu prekladat znova.
b) 2.2.19 je uz temer 3 roky stabilizovana, ma ve vanilla stavu slusnou
   hodnotu a neda se pouzit jako argument na soucasne 2.4.x jadra,
   protoze tem je teprve 9 mesicu.

> Ano, kvalitni prace byla a je vzdy tezka (v budoucnu to nebude lepsi i
> kdyz kdo vi, az komputery budou vyvijet zpusobem Alfa/Beta rezu, ktery
> se nyni pouziva na 'simulaci' inteligence ve hrach, treba to bude jine).

Jasne, do verejnosti se nedostanou "tzv. zmetky 2.4.x kde x < 10" a az je
nekdo (kdo asi?) otestuje, tak nam je Linus po 5 letech uvolni a my si
budem uzivat absolutniho klidu.

NIKDO NIKOHO nenuti pouzivat jadra 2.4.x, ktera jsou sice v tzv. stabilni
rade, ale evidentne nejsou jeste stabilizovana. Vzdycky to tak bylo i v
minulosti a pokud nekdo chce nadavat, mel by zustat u rady 2.2.x nebo
misto nadavani prispet ke stabilizaci rady 2.4.x.

Nazyvej si to jak chces, ale stabilni jadro (stejne jako v minulosti) lze
ziskat POUZE iteraci, ktera se bude k tomuto stavu priblizovat (soucasna
stabilni rada) a NESTANE se tak bez masivniho testovani (tj. bez postupu,
ktery prave absolvujeme a ktery nekteri chytraci tak pomlouvaji). NELZE to
preskocit a vsichni VEDI, jaka je situace (pokud tedy chteji a nesnazi se
sami sobe namluvit, ze 2.4.jakekolivnizkecislo je finalni produkt a na
zakleade teto chybne konstrukce vyplodit tunu nadavek).

Stabilni rada se tak oznacuje proto, ze v ni NEPROBIHA vyvoj a jejim
ukolem je STABILIZACE jako PROCES a ne jako vec, ktera nam za tyden spadne
do klina. Pokud Linus vymeni ve stabilni rade VM, mel pro to asi zavazny
duvod (treba uzbnal, ze soucasny kod se stabilizovat neda) a neodporuje to
terminu stabilni rada, protoze *opakuji* - jeji vyznam je v tom, ze
*probiha* stabilizace a ne ze jadro 2.4.0, 2.4.1 nebo 2.4.9 ma byt finalni
produkt.

> > Principem kolektivniho vyvoje GPL programu by melo byt vyuzivani cizi
> > prace a pridavani vlastni pridane hodnoty. Vymyslet kolo je (bohuzel)
> > _dost_ neproduktivni.
>
> A neni nahodou onim kolem i patche na 'neproduktivni' jadra vendoru?

Ehm. Ty patche jsou z velke casti obsazene v novejsich jadrech od Linuse.
Je lhostejne, zda si je vendor pujcil od ciziho nebo je sam vyrobi, zasle
do konference a pred tim, nez se dostala do mainstreamu, tak s nimi
problem resi. Znovu opakuji - Linus udrzuje trvaly vyvoj, vendor vyda 2x
rocne produkt, ktery *musi* mit za sebou pul roku ladeni a priprav, jinak
je to k nicemu (a nemusel to delat). Proto vendor vydava ponekud starsi
jadro, ktere obsahuje opravy, ktere v novejsich jadrech uz obvykle jsou,
ale novejsi cela jadra bud vubec nebo zatim nestihla projit QA (tj.
Quality Approval, tj. testovanim). Dolezite je, aby se backportovani oprav
nestalo modlou (tj. aby distributor nevyrabel jadro, ktere ma zaklad rok
stary a k tomu milion zaplat - musi udrzet rozumny pomer, jinak se vazba
na aktualni stav ztrati a zaplatovani nebude mit pozitivni efekt na
samotny vyvoj novejsich verzi).

To, co tady predkladas za argumenty je demagogie, ktera s logikou a
logicky spravnymi argumenty ma velmi malo spolecneho (ze by moda?). Je
lepsi zkusit driv myslet, nez neco placnout.

> > PS: Prosim, aby reakce neobsahovaly logicke rozpory ;-)
>
> 	Snazim se o to celou dobu, urcite rozpory (chapu, ze posunem doby)
> zaznamenavam u Tvych reakci, na patricnych mistech se o nich zminuji -
> muzes toliko rici o mem postoji?

Ano, pokud nejaky clovek X utrati radove stovky clovekohodin na ladeni a
testovani, pak ten, ktery jeho praci opovrhne, spichne si za pul hodiny
svuj vlastni produkt, ktery ani odpovedne neotestuje a pak to predklada
jako svoji prednost, je to *dost* podezdrele.

Spravnejsi postup by byl provest selekci na selekci, tj. vyuzit prace
vsech, kteri ji uz do dila vlozili (jenze to je moc prace, ze jo). Jinak
je GPL k nicemu (ona je tu prave proto, abychom mohli cizi praci vyuzivat
a pridavat vlastni hodnotu) a vysledek vlastni prace je jeste horsi (i
kdyz se honosne oznacuje).

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