Elegem lett a sok nagyszájúból, ezért úgy döntöttem, lehetőséget adok nektek a gyakorlatban is bizonyítani, és egy versenyre hívlak ki Titeket!
Amennyiben nem érkezne egyetlen működőképes beadvány sem, vagy a C nyerne, akkor azt úgy kell érteni, hogy valójában a gyakorlatban egyik csodanyelv sem képes leváltani a C-t, és továbbiakban nem hangoztathatjátok ezt a HUP-on. Ha nem a C nyerne, akkor pedig vice versa, megígérem, hogy nem fogom a továbbiakban az orrotok alá dörgölni, hogy felültetek a hypenak és bedőltetek a marketing bullshitnek. Ez így fair, nem?
https://gitlab.com/bztsrc/langcontest
A feladat: egy olyan rendszerprogram írása, ami nem csinál mást, mint másodpercenként eggyel növel egy számlálót a képernyőn. Elég egyszerű, nem lehet probléma bármilyen nyelven megírni ezt, igaz?
A verseny szabályait igyekeztem úgy kialakítani, hogy azok a lehető legegyenlőbb feltételeket biztosítsák, bármilyen nyelvről és fordítóról is lett légyen szó, és igazságos összehasonlítási alapot szolgáltassanak:
- architektúrának a 64 bites x86-ot választom, mert arra minden nyelvhez biztos van fordító és könnyedén tesztelhető, ráadásul tele van hozzá doksival a net
- mivel nincs oprendszer, a betöltőt biztosítom, emiatt nem kell aggódni, nektek csak egyetlen lefordított rendszerprogramot kell csinálni
- bármilyen nyelv használható, az Assembly-t leszámítva (a betöltő teszteléséhez egy Assembly-ben írt referencia implementációt biztosítok)
- inline Assembly nem, csak az adott nyelv natív utasításkészlete használható, a forrásnak hordozhatónak kell lennie (azaz hiba nélkül le kell fordulnia többféle architektúrán, akkor is, ha úgysem működne ott)
- nem használható semmi olyan kulcsszó vagy opció, ami kikapcsolja a nyelv alap funkcióit, mert az úgy már nem a csodanyelv lenne (pl Rust-ban az unsafe/unmanaged, vagy C++ alatt az -fno-exceptions/-fno-rtti nem megendegett)
- bármilyen más kulcsszó, parancssori opció használható, akár fordítóspecifikus, architektúraspecifikus is (például hívási, optimalizálási, ellenőrzési, kódgenerálási, linkelési stb., bármi más mehet, csak a nyelv alapkészletét tilos leszűkíteni)
- bármilyen fordító megengedett, ami képes az adott nyelvet lefordítani (például Go esetén gcc-go/golang, C esetén gcc/Clang stb., semmilyen megkötés nincs a fordítóra)
- bármilyen szabványos függvénykönyvtár használható, ami a nyelvvel és a fordító telepítésével együtt érkezik vagy Ti írjátok, de harmadik féltől származó, netről letöltött nem (ha a nyelvnek van bare metal változata, természetesen azt is ér használni)
- bármilyen fordítási segédprogram megengedett, olyan is, amit külön kell telepíteni vagy saját fejlesztésű (például interface bindolók, fejléc generálók, linker szkriptek, binutils, make/mk/cmake/ant/scons/meson/ninja/azanyjakinyja stb.)
- a lefordított program nem lehet nagyobb, mint amit egyetlen BIOS hívással be lehet tölteni a lemezről (65024 bájt)
- a képernyőre VGA teletype módban kell írni (ASCII karakter (0x30 - 0x39) + attribútum (0x07 fehér) párosokból álló tömb a 0xB8000 fizikai címen a Video RAM-ban)
- a pollozás nem megengedett, mert az nem lenne sem hatékony, sem energiatakarékos, sem pontos
- a program megírására 1 hónap áll rendelkezésre
- egy program többször is módosítható és többször is beadható ez idő alatt, a legutolsó fog számítani (lehet reagálni a mások által beadott pályaművekre, és lehet újabb optimalizációkkal előrukkolni)
- a nyertes az a program, ami a legkevesebb segédprogramot, kulcsszót és specifikus opciót használja az adott nyelv készletéből (magyarán ami a legkevésbé gányolt), ezen kívül pedig ami legkissebb bájtméretű, működő binárist produkálja, holtverseny esetén meg ami a kevesebb memóriát fogyasztja futás időben (vermet is beleértve)
A felsorolt limitációk a hardveres futási környezet sajátosságai (long mód, BIOS betöltés, VGA képernyő), ezek nem megkerülhetőek, muszáj alkalmazkodni hozzájuk.
Elvileg a 64 bites long mód nem tartozna ide, de ennélkül már a verseny indulása előtt nyerne a C és elvérezne az összes többi csodanyelv... :P De jófej leszek és esélyt adok nektek, így legyen hát 64 bit only.
A függvénykönyvtárakra vonatkozó megkötés azért került bele, hogy csak a nyelv maga számítson. Standard lib használható, de el is hagyható, 3rd party lib viszont tilos, mert az már nem a nyelv része.
Hogy a fordítási környezetből adódó eltéréseket is kiiktassuk, két betöltőt is biztosítok: az első ELF binárist tölt be, és SysV ABI-t használ:
cat boot_elf.bin programod.elf > disk.img
A másik pedig PE/COFF binárist és MS fastcall ABI-t (pont, mint az UEFI):
cat boot_pe.bin programod.exe > disk.img
Mindkét esetben az elkészült virtuális lemezt qemu alatt, a következő paranccsal kell tudni futtatni:
qemu-system-x86_64 disk.img
Hogy a programokba tényleg ne kelljen Assembly betét, a betöltő a bináris fejlécében megadott linkcímekre másolja a szegmenseket, kinullázza a bss-t, beállítja a vermet lefele növekvően 640K-ra, az alacsonyszintű CPU utasításokhoz pedig interfészt és wrapper függvényeket biztosít, mielőtt a belépési pontot meghívná.
Relokációt nem végez, a programot linkeljétek valaholva a 96K és 640K vagy az 1M és 2M közé, ahová jólesik, és több szegmensből is állhat akár.
Az interfészt pontosan ugyanúgy kell használni, mint UEFI esetén, csak itt más függvényeket tartalmaz. Ennek a C nyelvű definíciója:
typedef struct { void (*load_idt)(const void *buffer, const uint16_t size); /* betölti a megszakításkezelőket */ void (*enable_interrupts)(void); /* engedélyezi a megszakításokat */ void (*disable_interrupts)(void); /* letiltja a megszakításokat */ void (*iretq)(const int localsize); /* visszatér a megszakításkezelőből */ } almost_efi_system_table_but_not_quite_t;
A program belépési pontja egy mutatót kap paraméterül erre a struktúrára, pontosan úgy, mint UEFI-nél.
EDIT: mivel sokan sírtatok, ezért módosítás: az összes paraméternél kiírtam, hogy const, ha ez nem lett volna egyértelmű, és ezeknél a függvényeknél, és szigorúan csakis ezeknél az interfész által biztosított függvényeknél használható Rust alatt az unsafe. VAGY Az interfészt egyáltalán nem kötelező használni, le is implementálhatjátok ezt a négy függvényt Rust-ban, ekkor azonban nem lesz külsős függvényhívás, így ilyenkor tilos az unsafe.
Továbbá, hogy még a hardverprogramozási készségek se számítsanak, és tényleg csak a nyelveket mérjük össze, a betöltő megteszi azt a szívességet is, hogy előre felprogramozza a megszakításvezérlőt valamint a PIT-et másodpercenkénti 100 IRQ megszakításra, azonban nem kezd megszakításokat generálni, míg az enable_interrupts() függvényt meg nem hívjátok.
Hasonlóan az iretq() hívás gondoskodik a megszakításvezérlőben az IRQ nyugtázásáról is, így azzal sem kell törődnötök. A load_idt() híváshoz segítségként, 32 kivételfajta van és 16 IRQ, a kódszelektor a 32-es, a megszakításkapu attribútuma meg a 0x8E.
Itt az alkalom, hogy bizonyítsátok, a Go, Rust vagy bármelyik másik agyonhypeolt csodanyelv valóban képes lehet a C leváltására! Én állítom, hogy nem, bizonyítsátok be, hogy tévedek! Versenyre fel!
Hozzászólások
Ez nem bizonyítás. A te környezeted egy speciális eset.
És mégis ugyan, mi lenne benne a speciális? Egyetlen számlálót kell növelni és kiírni a képernyőre. Ennél faékebb feladatot nem tudtam kitalálni.
Megadott feltételek mellett.
Semmi olyan feltétel nem szerepel, amit egy rendszerprogramozási nyelvnek gondot jelethetne. Semmi.
Sőt, még kifejezetten könnyítettem is a feltételeken, normál esetben nektek kéne felprogramozni a PIT-et és a megszakításvezérlőt, de itt ezt megteszi helyettetek a betöltő.
Arra gondolok, hogy a C jogosultsága bizonyos helyeken nem kérdés (lásd akár a saját példád), bizonyos helyeken pedig ma már ésszerűbb egy magasabb szintű programozási nyelvet használni. Emiatt a te példàd nem bizonyítja azt, hogy hülyeség lecserélni a C-t. Ekkor nem beszéltem az üzleti érdekröl és gazdaságosságról sem, mely szerint egy modernebb magasabb szintű nyelvhez van munkavállaló is.
Én meg arra gondolok, hogy a magyar nyelvű szövegértés meghaladja az értelmi képességeidet, mégse hangoztatom ezen véleményem.
Nyilván, mivel a példámban (egy számláló növelése és kiírása a képernyőre) az égadta világon semmi C specifikus sincs. Sosenemis volt cél!
Mégegyszer, a célja a versenyek az, hogy bebizonyítsátok, nemcsak a szátok jár. Eddig csúfosan felsültetek, mert még egyetlen megoldás sem érkezett. De még van idő bizonyítani.
Telibeszarom azt ami a fejedben van. A másik topikot el sem olvastam, ezt a posztodat is csak félig, mert meguntam, Elbeszélünk egymás mellett. Te valami másra válaszolsz.
Még mindig nem árultad el, mit is értettél "speciális eset" meg "megadott feltételek" alatt. Merhogy azokban aztán semmi C specifikus sincs.
Most már jól látod mire reflektáltam. Pont erre, hogy ez nem bizonyítás, amit te annak hívsz. Függetlenül annak tárgyától, mert az engem speciel nem is érdekel.
https://hu.m.wikipedia.org/wiki/Matematikai_bizony%C3%ADt%C3%A1s
kulonben is megmondta hogy itt mindenki bunko troll es szemelyeskedik, mikozben o probal intelloigensen megfogalmazni velenyeket a sok szarfaszunak: "Én meg arra gondolok, hogy a magyar nyelvű szövegértés meghaladja az értelmi képességeidet" :)
En csak a popcorn miatt jottem, de a zsurizes szempontjait nem ertem. Attol fugg, hogy levalthato-e a C, hogy hany kulonbozo kulcsszot hasznaltal a kodban? Miert relevans az?
Nem. Azonos nyelvű pályaművek esetén dönt az, hogy melyik megoldás kevésbé gányolt. Például két működő Rust-ban írt megoldás közül az a befutó, amelyik kevesebb speciális opcióval valósítja meg ugyanazt.
Akkor csak elkerulte talan a figyelmemet, de igy nem vilagos, mit jelent a "vagy a C nyerne".
De, nagyon is világos. Felesleges kifogásokat keresned, küldj be egy megoldást inkább.
Dehogy kuldok, egy sort nem irtam meg Rustban. Barmi, amit bekuldok, az sokkal inkabb az en Rust-szuzessegemre refeklektalna, mint a C-hez kepest nyujtott lehetosegeire a nyelvnek.
Ettol meg erdekelhet, hogy milyen szempontok alapjan lehet barmirol kategorikusan kijelenteni, hogy "jobb", vagy "rosszabb" a masiknal. Mondott egyaltalan barki olyat, hogy a Rusttol kisebb lesz a binaris merete?
Hát, valamilyen egzakt módon mérhető metrikát csak fel kell állítani. Te mit javasolnál helyette?
(A bináris méretét nézni egyébként egyáltalán nem ördögtől való, ha van két program, ami pontosan ugyanazt csinálja, de az egyik 2 kilobájt, a másik meg 400 Megabájt, akkor nem kérdés, melyik a jobb a megoldás.)
>Te mit javasolnál helyette?
Például, hogy a szerző bizonyítsa be matematikai precizitással, hogy ha a fordító és a runtime a nyelv specifikáció szerinti szemantikáját maradéktalanul betartja, akkor a programja biztosan nem címez félre és nem leakel :-P
Erre egyébként nem válaszoltál, hogy mitől változott meg a b értéke észrevétlenül, mikor nem volt átadva paraméterként, és be volt kapcsolva az address sanitizer is: https://hup.hu/comment/3035799#comment-3035799
Rendben, hol van ez a matematikai bizonyítás a Rust esetén? Várom a dolgozatodat!
Szerintem nagyon sokaig fogod varni. :)
Nem, mert én tudom, mi az a szarkazmus.
Ha a 400MB-os is ellatja a feladatat akkor felolem az is jo. Nem, nem jobb a 2Kb-os csakis akkor ha kvarcorara akarom rarakni. De ha egy Spark clueteren akarom elinditani es masfel percig indul a 400MB-os progi, de aztan stabilan fut, konnyebb supportalni es odaadni egy juniornak es tobb feature-el randelkezik mint a 2KB-os akkor az a jobb.
Ennyi.
Nem erdekel kinek nagyobb a fasza. :D
És ebben hol is tettél javaslatot egy jobb metrikára?
Hát, azért nagyon nem mindegy, hogy egy egyszerű program 0,002 vagy 400 MB, az azért 200 ezerszeres különbség. Még a mai hardveren sem. Az a baj, hogy mindenki így gondolkodik már, hogy legyen minden 400 megás, Electron alapú fos, az is lehetőleg valami konténerizált csomagformátumban, ami betölti a saját libjeit még külön, és csodálkozunk, hogy az isten RAM-ja se elég.
A 400 megás progival meg nem csak az erőforrás-használata a baj, hanem, hogy a fejlesztőnek is több időbe telik minden egyes fordítás és debugolás, ami egy 2KB-os programnál megint kb. arányos különbség. Valószínű a függősége is több a 400 megásnak, meg nagyobb eséllyel törik el egy frissítéskor is.
Azt se feledd el, hogy nem kell feltétlen kvarcóra, mai napig vannak beágyazott eszközökön, SBC-ken, ipari vezérlőkön futó kódok, és ezek a hardverek kb. 486-os szintűek néha. Teljesen valós felhasználási igény, hogy egyes kódoknak ezeken is futnia kell.
A versenyen lehet részt veszek, de még nem ígérem biztosra. Egy C kódot nem nehéz szerintem rá megírni, de annyira egyszerű feladatnak tűnik, majdnem Hello World szintje. Tudom a kiírás tiltja, de poénból megérné ASM-ben írni, sose írtam még 64 bites x86 ASM kódot.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Egyetertek veled. Ha beagyazott eszkozre kell akkor igenis szamit a meret. De egy streaming app eseten ami egy tobb szaz node-os spark clusteren fut ahol a node-oknak egyenkent van 300+ GB memoriajuk inkabb azt nezem, hogy az app elvegzi e a feladatait ugy ahogy az kell neki, magabiztosan es biztonsagosan es minden feature-el amivel rendelkeznie kell. Es nem nem erdekel mekkora a meret (amugy nem lesz 400MB :D)
Az a baj, hogy nem igaz hogy "mindneki ugy gondolkodik". Amit irtal hogy electron meg mifaszom (ahogy latom a Go-t is elohoztad) az korulbelul desktop felhasznalas es azt le se szarom. :D
Az a baj, hogy hiaba mondom nem erti meg a tema nyitoja, hogy nem szukseges semmit sem bebizonyitania. Mert nincs mit. Ezert is kerdeztem hogy kinek akar es mit bizonyitani. Mi foglalkozunk IoT-val is, biztosithatlak hogy ott nem scalaban van megirva az app, ami fut a kis szenzoron.
Azt hogy mi miben van megirva a cel hatarozza meg, de neha meg az sem hanem az uzlet. A valo eletben persze. Mert hobbi porjektet mindenki abban ir amit akar. :D
Nálunk is volt olyan függvény, amit C-ről írtunk át PySpark-ra. Lehet, hogy az egyszálú teljesítmény lassabb, de a spark implementáció száz node-ra is skálázódik gond nélkül. Olyan teljesítmény növekedés volt, hogy mindenkinek leesett az álla.
Ne vedd mar szo szerint, legyen mondjuk a 0.002 es 0.004, a kulonbseg ugyan meg mindig ketszeres, de a gyakorlatban egy-ket specialis esetet kiveve senkit nem erdekel.
De vegye csak szó szerint. A számokat nem hasraütésszerűen írtam, hanem életből vett példa. Ablakos alkalmazás, ami egy lemezképet kiír egy meghajtóra: Balena Etcher, többszáz MEGAbájtos electron alkalmazás, versus USBImager, ami párszáz KILObájtos egyetlen függőség nélküli portable executable. Mindkettő nyílt forráskódú, ingyenes, azonos felhasználási feltételekkel bír és mindkettő képes tömörített lemezképet is kiírni.
szoval akkor mind a ketto jo arra, hogy egy tomoritett lemezkepet kiirjon azt mondod.
Attól függ: ha a homeserveremre kell, hogy lássam, mikor megy a következő metró, akkor az ára + licenc pl nekem sokkal nagyobb tényező, mint hogy mi a mérete - úgyis fillérek már bármilyen hardver. Ha munkakörnyezetbe kell, akkor valszeg a projekt / megrendelő által elvárt követelmények (adott hardver, SLA, ár) lesznek a fő szempontok, és hogy, hogy melyik mennyire teljesíti azt.
Generikusan ki jelenteni, hogy az egyik jobb, mert kisebb, hát...
Na, mégegy kötözködő, aki csak pofázik, de megoldást, azt bezzeg nem küld.
Ha nem lett volna nyilvánvaló a leírásomból, a két megoldás MINDENBEN azonos (ár, licensz, SLA stb.), csakis a méretük különbözik, semmi más.
Azt hittem, ennek tízévesen vége, hogy a melyik a legjobb konzol jellegű vitákra verjük ki.
Ha mindenben azonos, akkor nyilván méretben is. Ha a méretben eltérnek, akkor nyilván másban is el fognak - hogy csak a legtriviálisabb kettőt említsem, az eddig ráfordított erőforrásban, meg az esetleges változtatások által igényelt ráfordítás mértékében.
Na, mégegy kötözködő, aki csak pofázik, de megoldást, azt bezzeg nem küld.
Vagy lehet, hogy nem mindenki ugyanazzal az ertekrenddel nezi a vilagot, mint te. Miert nem ilyenben gondolkodsz, ha versenyezhetneked van? https://www.ioccc.org/
Nincs versenyezhetnékem. Lehetőséget adtam nektek, hogy a gyakorlatban is bizonyítsátok, nemcsak a szátok jár.
Hát az már biztos! A legtöbb faszkalap úgy mondana a helyemben ítéletet, hogy nem adna lehetőséget a másik félnek bizonyítani. Én valóban nem ilyen vagyok, én biztosítom a lehetőséget Nektek. Kár, hogy eddig még képtelenek voltatok élni vele, de még van idő beadni legalább egy megoldást.
Tippem szerint ennek a fő oka az, hogy jól látszik, hogy Frankói magasságban van a magabiztosságod, és a bármi minimális más vélemény/szemszög befogadásának képessége, ami miatt borítékolható, hogy ebből érdemi álláspont változás nem lesz senkinek se, hiába csinálná meg valaki. Cserébe gyakorlatilag nem tudsz lekicsinylő személyeskés nélkül megszólalni, ezért senkinek nincs kedve veked játszani.
És milyen bizonyítékokkal szándékozol alátámasztani ezen állításaidat?
(ps: a magabiztosságomnak empirikus oka van, nem máté' Nektek is simán lehetne, ha a megoldással foglalkoznátok irogatás helyett.)
ps: a magabiztosságomnak empirikus oka van
- Azt hiszi maga nagymenő, mert menő klubokba jár, mert bombanők lefekszenek magának? Azt hiszi maga nagymenő, mert lebuktatta azokat a kazetta-kalózokat?
- Beláthatja, hogy van elég okom rá.
Semmivel. Egyrészt alátamasztják a te kommentjeid bőségesen, másrészt a suli udvarán se szokták elmagyarázni a toxikus, folyamatosan bunkó kiskampónak, hogy mi a baj, egyszerűen egyre többen, egyre nagyobb ívben kerülik ki, ahogy egyre hangosabban mondja, hogy mind hülyék vagytok, és nem igazán érdekel senkit, hogy elhiszi amit mondd, meg önigazolja magának, hogy igaz, mert nem vesznek részt az izéjében.
Megoldani meg nem akarom, sose foglalkoztam ilyen alacsony szintű sajtreszeléssel, csk ha muszáj volt, nem mozgat, meg nem is akartam sose kicserélni a kedvenc nyelvedet. Értelmes beszélgetést viszont szívesen olvastam volna, mert láthatóan te se vagy járatlan ezekben, és vannak még egy páran itt, akiknek szintén érdekes meglátásai szoktak lenni. Sajnálatos, hogy a kommunikációs deficited ezt ellehetetleníti.
Az "krambó" nem pedig kampó.
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
Már ahol.
De hat en nem akarok bizonyitani semmit. Privatban lehet megkeresni konkret dijazas megjelolesevel, ha valaki szeretne, hogy szoftvert fejlesszek neki. Nekem jo ugy is, ha szerinted csak a pofam jar.
Rendben, de tarsd is be amit itt és most ígértél, és soha ne akard bizonygatni, hogy a Go/Rust/Kiskutya/legutóbbihype leváltja a C-t! ;-) Szavadon foglak!
Csinaltam mar valaha ilyet? :)
Eppen olyan objecktiv alapon, mint hogy a szokek vagy a vorosek tetszenek e jobban :D
Melyik a szebb? Mindegyik!
Amennyiben D kosarasak a csajok :D
A kosarasból is vannak szépek. Meg a köztes skálán is.
jaja, ugy vagyok a csajokkal, mint gomobc artur a csokival
Szerintem te félreérted, hogy hol lehet célszerű Rust-ot használni C helyett. Nem a kódsoroknak abban a 0.01%-ában, ami pl. a kernelek leghardverközelibb része. Hanem a többi 99.99%-ában.
Nem kerülte el a figyelmem. Pontosan ezért lett kiírva ez a verseny úgy ahogy, az összes általad 0.01%-ba sorolt hardverközeli dolgot megoldja helyetted a betöltő, Neked csak a maradék 99.99%-át kell hozzáadnod.
Nem véletlen, hogy a betöltő minden alacsonyszintű CPU utasításhoz biztosít egy wrapper függvényt, amit szabványosan meghívhatsz, mint bármelyik másik függvényt.
A videómemória közvetlen írását hová sorolod? Az egy eléggé hardverközeli dolog.
Továbbra sem akarod megérteni, hogy a Rust a helyességi ellenőrzéseivel pont hogy nem az ilyen feladatok miatt lett bevezetve. Az ilyen dolgokra maradnak az eddigi módszerek, pl. a C, vagy Rust unsafe.
Mikor jon az a resz, amikor eloadod, hogy "senki nem mondta, hogy a C-t valtja le a Rust" es akkor linkelhetjuk, hogy de?
Uncsi mar!
Nyugodtan linkeld, ahol én ilyet mondtam. Mások nevében nem nyilatkozok.
Esetleg valami érv, vagy érdemi válasz?
Hat a 99.99%-ot a parent parentjeben egy atlagos szakujsagiro 100%-ra kerekiti - innen indul a feszultseg.
Erdemi valasz:
Amugy inkabb 98%-2%, vagy 95%-5% lesz az szerintem.
Pl. openssl forkot irnal Rustban? Hasznalnad a C-s openssl/libressl/boringssl helyett?
Irtam en mar python + bash komboban drivert, mert csak arra volt ido. Jol performalo nem volt, de mivel percenkent 8 packetet se kellett kikuldeni a soros porton, "senki nem vette eszre".
Azert hozok peldanak SSL-t, azt van, hogy masodpercenkent sokszor szamolja a rendszer, megsem hardverkozeli.
Van ilyen: Rustls.
Vannak akik használják production-ben, még olyanok is vannak, akik ezt ajánlják openssl helyett. ;-)
A fenti reddit fórumban épp azt írják, hogy sokkal gyorsabb a Rustls, mint az Openssl.
Elolvastam a fenti reddit forumot, sok szempontbol ajanlottak, de azt az informaciot nem talaltam meg, hogy gyorsabb, sem azt, hogy az hogy lett merve.
Csak írták, hogy gyorsabb, mérés nem volt mellette. Pl.:
might be
Ugyan, ne bohockodjunk mar. Aki irta, az is bevallja, hogy csak tippel.
Én pl simán lehet, hogy igen, az openssl tipikusan olyan, amiben -- és ezt a vele sokat dolgozó kollégák mondják -- a crypto jó, a kód egyébként programozó szemmel finoman szólva nem az igazi, látszik, hogy kriptósok írják, tehát látnék benne hozzáadott értéket, ha az eszköz, amiben fejlesztenek a memoria kezelési hibák esélyét jelentősen csökkentené.
OTOH ebből a szempontból azért nem annyira rossz az openssl track recordja egyébként.
En meg szeretnem ha olyan programot irna valaki barmilyen nyelven, ami egy kafka streambol kiveszi a JSON uzeneteket, majd bizonyos mezok alapjan a megfelelo DB-be kuldi, ami lehet PostgreSQL, ES, stb. A program stateless legyen, de egy cachebe rogzitse a szamlalokat, valamint kepes legyen logolni JSON-ben mint formatumban es kezeljen sink-eket mint tavoli syslog, ES, Clickhouse endpointokat. Legyen neki egy monitoring API-ja es egy prometheus endpointja is (/metric), ami a cache-ben tarolt szamlalokat adja vissza.
Az alkalmazasnak kepesnek kell lennie bufferelni az adatokat, ha a storage endpoint nem erheto el, vagy reprocessalnia oket a kafka topikokbol.
Aki akarja irja meg C-ben, de mehet felolem Rust-ban is. :D
És ez a feladat hol is bizonyítá, hogy képes egy nyelv a C leváltására? Ez sima alkalmazásprogramozás, ráadásul a lényege egy tucat 3rd party lib használata, aminek semmi köze a nyelvhez magához.
Ugye, ugye...akkor mitol lenne a C a legjobb nyelv? Attol, hogy megtalaljuk azt a teruletet, amiben a legjobb, masra meg nem azt hasznaljuk ha nem az a legjobb.
A Te feladatod "versenyeztetni" a C-t egy olyan esetben, amire de tenyleg a C a legjobb.
Azt nem ertem, hogy mit akarsz elerni vele? Kinek akarod bizonyitani, de meg inkabb hogy mit is? :D
TROLL. Ezt senki sem állította, a verseny célja az, hogy bebizonyítsátok, a csodanyelveitek egyáltalán képesek-e azt a funkcionalitást biztosítani, amit a C kisujjból kiráz.
Eddig csak nyafogást, kifogásokat és trollkodást sikerült produkálnotok, bárminemű bizonyítást kevésbé. (És egyébként pont ezt is vártam, nyilvánvalóan csak széjkaratéban vagytok erősek, de a programozáshoz nem is értetek, pont ahogy sejtettem.)
Az egesz thread egy trollkodas, nem ertem, hogy mit vartal.
Valamilyen random hupu altal bekuldott kodok alapjan te majd eldontod, hogy "továbbiakban nem hangoztathatjátok ezt"? Miert, te ki vagy, mar ne is haragudj? En peldaul innentol minden C-s threadbe bele fogom kommentelni, hogy Rustban sokkal faszabb lenne megcsinalni ugyanezt. Csakazertis. :P
Ember, eletemben nem programoztam komolyan. Mi a faszt akarnek Neked bebizonyitani. Respect azert amiket irtal, a rendszerbetoltoidnel is leirtam hogy ez igen bazdmeg kemeny pocsu legeny vagy. So fuckin' what?
Dolj hatra es nyugodj meg, mert igazad van. Kurvara nem ertek a programozashoz. So fuckin' what?
Ugyanakkor tovabbra is az a kerdes, hogy mi a faszt akarsz bizonyitani es kinek?
Azt kerdezed, hogy egy nylev kepes e egy szamlalot novelni? Mert ez igy egy altalanos tema amiben ossze lehet hasonlitank azt hogy egyes nyelvekben milyen implementaciokat lehetne megirni. Aztan elkezded szukiteni a lehetseges eseteket es azt mondod, hogy rendszerbetolteskor? Ezzel azonnal kixarva egy csomo nyelvet.
Szoval akkor csinalok egy versenyt, hogy ki tudja nalam jobban megfozni a kedvenc brassoimat az en szajam ize szerint. Mar tudom is hogy ki nyerne. :D
Na akkor mégegyszer, ez a versenykiírás azoknak szól, akik folyamatosan tépik a szájukat itt a HUP-on, hogy a Rust-nak, Go-nak meg a többi csodanyelvnek le kéne váltania a C-t.
Ez a verseny nekik szól, hogy bizonyíthassák, ez egyáltalán lehetséges-e. Egyelőre még egyetlen egy működő PoC-uk sincs.
na azok is pont olyan evangelistak, mint Te.
Let the religious war begin!!! :D
hobbiprojekteken azt csinaltok amit akartok. Allhat a pocok a C-re, Rust-ra Go-ra, Scala-ra, Python-ra
Az uzlet meg majd eldonti, hogy melyik kell eppen az adott problemara mennyiert mennyi ido alatt es meddig. :D
Kivéve, ha az a pöcök alkalmatlan a feladat megoldására. Akkor mondhat az üzlet akármit, nem fog menni, csak csőd lesz belőle.
Továbbra is várom a megoldásaidat, mert küldeni még egyet sem küldtél. Írhatod Rust-ban, Go-ban, sőt, még akár Python-ban is! Szeretném látni!
Az a baj, hogy amit eddig irtal azt sejteti, hogy fogalmad sincs az uzletrol. Mindenben meg lehet irni mindent. es meg csak az sem biztos hogy a legalkalmasabb eszkozben kell. Sot az sem biztos hogy e legjobb minosegben kell megirni. Sok mindentol fugg. Sot a scope novekedesevel vagy valtozasaval valtozhat az is, hogy mi volt addig a megfelelo es miert.
De tenyleg nem varom el hogy megertsd mert latom, hogy olyan messze allsz az uzleti elettol, mint en a C programozastol :)
Bocs, de nem értem meg, miért akarod előre megtrollkodni ezt a versenykiírást.
A kiíró előre leírta, hogy rendszerprogram, leírta a feltételeket, leírta a pontozás részleteit. Azt mondhatod, hogy pl Rust unsafe az kellene, és később módosított is a kiíráson.
Nyilván neki is van prekoncepciója, neked is. De míg ő szeretne empirikus bizonyítékot, te azt mondod: hidd el, hogy …., és amúgy is lejt a pálya stb… Mivan akkor ha egy Rust mágus odabasz valami tuti programot, és a kiíró is belátja, hogy tényleg ez a Rust program csak 20%-kal szarabb de eléggé ígéretes stb… Vélhetően a C lesz a nyerő, de engem érdekelne, hogy a többi nyelv úgynevezett hatékonyságban hogyan áll az ilyen feladatok esetén ( én is C kalapáccsal verek be minden szöget, ki is röhög a fiam érte )…., mert hat erre jó a fórum, vagy mi a faszom?!
Mert ez a verszeny: "legem lett a sok nagyszájúból, ezért úgy döntöttem, lehetőséget adok nektek a gyakorlatban is bizonyítani... hogy valójában a gyakorlatban egyik csodanyelv sem képes leváltani a C-t"
Aztan utana megalkotta azt a kiirast amiben nagyon nagy valoszinuseggel a C fog kijonni gyoztesen. :D
Ez ugyanaz, mintha azt mondom (az o stilusaban): "na sok kis faszkalap, akik semmihez sem ertetek (mert o ert C-hez es mindan mas csak demagog faszsag, tehat ami azon kivul van az szar), csinaljatok egy jo kajat, de legyen benne csirkemell, liszt, tojas, zsemlemorzsa. En megcsinalom a rantotthust, ti meg probaljatok barassoit, lassagne-t csinalni belole, lassuk meg melyik kis csokottnek sikerul az ami nekem"
Most a tobbi hulyeseget az uzleti eletrol meg minden masrol hagyjuk is. :D
Ok értelek. Csak azt fontold meg pls:
Scenario 1) ( jelen helyzet ): A kiírást ekézitek, 100 hozzászólás arról szól, hogy mekkora idiótaság az egész, és amúgy sem ér semmit az eredmény. Eleve evvel lehúzzátok az egész szakmaiságát, a pályázók által letett eredményt, mert mínuszról indul az egész. Mindenki vérmérséklete szerint basztatja a másikat. A faszméregetés nem vezet eredményre.
Scenario 2): Kiírásra szakmai javaslat: pl Rust unsafe használata. Pályázatok beérkeznek. Mindenki boldog. Szakmai vita elindul, hogy ez ezt csinálja, ez azt stb…, mi miért jó és hatékony, és mi az előnye ennek/annak. Esetleg más szempontok is bejöhetnek stb… Esetleg megismerhetjük pár dologról a bzt szakmai véleményét ( mert az van neki ), esetleg belátna ő is valamit, amit majd egy sör mellett megköszönne ha öreg lesz stb….
A legjobb ügyek is ott akadnak el, hogy az emberek úgy érzik, hogy mindenképpen először a farkukat kell összemérni, pedig evolúciós szempotnból az együttműködés célravezetőbb. Aztán utána már lehet hozni a centit, ha már van produktum.
Senki az eg egegyadta vilagon nem kerdojelezte meg bzt szakmai tudasat. Sot meg en is iszonyatosan tisztelem, amit el is olvashatsz a masik topicokban.
Tiszteletteljesen felhivtak a figyelmet itt egy par dolgora:
1. Senki sem mondta hogy akarmi is levaltja a C-t. Azt maximum, hogy vannak teruletek ahol celszerubb mast hasznalni es nem biztos hogy technologiai okok miatt, hanem uzleti okok miatt
2. A fenhejazo, onmagat piedesztalra emelo, masokat csuklobol lenezo stilus nem fog segiteni abban, hogy ez szakmai forum maradjon
Az a baj, hogy a hatalmas egoja mellett meg sertodekeny is. Es sajnos a sertodekenyseg szemuvegen keresztul egyszeruen nem volt hajlando megerteni mit akarunk mondani. Ha a kiirasbol kivette volna a sertodekenyseget semmi baj nem lenne. Olvasd el a kiirast az elso par mondat nelkul meg azokkal egyutt.
De hogy szakmai is legyek (amitrol mar itt is irtam parszor), korulbelul 2005 tajeken hagytam abba azt, hogy mindenfele teszteket olvassak nyelvek es forditok osszehasonlitasarol teljesitemeny, meg minden ilyen szempont alapjan. Addigra megertettem (es korulbelul felnottem) hogy nem veletlenul csinalnak ujabb es ujabb nyelveket. Nincs egy gyuru, szent gral, tuggyamifaszom. Szoval igen, szerintem meg a sertodott hozzaallas nelkul sincs semmi ertelme a feladatnak. Es hat engedtessek meg nekem, hogy mivel ez egy forum leirjam a velemenyemet. Es ez nem basztatas hanem egy velemeny. Amit nem kell elfogadni, de civilizalt emberek azert meg szoktak hallgatni a masik velemenyet es kultoraltan ignoraljak. Ha nem tudjak elfogadni es elkezdenek tombolni, akkor keszuljenek fel, hogy korejuk kepzelik a gumiszobat es a hatul kotos kis kabatkat. :D
Ha az ego erős és hatalmas lenne, akkor nem lenne sértődés, de itt az énkép korántsem stabil, emiatt a sértődés. Attól ne essünk hasra, ha valaki 20++ év után ért a saját területéhez. A baj az, hogy neki ez mérőszerszáma lett, így szerinte aki ehhez nem ért az hülye.
Minden embernek van fejlövése. De ha mindig idealizált emberrel akarunk csak beszélni és/vagy idealizált környezetben, akkor a végén csak magunkban motyogunk.
Magam részéről figyelemmel hallgatom azt, aki valamihez ért, meg ha fejlövése nagyobb is az átlagnál.
Ok, értelek, és nagyjából egyet is értünk. Ezért írtam, hogy fontold meg: célravezető lenne-e megvárni a szakmai eredményt és csak utána elküldeni bzt-t a picsába. Miért kell előtte, szerinted megváltozik?
Egyetertek.
Idezek a nyitobol:
Ha nem a C nyerne, akkor pedig vice versa, megígérem, hogy nem fogom a továbbiakban az orrotok alá dörgölni, hogy felültetek a hypenak és bedőltetek a marketing bullshitnek.
Ezert van teljesen igazad.
Nem az eltolt golvonalra kell panaszkodni, hanem bullshit helyett koddal bizonyitani. Kinos, hogy milyen sok embernek megy a szovegeles, de kodot irni mar szinte mindenkinek derogal.
Egyebkent nekem golgota ellenkihivasa is tetszik: tud-e valaki C/C++-ban optimalis adatszerkezetet irni, ami beszel jsonnal es ES-csel.
Kulon pikans lenne, ha valaki felhasznalna a megoldasahoz pl. a PostgreSQL forraskodjat. :D
Iszonyat egyszeru lenne szerintem C-ben is megirni, mivel az egesz csak protokol es szerializacio. Mas kerdes hogy akar pythonban 3 sor es kb. fel ora annak aki most ismerkedik a python nyelvvel. Hogy atom stabil lesz a az a 3 sor python (jo kicsivel tobb, de erted mit akarok mondani)?. Ki tudja. Ha mikroszervizkent inditom akkor leszarom mennyire stabil, majd ha ujraindul akkor folytatja amit elkezdett. Na igen, de akkor mar kell egy cache, amiben rogziti mi az utolso adat amit kiszedett a kafka topic-bol, szoval johet a cache-el valo beszeles implementazioja is, na az megknt par sor a kezdo python progamozonak. De egy ugyes kezu scala-s megirja ugyanannyi ido alatt, mint egy pythonos kezdo.
Hogy meyik a jobb, fasz se tudja, majd a business eldonti. De hogy nem C-ben kell megirni az tuti. Meg lehet? Meg hat. Erdemes? Egy nagy budos lofaszt. :D
A postgresql forraskodja mondjuk nem tudom hogy kerul ide ehhez a kerdeshez, mert semmi koze az ES-hez vagy a Kafka-hoz, bar mondjuk tud JSON-t tarolni (JSONB adattipus), de itt siman azt kell tudni a proginak, hogy egy JSON-t rakuld egy HTTPS kapcsolatra adott API-ra. Ezt meg meg nodejs-ben is baszott konnyu megirni. De gondolom C-ben is van "request" meg JSON library.
A masik oldal a nehezebb, amikor a Kafla-bol kiolvasod a nyers adatot es egy yaml leiro szerint aggregalod a memoriaban, de elosztott modon (ala SPARK), mert mi van ha egy 4 kb-os adatbol kell kivenni, de mi van ha mondjuk egy 3GB-osbol, es ebbol is az utolso 5 perc osszes envelopjaban levo adatbol kell legyartani az aggregaciot.
Na mindegy is. Itt hidd el nem a C a nyero meg ha meg is lehet irni benne.
>Senki az eg egegyadta vilagon nem kerdojelezte meg bzt szakmai tudasat.
De, én megkérdőjeleztem. A memóriakorrupció elleni védelmet nem érti hogy hogy működik se C-ben, se a menedzselt nyelvekben, hiszen egyenlőségjelet tesz a Valgrind és tsai illetve a garantáltan biztonságos memória menedzsment közé. C-ben azt állította, hogy mindent ki tud fogni a Valgrind, pedig sajnos nem. A Rust memóriákezelésre pedig azt állította, hogy ugyanazt generálja, mint a C ASAN, pedig nagyon nem. Ez olyan mértékű tévedés, ami mellett nem lehet csak úgy elmenni, kapott linkeket és példákat is, mégis köti az ebet a karóhoz. Ettől még tudhat rendszerbetöltőt írni, csak nem ismeri az eszközeit senior szinten. Nem baj, lehet produktívnak lenni az ő szintjén is, csak nem kellene arcoskodni olyan területen, amit nem ismer.
Még arra is vettem a fáradságot, hogy csináljak neki egy példát, ami demonstrálja a mondandómat, csak "elfelejtett" válaszolni rá: https://hup.hu/comment/3035799#comment-3035799 Majd pont még rendszerprogramot is fogok írni neki Rustban.
Szerintem elbeszéltek egymás mellett. Mind a ketten igazat írtok. A C többek között a memória területen történő egyszerű matatásra felkészített nyelv, ez magában hordozza a problémák jellegét: nevezetesen nem lehet egyértelműen eldönteni a “hibák” egy részénél, hogy szándékos-e egy adott terület írása vagy sem. Kidolgozni ellenőrző mechanizmust csak azokra az esetekre lehet, amelyek egyértelműen eldönthetők: Pl free hiánya, buffer overflow, és ezekre ellenőrző mintázat írható.
Az általad irt példa halmozott probléma, talán erre is lesz majd pattern vagy a fordítóban vagy egyéb segéd programban mint pl Valgrind.
>Mind a ketten igazat írtok.
Kivéve, hogy bzt téved. Konkrétan azt írta, hogy a Rust is ugyanolyan kódot generál, mint az ASAN, ami blődség, és pont a lényeg megértésének hiányára utal. Én is követtem már el szakmai tévedést, és még ragaszkodtam is hozzá egy darabig, de aztán a végén csak utánajártam és korrigáltam amit még lehetett. De ez már túlzás, hogy megír egy komplett számláló rendszerprogramot, hogy "bizonyítson" valamit amit senki se ért, de közben nem néz végig egy Rust vagy Java tutoriált, hogy mégis hogyan működik a memória biztonság.
>Az általad irt példa halmozott probléma, talán erre is lesz majd pattern vagy a fordítóban vagy egyéb segéd programban mint pl Valgrind.
Nem értem mitől lenne halmozott, egy darab elrontott pointer aritmetika van benne. A minta egyébként simán előfordul C programokban, hogy pointer szerint matatunk valamit.
Az első esetben annyit kellett trükközni, hogy két külön forrásban legyen az sprintf és a buffer, így a compilernek sosincs meg az egész kontextus, ezért nem tud fordítási időben bufferméretet ellenőrizni. Nem hajánál fogva előhúzott minta, számtalanszor láttam ilyet valódi programban is.
A másodikban azért van pointer szerinti kiíratás, hogy garantált legyen, hogy a b változót is stackre allokálja a fordító. Ha mindkettő stacken van, akkor máris elérhető egyik a másik hibás offsetelésével. A kérdés csak az, hogy mennyi az offset, ami fordítófüggő, de mindig van olyan szám, amivel éppen észrevétlenül hibázik a rendszer.
A menedzselt nyelvekben azért nem lehet ilyet csinálni, mert "pointer helyett" "referencia" van, ami pointer+méret+típus információ és minden esetben ellenőrzive van, hogy pontosan oda címzünk amire jogunk van. Az ellenőrzés sokszor lehet fordítás idejű zéró plusz költséggel (egyébként érdekes módon pont azon egyszerű esetekben tud fordítási időben ellenőrzni a fordító, amikor a C fordító is tud érvelni a pointer méretére), de amikor plusz utasítás, akkor se óriási a költség, mivel regiszterben vagy cache-elt memóriában közlekedik a metaadat, amit gyorsan el lehet érni.
pont ezért írtam, hogy halmozott a probléma - a compiler/ellenorzo program szempontjából.
Jaj, hagyjál már! Ilyen vagy nincs, vagy ha létezik, az egyúttal azt jelenti, hogy nem tudsz megcsinálni benne bármit, amelyre a hardware képes. Azt nem nevezném fejlődésnek, hogy elvész a lehetőség, korlátolt lesz a működés. Nekem az a jó nyelv, amelyben bármit le tudok írni, amit egyáltalán el tudok képzelni. Az assembly ilyen, tehát az egy jó nyelv. A C is nagyjából ilyen, az is egy jó nyelv. Bár ott már lehet, hogy bajlódni kell a linker scripttel, ha például bootloadert írsz, vagy a main() előtt kell valamit futtatni, akkor el kell olvasni, az adott fordító hogyan ad lehetőséget egy kis assembly kód futtatására. A többi az korlátolt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ez egy trade-off. Minél több megszorítást csinálsz, annál kevésbé lehet hibákat elkövetni (ne menjünk messzire, MisraC). Cserébe elveszik a kezedből a "kreatívkodást". Ami lehet jó, de ha a kipörgésgátló szoftvert fejleszted a kocsimba, vagy a lélegeztetőgépet amit életben tart, akkor nagyon nem mindegy, hogy mennyire lehet kreatív a fejlesztő, vagy mennyire tud bizonyíthatóan hiba nélküli kódot írni. Ennek nyilván sok szintje van, és nem véletlen hogy sok helyen a kódot modellből generálják (aminél pedig bizonyítják a korrektséget).
Értem, amit beszélsz, csak nem tudok vele azonosulni. Ne vegyék el a művész szabadságát! Modellből generálásról jut eszembe, épp MCC van nyitva a hozzászólásom alatt, legeneráltattam C kódot initelésre összekattintgatós módon, erre ez a gyökér UART-hoz generált valami bloat ámokfutást, amelyet perceken belül úgy penderítek ki a kódból, hogy lába nem éri a földet, mert felbosszantott. Ja, nem mellesleg ráadásul elsőre, manuális kozmetikázás nélkül le sem fordult, amit generált. Arra mindenesetre jó, hogy a rengeteg hardware-t vezérlő regiszter initjét összefércelje, mert ennél azért nem bízom benne jobban.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Akkor most a Rust az unsafe-től lesz jó nyelv? Vagy pont attól rossz? Kezdek összezavarodni :)
Nem ismerem a rust-ot, szóval nem mondanék róla véleményt. Nekem a C szintaxisa nagyon bejön, nagyon logikus, számomra érthető, és mindamellett még eléggé szabad, nem korlátolt a nyelv, eddig amit kitaláltam, azt meg tudtam benne csinálni. Például megengedi ugyanannak a memóriaterületnek különböző típusú változóként való felhasználását a union által. Nem tudom, a rust-ban van-e a C unionnak megfelelő konstrukció.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
kár veled vitatkozni, aki nem azt mondja, amit hallani szeretnél, az troll, nyafog, kifogás
Ez egy valid verseny, de attól, hogy a C győz _ebben_, az továbbra sem jelent mást, mint azt, hogy a C és az ökoszisztémája _ebben_ a legjobb. De ettől még nem fog mindenki a fejéhez csapni, és enterprise alkalmazásokat, az adatelemzéseit, meg még ki tudja mit átportolni C-re, mert az a _jó_.
Számtalan ember gyorsabban megír valamit python-ban, ami kell neki, észre sem veszi, hogy felháborítóan lassan fut (hiszen még mindig nagyon gyors), és számukra sosem lesz a C a legjobb nyelv, mert mire megtanulja, megérti, hogy hogy kéne C-ben ugyanazt megoldania, 6 körrel marad le a feladatával
Azoknak, akik amiatt nyafognak, hogy rendszerprogramot kell írni: ez van, a C már csak egy rendszerprogramozási nyelv, így ha egy másik nyelv le akarná váltani, annak is minimum rendszerprogramozási nyelvnek kell lennie.
A miheztartás végett, mielőtt kiírtam volna a pályázatot, elkészítettem a referencia megoldásokat Assembly-ben (ezt mellékeltem is), C-ben és Ada95-ben. Tehát jól bejáratott rendszerprogramozási nyelveken egész biztosan gond nélkül megoldható a feladat, felesleges kifogásokat keresni. (Sőt, még azt is elárulom, hogy ahhoz, hogy a C forrás leforduljon gcc-vel és Clang-al is egyaránt, kellett egy ifdef, ha PE/COFF-ba fordít.)
Amennyiben olyan eset állna fenn, hogy a betöltő nem tud betölteni egy érvényes lefordított programot, akkor természetesen ASAP javítom a betöltőt. De eddig csont nélkül indítja az Assembly-ből ELF és PE/COFF formátumba fordított, valamint a gcc-ből ELF, illetve Clang-ból ELF és PE/COFF formátumba fordított binárisokat.
A problema hogy ugy akarod eldonteni hogy melyik a jobb nyelv, hogy egy specialis feladatot talaltal ki, amire a C a legjobb.
A fenti bigdata streaming (spark/flink) vagy stateless microservice aplikaciot is meg lehet irni C-ben is, sot meg lehet gyorsabb is lesz maga a program, de ide a rozsdas bokot, hogy egy ugyes scala programozo 10ed annyi ido alatt rakja ossze.
Sot ismerek olyat, aki C++-ban irt ML/Anomaly detection progit par nap alatt. Szep-szep. De python-ban ugyanazt meg lehet irni fel ora alatt. Es nem, ez nem jelenti azt hogy a python "jobb nyelv" lenne. Azt jelenti, hogy penz beszel, kutyaszar tancol, es uzleti szempontbol kurva mindegy hogy a C a vilag legjobb nyelve e vagy sem. :D
Ez konkrétan hazugság. Erre a feladatra az Assembly a legjobb, de nem is ez volt a kérdés, és még mindig nem árultad el, hogy egy számláló növelésében és kiírásában mi lenne a speciális. Csak nyafogsz.
Ha a feladat lényege az, hogy ki tud gyorsabban minnél több middleware-t berántani a kódjába, akkor azzal NEM a nyelv kifejezőerejét teszteled.
A feladat, hogy valami noveljen egy szamlalot. Ha megteszi, akkor jo. Korulbelul mindegy miben irjak. Leszarom, hogy assembly, C, Rust, python, lofasz.
Se a merete, se "gyorsasaga", se a resource ehsege nem erdekel addig, amig valaki ezt nem rakja be a kovetelmenyek koze. Meg csak az ssem, ha valaki a jovo honapban adja azt le neked, mert addig irja mas valaki meg megirja egy perc alatt.
A Te kovetlemneyeid akkor lennenek jok, ha azt mondanad: ferjen bele 2KB-ba, a maximalis cpu hasznalata legyen X ciklus, a memoria hasznalata maximum X byte, stb stb., es most inditod a stoppert, holnap reggel nyolcra legyen a git-ben egy branchen.
A jelenlegi kirasban nekem minden megoldas tok egyforman jo. Minden nyelv szuper :D
Akkor küldj be egy megoldást! Mindegy, miben írod, csak működjön!
Az a baj hogy a write-only mododban nem is akarod megerteni mit irtam es erre meg radobod egy nagykanallal a sertodottsegedet is . :D
Ne, akkor itten van egy jo kis kod
szamlalo=0
loopoljvazze:
szamlalo ++
sleep tudjatokom
LOL
Ugyan miért lennék sértődött? Hallucinálsz tán, mint egy AI? Ha valami, akkor szomorú vagyok, hogy a Ti szintetekre süllyedt mára a szakma. :-( Ez elvileg itt a HUP, egy szakmai fórum informatikusoknak.
Az en szintemen a sok kis szanalmas fasz tartja ossze a te kis ITs vilagodat :D
Nem, valójában a szánalmas kis faszaid nem tartanak semmit sem össze az IT világában. Bár egy hozzád hasonló ez sosem fogja megérteni, csak amikor már túl késő lesz.
Koszi mester.
(ezen jot rohogtem :D)
Már csak az időzítésen kell dolgozni.
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
Kipróbáltam a natív ELF-et generáló fordítómmal https://gitlab.com/bztsrc/brainfuck :-)
Érdekes, nálam out of bound addressing errort ír rá.
[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS
A Daru és a Róka vendégsége: https://www.youtube.com/watch?v=3Jg9UUo90yg
Nem látom, hogy bármit is beadnál, pedig most megkaptad a lehetőséget, hogy gyakorlatban is igazold, nemcsak a szád jár.
De miert lesz neki jobb, ha igazol neked barmit is?
>megkaptad a lehetőséget, hogy gyakorlatban is igazold, nemcsak a szád jár.
Konkrétan mit is? Ha visszaolvasnád a hozzászólásokat, a tényszerű tévedést javítottam csak, miszerint a C-re továbbra sem lehetséges maradéktalanul memória túlcímzést ellenőrizni. Ennyi volt az állításom, ezt nem tudod cáfolni, mert így van. Rust evangelista nem vagyok, mert még alig ismerem. Szerintem érdekes téma, de eddig nem volt időm rá: érdekes és pénz hozó projekteken dolgozom, úgyhogy nem panaszkodok, de hiába érdekel, nem Rustoztam eddig egy tutoriálon túl.
Talán a Java a kedvenc programozási nyelvem a libekkel és eszközökkel együtt. De sosem állítottam, hogy rendszerprogramozásra alkalmas volna.
Azt nem veszed észre, hogy az alap állításoddal nem is álltam szembe, szeretem is a C-t, dolgozok is vele. Csak annyira fel vagy fuvalkodva, hogy mindenre vagdalkozol ahelyett, hogy gondolkodnál inkább.
Az szerintem nyilvánvaló, hogy bármilyen menedzselt nyelvhez szükséges az unsafe opciók használata ahhoz, hogy interfészeljünk a hardver környezettel. A kiírást nem gondoltam végig, de sejtem, hogy itt ugyanez van, nem tudsz C-be belehívni unsafe nélkül, mert C-t hívni eleve unsafe a Rust nyelven belül. (Tippre, nem néztem utána és talán nem is fogok.)
A környezethez drótozó kódokon kívül a többi viszont már lehet safe, az a logika, hogy egy timer szerint, vagy a buffer swap interruptból triggerelve beírunk két bájtot az már gyerekjáték. A nehézséget a C API elérése és a timer felrpogramozása jelenti. Mivel C API-t adtál, ezért ez pont olyan mint a Róka és a Daru vendégsége. Én meg kiírok egy versenyt, adok egy Java API-t, és az nyer aki a legegyszerűbben használja a Java API-t. Írhatsz JNI-t rá, de bukod mert túl bonyolult lesz.
A Rustnak nem engedni az unsafe-t, az itt nem fair, mert az olyan mintha én azt mondanám, hogy te meg futtas rendszerbetöltőt Valgrinddel, de úgy, hogy ne mondd meg neki, hogy a rendszer regisztereihez hozzá szabad férni direkt címzéssel. Úgy kivág mint macskát szarni. Ha meg megmondod, hogy ezeket neked szabad, az pont olyan mint Rustban az unsafe.
LOL
A feladat direkt úgy lett kiírva, hogy NEM kell hardver környezettel interfészelned, a betöltő szándékosan elfedi ezt előled és egységes, magas szintről hívható funkciókat biztosít.
Rosszul sejted.
Nem. De persze nem várom el a Te szövegértési képességeiddel, hogy felfogd, egyaránt biztosított a SysV ABI és az MS fastcall ABI is, szabadon választhatsz.
Felmerül a kérdés, hogy te egyébként ismered azt, amit fikázol? Konkrétan a Rustról, vagy akár bármilyen menedzselt nyelvről van bármi fogalmad? Hogy amikor arról beszélünk, hogy véd a memória félrecímzéstől, akkor az hogyan működik? Mert ha értenéd, akkor tudnod kellene, hogy nem lehet a nyelvből kihívni unsafe nélkül. A kulcsszót nem tudom, hogyan kell alkalmazni, de nyilvánvaló, hogy a nyelv a garanciáit nem tudja biztosítani akkor, ha belehívsz C-be, tehát unsafe.
De ez nem baj, mert csak beírod, hogy unsafe, a projekt résztvevői elfogadják a kockázatot és minden működik.
De unsafe kulcsszó nélkül elvi okok miatt nem működhet. Vagy annyira nem érted a koncepciót, hogy eleve nem érted, vagy ha érted a koncepciót, akkor nem tisztességes a kiírásod. Döntsd, hogy melyik eset forog fenn, aztán módosítsd úgy a kiírást, hogy lehet használni az unsafe kulcsszót, illetve ha szükséges, akkor egy minimális illesztőt is. És máris lesz talán aki megcsinálja neked.
Ennél a feladatnál sehol sem kell "belehívni C-be". És még választhatsz is, hogy milyen ABI-t szeretnél az interfészhez.
Ráadásul a függvények még véletlenül sem nyúlnak a program memóriájához, csak CPU utasításokat ágyaznak körbe, így még annak sem lehet akadálya, hogy immutable-ként definiáld Rust alatt, ha épp úgy szeretnéd.
Igen, nalunk is minden team pontosan ezen kriteriumok alapjan donti el, hogy mi a legjobb megoldas egy feladatra.
#janem
Igen, mert nálatok a teamek ahelyett hogy dolgoznának és termelnének, azzal vannak elfoglalva, hogy különféle nyelveket hasonlítsanak össze. Paraolimpián nem indulnak a teamjeitek? (szarkazmus)
Ennek a versenynek hogy lehetne már ugyanaz a célja, mint egy cég részlegének? Sehogysem.
No igen, nehez meroszamot rendelni ahhoz, amikor rendben van a doksi, a CI, a re/un/... deploy; van failover, backup es monitoring, vannak processzek, megismetelheto, atveheto a fejleszes es uzemeltetes, van 24/7 pager duty, van biztonsagi audit, es meg sorolhatnam.
Sokan, akik nem dolgoztak meg kozepes/nagy cegeknel, nem is tudnak ezekrol. Nagy cegeknel a jo kod max. a fele a requirement-eknek. Siman van atlagosan minden koder melle egy SRE/Security/PO/IA/BA/PM fo. Egy 3-5 fos team melle siman egy 3-5 fos support garda tartozik, akik a (developer szemszogbol) "kulimunkat" vegzik.
Kis cegnel ezeket altalaban elsumakoljak, vagy annyira egyszeru a landscape, hogy egyvalaki megcsinalja kaveszunetben. De nagy ceg ezt nem engedheti meg maganak; egy esetleges sulyos leallasbol, security breach-bol, adatvesztesbol akkora veszteseget tud 'kitermelni', amibol kijon a teljes IT eves fizuja... Mas a nagysagrend.
Én nem programozok vagy 25 éve, de üzemeltetőként is értem, hogy miért háborodott fel bzt kolléga és mit szeretne megmutatni ezzel a versennyel.
Aki itt (is) vitatkozik, az vagy nem érti (ez fura, le lett írva ezerszer), vagy csak a vitatkozás/ellentmondás kedvéért írogat ezekbe a topikokba (aminek meg semmi értelme igazából jelen esetben).
Az utóbbi napok C/C++ kötődésű topikjainak lényege, hogy azt állították (cikkek, hozzászólók), hogy a C/C++ leváltása felé kezdenek mozdulni még a legnagyobb programgyárak is, mert azok jobbak (főleg a memóriabiztonságra hivatkoznak). Itt a _leváltáson_ volt mindig a hangsúly, nem a jobbságon. Mert ugye az nagyobbat üt a neten, hogy "leváltjuk az 50 éves technológiát", mint az, hogy "bizonyos dolgokat más nyelven írunk mostantól".
Na, ez a verseny arról szól, hogy a C/C++ elég valószínűleg nem leváltható, mert vannak feladatok, amik csak ezzel, vagy ezzel sokkal hatékonyabban oldhatóak meg.
Teljesen nyilvánvaló, hogy manapság egy ügyviteli program megírásához nem C nyelven kezd hozzá senki, mert ugyan tökéletesen alkalmas rá, csak kicsit tovább tartana, mint egy UI-s felhasználói program fejlesztésére kitalált nyelven/rendszerben (pl. C# és a .NET, WPF ökoszisztéma hozzá). De sok kernel rész, meghajtóprogram, idő/teljesítmény kritikus feladat esetén ma is a C-t vagy hozzá hasonló alacsony szintű nyelvet kell elővenni, ha nem is az egész program készül benne.
Én bízom azért benne, hogy lesz, aki megírja valamilyen nyelven, ha más nem, a móka kedvéért!
Szerintem itt a HUP-on nagyon kevesen vannak, akik ilyen alacsony szintű programozással foglalkoznak, ráadásul azt ne C-ben csinálnák már évtizedek óta. Nem gondolnám, hogy közülük van egy is, aki hajlandó lenne ezt Rustban megírni.
Így én nem igazán bízom ebben.
Esetleg akkor lenne holmi esély, ha valaki megírná legalább C-ben, nyilvánossá tenné a kódot.
Ilyenkor már nagyobb eséllyel tudnák a Rust-ot ismerő, de ilyen alacsony szintű programozást nem ismerő, programozók azt átírni.
Sőt, azt mondom, akkor lenne a verseny korrekt, ha a kiindulási C kódot a verseny kiíró nyilvánossá tenné!
Én beágyazott programozó is vagyok, C-ben kiismerem magam, a Rust érdekelne, és kifejezetten jó mókának tűnne ilyesmit írni AMD64-re. De az agresszív kismalacos hozzáállás miatt úgy érzem akármit is hoznék össze, arról kiderülne, hogy eggyel több unsafe kulcsszó van benne, vagy kellett hozzá egy ASM betét, vagy ilyesmi, és ezért érvénytelen az egész.
Nem értem bzt miért idegenít el magától mindenkit, mert kifejezetten érdekesek lehetnének ezek a témák ha nem vagdalkozna hozzá. Olyan mint egy Apple fanboi, aki a C-ért rajong az Apple helyett :-)
Nem tudom x86-on hogy van, de például ARM-eken vagy AVR-eken is kell néhány "compiler intrinsic" vagy assembler betét ahhoz, hogy a rendszer alapjait le tudjuk tenni, amire már lehet szabványos vagy MISRA C-t írni. Ezért a Rust-tal szemben is az volna az ésszerű, hogy a rendszer "szélén", azaz ahol a számára külvilággal interfészel, ott engedjük meg az unsafe használatát. Hívj meg egy ABI-t, ami nyilván eltér a Rust hívási konvenciójától, de ne használj unsafe-t! Teljesen korrekt versenykiírás. Pedig amúgy érdekes lehetne.
Bocs, de ezen a szánalmas kifogáshalmazon akkorát röhögtem, hogy kicsordult a könnyem is tőle :-D
Én nem vagdalkozom, összekeversz valakivel! Még az idióta hozzászólásaitokra is igyekszem kulturált válaszokat adni, nézd csak végig ezt a topikot! Nem rám gondoltál.
Na akkor neked is leírom mégegyszer, hogy pont erre van a betöltő és az interfésze, és ezért lett kiírva a verseny úgy ahogy. A megoldáshoz NINCS szükség sem alacsony szintű programozásra, sem Assembly betétekre. Nyilván, különben nem nyelvek összehasolítása lenne.
De hisz ott meg van engedve... Pedig nem is kellene, de engedtem a sirákozásaitoknak. Ez többé már nem lehet kifogás.
>Pedig nem is kellene
Na, várj! Akkor te ezt már megcsináltad Rust-ban? Tehát _tudod_, hogy nem kell? Tehát nem is úgy írtad ki a "versenyt", hogy ne lehessen Rust-ban megcsinálni? Vagy úgy gondolod hogy egy ideális világban nem kellene? Nem igazán értelek, hogy mivel mit akarsz mondani.
Természetesen nem. Már pusztán az a tény, hogy a kiírás végigolvasása után mégis ezt feltételezted, Téged minősít.
Mint ahogy azt direkt külön le is írtam a kiírásban, úgy lett kialakítva a versenyszabály, hogy azt bármilyen rendszerprogramozási nyelven könnyedén meg lehessen oldani. Akár Rust-ban is.
Még a Rust dokumentációja is azt állítja, hogy nem kell. Sem egy ideális világban, sem a gyakorlatban nincs rá szükség ehhez a feladathoz. Az interfész egyáltalán nem használ Rust memóriát (!), nem foglal, nem szabadít fel, nem módosít egyetlen változót sem; mindössze az egyik függvénynek kell átadni (kizárólag olvasásra) egy konstans, immutable tömböt. Rust szemszögéből a betöltő által biztosított minden függvény safe.
Hát azt látom.
Úgy látom nem sikerült elolvasnod azt, amit belinkeltél.
Rust szemszögéből minden külső függvény unsafe, lényegtelen, hogy szerinted safe-re írtad meg.
Pedig ez is le van írva a linkelt doksiban, hogy a direkt memória írása, de még az olvasása is unsafe. Mintha a feladatban szerepelne direkt memória írás, nem? Ezt viszont nem engeded. Akkor mégis úgy írtad ki, hogy Rustban ne lehessen megcsinálni.
Nagyon nem lényegtelen. Egy állítólagos rendszerprogramozási nyelv esetében meg főleg nem lényegtelen, hogy képes-e külsős függvényeket hívni kompromisszumok nélkül!
LOL! Azt állítod hát, hogy e definíció értelmében nem is létezhet safe Rust! Merthogy amit írtál, az bizony ezt jelentené!
LOL-ozás helyett inkább olvasd el, amit belinkeltél, akkor nem lenne ennyi tárgyi tévedés az írásaidban.
>Én nem vagdalkozom, összekeversz valakivel! Még az idióta hozzászólásaitokra is igyekszem kulturált válaszokat adni, nézd csak végig ezt a topikot!
VS
>A legtöbb faszkalap úgy mondana a helyemben ítéletet, hogy ...
>valójában a szánalmas kis faszaid nem tartanak semmit sem össze az IT világában. Bár egy hozzád hasonló ez sosem fogja megérteni, csak amikor már túl késő lesz.
>az idióta hozzászólásaitokra ...
Szerintem a programozás mellett tánc és illemtanár is lehetnél, mert született tehetség vagy ebben is :-)
Látom az olvasás még mindig nem az erősséged.
Ezek mind konkrétan egytől egyig IDÉZETEK, és szándékosan azokból a hozzászólásokból származnak, amikre a választ adtam! LOL!
A faszkalap szóra ha rákeresel, te használtad először. Vagy egy másik topikból idézted? Pont arra akartam utalni, hogy itt is, meg ebben a topikban is szinte kivétel nélkül te kezdted a személyeskedést és a gyalázkodást is: https://hup.hu/node/184578
A vesszőparipám, hogy a C eszközei nem tudják garantálni a memóriabiztonságot, ezért erre a témára reagáltam. Adtam egy példát, hogy mit nem lehet 100%-ban kifogni statikus ellenőrzéssel. Erre a reakció: "Hahahahaha! Te nem fordítottál sok C programot ugye?" Ez még nem túl durva, de akkor is a személy felesleges támadása, ami nem szül jó hangulatot.
Erre _reakcióként_ egyáltalán nem durvábban reagáltam minimális személyes szúrással: "Parttalan ez a vita, ha nem érted a különbséget aközött, hogy..." Arra törekszem, hogy nem kezdek személyeskedést és nem szólok vissza durvábbat mint amit kaptam. Ezt kiegyensúlyozottnak érzem a saját szabályaim szerint.
Válasz: "jól látszik, hogy az alapfogalmakkal sem vagy tisztában. Csak dobálózol itt olyan dolgokkal, amiket valahonnan hallottál, de valójában lövésed sincs, mit jelentenek. Már meg ne sértődj, de olyan vagy, mint egy indiai copy'n'paste huszár." Szerintem a független elemző is megállapíthatja, hogy ez megint eszkaláció ahelyett, hogy a felajánlott deeszkalációt elfogadtad volna. (Az, hogy nem emeltem a beszólás pofátlanságán, csak éppen alulról súroltam, de ezen az egyen kívül semlegesen fogalmaztam a deeszkaláció felajánlását jelenti meta-nyelven.)
Plusz:
"A baj az, hogy fogalmad sincs, hogy működik valójában a határellenőrzés (és a Rust fordító sem csinál mást, mint hogy csont ugyanazt az ellenőrző kódot generálja, mint a "-fsantize=address" hatására a gcc), nem tudod, mi a különbség a szintaktikai és szemantikai ellenőrzés között, és mégis próbálod osztani itt az észt."
Még egy beszólás ráadásul tárgyi tévedéssel egybefonva. Tehát kettő egy posztban és mindkettő durvább mint amire reagáltál, egyértelmű szándékos eszkaláció.
Az már csak hab a tortán, hogy erre a felkérésre: "Ha meg arra gondolsz, hogy egy másik változó címzésekor íródik felül, akkor fuss neki mégegyszer, hogy mi is az az ASAN és mire való, gugli a barátod! De elárulom, ezt az esetet észreveszi a C fordító statikus ellenőrzése és a valgrind is!" itt a válasz, és bár kb minden kommentre mondasz valami csúnyát, erre azóta sem jött válasz: https://hup.hu/comment/3035799#comment-3035799 Hogy lehet, hogy az ASAN figyelmét elkerülte, hogy az a pointer félrecímzésével a b értékét írtam felül? És valóban lehet ilyen példát csinálni Rustban vagy Javában? Esetleg a .NET valamelyik nyelvében? Azért nem lehet, mert alapvetően másképpen működnek mint a C és nem valószínűségi alapú az ellenőrzés bennük, hanem bizonyíthatóan korrekt. És az első lépés az kellene, hogy legyen, hogy megtanulod hogyan működnek ezek, mielőtt nagy mellénnyel gyalázkodásba kezdesz.
Egyébként tök örültem amikor írtál a rendszerbetöltőről, gondoltam na lám egy újabb érdekes arc megjelenik a hup-on, milyen király. Én igazán jóban akartam volna lenni veled, de egyszerűen elképesztő a viselkedésed. Szerk.: részemről továbbra is nyitott vagyok a deeszkalációra, ha hajlandó vagy abbahagyni a vagdalkozást.
Kiszámítható vagy, mint egy Csebisev interpoláció!
Te komolyan azt hitted, hogy ha megpróbálod a fejemre olvasni mindazt, amiben TE MAGAD vagy sáros, akkor majd megszeppenek vagy mi? ROTFL. Küldj be valamit, akkor talán komolyan vesznek majd az emberek, de addig csak nevetség tárgya maradsz.
annyira bekepzelt es nagyszaju vagy, hogy kb mindenki leszarja a versenyedet, kiveve a kis felszopofijuidat :D
Na akkor a jó ég tudja hányadszorra ismét, a feladat megoldásához direkt NINCS szükség alacsony szintű programozásra! Ez a kiírásból több, mint egyértelmű, meg már jópárszor leírtam a gyengébbek kedvéért.
Ha látnám a C kódot, akkor talán még el is hinném ;-)
Ezek nekem mind nagyon alacsony szintű dolgoknak tűnnek:
Mármint egy tömbbe írás neked már alacsony szintű programozának minősül? Ja, már mindent értek.
Gyk: ez egy teljesen mezei karaktertömb, annyi csak, hogy fix címen helyezkedik el, és felváltva ASCII karaktereket és attribútum bájtokat tartalmaz. Hogy miért ilyen? Tessék az IBM mérnökeinél reklamálni, nem én találtam ki!
De egy olyan programozási nyelvnek, ami állítólag leválthatja a C-t, nem kéne, hogy gondot okozzon írni bele!
Hidd csak el nyugodtan. A C forrás egyetlen fájl, két függvény, kevesebb, mint 50 SLoC, nincs benne inline Assembly, és csakis interfész függvényhívás történik benne (még lokális függvényt sem hív).
De nyugodtan megnézheted az Assembly referenciát is, nincs benne semmilyen alacsony szintű programozás, csakis interfész hívás. Sehol egy in vagy out utasítás, de még egy iret vagy lidt se; semmi, ami bárminemű alacsony szintű eszközhöz vagy CPU rendszeregiszterhez nyúlna.
Na, várj! Egy változónak a section meghatározása a C szabvány része? Eddig arról volt szó, hogy a nyelv szabványos eszközeit használhatjuk. C-ben úgy tudom, hogy sectiont használni nem része a szabványnak. Most akkor ezt lehet? Vagy C-ben tilos volna használni, mert nem része a szabványnak, viszont cserébe ott lehet olyat írni, hogy uint8_t * buffer=(uint8_t *)0xabcdef; De ezt Rust-ban nem írhatom le, mert ott unsafe-nek minősül? Viszont section specifikációt csinálhatok, mert az viszont része a szabványnak? (https://doc.rust-lang.org/reference/abi.html?highlight=link_section#the…) Bár az meg nyilván nem része a szabványnak, hogy mit kell kezdeni ezekkel a nevekkel, mert az meg platform specifikus, a linker szkript pedig nem Rust.
Te mit jössz már megint folyton a C-vel? Hajlandó lennél felfogni végre, hogy a versenyszabályokban és a feladat kiírásban nincs semmi C specifikus?
Tanulj már meg olvasni, ez már tényleg nagyon szánalmas, amit művelsz. Idemásolom:
bármilyen fordítási segédprogram megengedett, olyan is, amit külön kell telepíteni vagy saját fejlesztésű (például interface bindolók, fejléc generálók, linker szkriptek, binutils, make/mk/cmake/ant/scons/meson/ninja/azanyjakinyja stb.)
Csináld, ahogy akarod, csak adj már be végre valami megoldásfélét!
Sajnos nem értesz semmit és nem is vagy hajlandó elgondolkodni rajta sem, pedig leírtam már egy párszor, illetve el is olvashatnád az általad belinkelt oldalon.
A tömbbe írás természetesen nem számít annak, de egy fix memóriába írás vagy olvasás már annak számít. Az zavar meg, hogy szintaktikailag ugyanúgy néz ki egy saját tömbbe írás, mint a direkt memóriába írás. Ha C-ben és Rust-ban erre külön kulcsszó lenne (pl. read/write, in/out), akkor talán jobban megértenéd.
Namost a C++ szintakszisa valami borzalom. Persze megszokhato, de igazabol a feature-ok felet siman ki lehetne dobni kulonosebb kifejezokeszseg-vesztes nelkul (az utobbi par evben felivelo programnyelvek meg is tettek). A maradekot meg lehetne sokkal egyszerubben, olvashatobban is.
En probaltam es hasznaltam rust-ot, de igazabol nem vagyok meggyozve, hogy ez lenne a jovo -- ugyanaz a baj, mint a C++-al, egyszeruen a borrow checker egy kinszenvedes, totalisan lekorlatozza a developer productivity-t. Mondjuk reszelgetik rendesen, mar most is sokkal jobb, mint 3-4-5 eve volt, de meg 2x ennyi 'reszelgetes' kene neki, mire azt mondanam, kezd OK lenni.
A C-ben meg a 70-es evekbol visszamaradt stdlib a fo gaz. Azert ne 'char*' legyen a string igy anno 2024-ben! A szintakszis OK, egyszeru es kovetheto, de a komplett lib-et ugy, ahogy van, le kene cserelni. Meg a rust Rc/Arc/Box/... modellje is hasznos lenne, hogy 3 karakterbol GC-t es thread-safetyt kapjal. Valamint igy 2024-ben valami buffer overrun vedelem se artana, bar pointerekkel ez nehezkes, de legalabb az opcio jo lenne, stdlib szintjen akar.
Szoval nem, a C/C++ egyaltalan nem jo, viszont az is igaz, hogy a kihivoi se. Mindegyikre raferne egy massziv reszelgetes.
Mi a baj a char *-gal? Nehéz megemészteni, hogy a printf("Hello world!\n"); esetében maga a szöveg valahova teljesen máshova tárolódik, s a printf() ott csak egy pointert kap meg, ami a 'H' betűre mutat?
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
rossz helyen kopogtatsz, en profi vagyok c-ben.
de attol az meg szar.
a char*-al rengeteg gond van; a string ugye egy osszetett dolog, van ugye neki charset-je/encoding-ja, van (O(1) -ben lekerdezheto) hossza, meg nemi encapsulation se artana neki, mert ha valaki belebizgeral pointerrel, siman lehet az adott encoding-ban invalid a mar beolvasott es ellenorzott byte-stream.
Es akkor megerkezunk oda, ahol kb. az *osszes* mai nyelv/platform a stringet kezeli.
Igy van, és a akkor olyan kérdésekkel nem is foglalkoztunk amikor menet közben váltódik az irány (jobbról balra írt nyelv mint a héber vagy az arab, de amikor angol szöveg jön, akkor balról jobbra kell olvasni, szóval akkor mi is az utolsó karakter)?
Amikor a C kialakult, ASCII tábla volt. Akár az is lehetne, hogy minden karakter 7 bites, az utolsó karakter lenne 0x80-nal OR-olva. Az strlen()-nel szemben nem tudok olyan követelményről, hogy O(1)-nek kellene lennie, bár ki-ki magában megfogalmazhat efféle igényt. A C-ben nem mellesleg az a jó, hogy minden nehézség nélkül kialakíthatsz saját struktúrát, ábrázolást string kezelésére. A hátulütője nyilván az lesz, hogy a fordító nem fog róla tudni, így a string konstansok megadása elég kellemetlenné válik.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Olyan stílusban nyomod a hülyeséget, mint ha csupa óvodás hülyegyereknek nagyaráznál. Ezek a bőlére eresztett, infót sem tartalmazó posztok azok amiért nem olvassa az ember a posztjaidat.
Elnézést, hogy három és fél sorral - nyilván megjelenítéstől függ - terheltem drága életed idejét. Egyrészt elolvastad, mert írtál is rá, másrészt maradj a polfórumoknál, annak nyilván sokkal több értelme van, amikor bolonddal egymás testnedveiben csúszkálva nyilvánosan igyekeztek alázni egymást. ;) Azok a hozzászólások aztán igazán üdítők, sokat adnak a HUP közösségének életéhez.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Ha már szakmaiságodról annyira meg vagy győződve, akkor kicsit magasabb szinten kéne azt előadni!
Nem hülyeséget írtam, legfeljebb neked nem tetszett. Sőt, ha jól értem, amit írsz, az nem tetszett, hogy túl nyilvánvaló, amit írtam, így azt feleslegesnek érezted.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Én csak építő jellegű kritikát fogalmaztam meg: konkrétan nem kell hosszan ismételgetni, nyilvánvaló dolgokat. Ez olyan PCfórum szint.
meg a hash-nek, meg a list-nek, meg a set-nek, meg a ....
es akkor minden egyes projekt maganak mokanyol, tok jo, gyakorlatilag teljesen mas platform, atjarhatatlan.
ha leulsz egy python, java, go ele, akkor 10 percen belul atlatod; tudod, mire szamits, mit hol keress.
leulsz egy C ele, es szopsz, mint a torkosborz, mert az stdlib evtizedes elavultsaga miatt kvazi mindegyik total mas. ez mar most is igy van sajnos.
aztan mikor egy glib-es kodot kell atvinni qt ala, akkor meg nem megy, es kvazi ujra kell irni. tokjo.
És persze meanwhile python, java, go-ban is minden nehézség nélkül kialakíthatsz magadnak ennek ellenére bármi mást a string kezelésére, ha neked arra van igényed, nem mintha ne lehetne byteokkal pancsolni ugyanúgy....
Francokat. Ez csak addig igaz, míg egy adott nyelven, egy adott framework-ön belül maradsz.
Csak a zöldfülűek szopnak vele, a gyakorlott programozók áldják az eget, hogy a C pontosan úgy ábrázolja az adatokat, ahogy azok a memóriában vannak, és ezért nincs szívás, nem úgy, mint ha pl Python-ból kell egy összetett struktúrát átadni egy C++-ban írt függvénykönyvtárnak. Vagy csak egy NumPy eljárásnak. Vagy egy CPython wrapperelt eljárásnak.
Egyáltalán érted, miről beszélek? Fogadjunk nem. Segítek, az általad felsorolt nyelvek a típuskódot az érték mellett tárolják, így képtelenség másolás nélkül adatokat mozgatni közöttük. Hiába van CPython, JavaJNI, CGo, ezeknek mind az a hátránya, hogy nagy adatmennyiségre használhatatlanok, mert nem képesek címszerinti átadásra, hisz az általad megnevezett összes nyelv egyedi formátumban tárolja az adatokat a memóriában. Röviden: ezeknél a nyelveknél még esélyed sincs megúszni pont azt, amit a glib-qt-nál kifogásoltál, mert a nyelv része, nem tudod megkerülni. C-ben simán megoldható (tudnillik mind a glib, mind a qt egy függvénykönyvtár és még véletlenül sem része a nyelvnek).
Nagyon, nagyon, nagyon leegyszerűsítve egy konkrét példával: C-ben megteheted azt, hogy definiálsz egy struct-ot, majd egy-az-egyben betöltesz oda egy BMP képet mondjuk, és mindenféle konvertálás nélkül máris kezelni tudod. Az általad felsorolt egyik nyelvben sem lehetséges ez, mert az azokban definiált struktúra memóriaképe nem azonos a fájlbeli bájtoffszetekkel. Ezeknél a BMP struktúra mezőit külön-külön kell egyesével beolvasni és átmásolni a nyelvben definiált struktúra mezőibe, hogy azok használható Python, Java, Go stb. változók legyenek. Capisci?
Ja, bocs, most látom csak, hogy csillámfaszláma vagy. Oszt POSIX szabványról teccett-e már hallani? Nincs olyan, hogy "totál más stdlib", minden libc interfésze pont ugyanolyan, szabvány.
Itt elfelejtkezel a paddingról, amit a compiler automatikusan csinál. Egy C struct memóriabeli mérete, a tagok struktúrán belül pontos elhelyezkedése teljesen más lehet, mint amit te a programkódban látsz.
De gondolom ezt compiler direktívákkal lehet kapcsolgatni, alapvető dolog C-ben, hogy Te mondod meg, hogy a memóriában hogy legyen egy struktúra.
A compiler direktíva nem része a C szabványnak egyáltalán. Hordozható, pláne platform független kódot nem lehet vele írni.
Az meg, hogy valaki C kód helyett GCC/Clang/MSVC specifikus kódot ír, az hadd legyen az ő saját problémája.
Ok, igaz.
Lényegtelen. Miért kellene módosítás nélkül azonnal helyesen lefordulnia más környezetben ugyanannak a forráskódnak? Az a lényeg, hogy platform- és fordítófüggően megoldható az, hogy a platformok közötti binárisok átadják az adatstruktúráikat egymásnak.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Csak betévedtem ide, és olvasgatok, és tényleg jó szándékkal írom: ha valaki a kalapácsot ismeri jól (pl.: C-t), akkor hajlamos lehet mindent szegnek nézni.
Ellentmondásos érzést okoz, ha valaki elvileg mélyen ért egy területhez, de kommunikálni furcsa lekezelő stílusban kezd másokkal,
- nem jut eszébe, hogy nem csak annyiból áll a világ, amit Ő ismer, és lehet hogy a másiknak összegezve 1000-szer nagyobb tudása van.
- a másik még nem tart ott szakmailag, talán teljesen kezdő (nem jut eszébe, hogy Ő is tartott ott valamikor).
istenkomplexusban szenvedo es kulcslukon kikukucskalva (ez az egesz vilag!) emberkedo szemelynek hiaba mondasz barmit :D
Én a nyelvről beszéltem, te meg a hozzá elérhető library-kről. Jó, hogy nem hozod ide az operációs rendszer szolgáltatásait, különösképp, hogy nem csak oprendszer fölött lehet C-ben programozni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
hol?
A glib vs. qt-t te keverted ide.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Efelett elsiklottam, bocs.
Egyrészt én biztos nem, mert nem én írtam azt a kommentet.
Másrészt elsiklottál a lényeg felett, hogy a való világban más nyelveken nem kell ~minden nagyobb projektben használható string kezelést csinálni, mert jó az, amit a nyelv tud.
(Meg afelett is, hogy más nyelveken is nyugodtan implementálhatok sajátot, ha nem tetszik. Nem hiszem, hogy létezik olyan kicsit is szélesebb körben használt nyelv, amiben ne lehetne kézzel biteket meg byteokat baszogtatni as-is)
Eleve ott bukik az egész versenykiírásod, hogy a Rust nyelvhez nem számítod hozzá az unsafe -et. Az unsafe a nyelv része, éppen azért, hogy minden olyat meg lehessen csinálni vele, amit a C-vel is, de úgy, hogy a 99,9%-a sokkal biztonságosabb, mint C-ben. ;-)
És unsafe használata esetén áll az összes általatok oly bőszen hangoztatott memóriabiztonság? Na ezért nincs benne a kiírásban.
De tudod mit? LEGYEN. Az interfész által biztosított függvényekre (és szigorúan csak azokra) használható Rust alatt az unsafe, de a többi függvényre továbbra sem.
Rendben, de akkor C-ben se lehessen pointert használni, csak az interfész függvényekre.
Rendben! Ez eddig sem is volt másként!
Ehh, ki kell írnom, mert úgysem értitek: szarkazmus. A pointer használatától nem függ a fordító viselkedése, nem úgy, mint ahogy az unsafe kikapcsolja a borrow checkert. Egy C program, ami használ pointert meg egy, ami nem, nem fordul másként. A Rust esetében ez nem igaz, ott az unsafe használata MEGVÁLTOZTATJA a fordító visekedését. Egyébként meg hozzáírtam, hogy az interfész esetén használhattok unsafe-t, szóval tessék örülni és pofázás helyett egy megoldást beadni.
Mint laikus, én érteni vélem az unsafe használatának tiltását, hiába a nyelv része. Hozzáteszem, életembe nem láttan Rust kódot, a nyelvet sem ismerem, sőt, C-ben sem programoztam soha.
Viszont az eddigiekből lejött, hogy az unsafe "kiiktatja" a Rust egyik lényegi funkcióját, a védelmet. Egyszerűsítés!: az átlag programozó, ahogy megtudja, hogy kikapcsolhatja a védelmet, akkor bármi hiba esetén elsőre azt fogja tenni. Ha úgy működik a lomja, akkor nem keresi tovább a hibát, hanem úgy hagyja, gyakorlatilag megölve a védelmet nyújtó nyelv előnyét, az eredeti hibát pedig benne hagyva.
Pont ezért lettek népszerűek a nem típusos nyelvek, amikor bármit be lehet hányni bármilyen változóba, és amikor kiveszed, arra számítasz, hogy olyasmi van benne, amit szeretnél. Aztán ha mégsem, akkor majd a user észreveszi és hibát jelent. Típusos nyelvnél ez fordítási időben kiderül, csak úgy "lassabb" haladni, hogy mindig mindenféle bosszantó hibaüzenetekkel kell foglalkozni a fejlesztés során...
Azt gondolom, ez a kizárás oka, csak nincs minden egyes feltétel hosszas körmondatokkal megmagyarázva.
A Rust nyelv is olyan mint az összes többi: egy jó programozó munkáját segíti, egy rossz programozó meg pont ugyan olyan szar programot fog mindben írni.
Az unsafe nem az jelenti, hogy az adott programrész feltétlenül bajt csinál, hanem azt, hogy arra a részre nem tud a compiler garanciát adni. Mert garanciát akkor tud adni, ha a matematikai konstrukció amire a biztonság bizonyítása épül mindenütt be van tartva. Az unsafe-re a programozónak kell garanciát adnia, nagyjából ott van ahol C-ben lenne: vannak eszközei amikkel lehet hibás és hibátlan programot is írni.
Általában két céllal hozzák létre az unsafe dolgokat:
Egyik a teljesítmény növelése, amire nagyon ritkán, de szükség lehet. Azért mondom, hogy ritkán, mert a teljesítmény növelésére persze mindig szükség van, de többnyire nem ez a szűk keresztmetszet. Ritka az olyan program ami már annyira optimális, hogy már csak unsafe-fel lehet javítani rajta. De van ilyen és szükség van rá, akkor lehet.
A másik pedig a virtuális gép szabályainak nem megfelelő dolgok használata, ami lehet például egy másik nyelvbe belehívás, vagy perifériák memóriájának közvetlen írása. Ez az amire vélhetően a "versenyben" szükség volna.
Összefoglalva az unsafe azt jelenti, hogy a biztonságosságot a compiler és a runtime nem tudja garantálni, mert a bizonyítás logikájába bele nem férő módon történik a működés. De ettől még az a kód lehet biztonságos, csak azt a programozó egyéb módszerekkel kell hogy garantálja.
Nem hinném, hogy valódi probléma volna, hogy a kezdők értelmetlenül használnák az unsafe konstrukciót. Nem lesz attól egyszerűbb semmi, egyáltalán nem erről szól ez a kulcsszó. És ha mondjuk egy kernelt fejleszt valaki Rustban, akkor abban lesz fix számú unsafe, és azt ki lehet listázni a kódból és hozzá lehet mindegyikhez rendelni egy magyarázatot, hogy miért szükséges használni, és mi garantálja, hogy megfelelően működik. És az unsafe nem azt jelenti, hogy az egész programban deaktiválva vannak a védelmek, hanem csak pont abban a kis részben.
Az pedig továbbra is áll, hogy nyilván nem lesz egy kezdő szarja jó attól, hogy Rustban van, arra viszont mégis garanciát ad a nyelv, hogy a memória a virtuális gép szabályainak megfelelően fog működni. Tehát ha nem kap referenciát a kezdő programozó függvénye a b változóra, akkor annak az értékét nem tudja átírni semmilyen módon.
Egy c programban, ha 1 függvényt használsz, ami nem tuti, akkor megtörténhet, hogy felülírja az isLaunchingNuclearRocketImminent változó értékét igazra. Akkor is, ha a függvény feladata csak vonalkód nyomtatás lett volna valójában, de mondjuk valaki számok helyett betűket is írt a mezőbe, ami az átalakítás során overflowolt, és épp ez a változó csücsült ott. Ilyen Rustban nincsen, nem lehetséges. Ezt a hibaosztályt megszünteti a biztonságos memória menedzsment. De nem csak a Rustra igaz ez, számtalan nyelv régóta tudja, a Java és a .NET is ilyen volt már a kezdetektől (90-es évek), Quora szerint a BCPL volt az első nyelv, amiben biztonságos pointerek voltak.
>Azt gondolom, ez a kizárás oka, csak nincs minden egyes feltétel hosszas körmondatokkal megmagyarázva.
Ennek semmi értelme nem lenne, mert a funkcionalitás maga, például JavaScriptben megírva kb egysoros volna. Semmi értelme nincsen a probléma logikáján belül unsafe-t használni valakinek, aki tudja hogyan kell Rustot programozni. A tiltás értelme pontosan az, hogy a Rust unsafe nélkül csak Rustot tud hívni, hiszen ami kívül esik az ő VM-jén az számára nem safe. Tehát fából vaskarika unsafe nélkül a kírás. Olyan mint az, hogy "Vágjátok ki az erdő legnagyobb fáját! Ezzel a heringgel!" És ezt vagy tudja bzt és akkor nem fair a kiírás, vagy nem tudja, és akkor meg olyat kritizál amit nem ismer. Vagy lehet az is, hogy a C-be híváshoz nem kell az unsafe kulcsszó, de attól még az ugyanaz. Például Java-ban a native kulcsszó jelöli a JVM-ből kilépő hívást, amivel például C libraryt lehet hívni. Tehát nem unsafe a neve, de attól még az persze unsafe, mert a JVM nem tudja ellenőrizni, hogy odakinn ki mit hogyan fog felülírni.
1. nem is kell garanciát adnia a fordítónak, mivel az az interfész önmagában garantáltan safe. Ha a Rust nem lenne képes egy külsös safe függvény meghívására, az biza a nyelv hibája lenne. (Egyébként de, képes, mivel immutable a bemenet, de ezt is leírtam már vagy százszor)
2. az interfész esetében egyébként is megengedett az unsafe, mivel láthatóan nem tudjátok, hogy kell használni a Rust-ot, szóval ne gyere azzal, hogy nem lehet
JUJJ. Egyrészről mint mondottam volt, az interfész esetében nincs tiltás, másrészről a Rust-ot nem is VM futtatja. Te valami iszonyatosan nagyon el vagy tévedve.
Most már meg kellett néznem a specifikációt, mert már idegesít, hogy én sejtem hogy minek kell ott lenni, mivel ismerek jópár nyelvet, de pont a Rustot nem. Te meg olyanokat mondasz, ami nem lehet ott. Szóval lássuk a specifikációt: https://doc.rust-lang.org/reference/unsafety.html
"Unsafe operations are those that can potentially violate the memory-safety guarantees of Rust's static semantics.
The following language level features cannot be used in the safe subset of Rust:
Dereferencing a raw pointer.
Reading or writing a mutable or external static variable.
Accessing a field of a union, other than to assign to it.
Calling an unsafe function (including an intrinsic or foreign function).
Implementing an unsafe trait."
Tehát raw pointer access és a foreign function call is unsafe a specifikáció szerint. Ami nem meglepő, hiszen ezek kívül esnek a _virtuális gép_ hatáskörén. Mindegy, hogy valójában van-e runtime virtuális gép, a programozási nyelvek specifikációjában virtuális gépnek hívják a működés specifikációját, mivel ez nem egy létező gép, hanem virtuális, pont a nyelv specifikálja, de nincsen valódi gép ami így működik.
Az is mindegy, hogy kell-e ezekhez unsafe kulcsszó, a lényeg, hogy a specifikáció egyértelműen megjelöli, hogy a Rust VM szempontjából ezek unsafe konstrukciók. Vicces egyébként, hogy épp egy fejezettel előtte van az inline assembly, ami nyilván szintén unsafe, de itt elfelejtették újra megemlíteni: https://doc.rust-lang.org/reference/inline-assembly.html
Összességében a Rust specifikációja nem látszik annyira kidolgozottnak, mint például a Java nyelvé (ez az amit régebben mélyebben olvasgattam), de nagyjából az van benne amire számítottam.
Na most akkor döntsd el légy szíves, hogy konkrétan az unsafe kulcsszó az ami tiltott, vagy az unsafe konstrukciók általában? Egyébként leírtuk, hogy a videó RAM elérés az, amihez szükséges a "raw pointer" használata, ha ezt tiltod, akkor nem lehet megcsinálni és visszajutunk a róka és a daru vendégségéhez. A versenykiírás legyen először egzakt, addig nem állnék neki vadul kalapálni a pályaművet.
Már leírtam konkrétan, görgess egy kicsit feljebb. Semmi sincs tiltva, ami a megoldáshoz feltétlenül szükséges!
Egyáltalán nem szükséges.
Azt azért lássuk, hogy ha igaz, amit írsz, és ehhez tényleg ki kell kapcsolni a memóriaellenőrzést, akkor nincs jogotok arra verni a nyálatokat, hogy hű, de jó a Rust, mert van benne memóriaellenőrzés!
Van benne memóriaellenőrzés, csak épp muszáj kikapcsolni (Te állítottad ezt, nem én). Pontosan az ilyen marketing bullshitekre akartam rámutatni ezzel a kiírással!
ps: egyébként tényleg nem kötelező a video RAM eléréshez a "raw pointer", használhatnál helyette pl. sima mezei tömböt és linker szkriptet. De ez csak egy lehetséges megoldás a sok tucatnyi közül.
Baszki, a tortenelem tenyleg megismetli onmagat.
Tobb mint negyed evszazaddal ezelott, a legutolso programozo versenyen azt nyertem, hogy a Zengo nevu kocsmaban Ujpesten egy hetig (vagy egy honapig? fene tudja mar) ingyen ihattam az osztalytarsam kontojara.
A feladat a sima "Egy sakktablan hany kiralynot tudsz elhelyezni anelkul, hogy barmelyik utne barmelyiket?" volt. A szempont a kod tisztasaga es a lepesek szama volt. A kollega Turbo Pascalban irta, en Borland C++ nyelven.
Az remlik, hogy rekurzivan irtam, de volt valami csalas, mert bizonyos esetekben tobbet leptem vissza, mert elore bejeloltem, hogy kesobb mely mezok nem lesznek jo. Vagy valami hasonlo, mar nem emlekszem.
Na mindegy, a lenyeg, hogy a C/C++ versus akarmi vita mindannyiunkat tul fog elni, es meg az ukunokaink is ezen fognak veszekedni!
Haha, a jó öreg klasszikus backtrack?
Tényleg jó lenne, ha valóban ismételné magát, de sajnos a Te versenyeddel ellentétben - ahol volt egyáltalán mit összehasonlítani -, itt most csak siránkozás és szánalmas kifogások érkeznek bármiféle értékelhető megoldás helyett :-( :-( :-(
Bár sejtettem, hogy ez lesz, de azért szívem mélyén azt kívánom, bárcsak rendes verseny lenne ez is. De van még egy hónapjuk, talán valaki rámcáfol addig.
(Egyébként felőlem jöhet Pascal megoldás is, bár az nem egy agyonhypeolt nyelv, mint a Rust, és annál sosem volt kérdés, hogy megoldható-e benne ez a feladat. De ezektől függetlenül is jó lenne látni mégegy öreg motorost! Rég használtam Pascal-t, de legutóbb is pont egy rendszerprogramot kalapáltam össze fpc-ben demonstráció gyanánt.)
En mar reg nem programozok "nagyban", mostansag 95% bash, mert rendszergarazda vagyok, konkretan evek ota nincs semmilyen IDE a gepemen.
De egyebkent a memoriakezeles es a leakeles elkerulese mar 25 eve is tema volt. 2000 -ben keszullt vizsga munkam egy olyan C++ osztaly volt, ami a himem.sys -re tamaszkodva egyfajta virtualis memoriat biztositott az ot felhasznalo kod szamara. Lokalis valtozokent kellett peldanyositani, de a sok (lokalis) peldany egy static valtozon keresztul tartotta egymassal a kapcsolatot. Az adott peldanyt hasznalva lehett rajta keresztul rohadt nagy meretu tombot, listat, fifot, lifot foglalni, es hasznalni. DOS alatt lehetett igy akar tobb MB-os adatszerkezeteket egyben kezelni. A josag az volt benne, hogy ha kileptel a lokalis valtozod ervenyessegi tartomanyabol, akkor a destruktor felszabaditott mindent, amit eddig foglaltal, ergo esely sem volt leakelni, ha rendesen hasznaltad.
Persze ez csak egy technikai bemutato volt, hiszen addigra mar volt vedett mod, es mindenki Windows 98 -at hasznalt, igy a DOS szukebb keretei a kutyat sem erdekeltek, de azert jo mulatsag volt megirni.
Fura, hogy evtizedekkel kesobb is ugyanazok a problemak koszonnek vissza, amelyek csak reszben vannak jol megoldva. A Java GC jo elgondolas, de a finomhangolas azert be tud kavarni. Irtad, hogy Ada-ban irtal kodot, nos, egy volt munkahelyemen olyan "biztonsagos" Ada kodot kellett kezelnem, ahol nagyjabol minden valtozohoz kulon tipust hoztak letre, hogy biztosan ne lehessen kisebbet-nagyobatt beletolteni mint amire a kolto gondolt. Ez elmeletileg jo, csak gyakorlatilag a fene se tudta fejben tartani, hogy a tobb tucat integer valtozobol melyik milyen range ertekekkel rendelkezik. Agyf4szt is kaptam tole rendszeresen. Nem sokkal kesobb meg a dolog masik oldala jott szembe ugyanannal a cegnel, amikor C# programozoi sapkaban allandoan olyanokat kellet irnom, hogy if (alma != null) alma.valami(); mert a hatam borzongott, hogy mi az isten ez a kupleraj, hogy kerulhet ide egy null ertek, es ha null, akkor miert nyeljuk le csendben a nem teljesen jo mukodest, ahelyett, hogy megallitjuk a szemet be, szemet ki folyamatot?
Szoval nem csak nyelvek, de a programozasi szokasok, modszertanok is tudnak annyira masok lenni, hogy ihaj.
Én nem tudok ilyet írni, viszont nem tudom lesz-e belőle valami (remélem igen), szeretem az ilyen kódpornókat. :)
"Sose a gép a hülye."
Elsőre ez a kép jutott eszembe. Sajnos lehetséges, hogy nem mérhető, hogy melyik nyelv a legjobb. Túl komplex, mennyi mindentől függ. Ott van a nyelv megtanulásához szükséges idő, a kódolási idő, stb...
És milyen jó, hogy sosem ez volt a kérdés, és hogy ennek a versenynek egyáltalán nem is ez a célja!
Ezek mind egyénfüggő dolgok, semmi közük a nyelv kifejezőerejéhez. Milyen jó, ezen szempontok egyike sem szerepel a kiírásban!
Onellentmondasba utkoztel, de gondolom valami kis szemelyeskedessel es onmagad piedesztalra emelesevel majd kimagyarazod magad: :D
"Elegem lett a sok nagyszájúból, ezért úgy döntöttem, lehetőséget adok nektek a gyakorlatban is bizonyítani, hogy valójában a gyakorlatban egyik csodanyelv sem képes leváltani a C-t"
:D
Ha jól értem, egy nagyon fontos dolgot felejtettél ki az értékelési renszerből: a befektetett időt.
Mikor szarul voltunk fizetve ez nem volt releváns, de most igen.
Ha jól értem, akkor csak kötözködsz, mivel még egyáltalán nincs is mit értékelni. Küldj be előbb egy megoldást, aztán majd visszatérünk rá!
A befektetett időt egyébként szándékosan hagytam ki, hogy a programozói készségek ne számítsanak bele, csak a nyelv. Nekem a C megoldás kb. 15 percet vett igénybe, az Ada kb egy órát (mert vétettem egy hibát, és debuggolni kellett). Ezzel úgysem képes versenybe szállni senki itt a HUP-on, ezért nem is lenne fair, úgyhogy kihagytam a szempontok közül, és egységesen 1 hónapot adtam a megoldásra.
A teljesség kedvéért az egész versenykiírásra ráfordított idő:
- megtervezni a szabályokat kb. 2-3 óra volt (ezért ennyi, mert közben több nyelv dokumentációját is átnéztem ellenőrzés végett),
- a betöltőt elkészíteni kb. fél óra, ebben benne van az ELF és PE/COFF formátum lekezelése, a megszakításvezérlő és a PIT felprogramozása is. Ehhez felhasználtam korábbi projektek forrását, azért ilyen kevés.
- az Assembly referencia megoldást elkészíteni kb. 10-15 perc volt (ez nem számít ugye bele a versenybe, de a betöltő teszteléséhez szükség volt rá, hogy legyen egy jól behatárolt baseline)
- további 1 óra volt a tesztelés és debuggolás qemu és bochs virtuális gépeken. Bár a kiírás csak qemu-ra szól, egy másik virtuális gépen is leteszteltem a biztonság kedvéért.
- plusz kb. 10-15 perc volt megírni a HUP topikindító bejegyzést.
Szumma: kb. 1 munkanap, tokkal-vonóval. (csütörtökről péntekre éjjel álmodtam meg a versenyt, pénteken kb. délelőtt 10 óra magasságában álltam neki, és a poszt fél ötkor került ki a HUP-ra.)
Érdekesség: a tesztelés során előjött egy Clang bug MS fastcall ABI használata esetén (parancssori kapcsoló figyelmen kívül hagyása), ezért módosítottam az interfészt, és hozzáadtam a függvény által használt lokális változók méretét paraméterként az iretq() függvényhez, hogy egészen biztosan bármilyen nyelvből, bármilyen fordító által generált kód esetén használható és probléma nélkül meghívható legyen.
Igen, kotozkodok, ugyanakkorb felreerted. Pontosan tudom, hogy csak C-ben irt palyamu fog nyerni, a masodik helyezes erdkel jobban, Az kevesbbe, hogy sokx modatban dicsered magad.
Egy jotanacs: fogalmazz tomoren, lenyegretoroen.
Én csak azért jöttem, hogy a HUP nagypofájú "programozói" ^ hogyan szerepelnek majd a megmérettetésen 🍿
trey @ gépház
Úgy tűnik a hozzászólásokból, hogy a csapat egy jelentős részének - ide értve magamat is - már megkoptak vagy soha nem is voltak elég mély ismereteik ahhoz, hogy egyáltalán értsék, hogy mégis mi a nyavaja történik vagy kéne történjen itt pontosan, mi fán terem a rendszerprogramozás. Ennek ellenére persze egyesek meglehetősen vehemensen osztják az észt :)
Nem programoztam rustban, még csak nem is nagyon foglalkoztam vele, szóval gondoltam doksi jóbarát, nézzük mit tud az unsafe:
https://doc.rust-lang.org/book/ch19-01-unsafe-rust.html
Aztán ismerős volt, már idézett valaki ebből.
Ebből a felületes kezdeti bevezetőből nekem két dolog jön le:
1. Alacsony szinten programozni rustban usafe nélkül nem lehet, azért van, hogy ha valaki ilyet akar, akkor tudjon.
2. Kifejezetten cél, hogy lehessen unsafe-et használni, ez egy üzemmódja a nyelvnek adott feladat esetében és akkor a programozó tökönszúrhatja magát ha akarja.
Tehát vannak dolgok amiket a nyelv tervezői szerint Rustban is deklaráltan veszélyesen csinálnak az emberek. Namármost akkor megintcsak két dolog lehet.
1. Amiért szidják a C-t, hogy szar meg nem biztonságos, az igazából zömében nem az alacsonyszintű rendszerprogramozás, hanem a magasabb szintű pl. OpenSSL, GTK (még mielőtt nekem esnének, hogy ezek nem is szarok, ezek csak példák magasabb szintű felhasználásra), ahol azért használják mert egy C formájú kalapáccsal oda is oda lehet baszni.
2. Azokat a feladatokat amiket meg lehet oldani Rusttal safe módban nyilván meg lehet írni C-ben is megfelelő eszköztámogatással éppen olyan biztonságosan. Akkor az a kérdés, hogy kényelmesebb-e Rustban dolgozni?
Nekem elsőre a Rust szintaxisa elég fura, de lehet csak szokni kell. :)
Szerintem jól látod a problémát. Amikor a tanult kolléga rendszerprogramozásról beszél, akkor ő lényegében nagyon alacsony szintű, kb. periféria programozásra gondol, miközben a rendszerprogramozás ennél jóval bővebb: ebben benne benne van a kernel és a hozzá kapcsolódó szolgáltatások (scheduler, file system, networking, stb.) és sokszor még olyan közös könyvtárak, melyekre utána a magasszintű nyelvek építenek (például kriptográfia műveleteket/titkosítást megvalósító könyvtárak, ui könyvtárak, web szerverek, adatbáziskezelők, stb.)
"Operating systems, device drivers, BIOS and other firmware, compilers, debuggers, web servers, database management systems, communication protocols and networking utilities are examples of system software."
https://devopedia.org/systems-programming
És igen, alapvetően két okból írták ezeket a rendszerprogramokat C-ben: (1) mert ehhez értettek, ezt ismerték (kalapács-szög) (2) mert nem volt alternatíva.
Pontosítsunk: ennél a versenynél azért nem vettem ide az általad felsorolt bővebb halmazt, mert egy számláló növeléséhez és kiírásához nincs szükség ezekre. Ugyanezen okból biztosítottam a betöltőt, hogy még PIC + PIT eszközmeghajtót se kelljen írni, és a CPU funkciókat is beburkoltam magas szintről hívható eljárásokkal, hogy a függvénykönyvtárak függőséget is kiiktassam.
Egy kis pontosítás a (2)-eshez: továbbra sincs alternatíva. Eddig egyetlen megoldás sem érkezett, csak picsogás, siránkozás, kifogások áradata. Amíg az ellenkezőjére nincs bizonyíték, addig továbbra is fel kell tennünk, hogy a Rust alkalmatlan a feladatra.
Történelmi érdekesség: mind a Pascal, mind az Ada bizonyítottan rendszerprogramozási nyelvek, amik valós alternatívái lehettek volna a C-nek, de valamiért mégsem váltották le azt.
https://www.redox-os.org/
Welcome.
Ez tele van unsafe-el, extern "C"-vel, ez nem memóriabiztos natív Rust. Welcome!
Mint ahogy a tanult kollégák elmondták, ez a trade-off: bizonyos részeket nem lehet memory safe-re írni, mert nem. Viszont, ha a kódom 99%-át memory safe-re tudom írni, akkor csak a maradék 1%-ra kell koncentrálnom hogy ott ne legyen probléma.
https://doc.redox-os.org/book/ch01-06-why-rust.html
Csakhogy ez Rustban íródott, itt nincs egyetlen külsős függvény sem! Ha a kód 99%-a unsafe mentes lenne, nem szólnék semmit, de ez az állításod hazugság. Gyakorlatilag a függvények több, mint 80%-a unsafe!
Konkrét ellenpélda: indokold meg, ennél függvénynél például miért kell az unsafe-t, ha az egyszer nem használ memóriát egyáltalán és csakis belsős Rust függvényeket hív! Ha igaz lenne, amit a Rust dokumentáció ír, akkor itt nem szabadna, hogy szerepeljen az unsafe.
(Abba, hogy mennyire elképesztően nem hatékony, és hogy a programnyelvtől függetlenül is konkrétan hibás ez a kód, inkább bele se menjünk.)
Gondolom mert továbbhív egy másik függvénybe amelyik ugyanúgy unsafe, ami a nap végén gondolom valami C-ben implementált cuccot hív (a fájl elején ott van a
use crate::
).Egyébként 513 unsafe van a teljes kernelben, legalábbis a kereső nekem annyit adott vissza. Ennél felteszem egy "kicsivel" több függvény van.
Na akkor ízlelgessük kicsit, amit itt írtál.
1. továbbhív egy unsafe függvénybe, ezért ennek is unsafe-nek kell lennie: ezzel gyakorlatilag azt mondod, hogy effektíve lehetetlen safe Rust kódot írni, merthogy a hívási lánc végén minden alacsony szintű függvény unsafe.
2. C-ben implementált cuccot hív: nocsak, nocsak, mégegy beismerő vallomás, hogy a Rust nem alkalmas a C leváltására? Ez a mondat minden kétséget kizáróan ezt jelenti.
Igen, valószínűleg a Rust nem tudja 1-az-1-ben leváltani a C-t, viszont kellően le tudja csökkenteni azon helyzeteket, ahol C-t (vagy pl. assembly-t) kell használni. Ez pedig lehet, hogy bőven elegendő, és már előrelépés. Neked nem, neked jó lesz a C, másnak meg igen.
Az állítás ezen részét még mindig nem látom bizonyítottnak.
Mit ahogy azt sem, hogy hogyan lehetséges egyáltalán safe Rust írása, ha
1. állításotok szerint nem lehet mindent safe-ben megírni
2. a raw pointer unsafe például, és mivel ez nélkülözhetetlen bármilyen memóriaallokátor írásakor, így a memóriallokátor sem lehet safe
3. safe-ből nem hívható unsafe, csak unsafe-ből, tehát minden dinamikus memóriát használó eljárás, ami a memóriallokátort hívja, muszáj, hogy unsafe legyen
4. ha minden memóriafoglalás magával vonza, hogy unsafe, akkor hogy is lehetséges safe Rust kódot írni?
A baj itt az, hogy ez az egész egy humbug, és a hosted Rust alkalmazások csakis azért lehetnek "safe"-ek, mert az std felrúgja a nyelv saját szabályait, és ellenőrizetlenül, csakazértis safe-nek van bevasalva ez a függvénykönyvtár, holott ha pusztán natív Rust-ban akarnád implementálni, akkor képtelenség lenne ezt megvalósítani a fent sorolt okok miatt.
Ez valszeg csak egyik irányba kötelező. Unsafe kódot csak unsafe kódból lehet hívni, de safe kódot lehet unsafeből.
Igen, de ez az unsafe hív safe-t irány sosem volt kérdés.
A gondot az okozza, hogy az alacsony szintű függvényeknek muszáj unsafe-nek lenniük, így tehát az azokat hívó magas szintű függvényeknek is (ez a safe hívna unsafe-t irány). Mégis, valahogy azt hazudják, hogy a magas szintű függvények safe-k lehetnek, holott ez a Rust saját szabályai szerint sem lehetséges.
Ha tényleg betartjuk a Rust dokumentációban foglalt szabályokat, akkor nyilvánvaló, hogy lehetetlen safe Rust programot írni. Ez csakis úgy lehetséges, ha felrúgjuk a specifikációban foglalt safe nem hívhat unsafe-t szabályt, másként nem. Ezzel pedig pont a lényegét veszíti el a safe kulcsszó.
Ez nem így van, csak maga a hívásnak kell unsafe-ben lennie, az egész hívó függvénynek nem, az lehet safe.
Az általad belinkelt, de még mindig el sem olvasott doksiban ez is benne van, lásd 19-6 lista. ;-)
Állításod szerint ez érvényes safe Rust kódnak minősül:
Köszönöm, hogy felhívtad erre a figyelmem, álmomban sem gondoltam volna, hogy ennyire szar lenne a Rust! Ezek szerint a Rust memóriaellenőrzési garanciája konkrétan egy fabatkát sem ér.
Ez tökéletes bizonyíték arra, hogy a Rust nem is memóriabiztonságos nyelv!
Disclaimer: nem értek a lovakhoz :)
Szerintem itt félreérted a koncepcióját a rustnak.
Miután minden hardver közeli funkció, és egyéb külső függvény alapvetően "unsafe" (nem tudja a fordító bizonyítani a biztosságát a kódnak - mert nem látja hogy mit tartalmaz) ezért unsafe-be kell tenni.
Viszont aki az adott függvényt/függvénykönyvtárat írta "vállalja" hogy safe a kód, így a ráépülő kódok safe-k lesznek, és azon már működnek a nyelv-szintű garanciák.
Itt vélhetően rosszul gondolja a kolléga, nem C-t hív, csak unsafe műveletet végez.
Nincs benne C hívás, hanem még a C-s könyvtárat is újraírták Rust-ban.
Mivel nagyon unalmas már a siránkozásaitokat és kifogásaitokat hallgatni, a továbbiakban csak azokat veszem komolyan, akik be is adnak valamit.
Addig is mégegyszer, nyomatékosan:
- a repóban egyetlen egy C forrás sincs.
- a feldatatban semmi C specifikus nincs. Egy számláló növelése és kiírása a képernyőre nem szabadna, hogy gondot okozzon bármilyen rendszerprogramozási nyelven.
- bármilyen nyelv, bármilyen fordító, bármilyen szkript, bármilyen segédprogram használható a lefordításhoz.
- megoldásnak egy ELF vagy PE/COFF formátumú futtatható binárist kell prezentálni, ami egybefűzve a formátumnak megfelelő betöltővel fut qemu-n.
- beadás határideje 2024. április 8. 00:00:00 UTC.
Ennyi.
Én még talán annyit vettem volna bele a kiírásba, hogy valaki ne AI-val írassa, de az meg elég ellenőrizhetetlen mondjuk.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Felőlem aztán... A nyelvet hivatott tesztelni a verseny, nem a programozót.
Kicsit játszottam vele, ráengedtem a ChatGPT-t (az ingyenes verziót), ha már az NVIDIA meg a Microsoft szerint is az AI fog programozni. Nem mondom, hogy teljesen értem mindegyiket. Mert, bár érdekelnek a programnyelvek, sokkal megismerkedtem, egyikben sem írtam programot.
Megírattam vele Free Pascal, ADA, Forth (VFX), Rust, Go és Zig nyelven is. Már csak le kellene tesztelnem a generált kódokat, hogy egyáltalán működőképesek-e. Sajnos ennyire nem vagyok otthon programozásban, hogy magam is meg tudjam írni őket.
Természetesen nem rontom el bzt kolléga kihívását! Figyelmesen követem, hogy valamelyik babzsákfejlesztő felveszi-e a boxkesztyűt!?
Nagyon szépen köszönöm, hogy vetted a fáradságot és legeneráltattad ezeket a megoldásokat!
Ha esetleg feltennéd valahova a forráskódokat, akkor simán lehet, hogy lesz itt jelentkező, aki szívesen segít Neked lefordítani őket, mert ez a teszt már önmagában is roppant érdekes! (És egyébként még a versenyszabályoknak sem feltétlenül mond ellent, azt írtam, bármilyen segédprogram használható. Kicsit sántít ugyan, mert nem a fordítási környezet része, de vegyük úgy, hogy az MI is egy fordítási segédprogram ez esetben!)
Amint a fordítással megvagy, akkor csak annyi dolgod, hogy eléfűzöd a betöltőt és az így keletkezett fájlt átadod a qemu-nak:
Elvileg ennyi letesztelni.
A tisztánlátás végett annyi kérésem lenne csak, hogy két kört csináljunk. Első körben próbáljuk meg lefordítani pontosan azt, amit generált. Második körben meg azt, amibe esetleg kézzel bele kellett javítani, hogy forduljon, vagy hogy helyesen működjön.
Zig? Azmiaz?
Összevetve a beküldött kódokkal, nincs a helyzet magaslatán. Most csak Rust megoldást kértem tőle, de olyan dolgokat használ, ami ki van kötve, hogy nem lehet. Busyloop-ban várakozik, inline assembly-t használ, a loader asm forrását is megkapta és a struct-ot is, de a PIT inicializálást megírja újra. :-)
De amúgy jó ugráltatni!
Ha ennyire sírtok, hogy külsős függvény így-úgy unsafe, akkor megírhatjátok ezt a négyet unsafe nélkül natív, belsős Rust függvényekben is!
- load_idt: betölti az IDT-t. A megadott buffert a függvény nem írja és még csak nem is olvassa, csupán csak betölti a címét a CPU-ba
- enable_interrupts: a CPU megszakítások engedélyezve jelzőbitjét állítja be
- disable_interrupts: a CPU megszakítások engedélyezve jelzőbitjét törli
- iretq: lenyugtázza a megszakításvezérlőben az IRQ-t és visszatér a megszakításkezelőből
Választhattok:
1. vagy használjátok az interfészt és ezeknél az unsafe-t
2. vagy nem használjátok az interfészt, Rust-os függvényekkel implementáljátok le, de ekkor nem használhattok unsafe-t
Mi ez a C? Sose hallottam róla ...
Úgy is van! Mind a betöltő, mind a referencia implementáció Assembly-ben lett írva! :-)
Na kérem, ez egyszer és mindenkorra eldőlt, az összes picsogó, aki szerint C-re lett kiírva a verseny meg ilyenek, jobb, ha bocsánatot kérnek!
Befutott az első Rust megoldás. Nincs nightly rustc-m, így letesztelni nem tudtam, de nekem teljes és nagy valószínűséggel helyes megoldásnak tűnik!
Akkor nem szívatom magam a ChatGPT által adott megoldással. Játszós környezetben telepítettem Rust-ot és próbáltam a ChatGPT által adott válaszokból megoldani, de ezidáig nem született megoldás. Mondjuk egyelőre ez annyit jelent, hogy prompt engineer-ként sem fogok tudni elhelyezkedni egyelőre. :-D
szerk.: az első pályaművet letöltöttem és kipróbáltam. Ahogy sejtetted működik. De gyanítom ez nem is volt kérdéses. A beküldő kódját megnézve nekem az jött le, hogy hasonlóan hozzád, érti is amit csinál. Nem úgy mint a többi szájkaratés. De mivel én csak ugatom a témát, a véleményem nem túl releváns.
A "többi szájkaratés", aki nem tud ilyen alacsony szinten programozni, az éppen azért
szájkaratézottérvelt, hogy az ilyen megoldásokat is el kelljen fogadni.Úgy látszik, hogy mégsem "szájkaraté" volt, hanem megalapozott érvelés, amit bzt, a fenti hozzászólása alapján, el is fogadott.
Akkor ezt most hogyan kell értelmezni? Elfogadod azt, hogy a C lecserélhető?
Úgy kell érteni, hogy alaptalanul vádoltál azzal, hogy a versenykiírás "speciális" meg hogy C specifikus lenne.
Szerintem nem értettél meg.
Ma délután két óra alat eljutottam Free Pascalban egy 90%-os megoldásig. :) Az interrupt handlerrel van valami gebasz, amúgy megy. Olybá tűnik mintha vagy az IDT táblaban a setup vagy a meghívása félremenne. De még reszelem. De az már biztos, hogy az x86_64 rendszerprogramozási/ELF tudásom hiányos hozzá, nem az eszköz. Szóval grat mindenkinek h. felértek egy Pascal szintjére. :P
Amúgy ez remek játék, csak az a bajom, hogy rohadt specifikus dolog, amihez leginkább azt kell ismerni, hogy a programozási nyelvedet hogy lehet a kőbróken by design és legacy all the way down x86_64 architekúra köré csavarni. Attól hogy ez megy, még nem biztos h. nagy alkalmazások fejlesztésére alkalmas a nyelv. Ráadásul ez a szintű interrupt handling még a nagy OS-ekben is többnyire assemblyben van írva, pedig azok C-ben készültek. :)
De amúgy ettől függetlenül élvezem ezeket a kihívásokat, szóval elszívok még vele, csak ezzel nem dől el semmi, nem bizonyít semmit.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
És meg is van - jó kis compiler bug, így jár aki a Git main-en él... :D Az IDT összerakásakor a compiler félreoptimalizál valamit. Egyelőre wörkaround befigyelt, majd kifixelem a compilert is, vagy anyázok az x86_64 port karbantartóinak... De mindenesetre most már szépen megjönnek az interruptok a handlerbe.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Így: https://github.com/chainq/langcontest-pas
Ja a bináris (ELF) amúgy 664 byte. Ebből 256 byte csak a 4db ELF section header, amik nélkül 408 byte-ról beszélünk. Ami kisebb mint a kézzel írt assembly 425 byte-ja... :) Tudom, sántít az összehasonlítás, de azért vicces. Még van egy hónapom, talán majd kiszopom hogy hogy lehet olyan ELF-et gyártatni, amiben nincsenek sectionök.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Köszönöm! Hozzáadom a Pascal megoldásodat!
Igen, a verseny célja az, hogy a nyelv kifejezőerejét teszteljük. Mivel a C egy rendszerprogramozási nyelv, minimum elvárás, hogy a többi versenyző is képes legyen erre, emiatt lett a feladat egy rendszerprogram.
Szerintem egy rendszerprogramozási nyelv alkalmazásprogramozásra is alkalmas kell legyen, hisz utóbbi a szűkebb funkciókat igénylő halmaz. (Lásd pl. Pascal alkalmas mindkettőre, ugyanakkor például a Java csak alkalmazásfejlesztésre való, rendszerprogramozásra nem. Ezzel szemben nem ismerek olyan nyelvet, ami csak rendszerprogramozásra való, ellenben alkalmazásfejlesztésre nem használható.)
És itt is. Direkt azért biztosít interfészt a betöltő, hogy ez ne legyen probléma.
De az a baj, hogy egy x86_64 rendszerprogramozás az bármiben gusztustalan, még C-ben is. Ez kb. olyan mintha azzal tesztelnénk melyik (emberi) nyelv mennyire szép, és milyen "kifejező ereje" van, hogy milyen jól lehet benne kínrímeket írni. "Mint Zuzuval beszélgetni. Enyhén szórakoztató, de leginkább fájdalmas." Ebből a szempontból a C az különösen olyan, hogy meg lehet írni benne egy csomó mindent amit másban nem, nyolc rétegű makróhalommal meg pragma-túltengéssel, csak minek. 2 sor inline assembly többet ér, még akkor is ha az már "nem a nyelv része". (És most itt nem akarok Pascal vs. C-be kezdeni, mert azt tényleg minek, az a vonat min. 35 éve elment.)
Mindegy. A szentimentumot értem a newschool nyelvek ellen, de attól még továbbra is úgy gondolom, hogy ez nem egy jó teszt. Pluszban, a Rust-nak mintha lett volna egy embedded working groupja, amiben különösen erre mentek rá, hogy hardware közeli dolgokra, igaz főleg mikrokontrollerek és társaik programozására jó legyen. Szóval az ilyen tesztekkel az a baj, hogy ahogy az idő halad, egyre extrémebb és extrémebb dolgokkal kell majd "tesztelni", hogy mennyire nem jó semmire. És őszintén, már egy x86_64 low-level interruptkezelés is elég extrémen ronda...
Én legalább bevallom hogy szubjektív okokból nem kedvelem a Rust-ot, pl. szerintem ritka gusztustalan a szintaxisa, de mivel mások meg a Pascalról gondolják ezt, ezért nem fogunk összeveszni, inkább tisztelem felebarátaim elmebaját és kész. Meg a szokásos overhype miatt, miszerint ez majd megoldja az afrikai éhinséget, a globális felmelegedést, feltalálja a mindenség elméletét, meg a toronyórát lánccal is, csak én már elég öreg vagyok hozzá, hogy emlékezzek legalább 3 ilyen ciklusra szakmánkból. Én még emlékszem, amikor a Java volt a jövő, abban írtak OS-t, meg a sok okos elhitte hogy "van garbage collector, ezért nem lehet memory leaket csinálni". Aztán egész jó pénzt kerestem abból úgy egy évtizedig, hogy az ilyen fejlesztők kódjait fixelgettem. :) Már kezdődik ez a trend a Rust-nál is, most pl. a Microsoft kiadta a Rust-ban Windows-ra írt sudo klónt, aminél feltüntették h. mekkora sekureti stonks, mert hogy Rust, na egy hozzább értő szét is kapta mint floki a lábtörlőt, mert "az ellen nem véd" ha valaki elbassza az ellenőrző logikát és emiatt az egész cucc a nagyon memory-safetyvel együtt simán bypassolható. Szóval ja. Nekem ez a fajta hívő-hozzáállas, és a kritikai gondolkodás hiánya, ami nem tetszik egy csomó newschool nyelvben, és a Rust ebból az elsőszámú példa. De majd kinövöm, gondolom. A Java-t meg a Pitont is utáltam eleinte, aztán mikor végül valamit dolgozni kellett benne, akkor csak ment... Mondjuk hobbiból továbbra sem megyek egyik közelébe sem...
Legalul a processzor úgyis csak a goto-t meg a pointereket ismeri. Hogy ki mivel akarja kábítani magát, hogy ez nincs így, majdnem mindegy. :) Köszönöm, hogy elmondhattam, leültem.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Miért hagyta el bzt a barátnőjét? Mert nem C melltartót hord.
Butasagot beszelsz hiszen a C/C++ azt jelenti, hogy C es C meret felett jon a paros menyorszag, es ezzel en magam is teljesen egyet tudok erteni. :-)
És úgy gondolod, hogy ez egy ideillő, személyeskedésmentes, szakmai jellegű hozzászólás a részedről?
Oregon, golgota, asch, enpassant
Kiderült, hogy a vádaskodásotok teljesen alaptalan volt. Tényleg nem érzitek úgy, hogy illendő volna egy bocsánatkérés?
Nem vádaskodtam egyetlen egy hozzászólásomban sem.
Azt nem éreztem fair-nek, hogy az unsafe-et nem engeded meg, így megoldhatatlanná válik a feladat Rust-ban.
Erről írtam minden hozzászólásomban.
Kezdetben elfogadtad, hogy az interfésznél lehessen, végül pedig azt is, hogy memória direkt írásánál is. Így én elértem a célom, Rustban is meg lehet oldani a feladatot.
bzt, nem kellene bocsánatot kérned, hogy kezdetben kizártad mondvacsinált okokra hivatkozva a Rust-ot?
Egyébként én elfogadom bocsánatkérésnek azt, hogy végül is elfogadtad az érveimet.
Te írtad: Nem gondolnám, hogy közülük van egy is, aki hajlandó lenne ezt Rustban megírni.
Ami valójában nem fair, az az, hogy azzal jöttök, azért jobb a Rust, mert memóriabiztos, miközben a legeslegelső dolog, amit itt követeltetek, az az, hogy unsafe-el kikapcsolhassátok a memóriabiztonságot...
Egyébként meg még mindig nem adtál be semmilyen megoldást, csak pofázol. Nem bántásból mondom, csak ténymegállapítás.
Úgy látom, hogy még mindig nem érted. Megpróbálom a beadott Rust kód alapján elmagyarázni.
Ebben minden safe, kivéve az az egyetlen sor, ami írja a direkt memóriát. Ha az nincs megengedve a Rust-nak, akkor nem lehet megírni Rustban a feladatot.
Itt még tovább lehetne csökkenteni az unsafe r észt, hiszen a a vga.add(i * 2) is kitehető, illetve a digit növelése 48-cal.
Tehát így a legkevesebb az unsafe rész:
Egyáltalán nem. Sőt!
Egyrészt most már, hogy van pályamű - amit majd én is meg fogok nézni magamnak, eddig nem láttam -, mostantól mindannyian mondhatjuk, hogy a Rust leválthatja a C-t, hiszen még számlálót is lehet rendszerprogramként megvalósítani, arra is alkalmas.
Másrészt erre továbbra is várom a választ: https://hup.hu/comment/3035799#comment-3035799 Ha megnézed még a dátuma is jóval előbbi mint a versenykiírásod. Tehát az óvodai vagdalkozás szabályai alapján előbb neked kell megfelelned a kihívásnak, addig meg sem szólalhatnál, ameddig erre nem adsz kimerítő választ.
Utána az következik, hogy bocsánatot kérsz a hangvételed miatt, ami egyrészt nincs megalapozva tudással, de még ha tudással megalapozott volna, akkor sem volna jogos egy fórumon vélemények miatt "anyázni". Ha megnézed eltérő véleményekre, de csupa normális hangvételű posztra reagálsz rendszeresen "anyázással". Nem kéne!
Utána pedig töredelmesen le kell írnod, hogy tévedtél mind a Rust rendszerprogramírása alkalmassága kapcsán, mind pedig a C memóriabiztonság ellenőrző technikáinak a működési elve és megbízhatósága kapcsán. Mi pedig többen is próbáltunk rávezetni téged a megfelelő szakszavak és pointerek biztosításával, amit figyelmen kívül hagytál. Nekünk mindannyiunknak igazunk volt, te viszont az arroganciád miatt nem tudtad befogadni az igazságot. A magam részéről ezt mind meg tudom bocsátani, ha írásban kéred.
Ha jól értem a kiírás valóban olyan volt, hogy a Rust unsafe konstrukciói nélkül nem megoldható, de utólag jóindulattal elfogadtad az unsafe pályaművet. (Nem néztem még meg, a többiek reakciói alapján mondom. Majd megnézem ha lesz időm.) Ez szép a részedről, de előre honnan tudhattuk volna? A kérdéseinkre adott válaszod alapján jogosan következtettünk arra, hogy nem fogod elfogadni. De jogos volt elfogadni és örülök is neki. Mivel az üzenetváltásainkban nem erre utaltál, ezért nincs miért bocsánatot kérnünk.
A linker szkriptre nem gondoltam, hanem a pointert akartam volna beírni közvetlenül a kódba. Ez az egy, amiben tévedtem. A tervezés első fázisaiban - azaz a lehetőségek felmérése közben - elkövetett tévedésért nem szokásom bocsánatot kérni.
És ezek után sem tartozok bocsánatkéréssel azért, amiért még pénteken is pénzér dolgoztam (tudom, lámerség pénteken dolgozni), és péntektől-hétfőig sem foglalkoztam a _te_ hobbiprojekteddel, hanem a családdal töltöttem a hétvégét. Mínusz az online trollkodás meg egy kis saját hobbiprojekt persze :-)
Kedves óvodás vagdalkozó!
https://hup.hu/comment/3035782#comment-3035782
Ez korábbi, mint a Tiéd, és mivel nem válaszoltál rá, így ha komolyan veszed magadat, nem is lett volna jogod feltenni a comment-3035799 kérdést, ugyebár. Ide is idemásolom: És a Go meg a Rust meg a többi csodanyelv hogy is veszi ezt észre? Mutass egy konkrét példát
Csakis azért szerepelt az unsafe tiltás, mert Ti állítottátok, hogy a Rust egy memóriabiztos nyelv! Aztán a legelső dolgotok az volt, hogy elkezdtétek habzó szájjal követelni, hogy ki lehessen kapcsolni a memóriabiztonságot Rustban...
És mégegyszer: az interfész teljesen safe, nem nyúl a memóriához, a load_idt-nek átadott buffert nemhogy nem írja, de még csak nem is olvassa, mindössze betölti a címét a CPU-ba.
A "csodanyelvek" nem észreveszik, hanem kizárják azt az esetet, hogy a-ra kap referenciát egy metódus és mégis b-t írják felül. És leírtam a választ, nem maradt megválaszolatlanul.
>az interfész teljesen safe
Nem vitattam, hogy el van-e baszva. Hanem azt állítottam, hogy a Rust technológiája szempontjából unsafe, mert nem ő bizonyítja, hanem a programozó vállal rá garanciát. Már párszor leírtuk ezt is.
Az óvodás vagdalkozást te kezdted ilyenekkel, hogy nem pofázhatunk vagy hasonlók - nem keresem ki szó szerint. Csakis azért reagálok a stílusodban, mert másképp erre képtelenség. Még az óvodás vagdalkozásnak is vannak szabályai, és az első megválaszolatlan kérdés még mindig neked van szegezve nem nekem. Egyelőre te vagy aki itt nem pofázhat. Majd ha megválaszoltad a fentebb linkelt kérdést.
:facepalm: és mégis hogy tervezik kizárni annélkül, hogy előbb észrevennék...?
Hát a Rust biztos nem. Csak pár ellenpélda:
https://github.com/rust-lang/rust/issues/106868
https://github.com/rust-lang/rust/issues/75577
https://github.com/rust-lang/rust/issues/72933
https://github.com/rust-lang/rust/issues/70078
https://github.com/rust-lang/rustfmt/issues/6107
...stb.
Ezekben az a közös, hogy a Rust fordító egyáltalán nem vette észre, hogy másik változóba ír a generált kód, és még csak trükkös referenciára sem volt szükség hozzá. Sima lokális változó korrupció. Pár issue-t workaroundoltak, de olyan is van bőven, ami a mai napig megoldatlan.
Tudod, itt az igazán nagy baj nem az, hogy memóriakorrupció előfordulhat bármilyen nyelven. A baj az, hogy míg ezzel a C programozók tökéletesen tisztában vannak és odafigyelnek rá, addig a Rust programozók bedőlnek a marketing bullshitnek, hogy memóriabiztos, és a hamis biztonságérzetük miatt egyáltalán nem figyelnek erre.
Nem esne nehezemre, ha lenne miért.
Köszönöm a beismerő vallomást!
Valóban a legnagyobb baj az, hogy fel sem fogod (vagy csak azt hazudod, hogy nem tudod), miért kéne bocsánatot kérned.
Akár így, akár úgy, jól látszik, milyen ember is vagy valójában.
Arról írtam, higy módszered nem bizonyítása semminek. A cicaharcba nem.mentem bele.
Tudod mi a különbség a példa, ellenpélda és a bizonyítás között?
Valóban nem mentél bele, hanem Te magad kezdted azt a bizonyos ún. "cicaharcot" ;-)
És még mindig nem tisztáztad, hogy mit is kifogásoltál pontosan, csak vagdalkoztál akkor is, meg most is.
Én megelégszem egy bocsánatkéréssel, nincs harag.
Ne haragudj, de a te betegséged nekem új, nem tudom, hogyan reagáljak rá. Értelmes szavak nem mennek át.
Rust 'megoldás' szerzője.
Rust proponens vagyok, de szerintem ez az ötlet hogy van valami csodanyelv teljesen null. A nyelveket problémák megoldására csinálták, C-ben nem fogsz web komponenseket írni, JS-ben nem fogsz interruptokat kezelni. Rust előnye szememben hogy igaz nem lehet 100% teljesen korrekt safe programot írni, de ha egy random memóriacímre kell írnod akkor igazolnod kell hogy igen, tudom mit csinálok, engedj írni ide, ha felrobban én basztam el valamit. DE programokat amiket írok a 3 nagy operációs rendszeren futnak, unsafe részét már megírták és sok szem van rajta hogy korrekt legyen, így amikor én használom mint api biztos lehetek benne illetve típus szinten nem is engedi hogy például invalid referenciát adjak egy függvénynek, ha a safe subset alatt maradok.
Ööö, jelen, én rendszeresen csinálom... (bár annyira sosem voltam elborult, mint pl. aki webfórumot írt Assembly-ben, én általában csak JSON REST API-kat szoktam C-ben implementálni, de végfelhasználói HTML-re is akadt már példa). A lényeg, hogy simán lehetséges, és bizony vannak, akik csinálják is.
Ez viszont valóban, még elméletben sem lehetséges, mivel interpretált szkriptnyelv.
A hozzászólásod többi részével tökéletesen egyetértek, és külön köszönöm, hogy kulturáltan érveltél. Igen, az hogy ellenőrzött lib-eket használ az ember valóban rengeteget számít, ez tény, de ez éppúgy igaz a többi nyelvre is. Lehet érdemes lenne egy alkalmazásfejlesztői versenyt kiírni majd, amibe már beleszámítana a lib ökoszisztéma is.
javascript mikrokontrollerre:
http://johnny-five.io/
Kifejezetten interruptra pelda:
https://gist.github.com/rwaldron/769068fbbc9b433768dd
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....
Elgondolkodtam, hogy lehetséges-e egyáltalán értelmes szabályokat kiírni alkalmazásfejlesztésre, amennyiben a libek is beleszámítanak.
Hát nem egyszerű. Ha a libek számát nézzük, akkor biztos, hogy a C magasan nyer, de elsősorban azért, mert már nagyon régóta használják, és minden más nyelvvel is garantáltan kompatíbilis.
A libek minőségét pont a libek hatalmas száma miatt nehéz meghatározni, mert tuti kimarad pár. Ugyancsak ennek köszönhető, hogy nincs egységes lista róluk (bár volt próbálkozás, pl. CPAN), és hogy natívan kell telepíteni őket (pl. debian és ubuntu alatt csak hozzácsapod a csomagnév végéhez, hogy "-dev", és a többit az apt megoldja neked). Ez jó, mert nincs szükség külön hekkelésre meg infrastruktúrára, gond nélkül simul a rendszerbe, rengeteg a mirror; ugyanakkor rossz is, mert minden disztrónak saját lib listája van emiatt. (Például ugyanaz a Perl xml parser lib elérhető sima csomagban is a disztrómon, ami feltesz manpage-t meg mindenféle doksit, meg CPAN alól is, ami viszont nem telepít manpage-t. Melyiket vegyük figyelembe? Python-os libek esetén ugyanezek a kérdések merülnek fel.)
Ha a dokumentáltságot akarjuk nézni, akkor megint hasonló a szitu: nem minden libnek könnyű megtalálni a doksiját, és soknak nincs, vagy rossz. Ugyanakkor az is tagadhatatlan, hogy a valaha létezett legjobb lib doksik mind C libekhez tartoznak.
Itt külön kiemelném a Microsoft-ot, ami általában csapnivaló doksikat készít, de az MSDN-je annyira szenzációs, hogy azt komolyan tanítani kéne, hogy tessék, így kell lib doksit csinálni. Minden paraméter külön-külön részletesen el van magyarázva, bőven megtolva infókkal meg linkekkel, és ha valami nem is lenne világos, egyértelmű, merre kell tovább keresgélni. A különösen neccesebb hívásoknál, meg a kezdők által gyakran felmerülő kérdésekre meg mindenhol konkrét C nyelvú példaprogramokat tartalmaz a dokumentáció, még akkor is, ha triviális (például ilyeneknél).
A másik tökéletes példa az ugyancsak kiváló minőségű SDL dokumentáció. Na, így néz ki egy jó lib doksi. Részletes paraméter leírás, linkek, példaprogramok dögivel. (Sajnos épp webmotort váltanak, így előfordulnak benne kissebb formázási bökkenők, de ezeknek semmi köze a doksi minőségéhez, ez technikai probléma).
C# esetén nem rendelkezem kellő tapasztalattal, de ismerősök szerint a .NET dokumentáció ugyanilyen jó minőségű, már ami a Microsoft által biztosított libeket illeti, de a többi 3rd party libé már csapnivaló. De ezt csak mások véleményére alapozva írom, semmiképp sem mérvadó, nincs személyes tapasztalatom.
Java esetében hasonló a helyzet, de ott még tovább bonyolódik a dolog a rengeteg szerteágazó middleware miatt. Ott sem hiszem, hogy könnyű lenne értékelni a libeket megbízhatóság vagy épp dokumentáltság szerint, mivel nagyon nagyon sok van, ráadásul sokminden middleware specifikus, így kérdéses, mit is vegyünk szó szerinti Java libnek.
...stb.
Szóval ha valaki ki akar írni egy alkalmazásversenyt, akkor hajrá, támogatom! Én biztos nem fogok, mert nem érzem azt, hogy igazságos szabályrendszert tudnék felállítani hozzá.
A doksi 99%-a peldaerteku, de tipikusan van egy-ket kevesbe frekventalt resze, ahol csak ki van hanyva a netre, hogy milyen tagja vannak egy-egy osztalynak, aztan szevasz. Koszi, ki vagyok segitve, az IDE ugysem mutatja meg. (De.)
Tipikusan ilyen peldaul, amikor WMI-n keresztul kellett nemreg kinyernem Hyper-V guestek bizonyos adatait, mar-mar a kuruzslas kategoriaban. Abban sem vagyok teljesen biztos, hogy amit talaltam hozza, az valodi feature, vagy csak egy bug, amit egyszer majd patch-elnek, es akkor mehet a kodom a kukaba. A masik ilyen WTF moment nemreg a secpol lekerdezese volt. Annak konkretan az lett a vege, hogy az alkalmazasunk lefuttat egy secpol.exe-t a hatterban, es osszeszedi annak a fajlba mentett kimenetet. Ha nem sikerul, akkor szopo van, error, try again later.
Osszessegeben azert inkabb szeretettel gondolok ra, mint nem.
Igen, pontosan ezt mondták akiket megkérdeztem. Sajnos ez a forráskommentekből generálunk használhatatlan doksit, nyelvtől függetlenül is jellemző :-(
TLDR: van már valami?
https://iotguru.cloud
Személyeskedés, meg 1 darab működő pályamű
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
Ha a referencia implementációt nem számoljuk bele, akkor összesen 4 megoldás van eddig.
Érkezett egy Rust és egy Pascal megoldás (ezeket már fel is tettem a repóba), én meg viccből csináltam egy olyan C változatot, ami egyáltalán nem használ pointert, mivel egyesek reklamálták, hogy ne lehessen pointer C-ben.
Mind multiplatform, kikéve a Rust-ost, de az is csak mindössze egyetlen egy kulcsszó miatt (feature(abi_x86_interrupt)) nem fordul. A kód összes többi része architektúrafüggetlen, ezért szerintem az is elfogadható multiplatformnak.
Lehet már maga a kiírás is olybá tűnt, hogy bzt magas lóról beszél. Érthető. Az én meglátásom szerint neki van mire. Valóban tudja mit csinál. Viszont arra a gőgre, amit pl. a Rust hívők képviselnek, szerintem teljesen valid reakció volt a kiírás. Egyszerűen bicskanyitogató a nyomulás amit művelnek. Próbálják minden eszközzel legitimálni az új csillámfaszlámás programozási nyelvüket úgy, hogy közben keresztes hadjáratot indítanak a régi, már jól bevált, bizonyított nyelvek ellen. Közben a "nagy" tech cégek, és még a fehér ház is bekajálja az evangéliumot. Gondolom ezért lehetséges mert már ezeken a helyeken is ugyanezek a bokavillantós, babzsákfotelben nevelkedett, szójalattét szürcsölő soydev-ek mondják az áment. Igen, a Rust-ra van kihegyezve, mert rájuk a legjellemzőbb. Aztán ha valaki kicsit a mélyére néz a dolognak, tulajdonképpen semmivel sem különb az egész, mint amit már régen kitaláltak. Csak az egész nyakon van borítva egy rózsaszín cukormázzal.
Egy valóban jó programozó bármilyen nyelven tud jó programot írni. Egy szar programozónak meg adhatsz bármilyen szuper biztonságos nyelvet, akkor is tökön lövi magát. Ettől a Rust sem fogja megvédeni.
És pont az ilyen bootcamp-ben nevelt kódhuszároknak köszönhetjük, hogy lassan egy szájbatekert paint programhoz is 128 magos processzor kell, Terabájt RAM, meg a világ összes háttértára nem elég. Hogyan írnak ma is egy floppy lemezen elférő, teljes értékű operációs rendszert grafikus felülettel és még pár játék is belefér?
Hogyan írnak ma is egy floppy lemezen elférő, teljes értékű operációs rendszert grafikus felülettel és még pár játék is belefér?
Rustban, mert a C halott, megmondtak :D
En barmikor szivesen beszallok a bootcampek ekezesebe, de azert ne essunk at a lo tuloldalara, nincs igeny arra, hogy tomegevel keszuljenek az egy floppy-n elfero teljes erteku OS-ek, jatekokkal. Ne az legyen mar a szakmad merceje, hogy mennyi haszontalan dolgot tud eloallitani. Ha ilyen kihivast keresel, akkor demoscene versenyekre, vagy C obfuszkalo kihivasokra kell nevezni.
Ma ott tart ez az iparag, hogy a digitalis analfabeta nagymama minden problema nelkul lathatja a masik orszagban elo unokajat, meg bele tudunk nezni az emberek testebe kivulrol, sot, mar lassan muteteket levezenyelnek az orvosok egy masik foldreszrol, de ez lofasz, mert a sok rohadt bootcampes ingyenelo nem ir eleg floppy-s OS-t. :)
Szerintem nem estünk át a ló túloldalára. Azok estek, akik a mai operációs rendszereket és programokat írják. Ez egy sarkos példa volt, amire nagyon ráfókuszáltál. Nem azt akartam vele érzékeltetni, hogy legyen sok egyfloppy-s rendszer. De állítsuk már meg ezt az végtelen pazarlást! És erre jó példa a mai operációs rendszerek és programok. Én az ellentétre akarom felhívni a figyelmet, mindegyik működő operációs rendszer, grafikus felülettel! Az egyik elfér egy floppy-n, a másiknak lassan több tíz GB nem elég. Nem beszélve arról, hogy tulajdonképpen nem tudod használni a számítógépedet, mert az operációs rendszer zabálja fel az összes erőforrást. Holott nem az lenne a feladata (szinte láthatatlanul), hogy kezelje és elérhetővé tegye az erőforrásokat?
De a ketto ugyanarra jo? Mert ha nem, akkor ez az osszehasonlitas igy fals.
Ugyanarra. Persze. Mire való egy operációs rendszer?
Tehat a floppy-n is elfero operacios rendszerrel tudok olyat csinalni, hogy az uj kolleganak kozvetlenul a nagykerbol kuldom ki a ceges laptopot, amit kivesz a dobozbol, beirja a ceges accountjanak adatait, es az OS feltelepit mindent, amire a munkajahoz szukseg lesz?
Vagy mondok egyszerubbet, a floppy-s OS plug&play mukodik ~minden forgalomban levo hardverrel?
Mutatsz kerlek ilyenre peldat?
A gyakorlatban arra, hogy tudjak a szamitogepemmel penzt keresni es/vagy szorakozni. Tudom, hogy letezik egy szakmaibb, de teljesen irrelevns definicio is.
Nem tudom miért akadt be a floppy, úgy látom ennél tovább nem látsz. Egy példa volt arra, hogy létezik akkora méretű operációs rendszer is, grafikus felülettel, amivel működik a számítógép. Nyilván annyira én sem vagyok zokni, hogy azt gondoljam, majd a legújabb grafikus motoron futó Doom menni fog rajta.
Az OS minek telepítene fel bármit is?
Azt a ~minden forgalomban lévő hardvert hanyagoljuk. Még Linux alatt igaz is lehet, de Windows-t hagyjuk, és még a driver-ek sem indokolják a gigás telepítéseket.
Nem a floppy a lenyeg. Te mondasz olyanokat, hogy az 1-2 megas OS, meg a 10-20 gigas (melyiknek kell 20 giga az OS-nek? mindegy is)
"ugyanazt tudja""ugyanarra jo". Felolem lehet floppy helyett network boot is, tokmindegy.Mi az operációs rendszer feladata? Ennek tükrében vizsgáljátok meg azt, hogy ugyanarra jó! Sehol nem állítottam, hogy egyenértékűek! Nem is lehetnek.
Te mondasz olyanokat, hogy az 1-2 megas OS, meg a 10-20 gigas (melyiknek kell 20 giga az OS-nek? mindegy is) "ugyanazt tudja" "ugyanarra jo". Felolem lehet floppy helyett network boot is, tokmindegy.
Ugyanazt tudja (a saját kontextusában = OS). A nagyobbik nem ugyanazt tudja (általánosságban), mint a másik, mert van még "bónuszként" odabaszva melléje úgy kb. 85-90%-nyi minden más junk, amire amúgy a kontextusban (= OS) semmi szükség nincs, és az igen nagy részére a felhasználók döntő többségének igazából semmiféle igénye nincs. Viszont kvázi rájuk van erőszakolva (ne sánta, itt egy púp! jeligére), mert nem opcionális, nincs triviális módja annak, hogy a felhasználó ne kérje - nyilván elvileg le lehet vakarni ezeket, de az egyrészt erősen feketeöves próbálkozás, meg aztán vagy eltörik valahol egy NULL-pointer miatt valami, vagy nem (való életbeli példa: ha elkezded egy Win10-ből kidobálni a csomagokat, el fog jönni az a pont, amikor valamelyik fül a Gépházon megnyitáskor crashel. Mert a nagytudású redmondi programozók a büdös életben nem tesztelték a szoftvert minimál környezetben).
Már kezdtem azt hinni, hogy kínaiul beszélek. Ezek szerint van aki megérti, miről szólt.
Megerteni sokan megertettek, legfeljebb nem ertettek vele egyet.
Te olyan definiciokon rugozol, ami a gyakorlatban semmit nem jelent. Tegnap telepitettem egy RHEL-t, valami 780 csomag volt az alaptelepites. Most akkor ebbol mennyi az operacios rendszer, es mennyi a userland? Vegulis mondhatod, hogy nem kell networking az OS-be, meg nem kell text editor, csak akkor hasznalhatatlan lenne a gep, amikor eloszor bekapcsolod.
Azt probalom a fejetekbe vesni, hogy igen, lehet 1-2 megas, vagy akar meg kisebb OS-t gyartani, van is olyan (nagyon-nagyon szuk) terulet, ahol ertelme is van, de ez nem valamifele kovetendo benchmark. Attol meg, hogy mondjuk egy desktop Linux elfoglal ugy 2 GB tarhelyet, attol nem lesz szuksegszeruen "rossz". Ez bullshit. Tovabb nem is akarom ragozni.
Nem, nem az OS zabalja fel a gepek eroforrasait, hanem a rajta futo programok. Es jo is ez igy, mert azert vannak az eroforrasok. Majd a cpu scheduler meg a virtual memory manager szepen lekezeli ezeket.
Masreszrol tenyleg megneznem azt az 1.4 MB-os operacios rendszert aminek van grafikus felulete, tudja a bloetooth-ot, wifi-t, kezeli a 3D kartyat es szepen futtatja az UE5-os jatekokat, dolby hanggal.
Most megneztem az en kernelem a Linuxomon 78MB-ot eszik. Kurvara nem ferne ra egy floppy-ra. De kulonosebben nem zavar, hogy a programok amiket hasznalok hasznaljak a cpu-t es memoriat, mert igy tudok zenet hallgatni, mikozben futnak a k8s-es tesztjeim local-ban es meg ide irogatok is. Persze ha nem dolgoznek, nem hallgatnek zenet a bt fulesemen az internetrol es nem irogatnek ide, akkor lehet eleg lenne ket floppy-nyi is a kernelnek. Igaz akkor hasznalni sem tudnam a gepemet, de micsoda mini rendszerem lenne :D
(mivelhogy grafikus feluletu OS-ekrol beszeltel es nem egy ioT szenzor lapkarol)
Jah, a Linux is egy szar, mert nem fer mar ra egy floppy-ra :D
Bluetooth, wifi meg a dolby hang nem indokolja a több tíz gigás rendszert. Szerintem a 3D kártya sem. Az UE5 hogy is jön az operációs rendszerhez újfent?
Pontosan, az nem baj, ha a programok használják a cpu-t és a memóriát, de ne az oprendszer, a háttérben futó több száz folyamattal, amit senki nem kért, hogy fusson.
Szerintem arra gondolt, hogy OS-t nem l'art pour l'art futtatunk, hanem akarunk a gepen dolgozni/jatszani.
driver1:
driver2:
Size: 681.2 MB
driver3:
File Size
641 MB
Es ez csak 3 random driver, amit igy beirtam a google-be hirtelen. Nem az a baj, hogy egy OS 20-30GB, hanem ha nem kezeli rendesen a hardvert amin futtatnad.
De oke, a 640 megas driver package tenyleg bullshit, en meg ezt sem vitatom, csak ne csinaljunk mar ugy, mintha igazabol a mai OS-ek ugyanazt a feature set-et tudnak, mint regen, csak a babzsakfejlesztok alkalmatlankodasa miatt lett tizezerszer akkora a meretuk.
nem is az a kerdes mennyire bullshit vagy sem (amugy nem, mert rengeteg alkalmazasfuggo kod van ezekben, ami pont azok mukodeset biztositja es/vagy performacia miatt kell bele), hanem, hogy ezek a valo eletben hasznalt modern megoldasok. pont le*om, hogy egy szoftver pl. 3kilobyte vagy 300MB, mert a hattertartol a memoriaig a 300 MB is <0.1s alatt jut el egy modern rendszeren. mikozben az atlag human autovezeto reakcioideje ~0.5-1 sec...
nincs alternativad ezekre, ergo "this is the most simple solution."
Mik azok az ezek? Operációs rendszerről beszéltem. És vannak alternatívák. Próbáljátok már meg tényleg ebben a kontextusban értelmezni.
driver nelkul szart se er az OS-ed. ugyanezek integralva is benne vannak jobb esetben az os-ben vagy az elso update lehuzza oket (vajonmitol20-30giga111!!!!)
Persze, és ebből jó eséllyel 634MB a szemét (installer, tray app, csoda updaterek, mindenféle nem kellő utilityk), és 0.47MB (az inf, a cat meg max 1-2 sys fájl) a lényegi driver. Ezért nem telepítünk installerrel soha drivert.
"Sose a gép a hülye."
hat, rohadtul nem :) ahogy irtam is fentebb sw-hw-kompatibilitasi meg API verziok tomkelege miatt ekkora, plusz jar hozza a szoftver, amivel a kedves paraszt kezelgeti a hardveret meg kihasznalhatja a kepessegeit.
mukodik anelkul, csak akkor egyreszt mi lesz azokkal a pistikekkel, akik arra elveznek, hogy mennyi mindent be lehet allitani! :D vagy epp azokkal, akiknek tenyleg be is kellene valamit.
Valami nagyon speciális cuccról beszélhetsz, mert nem emlékszek, hogy találkoztam valaha is olyan hardverrel, amihez ha volt adott OS-en belül driver és működött rendesen, akkor ne lehetett volna az OS valamelyik saját tooljával, vezérlőpultban, vagy mittomén akárhol beállítani valamit, legyen az akár hangkártya, nyomtató, bluetooth, wifi vagy akármi.
"Sose a gép a hülye."
hat, pedig video output minden dekstop gepben szokik lenni. tenyleg iszonyatosan specko cucc, eleg bonyi es altalaban tobb benne a tranzisztor, mint a CPU-ban, pl. nalam ez az arany 5:1.
É minden egyes tranzisztorhoz külön kell driver? :-D
te se lattal meg modern VGA-t vagy ismered legalabb erintolegesen a funkcioit? ertem en, hogy a 80x25 text mode-hoz nem kell driver meg szoftver... de ahhoz nem kell 10-20+kkk tranzisztor sem.
osszekeveritek az out-of-the-box "valahogy" mukodiket meg leszarjatok, hogy a kedves user ki tudja-e a hasznalni a termek adta funckiokat szoftver nelkul.
A baj nem is az, hogy nem képesek tömegével ilyeneket gyártani, hanem az, hogy ha akarnának se tudnának még mutatóba se.
És abban sem lennék olyan biztos, hogy ne volna igény. Persze nem floppy és nem OS, de szerintem nagyon is lenne igény a kicsi, gyors, jól átlátható programokra a mai világban, amikor még a fájlböngészőt is teleszarják telemetriával és kémprogramokkal.
Biztonsági szempontból nagyon nem mindegy: elrejteni valami kártékony kódot egy 100 Megás programban gyerekjáték. Ugynazt elrejteni 100 Kilobájtos kódban művészet, már ha lethetséges egyáltalán. (Emlékezz csak, régen, amikor 64K volt a BIOS ROM maximális mérete, még vírus sem volt rá, bezzeg ma, amikor több megás a firmware, még egy párhuzamosan futó, lehallgatásra kifejlesztett operációs rendszert is elrejtettek benne (!).)
Arról nem is beszélve, hogy a mai sérülékenységek több, mint 99%-a nem is abból ered, hogy ne írnák meg jól a programot, hanem abból, hogy nem is akarják jól megírni, nem is képesek jól megírni, mert minek, csak berántanak dependency-nek valamit, máshoz nem is értenek. Tipikus példa erre bármelyik electron "alkalmazás" (de a fentebb emlegett IME-t sem csak a CIA és az FBI tudja használni, hanem bármilyen rosszakaród is hozzáférhet, mert azt is hozzá nem értő vérpistikék követték el). Aztán persze később rendszerint kiderül, hogy a berántott dependency már eleve lukas volt, mint a szita. Erről több tanulmány is született már, és azt is megmérték, hogy a kifejezetten a dependency-ket célzó támadások száma 2017 és 2019 között majdnem a duplájára, 88%-kal emelkedett. A helyzet annyira súlyos, hogy már a nem épp IT centrikus újságok, mint pl. a Forbes is többször foglalkozott a témával.
Felhasználói élmény szempontjából sem mindegy, hogy 1 perc bebootolni a gépet vagy csak 25 ezredmásodperc, vagy hogy egy alkalmazás azonnal indul, vagy perceket kell várni rá. Ez direkt kihat a munkáltatók zsebére is, egyszer érdemes lenne összeszámolni, hogy egy átlagos irodában egy átlagos napon mennyi fizetett idő megy el arra, hogy az alkalmazottak várnak a számítógépre. Gyanítom a GDP nem elhanyagolható részét teszi ki a valóságban. (Arról nem is beszélve, hogy egy programozót rendesen kiképezni drága ugyan, de egyszeri költség, míg a veszteség kevésnek tűnik, de folyamatos és általános.)
Szóval nekem az a véleményem, hogy az igény továbbra is fennáll, csak most már nem a hardver limitációk indukálják, mint régen, hanem manapság az átlátható, biztonságos és hatékony megoldás miatt lenne nagy szükség rá.
Plusz még egy teljes értékű webböngésző, JavaScript motorostul. Azt se felejtsük el, hogy pl a Hanoi tornya játék JavaScriptben volt írva azon a bizonyos floppyn.
A HUP "szakmai közösség" szakmai témában szakmait táncol ^ 🍿
trey @ gépház
Jaja, mióta kevesebb a flame, itt kell dagonyázni
Aláírás _Franko_ miatt törölve.
RIP Jákub.
neut @
https://gitlab.com/bztsrc/langcontest/-/tree/main/trey
"trey" did not exist on "main"
Veletlenul elfelejtetted push-olni a palyamunkad, gondolom. Meg jo, hogy eszrevettuk! :)
Én csak egy autószerelő vagyok! Csak a 🍿-ért jöttem! Meg az elitet figyelni, aki szerint az a baj a HUP-pal, hogy nincs szakmai kontent és csak a flame megy! ^
https://gitlab.com/bztsrc/langcontest/-/tree/main/gelei
trey @ gépház
Valami network issue lehet, nalam visszajon 302-vel, ahogy kell.
El404-elt a powershell manual, amit par eve bookmarkolt, a tobbi nyelvet meg nem ismeri annyira. :)
A te megoldásod se látom ott. Se Oregon-ét.
trey @ gépház
Az enyemre azert nincs szukseg, mert en a "C a kiraly" tabort erositem, nem tudok nyelvet, amiben ez jobb lenne.
Ergo ez a kihivas nem nekem szol. :)
Ellenben aki a HWSW-nel arrol hazudozik, hogy megszunik a C, es felfefordit ennek a narrativanak megfeleloen forrasokat, annak se latom ott a kodjat.
Megírhattad volna C-ben. Szebben!
Mi közöm nekem ehhez? Írtál már neki?
trey @ gépház
XMI nezett utana olyan melysegben, hogy legyen eleg alapja helyreigazitast kerni:
https://hup.hu/comment/3033599#comment-3033599
https://hup.hu/comment/3033483#comment-3033483
(Bevallom, hirtelen ugy emlekeztem "trey" a cikk szerzoje, nem "hup" - hibasan)
Semmi közöm a cikkhez, sem a reklám/beajánlott tartalmakhoz.
trey @ gépház
egyreszt sehol nem lett leirva, h "megszunik" a c, ahogy te mondod, arrol van szo, h egyre nagyobb a nyomas, h helyettuk memoriabiztos nyelvet hasznaljanak. masreszt amikor akar cegek, akar kormanyzati szervek memoria biztonsagos nyelvekrol beszelnek, akkor hol nevesitik a c/c++ mint problemaforrast, hol nem. de ugye amikor memoria biztosnagos nyelvekrol beszelnek, ki tudod talalni mely nyelvek nem azok?
Nagyjabol onnan indultunk, hogy Egyesült Államok Nemzetbiztonsági Ügynöksége (NSA) kiadta anno ezt, ez alapja minden hivatkozasnak, es a 2023 kivervedelmi strategianak is. Azt hiszem ennel jobban nem lehet nevesiteni az emlitett nyelveket.
CSI_SOFTWARE_MEMORY_SAFETY.PDF (defense.gov)
NSA advises organizations to consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++ and assembly, to a memory safe language when possible.
Freud forog a sírjában! :DD
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Hát, eléggé úgy tűnik, hogy szerinted azért jó a c, mert kiverheted vele a művészi szabadságra, szerintem elég jól betalált :-D
Nem én írtam, ugye. ;) Amúgy meg valóban az a bajom, hogy az újabb nyelvekkel elvész az alkotói szabadság, az ötletelés lehetősége. Ha ez így megy tovább, olyan mélységekbe jut a programozói szakma, mint az orvosi: protokollok vannak, mit hogyan kell kezelni, így aztán megölik a kreativitást, a beteget meg az Isten óvja attól, hogy ritka betegsége legyen, mert kötelezően félre fogják kezelni. :(
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Dehogynem, te jöttél a művészi szabadsággal :)
Egyébként meg a nehézség veszik el, mint ez a konkrét valami mutatja, pl a rustban is nyugodtan lehet alkotni, ha kell, csak amikor megszeged a józan ésszel az esetek nagy többségében betartandó normát, akkor le kell írni, hogy ezt teszed.
Rengeteget elmond, ha szerinted egy szakmának az mélysége, hogy keretek, protokollok és best practicek vannak.
Egyrészt amíg nem voltak protokollok addig is félrekezelték ezeket, ha tippelnem kellene, akkor meg merném kockáztatni, hogy a protokollok növelik az esélyét, hogy egyáltalán feltűnjön, hogy itt valami nem stimmel. Abban viszont egészen biztos vagyok, hogy a nem ritka betegségben szenvedők (akik ugye a definíció szerint többen vannak) sokkal kiszámíthatóbban jutnak normális kezeléshez, mint ha ezek nem lennének.
Dehogy ölik meg, magas szintű nyelveken, magas szintű problémákkal pontosan ugyanolyan kreatívan lehet foglalkozni, mint alacsony szinten alacsony szintű problémákkal. Csak szerinted -- mivel te azt szereted -- ezért az utóbbi érdekes kreatívkodás, az előbbi meg nem. Én pl azért nem szeretek odalent matatni, mert azt érzem, hogy az idő nagy része olyan problémák megoldásával megy el, amik irrelevánsak ahhoz képest, amit valójában meg akarok oldani.
---
Egyébként pedig: ez egy szakma, ha művészkedni akarsz, annak is van helye, kell menni demo scenre, lehet hobbizni meg minden. Kurva jó móka, de amikor épp szakma, akkor szakmázz. A doki se varjja matyóhímzéssel összes a sebet, mert egyébként az neki tetszik.
Nem ertem. Milyen kreativitasra vagysz mikor egy feladatra megoldast kell talalni az adott nyelvben, barmelyikben? Vagy azt mondjuk egyikben sincs vavyazt, hogy mindegyikben. C-ben, Python-ban, Go-ban, Scalaba-n is lehet szep es kreativ kodot irni. Bar en egy programnylevtol inkabb azt varom el, hogy az adott teruleten hatekony legyen.
Az orvos se legyen kreativ, ne legyen piocazas, meg koponyalekeles, meg ne fessen novenyi anyagokkal a koldokom kore szines abrakat mikozben torokhangon enekel. Hanem fogja azt amit tanult meg amit tapasztalt es a tudasaval felvertezve a leheto leghatekonyabban vizsgaljon meg es diagnosztizaljon, majd talalja meg a gyogymodot. A vizvezetekszerelo se epitsen hullamvasutat a csovekbol, mert milyen kreativ, hanem vezesse el egyenesen a vizet oda ahova kell. Detto a villanyszerelo.
En sem habositom barokkos megoldasokkal amit az ugyfel ker. Amit en leteszek az esztalra az egy hatekony es gyors megoldas a problemajara. Ha azt akarja, hogy szines halacskak ugraljanak kozben elo valahonnan, akkor hivjon valaki mast.
Egy problémát lényegében bárhogyan meg lehet oldani. Korlátlanok a megoldási lehetőségeid, csak a fantázia hiánya szab határt.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
a feladat hogy adj ossze ket szamot. Ezt milyen fineszesen lehet megoldani tobb fele modon? Es az nem creativitas ha irsz ra egy fuggvenyt, az ugyanugy ket szamot ad ossze.
Mennyi 2+2? De ne jöjjetek nekem a bolsevik-náci propagandával, hogy 4! Rendes választ kérek!
- 3.99999999
- de ez hibás...
- de en voltam a gyorsabb!
Ha még emlékszik valaki. :-)
AMD likes this.
2+2 = 5.08, de az áfa visszaigényelhető ha a tanár úr úgy óhajtja. :-)
A kérdésnél figyelembe kell venni a 2 kiindulási állapotát, azaz: 1 + 1
Jól látható a megoldás felé vezető út első lépése: az 1 az alapja ennek a problémának.
Az 1 pedig, mint köztudott 3 x (1/3), amelyet ha megvizsgálunk, rájövünk, hogy az 1/3 a kiindulási pont.
Vagyis 0,333333 + 0,333333 + 0,333333 = 0,9999999
Tehát 0,9999999 + 0,9999999 = 1,9999998
1,9999998 + 1,9999998 = 3,9999996
(Meg kell jegyeznünk, hogy a számítások közelítő értékűek.)
:)
Ha a specifikáció nem ilyen egyszerű, azonnal kinyílik a világ előtted. Mondjuk egy kommunikációs protokollt kell megvalósítani, meg egy másikat, meg méréseket, meg egy mérőrendszer vezérlését, az egész cucc csillió féle konfigurációját. Itt máris rajtad múlik, hogy blokkolósan, vagy kvázi multitaszkosan írod-e az egészet, a kommunikáció bufferelt lesz, vagy bevárod a választ rá, multitask megoldásnál hogyan oldod meg az interprocess kommunikációt, mert lehet minden egyes esetre egyedi globális változókon keresztül átadni paramétert, de lehet sokkal szebben, belső üzenetküldő infrastruktúrát kialakítani, az is a saját döntésed, az hogyan legyen megvalósítva, paraméterezve, a függvényeidet hogyan kelljen hívni, használni.
Az is a te döntésed, hogy pollingolva, IT-ből vagy DMA-val hozd el a kommunikációs modultól az adatokat, vagy add át neki. Tényleg csak a hardware és a fantázia korlátai léteznek.
Értem én, hogy 2+2 esetén nincs túl nagy mozgástér, de a gyakorlati problémák ennél picit szerteágazóbbak, és ezt te éppen úgy tudod. ;)
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A valaszodban gyakran elofordulo fordulat "a rajtad mulik", ami akkor igaz ha hobbi projekten dolgozol sajat magadnak. Masreszrol a apeldad nagyon jol szemlelteti, hogy milyen tipusu problemakban csagy jaratos es azokban gondokodsz.
A legtobb esetben visoznt a valo eletben ennel sokkal de sokkal jobban meg van kotve a kezed. Egyszeruen nem lehetsz kreativ.
De ertettem amit irtal es a felvazolt esetben igazad is van.
Egyébként mi van azokban a példákban, amit egy kb bármelyik nyelv korlátozna?
Ezek szerint jó helyen dolgozom. :) Ilyen szempontból mindenképpen, pénzben már közel sem.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Tőlem mit szeretnél látni? Nekem továbbra is a problémám ugyanaz. Ez nem bizonyítás. Tudom, hogy te sem érted, de neked van felmentésed ez alól.
Nem ismeretlen az alacsonyszintű programozás számomra, de nem szeretem. Rustot nem is ismerem, csak egy alap tutorialt csináltam meg benne. Ennyi.
Valamit félreértettél. Én semmit sem akarok tőled látni. Szerintem aki itt látni akart valamit, az a téma nyitója. Én csak azért jöttem, hogy lássam, ahogy akasztják a hóhér(oka)t.
trey @ gépház
Ize ... nincs idom ilyenekre, te nyertel :D
Ne etesd a trollokat!
Amugy minek fektetsz ennyi energiat ebbe?
Hogy ne csak a levegőbe beszéljek, és tényleg korrekt összehasonlítás legyen, megcsináltam C nyelven és Rust-ban is. A Merge Request-et már ott a repo-ban.
Hogy izgalmas legyen, a C/C++ megoldás Visual Studio-val készült, PE formáutmú .exe az output-ja.
A háttérről: assembly-ben kb. 25 éve, még gyerekként programoztam értelmezhető mennyiséget, akkor kb. néhány száz óra nagyságrendű volt az idő, amit ebbe beletoltam. Meg volt egy könyvem, ami a 32 bites védett módú oprendszerekről szólt, ez hasznos volt annak kapcsán, hogy mi az az Interrupt Descriptor Table (ami egyébként koncepciójában nem sokat változott 64 bitre átállásnál). Ez most nagyon jól jött, hogy értsem miről is van szó, mit csinál az assembly nyelvű példa megoldás.
C nyelvvel már többet foglalkoztam, de igazán olyan sokat nem használtam, főleg az utóbbi 10 évben.
Rust-ot még soha nem használtam. Igazából erős kezdés volt így, hogy egyből egy rendszerprogramozási feladat :) Ez látszik is, hogy a nyelvet nem ismertem, sokkal inkább C jellegű a megoldás, kevésbé jól használja a Rust-os feature-öket. Ez jól látszik a már korábban elkészült Rust-os megoldáshoz hasonlítva. A legtöbb idő itt egyébként arra ment el, hogyan lehet bare metal bináris output-ot gyártani, hogyan lehet az outputhoz base address-t beállítani stb.
Amit mindkét megoldásban megcsináltam, hogy ne busy loop legyen a belépési pont végén a ciklus, hanem a HLT utasítást hajtja végre.
Összesen kb. tíz órát toltam bele. Napi szinten egyébként magasabb szintű nyelvekkel foglalkozok, C#, Java, JavaScript, Kubernetes, Cloud, DevOps témák.
Megjegyzés a peremfeltételekhez: az iretq hívást így kezelni, hogy a saját interrupt handlerből kell meghívni függvényként azt, ami majd valahogy kiléptet az egész interrupt handler-ből, ez szerintem szívás. Csak fragile megoldásokat találtam rá, de ahogy látom, mások is. A probléma gyökere, hogy egy magas szintű nyelvben, lényegében bármi ami nem assembly, nem igazán tudod megtippelni, hogy mekkora lesz a stack frame, amit el kell pusztítani, hogy az IRETQ gépi kódú utasítás a megfelelő stack pointernél fusson le. Itt kb. jósolni kell, hogy mi az a szám, amivel nem fagy le az egész gép. És ez lehet, hogy egy másik compiler verziónál már más lesz. Hogy itt tegyek javaslatot is, ezt szépen úgy lehet szoftver architektúra szempontból megcsinálni, hogy az interrupt handler egy rövid stub assembly-ben, akár a bootloader részeként, ami CALL utasítással meghívja a tényleges függvényt, ami a megoldás része, és a visszatérés után ez a stub lép ki IRETQ-val. Persze ekkor az eredeti megoldandó feladatnak egy jó része már kiesik, hiszen az IDT-t nem a megoldásban kell kitölteni, hanem a bootloader tölti ki, és a bootloader hív tovább a stub-ból a már normál módon megírt interrupt kezelő függvénybe.
A válaszomhoz előrebocsátom, hogy én csináltam a Pascal verziót. A leírt jelenséghez nem kell másik compiler verzió, és én is belefutottam. Sokszor elég ha csak az optimalizációs beállítások változnak. Ez ugye befolyásol(hat)ja hogy hány változót tart a fordító a veremben és mennyit regiszterekben, amivel együtt az iretq() függvénynek átadandó szám is változik.
Erre - legalábbis Free Pascalban - több megoldás is van. Az első, hogy van két beépített compiler intrinsic, amivel ki lehet számolni a base pointer és az aktuális stack pointer közötti különbséget, amivel megkapod a localsize-t, és azt átadni az iretq függvénynek. Ami rendben volna, de szintén optimalizácíós célból a fordító szereti elhagyni a base pointert, és azt nem volt türelmem kipróbálni, hogy olyankor mi van, ezért csak beírtam én is egy számot, és kész.
A másik, hogy a Free Pascal alapvetően tud "interrupt" típusú függvényt fordítani, vagyis IRET-et generálni RET helyett a függvény végén. Emiatt nekem egy "interrupt acknowledge" függvény jobb lett volna. Az elegánsabb design is, mert akkor az interrupt acknowledge lehet platformfüggetlen (pl. másféle IRQ acknowledge, nem csak a legacy PIT van ám!), a fordító meg megoldja a többit. A másik amit te is leírsz, hogy ez így egy félmegoldás, ami nem elegánsan interfészelhető, mert félig nálad van az irányítás, félig meg a betöltőnél. És őszintén az sokkal jobb teszt lett volna ha már rendszerprogramozás, hogy a fordító tud-e önállóan interrupt stílusú függvényt generálni.
És ugyanitt disclaimer: Az x86_64 portja a Free Pascalnak nem tud (még) interrupt stílusú függvényt generálni. Igazából az egész embedded target félkész x86_64-en. Az infrastruktúra jelen van hozzá, i8086-on, i386-on megy, az x86_64 portból hiányzik a releváns kód, ami az interrupt stackframe-mel megküzdenie. Szóval nekem ebből a szempontból még jól is jött hogy iretq() van, de, rendszerprogramozási teszt szempontjából az a verzíó, hogy teljesen rád van bízva az interrupt handlerből való visszatérés, érdekesebb lett volna!
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Köszönöm, máris hozzáadom!
Erre elvileg nincs szükség, a betöltő pont azért van. Bármilyen szabályos ELF vagy PE/COFF betölthető velük, nem kell alacsony szintű raw binary fájlokkal vacakolni, meg futásidőben valós módban betölteni a fennmaradó részt.
Tessék az AMD és Intel mérnököknél panaszkodni, ne nálam. Így működik a CPU, ezt nem tudod megkerülni. Még Assembly-ben is külön speciális utasítás van erre (aminek a neve történetesen "iretq").
Dehogyisnem! Pontosan tudod, hogy a stackframe egyetlen változót helyez a verembe (a korábbi stackframe tetejét), és ez nyelv valamint fordító független, illetve a függvényhívás CALL utasítás mégegyet, de ez megint nyelv és fordító független.
Egy C program ezen a CPU specifikus működésen túl nem is nyúl a veremhez (amennyiben a függvény nem tartalmaz lokális változót).
Pont ez volt a verseny egyik célja, hogy az ilyenekre, amire itt panaszkodsz, rávilágítson: a Rust nem egy jövőbiztos megoldás, a C-vel ellentétben nincs semmi garancia arra, hogy 5 év múlva is működőképes programot fog fordítani! Simán lehet, hogy addig vagy 10x átírják az ABI-ját, ami úgy fogja eltörni a kódodat, hogy közben nem változik a forrásod egy bitet se!
Bocs, de amit a C fordító "nem nyúl a veremhez" eszmefuttatásról írsz, az egyáltalán nincs így és 100% fordító specifikus. És amint írtam, még optimalizációs beállítástól is függhet (pl. generál-e a fordító frame pointert az rbp-be, ezt eltárolja-e a verembe vagy sem). Erről vajmi keveset ír az ABI... Ez egy olyan dolog amire _semmi_ garancia nincs. Sem C-ben, sem semmiylen nyelven.
Most kipróbáltam, GCC 12.2.0, x86_64 Debian bookworm, természetesen -O3-mal egy üres függvény kizárólag egy "ret"-re fordul, míg -O0-val beletolja a frame pointert is a stackbe. Szóval ha erre akarod építeni az elméleted hogy a Rust miért nem "jövőbiztos" akkor ez masszívan mellément.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Nem. A stackframe maga független. Az optimalizációtól csak az függ, hogy teljes egészében kimarad-e vagy sem, az nem, hogy hogyan működik.
Nagyon nem! Fogadjuk, hogy 10 év múlva is épp ugyanúgy be fogja tenni a stackframe-t bármelyik C fordító -O0 esetén, és épp ugyanúgy csakis a korábbi stackframe tetejét fogja csak a verembe tenni, semmi mást! Ez már a DOS-os fordítóknál is így működött, és gcc 2.0 (a legelső gcc verzió, amit használtam) óta egész biztos így van, Clang alatt is így van, és az is biztos, hogy így is fog maradni. Mind a gcc, mind a Clang esetén különösen odafigyelnek a backward kompatíbilitásra (a -O3 persze nagy valószínűséggel generálhat mást, de az -O0 nem fog változni, ebben biztos vagyok).
Az hogy a stackframe miért nem változik, annak sokkal inkább ABi és hardware-es okai vannak, semmint fordító okai, ezért volt már így DOS-on és GCC2.0-n is... De a localsize attól még megváltozik az optimalizációtól, ergó át kell írni azt a rohadt konstanst.
Másrészt ha jól értem akkor a vélemény és érvrendszer átment abból hogy a "C garantálja a kompatibilitást" abba hogy a "C garantálja a kompatibilitást -O0 esetén". Ami vicces lenne, ha nem lenne legalább annyira szomorú...
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Pontosan, nem fordító specifikus.
Természetesen. De nincs más mód. Ha tudsz egy bármilyen más megoldást erre, mint a localsize változó átadása, csak szólj és lecserélem.
Annyiban jogos, hogy valóban nem írtam explicit ki, mert magától értetődőnek vettem, hogy a fordítók optimalizálójai folyamatosan fejlődnek és változnak, és hogy a megoldásom -O0-át használ. Valóban explicit ki kellett volna már írnom a legelején a félreértések elkerülése végett.
Valószínűleg a "helyes" megoldáshoz nem fogod megúszni, hogy az interrupt handlered egy assembly függvénybe lépjen be először. Hiszen a mostani megoldás kb. "véletlenül", a megszakításkezelő egyszerűsége és a főprogram gyakorlatilag teljes hiánya miatt működik (így a főprogram nem kerül regiszter-konfliktusba a megszakításkezelővel). Az interruptkezelőnek ugyanis nem csak az ABI által deklarált, hanem az összes regisztert le kell(ene) mentenie, beleértve az ABI által scratch regiszterként definiáltakat, az FPU-t és a multimédia (SIMD) regisztereket is.
Mint mondtam, Free Pascalban lehet "interrupt"-ként deklarálni egy függvényt, akkor a fordító magától tudja, hogy az összes regisztert le kell mentenie és visszaállítania, ill. hogy iretq-t kell fordítania a függvény végén. Ha ez nincs, mert az adott nyelv kevésbé alkalmas rendszerprogramozásra mint egy Pascal (trollface), akkor nincs más megoldás mint az assembly stub-ból callback, amit már szintén mondtak itt páran.
Ezt az egészet egyébként részletezi ez a cikk. Amit - ó az irónia - Rust-hoz írtak.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Ez szerintem elég rossz megközelítése a kérdésnek, ezt semmi sem garantálja. Ez a törékeny megoldások mintaképe. A fordítónál a backward compatibility nem erről szól, hogy ilyen jellegű garanciákat adna. Ezzel inkább csak magadnak és másoknak adsz munkát, amikor később egy ilyet javítani kell.
Célszerűbb előremutatóbban gondolkozni, és olyan megoldásokat és program struktúrákat keresni, amik definíció szerint jól fognak működni, később is, garantáltan.
Nyilván, de akkor a Rust labdába se rúghatott volna a verseny során, mert mindenképp Assembly-ben kellett volna megírni a necces részt.
Itt arra gondolok, hogyan tudom azt elérni, hogy a Rust által generált output az ne támaszkodjon arra, hogy van oprendszer, ill. van C runtime. Van ehhez opció, csak nyilvánvalóan ez az erősen haladó rész. Ahogy mondtam, ez az első Rust programom. Szóval ez inkább a saját szívásom volt :)
Ezzel én teljes mértékben tisztában vagyok. És semmi hiba nincs a CPU utasításkészletében. Itt csakis abban van a hiba, hogy te hogyan tervezted meg, hogy a megoldás futása során majd meghívódjon az IRETQ utasítás. Arra gondolok, hogy ahelyett, hogy
sokkal értelmesebb így csinálni:
Ez tippre nem így van, szerintem lehet olyan bonyolult kifejezéseket csinálni, ahol lokális változó nélkül is muszáj a stack-hez nyúlnia a compilernek. Másik szempont: ha csapatban dolgozol? És bárki hozzáad később egy lokális változót a függvényhez? Akkor mindenki vakarhatja a fejét, hogy mitől fagy le az egész, mert van valahol benne egy magic constant, aminek elmászott az értéke.
És ez teljesen igaz C-re és Rust-ra is. Ez a fajta megközelítés nyelvfüggetelenül szívás. Ahogy mások is írták, akár compiler optimalizációs szinttől is függ. Pl. a Microsoft compiler a CALL helyett JMP hívással megy tovább a bootloader-ed függvényébe, mivel látja, hogy ez a függvény utolsó sora. Úgy itt ezért kellett pl. negatív szám ahhoz, hogy mekkora a stack frame.
Azt akartam ezzel mondani, hogy ez egy értelmesebb méretű rendszernél átgondolandó. A jelen példaprogramnál persze tökmindegy, mondhatni a kihívás része :)
Ezt amúgy úgy hívják hogy tail-call optimization és/vagy tail call elimination és szabvány optimalizációs gyakorlat. Wiki cikk is van róla. Szerintem a GCC is csinál ilyet bizonyos esetekben. De igen, fordítófüggő hogy hányszor és hogyan és milyen helyzetekben használja.
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Igen, ezt kommentként bele is írtam a megoldásba :) Ebből is látszik egyébként, hogyha kommentelni kell valamit, akkor ott valami bűzlik. Jobb, ha a programkód a saját nyelvén önleíró, jól olvasható.
Bocs, a megoldśaod nem néztem még, csak a hozzászólásra reagáltam. Az mindenesetre beszédes, hogy ha jól értem a kihívást az eredeti kiírótól függetlenül megoldók, 3 különböző nyelv és 4 különböző fordótó ellenére is egyetértünk abban, hogy ez az interfész így nagyon nem kerek és inkább a "hogyan ne" példája, semmint annak hogy miért Rust-ban ne. :)
-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-
Persze, na de ekkor Assembly-ben kell írnod wrapper függvényeket, Assembly-ből kell az IDT-t betölteni, és Assembly függvények címét tartalmazná az IDT. Magyarán az égadta világon semmit sem tesztelnél a nyelvből, mert gyakorlatilag minden Assembly-ben lenne. Nyilván megoldható a feladat, ha minden Assembly-ben van és nem az adott nyelven.
És megintcsak persze, de elfelejted, hogy a kifejezés végére muszáj visszaállítani a stack pointert a kifejezés előttire, különben nem működhetne a program. Magyarán olyan, mintha nem is változott volna a stack.
Ez komoly tévedés. Kétségeim vannak a hozzáértéseddel kapcsolatban. A stack pointer a függvény végén áll vissza arra amire kell. Nem pedig a kifejezés végén. Hogy függvény közben hogyan mozog akár a 14. és 16. sor között, az teljesen a fordítóra van bízva.
Tévedés! Ez már optimalizáció függő!
Nem tudom, mire gondolsz. Csak arra tudok gondolni, hogy úgy érted, hogy van olyan optimalizáció (vagyis inkább az optimalizáció teljes hiánya), amikor minden olyan ponton, ami egy kifejezés végének felel meg a forráskódban, visszaáll egy biztos értékre. Ha teljesen precízen akarod, akkor valóban úgy kellett volna írnom, hogy a kifejezés végén nem kell visszaállnia, de visszaállhat. Viszont a lényeg továbbra is az, hogy a függvény végén van az a pont, amikor vissza kell állnia.
De amúgy van ennek jelentősége? Ha jól definiált működésű program struktúrákban gondolkozol, akkor ezek a részletek pont hogy nem számítanak. Csak arra próbálunk többen is rávilágítani, hogy a törékeny megoldás sok ponton törhet el. Egyszerűbb az a program struktúra, ahol nem számít, hogy pontosan mi történik.
Csak arra próbálok rávilágítani, hogy alaposan összetéveszted a nyelv kifejezőerejét tesztelni hivatott, szándékosan pofonegyszerű célfeladatot egy bármilyen production ready programstruktúrával.
Ennyi erővel azzal is érvelhetnél, hogy soha senki ne vegyen Trabantot, mert törékeny és nem jó bele a V8-as motor!
Az, hogy az IDT-t a nyelvből kell beállítani ennél a feladatnál, nem azért van, mert így szokás, hanem mert konkrétan két dolgot is tud tesztelni ezáltal: átadható-e magasszintű tömb alacsonyszintű utasításnak, és hogy magaszintű függvény címén végezhető-e logikai művelet, mert bizony ezek a fránya hardver mérnökök sokszor ilyen elvárásokat támasztanak a rendszerprogramok felé, és nemcsak az IDT-ben, de például az IDT-ben is, így egy nyelv ellenőrzésre kiváló. Érted már?
Szerintem te nem érted, hogy mi a problémám, és másoknak is, aki vette a fáradságot és adott be megoldást. Nem az a gond, hogy mit lehet megoldani Rust-ban (az már felmerülhet, hogy mit célszerű, de most ugye pont arról volt szó, hogyha összeszorítjuk a szánkat, akkor akár ezt a kihívást is meg lehet benne oldani.) Az élő példák mutatják, hogy az IDT felprogramozást is meg lehet írni Rust-ban.
Hanem az a probléma, hogy egy olyan interfészt definiáltál a feladatkiírásban, ami ahogyan összeköti a bootloader-ed meglévő kódját a beadandó megoldással, az törékeny. Most fogalmazzak úgy, hogyha a bootloader ezen része is Rust-ban lenne írva, akkor nem lenne ez a gond :D. De nem így akarok fogalmazni, mert nem akarom megemelni a vérnyomásodat. Úgy fogalmaznék, hogy célszerű olyan interfészt csinálni, ahol bármilyen nyelven van a bootloader, és bármilyen nyelven a megoldás, köztük legyen stabil a bináris interfész.
Na akkor mégegyszer, mutass egy bármilyen más megoldást rá és lecserélem. Az egyetlen kitétel, hogy nem lehet Assembly-ben az egész.
Tökéletesen tisztában vagyok vele, hogy törékeny, ezt már többször jeleztem is, hogy a CLang és fastcall ABI esetén is van vele probléma.
Naná, de az a betöltő nem lenne képes tesztelni a nyelvet. Mit nem lehet érteni azon, hogy ez nem egy célszerű betöltő, hanem direkt specifikusan a nyelvek tesztelésére készült, szándékosan csakis ehhez a feladathoz?
Megpróbálok vázolni egy megoldást. Ehhez először lássuk mi a probléma: eltérő oldalakon vannak definiálva az IDT felprogramozási pont és belépési pont (ezek a megoldandó feladatban, továbbiakban solution), és a kilépési pont (ez a bootloaderben, továbbiakban bootloader :)). Továbbá meg akarjuk tartani azt, hogy az IDT felprogramozás az továbbra is a megoldandó feladatban maradjon, hogy továbbra is téma maradhasson, hogy lehet-e tömböt bitmintával feltölteni Rust-ból.
Ezt át kell alakítani (tőlem mondhatjuk azt is, hogy refaktorálni), hogy valahogy úgy nézzen ki, hogy az IDT felprogramozás a megoldandó feladat része maradjon, az interrupt handler belépési pont és kilépési pont a bootloaderben van, viszont a tényleges timer kezelés már újra a megoldandó feladatban. Így nem keveredik az, hogy a közvetlen IRQ belépés és IRQ kilépés különböző rétegekben van.
Ez úgy működhet, hogy a bootloader úgy hívja meg az ELF vagy PE bináris belépési pontját, hogy átad egy második paramétert is, egy függvény címét, ami az interrupt handler közvetlen belépési pontjának címe, és a bootloaderben van implementálva (legyen ennek a neve bootloader_timer_handler). A megoldandó feladat úgy programozza az IDT-t, hogy ezt a második paraméterként megkapott bootloader_timer_handler adja át a timer interrupt címéhez az IDT-ben.
A bootloader interfészből el kell dobni az iretq függvényt, helyette fel kell venni egy olyan új függvényt, hogy set_solution_handler_address. Ezt az interruptok bekapcsolása előtt kell még meghívni a megoldandó feladatban. Egy paramétert vár, a megoldandó feladatban magas szintű nyelven megírt függvény címét. A bootloader ennek meghívásakor elmenti a megkapott függvény címét a solution_handler_address változóba. A bootloader_timer_handler pedig abból áll a bootloaderben implementálva, hogy CALL utasítással behív a solution_handler_address változóban tárolt címre, utána meg megcsinálja az OUT és IRETQ utasításokat. Ezzel az a struktúra fog kialakulni, amiről már az elején itt írtam: https://hup.hu/comment/3037581#comment-3037581
Javaslom, hogy ezeket a változásokat úgy csináld meg, hogy külön branchen, vagy ilyesmi, hogy a már beadott feladatok még működjenek.
Hát ez az, ha ez a betöltőben lenne Assembly-ben implementálva, akkor egyáltalán nem lenne alkalmas a nyelv tesztelésére.
Mégegyszer, ha nem kifejezetten azt akarnánk tesztelni, hogy csakis a nyelvben rendelkezésre álló eszközökkel, magas szintű függvényekkel, Assembly nélkül megoldható-e a megszakításkezelés (ami egy tipikus példája a nyakatekert rendszerprogramozásnak, tömbátadással, függvénycím bitshifteléssel stb.), akkor nyilván én is Assembly wrappert használnék. Sőt, mi több, tuti, hogy nem megírnám, hanem Assembly makrókkal generáltatnám ki, az ISR-eket éppúgy, mint az IDT tartalmát. Interfész helyett meg egyetlen inline Assembly-vel töltetném be az IDT címét. De hát pont az a cél itt, hogy csakis a nyelv natív eszközkészletét lehessen használni, mivel arra vagyunk kíváncsiak, hogy azzal megoldható-e.
Figyeld meg, az interfész direkt csak CPU utasításokat burkol körbe, a lehető legalacsonyabb szintű. Az első draft-ban az "iretq" tényleg csak egy "iretq" utasítás volt, és volt benne "inb" meg "outb" is. Aztán úgy döntöttem, hogy még a megszakításvezérlőt se kelljen nyugtázni, mert az már nem nyelvi ismereteket, hanem meghajtóprogramozási ismereteket igényel, azért kikerült az "inb" / "outb" az interfészből, a nyugtázás meg bekerült az "iretq"-ba.
Hát, szerintem ez a gondolatkísérlet ott sántít, hogy azzal, hogy ragaszkodsz a kiindulási struktúrához, nem azt teszteled valójába, amit akartál, hogy vajon a Rust jobb/rosszabb-e mint a C. Mert mint látszik, mindegyikben sikerült megoldást írni. És egyébként mindegyik nagyon hasonló felépétésében, a Pascal-os is. És mindegyik törékeny, igen a C is.
Aminek oka, hogy a kiindulási peremfeltételeid mentén, ha ezekhez továbbra is ragaszkodsz, mindegyik megoldás csak törékeny lehet. Kivéve az assembly, de ugye most valamiért ehhez ragaszkodsz, hogy assembly ne lehessen a megoldás része. Ha van benne unsafe, akkor miért ne lehetne kb. 3 sor assembly is? És ismétlem, ez C-nél is ugyanúgy kell ahhoz, hogy jól struktúrált legyen a megoldás. És akkor most ez a néhány sor assembly vagy a bootloaderbe kerül egészében, vagy a megoldandó feladatba egészében. Másképp nem fog menni.
Még lehetne esetleg azzal játszani, hogy semmi sincs a bootloaderben, minden a megoldandó feladatban van, belépés és kilépés, és nem assembly-ben, de akkor a nyelvnek explicit támogatni kell azt, hogy egy függvény nem normál függvény, hanem interrupt handler.
Van ilyen kezdeményezés a Rust-nál, de még nincs kész: https://github.com/rust-lang/rust/issues/40180
És itt a C szintén elvérzik (hoppá, erre számítottál?): https://stackoverflow.com/questions/21336730/can-interrupts-be-handled-…
Dehogyisnem, pontosan azt. Olvasd csak el a kiírást, a cél mindig is az volt, hogy kiderüljön, ha meg lehet oldani, akkor mennyi hekkelés és speciális kulcszó árán. C alatt ehhez egyetlen speciális kulcsszó sem kell, simán működik mezei függvényként is. Quod Errat Demonstrandum.
Nem, nem lehetne. Sosem fogsz pl. lidt vagy sti utasítást generáltatni semmilyen magas szintű nyelvből. Ehhez minimum inline Assembly kell.
LOL! Most komolyan utolsó szalmaszálként azt próbálnád tagadni, amire több működő PoC is van...? Legalább 2 ember legalább 4 különböző programban simán megoldotta...
Működik, de törékeny. Tehát a "simán működik" nem helytálló. Ezt mások is részletezték, hogy különböző C fordító opciókkal hogy változik a stack frame mérete.
Itt nem az LIDT utasításra gondoltam, a "minden"-nel az interrupt handler belépésére ÉS kilépésére utaltam, és ez szerepel a mondatomban is. Jelenleg a belépés a magas szintű nyelvben van, a kilépés a boot loaderedben, és mondjuk ki, ez a szálban részletezett probléma gyökere.
És ahogy látható, ez másnak is szemet szúrt, aki szintén megoldotta. Jó tanács: ha mindenki szembe megy az autópályán, érdemes elgondolkozni, hogy ki tévedt el...
Ez nem utolsó szalmaszál, valamit félreértesz. Ez arra utalt, hogy van-e nyelvi elem arra, hogy a fordító IRETQ-t generáljon. És jelenleg se a szabvány Rust-ban, se a szabvány C-ben nincs.
Lehet, hogy elkeveredtél a thread-ek és hozzászólók közt, de én oldottam meg C-ben és Rust-ban is, egyszerre. Szerintem komoly szövegértési problémáid vannak, és fel sem fogod, hogy mit próbálok magyarázni itt sok hozzászóláson keresztül, hogy igen, vannak megoldások a feladatodra, több nyelven is. De mindegyik törékeny, és hogy miért, azért, mert olyan interfészt találtál ki, ami magas szintű nyelven csak törékeny lehet, és ragaszkodsz ahhoz, hogy ne legyen assembly a megoldásban.
Tovább nem fogom ezt részletezni, mert úgy érzem, hogy felesleges, mert egyszerűen fel sem fogod igazán, hogy miről próbálok itt beszélni, mi a probléma. Sajnálom.
Itt most saját magad ismerted be, hogy a kilépés nem is lenne sehogy másként megoldható (az inline Assembly ugye nem megengedett).
Nem nekem vannak szövegértési problémáim, hanem Te keveredtél önellentmondásba.
A lehető legegyszerűbb interfészt alkottam meg, aminél natív függvényben van a megszakításkezelő belépési pontja, és igen, ragaszkodom hozzá, hogy ne Assembly-ben legyen, mert akkor az - ki hitte volna - Assembly-ben lenne és nem az adott nyelven.
Így van a kilépés nem oldható meg, assembly kell. De továbbra sem érted, hogy akkor jól strukturált és nem törékeny a program, ha a kilépés és a belépés ugyanabban a rétegben van (vagy a bootloaderben, vagy megoldásban). Tehát a belépésnek is assembly-ben kéne lennie, hogy ne legyen törékeny.
De lehet, hogy nem szövegértési problémák vannak, hanem a rövidtávú memórával vannak gondok. Milyen érdekes, hogy pont ma részleteztem neked, hogyan oldható ez meg normálisan:
https://hup.hu/comment/3037581#comment-3037581
https://hup.hu/comment/3037646#comment-3037646
Oké, ragaszkodj hozzá, de ezzel nem a C/Rust között teszel különbséget, mert ismét, sokadszor, mindkettőben pont ugyanolyan törékeny megoldást lehet csak gyártani. Amivel nincs gond egy ilyen kihívásnál, ha odatesszük mellé, hogy igen, itt a megoldás, de törékeny, mert ilyen a kiírás.
És te mégis felróttad.
Világosan megmondtam, hogy miért rossz. Ha nem érted, az nem az én bajom, de a megoldásod egyszerűen nem alkalmas arra a feladatra, amire ez a verseny hivatott. A gyorsfutókat sem centivel méred, hanem stopperrel.
Még véletlenül sem azért van az egységes interfész, hogy bármiféle különbséget tegyen, pont ellenkezőleg.
Miért nem vagy képes megérteni, hogy a verseny célja a nyelv kifejezőerejének és az ehhez szükséges gányolások mennyiségének felmérése és nem pedig egy atomstabil operációs kernel írása?
Rohadtul senkit nem érdekel, hogy törkény-e a kizárólag ehhez az egy feladathoz megalkotott egyszeri interfész, mert kurvára senki sem fogja sehol máshol, de pláne nem egy production rendszerben soha felhasználni. Egyetlen egy célja van, és arra alkalmas, pont.
Úgy érzem, van ahová nem kell már lényegi válasz. Úgyhogy, ez ennyi. Bár közben már a személyeskedést kiszedted a kommentedből, sajnos nem voltam elég gyors :D
Azért részedről sem ártana egy bocsánatkérés.
Olyant követelsz, ami sosem volt cél ennél a versenynél, kb. mintha azt várnád el a magasugróktól, hogy egyben tökéletes balett-táncosok is legyenek. Ne csodáld, ha elsőre felhúztam magam. És igen, gyorsan korrigáltam, mert személyeskedés nélkül is igazam van.
Nem volt sértő szándékom, én egész eddig csak azt próbáltam átadni (és nem követeltem, igyekeztem úgy fogalmazni, hogy javaslat legyen), és szerintem az itteni szokásokhoz képest meglehetősen elég konstruktívan: https://hup.hu/comment/3037646#comment-3037646 hogy hogyan lehet azt megoldani, hogy ne legyen szívás az interrupt-ból való kiszállás.
Beláthatod, hogy ez egy fájó pont, és emiatt a beadott megoldások "csúnyák" és "törékenyek", ezt más is jelezte, hogy bántja a szemét. És ilyenkor felmerül, hogy lehetett-e volna jobban megcsinálni a kiírást.
Lehet, hogy nem adtam át elég jól érthetően, de ez egy olyan átalakítás, hogy a timer kezelő továbbra is Rust/C, ahol az eddigi beadott programok lényegében annyit változnak csak, hogy a timer kezelő utolsó sora nem a bootloader felé az iretq hívás, hanem csak simán a függvény vége (normál visszatérés egy normál függvényből). De maga függvény, a counter növelés, képernyőre kiírás tökéletesen ugyanúgy néz ki, Rust-ban vagy C-ben van implementálva, pont úgy mint a már meglévő megoldásokban, nem kell emiatt assembly sehol a megoldásban, és nincs a törékeny alloc_size magic konstans. Tehát szinte ugyanúgy néz ki minden, pontosan ugyanúgy teszteled a nyelvek közti különbségeket és hasonlóságokat.
Szerintem is. Ezért is döntöttem úgy, hogy módosítom a korábbi posztom.
Pontosan. És mivel ez egy normál visszatérés egy normál függvényből, pont ezért alkalmatlan annak tesztelésére, amiről itt szó van. Azt se felejtsük el, hogy ilyenkor a megszakításkezelő belépési pontja is Assembly, és nem pedig natív függvény.
Ez így önmagában alkalmatlan annak eldöntésére, hogy egy nyelv használható-e rendszerfejlesztésre, ami az egyik kiemelt szempont.
Nem. Ezáltal pont azt iktatnád ki a tesztből, a lényege.
A számláló maga nem érdekes, az csak azért van, hogy ne kelljen debugger ahhoz, hogy lássuk, működik-e. A lényeg az az, hogy alacsony szintről hívódjon egy magas szintű, adott nyelven íródott funkció, a lehető legkevesebb hekkeléssel.
Hát nem, mert a gyakorlatban született megoldások azt mutatják, hogy az interrupt-ba belépés pofonegyszerű minden eddigi megoldás nyelvén, a kilépés meg "bizonytalan" minden eddig nyelven. Tehát akkor itt mégis mit döntünk el a rendszerprogramozhatóság lehetőségéről az egyes nyelvek között? Szerintem semmit, mert az derül ki, hogyha megbízhatóan akarsz interrupt kezelést programozni (rendszerprogramozni), akkor muszáj egy assembly stub a belépésre ÉS kilépésre is. És ez igaz C-re, Rust-ra, Pascal-ra is.
Tehát továbbra is igaznak tartom, hogy a javasolt átalakítással nem veszted el a rendszerprogramozhatóság eldöntését a nyelvek között, de egy korrektebb keretet adsz az egésznek.
Azt már csak halkan jegyzem meg, hogy az inline assembly a Rust nyelv specifikációjának része, a C-nek viszont nem. Tehát az lenne a helyes értelmezés, hogy Rust pályaműben használhatjuk, C-ben viszont nem. Lassan ott tartunk, hogy kiderül, hogy bzt saját meghatározása szerint a Rust alkalmas rendszerprogramozásra, de a C nem :-)
Én csináltam pointer és inline Assembly mentes C megoldást. Hol is van a Te unsafe mentes Rust megoldásod?
Azért azt pointer mentesnek nevezni, hogy a videó memória tömbödet a linkerrel fix címre rakatod, az elég furcsa érvelés. Valóban kevesebb a * karakter a C kódodban, mert így nem pointerrel éred el a fix címet, de attól még te is pontosan tudod, hogy ez tökéletesen ugyanaz, mint egy pointer egy fix címre, csak a linker eszközeivel megoldva, és tökéletesen ugyanaz, mint a Rust-ban az unsafe blokkban a pointer egy fix címre.
Azért itt felmerül az a kérdés, hogy a postás a Kossuth utca 10 címre érkező levelet vajon fix címre hordja ki vagy pointerrel? És csak a linker eszközeivel megoldva a pozícióját változtatja-e a Kossuth utca 10? Vajon postás bátyánk melyik esetben rohan túl - unsafe módon - az adott címen? :-D
Mindkét esetben ugyanúgy csinálsz buffer overflow-t. Ha elhibázod annak a kiszámolását, hogy a videó memória hányadik karakterét akarod módosítani (mindegy hogy pointerhez hozzáadással vagy a tömbbe indexeléssel), akkor túlfutottál. De javíts ki, ha tévednék.
Ha ez ellen akarsz védekezni, akkor kell valami API, amivel eléred a képernyőt. Amennyiben közvetlenül írsz a memóriába, memóriába ágyazott perifériára, úgy mindig követhetsz el hibát. Azt nem értem, hogy ez miért baj. Például while (true);, aztán puff, wathcdog reset. Szóval ahhoz nem kell sokat tenni, hogy valamit elrontsunk, de lehet a fenti példában szándékos is annak a wd resetnek a triggerelése. Akkor ez most bug vagy feature? Attól függ, hol írom le az adott kódot és mi vele a célom.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Örülök, hogy te is így látod. Hogy miért baj? Nem maga a konstrukció a baj, mert az egy ugyanolyan unsafe megoldási lehetőség, mint az összes többi, igazából ízlés dolga. Hanem a mögötte lévő érvelés a baj (és ezért ez a válasz igazából nem is feltétenül neked szól): mert aki a "pointer-mentes" C megoldással érvel, hogy aztán az biztonságos, mivel ugye nincs benne pointer, az abban a tévképzetben lehet, hogy nem is csinálhat buffer overrun-t. De csinálhat. Pont ugyanúgy, mint a C pointer, vagy a Rust unsafe pointer.
Trollkodás helyett itt a válaszom: A feladatban egyetlen (na jó, kettő) abszolút cím van. Ez nem "szoftver element", hanem fix érték. Szerintem elég hülye az, aki - a címzés módjától függetlenül - olyan kódot képes erre írni, ami képes eltéveszteni a célt. Az abszolút címnek az a legfontosabb tulajdonsága, hogy egyszerűen ott van, mivel hardver.
Ha jól értem a szálat, gondolkodni nem akaró balfék programozók ellen kitalálnak új programnyelveket, amelyek még fegyelmezetlenebb kódolásra ösztönzik a szakma művelésére alkalmatlanokat, amelynek hatására majd még hülyebiztosabb nyelvek lesznek, amelyekben már szinte semmit sem lehet megvalósítani, mert az úgy nem biztonságos. :(
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A C is pont így keletkezett, ahogy leírtad, csak neked már az a baseline.
https://iotguru.cloud
Már az assembly után? A magam részéről jól megvagyok assembly-vel is, ott inkább az a baj, hogy többféle platformra meg kell tanulni a CPU-t, ami kellemetlen, illetve ami C-ben nagyon egyszerűen, kényelmesen megfogalmazható, az azért assembly-ben egy hegymászós túra szöges bakancsban.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Meglepő módon a C a B utódja, aminek az elődje a BCPL, ami a CPL utódja, amit az ALGOL 60 inspirált, az ALGOL a FORTRAN egyik továbbfejlesztése, ami a SpeedCoding hiányosságait oldotta meg és a SpeedCoding az, amire azt lehet mondani, hogy az assembly után jött.
Mindegyik azért jött létre, mert "gondolkodni nem akaró balfék programozók ellen kitalálnak új programnyelveket, amelyek még fegyelmezetlenebb kódolásra ösztönzik a szakma művelésére alkalmatlanokat, amelynek hatására majd még hülyebiztosabb nyelvek lesznek, amelyekben már szinte semmit sem lehet megvalósítani, mert az úgy nem biztonságos."
https://iotguru.cloud
Nem hinném, akkoriban nem a safety volt a becsípődés, hanem a funkcionalitás kiterjesztése. Fortranról már csak nagyon halvány emlékeim vannak, tanultam, de nem használtam, de úgy rémlik, a C-nél sokkal sótlanabb, szegényesebb nyelv.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Funkcionalitás kiterjesztése? Mit nem tudtál megcsinálni Assembly-ben, amihez C kellett? A C előnye az, hogy sokkal kevesebb melóval tudsz biztonságosabb programot írni, ahogy említetted is: "ami C-ben nagyon egyszerűen, kényelmesen megfogalmazható, az azért assembly-ben egy hegymászós túra szöges bakancsban". A C egy csomó dolgot megcsinál helyetted és biztonságosabb is, mintha Assembly-ben írtad volna meg, ahol könnyen el tudsz nézni egy címkét, ahova ugranod kell és már szétesett a program.
Szóval újra: a C azért jött létre, hogy a "gondolkodni nem akaró balfék programozók ellen kitalálnak új programnyelveket, amelyek még fegyelmezetlenebb kódolásra ösztönzik a szakma művelésére alkalmatlanokat, amelynek hatására majd még hülyebiztosabb nyelvek lesznek, amelyekben már szinte semmit sem lehet megvalósítani, mert az úgy nem biztonságos".
A C nem egy elérendő állapot, hanem egy darab nyelv a fejlődés hosszú-hosszú útján. Aki mostanában kerül bele a szakmába, annak a Rust lesz a "C" és a C lesz az, ami neked most a Fortran és úgy nézel most a Rust-ra, mint annó a Fortran programozók a C-re. És még mindig vannak karbanartott Fortran programok...
https://iotguru.cloud
Teljesen félreérted. Pl. a Rust lekorlátoz egy csomó mindenben, hogy biztonságosabb, kevesebb hiba legyen a kódban, de megadja a lehetőséget, hogy mindent megcsinálhass, ha biztos vagy abban. Pont erre való az unsafe kulcsszó.
Az alábbi hozzászólásod alapján magadat is a "gondolkodni nem akaró balfék programozók" közé sorolod?
Nem mondtam soha, hogy nem hibázok. Csak ne az legyen az az általános hozzáállás, hogy nyfog a fordító, rakjunk a változó neve elé egy csillagot, még mindig nyafog, tegyünk elé még egyet, most lefordult, tehát így lesz jó. Mert nagyon nem, meg kell nézni, hogyan lett deklarálva az a változó, hogyan használjuk, mert le lehet írni ilyen módon úgy is valamit, hogy lefordul ugyan, de nagyon nem az fog történni, amit szeretnénk.
Hibázni szabad, tessék megkeresni a bugot és kijavítani! Nekem egyes emberek mentalitásával van bajom, azzal, amikor félszívvel csinálnak valamit „jóvanazúgy” megközelítéssel.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
A switch-hez pont láttam olyat valahol, hogy lehet overrun, de kulcsszóval jelölni kell, vagy break; vagy overrun; kell mindenképpen. Így nem lehet benézni, de a teljesítmény is megmarad.
Igen, ez például jó ötlet, a C-ben nem gondoltak rá.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Eszembe jutott még egy hibalehetőség. Nem mindegy, hogy egy tömbben sizeof()-ot vagy elemszámot használunk. Van ahol az egyikre, van, ahol a másikra van szükség. De például a konstans string sizeof()-ja meg eggyel nagyobb, mint a hossza érthető okok miatt. Itt is lehet hibát véteni.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Szerinted, ha egy nem törődöm programozó csak úgy tud megírni egy kódot, hogy a fordító lépten-nyomon figyelmezteti és nem fogadja el a hibás kódot az sokkal rosszabb, mintha elsőre elfogadná és majd futás közben derül ki, ott is kétszer, háromszor elszáll, mire jó lesz?
Ezt azért gondold át!
Nem attól lesz jó egy programozó hozzáállása, hogy bármit megcsinálhat és nem kell figyelnie semmire, sőt!
Kényelmessé tesznek ezek a mesterséges korlátok, ami fegyelmezetlenséget és nemtörődömséget okoz.
Amikor fiatal voltam, nem voltak mobiltelefonok. Buták sem. Ha valakivel találkozni akartunk, s azt megbeszéltük két nappal, vagy egy héttel a találkozó előtt, akkor nem felejtettünk el odamenni, nem szóltunk oda a találkozó előtt fél órával, hogy jaj, bocs, kések egy órát, mert hullik a macskám szőre, hiszen erre nem volt lehetőségünk, hanem ott voltunk. Mindenképpen.
Ma oda lehet szólni a másiknak, ezért sokan fegyelmezetlenek, nem adják meg a másik embernek a kellő tiszteletet. Esik az eső? Nem baj, majd írok egy chat üzenetet vagy felhívom, hogy nem megyek. Az már vérmérséklet kérdése, hogy tartozik-e hozzá indoklás, egy átlátszó hazugság lesz az indok, vagy a valós, de elég rosszul csengő érv. Mindegyik nagyon rosszul hangzik. A telefon, a kommunikáció könnyebbé válása nem segített, hanem fegyelmezetlenné tett, az emberek most már nem megbízhatók.
Épp, mint az újabb programnyelveket használó programozók.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Most korbeneztem a korulottem ulo Scala, Python, Go "ujabb proframnyelveket hasznalo programozok kozott", hat a legfiatalabb 42. Mondtam nekik hogy mondtad hogy mind fegyelmezetlen halatlan pocs, mert nem C-ben irjak a kodot, hanem a faszsagaikban amik nem is igazi programnyelvek. Megkerdezem majd Csabit is aki 57, hogy mi a velemenye errol. :D
Általában írtam. Azok, akikről te beszélsz, szerintem C-ben is jó programokat írnak vagy írnának, nekik nem feltétlen szükséges a minőségi munkához a nyelv korlátoltsága. Azokról beszéltem, akik fércmunkákat adnak ki a kezeik közül, s csak a limitáció tartja hellyel-közzel megfelelő keretek között az alkotásaikat.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Akkor tulajdonképpen elpattintottál egy "ezek a mai fiatalok" mondást és megpróbáltad ráhúzni a C nyelvre, hogy az bezzeg adna tartást, de aztán kiderült, hogy semmi köze az egésznek a C nyelvhez, pusztán csak a fiatalokkal van bajod?
https://iotguru.cloud
regenmindenjobbvo't!!!!!11 :D
Azt mondom, hogy semmi baj a C nyelvvel. Nagy szabadságot enget, teret ad a fantáziának, szabadon lehet benne kódolni, nem köti meg az ember kezét. Egyesek szemében ez veszélyes, mert ők nem bíznak a kóderben. Azt mondom, aki nem hajlandó precíz munkát végezni, nem írja ki pl., hogy if (ptr) *ptr = valami;, az ne csak C-ben, de más nyelven se programozzon, hanem menjen babszemeket válogatni, arra talán alkalmas. Azzal az iránnyal van bajom, hogy hülyék ellen hülyebiztos nyelvvekkel védekezünk a szabadság rovására ahelyett, hogy igényesebb emberek művelnék ezt a szakmát.
tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE
Tegye fel a kezét aki hibátlan kódot ír mindig. Most pedig tegye fel a kezét aki szerint fontos hogy a lehető legkevesebb hibát tartalmazó kódok készüljenek el? Most pedig az, aki szerint ne a technikai hibákkal kelljen foglalkozni fejlesztés közben hanem a logikai hibákkal. Szerintem meg is válaszoltuk a kérdésre a választ. Nem, nem a hülyék miatt emeljük magasabb szintre az absztrakciót, hanem azért, hogy a lényegre tudjunk fókuszálni, az üzleti érték előállítására egy olyan iparágban ami alapvetően nagyon drága.
Nem kell ehhez kézfeltét, szépen látszik a szomszé