Názory k článku
Hector Martin odstoupil z pozice vedoucího projektu Asahi Linux

To je smutné, že táto aféra takto skončila. Práca na linuxovom kerneli je toxická, teraz v tom výnimočne nemá prsty Linus.

TL;DR - Správca kernelu povedal, že viac programovacích jazykov je rakovina, na čo Hector Martin začal robiť drama queen a postovať ublížené veci na Mastodon.

Víc jazyků = závislost na více kompilátorech a dalších nástrojích, vyšší komplexita a nutnost umět více jazyků.

Jinak se mohlo Jádro už dávno psát v C++ a díky SBRM (RAII) a dalším vlastnostem toho jazyka by to zjednodušilo kód a odbouralo část chyb (na druhé straně to vyžaduje určitou znalost C++ což řada vývojářů nemá nebo nechce mít – totéž platí pro Rust).

Kromě stavění Babylonské věže a zachování čistého C mne napadají další možnosti:

a) Převést všechen kód do vyššího programovacího jazyka, aby celé jádro bylo v jednom jazyce a kompilovalo se jedním kompilátorem.

b) Mít dobré stabilní API/ABI, aby všechny ovladače nemusely být v jednom repozitáři a nebylo nutné je průběžně oprašovat a šlo je efektivně vyvíjet a udržovat nezávisle jinde.

Ani jedna z těch možností není ideální.

C++ je košatý jazyk, ktorý má milión rôznych konvencí a zápisov. Nejdem to hodnotiť, či je to dobré, alebo zlé. Ale je to dôvod, prečo som pred 20 rokmi vybral Javu. Vždy keď som videl nejaký nový kód, čumel som ako tela na nové vráta.

Rust má skromnú syntax, preto naň Linus kývol.

Možnosť c) Vykašlať sa na Linux a pomôcť projektu Redox OS. Ako viem, že je to hračkársky OS, ale podobne začínalo veľa iných.

A taky skončilo. Redox OS je docela dobrý nápad, líbí se mi architektura, jazyk -- nicméně nevýhoda je že na běžném HW to jako daily system nemůžete provozovat... Tj. drivery. A výrobci těžko budou podporovat další OS.

Unix tiež začínal ako divný operačný systém pre počítače rady PDP od fy Digital. Pritom to ani nebol jediný OS pre tie počítače, digital mal kadejaké RSTS a pod.

Ak by sa povedzme zamerali na nejaký rad system76 a povedzme raspberry pi, možno by to stačilo.

To je věc zkušeností, znalostí, názoru, pochopení...

Já si třeba nedovedu představit, co užitečného by C++ do jádra přineslo, a dovedu si představit co špatného by C++ do jádra přineslo.

Zatímco u Rustu výhody vidím jasné, a nevýhody jediné - je to nový jazyk.

Pro zajímavost, Linus měl výhrady v nepředvídatelnosti C++. A naopak, ve skutečnosti se jádro píše v C++, přesněji v subsetu C++, a nikoliv ve vanila C. Podrobnosti si už ale nepamatuji.

Např výjimky. On kouká na diff změny, a aby viděl, co to v některých situacích udělá, musel by si najít i kód dost jinde (často dokonce v jiném souboru). Nicméně třeba Google tento problém řešil tak, že v dohodnutém stylu psaní C++ výjimky zrušil. Parametr kompilátoru zruší jejich podporu, takže např new pak bráti NULL stejně jako Cčkový malloc. Vlastně má zadarmo objektovost, nativně, bez tuny maker, přitom ošetření chyb dělá stále v C stylu (lokálně u operace).

21. 2. 2025, 16:43 editováno autorem komentáře

Co by mohlo C++ priniest? Napriklad RAII/SBRM? Ale aj triedy by boli uzitocne; teraz si robia rucne dispatch tabulky, mohli by to byt virtualne metody.

V xnu (macOS), IOKIt je v C++ (zakazane su vynimky, viacnasobna dedicnost, sablony a RTTI).

