Názory k článku
Linus Torvalds o zařazení podpory jazyka Rust do jádra

Naopak - hned poznáš prasata :)

Moc nerozumím, co konkrétně ti vadí? Že bude v kernelu nějaký jiný jazyk než C, tozn. třeba Rust? To je přece technikálie, na funkci kernelu to nemá přímý vliv. Pokud tam Rust bude, tak z dobrých důvodů, protože dokáže ulehčit práci vývojářům nebo zlepšit kvalitu výsledného produktu. To zatím nevíme, teprve se to ukáže. Podporu dalších architektur mimo x86 a ARM je možné v budoucnu celkem jednoduše vyřešit např. frontendem pro gcc, na tom se také pracuje: https://opensrcsec.com/open_source_security_announces_rust_gcc_funding

Rust fanklub přistupuje narozdíl od tebe k problému naprosto pragmaticky. Oni vědí, že napsat kernel znovu je práce na několik desetiletí a nechtějí se do tak velkého projektu pouštět, nemají na to prostředky. Zároveň vědí, že integrace Rustu do existujícího kernelu může přinést benefity na obou stranách, jak na staně kernelu (jednodušší vývoj a vyšší kvalita), tak i pro Rust (propagace, prestiž, vyšší počet potenciálních vývojářů, portace na více architektur...). Pokud to vyjde, tak to bude win-win situace pro všechny.

Moc nerozumím, co konkrétně ti vadí?

Vadí mi, že to všechno podle všeho směřuje ke stavu, který jsem popsal v tom minulém příspěvku: "že přeložit jádro bez rust toolchainu půjde jen teoreticky (za cenu obětování podstatné funkcionality) a že nebude možné být vývojářem jádra nebo dokonce reviewerem nebo maintainerem subsystému, aniž by člověk ovládal i rust". Vy takovu vizi možná považujete za win-win, já bych to považoval za velkou prohru.

25. 3. 2021, 20:53 editováno autorem komentáře

Linux kernel je už teď možné přeložit clangem, což je LLVM + C frontend. Rust compiler je LLVM + Rust frontend. Jiný frontend nad existujícím toolchainem není velká technologická změna. Stejně tak je možné mít Rust frontend ke gcc, když bude taková potřeba.

A že bude k vývoji kernelu potřeba i nějaká znalost Rustu? To je přece na vývojářích, pokud budou Rust bojkotovat, tak se neprosadí. Pokud v Rustu uvidí nějaké výhody, tak ho budou sami požadovat. Zatím nevíme, jak to dopadne.

Linux kernel je už teď možné přeložit clangem, což je LLVM + C frontend.

Je to možné... ale jen možné, není to nutnost.

Jiný frontend nad existujícím toolchainem není velká technologická změna.

Je to velká změna z praktického hlediska. Jádro typicky není problém přeložit 5-6 let starým gcc a naopak, i velmi stará jádra lze typicky přeložit dnešním gcc jen s trochou práce. U rustu to funguje úplně jinak. To je snad to jediné pozitivní, co by tohle dobrodružství mohlo teoreticky přinést: že by to ten bohémský přístup vývoje rustu mohlo trochu zkultivovat. Bojím se ale, aby to nedopadlo obráceně.

A že bude k vývoji kernelu potřeba i nějaká znalost Rustu? To je přece na vývojářích, pokud budou Rust bojkotovat, tak se neprosadí.

"Vývojáři kernelu" nejsou nějaká uzavřená skupina. Kdokoli se může sebrat a poslat patch nebo sérii. Takže si představme, že někdo pošle rustový modul třeba do netfilteru a Pablo nebude umět rust. Bude ho moci odmítnout čistě na základě toho, že rust neumí a v nechce se ho učit? Nespustí rustaři povyk, že je to diskriminace? Nebo se bude muset každý maintainer povinně rust naučit na takové úrovni, aby mohl zodpovědně dělat review? (Pro srovnání: třeba takový maintainer memory managementu se dodnes nenaučil ani git.) A co vývojáři, součástí jejichž práce je řešení chyb nahlášených zákazníky - chyb, které mohou být přímo v rustovém kódu nebo bude jeho důkladné pochopení k vyřešení potřeba?

Prostě se celou dobu snažím vysvětlit, že představa, že rust kód bude něco izolovaného, čeho si nebude potřeba všímat, kterou se rust fans snaží navodit, je naprosto nerealistická. Jen nevím, jestli je to jejich neznalostí, jak vývoj jádra a práce na něm fungují, nebo jestli je to záměrné matení.

