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.

Már megbocsáss, de ez nem professzionális hozzáállás, hanem hiszti.

Nem a Rust-osok jönnek, és főleg nem a kékhajúak miatt történik mindez.
Olyan, mintha egy gödör aljáról szemlélnéd a világot.
Nem akar senki új OS-t csinálni, ez az egész nem a Rust-ról szól. Hanem a Linux kernel jövőjéről.
Vannak olyan igények az ipar oldaláról, amiket a jelenlegi fejlesztési folyamat nem tudott megugrani. Hozzáteszem, ez nem csak a Linux kernelre igaz.
Ezeknek a problémáknak egy részére kapóra jön, amit a Rust ígér. Hogy beválik-e, azt nem lehet előre teljes bizonyossággal megmondani. Ellenben az egyre nyilvánvalóbb, hogy a jelenlegi toolchain és folyamat nem fog ezekre a problémákra megoldást hozni.

El kell tudni fogadni, hogy változnak a dolgok.
A Linux mára egy ipari OS lett. Ha kemény vonalas communityzés kell, szerencsére még mindig ott van a BSD.

Hiszti?

Ebben a sztoriban ki hisztizik?

Olyan, mintha egy gödör aljáról szemlélnéd a világot.

Olyan, mintha magas lóról beszélnél. Ahogy a peronos hasonlatodban, amit tán kétszer is elsütöttél!
De ha már a vonatozásnál tartunk: szerintem a kernel fejlesztőknek teljesen megfelel a szokásos fél nyolcas, menetrend szerinti gyorsvonat. Nem akarnak felszállni a hájpvonatra, ami lehet a következő kanyarban kisiklik.

...a Rust igér...

Nekünk bizonyíték kell! Nem ígéret! Ahogy az oldszpájsz reklámban is megénekelték...

Ha kemény vonalas communityzés kell, szerencsére még mindig ott van a BSD.

Ennek így kicsit másabb a csengése. Az előző említéskor mintha azt sugalltad volna, hogy amelyik fejlesztőnek/karbantartónak nem tetszik a Rust a Linux kernelben, az mehet a BSD-hez. Hogy is van ez? A vendég kidobja a házigazdát? Vagy mit akart kifejezni?

Onnantól, hogy beszáll a tőke, az elvek helyett az igények kerülnek előtérbe.

Igények vannak ott is, ahol tőke nincs. Nem az igényekkel van baj, hanem azzal, hogy a tőke bejövetele olyan arrogáns, invazív elemek megjelenésével jár, mint Lenart Pöttering és olyan szélsőséges idealizmusaik erőltetésével, mint a systemd vagy a pulseaudio.

Aztán nézni, mire megy a community lóvé nélkül az elveivel, 30 év alatt.

Linux-szal összemérhető mértékben használható, áttekinthető, rendezett, konzisztens rendszer. Erre megy mondjuk egy FreeBSD.

A tőke korlátlan beengedése az ilyen projektekbe pedig rohadtul nem egészséges azokra nézve, mert előbb-utóbb felfalja őket. Ahogy a Red Hat tette a desktop Linux-szal. Ez igazából az a kihívás, amit a GNU nem volt képes orvosolni a licenszeivel. Felszabadította a fél világot a proprietary szoftverek egyeduralma alól, de nem számolt azzal, hogy a tőkeerős multik immáron nem a kódot fogják önzőn, mohón szorongatni, hanem kisgömbőcként falják fel a nyílt forráskódú projekteket.

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

Ezt inkább pszichológiai, politikai fogásnak szánta, mivel ő a második legnagyobb vezető a kernelben, azt hitte, hogy ha a rust-osok mellé áll, akkor sikerül lenyugtatnia a kedélyeket, és látják rajta, hogy nem minden fő C-s fejlesztő gecizik. Tény, hogy ha nem ért hozzá, akkor nem kellett volna szakmai részletekbe mennie vele, elég lett volna csak annyit mondania, hogy nincs ellene a Rust-nak, és ő a részéről mindent megtesz, hogy együtt tudjanak dolgozni a rust-osokkal.

