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.

É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.

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.

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.

( 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!

( 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

( 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.

( 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