Folytatódik a Rust-dráma az LKML-en, most éppen Christoph Hellwig fakadt ki

Kernel

Hellwig szerint Linus privátban jelezte, hogy beolvasztana Rust kernel kódot az érintett alrendszer karbantartójának kifogásainak ellenére is. Hellwig szerint nincs baja a Rust-tal önmagában, de mint írta, "egy irányítatlan, többnyelvű kódbázis kezelése biztos módja annak, hogy inkább mással töltsem a szabadidőmet" ... :

Nem gondolom, hogy egy weboldal bármilyen formában hasznos lenne. Ha azt akarod, hogy érvényes legyen, akkor a kernel fában kell lennie, és széles körben el kell fogadni.

Továbbá tényszerűen hibás információkat állít. Például:

"Egyes alrendszerek dönthetnek úgy, hogy egyelőre nem akarnak Rust kódot, jellemzően sávszélességi okokból. Ez rendben van és várható."

miközben Linus privátban azt mondta, hogy ő bizony akkor is be fog olvasztani Rust kódot, ha egy karbantartó ellene van. (Ezt privátban mondta, ha forrást keresel hozzá.)

Tehát jelenleg Linux fejlesztőként vagy karbantartóként muszáj foglalkoznod a Rusttal, akár akarod, akár nem.

A Rust kód pedig nem csupán Rust kódot jelent [1] – a bindingok egyáltalán nem úgy néznek ki, mint az idiomatikus Rust kód, hanem egy teljesen más jellegű megoldás, amely hatalmas szemantikai szakadékot próbál áthidalni. És nem csupán néhány helyen teszik ezt, hanem épp most nyomják be minden egyes alrendszerbe és könyvtárba.

Tehát ezek a bindingok mindenhol el fognak terjedni, mint egy rákos burjánzás, és nagyon gyorsan eljutunk oda, hogy egy olyan szoftverprojektből, amely eddig a globális fejlesztéseket és javításokat támogatta, egyre inkább fragmentált rendszerré válunk [2]. Ez a Linuxot egy többnyelvű projektté alakítja át, egyértelmű irányelvek nélkül arra vonatkozóan, hogy mikor melyik nyelvet kell használni [3]. Még a bindingokon kívül is sok kód nem lesz idiomatikus Rust, mert a kernel adatszerkezetei – például az intruzív és önreferenciáló struktúrák, mint az ubiquituous linked list-ek – ezt nem teszik lehetővé. Nem azzal ártunk-e mind a meglévő kódbázis biztonságosabbá tételén dolgozóknak, mind azoknak, akik Rustban szeretnének rendszerszintű programozást végezni?

Dolgoztam már ilyen kódbázisokon, és ezek a rémálmaim, mert folyamatosan újraírnak részeket A nyelvről B nyelvre X okból, majd vissza Z okból. És ebben még benne sincs a szokásos "kreatív" Linux-karbantartói belharc.

Szeretném megérteni, hogy mi a célja ennek a Rust "kísérletnek": Ha a memória-biztonsági problémákat akarjuk javítani, akkor azt a meglévő kódon kell megtenni, és olyan módszereket találni, amelyekkel utólag beépíthetjük ezt. Az utóbbi időben rengeteg munka ment ebbe, és még sokkal többre lenne szükség. De ez is megmutatja, hogy a fő karbantartókat már az olyan triviális dolgok is elriasztják, mint az integer túlcsordulás ellenőrzése vagy a fordító által kikényszerített szinkronizáció (például a Clang thread sanitizer). Hogyan fogjuk áthidalni azt a szakadékot, amely az egyik oldalon még az egyszerűbb biztonsági szabályokat sem fogadja el, míg a másikon szigorúbbakat kényszerít ki?

Ha csupán az a cél, hogy a driverek írását megkönnyítsük, akkor egy új nyelv erre még több munkát jelent, és tovább növeli a már így is túlterhelt karbantartók munkáját, akik a mag infrastruktúráját tartják karban.

Szóval nem gondolom, hogy ez a szabályzat túl hasznos lenne. Jelenleg az egyetlen szabály az, hogy Linus bármire rákényszeríthet, amit akar (nyilvánvalóan ez az ő projektje), és szerintem ezt egyértelműen ki kellene mondania, beleértve a közreműködőkkel szembeni elvárásokat.

A magam részéről én tudok és tudok is Rusttal dolgozni, örülnék, ha a kernelt egy biztonságosabb világba hoznánk, de egy irányítatlan, többnyelvű kódbázis kezelése biztos módja annak, hogy inkább mással töltsem a szabadidőmet. Hallottam már másoktól is ilyesmit félhangosan megjegyezni, csak nem mindenki ennyire szókimondó.

[1] Írtam és dolgoztam már nem kevés felhasználói térben futó Rust kódon, de nem vagyok szakértő, szóval ezt fenntartásokkal kezeld.

[2] Az eBPF-alapú driverek ötlete, ahogy a HID csinálja, szintén nem segít ezen, bármennyire is kedvelem az eBPF-et bizonyos felhasználási esetekben.

[3] Hacsak Linus nem kényszeríti rá az alrendszeredre, vagy Dave nem dönt úgy, hogy minden Nvidia hardvert érintő kód Rustban kell, hogy legyen, természetesen.

Részletek itt.

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

( XMI | 2025. 02. 19., sze – 10:26 )

