A Linux 7.0 hivatalosan lezárja a Rust-kísérletet

Kernel

Úgy fest, hogy a Linux kernel fejlesztői eljutottak a "kell-e a Rust a Linux kernelhez" kísérlet végére és a kísérlet a következőképpen zárult:

experiment is done, i.e. Rust is here to stay.

Vagyis "a kísérlet lezárult, a Rust marad itt". Ugyan ezt már decemberben kimondták, de most került a változtatás pull request-ként Linushoz beolvasztásra a (várhatóan) 7.0-s kernelhez:

Documentation:

 - Conclude the Rust experiment.

Részletek itt.

( goodbyte v | 2026. 02. 09., h – 13:58 )

Majd forkolják...

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

( locsemege v | 2026. 02. 10., k – 00:30 )

Biztonságos és lassú. Remek. :(

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( Raynes v | 2026. 02. 10., k – 06:58 )

Fak, én először úgy olvastam, hogy vége a Rustnak a kernelben, már kezdtem örülni. Aztán olvasom, hogy marad.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Valóban figyelemre méltó jelenség, hogy gyakran olyanok aggodalmaskodnak ezen, akik életükben egy büdös sor kernelkódot nem láttak (most nem Raynes-re gondolok, hanem általában).
Meg akik utoljára az egyetemen láttak C kódot, amikor beadták a progterv nagyházit. De azért fúúj Rust. Az egy cseppet sem zavarja őket, ha egy kihalásra ítélt állatfajra bíznánk a kernel jövőjét.

Hát gecc már bő 15 éve úgy éreztem C programozóként, hogy ennek abban a formában, ahogy én szerettem, vége lesz.
Nézd meg a fiatal generációt, hányan akarnak C programozók lenni. Lehetőségük sincs, mert alig van projekt és környezet, ahol tapasztalatot szerezhetne. A C-hez pedig az nagyon kell.

Meg lehet nézni továbbá a C-only projekteket, amiknek vannak nem C-only alternatívái. Melyik hogy fejlődik. Bloat a python-ban fejlesztett a C-hez képst? Igen. Érdekli ez a júzert? Nem. A júzert az érdekli, hogy bele van integrálva minden state-of-the-art feature. Pythonban sokan programoznak, C-ben meg kevesen. Látszik a különbség.

ez a C vs python erdekes kerdes. en mindkettot ismerem, 20-25 ev tapasztalattal (py-t v2.3 ota) hasznalom sokat. de egyre kevesbe nyulok c-hez ha valami uj dolgot kell csinalni, mert ugyan a py lassabb (pypy-vel amugy alig), de sokkal gyorsabban es hatekonyabban lehet vele dolgozni, tobb jobb lib erheto el hozza. egyszeruen nagyon keves olyan problema van, ahol megeri a c-t hasznalni.

egyszer sok eve olvastam, hogy a cegek azert nem fejlesztenek optimalizalt, hatekony kodokat, mert a jo programozo sokkal dragabb, mint a hardver. raadasul sokkal tovabb is tartana a fejlesztes. inkabb vesznek erosebb gepet hozza...

Így van. Bár vannak a python-nak hülyeségei, szinte minden van hozzá, kész dolgokkal indulsz el. Míg C-ben úgy indul egy adatfeldolgozás/jelfeldolgozás, hogy megírom a primitíveket hozzá. Pythonban ezt mind le lehet szarni. Persze néha beszopod, de hamar rátalálsz, mi a bevált gyakorlat olyan esetben.

Nem kell hozzá szakadni. Egyszerűen ez a Rust most csak egy hülye divat, általában komolytalanabb fejlesztők keresik vele az 5 perces hírnevet, világmegváltást, kerék újra feltalálását. Semmi szükség nem volt rá a kernelben, teljesen jó volt évtizedekig a Unixok, Linux, BSD-k kernelében a C, megvoltak rá az automatizált eszközök, tesztek, hogy bugokat, sérülékenységeket megfogjanak.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Jah, csak amikor a kernelt elkezdték írni, akkor a C volt a de facto standard programnyelv, most meg 10 leendő szoftverfejlesztőből 0 akar C-t tanulni.

Úgyhogy el lehet dönteni, hogy a kernel majd megáll-e egy adott verziónál, aztán ennyi, mert nem lesz hozzá humánerőforrás, vagy engednek egy népszerűbb nyelvet, vagy majd vibe code-olják C-ben, aztán lesz, ami lesz.

Szerintem ez előítélet. Másrészt a Rust nem gondolom, hogy divat lenne. Épp ebből gyúrja most az új low level nyelvet az iparág.
Mi máson nőttünk fel, számomra is kedvesebb a C és a hozzá kapcsolódó filozófia. Magam is C programozó voltam. Azt a világot nagyon szerettem. De elmúlt. És ezt itt sokan nem tudják elfogadni, és jönnek mindenféle érzelmi kitörésekkel.

A Rust legalább annyira túlkomplikált, mint a C++. Ebből a szempontból a Zig inkább helyettesíthetné a C-t. Ha nem járna mindkettő gyermekcipőben.

Zig mellett szóljon, annak a támogatói/kedvelői nem akarnak elvakultan mindent is újraírni Zig-ben.

Make it as simple as possible, but not simpler. - A. Einstein

Semmiféle hiszti nincs. Ha valaki hisztizik, azok pont a Rust hívők. A hozzászólásaid hangvételéből nekem úgy cseng, te is azt a tábort erősíted.

Én nem félek semmitől! Mikorra várhatjuk, hogy kiderüljön? Mert ígérettel tele a padlás, de profitot nem nagyon látok egyelőre.

Itt említettétek páran, hogy jönnek a dinoszauruszok és seggbeharapják a kivenhedt C programozókat! És velük együtt kihalnak.

Ha egy ilyen nyelvvel akarják az utánpótlást biztosítani... Ez inkább arra jó, hogy elriasszák az ember fiát a programozástól. Kód olvashatóság, szintaxis szempontból semmiképpen nem nevezném szerencsésnek. Túlkomplikált az egész. Maga a nyelv, a nyelvi elemek, crate, toolchain.

Félre értés ne essék! Nem utálom a nyelvet! Az egresszív felhajtás ami körülötte van, az viszont ellenszenves. Arra, amire szánták, és amit sokan látnak benne, arra véleményem szerint alkalmatlan!

Make it as simple as possible, but not simpler. - A. Einstein

A hozzászólásaid hangvételéből nekem úgy cseng, te is azt a tábort erősíted.

Már többször elmondtam itt, hogy a C-s tábort erősítem.
Viszont boomer hiszti helyett megérteni próbálom az okokat, és előre tekinteni.
Jöttök mindig a nosztalgikus képzelgésekkel, csak hát azok meg lehet nézni, hova vezettek az elmúlt évtizedekben.

ellenszenves

Az iparág pont leszarja a lelki békédet. (Egyébként az a boomer nyüszítés, amit egyesek nosztalgiából művelnek, ugyanolyan ellenszenves.)

arra véleményem szerint alkalmatlan!

Nem az a kérdés, hogy alkalmas-e. Hanem hogy alkalmassá tehető-e. Szerintem ezt készítik most elő.

Egy darabig elmegy a közösség balfaszkodása, de az ipar türelme nem végtelen. (A Linux fejlesztési irányát pedig az ipar jelöli ki, nem a nosztalgiázni vágyó boomerek.) Így lett a systemd és a Wayland. Aztán lehet utólag károgni. Előtte kellett volna kihúzni a fejet a seggből.
A félreértés elkerülése végett: részemről ez nem vágy, hanem diagnózis. A systemd jobban fáj, mint kb. bármi a Linux háza táján. És Wayland rajongó sem vagyok.

Boomer hiszti, boomer nyuszítés, nosztalgikus képzelgés?! Pontosan a haladó és trendi Rust evangélisták beszélnek így! 🤣

Nem tudom a lelki békémnek mi köze van ehhez? Leírtam a véleményem a Rust jelenségről!

Valami csodaszernek tartják, hogy majd jól meggyógyítja a szoftver világban burjánzó rákot! De csak tápszer neki.

A Linux kernelbe nem Rust kell, hanem olyan programozók, aki tényleg megtanultak és tudnak is programozni! Nem ilyen AI-n nevelkedett prompt huszárok. Akiket aztán Linus rendre elhajt a fenébe... 🤣

A Rust egy nagyon jó eszköz arra, hogy hamis biztonságérzetben még több trágya kód és szoftver szülessen, az AI papin felnevelt 'kóderektől'/kóklerektől!

Még mielőtt! Minden nyelven lehet szar és jó kódot is írni! Mivel jelenleg nincs igény a jó kódra ezért tartunk itt! Ezen semmilyen csodaszer nem segít!

Hogy egy klasszikust idézzek:

"Térfogat növelő szer?! Hát noooormális?!"

Felfújt, tápértékben szegény, cukormázzal édesítőszerrel (már nem lehet cukrozni sem, az méreg!) leöntött foshalom!

Make it as simple as possible, but not simpler. - A. Einstein

Azok a 40+ -os tapasztalt kóderek 10 év múlva 50+ -osak lesznek, és nem biztos, hogy életük célja 100+ éves korukig ezt csinálni... Az, hogy vannak még kritikus helyeken is Fortran kódok, amik kifejezetten sok pénz mozgatásáért is felelnek akár, nem az a jó irány, hogy tartsuk meg ezeket az idők végezetéig (+1 nap). Mert ott már explicit kijött nem egy és nem két esetben, hogy hozzányúlni az bizony a feneketlen pénznyelő kút és ama bizonyos erdő és abban történő tátott szájjal való cikázás, miközben a sz0pórollert már rég csapágyasra hajtotta minden érintett... 

Lehet, hogy majd a ZS generáció feltalálja, hogy konténerizálja az erdőt is, a rollert is. És majd a dockerben az lesz, hogy rollerrel száguldoznak az erdőben.
Az milyen nagy mutatvány lesz. Kettő az egyben. Mindig az volt a menedzserek vesszőparipálya,

Még nincs aláírásom.

Anno volt a Clipper, ami egybecsomagolta a futtatókörnyezetet a programmal... Aztán volt olyan, hogy statikusan fordított bináris - az is az egybecsomagolásról szólt... A docker konténer... Oh, wait... 

Mondjuk OS/platform üzemeltetőként nekem jó,ha konténerben kapom a "szemetet", mert onnantól az abban lévő komponensekért a felelősség nem nálam, hanem a konténer szállítójánál van... 

Oh a Clipper! Volt amikor Amiga-n fejlesztettem emulátorral. Minden egyes fordítás után meghalt a rendszer. Szerencsére a gép gyorsan indult.
MInden esetre a helyes munkamódszer az volt, hogy egyszerre ne csak egy hibát javítsak és azután teszteljem.

Még nincs aláírásom.

( arpi_esp v | 2026. 02. 10., k – 08:41 )

szerintem a systemd-t is be kene olvasztani a kernelbe, persze csak miutan ujrairtak rustban

Nekem sem kedvencem, de szégyennek nem mondanám. Vannak azért jó oldalai a systemd-nek:
1) nagyon gyors inittéren, nagyon meggyorsítja a bootolást, az OpenRC megközelíti, de nem éri utol
2) a logokat tömöríti, ezáltal kisebb az esélye, hogy elegyék a helyet, bár ez megoldható lenne egy olyan fájlrendszerre logolással is, ami transzparensen röptömörít
3) a .service fájlok INI/TOML szintaxisa is elég könnyen kezelhető, érthető, olvasható
4) a systemd boot egy nagyszerű bootmanager, sőt, használható systemd nélkül is, minimalista, a titka, hogy azt nem Pöcstering írta, ezt csak felvették utólag a systemd-sek, mert elhagyatott német projekt volt (gummi boot néven), hogy karbantartják.

