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

Pavel Kankovsky peak na argo.troja.mff.cuni.cz
Sobota Říjen 13 21:36:45 CEST 2001


On Wed, 10 Oct 2001, Michal Ludvig wrote:

> Pak taky jsem v drtive vetsine pripadu schopen vyrobit jadro mnohem
> mensi nez to, ktere nabizi distribuce. Navic si do nej natvrdo
> zakompiluju ovladace vseho potrebneho a nemusim se zabyvat
> initramdiskama, abych vubec byl schopen nabootovat.

Take jsem si myslel, ze je to dobry napad...nez jsem byl postaven pred
problem, ze potrebuju to same jadro (s urcitou sadou specialnich patchu)
nainstalovat na nekolik pocitacu s dost ruznou hw konfiguraci, nez se mi
nekolikrat stalo, ze treba bylo nutno vymenit v pocitaci sitovou kartu za
uplne jiny typ, a nez se mi stalo, ze jsem na nejakem pocitaci potreboval
nejakou dalsi funkcnost jadra, aniz by byla vhodna chvile pro rekompilaci
a reboot. Pak jsem zacal ocenovat zpusob, jakym se delaji jadra
v distribucich -- tj. maximalne univerzalne.

Optimalizace je fajn, ale jen kdyz opravdu neco usetri, pricemz ztraty
na case a dusevnim zdravi lidi kolem toho se pocitaji mezi naklady.

> Rozhodne bych kompilaci vlastniho jadra doporucil vsem pokrocilejsim 
> zacatecnikum, protoze tim ziskaji vetsi prehled o tom, [...]

Prehled vetsinou neziskaji (stejne aspon polovine veci nebudou rozumet a
druha polovina je prosty seznam podporovanych zarizeni -- kteremu obcas
take nebudou rozumet, protoze nektera zarizeni maji pet ruznych jmen),
ale odstrani se zrno od plev a zustanou jen ti nejdrsnejsi. :)


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

> takto me to stalo pulden prace se zaverem, ze chyba neni u mne, ani u
> Linusova 2.4.4., ale u kernel-source-XYZ.rpm (IMHO to bylo 2.4.2-patch
> milion) -

Hmm...a fungovalo to ve vanilla 2.4.2? Jinak je to porovnani jablek
s hruskami.

> chtel bych videt jak byste s vendor predpripravenym jadrem (tedy
> vyuzivajicim kernel-XYZ.rpm) rozchodil dohromady ISA a PCI sitovky
> apod...

Clovek, co ma potrebu zprovoznit v jednom pocitaci ISA a PCI sitovky,
je podle mne zraly na navstevu u doc. Chocholouska. :)

> A mame zaacrovany kruh - pokud se jadro nebude dostatecne nasazovat,
> nevyladi se, pokud se nevyladi, nebude ochota ho nasazovat.

Jak rika klasik (o race conditions, ale u slozitych systemu to plati
obecne): to nejde odladit, to se proste musi naprogramovat dobre. (*)

> [...] a domnivam se, ze lide spise jednoduseji najdou chybu v cistem
> jadre, nez v 1000x prepatchnutem, [...]

Najit chybu znamena, ze je pozorovano, jak neco funguje (nebo muze
fungovat) spatne. Cili je tento vyrok ekvivalentni tvrzeni, ze
ozaplatovane jadro ma mene zjevnych chyb. :)


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

> Pomilu-li zavazny bezpecnostni problem, ktery se tahne az do (ne
> vcetne) 2.2.19., mate proti starsim jadrum neco?

Bezpecnostni dira velka jako vrata od hangaru, ve kterem na Cape Canaveral
montuji rakety, nestaci?


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

> Zakladni problem vsak vidim v tom, ze neexistuje naprosto zadna HW
> sestava (a zakaznik ji casto chce doporucit, na znacce netrva), kterou
> bych mohl s klidnym svedomim doporucit z fleku. Ani u jednoho x86
> compatidebile HW si nejsem dopredu jisty, ze ho uchodim, mohu prolezt
> desitky HW zamerenych Webu, presto dokud to nemam koupeny (vyjimecne
> dostanu pouze na otestovani) a ten Linux na to nenainstaluju a
> nerozhodim vse potrebne (zejmena aby jadro korektne bez chyb a panicu
> chodilo) - mysleno zejmena HW periferie - nemohu o tom HW rici nic...