Egyébként a Rust-nak én se lennék ellene, én a hájpnak vagyok nagy ellenzője. Sajnos több évtizede nyomom már a PC, meg hobbi programozós mókát, tanultam már mindenfélét, a legtöbb cucc, ahogy lement körülötte a hájp, szépen elavult tudás lett, ment pocsékba, felesleges erőlködésnek bizonyult. Ezért én 10× is meggondolnám, hogy Rust-ot tanuljak-e. Anno a Java-ról, PHP-ről, Ruby-ról, Go-ról, meg mindenféléről úgy gondolták, hogy a világot megváltja, aztán csak nem úgy lett. Közben meg C, unixos dolgok, vi/vim, stb. örök maradt, átálltam inkább az ilyenekre az évek folyamán, nincs nekem erőm, hogy mindenki hülye hájpjának szaladgáljak utána.

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

Egyébként a Rust-nak én se lennék ellene, én a hájpnak vagyok nagy ellenzője.

Egy dolgon gondolkodj el: Kellene neki ekkora hype, ha tényleg annyival jobb lenne a C-nél, mint amennyire hype-olják? Onnan lehet megismerni a legjobban a kamuinnovációt és a szemfényvesztést, hogy túltolják a hype vonalat és majdhogynem már vallást csinálnak belőle. Mindezzel azt kompenzálják, hogy a Rust távolról sem tud minden szempontból jobb lenni a C-nél. Így manipulációval, a tudatok megerőszakolásával akarják elterjleszteni, mert ezzel néhány milliárdos multi valamennyit spórol™.

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.

> tele van a kernel forrása olyan dolgokkal, ami nem része a szabványnak.

Mondjuk, feltételezve, hogy csak indokolt esetben használnak nem-szabvány C feature-ket, a kód nagyobbik felére igaz lehet ettől még, hogy építenek a standard C feature-kre. Én nem érzem itt az ellentmondást,

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

A Red Hat is 16 éve motivált a Wayland-ra, mégse sikerült minden szempontból jobbat csinálnia belőle, mint az X11, de mivel ezt a presztízsveszteségtől tartva nem hajlandó elismerni, így erővel, korporatokrata felhatalmazással fogja lenyomni a Linux-világ torkán a szutykát. Pont úgy, ahogy a multik fogják a Rust-idealizmust a kernelen. Semmi gond, ha lesz egy szarul-húgyul implementált, bloated fos instabil kernelünk, de legalább ráragaszthatjuk a biztonságos™ címkét, hiszen nincs benne memóriakezelésből adódó exploit. 🤡

Lehet, hogy meglepo, de ezek profit-orientalt cegek, amik *merik* a projektek sikeresseget, es nem fixa ideak alapjan dontenek. A zaro keynote-ot Mark Russinovich (CTO, MS Azure) tartotta. A legtobb projektnel, amit migraltak, 10-15% koruli teljesitmenyjavulast is mertek, nem mindenhol, de teljesitmenyromlast viszont sehol sem.

Ezeket emelnem ki:

 - Alice Ryhl: Rust project goals 2024: Stabilizing Rust in the Linux Kernel
 - Mark Russinovich: Microsoft is Getting Rusty: A Review of Successes and Challenges
 - Victor Ciura: ABI Resilience

Utobbit inkabb azert mert erdekes figura, a C++ kozossegbol jott, rendszeres eloado a CppCon-on is, most meg a Rust csapatban van (MS). 

A parhuzamos programozasosat en is ujra akarom nezni, mert tul kis terembe raktak, es az ajtobol nem sok mindent lehetett erteni...
 - Evgenii Seliverstov: Parallel Programming in Rust: Techniques for Blazing Speed

*merik* a projektek sikeresseget, es nem fixa ideak alapjan dontenek