A nepredvidatelnost v C++? Ked pouzije podobnu ficuru v Ruste, uz to nie je nepredvidatelne? Ked pouzije sablony v C++, kod sa moze nafuknut pre kazdu specializaciu; ked v sablone je pouzitych viacero generickych typov, tak kombinacia specializacii dokaze pekne rychlo vyletiet. Ale co sa asi tak stane v Ruste? Pribehnu jednorozci? Takze je to len o optike; nepredvidatelnost C++ pochadza z postojov v 90-tych rokoch, povest ostala. Novinka Rust sice robi presne to iste, ale "to je ine".

Souhlas.

Jen k těm šablonám:

Ked pouzije sablony v C++, kod sa moze nafuknut pre kazdu specializaciu; ked v sablone je pouzitych viacero generickych typov, tak kombinacia specializacii dokaze pekne rychlo vyletiet.

1) Ten počet typů tam nebude jen tak zbůhdarma, ale nejspíš proto, že je někdo potřebuje.

2) Jak by to vypadalo v „čistém“ C? Buď se tam funkce/struktura rozkopíruje X krát a bude obsahovat podobný kód, takže to bude stejné nebo horší jako s těmi šablonami. Nebo někdo udělá obecnou „abstrakci“ založenou na ukazatelích, unionech a přetypování – což je sice méně kódu, ale zato záludnějšího a náchylnějšího k chybám.

Také ho sleduji a podle mě jeho reakce je příliš osobní a ufňukaná. Rust do kernelu míří dlouho a pomalu, tohle se nezměnilo, místo, aby se snažil ukázat, že to může fungovat, se začne takhle vztekat?

Tomuhle naprosto rozumím:

> Despite that, I ended up burning out, primarily due to the very large fraction of entitled users.

> No matter how much we did, how many impossible feats we pulled off, people always wanted more.

Ale na druhou stranu vidím, že velká část jeho vnímání situace plyne z dlouhodobé frustrace. Čtu email od tytso a přijde mi naprosto v pořádku, protože tohle je naprostá pravda:

> One of the things which gets very frustrating from the maintainer's
> perspective is development teams that are only interested in their pet
> feature, and we *know*, through very bitter experience, that 95+% of
> the time, once the code is accepted, the engineers which contribute
> the code will disappear, never to be seen again. As a result, a very
> common dynamic is that maintainers will exercise the one and only
> power which they have --- which is to refuse to accept code until it
> is pretty much perfect --- since once we accept the code, we instantly
> lose all leverage, and the contributors will be disappear, and we will
> be left with the responsibility of cleaning up the mess. (And once
> there are users, we can't even rip out the code, since that would be a
> user-visible regression.)

Tohle neplatí jenom pro Linuxový kernel, ale obecně pro libovolný trochu větší Open Source projekt. Pro příklad uvedu tohle: https://lists.isc.org/pipermail/bind-users/2024-November/109108.html

A když jsem se zeptal, kdo to bude udržovat až dostudují: https://lists.isc.org/pipermail/bind-users/2024-November/109111.html, tak nastalo ticho po pěšině.

Tak nějak vnímám, že je asi dobře, že od toho šel pryč. Je to dobře hlavně pro něj, protože tak nějak tuším, že by se z něj mohl stát díky frustraci přesně ten entitled user, na které si v úvodu stěžuje.

Myslíte, že toto je jeho případ? Nevypadá to, že by se po začlenění plánovali na všechno vykašlat. Chtěli dále pokračovat v přidávání podpory dalšího hardware.
Frustrace z jeho blogpostu úplně tryská. I kdyby byla pravda čtvrtina toho, co popisuje za zážitky s maintainery kernelu, je to děs.

Mám pocit, že jsem udělal dobře, když jsem po 20 letech s Linuxem na desktopu utekl k macOS.

Taky mi přijde, že to myslí podstatně vážněji, než študáci, kteří zkusili nabídnout svůj hack (a byly logicky odmítnuti).

