Háromról egyre csökkent a Rust for Linux alrendszer karbantartóinak száma

Kernel

Harmadára csökkent a mainline Linux kernel Rust alrendszerének, a Rust for Linux karbantartóinak létszáma. Alig több mint egy éve még hárman voltak, majd Wedson Almeida Filho lemondott a betöltött karbantartói pozíciójáról. Most pedig Alex Gaynor szintén a távozás mezejére lépett, magára hagyva egyedüli karbantartóként Miguel Ojeda-t.

( asch v | 2025. 11. 25., k – 14:45 )

Mi lehet az oka? Nincs mögötte finanszírozás? Szívás ez a munka? Vagy szellemileg nem eléggé kielégítő?

Az az oka, amit hónapokkal ezelőtt megírtam a HUP-ra, mikor az a Asahi Lina otthagyta a kernelt. Ezek a rustosok csak divatemberek, addig tartanak ki, amíg épp a kedvük tartja, amíg le nem ül a hájp, aztán ahogy elfogyott a lelkesedésük, megunják a banánt, lépnek le a Petőfi Csarnokba, keresnek maguknak más érdekességet, más hájpot, amivel 5 percig megint bekerülhetnek a hírekbe. A C-sek egészen mások, ők dinoszauruszok, ők ha valamibe belekezdenek, akkor kitartanak mellette a végsőkig, akkor is, ha nem menő már, unalmas, elegük van, nyomják, amíg tudják. Mielőtt valaki okoskodna, hogy nem a nyelv függvénye, az erősen téved. A C már nem érdekes, régi, ha valamit valaki megír C-ben, azt mindenki leszarja, nincs hírértéke, a kernelben sem, van már benne 30 millió C sor, senkinek nem üti meg az ingerküszöbét. Így aki ezzel foglalkozik, az a hivatástudat miatt csinálja, mert ebben jó, ezzel akar foglalkozni.

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

( Sanya v | 2025. 11. 25., k – 14:46 )

Pedig amit Rustban megírnak, az mindennél jobb!

Abban biztosan jobb, hogy nem egy pökhendi uraság becsszavára van bízva, hogy biztos nincs elcseszerintve benne semmilyen memóriakezelés (vagy szálkezelés) ... Persze, más bőven el lehet még egy Rust kódban, de vannak helyek, ahol pont az előbbi állítás igazságtartalma lenne marhafontos.

Erről eszembe jutott, hogy velünk utazott vonaton egy fülkében a 2000 környékén egy már nyugdíjas MÁV dolgozó, aki elmesélte, hogy mennyit dolgozott ott, milyen régi és tapasztalt munkatárs, meg azt is, hogy Ladányba tart. Hát nem leszállt Karcagon mert eltévesztette az állomást?

( kleinie | 2025. 11. 25., k – 19:27 )

Már várom a hírt, mikor kitakarítják a kernelből... Mennyi felesleges meló... Mint mindent is újraírni Rust-ban.

Nem vagyok programozó, nem írok programokat, csak érdekel a téma és sokat olvasok programozással és nyelvekkel kapcsolatban. Mikor megjelent a Rust, nagyon tetszett... Aztán egy förmedvénnyé változott az egész!

Nekem a Rust mar az elejetol fogva nem tetszett. A Python viszont szepen fejlodik, a 2-es Python hulyesegeit kijavitottak, es a 3-asba eleg jo dolgok kerultek bele az utobbi par verzioban. Egyik kedvenc nyelvem lett.

A strange game. The only winning move is not to play. How about a nice game of chess?

a 2-es Python hulyesegeit kijavitottak

ez igaz, de sok baromsag is kerult bele, mint a typing (aminek semmi ertelme, hisz az interpreter szarik raja, cserebe olvashatatlan lett tole kb minden ujabb kod), vagy a decoratorok es hasonlo marhasagok.

az asyncio mondjuk jo cucc, azt elismerem, de azt sem a 3.6-nal kellett volna belerakni hanem sokkal regebben, es akkor az azt emulalo/kerulgeto kokanyolasok kimaradtak volna.

nem is lattam meg olyan kodot ahol valaki hasznalta volna

hat en meg az utobbi evekben csak olyat latok, sot kb minden komolyabb python lib/framework irodik at typed-re ezzel teleszemetelve a commit logokat, raadasul a doksikban is ilyen, vicces mikor egy parameter utan fel van sorolva 15 fele tipus opcio

Typing nálunk kötelező. Nem véletlenül. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

