TL;DR volt egy C-ben írt eszköz, ami éveken át tök jól működött. Bizonyos részeit átírták Rust-ba, ennek eredményeként a csomag karbantarthatatlanná vált, annyira, hogy most meg is szűnik, ha nem jelentkezik valaki karbantartónak.
Hosszan: a bcachefs-tools karbantartója elmeséli, milyen csodás a Rust: https://jonathancarter.org/2024/08/29/orphaning-bcachefs-tools-in-debia…
Pár érdekes szösszenet a blogból:
In 2019, it seemed that the time has come for bcachefs to be merged into Linux, so I thought that it’s about time we have the userspace tools (bcachefs-tools) packaged in Debian.
It was quite easy to package it, since it was written in C and shipped with a makefile that just worked, and it made it past NEW into unstable in 19 January 2020
Fast-forwarding towards the end of 2023, version 1.2 shipped with some utilities written in Rust
I got some help from the Rust team who says that the common practice is to relax the dependencies of Rust software so that it builds in Debian.
I found this a bit disturbing, but it seems that some Rust people have lots of confidence that if something builds, it will run fine.
With that in mind, at this point you may wonder how any distribution could sanely package this. The problem is that they can’t.
És a konklúzió:
As it stands now, bcachefs-tools is impossible to maintain in Debian stable.
With this in mind (not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit), I decided to remove bcachefs-tools from Debian completely. Although after discussing this with another DD, I was convinced to orphan it instead, which I have now done.
Gratulálok, ez ám az előrelépés és a fejlődés! Iskolapéldája, hogy a Rust jobb a C-nél! (szarkazmus)
Most jöhetnek a habzószájú Rust-huszárok, de javaslom, hogy ha tényleg komolyan veszitek magatokat, akkor inkább jelentkezzetek bcachefs-tools karbantartónak!
Hozzászólások
Mint nem fejlesztő, amit én látok kis túlzással:
- Ami a 2000-es években volt a PHP, Java.
- Az a 2010-es években a Python.
- A 2020-as években a Rust.
Hogy ez így jó-e....
Hát igen, nagyjából. Itt annyival nagyobb a baj, hogy PHP, Java, és Python esetén nem kell csomagokat eltávolítani a Debian stable-ből, míg Rust esetén kénytelenek.
A fő különbség, a korábbi agyonhájpolt nyelvek (bár nem váltották meg a világot) továbbra is használhatók és a bennük írt toolok elérhetők Debian alatt, addig a Rust-os toolt kevesebb, mint egy évvel a megjelenése után már muszáj törölni, mert karbantarthatatlan.
Szerintem ez a jó öreg függőség kezelési probléma. A python -nál is kész öröm amikor pip -pel kell telepíteni olyan csomagot aminek van bináris függősége. Ha a rendszerben lévő bináris nem kompatibilis, kezdődhet a tánc. Nyilván a RUST esetében ami nem interpretált nyelv ez a konfliktus gyakrabban jön elő, hisz sokkal több a bináris függőség. De ugyan ez a probléma létezik C vagy C++ programok esetében is, pl. ha az upstream gyorsan, és nem visszafelé kompatibilisen cseréli a függőségeit. Ilyenkor van, hogy a disztróban ősöreg verzió érhető csak el, mert a függőségek frissítése borítaná a rendszert.
A régóta használt nyelvek azért egyszerűbbek, mert van 1000 példa és írott vagy íratlan szabály a probléma elkerülésére vagy kezelésére. De ez nem a RUST hibája, csak egy új technológia bevezetésének a nehézsége.
Csak majdnem, lásd alább.
Nem, nem létezik, mert a C vagy C++ fordító nem akarja mindig a legfrissebb csomagokat a netről lerángati. (A pip akkor már közelebb áll a hasonlathoz, de amíg a Python simán megy pip nélkül, addig a Rust öntökönszúrás cargo nélkül.)
De, mivel saját csomag és függőségkezelője van, amivel menthetetlenül egybe lett gyógyítva. Konkrétan koncepcionális problémáról van itt szó.
A Gonak is van valami hasonló agymenése.
ott azert tobb megoldas is van. go mod vendor, es akkor a targeza-ba bele lehet rakni a szukseges fuggosegek forrasat. nyilvan a forrascsomag igy nagy lesz.
de ha a megfelelo konyvtarban ott a forras fajlok, akkor a gobuild azt fogja hasznalni, es nem fog a netrol letolteni semmit. a debian is ezt a modszert hasznalja:
nagy melo, de minden go-s cuccnak megvan a dev csomagja:
https://packages.ubuntu.com/jammy/golang-golang-x-oauth2-dev
https://packages.ubuntu.com/search?suite=default§ion=all&arch=any&k…
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Ami semmit sem segít azon, ha a python szkriptnek bináris függősége van, és a megfelelő verzió nem érhető el a rendszerben.
Ott van pl az openssl-sys crate, ami a rendszerben lévő openssl shared library wrappere. Nem tölt le semmit, csak szól, ha a .so nem elérhető. Szóval koncepcionálisan a RUST együtt tud élni a rendszer csomagkezelőjével, ergo a Debian maintainer el tudná készíteni dpkg -ben a függőség fát, majd az upstream project függőség kezelését patch -ekkel tudná megfelelően módosítani. Innentől pont ugyan úgy kezelhető a függőség mintha C vagy C++ program lenne. Ha a python csomagokat újra tudják csomagolni akkor a cargo -val mi a gond?De az a vita, hogy ki diktálja a függőségeket nem mai keletű. A disztrók saját csomagtárolói rendszerint lassabban frissülnek, cserébe stabilabb működést biztosítanak. A lassabb frissülés viszont biztonsági kockázatot jelent. Az upstream projektek szempontjából pedig szívás, hogy ahány disztró, annyi dudás próbálja diktálni milyen függőségek elérhetőek, és hol találhatóak. Az konzervatív megközelítés, hogy a disztró diktál, és az upstream lesz szíves alkalmazkodni, mert a rendszerbe nem telepíthet minden jöttment mindenféle dolgokat. Az új megközelítés, pedig, hogy az upstream lesz szíves hordozható csomag formátumban kiadni a termékét, ami downstream 1:1 -ben használható megfelelő izoláció mellett.
Esetünkben valószínűleg az a baj, hogy a Debian maintainer esetleg nem ért a RUST -hoz, illetve a wrapper csomag hierarchia elkészítése kezdetben sok meló. Az upstream peding nem elég rugalmasan áll a függőség kezeléshez (ott a cargo, majd én megmondom mi legyen). Erre teljesen jó megoldás hátralépni, hogy csinálja más, de nem tűnik úgy, hogy ez a RUST sara.
De nem tudja, és már elege is lett, hogy neki kellene más szarját lapátolnia, pont ezért szünt meg a csomag.
Az, hogy redundásan és globálisan duplikálni kell a csomagfüggőségeket, ami mindig is örök probléma forrása lesz. Python esetében nincs ilyen, ott simán tudsz lokális függőségeket megadni és egymás mellé telepíteni 2.6-ot és 3.3-at (pip nélkül is). Rust cargo-val ez nem kivitelezhető, mint a fenti példa mutatja (nem is válthatod ki a cargo-t, és nem is tudsz több, független verziót telepíteni egyszerre).
Hanem kié? Miért van az, hogy amíg nem jelentek meg a Rust-os programok a csomagban, addig 3 éven át nem volt ilyen gond, csak azóta?
Pythonnál legalább egyszerű egy virtualenvet csinálni, nem kell keverni a disztro csomagkezelő és a pip dolgait.
Ami egészen addig működik, amíg a pip csomagnak nincs bináris függősége.
Nem tudom, mire gondolsz, a pip az nekem full pythonnak néz ki, szóval ha a virtualenv parancs működött, utána a pipnek se lesz akadálya.
Vagy hogy egy tetszőleges python csomagra gondolsz, aminél megszívhatod pip install közben?
Jártunk úgy windows alatt, hogy egy adott csomaghoz tartozó C kód nem fordult le (a csomag letöltése után próbálta összeforgatni). A megoldás végülis az lett hogy az egészet behajítottuk egy linux alapú docker containerbe, aztán úgy már működött.
Igen, azzal van a baj, mikor vmi külső build time dep van.
Ja, hát az szívás. De ez nem több, mint akármelyik C program API/ABI inkompatibilitási gondja, nem a Python hozza be.
De ettől még belekeverni a csomagkezelő dolgait.
Ha keresek egy toolt, és úgy kezdődik doksi a telepítésről, hogy pear meg pip install, már zárom is be. Nem akarok ilyennel baszakodni. Ha nem telepíthető minden függőség csomagból, akkor viszlát.
"Sose a gép a hülye."
A párja a gem (Ruby). Egyszer véletlenül sudo-val telepítettem egy gemet, a vége az lett, hogy újra kellett telepíteni az egész gépet, mert nem lehetett visszacsinálni se és onnantól semmi se működött. (Kicsit túloztam, valójában egy munkanapnál több nem ment el rubygemmel birkózással.)
Jah igen... Az is csodás.
"Sose a gép a hülye."
Ennek egyébként ez az egyik oldala... És ez alapvetően nem akkora probléma. De a másik, amitől rosszul vagyok, hogy írjuk újra az aktuális divatnyelvben, ami sem plusz funkciót nem hoz (sőt...), se sebességet, se kevesebb erőforrást, ellenben ígér biztonságosabb kódot, de az eredmény valahogy mégis az, hogy egyre szarabb minden.
Hogy létezett egy tool/program a 90-es években, C-ben/Pascalban, volt 50KB, evett pár MB ramot, volt benne 3 ismert bug.... 2000-ben újraírták Javaban, lett 5MB (a jre ugye...), evett 50MB ramot, lassabb lett és lett benne 5 random előjövő hiba. Kalapálták évekig, talán eljutott a C-s szintjére. Majd a divathullámra felülve (plusz mert az új fejlesztő nem fogja a régi szaros kódját tákolni) 2010-ben újraírják pythonban, a nyers kód 10KB, de az összes szükséges lib-et ha megnézem + a futtatókörnyezetet, akkor lett 500MB, kell neki min. 200MB ram és lett benne 10 hiba.... Ezt is kalapálják évekig, mire valami használható lesz belőle. Majd jön a Rust. És mindenki el tudja képzelni itt is mi történik....
[szerk] Jah, és Rust, reszkess, mert jön az új megváltó!
"Sose a gép a hülye."
Nem kell reszketnie, mert elég más a célterülete. Ahogy egy másik nyelvnek sem kell.
Az se biztos, hogy nagy szeletet ki tud majd szakítani, de nagyon érdekes ötlet mentén indult el. Az biztos, hogy lesznek területek, ahol kedvelni fogják a használatát.
Ez rendszerintegrálási probléma.
Régóta tudjuk, hogy egy akár fejlettebb technológiára való átállás is komolyabb fennakadásokkal jár. Ez programnyelvfüggetlen.
Jonathan azzal kezdi, hogy amikor a projektet indították, a zfs nem tartott még itt (később a btrfs-t is említi), valmint azóta az nvme miatt is gyorsan párolog a megoldásuk előnye, jócskán esett a motiváció.
Én nem az az ember vagyok, aki mindent átírna, ami kész van, tesztelve van; de ez a történet nagyon nem a két programnyelv összehasonlításáról szól.
> it seems that some Rust people have lots of confidence that if something builds, it will run fine.
A következő sorokban írja, hogy futott is, csak neki kényelmetlen volt ez a megoldás, de lehet, hogy ez változni fog, ha jobban megismeri a Rustot. A relax dolgot én nem ismerem, lehet persze tök jogos is, hogy ez a megoldás nem szerencsés... de egy lényeges mondat van az előző bekezdés elején:
> dependencies for bcachefs-tools in Debian didn’t at all match the build requirements.
Ezen nem kell meglepődnünk, régi hagyománya van, a Debian nem kapkod minden komponens frissítésével (a biztonsági kérdések mellett gondolom, azért sem, mert ekkora függőségi gráfban ez nagyon nehéz), tehát aki mindenből a legújabb libeket használja, annak a csomagját nehéz lesz betenni. Rustban egyébként könnyű régebbi függőségeket használni, csak úgy kellett volna elkezdeni, vagy most várni kell kicsit. Vagy backportolni. Megoldások azért vannak (leginkább a fejlesztő kezében, a karbantartó gondjait megértem).
Szerintem akinek kell, csinálhat docker konténert is, ami statikusan buildeli a bcachefs-tools csomagot.
> not even considering some hostile emails that I recently received from the upstream developer or his public rants on lkml and reddit
Ismét nem programnyelv kérdése, hanem kommunikáció, együttműködés.
Nem, ez a Rust koncepcionális problémája. Az összes többi hájpolt nyelvvel nincs ilyen probléma, azoknál nem volt integrálási gond. (Lásd pl. Python, ott is agymenés a verziózás, de megoldható, simán tudsz 2.6-os és 3.3-as környezetet is telepíteni ugyanarra a gépre.)
Olvasd végig figyelmesen, mi okozza a problémát. Nem a nyelv maga, hanem a köré épített, átgondolatlan és bloated infrastruktúra és ökoszisztéma. Ez pedig a Rust sajátja.
Senki nem is lepődik meg rajta. Azon inkább, hogy a Rust az egyetlen, aminél ez egy leküzdhetetlen akadályt eredményez. (Engem mondjuk nem, korábban is mondtam már, hogy ebből baj lesz.)
Nem értek egyet. Az, hogy képtelenség a Rustafári közösséggel és a fejlesztőivel normálisan kommunikálni, nagyon is szerves része az alapproblémának. Arrogánsan azt várnák el, hogy a világ alkalmazkodjon hozzájuk, mert ők szarták a spanyolviaszt, hát így nem könnyű integrálni már meglévő rendszerekbe.
Többször felhoztam már érvként azt a Rust-al kapcsolatban, hogy baj lesz itt később, ha mondjuk 10 év múlva kell majd megismételni egy fordítást és nem fog menni. Utólag nagyon meg fogják szívni azok, akik most átállnak Rust-ra.
Mint most kiderült, ez már 1 év távlatában is súlyos problémákat okoz, nem is kell 10 évet várni hozzá (mégegyszer, a Rust ökoszisztémáról van itt szó, nem a nyelvről, és a docker sem megoldás, mert semmi garancia, hogy 10 év múlva működni fog-e a most generált konténer, volt már breaking change nem is egy).
Nem mennék bele különösebb adok-kapokba, egy dologra reagálnék:
Sokadszor látom ezt a „másik oldallal van a baj” alapbeállítást.
A Rust nyelv és ökoszisztéma fejlesztését nézve én eddig mindig komoly átgondoltságot láttam, nem érdemes pl. összemosni egy csomag fejlesztőjével, aki valószínűleg nem ugyanazokat a követelményeket támasztotta a saját projektjével szemben.
Nincs olyan, hogy „másik oldal” (Rustafari), a valóság ennél azért cizelláltabb.
Ezt ugye csak viccnek szántad? A Rust kapcsán hatalmas a hájp, és minden szakmai érvet megpróbálnak lehurrogni a Rustafárik. Kb. mint az Apple fanboyok, csak programozási nyelvben, józan ész és technikai érv mit sem számít nekik.
Gondolj bele abba, hogy még mindig nincs szabványos ABI-ja, iszonyatos szívás az .so, .dynlib, .dll illesztés, és ráadásul a borrow checker egyáltalán nem is szünteti meg a memleakeket, mint ahogy állították.
Pontosan az a baj, hogy nem érdemes, de mégis MUSZÁJ és kénytelen vagy, mert a cargo-t nem tudod megkerülni (vagy legalábbis nagyon nem éri meg megkerülni).
debianéknál az amúgy iS SLikertörténet volt mindig is...
Pontosan! Ez teljesen a fejlesztők hozzáállásán múlik csak.
Egyébként látjuk a Linux kernel kapcsán is, hogy a bcachefs-es fejlesztőkkel egyéb problémák is vannak.
Vannak itt olyanok? ;)
Hajbi! :) Nem hiszem, hogy a Te álláspontodat veszélyezteti a Rust. Lehet vele szépen, spórolósan dolgozni.
Nem is ez az alapvető baj vele.
Hanem hogy nem így dolgoznak vele és nem is szépen, spórolósan dolgozó fejlesztők dolgoznak vele, hanem vallási szektákat megszégyenítő influenszerként működő babzsákfejlesztők.
Ez sajnos azért nehéz helyzet, mert a projekt fejlesztőjének már átmosódott annyira az agya, hogy felüljön a Rust vonatra.
Azóta egyébként a drága már a Debian ellen kampányol.
Így kb. az egyetlen értelmes megoldás egy Debian-specifikus fork lenne, vagy a régebbi, még szét nem gányolt verzióra csak a C-s részek commitjait felrakni. Már ha ezek egyáltalán elválaszthatóak a Rust-osoktól.
Alapvetően teljesen igaza van az ő szemszögéből, illetve a Debiannak is a sajátjukból. Ez egy közös játék, de simán lehet, hogy a két világ úti egymást. A válaszokat is érdemes elolvasni.
Engem Eli valasza jobban felbasz, mint az eredeti level.
Alapvetoen nem arrol van szo, hogy a Debian userek nagy resze csak ugy l'art pour l'art "nem szeretne" uj szoftvereket hasznalni, hanem hogy a legtobb felhasznalasi modban (leszamitva a hobbi usereket) pont, hogy karos, ha adhoc modon beesnek az uj szoftverek.
Es igen, van a hobbi felhasznalas, aki nem akar Xboxot venni, mert az draga, helyette azzal szorakozik, hogy megvarja, amig valami update elkurja a rendszeret, es akkor lehet ujra reszelgetni rajta.
Jogos amit írsz, viszont a Debian bátran megteheti hogy ha nem tudja/akarja támogatni a Rust/Go/whatever nyelvet akkor ezt a csomagot kiveszi a támogatottak közül, és/vagy megy a régivel. Ekkor viszont ne a fejlesztőt keressék hogy mi miért nincs benne, meg a security bugok miért nincsenek javítva, ez innentől a debian és az azt használók feladata.
Ja tehát most már szegény™ fejlesztőt sajnáljuk, hogy alulról nyomja a seggét a babzsák, amikor válaszolni kell azokra a megkeresésekre, amik egyenes következményei, hogy trendbuziskodott.
A fejlesztés open source, a fejlesztő dönti el hogy mit és miben csinál meg. Ha ő Rust-ban akar alkotni, akkor abban fog, tekintve hogy sokan szereptévesztésben vannak: az open source nem jár. Az open source fejlesztő csinál valamit mert neki szüksége van egy funkcióra vagy pedig szakmailag kihívást érez és ennek eredményét megosztja a közösséggel. A közösségnek meg vagy tetszik, vagy nem. Mivel a közösség nem a munkáltatója, pénzt a fejlesztőnek nem ad, ezért joga sincs elvárásokat megfogalmazni.
Éppen ezért kezdtem el az open source mellett saját productot építeni. Ott majd a fizetős vendég rendelhet.
Ja igen, most jön az a típusú érvelés, hogy ha valaki kritikát fogalmaz meg, akkor "choosing beggar".
Senki nem vonta kétségbe a fejlesztői szabadságot, csupán kritikát fogalmaztak meg a fejlesztési irányelvekkel kapcsolatban.
Másik oldalon pedig Rust-trendi babzsákfejlesztőéknek sem jár az integráció a Debian-ba. Ahhoz olyan minőségű fejlesztést kell produkálni, hogy egy stable ágon megállja a helyét. Ez a kollégának sajnos nem sikerült, méghozzá a Rust-trendbuziskodásának köszönhetően.
mi is megfogalmazunk kritikat a kommentjeid miatt, megse fogadod meg. ennek ellenere a fejlesztotol meg elvarod...
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Helyesen: A fejlesztő elvárja, hogy bent legyen a csiligány Rust-újrafeltaláltkereke a Debianban.
Illetve elvárta, aztán beintettek neki, most meg játssza a sértődöttet és hergel a Debian ellen.
Ebben látod 100%-ig egyetértünk.
Így van, azért mondtam, hogy jelenkezzen valaki maintainernek. Le is forkolhatja, mert a projekt fejlesztője úgysem lesz hajlandó kiigazítani a kódját, hogy menjen az integráció.
Nem teljesen ertem a sztorit, magatol irodott at a kod Rustra? Gondolom ha szandekosan irtak volna at mas programnyelvre a toolt, akkor elore felmerik a lehetseges akadalyokat es elonyoket, majd ez alapjan hozzak meg a dontest, nem? Itt max olyat tudok elkepzelni, hogy egyik reggel arra ebredtek, hogy a chatgpt atirta a git repoban a cuccot.
Szerintem itt a határokkal van a gond. A tool fejlesztői úgy gondolták hogy jó ötlet átírni Rust-ba. Ezt a Debian nem képes/akarja/tudja lekövetni struktúrából adódóan. A srácot viszont állandóan megtalálják a Debian-osok hogy mi működik vagy mi nem működik Debian alatt. Azt gondolom, hogy alapvetően egyébként a fejlesztőnek van igaza.
Ha egy distró úgy gondolja hogy támogat egy alkalmazást akkor az ő feladatuk ezt megoldani hogy működjön és a támogatást is neki kell biztosítania. Ha a felhasználó a hivatalos (fejlesztő által készített) programot futtatja akkor pedig a fejlesztőt lehet keresni kérdések esetén.
Az hogy a Debian úgy döntött hogy ők támogatni fogják az újabb (rust alapú) verziókat is, az egyes egyedül az ő döntésük, és ennek biztosítása az ő feladatuk. Ha pedig ezt nem akarják, akkor forkolják le, és csinálják meg a fejlesztést amiben akarják.
Ööö, nem ez történt. Amikor a támogatás mellett döntöttek, még csak C volt, és csont nélkül ment is. Amióta bekerült a Rust, azóta csak szoptak, mint a torkosborz, ezért kevesebb, mint egy évvel később úgy döntöttek, megszüntetik a támogatást, erre fel a fejlesztő Rustafári módra elkezdett hőbörögni.
Megintcsak, ez miért lenne már a maintainer feladata? Nem az, és nem is kell, hogy az legyen. Ha nem akarják a feljesztő hülyeségeit tolerálni, akkor megszűnik a csomag támogatása és kész, pont, mint ahogy itt történt.
Én is ezt mondtam. A fejlesztőt valószínűleg nem érdekli a debian, nem akar vele foglalkozni. A Debian meg vagy leforkolja, átírja, akármi, vagy kivezeti.
De hát érdekli. Csak épp ahelyett, hogy kiigazítaná a kódját, inkább rágalomhadjáratba kezdett a debian ellen az lkml-en és reddit-en. Erre utaltam, mikor azt mondtam, hogy a Rustafárik arroganciája (a világ igazodjon őhozzájuk) is része az alapproblémának.
Rápillantottam a blogban emlegetett csomagfüggőségekre. Azért a fejlesztő bőven tudna mit kezdeni.
Vonatkozó xkcd. Amúgy még nem késő, ezek javítható dolgok. Csak a fejlesztőnél van a labda. Pont gondoltam, amit Eli is említett, a Cargoban természetesen lehet kérni minimumverziót csomagból.
Muszáj lesz a fejlesztőnek valamennyire integrációban is gondolkodni, persze ha nem akarja, hogy a cucca bekerüljön a Debianba és a Fedora-ba, akkor nem kell.
Egyébként az integrációt nagyon jó hogy mondod, egy csomó terméket el kellett utasítanunk mert nem tudott a céges rendszerekbe (pl. Entra ID) integrálódni, anélkül viszont nem fogjuk használni. Egy nagyon általános probléma hogy a fejlesztők olyan funkciókat raknak termékekbe, amit nem is oda kellene (az integráció miatt), és valahogy a nagy kép elveszik.
Egyébként ez általánosan egy probléma az IT-ban termékfejlesztésnél. Ha nincs jól felmérve a piac, nem tudjuk még a leendő ügyfeleink nevét se, nincs BA / SA, nincs sales / marketing stratégia, akkor ebbe könnyű belefutni.
Én dolgoztam olyan új termék bevezetésén, amelynél a leendő ügyfelekkel való beszélgetések során derültek ki olyan dolgok, amik miatt újra kellett írni / át kellett tervezni a termék bizonyos részeit. Az 5-10. ilyen módosítás után nagyon el tudta venni az ember kedvét, lelkesedését. Hiába volt agile / scrum, az nem segített az ilyen "pofonokon".
Mondjuk úgy, láttam már ilyet. Nem volt normális igényfelmérés, hiába volt szakmailag tényleg nagyon pöpecül összerakva a termék, ha egyszerűen nem fedte le a felhasználói igényeket.
De hát nem akar. Erre mondtam, hogy Az, hogy képtelenség a Rustafári közösséggel és a fejlesztőivel normálisan kommunikálni, nagyon is szerves része az alapproblémának. Arrogánsan azt várnák el, hogy a világ alkalmazkodjon hozzájuk, mert ők szarták a spanyolviaszt, hát így nem könnyű integrálni már meglévő rendszerekbe.
Nyilván megoldható lenne, ha a Rust-os fejlesztő nem lenne ennyire elszállva magától, bár azt, hogy a jövőben hogy fog működni, továbbra is kérdésesnek látom. Az, hogy a Debian csomagkezelőjétől és függőségeitől függetlenül is tartalmaz redundánsan csomagreferenciákat a Rust, továbbra is problémákat fog okozni a jövőben.
A Rust-os közösség előtt még mindíg ott a lehetőség, hogy nulláról (,,from scratch'') felépítsenek egy ,,UNIX-like'' jellegű rendszert, amelyben minden a saját izlésük alapján épül össze...
"Share what you know. Learn what you don't."
https://www.redox-os.org/
Tökéletes példa!
És ők is szopnak rendesen a Rust környezet miatt...
We download our dependencies from crates.io in every new make all run, but if the crates.io servers goes offline we can't continue our development.
Failed to build on archlinux via podman
Valamint a memsafety sincs, hiába lett Rust-ban írva:
If you press Ctrl+C in a running process of the terminal, RedoxFS crashes. (itt a tracelog-ból látszik, hogy kernel szintű crashről van szó.)
Na és persze a sebesség, ez ám a rapid-development-cycle: Hello World fordítás majdnem 2 perc (!)
uhm, amit irtal, egytol-egyig picsogas kategoria. ertem, valami gikszer volt, nem is feltetlen rust-tal, aztan megy az anyazas, hogy szar a rust.
ez kb. olyan, mint hogy kodolok linuxon, forditasi hiba, erre "szar a linux".
Na és persze a sebesség, ez ám a rapid-development-cycle: Hello World fordítás majdnem 2 perc (!)
Majdnem mint az FPGA :)
A fordításra visszatérve, lenne egy kérdésem.
Lehet az tudni -- és itt a Rust ökoszisztémát mélyebben ismerőkhöz fordulnék --, hogy a Rust -- a fordítás közben -- mennyire használja ki a gépben levő több magot/szálat ahhoz, hogy gyorsabb legyen a fordítás?
"Share what you know. Learn what you don't."
És a C vagy a Pascal?
A make igen jól használja a több CPU-t fordításhoz.
Gábriel Ákos
,,A make igen jól használja a több CPU-t fordításhoz.''
Ez rendben is lenne, de maguk a fordítóprogramok -- a make nélkül is -- miért nem használják ki jobban az említett erőforrásokat?
"Share what you know. Learn what you don't."
Mert egy processz felszabdalása nem triviális, de futás közben többet fogyaszt.
Elvileg kihasznalja maximalisan, annyi van, hogy te csak 'cargo build' -et irsz, a tobbi automatikusan tortenik.
A forditasi sebesseggel sose volt gond, inkabb az volt a gaz, hogy ugye a dependent crate-eket is leforditja elso build-nel, na az sokaig tud tartani.
A `cargo`-ban van egy olyan jellegű párhuzamosság, hogy egyszerre tudja fordítani az independent crate-eket, de ahogy ez a folyamat halad előre egyre kevésbé tud hatékony lenni, mert megjelennek a crate-dependenciák, és be kell várni a dependent crate-ek fordítását. Ezen van egy olyan optimalizáció, hogy a fordítási folyamat fel van bontva pipelineokra (parsing, type checking, ir generation, stb) így nem a dependent crate-ek teljes lefordítását kell megvárni, hanem csak az egyes stage-ekét.
Ezen felül magában a rustc-ben is van párhuzamosítás. Ezt kétfelé szokták venni, van a frontend (parsing, type checking, borrow checker, ir-genererator) meg a backend (llvm codegen) része a fordítónak. Ebből a backend az teljesen párhuzamos, a frontend a stableben még szekvenciális, de a nightlyban már ott van a parallel frontend experimental featureként, csak egyelőre még bugos.
Az első fordítás sokáig tart, mert mindent dependenciát lefordít, de utána a development profileban tud inkrementálisan fordítani, illetve ha fejlesztesz és csak az érdekel, hogy helyes-e a kódod, akkor tudsz codegen nélkül is fordítani.
Itt van pár timing, egy közepes méretű projektre (~15k sor, ~60 dependency, ~1000 crate) szekvenciális frontenddel, 24 magon. Elég jól látszik, hogy az inkrementális fordításnál nem nagyon tud mit párhuzamosítani. A teljesség kevéért beraktam a release profile-t is, ahol 18 másodperccel nő meg az általad tapasztalt fordítási idő, de közben a proci kétszer annyi melót végez, mint a dev profile esetében, mert többet optimalizál a codegen során.
Egyetértek, gáz. Nem is az, hogy valaki nem tud a kódjukkal mit kezdeni, de pont az egyik legnagyobb disztró csomagfenntartója, aki valószínű nem amatőr, ha az küszködik vele, a rust-osok magukba nézhetnének. Mert oké, a Debian nem érdekli őket, de azt kifelejtik, hogy nem csak hogy a legnagyobb disztró, de nagyon sok minden közvetlenül vagy közvetve (Ubuntu ágon át) rajtuk alapul. Egy profi rust-osnak most nagyon fel kéne lépni, és átvenni a Debian-csomag fejlesztését.
A rollingosok még bírják, Arch-on van a normál tárolókban bcachefs-tools, az AUR-ban meg szkript ami simán fordítja a bcachefs-tool-git-et, de még egy szinttől felfelé nekik is elegük lehet belőle.
Egyébként akármennyire is haragszok a Rust-ra, azt el kell ismerni, hogy még nem is a rust-osok legrosszabbak. Az AI/LLM-es barmok még náluk is sokkal meredekebbek, a GPU izzasztó mátrixaikkal, meg több gigás betanítós faszságokkal, copilot módjára összehányt kódokkal, torony magasan gázabb, mint a Rust valaha is lesz.
Meg sajnos C-s projekteknél is tapasztalható, hogy gurul el a fejlesztőknek a gyógyszer, most pl. az amdgpu driver környékén a 6.10-es Linux kernelben is volt egy csúcsa instabilitást, gafyást, újraindulást okozó beégés, ráadásul a 6.6-os LTS kernelbe is visszaportolták, és nem javították időben. Meg pl. Arch alatt a glibc-vel volt egy nagyon csúnya gikszer, az eredeti német csomagfenntartó lelépett a ’cibe, nem szólt senkinek, 1 év után vették észre, hogy nem volt új build a glibc-ből. Át is vette gyorsan ez az olasz Giancarlo gyerek, aki szintén gyakorlott csomagfenntartó, sok más csomagot is fenntart évek óta, de beletört a bicskája, olyan bonyolult volt a glibc patchelése, hogy végül 5-en kellettek hozzá, és 2 hétig szenvedtek egy topikban, mire meglett, hogy lefordult az összes szükséges patch-csel, pedig ez egy klasszik C projekt, nem C++, nem Java, nem Rust. Minden nyelven túl lehet tolni egy projektet rossz irányban, ez inkább a fejlesztőkön múlik, mint a nyelven.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Igen, itt a lehetőség, hogy ne csak a szájuk járjon. Kíváncsi leszek, lesz-e jelentkező.
Lehet, nekem még nem volt gondom ilyesmivel, különösebb gond nélkül sikerült elkerülni ezeket a csomagokat telepítésnél.
Ez nyilván gáz, de a Rust-os csomagot nemhogy időben, de sehogy sem javítják, inkább elárvult.
A glibc nem jó példa szerintem, mert az egy külön önálló állatfaj még a libc-k között is. Rengeteget szívok vele én is (főleg az idióta szimbólumverziózása miatt), de találtam már konkrétan implementációs hibát is benne.
Messze nem vagyuk ezzel egyedül, nem véletlenül álltak neki lefejleszteni a musl-t :-) És szerencsére egyre több distro áll át musl-ra.
Úgy érzem, hogy elszállt felettem az idő. Egy C package-nél ha előfordul valamilyen konfigurációs vagy fordítási hiba, akkor egyszerű kezelni a helyzetet. Pláne ha klasszikus GNU automake eszközökkel történik a konfig. De még a cmake sem olyen borzasztó. Ehelyett most jönnek a Rust-os csomagok, jó esetben clang-gal megfejelve. Számomra nem jól értelmezhetők a hibaüzenetek, nincs kedvem crate-ekkel babrálni. Aztán még külön öröm, ha egyik csomag egyik rust verzióra és clang-ra dependel, a másik meg másikra. Szóval érzem, hogy öregszem és eljön az az idő, amikor el kell majd engednem bizonyos dolgokat. Most még kitartok.
"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."
Nem ,,karbantarthatatlanná vált", hanem máshogy kellene karban tartani. Ez a másik topicban ki lett már fejtve.
Erre mondják, hogy a srác az egyik kezét a seggébe dugta, a másikkal meg írta a programot. ;)
Én megírnék egy CPU-t Rust-ban! :-D Sőt, tejeskávéhoz is jó!!! Jobb nyelv mint az eszperantó!
Úgy hallik, a Windows is magáévá fogja tenni. Ezzel lesz válasz az örök kérdésre: Miért?
Sajnos most csak ennyi jutott eszembe. :(
Ha a Rust kód lefordítható FPGA-ra. Na meg Javascript-ben is írtak már emulátorokat.
Miért? "Olcsóbb", mint (teljesen) microKernel architektúrára áttérni.
Ezt jól megaszondtad, vagyis nem mondtál semmit. ;) Bármi bármire lefordítható. Nem kellett i686 az AGC-hez sem, mert a logika és az algoritmus is megvalósítható bármivel. Elég volt hozzá elég kis számú NOR kapu, ami kb. 1 tranzisztor. Az "olcsóbb, mert nem microkernel", az nagyon kevés ahhoz, hogy bármi is optimális legyen. Szerintem assemblerben is meg lehet mindent írni és sokkal hatékonyabb. (Nem, nem a gyorsaság a szempont, mert ezt csak a hozzánemértők szajkózzák.)
Van olyan (bármilyen) feladat, ami kis- és nagynyomású pneumatikával vagy hidraulikával is megvalósítható. Akár egy számítógép is. Csak nem biztos, hogy optimális, pedig mikrokernel sincs benne. ;)
Te is jól megaszontad az elején :D Csak próbáltalak követni :D
Ha a Rust "Tejeskávéba is jó" az nyilvánvaló trollkodás, de az FPGA és a Javascript emulátor (sőt assembler fordító) az lehetséges. Én ís "írtam" már klaviatúra "drivert", ami egy EPROM-ból és egy csomó D flip-flopból állt. Hozzádugtad a géphez és tette a dolgát. Ehhez képest az FPGA nagyágyú, miért ne futna rajta bármi? Annyi igazságod vagyon, hogy normális ember nem tesz meg mégse bizonyos dolgokat. Még akkor sem, ha működne. Ilyen kis kedvencem a FREERTOS, ami bár működik, de a feladatok jó részéhez nem is kell OS.
Babzsákfotelben nevelkedett kezdő Rust huszárként a többi Rust huszárt kérdezném, már ha vannak itt, hogy milyen organikus szójalattéval érdemes követni ezt az állandó C-s herpderpet a tökéletes szórakozási élmény elérése érdekében?
Gluténmentes organic szója, barnacukor, a tetejére egy csipetnyi fair trade fahéj és kakaó. Én így kérem a Starbucksban, már nem is kérdeznek, ha meglátnak elkezdik gyártani.
Köszönöm! Egy kis fair trade kakaó ... tudtam, hogy valami hiányzik. A következő topicnál kipróbálom!
Saját fejésűvel.
A kókusztejet még csak értem, mert a kókusz elég nagy, lehet rajta fogást találni a fejéshez, de a szója az jóval kisebb... Bár ha azt nézem, rizstejet is hirdetnek - nem tudom a rizset hogyan fejik meg :-)
Ez egy cseles vicc volt. Rendes embernek a tej az fejéssel készül és tehén esetleg kecske tőgyét kell hozzá rángatni. Akik másból, máshogy csinálják és meg is isszák azok nem rendes emberek. ;)
Szerk: még egyszerűbben/falusiasan: B*sszátok meg a hülye tejeteket! ;D
Szerk2: ... meg a hülye programozási nyelveteket is. ;D
A "tej" fogalmát a magyar élelmiszerkönyv visszavezeti a 1308/2013/EU európai parlamenti és tanácsi rendelet) VII. melléklet IV. rész I. pont b) alpontja szerinti fogalomra, ami visszautal ugyanezen rendelkezés III. részére, ahol:
Piszkos Brüsszel.
A Magyar élelmiszerkönyv az EU csatlakozás előtt is nagyjából ezt a definíciót használta...
Régen se volt jobb semmi.
Ma már a kutyatej sem a régi.
"Normális ember már nem kommentel sehol." (c) Poli
:( Ne is mond, teljesen kiszáradt.
"nem tudom a rizset hogyan fejik meg" - nagyon pici fejőgéppel :)
Régóta vágyok én, az androidok mezonkincsére már!
Van organikus változat is, azt csak kézzel szabad fejni.
Azért legyél éber, lehet, hogy valahol már tervezik a következő mindenrejó csodaszert, mondjuk must (avagy grapejuice) néven.
Avokádólatte lesz az...
Gábriel Ákos
https://prog.hu/hirek/6746/linux-kernel-rust-integracio-ellenallas-mara…
megy a cicaharc :)
Én a hisztis™ C fejlesztőknek drukkolok. Az ilyen megélhetésiek pedig takarodjanak el a kernel közeléből.
-
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Off és teljesen naiv kérdés: Rust safety dolgait nem lehetne C-re alkalmazni? Annyi sanitizer meg static analyzer létezik, képtelenség vagy végtelen erőforrásigény lenne ezekből Rust szintű memory safetyt kicsikarni?
Az egyikben by design, a másikban meg kód- fordító- és környezetfüggően lesz meg az elvárt biztonság.
Pont ezért nem értem, ezt a fene nagy ellenállást C programozók részéről.
Memory safety-ről nem nyilatkozhatok. De a null safety-vel már találkoztam. Gondolom valami hasonló az elv. Null safety-nél a változó alapból nem lehet null. Megspórolod a null check-et, meg a hibakezelést, kevesebb kódot kell írnod, a kód is átláthatóbb. Maga a nyelv garantálja, hogy a változót, amikor fel akarod használni, akkor azon a ponton nem lehet null. Ráadásul mindezt fordítás időben nem futásidőben. Nem igazán látom a hátrányait, hogy miért ne akarná valaki használni.
Szubjektív: olvashatatlan a kód, olyan, mintha szándékosan minden szimbólumot és ASCII karaktert beleerőszakoltak volna. (De keress rá, nem vagyok egyedül ezzel)
Objektív: tetves lassú a fordítás, és lassú a fejlesztés. Nem tudod megkerülni az ellenőrzést, ezért a legapróbb módosítás után is órákat kell várni, míg lefordul, csak hogy kiderüljön, komplett refaktor szükséges a borrow checker miatt. Ahogy egy Rust fejlesztő megjegyezte: Programming in Rust is like being in an emotionally abusive relationship. Rust screams at you all day, every day.
C-nél simán működik az, hogy akkor kapcsolod be a sanitizert, meg tesztelsz valgrind-el, amikor jólesik, nem akasztja meg a rapid-development-cycle-t. Nem csipázom azt a hozzáállást, hogy csak mert akad pár faszkalap, aki nem teszteli a kódját, ezért szivassunk mindenkit az állandó és folytonos ellenőrzésekkel.
Csakhogy ez nem lehetséges. Mi van, ha a mutató egy adatfájlból ered? (Pl. ELF program header-ben a section table mutatója). Ez nem lehet fordítási időben ellenőrizni. Viszont tévesen azt hiszed, hogy a Rust fordító ezt az ellenőrzést megtette helyetted, úgyhogy lespórolod a futás idejű ellenőrzést, és máris kész a baj!
Értem, akkor ezek szerint nem az ötlet rossz, csak a megvalósítás. Ez egy valid érv.
Null safety-nél is van nullable változó. Ha kell használod. Csak nem mindegy, hogy minden esetben kell ezzel foglalkoznod, vagy csak ott ahol tényleg szükséges.
A Rust kód tényleg olvashatatlan (igaz nekem a C is).
Nem biztos, hogy maga az ötlet jó. A legtöbb panaszt azt hallom a Rust-al kapcsolatban, hogy a borrow checker mindig a lehető legrosszabkor kényszeríti a fejlesztőket a teljes refaktorra. Egy új prop bevezetése néha iszonyat mennyiségű munkát jelent, amitől meg a reviewerek mennek falnak. De ezt csak hallom, személyes tapasztalatom nincs.
Az személyes tapasztalat, hogy az agyonbonyolított nyelvtan (függvény a függvényben meg hasonlók), hogy mindig, minden libet újrafordít (a borrow checker miatt), no és az állandó kötelező ellenőrzések úgy általában rettenetesen belassítják a fordítást.
Itt elsősorban arra gondolok, hogy tele van halmozott kacsacsőrrel meg észre kell vegyél egy ' aposztrófot, no meg a !? egyszer a szimbólum után, néha meg a paraméterlista után, vagy hogy az _ speciális jelentéssel bír, ilyenek. Nem szimpi na.
Ezzel szemben a C-ben van egy maréknyi kulcsszó (mind angol szó, csak latin ábécé, semmi szimbólummizéria) meg egy tucat operátor és csókolom, ennyi az egész. A komplett nyelvtana simán elfér egy A4-esen. Extrém esetben 500 sornyi kódból kihozható egy C fordító, ami képes lefordítani önmagát (igaz, ebből elég sokminden hiányzik, de akkor is, nem semmi).
Maga a C nyelv nagyon nagyon pofon egyszerű (libc és precompiler nélkül) és nagyon jól olvasható kis gyakorlás után. Nem véletlen, hogy a legtöbb modern nyelv ezt vette alapul (D, C++, Java, JavaScript, PHP, Go, stb. de még a Rust is a C szintakszisból indul ki).
Engem meggyőztél. Mondjuk amúgy sem érdekel a nyelv.
Nekem nem úgy tűnt. A mostanival elégedett vagyok.
Nekem nem lenne vele szemben nagy ellenállásom, ha nem nyomnák ilyen gusztustalanul. A Rust-tal szerintem az a baj, hogy még egy kezdeti stádiumban lévő valami, de ahhoz képest túl agresszíven nyomják mindenkire, egyfajta szektaszerűen mindent ebben akarnak újraírni, újraíratni, mintha csak abban lehetne, meg feltüntetni sokkal kiforrottabb megoldásokról, hogy az szar, elavult, dobjuk ki, mert itt a Rust. Még mielőtt valaki azzal jönne, hogy a Rust is 9 éves nyelv, az igaz, így kimondva nem tűnik rövid időnek, de nagyobb, fontosabb projektekhez csak nemrég használják, az utóbbi pár évben, meg ha a 9 évet a Fortran 67 évével, a C 52 évével, vagy a C++ 39 évével vetjük össze, azért fiatal. Persze annyi helyzeti előnye van, hogy jelenleg a technológia gyorsabban mozog, több kódot írnak per év, mint 30-60 éve, vagy akár csak 10-20 éve, de a 9 év akkor is kevés. A kiforratlanságnak van egyfajta kaotikussága, pl. a Python gyorsan lett nagyon népszerű, ami később visszaütött, mikor a 3-as verzióra szinte teljesen áttervezték a nyelvet, hirtelen sok projekt ellehetetlenült. Túl fiatal projektben előfordulhatnak ilyenek, hogy még az irány nem teljesen világos, mert menet közben forrja ki magát az egész.
Jelenleg az egészet túltolják, mint a waylandesek a X11 elavultatását, még kész sincs a Wayland rendesen, mindig vannak hiányosságai, de sok fejlesztő és disztró már idő előtt el akarja erőszakkal avultatni az X-et. Ugyanaz a képlet, mint a Rust vs. C esetében, az X-nek van egy 30-40 éves előnye, sokkal több OS-t, display drivert, alkalmazást támogat, mint a Wayland, ráadásul sokkal jobban is van szabványosítva, mert a Wayland csak egy papíron létező protokoll, ahány implementáció, annyiféle megoldás és korlát, kicsit káosz, vadnyugat.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Azért ne túlozz. Ez így leírva hülyeség.
Ez szerintem minden nyelvre igaz. Minden nyelv fejlesztője a saját szekerét tolja, sőt verzióváltásnál is előjön, ahogy írtad Python 2 => 3-nál is megvolt. Tudom akkortájt Python-t használtam.
Ezt hívják fejlődésnek. Ez ellen lehet harcolni, csak nem érdemes. Az idő meg majd eldönti.
Kire nyomjak ra konkretan? Ram pl biztos nem.
Az igaz és sajnos baj, hogy a Rust körül kialakult egy indokolatlan fanboy-kultusz. És ennek hatására kialakult egy ellen-fanboy kultusz is.
A kettőben az a közös, hogy egyikük sem írt egy sor Rust kódot sem :)
Régóta vágyok én, az androidok mezonkincsére már!
Viszont a femboyok meg nagyon is irnak Rust kodokat...
Lasd ismert meme.
Teljesen igazad van, egyetlen dolgot javitanek:
Ennek az az oka, hogy tenyleg egy game-changer minden tekintetben, es tenyleg jobb. A security problemak tulnyomo tobbsege elo se fordulhat vele, ugyanakkor alig vagy semennyire se lassubb, mint a hasonlo c/c++ kod. Modern nyelvi elemek kerultek bele, mint trait, lambda, async/await, stdlib-je messze teljesebb es modernebb, egy modern package manager-rel (amit sokan szidnak, de a C vilag 'download+extract tarball' megoldasanal fenyevekkel jobb) es build rendszerrel (Makefile-tol mai napig hanyni tudnek neha, amit osszehack-elnek benne a dev-ek itt-ott - abszolut write-only).
Tul koran ugrottak ra sokan, az a fo gond. Pontosan ahogy irod, igazabol fordul es stabil, de az egesz masszivan beta meg. Ahogy a python3.0 es a 3.12 kozott is eg es fold a kulonbseg, vagy a java6 es 21 kozott, a rust elott is hasonlo palya all - nagyjabol kesz van, de ahogy a mondas szol, a feature-ok 80% -a megvan az ido 20% -aban, na ezt a pontot ertek el par eve a rust-ban, most a 'maradek 20%' -on dolgoznak. :)
Igazad van amugy, eroltetni semmit se jo otlet, de vesd ossze, mi tortenik valojaban: ifju titan tettre keszen ugrik egy erdekes projektre, tapasztalatot szerezni. Nyilvan nem egy 40 eves rendszert akar kitapasztalni, hanem egy sokkal jobb ujat. A 'regiek' meg nem. Ebbol borzaszto sok surlodas szarmazik, holott mindket oldal allaspontja teljesen valid es ertheto.
Ez opcionális, vagy kötelező használni?
Miért kell egy programozási nyelvbe package manager? (bármelyik nyelvbe)
disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.
Termeszetesen opcionalis, es nem a nyelv resze.
Mert sosem programozasi nyelvet hasznalsz, hanem egy *platformot*.
A programozasi nyelv az csak a language spec. Az meg forditani se fog neked.
Egy modern rendszerhez jon meg ugye a (kereszt)forditas, a lib-ek, 3rd party libek, dependency-kezeles, IDE, debug/remote debug, kulonbozo tesztek es reportok, es meg millionyi "apro bizbasz", amit eszre se veszel, de nelkule gondban lennel.
Ez az egesz a "platform". Bar gyakran nem veszik annak, de bizony a platform resze meg a support: official es stackoverflow, a training, a certificate-ek, a garantalt/megbizhato (security) javitasok, a kiszamithato update-ek.
Pontosan ez a compiler vs. platform az, ami miatt a linux/OSS sokaig (es ma is gyakran) nem rug labdaba a corporate piacon. Mert ott a full platform kell, egy fordito meg egy vim nem eleg.
Lehetni lehetne, de minek? A Rust memsafety-je egy parasztvakítás, valójában semmit sem ér (igazából még árt is, mert hamis biztonságérzetet kelt).
https://doc.rust-lang.org/book/ch15-06-reference-cycles.html
https://internals.rust-lang.org/t/a-new-memory-leak-example-with-channe…
https://www.deleaker.com/blog/2022/04/12/memory-leaks-in-rust/
https://klau.si/blog/testing-memory-leaks-in-rust/
https://users.rust-lang.org/t/detect-and-resolve-memory-leak/76105
https://onesignal.com/blog/solving-memory-leaks-in-rust/
...stb.
A megoldás egyébként pont az, amit C-nél már ősidők óta alkalmaznak: egy plusz ellenőrzést végző allokátor használata a beépített helyett a debug idejére.
https://github.com/lynnux/leak-detect-allocator
Valójában sokkal jobbak ezek, mint a Rust-é (egyszerűen azért, mert a rustc még új, tele van kijavítatlan bugokkal (jelen sorok írásakor kb. 10000 megoldatlan jegy), addig a C-s toolokat már évtizedek óta használják és alaposan ki lettek már tesztelve és reszelve).
Az egyik legjobb ilyen tool a valgrind: mindent tud, amit a Rust ellenőrzője, azonban nem lassítja feleslegesen a production-t, mert csak debug-kor használod (és nem függ semmiféle fordítótól se). Ez mondjuk nem static analyzer, futás közben végzi az ellenőrzést, és akár Rust kódot is tudsz vele ellenőrizni.
Ez nem igaz, hogy parasztvakítás lenne.
Először is a C-re létező megoldások egyike sem ad teljes fedést a memóriahibákra. A valgrind (és oldschool elődjei, mint pl eletricfence), futási időben akkor találják meg a hibát, ha a ráfutsz. Amennyire jók a teszteseteid, annyira fog hibákat találni. A statikus kódelemzők (mint coverity és hasonlók), leginkább mintákat keresnek (nyilván egyszerűsítés, elég kiterjedt elméleti háttere van), szintén nem tudnak teljes fedést adni. A runtime és a statikus analizátorok többé-kevésbé kiegészítik egymást, de mindkét esetben lehetnek fals negatívjaid és sokszor fals pozitívjaid id.
A C-ben egyszerűen nem jelölsz nyelvi szinten sok árnyalatbeli különbséget, amire a Rust-ban külön fogalom lett bevezetve (lásd borrow, mutable borrow, rc, refcell, weak reference stb. ezek C-ben mind ugyanolyan pointerek). Emiatt a statikus kódelemzőnek is sokkal kevesebb támpontja van, hogy az adott helyen mi volt a szándék.
A Rust az ígéri, hogy ugyanazt a memóriabiztonságot adja, amit a menedzselt memóriás programnyelvek, de ezt tudja runtime overhead-et jelentő háttérszolgáltatások (pl garbage collector) nélkül. És ezt lényegében hozza is. Lehet benne memory leak? Mint ahogy Java-ban is, pedig ott van GC. (igen, kicsit más a mechanizmus, ahogy előáll, de a nehézsúlyú menedzselt memóriás nyelvek sem tudják teljesen kizárni a lehetőségét.)
Régóta vágyok én, az androidok mezonkincsére már!
Ígéri, lényegében hozza is... vicces... :D
Azért lényegében, mert például a GC-nek az is egy szolgáltatása (nem minden programnyelv esetén, de pl Java-nál igen), hogy defragmentálja a memóriát. Ehhez objektumokat át kell tudni helyezni futási időben, a referenciákat valahogy útánhúzni. És lehetőség szerint mindezt egy külön szálon, nagy "stop-the-world" global lock nélkül.
Na ilyen nincs a Rust-ban. (Okkal, low-level rendszerprogramozásnál elég kellemetlen tud lenni, ha egy driver a hardverének egy meghatározott címére rak egy struct-ot, aztán a minden lébe kanál memory manager elrakja onnan) Sok kis random allokáció és felszabadítás után a page-ek úgy fognak kinézni, mint az ementálisajt. Ténylegesen nem leakel memóriát, de az oprendszernek nem fog tudni komplett page-eket visszaadni.
Régóta vágyok én, az androidok mezonkincsére már!
Igy van, sokan elfelejtik, hogy bizony java-ban minden tovabbi nelkul lehet OOM-et csinalni; sot, az egyik gyakori hiba production-ben pont az, hogy amikor egy 'elszabadult', Map-ben tarolt cache-tol kezd fogyni a memoria, akkor szegeny GC erolkodik, egyre nagyobb stop-the-world GC-pausokat csinal, ahogy mar masodpercenkent fut, az utolso 1% szabad memoriat probalva visszaszerezni folyamatosan.
A hiba meg pofon egyszeru, egy nem limitalt cache, vagy egy nem thread-safe tarolo okoz ilyeneket minden tovabbi nelkul. De elofordul ORM vagy json mapper -beli hiba is, ami hasonlot tud okozni. Vagy csak siman rosszul hasznalt hibernate, minden tovabbi nelkul. Globalis, vagy kvazi-globalis 'tarolok' is okozhatnak konnyen OOM-et, ha osszevissza hasznaljak (igen, ennek leteznie se kene, de gyakran osszefutni vele megis :D )
Ami nincs, az a use-after-free, out-of-bounds read, meg ugye az elfelejtett free().
A thread-safety-t szinten nem garantalja a java; vannak benne szinkronizacios primitivek, de amugy ugyanaz, mint a C.
Köszi, érdekesek. Igen, valgrindot használok és nagyon sok hibát ki tud szűrni. Memóriakezelési hibákra is hasznos de ami nekem különösen hasznos része, hogy deadlockokat is tud detektálni és írja ki és hol fogja a mutexet. Viszont csak ez a kettő magában szintén ad egyfajta hamis biztoságérzetet, mert a teszteseteidtől függ, előjön-e valami olyan leak, ami csak cornercase-ket érint. Legalább nem is ígérnek többet, ennyiből mindneképp korrektebb Rustnál.
Időközben találtam két projectet, https://xr0.dev/ és https://frama-c.com/, ez utóbbi elég fájdalmasan bloatednak néz ki, az xr0 meg nagyon kezdeti állapotban van. Mindenesetre nekem tetszene valami borrow checker-szerűség C-hez, ami mélységében felderíti a cornercaseket is. eBPF verifier valami hasonló, ott a kernel betöltési időben szól, ha dangling reference van, esetleg unsafe memory access vagy ehhez hasonlók. Sajnos ez csak kernelre korlátozódik és van egy 1 milliós utasítás limit is, végtelen ciklusokat elkerülendő.
A Rust deadlock es memoriaszivargas ellen deklaraltan nem nyujt garanciat (de az esszeru RAII-megoldas sokat segit, lasd pl. mutex guard-ja). Amire jol szamithatunk, az a dangling referencia, adatversenyhelyzet, invalid iterator (es azzal egyenerteku problemak) elkerulese.
Es igen, kell a nyelv hozza, pl. referenciak elettartamat jelolni kell sokszor.
Ez előbb jött szembe: https://safecpp.org/P3390R0.html
Ebben ránézésre elég sok meló van, persze kérdés lesz-e belőle valami. Úgy tűnik legtöbb safety feature-t sikerült átültetniük C++ba.
Tényleg komoly munkának tűnik.
A rust egy alapvetoen komoly piaci rest tomott be, ezert lett hirtelen nepszeru.
A gond az, hogy igazabol baromira nincs meg kesz, durva valtozasok vannak benne mai napig, es pl. a borrow checker-e is egyre jobb lett az evek alatt, ma mar kezd egesz hasznalhato lenni.
A mem safety alapvetoen nagyon jo dolog, abszolut game-changer; ezt semmi mas nem tudja. Hasonlitjak itt egyesek a mar letezo C malloc() replacement-ekhez, de ez sokkal tobbet tud annal: koveti, hogy melyik kod blokk az owner-je minden egyes allokacionak. Ez multi-threading eseten is hasznos, nem beszelve arrol, hogy rakenyszerit, hogy rendesen vegiggondold, mi hova tartozik a kododban; rendesen scope-olt kod hianya gyorsan megbosszulja magat rust-ban. Tehat egyfajta kodminoseg-javito is.
Ezen kivul a C alapvetoen baromira elavult, a rust tenylegesen erosen modernizalt nyelv, kb. kotlin-nal van egy szinten, csak rendszerprogramozashoz hasznalhato, nem app/backend-hez. Gondolok itt trait-ekre, lambda-kra, async/await-re, memory management-re, es meg millio dologra, ami egy modern nyelvben/platformban alap ma mar.
De, ahogy irtam, a legnagyobb gond, hogy tul koran tul sokan kezdtek hasznalni, mert egy hatalmas piaci rest tomott be, nagyon hianyzott; ha ugy tetszik, tul keson jott igy felkeszen is.
Aztan ebbol jon minden egyeb problema.
A debian package management-je meg erosen megkerdojelezheto; en pl. utalom, hogy a java/perl/python/... csomagokat ok kulon becsomagoljak, es 1 verzio erheto el az egesz rendszernek, mert egyik csomagkezelovel megaldott nyelvnel sem cel ez. Python-ban van ugye venv/..., java-ban fat jar, alapvetoen ez a modja a szoftver disztribucionak. Ez a debian-fele "az osszes app-hez ugyanazt a verzioju libet hasznaljuk" mar a C/C++ vilagban sem mukodott rendesen, ha emlekeztek; allando gond volt, hogy az patkolni kell a forrasokat, mert az egyiknek ilyen glib kell, a masiknak meg olyan.
java/python/rust -nal meg kevesbe mukodott ez. Mar a snap-et is kapasbol ugy irtak, hogy tobbfele verzioju lib-et tamogat, meg osszecsomagoltak a lib-eket a szoftverrel, a'la macos .app.
Igazabol ami kene a debian-ba, az az, hogy tamogasson multi-versioning-et csomagokra, es minden csomag arra a verziora dependelhetne, amire szuksege van. Ehelyett megy a nyigas, hogy "szar a rust". Nem a rust szar, a debian nem kovette az elmult evtized(ek) valtozasait.
Memory safety megoldható lett volna C-ben is, megfelelő toolkitekkel és programozási tudással.
A Rust pedig szar. Lehet, hogy azért szar, mert túl későn jött, félkészen, de ettől még szar úgy, ahogy most van. Akkor is, ha a koncepciója jó volt.
A Rust-nál viszont van egy még szarabb dolog: Amikor egyesek a fél világot Rust-ban akarják újraírni és szerintem ez veri ki a biztosítékot a legtöbb helyen, nem a Rust, meg a tisztán nulláról Rust-ban írt, nem invazív projektek létezése.
Ez az, amit fontos, hogy megerts: NEM, NEM LEHET. A rust nyelvi szinten oldja meg a memoria-kovetest, es pontosan tudja, koveti, hogy, melyik object mekkora es KI A TULAJDONOSA. Ezt C-ben egyszeruen nem tudod, mert ehhez kapasbol ugy kell tervezni a nyelvet, ugy kell irni a kodokat, ugy kell tervezni a lib-eket, API-kat.
A rust nem szar, tud rengeteg nyelvi szintu dolgot, ami durvan hianyzik a C-bol. NEKED nem tetszik, ertem, ettol meg nem lesz szar. Amugy meg jobb, ha hozzaszoksz, mert kozel s tavol nincs masik C alternativa, szoval a kozeli jovoben ez lesz a C replacement. Ha nem tetszik, akkor is, mert a tobbiek szerint meg jo es nekik tetszik.
A komplett OO-t kihagytak belole BTW, ami persze nem meglepo, a kotlin se eroltette mar; composition over inheritance es default public a manapsag divo iranyzat, ami remekul osszevag a C stilussal.
Az eroltetesrol annyit, hogy a masik ember szemszogebol meg te erolteted azt az 50 eves elavult C-t, strcpy() -vel meg malloc()-cal, amiben meg egy dinamikus array vagy string sincs alapbol. Maradjunk annyiban, hogy inkabb erzem eroltetesnek azt, aki szembemegy az arral.
https://xyproblem.info/
Nem is kell. Nem kell pontosan tudni, nem kell követni, nem kell tudni, ki a tulajdonos. Biztonságos kódot kell írni.
Ami nem feltétlenül szükséges.
Leírtam én is és leírták mások is, hogy miért szar és nem volt közte az, hogy azért, mert hajbazernek nem tetszik.
A Rust nem C alternatíva, csak a magadfajták szeretnék azzá erőltetni.
Az 50 egy szám. Ami lehet a kiforrottság, széleskörű kompatíbilitás, robusztusság mértékegysége is. A netfüggő Rust nem kifejezetten erről híres.
strncpy()-vel is lehet.
Azok jelenleg ti vagytok, amikor kerneleket akartok újraírni a szutykotokban.
Hint: amikor latvanyosan beskatulyazol embereket, eldontve helyettuk, hogy ok mit gondolnak, csak azt ered el, hogy teljesen elszigetelodsz, es mindenki ellenseg lesz.
A tobbit nem olvastam el, es reagalni sem fogok ra.
Hint: akinek nem inge, ne vegye magára. Ha valakire nem illik a definíció, amit írok, akkor nem is kell úgy érteni, hogy illik.
Amikor a Rust-influenszer először felszólít arra, hogy ne skatulyázzak embereket, és ne döntsem el helyettük, hogy ők mit gondolnak, mert akkor teljesen elszigetelődöm. Aztán közli, hogy ő nem is hajlandó a másik álláspontját még elolvasni sem. :D
A kettős mércéd vagy az álszentséged sikerült gyorsabban újraírni Rust-ban?
Az a gond, hogy itt a programnyelvet sokan (Te is) az alapján ítélik meg, hogy milyen fanboy- / ellenfanboy-kultusz van körülötte.
Az egész azzal kezdődött, hogy minden nyomorult biztonsági sebezhetőség alá elkezdték egyesek bekommentelni, hogy "újra kéne írni- / miért nincs még újraírva- / látjátok ezért kell újraírni Rustban". Állítom, hogy döntő többségük olyan ember volt, aki azelőtt egy hello world példát nem írt meg rustban.
Nyilván erre válaszként beindult a szatirikus vicc csinálás és az "újra kéne írni Rustban" már szándékosan ironikus poénforrás volt. Olyan emberektől, akik szintén egy sor kódot nem írtak rustban.
Én pl nem mondom, hogy mindent újra kell benne írni. Sőt, userspace-ben valószínűleg jobban jársz egy managed-memóriás nyelvvel. Ott ugye nem kell követned, hogy ki a tulajdonos, nem kell agytorzitó módon gondolkodni a borrow-checkhez.
Ugyanakkor (perverz érdeklődésből) el szoktam olvasni az egyes biztonsági sebezhetőségek részletes leírását. Azt gondolom van egy bizonyos képem arról, hogy sokszor milyen komplexitás van mögötte és mennyire nyakatekert corner-case-eket kell megtalálni és kihasználni. Pl a webp-ben volt pár hónapja olyan sebezhetőség, ami a huffman kódolás lehetséges hibáinak egy elméletileg is egészen különleges speciális esetét használta ki, hogy túlírhassa az elméletileg lehetséges legnagyobb méretű adatszerkezetre helyesen lefoglalt memóriát. Aki (whitehat) megtalálta ezt a hibát, egyáltalán azért állt neki reprodukálni, mert tudta, hogy élesben használják az exploitot rá, tehát _valahogy_ lehetségesnek kell lennie, hiába tűnik algoritmuselméletileg lehetetlennek. Ezek messze nem strcpy() vs. strncpy() bonyolultságú problémák. És ezt nagyon nem fogja meg semmi valgrind meg hasonló kód analizáló tool. Ennyit arról, hogy C-ben meg kell tanulni "helyesen kódolni".
Túl van már a szakma azon, hogy az igazán jó programozónak nem kell semmi védőháló.
Régóta vágyok én, az androidok mezonkincsére már!
Kell védőháló, de nem olyan áron, hogy bloated szutykokban mindent is újraírunk.
Például több whitehat és kódszintű biztonsági audit, az kell.
Egyrészt mit értesz bloated alatt?
Másrészt a kettő nem zárja ki egymást. Egyrészt a legjobb kódszintű biztonsági audit, ha a fordító kapásból megfogja a biztonsági hibák egy teljes osztályát. Másrészt biztonsági hiba nemcsak memóriakezelésből vagy szálkezelésből lehet, tehát bőven marad mit néznie a whitehat-eknek, csak egy hibaosztállyal kevesebb, amivel foglalkoznia kell.
Régóta vágyok én, az androidok mezonkincsére már!
Azt értem bloated alatt, ahogy a Rust ökoszisztéma ma fel van építve. Tehát, nem magát a nyelvet, hanem a csomagokat, libeket, csomagkezelőt (cargo), a függőségkezelést, a build-time letöltögetést stb. Meg azt, amikor a hosszú évekig optimalizált C kódot valamelyik half-stack babzsákfejlesztő újraírkálja egy erőforráspazarlóbb, átgondolatlanabb kóddá, mert úgy legalább memorysafe™.
Ok. Jó hogy felhoztad, a következő kérdésem pont a babzsákfejlesztő definíciója.
Mitől babzsákfejlesztő valaki?
(Már azon kívül, hogy babzsákon ül és fejleszt. Esetleg babzsákot fejleszt... :) ).
Régóta vágyok én, az androidok mezonkincsére már!
Az elődjeinél, kortársainál kedvezőbb körülményekbe belekényelmesedő, aktuális tech-divattrendeket feltétlen követő, half-stack fejlesztő, aki megélhetési alapon fejleszt, beleértve a karrierista, portfólióépítgető open-source fejlesztőket is, akik nem minden fejlesztésükért kapnak munkabért. Körülmények alatt értjük a bloat keretrendszereket, build környezeteket, IDE-ket, az 1 TB SSD-t, a 64 GB RAM-ot, a 13. generációs csiligány Intel processzort, a 4K monitort, a gigabites internetkapcsolatot, a legfrissebb OS és library verziókat és valamennyi olyan tényezőt, ami mások kárára teszi kényelmessé a fejlesztési munkát. A babzsákfejlesztés eredménye általában az, hogy a babzsákfejlesztő által megspórolt energia sokszorosát kell a felhasználóközönségnek megfizetnie az erőforráspocsékoló szoftvereknek, mint végeredménynek köszönhetően (megemelkedő villanyszámla, hosszabb futásidő, hamarabb újravásárolt hardverek stb.) amellett, hogy az egész folyamat gyorsítja az elavulást és fokozza a környezetszennyezést.
Köszönöm! Ezt akartam hallani. :)
Mert szerintem a rust pont hogy nem kényelmes. Azért, hogy futási időben ne legyen "erőforráspocsékoló" runtime a program alatt, azzal fizetsz, hogy bonyolult benne fejleszteni.
Régóta vágyok én, az androidok mezonkincsére már!
De igen, kényelmes, azok számára, akik nem képesek memorysafe kódot írni.
Ha nem képesek ilyen kódot írni, vajon képesek más szempontból is jól átgondolt kódot írni?
Ha a Rust implementáció bloat-abb lesz a C-snél, vajon észreveszik-e a csiligány, 13. generációs CPU-s, 1 TB SSD-s, 64 GB RAM-os erőművükön?
Akik nem képesek memorysafe kódot írni, azok rustban nem képesek olyan kódot írni, ami egyáltalán lefordul. :) Másrészt akinek a bloatság nem fontos, annak évtizedek óta rendelkezésre áll 100-féle managed memóriás, funkcionális és egyéb deklaratív paradigmákkal díszített, babzsákkényelmes programnyelv. Nem fogja magát Rusttal szívatni, aki nem olyan környezetbe fejleszt, ahol számít a low-level erőforrásgazdálkodás.
Régóta vágyok én, az androidok mezonkincsére már!
Nem is mondtam, hogy más memorysafe™ nyelven ne írnának bloat-ot. :P
> Ha nem képesek ilyen kódot írni, vajon képesek más szempontból is jól átgondolt kódot írni?
... itt viszont fontos tudni, hogy a Rust semmit nem csinál meg helyetted. Kb. a C++ shared_ptr<>-éhez hasonló bonyolultságú automatizmusok léteznek a standard libben, más nem. Ugyebár futtatókörnyezet nincs. GC nincs.
Viszont a korábbi programnyelvektől pontosabban tud hibát jelezni, szinte tanít programozni. HN-en többször olvastam, hogy C++-ban is okosabban dolgoznak, mióta megtanultak Rustban; magam is így érzem.
Ez valójában nem a fejlesztőn és a fejlesztő munkakörnyezetén múlik, hanem azon hogy van-e erre teszt?!
Van-e ilyesmi tesztre igény egyáltalán? Eszébe jut valakinek?
A szoftverminőség régóta többszereplős játék, messze nem kizárólag a fejlesztő feladata és felelőssége.
Gábriel Ákos
Ez valójában a fejlesztőn és a fejlesztő munkakörnyezetén is múlik, mivel a legtriviálisabb teszt a kód rögtönzött kipróbálása a fejlesztő által, még fejlesztés közben. Lehet ide Test-driven Development-et, meg mindenféle idealizmust erőltetni, de ha odaraksz egy 2. generációs Intelt a fejlesztő elé, akkor az általa elkészített végeredmény nagy valószínűséggel sokkal gyorsabb lesz, mintha egy 13. generációs csiligány szutykot raksz oda.
Van arra igény, hogy a szoftverek ne bloat-osodjanak el? Igen, a józan ész ezt diktálja és a felhasználóközönség se szeretné kidobni a gépét a bloat miatt, mivel az neki anyagilag nem érdeke. Az, hogy van-e rá teszt, attól függ, hogy a szoftvermultinak vagy a babzsákfejlesztőnek van-e erre igénye. Nekik pedig alapvetően semmire nincs igényük, a pénzen kívül. A pénz pedig akkor is jön, ha bloat-ot írnak, mert a felhasználónak nincs más választása, főleg proprietary szutykok esetén.
(Babzsák-téma): Messze egyetértek, hasonló dolgok miatt aggódok én is.
+ függőséget kialakító szolgáltatások, és még sorolhatnám.
En azt hittem a babzsakfejlesztok mindig a legujabb MacPro-n toljak Retina display-jel.
Is. És van hozzá pöpec hátizsákjuk is.
Mondjuk az az egy helyes döntés a Rust-ban, hogy az OO-t nem erőltették benne. Egyik kevés pozitívuma.
A másik pozitívuma a rust-osoknak, hogy nem félnek semmit újraírni. Ez sokszor szerencsétlen, de egyes esetekben hasznos is lehet akár. Sok olyan régi, mamutprojekt van, amiben szét van szaporodva a legacy kód, hack, karbantarthatatlan emiatt, újra kéne írni, de senki nem vállalkozik rá, de legalább jönnek a rust-osok, hogy bizonyítási vágyból megcsinálják.
Anno a bankok meg amerikai adószerbek is úgy ragadtak Cobolon, hogy egy szűk fejlesztői réteg egy spéci nyelvvel kisajátította ezt a területet, nem volt érdemi, egészséges konkurenciájuk, ezért olyan monopol helyzetet alakítottak ki ezen a területen, hogy senki nem bírja megtörni a mai napig, és jelentősen gátolja a fejlődést, lehet dinoszauruszok korabeli kódokkal szívni miatta, az összes ilyen kód időzített bomba, nem is az a kérdés, hogy felrobban-e, hanem mikor.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Áá, vannak a Rust-ban mindent újraírós babzsákfejlesztőknél is rosszabbak, Cobol-lal IBM mainframe-re fejlesztők, a mindent Windows alatt, .NET/C#-ban mindent formokkal baromolók, valamint a mindent JS-ben meg Elecronként megíró webdevek, Javások, a mindent Unity-ben összegányoló hipszterek, illetve náluk is sokkal rosszabbak az AI-sok, ami jelenleg az új legalja, napiszar színvonal most. A szabály itt is áll, hogy mindennél van rosszabb. Sajnos. Egyre nagyobb az Isten állatkertje, főleg manapság, mikor mindenhez ennyire könnyű a hozzáférés, a neten futótűzként terjednek trendek, mindenféle hülye beszállhat fejleszteni. 1000 féle hülyeséget találnak ki, mindegyikben megvan a potenciál, hogy masszív rajongói táborra találjon.
Amennyire minden megoldás egyre idiótább, vissza fogod te még sírni a Rust-ot, Gtk/Qt-t, ahogy jönnek helyettük a még sokkal szarabb megoldások. Hirtelen megszépül az emlékük. Emlékszem, hogy amíg nem volt Rust, addig mindenki a C++-t szidta, hogy átláthatatlan, minden bele lett dobálva a nyelvbe, mint a Fradi levesbe (funkcionális, aspektus orientált, stb. paradigmák,), meg hogy szar a garbage collection benne, aztán most hirtelen van nála rosszabb.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Van benne igazság jócskán... Sajnos az újabb generáció(k) (tisztelet a kivételnek) nem tudja, és sokszor nem is akarja(!) megtalálni a szerszámosládában a megfelelő méretű villáskulcsot vagy épp csavarhúzót, hanem azt használja, ami a kezébe akad, amit már használt korábban - mert "azt ismeri". De ha magunkba nézünk, azért bennünk is megvan ugyanez a hajlam... ("Ezt Perl-ben 10-20-30 éve is jól meg lehetett csinálni, akkor most is...")
A Perl nem jó, mert az már amúgy is ott van minden Unixos gépen, arra nem figyel fel senki, de ha Haskell-ben alkotsz valamit Ruby pluginokkal, lehetőleg mindenféle egzotikus függőséggel, akkor már van esélyed, hogy felfigyelnek rád, hogy 'micsoda májer!'
Az a figyelemhiányos baromállat, aki így gondolkodik, menjen inkább TikTok-influenszernek, valami semleges témában, ne szennyezze az open-source teret.
A leggyakrabban az ágy alá gurul, kerested már ott?
Nem kell a pszichiáterkártya huputeve, nem attól lesz (attól sem lesz) létjogosultsága a Rust-influenszer babzsákfejlesztőknek.
Ja. Babzsákfejlesztők. Meg a valóság:
https://security.googleblog.com/2024/09/deploying-rust-in-existing-firm…
A Perl nekem nem a kedvencem, a szintaxisa miatt, de az tetszik, hogy az 5-ös verziótól kezdve JIT-tel fordít, és emiatt nagyon jó a teljesítménye, azonos szintűnek érzem sok C kóddal. A Haskellel sincs sok bajom, két apróságot leszámítva 1) nem áll rá az agyam a funkcionális programozásra, 2) a compiler csomagja iszonyat nagy, és maga a fordító is rohadt lassan fordít, aki szereti a gyorsaságot, annak tarkón lövés lesz. A Ruby-ról meg nem tudtam soha eldönteni, hogy mire jó, ahogy elnézem, mások se, nem is nagyon írnak benne semmit, hála az égnek.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
A Cobol-ról - eltekintve attól, hogy szószátyár - csak jót hallottam.
A Rust rengeteg dolgot tud, amit épeszű ember nem is akar megoldani. A C meg struktúrált assembler. Az a szoftveres kolléga, aki minden nyelven IS tud programozni, C-ben gyenge kezdő szintet üt meg. Hja, van aki a józan valóság helyett csak absztrakcióban képes gondolkodni.
Kedvencem, amikor a 2500 java osztály sima liba, de a 35-80 assembler utasítás megtanulása mission impossible. Bár az előbbi tudás alapján az ilyenek gyakran pontatlanul és trehámyul programoznak. Tehát szó sincs a 2500 osztály akár felületes ismeretéről sem. Ennek alapján a Rust egy abszolút használhatatlan nyelv lehet - akárcsak egyeseknek az assembler - mert olyanokat is meg lehet (kell) oldani vele, amit "eddig nem szoktunk".
Valójában aki Rust-ban képes szépen és jól megoldani egy feladatot, az olyan kölrültekintő lehet, hogy akár C/C++-ban is menne neki. :-D
Azért hogy kinek mikor mitől korpásodik a haja - attól is függ, hogy mennyire van megfizetve, meg mit tekint feladatának. Arról nem is beszélve, hogy felelősen ki mihez hajlandó hozzányúlni.
Egyébként ja. :)
Ne hallgassál róla, nézz meg egy netes Cobol kurzust, vagy olvass el egy alap könyvet róla. Agyrém. Nem csak az, hogy nagybetűsen ki kell írni minden hülyeséget, a logikája is olyan, hogy kb. nincs is neki, csak mindenféle konvenció egymás hátára dobva, az egésznek se feneke, se alja. Garantálom, hogy 5-10 perc múlva felmegy tőle a vérnyomásod.
Az utolsó részében igazad van, aki jó fejlesztő, az bármilyen nyelven tud normális dolgot írni, és fordítva is igaz, hogy aki kókler, az minden nyelven csak gányolni fog, teljesen mindegy, hogy mit adsz a kezébe.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
A vérnyomásom enélkül is magas. ;)
Hát ez van, egy újszülöttnek minden vicc új. Azért a nagybetű, mert olyan régi, hogy akkor még tényleg 7 bites ASCCI volt a divi. Én, mint assembler programozó (40 év) és aki FORTRAN és ALGOL nyelveken nevelkedett, semmi érdekeset nem látok benne. Egy precíz, deklaratív nyelv. Valószínűleg nem lehet olyan trehány programot írni benne, mint pl. a java és tsaiban.
Régen mindig egy kicsit a hardvert is programoztad. Pl. fpu nélkül lényeges know-how volt, hogy 1/3 helyett 0,333333.. értéket használj, mert az gyorsabb. (Pl. Odra 1204) Hasonló okkal keletkezett a TurboBCD, ami a tizes aritmetkát használta a pontosabb számításokhoz. Az első assembler, amivel dolgoztam, szintén nagybetűs volt, max. 6 betűs neveket engedett meg, amiből csak öt betűt használt. ;) Ennek ellenére korrekt macroassembler volt, nem olyan, amit manapság a C++/java huszárok írnak.
Szóval kalkuláld bele, hogy régen minden szarabb volt.
A hülyeség teljesen technológiafüggetlen. Konkrétumok és tényekkel alátámasztott higgadt vélemények helyett csak a hiedelmek, hallomások, félelmek és úgy egyáltalán a frusztráció ömlik.
Seniorként, architectként az a dolgunk/dolgom/felelősségem hogy egy adott helyzetben és környezetben a lehetőségekhez képest élhető megoldásokat hozzak ki - azokkal együtt akik éppen akkor ott vannak.
Gábriel Ákos
Sőt, C++ fejlesztők között is van nagyon hülye. Példának okáért a Hyperland fejlesztője, aki elkezdte a legújabb verziót C++26-ra dependelni, igaz, hogy még a C++23-at se támogatják rendesen a fordítók, de neki már most 2024-ben a 2026-os szabvány kötelező, így csak gcc 14+ meg clang 18+ verzióval fordul, ezzel ki is zárta a disztrók 95%-át a fordításból, csomagkarbantartásból, hiszen a többség csak régebbi gcc/clang-verziónál tart. Most erre büszke, hogy a 26-tal milyen májer, már távcső nélkül is mindenki látja, hogy ő a legény a gáton. Erre áll fel neki, hogy ettől ő milyen különleges lesz, az IT/FOSS média meg le is cikkezi vezető hírnek, hogy adják alá a lovat. Semmivel nem különb, mint a Raszt Putyinok.
Mondjuk ezeket a nyelvi bizottságokat se értem, hogy mit akarnak ezekkel az új nyelvi szabványokkal, olyan gyorsan jönnek ezek, hogy a fordítók és a fejlesztők nem bírják lekövetni. Pl. Fortranból is van 2023-as szabvány, de még a 2018-asat se támogatja teljesen egy fordító se, és a legújabb, amit a fejlesztők használnak, az a 2003-as változat, de a legnagyobb részük nekik is még még Fortran90-95-öt használ a visszafelé kompatibilitás miatt.
Másik példa rá a Cobol, aminek van szabványkiegészítése 2002, 2014, 2023-ból is, hogy lehessen verni a cicit, hogy a nagyobb szám jobb, közben meg aki még Cobolt használ, az valami régi verzión van, mert ősrégi mainframe kódot kalapál. Úgy néz ki, hogy ennek is divatja van, remélem a Basicből is szabványosítanak egy 2029-es verziót, hogy aktualizálják, kell, mint egy falat kenyér.
Még a jó öreg C-ből is tök felesleges volt a C11, C17, C23, a legtöbb projekt C89-C99-en van kompatibilitási okokból. A lényeg, hogy a nagyobb verzió az menő, ki lehet tenni bekeretezve a falra.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Mondjuk néha bölcsebb lenne, ha hallgatnál olyan témában, amihez bevallottan nem értesz.
Tudom, én nem értek hozzá. Majd a 2037-es szabványkiegészítés felnyitja a szemem. Addig is lesz pár hülye, aki mindent abban ír, mert az cool. Én egyébként nem is ítélem el, aki használ új szabványokat, próbál haladni a korral, kipróbálja pl. benne a lehetőségeket egy gyakorló projekttel, stb.. Itt a gond azon van, hogy élesben fejlesztők erőltetik vagánykodásból, olyan kódnál, aminél inkább kompatibilitásra kéne törekedni, hiszen mindenhol kéne működnie, lefordulnia.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Loop.
Kimaradt a NoSQL mindenre is jo.
A másik véglet meg hogy mindent erőltessünk bele SQL-be.
Gábriel Ákos
Éppen itt esik el a koncepciód, hogy programozói tudást feltételez.
Gábriel Ákos
Nem értek hozzá, csak szembejött a cikk, és idevág:
A Google szerint nem olyan nehéz a C/C++ kódok Rustra cserélése
A keresőóriás még aktívabban áll be a memóriabiztos nyelv mögé, miközben más oldalakon inkább ellenállás érezhető.
A memóriakezeléssel összefüggő biztonsági sérülékenységek csökkentése érdekében a Google még aktívabban támogatja a Rust használatát az alacsonyszintű firmware-ek kódjaihoz. A keresőóriás két szoftvermérnöke, Ivan Lozano és Dominik Maier a napokban osztották meg tapasztalataikat egy dokumentációban, amiben arra jutottak, hogy a korábban C és C++-ben írt legacy firmware kódokról viszonylag gyorsan és hatékonyan lehet fokozatosan átállni Rustra.
vs.
Nem mindegy mit mire hasznalsz.
A kérdés nem is ez volt, hanem hogy az újraírt kód mennyire marad karbantartható. Mint látjuk, hiába lehet gyorsan átírni, ha a végeredmény nem menedzselhető és egy-két éven belül fordíthatatlanná válik.
Ezt már számtalanszor leírtam, de leírom ismét: egy C-ben írt kód 20 év múltán is garantáltan simán lefordítható marad, míg a Rust pár év után már kuka (lásd bcachefs-tools). Ez az, amit a babzsákfotelhuszárok elhallgatnak, és ami miatt iszonyatosat fognak szívni 5-10 éven belül a cégek és a feljhasználóik.
És ez a Rust hibája, vagy a cargoé?
Ha a cargo tényleg beránt mindenféle external bináris baromságot az eléggé tré megoldás.
Mentségükre szolgáljon hogy enterspájz babzsákfejlesztőék általában konténerekbe dolgoznak (minimum docker de inkább kubernetes) ott meg kvázi mindegy mit lapátol össze a cargo, elférnek egymás mellett. Több diszket igényel, több memóriát eszik, igaz.
Gábriel Ákos
Nahát, @gabrielakos TROLL uraság elfelejtett nick-et váltani, miközben magának válaszolgatott, LOL :-D :-D :-D
Csakhogy a docker meg a kurbenetes ugyanolyan babzsákfejlesztő tákolmány, azoknál is épp úgy, folyamatosan törik minden. Egy 5 évvel ezelőtt elkészített image-t nem tudsz gond nélkül futtatni a legfrissebb dockerrel, ott vagy, ahol a part szakad.
(Keress csak arra, hogy "docker backward compatibility problem", rengeteg találat lesz.)
Hogy micsoda?
Nem csoda, lebukott.
https://hup.hu/comment/3112593#comment-3112593
https://hup.hu/comment/3112484#comment-3112484
https://hup.hu/comment/3112556#comment-3112556
Mind gabrielakos ugyanazon témában adott válaszai, egymásnak ellentmondó véleményekkel. Utolsónál meg egész konkrétan a saját posztjára válaszolt.
Mi a baj azzal, hogy valami eszébe jutott másnap, és hozzáírta egy új kommentben?
"Csakhogy a docker meg a kurbenetes ugyanolyan babzsákfejlesztő tákolmány, azoknál is épp úgy, folyamatosan törik minden. Egy 5 évvel ezelőtt elkészített image-t nem tudsz gond nélkül futtatni a legfrissebb dockerrel, ott vagy, ahol a part szakad.
(Keress csak arra, hogy "docker backward compatibility problem", rengeteg találat lesz.)"
Gondolom ezt olvastad valahol a neten es most hasznalod kardozni mert jobbat nem tudsz.
Nalunk viszont 2018-ban buildelt imagek (1.13-as K8S-t hasznaltunk akkoriban) koszonik szepen jelenleg is futnak 1.30-as K8S-en 2024-ben :)
Nyilván az akkor készített image jó marad, míg fel nem merül, hogy valamit módosítani kell benne, tehát újra kellene buildelni... Na jó, de akkor frissítsünk benne mást is, vagy maradjunk a 2018-óta teljesen megszűnt és internetről is letörölt Linux-disztribúciónál?
Amire en valaszoltam aszerint az allitas szerint a valtozatlan kontener nem fog futni ujabb docker verzion, erre reflektaltam mivel ez nem igaz.
Az ujrabuildelessel kapcsolatos problemaknak amirol te beszelsz semmi koze se a K8S-hez, se a a dockerhez. Az egy teljesen mas problema hogy egy 2018-as distronal elofordulhat hogy mar a reposzerverek se elnek.
Az kb csak szerencse kérdése (egy hosszú életciklusú projekt felhasználása során), hogy te épp abban az időszakban használod, amikor nem vezetnek be kompatibilitás törő változtatásokat. :-P
Amennyire tudom, nem external bináris dolgokat ránt le, hanem forrást. De csak érintőlegesen foglalkoztam vele, meg használok Rust alapú programot, amit én fordítottam cargoval, szóval tévedhetek. Egy Rust programban meg lehet adni különféle függőségeket, és ha cargoval fordítasz, akkor ezeket is letölti, fordítja (mint a BSD ports Macports, vagy a gentoo). Én úgy érzem, a probléma itt az, hogy a szükséges források verziószáma nem elég szűk (ezt külön meg lehet adni), és ha csak meg van említve, hogy X lib kell, akkor lehet, hogy mire a következő fordítási menet jön, akkor már másik verzió az aktuális.
De majd jön valaki és helyretesz (remélem).
Mivel eléggé egybe van vasalva a kettő, ezért nincs értelme a kérdésnek. Cargo nélkül szinte lehetetlen Rust-ot használni.
Amit amúgy eléggé f@sság a Rust-ra kenni.
Olyan mintha a make hülyesége miatt a C-t szidnád.
Build környezet lecserélésben a Java jeleskedett (utálom is érte), volt ugye először a nagy büdös semmi (make) aztán ant aztán mvn és gradle.
Egyiknek a hülyeségének sincs köze a Java-hoz.
Egyszer majd valaki megunja a cargo-t és csinál helyette jobbat.
Gábriel Ákos
fordítható vagy linkelhető (buildelhető) ?
ha a library-k (api-k) lecserélődnek akármilyen kód körül (lehet az c, java, bármi) akkor ugyanúgy nem fog buildelni.
ahogy egy libssl1-hez írt c kód se fog buildelni ubuntu 24-en (mert már csak libssl2 van)
vagy egy java8-ban írt jaxb-s cucc se fog buildelni java17-tel és jakarta-val (oké az már compile-olni se fog)
Gábriel Ákos
ugyanígy próbálj már lszi egy 20 éves motif-os játékot buildelni mai linuxon... :)
Gábriel Ákos
Nahát, @gabrielakos TROLL uraság elfelejtett nick-et váltani, miközben magának válaszolgatott, LOL :-D :-D :-D
Egyik sem. A nyelv is folyamatosan változik, meg a csomagjai is.
Ezt benézted, mert ilyent konkrétan csináltam. 15 évvel korábban írt C kódom simán fordul (egyedül az XF86VidModeSwitchToMode-ot kellett kikommenteznem, mert XOrg alatt olyan nincs, minden más csont nélkül ment).
Nemcsak a fordító és a libek frissítését élte túl simán, de egyetlen dolgot leszámítva még azt is, hogy komplett lecserélték az X11-et egy tök másik szerver implementációra alatta.
>egyedül az XF86VidModeSwitchToMode-ot kellett kikommenteznem, mert XOrg alatt olyan nincs, minden más csont nélkül ment
De a Rustos csávó is pont ezt mondaná, hogy egyedül ezt vagy azt kellett átírni, mert egy libet lecseréltek alatta. Ha át kellett írni, akkor nem fordult változtatás és csont nélkül.
Mondani mondhatja, de akkor se lesz igaza. Az az egyetlen egy általam használt függvény egy nem dokumentált, nem X11 szabványos, kifejezetten XFree86-os tákolás volt eleve. Ha anno nem írom bele, akkor most ki se kellett volna kommenteznem, és módosítás nélkül fordulna minden más.
De akkor legyen másik példa: xbill, eredetileg 1994-ben írták, utolsó update 1998-as, és még mindig csont nélkül fordul a legújabb környezetekben is. (Ne keverd össze a Java-s porttal, mert az is van belőle.)
Jaja, vagy egy eredetileg 32 bitre írt programot fordíts le 64 biten és próbáld futtatni. Mekkora esélyed van hogy nem lesz segmentation fault benne?
Pont a C _mellett_ jönni ezzel az érvvel extrán nevetséges.
Elég jó. Mind az általam említett projekt, mind az xbill eredetileg 32 bitre íródott, mégis csont nélkül fordul 64 bitre, és hiba nélkül futnak is. De kismillió egyéb példát is tudok, lásd pl. USBImager, mind a mai napig fordítom ugyanazt a kódot 32 bitre és 64 bitre is.
Ha lenne egy csipetnyi C tapasztalatod, akkor tudnád, hogy itt most csak saját magad járattad le. Nem kicsit, nagyon.
Léteznek kódok, amiket eleve jól írtak meg úgy, hogy minden architektúrán egyformán jól működjenek. De ilyet csinálni külön erőfeszítés, és a C szabványa pont nem segít ebben. Egész könyvnyi anyagok szólnak arról, hogy milyen nem definiált, illetve platformfüggő működéseket lehet előcsalni a C nyelvből úgy, hogy látszólag tökéletes a programunk. Javaslom a MISRA-C standard olvasgatását, ami erről szól.
Minden egyes posztod újabb ékes bizonyíték arra, hogy nem is értesz a C-hez, csak fikázni próbálsz.
Hazugság. (Mondom én, aki aktívan több tucat multiplatform C projektet visz jelenleg is).
A C nyelvből semmilyet. Az mind a libekre (főként a libc-re) vonatkozik, és ráadásul mindet pikk-pakk kiszúrják a modern fordítókba épített UBSAN ellenőrzések. Csak egy kapcsoló.
Mondom én, egyáltalán nem is ismered és nem is értesz a C-hez. De hogy gyakorlati tapasztalatod nulla vele, az egészen biztos.
De azt azért jól sejtem ugye, hogy a multiplatform C projektjeidnél bizony a külső build rendszer varázsolja meg, hogy a compiler flagek (amik a nyelv specifikációban rögzítetlen dolgokat fixálják le valamilyen konkrét viselkedésre) és a típusokat felüldefiniáló #define-ok pont jók legyenek az adott architekturán?!
Régóta vágyok én, az androidok mezonkincsére már!
google ilyeneket talál:
https://forum.index.hu/Article/showArticle?t=9171087
Alapvetően a
stdint.h-t kell használni, és máris szembenézhetünk azintptr_tésuintptr_ttípusokkal. (Jó, a Windows-on minden úgy szar, ahogy van, de ezt tudtuk eddig is. (Pl. Unixban/C-szabványban printf-nél%d, %ld, %lldjelentéseint, long, long long; Windows-ban%d, %I32d, %I64dvagy valami hasonló jóság használatos erre.))A printf-re az inttypes.h konstansait kell használni és akkor platformfüggetlen lesz. Lásd: https://pubs.opengroup.org/onlinepubs/009695399/basedefs/inttypes.h.html
Vagy még szerencsésebb, ha elengedjük az egész Wintendót.
És akkor eszembe jut a DOS-os világ amikor Turbo C-ben near, far és huge pointerekkel kellett telecseszni a C programodat... És valami olyasmi is volt, hogy figyelni kellett, hogy az adatpointer és a függvénypointer esetén nem egyformán működött ez a near/far/huge dolog. Az tanulságos történet volt a "hordozható" C-ről :)
Régóta vágyok én, az androidok mezonkincsére már!
Leülhetsz, elégtelen.
Általában nem számít, hogy 32 vagy 64 bitre fordítod a programot, ugyanabból a forrásból ugyanúgy fog működni mindkettőn. Még a sizeof(int) is csak 4 byte x86_64-en, mint 32-biten.
Szerk. : rosszul emlékeztem, újra kell írnom.
Az int specifikáció szerint legalább 2 bájtos. avrgcc-n például a mai napig 2, mert ott túl költséges volna mindent 4 bájton tárolni. Előjeles módban nem specifikált az overflow megvalósítása.
A long gcc -m32-ben 32 bites, -m64 módban 64 bites.
A struktúrák alignmentje és a pointerek mérete is eltér. Ha például a kóder int-be tárolt pointert, akkor abból baj lesz. Hasonlóan a struktúrák bináris fájlba írása bajt okozhat.
A Microsoft szerintem jobban döntött mint a gcc: az ő compilerükben az integer típusok mérete megmaradt 64 bitre váltáskor. Nyilván a pointerek nem.
Minden egyes posztod újabb ékes bizonyíték arra, hogy nem is értesz a C-hez, csak fikázni próbálsz.
Szól érte a fordító, hibát jelez és nem engedi. Nincs itt semmiféle baj.
stdint.h
Nem is a gcc döntött. A SysV betartotta a C szabványt, a Microsoft meg szart a szabványra. Egyébként meg a gcc-nek megadható, hogy LLP64-et használjon, ellenben az MSVC-vel nemigen lehet semmi másra fordítani.
De ha olyan C kódot akarsz írni, aminek tökmindegy a címzési modell, az sem probléma, intptr_t.
Persze, lehet szarul használni a C-t, de a Rust-ot is! Minden nyelven lehet gányolni és szar kódot írni, ezzel semmi újat nem mondtál.
> A Microsoft szerintem jobban döntött mint a gcc: az ő compilerükben az integer típusok mérete megmaradt 64 bitre váltáskor.
Kivéve a WPARAM, LPARAM, LRESULT tipusokat, azok 64-bitesek.
Hasonlóan a struktúrák bináris fájlba írása bajt okozhat.
Persze, ha szarul csinálod. Mondok egy újat: ez esetben a big endian és little endian platformok közt se lesz hordozható a fájlod, nem csak 32 meg 64 bites binárisok közt.
Amiről beszélsz az nem a nyelv stabilitása hanem a használt api-k stabilitása továbbra is.
Nem véletlenül felejtettél el válaszolni a libssl1 vs libssl2 felvetésemre.
A 20 évvel ezelőtti FizzBuzz implementációm ugyanúgy fordul és buildel ma is:
- pascalban
- c-ben
- pythonban
- javaban
Ha a legalapabb dolgokat használod csak egy környezetből annak nem kunszt száz évvel később is fordulni és futni.
Ha egy tavalyi Rust-ban implementált FizzBuzz ma nem fordul le, na az gáz. (nem tudom, nem ismerem egyáltalán)
C-ben meg ugye a "legalapabb" dolgokon kívül nincs más nyelvi elem.
Gábriel Ákos
Én épp a Rust bevezetőt olvasom (ezen topik újra fellelkesített), 2021-es és még működik. Az ígéretük az, hogy örökre működni fog, majd meglátjuk mi lesz belőle.
Ehhez "csak" annyi kell hogy a test-suite-ból sose töröljenek - a babzsákfejlesztők, ugye.
Gábriel Ákos
Azért nem válaszoltam, mert hülyeséget kérdeztél. Benézted a nevek hasonlóságát, valójában a libssl1 és libssl2 két külön, egymástól független függőség.
Nem néztem bele a bcachefs-tools forrásába, de nem tartom túl valószínűnek, hogy egy parancssoros toolnak alap dolgokon kívül nagyon használnia kellene bármit is. Ha meg egy egyszerű parancssoros toolhoz is nem-alap csomagokra van szükség, akkor az megint iszonyat gáz. Ennek ellenére mégsem fordítható le Debian alatt a pár éves Rust kód, ezért árvult el a csomag.
Tehát kijelenthetjük, hogy létezik legalább egy olyan Rust-ban írt parancssoros tool, ami nemhogy 100, de már 3 évvel később sem karbantartható. És nem is ez az egyedüli példa, akad még bőven:
- I hit a compile error with old Rust code (csak lezárták, nem is lett javítva)
- Help, can't compile project from Feb 2022
- Error Compiling Old Rust project
- As of now I am using Rust 1.29.00 but I am facing some compilation issues and it seems this problem can be resolve with.
- Cant make, using old version of Rust and nothing will work to use the new version (1.72.1)
- Error while compiling a rust file generated by c2rust (ok: nyelvi inkompatibilitás Rust verziók között)
...stb.
Ez messze nem egy teljes lista, csak egy gyors merítés, ráadásul az ilyen jellegű problémák száma drasztikusan nő.
Nézd meg jobban...
Ha van egy programunk ami még libssl1 idején készült akkor azt hogyan fordítod/buildeled le egy olyan rendszeren amire alapból nem kerül fel a libssl1 csak a libssl2 ?
Gábriel Ákos
Nyilvánvalóan úgy, hogy felteszed, csak ismételni tudom magam: "a libssl1 és libssl2 két külön, egymástól független függőség."
Ugyanez van SDL1 / SDL2 / SDL3 esetén, apache és apache2 esetén, libtss és libtss2 esetén, libssh és libssh2 esetén, libfuse és libfuse2 / libfuse3 stb. esetén. A főverziót pont azért rakják a csomagnévbe (is), hogy külön dependelhetőek és telepíthetőek maradjanak.
A lényeg nem ez, hanem hogy míg a Rust remote-ból akarja mindig hozni a legfrissebbet (hacsak nem gányolod szét a cargót már a legeslegelején), addig a C csak lokális libeket ismer, ezért könnyedén archíválható a teljes fordítási környezete. Egy olyan backup-ot készíteni, amiben benne vannak a libek is, gyerekjáték C repó esetén, Rust-os repónál meg kőszopás (pláne, mivel mindig minden függőséget kötelező újrafordítani, szóval nem is elég a lib, az összes forrás akkori állapotát kell(ene) archíválnod hozzá, de az rengeteg, ezért nem is csinálja senki).
A fentebb linkelt példámban például a regex lib függőség nem fordult le az új Rust verzióval, mégcsak nem is arról a forrásról van szó, amit a csóka írt.
> a Rust remote-ból akarja mindig hozni a legfrissebbet (hacsak nem gányolod szét a cargót már a legeslegelején)
Nem akarja a legfrissebbet, föntebb linkeltem a doksiból, verziószámot megadod, kész. "*"-ot persze lehet még írni a verziószám helyére, de azt release-nél nem érdemes, és a crates.io sem fogad be olyan csomagot, amelyik így kéri a függőségeit.
Lehet helyi könyvtárból is kérni a függőséget. Lehet crates.io repótól független, saját gitből is. Lehet hanyagolni az egész cargo-t (rustc doksi van), de szerintem nem érdemes.
> Egy olyan backup-ot készíteni, amiben benne vannak a libek is, gyerekjáték C repó esetén, Rust-os repónál meg kőszopás
Csak buildre:
Mentésre is: cargo vendor .
Még nem használtam ezeket, de nagyon erre valónak néznek ki.
Sőt, a tutorial azt mondja, hogy a cargo.lock lefixálja a pontos verziókat és ameddig explicit nem lépteted előre, addig ugyanaz marad az összes függőség. Konkrétan írja is a tutorial, hogy egyes projektek ezt a fájlt is beteszik a verziókezelőbe a reprodukálhatóság céljából. Ameddig a források elérhetősége megvan, addig lehet reprodukálni, és persze csinálhatsz lokál repót is, ahogy írod, és akkor örökre vasalva van minden.
kontra
Persze, meg lehet adni a konkrét verziót, csak akkor a) nem működik, b) a Rust team azt javasolja, hogy "relax the dependencies", azaz hogy NE ADJ MEG verziószámot.
Róka fogta csuka.
...ha szétgányolod a cargo konfigot már a legeslegelején, ahogy mondtam. A Rust fejlesztők 99%-a nem fogja, úgyhogy már megint csederből vederbe.
:( Az előbb azt mondtad, a Rust mindig a legfrissebbet akarja hozni remote-ból, leginkább erre reagáltam.
Mi az a libssl2?
Ezt én se nagyon értem, mivel az OpenSSL esetében: "The latest stable version is the 3.3 series"
Talán a libssh2 -t akarta mondani.
Off: ha C-ben alkotva aggódunk a buffer-túlcsorduláson, ilyesfélékkel is próbálkozhatunk (így még nem 100%, mert a snprintf visszadhat negatív értéket, tehát kell a mesébe még egy my_snprintf, ami ezt úgy kezeli, hogy inkább nullát ad vissza):
C-nek ez a rákfenéje, ezek a string függvények. Még az 'n'-esek se sikerültek hülyebiztosra, pl. én hiányolok egy olyat, ami a \0-t mindenképp a végére teszi, és nem vagy igen, vagy nem, attól függően, hol fogy el a puffer. A fenti példához is kellene egy buff[sizeof(buff)-1] = 0, hogy biztosan le legyen zárva.
Egy számmal jobb a strlcpy/strlcat páros, de azok nem találtak el a szabványba, BSD-specifikusak.
Igen, sajnos. Látszik, hogy az OpenBSD-sek is érezték, hogy az strncpy/strncat nem az igazi. Slprintf meg nincs ott sem, ha jól tudom.