Názory k článku
Rust zachrání Linux před umělou inteligencí, říká Greg Kroah-Hartman

zajimave. normalne s toho celeho zacinam mit pocit, ze typove bezpecne jazyky pujdou nahoru, nebot AI bude v tech netypovanych a mene bezpecnich jazycich nachazet tolik chyb ze bude jednoduseji prejit na bezpecnejsi jazyky.

a nebude rovnako jednoduche este pred kompilaciou programov v tych netypovo bezpecnych jazykoch prehnat novy kod cez ai, ktora odhali vsetky chyby co by odhalil kompilaror typovo bezpecnych jazykov, plus odhali aj dalsie chyby ktore by neodhalil ani ten "zazracny" rust kompilator?

je tazke naucit ai aby upozornila v c-ckovom zdrojaku na vsetko na to na co upozornuje kompilator rustu a dat ako podmienku pre prijatie patchu do linuxu, ze musi touto kontrolou ten novy kod prejst a ziadny kod ktory cez taku kontrolu neprejde na "zelenu" proste zacleneny nebude? s vynimkou ak dany vyvojar dokaze, ze konkretne v tomto pripade to nebude viest k bezpecnostnej chybe a je to potrebne z nejakych dovodov mat napisane presne takto
ak tu ai je mozne takto pouzit tak v tom momente mas bezpecnost na urovni rustu s vyhodami ktore poskytuje c-cko

pytam sa pre seba, nie kamarata :)

Odkdy je AI (strašný HW a nedeterministický SW) "stejně jednoduchá" jako deterministický seznam pravidel/instrukcí?

> a nebude rovnako jednoduche...

Ne nebude. Už jen proto, že AI "linter" a typová kontrola v překladači dělají něco trochu jiného.

Ty zázraky možná zvládne ta AI. Jenže se na ně z principu fungování nedá spolehnout. Ten proces je nedeterministický, chybující, extrémně výpočetně náročný, atd... Takže vyžaduje kvalifikovaný lidský postprocessing.

Rust a spol nesplibují zázraky ale spíš záruky. Nechytnou toho tolik, co to AI ale fungují deterministicky, spolehlivě a za zlomek nákladů. Je to spíš první filtr, který eliminuje nejčastější stupidní chyby a udělá to rychle a přímočaře.

> je tazke naucit ai...

Pekelně těžké.

> vyhodami ktore poskytuje c-cko

Primární výhoda Cčka byly mraky existujícího kódu. Jenže rozmach AI tuhle výhodu překlopil na extrémní náklady.

Víš že se dá dělat víc věcí najednou? Můžeš použít AI a dbát víc na paměťovou bezpečnost. Naopak, praxe ukazuje že LLM, pokud funguje, funguje tím líp čím víc se jí dá mantinelů, na což je Rust ideální.

Každopádně, hledání chyb přes LLM je spíš podobné hledání chyb fuzzerem. Může to přispět k nalezení chyb, ale není to deterministický proces a stejně potřebuje práci člověka.

Céčko oproti rustu nemá prakticky žádné výhody, kromě toho, že na Rust se vývojáři musí učit nová paradigmata. Rust a C kód může pěkně koexistovat a pokud něco přepíšete do Rustu, pravděpodobně to bude mít srovnatelný výkon jako v C. Není jiný důvod Rust nepoužívat, než chybějící znalost toho jazyka.

To jiste ... takva drobnost ze Cckovy kompilator zvladne prelozit sam sebe ... kdo by se tim zaobiral ... NAPRIKLAD.

rustc ale v klidu zvládne přeložit sám sebe; jediné, co mu chybí v řetězci, je náhrada LLVM. A to, že do Rustu zatím nikdo nepřepsal LLVM, neznamená, že to nelze. Prostě doposud nebyla potřeba.

To, že kompilátor nějakého jazyka zvládne přeložit sám sebe není nijak výjimečné. Takže i když teď Rustu chybí náhrada LLVM napsaná v Rustu, není to žádný principiální problém, který by nešlo poměrně snadno vyřešit. Přičemž kdyby na tom záleželo, zrovna tohle je celkem dobře řešitelné pomocí AI. Existuje vzor napsaný v C a hlavně se to dá snadno testovat – může se nad tím iterovat tak dlouho, odkud nebude nový kód dávat identické výsledky jak LLVM.

Na druhé straně i ten, co to programuje může použít AI v C, takže ty chyby odhalí, než to commitne.