> jestli je to jejich neznalostí, jak vývoj jádra a práce na něm fungují
Je to neznalostou toho ako funguju velke projekty ktore neobsahuju iba moj kod a maju nejaku historiu. Kazdy mlady neobruseny clovek chce prist s novou ideou a obratit nas existjuci svet naopak. Az neskor ako nabera skusenosti zistuje kolko toho ani nevie a ze vacsinu toho co navrhuje sme uz aspon 5x skusali a nevyslo.

Clang pro překlad kernelu aktuálně používá Android, ChromeOS a MandrivaLinux. Clang nabízí nějaké benefity navíc, má pokročilejší statickou analýzu než gcc a s clangem je možné použít LTO optimalitaci kernelu. Má to výhody, které nevidíš, stejně jako nevydíš výhody u Rustu.

Rust fans se nesnaží navodit názor, že bude Rust v kernelu nějak izolovaný, jak jsi na to přišel? Začíná se drivery, protože je to nejlogičtejší místo, kde začít. Je to experiment a je všeobecná shoda na tom, že má smysl Rust v kernelu vyzkoušet.

Tvoje argumenty jsou ve stylu "nechci se učit Rust, takže ho nechci ani v kernelu". Ale takhle to nestojí, Rust se do kernelu dostává, protože má potenciál kernel zlepšit, nabízí oproti C něco navíc. Zatím nevíme, jak to dopadne. Buď Rust vývojáři přijmou a budou chtít používat, nebo ne, časem uvidíme. Pokud převládne většinový názor, že Rust je pro kernel přínos, tak si myslím, že se každý kernel vývojář (včetně tebe ;-)) Rust nějak naučí, protože to bude potřebovat ke své práci. Rust není žádná raketová věda.

Clang pro překlad kernelu aktuálně používá Android, ChromeOS a MandrivaLinux. Clang nabízí nějaké benefity navíc, má pokročilejší statickou analýzu než gcc a s clangem je možné použít LTO optimalitaci kernelu. Má to výhody, které nevidíš, stejně jako nevydíš výhody u Rustu.

To, že jde jádro přeložit pomocí clangu, nijak neomezuje toho, kdo tuto možnost nechce nebo nepotřebuje využívat. K tomu, abych mohl přeložit jádro s běžnou konfigurací, nepotřebuji mít nainstalovaný clang a nepotřebuji nic vědět o jeho specifických featurách. Stejně tak nic z toho nepotřebuji k tomu, abych mohl debugovat a opravovat chyby, posílat patche nebo dělat review. (Jediný problém by byl, pokud by kvůli clangu musel být hůř čitelný nebo méně efektivní kód.)

Rust, pokud by se opravdu ujal, by byl úplně jiný příběh. Běžná konfigurace by bez rust toolchainu (té správné verze) přeložit nešla, každou chvíli bych se musel nořit do rustového kódu a při troše smůly musel bych ho reviewovat. Nemluvě o tom, jaká lahůdka by bylo dělat úpravy nebo rozšíření interního API (konkrétně třeba ethtool_ops), pokud by část NIC driverů byla v rustu. To je naprosto zásadní rozdíl.

Tvoje argumenty jsou ve stylu "nechci se učit Rust, takže ho nechci ani v kernelu". Ale takhle to nestojí, Rust se do kernelu dostává, protože má potenciál kernel zlepšit, nabízí oproti C něco navíc.

Ne. Hrozí se tam dostat, protože neodbytná RiiR klika pochopila, že napsat jádro operačního systému v rustu není taková legrace a že pro ně bude mnohem pohodlnější přilepit se na existující populární projekt, vyzobávat si zajímavé třešničky a "heavy lifting" (a obecně to, s čím si nechtějí špinit ruce) nechat na těch hloupých céčkařích, na které budou dál plivat špínu, zatímco jim přidělají hromadu práce navíc.

Rust není žádná raketová věda.

...zatímco jinde v téže diskusi je to doporučováno jako síto, kterým by se mělo určovat, zda je někdo dost způsobilý být vývojářem.

Rozděluješ svět na "dobré" C a "špatný" Rust a bojuješ proti Rust toolchainu, který se v kernelu ve formě LLVM už dávno používá. To je dost černobílé vidění. Celé to podáváš tak, že Rust způsobí nějakou větší vstupní bariéru a vícenáklady pro vývoj kernelu. Ono je to ale přesně obrácene. Napsal jsem hodně kódu v C i v Rustu, takže můžu srovnávat.

