optimizace jadra

[Ing. Pavel PaJaSoft Janousek]

Milan Kerslager wrote:
> dostatecny duvod a vedomosti) alespon 2 nebo dokonce 3 roky. Ani pred
> tim jsem to nedoporucoval a myslim, ze ani nikdo z "rozumnych".

	:-) a ten 'rozumny' je kdo? Pokud bychom takto konzervativne 
postupovali, tak nemame a) vyvojovou radu, b) vubec Linux, protoze prece 
nebylo rozumne strkat nos do UNIXovych obchodu za tezke prachy... toto 
neni argumentace, kterou prijimam.

	Jak uz psal p. Ronai, clovek je tvor zkoumajici, pokud chci produkcni 
system nebudu si hrat (a treba prave proto nenainstaluju ten sqely RH 
8.0), pokud chci experimentovat, chci zkouset, neco se naucit, neni nic 
spatneho na tom, kdyz mne obcas nekdo popostrci v oblastech, o kterych 
100% nevim - a uprimne, kdo dneska vi o celem kernelu tolik, aby mohl 
'radit'? Ani 'spravci' rad ne, tezko budu chtit napr. po Marcelovi 
vysvetlit, proc v IDE nastavuje Hendrix na portu X ten a ten bit.

	Ale utnout snahu cloveka o zkoumani hned v uvodu s tim, ze to nema 
delat a proc to vlastne chce, je na nic.

	Samozrejme neco jineho je pokud ma clovek problem a hodla ho resit 
spatnou cestou, to je na miste ho co nejdrive utnout, nejlepe s odkazem 
proc nebo kratkem vysvetleni.

> Mnozstvi prace, ktere vlozi do jadra distributor je nepomerne vetsi, nez
> akce Ferdy Brabence, ktery vezme tarball a napise make. Nemluvim uz o QA
> (tj. o vysledne kvalite a jeji kontrole).

	No tim QA se ohanite docela dlouho, jak je tedy mozne po tak masivnim 
QA, ze kdyz vezmu source kernel-sourceXY.rpm, ktere produkuje RedHat, 
tak pri urcitych kombinacich voleb jadro neni schopne ani korektne 
prelozit a slinkovat? O dalsich labustkach jako zkompilovane jadro, ale 
zatuhnuti hned po Booting Linux... apod. bych mohl vypravet jeste obsirneji.

	Nerikam, ze tarball je po teto strance lepsi ci horsi, oboji (vyse 
zminene) jsem za dobu sve pruduktivni prace s Linuxem vyprodukoval i 
zde. Linus ma zrejme sve duvody, proc nektere veci nezacleni do 
tarballu, stejne jako maji komercni firmy duvod trochu riskovat aby 
vyrobili neco, co se odlisuje od konkurence (a zajimave, ze do tohoto 
postupu se rovnez navazite). Nesouhlasim v souvislosti s jadrem (protoze 
mam velmi bohate osobni zkusenosti) o QA a 'lepsim' jadre od komercnich 
firem, ktere tu jiz nekolik let sirite s odkazem na nejake clovekoroky 
prace, kterou proste nevidim a ani neverim, ze je to mozno takto stavet.

BTW Vzdy mluvim o situaci, kdy ta sama konfigurace s tarball jadrem 
slape na poprve jak hodinky => faktickou chybu ci feature hardware si 
skrtnete hned, maximalne to muzete pricist 'nevhodnemu' ci radne 
neotestovanemu patchu, ktery tam pridal distributor - to je rovnez o QA, 
vidte?

> Tohle je dost nefer tvrzeni. Jednak v 6.2 nebude existovat SW vybaveni,
> ktere je defaultne v 8.0. Jednak mnozstvi bezpecnostnich problemu, ktere
> si vytvorite bude nezanedbatelne a take budete muset ozelet dalsi veci
> (napr. velke soubory, rychle ATA, UDMA, atd). Pokud porovnam mnozstvi
> prace, kterou budete muset vynalozit s cenou noveho HW, budete to tezko
> pred sefem obhajovat.

	S timto souhlasim, ale jen castecne, jak uz nekdo psal - mame levnou 
hrubou CPU silu, drahou silu programatorskou, dle toho vypada software, 
situace v opacnou zrejme jiz nikdy nenastane, takze se musime smirit s 
tim, ze ty same ukony budou 'zrat' cim dal vice vykonu CPU. Souhlasim s 
tim, ze vyssi funkcionalita zpravidla zmename vyssi narocnost. Proto 
jsem nikdy nemel rad porovnani MySQL vs. PostgreSQL jen z hlediska 
rychlosti jednoho stupidniho selectu, ale nezastavam nazor, ze zrovna u 
jadra jako takoveho musi urcite veci trvat cim dal dele, ackoli se 
takzvane horlive pracuje na optimalizaci... A v modelu Linuxu a 
pribuznych OS nemam pocit, ze bezpecnost jadra je v nejake relaci s 
vykonem ci narocnosti; aplikacni, relacni a jine vstvy nechavam stranou, 
protoze ty nejsou otazkou jadra...

> Jenze dnes si nehrajeme na vojaky, ale (obvykle) se snazime udrzet v
> chodu (nebo vyvinout) radove slozitejsi systemy. A jadro je prostredek a
> ne smysl prace admina.

	A jak vite, ze ten, co chtel nakouknout pod poklicku (a treba casem 
prijit se zajimavymi zjistenimi a navrhy, stejne jako to udelali i jini, 
treba v teto konferenci) je prave v pozici admina? Vase reakce vsak byla 
vzdy naprosto uniformni.

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Sokolova 67, 619 00 Brno
E-mail: mailto:Janousek na FoNet.Cz             Tel.: +420  5  4324 4749
SMS:    mailto:P.Janousek na SMS.Paegas.Cz      Fax.: +420  5  4324 4751
WWW:    http://WWW.FoNet.Cz/               E-mail: mailto:Info na FoNet.Cz
-----------------------------------------------------------------------