> může použít AI

Tak jednoduché to fakt není. Co přesně vlastně má být to "použít AI"?
a) Problém zavalení AI slopem se nedá řešít generováním dalšího AI slopu. Údržbář fakt nebude provozovat AI v režimu CVE tro(t/l)la. Naopak to potřebuje vyhodnotit a odpálkovat s minimem námahy.
b) Ty chyby jsou obvykle v kódu, co už je dávno commitnutý. Často je to kód, který už spoustu let viděl jenom překladač. I když tuhle část Rust neřeší, tak může v novém kódu zaříznout celou třídu falešných poplachů.

Právě, v novém kódu můžete použít AI na review.

No ale review jednou AI vám nezaručí, že tam nějaká jiná AI "něco" nenajde. Klidně falešný poplach, který je ale taky třeba vyhodnotit.

Pozdě ale přece.

A sakra. To se zdejší odborníci zblázní

Ked riesite problem alkoholizmu heroinom.

Celkom mam rad principy Rustu aj ako jazyk je super, ale ma svoje uce case a nemyslim si, ze vseliek na vsteko. Hlavne ked tam bude tona unsafe kodu a Rust magie, na jadro a low-level veci mi pride C/Zig/C3 vyrazne lepsi.

Ale mam pocit, ze tu sa pan snazi riesit problemy sposobene jednym buzzwordom tym, ze cezen da iny buzzword. Co by sa mohlo pokazit, vsak?

> Ked riesite problem alkoholizmu heroinom.

Eh?

Jinak co jsem tak četla blogy Asahi Liny při jejím vývoji GPU driverů, ta vrstva unsafe nebyla zas tak velká, zrovna tu "tunu unsafe" dost rozporovala jako běžný omyl.

Baví mě že píšeš o Gregovi K.H. jako o nějakém "pánovi" jako by to byl nějaký kolemjdoucí s novou hračkou co kecá do vývoje jádra, a ne správce stable větve kernelu a člověka který o něm ví nejspíš nejvíc hned po Linusovi.

Díky za zmínku o GKH, je vidět, že předřečník netuší, o koho jde.

Jakoby to bylo podstatné. I kdyby to říkal Ježíšek, tak to samo o sobě nic nedokazuje

Ne, ale jeho expertýza v daném oboru jeho tvrzení přidává váhu, zvlášť proti někomu kdo o vývoji Linux kernelu ví tak málo, že ani nezná GKH.

...a člověka který o něm ví nejspíš nejvíc hned po Linusovi.

Je až neuvěřitelné, jak se tahle pověst drží. Tedy aspoň mezi laiky. Mezi vývojáři jádra (snad kromě Linuse samotného, který si obecně na "staré kamarády" potrpí, viz třeba Andrew Morton) má naopak Greg Kroah-Hartman pověst čím dál horší, zejména kvůli tomu, jak pod ním fungují stable větve a v poslední době také kernel CNA.

Je fakt že to poslední dobou sleduju o něco míň, nějaký tlak proti Gregovi jsem nepostřehla. Uf... Máš k tomu něco víc?

Neříkal bych tomu "tlak proti", spíš jde o reputaci a to, nakolik jsou jeho prohlášení braná vážně.

Stable větve už roky dělají víc škody než užitku právě proto, že se Greg KH (a Sasha Levin, abychom byli fér) řídí heslem "hlavně aby tam něco nechybělo", takže tam proudí tuny nesmyslného balastu. Pro představu doporučuji přečíst Documentation/pro­cess/stable-kernel-rules.rst (aspoň první sekci) a pak si ta pravidla porovnat s changelogem kterékoli stable větve. S kernel CNA je to podobné, od doby kdy Greg KH a spol. převzal přidělování CVE id, je ten příval daleko mohutnější a daleko nesnesitelnější.

V obou případech sice technicky existuje způsob, jak stable backport nebo CVE zpochybnit, ale je záměrně nastaven tak, aby to bylo řádově obtížnější než jejich vytváření, takže se na to nakonec každý vykašle a buď backportuje i nesmysly (protože je to jednodušší) nebo si nastaví filtraci až u sebe. A Greg KH se pak nestydí argumentovat nízkým procentem zpochybněných patchů/CVE a prohlašovat: Podívejte, jen takhle málo bylo zpochybněno, z toho je vidět, jak skvěle ten proces funguje a že tam všechno opravdu patří. Lze se pak divit, že jeho prohlášení a hodnocení nikdo nebere moc vážně?

