"Rust a Linux kernelben"

Címkék

Korábban még csak érdekességként jött szóba, ma pedig már szinte kész tény: érkezik a Rust programnyelv támogatás a Linux kernelhez. Greg Kroah-Hartman veterán kernelkarbantartó a témához ajánlott egy "jó bevezetőt" a támogatáson dolgozók tollából. Elolvasható itt.

Hozzászólások

Egy új korszak kezdete...

(Kíváncsi leszek a Windows-kernelbe is bekerül-e majd valamikor).

Vagy saját jogon, ha már benne vannak a szervezetben.

Én mindenesetre elkezdtem az ismerkedést (és a hajkitépést :) )

Az enterspájz nem az én világom, vagy  a rust vagy a pék esetleg pizzasütő szakma. Paleós reagálást nem kérek :)

IMHO rust tamogatas mogott, foleg az eloregedo fejleszto tabor allhat.
Lehet hogy fiatalsagot jobban erdekeli rust mint C manapsag, talan tobb ember szamara
teheti vonzobba driver fejlesztest, ha C mellett rust opcio is van.

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

Amik főleg azért fordulnak elő, mert a friss programozó nemzedék számára a hardver már egy fekete doboz. E mellett sajnos egyre jobban hígul a szakma. A demand miatt pedig ez is belefér.

Nem akarok ebben a témában igazságot tenni, és sem a C, sem a Rust oldalán kardoskodni. Szerintem teljesen mindegy, hogy C vagy Rust. Az a gond, hogy nem maga a C a probléma. A tüneteket jól kezelheti a Rust, de magát a problémát nem oldja meg. Legfeljebb tovább görgeti.

Hogy friss programozó vagy nem, az engem mint fogyasztót kevésbé érdekel. Az annál jobban, hogy már utálom a hetente jövő security patch-eket.
Jól néznénk ki, ha a kőműves is minden hónapban jönne odébb toszigálni valamit a házamon.

Az hogy "hozzászoktunk" ahhoz, hogy frissíteni kell, az nem azt jelenti hogy normális, csak hogy alkalmazkodtunk egy rossz megoldáshoz és már fel sem tűnik, hogy mennyire hülye irányba haladunk.

Tudják használni. Nem hülyék, akik komolyabb kódokat írnak.
Ellenben az hogy a memóriakezeléssel kapcsolatos alacsony szintű hibákat tekintve    szinte mindig hibamentes kódot ír  és a   kizárt hogy hibázzon    belátható, hogy nem ugyanaz. Utóbbit csak automatizált ellenőrzés mentén tudod garantálni.
Szoktál C-ben nagyobb programokat írni? Sosem volt memóriakezeléssel kapcsolatban tévesztésed? Tuti?

Persze algoritmus hibák ellen nem véd, de legalább a memóriakezelési hibákat kivédi, ami a CVE-kben napjainkban oly gyakran díszeleg.

Igen, ez a populista érvelés.

Megnőtt a demand, többen lettünk, így statisztikailag több az olyan programozó, akinek nemhogy a képességei nincsenek rendben, de elhivatottság terén is akadna room for improvement.

Nyilván nem látok mindenkit és minden projektet. De egyrészt nekünk azért elég jól sikerült leakmentes kódokat írni, amik futnak egy pár eszközön 7/24-ben, kritikus helyeken is. Igaz, mi rendesen megterveztük, amiket csináltunk, és tisztességesen egységteszteltünk, nem szartunk bele az egészbe. Nyilván előfordult hiba, de az nagyon gyorsan ki is derült, és nyakon is csíptük.

Másrészt találkoztam a munkám során egypár fejlesztővel, akik finoman szólva nem éppen best practice módon álltak a munka rájuk eső részéhez.

Engem például kurvára meglep, amikor egy évtizedes múlttal rendelkező csapat dobálja a malloc()-okat. Ennyi idő alatt nem termeltek ki magukból egy allocator és adatkezelő lib-et? Ha ez a helyzet, akkor miért nem használnak valamilyen nyilvános lib-et?
Memóriaterület másolásakor minimum az n-es függvények használata, de jobb inkább a saját lib függvénye, ami majd seamlessly újraallokál (vagy kezeli a helyzetet, ahogy kell), ha nem fér el az adat a célterületen.
És nem ez szokott lenni az egyetlen baj. Előfordul, hogy át sincs gondolva az egész, csak elkezdtek valamit, aztán lett valami, aztán majd megint csak lesz valami.
Ezeket a problémákat a Rust nem fogja megoldani. Nekem nem is a Rust-tal van bajom.

A korrektség kedvéért ismét meg kell említeni, hogy nem minden programozó ilyen. Ismerek olyan zseniális srácokat, akik újra és újra rádöbbentettek, hogy mennyire keveset tudok, és szívből jövő, sincere deepest respect irányukban.
Sőt, megkockáztatom, hogy a többség alkalmas arra a munkára, amit csinál. Csak a trógerek ganébombái nagyobbat szólnak.

Utóbbit csak automatizált ellenőrzés mentén tudod garantálni.

Ott se.

Sosem volt memóriakezeléssel kapcsolatban tévesztésed? Tuti?

Mondtam én ilyet? Nem? Akkor mire írtad ezt? Jó kis szalmabáb érvelés sose rossz?

Persze algoritmus hibák ellen nem véd, de legalább a memóriakezelési hibákat kivédi, ami a CVE-kben napjainkban oly gyakran díszeleg.

Nem szeretnék ezen még egyszer többszáz kommenten át vitatkozni. A korábbi topicban itt összeszedtem egy csokorba, hogy miért áll égnek a hajam ettől a "acészarmerszegfótmegbafferóverflódemajdarasztmindentmegódhejettüngmerabbannincsszegfótmegbafferóverflóúgyhogyírgyungizibemindentátrasztbanembajhanemfogműködnicsakpusztujjonmánacévégreéjjenekahaladóinfómatikajieszmékek" mentalitástól. Még mindig nem a Rust létezésével van bajom, hanem az erőszakos hittérítéssel, hogy ez a true way, dögöljön meg a cé.

Egyrészt az elcseszés az a programhiba, azaz esetünkben a crash. Nem az a hiba, hogy egy unsafe részekkel bíró függvény nullpointert ad vissza, hanem az, hogy ezt egy safe módú szövegkiirató felhasználja, mint adatforrást.
Másfelől az állításod az volt, hogy a Rust safe módja az automatizált ellenőrzésével pont az vállalja, hogy a programozó ne követhessen el memóriakezelési hibát, viszont, tekintve, hogy a safe mód automatikája nem ellenőrizte le, hogy a safe módban felhasznált unsafe forrású adat nem okozhat-e memóriakezelési hibát, így ez bizony jó példa az általad emlegetett limitációkra.

Másfelől az állításod az volt, hogy a Rust safe módja az automatizált ellenőrzésével pont az vállalja, hogy a programozó ne követhessen el memóriakezelési hibát, viszont, tekintve, hogy a safe mód automatikája nem ellenőrizte le, hogy a safe módban felhasznált unsafe forrású adat nem okozhat-e memóriakezelési hibát, így ez bizony jó példa az általad emlegetett limitációkra.

Nem a safe modeban követte el a memoriakezelési hibát, hanem az unsafeben. Az safe mód azt teljesen nyilvánvalóan nem tudja vállalni, hogy ami rajta kívül történt, az jó legyen. Ez a limitáció elég egyértelműen meglesz minden ilyesmi megoldásban.

Nem az a memóriakezelési hiba, ha nullpointert adunk vissza referenciaként, hanem az, ha írjuk/olvassuk az ominózus referenciát, ez pedig a kiíratásnál történik meg és nem a referencia létrehozatalakor. Szemmel láthatóan nem működik ez a limitáció.

A memóriakezelési hiba nem a nullpointer keletkezésekor keletkezik, hanem a felhasználásakor, a hozzáférési kísérletkor. Önmagában egy nullpointer létezése nem hiba. Akkor van hiba, ha valaki megpróbál az általa reprezentált címhez hozzáférni. És ez pedig bizony a safe módban történik.

Mint írtam, nincs NULL pointer a Rust safe módjában.
Helyette itt egy példa, hogyan van NULL száműzése mellett a 'nincs' jelezve:

fn teszt(s: &str) -> Option<&str> {
    if s.len() > 5 {
        Some(s)
    } else {
        None
    }
}

fn main() {
    if let Some(x) = teszt("alma") {
        println!("{}", x);
    } else {
        println!("Túl rövid, nincs eredmény (None)");
    }

    if let Some(x) = teszt("almáspite") {
        println!("{}", x);
    }
}

Kipróbálhatod:
   $ rustc pelda.rs;
   $ ./pelda

Javaslom mindenkinek kiismerni a C és Rust nyelvet a szép és csúnya oldaláról egyaránt és utána jobban tudunk érvelni mellette vagy ellene.

Az unsafe módban, amikor te a Rust védőhálója helyett az unsafe kulcsszó kiadásával magadra vállaltad a felelősséget, bizony hülyeséget csináltál, érvényes adat helyett hülye adatot tettél a rendszerbe. A fordító nem bírált felül, hiszen te kérted tőle el saját felelősségre a teljes kontrollt, a felelősség innentől a tied.
Hogy ez a programfutás során időben később robban, arról nem a safe módban írt kód tehet. Ne a safe részen keresd a hibát, hanem azokban a részekben, ahol unsafe kulcsszóval magadra vállaltál minden felelősséget.

Lentebb(?) már kérdeztem: és ha nem én írtam az ominózus unsafe kódot, csak felhasználtam? Fogtam egy 200 kB-os libet, volt benne ez az unsafe részeket tartalmazó függvény és meghívtam. Úgy is az én felelősségem? Innentől kezdve hol vagyunk előrébb, mint bármely nem biztonságos nyelvvel?

Tetszenek ismét a kérdéseid.
A bizalom roppant kényes téma. Drága ellenőrizni, ellenben olcsó 'hinni'.

Nézzünk eseteket:

   1.) 'Okosban' letöltök egy hipi-szupi varázskódot az internetről és beépítem a szoftverembe, amit eladok. Reklamál az ügyfél és száttárom a kezeimet. NEM tárhatom szét, én használtam fel ellenőrzés nélkül internetről letöltött komponenst.
   2.) Megvásárlok egy hipi-szupi varázskódot és beépítem a szoftverembe, amit eladok. Reklamál az ügyfél és száttárom a kezeimet. NEM tárhatom szét. Én alám dolgozott a varázskód előállítója, terméket adtam el. Az másik kérdés, hogy ebből én utána mit érvényesíthetek a beszállítóm felé, hiszen ő sem tárhatja valójában szét a kezét. További kockázat (termékkel jártam így) a beszállítói láncolat. Igen, a beszállító elismerte, de valójában kijavítani nem tudta ő sem, mert a hibás komponenst binárisként kapta és nincs rá supportja. Kínos, a termék ismert és kijavítatlan hibákkal rendelkezik. Ez sajnos a globalizációs 'olcsójános' elv miatt ma elég gyakori.
   3.) Megvásárolok egy hipi-szupi varázskódot és a forráskódjában legalább az unsafe blokkban levő dolgok biztonsági kihatásait magam ellenőrzöm. Ez lenne a felelősségteljes magatartás.
            Ezen a ponton jön elő a Rust erőssége: a teljes kódbázis helyett csak a sokkal kevesebb 'unsafe' részt kell a memóriakezelési és hasonló low level hibákra ellenőrizni és nem a teljes beépítendő kódbázist.

Valójában az, hogy elhisszük, hogy idegen által írt, internetről letöltött kód 'biztosan' hibátlan ... a mai informatika másik rákfenéje.

Tetszenek ismét a kérdéseid.

Nem tehetek róla, unpopular opinion is unpopular.

Drága ellenőrizni, ellenben olcsó 'hinni'.

Ez kb. lehetne a Rust safe módjának mottója is. :P

1.) 'Okosban' letöltök egy hipi-szupi varázskódot az internetről és beépítem a szoftverembe, amit eladok. Reklamál az ügyfél és száttárom a kezeimet. NEM tárhatom szét, én használtam fel ellenőrzés nélkül internetről letöltött komponenst.
2.) Megvásárlok egy hipi-szupi varázskódot és beépítem a szoftverembe, amit eladok. Reklamál az ügyfél és száttárom a kezeimet. NEM tárhatom szét. Én alám dolgozott a varázskód előállítója, terméket adtam el. Az másik kérdés, hogy ebből én utána mit érvényesíthetek a beszállítóm felé, hiszen ő sem tárhatja valójában szét a kezét. További kockázat (termékkel jártam így) a beszállítói láncolat. Igen, a beszállító elismerte, de valójában kijavítani nem tudta ő sem, mert a hibás komponenst binárisként kapta és nincs rá supportja. Kínos, a termék ismert és kijavítatlan hibákkal rendelkezik. Ez sajnos a globalizációs 'olcsójános' elv miatt ma elég gyakori.

Mi van, ha ellenőrizte, csak az ő tesztadataival nem jött ki az unsafe részből crash-t okozó cucc?

3.) Megvásárolok egy hipi-szupi varázskódot és a forráskódjában legalább az unsafe blokkban levő dolgok biztonsági kihatásait magam ellenőrzöm. Ez lenne a felelősségteljes magatartás.
Ezen a ponton jön elő a Rust erőssége: a teljes kódbázis helyett csak a sokkal kevesebb 'unsafe' részt kell a memóriakezelési és hasonló low level hibákra ellenőrizni és nem a teljes beépítendő kódbázist.

Mi van, ha átnézte, de nem talált benne semmilyen triviális baromságot?

Nem lenne egyszerűbb leellenőrizni, hogy az a pointer nem mutat-e olyan helyre, ahová a program nem nyúlkálhat? Persze tudom: nem, mert ha minden pointer access-t ellenőrizne a nyelv, akkor akkorává válna a sebességhátránya a C-hez képest, hogy már nem lehetne bemesélni az embereknek, hogy a Rust minden téren valid alternatívája a C-nek.

Valójában az, hogy elhisszük, hogy idegen által írt, internetről letöltött kód 'biztosan' hibátlan ... a mai informatika másik rákfenéje.