Ez a ketto pont hasznos. A type hint persze opcionalis, de az IDE-nek jol jon, tudja, hogy mivel tudja kiegesziteni a kododat (pl. ha lista tipusu utan irsz pontot, felajanja az appendet, set utan az add-et). Libekben ezert terjed, sajat kodban nem kell hasznalnod. Egyebkent random LLM kitalalja es odairja neked, ebben kozel 100%-osak, nem szoktak hibazni.

A decorator ritkabban kell, de olyankor nagyon hasznosak, tipikusan ha valamit valahova be kell regisztralni (Flask mellett meg megemlitenem a PyQt-t). Meg van par hasznos beepitett (pl. cache, lru_cache), es sajatot is irhatsz.

Ezekhez kepest az asyncio-t kisebb elorelepesnek latom, de az is hasznos, ha olyan a feladat.

A strange game. The only winning move is not to play. How about a nice game of chess?

Jepp, a typing tök hasznos. Az olvashatatlanságot kicsit adom, néhol azért nem sikerült túl szépre -- bár azért most már alakult, néhány durva agyafszt levettek, illetve valójában egész jó indikátora annak, hogy elmaradt a KISS, ha nagyon gányul néz ki.

De igen, az van, hogy persze a nyelv egyszerűségéhez (as in, sallang nélkül lehet haladni) ugyan sokat ad, hogy dinamikusan típusos, de egy méret után kurvára megkönnyíti a munkát, hogy ki van írva, hogy az mi a pék, ami ott van. Nekem viszonylag gyakran kell jó nagy régi (értsd, még nagyom python2 volt) kódbázisban turkálni, és agyfasz időnként mire kitúrod, hogy abban az izében, ami bejön, valójában mi a picsa is van úgy egyébként, és azt ki is hol a brébe állítja elő. Ilyenkor igen hosszú nyomozati eljárást lehet tenni, mire kitúrod, hogy az honnan is jött (ráadásul extra kibaszásnak időnként oda-vissza C-be, hogy jó legyen). Simán odaadnám valaki fél kezét, hogy legyenek benne type hintek.

Van valamivel frissebb is (azért az is már bőven 6-7 éves), simán ilyen 100K LOC nagyságrendben, amit jobban is ismerek, meg sokkal véreskezűbb diktátorként vigyáztam rá, hogy ne rohadjon fossá a kód architektúra, ebben kevésbé fáj, de azért sokkal jobb azokhoz a részekhez nyúlni, ahol már van typehint.

A kikényszerítése* ügyében kicsit meg van az ember hasonulva. Egyrészt nem elhanyagolható mennyiségű plusz munkát jelent unitteszt / kódírás környékén, hogy az ember tisztességesen belátva megfelelően lefedje azt amit egy compiler gyakorlatilag azonnal ad. Cserébe azért azt is tudjuk, hogy sokszor az a fájdalom átkerül oda, míg végre lefordul, nehéz megítélni, hogy valójában mennyivel szarabb (és melyik :) )

A dekorátorok meg imho leginkább ízlés kérdései, nem baj, hogy vannak. Van azért bőven olyan eset, amikor sokkal tisztább megoldás, mint a usernek magyarázni, hogy milyen baseclass, meg olyan mixin, meg mit kell belőle megtartni, mert tisztább. Én személy szerint azt a usage módot, amit pl az emlegetett flask csinál, hogy ilyen lazybe oda lehet baszni mondjuk a routeokat, azt pont nem szeretem, értem, hogy csudi gyors írni, csak nem lesz igazán áttekinthető a végeredmény

szerk: *mármint hogy maga az interpreter kényszerítse ki. 

gondolom ez onnan ered, hogy a python eredetileg script nyelvnek indult, a perl alternativajakent. ma mar ez nyomokban sem latszik, talan a print functionna alakitasa volt az utolso dofes ennek.

nekem amugy a java megoldasa jobban tetszett, az ugye alapvetoen tipusos nyelv, de van object tipus ami meg barmi lehet.

nekem amugy a java megoldasa jobban tetszett, az ugye alapvetoen tipusos nyelv, de van object tipus ami meg barmi lehet.

Erosen tipusos, nem csak alapvetoen. A referencia lehet Object, mivel az osszes object abbol szarmazik, tehat hivatkozhatsz ra Object-kent. A tenyleges objektumnak, ami ott csucsul a memoriaban mindig van egy jol definialt tipusa, nem castolhatod akarmire.

Az "easy things easy" jól megy vele. A duck typing a gyakorlatban egy baromi flexibilis interface megoldás. Nem kell külön interfacezés, vagy öröklődés helyette, nem kell minden alesethez külön típusokkal csesződni variációk egy témára ügyben, nem kell genericsezni.

Persze egy pont után rájössz, hogy jó azért az, ha ezek egy része mégiscsak meg van csinálva, de azért mégiscsak te döntöd-el, hogy mi releváns, és mi nem az. Persze, "#3 With great power comes great responsibility".