Sveho casu byl v Linux Journalu clanek, ve kterem lidi z VA Linuxu (?)
popisovali, jak vyrabeji fungujici sestavy -- napr. musi u kazde nove
serie *tehoz typu* nejake komponenty preventivne otestovat, ze se chova
stejne jako predchozi serie (a ne jinak s tim, ze pripadne rozdily
(ne-li rovnou chyby vznikle pri vyrobe) zamaskuje driver dodavany
vyrobcem komponenty). To asi nebude tak uplne problem na urovni
softwaru...

> Citite ten obrovsky rozdil oproti svetu MS Windows - bere se skoro za
> samozrejmost, ze pokud bych na 'certifikovanem' pocitaci pro MS Windows
> 98 (priklad) MS Windows 98 nenainstaloval, vyreklamuji celkem bez
> problemu...

Docela rad bych chtel zkusit reklamovat to, ze u notebooku, na kterem je
"certified for Windows 95", neslo v ciste instalaci zmineneho "OS" vubec
zprovoznit PCMCIA (s vymluvnymi chybami "Code 2" apod.). Nicmene asi bych
nepochodil: jednak bylo davno po zaruce, jednak bych byl pravdepodobne 
poslan do haje, protoze to funguje nikoli s "MS Windows 95", ale s MS
Windows 95 ve forme (tj. se specialnimi drivery atd.), v jake je to
predinstalovano pri koupi pocitace.

> kdo mi proda v republice takovy pocitac pro Linux?

Dokud nebude dost velka poptavka, tak nikdo. Ale muzete si ho nechat
dovezt ze zahranici (napada mne ten zminovany VA Linux). Nebude to levne,
ale na prislovi, ze "nejsme tak bohati, abychom si kupovali levne veci",
neco je.

> Vendori to ale velice podporovaly (uz chteli mit 2.4.) a misto toho,
> aby bylo jeste rok 2.3.X (X > 200 treba) jsme dostali jako 'darek' 2.4.0
> inu proto, ze od 2.2.0 je to hodne dlouho... - to ma byt argument?

Jsem dost skepticky ohledne toho, ze by se pri pokracovani 2.3 vubec nejak
pokrocilo ve stabilizaci kodu, nebot vyhlaseny "code freeze" se v praxi
moc neuplatnoval. Kdyz uz nic jineho, tak byla verze 2.4.0 vyznamna
psychologicka hranice, ktera urcila bod, od ktereho se smeruje (snad)
k budouci opravdu stabilni verzi.

Mozna, ze by mely byt tri druhy rad verzi (vyvojova, stabilizacni,
stabilni) misto dvou (vyvojova, stabilni...tady spis v uvozovkach).

(BTW: vendori jsou nezivotni? ;> )

> > :-) Mam zacit vypocitavat veci, ktere nejsou/nebyly koser ve vanilla
> > jadrech?
> 
> Oba to vime, odpovezte mi vsak na otazku - jak dlouho se tam udrzely?
> Jak dlouho se tyto 'nekoser' veci drzi ve vendor jadrech?

Spis je otazka, zda mnozina vsech "veci, co nejsou koser" konverguje
k prazdne mnozine a jak rychle. Nebo je mozna na miste spis otazka, proc
tam takove veci vubec byly...mam jiste obavy, ze bazarovy model vyvoje
interpretovany tak, ze "proste neco pustime do sveta a lidi si to sami
odladi" (coz je vlastne rozvinutejsi varianta pristupu "proste neco
pustime do sveta a lidi nam to otestuji" uplatnovana i jinde), je cesta do
pekel (viz tez (*)).


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

> Ale jdi, mas snad v zaklade proti 2.2.5 neco? Ja mam proti 2.4.X (X >=
> 10!!!!) dost vyhrad.

Tak nejak si vzpominam, ze tak zhruba do 2.2.15 tady pomerne dost lidi na
2.2 nadavalo zpusobem, ktery nema daleko do soucasne kritiky rady 2.4.

> Najednou je Alanovo jadro nejlepsi? Nedavno jsi vychvaloval Linusovo
> sito... nevidis si ani na spicku nosu!