Reakce správce byla jasná - přes mě žádný Rust neprojde, i kdyby byl sebelepší. Trochu mě zklamala reakce Linuse, protože pokud jednou udělali rozhodnutí, že Rust bude možno používat, pak takováto reakce jde zcela proti tomu a IMO by se jakožto šéf k tomu měl vyjádřit. Chápu, že to Martina odradilo, obzvláště pokud to dělal dobrovolně ve svém volně (narozdíl od drtivé většiny ostatních diskutujících ve vlákně).

Na druhou stranu mu muselo být jasné, že když to začne hrotit mimo mailinglist, ztratí pozici důvěryhodného partnera a přijde o většinu podporovatelů, kteří s ním v technických otázkách jinak souhlasí.

>>> Mám pocit, že jsem udělal dobře, když jsem po 20 letech s Linuxem na desktopu utekl k macOS.

Hmm, apple je napoly firma a napoly sekta. Tam sa všetko deje za zavretými dverami. Pochybujem, že tam je vývoj natoľko demokratický, aby niekto písal ovládače, ktoré si sám veľký mufti neobjednal a nedajbože, aby ich písal nejak "zle".

> Myslíte, že toto je jeho případ? Nevypadá to, že by se po začlenění plánovali na všechno vykašlat. Chtěli dále pokračovat v přidávání podpory dalšího hardware.

Nemyslím.