Másik? Mi az egyik? A hülye programozók? A bloated környezetek és keretrendszerek? Az ostoba ideológiák? Vagy ezek így együtt, azaz a microsoft? :P (A mikiszoft opcionálisan behelyettesíthető kuglival, redhettel, whateverrel.)

Egyrészt nem assignolni, hanem műveletet végezni vele: az első sor az assign (hozzárendelés), a második az access (hozzáférés).
Másfelől, a Rust-os példában nem lehetett tudni, mert függvényből jött vissza. Mi van, ha nem is nullpointert ad vissza, hanem egy véletlenszámot, ami akár véletlenül még mutathat is a program tárterületére? Mitől safe egy kód, ami nem ellenőrzi a használt pointereinek validitását?

> Egyrészt nem assignolni, hanem műveletet végezni vele: az első sor az assign (hozzárendelés), a második az access (hozzáférés).

Borzasztó fordítva vagy bekötve :) De igen, így is lehet nézni, mindegy, írni akartál a pointer címére.

> Mi van, ha nem is nullpointert ad vissza, hanem egy véletlenszámot, ami akár véletlenül még mutathat is a program tárterületére? Mitől safe egy kód, ami nem ellenőrzi a használt pointereinek validitását?

Hogy tudja ellenőrizni, hogy a benne levő véletlen helyre mutató pointer jó? Nyilván sehogy, mert ez elméletileg lehetetlen. A programozó dolga, hogy az unsafeből ne jöjjön ki faszság.

Borzasztó fordítva vagy bekötve :) De igen, így is lehet nézni, mindegy, írni akartál a pointer címére.

Hát ha nálad az assign a hozzáférés és az access a hozzárendelés, akkor nem én vagyok fordítva bekötve.

Hogy tudja ellenőrizni, hogy a benne levő véletlen helyre mutató pointer jó? Nyilván sehogy, mert ez elméletileg lehetetlen.

Miért lenne lehetetlen? A program hozzáférni kizárólag olyan adatterületekhez férhet hozzá, amiket allokált, illetve a saját stackjéhez és data szegmenséhez. Azt egy mezei listával nyilván tudja tartani, hogy milyen címekre mekkora területet allokált, a stack/data pointerek kiolvasása meg ne legyen már lehetetlen...

A programozó dolga, hogy az unsafeből ne jöjjön ki faszság.

C-ben tuti, de Rust-ban a safe mód pont arról kéne, hogy szóljon, hogy megvédi magát. És itt egyébként a függvény java is safe volt, egy sornyi unsafe volt benne.

Hát ha nálad az assign a hozzáférés és az access a hozzárendelés, akkor nem én vagyok fordítva bekötve.

Ne forgasd ki a szavaim. Ha szerinted a második sorban levő kifejezés nem egy assignment, akkor van baj.

Miért lenne lehetetlen? A program hozzáférni kizárólag olyan adatterületekhez férhet hozzá, amiket allokált, illetve a saját stackjéhez és data szegmenséhez. Azt egy mezei listával nyilván tudja tartani, hogy milyen címekre mekkora területet allokált, a stack/data pointerek kiolvasása meg ne legyen már lehetetlen...

Mert az unsafeből jött, ami kifejezetten azért van, hogy meg tudd kerülni a védelmi mechanizmusokat? 

Ne forgasd ki a szavaim. Ha szerinted a második sorban levő kifejezés nem egy assignment, akkor van baj.

Először access, csak aztán lenne assignment, de már az accessnél elhasal az access violation miatt. A Rust példában viszont nem volt assignment, akkor maradjunk annál C-ben is:

char *x = NULL;
printf(x);

Erről volt ugyanis szó, csak rossz volt a C-s példa.

Mert az unsafeből jött, ami kifejezetten azért van, hogy meg tudd kerülni a védelmi mechanizmusokat?

Nem az unsafe alatti részt kell ellenőrizni, hanem a safe részt. Történik egy kiírás, amiben egy referencia alól akarunk stringet kiírni. A referencia függvényből jön, azaz letárolódik az értéke valahova, mielőtt használja a safe rész. Azt már a safe módú kiíró fogja címként felhasználni, tehát letárolta valahova, akkor meg már ellenőrizheti is, hogy olyan helyre mutat, ahova egyáltalán a task hozzáférhet, mert nem lehetetlen ezt ellenőrizni, hogy hozzáférhetsz-e valamihez, vagy sem; le is írtam, hogyan lehet ellenőrizni.

Először access, csak aztán lenne assignment, de már az accessnél elhasal az access violation miatt. A Rust példában viszont nem volt assignment, akkor maradjunk annál C-ben is:

char *x = NULL;
printf(x);

Erről volt ugyanis szó, csak rossz volt a C-s példa.

Ok. És igen, igazad van, természetesen előbb access. 

Nem az unsafe alatti részt kell ellenőrizni, hanem a safe részt. Történik egy kiírás, amiben egy referencia alól akarunk stringet kiírni. A referencia függvényből jön, azaz letárolódik az értéke valahova, mielőtt használja a safe rész. Azt már a safe módú kiíró fogja címként felhasználni, tehát letárolta valahova, akkor meg már ellenőrizheti is, hogy olyan helyre mutat, ahova egyáltalán a task hozzáférhet, mert nem lehetetlen ezt ellenőrizni, hogy hozzáférhetsz-e valamihez, vagy sem; le is írtam, hogyan lehet ellenőrizni.

Persze, hogy lehetne, csak ha ezt a mentalitást generalizálod, akkor oda fogsz jutni a végén, hogy nincs is unsafe, mert mindent, amit ott csináltál, leellenőrzünk, hogy megfelel-e a safe szerint. Márpedig az unsafe azért van, hogy meg tudd kerülni az ellenőrzések megkötéseit, ha az tényleg szükséges. Én értem, hogy ez tud bajt okozni, és limitálja a hasznosságot, de én továbbra is azt gondolom, hogy ez nem a safe hiányossága, hanem a rossz unsafe kód következménye. És szerintem az egy teljesen élhető kompromisszum, hogy mondhatod, hogy most ne legyél okosabb nálam, tudom mit csinálok, akkor hagyja neked a tool, hogy rendben kisgazdám, de akkor te vagy a felelős a következményekért is.

Persze, hogy lehetne, csak ha ezt a mentalitást generalizálod, akkor oda fogsz jutni a végén, hogy nincs is unsafe, mert mindent, amit ott csináltál, leellenőrzünk, hogy megfelel-e a safe szerint.

Ettől miért ne lenne lehetőség unsafe módon dolgozni? Azt továbbra sem kell ellenőrizni ami unsafe blokkban van, lévén az - nomen est omen - unsafe, de az, hogy egy safe rész ellenőrizetlenül felhasznál egy változót, amit egy unsafe rész állított elő, az bizony rés a pajzson. A crash a safe részben történik. Ennyi a lényeg és nem több. Érdektelen, hogy a kapott adata unsafe körülmények között jött létre, mert safe körülmények között lett felhasználva és az eredmény a crash volt.

Márpedig az unsafe azért van, hogy meg tudd kerülni az ellenőrzések megkötéseit, ha az tényleg szükséges. Én értem, hogy ez tud bajt okozni, és limitálja a hasznosságot, de én továbbra is azt gondolom, hogy ez nem a safe hiányossága, hanem a rossz unsafe kód következménye. És szerintem az egy teljesen élhető kompromisszum, hogy mondhatod, hogy most ne legyél okosabb nálam, tudom mit csinálok, akkor hagyja neked a tool, hogy rendben kisgazdám, de akkor te vagy a felelős a következményekért is.

Csakhogy - ahogy mondtam - az összeomlás a safe részben történik: akkor, amikor azt kértem, hogy most legyen okosabb nálam, mert nem tudom, hogy mit csinálok. Mi van, ha az unsafe részt tartalmazó függvényt nem is én írtam, csak felhasználtam? Én itt bízok a nyelvben, hogy nem érhet baj, amíg safe módban vagyok, aztán puff...

Mert ha mindenre, ami kijön az unsafe blokkból, hirtelen igyekszünk kikényszeríteni ugyanazt az ellenőrzést, akkor az unsafe blokk értelmét veszti koncepcionálisan, mert nem tudsz igazából semmit tenni, amit ne lehetett volna safe módban, nem lesz átjárás. Igen, ciki, hogy ez egy safe blokkban fog adott esetben a lábadra esni, jobb volna, ha nem tenné, ezért mondtam, hogy ez szerintem egy elfogadható kompromisszum, hogy ezzel tisztában kell lenni. És nyilván ezért is kell az unsafet minimalizálni, meg árgus szemekkel átnézni, hogy ne csorgasson át szart a kód safe részébe. Ettől még a baj a safe részben lesz.

Az pedig, hogy ki írja a kódot, teljesen lényegtelen.

Mert ha mindenre, ami kijön az unsafe blokkból, hirtelen igyekszünk kikényszeríteni ugyanazt az ellenőrzést, akkor az unsafe blokk értelmét veszti koncepcionálisan, mert nem tudsz igazából semmit tenni, amit ne lehetett volna safe módban, nem lesz átjárás.

Dehogynem lesz átjárás, csak épp az átjáró adatok validálva lesznek. Az unsafe lényege nem az, hogy direkt átadhass rossz adatokat, hanem az, hogy megtehess olyat, amire a nyelv bereklamál safe módban.

Igen, ciki, hogy ez egy safe blokkban fog adott esetben a lábadra esni, jobb volna, ha nem tenné, ezért mondtam, hogy ez szerintem egy elfogadható kompromisszum, hogy ezzel tisztában kell lenni.

Hogy legyen vele tisztába az, aki nem ismeri a bejövő adatok természetét, mert azok nem az ő kódjából érkeznek?

Ettől még a baj a safe részben lesz.

Erről beszéltem idáig. Örülök, hogy konszenzusra jutottunk.

Az pedig, hogy ki írja a kódot, teljesen lényegtelen.

Nem azon volt a hangsúly, hogy ki írja a kódot, hanem, hogy ha felhasznál egy libet és nem tudja, hogy az adott függvény hogy old meg valamit, akkor most hiba volt-e a részéről, hogy támaszkodott a safe módra, vagy sem? Mert ha hiba, akkor viszont át kell néznie a felhasznált library kódját, ami ha soktíz kB-ra rúg, az nagyon "meggyorsítja" a fejlesztést. A safe mód lényege a Rust userek szerint pont az lenne, hogy az ember ne követhessen el triviális hibákat, márpedig, ha egy sima print crash-t okoz, mert a kapott referencia invalid memóriacímre mutatott, az bizony triviális hiba, hiszen a delikvens egy meghívást, meg egy kiiratást csinált, nem többet.

Erről beszéltem idáig. Örülök, hogy konszenzusra jutottunk.

Bocs, nem, csak kimaradt egy nem. :)

Az unsafe lényege nem az, hogy direkt átadhass rossz adatokat, hanem az, hogy megtehess olyat, amire a nyelv bereklamál safe módban.

Nem nagyon látom, hogy a gyakorlatban mire lenne ez használható.

 Nem azon volt a hangsúly, hogy ki írja a kódot, hanem, hogy ha felhasznál egy libet és nem tudja, hogy az adott függvény hogy old meg valamit, akkor most hiba volt-e a részéről, hogy támaszkodott a safe módra, vagy sem? Mert ha hiba, akkor viszont át kell néznie a felhasznált library kódját, ami ha soktíz kB-ra rúg, az nagyon "meggyorsítja" a fejlesztést. A safe mód lényege a Rust userek szerint pont az lenne, hogy az ember ne követhessen el triviális hibákat, márpedig, ha egy sima print crash-t okoz, mert a kapott referencia invalid memóriacímre mutatott, az bizony triviális hiba, hiszen a delikvens egy meghívást, meg egy kiiratást csinált, nem többet.

Ha nem bízik benne, akkor sem kell átnézni neki mindent, csak az unsafet. De ez alapvetően annak a dolga, aki az unsafe kódot írja. A triviális hiba továbbra is azért van, mert ott valaki elkefélt valamit, mikor megígérte, hogy de én bizisten tudom mit csinálok. De innen már csak ismételni tudom önmagam. Ez természetesen nem ideális, és faszkalapok meg rosszindulatúak továbbra is tudnak vele bajt csinálni, de jó eséllyel akkor is kevesebb lesz a triviális hiba, mint korábban, és kiszúrni is egyszerűbb lesz, mert bazi nagy unsafe flag lesz rajta.

Nem nagyon látom, hogy a gyakorlatban mire lenne ez használható.

Ezt most mire írtad? Az unsafe módra?

Ha nem bízik benne, akkor sem kell átnézni neki mindent, csak az unsafet.

Itt pont az volt a lényeg, hogy meg lehet bízni a safe módban.

De ez alapvetően annak a dolga, aki az unsafe kódot írja.

Ja. Ő meg leszarta és elbaszta. Aki meg felhasználta, az szív vele. Ezen a Rust sem segít.

A triviális hiba továbbra is azért van, mert ott valaki elkefélt valamit, mikor megígérte, hogy de én bizisten tudom mit csinálok.

De nem érted, a végeredmény az, hogy a végfelhasználó viszont rászívott, safe módban is. Nem védte meg.

Ez természetesen nem ideális, és faszkalapok meg rosszindulatúak továbbra is tudnak vele bajt csinálni, de jó eséllyel akkor is kevesebb lesz a triviális hiba, mint korábban, és kiszúrni is egyszerűbb lesz, mert bazi nagy unsafe flag lesz rajta.

Azt senki nem vitatta, hogy a hibák száma csökkenni fog. A safe mód biztonsága van vitatva, hogy az egy illúzió.

Nem hagytam figyelmen kívül. Egyszerűen úgy látom, hogy ugyanazokat a köröket futjuk, ráadásul a dolgok állásában kb egyet is értünk, a végkövetkeztetésünk más. Eléggé biztos vagyok benne, hogy te nem fogod elfogadni az enyémet, hiszen eddig sem tetted, abban is egész biztos vagyok, hogy a saját álláspontomon sem fogsz már tudni érdemben változtatni a "de nem érted ..." kezdetűekkel: de, értem, eddig is értettem. Azoknak, akik meg csak olvassák már nem fog többet hozzátenni, ha megyünk körülötte még kettőt.

