Vlákno názorů k článku
Hector Martin odstoupil z pozice vedoucího projektu Asahi Linux od RDa - Problem je znova nejake planovani. Kdyz chybi cidlo...

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.