Újraírják a Tor-t C helyett Rust-ban

Programozás

A Tor projekt azon szorgoskodik már egy ideje, hogy újraírja a 2000-es évek óta C-ben létező produktumát a manapság egyre nagyobb teret hódító Rust-ba. Milyen okok miatt vágtak bele a munkába? A szokásos érvek a C ellen: buffer overflows, use-after-free bugs, memory corruption.

A Tor Rust verziója az Arti, aminek most jelent meg az 1.8.0-s kiadása:

Az Arti a folyamatban lévő projektünk, amelynek célja egy következő generációs Tor-implementáció létrehozása Rustban. Örömmel jelentjük be a legújabb kiadást, az Arti 1.8.0-t.
Post by @itsfoss@mastodon.social
View on Mastodon

Bejelentés itt.

( wladek1 | 2025. 12. 12., p – 08:51 )

Oriasi sikertortenet eddig is, mindenkepp mindent ujra kell irni benne. Talan a C-t magat is ujrairnam Rust -ban.

Error: nmcli terminated by signal Félbeszakítás (2)

Nem erről van szó. Hanem arról, hogy egyre több szoftveres megoldás kell, a világ napról-napra egyre jobban függ az IT-tól. A programozók túl vannak hajtva, mindennél fontosabb a teljesítés, még ha nem is minőségi, ezt persze a konstans béta szemlélet, agilitás és hasonló bullshitek mögé rejtik.

Cserébe ez azt is jelenti, hogy egy szoftveres hiba nagyon komoly következményekkel tud járni, gazdasági, biztonsági, meg mindenféle egyéb problémákat tud okozni.

Emiatt aztán elsőrendű fontosságú, hogy kiküszöböljük a hibákat a lehető leghamarabb. Nem arról van szó, hogy hülyülnének a programozók, hanem arról, hogy a heti 40 meeting, párhuzamosan futó és folyamatosan változó projektek és mindenféle egyéb fókuszvesztés miatt, bizony, hibáznak. És a hibáknak meg komoly következménye van.

Régen ráfordíthattad azt a mennyiségű munkát, mert magának a terméknek az életciklusa hosszabb volt, és meg tudott térülni.
Sokan azt nem értik, hogy nem a tökéletes program a cél. Hanem a még éppen elég jó. A fejlesztési folyamat pedig legyen gyors és gazdaságos.

Régen ráfordíthattad azt a mennyiségű munkát, mert magának a terméknek az életciklusa hosszabb volt

Nyilván, mivel kevesebb helyen használtak szofvert. Minden ment papíron, vagy mechanikusan. Ma már nincs így, egyre több és több és több szoftver kell, minden változik, a változást is követni kell, rengeteg munkája van a fejlesztőknek.

Rengetegszer mondta egy volt főnököm olyankor, amikor szerintem csak a specifikációnak és az elvárásoknak akartam megfelelni, hogy ez, amit most éppen csinálok: ki fizeti meg???

Jól van az a nélkül is.
A bare minimumra törekvés volt mindig. Aztán ha valami nagyobb gáz, mint gondoltuk, majd utólag mögérakjuk.

A sérülékenységek legnagyobb része buffer overflow jellegű, a C fejlesztőknek pedig az elmúlt 40+ évben nem sikerült elérni hogy ne legyenek ilyen hibák a kódjaikban (illetve igen, nagyon komoly korlátozásokkal írt kód mellett, lásd Misra-C). Most akkor vagy mindenki hülye, vagy egyszerűen a nyelv nem alkalmas arra hogy az ilyen jellegű hibáktól védjen.

Az a baj, hogy nem csak buffer ovverun errorral találkozunk, hanem folyamatosan mindenféle, teljesen felesleges hibákkal. Ebőll a rust ki fog javítani párat, beletesz párat...

Lehet, hogy valami javulni fog, de csak ettől nem várnék megváltást.

http://plazmauniverzum.hu <> A látható anyag 99.999%-a plazma <>

Van rengeteg projekt, ahol leírják, hogy mit várnak a Rust-ra átírástól, nagyjából objektívan kiemelve a várt előnyöket és megemlítve a várt hátrányokat.

