Před třiceti lety byl Linus Torvalds 21 letým studentem na univerzitě v Helsinkách, když poprvé vydal linuxové jádro. Jeho oznámení začalo: „Dělám (bezplatný) operační systém (jen koníček, nebude to velký ani profesionální …)“. O tři desetiletí později používá 500 nejlepších superpočítačů Linux, stejně jako více než 70 % všech smartphonů. Linux se tedy stal velkým a profesionálním projektem.
Po tři desetiletí vedl Linus Torvalds vývoj linuxového jádra a inspiroval nespočet dalších vývojářů a open source projektů. V roce 2005 vytvořil Linus také Git, který pomáhal řídit proces vývoje jádra, a od té doby se stal nejpopulárnějším systémem pro správu zdrojového kódu, kterému důvěřuje nespočet digitálních projektů.
Poskládali jsme linuxový server s parametry, které odkazují na kulaté výročí.
Za jedinečnou cenu ulovíte server s parametry, který toho utáhne více než by se zdálo. Nejlepší na tom je, že si ho můžete na týden vyzkoušet zdarma. V klidu si data převedete, zprovozníte a ověříte si, že všechno funguje a až teprve poté řešíme faktury…
VPS Centrum
Vyzkoušejte zdarma naši aplikaci pro správu serveru a domén. Budete si připadat jako zkušený administrátor.
*Akce platí od 17. 9. do 17. 10 2021
Druhá část rozhovoru: Open source a osobní život
Následující rozhovor je přeložen díky webu tag1consulting.com. Linus Torvalds odpověděl na otázky e-mailem a přemýšlel o tom, co se za ta léta naučil z vedení velkého open source projektu. V této první části se zaměříme na vývoj jádra Linuxu a Git. „[Linux] byl osobní projekt, který nevyrostl z nějakého velkého snu vytvořit nový operační systém,“ vysvětluje Linus, „ale doslova vyrostl jakousi náhodou, když jsem se zpočátku pokoušel naučit vstupy a výstupy mého nového PC hardware.“
Pokud jde o vytvoření Gitu a jeho následné předání Juniovi Hamanovi za účelem zdokonalení a údržby, poznamenal Linus: „Nechci tvrdit, že programování je umění, protože ve skutečnosti jde hlavně o „dobré inženýrství“. Věřím v mantru Thomase Edisona „jedno procento inspirace a devadesát devět procent potu“: je to téměř všechno o malých detailech a každodenní práci. Existuje ale i část „inspirace a kreativních řešení“, které jsou víc než jen řešení nějakého problému – řešení čisté a pěkné.
Přečtěte si první část a vraťte se příští týden ke druhé části, kde Linus zkoumá postřehy získané za tří desetiletí v čele Linuxového jádra.
Vývoj kernelového jádra
Jeremy Andrew: Linux je všude a vždy bude inspirací pro celý open source svět. Samozřejmě to tak nebylo vždy. Linuxové jádro vyšlo v roce 1991 skromným zveřejněním na serveru Usenet na comp.os.minix. O deset let později jste napsal poutavou a osobní knihu nazvanou „Jen pro zábavu: Příběh náhodného revolucionáře“ (orig. název: Just for Fun: The Story of an Accidental Revolutionary), který pojednává o velké části této historie. Letos v srpnu oslaví Linux 30. výročí! To je úžasné, gratulujeme! V jakém okamžiku na této cestě jste si uvědomil, že Linux byl mnohem víc než „jen koníček“?
Linus Torvalds: Může to znít trochu směšně, ale ve skutečnosti se to stalo velmi brzy. Již koncem 91 roku (a určitě počátkem roku 92) se Linux stal už mnohem větším, než jsem čekal.
Freelo - Nástroj na řízení úkolů a projektů
Přidej se, pozvi svůj tým a klienty, rozděl práci a sleduj, jak se úkoly dají do pohybu.
A ano, vzhledem k tomu, že do té doby bylo pravděpodobně jen několik stovek uživatelů (a dokonce i „uživatelé“ byli příliš silní – lidé, kteří si s tím pohrávali). Asi to zní divně vzhledem k tomu, jak Linux později skončil mnohem větší, ale v mnoha ohledech pro mě osobně bylo bodem zlomu, když jsem si uvědomil, že to ostatní lidé skutečně používají a zajímají se o můj projekt, který začal mít svůj vlastní život. Lidé začali posílat patche a systém vlastně začal dělat mnohem víc, než jsem si původně ve skutečnosti představoval.
Myslím, že X11 byl portován na Linux někdy v dubnu roku 92, a to byl další velký krok, kdy najednou došlo k GUI a zcela nové sadě funkcionality.
Abych to uvedl na pravou míru – opravdu jsem nezačal s žádnými velkými plány a s velkými očekáváními. Byl to osobní projekt, který nevyrostl z nějakého velkého snu o vytvoření nového operačního systému, ale doslova vznikl nahodile, když jsem se zpočátku pokoušel naučit vstupy a výstupy mého nového PC hardwaru.
Když jsem tedy vydal úplně první verzi, šlo spíše o „pohled na to, co jsem udělal“ a doufal jsem, že to ostatní budou považovat za zajímavé, ale nebyl to skutečně seriózní a použitelný operační systém. Byl to spíše důkaz konceptu a jen osobní projekt, na kterém jsem v té době pracoval několik měsíců.
A od přechodu od „osobního projektu“ k tomu, že to bylo něco, kde to ostatní používali, posílali zpětnou vazbu a hlášení o chybách a občasné opravy, to byla pro mě velká změna.
Uvedu jen příklad něčeho opravdu zásadního: původní licence na autorská práva byla něco jako „toto můžete šířit ve zdrojové formě, ale ne za peníze“.
Bylo to proto, že komerční unix byl drahý (pro chudého studenta, který utratil všechny své peníze za nový počítač. A tak pro mě bylo velmi důležité, aby zdrojový kód byl k dispozici (aby si s ním lidé mohli hrát) a chtěl jsem, aby Linux byl otevřený lidem jako já, kteří si prostě nemohli dovolit alternativy.
A na konci roku 91 jsem změnil licenci na GPLv2, protože existovali lidé, kteří ji chtěli distribuovat na disketách místním skupinám uživatelů Unixu, ale chtěli alespoň získat zpět náklady za diskety a jejich čas při kopírování. A uvědomil jsem si, že to bylo zjevně zcela rozumné a že důležitou věcí nebyly „žádné peníze“, ale „zdroj musí být otevřeně dostupný“.
Konečný výsledek: lidé jej nejen distribuovali na schůzkách skupin uživatelů Unixu, ale k časným disketovým distribucím jako SLS a Slackware došlo během několika měsíců.
Ve srovnání s těmi počátečními opravdu zásadními změnami bylo všechno ostatní „přírůstkové“. Jistě, některé přírůstky byly docela velké (IBM přichází na palubu, Oracle DB se přenáší, Red Hat IPO, Android se zvětšuje na telefonech atd.). Ale stále byly méně osobně revoluční než ta počáteční fáze, „kde lidé, které ani neznám používají Linux “.
JA: Litujete někdy svého výběru licence nebo kolik peněz jiní lidé a společnosti vydělali na něčem, co jste vytvořil?
LT: Rozhodně ne.
Za prvé se mi vede celkem dobře. Nejsem šíleně bohatý, ale jsem dobře placený softwarový inženýr a dělám, co chci, kdy chci. Necítím se tedy poškozený.
Ale stejně důležité je, že jsem 100% přesvědčen, že licence byla velkou součástí úspěchu Linuxu (a Git, když na to přijde). Myslím, že všichni zúčastnění nakonec budou mnohem šťastnější, když vědí, že všichni mají stejná práva a nikdo není v oblasti licencování upřednostňován.
Existuje značný počet těchto projektů tzv. „duální licence“, kdy si původní majitel ponechá komerční licenci (můžete ji použít ve svém proprietárním produktu, pokud nám zaplatíte licenční poplatky) a na druhé straně je projekt také k dispozici v rámci něčeho jako GPL právě pro případy open source.
A myslím, že je opravdu těžké vybudovat komunitu kolem takovéto situace, protože strana open source vždy ví, že je to „druhá třída“. Navíc to vede k velkému množství licenčních papírů, aby si zakládající strana vždy zachovala svá zvláštní práva.
A na druhou stranu jsem viděl spoustu BSD (nebo MIT nebo podobných) licencovaných open source projektů, které se fragmentují, když se stanou dostatečně velkými, aby byly komerčně zajímavé.
Takže si myslím, že GPLv2 je do značné míry dokonalou rovnováhou „každý pracuje podle stejných pravidel“ a stále vyžaduje, aby to lidé komunitě vraceli („tit-for-tat“). A každý ví, že všichni ostatní zúčastnění jsou vázáni stejnými pravidly, takže je to všechno velmi vyrovnané a spravedlivé.
Samozřejmě, další část toho je, že dostanete i to, co jste vložili. Jistě, můžete se pokusit „sjíždět na vlnách“ projektu a být jen uživatelem, a to je v pořádku. Nemáte nad projektem žádnou kontrolu. To může být také v pořádku, pokud opravdu potřebujete pouze základní operační systém a Linux již dělá vše, co chcete. Když však máte zvláštní požadavky, jediným způsobem, jak projekt skutečně ovlivnit, je účast.
Díky tomu jsou všichni upřímní. Včetně mě. Kdokoli může projekt rozdvojit a jít vlastní cestou a říci „Bye, Bye, Linusi, přebírám údržbu mé vlastní verze Linuxu“. Jsem „zvláštní“ jen proto, že mi lidé věří, že odvedu dobrou práci. A přesně tak by to mělo být.
To, že kdokoli může udržovat svou vlastní verzi, znepokojovalo některé lidi kvůli GPLv2, ale opravdu si myslím, že je to síla, ne slabost. Trochu neintuitivně si myslím, že to vlastně způsobilo, že se Linux vyvaroval fragmentaci: každý si může z projektu vytvořit vlastní fork, a to je v pořádku. Ve skutečnosti to byl jeden z hlavních konstrukčních principů „Gitu“ – každý klon úložiště je jeho vlastním forkem.
Rozvětvování tedy není problém, pokud pak můžete dobré součásti sloučit zpět. A to je místo, kde přichází GPLv2. Právo na fork a dělat si vlastní věci je důležité, ale druhá strana mince je stejně důležitá – právo na to, aby se projekty mohli spojit, když se fork ukáže jako úspěšný.
Dalším problémem je, že opravdu chcete mít nástroje na podporu tohoto pracovního toku, ale musíte mít také přístup k jeho podpoře. Velkou překážkou spojování vidlic není jen licencování, ale také „špatná krev“. Pokud vidlice začíná z velmi antagonistických důvodů, může být velmi obtížné sloučit obě vidlice – ne z licenčních nebo technických důvodů, ale proto, že vidlice byla tak rozdílná. Znovu si myslím, že se tomu Linux vyhnul, hlavně proto, že jsme věci viděli vždy jako přirozené, a pak je také velmi přirozené pokusit se je sloučit zpět, když se nějaká práce ukázala jako úspěšná.
Moc nelituji volby licence, protože si opravdu myslím, že GPLv2 je velkou součástí toho, proč byl Linux úspěšný.
Peníze opravdu nejsou tak skvělý motivátor. To lidi nedává dohromady. Myslím, že mít společný projekt a opravdu mít pocit, že v tomto projektu skutečně můžete být plnohodnotným partnerem, je přesně tím, co lidi motivuje.
JA: V dnešní době, kdy lidé vydávají zdrojový kód pod licencí GPLv2, tak to obvykle dělají kvůli Linuxu. Jak jste našel licenci a kolik času a úsilí jste věnovali kontrole dalších licencích?
LT: V té době se lidé stále hádali o BSD vs GPL (myslím, že částečně poháněné tím, jak má RMS opravdu talent na vytáčení lidí), takže jsem viděl některé diskuse o licencích jen prostřednictvím různých diskusních skupin usenet I četl (věci jako comp.arch, comp.os.minix atd.).
Ale dva hlavní důvody byly pravděpodobně jednoduše gcc – což bylo velmi důležité pro spuštění Linuxu, protože jsem absolutně vyžadoval kompilátor C – a Lars Wirzenius („Lasu“), který byl druhým švédsky mluvícím CS studentem na univerzitě v mém ročníku (švédština je ve Finsku poměrně malá menšina).
Lasu se mnohem víc zabýval diskusemi o licencích než já.
Pro mě nebyla volba GPLv2 nějakým velkým politickým problémem, šlo hlavně o to, že moje původní licence byla tak ad-hoc a potřebovala aktualizaci a cítil jsem se vděčný gcc a GPLv2 odpovídal mému očekávání.
Namísto vytvoření další licence (nebo pouze úpravy původní licence – mohlo být řešením pouze odstranění klauzule „žádné peníze nezmění majitele projektu“ jsem chtěl vybrat licenci, o které už lidé věděli, a zapojil několik právníků .
JA: Jaký je váš typický den? Kolik z toho utratíte za psaní kódu, oproti kontrole kódu, oproti čtení a psaní e-mailů? A jak vyvažujete osobní život a práci na Linuxovém jádře?
LT: V dnešní době už píšu velmi málo kódu. Už to takto trvá docela dlouho. A když napíšu kód, nejběžnější situace je, že se diskutuje o nějakém konkrétním problému a já provedu změny a pošlu je jako opravu většinou jako vysvětlení navrhovaného řešení.
Jinými slovy, většina kódu, který píšu, je spíše „pohled, co to udělat takhle“, kde je oprava velmi konkrétním příkladem. Je snadné se ponořit do nějaké teoretické diskuse na vysoké úrovni o tom, jak něco vyřešit a já zjišťuji, že nejlepším způsobem, jak popsat řešení, je často jen napsat fragment kódu – možná ne celou věc – a prostě to udělat tímto způsobem konkrétní.
Protože veškerá moje skutečná práce je věnována čtení a psaní e-mailů. Je to hlavně o komunikaci, ne o kódování. Ve skutečnosti považuji tento druh komunikace s novináři a technickými blogery atd. za doslova součást mého pracovního dne – může mít nižší prioritu než skutečné technické diskuse, ale i tomu věnuju spravedlivou část svého času.
A ano, také trávím čas recenzemi kódu, ale upřímně řečeno, v době, kdy dostanu požadavek na kontrolu, měl by být již zkontrolován více lidmi. Takže i když se stále dívám na patche, ve skutečnosti se dívám spíše na vysvětlení a historii, jak ke mně patch přišel. A s lidmi, se kterými jsem pracoval nejdéle kontroly ani nedělám: jsou správci jejich subsystému, nejsem tam proto, abych jejich práci kontroloval.
Takže docela často je mým hlavním úkolem „být tam“, být sběrným místem a být osobou, která řídí a vynucuje vydání. Jinými slovy, moje práce je obecně více o procesu údržby než o kódu na nízké úrovni.
JA: Jaké je vaše pracovní prostředí? Například dáváte přednost temné místnosti bez rušení nebo místnosti s výhledem? Máte tendenci pracovat v tichu nebo při poslechu hudby? Jaký druh hardwaru obvykle používáte? Zkontrolujete kód s vim v terminálu nebo s fantastickým IDE? A máte pro tuto práci preferovanou distribuci Linuxu?
LT: Můj pokoj není úplně temný, ale mám zavřené žaluzie na okně vedle mého stolu, protože nemám rád jasné sluneční světlo. Takže žádné výhled, jen (špinavý) stůl s duálními monitory 4k a výkonným stolním počítačem pod stolem. A pár notebooků kolem kvůli testování, když jsem na cestách.
Chci pracovat v tichosti. Dříve jsem nenáviděl tikání mechanických diskových jednotek – šťastně dlouho odsunutých do odpadkového koše, protože už více než deset let používám výhradně SSD – a hlučné větráky CPU jsou také nepřijatelné.
A to vše se děje v tradičním terminálu, i když nepoužívám ‚vi‘. Používám tuto ohavnost zvanou „micro-emacs“, která s GNU emacs nemá absolutně nic společného, kromě toho, že některé klíčové vazby jsou podobné. Zvykl jsem si na něj na univerzitě v Helsinkách, když jsem byl malý chlapec, a nedokázal jsem se od toho odnaučit, i když tuším, že to budu muset brzy udělat. Před několika lety jsem narazil na velmi omezenou podporu utf-8, ale je vidět, že můj pomocník nebyl udržován od poloviny 90. let. 🙂
Univerzita v Helsinkách micro-emacs používala, protože fungovala na systémech DOS, VAX / VMS a Unix, a proto jsem se s tím seznámil. A teď mám na to pevně zakódované prsty. Opravdu potřebuji přejít na něco, co je ve skutečnosti udržováno a správně dělá utf-8. Pravděpodobně „nano“. Ale můj hacknutý kus historického odpadu funguje natolik dobře, že jsem nikdy nebyl nucen své staré prsty naučit nové triky.
Moje pracovní prostředí je tedy poměrně jednoduché: několik otevřených textových terminálů a webový prohlížeč s e-mailem (a několik dalších karet, většinou zpravodajské a technické weby). Chci mít spravedlivé množství prostoru na ploše, protože jsem zvyklý mít poměrně velká okna terminálu (100 x 40 je druh mé výchozí počáteční velikosti) a mám několik terminálů otevřených vedle sebe. Tedy duální 4k monitory.
Fedoru používám na všech svých počítačích, ne proto, že by to bylo nutně „preferováno“, ale proto, že jsem zvyklý. Nestarám se hluboce o distribuci – pro mě je to hlavně způsob, jak nainstalovat Linux na stroj a nastavit všechny své nástroje, abych mohl potom vyměnit jádro a pracovat jen na tom.
JA: The Linux Kernel Mailing List je místo, kde se vývoj jádra děje veřejně. Jak stíháte vyřizovat tolik e-mailů? Prozkoumali jste jiná řešení pro spolupráci a komunikaci mimo seznam adresátů, nebo existuje něco na jednoduchém seznamu adres, který je ideální pro to, co děláte?
LT: Ach, to jsem nečetl už roky. Je toho už příliš mnoho.
V dnešní době místo toho používám funkcionalitu lore.kernel.org, protože funguje tak dobře a kolem ní jsou postaveny další nástroje. Namísto toho, aby se disk automaticky archivoval v mých vlastních poštovních archivech, budou diskuse viditelné. Ale základní pracovní postup je koncepčně stejný.
Samozřejmě dostávám slušné množství e-mailů – ale v mnoha ohledech se to v průběhu let zlepšovalo spíše než zhoršovalo. Velkou součástí je Git a to, jak dobře funguje uvolnění jádra: dříve jsme měli mnohem více problémů s tokem kódu a nástroji. Moje e-mailová situace byla na přelomu století, kdy jsme stále obchodovali s obrovskými patch-bombami a měli jsme vážné problémy se škálovatelností ve vývoji, mnohem horší.
A model adresáře s nástroji kolem něj opravdu funguje velmi dobře. To neznamená, že lidé kromě e-mailu nepoužívají jiné komunikační prostředky (jak osobní kontakty, tak seznamy adresátů): existují lidé, kteří mají rádi různá nastavení chatu v reálném čase (tradiční je IRC). A i když to nikdy nebylo mojí věcí, je zřejmé, co někteří lidé rádi používají pro brainstorming. Ale tento model „seznamu adres jako archiv“ funguje velmi dobře a funguje bez problémů i s celým „odesíláním oprav mezi vývojáři jako e-maily“ a „odesíláním zpráv o problémech jako e-maily“.
E-mail tedy zůstává hlavním komunikačním kanálem a usnadňuje diskusi o technických problémech s opravami integrovanými do stejného média. A funguje to napříč časovými pásmy, což je velmi důležité, když jsou všichni geograficky tak roztažení.
JA: Od této chvíle je nejnovější vydání 5.12-rc5. Jak standardizovaný je proces vydání? Například, jaké změny se změní na -rc1, versus -rc2 atd.? A kdy se rozhodnete, že release je připraven k oficiálnímu vydání? Co se stane, když se mýlíte a po konečném vydání dojde k velké regresi a jak často se to stane? Jak se tento proces v průběhu let vyvíjel?
LT: Zmínil jsem se o tom už dříve: samotný proces je opravdu docela standardní a zůstal tak i po poslední desetiletí. Před tím prošel několika otřesy, ale ve skutečnosti to fungovalo jako švýcarské hodinky od verze 3.0 (a ve skutečnosti několik let před tím – přechod na Git byl v mnoha ohledech začátkem moderního procesu a chvíli trvalo, než si všichni zvykli).
Myslím, že jsme měli tuto kadenci „dvoutýdenního období“, po níž následovalo zhruba 6-8 týdenní okno kandidátů, které čekali na finální vydání. Takto to funguje už posledních 15 let.
A pravidla byla vždy stejná, i když nebyla vždy zcela striktně vynucována: slučovací okno je pro nový kód, který je údajně „testován a připraven“, a následující zhruba dva měsíce jsou pak na opravy a ujištění se, že jsou všechny problémy vyřešeny. Což se ne vždy stane a někdy se údajně „připravený“ kód před vydáním deaktivuje nebo dokonce vrátí k přepsání.
A pak se to opakuje – takže máme vydání zhruba každých 10 týdnů.
Podle kritérií vydání se cítím dostatečně sebevědomě, což samozřejmě závisí na tom, jaké druhy hlášení problémů stále přicházejí. Pokud některá oblast stále vykazuje problémy, jsem docela agresivní na to, abych věci vrátil a říkal „s tím se budeme zabývat v pozdějším vydání, jakmile to vyřešíme úplně“, ale celkově je to poměrně vzácné.
Vždy to vyjde? Ne. Jakmile je jádro vydáno – a zvláště když ho distribuce vyzvedne – získáte nové uživatele, získáte lidi, kteří ho během vývoje netestovali a našli věci, které nefungovaly a my jsme se během rc nezachytili. To je docela nevyhnutelné. Je to součást toho, proč máme celé stromy „stabilního jádra“, které po vydání nadále přidávají opravy. A některá stabilní jádra jsou udržována déle než jiná a jsou nazývána jádry LTS („Long Term Support“).
To vše se za posledních deset let nezměnilo, přestože nakonec máme zavedeno více automatizace. Automatizace testování jádra je obecně obtížná – částečně proto, že velkou část jádra tvoří ovladače, které pak samozřejmě závisí na dostupnosti hardwaru – ale existuje několik firem, které provádějí testování bootování i výkonu a provádějí různé náhodné testy zátěže. A to se za ta léta hodně zlepšilo.
JA: Je v jádře něco, co není optimální, ale pro správné vyřešení by bylo zapotřebí úplné přepsání? Jinými slovy, jádro je 30 let staré a znalosti, jazyky a hardware se za 30 let hodně změnily: pokud byste jej nyní přepsali úplně od začátku, co byste změnili?
LT: Ve skutečnosti jsme byli opravdu dobří v tom, že jsme dokonce kompletně přepsali věci, pokud to bylo nutné, takže vše, co by bylo bezprostřední katastrofou, bylo již dávno přepsáno.
Jistě, máme slušné množství vrstev „kompatibility“, ale obvykle nejsou hrozné. A není jasné, zda by i tyto vrstvy kompatibility by při přepisování od začátku skutečně zmizely – jde o zpětnou kompatibilitu se staršími binárními soubory (a často o zpětnou kompatibilitu se staršími architekturami, např. Spouštění 32bitových aplikací x86 na x86-64). Jelikož považuji zpětnou kompatibilitu za velmi důležitou, chtěl bych je udržovat i v přepsání.
Je tedy zřejmé, že existuje spousta věcí, které „nejsou optimální“ v tom smyslu, že lze něco vylepšit, ale při formulování odpovědi musím říci, že ne, není tam nic, čím bych opovrhoval.
Existují starší ovladače, o které se nikdo nikdy nebude dostatečně starat, a tak mohou systému házet klacky pod nohy. Nebyl to problém, a když se z něj stane problém, máme tendenci poměrně aktivně odstraňovat podporu starších verzí ovladače, protože nemůžeme najít nikoho, kdo by to udržoval aktuální. Za ta léta jsme se tedy zbavili spousty ovladačů a zbavili jsme se podpory celé architektury, když jí již nemá smysl udržovat.
Jediným hlavním důvodem pro „přepsání“ by bylo, kdybyste nakonec měli nějaký případ použití, kdy celá struktura už nemá smysl. Nejpravděpodobnějším scénářem by byl nějaký malý vestavěný systém, který prostě nechce všechno, co Linux nabízí, a má hardwarovou stopu tak malou, že prostě chce něco menšího a jednoduššího, než to čím se Linux za ta léta stal, protože Linux hodně vzrostl. Dokonce i malý hardware (myslím, že mobilní telefony atd.) Je dnes mnohem schopnější než původní stroj, na kterém byl Linux vyvinut.
JA: A co přepsat alespoň části pomocí Rustu, jazyka, který byl speciálně navržen pro výkon a bezpečnost? Existuje prostor pro zlepšení tímto způsobem? Máte pocit, že je někdy možné, aby v jádře nahradil C jiný jazyk, jako je Rust?
LT: Uvidíme. Nemyslím si, že Rust převezme jádro kernelu, ale dělat jednotlivé ovladače (a možná celé podsystémy ovladačů) v něm nezní úplně nepravděpodobně. Možná i souborové systémy. Není to tedy „nahradit C“, ale spíše „rozšířit náš C kód tam, kde to dává smysl“.
Ovšem zejména ovladače tvoří zhruba polovinu skutečného kódu jádra, takže je na to spousta prostoru, ale nemyslím si, že by někdo opravdu očekával přepsání stávajících ovladačů na Rust, spíše „někteří lidé udělají nové ovladače v Rustu a pár ovladačů může být přepsáno tam, kde to dává smysl “.
Ale právě teď je to spíše „lidé to zkouší a hrají si s tím“, spíše než cokoli jiného. Je snadné poukázat na výhody, ale určitě existují i složitosti, takže velmi využívám přístup vyčkávání, abych zjistil, zda se slíbené výhody skutečně projeví.
JA: Existují nějaké konkrétní části jádra, na které jste osobně hrdý?
LT: Mezi výjimečné části, na které mám sklon poukazovat, patří vrstva VFS „virtuální souborový systém“ a zejména vyhledání cesty a náš kód VM. První z nich, protože Linux prostě dělá některé z těchto základních věcí, mnohem lépe než cokoli jiného. A to hlavně proto, že podporujeme více než 20 architektur a stále to děláme s převážně jednotnou vrstvou VM, což je podle mě docela působivé.
Ale zároveň je to do značné míry funkce „o jakou část jádra se staráte“. Jádro je dostatečně velké, že různí vývojáři (a různí uživatelé) budou mít jednoduše odlišné názory na to, na čem záleží nejvíce. Někteří lidé si myslí, že plánování je nejzajímavější částí jádra. Jiným se líbí hloupost ovladačů zařízení (a máme jich spoustu). Osobně mám tendenci se více angažovat v oblastech VM a VFS, takže na ně potom přirozeně poukazuji.
JA: Našel jsem tento popis vyhledávání cesty a je složitější, než jsem čekal. V čem je implementace Linuxu mnohem lepší než v jiných operačních systémech? A co myslíte tím „lepším“?
LT: Hledání cesty je opravdu tak běžná a zásadní věc, že většina lidí mimo vývojáře jádra o tom ani nepřemýšlí jako o problému: pouze otevírají soubory a berou to jako samozřejmost.
Ale ve skutečnosti to je komplikované dělat opravdu dobře. Přesně proto, že absolutně všechno neustále vyhledává cestu, je to nesmírně důležité pro výkon a je to jedna z těch oblastí, kde také chcete dobře škálovat v prostředích SMP a má spousty složitosti při zamykání. A moc nechcete dělat žádné I/O, takže ukládání do mezipaměti je velmi důležité. Hledání cesty je ve skutečnosti tak důležité, že ji nemůžete nechat na nízkoúrovňovém souborovém systému, protože máme více než 20 různých souborových systémů a mít každý z nich vlastní ukládání do mezipaměti a jeho vlastní uzamčení, by byla úplná katastrofa.
Jednou z hlavních věcí, kterou vrstva VFS dělá, je tedy opravdu zvládnout veškeré zamykání a ukládání do mezipaměti komponent cest, zvládnout veškerou serializaci a procházení přípojného bodu, a to vše pomocí většinou bezzámkových algoritmů (RCU), ale také pomocí některé opravdu chytré věci podobné zámku (zámek „lockref“ v linuxovém jádře je velmi speciální „spinlock s počtem odkazů“, který byl doslova navržen pro ukládání do mezipaměti dcache, a je to v podstatě specializovaný počet referencí s ohledem na zámek, který dokáže zámku provést pro některé běžné situace).
Konečný výsledek: nízkoúrovňové souborové systémy stále musí provádět skutečné vyhledávání věcí, které nejsou uložené v mezipaměti, ale nemusí se starat o ukládání do mezipaměti a všechna pravidla soudržnosti a pravidla atomicity, která jsou součástí vyhledávání cest. To vše za ně zpracovává VFS.
A to vše překonává cokoli, co udělal jakýkoli jiný operační systém a v zásadě se dokonale přizpůsobí strojům s tisíci CPU. A dělá to tak, že i když se všechny tyto stroje nakonec dotknou stejných adresářů (protože věci jako kořenový adresář nebo domovský adresář projektu jsou věci, které se dokonce i silně podprocesní aplikace dotýkají najednou a které se nedistribuují na jakýkoli druh chování na vlákno).
Není to tedy jen „lepší“, je to „Lepší“ s velkým „L“. Nic jiného se tam ani nepřiblíží. Linuxová dcache je prostě třída.
JA: Minulý rok byl na celém světě obtížný. Jak pandemie COVID-19 ovlivnila proces vývoje jádra?
LT: Ve skutečnosti to mělo velmi minimální vliv, protože jsme vždy pracovali z domova. E-mail je skutečně skvělý nástroj a nespoléhali jsme se na osobní schůzky.
Pandemie ovlivnila loňský summit jádra a tento rok je stále ve vzduchu. Většina konferencí byla zrušena nebo změněna na virtuální. Lidé, kteří předtím pracovali v kancelářích, začali pracovat z domova (ale mnoho správců jádra to již dělalo). Hodně věcí kolem se změnilo, ale samotný vývoj jádra fungoval přesně jako dříve.
A samozřejmě to ovlivnilo celý náš život jinými způsoby – jen sociálními důsledky obecně. Ale celkově jsem jako vývojář jádra, který již s lidmi komunikoval téměř výhradně prostřednictvím e-mailu, byli pravděpodobně jedny z nejméně postižených.
Git – Systém řízení distribuované verze
JA: Linux je pouze jedním z vašich všudypřítomných příspěvků do open source. V roce 2005 jste vytvořil Git, velmi populární distribuovaný systém pro správu zdrojového kódu. Rychle jste migrovali zdrojový strom jádra Linuxu z proprietárního Bitkeeper a do nově vytvořeného a otevřeného Gitu a ve stejném roce jste předali údržbu Junio Hamanovi. Je tam spousta fascinující historie, co vás vedlo k tomu, abyste tak rychle odevzdali vedení v tomto projektu, a jak jste našli a vybrali Junia?
LT: Tato odpověď má tedy dvě části.
První část spočívá v tom, že se mi moc nechtělo vytvářet nový systém. Linux byl vytvořen, protože mi připadá fascinující rozhraní na nízké úrovni mezi hardwarem a softwarem – je to v podstatě práce z lásky a osobního zájmu. Naproti tomu Git byl vytvořen z nutnosti: ne proto, že mi připadalo zajímavé programovat správce zdrojového kódu, ale proto, že jsem absolutně opovrhoval ostatními správci. BitKeeper jsem považoval za nejlepší a pro Linux fungoval opravdu dobře. Bohužel, jak Linux rostl, tak BitKeeper přestal dostačovat.
Konečný výsledek: Dělám Linux více než 30 let (do výročí prvního vydání zbývá ještě pár měsíců, ale začal jsem s tím, co by se Linuxem stalo již před 30 lety) a udržuji ho celý čas.
Ale Git? Nikdy jsem si nemyslel, že to opravdu budu chtít dlouhodobě udržovat. Rád ho používám a očividně si myslím, že je to nejlepší SCM ve světě, ale není to moje základní vášeň a zájem, pokud chápete, co se snažím říct.
Takže jsem vždycky chtěl, aby SCM pro mě udržoval někdo jiný – ve skutečnosti bych byl nejšťastnější, kdybych ho vůbec nemusel programovat.
Pokud jde o Junia - byl jedním z prvních lidí, kteří přišli jako vývojáři k Gitu. Jeho první úprava kódu přišla během několika dní poté, co jsem zveřejnil úplně první a velmi hrubou verzi Gitu. Junio tedy ve skutečnosti už od začátku v Gitu existuje.
Ale není to tak, že jsem projekt předal prvnímu náhodnému člověku, který se objevil. Udržoval jsem Git několik měsíců a to, co mě přimělo zeptat se Junia, jestli chce být správcem, je ta velmi těžko popsatelná představa „dobrého vkusu“. Opravdu k tomu nemám lepší popis: programování je o řešení technických problémů, ale důležité je také to, jak je řešíte a jak o nich přemýšlíte, a je to jedna z věcí, které postupem času začínáte uznávat: určití lidé mít tu „dobrou chuť“ a vybrat „správné“ řešení.
Nechci tvrdit, že programování je umění, protože ve skutečnosti jde hlavně o „dobré inženýrství“. Velmi věřím v mantru „jednoprocentní inspirace a devadesát devět procent potu“ Thomase Edisona: jde téměř o malé detaily a každodenní gruntování. Ale je tu ta příležitostná „inspirační“ část, ta „dobrá chuť“, která není jen o řešení nějakého problému – ale o jeho čistém a pěkném řešení.
A Junio měl ten „dobrý vkus“.
A pokaždé, když přijde na řadu Git, snažím se nezapomenout na to, aby to bylo velmi jasné: možná jsem začal a navrhoval základní myšlenky v Gitu, ale často mám za tu část velkou zásluhu. Je to už více než 15 let a já jsem se do toho Gitu zapojil jen ten první rok. Junio byl příkladným správcem a je to on, kdo z Gitu udělal to, čím je dnes.
Btw, celá ta věc „dobrého vkusu“ a hledání lidí, kteří ho mají, a důvěřování jim – to do značné míry není jen o Gitu. Je to také historie Linuxu. Na rozdíl od Gitu je Linux očividně projekt, který stále aktivně udržuji, ale podobně jako Git je to také projekt se spoustou dalších zapojených lidí a myslím, že jedním z velkých úspěchů Linuxu jsou doslova stovky správců, to vše s těžko definovatelným „dobrým vkusem“ a se všemi lidmi, kteří udržují části jádra.
JA: Dali jste někdy kontrolu správci, abyste později zjistili, že to bylo špatné rozhodnutí?
LT: Naše struktura údržby nikdy nebyla tak černobílá a nepružná, že by z toho někdy byl problém. Ve skutečnosti to není tak, že bychom dokonce umožnili, aby kontrola údržby byla něco velmi zdokumentovaného: máme soubor MAINTAINERS, ale je to proto, abyste našli ty správné lidi, není to vlastně známka nějakého výlučného vlastnictví.
Takže celé „kdo vlastní co“ je spíše tekutým vodítkem a „tato osoba je aktivní a dělá dobrou práci“ než nějaká „oops, nyní jsme této osobě dali vlastnictví a pak se to pokazilo“.
A je to plynulé také v tom smyslu, že jste možná správcem jednoho subsystému, ale pokud existuje něco, co potřebujete z jiného subsystému, můžete často překračovat hranice. Obvykle je to něco, o čem lidé samozřejmě hodně mluví, ale jde o to, že se to opravdu děje a není to žádný tvrdý druh pravidla „měl by ses dotknout pouze tohoto souboru“.
Ve skutečnosti to do jisté míry souvisí s dřívější diskusí o licencování a dalším příkladem toho, jak jedním z konstrukčních principů „Gitu“ bylo, že „každý má svůj vlastní strom a žádný strom není technicky speciální“.
Protože spousta dalších projektů použila nástroje – jako CVS nebo SVN – které zásadně dělají některé lidi zvláštními a které zásadně mají „vlastnictví“, které k tomu patří. Ve světě BSD tomu říkají „odevzdat bit“: To znamená, že má nyní povoleno odevzdat se do centrálního úložiště (nebo alespoň jeho částí).
Ten model jsem vždycky nenáviděl, protože nevyhnutelně vyústí v politiku a „klikový“ model rozvoje, kde jsou někteří lidé zvláštní a implicitně důvěryhodní. A problémem není ani ta „implicitně důvěryhodná“ část – je to ve skutečnosti to, že jiným lidem nedůvěřují a jsou ze své podstaty cizími osobami.
V Gitu opět taková situace neexistuje. Všichni jsou si rovni. Kdokoli může udělat klon, dělat svůj vlastní vývoj, a pokud odvede dobrou práci, může se znovu sloučit (a pokud odvede vynikající práci, stane se z něj správce a nakonec bude jedním z těch, kdo to spojuje do vlastních stromů.
Není tedy nutné dávat lidem zvláštní privilegia – není třeba používat „odevzdávací bit“. A to také znamená, že se vyhýbáte politice kolem ní a nemusíte lidem implicitně důvěřovat. Pokud nakonec udělají špatnou práci – nebo častěji, jen se vytratí a najdou jiný zájem – nedostanou se zpět do spojení a také jim nebudou bránit ostatní lidé, kteří mají nové nové nápady.
JA: Zapůsobily na vás někdy nové funkce Gitu a staly se součástí vašeho pracovního postupu? Existují funkce, které byste přesto chtěl přidat ještě navíc?
LT: Můj use-case byl zjevně první, který byl splněn, takže u mě zřídka šlo o nějaké nové funkce.
V průběhu let se Git určitě zlepšil a některé funkce našli místo i v mém pracovním postupu. Například Git byl vždy poměrně rychlý – byl to nakonec jeden z mých designových cílů – ale hodně z toho bylo původně vytvořeno jako shell-script kolem některých základních pomocných programů. Za ta léta většina tohoto skriptování zmizela a to znamená, že mohu použít patch-bomby od Andrewa Mortona ještě rychleji, než jsem původně dokázal. Což je velmi potěšující, protože to byl vlastně jeden z prvních benchmarků, které jsem použil pro testování výkonu.
Git pro mě tedy vždy byl dobrý, ale samozřejmě se s časem zlepšuje.
Závěr, část první
Ve druhé části tohoto rozhovoru Linus hovoří o tom, co se naučil při řízení velkého projektu s otevřeným zdrojovým kódem. Poskytuje správcům mnoho informací a rad o tom, co pro něj nejlépe funguje a jak se vyhnout vyhoření. Mluví také o Linux Foundation a o tom, co dělá, když se nezaměřuje na vývoj linuxového jádra.