Ale také si nemyslím, že zmiňovaný email s “fine blue line” (https://lore.kernel.org/lkml/20250208204416.GL1130956@mit.edu/) byl nějak osobní. To co tytso popisuje je solidní přístup - prostě je těžké do kernelu dostat nový kód, protože kdyby nebylo, kernel by uhnil zevnitř.

přesně tak, přidat někam novou implementaci není románek na noc, ale přímo manželství, je to odpovědnost na dlouhé roky. Proto by se každá veřejně dostupná funkce měla dvakrát zvažovat než se implementuje.

To je i důvod proč více času věnuji openbsd než linuxu, stíhám tam sledovat vývoj a věci, které se implementují.

Nedivím se frustaci kernel maintenerů, ale na druhé straně nerozumím tomu proč toho přidávají tolik nového, asi ta poptávka je dost monstrózní.

Je vycerpanej a vyhorelej, no. Soucitim s nim. Kdyz jsem si tim prochazel, tak jsem take mel pocit, ze zadost uzivatele o ficuru je osobnim utokem a nedocenenim, co vsechno uz bylo udelano.

Problem je znova nejake planovani. Kdyz chybi cidlo teploty procesoru, kdyz chybi tranzice do low power... co dalsiho tam chybi?

Plan pro Apple silicon nejde udelat v tabulce o par jednotkach radku, jak to maji na webu/gitu/wiki, ci kde jsem to videl - je potreba se starat o to, ze co delaji, delaji spravne, a ne jako krtek co se vyhrabal na random pozici a ted mu mame tleskat jak je sikovnej ze nam zoral pole. To je presne to - jak tihle sebestredni mistri k ukolu pristupuji a to je spatne.

Takze z pohledu mainlinovani - je opravdu dobre ze se neakceptuje zadnej mezistav a kazdej zblebt, ale vyzaduje se napr. podpora uplna na danou platformu.

Jestli nechce na tom nekdo dalsi vyhoret a ma v umyslu byt sponzorovan - at predvede kompletni dependency tree, co je treba udelat a jak veci souvisi - a ne ze to bude jedno velke neznamo a mysli si ze mu lidi budou dotovat jeho pokusy kde se nahodou jednou blisknul.

Za me vidim nulovou sebereflexi z vyhoreni - holt nekteri lidi jsou nepoucitelni.

Proč se teda akceptuje mezistav u všeho ostatního? GPU, power management, senzory... mám už třetí Zen notebook a stále není funkční ani základní podpora AMD Sensor Fusion Hub, bez kterého nefungují klíčové funkce convertible laptopu (rotace, dimming), ale přesto kód v kernelu je. Čím to?

Přijde ti "rust is cancer" jako technický argument zapadající do tvé interpretace nebo to spíš bude jinak?

Tak problem muze byt dvojity - bud tam AMD nedodalo co melo (ohledne toho sensor hubu), nebo vyrobce konkretniho zarizeni provedl customizaci, ktera se blbe portuje, nebo musi resit per device, a zde uz je to politika toho, ze vyrobce podporuje Win a jedes nepodporovany OS, tak si porad sam. Viz problemy u audio rozhrani, kde existuje tabulka jak jsou jednotlive kanaly/konektory zapojeny, protoze jack-sensing byl az domenou pozdejsi generace.

Ja s "rust is cancer" souhlasim. Do jadra to nepatri.

Kdybych to mel ja resit architektonicky, tak varianta, kde Rust muze hrat nejakou roli by byla "Rust Island", tj. kernel modul s rozhranimi (shim) a pak rustovejmulti-moduly. V idealnim stavu jeden velky, jasne izolovany, loadable blob, ktery si bude zit svuj rusted zivot, kam si vsichni contributori rustu muzou natlacit sve vytvory.

Jsem tedy tak proti tomu, jak kernel developeri tlacili rust vyvojare, aby si delali ty bindingy per modul a ve sprave to mel spravce modulu - protoze ty mezivrstvy nechtej mit genericke, natoz je udrzovat, kdyz to nekdo zmeni v jadru. Preferuji tu mezivrstvu vyclenit - a ze to nejde.. nuz nvidia s takovym shimem zila jako hodne let, pro svuj proprietarni ovladac, a vyjma stavu kdy ho explicitne vyvojari jadra bojkotovali skrze omezeni gplonly-exports, tak to fungovalo ok - s nejakou akceptovatelnou prodlevou a omezenim jako parovani verzi.

Mit stabilni a dobre definovany api/shim by zde opravdu pomohlo - a ta varianta proc mega-modul - aby se pripadna zmena v api nemusela resit pro kazdej ze stovek rust modulu individualne, ale vyresila jednou (jako reakce na zmeny ve vyvoji jadra a zmizeni/prida­ni/zmeny funkci ci parametru).

A to se dostavame zpatky a kolecko se uzavira - proc se Rust tlacil tak mermomoci do jadra, kdyz mohl zustat jen jako jazyk pro tvorbu out of tree modulu? U toho to melo zustat a pokud ten rust codebase by byl opravdu relevantni, tak meli spise tlacit na stabilizaci API, aby to nemuseli pokazde prepisovat a placat se v bahne. Protoze tohle placani se je stejne, at uz jde o in-tree nebo out-of-tree codebase. Stabilni API tam nyni neni.

Z dnešního Linuxu už mikrokernel neuděláte.

API je právě jeden z problémových bodů. Ani samotní C správci se neshodli na přesné sémantice některých API pro grafické ovladače, kde ten tenký Rust wrapper odhalil nekonzistence.

Prostředí kernelu je dlouhodobě extrémně toxické a sám Linus na tom má velký podíl.

preto by mozno bolo dobre zacat novy kernel.
Cast veci, kvoli ktorym linux funguje ide sucasnosti do kytek...
S API pre graficke drivery je dlhodobo problem..

Ale od toho shimu, který jak píšete linuxáci dokonce chvíli blokovali, je to jen krůček ke stabilními ABI. A přes to by se nepřenesli už vůbec. Plus posílat kód, až když je úplně hotový, dopadne v příliš velký balík změn, který nikdo nebude mít čas projít. Skončilo na tom dokonce i AMD se svým GPU kernel driverem (měsíce se to pak řešilo).

AMDGPU je uplne iny pripad; bolo im povedane "takto to nerobte", AMD to ignorovali a urobili presne tak, ako im bolo povedane, ze nie je neakceptovatelne a potom sa cudovali, ze ich s tym poslali do certa. Niektori ludia jednoducho nepochopia na prvy krat.