Ami baja van:
a) nem csak egy initrendszer, hanem mindenes akar lenni (rendszeresemények kezelése, hálózat/DNS kezelés, felhasználók kezelése), emiatt túl vagy bonyolítva
b) rá van tolva mindenkire, függőségek mentén.

Pöcsteringet se szeretem, ahogy szoktam írni, szemem ráng tőle, de pl. a mostani Rust, AI vibecoding huszárok sokkal rosszabbak nála.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Remélhetőleg ritkán, bár amikor egy hat node-ból álló Checkpoint clustert kell upgrade-elni, akkor egymás után sokszor :) (szerencsére számomra már múlt idő) Arra szerettem volna utalni - és erre a kérdéseddel épp ráerősítettél - hogy ilyen környezetben a legkevésbé az számít, hogy a kernel és az init rendszer mennyi idő alatt indul el.

Tele kernelhibával természetesen :D

A Linux sem csodaszer, az egy kernel (na jó, vegyük mellé a libc-t), afelett jönnek persze az alkalmazások, amelyek olyanok, amilyenek. És persze ha megvettél valami holmit, amin linux kernel fut, de a rátelepített holmi már a gyártó alkalmazása, a supportot és a használat módját természetesen ő szabja meg, akkor te nem restartolsz egy-két service-t, hanem a leírás szerint fogsz upgrade-elni, hogy a support egyáltalán szóbaálljon veled.