Ott elég nagy probléma lehet a metrikákkal, ahol egy 10 év alatt stabilitást elérni nem képes komponenst életben hagytak. Olyat, ami az elődjének a szintjét, stabilitását, kompatíbilitását még 16 év után sem képes hozni. Vagy, a másik lehetőség, hogy csakazértis alapon, ők akarják leuralni a desktop Linuxot és újból felforgatni, hogy semmi ne maradjon a nem Red Hat által összetapicskolt technológiákból.

Persze, ugye soha nem láttunk még olyat se, hogy egy piacvezető milliárdos multi szórja a pénzt egy senki által nem kért, "legyen nekünk is sajátunk" idealizmusra. 🤡 Nem láttuk pl. a Google-t sem a Facebook-ot Google+ néven sikermajmolni, aztán bedőlni vele. 🤡 Nem láttuk az iWiW-et a Telekom irányítása alatt sem a Facebook-ot elkezdeni majmolni, majd bedőlni vele. 🤡

A legtobb projektnel, amit migraltak, 10-15% koruli teljesitmenyjavulast is mertek, nem mindenhol, de teljesitmenyromlast viszont sehol sem.

Vajon majd jövőre és az után is fennáll majd ez a százalék? Vagy utána már bloatabb lesz, csak már senkit nem fog érdekelni, mert mindenkit áterőltettek és nem lesz visszaút, inkább vesznek új gépet? A kérdés költői. Mindannyian tudjuk a választ.

ők akarják leuralni a desktop Linuxot

Bocs, nem nagyon tudom kovetni a csapongo gondolatmenetedet, ki beszelt desktop Linuxrol? Linux kerneltol indult a szal, es az Azure-os CTO sem arrol beszelt amugy, hogy a Windowsban mindent lecserelnenek. Apro proof-of-concept project-ekkel indult, az egyik a HyperLight:
https://opensource.microsoft.com/blog/2024/11/07/introducing-hyperlight…

Aztan kis csapatok nehany honapos munkaval kisebb library-kat atmigraltak, amik biztonsagi szempontbol kritikusak, viszont nincs fuggoseguk (vagy minimalis), es nyilvan megneztek, hogy nem romlott-e a teljesitmeny, allitolag nem. UEFI, crypto, felsorolt egy rakas projektet.

Szoval az egyik fajta statisztika, amiket mutogatott az az volt, hogy a sebezhetosegek hany szazaleka vezetheto vissza olyan hibakra, amiket a Rust mar forditaskor kiszur, es hat a helyzet az, hogy az arany eleg magas, es evtizedeken keresztul szinte allando.

A masik fajta statisztika meg az volt, a C/C++ vs. Rust implementaciokat hasonlitottak ossze, sebesseg, memoriaigeny stb.

Szoval ezek utan jutottak el oda, hogy uj projekt mar csak Rustban indulhat, es nem C/C++-ban (ahol garbage collection kizart).

Nyilvan egy CTO fenyezni fogja a sajat eredmenyeiket, de nem tennenek bele a Rust Foundation-be evi 1m dollart, ha ez nem fizetodne ki nekik.

Bocs, nem nagyon tudom kovetni a csapongo gondolatmenetedet

Szerintem csak akkor van így, amikor nem értesz egyet.

ki beszelt desktop Linuxrol?

Én beszéltem. Reagáltál is rá. Tehát felvetted a fonalat és még példálóztál is.

Szoval az egyik fajta statisztika, amiket mutogatott az az volt, hogy a sebezhetosegek hany szazaleka vezetheto vissza olyan hibakra, amiket a Rust mar forditaskor kiszur, es hat a helyzet az, hogy az arany eleg magas, es evtizedeken keresztul szinte allando.

Meg amit eddig is kiszúrtak más analyzerek is C kódból, csak azt elfelejtették megmérni, gondolom véletlenül™. Nem mellesleg azt is elfelejtették megmérni, hogy az átírkálással hány új bugot, sebezhetőséget stb. gyártottak.

