Greg Kroah-Hartman kiállt a Rust-ban írt illesztőprogramok mellett

Kernel

A Linux második számú "parancsnoka", Greg Kroah-Hartman szintén nagy támogatója a Rust kernelkódnak. Ma újabb LKML levelet írt, amelyben felvázolja a Rust előnyeit, és arra ösztönöz, hogy az új kernelkódok/illesztőprogramok C helyett Rust nyelven legyenek:

Mivel olyasvalaki vagyok, aki látott szinte MINDEN kernelhiba-javítást és biztonsági problémát az elmúlt 15+ évben (nos, remélhetőleg mindegyik bekerült a stabil ágakba, bár néha kihagyunk néhányat, amikor a karbantartók vagy fejlesztők elfelejtik megjelölni őket hibajavításként), és mint aki látja az összes kiadott kernel CVE-t, úgy gondolom, hogy tudok beszélni erről a témáról.

A legtöbb hiba (mennyiségben, nem minőségben vagy súlyosságban), amivel találkozunk, a C-ben lévő apró, bosszantó, speciális esetek miatt keletkeznek – ezek a Rustban teljesen eltűnnek. Olyan dolgokról van szó, mint az egyszerű memóriafelülírások (nem mintha a Rust mindet képes lenne elkapni), a hibakezelési takarítások, az error értékek ellenőrzésének elmulasztása és a use-after-free hibák. Ezért szeretném, ha a Rust bekerülne a kernelbe, mert ezek a problémák egyszerűen megszűnnek, így a fejlesztők és karbantartók több időt fordíthatnak a VALÓDI hibákra (például logikai hibákra, versenyhelyzetekre stb.).

Teljes mértékben támogatom, hogy a C kódbázisunkat olyan irányba mozdítsuk, amely lehetetlenné teszi ezeknek a problémáknak a felmerülését. Az, amit Kees, Gustavo és mások ezen a téren végeznek, csodálatos és teljesen szükséges munka. 30 millió sor C kódunk van, amely a közeljövőben nem fog eltűnni. Ez egy értékes erőfeszítés, amely nem fog leállni, és nem is szabad, hogy leálljon.

De az új kódok és driverek esetében, ha Rustban írjuk őket, ahol ezek a hibák egyszerűen nem fordulhatnak elő (vagy sokkal ritkábban), az mindenki számára előnyös – miért ne tennénk ezt? A C++ ebből semmit sem ad nekünk a következő évtizedben sem, és a C++ nyelvi bizottság problémái arra utalnak, hogy aki fenntartható kódbázist akar hosszú távon, az jobban teszi, ha minél hamarabb elhagyja ezt a nyelvet.

A Rust lehetőséget ad arra is, hogy az in-kernel API-jainkat úgy definiáljuk, hogy szinte lehetetlen legyen rosszul használni őket. Túl sok bonyolult és trükkös API-nk van, amelyek túl sok karbantartói átvizsgálást igényelnek csak azért, hogy „biztosak lehessünk benne, hogy jól használtad”. Ez részben abból fakad, ahogy az API-jaink az évek során fejlődtek (hány különböző módon lehet egy struct cdev-et biztonságosan használni?), és abból, hogy a C nem teszi lehetővé az API-k olyan formában történő kifejezését, amely biztonságosabbá és könnyebben használhatóvá teszi őket. Az, hogy minket, ezen API-k karbantartóit újragondolásra kényszerít, JÓ dolog, mert ezáltal mindenki számára – már a C felhasználók számára is – tisztábbá és jobbá tesszük őket, így a Linux összességében is jobb lesz.

És igen, a Rust kötései varázslatnak tűnnek számomra egyes helyeken, mivel nagyon kevés Rust-tapasztalatom van, de hajlandó vagyok tanulni és együtt dolgozni azokkal a fejlesztőkkel, akik hajlandóak segíteni ebben. Nem tanulni és nem változtatni az új bizonyítékok alapján (lásd a megjegyzésemet arról, hogy minden kernelhibát elolvasok) egyszerűen ostobaság lenne.

A Rust nem „ezüstgolyó”, amely minden problémánkat megoldja, de rengeteg helyen hatalmas segítség lesz, így ha új dolgokról van szó, miért ne akarnánk ezt?

A Linux egy eszköz, amelyet mindenki más használ a saját problémáinak megoldására, és itt vannak fejlesztők, akik azt mondják: „Hé, a mi problémánk az, hogy olyan kódot akarunk írni a hardverünkhöz, amelyben ezek a hibák automatikusan nem fordulhatnak elő.”

Miért hagynánk ezt figyelmen kívül?

Igen, tisztában vagyok a túlterhelt karbantartói problémával (mivel én is egy vagyok közülük), de itt vannak emberek, akik valóban elvégzik a munkát!

Igen, a kevert nyelvű kódbázisok nehezen kezelhetők és fenntarthatók, de mi kernelfejlesztők vagyunk, az isten szerelmére! Már régóta fenntartjuk és erősítjük a Linuxot, sokkal hosszabban, mint bárki valaha is gondolta volna, hogy lehetséges lesz. A fejlesztési modellünket egy jól működő mérnöki csodává alakítottuk, olyasmivé, amit senki más nem tudott elérni. Egy új nyelv hozzáadása igazán nem kellene, hogy problémát jelentsen – ennél sokkal rosszabb dolgokat is kezeltünk már, és most sem szabad feladnunk, ha a projektünk sikerét akarjuk biztosítani a következő 20+ évre. Amikor új, jó ötletekkel találkozunk, előre kell lépnünk, és támogatnunk kell azokat az embereket, akik ténylegesen elvégzik a munkát annak érdekében, hogy mindannyian együtt sikerrel járjunk.

Köszönettel,

Greg K-H

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

( bzt | 2025. 02. 20., cs – 16:45 )

Szerkesztve: 2025. 02. 20., cs – 16:55

A szokásos rusztafári ömlengés és bullshitelés mindenféle konkrétum nélkül.

amivel találkozunk, a C-ben lévő apró, bosszantó, speciális esetek miatt keletkeznek – ezek a Rustban teljesen eltűnnek.

Dehogy tűnnek el. Ez konkrétan bullshit, amit konkrét példák milliói cáfolnak.

ha Rustban írjuk őket, ahol ezek a hibák egyszerűen nem fordulhatnak elő (vagy sokkal ritkábban)

Dehogynem fordulnak elő. Arról nem is beszélve, hogy a kernel legtipikusabb memóriastruktúrái (láncolt listák és gráfok) a borrow checker miatt eleve MEG SEM VALÓSÍTHATÓak Rust-ban, szóval az egész kernelt át kéne írni hozzá.

