Dlouhy Povzdech: Kde skonci vyvoj Jadra? (bylo: Re: Pozor naMandra

[Tomas Valousek]

On Tue, 23 Oct 2001, Oto Buchta wrote:
> Dne po 22. říjen 2001 19:17 Tomas Valousek napsal(a):
> > On Mon, 22 Oct 2001, Oto Buchta wrote:
> > > Dne po 22. říjen 2001 15:41 Milan Kerslager napsal(a):
> > > > Linus nema nad vyvojari zadnou moc ani kontrolu, to je zasadni problem.
> > > Sorry, fakt se nemuzu udrzet. Milane. Tak Linus nema kontrolu? A KDO
> > > DOPRKENYVOHRADY STRKA PATCHE DO JADRA? Panbuh?
> > > On ma prave ABSOLUTNI KONTROLU A MOC. ON je ten sef, ktery MUSI O VSEM
> > > VEDET a navic to MUSI DOSTAVAT V PREDZVYKANE PODOBE nekolikaradkovych
> > > patchu!!!
> > A z toho jako podle vas vypliva, ze je ovlada a ma nad nimi kontrolu??????
> > Kazdy vyvojar si snad muze a dela co chce.
> Ano. Dela. Ale to muze i programator ve firme. Pak je s nim ale stejne 
> zameteno jako s clovekem, ktery  pise kod, ktery neodpovida Linusovu 
> standardu. Clovek je vzhozen z prace, kod neni obsazen v oficialni distribuci.
> Je v tom takovy rozdil?
V tom neni rozdil. Ale poslednim "zamestnanim", kde jsem se nechal ovladat 
byla SPSSE. Ted kdyz me nekdo nebo neco na****, tak se na nej taky muzu 
s klidem ...... Ekonomicke a jine dusledky je samozrejmne vec jina. 
A vy jste to udelal stejne. Posilal jste bugreporty, opravil driver pro 
MPU, Linus vase patche neaxeptoval, nastval vas, tak jste se na nej taky 
vykaslal.

> Pak jsou lide, kteri si mohou ve sve praci delat co chteji, diktovat 
> generalnim reditelum velkych firem, proste jsou nenahraditelni nebo tezko 
> nahraditelni. Typicke priklady - jadro a AA (kolikrat ho Linus napominal 
> kvuli cistote kodu?) oproti jednomu nejmenovanemu cloveku z PVT.net .
> 
> > > > Jakekoliv rozhodnuti musi podlehat tomuto kriteriu a prostemu faktu, ze
> > > > team lidi, kteri to delaji je promenlivy. Dale nemuze nikomu zadat
> > > > zadne ukoly a tim mene dlouhodobe. Jeho osobni zdroje jsou omezene a
> > > > pozadavek
> > >
> > > Jiste ze muze. A dela to. Distribuuje bug-reporty, ktere nepatri jemu. To
> > > JE ukolovani, at tomu veris nebo ne. Bugreport od nej je neco jiheo nez
> > > bug-report od strejdy Vani z Horni Dolni.
> >
> > Ale kazdy se muze svobodne rozhodnout, jestli neco bude nebo nebude delat
> > a jak to bude delat.
> 
> Ano. Muze. Ale neni o jeho svobode, zda se jeho patch dostane do jadra. A 
Protoze to neni vase. Je to Linusovo.

> > > > treba na komplexni regresni testy (jinak ze zaplatu nepusti) jsou
> > > > nerealne (to by dnes neproslo vubec nic - pro kontrolu jsou k dispozici
> > > > [zatim] JINE mechanismy).
> > >
> > > Ano. A jednim s mechanismu je STABILIZACE JADRA "stabilni" rady. Kdyz
> > > nekdo tento mechanismus kritizuje, ty ho hned odpalkujes s tim, ze to tak
> > > je a bude a basta.
> >
> > Minuly tyden jsem si stezoval p. Kerslagerovi, ze se mi zda byt manual na
> > hdparm dost neaktualni. Ocekaval jsem, ze mi rekne neco ve smyslu: "Mas
> > pravdu, stoji za prd." On sedl k pocitaci napsal:
> > cp /usr/share/man/man8/hdparm.8.gz ./
> > gunzip hdparm.8.gz
> > vi hdparm.8
> > Rekl: "Nejlepsi reseni je to upravit a poslat vedoucimu projektu."
> > A ma pravdu.
> > Jak jste prispel ke stabilizaci jadra?
> 
> Ke stabilizaci jadra 2.4 ani 2.2 jsem neprispel nijak. To priznavam. 
> Na druhou stranu jsem posilal celkem bugreporty na jadra 2.0 a 2.1. Pak jsem 
> se rozhodl prispet svoji troskou do mlyna. Tak jsem do jadra (2.1 hodne 
> vysoke verze) prispel patchem na rozchozeni MPU401 pro ALS100 (chybela 
> inicializace, tak jsem si lousknul dosovsky inicializator). NIKDY se tento 
> patch do jadra nedostal! Duvod? Patch neprosel sitem. 
> Trvalo mi to celkem priblizne100 clovekohodin. Jen tak vyhozeno luftem. No, 
> jen tak ne, aspon jsem si rozchodil zvukovku. 
To zalezi jak se na to divate. Pro me by bylo dulezitejsi, ze jsem si 
rozchodil zvukovku. Jestli patch Linus axeptuje je jeho vec.

> > Navrhnete prosim, jak by mel stress-test podle vas vypadat?
> Stress test na co? Treba na zvukovku? Ale to je preci strasne jednoduche.
> Jsou celkem tri typy moznych testu pro ovladace: Na jednu stranu povesite 
> generator "zateze", na druhou stranu bud:
> 1) primo zarizeni - test v praxi nejlepsi
> 2) emulator jeho chovani - emulator je napsany tak, aby presne odpovidal na 
> funkci podle specifikace. Toto je nejlepsi reseni, ale opravdu se tezko 
> programuje.
> 3) ctecku signalu - rekl bych ze dostatecna pro vetsinu veci.
> Pripravite sadu ctveric (data zaslana na vstup ze strany kernelu, data 
> prectena ze strany zarizeni, data odeslana zarizenim, data prijata ze strany 
> kernelu).
> Potom iterujete pres seznam ctveric a pokud nekde dojde k odchylce, mate 
> jistotu, ze doslo k chybe.
> Pro slozitejsi testy lze ctverici rozsirit o priblizne casy, obsah stacku, 
> zatizeni,...
Omlouvam se, mel jsem polozit otazku:
"Jak byste si predstavoval realny stress-test jadra, ktery by otestoval 
vsechny casti jadra, vsechny ovladace atd."
Ja nepochybuji o tom, ze je mozne vyrobit univerzalni stress-test na 
kernel. Ale pochybuji o tom, ze je to v realnych moznostech Linuse.
Nehlede na to, ze QA delaji distributori a delaji to podle meho nazoru 
dobre. (jediny muj VAZNY problem, ktrery vedl k NESTABILITE az temer k 
NEFUNKCNOSTI jadra 2.4 byly hw problemy s bridgi 686(A,B). VM je (byla) 
zavazna chyba, ale nevedla k nestabilite nebo padum systemu a s jinymi 
chybami sem se diky bohu (Linusovi ;-) nesetkal.)

