Miért nem értik meg az emberek, hogy vége az IT "aranykorának"?

2*Sü, meg kell mondjam, te csak arra vagy jó, hogy bosszantsd az embert, vagy hogy legyen kin röhögni. Most már csak röviden válaszolgatok neked, mert unom a firkálmányaidat és a fafejűségedet.

>>> "Mutass egy olyan példát, aminél ennek az oka az eltérő architektúrák eltérő memóriacímzése."

Ezer ilyen akad, de nem csak a memória címzése, hanem már a processzor üzemmódja is korlát, mert x86 esetén pl. a BIOS és annak rutinjai, szolgáltatásai csak valós módban érhetőek el, védett módban erre lehetőség, jellemzően nincs. A képernyő memória direkt elérését szolgalmazó rutinokat már nem is hozom fel.

>>> "Nyilván tudod, hogy az Android hivatalosan ajánlott programozási nyelve"

A google egy magáncég, ergo, nincs olyan tevékenysége, hogy "hivatalos". Ami hivatalos, az a NAV felszólító levele, vagy egy bírósági végzés, netán rendőrségi idézés. Ezek mindegyike hivatalos, de a google és az ő céges nyilatkozataik éppen annyira hivatalosak, mint egy kocsma közepén ordibáló emberé, szóval: semennyire.

>>> "Nem azért született a C, mint absztrakciós szint, mert a fejlesztő hülye. Azért született, mert a fejlesztő nem akar 10 különböző kódot írni, hogy 10 különböző platformon, oprendszeren, architektúrán is futtatható legyen ugyanaz a program."

Ez a te, meglehetősen stupid álláspontod, amely primitív, nevetséges, azon túl, hogy merő kitaláció, ami a te tájékozatlanságodon alapul.

A C azért született, mert az assembly túl fárasztó, a B nyelv meg túl lompos és körülményes volt ahhoz, hogy kielégítse a UNIX-szal kapcsolatos fejlesztői igényeket és véletlenül sem azért, amit te ide behazudsz.

Eleve, a C nem absztrakciós szint, hanem egy MID level programozási nyelv. Az más kérdés, hogy mint minden programozási nyelv, nyújt valamilyen absztrakciót, más alternatívákhoz képest. Mondjuk a valamivel korábbi Algolhoz, Pascalhoz képest kifejezetten szegényes ez az absztrakció. A C kód meg kb. annyira hordozható, mint egy vonatszerelvény kerekek nélkül. Nem véletlen, hogy #include direktíva nélkül nem is igen lehet C nyelvű, működőképes programot írni. Pascalban viszont lehet. Ennek fényében éppen a C-re mondani azt, amit te behazudsz, ez az évtized vicce. A C nyelv éppen a hardver-közeliségének köszönheti a karrierjét.

Egyébként, hogy az igazat megtudd, a C kezdetben a UNIX opre forrása mellé volt csomagolva és nem volt több, mint egy preprocesszor meg egy transpiler (ez az egyik prog-nyelvről egy másikra fordít, de forrást köp ki). A preprocesszor a forrást feldolgozta, egy köztes formátummá alakítva, a transpiler meg ebből generált assembly kódot. Végül ezt a kódot fordították tárgykódra a célgép assemblerével.

Természetesen az egész cuccot mindenhol az ott egzisztáló gép hardveres képességeihez, egyedi adottságaihoz kellett igazítani. Ez azonban többnyire megérte, mert az assembly mnemonikok átírása és a HW specifikus részek kiigazítása még mindig kisebb munka volt, mint amivel az eredmény (a futó, biztonságos(nak hitt) UNIX) kecsegtetett.

Ráadásul, a C még csak nem is magas szintű, amit mellesleg megelőzött több, valóban magas szintű nyelv, mint a BASIC, Algol, Pascal, stb. De még ezek egyikének sem volt célja az, amiről te próbálod itt kábítani a népet a, már lassan egy kötetet kitevő marhaságaiddal.

>>> "Hát nem a biztonság és az adatvédelem miatt. Az ellen az API önmagában nem véd."

De igen, ugyanis az API, vagy egy köztes layer hivatott ellenőrizni például a memória hivatkozásokat, hogy egyáltalán, tartományon belüli e a kért cím, mert lehet, hogy nincs is n megabájt abban a gépben, csak n div 2. Ilyenkor, ha nem lenne erre való köztes layer, akkor a hiba magával rántaná az oprendszert is. De még írhatnék ilyen példát százat, nem létező, vagy foglalt port címekről, verem túlcsordulásról, hardware failure-ről, csak már nincs hozzá kedvem.