Tegnap elolvastam eredetiben.

Az első alkalom hogy a kernelben Rust kapcsán valaki azzal jön, ami szerintem is az igazi probléma. Hogy innentől kezdve nincs olyan, hogy egy kernelfejlesztő C-only, mert a C-kódban végzett módosítás is kihat a Rust bindingokra. És érteni kell, nagyon lowlevel szinten hogy pontosan hogyan.

Ugyanakkor megint van egy hiszti is a dologban. Ez a "Linus privátban azt mondta" dolog nekem kicsit bűzlik. Igazából nem tudjuk Linus mire válaszként mondta és pontosan mit. Kicsit gyanús, hogy a hivatalosan meghirdetett szabályokat (jelenleg csak driverek és a hozzájuk szükséges bindingok lehetnek Rust-ban) pont Linus akarja sutyiban megszegni. Szerintem volt annak valami konkrétabb kontextusa, ami Christoph szándékosan nem idézett be.

Régóta vágyok én, az androidok mezonkincsére már!

Egyébként a Swift fejlesztők csináltak egy elég jó C++ - Swift integrációt (Clangra és LLVM-re építve), hogy nem kell kézzel karbantartani Swift C++ bindingokat, mert a fordító kezeli. Ugyanezt kellene megcsinálni Rust és C (illetve C++, de ez a kernelnél nem releváns) között.

Ez a "kézzel karbantartjuk a bindingokat" egyértelműen hibás hozzáállás, mi pl. megcsináltuk az automatikus binding generálást Apple ObjC API és Java között már 12 ével ezelőtt.

Szerintem most üt vissza az, hogy a kernelen belül nincsenek stabil APIk, hanem az az elvárás, hogy minden belső API módosítás át legyen vezetve mindenhol, ami egy C kernel fejlesztőtől nem várható el, hogy megtörténjen Rust nyelvű részeken is.

Hozzáteszem, hogy sokszor ez az API átvezetés nem jár együtt tényleges teszteléssel, legalábbis a ritkábban használt részeken - ami persze érthető is, ha pl. az eredeti fejlesztőnek nincs is olyan hardvere, amin tesztelni tudna. De így hiába vannak átvezetve a módosítások, hogy forduljon, nem lehetünk biztosak abban, hogy helyes lesz az új kód működése.

Én sem teljesen értem ezt a 'kézzel karbantartott "abstraction"-öket kell használni, nem pedig az automatikusan generált binding-okat' szabályt de itt van: https://docs.kernel.org/rust/general-information.html#abstractions-vs-bindings

Régóta vágyok én, az androidok mezonkincsére már!

Elolvastam, és ebből nekem úgy tűnik, hogy a Rust kernel támogatásával az a baj, hogy csak a munka egyik felét próbálják elvégezni: kézzel Rust kompatibilis absztrakciókat próbálnak gyártani a C kernel API-k fölé anélkül, hogy a C API-k módosulnának.

Az én véleményem az, hogy az egyetlen karbantartható megoldás az lenne, ha a C API-k lennének úgy módosítva (és szükség esetén metaadatokkal kiegészítve), hogy azokból a most kézzel előállított Rust absztrakciók automatikusan generálhatók legyenek.

Fontos látni, hogy ezek a módosított (és jó eséllyel biztonságosabban használható) API-k nem csak a Rust nyelvi felhasználást segítenék, hanem új, automatikus biztonsági és kódhelyességi ellenőrzések bevezetését is lehetővé tennék a C-ben írt kódrészekre is, így nem csak a Rust-ban írt kódrészek profitálnának belőle, hanem minden Linux felhasználó.

Egy ilyen, nem csupán technikai hanem kultúrális átalakulást elérni hosszú és sokszor frusztráló folyamat, ahol a jó kommunikációs képességek, a türelem és a másik nézőpontjának megértése talán fontosabbak mint a kódolási készség.

Ui: A kernelnek egyébként sok helyen nagyon szépen összerakott OO-jellegű belső API-ja van, tehát szerintem viszonylag kevés tényleges API módosítással megoldható lenne, inkább olyan annotációkat kellene megadni, mint pl. ki a tulajdonosa egy visszaadott objektumreferenciának, amit C nyelven nem lehet közvetlenül kifejezni.

Ehhez az kene, hogy:

  • Vagy a C programozok legyenek hajlandoak Rustozni
  • Vagy a Rust programozok legyenek hajlandoak C-zni

Ez meg ennyi karbantarto mellett is ritka kivetel - Rust vallasuak es laggardok kontributolnak csak, akik szerint a masik nyelv vagy megtanulhatatlan, vagy eleve az orok karhozat utja es mordori nyelv, tehat meg nem szolalnak rajta, stb.

Ez már csak egy ilyen erőszakos szakma. Régen a Pascal bajnokai ütötték-verték a C/C++ lovagjait, aztán jöttek Pythonos barbárok ostromolni a C/C++ elefántcsonttorony mágusait, most meg éppen a Rust bátor harcosai rázzák a lándzsáikat a C/C++ állásai felé. Néhány év múlva meg majd arról megy a vaker, hogy a <FIXME> tüzérei ágyúzzák a C/C++ várának patinás falait. Nincs új a nap alatt... :-)

Szerintem ez inkább egy - egy hangos kisebbség a különböző nyelvek környékén, akik mindenhova beírják (pro és kontra), hogy miért nincs senki másnak igaza, csak nekik. :)

