Nisam baš pratio razvoj Rust jezika, vidim da je već sazreo 10+ godina, ali nije to tema
Tema je, šta će se dešavati sa linuxom, jer se već pomalo agresivno gura Rust kako bi zamenio core komponente pa i sam kernel linuxa
Da li je to napredak ili nešto drugo, s obzirom da je Rust fondacija podržana od Microsofta, Amazona i ostalih filantropa.
Dakle šta će biti sa GNUom, koji btw ima svoj neki fork Rusta uz copyleft licencu, ali je daleko od stabilne varijante
Interesuje me vaše mišljenje, ja lično nisam oduševljen, ponajviše zbog licenciranja i hitne zamene C,C++ koda Rustom, npr dev za APT je najavio da će već za koji mesec jedna od ključnih komponenti biti rekompajlirana u Rustu, kernel već koristi Rust module..itd
[ djoka_l @ 29.01.2026. 09:30 ] @
U Linux kernelu nema C++ koda, to je Linus odavno zabranio.
APT nema veze ni sa kernelom ni sa GNU, jedan od desetina paket menadžera koji rade na Linuxima.
Rust je zaista koriščen u manjoj meri u Linux kernelu. I dalje se Rust oslanja na C biblioteke, pa je nedavno bila velika drama oko bcachefs fajl sistema koji je izbačen iz zvanične podrške.
Naime, za bcachefs neki delovi su bili pisani u Rustu, s tendencijom da ceo bude prebačen u Rust, ali ne odmah nego tokon dužeg niza godine.
Pa, tip koji je razvijao bcachefs, naravno, u svom kodu je morao da koristi poziv bibliotečkih funkcija pisanih u C-u, pa se našao pozvan da menja biblioteke koje nisu u njegovom flasništvu, pa čak i da traži merging tih izmene posle kraja ciklusa.
Naravno, Linus i gomila drugih ljudi su pobesenli, i izbacili bcachefs iz kernel developmenta.
To nema veze sa Rustom kao jezikom, verovatno će Rust po malo da ulazi u kernel, ali to opet nema veze sa GNU, jer GNU nije kernel.
[ Nedeljko @ 01.02.2026. 09:49 ] @
Ko god da podržava Rust, samo neka nastavi.
Rust je programski jezik koji nudi visok nivo sigurnosti. Recimo, C te ne sprečava da napišeš x[100] gde je x niz od 10 članova. U nekim slučajevima te neće sprečiti ni Rust, ali ćeš dobiti runtime grešku. U njemu nema invalid read-a.
Nudi još neke garancije. Neki kažu da sve te garancije propadaju ako imaš unsafe blokove. Ne, Rust nudi u tom slučaju iste garancije, pod pretpostavkom da su svi unsafe blokovi dobro napisani, što je odgovornost autora tih delova koda.
Zaživeo je na tržištu rada za mission critical projekte. Nudi i sigurnost i performanse na visokom nivou.
Rust koliko znam ima alate za interfejsovanje C/C++ biblioteka. Izlazak iz Rust ekosistema zahteva unsafe blokove, ali su u slučaju C-a jednostavni, a za C++ ima valjda neki alat, pa nije problem.
Ipak, Rust je drugačiji jer ima borrow checker, koji je njegova glavna inovacija, tako da kada se koriste biblioteke iz drugih jezika (recimo, GTK port za Rust), oseća se da nije prirodno uklopljena u Rust filozofiju, tako da se teži "rust-ovskim bibliotekama", koje su u duhu Rust-a.
Takođe, Rust ne podržava OOP jer ne podržava nasledđivanje. Autor Rust-a kaže da je Rust inspirisan raznim programskim jezicima i paradigmama, ali se niej slepo držao ničega od toga, nego težio pravljenju programskog jezika sa najboljim rešenjima. U OOP svetu, nalseđivanje se koristi za apstrakciju (polimorfizam - tretiranje podataka različitih tipova na isti način) i za ponovno korišćenje postojećeg koda. Rust nudi svoja rešenja za to.
Glavna mana Rust-a je što je težak za učenje i rad, pa nema mnogo radne snage koja ga dobro zna, pa se na tržištu rada traži da potvrdiš vladanje Rust-om velikim, ozbiljnim projektom. Zbog toga ne može biti masovan.
Ipak, nudi vrlo moćan sistem makroa sa kojim je svašta napravljeno. Sa mogućnostima koje nudi, privlači klikeraše, kojima težina nije problem i koji onda naprave sjajan ekosistem oko njega.
Njegovu zrelost pokazuje i činjenica da se na internetu pojavljuju sadržaji sa njegovim manama (implementacija md5sum je skoro 20 puta sporija od GNU C implementacije), što pokazuje interesovanje stručnjaka za njega i njegovo preispitivanje. Za Rust je to dobro, jer problemi isplivavaju na površinu, pa će se i rešavati.
Rust ima biblioteke koje se zovu crate-ovi. Ima ih u Rust repozitorijumima za svašta. Uglavnom nema potrebe za izlaženjem iz repoa.
Razvijaju se na način koji ne čuva kompatibilnost unazad, kao što ga ni Rust jezik ne čuva (nova verzija Rust jezika može da ne bude kompatibilna sa starom), ali se za to nudi rešenje u vidu konfiguracionog fajla projekta, koji se zove Cargo.toml, a u kome su navedene verzije i jezika i crate-ova koje se koriste, tako da će projekat nastaviti da se komapjlira na isti način, radi bez obzira na pojavu novih verzija.
Između crate-ova međusobno i između crate-ova i verzija jezika postoje zavisnosti, tako da može doći do konflikta slično kao kod paketa u repoima Linux distribucija. U slučaju konflikta se projekat ne može kompajlirati dok se ne razreše.
[ Nedeljko @ 01.02.2026. 22:12 ] @
Problemi nekonzistentnosti (za nešto mora verzija X crate-a A, a za nešto drugo verzija Y crate-a A) su rešivi pravljenjem biblioteka, svaka sa po jednom verzijom cratea A, pa onda njihovo korišćenje u istom projektu. Ako nekome smeta što MS i Amazon podržavaju Rust, Microsoft je platinasti član Linux fondacije, a srebrni članovi su amazon.io i aws.
oracle_kid:
Nisam baš pratio razvoj Rust jezika, vidim da je već sazreo 10+ godina, ali nije to tema
Tema je, šta će se dešavati sa linuxom, jer se već pomalo agresivno gura Rust kako bi zamenio core komponente pa i sam kernel linuxa
Da li je to napredak ili nešto drugo, s obzirom da je Rust fondacija podržana od Microsofta, Amazona i ostalih filantropa.
Dakle šta će biti sa GNUom, koji btw ima svoj neki fork Rusta uz copyleft licencu, ali je daleko od stabilne varijante
Interesuje me vaše mišljenje, ja lično nisam oduševljen, ponajviše zbog licenciranja i hitne zamene C,C++ koda Rustom, npr dev za APT je najavio da će već za koji mesec jedna od ključnih komponenti biti rekompajlirana u Rustu, kernel već koristi Rust module..itd
Rust je jako koristan u pisanju koda koji procesira kompleksne formate ili bilo kakav tip ulaznih podataka koji nije garantovan da bude korektan / po specifikaciji. U kontekstu kernela, pricamo o drajverima.
Tako je, zapravo, i nastao - kao projekat sponzorisan od Mozilla-e (browser je jako dobar primer kompleksnog softvera koji barata sa komplikovanim formatima cija tacnost nije zagarantovana i koji mogu biti vektor za infekcije, drugi primer su codec-i i parseri dokumenata koji su jako cest vektor infekcija i dan danas).
Tako da postojanje drajvera i sl. koda pisanog u Rust-u generalno nije losa stvar po Linux (ili bilo koji drugi OS, tipa Windows ili Android) - kriticne komponente koje mogu biti iskoriscene za hakovanje ce imati manju povrsinu koju napadaci mogu da iskoriste za iskoriscavanje sigurnosnih problema.
Ne verujem da ce Rust zameniti C u Linux (ili Windows) kernelu, ali ce vrlo verovatno postati vise zastupljen u drajverima.
[ Nedeljko @ 04.02.2026. 13:58 ] @
Ja ne znam odakle to o Rust-u da je posebno podesan (u odnosu na druge jezike) za robusno procesiranje jezika, niti sa čimiz Rust-a to ima veze.
Jedino ako su klikeraši smislili neke kerefeke za Rust za to.
[ Nedeljko @ 04.02.2026. 14:03 ] @
Evo šta mi je napisao gospodin ChatGPT:
Rust je posebno dobar kad hoćeš performanse bliske C/C++, ali uz jake garancije bezbednosti (memory safety) i predvidljivo ponašanje. Najčešće “blista” u ovim situacijama:
Sistemski i “near-metal” softver: OS delovi, drajveri, embedded, razni runtime-i, alatke.
Visokoperformansni serveri i mrežni softver: niska latencija, visoka propusnost, stabilnost.
Konkurentni/parallel programi: gde je trka (data race) skup bug — Rust te tu mnogo štiti.
CLI alatke i dev tooling: brze, pouzdane, lako se distribuiraju kao jedan binar.
Kriptografija i sigurnosno osetljiv kod: jer je “klasa” bagova manja.
WASM: Rust → WebAssembly je dosta popularna kombinacija.
Biblioteke (FFI) koje treba da budu stabilne: možeš da praviš jezgro u Rust-u, a da ga koriste drugi jezici.
A ovo za “složene formate koji možda nisu po specifikaciji” — da, ima veze (indirektno)
Rust je vrlo pogodan za robustno parsiranje “prljavih” ili delimično neispravnih formata (ili formata koji su “u praksi” drugačiji od specifikacije), ali ne zato što Rust “magijski” razume takve formate — nego zato što:
Tipovi i Result/Option te teraju da eksplicitno modeluješ greške i nedostajuća polja.
Umesto “crash ili UB”, dobiješ kontrolisano: validno / invalidno / nepotpuno / fallback.
Nema “undefined behavior” tipa buffer overflow-a ako ne koristiš unsafe.
Kod parsiranja binarnih formata i mrežnih paketa ovo je ogromno.
Lako gradiš “tolerant parser”:
prihvati više varijanti,
verzionisanje formata,
“best-effort” dekodovanje,
čuvanje “unknown fields” radi round-trip serializacije.
Odličan ekosistem za parsiranje: nom (parser combinators), serde (JSON/YAML/TOML/…); plus biblioteke za specifične formate.
Bitan detalj: “tolerantan” parser nije uvek dobar
Za neke stvari (npr. kripto protokoli, autentifikacija, bezbednosni tokeni) “tolerant parsing” ume da bude opasan: napadač iskoristi razliku između “kako ti parsiraš” i “kako drugi parsira”. Tada je bolje biti strogo po specifikaciji.
[ oracle_kid @ 11.02.2026. 12:46 ] @
Rekoh na početku da tema nije Rust, već licenciranje i budućnost Linuxa, ali čini mi se da se više potencirao tehnički deo Rusta.
Vidim da svi teraju priču da je Rust “spas za bezbednost”. A u pozadini je distanciranje od GPLa na duže staze. GNU + Kernel je GPL copyleft, vrati zajednici ono što uzmeš. Rust je MIT/Apache odn. uzmi, zatvori, teraj dalje, hvala lepo. I sad treba da verujemo da tu nema dugoročne igre?
Dakle, nije problem jezik. Problem je ko ga gura i pod kojim pravilima. Rust fondacija= korporacijski interes. Bigtech daje pare, drži volan. Danas “memory safety”, sutra možda zaključani fork optimizovan za cloud gigante, moćniji jer se finansira, a community varijanta polako zaostaje ili nestaje.
GPL je godinama terao firme da igraju pošteno. Sa novim licencama to nestaje. Lakše je izvući deo, zakrpiti po svom, zaključati ostatak i reći pa sve je open source, šta hocete. Da ne govorim o nestabilnosti Rusta u smislu da i dalje evoluira..povratna nekompatibilnost, ma savršen kandidat za core projekat
Stalmanova ideja koja je napravila Linux jedinstvenim - da je sloboda važnija od komfora, polako nestaje. Ok, možda sam konzervativan, ali baš takav Linux mi se sviđao
[ Nedeljko @ 11.02.2026. 21:38 ] @
Do sada se Linux kernel razvijao u gcc-u koji ti omogućava da licenciraš svoj kod kako hoćeš, ako i Rust. Slobodno ga stavi pod GPL ako hoćeš. Da, fork Rust-a se može pojaviti. Može i od llvm-a.
[ Nedeljko @ 12.02.2026. 16:37 ] @
Citat:
oracle_kid: Rust fondacija= korporacijski interes. Bigtech daje pare, drži volan.
Pa, i Linux fondacija je korporacijski interes. Bigtech daje pare i drži volan.
[ oracle_kid @ 15.02.2026. 12:11 ] @
Citat:
Nedeljko:
Pa, i Linux fondacija je korporacijski interes. Bigtech daje pare i drži volan.
Ma naravno sve je to isto, GPL , MIT, non-profit, BIG-profit, Billy, Chilly-Willy i naravno Džej
[ Nedeljko @ 15.02.2026. 16:00 ] @
Guglaj Linux Foundation member.
Platinum members:
1. ERICSSON
2. FUJITSU
3. Google
4. HITACHI
5. HUAWEI
6. Meta
7. Microsoft
8. NEC
9. ORACLE
10. Qualcomm
11. IBM / Red Hat
12. SAMSUNG
Gold members:
1. ANTHROPIC
2. Baidu
3. DELL Technologies
4. FUTUREWEI
5. HONDA
6. LY Corporation
7. MITSUBISHI ELECTRIC
8. Panasonic AUTOMOTIVE
9. Panasonic
10. Renesas
11. SONY
12. TOSHIBA
13. TOYOTA
Da, dva pominja ja Panasonic-a su u redu.
Silver members (1410).
[ Nedeljko @ 02.03.2026. 13:03 ] @
Pokretač teme je verovatno mislio na ovako nešto:
[ Nedeljko @ 02.03.2026. 13:57 ] @
Linux kernel je licenciran kao GPLv2. Licenca GPLv3 nikada nije bila prihvaćena i nije kompatibilna sa GPLv2. Dakle, ne može isti kernel imati GPLv2 i GPLv3 delove.
Rust toolchain je open source, pa ne ograničava licenciranje koda napisanog u Rust-u ni u izvornom ni u kompajliranom obliku.
Međutim, u binarni oblik ulaze biblioteke i crate-ovi. Oni su uglavnom dvostruko licencirani sa MIT (kompatibilna sa GPLv2) i Apache 2.0 (nekompatibilna sa GPLv2, mada kompatibilna sa GPLv3). Dakle, mogu se koristiti isključivo oni koji imaju MIT licencu kao mogućnost.
Linus je i ranije prihvatao kod pod BSD ili drugom open source licencom ako je GPLv2 kompatibilna, mada ne uvek. Ako se nešto pravi baš za kernel, onda mora GPLv2, a ako je nešto uzeto odnekud, onda ne mora, nego može i neka kompatibilna licenca.
Meni iskustvo kaže da ne treba brinuti o tim "fundamentalnim problemima" dok se ne ispolje. Kada se ispolje, onda naći rešenja. Linux se do sada tako razvijao. Linus je to izrazio rečima "Linux je evolucija, a ne kreativni dizajn". Razvoj se rukovodi tekućim problemima, a ne nekim ciljem u budućnosti.
[ Nedeljko @ 03.03.2026. 10:17 ] @
Evo još jednog videa na tu temu
U vezi s tim, odavno postoje veliki i važni open source projekti pod permissive licencama - FreeBSD i derivati (NetBSD, OpenBSD i PC BSD) i llvm. Šta se desilo sa slobodama nad njima? Ah, da, apple je dobudžio llvm za njegove sisteme. Jesu li ostali izgubili?
Copyleft licence su bile od koristi za webkit, kada je Apple pokrao KHTML koji je bio pod LGPLv2.1 licencom. dobudžili ga do WebKit-a i zatvorili. To tako ne može, pa je Apple po sili zakona morao da opensource-uje webkit.
Da li se iko seća XFree86 projekta? To je bio X server za Linux do trenutka kada je objavio verziju 4.4 koja nije u celini pod open source uslovima. Linux distribucije su privremeno ostale an verziji 4.3 koja je bila potpuno open source da bi se ubrzo pojavio x.org fork koji je bio potpuno open source i nadalje je bio korišćen on.
[ Nedeljko @ 25.04.2026. 18:43 ] @
Evo izveštaja za core utils u ubuntu-u 26.04:
Ova skripta koju je napisao gospodin ChatGPT
Code (bash):
dpkg-L coreutils-from-uutils \ |grep-E'^/usr/bin/[^/]+$' \ |sort \ |whileread-r p do name=$(basename"$p") real=$(readlink-f"$p") ver=$("$p"--version2>&1|head-n1)
ifecho"$ver"|grep-qi'uutils'; then impl='Rust/uutils' elifecho"$ver"|grep-qi'GNU coreutils'; then impl='GNU/C' elifecho"$real"|grep-q'^/usr/lib/cargo/bin/coreutils/'; then impl='Rust/uutils' elifecho"$real"|grep-q'^/usr/bin/gnu'; then impl='GNU/C' else impl='unknown' fi
što čini core utils, C implementacije su zadržane za
cp, df, mv, rm i true.
Zanimljivo je da je true zadržan u C-u, dok je false reimplementiran u Rust-u.
[ Nedeljko @ 25.04.2026. 19:06 ] @
Još nešto. Koliko se Rust uklapa u Unix filozofiju?
Svaka komponenta treba da bude instalirana jednom na sistemu i da je koriste svi programi kojima treba na sistemu.
hello world kompajliran raznim jezicima
C: gcc 15952 bajta, posle strip-a 14472 bajta,
clang 15992 bajta, posle strip-a 14504 bajtova.
C++: g++ 16504 bajta, posle strip-a 14480 bajtova,
clang++ 16312 bajta, posle strip-a 14512 bajta.
Rust: rustc -C prefer-dynamic daje 8528 bajtova, posle strip-a 6160 bajtova.
Dakle, ako bi se sve reimplementiralo u Rust-u, bilo bi ekonomičnije za RAM i disk.
Ako baš mora statičko linkovanje, mogu da se biraju feature-i crate-ova koji se koriste. Ne mora da se ulinkuje ono što se ne koristi.
[ Ivan Dimkovic @ 26.04.2026. 09:47 ] @
Citat:
Nedeljko:
Ja ne znam odakle to o Rust-u da je posebno podesan (u odnosu na druge jezike) za robusno procesiranje jezika, niti sa čimiz Rust-a to ima veze.
Jedino ako su klikeraši smislili neke kerefeke za Rust za to.
Da, postoje naravno i drugi jezici koji ne pate od nedefinisanog ponasanja ili nesigurnog baratanja memorijom ali Rust je jedan od retkih popularnih jezika koji nudi uporedive performanse u odnosu na C/C++ ukljucujuci i mogucnost pisanja kernel-mode koda.
Kojekakvi codeci sl. su odlicna “meta” za Rust, ne zbog “sintaktickog secera” vec zbog mogucnosti da se ne izgube performanse a da se umanji mogucnost eksploatisanja nesigurnog manipulisanja memorijom.