Az operációs rendszer legfőbb feladata az erőforrások adminisztrálásán kívül a védelem. A rendszer védelme (elsődleges prioritás) és a futó programok védelme (másodlagos prioritás).

51: Eddig szórakoztam azon a rengetek ökörségen amit idehánytál. De most már kezd nagyon fárasztó lenni.

Látszik, hogy fogalmad sincs miről beszélsz. És nem az 1960-as hanem az 1860-as években ragadtál le.

"A google egy magáncég, ergo, nincs olyan tevékenysége, hogy "hivatalos". -> Ez az állítás totálisan nem igaz. Ha egy gyártó kiad egy bármilyen terméket (a legegyszerűbb zoknitól az űrhajóig, bármit, akár szoftver akár hardver, egy autó, bármi amit egy gyár állít elő, és itt a Google az Androiddal gyártónak minősül) kiad egy hivatalos(!) anyagot amit műszaki dokumentációnak neveznek. Hogy ennek milyen részei vannak az nagyon függ a terméktől, nyilván egy zokni esetén egészen más mint pl. egy űrhajó esetén. Ennek része az szintén hivatalosan, hogy mire és hogyan "kell" használni. Nyilván ettől eltérő, mert pl. a zoknit húzhatod a fejedre, egy személyautóval jogod van belerohanni a betonfalba stb. stb. tehát ettől a hivatalos dokumentumtól el lehet térni. Azonban ha eltértél használatban (pl. 90-el bele mész szándékosan a betonfalba) akkor megfordul egy jogi eljárásban a bizonyítási kényszer. Amíg betartod azt amit a gyártó ír a termékéről (pl. hogy Androidra ezzel és ezzel a fejlesztő eszközzel javasolja a fejlesztést) és valami nem úgy sikerül (pl. betartod a gyártó összes előírását és kiesik az autó kereke) akkor bizonyos körülmények között még a garancia és szavatossági időn túl is felel a gyártó a termékéért. Ha eltértél akkor neked kell bizonyítani, hogy nem tértél ettől annyira, hogy az érdemben befolyásolja a termék viselkedését. Ld. pl. valaki a fejére húzza a zoknit és ezért megförmed, akkor azért nem a zokni gyártója lesz a felelős. Ezt a jog rendeltetéstől eltérő használatnak nevezi, és pl. egy bírósági eljárásban az első számú dolog amit megnéznek, hogy a gyártó által hivatalosan kiadottak szerint történt az adott dolog használata vagy sem. Aztán lehet vitatkozni, hogy az a felhasználási mód mennyire fér össze a gyártó által kiadottal vagy sem. Ennek persze vannak vicces folyományai, pl. Amerikában a gyártó beleírja, hogy macskát ne száríts a mikrohullámú sütőben. És igen ez innen kezdve hivatalos.

A hsz-ed többi része legalább ekkora tudatlanságról árulkodik. És hatalmas tárgyi tévedésekkel van tele.

"Az operációs rendszer legfőbb feladata az erőforrások adminisztrálásán kívül a védelem. A rendszer védelme (elsődleges prioritás) és a futó programok védelme (másodlagos prioritás)." -> Mondom, hogy leragadtál az 1960-as évek szintjén. 1966. március 31-én jelent meg operációs rendszer a piacon, amelyben már az alkotók célként tűzték ki, hogy az operációs rendszer optimálisan gazdálkodjon az erőforrásokkal, ne csak adminisztrálja, hanem optimalizálja. Ennek lett egy "következménye" az, hogy a gépen egy időben több eltérő feladat elvégzése is lehetségessé vált. És ezt utána az összes többi operációs rendszer folytatta. Tehát legkésőbb 1966 óta az operációs rendser feladat az erőforrás optimalizálás is. Tehát amit írsz legkésőbb 1966 óta nem igaz.

"A rendszer védelme (elsődleges prioritás) és a futó programok védelme (másodlagos prioritás)." -> Eddig azt állítottad, hogy az operációs rendszert programozók készítik, tehát az is egy program. Itt meg azt állítod, hogy az operációs rendszer nem program, mert nem fut a számítógépen. vö. rendszer védelme <-> a futó programok. Ezek szerint az operációs rendszer nem futó program, hanem csak úgy van a levegőben és nem is program mert nem is tud futni? Akkor mi az operációs rendszer ha nem futó program, hiszen másképpen kell védeni?