A haterek azok, akik ezt úgy látják, vagy próbálják láttatni, mintha csodát várnának az átírástól. Lásd, pl. bzt megszólalását Linux kernel ügyében.

Csodavárásnak állítja be Greg Kroah-Hartman írását, pedig egy tárgyilagos leírás, lásd a válaszomat rá.

Nem akarlak megsérteni, de úgy tűnik, hogy Te is csodavárásnak állítod be ezeket. Aki nem fan és nem hater, az látja az előnyeit, hátrányait.

( hory v | 2025. 12. 12., p – 10:44 )

Szokásos Rust-bashing már el is kezdődött. :D

Részemről inkább amiatt morcognék, mert a rust igazából még nem egészen áll készen arra, hogy széles körben használják. A borrow checker még mindig borzasztó alapszintű, és egészen primitív helyzetekben is triggerelődik.

Sokat javult a helyzet 5-6 évvel ezelőtthöz képest, de sehol sincs ahhoz képest, ahol lennie kellene.

Ugye a borrow checker kvázi egy kötelező static analysis tool, ami bele van égetve a rustc-be. De akkor meg mondjuk elsődleges fontosságú lenne, hogy ne legyen útban, csak amennyire kell. De perpill kurvára nem ez a helyzet, és gyakorlatilag minden rust developer, kezdő és régi, küzd vele.

Van ugyan a project polonius, de nem nagyon jut egyről kettőre valamiért.

Ha lenne tisztességes, intelligens borrow checker a rust-ban, akkor tényleg készen állna rá, hogy átvegye a C helyét.

Az iparban szerzett tapasztalatok azt mutatják, hogy soha a büdös kurva életbe' nem készül el semmi, ha csak várunk. Éppen ez tudja megkatalizálni a fejlesztését, hogy bedobjuk valamibe élesbe', oszt akkor már csak előre lehet menekülni. Ne félj, rendbe fogják rakni, hirtelen fontos lesz.

Mutatnál példát arra, ahol nem segít a borrow checker, csak útban van?

 

Amúgy a Polonius kapcsán érdemes elolvasni a blogcikket, ami alapján készült, kiemelten szerepel benne:

The first thing to note is that this proposal makes no difference from the point of view of an end-user of Rust.

Szóval a programozók szempontjából a Poloniusos borrow checker pontosan ugyanúgy viselkedik, mint a mostani.

Mutatnál példát arra, ahol nem segít a borrow checker, csak útban van?
Kettős láncolt lista. Vagy bármilyen node gráf. Vagy bármilyen memallokáló libhívás. Meg még egy valag eset vagy van vérthugyozós példa is.
Ez persze csak azok az esetek, ha jól működne, de ráadásul nem is mindig működik jól.
Ha lenne tisztességes, intelligens borrow checker a rust-ban, akkor tényleg készen állna rá, hogy átvegye a C helyét.
Hát azért még kismillió dolog nem ártana a Rozsdácskába, mondjuk egy stabil ABI többek között. A C azért veri mind a mai napig kenterbe, mert a C ABI a bináris lingua franca.
Az sem ártana, ha kihajítanák a Cargo-t, és lehetővé tennék, hogy más nyelvekből fordított objektumokkal is lehessen statikusan linkelni. Ez az "elavult" C-nél tök alap, simán összelinkelheted pl. egy Ada-ból fordított .o-val.
Ne dőlj be az álhírnek. Annyiról van csak szó, hogy le akarják venni az "EXPERIMENTAL" cimkét, és még véletlenül sem arról, hogy az egészet újraírják Rust-ban. A C volt, van és még nagyon sokáig lesz a kernelben.
A port.hu szokás szerint hazudik meg félrefordít dolgokat. Az igazság odaát van:
it [Rust] is now a core part of the kernel and is here to stay. So the "experimental" tag will be coming off.
Aztán hogy meddig marad, azt majd meglátjuk, pláne ha az egy szem megmaradt maintaner is beadja a kulcsot, mint a többiek. Én nem tennék nagy összeget olyan kernel modulra, ami mögül sorra hátrálnak ki a kitalálói, és kevesebb, mint egy év alatt one man showra redukálódott. Mondhatni, most már single point of failure.

