Vlákno názorů k článku
Komiks: Mistr a učedník

Jestlize lidi neustale otravujou s nejakou kravinou, tak to je pouze znamka toho, ze dokumentace neobsahuje dulezitou informaci na relevantnim miste. Tedy ze je chyba v dokumentaci.

Bohuzel Linux a podobne free software projekty zadnou slusnou dokumentaci nemaji, a ani ji mit nemuzou, protoze vyvojari mi sami na kernel mailing listu sami odepsali, ze si to nepreji, protoze "to stoji cas".

Ja na Ronje takovy problem nema - kdyz lidem neco z instrukci neni jasny, tak to beru jako chybu instrukci a opravim to tam.

Vysledek je takovy, ze to chodi na prvni pokus i lidem, kteri v zivote zadnou elektroniku nestavili.

Coz o Linuxu se rict neda, je to presne naopak - pouzivam ho vylucne a nepretrzite asi 11 let, takze zadny novacek nejsem, a stejne mi to vetsinou nechodi ani na kdovikolikaty pokus.

Napriklad posledne ALSA - asi 3 dny jsem se s tim moril, aby chodil korektne dmix, a nakonec nechodil, protoze v ALSA byla buga (podle jejich bugtrackeru).

Casto vyvojari taky alibisticky napisou dokumentaci a nehnou ani prstem pro to aby byla prehledna, takze vysledek je dokumentace neprehledna, ktera je k nicemu - k cemu je cloveku ze v dokumentaci je informace, kdyz nevi, jak se k ni dostat (na ktery link kliknout nebo ktere klicove slovo vyhledat).

Psychologicky profil typickeho vyvojare free SW je dle meho nazoru zakomplexovany asocialni autista, ktery si mysli, ze je reditelem zemekoule. Jeho schopnosti v oboru psychologie, marketing, ergonomie a dokumentace jsou 0. Slovy: nula.

Tohle je treba zmenit - vyvojari musi adresovat tento problem stejne jako adresuji technicke problemy v software - analyzovat a odstranit pricinu. Jenze k tomu se nejdriv musi zbavit emocni zavislosti na svem vlastnim egu. K tomu je dle meho nazoru idealni buddhismus, ktery propaguje Johanka.

"Psychologicky profil typickeho vyvojare free SW je dle meho nazoru zakomplexovany asocialni autista, ktery si mysli, ze je reditelem zemekoule. Jeho schopnosti v oboru psychologie, marketing, ergonomie a dokumentace jsou 0. Slovy: nula."

Tohle sedi na me --- az na to, ze nejsem autista, ale schizoidni psychopat. Schopnosti v jinych oborech nemam.

Uplne ne - nemas pocit, ze jsi reditelem zemekoule. V oboru ergonomie take urcite schopnosti mas - uzivatelske rozhrani Linkse je lepsi nez klikni-a-koukni-se-kam-ses-tentokrat-trefil v beznych programech. Taky scrollovani je advancovane jako v GIMPu a ne primitivni jako ve Firefoxu.

Ale jinak ten zbytek to jo, to je fakt. A vzhledem k tomu ze ses totalni psychopat tak si ani nemyslim, ze to hodlas zmenit :)

Ehm, môžem sa opýtať čo je na scrollovaní vo firefoxe primitívne?

Nechodí scrollování plochy ve 2D při zmačknutí prostředního tlačítka myši. Horizontální scrollování pak nejde ani pomocí kolečka musí se jít na scrollbar pokaždý když chceme scrollnout.

Scrollování kolečkem skáče takže člověk ztratí řádku co čte. V Linksu je to plynulé takže se řádka neztratí, a navíc se dá číst i během scrollování.

Nabízím jiný pohled: Scrollování kolečkem skáče, a proto funguje rychle. Podle právě podniknutého pokusu (nikterak seriozního, ale základní představu poskytne) se po skoku během cca 200ms chytím správného místa na obrazovce a čtu dál, zatímco při pomalejším plynulém scrollování po podstatně delší dobu sice stále čtu, ale výrazně pomaleji, než když se text nepohybuje.