A Rust lehetőséget ad arra is, hogy az in-kernel API-jainkat úgy definiáljuk, hogy szinte lehetetlen legyen rosszul használni őket.

Hazugság. Mivel C-vel is illeszteni kell, ezért unsafe nélkül nem is lehetséges. Ráadásul az FFI további biztonsági problémákat okoz.

És igen, a Rust kötései varázslatnak tűnnek számomra egyes helyeken, mivel nagyon kevés Rust-tapasztalatom van

Na tessék, saját maga ismeri be, hogy NEM IS ÉRT HOZZÁ, úgy próbálja meg osztani itt az észt.

Hogy én mennyire ki nem állhatom az ilyen álszakértő faszkalapokat, rengeteg kárt okoznak az IT-ban! Én inkább hallgatnék a megbecsült, nagy múltú C kernel fejlesztőkre, semmint egy olyanra, aki nem is ért a Rust-hoz!

"Olyan dolgokról van szó, mint az egyszerű memóriafelülírások (nem mintha a Rust mindet képes lenne elkapni), a hibakezelési takarítások, az error értékek ellenőrzésének elmulasztása és a use-after-free hibák."

A linkelt "ellenpélda" egy másik hibáról, a memory leak-ről szól.

Bár nem szeretem a Rust-ot, de azért ismerjük el, hogy a borrow-checker sok egyszerű alap hibát kiküszöböl.

A linkelt "ellenpélda" egy másik hibáról, a memory leak-ről szól.

Nem igaz. Van ott szó bőven memory vulnerability-ről is! De egy pár perces kereseséssel te is bőven találsz ellenpéldákat, konkrét esettanulmányokkal. Nem nehéz, mert baromi sok van. Nyilván memleak-es ellenpélda is akad bőven, de memory vulnaribility ellen sem ér fabatkát sem.

Bár nem szeretem a Rust-ot, de azért ismerjük el, hogy a borrow-checker sok egyszerű alap hibát kiküszöböl.

...és egy csomó, a kernel által jelenleg használt struktúrát meg lehetetlenné tesz! Ha nulláról indulnának, az egy dolog lenne, de itt már meglévő C kódhoz való illesztésről van szó, ami ég és föld. Ez utóbbi unsafe nélkül lehetetlen, így az összes fennen hangoztatott Rust "előny" megy élből a kukába!

Tényleg nem értem, hogy a Rust-afárik miért nem írják meg nulláról a kernelt.

Ha ennyire egyszerű™ és hatékony™ ez a nyelv, elvileg kevesebb idő alatt újraírnák benne a kernelt, mint amennyi ideje a Red Hat a Waylandot gányolgatja (úgy 16 éve). Tök jó lenne, ha az ilyen szélsőséges indealizmusok, trendbuziskodások nem a Linuxot basznák szét, forgatnák fel, hanem legalább elkülönülnének. Mivel ezt a szutykot is leginkább a multik nyomják meg hátszéllel (Microsoft, Google, Amazon), csinálhatnának is egy OS-t, amit csak és kizárólag Rust-ban írnak. Nem, azt nem. Inkább felforgatjuk a Linux-világot, hogy az ingyenfejlesztőknek ne legyen más választásuk, mint a mi idealizmusaink szerint fejleszteni.

De tényleg mit erőlködnek a Linux kernelben?

Ha annyira fasza a Rust, akkor írjanak egy saját kernelt/oprendszert és mutassák meg, hogy miben jobb, mint a jelenlegi. Senkinek nincs szüksége sem a felhajtásra, amit ezzel a szituációval generálnak, meg a plussz körökre, amit a Rust bevezetése miatt meg kell futni.

Szerinted akik idáig csinálták és teljesen jól megvannak a jelenlegi környezetükben, most azok menjenek BSD-zni, mert a kékhajú (újfiúk | lányok | delfinek | *) beleszartak a homokozóba?

A Redox kernel ki tudja váltani egy az egyben a Linux kernelt? Nem. Akkor hajrá! Lehet azt reszelgetni.

szerk.: nem a Rust-ot utálom. Anno tetszett nekem is, neki is álltam, hogy megtanuljam.

Szerintük a Rust egy jó és hasznos dolog a Linux kernelben, és nem egy másik OS-t akarnak írni.

Aki másikat akart írni, az más OS-t ír. Sokan egyetértenek velük, mások nem, megint mások elvben igen, de másképp csinálnák.

Ebből (egyébként hasznos) viták alakulnak ki, amiket valamilyen formában fel kell oldani, és ami nem mindig egyszerű dolog, ennek a folyamatát látjuk most.

Szerintem hosszú távon jobban járunk, ha megoldják azt, hogy hogyan legyen kétnyelvű (C & Rust) a Linux. Nem lesz egyszerű, lesznek akik emiatt abbahagyják a fejlesztését, de mások meg pont emiatt fogják elkezdeni. Korábban is voltak nagy drámák (CK kernelek, processzütemezők, PaX / grsecurity), amik jól - rosszul lettek kezelve. Ettől még a Linux köszöni szépen jól van.

Ez egy nehéz dilemma. Hosszú távon szerintem is egyértelmű az előny, de addig a rövidtávon kell átvergődni valahogy. Ráadásul úgy, hogy igazából nem látod, nincs mérhető metrikád rá, hogy mi az amit még "kibír" a projekt. Rohadtul nem szívesen lennék ilyen döntéshozó pozícióban.

Ami szintén necces dolog, hogy a jövőben a céges kontribuciók csökkenő mennyiségére lehet számítani. Olyan cégek, mint az Intel, amik eddig nagyon sok kernelfejlesztőt fizettek, most éppen eléggé bukóágon vannak. Pillanatnyilag pont olyan cégeknek áll a világ, mint a Broadcom meg az Nvidia, amik hírhedtek voltak az open-source ellenes hozzáállásukról. Amazon - van saját from-scratch fejlesztett hypervisor-uk, kb annyira érdekli őket a Linux, hogy fusson AWS-en. Microsoft, dettó ugyanez Azure-rel. Apple - teljesen saját OS-ük van, leginkább abban érdekeltek, hogy minél kevésbé legyenek interoperábilisek bármivel a saját ökoszisztémájukon kívül. Google - hát amit a W3C-ben művelnek, az alapján talán jobb ha nem fejlesztenek a kernelbe... 

Régóta vágyok én, az androidok mezonkincsére már!

Én azt gondolom (remélem :) ), hogy Linus ezeket átgondolta ... :) 

