Vlákno názorů k článku
Hector Martin odstoupil z pozice vedoucího projektu Asahi Linux od balkovic - To je smutné, že táto aféra takto skončila....

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.