Rovněž všelijakých scrollovacích udělátek existuje do Firefoxe přehršel, takže každému, co jeho jest. Ergonomie je pěkná věc, ale dost často konverguje k poznání, že různým lidem vyhovuje různé ovládání. (Opět příklad z vlastní zkušenosti: někteří programátoři například čtou rychleji syntax-highlighted zdrojáky, někteří zase neobarvené.)

> Ergonomie je pěkná věc, ale dost často konverguje k poznání, že různým lidem vyhovuje různé ovládání.

souhlas na 100% - to je prave pekne na linuxu/unixu, ze je hodne veci konfigurovatelnych ... ja jsem treba nikdy nepotreboval ve VIM-u jiny styl editace dlouhych radku, nez default (logicky radek je na vic fyzickych radkach a sipky up/down skaci po logickych radcich), ale kdyz se vyskytla potreba udelat to tak, aby to skakalo po fyzickych, tak jsem zjistil, ze to nejenom lze, ale dokonce to lze pohodlne namapovat i na sipky ...

kazdemu vyhovuje neco jineho a kazdy si to, co mu vyhovuje, muze zapnout/nastavit ... freedom

Mne vyhovuje skokovy, ale plynuly scrolling. coz je v Xkach zrejme problem. Posledni rozumne skrolovaci program byl CED na Amize. Vypada to, ze nikdo nedokaze napsat opravdu plynuly scrolling, protoze to co predvadeji bezne desktopove aplikace je k placi. Nevi nekdo v cem je problem? VSYNC je preci k dispozici.

VSYNC, vertikalni synchronizace znama jako snimkova frekvence urcuje, jak casto se prekresluje snimek na stinitku obrazovky. Dnes to byva obvykle 75Hz, 85Hz, 100Hz apod. Plynuleho scrollingu se dosahne tak, ze pri kazdem prekresleni snimku dojde k posunu objektu na obrazovce o stejny pocet pixelu. Napr. o 2 pixely pri kazdem snimku. K prekresleni frame-bufferu, ktery obsahuje prave zobrazovany snimek, musi dojit, kdyz se paprsek vraci na zacatek obrazovky. Nekdy se pouziva double-buffering, kdy se na pozadi pripravuje dalsi snimek a pri navratu paprsku se pouze prehodi zobrazeni na druhy snimek. Diky tomuto se pak jevi scrolling jako naprosto plynuly. Pokud se toto nedodrzi a snimek se prekresluje jeste behem zobrazovani, dojde k "roztrhani" obrazu na nekolik kusu. Je to videt napr. u 3D her s vypnutym VSYNCem, kdy pri otaceni postavy se obraz roztrha.

vsync je sice mozna k dispozici, ale bojim se, ze vyrenderovani obrazovky se za jeden pruchod nestihne a s prihlednutim k multitaskingu..... :-( Doufam, ze i toto se s XGL vyresi, tam se o o pozici vsync muze starat karta a procesor si muze prepinat tasky jak chce. Na 8bitech, kdy v ram sedela skoro jedna cela aplikace si mohli autori dovolit delat pekne svinstvo, ale u soucasnych systemu to je asi trochu problem. (tim nechcu tvrdit, ze amiga byla 8bit, ale autori se vic snazili... a nepouzivali zrejme vektorove fonty ale rastry a podobne srandy)

Amiga sice nebyl osmibit, ale prasečin z osmibitů tam nebylo málo, dokonce bych řekl, že jich tam bylo víc, než je únosný! Celý to bylo tragickým způsobem poplatný době a jednoduše to MUSELO vyhnít!

Osobně je mi jedno, jakej co používá scrolling, protože pokud někde něco potřebuje Xka, či jiný grafický prasečiny, jsem maximálně nasranej už v tom momentě, kdy to spustím, takže skákající scrolling mě už víc nasrat nemůže, v textmodu je to myslím úplně jedno.

Ve Firefoxu 1.5 se mi na nějaké stránce stalo to, že kurzor blikal v TEXTAREA, ale klávesy UP, DOWN, HOME, END, mi scrollovaly celý dokument místo, aby jezdily kurzorem v textarea. Nešlo s tím nic dělat, ani, když jsem do textarea opakovaně klikal myší --- jediná možnost, jak s tou textarea pracovat bylo kurzor umístit myší a pak psát. Raději mám Mozillu, ta má bugů míň. Škoda, že se už nevyvíjí.

tak to se pletes - http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.0.1/ - je napr i v portage v gentoo, coz je moje distro ... posledni verze vedla k dost velkymu zvyseni stability, aspon mail klient me zatim jeste ani jednou nespad, coz u 1.0 byl dost castej jev ;)