Nem nagyon függ össze a dolog azzal amit írtál, de értem. Van egy olyan elméletem, miszerint minden programnyelv annyira biztonságos, mint az aki használja. Nem vagyok valami nagy programozó zseni, de szerintem képes lennék triviális baromságokat írni bármilyen nyelven úgy, hogy értelmes dolognak tűnjön.

Nemrég pl. egy eredetileg pythonban írt pontfelhő manipuláló programomat írtam át Rustban. A pythonos változat a sok függőség miatt (numpy, scipy, pandas, stb) miatt elég nehézkesen volt mozgatható. A cargo.toml fájlban csak egy függőség van, az nalgebra, jó mondjuk ez hozott magával fél gigabájtnyi cuccot, de a futtatható, statikus bináris 1 mega alatt van. Ráadásul sokkal gyorsabban dolgozik, mint az elődje. Durva volt, de a végén nagyon büszke voltam magamra, hogy ilyen elmebeteg nyelven is sikerült megcsinálni, ráadásul úgy, hogy ugyanazt tudja. Szóval ez részemről egy piros pont a Rustnak. Mivel ez volt az első komolyabb Rust projektem, biztos vagyok benne, hogy van benne bőven olyan szintű marhaság, mint amitől nemrég leseggelt a CloudFlare.

[Falu.Me]==>[-][□][X]

Az elméleted még meg is állja a helyét! Ill. már elég sokszor elhangzott itt is: aki ugatja, annak adhatsz bármilyen programnyelvet, képes benne szar kódot írni.

Nekem pont amiatt nem fekszik, amiért te "elmebetegnek" hívod! Mondom, ez nem tapasztalat. Egyszerűen nem tetszik az egész, a nyelvi elemek, a támogató eszközök, a túl nagy felhajtás körülötte (már-már vallási/politikai magasságokat súroló)...

A te esetedben, gondolom ezt akár C/C++, vagy Java nyelven is meg lehetett volna csinálni hasonlóan.

( NagyZ v | 2025. 11. 25., k – 23:44 )

akkor lehet is torolni a kernelbol az egeszet :)

( persicsb | 2025. 11. 26., sze – 09:27 )

Ez nem jelenti azt, hogy kevesebb fejlesztő van, ez csak a maintainerek, azaz azok, akik az adminisztratív munkát végzik a patchek fő kernelfába juttatásakor. Ettől még Rust for Linux fejlesztőből lehet sokkal-sokkal több. Kevesebb lett a titkárnő, ennyi történt.

najo, de egy maintainernek nem csak annyi volt a dolga hogy elfogadja a PR-t, hanem at is nezi, nem? igy most vagy lassabban kerul be egy-egy kod, vagy kevesebb figyelmet kap, es jobban atcsuszhatnak a hibak...

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Rohadtul nem csak adminisztratív feladatuk van. Ők reviewzzák az összes kódot, és csak az ő jóváhagyásukkal kerülhet be. Van persze egy rakás automata teszt is, ami segít ebben, de a végső szót akkor is ők mondják ki.

És olyan apró szarokra is odafigyelnek, mint hogy a git commit log megfelelően legyen megfogalmazva, pl. csak kijelentő mondatok szerepeljenek a kód változásokra vonatkozóan.

Akárhonnan nézzük 1 ember kevésnek tűnik. Mi van ha lebetegszik? (ebben a fene nagy elfogadott vilagban mindenkinek joga van a terhessegre)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Próbáltam volna egy értelmezhető quick statot csinálni a MAINTAINERSből, de annyira lehetetlen bescopeolni a címből, hogy mi mekkora, ami egyébként releváns összehasonlítás volna a rustttal, hogy na.

Illetve azért az látszik, hogy a dolgok, amik a maintainers fileban meg vannak jelölve rustnak, ott egyébként nem igazán van olyan, hogy ne lenne legalább két ember, még ha az egyik reviewer is (de ami érzésre nagyobb falat, ott azért meg vannak jelölve ált ketten). És ezek közül sehol egyik se Miguel.

Meg a hírből az azért kimaradt, és ezt tán van értelme lestatolni, hogy reviewernek azért ott van még 8 ember. Az egész maintainersben összeses 4 ilyen terület van, meg 1 db 9-es. (A 3102-ből). És abból a négyből az egyik rust. Ha összeadod a maintainer+reviewer számokat, akkor is az látszik, hogy van összesen 8 másik terület, ami tud 9+ embert. Szóval nem biztos, hogy valójában akkora itt az emberhiány, mint ahogy esetleg tűnik a hírből.