Red Hat Bugzilla: vecirek jen pro zvane?

[Milan Kerslager]

On Wed, 22 Aug 2001, Ing. Pavel PaJaSoft Janousek wrote:

> '-) uvedu konkretni priklad - ve sve dobe (nevim jak dneska) se dala
> zapnout automaticka konverze konce radku (LF/CR+LF) mezi Linuxem a

Tohle je nelogice. Sam priznavas ze jsi to nedotahl do pouzitelneho stavu
(tj. napsat, vyzkouset, zdokumentovat, nechat to prijit konferenci, ...)
tak pros to stavis do svetla, ze za to muze Linus a jeho praktiky?

> > Kazdou vec musi nekdo schvalit. Vyoj nelze delat za pomoci anarchie. To,
>
> 	Naprosty souhlas, ale jak uz tu nekolikrat padlo, proc se konkretne u
> Linuxoveho jadra naprosto ignoruji davno odzkousene, odladene a funkcni
> modely softwaroveho inzenyrstvi? Promin, ale argument, ze ReiserFS dame
> do jadra (sam vis, ze se moc dobre vedelo o problemech) aby tam uz
> konecne nejaky zurnalovaci FS byl neberu... Stejne jako v 2.2.19 mame 2

Linux mel realne problem s tim, ze NIC takoveho ve sve stabilni rade nema.
Kdyby se ReiserFS nepouzil, neexistoval by precendens a tlak na vyvoj
dalsich (vznikl by pocit, ze je na to dost casu - ve vyvojove vetvi
jadra). Jine FS nebyly slouceni schopne - bud proto, ze jejich vyvojari
byli prilis opatrni, nebo to proste nebylo jeste zrale. Naproti tomu
Reiser si vydupal povedomi, ze "mu to funguje", i kdyz realne problemy
byly (to, ze to bylo v jadrech SuSE byl taky argument pro to, ze to je
rozumne odladene).

> drivery na Realtec8139 (sitova karta) - a i ja zaznamenal situaci, ze
> ackoli normalne pouzivam rt8139.o, v jednom specifickem pripade jsem byl
> nucen pouzit (vlastne ve dvou) rt8139too.o, protoze jinak jsem po
> inicializaci driveru prisel o link na HUBu... - dodnes nevim proc, ale
> druhy driver funguje sqele...

Obecne je nekolik moznych duvodu:

a) mainatiner puvodniho driveru je nepruzny a nekdo zacne psat
   svuj vlastni driver. Protoze neni odladeny (vetsinou pro starsi HW
   a pro chyby HW), daji se do jadra oba (protoze stary driver neumi
   novy HW)
b) maintainer se rozhodl, ze ovladac je hrozny a ze ho prepise. Nova verze
   ma stejne problemy jako a), ale stara je uz neopravitelna. Do jadra
   tedy jsou obe (pripad aic7xxx)
c) vyrobce HW napise svuj vlastni ovladac. Je lepsi, ale neodzkouseny,
   je potreba zajistit zpetnou kompatibilitu a zaroven motivovat vyrobce k
   dalsi cinnosti - v jadru budou oba dva (pripad 3Com, a myslim i ten
   Realtek)
d) tvurce driveru nema k dispozici testovaci HW. Stejne chipy se HW lisi.
   Stary driver nektere problemy obchazi, ale kodu uz nikdo nerozumi
   (aic7xxx)

> kvalitni - protoze to a) nekdo neprotlacil (nemel snahu) nebo b) se to
> Coxovi nebo Linusovi (a jinym 'vyse' postavenym) nelibilo...

Treba oduvodnene. Neni jednoduche napsat neco tak, aby to bylo vecne
spravne.

> Dalsi konkretni vec (popisuji jen pripady ktere jsem bedlive sledoval)
> je s lm_sensors, dokud byly jako solo patch, fungovali sqele, po
> zarazeni do jadra naprosto nefunkcni (na chybu jsem bohuzel neprisel,

Pravdepodobne se nekde stala chyba. Mohl byt odstranen nejaky casovy
hazard, takze se ochrani jadro (tj. system prezije), ale ovladac nefunguje
(lepsi reseni, nez se smirit s tim, ze se to "nekdy zasekne").

> Bohuzel ne vzdy mas... - konketni priklad jsem uvedl QoS - ac je to
> reseni ramcove uplne nekde jinde (a zpetne kompatibilni), uvazuje se,
> zda-li bude soucasti 2.6 nebo az pozdejsi a pritom je dneska v
> praktickem nasazeni flexibilnejsi a hlavne funkcnejsi nez soucasny stav
> v jadre, o cistote radeji uz ani nemluvim. Jak psal Standa Meduna, to co
> je v ofic. jadre zkousi radove (i vice radu) vice lidi nez co je nekde
> na Webech v patchech. Jenze jak se muze nova vec vyzkouset, kdyz o ni
> lidi nevi ze ani neco lepsiho existuje? K cemu mam na spoustu options
> experimental status (a nekdy i roky;-)) a spoustu veci, ktere si jiz ani
> experimental status nezaslouzi tam proste neni...