Ami meg itt elsikkadt a mondanivalómból, azt a másik szálon hg2eczvel éppen beszéled.

És ha a nullás címen levő memóriát akarjuk ténylegesen olvasni? Nyilván unsafe módban 0-ra állítottad a pointert hozzá.
Lásd hirtelen példának a C64 memóriába ágyazott GPIO portjait... Bár erre nem portolták a Rust fordítót, csak 8 bites AVR-ekre.

Mi alapján lenne elvárható a Rust safe módjától, hogy felülbírálja az unsafe módban írt részt, aholis a fejlesztő saját felelősségére kérte hogy legyen kikapcsolva a nyelvi védelem?

Nekem, alapban ott büdös, hogy van safe és unsafe mód. Nope. Vagy legyen unsafe a nyelv, mint mondjuk a C, vagy legyen safe, de akkor találjanak ki olyan megoldást, hogy a fordító mindig képes legyen biztonságos kódot fordítani.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

találjanak ki olyan megoldást, hogy a fordító mindig képes legyen biztonságos kódot fordítani

Egyrészt ilyen már több is "van" (valójában egyik sem az) és akkor azokkal kellene konkurálni, amikben semmi igazán létfontosságút nem írtak, másrészt meg akkor aztán tényleg túl lassú lenne a C-hez/C++-hoz képest és nem lehetne megideologizálni, hogy miért is kellene a lingua franca helyett egy a megacorpok kezében lévő nyelvre átírni az összes fontos szoftvert, mert most ugye ez a mantra, hogy csak picivel lassabb, mint a C, de "nem lehet" benne hibázni, vagy csak direkt.

Rendszerprogramozási nyelvet unsafe nélkül meg lehet valósítani?
Például safe módon hogyan címeznél direktben memóriába ágyazott I/O regisztereket? Tudnál operációs rendszert írni safe módban?

Valahol ki kell bújnod a védőháló alól. Itt a kérdés az, hogy a teljes kódot kell felülvizsgálni, vagy csak szűk unsafe kulcsszavas blokkok kihatását?
Továbbá kérdés, hogy az igényességed és a kontrolling folyamat hogyan viszonyul az indokolatlan unsafe kulcsszó használathoz olyan esetekben, amikor van safe megoldás is arra?

Mármint az indokolatlan unsafe száműzése? Remélem az így lesz, ekkor tényleg kisebb munka lesz az alapos code review.
Viszont lesznek bőven helyek, ahol a rendszerprogramozás során ki kell bújni. A jelenlegi linux-next ágban már láthatsz kisebb kódrészeket, ahol kibújnak a védőháló alól.

Én optimista vagyok az eddigi Rust-tal való programozási (x86-on és ARM-on futó Linux, továbbá ARM mikrovezérlő) tapasztalatom alapján.
De majd meglátjuk, lehetnek még számításon kívül hagyott kellemetlen dolgok. Nem véletlen a linux-next -ben az, hogy a Rust alrendszer a konfigban opcionális, tehát teljes egészében kihagyható.

A memóriahozzáférési hibát az okozza, ha hozzá nem férhető memóriacímhez próbálunk hozzáférni és a memóriavédelem tarkónlövi a programot. Van C64-en memóriavédelem? Van ott hozzá nem férhető cím? Tök mindegy, hogy a pointerünk mit tartalmaz, a lényeg, hogy olyan memóriacímre mutat, amit a memóriavédelem fog meghiúsítani (SIGSEGV). Ha a memóriavédelem nem lép közbe, akkor crash sem lesz.

Érdekes, eddig az volt a mantra, hogy ez a nyelv jobban tudja, mint a programozó, meg mindentől megvéd. Most meg egy szimpla safe mode-i pointervalidáció nem fér bele, hogy amit ott safe módban át akarunk adni, ahhoz van nekünk hozzáférésünk, vagy sem?

Igen ... látom több fórumtársnak a safe - unsafe kettősség nagy dilemmát okoz. De ahogy pár hozzászólással feljebb leírtam, kizárólag safe módban rendszerprogramozást, operációs rendszer írására alkalmas nyelvet cáfoljatok meg, de nem fogsz tudni csinálni.
Ennek a kettősségnek akar a nyelv megfelelni

   - safe (default) módjával
   - unsafe blokkok - könnyen megkereshető 'unsafe' kulcsszó által jól elhatárolt (sőt fájlonként bekapcsolható fordítási warning vagy akár fordítási tiltás) módjával

Még mindig kérdés az, hogy ha az unsafe (ahol saját felelősségedre átveszed a kontrollt) részek kihatásainak kivételével, tehát tisztán safe módban lehet-e Rust-ban memóriakezelési hibát véteni? Ezt az esetleges limitációját akarom megismerni.

De ahogy pár hozzászólással feljebb leírtam, kizárólag safe módban rendszerprogramozást, operációs rendszer írására alkalmas nyelvet cáfoljatok meg, de nem fogsz tudni csinálni.

Ez az operációs rendszer specifikációjától függ. Egy tíz soros LED villogtató is lehet operációs rendszer, ha három LED-en kell operálni. Linux kernelt tényleg nem fogsz safe módban írni, az fix. Viszont ennyi erővel a Linux kernel safe részeit meg lehetne írni C++-ban is és akkor a hordozhatóság csak marginálisan csökken.

Még mindig kérdés az, hogy ha az unsafe (ahol saját felelősségedre átveszed a kontrollt) részek kihatásainak kivételével, tehát tisztán safe módban lehet-e Rust-ban memóriakezelési hibát véteni? Ezt az esetleges limitációját akarom megismerni.

Ezt a kérdést te magad válaszoltad meg a múltkori példáddal, amikor bebizonyítottad, hogy a safe mód is dönthető az adatellenőrzés hiánya miatt. Ez mi, ha nem a safe mód limitációja?

Egyúttal itt jegyzem meg, hogy a forráskódból az unsafe blokk warning-olható vagy tiltható a forráskód elejére tett opcióval. Így meg sem kell nézni a hátralevő részét, hogy van-e benne.

#![warn(unsafe_code)]
//#![forbid(unsafe_code)]

fn main() {
    let x = [10, 20, 30];
    println!("Csak teszt: {}", x[0]);
    unsafe {
        println!("Csak unsafe teszt: {}", x.get_unchecked(0));
    }
}

$ rustc pelda.rs

C-ben is már régóta hiányolok valami

#pragma safecode

jellegű megoldást, ahol a klasszikus "bármit" helyett bizonyos biztonsági korlátok mentén lehessen programozni.

Kár hogy az alábbi linkeken elért vívmányok nem jöttek (még) át a GNU-C -be:
     http://www.safe-c.org
     https://www.microsoft.com/en-us/research/project/checked-c/

Azt se felejtsük ki, hogy az eredeti C nyelvet a produktivitás elve vezérelte. Nagyon jól sikerült, ezért szeretjük, szeretem.
Aztán időközben bejött a képbe a 'közös hálózatra mindent' elv, ahol pedig az évek alatt előtérbe került a kompromittálhatóság fogalma.

Ezért érzem azt, hogy a jövőben a C-nek is lesz valami biztonságosabb módja is. Igény az látszólag van rá és a Rust mentén már példa is.

Ahhoz, hogy valami nagy tömegben elterjedjen, ez kell. Igaz ez az elektromos aljzatokra, igaz a konyhai kis/nagygépekre, úgy általában a villamos energiára, igaz ez az autózásra (minek biztonsági öv, nem igaz?), igaz ez mindenfele veszelyes, odafigyelest igenylo eszkozre. egyre hulyebiztosabbak lesznek.

Gyakorlatilag ma nem létezik olyan iparág, ahol üzleti folyamatoknak ne lenne része, sokszor pedig alapvető része az informatika.