Naučit se C, aby se v něm daly začít psát nějaké jednoduché programy, je otázka krátké doby. C je takový portabilní assembler, tohle se dá zvládnout rychle. Ale rozhodně to neznamená, že je možné s takovými znalostmi přispívat do kernelu, protože psát dobré programy v C vyžaduje roky zkušeností a znalostí, jak se v C nestřelit do vlastní nohy.

Naučit se Rust, aby se v něm daly psát nějaké jednoduché programy, je težší než v případě C. Začátečník bojuje hlavně s borrow checkerem, zvyknout si na koncept vlastnictví nějakou dobu trvá. To je nepřímý důsledek toho, že Rust nenechá začátečníka střelit se do vlastní nohy, všechny potenciální chyby v memory managementu a sdílení objektů mezi thready chytí překladač a chybný program vůbec nepřeloží.

Pokud se chci naučit nějaký jazyk na takové úrovni, abych mohl přispívat do kernelu, bude to s Rustem trvat kratší dobu než s C. Rust umožňuje přeskočit fázi učení se explicitnímu memory managementu, což je v C na velkých projektech to nejsložitější a taky zdroj hodně chyb včetně bezpečnostních. Rust taky snižuje kognitivní zátěž při code review, ten kdo dělá code review se nemusí zabývat memory managementem a řesí hlavně business logiku, což zase zrychluje vývoj a zkvalitňuje výsledný produkt.

Pokud se Rust do kernelu dostane, může to přilákat více vývojářů, protože vstupní bariéra nutná pro psaní kvalitního kódu se oproti C sníží. Je možná trochu škoda, že s Rustem nemáš větší zkušenost, přicházíš o spoustu dobrých věcí, které C nenabízí a nikdy nabízet nebude.

Podívej se kam to za ty roky dotáhla s Rustem Mozilla. Nikam. Nic to nezlepšilo, Firefox nemá víc kontributorů ani uživatelů... Jen spálili miliony člověkohodin na přepis několika modulů, který reálně ale nikomu nic nepřinesl.

Pokud chceš kernel v Rustu, tak začni psát kernel v Rustu a neprzni existující projekty v C, které mají výborné C vývojáře a komunitu kolem. Přesně lidi jako ty tyto komunity pak rozvrací.

Zase to skálopevné přesvědčení rustařů, že "explicitní memory management" je to nejdůležitější, čím se člověk při vývoji zabývá. Ne, není. A i kdyby byl, rust vás ho stejně nezbaví, tedy ne toho skutečného. Ne, žádný supergeniální jazyk za mne nevymyslí, co alokovat z generické slab cache, na co bude lepší použít vlastní, kde get_free_pages() a kde vmalloc(), jak organizovat data ve struktuře s ohledem na jejich použití atd.

Ale ten skutečný problém, kterým se programování jádra odlišuje od userspace, je konkurence. A to je zase věc, kde mi žádný fancy moderní jazyk nepomůže - a pokud snad ano, tak leda způsobem, který je z praktických důvodů nepoužitelný. Namátkou třeba tenhle commit. Když se na to podívá nějaký vyznavač moderních jazyků, které "myslí za programátora", uvidí v tom jasnou chybu návrhu, že přece nemůžu číst data, která mi mezitím někdo mění pod rukama, a začne mi vysvětlovat, jak by to chytřejší jazyk vyřešil za mne. Jistě, vyřešil... tím, že by všechny přístupy pozamykal (nebo mne donutil to udělat), což je přesně to, co by tady nadělalo víc škody než užitku.

Obecně ty vize, jak rust zázračně

...nenechá začátečníka střelit se do vlastní nohy, všechny potenciální chyby v memory managementu a sdílení objektů mezi thready chytí překladač a chybný program vůbec nepřeloží.

jsou sice hezké, ale v kontextu jádra použitelné nanejvýš v těch částech, kde na výkonu nezáleží. Jenže v jádře máte dost míst, kde by i spinlock byl příliš pomalý, takže jste odkázán na RCU, místa, kde musíte řešit explicitní memory bariéry, protože konkurenční přístup vyloučit nemůžete, místa, kde je buffer percpu a k ochraně stačí dočasně zakázat preempci nebo jen softirq (protože vím, z jakého kontextu může konkurenční přístup přijít). Jistě, tohle všechno můžu nechat automagicky vyřešit borrow checker - ovšem jen tím, že mi většinu těch triků vůbec nedovolí. Ale ty triky nejsou samoúčelné, jsou tam kvůli efektivitě; nasekat všude zámky a reference by bylo mnohem jednodušší i v céčku, ale jsou dobré důvody to tak nedělat.

Ale ty triky nejsou samoúčelné, jsou tam kvůli efektivitě; nasekat všude zámky a reference by bylo mnohem jednodušší i v céčku, ale jsou dobré důvody to tak nedělat.