Önmagában a Rust fejlesztési metodikája nagyobb kockázat, mint a memory corruption bugok lehetősége. Hogy a legegyszerűbb feladat elvégzésére is ott a netről húzigált library és erre van az egész ökoszisztéma berendezkedve. Csak ezt illik elfelejteni és mélyen kussolni róla, hiszen most egy trendet kell elterjeszteni, mivel mással, mint a divatdiktatúra eszközeivel.

Nyilvan egy CTO fenyezni fogja a sajat eredmenyeiket

Még csak fényezni sem kell, ha amit nem akarsz látni, azt egyszerűen nem méred meg.

Szerintem csak akkor van így, amikor nem értesz egyet.

Koszonom, hogy megosztottad a gondolatodat arrol, hogy szerinted en mit gondolok akkor, amikor azt irom, hogy nem tudom, kovetni, mit gondolsz. Eleg meta. Pedig nem. Csak szimplan nem tudom kovetni.

Én beszéltem. Reagáltál is rá. Tehát felvetted a fonalat és még példálóztál is.

Nem. Abban a kommentben azt irtad, hogy a Waylandet akarja a RedHat beletolni a Linuxba. Ez valoban desktop linux, bar nem latom, hogy fugg ossze a Rusttal.

Innen jutottal el oda (ha jol ertelmeztem), hogy mar a Rust jelenlete a kernelben is tonkreteszi a desktop (!) linuxot, sot, az is a cel.

netrol huzigal library

Asszem mar tisztaztuk, hogy kernelfa es stdlib van, nincs cargo.

Nem trendet akarnak kovetni, hanem pont forditva. Van egy technologia (programnyelv, nevezd ahogy akarod), amivel penzt tudnak sporolni, es beallnak moge, gyakorlatilag fenntartani a trendet. Erdekuk, hogy ne doljon be.

Még csak fényezni sem kell, ha amit nem akarsz látni, azt egyszerűen nem méred meg.

Biztos lehetsz benne, hogy megmerik, nem hulyek, es nem erzelmi alapon dontenek. Legfeljebb nem mutatjak meg, ami nekik nem kedves.

Ez valoban desktop linux, bar nem latom, hogy fugg ossze a Rusttal.

Az erőltetés módjában függ össze. Mind a Wayland, mind a Rust egy premature tákolmány összehasonlítva a már 30 éve létező, bevált megoldásokkal. Mindkettő erőltetésének a jelenlegi ökoszisztéma konzisztenciája, stabilitása, időtállósága látja kárát. A probléma nem a Rust-tal van, hanem azzal, hogy olyan területekre akarják relatíve rövid idő alatt beerőltetni, ahová jelenleg nem való és ezzel felforgatnak egy évtizedek óta koherens ökoszisztémát.

Innen jutottal el oda (ha jol ertelmeztem), hogy mar a Rust jelenlete a kernelben is tonkreteszi a desktop (!) linuxot, sot, az is a cel.

A Rustafárik és a mögé állt arrogáns tech-multikák úgy teszik tönkre a kernelt, ahogy a Red Hat tönkretette a desktop Linuxot.

Asszem mar tisztaztuk, hogy kernelfa es stdlib van, nincs cargo.

Még nincs.

Van egy technologia (programnyelv, nevezd ahogy akarod), amivel penzt tudnak sporolni, es beallnak moge, gyakorlatilag fenntartani a trendet. Erdekuk, hogy ne doljon be.

Amit ezek a multik megspórolnak, mások ezerszeres árat fizetnek érte, még ha ez elsődlegesen nem is pénzösszegekben realizálódik. Pont úgy, ahogy ez lenni szokott. Tipikus eset: húzzunk be még egy bloated framework-öt, mert olcsóbb lesz tőle a fejlesztés, cserébe százmillióknál jön elő a bloated framework CPU- és memória overheadje. Ezek egyoldalú "kompromisszumok".

Biztos lehetsz benne, hogy megmerik, nem hulyek, es nem erzelmi alapon dontenek. Legfeljebb nem mutatjak meg, ami nekik nem kedves.