Ezzel együtt létrejöttek (nem most, sok sok évvel ezelőtt) az olyan magasabb szintű alkalmazásfejlesztésre szolgáló nyelvek (Java, C#, de akár még a python, PHP, ruby is ide sorolható) és a köréjük épülő ökoszisztéma, mely biztosítja azt, hogy a fejlesztőnek az üzleti problémák megoldásával kelljen foglalkoznia, ne a memóriafoglalással, a bitvadászattal, stb. Ezek a feladatok jelentik az összefejlesztői
munkák nagyon nagy százalékát.

Tehát igen, az ipar megköveteli hogy elkészüljenek ezek a rendszerek, lehetőleg vállalható határidővel, fussanak megbízhatóan, és elég jók legyen ahhoz, hogy a mindennapi munkát el lehessen velük látni.

Például ez lett abból:
           https://www.youtube.com/watch?v=nHJV2ui99Bo
És ez: https://www.youtube.com/watch?v=EeQ0HtNYx9w
És ez: https://www.youtube.com/watch?v=Ep4Z-vDCU3U
És ez: https://www.youtube.com/watch?v=mXAR9P_tuP4
És ez: https://www.youtube.com/watch?v=3IWhO5A-Lkc
És ez: https://www.youtube.com/watch?v=kHixE3cJV4g

Csak hogy néhányat említsek az idei hazánk útjain felvettek közül.
Ez ugyan fél éves, de megmagyarázhatatlan mire gondolt a jogosítvánnyal rendelkező?  https://www.youtube.com/watch?v=-AImSyFPNSE

Hmm, most értettem meg a múltkori vitát. Nem is szakmai kifogásotok volt a Rusttal szemben, hanem ez inkább egy hozzáállás. Ugyanazt képviselitek a programozással kapcsolatban, amit régen az arisztokrácia azzal kapcsolatban, hogy a pórnépnek nem kell tudnia írni és olvasni, hiszen úgyis csak a földet túrják. Vagy épp, hogy a nőknek minek szavazati jog, úgy sem érnek rá politizálni, miközben a konyhában főznek és nevelik a gyerekeket. Lényegében ugyanannak a filozófiának különféle megjelenése ez a "minek programozzon/írjon/szavazzon mindenki": van egy önmagát elitnek gondoló csoport, ami nem szeretné, hogy a nagy becsben tartott csoportjuk kibővüljön/megszűnjön így ne tudják magukat megkülönböztetni a pórnéptől.

Szerencsére ezek az idő során mind kihalásra voltak ítélve, és ki is haltak. Az elkövetkező generációknak talán ugyanolyan archaikus lesz az a gondolat, hogy régen a programozás (akár valami magas szintű nyelven) egy elitista kis csoport "kiváltsága" volt, mint ma nekünk az, hogy az írás/olvasás/szavazás régebben hasonlóan csak a kiváltságosak számára volt elérhető. Vagy akár az, hogy Linux kernelt csak C-ben lehet írni.

A lószart. Volt szakmai kifogás, csak az valahogy megint nem volt érdekes...
Jöjjön nyugodtan programozni bárki, csak értsen hozzá és ne a nyelv próbálja kompenzálni, ha nem ért hozzá. Ez nettó gusztustalan csúsztatás volt a részedről, egyenlőségjelet tenni a meritokrácia és az arisztokrácia közé.

Bocsáss meg, ezt demagóg hozzászólásnak tartom. Lehetséges, hogy vannak elitista programozók, de jómagam nem erről beszéltem.
Mindig boldog vagyok, amikor valaki a programozást választja hivatásul, vagy akár hobbiból programozik. Szívesen segítettem mindig a fiatalokat.
De ha kérhetem, akkor ezt elhivatottsággal tegyék.
Mert sajnos találkozik az ember olyanokkal, akik úgy keveredtek ide, hogy hallották, hogy ,,programozással jól lehet keresni", és nem akarnak ők a legjobbak közé tartozni, csak valahogy ellebegni ennek a tónak a vizén. A demand miatt pedig ők is a felszínen maradnak.

Mondok egy analógiát.
Régen a kereskedelmi pilóták a légierőtől és a vitorlázó szakosztályoktól kerültek ki. Ők rendkívüli tapasztalattal rendelkeztek, és baj esetén hihetetlen mentéseket tudtak végrehajtani egy tohonya utasszállítóval is.
Mára a pilótaképzés sajnos üzlet. Ha van elég pénzed, vagy apuci befizet, idő kérdése, és kereskedelmi járatokon pilóta lehetsz.
A programozás terén ugyanez az érzésem. Vannak most is nagyszerű szakemberek, de lett egy ilyen jellegű ,,beáramlás" is.

Tartom, hogy nem kell mindenkinek programozni. Mint ahogy pilóta vagy cukrász se lehessen mindenki.
Nem tudom láttál-e már olyan cukrászt munka közben, hogy közben arra gondoltál, neked ez semennyi tanulással nem menne így. Mert hiányzik belőled valami, ami benne megvan. Nem tudod megfogalmazni, hogy mi, de egyértelműen felismered, hogy ez a helyzet.
Velem gyakran van ilyen, amikor szakembereket figyelek munka közben.
(Nem minden cukrász ilyen; ott is ezt gondolom: van köztük, akinek nem szabadna csinálni.)

Lehessen bárkiből programozó, aki alkalmas erre. Ez is alkatfüggő.
Vannak, akik más szakmában sokkal jobbak és sikeresebbek lehetnek.

Megjegyzem magam sohasem tiltakoztam a Rust ellen. Nemrég említettem valahol, hogy tőlem az egész kernelt újraírhatják Rust-ban, mert nem ez a lényeg.

A Te analógiádra visszatérve: lehet, hogy megtanítottuk a tömegeket írni és olvasni. Most funkcionális analfabétákkal van tele a világ.

Ennek azért erősen más az olvasata, mint a "nem kellett volna nagytömegben elterjednie". Egyébként szerintem a szakmában van annyi önkontroll, hogy differenciálja az embereket

Tartom, hogy nem kell mindenkinek programozni.

Mint ahogy villanyt szerelni, házat építeni, kamiont vezetni, bútort gyártani, stb. szintén nem. De legyünk már őszinték, az IT azért létezik és azért növekszik ennyire, mert igény van az általa nyújtott szolgáltatásokra, termékekre, nem pedig azért, mert egyesek ilyen vagy olyan jók benne.

Így van: igaz ez minden szakmára.
Ahogy az is, hogy sok helyen megpróbálnak trükközni és költséget externalizálni.
Ilyen, amikor egy vendéglő nem fizet a szemétszállításért, hanem műszak végén a dolgozóknak hazafelé kell teríteni a zsákokat lakótelepi kukákba. Vagy amikor nem szakácsok főznek, hanem tinilányok vagy öreg nénik. (True story mindegyik.)

A programozás terén is megvannak ezek megfelelői.

Tegyél biztonsági övet egy fúrógépre. A programozás nem egy készre szerelt termék, hanem maga a szerszám. És nem a szerszámokat kell hülyebiztossá tenni, mert az lehetetlen, hanem a hülyéket kell a szerszámok közeléből eltávolítani.

Az ipari szerszámok egy jelentős része tele van mindenféle olyannal, ami a használó hülyesége ellen véd fordulatszámszabályozótól a biztosítékon át addig, hogy a vágógép elindításához két kézzel kell nyomni a gombot, hogy még véletlen se csapjad le a kicsi ujjacskádat.

Arról nem beszélve, hogy pl egy CNC gép is egy szerszám, pedig lehetne mindent kézi reszelővel is csinálni.

De nyugodtan kifúrhatod vele a másik szemét, vagy berakhatod a CNC-be a fejét. Vagy csak simán hozzábaszhatod és kifolyik az agyveleje (feltételezvén, hogy rendelkezik ilyen alkatrésszel). Egy dolog, hogy leégetni nem tudja olyan könnyen (ha nagyon akarja azért az is sikerül), de balesetet minden további nélkül tudnak vele csinálni. Nem tudsz hülyebiztos szerszámot csinálni. Egyszerűen lehetetlen.
Hiába zárod lonsdaleitlabdába a szerszámokat, aki hülye az úgy is kárt fog tudni okozni vele (ha másképp nem megy, hát ágyúba dugja a labdát és belelövi az épülő házba), arról nem is beszélve, hogy mivel így nem lehet velük dolgozni, muszáj nyitni a labdát (értsd: unsafe) és onnantól GOTO10...

Azt senki nem mondta, hogy mindent csináljuk kézi reszelővel, de próbálj egy ötraszteres lyukba belegyömöszölni egy CNC gépet. Próbálj egy mínusz fél nanobites mikrokontrollerre Java-ban vagy épp Rust-ban programot írni.
A reszelősök nem mondták, hogy a CNC rossz, a CNC-sek viszont ki akarják irtani a reszelőt, mert az nem haladó. Nagy különbség.

Persze. Ettől mégiscsak van általában értelme, hogy van benne biztosíték, meg ritkábban vág le ujjat a könyvkötő. A Cben is vannak safetyk, érvelésed alapján mindent assemblyben kellene írni, teljesen fölöslegesek a fejlesztőt segítő absztrakciók. A rust látott néhány jellemző problémát a szerszámmal, és megpróbált ezekre jobban odafigyelni, ennyi ez, nem több, nem kevesebb. Ettől még természetesen abban is lehet szar kódot írni.

Az ideológiai "kiirtani típusú" félelmeiddel nem nagyon tudok mit kezdeni, nem szeretnék érdemben beleszólni. (Csak nagyon zárójelben jegyzem meg, hogy dehogynem akarták, géprombolás volt a jelenség neve, még a történelem könyvekben is benne van ;)

érvelésed alapján mindent assemblyben kellene írni

Hát én rohadtul nem ezt mondtam. Szó szerint leírtam, hogy senki nem mondta, hogy mindent is a kézireszelővel... Így nincs értelme vitázni, ha nem az ellen érvelsz, amit mondtam.

A rust látott néhány jellemző problémát a szerszámmal, és megpróbált ezekre jobban odafigyelni, ennyi ez, nem több, nem kevesebb.

Ezzel nincs is semmi baj, sőt ez egy baromi jó dolog. Az már nem annyira, hogy erre építve vallási hadjáratot indítanak a többi koncepció ellen.

Az ideológiai "kiirtani típusú" félelmeiddel nem nagyon tudok mit kezdeni, nem szeretnék érdemben beleszólni. (Csak nagyon zárójelben jegyzem meg, hogy dehogynem akarták, géprombolás volt a jelenség neve, még a történelem könyvekben is benne van ;)

A hasonlatod két okból is fals: egyrészt ott egy munkafolymat lett gépiesítve, nem pedig egy szerszám erőszakosan lecserélve egy másikra, másrészt meg mert itt elég nagy átfedés van a reszelősök és a CNC-sek között; ott meg a munkások és a gépek között nem is lehetett átfedés.

Hát én rohadtul nem ezt mondtam. Szó szerint leírtam, hogy senki nem mondta, hogy mindent is a kézireszelővel... Így nincs értelme vitázni, ha nem az ellen érvelsz, amit mondtam.

Kérlek szépen, hagyd ki a szokásos hisztit. Az eredeti felvetésed az, hogy nem kellenek a safetyk, ipari eszközökön sincs, mert minek. És fölösleges a rustban megpróbálni a memóriakezelési hibákat megpróbálni kezelni, mert akkor is el lehet cseszni. Én erre hoztam a te példáddal analógot, hogy bizony ott is vannak ilyenek, pedig egyértelmű, hogy normális ember nem teszi a kisujját a vágólapra.(v.ö.: nyilván senki nem bassza el a memóriakezelést"). "És nem a szerszámokat kell hülyebiztossá tenni, mert az lehetetlen, hanem a hülyéket kell a szerszámok közeléből eltávolítani." ez bizony pontosan azt mondja, hogy nem kell új szerszám. Szóval a két állításod ellent mond egymásnak. Ne haragudj, hogy én az eredetivel foglalkoztam, nem a bénácska analogiával.

... hogy erre építve vallási hadjáratot indítanak a többi koncepció ellen ...

A hasonlatod két okból is fals: egyrészt ott egy munkafolymat lett gépiesítve, nem pedig egy szerszám erőszakosan lecserélve egy másikra, másrészt meg mert itt elég nagy átfedés van a reszelősök és a CNC-sek között; ott meg a munkások és a gépek között nem is lehetett átfedés.

Legyen neked, rossz hasonlat, mint mondtam, ebbe az ideológiai vitába nem szeretnék beleszólni, én pusztán arra kívántam reagálni, hogy igenis nem mindegy, milyen az a szerszám.

Kérlek szépen, hagyd ki a szokásos hisztit.

Mondok valamit, te reagálsz valami teljesen másra, én ezt szóvá teszem és akkor az hiszti, ráadásul szokásos? Szerintem meg fejezd be a szokásos szalmabábcsépelést és a szavak számbaadogatását, vagy ha akarod folytasd, de nélkülem. Már megint megtaláltál és már megint nem tellik tőled másra, mint arra, hogy hülyének titulálj. Már megint te. Unlak, mint a TV-műsort.

Az eredeti felvetésed az, hogy nem kellenek a safetyk, ipari eszközökön sincs, mert minek.

Hol állítottam azt, hogy az ipari eszközökön nincsenek safety-k? Hogy nem esett még szét az a szalmabáb.

Én erre hoztam a te példáddal analógot, hogy bizony ott is vannak ilyenek, pedig egyértelmű, hogy normális ember nem teszi a kisujját a vágólapra.

Csak épp nem a normális emberekről volt szó, hanem a hülyékről, lévén egy hülyebiztosnak kikiáltott nyelvről volt szó, de nem baj.

ez bizony pontosan azt mondja, hogy nem kell új szerszám.

Nem jelenti ezt. Szó szerint leírtam, hogy nem a Rust koncepciójával vagy létezésével van bajom. Jöjjön az új szerszám felőlem, de ne folytassanak kereszteshadjáratot a régi ellen, főleg úgy nem, hogy az új nem is jó mindenre, amire a régi. Ez egy poszton belül már a harmadik számba adott baromság, amit sosem mondtam. És ezek után még az a hiszti, ha ezt szóváteszem? Te megint csak azért jöttél ide, hogy velem flamelj, a téma nem is érdekel téged.

Szóval a két állításod ellent mond egymásnak.

Nem, nem mondott ellent, csak olyat adsz a számba, amit nem mondtam, úgy könnyű ellentmondást kiáltani. Nem mondtam, hogy írjunk mindent assemblyben, meg azt se, hogy nincsenek safety-k az ipari eszközökön, azt meg pláne nem mondtam, hogy nem kell új szerszám. Ennyi erővel én azt mondom, hogy te is ellentmondtál magadnak, mert egyfelől azt állítottad, hogy a busz szélesebb, mint kékebb, de azt is mondtad, hogy kékebb, mint amilyen hosszú.

Na jó, goto 10, mert megint el fogunk kezdeni ezer szálon vitatkozni, aminek semmi értelme, mert teljesen követhetetlen. Annyit azért hadd szögezzek le, hogy nem, megint nem tituláltalak hülyének. És a szádba sem akarok adni semmit, próbálom értelmezni, amit mondtál. Szóval. 

Én erre a mondatodra reagáltam:

 És nem a szerszámokat kell hülyebiztossá tenni, mert az lehetetlen, hanem a hülyéket kell a szerszámok közeléből eltávolítani.

Nekem ez azt jelenti, hogy nem kell a szerszámon javítani, hanem nem kell odaengedni, aki hibázik. Ezt nem tudom másképp értelmezni, mint hogy semmi szükség a rustra, és az ő extra safetyjeire. Ebből viszont következne az, hogy egyébként a Cre sincs. És nekem ez ellentmond annak, hogy szerinted nincs baj a rusttal. Ha nem ezt jelenti, akkor kérlek, segíts, hogy mit?

Az, hogy egyébként ki milyen keresztes hadjáratot folytat vagy nem folytat, mint mondtam továbbra sem érdekel. Hidegen hagy, nincs véleményem, nem ismerem a helyzetet, nem akarok beleszólni.

megint nem tituláltalak hülyének

vs.

Kérlek szépen, hagyd ki a szokásos hisztit.

Ja. Nem.

És a szádba sem akarok adni semmit, próbálom értelmezni, amit mondtál.

Akkor miért tetted meg egy poszton belül háromszor is?

Nekem ez azt jelenti, hogy nem kell a szerszámon javítani, hanem nem kell odaengedni, aki hibázik.

Csak a második fele stimmel, az első nem. Én nem azt mondtam, hogy nem kell a szerszámokon javítani, hanem, hogy azzal nem oldjuk meg a hülyék problémáját, tehát ha ez az indok, akkor ez egy sziszüphoszi szélmalomharc, hogy egy ilyen képzavarral éljek. [CT](Dehát nem ez a valós indok, ez csak a casus belli. Az indok valójában az, hogy a mögötte álló nagy cégek (Amazon, Huawei, Google, Microsoft és a Mozilla) még jobban kiterjesszék a kontrolljukat a Linux kernelre és egyéb kulcsszoftverekre, amiket bármi áron át akarnak portolni/konvertálni, még akkor is, ha nem lesz tőle jobb, viszont onnantól legalább csak a platformok töredékére lesz elérhető (vesd össze a C platformtámogatását a Rust-éval); és ehhez a fundamentalista Rust-fanatikusokat használják fel.)[/CT]

Ezt nem tudom másképp értelmezni, mint hogy semmi szükség a rustra, és az ő extra safetyjeire. Ebből viszont következne az, hogy egyébként a Cre sincs. És nekem ez ellentmond annak, hogy szerinted nincs baj a rusttal. Ha nem ezt jelenti, akkor kérlek, segíts, hogy mit?

Akkor javíttasd meg az interpreteredet, mert szó szerint leírtam, hogy "Még mindig nem a Rust létezésével van bajom, hanem az erőszakos hittérítéssel, hogy ez a true way, dögöljön meg a cé." A kereszteshadjáratra, meg a hülyék elleni védekezéssel való indoklásra nincs szükség, nem a Rust-ra. Szerinted érdekelne engem az egész cécó, ha nem már megint arról lenne szó, hogy irtsuk ki a C-t, mert pár álhaladárnak a puszta létezése is fizikai seggfájást okoz?

Az, hogy egyébként ki milyen keresztes hadjáratot folytat vagy nem folytat, mint mondtam továbbra sem érdekel. Hidegen hagy, nincs véleményem, nem ismerem a helyzetet, nem akarok beleszólni.

Jé, nahát...elismerted, amit leírtam:

Te megint csak azért jöttél ide, hogy velem flamelj, a téma nem is érdekel téged.

Ja. Nem.

Nem. Javíttasd meg az interpreteredet, vagy ne adj dolgokat a számba, amit nem mondtam ;)

Akkor miért tetted meg egy poszton belül háromszor is?

Nem volt szándékom, reagáltam arra, hogy te mit mondtál. Tudod, ez egy fórum.

Csak a második fele stimmel, az első nem. Én nem azt mondtam, hogy nem kell a szerszámokon javítani, hanem, hogy azzal nem oldjuk meg a hülyék problémáját, tehát ha ez az indok, akkor ez egy sziszüphoszi szélmalomharc, hogy egy ilyen képzavarral éljek.

Értem, köszi, hogy tisztáztad. Sajnálom, hogy nem ezt olvastam ki belőle, nekem ennek a parentjában levő kommentjedből nem ez jött le.

Jé, nahát...elismerted, amit leírtam:

Te megint csak azért jöttél ide, hogy velem flamelj, a téma nem is érdekel téged.

Nem. A téma érdekel. Legalábbis az, amiről azt gondoltam, hogy a téma, hogy van-e bármi értelme az ilyen eszköz jellegű fejlesztéseknek, és hogy miért mondod, hogy nincs. Ha itt csak az a téma, hogy mert valakik hittérítenek, és köcsögök, az valóban nem érdekel, meg ha érdekelne se tudnám most sem megerősíteni sem cáfolni a véleményedet, mert ahhoz még kéne némi info. És éppen azért írtam, hogy ha "csak" erről van szó,  akkor abba nem akarok beleszólni, hogy ne gondold, hogy mindenféléket is meg akarok magyarázni neked, hogy nem úgy van, és gondold azt, hogy "megint" támadlak. Sajnálom, hogy nem sikerült.

Nem. Javíttasd meg az interpreteredet, vagy ne adj dolgokat a számba, amit nem mondtam ;)

Csak egy hülye hisztizik, tehát ha szerinted hisztizek, akkor szerinted hülye vagyok. QED.