Szerintem minden hardvergyártó cég főleg olyan dolgokon dolgozik, a kernelnél is, amitől azt reméli, hogy több HW-t fog tudni eladni. A Qualcomm pl. pont azért, mert ők most az "ARM világ AMD-je" (és nyilván ez az analógia sántít, mert ugye itt bőven nem 2 szereplős a piac, hanem ott van az Apple, Nvidia mellett a Samsung, Broadcom + a kínai gyártók :) ) végre elkezdte az X Elite chipsetek mainline Linux supportját csinálni, nem csak az Androidos kernelt adják ki rá.

A Google W3C ténykedését nem követtem, ha arra gondolsz, hogy mostanra a W3C = amit a Chrome tud, akkor ez szerintem nem (csak) a Google hibája, hanem kb. mindenki másé is, beleértve "minket" = az egész fejlesztői közösséget, akiket kb. nem érdekelt, hogy mi folyik a W3C-ben. Ezzel együtt a Wasm szerintem relatíve jól sikerült mostanra, bár a GC nem lett egy sikertörténet, pont Varga Zoltán (korábban Mono / Xamarin, most MS .NET VM fejlesztő) írta meg nekik Githubon, hogy amíg nem csinálják meg rendesen, addig a .NET nem fogja tudni használni. Ennek lassan 5 éve ...

Ami szerintem viszont nagyon félrement, az a WebGPU. Amikor kiderült, hogy az Apple nem megy bele, hogy SPIR-V legyen a shader formátum, akkor kellett volna beszántani az egészet, és megcsinálni a WebVulkan - WebMetal speceket, amiknek volt is PoC implementációjuk. Ez egy nagyon vékony wrapper lett volna a "rendes" Vulkan / Metal felett, néhány korlátozással, de nem kellett volna teljesen új renderer backendet írni hozzá mindenkinek, amit még a browsergyártóknak vissza kell konvertálniuk Vulkanra / Metalra, hogy biztos lassú legyen. Aki ebben a világban dolgozik, már úgyis megcsinálta a Vulkan és Metal rendererét, az a 3 ember, aki meg most kezdte volna, az megírja a Vulkant, és Metalhoz meg használja a MoltenVK-t.

Visszatérve a Google vs kernel témára: szerintem az Android kernellel elég korrekt munkát végeznek (amit persze a gyártók általában szétgányolnak, de aktívan próbálják őket terelgetni a közös kernel irányába). Pl. megcsinálták a stabil Linux kernel modul API-t az Android kernelekben, amit itt a HUP-on ~20 éve hiányoltak a Linuxból a Solaris fanok. 

Igen ahogy sejted, elsősorban pont arra gondolok, hogy ha a Google ugyanúgy egyedül marad nehézsúlyú szereplőként, mint a W3C-nél, akkor pontosan W3C == Chrome eset fog megismétlődni, csak ezúttal Linux == Android formában. Szerintem abból a szempontból cikis leginkább, hogy a webes api-kat telefosták olyan feature-ökkel, amik security és főként privacy szempontból katasztrofálisak, aztán - mikor már boldog-boldogtalan visszaél vele - eső után köpönyeg jelleggel kell agyalni rajta, hogy lehetne valahogy valami kontrollt visszaadni a felhasználó kezébe. Főleg a mikrofon-kamera-webrtc környékén ment ez, de kb minden alkalommal megismétlődött a menetrend. Abban biztos vagyok, hogyha többszereplős a játék, akkor legalább ki van kényszerítve egy diskurzus - még a feature szabványba felvétele előtt - hogy ezzel potenciálisan hogy lehet visszaélni és hogy kéne ezt megelőzni.

A stabil kernel driver API ugyanúgy egy elég problémás dilemma volt anno, mert benne van a pakliban, hogy beleragad a kernel egy állapotba és onnan nem lehet változtatni. Szerintem az elmúlt 20 év azt igazolja, hogy az volt a helyes irány, hogy nem csináltak ilyet. Ha a kernel dominánsan a Google kezébe kerül, akkor szinte biztos átnyomja ezt is, ami hosszú távon többet is árthat, mintha csak a "C" nyelv maradna fixen.

Amúgy teljesen off jelleggel, érdekes amit mondasz a WASM-ről. Nem követtem ezt a részét, most kezdtem utánaolvasni, nem volt meg, hogy ennyire gáz a helyzet.

Régóta vágyok én, az androidok mezonkincsére már!

Igen, ezt mondtam én is. Írják meg a rust-osok a saját kernelüket a 0-ról. Nem kicseszésképpen, vagy szarkazmusból mondva, hanem ha tényleg az alapoktól felépítik saját maguk, a saját fejlesztési metodikájukra, és a Rust képességeire alapozva, akkor nem lesznek kötve egy C-s projekt korlátaihoz, nem lesz kivel súrlódjanak. Ez nekik is tényleg jó lenne, egy jó alkalom, hogy megmutassák mit tudnak, ha nem gáncsolja őket senki.

Azt meg ne higgye ám senki, hogy képzett fejlesztőnek unixlike kernelt írni annyira nehéz, van rá már egy csomó opensource példa, az eredeti-kiadott unixos és BSD-s kódoktól kezdve a Linuxon át, a Redox OS-ig, GNU Hurd-ig (igen, ez egy vicc, de működik, kódot lehet belőle nyúlkálni). Tehát nem kell saját kútfőből nekimenni, vannak rá dokumentált rendszerhívások, megírt példakódok, sőt, az AI is itt jöhet be, hogy API-kból gyorsan tud boilerplate kódot gyártani. Az AI hülye, megbízhatatlan, de ilyen sablonfeladatban segíthet, megmenthet egy csomó gépeléstől, stb..

Nem is kis munka, azt nem mondom, de nem is egyfejlesztős projektként indulna, ahogy anno Torvlads egy floppy-s egyetemista projektje. A rust-osoknak lépéselőnye lenne, jobb fejlesztői gépek, jobb IDE-k, virtualizáció, több tesztelési lehetőség, mindjárt több fejlesztő megy neki, nagy multik szponzorálják.

Igazából még nekünk begyöpösödött linuxosoknak is jó lenne, mert ha pl. a Linuxszal történik valami, akkor nem csak a BSD-k lesznek ott, meg az Illumos alapú cuccok, hanem lenne még egy alternatív FOSS platform, akár szeretjük a Rust-ot, akár nem, akkor is plusz alternatíva. Ezen rendszerek között úgyis van átjárás, mert ugye a unixos szabványok (POSIX, SUS, libc, stb.) garantálnak valamilyen mértékű átjárhatóságot, még ha adott esetben van is némi különbség a rendszerek között, pl. más initrendszer, más csomagkezelő, más virtualizáció, más konténerizáció, eltérő alapokon nyugvó (nem X11 alapú) felület.