"De igen, ugyanis az API, vagy egy köztes layer hivatott ellenőrizni például a memória hivatkozásokat, hogy egyáltalán, tartományon belüli e a kért cím, mert lehet, hogy nincs is n megabájt abban a gépben, csak n div 2." -> Nem ez nem az API vagy a köztes layer feladata. Totálisan nagy tévedés. Olvasd el pl. a POSIX leírását abban szépen leírja. Az API (ebből az I -> Interface magyarul illesztő felület) feladata az, hogy függetlenné váljon a programozó által megírt forrásnyelvi program attól, hogy a hardver és az operációs rendszer ezeket hogyan kezeli. Pl. vegyük csak a legegyszerűbb printf (vagy a már többször emlegetett malloc) függvényt. Én a programomban szeretnék kiiratni, hogy "Hello, Word!" nem akarok azzal foglalkozni, hogy milyen processzor, milyen hardver, milyen képernyő van a géphez kötve (vagy printer, vagy bármi amin ez képes megjelenni). Én azt akarom, hogy valahol megjelenjen ember számára láthatóan az, hogy "Hello, Word!". Az én programom egy API-n keresztül (ami függetlenítve lett minden mástól ld. pl. POSIX irányelvek), hog ez jelenjen meg. Majd ez az API "átfordítja" úgy, hogy az operációs rendszer és azon keresztül a hardver ezt el tudja végezni. Ugyanez pepitában a malloc is. Én kérek X db. változónak memóriát a programomban. A malloc az operációs rendszer API-ján keresztül jelzi az operációs rendszernek, hogy ez a bolond memóriát akar, majd az operációs rendszer (itt már ténylegesen hardver, operációs rendszer és egyebek függvényében) ezt vagy oda adja vagy sem. Ha nem kapok vissza egy NULL pointert és tudom, hogy nem sikerült. De az API nem fog a memóriával semmit csinálni, mert az nem az API feladata. Az API feladata, hogy függetlenül attól, hogy mi van az alatta lévő részeken. Azt majd az operációs rendszer és a hardver elvégzi.

Ha mégtávolabb kerülünk az operációs rendszertől nyilván kerülnek be bizonyos védelmi funkciók az API-ba, hiszen minél "korábban" kiderül, hogy valami olyat akar csinálni a program amit nem kéne az a legjobb. De ez nem követelmény egyetlen API-val szemben sem. Nyilván valahol a felhasználói "élmény" és a hardver között meg kell oldani azt, hogy ki mit csinálhat és mit nem. De ez nem elsődlegesen API feladat.

"A C kód meg kb. annyira hordozható, mint egy vonatszerelvény kerekek nélkül. Nem véletlen, hogy #include direktíva nélkül nem is igen lehet C nyelvű, működőképes programot írni." -> Na ennek fuss neki még 1x és olvasd el a C specifikációját. Azok az #inculde direktívák nem a hordozhatatlanság miatt vannak, hanem azért, hogy hatékonyabb programot lehessen írni. És a programozó kézben tudja tartani a programot, és azt, hogy mi is kerül befordításra és mi nem. A C-ben ezt a programozóra bízták, a PASCAL esetén (egyébként az még kevésbé hordozható mint a C, sokkal jobban függ az operációs rendszertől, hogy mit tud és mit nem, és mit kell beállítani, hogy egyáltalán le lehessen fordítani azt a szerencsételen programoit másik operációs rendszeren) ezt majd a fordító és a keretrendszer elintézi (ha egyáltalán sikerül neki). Én a PASCAL-ban is látom a "uses". Ld. pl. az IntToStr ami azért elég gyakran használt és ahhoz ezt azt be kell tölteni. A "uses" a Pascalban és az "inculde" a C-ben kb. ugyanazt csinálja. Megint hazudsz és terelsz és megint neked nincs igazad. (hogy a képességeidet meghalado google kereséstől megkíméljelek:

ld pl.: [link] ) érdekes itt is be kell tölteni egy math unitot. Ez miben más mint a C-ben az include? Idióta.

A többi ökörségre nem is reagálok.

>>> "operációs rendszeren) ezt majd a fordító és a keretrendszer elintézi (ha egyáltalán sikerül neki). Én a PASCAL-ban is látom a "uses". Ld. pl. az IntToStr ami azért elég gyakran használt és ahhoz ezt azt be kell tölteni."