Nem volt szándékom, reagáltam arra, hogy te mit mondtál.

De én nem ezt mondtam. Tehát azért adtál megint szavakat a számba, mert arra reagáltál, amit nem mondtam? Hát ez így végül is logikus, ezt mondtam én is. Akkor most miről vitatkozunk...?

Sajnálom, hogy nem ezt olvastam ki belőle, nekem ennek a parentjában levő kommentjedből nem ez jött le.

Ha nem írtam le most és eddig is többször, hogy a Rust-tal, magával a nyelvvel, meg annak filozófiájával konkrétan nincs semmi bajom (alig ismerem), akkor egyszer sem. Azzal van a bajom, amikor megindul a rozsdás had és állahullakbááár pusztujjonacééé csatakiáltással átírnak valamit Rustba, amit nem kellett volna.

van-e bármi értelme az ilyen eszköz jellegű fejlesztéseknek, és hogy miért mondod, hogy nincs

Látod? Már megint. Most mondom hatvannyolcezredszerre, hogy nem mondtam ilyet. Az eszközfejlesztéseknek en-generique van értelme, az eszközök erőszakolásának nincs.

Sajnálom, hogy nem sikerült.

Csak magadnak köszönheted. Én egyszer sem kötöttem beléd, te viszont egyike vagy annak az öt embernek, akik mindig megtalálnak egy kis beszólogatás erejéig. BTW, ha a téma érdekelt, akkor miért kizárólag nekem reply-ztél a topicban? Mert sem az OP-hoz, sem mások posztjaihoz nem fűztél kommentárt.

Ne haragudj, de én ennél egyszerűbben nem tudom leírni, hogy én így értettem, ezért reagáltam rá, és amikor épp ezt magyarázom, hogy ha te erről nem beszélsz, akkor is épp "már megint", akkor nem tudom hogyan kellene. Értem, hogy nem ezt akartad mondani, rendben, elfogadom. Én semmiről nem vitatkozom, elmondtam, hogy rendben, ha így van akkor így van, csak próbáltam neked elmondani, hogy én miért értelmeztem úgy a mondandód, ahogy, nem pedig beléd akartam kötni.

Csak egy hülye hisztizik,

Ez az állítás pedig hamis. Tehát a belőle levont következtetés is hamis.

BTW, ha a téma érdekelt, akkor miért kizárólag nekem reply-ztél a topicban? Mert sem az OP-hoz, sem mások posztjaihoz nem fűztél kommentárt.

Mert ha nem fűzök hozzá kommentárt, akkor nem érdekelhet? Egyébként van ugyanerről egy másik cikk, ott is van pl kommentem. 

A szalmabábcséplést még csak-csak meg lehet így magyarázni, hogy nem akartál belémkötni, csak "félreértetted", de a "hisztit" nem, ugyanis senki nem hisztizett. Mutass már rá, hogy a leírtak mely sorai felelnek meg nálad hisztinek? Hint: hiszti az amikor az ember amygdala hijack-et kap és dacában elkezd őrjöngeni és baromságokat beszélni/csinálni. Hol láttál te ilyet tőlem? Egy mezei kérés, hogy ne adj szavakat a számba az hol hiszti?

Ez az állítás pedig hamis.

Igen? Miért, mely értelmes emberek szoktak hisztitni?

Mert ha nem fűzök hozzá kommentárt, akkor nem érdekelhet?

De fűztél hozzá kommentárt, de kizátólag az én posztjaimhoz. Ez persze önmagában még semmit nem jelentene, a többségtől fel sem venném. De te egyike vagy azoknak, akik minduntalan megtalálnak egy kis baszakodásra.

Igazából te ignoráltad a kontextust, a beszélgetés, amibe beszálltál arról szólt, hogy van-e értelme az ilyesminek az eszközökben. Te hoztad be a köcsöghittérítők vonalat, ráadásul azon a threaden nem is volt ez jelen egyáltalán, két commented van felette, "Tehát nem megtanítjuk a fiatalokat, hogy tudják használni az eszközt, hanem az eszközt tesszük "gyermekzárassá..." illetve "Tegyél biztonsági övet egy fúrógépre. A programozás nem egy készre szerelt termék, hanem maga a szerszám. És nem a szerszámokat kell hülyebiztossá tenni, mert az lehetetlen, hanem a hülyéket kell a szerszámok közeléből eltávolítani."

és csinálod (megint) azt, amivel engem vádolsz folyamatban, és bizonygatod, hogy de én igenis lehülyéztelek. Úgy kezded az egész választ, hogy én rohadtul nem ezt mondtam, bizonygatod az mondanivalódat, hiába írom le, hogy nincs mit rajta bizonygatni, nem akartam cáfolni. De nem hisztizel, á nem.

Igazából te ignoráltad a kontextust, a beszélgetés, amibe beszálltál arról szólt, hogy van-e értelme az ilyesminek az eszközökben.

Ez nem igaz. Nézd már meg, hogy mire adtam a gyermekzáras választ. Baromira nem az volt a szál kontextusa, hogy most van-e igény biztonsági ellenőrzésekre, hanem az, hogy aki még nem tud programozni (az ominózus "fiatalok", jelentsen ez bármit), azt majd a Rust megakadályozza a baromságok csinálásában, így nem is kell neki megtanulnia, mert Rust-ban úgysem lesz lehetősége baromságot csinálni.

Te hoztad be a köcsöghittérítők vonalat

Mert megint bejött a hittérítős vonal, amikor megint jött az a nettó FUD, hogy mindenki hibázik, tehát a C-től meg kell szabadulni és majd a Rust jól megvéd minket magunktól. Ez nettó maszlag és nettó hittérítés. Kösz, de kösz nem.

és csinálod (megint) azt, amivel engem vádolsz folyamatban, és bizonygatod, hogy de én igenis lehülyéztelek. Úgy kezded az egész választ, hogy én rohadtul nem ezt mondtam, bizonygatod az mondanivalódat, hiába írom le, hogy nincs mit rajta bizonygatni, nem akartam cáfolni. De nem hisztizel, á nem.

Az igazam melletti érvelés nem hiszti, hiába próbálod ezt megmagyarázni. Az őrjöngve baromságok beszélése az hiszti. Ilyet tőlem nem láthattál. De tekintve, hogy te mindig ezt csinálod, hogy mindig valami hiteltelenítési kísérlettel próbálkozol, így ez a rész is kb. annyira hiteles, mint egy hamis SSL cert: az előbb még a puszta szóhasználat volt a hiszti, most meg az igazam bizonygatása. Legközelebb mi lesz a hiszti? Az írásjelek használata? A keyboard használata? Hogy egyáltalán válaszolni merek?

Ez nem igaz. Nézd már meg, hogy mire adtam a gyermekzáras választ. Baromira nem az volt a szál kontextusa, hogy most van-e igény biztonsági ellenőrzésekre, hanem az, hogy aki még nem tud programozni (az ominózus "fiatalok", jelentsen ez bármit), azt majd a Rust megakadályozza a baromságok csinálásában, így nem is kell neki megtanulnia, mert Rust-ban úgysem lesz lehetősége baromságot csinálni.

Megnéztem. A szál témája az, hogy van-e szükség védelmi mechanizmusokra, senki nem mondta benne, hogy nem kell nekik megtanulni. Az hangzott el, hogy egész jól véd egy rakás hiba ellen, meg olyanok, hogy ez egyébként külső szemlélőként kit érdekel, ha az elvileg nem hátulgombolós programozók ontják magukból a memória kezelésre visszavezethető bugokat. Te ebben fogalmaztál meg egy véleményt, hogy szerinted nem a gyerekzár a megoldás, én erre reagáltam. Aztán közölted, hogy de te nem ezt mondtad, hanem hogy nem kell erőltetni, meg kötelezővé tenni. Ok, rendben, de annak a szálnak a témája akkor is a safety featureök voltak szerintem.

Mert megint bejött a hittérítős vonal, amikor megint jött az a nettó FUD, hogy mindenki hibázik, tehát a C-től meg kell szabadulni és majd a Rust jól megvéd minket magunktól. Ez nettó maszlag és nettó hittérítés. Kösz, de kösz nem.

Kedves egészségedre, hogy nem. Hányszor mondjam még el, hogy rendben, értem, nem akarom vitatni?

 Az igazam melletti érvelés nem hiszti, hiába próbálod ezt megmagyarázni. Az őrjöngve baromságok beszélése az hiszti. Ilyet tőlem nem láthattál. De tekintve, hogy te mindig ezt csinálod, hogy mindig valami hiteltelenítési kísérlettel próbálkozol, így ez a rész is kb. annyira hiteles, mint egy hamis SSL cert: az előbb még a puszta szóhasználat volt a hiszti, most meg az igazam bizonygatása. Legközelebb mi lesz a hiszti? Az írásjelek használata? A keyboard használata? Hogy egyáltalán válaszolni merek?

Ott még csak kértelek, hogy ne kezd el (ha már a kontextus ignorálásánál, meg a hiteltelenítésnél tartunk), mert látszott, hogy jó úton vagy afelé, hogy megint sértődötten rugózz.  Azóta ezt sikerült is előadnod. Látod, most is még bizonygatod az igazadat, mikor már nem tudom, hattal feljebb leírtam, hogy, ok rendben, nincs ebben vita köztünk. De neked muszáj előadni, hogy a hiszt=hülye, és hogy az kizárólag az örjöngve tombolást jelenti, és hogy de én akkor is is ignorálom a kontextust, meg hitelteleníteni akarlak téged. Akar a fene. A mondandódra reagáltam.

Megnéztem. A szál témája az, hogy van-e szükség védelmi mechanizmusokra, senki nem mondta benne, hogy nem kell nekik megtanulni. Az hangzott el, hogy egész jól véd egy rakás hiba ellen, meg olyanok, hogy ez egyébként külső szemlélőként kit érdekel, ha az elvileg nem hátulgombolós programozók ontják magukból a memória kezelésre visszavezethető bugokat. Te ebben fogalmaztál meg egy véleményt, hogy szerinted nem a gyerekzár a megoldás, én erre reagáltam. Aztán közölted, hogy de te nem ezt mondtad, hanem hogy nem kell erőltetni, meg kötelezővé tenni. Ok, rendben, de annak a szálnak a témája akkor is a safety featureök voltak szerintem.

"Szerinted." A szál a BSD-től indult, kezdjük itt, tehát máris nem igaz, hogy a védelmi mechanizmusok szükségessége volt az alaptéma. Abba aztán bejött az első hittérítős komment, hogy majd a Rust-tal jól lecsökken a mindenféle memóriakorrupciós sechole-ok és bugok száma. A védelmi mechanizmusokról konkrétan még mindig nincs szó, csak a rasztjó'megvéd mantráról, ami egyébként még mindig nem igaz, mert ha valaki hülye - vagy ne is legyen hülye, értsd: laikus, tapasztalatlan, whatever - és nem tudja, hogy mit csinál akkor a Rust sem fogja tudni megakadályozni, hogy baromságot csináljon: elég, ha mindent unsafe-be tesz. Akkor aztán lehet majd magyarázni, hogy "de elég csak az unsafe részeket átnézni", hogy ha az egész unsafe... (Tehát ezen a ponton a téma már megint az volt, hogy acészarmerbafferóverflómegszegfótdemajdarasztmerabbannincsbafferóverflómegszegfót (de, van), csak, hogy értsd, miért jön szóba mindig a hittérítős vonal.) Ezt tette szóvá pink is, nem mást, hogy baromságra nincs gyógyír. hg2ecz meg sem próbálta cáfolni amit mondott, csak kijelentette, hogy őt ez nem érdekli, de már unja a security patch-eket. Azaz le van szarva, hogy nem a C csinálta a gixereket, hanem a hozzánemértés és ennek megfelelően a Rust sem fogja elhozni a megváltást, max. pár százalékot farag a hibaarányból, akkor is erőltessük a gyermekzárat a kiképzés helyett. És pontosan erre válaszoltam, hogy a gyermekzár nem megoldás: a kiképzés és a szelektálás az.

Hol is ignoráltam én itt a kontextust?

Kedves egészségedre, hogy nem. Hányszor mondjam még el, hogy rendben, értem, nem akarom vitatni?

Akkor minek hozod fel újra-és-újra a hittérítős részt? Ezt már megint te dörgölted az orrom alá, kb. már harmadjára.

Ott még csak kértelek, hogy ne kezd el (ha már a kontextus ignorálásánál, meg a hiteltelenítésnél tartunk), mert látszott, hogy jó úton vagy afelé, hogy megint sértődötten rugózz. Azóta ezt sikerült is előadnod.

Látod? Már megint. Most meg sértődötten rugózás. Hol látsz te bármi jelet arra, hogy megsértődtem? Már megint hitelteleníteni akarsz. Ez nagyon gagyi.

Látod, most is még bizonygatod az igazadat, mikor már nem tudom, hattal feljebb leírtam, hogy, ok rendben, nincs ebben vita köztünk.

Miben? A hittérítős részben? Akkor minek jössz vele elő újra-meg-újra? Vagy abban, hogy a Rust nem akadályozza meg az idiótákat az idiótaságban? Abban meg nem igazán értettél eddig egyet.

De neked muszáj előadni, hogy a hiszt=hülye, és hogy az kizárólag az örjöngve tombolást jelenti, és hogy de én akkor is is ignorálom a kontextust, meg hitelteleníteni akarlak téged. Akar a fene. A mondandódra reagáltam.

Te nem a mondandómra reagáltál, hanem teljesen másra: olyasmikre, ami engem tüntet fel idiótaként. És ezen tényleg felesleges rugózni, mert ezt már rég elismerted, hogy nem arra reagáltál amit mondtam, mert "félreértetted".

Kicsit offtopic, de ha a kedves kódíró mindent unsafe-be rak, akkor senki nem fogadja elfogadni a patch-ét, és írhatja át, éppen ugyanúgy, ahogy ha valaki rossz minőségű kódot, vagy pedig túl nagy változtatást próbál beleszuszakolni a kódbázisba.