Igazából egy tisztán Rust-os unixlike OS-re már van kész egy csomó Rust-kód, átportolták a GNU coreutils-t is már, uutils a neve, meg van egy csomó újraírt klónutasítás (bat, fd, ripgrep, stb.). Redox OS-ből is lehet egy csomót nyúlni. Van már pár kész Linux kernel driver is Rust-ban, jó, azokat át kell írni, de akkor se 0-ról indulás.

Szerk.: jó párhuzam erre a Google Chrome. Annak idején is úgy tartották, hogy böngészőt nehéz írni, túl sok munka, túl sok optimalizáció, nem éri meg senkinek. Aztán jött a Google, és a semmiből, 2009-ben előállt a Chrome-mal, ami mindjárt kezdetben is gyorsan sikeres lett, 10 év múlva meg egyeduralkodó, 10 millió kódsorossá hízott már akkor, pedig nem is dolgozott rajta annyi fejlesztő, mint a kernelen. Még 6 évre rá, mára meg 45 millió kódsoros már, veri a kernelt is. Az is igaz, hogy a Google milliárdokat ölt bele, de akkor is szépen mutatja, hogy nem kell hozzá 35 év, hogy utolérjék a Linux kernelt.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Egyelőre lehet, hogy unsafe-fel indul a buli, de ez változni fog.

Az nem érv, hogy valamire van ellenpélda. A világon mindenre van ellenpélda.

Valójában teljesen mindegy, hogy mi itt mit gondolunk. Nem a mi - többé vagy kevésbé szakmai - érveinken fog ez eldőlni. Engem különösen zavar, hogy sokan érvelnek érzelmi, mintsem tudományos alapon.

Én inkább hallgatnék a megbecsült, nagy múltú C kernel fejlesztőkre, semmint egy olyanra, aki nem is ért a Rust-hoz!

Greg Kroah-Hartman:

As of April 2013, he is the Linux kernel maintainer for the -stable branch,[2] the staging subsystem,[2] USB,[2] driver core, debugfs, kref, kobject, and the sysfs kernel subsystems,[2] Userspace I/O (with Hans J. Koch),[2] and TTY layer.

Kik lennének a „megbecsült, nagy múltú C kernel fejlesztők”?

Kedves therion, bedőltél a parasztvakításnak. Ez a Greg hosszasan sorolja és öntömjénezi magát, hogy ért az A-hoz, majd pedig véleményt mond B-ről. Te meg simán, gondolkodás nélkül bedőltél ennek az átlátszó olcsó szemfényvesztésnek. Erről ennyit.

Kiemelem MÉGEGYSZER: Greg Kroah-Hartman:

nagyon kevés Rust-tapasztalatom van

Ezt saját maga ismerte be, persze csak a végén, mert azt már úgysem olvassák el egyesek!

Kik lennének a „megbecsült, nagy múltú C kernel fejlesztők”?

Azok, akik marketing bullshit helyett szakmai érvekkel állnak elő. Greg részéről NULLA szakmai érv hangzott el, csak a szokásos rusztafári mantrákat tolja, amik egyébként konkrét hazugságok, erről bárki meggyőződhet egy pár perces webes kereséssel.

Kiemelem MÉGEGYSZER: Greg Kroah-Hartman: nagyon kevés Rust-tapasztalatom van
Ezt saját maga ismerte be, persze csak a végén, mert azt már úgysem olvassák el egyesek!

Ilyeneket szerénységből szoktak írni. Van rá egy 6pack-em, hogy sokan örülnének annak a kevés Rust-tapasztalatnak...

Honnan tudod, hogy IT influenszer bullshitet olvastál? Onnan, hogy a szöveg önmagának is ellentmond.

"nem fordulhatnak elő (vagy sokkal ritkábban)"

Tehát előfordulhatnak.

"szinte lehetetlen"

Ami szinte lehetetlen, az nem lehetetlen, tehát lehetséges.

Én inkább hallgatnék a megbecsült, nagy múltú C kernel fejlesztőkre, semmint egy olyanra, aki nem is ért a Rust-hoz!

Hamarosan eljutunk oda, hogy a C-ben kódoló kernel-fejlesztőket nyilvánosan megalázzák, laggardoknak, dinoszauruszoknak állítják be az ottani Raynes-ek, dorsykák és Zeller Mérnök Urak, valamint "bezzeg, ha Rust-ban írtad volna" alapon teszik őket felelőssé a hibákért, miközben a Rust-ban elkövetett gányolások felett természetesen szemet húnynak és mélyen kussolnak.

Különszám, hogy egy lapon említi a fenntarthatóságot és a Rust-ot. Vajon állandó netkapcsolatot igénylő cargo-t látott már közelről? Esetleg üzemeltetett ilyen registryt annak minden járulékos bloat posványával együtt? Ja nem, mert nem ért hozzá, csak influenszerkedik.

Ez azert nem igy megy. Volt szerencsem ott lenni a Rust Nation UK-n par napja. Meg nincsenek fent a videok, ugyhogy belinkelni nem tudom, de Alice Ryhl a Google-tol tartott egy eloadast arrol, hogy hol tart a rust a kernelben. Sok mindent bele kellett / kell tenni a Rustba ahhoz, hogy a kernelben tamogatott legyen. Tehat elsosorban a Rust igazodik a kernelhez, es nem forditva. Es nem influenszerek hajtjak a projectet, es nem is lobogo haju free software hackerek, hanem a nagy halak, e.g. Google, MS, RedHat etc.
https://www.rustnationuk.com/schedule

A fo kulonbseg az, hogy a nagy cegek igenis motivaltak, ugyhogy szerintem ez haladni fog. A hianyzo nyelvi funkciokat bele fogjak rakni a Rustba, legfobb ellenero inkabb az, hogy a Rust nem standardizalt, mig a C ISO standard. A kernelfejlesztoknek kellenek garanciak, hogy x-y feature nem fog eltunni a nyelvbol / stdlibbol.

legfobb ellenero inkabb az, hogy a Rust nem standardizalt, mig a C ISO standard.

Semennyire nem releváns a kernelfejlesztés szempontjából, hogy a C-nek van ISO által sztenderdizált változata, mivel nem azt használják, tele van a kernel forrása olyan dolgokkal, ami nem része a szabványnak.

The kernel is written using GNU C and the GNU toolchain. While it adheres to the ISO C89 standard, it uses a number of extensions that are not featured in the standard. The kernel is a freestanding C environment, with no reliance on the standard C library, so some portions of the C standard are not supported.

Lehet neked akármilyen standard compliant C fordítód, nem fogod tudni vele a kernelt lefordítani.