> > Ja pouzivam na programovani v Perlu vi. Kdyz mi reknete, ze by bylo lepsi
> > pouzivat XY, tak se zamyslim, jake ma vyhody vase reseni a rozhodnu se,
> > zda budu vami doporuceny vyvojovy prostredek pouzivat. Vam ale do meho
> > rozhodnuti VUBEC NIC NENI, zrovna tak vam neni nic do toho jestli, jestli
> > Linus pouziva mailbox nebo cvs, jestli pouziva C nebo Basic. Je
> > to jeho projekt a vy mu muzete pomoct. Nemuzete ho ale do niceho nutit.
> 
> Ja jsem ale uzivatelem produktu! A co vic, rad bych byl i vyvojarem, ale 
> proste mi to neni souzeno. Rad bych pouzival a vyvijel stabilni system.
> Ale kdyz jsme u vaseho prikladu. Predstavte si, ze po vas budu chtit jako 
> uzivatel zmenu, ktera by sla v systemu, ktery pouzivam ja (rekneme nejaky 
> case nastroj), udelat za deset minut. A vy si za to nauctujete 50 
> clovekohodin! Proc? Pouzivate Perl a vi. jak jste ale spravne rekl, mne jako 
> uzivatele to nema zajimat.
V jedne z firem, v ktere spravuji sit se pouzivaly Money2000. Zjistilo se, 
ze stoji za prd, tak jdou do WC a misto nich se bude pouzivat neco jineho. 
A ted mne dokonce napada, ze to je uplne idealni priklad myslenky, kterou 
jsem vam sdeloval v minulem mailu.
Money2000-techsupport k nicemu, program k nicemu, architektura systemu k 
nicemu. Na moje maily temer nereaguji, kdyz uz reaguji, tak maximalne 
nejaka sekretarka, ktera mi sdeli, ze mnou pouzivana featura  bude 
podporovana ve verzi Duel, ktera mela byt pred 3/4 rokem, ted jsou sotva 
u nejake beta verze => Cigler u nas ve firme skoncil
Basmon(sw pro ovladani kotelny)-napsal jsem jim, ze bych si potreboval, 
aby aplikace byla Client/Server. Oni me pozadavky axeptovali a zahajili 
vyvoj. Proto ho pouzivame.

Na Linux si tento priklad pretranformujte sam(i).

> Navic mam jeste nekolik dalsich moznosti co s tim.
> 1) forknout Linux
> 2) Nepouzivat Linux.
> 3)Prejet Linuse tirakem.
> 
> A rekl bych, ze dokud se nestane 1) nebo 3), hodne lidi bude delat 2). A to 
> je podle mne skoda :-(
To mate pravdu, je to skoda, ale pokud vas to HODNE stve, tak muzete 
zvolit variantu 1).

-- 
	Tomas -VALY- Valousek
	web design, internet projects, linux etc..
email: tomas na valousek.cz
www:   http://www.spsselib.hiedu.cz/~xvalous 	(~=ALT+126)