FYI: Most valóban nincs Rust projektünk, de amikor volt, az egy Rust - C - C++ hibrid kódbázis volt (robotika).

Garantált, hogy a genrált binding működni is fog? Mai napig fognak meg GCC/Clang bugokat kernel fordítással pedig mindkettő elég mature projekt. Valahol valami nem működik akkor jön egy plusz kör, hogy ugyan azt generálja-e nálad a toolod egyik verziója, mint a másik verzió valaki másnál. Elveszik az infó mitől javult meg a bug. Kézzel karbantartott bindingnál ez az infó érzésre historikusan megmarad, ami fontos lehet több ezer fejlesztős projektnél ahol folytön jönnek-mennek új emberek.

szerk.: 

The main idea is to encapsulate all direct interaction with the kernel’s C APIs into carefully reviewed and documented abstractions. Then users of these abstractions cannot introduce undefined behavior (UB) as long as:

  1. The abstractions are correct (“sound”).

  2. Any unsafe blocks respect the safety contract necessary to call the operations inside the block. Similarly, any unsafe impls respect the safety contract necessary to implement the trait.

Tényleg valami ilyesmiről van szó ezek szerint.

A jól megcsinált generált bindingban kevesebb hiba lesz, mintha kézzel próbálnák karbantartani. Jó binding generátort csinálni nem egyszerű, mivel általában különböző fogalmakat, absztrakciós szinteket kell összeegyeztetni. De meg lehet határozni mindkét oldali nyelvnek olyan részhalmazát, amire a binding jól fog működni, és azt külön statikus / fordítási idejű ellenőrzésekkel biztosítani, hogy a projekt csak ebbe a részhalmazba tartozó kódokat használjon. 

Ha ezt nem csinálják meg, akkor a generátort nem lehet majd jól használni, valószínűleg a bzt által hivatkozott generátor is ilyen.

ObjC -> Java irányban sem mi voltunk az elsők, akik bindingot akartak csinálni (a többiek a generátort fel is adták, inkább kézzel próbálkoztak), de mi beletettük azt a munkát (~2 év), ami miatt a generátor jól működött utána. 

 

Mármint a Linux kernelhez? Valószínűleg nem volt ott a környéken olyan aki értett volna ehhez (nem általános tudás), illetve ezzel akart volna foglalkozni (nem általános, hogy két vagy több nyelv agymenéseit akarja valaki összefésülni :) ), vagy nem találtak hozzá pénzügyi finanszírozót.

Mi pl. most többek között a Godot Enginehez csinálunk különböző nyelvi bindingokat (Swift, C++, <nem publikus még>). A Java / Kotlin binding meg a mi korábbi munkánkat felhasználva készült. Ehhez az is kell, hogy maga a Godot Engine úgy van felépítve, hogy ezt támogatja a GDExtension API-ján keresztül. Ez a GDExtension API egy hosszú távú befektetés volt, amikor ~5 éve elkezdték fejleszteni (és most is folyamatosan fejlesztjük ezt az oldalt is), de mostanra mindenkinek egyértelmű, hogy nagyon megérte. Se a Unity, se az Unreal nem invesztált hasonló API-ba.

Ezt a munkát megcsinálni a kernelnél is jelentős befektetéssel lehet csak, ehhez meg kell győzni pl. Linust, és szerezni rá pénzt pl. a Linux Foundation-től.

Ezt én is olvastam anno, ez már Juan válasza, ami elmagyarázza, hogy miért nem stimmelnek általánosságban az eredeti cikk megállapításai, hanem talált kb. 1 db API-t, amire tényleg lassú volt a binding.

A másik dolog, hogy a Godot folyamatosan fejlődik, és ezzel együtt a GDExtension API is, ahogy egyre több mindenre használják.

Amit javasolni tudok, hogy sokszor érdemes a legfrissebb, akár fejlesztői verziókat használni (ez most 4.4beta4), mert nagyon sok mindenben többet tud / gyorsabb, mint a 4.3, és elég stabil ahhoz képest, hogy "nem stabil" verzió.

egy irányítatlan, többnyelvű kódbázis kezelése biztos módja annak, hogy inkább mással töltsem a szabadidőmet

Az első alkalom hogy a kernelben Rust kapcsán valaki azzal jön, ami szerintem is az igazi probléma.

+sok! Ehhez azért még hozzátenném a build rendszer menedzselhetetlenségét (a Rust fordító folyon változik és eltöri a visszafele kompatíbilitást, részben azért is, mert a Rust nyelv még mindig nincs rendesen specifikálva), továbbá durván megnöveli a fordítási időt is. De tény, hogy a legnagyobb baj vele a kódbázis karbantarthatatlansága az interfészillesztések miatt.

Lehet itt az ideje átállni BSD-re...

( pirate | 2025. 02. 19., sze – 10:59 )

Szerkesztve: 2025. 02. 19., sze – 11:01

(A cikk nyomokban Mesterséges Intelligencia által szolgáltatott adatokat tartalmaz, így a tartalmát érdemes duplán ellenőrizni!)

Ezt chatgpt vagy valami hasonlo forditotta?

Meg van hova fejlodnie: "A magam részéről én tudok és tudok is Rusttal dolgozni,"
(az eredeti: "For myself I can and do deal with Rust itself fine")

