Dobrý den. Když se připravuji na rozhovor, obvykle použiji Google, abych se o dané osobnosti dozvěděl nějaké informace. Ve vašem případě jsem narazil na několik článků na serveru Root.cz, dokument o matematické analýze (trošku jsem zavzpomínal), seznam přispěvatelů do GNU GPL anglicko-českého slovníku a LKML. Jak jste se dostal k Linuxu a k vývoji jádra?
K Linuxu jsem se dostal ve čtrnácti letech. Na stroj mi ho nainstaloval rodinný přítel, který dodnes spravuje svoji vlastní distribuci Linuxu (a jejíž klon stále používám). Jednou ze základních věcí, které mne tehdy naučil, bylo i jak si přeložit vlastní jádro.
Když jsem chtěl jednou na konzoli posunout kurzor doprostřed obrazovky a vypsat barevně nějaký text, odkázal mne na zdrojáky kernelu, ať si to tam najdu sám. (Zkuste si to i vy.) A to byla nakonec snad ta nejcennější věc, kterou mě naučil - nebát se dívat do cizích zdrojáků, umět v nich efektivně hledat, rychle jim porozumět a tak je i dokázat snadno upravit dle obrazu svého.
Zároveň jsem se tím chtě nechtě seznámil s tím, jak je zdrojový kód kernelu (tehdy 2.1.113) zorganizován, a postupně jsem si v něm začal číst, jak to vlastně dělají...
Čím se živíte a na čem v současné době pracujete (z hlediska Linuxu)?
Pracuji na částečný úvazek jako síťový administrátor na univerzitě a píši specializovaný software pro GTS/Novera. V budoucnu bych se ale rád věnoval čistě programování svobodného software pod Linuxem, tedy v podstatě aby mi někdo platil za to, co nyní dělám pouze ve svém volném čase. To se mi doufejme snad již brzy splní...
Každý si může přečíst seriál o SCM na serveru Root.cz, který jste napsal. Co vás přimělo zabývat se tak detailně systémy SCM?
Hledal jsem již před několika lety něco lepšího než CVS pro vývoj ELinksu, zkusil jsem několik systémů a zjistil jsem, že nic pořádného zatím neexistuje - sice byla řada systémů, které byly bezesporu lepší než CVS, ale ne o tolik, aby stálo za to na ně přecházet. Alespoň jsem se rozhodl sepsat své zkušenosti do seriálu pro Root.cz, nakonec jsem se však dostal jen k tomu, abych pořádně popsal RCS a CVS. Snad si někdy najdu čas na pokračování.
Tak jsem se rozhodl, že mám už poměrně jasnou představu, jak by to celé mělo nejlépe fungovat, a že si napíšu vlastní systém. Jmenoval se PaVS a po chvíli jsem ho opustil - jednak jsem pak měl méně času, a zároveň jsem se dopustil "overengineeringu" - naplánoval jsem si ho tehdy moc grandiózně, místo toho, abych začal s něčím jednoduchým, co by již brzy mohlo mít nějaké základní rysy použitelnosti. Když jsem si teď na LKML všiml Gitu, dá se říci, že jsem vycítil druhou šanci.
Ani se mi nechce věřit, že Linus dlouhou dobu nepoužíval žádný SCM. Pak přišel BitKeeper. Nemyslíte, že to byl takový Larryho záměr vytvořit BitKeeper s jeho specifickou licencí? Proč se Linus rozhodnul pro BitKeeper?
Nebyl jsem u toho, ale podle zmínek, které se během let objevily na LKML, soudím, že Larry na BitKeeperu pracoval skutečně od počátku jako na čistě komerčním projektu - vycítil obrovskou díru na trhu (která není dodnes zcela zacelená) a rozhodl se ji využít. Opustil svoji tehdejší práci, založil si firmu a za tři roky přišel se skvěle funkčním a velmi promyšleným produktem.
Já osobně na tom nevidím nic špatného a je otázka, jak dlouho by trvalo open-source konkurenci dostat se tam, kde je teď, kdyby nebylo BitKeeperu. Ne že by třeba vyloženě ostatní SCM systémy kradly návrh či nápady BitKeeperu.
Myslím, že významná role BitKeeperu byla pro ostatní systémy zejména motivační. Jednak ukázal, co všechno jde dělat a jak to krásně funguje, a jednak myslím - ať už otevřeně nebo "podvědomě" - jeden z hlavních cílů konkurence byl vyrovnat se BitKeeperu.
V jistém smyslu Larry navrhl BitKeeper speciálně pro Linux Kernel; dá se ostatně říci, že jádro Linuxu je z mnoha hledisek pro SCM nástroje extrémním případem - jde o poměrně rozsáhlý projekt s vysokou frekvencí změn, ale také velmi distribuovaným vývojem. Své větve mají desítky lidí, kteří si mezi sebou poměrně čile vyměňují různé patche a zároveň je posílají výše po žebříčku správců různých částí jádra. Myslím, že Larry si prostě řekl něco jako: "Pokud BitKeeper zvládne tohle, zvládne všechno."
Linus proto byl při samotném navrhování BitKeeperu - několik hodin kreslili na podlaze po papírech, až nakonec Linus řekl: "Ok, pokud tohle uděláš a bude to takhle fungovat, budu to používat." A to se stalo - navíc v době, kdy si dost lidí začalo stěžovat na to, že Linus je přetížený a že tehdejší model není již dlouhodobě udržitelný. Dodnes si pamatuji na tehdejší olbřímí LKML thread "Linus does not scale".
Existovaly před BitKeeperem i jiné distribuované SCM, nebo byl BK první?
Nejsem přes historii SCM expert, ovšem tuším, že v té době již asi existovala Vesta a Aegis (o kterém kdosi trefně poznamenal, že má všechny vlastnosti, uživatelskou přívětivost a jednoduchost na naučení jako Boeing 747).
Čím se BK liší od jiných SCM?
Je vyzrálý, distribuovaný, relativně jednoduchý, snadno použitelný, dobře zdokumentovaný, rychlý a umí velmi dobře mergovat. Takovou kombinaci budete kromě BK zatím bohužel asi hledat těžko.
Proč by byl standardní (centralizovaný) SCM pro vývoj jádra nevhodný? Vždyť mnoho velkých projektů využívá s úspěchem například CVS.
Ano, pokud považujete za úspěch to, že se to celé ještě úplně nerozložilo a přes veškerá úskalí se daří vývojářům s CVS stále pracovat. ;-)
Linux byl od počátku výjimečný tím, že jeho vývoj byl velmi decentralizovaný (modelový bazaar), a zároveň šlo o velmi rozsáhlý projekt. Pokud pracujete na fetchmailu, můžete to dělat decentralizovaně a stále to držet na uzdě a používat centralizovaný SCM systém. Pokud jste správce nějakého subsystému a žonglujete se stovkami patchů, které nějak musíte dostat přes Linuse, je to horší. Zároveň si totiž Linus vyhrazuje neomezenou kontrolu nad tím, co do jeho větve kernelu přijde. Nemůžete tedy prostě udělat CVS repository, kam pár desítek lidí commituje hlava nehlava. Tedy můžete, ale bude to fungovat asi ještě hůře, než když si všichni navzájem prostě posílají patche.
Má vůbec smysl prodávat BitKeeper jako komerční produkt? Vždyť mnoho projektů, u kterých je nutno vést takto distribuovaný vývoj, snad ani v komerční sféře není, nemyslíte?
Nejsem manažer ani nepracuji na žádném větším komerčním projektu, ale myslím, že i pro firmy může být decentralizovaný styl vývoje užitečný, pokud máte po celém světě několik vývojových laboratoří, občas chcete posadit nějakého vývojáře s notebookem do letadla a chcete po něm, aby pracoval, nebo pokud na různých částech produktu dělají různé týmy, které jednou za čas sesynchronizujete.
Něco se šuškalo o tom, že se Andrew (autor Samby) začal snad "vrtat" v BitKeeperu. Údajně, nebo opravdu? Začal pracovat na nějakém projektu emulujícím BitKeeper?
Andrew Tridgell (tridge) začal před nějakou dobou pracovat na SourcePulleru, což je de facto nástroj na "vytahování" zdrojáků z BitKeeperu, včetně plnohodnotné historie. Sice existovala brána z BitKeeperu do CVS, v tomto exportu ovšem chyběly některé klíčové informace, proto nebyl příliš dobře prakticky použitelný pro převod historie z BitKeeperu do nějakého jiného podobně pokročilého systému.
Andrew "rozluštil" protokol BitKeeperu i formát, ve kterém ukládá soubory, to se ale ani trochu nelíbilo Larrymu McVoyovi (autorovi BitKeeperu) a v konečném důsledku to vedlo právě i k tomu, že Larry stáhl bezplatnou licenci pro používání BitKeeperu pro vývoj open-source projektů, tedy i linuxového jádra - proto koneckonců Linus vytvořil Git - nemohl už používat BitKeeper.
Je to ale celé poněkud tragikomické, vzhledem k tomu, že protokol BitKeeperu není nic nějak zvlášť tajemného (dokonce přátelsky odpoví na příkaz "help" seznamem příkazů včetně krátkého popisu) a použitý formát je de facto SCCS, třicet let starý napůl zapomenutý formát na ukládání historie souboru - účelem podobný RCS, ovšem postavený na jiných principech. Samozřejmě BitKeeper dělá ještě spoustu věcí navíc, ale podle všeho se ukázalo, že ty základní principy nejsou nic převratného, jen šlo vlastně hlavně o to, objevit znovu onen polozapomenutý stařičký formát a přizpůsobit ho současným potřebám.
Na podobném softwaru jako Andrew pracoval před nějakou dobou i Pavel Machek, ovšem pokud vím, práci pak přerušil, a nevím, jak daleko se vlastně dostal. Na Andrewově software je zajímavé to, že si sám dokáže stáhnout obsah repository z bkbits.net a pak jeho obsah plnohodnotně včetně veškeré historie vyexportovat do nějakého dobře zpracovatelného formátu. Je ale vlastně otázka, jak moc se bude jeho software používat, vzhledem k tomu, že nyní postupně všechny open-source projekty BitKeeper opouštějí. Proto je mnohem důležitější přínos to, že nyní víme, jak vlastně BitKeeper funguje a některé dobré nápady můžeme zužitkovat, a možná v konečném důsledku bude jako přínos i to, co tento software rozpoutal.
Teď vlastně hájím Andrewa, ale zároveň se domnívám, že je oprávněná i Linusova kritika. Tomu se nelíbilo, co Andrew způsobil, když přitom neměl v úmyslu vytvořit plnohodnotnou náhradu za BitKeeper, ale jen nástroj pro export informací, a nezdálo se mu to jako dostatečný důvod pro to, jít proti Larrymu a způsobit stažení BK licence. Osobně bych asi v Andrewově kůži volil opatrnější postup.
Hodně jsme o BitKeeperu s Andrewem mluvili na IRC a ukazuje se, že právě tento formát dává z velké části BitKeeperu tak dobré mergování - to je v dnešní době hlavní problém, na kterém různé systémy pro správu verzí dělají. Bohužel Git/Cogito touto cestou alespoň v nejbližší době jít nemůže, protože by vyžadoval změnit některé základní principy, na kterých je Git postavený. To se v budoucnu klidně může stát, ale v nejbližší době máme jiné priority.
Po celé aféře začal Linus hledat alternativu. Nejprve zcela zavrhl systémy jako CVS, Subversion nebo GNU Arch, poté zvažoval Monotone. Proč se nakonec rozhodl tak, jak se rozhodl?
Pokud se podíváte na Git a víte něco o Monotone, všimnete si jistě řady podobností, které jistě nejsou čistě náhodné. Linusovi se dle všeho Monotone opravdu líbilo, ovšem jedna závažná vada na kráse byla rychlost - pro projekt rozsahu linuxového kernelu by některé operace trvaly doslova roky. Je třeba říci, že vývojáři Monotone problém ihned začali řešit a poměrně brzy došlo k výraznému zrychlení, ovšem to již začal Linus pracovat na Gitu a pokud vím, Monotone je stále v porovnání s Gitem příliš pomalé.
Linus se dostal během několika dnů do situace, kdy potřeboval přejít z BitKeeperu na jiný SCM, a to prakticky okamžitě - nemohl čekat dalších několik týdnů či měsíců, než se nějaký konkurenční systém dostane do stavu, kdy je prakticky použitelný pro vývoj jádra. Proto se rozhodl napsat si prozatím jednoduchý nástroj, který by kladl maximální důraz na rychlost a jednoduchost, s tím, že z jeho formátu bude možno snadno později přejít na jiný SCM.
Po nějaké době velmi bouřlivého vývoje se však ukázalo, že Git je (vlastně zejména díky své původní jednoduchosti) velice zajímavá platforma pro vývoj relativně velmi mocného SCM systému, a zároveň Git již v té chvíli uměl prakticky všechno to, co kdy Linus chtěl po BitKeeperu.
Kdo všechno na Gitu pracoval? Jen Linus, nebo mu i jiní developeři posílali patche?
Třeba já... :-) Ale jinak se do vývoje poměrně brzy zapojili i někteří jiní jaderní vývojáři i někteří developeři, kteří toho asi do kernelu také mnoho nedělají. Asi nejvýznamněji přispěli Junio C. Hamano a Daniel Barkalow. Celkem přispělo něco kolem třicítky lidí, valná většina však jen několika záplatami.
Nástroj Git prý napsal za pár dnů. Jaká je architektura tohoto programu, je napsán v jazyce C?
Jedná se o sadu malých a poměrně jednoduchých nástrojů sloužících k manipulaci s různými částmi Gitu na relativně nízké úrovni. Vše je psáno v čistém C, vyjma přibalené vysoce zoptimalizované implementace počítadla SHA1 pro PowerPC, která je psána v assembleru.
V distribuci Gitu naleznete i několik shellových skriptů, ty však striktně vzato nejsou součástí Gitu samotného, ale slouží jen pro zautomatizování některých častých úkonů.
Znamená vaše odpověď, že Linus používá Mac?
Linus pokud vím používá skutečně Apple Macintosh - samozřejmě s Yellow Dog Linuxem, nikoliv se systémem MacOS. ;-)
Podle souboru README se nejedná o SCM program. Co to vlastně je a k čemu je to normálnímu smrtelníkovi dobré?
Když řeknu, že Git je v podstatě filesystem, většina lidí se teď vyděsí s tím, že jde o nějaký modul do jádra apod. Git však nemá s jádrem nic společného, jde o normální uživatelský program. Jde vlastně o souborový systém adresovatelný obsahem. Tedy když chcete z Gitu dostat nějaký soubor, neřeknete si o něj jménem, ale tím, co obsahuje. Obsah popíšete pomocí SHA1 hashe, což je metoda "silné kryptografie", která zjednodušeně řečeno ze souboru vycucne obsah a shrne ho do čtyřicetipísmenného kódu, který pak můžeme použít právě na adresování souborů podle jejich obsahu. Mnoho lidí znervózňuje možnost kolize, tedy že dva soubory s různým obsahem bude vyjadřovat stejný čtyřicetipísmenný kód. Naštěstí pravděpodobnost takové kolize je v běžném případě tak nízká, že by vás v takovém případě měla asi mnohem více znervózňovat možnost, že vám procesor řekne, že 1+1=3, nebo vám na serverovně přistane menší asteroid.
Samozřejmě tohle není celý Git, jde ale o jeho klíčový princip. Pro běžné smrtelníky-programátory může být Git zajímavý jako backend pro ukládání vlastních dat, ovšem mezi jeho cíle rozhodně nepatří uživatelská přívětivost. Proto práce s ním probíhá na relativně nízké úrovni a člověk musí zkrátka vědět, co dělá.
K čemu tedy Git používá Linus?
K vývoji Gitu a jádra. Git je nyní již v ostrém provozu a postupně na něj přecházejí správcové jednotlivých částí jádra. (Zde volně zaměňuji Cogito a Git - Cogito dokáže pracovat s jakýmkoliv gitovským repository a naopak, je tedy věcí každého, co si vybere. Pokud vím, většina vývojářů v současnosti používá Cogito, Linus samotný pak jakýsi mix Cogita a Gitu samotného.)
Co všechno dneska s Gitem mohou dělat uživatelé? Je jim Git k něčemu dobrý?
Práce s Gitem samotným je poměrně náročná. Git je natolik univerzální nástroj, že je jistě jen otázkou času, než se objeví jeho různá kreativní využití pro účely, které nemají s SCM nic společného, a na některé z nich může stačit strohé uživatelské rozhraní Gitu. Jako SCM je však přímo Git použitelný zřejmě jen pro opravdu hardcore uživatele.
Co si mám pod kreativním využitím představit?
To je právě to - systém by měl být navržen tak, aby dobře podporoval jakékoliv využití, hlavně to, které si představit nedovedete - nebo vás prostě nenapadne. Můžete si v u udržovat třeba maildirovou poštovní schránku (s tím přišel někdo na mailing listu, mě by to tedy nenapadlo).
Zvládne Git manipulaci i s binárními soubory?
V zásadě bez problémů, až na generování diffů - je ale otázka, jak to v takovém případě elegantně řešit; není to ale akutní otázka. V Cogitu byste měli navíc asi potíže při automatickém mergování binárních souborů (to Git sám o sobě neřeší).
Jste autorem programu Cogito (dříve git-pasky). Jedná se o nadstavbu, díky které se Git chová jako SCM. Mám pravdu?
Přesně tak. Cogito obaluje nízkoúrovňové příkazy Gitu (snad) uživatelsky přítulným rozhraním, takže v ideálním případě nemusí uživatel s Gitem samotným vůbec přijít do styku.
V současnosti by Cogito již mělo nabídnout podobné uživatelské rozhraní jako např. CVS nebo Subversion, i když zde jsou samozřejmě významné odlišnosti vyplývající z distribuované povahy Gitu.
Předtím jste mi nahrál na otázku tím, že jste se zmínil, že i Linus používá jistým způsobem Cogito. Je to pro vás určité zadostiučinění? Kolik práce jste do toho investoval?
Úplným zadostiučiněním by pro mě bylo, kdyby Linus používal Cogito se vším všudy. ;-) Jsem ale rád, že mu tu práci usnadňuje alespoň částečně.
Investoval jsem do toho několik týdnů poměrně intenzivní práce, ale ta by se mi asi bohatě vrátila, i kdyby Linus Cogito vůbec nepoužíval. Jednak ho totiž již používá mnoho jiných lidí, a přinejmenším jsem získal řadu nových zkušeností.
Nenapadlo vás ani na vteřinu, že byste Cogito vydal pod jinou než svobodnou licencí?
Ani na vteřinu. :-) Jednak si osobně myslím, že tento typ aplikací se mnohem efektivněji dá vyvíjet jako svobodný software (a je tak i více "obecně prospěšný"), a i kdybych si na něm chtěl někdy vydělávat na živobytí, to se dá i na svobodném software. Navíc zde by to už vůbec nedávalo smysl, když Git je svobodný software, navíc by Cogito nikdo (přirozeně) nechtěl používat a prostě by paralelně vznikla jeho svobodná alternativa, která by se vyvíjela mnohem rychleji.
Proč se jedná o úpravu programu Git a ne o programy/skripty, které by volaly příkazy Gitu?
Cogito samotné je sada skriptů, které volají příkazy Gitu. V současnosti ve své distribuci obsahuje i Git samotný s jistými úpravami, které však nejsou zásadního rázu a je pravděpodobné, že ve chvíli, kdy budete číst tento článek, už budou součástí i Linusova Gitu.
Je tedy možné již dnes použít Cogito jako plnohodnotný SCM?
Myslím, že Cogito by nyní již mělo být normálně použitelné pro každodenní práci, jsou zde však ještě některé ostré hrany, které je třeba obrousit, a dokumentace je také poněkud strohá. Zatím tedy stále jen pro odvážné.
Díky za rozhovor.
I já děkuji.