Igen, a jól ismert reply ... de meg lehet onnan is közelíteni, hogy az már bizonyította, hogy kepes évekig működni anélkül, hogy összeszarja magát. A tegnap kiadott, naprakész rendszernél sem garancia, hogy nem éppen most lapátolták bele vissza azt az RCE-t, amit már az elmúlt évtizedekben többször is "javítottak" (igaz történet alapján ...)

trey @ gépház

A tegnap kiadott, naprakész rendszernél sem garancia, hogy nem éppen most lapátolták bele vissza azt az RCE-t, amit már az elmúlt évtizedekben többször is "javítottak"

Anno a víruskergetők fénykorában volt az a kérdés, hogy az új verzió hány új vírust ismer fel, és hányat hoz magával :-) 
A "ha működik, ne piszkáld" jó hozzáállás - egészen addig, amíg auditon nem kell magyarázni,hogy miért 1234 éves OS van fent... Persze, lehet egyedileg, adott régi verzióban lévő ismert hibára kockázatelemzést csinálni, és bizonyítható módon indokolva "nem kihasználható" meg "felvállalt kockázat" címkével ignorálni - ez egészen addig tud működni,amíg nem 100-as nagyságrendű szerverpark és azon ezres nagyságrendben jelenlévő CVE-t serege az "ellenfél". Ott marad az, hogy update/upgrade, előbb a teszten, utána az uat-on, majd végül a prod környezetben is, mert ennyi CVE-t végignyálazni érdemben 10-ból 10 helyen nincs erőforrás. 