Ettől függetlenül ahogy olvasom a RUST fordítóval kapcsolatban Linus-nak merültek fel bőven kérdései, amikre nem igazán sikerült megnyugtató választ adni, szóval amíg ezek nem lesznek javítva, addig esélyes, hogy ez az egész experimental marad.

Erre ne vegyél mérget. Az a baj, hogy abból indultok ki, hogy a Rust ésszel lesz használva és lesöpritek az asztalról, hogy akik eszetlenül kódolnak, azok Rust-ban is eszetlenül fognak és akik elfogadják az eszetlen kódokat, azok Rust-ban is el fogják fogadni őket.

Azt gondolom, hogy kernel szinten nem nagyon hagyják - és korábban sem hagyták - hogy szemét kerüljön be. Szoktam néha olvasni a linux kernel listát, és ott keményen vissza van dobva minden, ami nem üti meg a szintet, még akkor is, ha valamelyik nagy cégtől jön. Ez szerintem alapvetően egy jó irány.

Hogy mennyire kellene egy C-ben írt kernelbe, ahol minden driver kernel szinten fut, Rust-ban kódolni, arról mérsékelten vagyok meggyőződve. Főleg ha ezt az energiát inkább akkor abba fektetnék, hogy a meglévő, RUST nyelven írt kernel-hez (pl. redox) adjanak hozzá újabb dolgokat.

 

Azt gondolom, hogy kernel szinten nem nagyon hagyják - és korábban sem hagyták - hogy szemét kerüljön be. Szoktam néha olvasni a linux kernel listát, és ott keményen vissza van dobva minden, ami nem üti meg a szintet, még akkor is, ha valamelyik nagy cégtől jön.

Aztán Torvaldsot meg majd megint toleranciatáborba küldik, mert nem volt elég befogadó. Ted Ts'o-t is széttépték az SJW-k, mert "ellenállt" pár dolognak, pl. nem volt hajlandó becsicskulni az intelnek és úgy megírni az RNG-t, hogy az teljesen az RDRAND-ra épüljön. A nagy cégek egyre inkább átveszik a kontrollt a Linux felett, mert túl fontos lett és az ipar túl nagy része alapul rá.

Hagyjuk, megint csak az látszik, hogy valami elképesztő módon tudsz mást kiolvasni ugyanazokból a szavakból, mint én, és hogy egyre jobban lovalod bele magad megint, hogy én téged bántani akarlak. Már ott tartunk, hogy idiótának akarlak feltüntetni. Nem akarlak, peace.

Hagyjuk, megint csak az látszik, hogy valami elképesztő módon tudsz mást kiolvasni ugyanazokból a szavakból, mint én

Hát ez elég érdekesen hangzik a szádból azok után, hogy elismerted, hogy nem azt olvastad ki a szavaimból, amit mondtam, mert "félreértetted" őket.

és hogy egyre jobban lovalod bele magad megint, hogy én téged bántani akarlak.

Nem lovalom bele magam, ez volt az alap az elejétől fogva, lévén a veled való vitákban mindig ide lyukadunk ki. Nem tudom feltűnt-e, de a tényleges szakmai vonalat már sok poszttal korábban elhagytuk és azóta csak arról szól az egész, hogy én mit mondtam, meg én mi vagyok. Ha te hozzám szólsz, tudom, hogy kb. két-három poszt múlva már arról fog szólni, hogy én épp mi vagyok.

Már ott tartunk, hogy idiótának akarlak feltüntetni.

Már? Már szinte az elejétől ez volt, egészen pontosan két posztig bírtad.

Hát ez elég érdekesen hangzik a szádból azok után, hogy elismerted, hogy nem azt olvastad ki a szavaimból, amit mondtam, mert "félreértetted" őket.

Igazából udvariasan elfogadtam, hogy jó, ezt akartad mondani vele :) Én továbbra is úgy látom, hogy a mondandód nem ezt jelentette, és következnek belőle azok a következtetések, amiket levontam, de képes vagyok elfogadni neked, hogy te ezt nem szántad bele, sarkosabb kijelentés volt, mint ahogy valóban gondolod (még ha ezt nem is ismerted be) és nem úgy van. Tényleg.

És egyébként itt csak azt akartam mondani, hogy teljesen más szemüvegen keresztül tudsz nézni eszemcseréket, más hangsúlyokat hallasz bele, teljesen másképp értelmezed, mint én. Figyelj: ez nem értékítélet, nem jobb vagy rosszabb, csak meglepően más.

Nem lovalom bele magam, ez volt az alap az elejétől fogva, lévén a veled való vitákban mindig ide lyukadunk ki

Tehát mégiscsak eleve úgy álltál neki, hogy én biztos téged akarlak bántani. :P

Nem tudom feltűnt-e, de a tényleges szakmai vonalat már sok poszttal korábban elhagytuk és azóta csak arról szól az egész, hogy én mit mondtam, meg én mi vagyok. Ha te hozzám szólsz, tudom, hogy kb. két-három poszt múlva már arról fog szólni, hogy én épp mi vagyok.

Feltűnt. Nem tudom, feltűnt-e, de én még mindig nem mondtam rád, hogy hülye vagy, meg idióta vagy, mert nem gondolom ezt. Te jutsz valahogy mindig ide, és adod a számba, hogy ezt tesztem. Igen, valóban mondtam, hogy ne kezd már a hisztit. Ami teljesen pariban van azzal, hogy "rohadtul nem ezt mondtam". És ha én kettőig bírtam, akkor te egyig se. Azóta nem tudod elengedni, és azóta megy erről a szájkarate. Amit, nem tudom feltűnt-e, hogy folyamatosan próbálom ezt megállítani, de te valahogy mégiscsak mindig válaszolsz rá. Kérlek, fogadd el, hogy nem akarlak én semminek beállítani, a konkrét felvetésedre akartam reagálni. 

Tehát mégiscsak eleve úgy álltál neki, hogy én biztos téged akarlak bántani. :P

"Mégiscsak?" Rögtön az elején, miután elkezdted a beszólogatást, le is szögeztem, hogy már megint megtaláltál.

Nem tudom, feltűnt-e, de én még mindig nem mondtam rád, hogy hülye vagy, meg idióta vagy, mert nem gondolom ezt.

Hogy mit gondolsz, azt nem tudom. De a burkolt hülyézés is hülyézés; tőled nem nagyon láttam mást, mint két-három poszton belül már a személyes vonalra terelést, hátha sikerül vele hitelteleníteni.

Te jutsz valahogy mindig ide, és adod a számba, hogy ezt tesztem.

Mert talán folyton ezt teszed?

Igen, valóban mondtam, hogy ne kezd már a hisztit.

És hisztiről szó sem volt, hiába szeretnéd ennyire belemagyarázni.

Ami teljesen pariban van azzal, hogy "rohadtul nem ezt mondtam".

Egyáltalán nincs, vagy, hogy stílszerű legyek: rohadtul nincs. Nem vagyok egy finom alak, a kötőszavaim sem azok. Replace-eld le "egyáltalánra" fejben, ha ennyire zavar, bár egyébként ha megszakadok sem fogom fel, hogy hogy lehetne pariban egy tagadás egy személyeskedő beszólással.

És ha én kettőig bírtam, akkor te egyig se.

Miért is? Mert leírtam, hogy rohadtul nem azt mondtam, amit a számba adtál?

Azóta nem tudod elengedni, és azóta megy erről a szájkarate. Amit, nem tudom feltűnt-e, hogy folyamatosan próbálom ezt megállítani, de te valahogy mégiscsak mindig válaszolsz rá.

A túrót akartad te megállítani. Oda-vissza csavargatod az indokaidat, hogy miért is vádoltál hisztivel, "félreértetted", "rohadtul" csúnyán beszéltem (már ekkora a snowflake faktor, hogy egy rohadtul is csúnya szó?), "bizonygatom az igazam", "sértődötten rugózok rajta" (ez utóbbi azért is vicces, mert ez már a hisztivel történő vádaskodás után történt; hogy akarsz egy beszólást olyasmivel indokolni, ami utána történt?); ezt nevezed te megállítási kísérletnek? Te bizonygatod még mindig, hogy én sértődötten hisztizek, mint egy hülye kölyök. Megint. Csak a kezem tudom már széttárni.

Kérlek, fogadd el, hogy nem akarlak én semminek beállítani, a konkrét felvetésedre akartam reagálni.

Miért fogadnám el az eddigiek után, főleg mivel egyáltalán nem a konkrét felvetésemre reagáltál, hanem arra, amit belemagyaráztál.

Na ehhez képest megnézel bármely, szoftverészetnél már kikristályosodottabb, nagyobb múlttal rendelkező szakmát, az lesz az első szava az összes mesternek, hogy ne szereld le a gépről a biztonsági elemeket. Legyen szó faipar, lakatosság, villanyszerelő, bármi.

Azt senki nem mondja, hogy nem kell megtanulni, hogy hogy működik valami. Gyalulni sem úgy tanítják az asztalosokat, hogy odabasszák az egyengető meg a vastagoló gyalugéphez, hogy nesze, tologasd rajta/benne a fát, hanem jobb esetben először kézzel, mert az elmélettel ugyanúgy tisztában kell lenni. Ettől még termelésben többnyire mégiscsak gépen megy az egész.

ÉS attól függetlenül, hogy vannak biztonsági elemek, ugyanúgy ismerni kell a szerszám jellemzőit, hogy ne lődd tökön magad (szó szerint). Viszont mégsem azt mondják, hogy akkor á, feleslegesek is a biztonsági elemek, hanem, hogy tudd, hogy mi ellen véd és mi ellen nem.

És nem a szerszámokat kell hülyebiztossá tenni, mert az lehetetlen

Kár, hogy csak végletekben tudsz gondolkodni. Attól még valamiért a szakemberek nagyjának láthatóan igénye van a biztonságosabb szerszámokra. Nem véletlen, hogy pl. a SawStop is akkorát ment Amerikában, Európában meg várja mindenki, hogy lejárjanak a szabadalmaik vagy végre kapható legyen itt is. (Ha húst érzékel a körfűrészlapon, belerobbant egy alutömböt a körfűrészlapba, hogy lefékezze és lehúzza az egész blokkot az asztal alá)

A nyilvánvaló, szándékos missuseval meg nem lehet mit tenni ("valaki szándékosan kifúrja a másik fejét"). Bár igazad van, az ilyeneket az elmegyógyba kell vinni, nem szerszámok közelébe.

Nem baj, pár száz év és ez a szakma is le fog tisztulni. Elvégre is az olyan egyszerű szerszámok, mint a véső, kalapács, is több ezer éves fejlődésen mentek át és még ott is vannak nyilvánvalóan jobb és rosszabb és helyzetfüggő megoldások.

Az emberek hibáznak. Akármilyen jó programozó, reviewer, tesztelő, stb valaki, ha elég sok kód megy át a kezei között előbb-utóbb el fog siklani a figyelme egy hiba felett. Ez ellen csak automatizálással lehet védekezni, eszköztől függetlenül. Ha a C nyelv nem teszi lehetővé, hogy ezeket a hibákat automatikusan meg lehessen fogni (a fordító vagy egy static analyzer segítségével), akkor az az eszköz hibája.

A mi szakmánk sokat tanulhatna a kereskedelmi repüléstől. Ha egy gép balesetet szenved egy pilóta hiba miatt, nem (csak) az a kérdés, hogy hogyan lehetne jobb pilótákat képezni, akik majd nem hibáznak. Hanem mit kellene változtatni a rendszeren, ami lehetővé tette, hogy a pilóta hibázzon és ez balesethez vezessen.

Pl. a Lion Air 610-es járat esetén az előző repülő személyzet felismerte a problémát és tudta kezelni a helyzetet, ezért voltak, akik szerint a balesetet pilótahiba okozta. Aztán az Ethiopian Airlines 302-es járatán kiderült, hogy hiába tudták a pilóták, mit kellene tenni.

Az emberek hibáznak. Akármilyen jó programozó, reviewer, tesztelő, stb valaki, ha elég sok kód megy át a kezei között előbb-utóbb el fog siklani a figyelme egy hiba felett.

Ennyi erővel Rust fordító programozói is hibáznak.

Ez ellen csak automatizálással lehet védekezni, eszköztől függetlenül.

És az automatizmust összeállítók nem hibázhatnak?

Ha a C nyelv nem teszi lehetővé, hogy ezeket a hibákat automatikusan meg lehessen fogni (a fordító vagy egy static analyzer segítségével), akkor az az eszköz hibája.

A kalapáccsal nyugodtan be lehet verni a szélvédőt és az eszköz nem akadályozza ezt meg, tehát ez az eszköz hibája. Vagy esetleg nem az eszköz hibája, mert nem is volt célja sosem, hogy megakadályozza? A felhasználó hibája nem az eszköz hibája. Ennyi erővel a tökéletes eszköz egy az embernél okosabb robot, ami jobban tudja az embernél nem csak azt, hogy hogyan kell a melót megcsinálni, de azt is, hogy az ember mit is akart csinálni. Mit ad Isten, elnézve a rettenetes-rémületes okosfos világot, pont erre megyünk. És milyen baromi jó, ugye?

Hanem mit kellene változtatni a rendszeren, ami lehetővé tette, hogy a pilóta hibázzon és ez balesethez vezessen.

Az tette lehetővé, hogy létezik. Javaslom: szüntessük meg a pilótát, csinálja robot az egészet. Elnézve a Tesla kocsijait, sokkal jobb lesz, mert csökkenni fog a túlnépesedés.

Ennyi erővel Rust fordító programozói is hibáznak.

Ez igaz, méghozzá kétféle módon. A fordító vagy nem tud lefordítani egy valid programot, ami bosszantó, de semmiképp nem okoz problémát a lefordított programban. Vagy lefordít egy nem valid programot, illetve nem a kódnak megfelelő kódot generál. Ez nyilván nem jó, de ezt a fordító auditálásával, tesztelésével meg lehet fogni. A fordítót csak egyszer kell jól megírni, ezért van értelme arra több erőforrást szánni, ami esetleg más programok esetén nem áll rendelkezésre.

És az automatizmust összeállítók nem hibázhatnak?