Ve firefoxu to jsou v rozsirenych nastavenich volby "pouzit automaticke posunovani" (na to prostredni tlacitko) a "pouzit jemne posunovani" (i kdyz i to jemne scrolluje docela rychle; me se pohybujici se text cte spatne, takze mi to poskakovani vyhovuje. Vim o kolik to poskoci a kde se teda mam chytnout a ctu dal)

problem neni v manualu, ale v 90% v uzivateli. kdykoli jsem cokoli potreboval rozchodit tak jsem si 99% veci rozchodil sam, at uz se jedna o cokoli. az v mire naproste zoufalosti nepochopeni a probdeni nekolika noci jsem ochoten otravovat druhe aby mi pomohli.
na druhe strane 90% lidi neni ochotna si precist ani zakladni informace a tak bude spamovat vase ICQ/MSN/mail a budou chtit presne ty informace ktere jsou popsane v manualu velkym pismem a hned na zacatku. a jsou i takovi, kterym napisete presne to co chteli slyset a oni na to jestli by jim to clovek mohl zopakovat, ze to nechapou.
vysledny efekt : dela to presne co by melo, ale nema to cenu vysvetlovat

Kdyz se nekdo zepta na mailinglistu na neco co je v manualu napsane na spravnem miste, informaci mu neposkytnu ale obkliknu URL. Ostatni uzivatele se to tak dovi taky a predejde se tomu, aby s tim otravovali.

Ono je to taky zpusobeny tim ze 90% manualu jsou crap takze ty uzivatele jsou uz nacviceny ze se tam ani neobtezujou kouknout. Ja se jim nedivim - ja to delam taky tak.

To je bezpochyby zajímavá psychologická teorie, ale já dám raději na praxi. Pokud se porozhlédnu po uživatelích okolo sebe (tím nemyslím ani tak naši alma mater, jako spíš přispěvatele všelijakých mailing-listů), nemohu si nepovšimnout, že značná část dotazů jasně ukazuje, že si v dokumentaci tazatel nepřečetl ani první odstavec, případně že mu naprosto uniká kontext (ptá se na ovládání nějaké síťové utility, aniž by znal základy fungování TCP/IP). Na takovou stěnu můžeš naházet hrachu kolik chceš a stejně, potvora, nedrží. V takových případech je hloupost vylepšovat hrách a RTFM je odpověď zcela zasloužená a pro dotyčného přínosná, i když pravý guru by jej samozřejmě spíš přetáhnul holí, aby se mu rozsvítilo :-)

Po profilu typického vývojáře se nemá smysl ptát, dopadne to dost podobně, jako ptát se na profil typického uživatele této planety, tj. tak, že slabší povahy se po poznání odpovědi leknou a utečou a silnější se občas raději stanou poustevníky. Ono napsat dobrý program s dobrou dokumentací není snadné a lidí takovým uměním nadaných je na světě nemnoho, takže většina programů je nutně mizerná. To ale není specialita softwarového světa -- například na sazbě knížek je to vidět úplně stejně: od té doby, co je může na počítači tisknout kdekdo, je většina knih vysázena mizerně. Ale práce opravdových sazečských mistrů se i dnes občas potkává.

Jak je to obecně, nemohu soudit, ale o vývoji kernelu něco málo vím. Je tam dobře vidět, že většina lidí okolo free SW dělá to, co je nejvíce baví, což je typicky také to, co nejlépe dovedou. A většina programátorů zkrátka daleko lépe programuje než píše dokumentaci, zvláště když se jedná o dokumentaci, kterou oni sami nepotřebují (naproti tomu třeba lockovací pravidla v kernelovém VFS jsou zdokumentována velmi důkladně, protože je to nutné). Ale ani u kernelu není situace nikterak katastrofální: třeba manuálové stránky syscallů jsou napsané a udržované docela dobře, o vnitřní architektuře jádra vycházejí i knížky (třeba velice pěkné Linux Device Drivers, k dispozici jak papírově, tak online). Určitě to může být lepší (zvláště autoři některých driverů jsou na slovo skoupí), ale nestěžuji si.

V mnoha případech je to prostě tak, že lidé free SW vyvíjejí hlavně sobě pro radost a teprve na druhém místě je všeobecné blaho světa. Pokud jim dokumentace nechybí, nejsou nikomu zavázáni ji psát. Pokud Tobě chybí, pak to nejlepší, co můžeš udělat, je přestat psychologovat a místo toho přiložit ruku k dílu. Maintaineři takřka všech programů patche do dokumentace vítají s otevřenou náručí.

Ked uz raz chces zdielat svoju pracu tak to rob poriadne, nie?

Právě že tak free software nefunguje. Lépe řečeno jsou ho dva druhy -- jeden autoři píší pro ostatní a dávají si obvykle záležet i na dokumentaci, zatímco ten druhý si napsali sami pro sebe a řekli si, že i když je to třeba narychlo splácaný hack, přesto by se mohl někomu hodit, a tak ho místo do šuplíku hodí na nějaké veřejně přístupné místo. Někdy taková věc zapadá prachem, jindy se z ní časem vyvine životaschopný projekt, jindy si ostatní takový program spletou se softwarem onoho prvního druhu a autorovi nadávají, že k tomu nenapsal dokumentaci.

Zkrátka spoléhat na to, že cokoliv publikovaného je kvalitní, je příznak naivity, nikoliv špatnosti světa.

Na ovládání a dokumentaci většiny programů je samozřejmě pořád co vylepšovat, spíš mne zaráží s jakou jistotou tady mnozí rozebírají, jak se programátoři cítí jako mistři světa :-) Ono je to často spíš tak, že po napsání velkého programu se cítíte dočista maličkatí, protože vidíte, že to je teprve začátek a že za každým řádkem se schovává hromada věcí, které by ještě stály za vylepšení.

(Osobní zkušenost: programátoři, kteří se cítí jako mistři světa, většinou píší spíš shareware pro wokýnka, vždyť co by se zahazovali s nějakým free SW... :) )

Jo já jsem jednou zadával součástky do Ronji a zadám "6.8" a ono to automaticky doplní na "6.8k" když se na obrazovku nekoukám, ale do papíru. Po delší době jsem si toho všimnul a trvalo mi asi hodinu než jsem našel kde se to vypíná. Vypínalo se to na posledním místě kde bych to hledal.

Takže až si někdo objedná Ronju a místo 6.8 odporů mu přijdou 6.8k a bude muset bugreportovat na Ronje a objednávat znova a znova platit dobírku, tak ať ví koho za to nakopat do prdele - vývojáře OpenOffice :)

Ne, to se pleteš. Nakopat mají jen a pouze Tebe, protože Ty jsi vypustil do světa něco, co jsi nezkontroloval. Teprve Ty pak máš právo kopnutí předat dál :-)

Doteď tu byla diskuze o věcech jako nastavení operačního systému, tam bych analogický problém považoval skutečně za chybu uživatele (protože konfigurace OS je odborná věc a nemá se do toho pouštět běžný uživatel).

Ale OO.org jsou normální uživatelský program a měl by počítat s tím, že typický uživatel je naprostý idiot. Já když dělám web, tak předpokládám, že uživatel neví, co je internetová adresa. Autoři OO.org by IMHO měli předpokládat, že uživatel nedokáže číst (protože on to skutečně nedokáže - je líný to na konci znovu přečíst)...

(Ve skutečnosti se mi to automatické doplňování, které tu pravděpodobně způsobilo chybu, v OO.org líbí, ale nemůže to fungovat, pokud bude ten program používat typický Windowsácký uživatel.)

> Autoři OO.org by IMHO měli předpokládat, že uživatel nedokáže > číst (protože on to skutečně nedokáže - je líný to na konci
> znovu přečíst)

Pokud po sobe uzivatel neprecte co napsal, tak je to debil, bez ohledu jestli to pise v OO, M$O, T602 nebo treba ne mechanickem psacim stroji. Bejt sefem (coz nastesti nejsem :-), tak takoveho zamestnance kopnu do prdele ...

> Pokud po sobe uzivatel neprecte co napsal, tak je to debil

No ano. Takovi lide skutecne v prumeru jsou. Co z toho ma plynout? Vyhladit 70% lidstva?

> bez ohledu jestli to pise v OO, M$O, T602

Ne, MSO nemaji takove nebezpecne featury jako bleskove doplnovani.

> Bejt sefem (coz nastesti nejsem :-), tak takoveho zamestnance kopnu do prdele ...

Whatever...

Tak z toho by mě šlak trefil hned v první chvíli. Jakmile bych v seznamu součástek našel něco ve stylu Rezistor 6.8k, tak to zmačkám a zahodím a vůbec to nebudu číst dál, protože je na první pohled jasný, že to nepsal někdo, kdo se elektronikou zabývá, ale nějakej šílenec od počítačů a od toho raději dál. Rezistor 6.8kOhm se označuje jako 6k8, rezistor 6.8Ohm jako 6R8. BTW Rezistor je součástka, odpor je veličina!

Ona dokumentace není všechno (a dokumentace k Ronji je taky...zajimavá). Může mi třeba někdo vysvětlit, co to je za šílenost v podobě U1,U2,U3 v Transmitteru Ronja 10M Metropolis? To je tam jako proto, aby to bylo složitější, nebo proč? To by nešlo udělat _jedním_ rychlým FETem?

Od toho jsem udělal definici Satisfying Products a Satisfying Projects, jejíž cílem je odlišit od sebe spolehlivě softare typu 1 a software typu 2:
http://ronja.twibright.com/satisfying.php

Ono když programátor se mohl programovat, tak se může naučit taky psát dokumentaci. Já jsem se to na Ronje musil taky učit. Ze začátku to bylo vysoce nekvalitní.

Ohledně té dokumentace --- pamatuji si třeba na bugu v jádrech 2.0, která byla nedostatečnou dokumentací způsobena: původně byla funkce mark_buffer_dirty() napsána tak, že se neblokuje. Autor ext2 filesystému si přečetl její implementaci, viděl, že se neblokuje, a použil ji takovým způsobem, že jeho kód na tom ne-blokování závisel. Po nějaké době vývojáři VFS změnili implementaci mark_buffer_dirty, aby se blokovala, a nevědomky tak udělali v ext2 race-condition.

Nejsem příznivce nějaké veliké byro-specifikace, ale u každé funkce, kterou mohou používat drivery, by se aspoň mělo napsat blokuje/neblokuje, může se volat z procesu/interruptu/timeru/softirq, může/musí/nesmí být drženy tyto locky. A pokud se tyto podmínky změní, tak nejlépe změnit název funkce, aby se drivery, co ji používají, neslinkovaly. Pokud jako vývojář driveru naleznu v jádře funkci, která se blokuje, pokud dostane argument třeba "3", nijak z toho kódu nepoznám, jestli je to blokování součást implementace (později ji můžou vývojáři přepsat, aby se blokovala za jiných podmínek) nebo jestli je to součástí architektury a je zaručeno, že se ve všech budoucích verzích bude blokovat pouze s tímto parametrem.

Takhle zdokumentované funkce by jistě bylo pěkné a kernel k tomu aspoň u důležitých funkcí konverguje. Ale především stále platí pravidlo, že kdo takto významně mění chování nějaké funkce, měl by si zkontrolovat všechna její volání. (I tehdy, bylo-li její chování dokumentováno, protože lidé jsou omylní.) To kupodivu docela dobře funguje, bugů podobných tomu, který popisuješ, se na LKML objevuje pomálu.

To je Mikuláši přesně dokonalý protipříklad na koncept "the source code is the ultimate documentation". Mohl bys ten odstavec přeložit do angličtiny a dát na svou homepage? Ať to lidi můžou linkovat jako odpověď uberprogramátorům na jejich řeči o "source code is the ultimate documentation" :)