Van ertelme igy cikket kozolni? Aki nem tudja az adott nyelven elolvasni le tudja maganak forditani amivel akarja, ehelyett most itt diszeleg egy forditas ami hibas (nem tudom hany masik hiba van benne, nem hasonlitottam ossze mondatrol mondatra az eredetivel).

Ha ez a cel: "az indulásakor még nem létező technikai vívmány kerül szándékosan felhasználásra, amolyan korrajzként archiválva" akkor sem igazan ertem minek ha tudjuk, hogy pontatlan.

szerk.: A level egyebkent korrekt, nincs benne az itt divatos "ez is a woke miatt van" duma, hanem ertelmes, technikai indoklasokat tartalmaz.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

legalább a fordításban helyesen "Rusttal" szerepel, a bevezetőben levő "Rust-tal" helyett

En valoszinuleg a "Rust-al" format reszesitenem elonyben, elvegre nem magyar szo, gondolom a "Rusttal" is helyes/elfogadhato. Szerencsere nem olyan gaz mint amikor a "deploy" iget ragozza valaki magyarul, az a halalom.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

Tényszerűen helytelen állítás. A ragozás azóta is változott, hogy én általános iskolában tanultam a Magyar nyelv helyesírási szabályai 11. kiadás alapján (jelengleg a 12. kiadás van érvényben, szóval igenis változott).
Arról nem is beszélve, hogy minden jövevényszó esetében a menetrend az, hogy eleinte kötőjellel, eredeti átírással, majd később esetleg fonetikusan, ragokkal egybeírva használjuk.

minden jövevényszó esetében a menetrend az, hogy eleinte kötőjellel, eredeti átírással, majd később esetleg fonetikusan, ragokkal egybeírva használjuk

Nincs ilyen „menetrend”: https://www.m-prospect.hu/helyesiras-3-idegen-szavak/

A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk.

A ragozás azóta is változott

A vonatkozó rész érdemben nem változott:

- Akh 11, 215.: "Az idegen írásmód szerint írt közszavakhoz és tulajdonnevekhez általában ugyanúgy közvetlenül (tehát kötőjel nélkül) tapasztjuk hozzá a toldalékokat, mint a magyar szavakhoz és tulajdonnevekhez: [...]"
- Akh 12, 215.: "Az idegen írásmód szerint írt közszavakhoz és tulajdonnevekhez általában ugyanúgy közvetlenül (tehát kötőjel nélkül) kapcsoljuk a toldalékokat, mint a magyar szavakhoz és tulajdonnevekhez, például: [...]" (<== Hazudtam!!! Itt megváltozott egy szó, eltűnt egy "hozzá", és belekerült a mondatba egy "például" -- hát nem ugyanaz a szabály!!!!!!)

A kötőjeles esetekkel a 217. szabály foglalkozik, a lényeg (=alapszabály) ebben sem változott. (Bár itt már egyértelműbb, hogy a 12. kiadásban némileg változott a szöveg.)

Egy szó álhír, mint száz: mind a 11. (1984-es!), mind a 12. kiadás szerint "Rusttal"-t kell írni. #T-nyellenőrzés4eva

> Arról nem is beszélve, hogy minden jövevényszó esetében a menetrend az, hogy eleinte kötőjellel, eredeti átírással, majd később esetleg fonetikusan, ragokkal egybeírva használjuk.

40 éves koromra derülne ki, hogy nem ismerem a magyar nyelvet? Valahogy kétlem. Be tudnád linkelni a megfelelő helyesírási szabályhelyet? Maga a könyv online itt van meg: https://helyesiras.mta.hu/helyesiras/default/akh12 és a legutolsó kiadása 2015-ben volt, azaz idestova 10 éve. De én életemben nem hallottam még helyesírás tekintetében "menetrend" -ről. Van esetleg valami időtáblázat is, hogy melyik vonat mikor indul? Hány év használat után lehet valamit fonetikusan írni?

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Rust-tal

És hogy miért volt, van és lesz ez így írva a HUP-on, azt mindenki találja ki. Akinek nem megy, majd adok példát, amin megnézheti, hogy miért van, volt és lesz így írva (az MTA meg elmehet a picsába az ajánlásaival, valószínűleg azokat normál magyar beszédekre és nem egy spec. IT oldalra hegyezték ki).

trey @ gépház

Példaábra:

https://hup.hu/comment/3165818#comment-3165818

(Ilyen helyeken jön ki, nem a mobiltelefonról véletlenül elkövetett typo-k esetén, ugyanis ez egy geci hiba, mert a helyesírás-ellenőrző nem jelzi. A fáradság és fáradtság is helyes, de abban a kontextusban a fáradtság hibás. Na, ez az igazi nyelvtan, nem a véletlen elgépelés)

trey @ gépház

Teljesen egyetértek trey-jel, én is így írom az összes ilyet, aminek nincs magyar megfelelője vagy nem tulajdon név.

Szerintem a szakmánkban ez az általánosan elfogadott, mondhatom azt is, hogy tájnyelv. Előbb-utóbb meghonosodik ez a szabály a nyelvünkben is, ha sokan használjuk ;-)

Nem, ezek nem idegen, hanem jövevény szavak. :)