Igaz. Az egyik pelda arra, hogy miket kell tamogatni a Rust-nak, az a "goto label", amikor assembly-bol ugrasz ki C kodra. Valszeg ez sem ISO standard.
A lenyeg, ami nekem lejott az eloadasbol, hogy fenntartas van azzal kapcsolatban, hogy a nyelvbol ki is kerulhetnek dolgok vagy megvaltozhatnak, es ez ellen akarnak valamilyen garanciat. Gondolom, a GNU project eleg garancia arra, hogy a GNU C-vel nem fog ez tortenni. A GNU Rust compiler (gccrs) nem egy kiforrott project.

Ja, pont ezt akartam írni.

"mivel nagyon kevés Rust-tapasztalatom van, de hajlandó vagyok tanulni és együtt dolgozni azokkal a fejlesztőkkel, akik hajlandóak segíteni ebben"

Szóval nem ismeri a Rust-ot, de lelkesedik érte. Majd elmúlik.
Azok a C hibák, amiket említett, elég tipikusak. De Rust-ban meg majd lesznek mások. Illetve ott van az a use-after-free. Az nem úgy szokott történni, hogy hívok egy kfree-t, majd használom a struktúrát ugyanabban a rutinban. Hanem inkább úgy, hogy megvolt a kfree(), de aztán jön még egy callback, és az fogja használni azt a bizonyos változót. Az ilyenek ellen semmilyen programnyelv nem fog megvédeni.

Öhm... Kedves bzt, minden tisztelettel, de te most tényleg le álszakértő faszkalapoztad Greg KH -t? Ez azért egy kicsit erős, és ha belegondolsz, kontraproduktív is, mert aki ilyet ír, annak az egyébként valid érveit hajlamos az ember kevésbé végiggondolni, mert úgy véli, hogy csak indulatból ír, azzal meg tele a bulvár, úgyhogy skip.

Kedves bzt, minden tisztelettel, de te most tényleg le álszakértő faszkalapoztad Greg KH -t?

Kedves YieGreg, te most tényleg ennyire gyatra vagy magyar nyelvű szövegértésből?

Nem is én állítottam, hogy Greg nem ért a Rust-hoz, hanem saját maga. De neked olvasni finnugrot nem megyen, igaz-é? És igen, ha valaki úgy nyilatkozik, hogy tudja, nem is ért hozzá, az biza' kontraproduktív és faszkalap, akárcsak az itteni szánalmas TROLLok.

Nem azt írta, hogy nem ért hozzá, hanem hogy "And yes, the Rust bindings look like magic to me in places, someone with very little Rust experience, but I'm willing to learn and work with the developers who have stepped up to help out here.".

Az ő múltjával én úgy vélem, hogy ami nála "very little Rust experience" az egy olyan magasra tett léchez képest very little mint a C tudása. Vagyis egy sima Rust programozó aki csak a Rust -hoz ért, az azt hiszi, hogy már milyen sokat tud, de aki egy más nyelvet kívül-belül az utolsó szögig ismer, az az egyébként erős Rust tudásáról simán úgy vélekedhet, hogy "de hiszen alig ismerem, még csak pár éve használom...".

Lehet, hogy én felülbecsülöm GKH tudását, de az alapján amit eddig letett az asztalra, szerintem eléggé végiggondolta amit mondott, és ha a C tudásához képest úgy is érzi, hogy még kevés a tapasztalata a Rust -al, szerintem annyira biztosan beleásta magát, hogy megbízható véleményt tudjon alkotni. Én bízom az értékítéletében.

Szerintem Greg látnok. Mondom ezt keményvonalas C-sként.

Számomra egyre nyilvánvalóbb, hogy mainstream-ben a Rust lesz az új C.
Nyilván van egy csomó kiöregedő fejlesztő, aki egész életében C-ben fejlesztett, talán még hexadecimális szorzótáblával kezdett, és minden emléke, élménye ehhez az ökoszisztémához kötődik, nem tudja ezt elfogadni. Szerintem ők a peronon fognak maradni.

Ez nem azért lesz így, mert szar a C. Hanem mert változtak az igények.

( samu.ferenc | 2025. 02. 20., cs – 17:48 )

Egy új nyelv hozzáadása igazán nem kellene, hogy problémát jelentsen

Ez még felkerülhet a híres utolsó mondatok közé ;)

A fejlesztési modellünket egy jól működő mérnöki csodává alakítottuk, olyasmivé, amit senki más nem tudott elérni.

Ha jól értem, most éppen ezen a jól működő modellen akarnak változtatni?! Akkor mi jelentősége annak, hogy eddig jól működött. A C-hez, Rust-hoz nem értek, de általában a a komplexitás növekedésével, a hiba lehetősége is növekedni szokott. A hibafaktor eddig is az ember volt, aki nem írt megfelelő C kódot, most ezt cserélik le, egy másik emberi hibára lehetőséget adó dologra, a kevert nyelvű kódbázisra. 

Sőt én továbbmegyek. Értem, hogy GKH igyekszik lelkesítő lenni, de az a mérnöki csoda a válságát éli. Ezt a válságot pedig az utápótlás nélküli; hálátlan feladatba belefásuló, kiégéshatáron lévő maintainerek jelentik (vagy ahogy tetszik, ők a fő tünetei). Hogy valójában mekkora válság, azt nem tudom hogy meg tudjuk-e ítélni kívülről. 

De az biztos, hogy az utolsó dolog, amit a szerettek volna a nyakukba kapni, az a projekt kétnyelvűsítése, amiben az átjárást biztosító binding-ok integritása felett is nekik kell őrködniük. Úgy, hogy a napi kb 1000 pull request átnézése mellett kéne felszedniük a rust-ot, ráadásul olyan mélységben, amilyenben a legtöbb napi szinten rust-ban kódoló fejlesztő sem érti.

Biztos vagyok benne, hogy ez még sok maintainernek fogja megadni a végső lökést, hogy otthagyja a projektet. Ami - mint változtatás - nem a válságból kilábalás irányába viszi a dolgokat.

(Ettől függetlenül értem azt is, hogy miért nyomatják a Rust-ot. Könnyen lehet, hogy az elutasítása ugyanúgy a projekt hosszabbtávú megrekedését eredményezné. Ez egy baromi nehéz kérdés, amire szerintem nincs egyértelműen jó megoldás.)

Régóta vágyok én, az androidok mezonkincsére már!

Értem, hogy GKH igyekszik lelkesítő lenni, de az a mérnöki csoda a válságát éli.

GKH egyetlen mérnöki vagy szakmai érvet sem hozott fel, csak a szokásos bullshitet puffogtatta.