Nyilván hibázhatnak, viszont az automatizmust is validálja maga a folyamat amit automatizál. Így minél több eseten fut annál nagyobb valószínűséggel buknak ki a hibái, amik ezáltal reprodukálhatóak, javíthatóak. Az emberekkel szemben az automatizmus nem fogja elkövetni ugyanazt a hibát, amit egyszer már javítottak.

A kalapáccsal nyugodtan be lehet verni a szélvédőt és az eszköz nem akadályozza ezt meg, tehát ez az eszköz hibája. Vagy esetleg nem az eszköz hibája, mert nem is volt célja sosem, hogy megakadályozza? A felhasználó hibája nem az eszköz hibája.

Ez a körülményektől függ. Egyrészt ahogy írod, lehet pont ez a cél, akkor ez nem hiba. Viszont ha ez nem cél, akkor is csak akkor hiba, ha a szélvédőt véletlenül sikerül beverni a kalapáccsal, ami a kalapács rendeltetésszerű használatával elég nehéz. Persze előfordulhat, hogy kicsúszik a felhasználó kezéből, vagy lerepül a kalapács feje, de ez már az eszköz hibája is, mert pl. nem megfelelő a markolata vagy nem rögzíti a fejet rendesen.

Az tette lehetővé, hogy létezik. Javaslom: szüntessük meg a pilótát, csinálja robot az egészet.

Ha összehasonlítod a mai repülőket a fél évszázaddal ezelőtti repülőivel, akkor ezzel nem is lőttél nagyon mellé. A személyzet száma a töredékére csökkent, számos automatizmus került beépítésre ami csökkenti a pilóták terhelését, így több idejük marad arra koncentrálni, ami nem, vagy nehezen automatizálható. Persze az is igaz, hogy a pilóták egyik dolga, hogy ha az automatizmussal van probléma, akkor át tudják venni az irányítást. De a számos rendszer közül szinte soha nem hibásodik meg egyszerre egynél több, és a legtöbb rendszer esetén az a gép nem szállhat fel újra, amíg a hiba nincs javítva. Vagyis összességében az automatizmus biztonságosabbá teszi a repülést, és ez a statisztikákból is látszik.

de semmiképp nem okoz problémát a lefordított programban

És de: keress rá az LLVM stack probe-ingra és a stack overflow problémára.

Ez nyilván nem jó, de ezt a fordító auditálásával, tesztelésével meg lehet fogni.

Kettős mérce. A kódok auditálásával és tesztelésével a C kódok bajait is meg lehet fogni. De azt nem, mert csak.

Nyilván hibázhatnak, viszont az automatizmust is validálja maga a folyamat amit automatizál.

Perpetuum mobile á la Rust? A hibás validáló automatizmus automatikusan validálja önnönmaga működését?

Az emberekkel szemben az automatizmus nem fogja elkövetni ugyanazt a hibát, amit egyszer már javítottak.

Az a bizonyos automatizmus sem véd meg mindentől, ld. feljebb a memóriakezelési zríket.

Viszont ha ez nem cél, akkor is csak akkor hiba, ha a szélvédőt véletlenül sikerül beverni a kalapáccsal, ami a kalapács rendeltetésszerű használatával elég nehéz.

De ez nem a kalapács hibája. Ez csúsztatás.

de ez már az eszköz hibája is, mert pl. nem megfelelő a markolata vagy nem rögzíti a fejet rendesen.

Elég szomorú, ha egy tárgyat hibáztatunk azért, mert a markolata nem passzol a felhasználó kezébe, vagy mert a felhasználó nem rögzítette a fejet.

Ha összehasonlítod a mai repülőket a fél évszázaddal ezelőtti repülőivel, akkor ezzel nem is lőttél nagyon mellé.

Asszem nem ment át, amit mondtam.

Vagyis összességében az automatizmus biztonságosabbá teszi a repülést, és ez a statisztikákból is látszik.

Egyfelől nem csak utasszállító repülőgépek vannak. Ha már mindenáron erőltetjük a repülős analógiát, akkor ez kb. az lenne, hogy tiltsuk be a sárkányrepülőket és a légcsavarosakat, csak az utasszállítók repülhessenek, mert abban van a pilótákat felülbíráló automatika. Legyen csak a nagy cégeké az ég. Tekintve, hogy ha belegondolok, hogy kik állnak a Rust vagy épp a Java, meg a C# mögött, meg a C állandó kiirtási kísérletei mögött, ez az analógia még stimmel is...
Másfelől meg nagyon nem mindegy, hogy az automatika megkönnyíti az ember dolgát azzal, hogy helyette végez el dolgokat, vagy épp megnehezíti azzal, hogy helyette dönt el dolgokat és megtiltja, hogy az ember másképp dönthessen.

És de: keress rá az LLVM stack probe-ingra és a stack overflow problémára.

Olvasd el újra az eredeti mondatot, aminek csak a második felét idézted be. A bináris létre sem jön, mert a fordító elszáll hibával, egy nem létező binárist pedig nem lehet futtatni, így nem is okozhat hibát.

Kettős mérce. A kódok auditálásával és tesztelésével a C kódok bajait is meg lehet fogni. De azt nem, mert csak.

A lényeg a mennyiségen van. A világ összes C vagy Rust kódja vajon hány nagyságrenddel több, mint egy Rust vagy C fordító kódja?

Perpetuum mobile á la Rust? A hibás validáló automatizmus automatikusan validálja önnönmaga működését?

Nem az automatizmus validálja önmaga működését, hanem annak a használata. Pl. ha van egy unit tesztem ami 100x sikeresen lefutott de 101x alkalommal hibára futott, akkor vagy a kódban történt olyan változtatás, vagy a tesztben van olyan hiba, ami miatt a teszt elhasalt. De ha kiderül, hogy a tesztben van a hiba, akkor nyilván a tesztet kell javítani, nem a kódot. Ezáltal a teszt még jobb lesz, még megbízhatóbban talál meg hibákat a tesztelt kódban.

Az a bizonyos automatizmus sem véd meg mindentől, ld. feljebb a memóriakezelési zríket.

Nem is kell megvédenie mindentől. Az is előrelépés, ha csak a gyakori hibáktól véd meg.

Elég szomorú, ha egy tárgyat hibáztatunk azért, mert a markolata nem passzol a felhasználó kezébe, vagy mert a felhasználó nem rögzítette a fejet.

Ha a markolat csúszós anyagból készült, vagy nem megfelelő a textúrája, az bizony az eszköz, illetve a gyártó hibája. A fej rögzítése szintén nem a felhasználó dolga, hanem a gyártóé.

Egyfelől nem csak utasszállító repülőgépek vannak. Ha már mindenáron erőltetjük a repülős analógiát, akkor ez kb. az lenne, hogy tiltsuk be a sárkányrepülőket és a légcsavarosakat, csak az utasszállítók repülhessenek, mert abban van a pilótákat felülbíráló automatika.

Ha egy hobbi pilóta kisgépe lezuhan, az legfeljebb neki és a családjának, barátainak fáj. Ha egy utasszállító lezuhan, az még érint pár száz embert, akik azért fizettek, hogy biztonságosan eljussanak A-ból B-be. Egy baleset csökkenti az utazóközönség bizalmát, ezáltal az utazási kedvét, arról már nem is beszélve, hogy jelentős anyagi kárral jár. Ezért a légitársaságok érdeke, hogy a légiközlekedést minél biztonságosabbá tegyék, különben a megszűnés fenyegeti őket.

Ugyanígy ha egy hobbiprogramozó kódjában van egy memóriakorrupciós hiba, az kis számú felhasználót fog érinteni és kis kárt fog okozni. Viszont ha a Linux kernelben van memóriakorrupciós hiba, az egyrészt komoly károkat okozhat rendszerek feltörése által, másrészt magas költsége lehet a hiba elhárításának. Ezért a Linux kernelre építő cégek (kb. a világ összes cége) érdeke, hogy a Linux kernelben kevés legyen a memóriakorrupciós hiba.

Legyen csak a nagy cégeké az ég.

Erre most is van példa, ellenőrzött légtérbe nem repülhet be akárki. De ez nem zárja ki, hogy mások is repülhessenek.

Ugyanígy ha a Linux kernelben lesz lehetőség Rustban programozni, az nem fogja kizárni, hogy továbbra is C-ben programozz.

Olvasd el újra az eredeti mondatot, aminek csak a második felét idézted be. A bináris létre sem jön, mert a fordító elszáll hibával, egy nem létező binárist pedig nem lehet futtatni, így nem is okozhat hibát.

Jogos, elsiklottam felette (mentem volna már enni). Nem létező binárisban valóban nem lesz hiba. Viszont akkor mondom, hogy van egy harmadik lehetőség is, amit kihagytál: nem csak le nem forduló, vagy nem megfelelően lefordított kód van, hanem megfelelően lefordított, de a fordító bugjából eredően mégis hibásan működő kód is. Ez volt az, amikor a stack probe-ing hiányában egy kellő mélységű rekurzió eltrashelte az egész vermet. A megírt és a lefordított kód is jó volt (lévén amíg nem ért el egy bizonyos szintű rekurziót, tökéletesen működött), csak éppen az maradt ki belőle, amivel a Rust állítólag kitűnik a többi nyelv közül: az idevágó validáció.

A lényeg a mennyiségen van. A világ összes C vagy Rust kódja vajon hány nagyságrenddel több, mint egy Rust vagy C fordító kódja?

És a világon vajon hány nagyságrenddel több C-t beszélő programozó van, mint Rust-ot? És a C-s programokból vajon hány nagyságrenddel van több a több nagyságrenddel kisebb komplexitásúakból? A mennyiséget sokfelől lehet nézni.

Nem az automatizmus validálja önmaga működését, hanem annak a használata. Pl. ha van egy unit tesztem ami 100x sikeresen lefutott de 101x alkalommal hibára futott, akkor vagy a kódban történt olyan változtatás, vagy a tesztben van olyan hiba, ami miatt a teszt elhasalt. De ha kiderül, hogy a tesztben van a hiba, akkor nyilván a tesztet kell javítani, nem a kódot. Ezáltal a teszt még jobb lesz, még megbízhatóbban talál meg hibákat a tesztelt kódban.

De itt most magáról a fordító védelmi automatizmusáról volt szó, nem pedig külső automatizmusokról. Az nem validálhatja önmagát. Kívülről persze, hogy lehet validálni, hogy a fordító validátora jól működik-e, de ennyi erővel ilyet a C kódokra is lehet írni.

Nem is kell megvédenie mindentől. Az is előrelépés, ha csak a gyakori hibáktól véd meg.

Kiket? A hülyéket? Esélytelen. Azok baromságot fognak csinálni. Olyat, amire a Rust fordítók írói legbrutálisabb rémálmaikban sem gondoltak. A többit? Azok Rust nélkül sem csinálnak olyan sok hibát. Lehet, hogy a Rust-tal még annyit se csinálnának, de cserébe jól lelassítja őket, hogy kerülgethetik a nyelv által támasztott akadályokat. (Nem, nem arra gondoltam, hogy unsafe-fel bypass-olják, hanem, hogy rendesen megírják.)

Ha a markolat csúszós anyagból készült, vagy nem megfelelő a textúrája, az bizony az eszköz, illetve a gyártó hibája. A fej rögzítése szintén nem a felhasználó dolga, hanem a gyártóé.

Tehát nem magának az eszköznek - a kalapácsnak: en-generique a kalapács koncepciójának - a hibája, mert a kalapács koncepciója az, hogy oda tudjál vele baszni egy jó erőset valahova és a markolat anyaga vagy kialakítása, meg a fej rögzítése nem része a koncepciónak, ahogy az sem, hogy hova baszol oda vele. Ha annak a kalapácsnak tényleg szar a markolata, vagy nincs rögzítve a feje, akkor fogsz egy másik gyártó által készített kalapácsot és le van tudva. Ha a C compiler, amit használsz szar, fogsz egy másikat. Rust-ból viszont csak egy van.

Ha egy hobbi pilóta kisgépe lezuhan, az legfeljebb neki és a családjának, barátainak fáj. Ha egy utasszállító lezuhan, az még érint pár száz embert, akik azért fizettek, hogy biztonságosan eljussanak A-ból B-be.

Hány utasszállító gép van a világon és hány sárkányrepülő és egyéb kis csipszar, vagy bármilyen automatikamentes - akár négy légcsavaros teherszállító - gép és arányaiban miből potyog le több? Van erre valami statisztika?

a légitársaságok érdeke, hogy a légiközlekedést minél biztonságosabbá tegyék

Akkor minek csinálnak ilyeneket? A pilótákat nem rátermettség alapján kéne kiválogatni és kiképezni?

Ugyanígy ha egy hobbiprogramozó kódjában van egy memóriakorrupciós hiba, az kis számú felhasználót fog érinteni és kis kárt fog okozni. Viszont ha a Linux kernelben van memóriakorrupciós hiba, az egyrészt komoly károkat okozhat rendszerek feltörése által, másrészt magas költsége lehet a hiba elhárításának. Ezért a Linux kernelre építő cégek (kb. a világ összes cége) érdeke, hogy a Linux kernelben kevés legyen a memóriakorrupciós hiba.

És ennek az a feloldása, hogy bármi áron, de átírjuk egy olyan nyelvre a Linux kernelt, meg minden egyéb kulcsszoftvert, amiben ugyanúgy lehet memóriakorrupciós hibát csinálni, ha nagyon akarod, viszont legalább egy fúziós erőmű kell ahhoz, hogy lefordítsd (a Rust saját magát 32-bites gépeken le sem tudja fordítani, mert nem tudnak annyi memóriát kicímezni) és az eddig támogatott platformok száma a töredékére zuhan vissza, de legalább a nagy cégek megint jól jártak, mert megsemmisítették a mindenki által beszélt C-t és helyette egy olyan nyelvben van már minden, amit csak az ő programozóik ismernek?

Erre most is van példa, ellenőrzött légtérbe nem repülhet be akárki. De ez nem zárja ki, hogy mások is repülhessenek.

Nem arról volt szó, hogy nem repülhet be akárki egy "zárt" légtérbe, hanem, hogy minden automatikamentes gépet letiltunk, mert "nem biztonságosak".

Ugyanígy ha a Linux kernelben lesz lehetőség Rustban programozni, az nem fogja kizárni, hogy továbbra is C-ben programozz.