Én a magam részéről ott használom a kötőjelet, ahol nem teljesen egyértelmű a leírt szó kiejtése, vagy lényegesen eltér a magyartól / nem illeszkedik jól a magyar hangok közé. Szóval pont a Rustot leírom szerintem így kötőjel nélkül írnám, de teljesen értem, hogy miért akarja valaki inkább kötőjellel írni ezeket.

Nem, ezek már pont olyanok, mint a telefon. Ezt használjuk rá magyarul. Igazodtak a magyar kiejtéshez. Senki nem mondja, hogy "ˈmänədər". Következésképpen nem is írom le, hogy monitorrel, pedig akkor szerintem így kéne ejteni (bár kétesélyes), és mivel ejtett hang az r, ezért nem kell a kötőjel. Viszont mint a konkrét példa mutatja, a másik hangrendű ragozás csatlakozik hozzá, mint amit a magyar fonetika kívánna. Tehát ha úgy ejteném, akkor jobb volna úgy leírni, hogy monitor-rel.

Ismerem a szabályt, szerintem rossz.

Szerintem a nyelvtan akkor fontos, ha másik fél vagy syntax errort dob rá, vagy félreérti. Amíg a csatorna másik végén lévő természetes vagy mesterséges intelligencia röptében javítja és JÓL értelmezi azt, amit írok, addig édes mindegy, hogy Rust-tal, Rust-al, vagy Russttal, vagy Rust nyelvvel. Ha megvan a kompatibilitás, akkor én nem szarozok ezzel tovább, ez pont olyan dolog, mint hogy mobilról ékezetek nélkül írok, mert egyszerűbb, kivéve azokat a szavakat amiket félre lehetne érteni az adott kontextusban.

A nyelvtani szabályok betartása segít, de nem kötelező. És bizonyos keretek között még csak nem is szegénységi bizonyítvány, ha valaki egy adott dolgot máshogy ír, mint ahogyan azt mások egy teljesen más környezetre és célra optimalizálva megalkottak egy olyan szabályegyüttest, ami globálisan valószínűleg elég jó, de lokálisan időnként simán érdemes lehet áthágni, ha ott és akkor nem célszerű a használata.

> Amíg a csatorna másik végén lévő természetes vagy mesterséges intelligencia röptében javítja és JÓL értelmezi azt, amit írok, addig édes mindegy, hogy Rust-tal, Rust-al, vagy Russttal, vagy Rust nyelvvel. Ha megvan a kompatibilitás, akkor én nem szarozok ezzel tovább, ez pont olyan dolog, mint hogy mobilról ékezetek nélkül írok, mert egyszerűbb, kivéve azokat a szavakat amiket félre lehetne érteni az adott kontextusban.

Íty yutotunk el a fészbuk nyelvhesz ahol tejesen ösze visza van minden irva de nem érdekeses mert a túl oldali fél tugya de kódolni.

Avagy a helyesírási szabályok használata elsősorban igényesség kérdése. Igen, lehet azt mondani, hogy "én lejjebb adok a szintből, mert..." és itt egy indoklás következik, de attól még lejjebb adtál a szintből, kész, ennyi. Nem szégyen ez, csak tudni kell a helyén kezelni. Azért gyakoroltatják annyit velünk az iskolában, hogy legalább azzal képben legyünk, hogy miből tudunk engedni. De szerencsére a legtöbb szabály amúgy meglepően logikus - még ha nem is úgy tanítják - a többi meg egyszerű annyira, hogy ne foglalkozzunk a logikusságával.

Alapvetően minden helyesírási szabálynak két állapota van: vagy betartod, vagy nem. Az, hogy te kitalálsz egy N+1 -edik szabályt, az egyszerűen csak annyi, hogy nem tartod be a meglevőt. 

Egyébként nem éri meg n+1 -edik szabályt kitalálni, főleg nem a helyesírásban: https://imgs.xkcd.com/comics/standards.png

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Egyrészt szerintem ez a konkrét eset nem szintből leadás. Én legalábbis azért extra kötőjelezek, mert a nyelvtan pont az nem segíti, ami a dolga lenne, hogy könnyen és pontosan értse meg az olvasó, ami oda van írva.

Másrészt nagyon népszerű fikkantani ezeket a mai fiatalokat, hogy még írni se tudnak, és fész nyelv van, csak ez teljesen figyelmen kívül hagyja azt, hogy ez egy teljesen új kommunikációs forma, gyakorlatilag a spontán élő beszéd helyett van, ilyen korábban sose volt. És nagyjából az történik, ami egyébként előbeszédben is. Ott is megy az ő-zés, hagyja le mindenki az n-t a -ban -ben végéről időnként, általában sokkal kevésbé szabatosan fogalmazunk, mint mondjuk egy beszédben, előadáson, akármin. Használják a fiatalok a saját szelngjüket, a szakmák a szakzsargonjukat. Más a cél, elég szűklátókörűség egy egyáltalán nem oda való mércéhez mérni. És logikus persze, logikus, mégis az van, hogy újságírók, rendes írók is rendre basznak el dolgokat (a tanító nénikről ne is beszéljünk ;) ). Lehet persze azt mondani, hogy azok is mind igénytelenek, ezzel együtt nagy átlagban ők sokkal jobban tudják, és sokkal jobban is figyelnek. Aztán mégis. (Illetve a kisördög azért benne van az emberben, hogy aki olyan szabályzatot ír, amiben rendszeres, hogy "az a szabály, hogy: xyz, kivéve, a, b, c, stb." az azért ne ugráljon olyan nagy mellénnyel :) )