Kristova noho!

Chápu, že z tvého pohledu jsou Rust vývojáři banda polodementních pubertálních výrostků, kteří přišli nejspíš z JS nebo podobně a nemají šajn o hardware, o zpětné kompatibilitě atd. a snaží se zničit všechno krásné a dobře fungující.

Realita:
1. Kernel/OS v Rustu jde napsat, existuje, jmenuje se Redox.
2. V Rustu samozřejmě je povědomí o např. lock-free technikách, RCU apod., existují knihovny poskytující např. lock-free fronty, mám s tím zkušenost, fungovalo to velmi pěkně a velmi rychle. S přístupem "prdnem na všechno refernce-counter a mutex" by řada důležitých Rustových projektů (např. Tokio, Actix, ...) nikdy nemohla fungovat s takovým výkonem, s jakým funguje. Zamykat všechno opravdu není jediná možnost a ty lidi opravdu nejsou tak retardovaní, aby nevěděli, že zamykání může být nepřijatelné. I když chápu, že ti přijde neuvěřitelné, že by tuto znalost mohl mít i někdo mimo kernel a C. V rustu je poměrně velká iniciativa pro embedded programování, kde třeba interrupt kód nebo korektní přístup k periferiím se musí už dávno řešit. Borrow checker sice nepodporuje explicitně třeba per-cpu buffery, ale je celkem dobře možné pro takové použití nějaké abstrakce napsat. Už jenom třeba mít k dispozici reálně fungující move semantics je obrovsky užitečné (oproti třeba té parodii na move semantics, co je v C++).
3. Pokud by Rust přišel do mainline, na 99% procent by byla použita nějaká konzervativně nastavená verze jazyka. Ne všechno v Rustu je hyper-progresivní záležitost s kompatibilitou max několik týdnů. Například libc binding knihovna má specifikovanou kompatibilitu s Rust kompilátorem z roku 2016 a tato kompatibilita je verifikovná autmatickými testy, takže patch, který by to porušil, ti to nevezme.
4. Pracuje se na Rust frontendu do GCC, pracuje se na zbavení se závislosti na LLVM, existují projekty pro zlepšení té situace "máme jen jeden kompilátor". Nemyslim si, že by adopce Rustu do kernelu měla mít rychlejší timeline než tyto projekty, nevypadá to na to.

Přál bych si, aby si lidi s tvým názorem někdy reálně vyzkoušeli vámi navrhovaný postup: Tj. třeba 10 let si psát někde do šuplíku jazyk s dokonalou specifikací, standardizací, mnohaletou zpětnou kompatibilitou a tím vším, co požadujete... jenom abyste následně zjistili, že ten jazyk nikdo nechce používat, protože za celou tu dobu byl reálně nasazen v maximálně několika málo projektech, a tedy je to víceméně one-man-show, je s tím je nulová zkušenost, koncepty nejsou ověřené realitou, nikdo to nezná, neumí...

On ten názor bude možná reálně jednodušší: Nové jazyky by se prostě neměly psát vůbec. Respektive, pardon, omlouvám se, nové jazyky se samozřejmě psát můžou, beze všeho... akorát se na ně uvalí takové požadavky, aby se pokud možno nemohly moc rozšířit a něco někde infikovat :)

1. 4. 2021, 14:45 editováno autorem komentáře

Tak srovnávat zrovna tyto 2 věci... Toto je vyjádření pro lidi, co věří tomu, že Rust je nějaká spása. Takže pár lidí teď může experimentovat s vysněným modulem v Rustu pro kernel. Já v tom fakt nic nevidím. nVidia je úplně jiná kategorie...

Aha. Tak si konečně přečti, co Linus řekl o C++, aby to bylo srovnatelné.

Hledáš tam něco co tam není.

anonacct: Na vašem místě bych:

1. Když autorita, kterou uznáváte, má na věc jiný názor, než vy, hledal bych, z čeho váš názor vychází, a zda se náhodou nemýlíte.

2 Pokud po svědomitém provedení prvního kroku budete stále přesvědčen, že se nemýlíte, zkuste se smířit s tím, že se může mýlit autorita, která si vážíte.

Je důležité se smířit s tím, že se můžete mýlit vy, a může se mýlit i autorita, které si vážíte. Je nedůstojné to překrucovat, že Linus Torvalds vlastně řekl něco jiného, než si myslí. A zrovna v případě Torvaldse je to i nesmyslné, protože jeho ostrý jazyk je všeobecně znám.

LOL sorry, nemám náladu to řešit :)