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

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.

>>> "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."

Akadj már le erről. A szabványosításnál sem volt szempont semmiféle hordozhatóság. A szabvány csak azt biztosítja, hogy a nyelv eszközei (kulcsszavak, adattipusok, operátorok, stb.) minden használó számára ugyanazt jelentsék. Pl. az értékadás operátora alatt mindenki ugyanazt értse adott nyelv használata során.

Eleve, a C fejlettségi szintje sehol nem volt akkor, amikor az UNIX-ot a segítségével megalkották. Nem is volt cél, hogy a C valaha is több lesz annál a segédeszköznél, aminek szánták. A C a B nyelv korszerűsített verziója volt, ami már tartalmazott adattípusokat is, mivel a B-ben ilyenek abszolút nem léteztek.

>>> "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."

Nem biztosít az semmi effélét. Egy programozási nyelv nem több, mint egy szellemi termék. Egy definíció. Aztán, hogy adott gépen a nyelv alkotója által definiált dolgokat (specifikáció) meg lehet-e valósítani, vagy sem, az kérdéses.

>>> "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."

Ez sem így van. A PC esetében több mint húsz MOV utasítás létezik opkód szinten, de Pl. a PDP-7-esen, amin a UNIX fejlesztése elkezdődött, MOV utasítás nincs, ami meg van, azokat úgy valósították meg, hogy az opkód (assembly szinten LAC vagy DAC) ugyanaz és a paraméter programozza fel az adatutat vagy a címregisztert. Egyébként, minden utasítása ilyen, amiből nincs is túl sok, mindössze 19. Sokan valószinűsítikl is, hogy éppen ez a relatív egyszerűség vitte sikerre a UNIX projektet, mivel egy komplexebb masinán valószinűleg ugyanúgy elvérzett volna a megvalósítás, ahogy dugába dőlt a MULTICS is.

A C is ennek a masinának (PDP-7) köszönheti a népszerűségét, mert ebben nem volt csak 8KiloSzó (a PDP-7 gépi szava 18 bit) memória és ez nagyon beszűkítette a mozgásteret, emiatt lett a C-ben sok az operátor és kevés a kulcsszó.

>>> "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."

Ha kell ilyen, elég ha írsz egy olyan programot, ami nagy. Az ugyanis nem fog futni valós módban, de még le sem fordul, mivel túllépi a 64K-s szegmenshatárt. PC-n ugyanis ekkora a legnagyobb program, ami valós módban futtatható.

>>> "ja, egy egér pozíciójának lekérdezéséhez is megszakítást kellett meghívni"

Megszakítást csak generálni lehet. Meghívni? Hát, azt nemigen.

>>> "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."

Itt fogható meg a lejobban a szükséges szemlélet hiánya. A gondolkodásodon is lászik, hogy full amatőr vagy. A dolgok nem így működnek az iparban, hanem úgy, hogy ez van, ezt kérik, ezért fizetnek, ezt kell megvalósítani. Ha az egy 250 soros piti számlázó program PC-re, akkor azt, ha egy bare metal fejlesztés valami STM32-re, akkor azt, ha a Voyager III űrszonda oprendszere egy 128 bites akármire, akkor meg azt.

Hogy te otthon mit bohóckodsz magadnak, hogy válogatod meg a hozzávalókat, mit kerülsz ki ennek okán és mit nem, az nem ide tartozik.

>>> "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."

Na, ehhez van a legkevesebb közöd, mégis erről firkálsz a legtöbbet. A komolyabb operációs rendszereknek van olyanjuk, hogy mag és héj (burok). A mag (CORE) végzi az ütemezést és az erőforrás elosztást. De ahhoz, hogy ezt zavartalanul tehesse, szüksége van védelemre, amit a héj hivatott biztosítani. Máskülönben egy rosszindulatú program fejreállíthatná vagy használhatatlanná tehetné az egész rendszert. Mondjuk nem tenne egyebet ez a progi, csak memóriát foglaltatna, annyit, amennyi a gépben talán nincs is. Ha egy ilyen kérés ellenőrizetlenül eljutna a CORE-ig, az elég nagy baj lenne. Az efféle héjak, burkok pedig nem olyan szaharok, mint azt te feltételezed, hanem éppen ellenkezőleg, végletesen ki vannak tesztelve. Legalábbis a kommersziális termékek esetében.

Most nézem csak…

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

És mit oktat? Alapjaiban rossz, vagy legalábbis feleslegesen nyakatekert megközelítést?

Mert ha Pascalban akarom megírni, az inkább néz ki valahogy így első megközelítésre is: [link]

(Ha van benne szintaktikai vagy más kisebb hiba, akkor elnézést, kb. másfél–két évtizede nem programoztam Pascalban.)

Nota bene a megoldásod használja a Power függvényt, amihez ugyanúgy kell az Uses. Vagy meg kell írnod egyet magadnak, amivel ugyanaz a baj, mint amit lentebb taglalni fogok.

Ami viszont nem mindegy:

- A te megoldásod egy ötjegyű szám esetén 50-szer lassabb, mint SysUtils függvénye. (Az enyém csak 2-szer lassabb.) De oké, lehet, hogy az adott helyzetben ennek nincs jelentősége.

- Ha valamilyen okból holnaptól nem elég az integer, hanem longint kell, akkor írhatod át a függvényedet… Ezt, meg még 8 másikat.

- negyedórákat, órákat pazarolsz el arra, hogy megírj valamit, amit mások már megírtak.

- Óhatatlanul fogsz hibázni, nem a legoptimálisabb megoldást fogod megvalósítani, míg mondjuk a Pascal sztenderd unitjaiban az évek során rengeteg hibát fedtek fel és javítottak ki, és szanaszét optimalizálták a kódot.

Tehát lassabban írsz meg egy hosszabb forráskóddal rendelkező és lassabban futó programot, ami potenciálisan több hibával rendelkezik. Mindezt miért? Valamiféle elcseszett és idejétmúlt szemlélet miatt, aminek a követése az égadta világon semmi haszonnal nem jár. (Vagy hát lehet, hogy van az eseteknek az a 0,01%-a, amikor van haszna és indokolt lehet, de ne ebből induljunk már ki.)