Igen, nekem is van RHEL5 meg 14.04-es Ubuntu "éles", archiv adatokkal - zárt, jól védett hálózati szegmensbe deportálva (egy terminálszerver van mellettük, oda lehet rdp-n bemenni, ha nagyon kell valami, de az rdp csak konzol meg egér, vágólap/fájlküldés/fittyfene az nincs. Amit ki akarnak onnan hozni, azt lementik egy adott könyvtárba, ahonnan egy script yool kitolja egy dedikált gépre. 

Attól, hogy nem volt bootolva, nem elavult az os. Kb. mindent tudok frissíteni, oszt megy egy service restart. Még firmware-re is vannak hot firmware loadingos eszközök. Gyakorlatilag magát a kernelt nem tudod frissíteni reboot nélkül. Nem figyelem, kernel-szinten mennyi a CVE.

Valahol igenis gond, ha meg kell bootolni a gépet.

"Nem figyelem, kernel-szinten mennyi a CVE"

magyarul elavult OS-en futnak a dolgaid, amit nem tudsz magyarázni, hogy miért így van, és nem is akarod tudni, hogy mennyi luk/hiba van a rendszerben... Írtam, hogy amíg nem kell auditon magyarázni, vagy épp a főnök előtt a szőnyeg szélén pingvinezni, mert se&&bedugták vazelin nélkül a céget egy méretes büntivel vagy épp a lukon ki-be járkálás okán adatot vesztett a cég, addig lehet élvezkedni a minél nagyobb uptime-ra, utána azért már kevésbé... 

"Valahol igenis gond, ha meg kell bootolni a gépet."

ott valami nagyon nem jól van tervezve/kialakítva. Tervezett leállásra kell, hogy legyen mód, illetve eljárásrend, mert ha az nincs, akkor egy nem tervezett kiesésre sincs felkészülve a környezet, és az bizony nagyon tud fájni...

Nálunk nagyon nehéz volt bármilyen komponenst indokolatlanul lecserélni.
Az újat mindig nagyobb kockázatnak tekintjük. Volt olyanra is példa, hogy csak a CVE került patch-elésre, nem az új verzió került fel.

Másrészt ha van is vulnerability-d, egyáltalán nem biztos, hogy az exposed is. Másképp jársz el egy border gateway esetén, mint egy szolgáltatást futtató node-nál, ami kívülről közvetlenül nem elérhető. Esetleg nem is IP alapú hálózatot routol.

Nem véletlenül írtam:
"Persze, lehet egyedileg, adott régi verzióban lévő ismert hibára kockázatelemzést csinálni, és bizonyítható módon indokolva "nem kihasználható" meg "felvállalt kockázat" címkével ignorálni - ez egészen addig tud működni,amíg nem 100-as nagyságrendű szerverpark és azon ezres nagyságrendben jelenlévő CVE-t serege az "ellenfél"."

Amíg egyedileg van rá erőforrás, hogy specifikus pecseléssel pöcsöljön :-) a rendszergazda, addig lehet direktben a CVE-re lőni, illetve olyan körülményeket kialakítani, amiben megfelelően alátámaszthatóan nem használható ki az adott sérülékenység, de ennek az erőforrásigénye bizony exponenciálisan megugrik, ha nem néhány, hanem néhány száz gép/vm/szolgáltatás van az adott ember/team keze alatt. Ja, és azt sem szabad elfelejteni, hogy support case-t nyitni elavult környezetben futó motyóra ugyan lehetséges, de a nulladik válasz 9x%, hogy az lesz, hogy tessék frissíteni, és utána reprodukálni a hibát. 