Végeredményben ugyanaz: részrehajló mérések, egyoldalú marketing bullshit.

Linux kapcsán az "évtizedek óta koherens ökoszisztáma" egy mítosz. Akármelyik alrendszert nézed, a változás volt állandó egyedül.

Audio alrendszer: OSS, ALSA, PulseAudio, Pipewire

Eszközkezelés : devfsd, hotplug, HAL, udev

Video alrendszer: X11R6.4, Xfree86, Xorg, Mir, Wayland

Init rendszer: sysvinit, openrc, systemd, initng, runit, upstart

Tűzfal-frontend Netfilterhez: ipchains, iptables, nftables meg ezerféle CLI eszköz (firewalld, ufw stb.)

Fordító: gcc (eredeti), egcs, gcc (egcs merge után), clang

CLI Shell: na ebből aztán van sok

Grafikus shell: ebből meg még több

Csomagkezelők: deb, rpm, apk és az újhullámos Flatpak, Appimage, Snap

 

Az olyan apróságokat, mint a Python2/Python3, Perl5/Perl6 (Raku) támogatás, meg hasonlók, azt hagyjuk is.
Nem véletlenül létezik a Filesystem Hierarchy Standard sem, meg a Linux Standards Base (amiknek a fejlesztése 10 éve megállt, és abandoned projekt már), egész egyszerűen nincs semmilyen koherens koncepció az egyes disztribúció- és alkalmazásfejlesztők számára, hogy mit hogyan illik csinálni egy Linux rendszerben.

Ami meg crossplatform, és támogat BSD-t is, meg Macet is, ott meg aztán alapvető, hogy az alkalmazásnak saját konvenciója van arra, hogy milyen formátumban, hol tárolja a konfigot meg egyéb fájljait.

Például amúgy jó kérdés, hogy egy 3rd party bináris (mondjuk példaként az Apache Mavent), az hova települjön? A /opt/apache/maven alatt legyenek a fájljai? Legyen-e symlink a /usr/bin-ben a /opt/apache/maven/bin/mvn-re vagy ne? Nem egyszerű kérdések ezek, és ahány ház, annyi szokás.

Ugyebár a GNU projekt lett volna az a projekt, ami szállít egy teljes értékű nyílt forrású operációs rendszert, ők 40 év alatt kernelt sem voltak képesek csinálni, illetve rengeteg dolgot képtelenek voltak szállítani, emiatt kell nagyon sok 3rd party dologhoz nyúlni, mert nincs más. Nincs komplett nyílt operációs rendszer a GNU/Linux szoftvereknél, ami koherensen lenne fejlesztve. Ez nem BSD.

Az ezerféle Linux-disztribúció meg szabadon választhat, hogy a sok-sok opensource projektből mit válogat be, mely komponensekből csinál rendszert magának. Ami állandó, az a változás, meg az inkoherens működés - projektek jönnek-mennek, kiszállnak a fejlesztők, megunják a hobbijukat stb. Hosszú távon ez nem tartható, és rengeteg erőforrást emészt fel.

Open-source komponensekből csak akkor lehet stabil dolgot csinálni, ha emögött vállalatok vannak, akik akkor is finanszírozzák a fejlesztést, karbantartást, ha amúgy a projekt maintainer megunta a dolgot. Állandság kell a projektek mögé, villamoskompatibilitás, mert máskülönben nem működik igazán hosszú távon a dolog, a nagy disztribúciók fejlesztői ezt megtanulták (meg megunták állandóan lecserélni az X dolgot Y-ra, mert az nem támogatott lett, és van helyette új shiny félkész projekt). Inkább csinálnak egy teljes oprendszert, amit ők támogatnak, nem véletlenül létezik a systemd például a Red Hat által támogatva.

Linux kapcsán az "évtizedek óta koherens ökoszisztáma" egy mítosz. Akármelyik alrendszert nézed, a változás volt állandó egyedül.