O nekterych vecich se vi, ze treba obsahuji potencialni deadlocky nebo
memory leaky (NTFS). Protoze neni zatim oprava (nebo je prilis nebezpecna
a nevyzkousena), oznaci se to jako experimental. To je ochrana ciloveho
uzivatele. Specialni featury jsou zajimave, ale mohou byt nebezpecne a my
to *musime* vedet.

> Takovy FreeSWAN - Free iplementace IPsec do Linuxu je jiz ve verzi
> 1.9.X, stale o ni jadro nema ani zminku, ac je to v soucasne dobe
> mohutne potreby a pozadavku na VPN site velmi zadana komponenta
> (pouzivaji se misto std. reseni ruzne VTUNy, CIPE apod.)...

Napis patch na dokumentaci a posli ho do l-k. Budes ho muset poslat treba
10x. Pokud to neudelas, nenadavej, protoze co si neudelame sami, to tam
proste *nebude*. Z vnejsiho pohledu spadas do stjne kategorie, na kterou
nadavas (tj. taky nic nedelas a taky za to muzes).

> Promin, Linus je nepochybne VELKY programator, ale osobne neverim, ze
> zna vyznam vsech radku v kernelu, ktere schvalil a pochopil funkci.
> Ostatne, jeho vagni pristup k mnoha vecech i tesne predtim nez zacal
> vubec s Linuxem (obcas problesknou perlicky z 'nataceni'...;-]]) zrovna
> nesvedci o jeho systematicke a ciste praci. Staci se take podivat na
> nektere hodne stare kusy linuxoveho jadra a clovek se nestaci divit... -
> Linus sam je s prominutim casto velky cune, ale vudci ostatnim si hraje

Protoze to jako cune napsal pred 10 lety, neznamena to, ze stejny prasarny
prijme dneska od kohokoliv. Musi tlacit na vyssi uroven kodu, ne dovolit
pokles.

> Promin, ale pokud napisu opravdu funkcni implementaci neceho, pak
> naprosto seru na opravovani nejakeho castecne funkcniho bastlu.
> Konkretne NTFS v jadre je pekny bastl a pokud se nepletu, nekdo vytvoril
> funkcni implementaci, ktera zvlada i NTVS verze 5 (Windows 2000) vcetne
> sifrovani apod...

A jak prokazes, ze tomu rozumis? Nejdriv hackuj, pak si hraj na pisalka,
ktery vysmrkne kdo z rukavu. Hackovani ciziho kodu vede k vyssimu umeni,
prijdes na veci, ktere se jinak nedozvis. Nelze sverit napsani celeho kusu
nekomu, kdo se k tomu nepropracoval. To ovsem neznamena, ze napsany kod
musi byt spatny. Ovsem pokud dotycny neziska ostruhy hackovanim postupne,
musi kvality prokazat pozdeji (tj. pri obhajovani). Nic nejde samo, nikdo
nic nikomu "za nic" neposkytne (ani duveru).

> To je dobre, ale spousta veci tam nikdy nedorazi a presto je nekdy
> kvalitnejsi nez co jsou 'nuceni' pouzivat standardni uzivatele...

A jak to poznam? Mechanismy, o kterych mluvim, jsou nespolehlivejsi. Nic
lepsiho neni. Slepa duvera je spatna. Vis kolik patchu se ruzne povaluje?
A kazdy autor o nich pise, ze jsou bez problemu...

> Proc tito zkuseni harcovnici ignoruji desetiletimi proverene zkusenosti
> jinych harcovniku (z jinych oblasti)? Opravdu mne Linus nakrkl, kdyz
> rekl, ze jeho 'CVSko' je mailbox a nic lepsiho nepotrebuje...

Protoze to ma sve vyhody. Argumenty jsem se zde snazil naznacit minuly
tyden.

> Jenze u CBQ konkretne neni problem v Kuznecovi, ten to plne schvaluje
> a na novem vyvoji se castecne podilel (je vubec Kuznecov jeste
> maintainerem aspon CBQ?), nema vsak naladu to prosazovat a tlacit
> proti Linusovi - sam se asi radeji venuje efektivnejsi cinnosti, nez
> nekoho porad premlouvat a presvedcovat o sve pravde... - Open Source
> je o svobode, volbe apod. - proc konkretne Linus obcas tu moznost
> volby bere ciste na sebe - on skutecne vi, co je pro stadecko

Je zavadejici si myslet, ze by vsichni vyvojari meli zustat u Linuxu.
Fluktuace je obousmerna a je prospesna. V Linuxu muze byt situace (zrovna
treba posledni rok), ze se proste nove veci do jadra nedavaji (feature
freeze, nynejsi neexistence vyvojove rady jadra).

Myslim, ze to jejinak naprosto o nice. Na vsechno, co napises a vedes ve
smyslu "Linux a Linus je blbej" se najde pritiargument. Nemuzeme nikdo
vedet podrobnosti a proto jsou to povetsinou dohady a "jedna pani
povidala". Je to proste o nicem a je to zbytecne dlouhy.

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