Egyébként a fész nyelvnek van egy olyan vetülete, ami ilyen súlyosan technikai kényelmetlenségből fakad, nagyon gyanús, hogy a teljesen katasztrófa csupa nagybetű, központozás környéken se öregebb generáció simán csak fennakadt valamin. Gyerek volt óvó nénije világította meg nekem erősen, aki egyébként kifejezetten művelt, választékos nő, aztán írt a face csoportba, és, szóval jézusbazmeg.

az MTA meg elmehet a picsába az ajánlásaival, valószínűleg azokat normál magyar beszédekre és nem egy spec. IT oldalra hegyezték ki

Es akkor azt meg nem is tudod, hogy az MTA hogy megeroszakolta a kinai pinyin atirasi szabvanyt is.

Az egesz vilagnak megfelel a Xi Jinping nev (ejtsd ~Si Dzsinping, esetleg Si Csinping, inkabb Dzs az). Igy hivjak a vilagsajtoban majdnem mindenhol. Kiveve Magyarorszagon: ott Hszi Csin-ping -kent kell leirni. Szemely szerint unnepelnem, ha az ujsagirok ehhez nem asszisztalnanak es a nemzetkozileg elfogadott leiratot hasznalnak az MTA-s hulyeseg helyett. Mert aki beszel egy kicsit is kinaiul vagy tanult kicsit is kinaiul, mind egyetert abban, hogy az MTA "pinyin-ujrafeltalalasa" ugy szar, ahogy van.

Szokásos HUP-szakértés/balfaszkodás. Az ilyeneket - minek ez, minek az, miért így, miért nem kellene - mindig is ignoráltam, a magam feje után mentem és így lett a HUP az IT egy sajátos szegletének korhű lenyomata, dokumentálása az internet pöcegödrében, ami egyedülálló a maga módján. Így maradhattak itt fenn olyan dolgok, amik egyedülállóak a neten. Ha a HUP-szakértőkre hallgattam volna, ezek ma nem lennének.

Kthxbye

trey @ gépház

( carlcolt | 2025. 02. 19., sze – 15:15 )

Szerkesztve: 2025. 02. 19., sze – 15:15

Faszomat ma'

Ha annyira szar a C a Rust-vallasuak szerint, akkor csinaljanak maguknak sajat kernelt a Linuxot meg hagyjak beken, vagy fogadjak el, hogy a Rusttol majdnem mindent elvarnak a C-sek, amit a C tenyleg tud (tobb egymastol fuggetlen compiler, 40 eve kialakult standardok, amik ma rengeteg olyan edge case-t lefednek, amikre Rustnal meg gondolni se volt lehetoseg, stb.)

