Red Hat Bugzilla: vecirek jen pro zvane?

[Ing. Pavel PaJaSoft Janousek]

> > > nejake casti kodu muze stat v podstate kdokoliv, kdo se zacne snazit.
> >
> >       Zkousel jsi to? Nestaci snaha o systematicnost, ale mit i __velmi
> > podobny__ nazor na implementaci jako nekdo vyse...
> 
> Jo, zkousel. Uspel jsem malo, nemel jsem vytrvalost a cas.

'-) uvedu konkretni priklad - ve sve dobe (nevim jak dneska) se dala
zapnout automaticka konverze konce radku (LF/CR+LF) mezi Linuxem a
VFAT... jenze jeji implementace byla IMHO velmi nebezpecna - a sice
konvertovalo se uplne vse krome souboru, ktere meli priponu ze seznamu
natvrdo definovaneho v jednom source souboru (bylo tam asi tak 25
znamych (well-known) pripon, trochu malo, ne?) - kdyz nic jineho, tak
jsem navrhoval opacnou logiku - seznam pripon souboru u kterych se
konvertuje a u ostatnich se proboha nic nemeni... (myslim, ze konverze
je v jadre do dnes a mnoho lidi netusi, co by to za paseku mohlo delat a
ze je v podstate tato volba nepouzitelna...)

	Snazil jsem se o kontakt jak maintainera VFAT tak i nekterych dalsich
lidi (je to tak 4 roky nazpet), samozrejme ze jsem neuspel... jednou
jsem si vyrobil svuj patch, ale pak jsem se na to vykaslal a volbu
nepouzivam, protoze vim o jeji nebezpecnosti (o l-k konfere jsem v te
dobe nevedel). Ano, take jsem nemel dostatek energie (a ze jsem ji
vynalozil dost) - radeji jsem se venoval jinych projektum (ktere mely
IMHO smysl vetsi)... - a myslis si, ze podobnych pripadu nejsou
(bohuzel) mraky?

> 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
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... 

	Takze proc kdyz v nekterych vecech je vzdy v jadre vyber (a kdyz si
zvolim volbu A, zrusi se mi automaticky voba B,C,D) a v nekterych neni
(pokud si jadro nepatchnu) ac srovnatelny zpusob je minimalne stejne
kvalitni - protoze to a) nekdo neprotlacil (nemel snahu) nebo b) se to
Coxovi nebo Linusovi (a jinym 'vyse' postavenym) nelibilo...

	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,
nemam az tak velke znalosti teto casti HW) aspon rok (na mem HW), pred
asi 3 mesici jsem si nasel cas a znovu jsem si s nimi pohral a ejhle,
konecne je to opraveno a zase vse funguje jak ma... - kolik zbytecneho
casu se muselo stravit znovuobjevovanim kola? (proc kernel po patchnuti
lm_sensors fungoval, kdyz se lm_sensors stali soucasti jadra naprosta
nefunkcnost aspon s urcitymi WINBONDy?)

> co jsi zde uvedl, je prekrouceni skutecnosti - Linus i A. Cox maji
> argumenty (a zkusenosti), pokud mas lepsi, dodas reseni (spravne,
> konzistentni, promyslene do budoucnosti, zapadajici do projektu, ...) mas
> jednoznacnou sanci. Musis mit i trpelivost a tim prokazat, ze svou praci
> dokoncis. Snazim se sledovat l-k uz asi 5 nebo 6 let a za tu dobu se
> vystridalo hodne jmen. Jen diky rozumne selekci se to drzi :-)

	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...

	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.)...

> Prestav si sebe, jak se staras o projekt s 1.5 milionu radku kodu. Velke
> neorganizovane zasahy porusi strukturu a uz se v tom nikdo nevyzna.

	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
skoro na boha. To neni kritika, to je sdeleni meh pohledu na vec, Linus
ma samozrejme pravo byt takovy, ja to akceptuji, protoze Linux pouzivam
denne a v mnoha ohledech mi sedi, nicmene to mi nebere pravo s nekterymi
vecmi nesouhlasit a treba se snazit o zmenu. Ze je takovych daleko vice
je na snade...

> kontroluje). Kdyz posles 20 jednoduchych fixu do NTFS a odstranis tim jeho
> soucasne nejvetsi problemy, tak prokazes, ze Tvoje nova implementace bude
> tezit ze zkusenosti a ze ses dobrej. Prijimajici ti pak uveri, mozna bude

	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...

	Samozrejme, kazdy si mysli, ze jeho kod je dobry bez chyb apod.,
ostatne chyby soubehu se hledaji ze vseho nejhure, zvlaste, pokud je
chyba soubehu nikoli v me komponente, ale v komponente (-tach), ktery
vyuzivam (zadna komponenta neni samorost)....

> Nesmis smesovat dve veci - opatrnost dlouhodobeho maintainera, ktery videl
> desettisice radku kodu a nadseni novacka (ktery by chtel ziskat hned prvni
> den osruhy - schvalne prehanim). Do l-k chodi hodne veci, ktere nekdo
> separatne udrzuje. Pokud chodi dlouho a dostanou se do verze 1.0, maji
> velkou nadeji (jsou overene, dlouhodobe...).

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

> nepokracoval. Je mozne, ze to nekde muze skripat, ale to chce cas. Nelze
> ignorovat slova zkuseneho harcovnika, ktery ma odsedenych tisice hodin.

	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...

> dne nekdo odstrani. Stejne problemy, jake musi prekonat novy implementator
> treba CBQ mel pri svem "prijimani" i Kuznecov.

	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 uzivatelu to
nejlepsi? (Otocim to - za jeho volbu ReiserFS mu pekne dekuju, at si ji
strci nekam... a za jeho casto nepouzitelna jadra - skutecne
neprelozitelna taky; neni vsevedouci ani vsemohou, tak at se do teto
pozice nestavi - sam se do ni delegoval a ve sve dobe to kazdy
akceptoval, dneska jsme trosku nekde jinde, Linux je take nekde jinde
nez byl a mozna je na case i zmena pristupu - tim nerikam, ze Linus je
dinosaurus, urcite zmeny citim rovnez)

> I A. Cox ma problemy s nekterymi patchi, ktere dava Linusovi. Obvykle ale
> po nejakedobe jejich udrzby projdou (nebo jsou mezi tim nahrazeny lepsi
> implementaci, coz je jeste lepsi).

	Pokud neni vsak nova implemnetace, neni to casto tak, ze se nekolikrat
zkousi aniz by se zmenil kousicek funkcniho kodu? To jsou veci, ktere s
vyvojem a funkcemi nesouvisi, ale souvisi prave s tim socialnim zazemim,
ktere ma IMHO linux cim dal horsi a uprimne znam nekolik lidi, kteri
prave proto utekli k jinym klonum UNIXu a Linuxu se jiz mohou jen smat
(nehlede k tomu, ze se na nej divaji pres prsty... - plne je chapu).

-----------------------------------------------------------------------
Ing. Pavel Janousek (PaJaSoft)                 FoNet, spol. s r. o.
Vyvoj software, Intranet / Internet          Anenska 11, 602 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
-----------------------------------------------------------------------