ráadásul olyan mélységben, amilyenben a legtöbb napi szinten rust-ban kódoló fejlesztő sem érti.

Azért tudsz te okosat is mondani, ha akarsz. Pontosan erről van szó. És még tegyük hozzá azt is, hogy a Rust nincs rendesen specifikálva, a fordító napi szinten változik.

Biztos vagyok benne, hogy ez még sok maintainernek fogja megadni a végső lökést, hogy otthagyja a projektet. Ami - mint változtatás - nem a válságból kilábalás irányába viszi a dolgokat.

Szerintem pontosan ez a cél, a Microsoft így akarja belülről szétbomlasztani az egyetlen épkézláb konkurenciáját. A Linux Foundation már a kezükben van, ezzel befogták Linus száját.

Ettől függetlenül értem azt is, hogy miért nyomatják a Rust-ot. Könnyen lehet, hogy az elutasítása ugyanúgy a projekt hosszabbtávú megrekedését eredményezné.

Ezzel vitatkoznék. Hosszú távon mindig könnyebb egy unilanguage projektet továbbvinni.

"Azért tudsz te okosat is mondani, ha akarsz."

s/ha akarsz/ha az történetesen egyezik a véleményemmel/ - jól gondolom?! :)

"Microsoft így akarja belülről szétbomlasztani az egyetlen épkézláb konkurenciáját" - hagyjuk már ezt, jó? Nem a 2000-es évek elején vagyunk. Apple, Google, Meta. Ők például konkurenciák. Nem a Linux eltiprásán múlik a Microsoft jövője.

"GKH egyetlen mérnöki vagy szakmai érvet sem hozott fel," - azért elég sokan elmondták már a szakmai érveket. Mert megold egy problémát, amit eddig más nyelv nem tudott megoldani: memóriabiztosságot adni garbage collector és mindenféle memory manager runtime nélkül. Ez utóbbiak lényegében ellehetetlenítették a memóriabiztos programnyelvek használatát kernel-fejlesztésre (néhány nagyon ezoterikus próbálkozástól eltekintve, ahol pl Java-ban próbáltak kernelt írni).

Igen, valóban találtak benne egy olyan speciális esetet, ahol a memory leaket elvileg sem tudja fordítási időben kivédeni. Más kérdés, hogy eléggé szándékosan akarni kell azt a helyzetet (ciklikus Rc referenciák) előidézni. Ez nem egy olyan dolog, amit csak úgy könnyen "benéz" egy fejlesztő, pláne ha hallott is róla, hogy ez kerülendő. 

Kérdés: meg se próbálkozzunk vele, mert nem 100%-os (csak 99)?

Kérdés 2: meg se próbálkozzunk vele, mert a fordító változik (mint ahogy a gcc is elég sokat változott az évek alatt, főleg a korai időkben, aztán meg jött az llvm/clang)?

Kérdés 3: meg se próbálkozzunk vele, mert agytorzító benne programozni? Különösen annak aki C-származék nyelvekhez szokott

Kérdés 4: meg se próbálkozzunk vele, mert a felfoghatatlanul nagy C-ben megírt kódbázis miatt esélytelen belátható idő alatt átírni az egészet?

 

Én is hajlok arra, hogy ez nem volt jó döntés, de teljesen más okból, mint amiket te próbálsz felhozni. És hajlok arra is, hogy az elutasítás sem lett volna jó döntés, mert hosszú távon bezárja a Linuxot egy idővel egyre inkább elavuló programozási környezetbe. Ami nem most azonnal fog kiütközni, hanem 10 év múlva (ha még lesz akkor elő ember). Erre nem volt jó válasz. Illetve hát lehetett volna még húzni az időt a döntéssel (dolgoztam olyan cégnél ahol ez volt a hozzáállás, na ők pl már nem konkurenciái se a Microsoftnak, se Apple-nek, se Google-nek...). Csak kérdés, hogy mi az az információ amire Linus-nak várnia kellett volna, ami alapján jobban tudna dönteni a jövőben?

Régóta vágyok én, az androidok mezonkincsére már!

s/ha akarsz/ha az történetesen egyezik a véleményemmel/ - jól gondolom?! :)

Rosszul gondolod.

azért elég sokan elmondták már a szakmai érveket.

Citation needed. Én még egyetlen konkrét szakmai érvet sem hallottam a Rust mellett, csak bullshitelést. A topiknyitóban sem szerepel egy komoly érv sem, csak a szokásos bullshit (ráadásul amiket ellenpéldák cáfolnak, keress csak rá, egyik Rust állítás sem állja meg a helyét a gyakorlatban).

Ellenben a Rust ellen érvelők nagyon is konkrét szakmai érveket hoznak fel, lásd másik topik.

Igen, valóban találtak benne egy olyan speciális esetet, ahol a memory leaket elvileg sem tudja fordítási időben kivédeni.

Legalább olvasd el, amit linkeltem, mielőtt írsz. Memory vulnerability-ről van leginkább szó (bár a memleak ellen sem véd, tény).

Más kérdés, hogy eléggé szándékosan akarni kell azt a helyzetet (ciklikus Rc referenciák) előidézni. Ez nem egy olyan dolog, amit csak úgy könnyen "benéz" egy fejlesztő, pláne ha hallott is róla, hogy ez kerülendő.

Ébresztő, a Linux kernel tele van kettős láncolt listával, ami pont ilyen! És nem, nem a kernel fejlesztők nézték be, szándékosan van így implementálva, méghozzá okkal.

Az a baj, hogy már megint azonnal nagyon sommás véleményed van valamiről aminek a darabaji nem kerültek a helyükre nálad.

"Legalább olvasd el, amit linkeltem, mielőtt írsz. Memory vulnerability-ről van leginkább szó"

Az FFIChecker-esről beszélsz? Elolvastad, vagy csak az abstractig jutottál? Segítek: ha nem a Springer felől akarod elérni, akkor nincs paywall: https://zhuohua.me/assets/ESORICS2022-FFIChecker.pdf Ahogy olvasom egyetlen konkrét vulnerability-t sem talált. Talált leak lehetőséget, talált undefined behavoir-t, és exception kezelési hibát. Meg talált egy szakajtónyi fals pozitívat. Nem írnak a cikkben arról, hogy bármelyik talált hiba önmagában kihasználható lett volna. Végig "may lead to potential vulnerabilities" a megfogalmazás.

És ez nem a Rust problémája, hanem a kétnyelvűség problémája. És a cikk lényegében pont arról szól hogyan lehet statikus checkert fejleszteni az ilyen hibák megfogására -> a jövőben ezek jobban szűrhetőek lesznek.

" tele van kettős láncolt listával, ami pont ilyen"