(Tudom, tudom, nem minden Rustos "Rust vallasu". Olyan is van, aki egy honapja meg csak a shellhez meg a pythonhoz ertett, aztan meg akart tanulni valami gepkozelibbet, hogy megse Pythonba' irjon mar drivert, de a C-t megtanulni nem volt eleg ideje)

amikre nem tudsz fordítót írni, mert egy rakás dolog a standard szerint nem definiált.

Néha elképedek, mennyire sötét emberek járnak ide a HUP-ra.

Egy: az, hogy a standard által nem definiált, miért jelentené, hogy nem lehet fordítót írni rá? Javaslom olvass utánna, mit is jelent a kifejezés (segítek: a fordító eldöntheti, hogy kezelje).

Kettő: ahhoz képest, hogy szerinted "nem lehet fordítót írni rá", rohadtul sok C fordító létezik, má' nem azé': Clang, gcc, xcc, MSVC, Intel C, Watcom C, tcc, chibi cc, SmallC, TurboC, Amiga C, MicroC, C--, Pacific C, DJGPP, C4...

Nem lehet, hogy nem is arról van szó, hogy "nem lehet fordítót írni" (hisz van egy valagnyi), hanem sokkal inkább arról, hogy "TE nem tudsz fordítót írni" és még arra is képtelen voltál, hogy utánnajárj, hány C fordító is létezik valójában mielőtt pofáznál? Már meg ne sértődj, de ha ennyire hülye vagy hozzá, akkor inkább jobb, ha csöndben maradsz és nem járatod le magad.

És mi a haszna a „tobb egymastol fuggetlen compiler”-nek meg a „40 eve kialakult standardok”-nak, ha a standardok nem biztosítják a fordítók közötti keresztkompatibilitást. (Szó szerint az egyetlen dolgot, amire a standardokat feltalálták.)

arc--; 

(de úgy tűnik ez nálad nem volt integer underflow-ra védve :D )

Természetesen szíved joga kötekedni, hogy valaki nem teljesen akadémiailag szabatosan fogalmazott egy fórumhozzászólásban. De a kontextusból - rajtad kívül - szerintem mindenki értette, hogy therion mire gondol. Hogy az általad felsorolt fordítók rohadtul nem ugyanazt a C dialektust beszélik és simán találni közöttük olyan párokat, amik között még egy hello world-öt sem tudsz módosítás nélkül átvinni. És akkor nem beszéltünk azokról a mocskos corner-case-ekről (pl over- és underflow kezelés) amik miatt ez az egész Rust téma felmerült.

Sajnos el kell fogadni, hogy a C már 55 éves és totálisan más világ volt a számítástechnikában, amikor Kerningham és Ritchie kitalálták. Sajnos az akkor megkötött (és akkor értelmes, indokolt) kompromisszumok - a rengeteg szándékosan definiálatlan viselkedés, ill. sokminden amire nincs nyelvi elem - többsége máig kísért. Hiába jött ki sok kiadása a C szabványnak, amiben kisebb nagyobb mértékben próbáltak foltozgatni rajta; a kompatibilitás totális eltörése nélkül inkábbcsak finomítgatni lehet, teljesen kiküszöbölni nem.

Arról nem beszélve, hogy a 2025-ben engedtessék már meg, hogy a C teljesen ellenőrizetlen (sok szempontból ellenőrizhetetlen) memóriakezelésénél valami több garanciát biztosító megoldást keressenek.

Régóta vágyok én, az androidok mezonkincsére már!

( joco01 v | 2025. 02. 19., sze – 15:32 )

Az én tapasztalatom egy többnyelvű kódbázis esetén: akkor működik, ha eldöntjük, hogy az új lesz a fő nyelv, és előbb vagy utóbb mindent átírunk abba. Ebből következik a válasz a Chris által felvetett problémákra.

Ahogy lehetőséget kaptam rá az első dolgom az volt a cégnél hogy kilövésre jelöltem az összes olyan nyelvet amelyet csak azért hoztak be mert valakinek éppen az hiányzott az önéletrajzából (lásd még CV driven development), és csak azt felejtette el hogy rajta kivül senki más nem ért hozzá, de legalább meg se akarja tanulni. Úgyhogy ott maradtunk egy rakás olyan service-szel amelyik nincs karbantartva, nem tudunk belenyúlni mert nincs hozzá szakértelem, de semmi olyat nem tud, amit a meglévő nyelvekkel ne lehetett volna hibátlanul megoldani.

többnyelvű kódbázis esetén: akkor működik, ha eldöntjük, hogy az új lesz a fő nyelv, és előbb vagy utóbb mindent átírunk abba

Na de ha mindent átírsz, akkor hogy lenne az már továbbra is többnyelvű kódbázis...? Én ezt sokkal inkább refaktorálásnak vagy komplett újraírásnak mondanám, semmint karbantartásnak.

> Na de ha mindent átírsz, akkor hogy lenne az már továbbra is többnyelvű kódbázis...?

A kevésbé fontos részek átírását évekig lehet halogatni. És a végén az is lehet, hogy vannak olyan alacsony szintű részek, amik sosem lesznek átírva (ahogy a mai napig van benne sok assembly is).

> Én ezt sokkal inkább refaktorálásnak vagy komplett újraírásnak mondanám, semmint karbantartásnak.

Egy nagy kódhalmazt, főleg a Linux kernelt, nem lehet csak úgy újraírni. Teljesen korrekt megteremteni egy második nyelv használatának lehetőségét és az interop megoldását, aztán darabonként lehet újraírni.

( joco01 v | 2025. 02. 19., sze – 15:34 )

> a fő karbantartókat már az olyan triviális dolgok is elriasztják, mint az integer túlcsordulás ellenőrzése 

C security in a nutshell. Jobb is, ha az ilyenek kihullanak, mert megijednek a Rusttól.

Tegyük hozzá, C-ben (pláne szabványosan, platformfüggetlen módon) overflow-t kezelni kifejezetten undormány dolog. Ráadásul extrém mértékben rá vagy utalva a fordító mintafelismerőjére, hogy egy ehhez hasonló a terjengős kódrészletből:

int add(int a, int b)
{
  if (a >= 0) {
    if (INT_MAX - a < b) {
      handle_error();
    }
  }
  else {
    if (b < INT_MIN - a) {
      handle_error();
    }
  }
  return a + b;
}

az optimalizáló rájöjjön, hogy valójában kb egy add, jo utasításpárost akartál borzasztó körülményes módon körülírni. Ja és persze ugyanezt meg kell csinálni külön kivonásra, szorzásra, signed/unsigned esetre...

Nyilván ha ér GCC-specifikus builtin-eket használni, akkor vannak kulturáltabb megoldások is: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html (az LLVM clang is átvette ugyanezeket: https://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins) De ezt nem mindenki vállalhatja be.

És akkor - most vagyunk a mostban - a C23 szabvány pár évtized után végre eljutott oda, hogy bevezették a stdckdint.h-ban (a fenti compiler-specifikus változatoktól természetesen eltérő) check integer függvényeket. Végülis jobb későn, mint soha...

Nyilván ez az egész nem valid kifogás, de sajnos a nyelv ügyetlensége évtizedek alatt ránevelte a fejlesztőket a rosszra.

Régóta vágyok én, az androidok mezonkincsére már!

C++-ban meg overload-olod az összeadást és kész.

Lesz belőle egy (valószínűleg) unhandled exception, abból meg egy oops vagy egy pánik. Rust esetén gondolom valami hasonló történik.

De azt bárki kiszámolta, hogy ha az összes aritmetikánál ellenőriznénk az integer overflow-t, akkor hányszor akkora vas kellene?

Egyébként sem kritikus minden esetben. Nyilván tömböt ne indexelj túl, de ha valami statisztikai értéknél fordul elő, akkor meg kit érdekel?

Alapvetően kb 3 iskola van:

  • a strucc - bedugjuk a fejünket a homokba és lesz ami lesz. Ez kb a userspace alkalmazások jelentős része. Hasonló a "longba már tutibiztos beleférünk" hozzáállás.
  • a matekozós - amikor sok számolgatásal és feltételezésekre építéssel kitalálunk egy olcsó input ellenőrzést, ami elvileg garantálja, hogy végig sehol nem lesz over/underflow. (jó törékeny, bármi módosítás, refaktor boríthatja)
  • a sebesség nem számít - mindenhol mindig legyen ellenőrzés, kerül amibe kerül

Egyébként az a vicc benne, hogy valójában szinte 0 költséggel lehetne ellenőrizni, mert a CPU mindig kiszámolja az overflow ill. carry biteket. Egy extra jo assembly utasítás (ezt hogy a tökbe lehet leírni, hogy NE legyen szóvicc belőle?! :) ) az aritmetikai művelet után és le van kezelve. Egy mai pipeline-olt, out-of-order, spekulatív, multi-issue CPU architekturán meg se érzed. A jo nem igényel ALU-t. A CPU párhuzamosan befuttatja az előző aritmetikai művelet jo-ját a következő aritmetikai művelettel (legfeljebb eldobja az eredményét, ha a jo-nál mégis ugrás volt).

Az egész attól lesz problémás és költséges, ha a programnyelv nem ad lehetőséget explicit leírni, hogy ezt akarod. A C23-ig a C pont ilyen volt.

Rust-ban a lényeg, hogy explicit meg kell mondanod mit akarsz. 4 féle opciót ad:

  • wraparound - mint a C-ben, figyelmen kívül hagyja a túlcsordulást, az érték körbefodul
  • saturating - túlcsordulásnál INT_MAX, alulcsordulásnál INT_MIN lesz az érték - jel vagy képfeldolgozásnál szokott ez kelleni. A CPU-kban manapság van dedikált utasítás erre.
  • checked - None típust ad vissza ha túlcsordult
  • overflowing - a wraparoundhoz hasonló, de egy tupple-ben a numerikus eredmény mellé kapsz egy boolean értéket is (a cpu overflow flag állapotát)

Mindegyik 1 vagy 2 assembly utasításra fordul.

Régóta vágyok én, az androidok mezonkincsére már!

C++-ban meg overload-olod az összeadást és kész.

C++ -ban nem lehet a beépített típusokra operator overload-ot írni, tehát mondjuk két int összeadására.

Nem kell hozzá nagyobb vas, a legtöbb CPU alapból adja, hogy volt-e overflow, és utána szinte költség nélkül van lehetőség a hibaágra ugrásra.

( Raynes v | 2025. 02. 19., sze – 17:48 )

Ja, az van, amit írtam az előző kapcsolódó hírhez. Itt kész tények vannak:
1) Linus egyszemélyi vezető, arra nem veszik rá, amit nem akar, a végén úgyis oda luykadunk ki, hogy az lesz, amit ő akar
2) addig fogják húzni a bajszát a rust-osok, amíg elege lesz, és inkább mással tölti a szabadidejét, pont ezt jósoltam.