Ona je oprava a oprava. Mame opravy, ktere odstranuji chybu, ale nikoli
jejich koreny, a opravy, ktere vec resi takrikajic systemove. Pritom i
prvni druh oprav muze byt uzitecny, protoze je typicky mnohem levnejsi
a rychleji hotovy nez ten druhy.

Linus klade pri prijimani zmen velky odpor, coz na jednu stranu brani
pronikani zmen, ktere by se treba v dlouhodobem horizontu ukazaly byt
danajskym darem, na druhou stranu to muze pusobit potize s vyresenim
jiz existujicich problemu (zvlast takovych, ktere nelze vyresit zmenou
tri radku v jednom souboru, coz jsou pohrichu ty nejbolestnejsi).

(V tomto kontextu mi je naprostou zahadou, jak je mozne, ze se do jadra
dostal tak zmrseny memory management. Tady neci QA selhalo na cele care.)

> Jinymi slovy - protoze beta tymu pri QA testech neprojde vanilla jadro
> Linuse => nase jadro, ktere projde nasimi QA testy je lepsi nez
> oficialni jadro, ktere projde daleko jinymi QA testy... cernobarevnost a
> upeti na jednu firmu jsme tu uz meli...

Tento argument nedava smysl, pokud neni splneno ze "nase" jadro neprojde
nejakymi testy, kterymi vanilla projde, a ze nejake rozumne ohodnoceni
tech testu (resp. jejich selhani) nestanovi, ze nedostatky "naseho"
jadra jsou celkove zavaznejsi nez nedostatky vanilly. Jenze co je to
"rozumne ohodnoceni" -- neni to nahodou skoro totez jako vyber testu,
ktere povazujeme za dulezite? Takze je treba ukazat, proc jsou ty
"daleko jine" QA testy (existuji vubec? kdo je provadi?) lepsi a
verohodnejsi nez "nase" testy.

> Ano mam __SOURCE__ jadra s chybou, muj kernel to chybu neobsahuje,
> protoze danou periferii proste bzImage obsazen nema (ani v modulu!) a na
> me konfiguraci se ani jine cleenupy chybove neprojevuji, asi delam neco
> spatne, ze nemam problem, vid?

Problem distributora je ten, ze si obecne nemuze rict, ze urcita chyba
je irelevantni, protoze problemovy kus kodu ve svem bzImage ani modulu mit
nebude, protoze vyrabi software i pro jine lidi, nez je pan Janousek,
ktery tu blbou cast zrovna nepotrebuje.

> > 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.
> 2.2.19 neni 3 roky (to je vazne dneska ulet, demagog jsi dneska Ty),

2.2.19 je posledni clanek rady 2.2, ktera existuje uz mozna ty tri roky
a jinde padly argumenty, ze 2.2.5 byla ok a ze zmeny provedene v 2.2
v poslednich X casovych jednotkach jsou vesmes spis kosmeticke. Takze
je to samozrejme receno blbe, ale fakt je, ze 2.2.19 stoji na zakladech,
ktere uz par let drzi a nekymaceji se.

> Vis, kvalitu proveruje cas, zajimave, ze u jinych produktu nevadi, ze
> se na novou verzi ceka do doby, kdy bude skutecne pripravena, nemohu za
> to, ze softwarove inzenyrstvi je pro mnohe jen pojem, ktery nekdy
> vzdalene slyseli, stavet takto domy tak...

Mam dojem, ze nekolik milionu obyvatel panelaku v nasem state by
souhlasilo s nazorem, ze "takto" se obcas stavi i domy.

> (Tak mne napada Concordy vyhodime protoze maji 40 let, vid?)

To mozna ne, ale nejspis je vyhodime, protoze je jejich provoz strasne
drahy a lidi dneska zrovna nemaji enormni zajem o leteckou prepravu. ;)

> Ty tvoris novy pohledy na jadra? Je to nekolik let co jsem cetl
> Linusovy definice (a nezaznamenal jsem, ze by svuj postoj vyrazne
> prehodnotil) a s Tvymi se zretelne rozchazi!

Mozna sve nazory explicitne neprehodnotil, ale v praxi to tak vypada. :P


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




Další informace o konferenci Linux