A kettős láncolt lista egy másik probléma, mint a Rc körbehivatkozás. Én anno végigcsináltam ezt a tutorialt: https://rust-unofficial.github.io/too-many-lists/ ami a láncolt lista különféle lehetséges implementációin - mint állatorvosi lovon - keresztül mutatja be az egész nyelvet, a borrow checker összes corner case-ével együtt. Egyébként javaslom, mert helyrerak sokmindent (ugyanakkor nem is hozta a kedvemet, hogy rust programozó legyek...). Persze *lehet* úgy is csinálni, hogy a ciklikus Rc problémába belefuss. De a javasolt módszer, hogy a visszirányba kell egy unsafe raw pointer, ha nem akarsz gyenge referenciákat használni.

Azt kell megértened, hogy a generics támogatás miatt ezt az unsafe részletet egyszer kell a kernelben jól megcsinálni, és nagyon alaposan reviewzni. Onnantól mindig lehet ugyanazt újrahasználni. C-ben a reuse nem ilyen tiszta.

(Edit: typo fix)

Régóta vágyok én, az androidok mezonkincsére már!

Az a baj, hogy már megint azonnal nagyon sommás véleményed van valamiről

Az a baj, hogy már megint azonnal nagyon sommás véleményed van valakiről, miközben nem is ismered.

Elárulom, én ha állítok valamit itt a HUP-on, akkor biztos lehetsz benne, hogy alaposan utánajártam a témának. Ezért van az, hogy nekem van igazam, a TROLLok meg tévednek. Nem azért, mert tévedhetetlen szupermen lennék, hanem mert posztolás előtt én elvégzem a házi feladatot, míg ők nem. Ennyi.

Itt most történetesen Rust-C illesztés ügyben ráadásul nemcsak elméleti, hanem többéves gyakorlatom és saját tapasztalatom is van. Tömören: nem jó.

Ms így akarja belülről szétbomlasztani az egyetlen épkézláb konkurenciáját

Ugyan a rust programnyelvet nem ismerem, de amit az Ablakok 11-el leműveltek, hogy még a saját, addig valahogy  elműködgető rendszereiket - xp, Ablak 7 - is teljesen szétcseszik, pont elég bizonyíték arra, hogy  bzt-nek és Hajbinak van igaza.

Az Ablakok 10 is már baromi idegesítő, hogy ha tegnapra kész kellene lenni valaminek, bekapcsolom és elkezd frissíteni, több ujraidulással - mikor már 18 éve megígérték, hogy mellőzik az állandó ujraindulásokat -  pedig gpedit-ben be van állítva hogy 2 és az aktív időszakban teszi mindezt.

"A Windows 10 rendszer folyamatosan frissíti magát, hogy biztosítsa a legújabb biztonsági javításokat és funkciókat."

nem b..eg, ha valamit AKAROK azonnal csinálni, akkor ne bíráljon felül egy sz@r op rendszer.

Raynes- írta, hogy ez adta meg neki a végső lökést a Linuxra való rugalmas átmenethez. 

Régóta mondom, hogy az a legjobb operációs rendszer, amiről nem is tudja az ember, hogy létezik. Ha az oprendszer soha nem hátráltat, láthatatlanul a kezem alá dolgozik, és hagyja, hogy a munkámmal törődjek, akkor pont azt teszi, amit várok tőle.

Ez linuxnál többnyire megvan, mert csendes, nem nagyon kér enni, nem kér buksisimit, néha tol neki az ember egy apt/dnf/whatewer upgrade -et, de nagyjából ennyi.

Windowsnál meg próbálom kimozogni a hülyeségeit, én dolgozok vele, pedig én vagyok a fizető vendég, hát akkor miért nem én vagyok a főnök?! Miért nekem kell a sz4rt lapátolnom, és igazodnom az olyan hülyeségeihez, ami pár verzióval korábban még nem volt kötelező? Jó, hát ez valójában nem kérdőjel, mind tudjuk, hogy a pénz miatt. Kár, hogy nincs olyan Windows verzió, hogy oké, duplába kerül, de hagyjon békén a baromságaival, alapból kussol és tud annyit az ablakkezelő gyárilag, mint egy évtizedes KDE.

Az LTSC nagyjából az egyetlen ami még használható agykárosodás nélkül.

nem b..eg, ha valamit AKAROK azonnal csinálni, akkor ne bíráljon felül egy sz@r op rendszer.

Soha még nem fordult velem olyan elő, hogy csináltam valamit a gépen, és ezt megszakította egy windows update. Legalábbis az elmúlt 10 évből nem rémlik ilyesmi. Illetve de, egy céges gépen a központi management megoldás küldött ki valami zeroday patchet úgy, hogy 15 percem volt befejezni a futó munkát, de ezt a céges IT csinálta, nem a Microsoft.

Nálatok ez hogy működik? 4 hétig tologatjátok az update-eket (asszem ennyi a default limit), és pont 3 hét, 6 nap, 23 óra 55 percnél kezdtek nekiállni valami Nagyon Kritikus feladatnak, természetesen a beállított aktivitási időablakon kívül, mondjuk hajnali négykor?

Nem szoktam halogatni, de rendszeresen előfordul, hogy előveszem a táskámból a gépet, bekapcsolom és várnom kell, mert frissítéseket telepít. Volt, hogy hatósági átadáson kellett rá várni, volt hogy prezentáció előtt.

Természetesen ki tudom várni, de bassza már meg az öreg ördög. Nem azért vettem a gépet, hogy a Microsoft használja!

Kicsit elszaladt a ló! Ahogy írtam más témáknál is: az operációs rendszer feladata az erőforrások kezelése/elosztása és nem a felzabálása a felhasználó programok és a felhasználó elől!

Nálam is éjjelre/hajnalra van téve az inaktivitási ablak, és ez így többnyire jó is, de volt egy olyan éjjeli meló, amikor hajnali kettő körül kicsit hátradőltem míg vártam a kolléga munkájára, és amikor kinyitottam a szemem, azt láttam, hogy ne kapcsolja ki a gépet... Anyád.

A másik az részben céges policy utálat is, hogy jön hogy újra kell indítani a gépet, mer csak. Na, nnálam többnyire nem csak egy mail kliens meg egy excel van nyitva, hanem jó pár SSH ablak, meg minden ami létezik, mindig kell két két sor a tálcán az ablakok gombjainak. Na, ilyenkor nagy öröm ám újra beállítani a munkakörnyezetet, belépni mindenhova, csak mert ez a hipermodern gép képtelen lecserélni egy futó processzt egy másikra reboot nélkül, mert nem engedi el a filerendszerben a telepítés idejéig. A GUI lebutítása helyett inkább törődnének azzal, hogy az update miatt ne kelljen reboot. 2025 van csesszék meg, mióta tudta ezt már a legkreténebb egy floppys linux is? De legalább van virtuális desktop, azzal csak két évtizedet késtek...