Meg fogsz lepődni. Az ISP-nél lévő levelezésemhez csak a szolgáltatáson keresztül, belülről érem el. A többi levelezésemnek nem tudom a jelszavait. Azon az egy gépen lévő Claws Mail kliensben van az összes levelezésem konfigurálva. Fejből szerintem még a mail címeimet sem tudom mind.

Tehát az a megoldás, hogy munkahelyről ssh-zok otthoni router-re, bekapcsolom magic packet küldésével a gépem, kinyitom a tűzfalat felé, utána ssh -CX a gépre, majd elindítom a mail klienst, viszont a lokális gépen jelenik meg annak ablaka, hiszen a remote gépen futó kliens az ssh fölött valósítja meg az X11 protocollt, s csatlakozik a lokális gépen futó X szerverhez.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Semmi különös, gyors SSD-nél csak élvezetes, ha a desktop rendszer gyorsan betölt, 3-4 mp alatt már a WM fut, nincs homokórázás. Embedded felhasználásnál szakik reszeltek olyan systemd-s rendszert, ami msec-ok alatt feláll. Minek várni, ha valami lehet gyorsabb? Nem is azt írtam, hogy ez mindenkinek fontos, csak egy előny, ami mellette szólhat. Nyilván ahogy írják, 5 percig az UEFI BIOS tesztekkel és RAID vezérlővel szüttyögő szervernél nem sokat gyorsít a bootoláson, ott valóban nem szempont.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

Ajánlom figyelmedbe. Ha ez kiforr és felépül hozzá az infrastukrúra nagyjából lényegtelenné válik a boot idő:
 

Live update orchestrator


This series introduces the Live Update Orchestrator, a kernel subsystem designed to facilitate live kernel updates using a kexec-based reboot. This has been designed primarily to allows virtual machines to continue working after the reboot with minimal downtime, a capability that is critical for cloud environments, but LUO is designed to be workload-agnostic. LUO achieves these goals by preserving the state of selected resources, such as memory, devices and their dependencies, across the kernel transition.

 

https://kernelnewbies.org/LinuxChanges#Linux_6.19.Live_update_orchestra…

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca