Hlavní navigace

Hackerská etiketa

Karel Kulhavý 18. 3. 2004

Vývoj svobodného softwaru probíhá specifickým způsobem za současné úzké spolupráce vývojářů a uživatelů. Nově příchozí do tohoto světa mají často problémy se v něm zorientovat, a tak přináším jakýsi přehled, který by jim to měl zjednodušit.

O hackerskou etiketu se jedná proto, že hacker je vývojář svobodné technologie. Vývojáři proprietární technologie mají etiketu jinou, a ta se v zásadě omezuje pouze na vnitřek podniku, pro který pracují, takže nemá pro veřejnost význam.

Netvrdím, že následující postřehy jsou nějakou obecně platnou normou. Jedná se o moje vlastní postřehy ze zkušenosti z této oblasti.

Z hlediska uživatele

Typická situace je, že uživatel přijde na stránky projektu, nalezne místo jasně označené jako startovní bod pro příchozí (zde začněte, about, o projektu, …) a přečte si, co od projektu očekávat, nejlépe i jeho specifikaci. Určí, zda projekt odpovídá jeho potřebám.

Pokud projekt jeho potřebám odpovídá, pokud má balíčkovací distribuci, program nainstaluje a pokračuje začátkem uživatelské dokumentace. Jinak typicky stáhne zdroják a pokračuje souborem README. Pokud není README, je instalační návod v INSTALL, případně v doc/README.html a podobně.

Pokud projekt neodpovídá potřebám uživatele, může hledat projekty další. Je zde Freshmeat, což je databáze projektů, a také Sourceforge, což je takový „zadarmo“ (za reklamy) hosting projektů a také jejich rejstřík. Dále existuje Free Software Directory, společný projekt Free Software Foundation a UNESCO.

Uživatel může očekávat, že program bude fungovat tak, jak má. Pokud nefunguje, je odpovídající akcí zjistit, zda to, jak se chová, je v rozporu s jeho specifikací, a pokud ano, poslat bugreport.

K čemu jsou specifikace a proč nestačí programy samotné? Slouží k zjednodušení práce s programy (obecně objekty reálného světa, lidskými produkty). Umožňují jakési abstraktní, stavebnicové a hierarchické chápání světa, které podstatně redukuje práci, v čemž právě přínos specifikace spočívá.

Svět se rozpadne na stavební kostky – moduly, objekty – a jejich rozhraní (specifikace). Je nutné, aby moduly byly jednoznačné – proto není dobré, když se dva projekty jmenují stejně, nebo když někdo udělá klon projektu a nechá mu původní jméno (např. existují dva programy jménem „jade“).

Uživatel s rozhraním pracuje tak, že moduly k sobě spojuje a kontroluje, zda rozhraní (specifikace) na obou stranách spojení odpovídají. Dá se snadno intuitivně nahlédnout, že pokud je větší systém složen z modulů, které jsou všechny BugFree™, a rozhraní na sebe pasují, pak musí i celek být BugFree™.

V případě, že celek nechodí, analyzuje se, zda sedí specifikace, a pokud nesedí, chybu udělal uživatel. Pokud sedí, nutně alespoň jeden modul se musí chovat v rozporu se svými specifikacemi. Tento přístup k realitě umožňuje pracovat předvídatelně i se systémy, jejichž vnitřní struktura je natolik složitá, že ji jeden člověk nemůže v jednom okamžiku celou chápat (natožpak uživatel). Typickým takovým systémem je počítač, na kterém běží nějaký software.

V případě nalezení chyby musí uživatel nejdříve ověřit, že to je skutečně chyba. Ve světě, kde se používají specifikace, to znamená najít rozpor mezi chováním programu a specifikací. A pak poslat bugreport nejlépe ve formě:

Strana 22, kapitola 22.3: "Přepínač -a způsobuje
zapnutí 8-bitového zpracování textu"
clock@beton: cat a.txt | program -a > vystup.txt
program: unknown option "-a"

Specifikaci neplést se „zříkám se odpovědnosti úplně za vše“ klauzulí v GPL. Ta je zde jen proto, aby se zamezily právní komplikace, a ve skutečnosti to tak nikdo nemyslí.

Při posílání bugreportů je nutno striktně odlišovat fakta, kterými jsme si jisti („program je vadný“) od domněnek („a na základě toho si myslím, že by to mohla být chyba, ale neumím to dokázat“), aby mohly být bugreporty hladce smysluplně zpracovávány a nepravdivá tvrzení nesváděla vývojáře (a případně uživatelské čtenáře mailing listu) zbytečně na zcestí.

Velmi vhodným se ukazuje program script. Ten způsobuje, že se vydávané příkazy i hlášky běžících programů zapisují do souboru (defaultně typescript), takže člověk pak tento soubor může vzít, editovat (je vhodné nechat jen relevantní fakta) a použít jako bugreport. Zaručí se tím mimo jiné, že člověk má přesnou kopii toho, co se dělo, a nehlásí jako chybu něco, co byl jeho překlep (i to se stane).

Dalšími podstatnými informacemi jsou verze programu (přepínače -v, -V, –version) a verze různých komponent systému (jádro, gcc, glibc, bash, automake, autoconf, make…). Spoustu práce ušetří, když si človek udržuje soubor pojmenovaný např. system.info, ve kterém má všechny verze systémových utilit poznamenány.

Bugreporty se posílají buď mailem autorovi, na nějaký mailing list, a nebo existuje automatizovaný systém (sourceforge, Bugzilla). Tento systém má sice výhodu, že chyba se zpracovává komplexně, ale člověk se musí typicky přihlašovat, což zdržuje. Také se občas vyskytují předvařené formuláře, které ne vždy mají vhodné možnosti nebo vystihují to, co je třeba sdělit. Projekt od projektu se systém hlášení chyb liší.

Hlásit je nutné i mezery v dokumentacích. Pokud při používání programu dojde k „zákysu“ (typicky se ve specifikaci píše, že program umí nějakou funkci, ale z dokumentace nelze zjistit, jak funkci vyvolat, případně dokumentace připouští dvě hypotézy, jak by se tohle mohlo dělat, spory v dokumentaci apod.), je nutno považovat to za chybu dokumentace a okamžitě hlásit.

Na druhou stranu je nutno se před takovým hlášením ujistit, že v dokumentaci skutečně mezera je. Dokumentace by měla být rozumně lokální – věci by se neměly popisovat v nějaké jiné kapitole, než kam patří. Například tomu odpovídá přečíst si od začátku do konce celou relevantní kapitolu, případně SEE ALSO na konci manuálové stránky, nebo v dokumentaci klíčové slovo vyhledat (i synonyma).

Poslední možností, když selhává dokumentace a specifikace, je Google. Toto je nouzový prostředek. Uživatel může s klidným svědomím očekávat, že všechny funkce programu jdou použít pouze s oficiálním manuálem v ruce. Může se totiž stát, že se program používá na stroji, jehož síťové připojení není plně nakonfigurováno, chybí prohlížeč, nebo je prostě linka do sítě zrovna spadlá.

Kromě Google pomůžou: FAQ, RFC (http://www.faq­s.org/) a HOWTO (přidejte do googlu slovo faq nebo howto). Pokud se jedná o systém Linux, je zde The Linux Documentation Project. RFC jsou standardy, které standardizují informační provoz v rámci Internetu.

Zpětná vazba od uživatele je důležitá. Uživatel je důležitý, protože vývojář nemá možnost ozkoušet, zda bude systém schopen použít člověk, který neví, jak funguje uvnitř, jen rozumí jeho dokumentaci. Je to stejný jev, který způsobuje, že látku ve škole dokáže lépe vysvětlit spolužák, který ji teprve před půl hodinou pochopil, než profesor, který ji učí už 20 let. Není důležité, zda uživatel umí nahlášený problém vyřešit, není se třeba obávat, že vývojář po něm bude řešení požadovat. Není třeba považovat toto počínání za kverulantní paranoiu. Hlášení chyby je příspěvek vývoji.

Neposlat bugreport, když by měl být poslán, je do určité míry nezodpovědné a nemělo by se to dělat, pokud člověk není v opravdu velké časové tísni. Čas strávený řešením nějakého „zákysu“ je čas ztracený. Posláním bugreportu tento kus času z říše času ztraceného vyjmeme a umístíme ho do říše času stráveného smysluplně.

Dále je užitečné, když uživatel navrhuje nové vlastnosti programu – víc hlav víc ví (nejlépe na mailing listu; ovšem i automatické systémy hlášení chyb typu bugzilla mají někdy možnost zadat bugreport jako feature request).

V případě, že program uživateli spadne, je z hlediska ladění důležité core. Aby se získalo, musí se jeho dumpování zapnout pomocí ulimit -c. core je dobré zagzipovat a někde uložit, kdyby se vývojář potřeboval podívat, co se ve spadlém programu dělo. Současně vývojář potřebuje binárku, kterou je dobré zaarchivovat, když hrozí, že bychom program smazali nebo přeinstalovali jinou verzí. Nakonec potřebuje zdrojáky, u kterých je třeba zjistit jejich verzi.

K programu může existovat několik míst, které obsahují dokumentaci. Jsou to manuálové stránky (man), dokumentace ve formátu texinfo (info), adresáře /usr/share/doc, /usr/local/sha­re/doc, web projektu (typický formát bývá HTML, PDF, PS). Neoficiální dokumentace může být i v HOWTO, které se vyskytuje někde na webu (například raidtools mají mezery v dokumentaci, které lze dohledat pouze v neofic. HOWTO). A nakonec když spustíme program s parametrem -help, -h nebo–help, vypíše nám typicky informaci, jaké má parametry z příkazové řádky, a jejich význam.

V tomto dílu jsem popsal, jak vypadá symbióza mezi uživatelem a vývojářem z hlediska uživatele. V příštím díle bude pohled z opačné strany.

Našli jste v článku chybu?

12. 4. 2004 14:48

Vladimír (neregistrovaný)

Hnidopichům bych doporučil jej prostě nečíst. Jak někdo mohl z původně dobře myšleného článku tady vypotit vleklou diskuzi o marxismu-leninismu, nechápu. Co byste vlastně chtěli, vy odpůrci? Aby zase všechno bylo uzavřeno, bez zdrojáků a každý kousek software ověřoval svou legálnost tím, že si bude "volat domů"? Chybí vám tržní chování? Máte možnost. Bill bude mít radost.

A autorovi děkuji. Podle mě to je kvalitní článek. Pár pátků už programuju (asi 30 let), ale lecos jsem nevěděl. Bug repo…

27. 3. 2004 2:50

Kovarczik (neregistrovaný)

Označte prosím příspěvkovou textarea "jen pro ideově nezávadné názory".

Jinak s takovou netolerancí vůči alternativním názorům na veřejném diskusní, serveru jděte raději pryč sám.



Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

Vitalia.cz: Tesco: Chudá rodina si koupí levné polské kuře

Tesco: Chudá rodina si koupí levné polské kuře

Měšec.cz: Zdravotní a sociální pojištění 2017: Připlatíte

Zdravotní a sociální pojištění 2017: Připlatíte

Podnikatel.cz: Víme první výsledky doby odezvy #EET

Víme první výsledky doby odezvy #EET

Podnikatel.cz: EET: Totálně nezvládli metodologii projektu

EET: Totálně nezvládli metodologii projektu

Root.cz: Certifikáty zadarmo jsou horší než za peníze?

Certifikáty zadarmo jsou horší než za peníze?

120na80.cz: Rakovina oka. Jak ji poznáte?

Rakovina oka. Jak ji poznáte?

Vitalia.cz: Manželka je bio, ale na sex moc není

Manželka je bio, ale na sex moc není

120na80.cz: Horní cesty dýchací. Zkuste fytofarmaka

Horní cesty dýchací. Zkuste fytofarmaka

Vitalia.cz: Dáte si jahody s plísní?

Dáte si jahody s plísní?

Vitalia.cz: Jsou čajové sáčky toxické?

Jsou čajové sáčky toxické?

Podnikatel.cz: Chtějte údaje k dani z nemovitostí do mailu

Chtějte údaje k dani z nemovitostí do mailu

Vitalia.cz: Chtějí si léčit kvasinky. Lék je jen v Německu

Chtějí si léčit kvasinky. Lék je jen v Německu

Podnikatel.cz: Babiš: E-shopy z EET možná vyjmeme

Babiš: E-shopy z EET možná vyjmeme

Lupa.cz: Teletext je „internetem hipsterů“

Teletext je „internetem hipsterů“

Vitalia.cz: Baletky propagují zdravotní superpostel

Baletky propagují zdravotní superpostel

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!

Lupa.cz: UX přestává pro firmy být magie

UX přestává pro firmy být magie

Vitalia.cz: Mondelez stahuje rizikovou čokoládu Milka

Mondelez stahuje rizikovou čokoládu Milka