Ale už dřív, coby maintainer USB, měl Greg KH pověst maintainera, který je "příliš hodný" a přes kterého lze protlačit věci, které by jinde neprošly. Pokud něco odmítal, tak spíš kvůli formálním nedostatkům. Přes všechny své chyby má Linus Torvalds jako hlavní maintainer jednu zásadní přednost: má dobře vyvinutou schopnost "říkat ne", i když to občas znamená, že se užitečné featury zdrží nebo do jádra vůbec nedostanou, pokud nesplňují kvalitativní nároky. Greg KH takovou pověst nemá a i když ho Linus před časem nechal, aby ho zastupoval, když si "dával pauzu", je dobré si všimnout, že ten interval začal až po skončení merge window a skončil před začátkem dalšího. Nemyslím, že je to náhoda.

Jinak to jak udržuje větev zas tak moc nerozporuje fakt že o kernelu ví pořád dost - moje pointa byla spíš v odmávnutí někoho kdo má prokazatelnou znalost v nějaké doméně jako nějakého náhodného kolemjdoucího.

Jakákoliv kritika jeho práce od tebe má pro mě mnohem větší váhu.

Na druhou stranu ten GPU driver má nějakou funkci co má snad 2k řádků jen proto, že to nešlo napsat tak, aby to bylo víc funkcí. Sice mám rust rád, ale toto zase ukazuje, že to opravdu není všelék a některé věci se v tom dělají fakt blbě.

Nemáš link? Tohle mě fakt zajímá :)

GKH je ten pán, který do Linux kernelu v době vrcholu woke šílenství doplnil CoC v době, kdy byl Linus "odeslán na dovolenou", aby se na to nemusel dívat?
Jo, na takové věci se nedá zapomenout.

Neřeším odbornou stránku, tam jde zcela evidentně o špičkového experta, nicméně v politické oblasti (do které problematika Rustu v jádru silně spadá) si dovolím si ponechat velmi rezervovaný názor.

Tak jsem si ty CoC schválně otevřel. Co přesně je tam tak strašné?

Jo, na začátku je delší seznam různých kontroverzních věcí, ale nic z toho se vývoje softwaru netýká. Co je špatně na tom, aby si svoje kulturní války lidi řešili jinde?

Z politického hlediska mi to přijde celkem v pořádku. Zabránil diskriminaci lidí a používání výrazů, které se do profesionálního projektu úplně nehodí. GKH tím podle mě spíš pojmenoval problém, který v tak velkém projektu reálně mohl nastat, a nastavil mantinely dřív, než by to přerostlo v něco horšího.
Kde je tedy přesně ten politický problém?

"S tím se v jazyce C potýkáme. Proto ho nemáme rádi."

Kdyby ho slyšel Linus 🤣

Linus má rád C?

Ano.

asi ano ked v nom zacal pisat, pise a aj bude pisat svoj zivotny projekt :)

Děláte, jako by měl v devadesátkách víc možností.

Jsem rád, že někdo pochopil smysl otázky. C podle mě byla pragmatická volba v daném čase, ale ten už je pryč.

Bezpečný jazyk potřebují lidi, AI spíše ne a bude ho potřebovat čím dál méně. Takže takové chyby může odhalovat AI při hledání chyb, které kompilátor odhzlit nemůže, protože nebude chápat kontext na rozdíl od AI. Pokud tedy vůbec budou ještě kód psát lidé. V ASM se už také moc nepíše. Je to tedy s tím Rustem hezké, ale poněkud to přišlo pozdě, před 40 lety by to bylo lepší. Ale ADA už byla, jenže se nějak neujala.

S LLM musím pracovat a z mé zkušeností právě naopak.

- Generování kódu dává nejlepší výsledky pokud má přísně nastavené mantinely. Rust je dává by default
- Hrozně pomůžou kvalitní chybové hlášky kompileru. Rust je v tomhle na špičce.
- Kvalitní dokumentace možných závislostí na jednom místě taky pomáhá.

Zatím AFAIK Rust nemá ani specifikovaný aliasing model, takže se může snadno stát, že unsafe kód, který se dnes dostane do jádra, bude mít za pár let, až se to dospecifikuje, nedefinované chování. Těžko se to dnes odhalí, když to není specifikováno.