A Windowsról ordít, hogy a MS sem veszi komolyan. Csak muszájból gányolja újra szét, ami az előző verzióban már kezdett jó lenni.

A céges policyk mindig tudnak érdekesek lenni. Nálunk pl. az (is) volt, hogy kitalálták, egy héten legalább egyszer újra kell indítani a gépet, ha valaki nem szokta lekapcsolgatni naponta. Ezt - hogy ne legyen nagyon zavaró, valamikor hétfő hajnalra tették. Ez csak akkor kellemetlen (de akkor nagyon), ha valamely okból vasárnap éjfélkorra kap az ember időpontot egy hosszabb release-re, és a release kellős közepén a gép minden értesítés nélkül újraindul. Ha esetleg többen voltunk benn egy release-ben, akkor némi időeltolódással, hol az egyik gépe indul újra, hol a másik, és így tovább.

( Raynes v | 2025. 02. 20., cs – 23:31 )

Én értékelem, hogy próbál normális lenni, egy elég jó fazon ez a Greg, mindig is szimpatikus volt, nagyon jó szíve van, de itt hiába próbál rendes lenni, meg elismerő a Rust-ról, ezt a kialakult szart nem fogja tudni feloldani egy kis békítéssel, meg a Rust erősségeinek az elismerésével. Arra azért jó lehet, hogy az ő véleményére legalább ad Linus, ha már máséra nem is. Annyival mentődhet most a rust-osok helyzete, de ez megint csak egy kis haladék lesz, a következő balhé előtt, ahol már szakadni fog a cérna Torvaldsnál is, és dobni fogja ezt az egész rust-ozást kompletten, ezt előre megmondom, pár hónap múlva visszajövök a topikba, és beírom, hogy igazam lett.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

( bzt | 2025. 02. 20., cs – 23:34 )

Szerkesztve: 2025. 02. 20., cs – 23:35

kroozo, persicsb, snq- látom befutottak a szánalmas TROLLok, akik még csak a témához sem képesek hozzászólni, csak ócsárolni próbálják a másikat.

Kis trolldetektor úgy beriasztott rátok, hogy a fal adja a másikat, LOL!

@gabrielakos, hol vagy ilyenkor? Miért nem szólsz rá a TROLLokra? (Most már lehet érdemes lenne összeszámolni, hány olyan eset fordult elő, amikor az admin a kifejezett kérés ellenére sem tett semmit.)

bzt nem tudja kezelni az indulatait és már többször be lett neki szólva, hogy fogja vissza magát...

aztán mindig ezzel jön, hogy gabrielakos büntesse csak meg azokat a gonosz trollokathuppereket, akik nem méltóztatnak magukat összeszarni tőle :) ...

Én nem ócsárollak, csak röhögök rajtad. Semmi értelme veled beszélgetni, mert azt hiszed, hogy mindenkinél okosabb vagy, cserében benne vagy top 5 azonnal személyeskedő, másokat fikázóban a hupon (és igen jó fej voltam azzal az öttel), szóval tök őszintén, ha fáj, hogy ócsárolni próbálnak, hát suck it up buttercup, neked egy szavad nem lehet.

Ez a gabrielakos dolog meg, szóval vasorrú bába, meg mágnesvihar :D

Az első kommentedben alszakerto faszkalapoztad a linux kernel kb masodik legprominesebb emberét, engem meg konkrétan megneveztél te szerencsétlen, milyen általánosságban?

HAZUDSZ!!!!!!

:⁠-⁠D:⁠-⁠D:⁠-⁠D sírok.

ja és persze egy szóval nem mondtam, hogy ebben a topicban. Szóval TERELSZ!!! CSÚSZTATSZ!!!

( bodobacs | 2025. 02. 21., p – 06:30 )

Szerkesztve: 2025. 02. 21., p – 06:35

Én még mindig nem értem, miért nem lehet a C-hez ilyen ellenőrzést csinálni és a többszálúságra jobban felkészíteni. Szerintem a c++ betegesen felfúvódott.

 

Unsafe c -> a normál. Safe meg a többszálú ellenőrzős.

Nemcsak lehet, hanem van. Ma már nem találsz olyan C fordítót, amiben ne lenne alapból ASAN, UBSAN, stack-check, bound-check stb. opció. Plusz rengeteg tool létezik a lefordított bináris ellenőrzésére (pl. valgrind, fuzzers stb.), amik csont nélkül ellenőrzik a többszálú programokat is.

Egyáltalán nem ördöngős jól megírni egy C programot, egy-két hónap gyakorlás után simán rutinná válik, csak hát ez nincs hypeolva.

valgrind a kernelre?

Nyilván nem, arra fuzzer való. Tudod, ott mindjárt a vessző után a zárójelen belül... "(pl. valgrind, fuzzers stb.)"
Legalábbis ha 3rd party toolokról beszélünk, amit úgy kiragadtál a kontextusából. Elsősorban ugyanis fordító opciókról beszéltem, amik működnek kernellel is.

( bennyh | 2025. 02. 21., p – 09:51 )

Ezt a sok picsogást itt, ha valaki olyat mond, ami nem tetszik nekik. Amúgy olvasni mindenféle hasonló kezdeményezésről, amik pl a C nyelvet reformálnák meg. Ha a Rust sz@r, miért nem lehetne helyette felkarolni valamelyik hasonló kezdeményezést és azt mondani, hogy ez jobb ezért meg azért... + még a neve sem olyan szerencsétlen :D

Ezt a sok picsogást itt

Hát ja, csak úgy dagonyáznak itt a TROLLok, akik semmi érdemlegeset nem tesznek hozzá, csupán csak a másikat próbálják ócsárolni... persze sikertelenül, mert csak magukat járatják le.

Ha a Rust sz@r

Nem erről van szó. Az a baj, hogy a rasztafárik nem hajlandók meghallani semmiféle jogos kritikát, hanem habzó szájjal fröcsögni kezdenek, pont mint az itteni TROLLcsorda. Nyilván ebből így sosem lesz egy jó nyelv / fordító (*), hisz ahhoz elengedhetetlen lenne, hogy odafigyeljenek az építő jellegű kritikákra.

(*) - ez meg is látszik, a Rust specifikáció még mindig nem teljes, olyan alapvető dolgok, mint az ABI sincs fixálva és folyton változik, emiatt törik a visszafelé kompatíbilitiás.