Lol.

Egy IntToStr függvény úgy nyolc, kilenc sor. Kétezer soros interpretert írtam "Uses" direktíva nélkül.

200 éves vagy és ami keveset tudsz, azt is rosszul. Mit keresel itt?

Nesze neked egy ad-hoc Uses-less program:

[link]

Ez az IntToStr fgv. mondjuk azért ilyen hosszú, mert oktatási célt szolgál:

[link]

Pancser.

"És az, hogy valaki szándékosan szopatja magát"

Az te vagy.

" hogy 2-3000 sorokat ír minden értelem nélkül "

Mitagadás, a "minden értelem nélküliség" azért elég szép összeget hozott.

Az az interpreter be lett ágyazva (ezért kerültem a standard függvények használatát) és minden eladott darab után pénzt kaptam, éveken át.

2*Sü, ezt írod:

"Nem azért született a C, mint absztrakciós szint, mert a fejlesztő hülye. Azért született, mert a fejlesztő nem akar 10 különböző kódot írni, hogy 10 különböző platformon, oprendszeren, architektúrán is futtatható legyen ugyanaz a program."

Hát akkor nézzük, mit is írnak erről:

" Although C was not originally designed with portability as a prime goal, it succeeded in expressing programs, even including operating systems, on machines ranging from the smallest personal computers through the mightiest supercomputers."

> Hát akkor nézzük, mit is írnak erről:

Itt félig valóban igazat kell adnom neked. A C megalkotásnál valóban nem nagyon volt a hordozhatóság szempont. Az már inkább az ANSI C megalkotásánál, magyarán a C nyelv szabványosításánál került elő. A nyelv fejlődésénél tehát már meghatározó lett a „write once, compile anywhere” elve. De egy nyelv sztenderdizálása akkor is biztosít valamilyen szintű hordozhatóságot, ha amúgy az nem volt feltétlenül cél.

De szerintem ez érthető, vagy érthetőnek kellene lennie. Nyilván ha én szabványba foglalom, hogy márpedig a short int az 16 bites, akkor minden a szabványnak megfelelő fordítónak kutya kötelessége ekként kezelnie és ennek megfelelően fordítania. Ha az adott gépen (legalább) 16 bites regiszterek vannak, egy inkrementálás egy utasítás lesz, ha csak 8 bitesek a regiszterek, akkor lehet több utasítást kell hozzá generálni. Nekem meg nem kell aggódnom, hogy egy születési évszám elfér-e egy short intben, mert *muszáj* neki elférnie. Nem kell aggódnom hogy ha le kell fordítani – akár úgy is, hogy ne is én fordítom le, hanem valaki más – egy olyan gépen, aminek 8 bites regiszterei vannak, hogy működni fog-e, mert működnie *kell*, ha nem, akkor az már a fordító felelőssége. Nem nekem, hanem a fordítást elvégő személynek, meg a fordító írójának kell tudnia, hogy maga a processzor hogyan végzi el az adott C nyelvű utasításokat.

Egyébként már az assembly is egy absztrakció, akkor is, ha egy adott assembly nyelvjárás kimondottan egy adott architektúrához kötődik. Hiszen más opcode-ja van egy MOV mögött, ha regiszterből regiszterbe történik az adatmozgás, más, ha regiszterből memóriába, ha memóriából regiszterbe, ha direkt memóriacím van, ha indirekt címzés van, ha direkt értékadás van stb… Az assembly mindezt egy elvontabb szinten, a lényegénél megragadva ugyanazon MOV utasításban fogja össze, és a fordító a paraméterek alapján tudja eldönteni, hogy mivé is kell fordítania. Olyannyira így van ez, hogy már bonyolultabb, sok száz soros assembly kódokat írogattam, mikor erről egyáltalán tudomást szereztem.

> Ezer ilyen akad, de nem csak a memória címzése, hanem már a processzor üzemmódja is korlát…

Nem ezer példa kell, hanem néhány. Aminél az, hogy az egyik környezetre lefordított C nyelvű program *azért* nem működik jól, holott a másikon jól működik, mert eltérő a memóriacímzés módja.