Előbb-utóbb megérkezik az a maintainer, aki elbír a feladattal.

Szívem szerint bízom benne, hogy még nagyon sokáig élni fog a C. Szeretem. Ebbe nőttem bele, hogy mit csinál a linker, milyen esetben mit, hogyan, mivel.
Ugyanakkor látom, hogy öreg motorosok vagyunk már. A fiatalabb generációk már nem ezekre a dolgokra verik ki.
Indirekt módon akkor szembesültem ezzel, amikor adott feladatra vizsgáltam két keretrendszert. Évekkel ezelőtt volt, részletekre már nem emlékszem. De az megmaradt, hogy az egyiket pure C-ben fejlesztették, és a hardvertámogatása (szenzorokra, aktuátorokra kell itt gondolni) a béka segge alatt volt. A másik kb. minden létezőt támogatott - ebbe Python-ban is lehetett modulokat befejleszteni.
Elkerülhetetlen belátni, hogy C-ben fejleszteni egyre kevesebb use-case esetén rentábilis. C bizonyára volt, van, és lesz. A szerepe azonban erősen leszűkült, és ez a tendencia a jövőben tovább folytatódik.

Bejezd be a maszatolást és másra mutogatást.
Nem szokásom "bejezni", de ha "fejezd be" akarna lenni, akkor ez a te szádból feledtébb viccesen hangzik!

Továbbra is fenntartom, hogy miért is írtam volna olyan címet, amit sosem használok és sosem látogatok? De még az idejét sem tudom, mikor kattintotam át rá utoljára. Évek óta nem is jártam arrafelé.
Egyébként meg tök mind1, a mondanivalón nem változtat semmit, s/*{4}\.hu/eredeti oldal/g és örülünk Vincent.

Nem szokásom "bejezni"

Te vagy az, tibyke?

Egyébként meg tök mind1, a mondanivalón nem változtat semmit

A mondanivalón talán nem, a közlő megítélésén viszont változtathat, hogy valami banális hibát fel tud-e vállalni, vagy egyből odaugrunk, hogy a gyíkemberek orvul UPDATE-elték az adatbázist

valami banális hibát fel tud-e vállalni
Ha én követtem volna el, felvállaltam volna.
egyből odaugrunk, hogy a gyíkemberek orvul UPDATE-elték az adatbázist
Kik? Te jössz az összeesküvéselméletekkel, te nem szólsz a témához, te próbálsz itt személyeskedni, nem én. Lásd kis trolldetektor.

Egyébként meg rohadt gyakori, hogy utólag változás történik, tessék konkrét példa. Azt még te sem képzelheted, hogy ez így lett eredetileg megírva, és aki anno látta a posztomat, az tudja, hogy bizony nem így nézett ki.
Egyetlen példa is elég a cáfolathoz, na és te milyen bizonyítékot mutattál fel? Ja, persze, az égvilágon semmit se, csak kaffogsz. Nem mintha bárkit meglepne.

( ssikiss | 2025. 12. 12., p – 17:28 )

[off] A következő HUP Választása díj szavazások közé fel kellene venni azt a kérdést, hogy mi volt az év legtöbbet ismételt flame-generáló témája, és ott az "XY ... átírása Rustra" opció legyen mindenképp! :D

( falu v | 2025. 12. 12., p – 18:42 )

Mi lenne, ha inkább C++ ban írnák újra? Abban nem lenne akkora sz*pás?

[Falu.Me]==>[-][□][X]
Mi lenne, ha inkább C++ ban írnák újra? Abban nem lenne akkora sz*pás?
Le vagy maradva, már próbálták, bukta lett. (Nem jut eszembe a projekt neve, sok-sok éve volt, de arra emlékszem, hogy I2P-t is tudott Tor mellett.)
Az mindenesetre jól mutatja a bukta mértékét, hogy én elfelejtettem még a nevét is, te meg még soha nem is hallottál róla.