Nem lett volna szabad a C-n kívül semmilyen más nyelvet beengedni, csak egyre több gondot fok okozni hosszú távon. Remélem nem a kernel sínyli meg, mert én úgy látom, hogy máris ez történik. Ezt nem is konkrétan a Rust ellenében írom, hanem akármelyikében. A Linux az mindig is egy C-s projekt volt, a fejlesztési módszerek is aköré alakultak ki. Felesleges ebbe a kialakult rendszerbe beavatkozni egy másik nyelvet, másik munkamódszert valló fejlesztőknek, csak állandó súrlódási forrás lesz. Ahhoz már a projekt túlnőtte magát, hogy alapjaiban rengessék most meg.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Linus egyszemélyi vezető, arra nem veszik rá, amit nem akar

Azért erre bőven van ellenpélda. Például amikor ráeresztettek egy faszkalapot, és amikor nagyon helyesen elküldte melegebb éghajlatra, ő húzta a rövidebbet, őt távolították el egy időre. Ezen kívül erős a gyanúm, hogy a Microsoft igencsak erős nyomást gyakorol rá a Linux Foundation révén. Nem hiszem, hogy önszántából támogatná a Rust-ot, a korábbi nyilvános nyilatkozatai alapján.

Nem lett volna szabad a C-n kívül semmilyen más nyelvet beengedni

+sok! Minden általam ismert többnyelvű projekt feleslegesen túl van bonyolítva és csak problémát okoz. Jobb és könnyebben karbantartható egy egységes build környezet.

Remélem nem a kernel sínyli meg, mert én úgy látom, hogy máris ez történik.

Én is így látom. TINFOILHAT ON A Microsoft belülről próbálja meg bomlasztani az egyetlen komoly kihívóját azáltal, hogy anyagilag pórázon tartja a döntéshozóját és ezáltal idióta, az open source közösségre káros döntések hozatalára kényszerítik. És ennek a sokévnyi aknamunkának az eredménye most már kezd meg is látszani. TINFOILHAT OFF.

( Dolphy | 2025. 02. 19., sze – 21:30 )

Na, ugy latom most mar a linux is uton van afele, hogy egy hasznalhatatlan szarkupac legyen. :)

( ssikiss | 2025. 02. 20., cs – 08:43 )

Szülési fájdalmak, majd elmúlik.