Ha elkezdik átírni rá? Ez már a másik topicban is volt: ha új modulokat írnak Rust-ban, az nem gáz, maximum az nem lesz mindenütt elérhető, de ha a régi kódokat kezdik el átírni, azt elveszik mindenkitől, aki nem beszél Rust-ban és minden platformtól, ahova nincs Rust fordító.

A kőműves nem azért nem jön minden hónapban, mert annyira job well done van, hanem mert azt már úgy meg is lehet baszni, ahogy van. Aztán nézegeted pár évtizedig.

Egyetértek, hogy a jelenlegi helyzet nem normális. De ezt a Rust nem fogja megoldani. Csak majd más jellegű problémák lesznek.

Ez azért vicces, mert 50 éve van C. A programozóknak nem sikerült 50 év alatt nem leakelő kódot írni. Ha 50 év nem volt elég, akkor lehet, hogy nem a fejlesztőkkel van a probléma, hanem koncepcionálisan hibás az az elképzelés, hogy ezt a fejlesztő nem tudja elrontani, tehát teljesen valid az az érv, hogy ezt le kell venni a fejlesztő válláról. Ami nem megy, nem kell erőltetni.

"nem maga a C a probléma" pedig epp hogy de! Vagyis ahogy a c program kezeli a memoriat, vagyis az pont nem kezeli, szoval a fejlesztok, ahogy kezelik a gep helyett. A kocsog devek akiknek egyre bonyolultabb problemakat kell megoldani egyre tobb emberrel egyuttmukodve. Mikor kitalaltak a c-t keves ember kodolt, nekik az atlagos hw kozeli tudasuk melyebb volt. Ma egy Rust compile time meg tudja csinalni azokat az ellenorzeseket, amik c-ben csak runtime jonnek elo.

Na, szerintem aki ma egy modern processzor kapcsán azt mondja, hogy pontosan tudja, hogy mi történik a chipen belül, az kurva nagyot hazudik. Régen a hőskorszakban, mikor még nem volt branch predictor, cache, pipeline, out-of-order execution meg egy halom más egyéb fancy dolog, amitől stateja lett a CPU-nak (a programozó számára látható regisztereken túl) még azt mondom, hogy oké. Ma már? GLHF. Arról nem is beszélve, hogy akkor még mindig egy adott CPU-ról beszélünk, semmi nem garantálja, hogy valami igaz-e a következő mikroarchitektúrára vagy, hogy az előző ne implementált volna valamit máshogy - hiába ugyanaz az utasításkészlet. És ahogy a spectre meg a meltdown megmutatta, igenis lehet mellékhatása.

Szóval itt nem csak a mélyebb tudással van gond, hanem azzal is, hogy maga a hardver is sokkal komplexebb lett a felszín alatt. Hol azért, mert ez volt az optimalizáls útja, hol azért, mert kellett az új feature. Ismerős valakinek a jelenség egy réteggel odébb?

Másrészről meg, láttam már .NET-es kódot is optimalizálva a CPU sajátosságaira, nem kell ahhoz C. Meg mutattak már C kódot is, ahol a fejlesztője nagyon okos akart lenni, merthogy jobban tudja, csak aztán végeredményben szarabb lett a kód. :)

Nekem is szimpatikus, ki van nézve vész esetére, ha a Linuxszal történne valami. Azért tényleg kár, hogy ott tart kb. mindenben, ahol a Linux tartott 20 éve. Bár ennek előnye is van, mert egyszerűségben, bloatmentességben is kb. ott tart. Meg ha BSD, akkor az sem mindegy, hogy melyikről beszélünk, mert a FreeBSD előrébb jár, mint egy NetBSD, az OpenBSD meg a kettő között valahol.

És itt nem csak hardvertámogatásról, driverekről van szó, hanem mindenféléről, Wine, Steam, Proton, Wayland, gyors bootidő, fájlrendszerek, stb.. Sőt, nekem a BSD, MIT és egyéb teljesen szabad licencek is szimpatikusabbak, mint a GPL. Meg az eredeti BSD userland is közelebb áll a valódi Unixhoz, mint a GNU userland.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

FreeBSD-ről beszélek, amikor azt mondom, BSD.

Nekem is szimpatikusabb a BSD, mint a Linux. Az egész filozófiája, következetessége, és a licenszek is. Tetszik a ragaszkodás a UNIX gyökerekhez, mert szerintem az egy nagyon powerful dolog volt és nem szabadna onnan elkurvulni.
Régen migráltam volna már Linuxról. Sajnos azonban mindig szarul jött ki a lépés és valamelyik lényeges hardver támogatása hiányzott. Nem akarok ezért külön gépet venni, inkább valamelyik meglévőt szánnám neki.

A hw támogatás sajnos rosszabb, mint amikor huszonéve elkezdtem linuxozni. És én nem olyan dolgokat várnék el, hogy menjen rajta xy bleeding edge grafikus kártya, csak legalább legyen wifi.
Wifi adapterem gyakorlatilag még nem volt soha semmiben olyan, amit támogatott.
Olyan common dolgokon is szívás van, mint mondjuk egy RPi.
És nem csak az új hardverek nem támogatottak, hanem a régiek se. Linuxon húsz éve legalább mentek a harmincéves hardverek, de itt ez sem igaz.

Remélem egyszer felértékelődik az, amit képvisel és megtalálja a közönségét. Nem gondolom, hogy a Linux vagy bármi más leváltása lenne a cél. Egyszerűen csak szerintem volna helye neki az ökoszisztémában.

Leszögezem nem az a bajom a Linuxszal, hogy lesz benne Rust (csak a félreértések elkerülése végett).

A Rust Linux kernelben való használata ellen magam sem emeltem szót soha.
Sőt, egyre jobban úgy érzem, hogy a Rust lesz az új C. Ezt én el tudom fogadni. Tőlem az egész Linux kernelt újraírhatják Rust-ban.

De pont arról beszélek, hogy ez nem fogja megoldani a problémát. Mert a probléma nem maga a C.
Lehet, hogy tünetileg kezel pár tyúkszemet, de kicsit olyannak érzem ezt, mint a hűsítő borogatást a fitymaszűkületre.

A valódi probléma nem a C vs. Rust fronton van.

Ismerve par ceget, nem igazan a munkasprogramozoval van problema. Kb a fele irna utolso standard szerinti kodot, a masik fele ragaszkodna a hulyesegeihez lasd jo az a raw pointer (persze 10 soros 1 emberes projektben, de nem 15 even keresztul irt egyszerre  tobb tucat programozo altal keszitett termekben).

A problema a cegekben van, amikor azt latom hogy a felsobb vezetes ugy osztja az eszt es a penzt, hogy nem jut architekturalis fejlesztesre. Nincs az, hogy ki kell dobni a kod egy reszet mert mar elavult. Nincs refaktoralas. Nincs penz auto tesztrendszerre. Nem vesznek fel donteshozonak tobb penzert hozzaertoket. Nem hallgatnak a tapasztalt programozokra. Nincsenek standard elvek a programozasban. Es itt komoly cegekrol is beszelek,pl Airbus ahol azert elvarna az ember a minoseget, de eszembe jutott pl a Boeing tragediai.

Igy persze a kod minosege is amolyan ahogy esik ugy puffan.

Masreszt maguk a termekek sokkal bonyolultabbak lettek, es ezt le kell kovetni uj fejlesztorendszerekkel, frameworkokkel, uj nyelvi elemekkel, esetleg uj nyelvekkel.

C-ben (C++-ban) sokkal dragabb fejleszteni mert 50 programozobol tuti lesz valaki aki ragaszkodik a regi dolgokhoz, mikozben a helyzet teljesen mas es egy uj generacios kornyezet pl a Rust megfogna egy csomo hibat, aminek az elkapasaba a cegek tobbsege nem invesztalna.

Egyeterertek veled hogy alapveto problemak vannak a cegeknel a fejlesztesben, de a megoldas egyik resze hogy magat a fejlesztes menetet is fejleszjuk, azaz kutatjuk hogy lehet olcsobb robosztusabb fejlesztest kieszkozolni.

Ebben valószínűleg igazad van, nálunk is voltak ilyen problémák.
Sajnos amikor az ,,ipari" vagy a ,,gazdasági" igényeket emlegetik, az általában egyet jelent azzal, hogy megpróbálnak minél több költséget externalizálni. Nem ritkán bután csinálva ezt.

Magam egyébként nem vagyok a toolchain és a módszertan fejlesztése, fejlődése ellen. Azt is elfogadom, hogy akár a Rust lesz az új C.
A következőkre akartam csak rávilágítani:
. C-ben is lehet jó módszertannal fejleszteni; nem gondolom, hogy ez nyelvfüggő lenne.
. Rust-ban kódolt szoftverek is hoznak majd hibákat, csak másmilyeneket. Mert a jó módszertant ott sem lehet megúszni.

Én nyilván nem tudom megállapítani, hogy mi a baj a hardvereddel, csak úgy megemlítem, hogy volt fejlesztő, aki BSD-zett, de mivel nem volt támogatott a wifi (vagy az eth? a franc se tudja már, most nem keresem elő a ckket), ezért azt a megoldást választotta, hogy csinált egy bhyve VM-et, aminek PCI-passthrough-val átadta fenti hálózati eszközt, a VM-be beletelepített valami 1floppys Linux router disztrót - és meg volt oldva a problémája. De nyilván ehhez akarni kellett használni BSD-vel azt a gépet :-)

Van az az eset, amikor ez még el is megy.

Egyébként süldő korában a Linux világában sem volt szokatlan az ilyesmi.
2004-ben vettem az első wifit notimat, egy Centrino-t, amiben miniPCI Intel Pro Wireless 2100 típusú wifi adapter volt.
(Ez volt egyébként életem legjobban szeretett notija.)
Ez volt az első gép, amire BSD-t szerettem volna tenni. Persze jöttek sorban a bukták, úgyhogy végül maradtam a gentoo-nál.
Ahogy számos más adapterhez, ehhez is csak ndiswrapper-es driver volt nagyon sokáig. De volt és működött.

Mindeközben Linus véleménye a RUSTról: https://lkml.org/lkml/2021/4/14/1099

Amúgy szívlapáttal kéne pofáncsapkodni a RUST evangelizációs kommandósokat. Ha van egy project, amit egy adott környezetben fejlesztenek, minden egyes más nyelvet belenyomkodók nemi tájékát ecetes sajtreszelővel kellene polírozni. Herótom van, hogy egy C-ben vagy C++ban fejlesztett alkalmazás nem lefordítható, mert van mellette fél tonna python, lua, rust, whatever és majd mindegyik törtt valamilyen szinten.

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ha nem is ennyire markáns a véleményem, alapvetően egyetértek Veled abban, hogy magam sem szeretem a más nyelveken beszuszakolt alkatrészeket.

Viszont el kell fogadni, hogy a Linux kernel egy piaci alapon fejlesztett termék lett. Ez pedig, ahogy máshol is látjuk, felülír minden szakmai elvet.

hát... kérdés, milyen a rust fordítója. Nézegettem alapfokú rust-os doksikat, szerintem nem rossz... sőt, a változótipusok deklarálása kifejezetten tetszik. ... "u32"... "f32"... c, c++-ban kezdett idegesíteni pl. az "int"... teljesen rendszerfüggő volt pl. hogy 16, 32 vagy 64 bites változónak fordította a fordító. ... rust-ban legalább egyértelműen definiálva van a tipus.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Ubuntu 18.04... melóhelyen 32 bites, otthon 64 bites van. A programban sokféle int-et használtam, int, long int, short int, uint32_t, uint64_t, stb... Az 32 bites gépen az int az short int volt, a 64 bitesen meg long int. ... legalábbis a fordító hibaüzeneteiből ezt szűrtem le. Ami a 32 bites rendszeren szó nélkül lefordult, az 64 bites rendszeren rengeteg warning-ot eredményezett a változók miatt, ami meg a 64 bites rendszeren fordult warningok nélkül, az meg a 32 bites rendszeren okozott warning-okat.

A végén nem használtam a sima int-et, uint32_t, int32_t használtam, így egyiken sem volt gond.

-fs-
Az olyan tárgyakat, amik képesek az mc futtatására, munkaeszköznek nevezzük.

Az tény, hogy a BSD-k nem arról híresek, hogy támogatnák a legújabb hardvereket. Valószínűleg közel sincs annyi fejlesztőjük, mint a Linux kernelnek. Kevés emberrel nem lehet mindent megoldani. Én közel 4 éve használok FreeBSD-t és kb. 1,5 éve OpenBSD-t ugyanazon az Asus X52F-es laptopon. Fő rendszerem az OpenBSD ssd-n, FreeBSD a tartalék a hdd-n. FreeBSD-t ritkán használom, általában csak, ha nyomtatni vagy szkennelni akarok, mert ott könnyebb volt bekonfigolni a hardvert. EPSON Stylus C62-es nyomtatóm, HP ScanJet 3400C szkennerem, webkamerám, wifi kártyám, stb mind működnek FreeBSD alatt. Igaz, laptopom már kb. 10 éves darab, nyomtató és szkenner még régebbi, de azért a FreeBSD ezeknél jóval újabb hardvereket is támogat. OpenBSD is, ha nem is annyit, mint a FreeBSD. Szóval azért azt nem mondanám, hogy BSD-k (főleg a FreeBSD) ott tartanak, ahol a Linux 20 éve. Amit sajnálok, hogy a D és a Julia nyelvet nem támogatja az OpenBSD, sőt a Julia csomagot most a FreeBSD13-ból is kivették valami python 2.7 függőség miatt.

Akkor peches lehetek, mert nekem pont a régi hardvereimet se támogatja. Gyakorlatilag nincs itthon olyan wifi adapter, ami megy vele.

Jó volna, ha legalább egy RPi menne vele regressziók nélkül. Nem is lenne profilidegen, mikroszervernek szerintem sokan használják.

Világos, hogy nincs mögötte annyi fejlesztő (és annyi cég), mint a Linux kernel mögött, és szerintem nem is cél, hogy a Linux útjára lépjen. Pont ez lenne az előnye, hogy szakmai, és nem gazdasági érvek mentén fejlődik.