Vidíš, a zrovna tihle lidé, kteří říkají, že source code is the ultimate documentation, jsou často těmi, kteří dokázali daleko víc než ostatní... Zvláštní, že?

U velkých projektů znám asi jen jedinou výjimku (zato pořádnou :)), a to je páně Knuthův TeX.

Tak, tak - "literate programming" (jak tomu D.E.K.) rikal ruleZ !

Já Ronju vyvíjím pro radost druhým lidem - sobě pro radost nikoliv, protože ji už vůbec nepotřebuju - mám domů 4Mbps down 0.5Mbps up kabelovkou za mírný peníz a je to poměrně spolehlivé.

Problém je právě v tom že ty lidi vyvíjej Linux pro radost sobě a ne ostatním. Navruhuju aby začli vyvíjet pro radost ostatním. Ona tam ta radost pro sebe pak vznikne jako vedlejší efekt. Aspoň tak to funguje u Ronji. A taky tak to hlásá Dalajlama a Johanka :)

Ono "přiložení ruky k dílu nefunguje" - např. u Ekiga jsem našel, že jim chybí prerequisita v instalačních instrukcích. Tak jsem jim to poslal a oni řekli že to odmítaj s tim že můj Linux je špatně nainstalovaný. Můj Linux byl nainstalovaný a ta buga v návodu Ekigy je pořád.

To si radši opravím dokumentaci od Ronji. Tam mě s tím nikdo nevyfuckovává. Posledně jsem strávil neuvěřitelného času na psaní testovacích procedur a teď už je to mnohem přehlednější než bývalo :)

Navruhuju aby začli vyvíjet pro radost ostatním.

S tím nemohu než souhlasit, ale je hloupost takové názory ostatním vnucovat, to nikdy v historii nefungovalo a není důvod, proč by to mělo fungovat zrovna teď :-)

Tak jsem jim to poslal a oni řekli že to odmítaj s tim že můj Linux je špatně nainstalovaný.

Ale no tak, přeci se nevzdáš hned :-) Každou chvíli posílám patche na nějaké drobnosti a v naprosté většině případů je autoři buďto přijmou nebo chybu opraví po svém. A když je odmítají, většinou z dobrých důvodů.

Možná je to tak, že ke každému je svět takový, jaký ho čeká :-)

MJ tvrdí: "Ono napsat dobrý program s dobrou dokumentací není snadné"

Já si myslím že to není pravda. Jednoduchý algoritmus k napsání dobrého programu s dobrou dokumentací:

1) Zadefinujte projekt jako satisfying project
2) vemte první bugreport který reportuje diskrepanci se satisfying productem, pokud nejsou bugreporty, tak
feature report. Pokud nejsou feature reporty, nějakou novou featuru si vymyslete
3) analyzujte bugreport a zjistěte příčinu bugy. V případě feature reportu vymyslete jak to implementovat
4) odstraňte bugu / přidejte featuru bez ohledu na to jestli to vyžaduje drobnou změnu nebo napsání programu znova from scratch
5) goto (2)

Tento algoritmus je jednoduchý a nevyžaduje znalosti ani zkušenosti - dají se doplnit on the fly z wikipedie a mamma.com.

Použil jsem ho na Ronje. Fungoval i přesto, že jsem ze začátku nevěděl ani jak funguje tranzistor (první zesilovač pro Ronju se choval opravdu legračně).

To je s prominutím pitomost. Tím vznikne projekt, který možná bude splňovat Tvou formální definici, ale dost pravděpodobně bude k ničemu. Něco jako "inženýři píší programy tak, že začnou debugovat prázdný program". Jenže na prázdný program sotva dostaneš užitečné bug reporty :-)

To, co popisuješ, je dobrá iterační metoda, jak ještě zlepšit projekt, který už je docela dobrý. A mnoho projektů se ještě do tohoto iteračního stadia nedostalo, případně dostalo, ale jelikož množství energie ve vesmíru je omezené, iterují pomalu. Ale i tehdy je dobré projekt zveřejnit, například proto, že někdo další může přiložit ruku k dílu. Byť nejlépe s tučným varováním, aby se z nepochopení stavu projektu nestalo další topivo pod ohníček těch, kdož rádi nadávají na špatnost světa :-)