Desktop Linuxról volt szó, ami egy elég jól körülhatárolható valami. Kernelről volt szó, ami szintén egy elég jól körülhatárolható valami. Ha a Red Hat invazív szutykait kiszeded a listából, fele annyi elem lesz rajta. Ha a többi multi szutykát is kiveszed, fele annyi se. Az X11R6.4, Xfree86, Xorg vehető egy kalap alá, mert az Xfree86 alá írt program köszöni szépen, 100% kompatíbilis az Xorg-gal. Nem igaz ez a szarul-húgyul implementált XWayland-os megoldásokra.

Azt se felejtsd el, hogy míg az ALSA lecserélte az OSS-t, addig a PipeWire, Pulseaudio már ráépülnek az ALSÁ-ra, ráadásul a PipeWire PulseAudio interface-t is megvalósít. Pont ugyanígy igaz ez a senki által nem kért firewalld-re.

GCC-vel mit nem tudsz lefordítani az egcs merge után?

CLI Shell: na ebből aztán van sok

Van olyan, amire a fél világ dependál és ez kizárja az alternatívákat? Nincs. A bash-re a fél világ dependál, de ettől még használhatsz bármilyen shell-t. Xorg-ot fogsz tudni használni, miután a Red Hat beerőltette a Wayland-szutykát, és az egész desktop Linuxot rádependáltatta? Nem fogsz.

Az olyan apróságokat, mint a Python2/Python3, Perl5/Perl6 (Raku) támogatás, meg hasonlók, azt hagyjuk is.

Nem kell hagyni, a Python2->Python3 átállás hasonló erőltetett menet volt. A mai napig létező és akár production-ben is futó Python2 kódok jól mutatják, hogy igény egyértelműen a Python2 további támogatására volt, nem annak deprekálására. 2020. január 1-jén deprekálták. A 2 évvel később kiadott (2027-ig támogatott) Ubuntu Jammy pedig szállította a python2 csomagot default repoban.

Az ezerféle Linux-disztribúció meg szabadon választhat, hogy a sok-sok opensource projektből mit válogat be

Már amíg a dependencialáncok ezt lehetővé teszik. Az a fajta beerőltetés, felforgatás stb. amit a multik csinálnak a Linux-szal (élen a Red Hat-tal) éppen ezt a szabadságot veszi el.

Open-source komponensekből csak akkor lehet stabil dolgot csinálni, ha emögött vállalatok vannak

Ez a legorbitálisabb tévedés, amit open-source vonalon elkövethetsz.

akik akkor is finanszírozzák a fejlesztést, karbantartást, ha amúgy a projekt maintainer megunta a dolgot

Ez azt feltételezi, hogy mindenre csak egy maintainer van, ami egy kellően nagy open-source közösség esetén nem igaz.

Állandság kell a projektek mögé, villamoskompatibilitás, mert máskülönben nem működik igazán hosszú távon a dolog

Ezt majd magyarázd el kérlek a Wayland-ot erőltetőknek. :) Nem, az XWayland továbbra sem ad teljes kompatíbilitást és egy instabil bloat szutyok.

Inkább csinálnak egy teljes oprendszert, amit ők támogatnak, nem véletlenül létezik a systemd például a Red Hat által támogatva.

Csináljanak, csak ne forgassák fel vele a Linux-világot. Látsz YaST-ot bármelyik disztróban? Látsz rádependáló desktop környezeteket? Nem. Mert a SuSE tudott úgy, már a Red Hat előtt is működni, hogy ne forgassa fel a Linux-világot. Nem azzal van baj, hogy enterprise minőségű Linuxot nagyvállalatok csinálnak. Azzal van, hogy mindent, ami oda bemegy, beerőltetnek máshova is. Ez hosszú távon a Linux teljes felforgatásához vezet. Csináljanak saját, Linux-alapú oprendszert, legyen benne systemd, pulseaudio, pipewire, meg amit akarnak, csak ne erőltessék rá a Linux-világra invazív módon, dependenciákon keresztül.