Programoztam eleget DOS-ban – még Pascal nyelven –, ja, egy egér pozíciójának lekérdezéséhez is megszakítást kellett meghívni, programoztam hangkártyát, meg csiszolgattam az assembly betétekkel tarkított unitomat, amivel truecolor grafikus módot is tudtam használni. De akkoriban a játékprogramok egy része is úgy működött, hogy rákérdezett, hogy milyen hangkártyád van, ha mondjuk Sound Blaster, akkor melyik IRQ-t és DMA csatornát használja, stb… Ha AdLib kártyád volt, akkor nem lesz hang, mert mi csak Sound Blaster 16-ra, meg AWE 32-re írtuk meg.

De ez a 90-es évek volt. Eltelt azóta kb. 30 év. Nekem *ma* nem kell bizdergálnom a BIOS-t. Meg nem bizdergálom a hardvereket direktben. Miért tenném? Ott az operációs rendszer, az a dolga, hogy a megfelelő drivereken keresztül ezt ő végezze. Nem is tudnám az az 587 különböző féle egeret, meg 237 féle hangkártyát megismerni sem, amiket majd a programom a futása során használni fog. Nem programozom direktben a videókártyát sem. Egy általános program esetén azért nem, mert az operációs rendszer, vagy a keretrendszer által biztosított kínálatot használom, nem nekem kell gondoskodnom arról, hogy a képernyőre rajzoljam azt a checkboxot. De ha nagyon grafika specifikus programot írok, akkor meg azért nem, mert ott van készen egy csomó megoldás az SDL-től az OpenGL-ig.

~ ~ ~

> > De igen, ugyanis az API, vagy egy köztes layer hivatott ellenőrizni például a memória hivatkozásokat, hogy egyáltalán, tartományon belüli e a kért cím, mert lehet, hogy nincs is n megabájt abban a gépben, csak n div 2.

Nem. Egy jól megírt API ellenőrzi a paraméterek helyességét, egy rosszul megírt API meg nem. Egy olyan API esetén, ahol egy korlátozott funkcionalitású rendszer van, ott meg majd az API dokumentációjában le lesz írva, hogy az adatok ellenőrzése a hívó fél dolga, rossz paraméterek esetén a rendszer nem várt működést produkálhat.

Pl. a Windowsnak zárt a forráskódja. Azért van az API, hogy ennek ellenére egy nyílt, egzakt módon meghatározott, jól dokumentált interfészen keresztül mégis használni tudjuk a rendszer szolgáltatásait. Egy bank rendszere is zárt, nem hogy nem kell tudnod a rendszer működését, hanem nem is tudhatod meg. De van egy nyílt API mondjuk egy bankkáttyás fizetéshez.

Tegyük fel, hogy van egy rendszer, aminél adatvédelmi szempontok miatt fontos, hogy egy bevitt dátum egy adott éven belüli dátum legyen. Lehet az API írója ezért úgy oldotta meg, hogy a dátumot két paraméterrel lehet megadni: hónap, nap. Hogy most ő ezt két 8 bites egészben tárolja, vagy unix timestamp formában? Az az ő dolga. Lehet, hogy a rendszer zárt, tehát nem tudhatom meg. Lehet, hogy ez időben meg is változik, de az API ettől még kompatibilis marad, mert az API-t utána igazították, és annak a megvalósítása gondoskodik az adatok konvertálásáról.

De ha pl. unix timestamp formában tárolja az adatokat, viszont az API megírásánál szimplán csak megszorozzák a napot 86 400-zal, nem ellenőrizve, hogy a nap az adott hónapnak megfelelő intervallumban van-e, akkor az API-t meg tudom hívni egy 12. hónap 173. napjával, és így mégis be tudok csempészni egy nem az adott éven belüli dátumot.

Sőt adott estben maga az API léte is lehet a biztonsági rések forrása. Lehet van egy szoftver, aminek van egy felhasználói felülete, és a szoftver rendesen ellenőrzi a felületen megadott adatokat. Biztonságos. De aztán szükség van egy API-ra, amit gyorsan kell megírni, másik programozónak kell megírni, a megírója figyelmetlen volt, álmos volt, másnapos volt, így aztán az API-n keresztül – ami nem ellenőriz minden adatot – be tudok csempészni olyan biztonsági kockázatot jelentő adatokat, amit a szoftver saját felületén keresztül amúgy nem, mert az meg jól ellenőriz minden adatot.

Tehát nem, az API hiánya nem jelent adatvédelmi, biztonsági hiányosságot, az API megléte sem jelenti azt, hogy adatvédelem vagy biztonság szempontjából jobb lenne a helyzet.