To jsi to nečet celý? "Jenže na prázdný program sotva dostaneš užitečné bug reporty" -> tomu odpovídá položka vymyšlení feature requestu.

"Ale i tehdy je dobré projekt zveřejnit" - já nepíšu že se to nemá zveřejňovat. Ty iterace může provádět i široká veřejnost na zveřejněném projektu.

Tyhle diskuse fakt nemaj cenu - jsou 2 druhy lidí. Jedni chápou co znamená "program slouží uživateli ke spokojenosti", a druhý to prostě nechápou, ať se jim to vysvětluje sebelíp.

Já si myslim že to nechápou protože oni jsou líný a tak maj podvědomě takové pochopení zablokované, aby se nedohalilo, že musej měnit svuj přístup a nedejbože něco nového se učit nebo se nedejbože přizpůsobit reálnému stavu věcí.

Já už se s lidma na Linuxu ani nehádám - radší píšu patche do projektů kde jsou lidi rozumní, jako např. do programu na tištěné spoje PCB jsem poslal už nejmíň 3 patche.

Četl jsem to celé a stejně mi to smysl nedává. Když píšu program, nezačnu od nuly a nevymýšlím si postupně feature requesty, nýbrž docela dlouho přemýšlím nad tím, co všechno by to mělo umět a jak to navrhnout, a až po hodně dlouhé době se z toho vyloupne něco konzistentního, u čeho má smysl začít nějaký iterativní vylepšovací proces. "Sloužit uživateli ke spokojenosti" je skvělá mantra, ale sotva dokonale splnitelná. I kdyby byl OpenOffice sebelépe dokumentovaný a měl sebevíc featurek, mně třeba ke spokojenosti sloužit nebude, já k ní potřebuji spíš vi-čko nebo emacs. A opačně -- jiným lidem se zase nezavděčíš sebelepším vi-čkem. To kupodivu také spousta lidí nechápe. Já už se s lidma na Linuxu ani nehádám -- to je asi dobře, tak útočné posty na LKML jsem už dlouho neviděl ;) Trocha pokory by neuškodila, pane kolego. Ale dost diskutování, pojďme oba přiložit ruku k dílu.

Americane maji skvele prislovi, ktere rika "you get what you pay for." Pokud se ti produkt nelibi, muzes chtit vratit sve penize. Jestli ti jakakoliv vec na programu natolik vadi, ze jej podle tebe nemuzete pouzivat, muzet jiste chtt vratit sve penize zpet.

Pokud vyvojar dela dany open source projekt zadarmo, budme radi, z tomu tak je, a on nema zadny duvod psat dokumentaci, kdyz nechce. Skutecne to stoji cas a existuji prijemnejsi zpusby, jak jej stravit, nez opetovne sezeni za pocitacem, zvlast kdyz uz takhle tento programator stravil dost casu nad projektem samotnym. Zejmena kdyz vubec neni asocialni. Myslenka, ze kdo neni altruista, je svine, je temer politicky nazor. Navic pomerne hodne nebezpecny politicky nazor.

Pokud je open source vyvojar placen, zalezi ciste na subjektu, ktery jej plati. Takovy vyvojar je obvykle pomerne drahy a neni jich mnoho. Dokumentaci tedy tvori jenom ve velmi omezene a zcela nezbytne forme (viz zminene zamykani ve VFS, snad jediny soubor v dokumentaci kernelu, ktery je aktualni). Pokud se ti to nelibi, muzes se stat zakaznikem danych spolecnosti a spolu s podobnymi uzivateli je primet to zmenit.

S tim nema nic spolecneho to, ze na ruznych forech se objevuji ruzni sasci vyjadrujici ostentativni pohrdani mene zkusenymi uzvateli.

Ano open source ma velike problemy s dokumentaci. Na tom ale neni nic divneho. Zvlast u obrovskych a velmi "zivych" projektu jako je kernel, gcc, KDE, kde jakekoliv psani dokumentace je z podstaty veci strelba na bezici terc.

PWN3D