Azzal van, hogy mindent, ami oda bemegy, beerőltetnek máshova is. Ez hosszú távon a Linux teljes felforgatásához vezet.

Senki nincs kötelezve, hogy ezeket a cuccokat használja. Bármelyik disztró szállítója dönthet úgy, hogy kihagyja a dolgokat. Ahogyan kihagyták a Yastot, a zyppert, az ezerféle más projektet, úgy lehet kihagyni a Red Hat többi projektjét is, senkit nem köteleznek, hogy használja. A közösség eddig is bármit és bármikor forkolt, ha úgy látták jónak.

Nem kell használni pipewire-t, nem kell használni systemd-t, nem kell használni semmilyen Red Hatos dolgot, senki nem kötelez erre.

Senki nincs kötelezve, hogy ezeket a cuccokat használja.

Még nincs.

Bármelyik disztró szállítója dönthet úgy, hogy kihagyja a dolgokat.

Egészen addig, amíg nem kell emiatt saját kernel-kódbázist karbantartania.

Ahogyan kihagyták a Yastot, a zyppert, az ezerféle más projektet

Az ne zavarja Persics Mérnök Urat, hogy ezek kihagyható projektek, mert nem dependál rájuk a fél világ. 🤡 Tehát amíg egy nem invazív YaST kihagyása triviális bármelyik disztróból, addig pl. az invazív Red Hat szutykok (systemd, pulseaudio, pipewire), vagy egy Rust-idealizmussal megerőszakolt kernel nem lesz az.

Nem kell használni pipewire-t, nem kell használni systemd-t, nem kell használni semmilyen Red Hatos dolgot, senki nem kötelez erre.

Az a projekt kötelez erre, ami nem ad más választási lehetőséget, mert nem hajlandó natívan ALSÁ-val vagy systemd nélkül működni. Pedig adott projektet se kötelezte senki a systemd adoptálására. Próbáld meg felismerni az invazív projekteket, hogy mitől invazívak. Ha sikerül felismerned, akkor meg fogod érteni, hogy a systemd (sajnos) miért nem YaST, és hogy a SuSE miért jóval kevésbé arrogánsabb multi, mint a Red Hat.

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!

szerk.: kellett nekem emlegetni. Ma oktatást/prezentációt tartottam. Egy órával előtte bekapcsoltam a gépem, elmentem reggelizni/kávézni (nem, még nem munkaidő). Visszaérve a gép elé: a windows frissít éppen. Én meg éppen oktatást tartanék... Egy jó 20 percet kellett várni rá!

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.

Ez az ún. fileless-malware-ek miatt lett bevezetve, amik nem perzisztáják magukat, hanem végig teljesen memóriában maradnak.

Gondolom egyszer bekerült valamelyik compliance-követelményrendszerbe és onnantól ez egy kötelezően implementálandó endpoint security szabály lett mindenhol. Ha nem csinálod, elbukod az auditot. Nálunk is a Macbook-ok lazán elmentek hetekig lecsukom-suspend, felnyitom-resume módon, de most már jön a dörgedelem, hogy nem volt x ideje restartolva, max 1-2 órával tudom elhalasztani (ráadásul olyan fos módon implementálták le a yamf-ban, hogy az szerver oldalon tárolja az uptime-ot - hol máshol - és teljesen rendszeres, hogy "nem veszi észre", hogy a gép restartolva volt és újra és újra cseszeget vele. Ilyenkor jönnek a sudo yamf recon meg kétszer restartolom restartolom meg hasonló manuális workaroundok)

Mostanában a céges telefonokra is kezdik teríteni a kötelező restart policy-t.

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

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.

Az az egy nem aggaszt, hogy nem terjed el, annyira agresszíven nyomják, az folyik a csapból is, hogy lehetetlen, hogy ne legyen végül mindenkire rátolva. Az AI után most a legmenőbb buzzword, mindent írnak újra Rust-ban.

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