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

"A sebességnél, nem ritkán van fontosabb is."

Mondj pár példát mi fontosabb a sebességnél.

"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." -> Ez igaz volt kb. 50 évvel ezelőtt. Ha ez így van akkor miért van "védett mód" a procosszerban, amikor bőven elég lenne a védelem a shell-ben (burok) ? Na ekkora idiótaságot se hallottam még a szakmában. Nem te fejlesztetted véletlenül azt a rendszert ahol a védelem teljesen kliens oldalon volt és csak egy picit megváltoztatott html kóddal egészen sok mindent meg lehetett csinálni? Mert ez a szemlélet amit leírtál pontosan azt eredményezi.

" 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." -> Ld. pl. a Windows esetén ahol olyan jól sikerül ez a tesztelés, hogy állandóan jönnek a frissítések, és rendszeresen vannak lokál és remote sebezhetőségek. Elképesztő idióta vagy.

“ Te csak egy sz@rszagú outsider vagy.”

Mert te milyen karriert futottál be fejlesztőként ami miatt azt hiszed, hogy jogod van ennyire lekezelően beszélni itt mindenkivel aki nem ért veled egyet?

#66

Hát, hol is kezdjem? Tényleg azt gondolod, hogy a programozás egy egyszerű kis játék, amit bárki csak úgy meg tud tanulni? Hát, nézd, az igazi programozók, akiket elismerek, tudják, mennyi munka, tudás és szenvedély szükséges ahhoz, hogy valóban értsenek a kód írásához! A programozás nem csupán egy hobbi; ez egy életstílus. Az, hogy te beszólsz, mintha csak azt mondanád, hogy a zene nem több, mint néhány hangjegy a kottán. A programozás logikája, a problémamegoldás művészete, a kreativitás és a kihívások – mindezek olyan dolgok, amelyeket csak azok értékelnek, akik valóban belemerültek ebbe a világba. Tudod, hány órát töltöttem el a bugok keresésével, a kód optimalizálásával és az algoritmusok megértésével? Minden egyes apró részlet, amit a programozás nyújt, a tudásom és a tapasztalatom tükre. Szóval, amikor valaki lenézi ezt a szakmát, az számomra olyan, mint amikor valaki csak úgy eldob egy gyönyörűen megírt regényt, mert nem tetszik neki a címe. Ha tiszteletlenül beszélsz a programozásról, akkor nemcsak a szakmát sérted meg, hanem azt a közösséget is, amely évek óta dolgozik azon, hogy a technológia fejlődjön és a világot jobbá tegye. Szóval, ahelyett, hogy beszólsz, talán érdemes lenne egy kicsit mélyebbre ásni, és megismerni, miért is vagyunk annyira szenvedélyesek ezzel a területtel kapcsolatban!

Összességében, ha nem érted a programozás szépségét és erejét, talán érdemes lenne inkább megismerkedni vele, mintsem lenézni. A programozás világa tele van lehetőségekkel – csak nyisd ki a szemed, és merülj el benne! Hát, ez már tényleg túlmegy a határon! Először is, hadd mondjam el, hogy a "védett mód" nem véletlenül létezik az x86 architektúrákban. Az, hogy te csak a "burok" szintjén nézed a dolgokat, sajnos azt mutatja, hogy nincs tisztában a rendszer mélyebb működésével. A védett mód nem csupán egy díszítő elem, hanem egy kulcsfontosságú biztonsági mechanizmus, amely lehetővé teszi a modern operációs rendszerek számára, hogy hatékonyan kezeljék a memóriahozzáférést és megakadályozzák a processzek közötti interferenciát. Ha ez nem lenne így, akkor a rendszerek stabilitása és biztonsága drámaian csökkenne. Ha azt hiszed, hogy az x86 processzorok védett módjának védelmi lehetőségei "pocsékak", akkor talán érdemes lenne jobban megérteni, hogyan is működnek ezek a mechanizmusok a gyakorlatban. A memóriavédelem és a taskkezelés nem csak úgy "megírható" a felhasználói szinten. Az operációs rendszerek, mint például a Linux vagy a Windows, rengeteg bonyolult mechanizmust használnak, hogy biztosítsák a biztonságot és a hatékonyságot.

Szóval, ha te csak egy "sz@rszagú outsider" vagy, aki nem érti a védett mód valódi jelentőségét, talán ideje lenne kicsit jobban belemerülni a programozás világába. Ahelyett, hogy lenézed a rendszert, próbálj meg tanulni belőle! Az elitista programozók nem csak a kódot írják, hanem értik is, miért működik úgy, ahogy. Ébresztő!

Az x86 védett módjának sok képességét a modern operációs rendszerek fejlesztői valóban nem használják ki teljes mértékben, mert ezek közül néhány a mai számítástechnikai környezetben vagy elavult, vagy korlátozott rugalmasságot biztosít a szoftveres megoldásokhoz képest. Az alábbiakban részletezem, hogy miért:

1. A Szegmentált Memóriamodell Elavultsága

Az x86 védett mód szegmentált memóriamodellt használ, amelyben a memória több szegmensre oszlik. A 32 és 64 bites operációs rendszerek fejlesztői azonban inkább az egyszerűbb lineáris címzést részesítik előnyben, ahol a memória egy egybefüggő címterületként kezelhető.

A szegmentált memória komplexitása miatt a fejlesztők általában minimalizálják a szegmensek használatát. Ehelyett a 64 bites mód (long mode) elterjedésével a lapozott, lap-alapú memóriakezelést alkalmazzák, ahol a címterek teljesen lineárisak, és jobban megfelelnek a mai alkalmazásoknak.

2. Többgyűrűs Privilegiumszintek (rings) Kihasználatlansága

Az x86 védett mód négy privilegiumszintet biztosít (Ring 0-tól Ring 3-ig), de a legtöbb modern operációs rendszer csak a Ring 0 (kernel) és Ring 3 (felhasználói) szinteket használja.

Az egyéb gyűrűk kihasználása bonyolultabb rendszert eredményezne, és a legtöbb operációs rendszer számára nincs szükség ekkora granularitásra. Az alkalmazások egyszerűbben és gyorsabban működnek, ha egy tiszta felhasználói-kernel elválasztás van, ami a két gyűrűvel is megoldható.

3. Hardveres Multitasking (Task State Segment) Mellőzése

Az x86 hardveres támogatást biztosít a multitaskinghoz a Task State Segment (TSS) segítségével, amely tárolja az egyes feladatok állapotát és segít a folyamatváltások kezelésében.

Azonban a legtöbb modern operációs rendszer (pl. Windows, Linux) szoftveres folyamatkezelést használ, mert ez nagyobb rugalmasságot biztosít az ütemezésben és a folyamatok kezelésében. A hardveres multitasking lassabb és kevésbé rugalmas, mint a szoftveres megoldások, különösen nagy rendszereken.

4. Virtualizáció és Modern Biztonsági Funkciók

A mai számítástechnikai környezetben a virtualizáció alapvető szerepet játszik, és az x86 hardveres támogatást nyújt hozzá (Intel VT-x, AMD-V), ami egyfajta „védett mód a védett módon belül.”

Az operációs rendszerek fejlesztői azonban gyakran kombinálják ezt saját virtualizációs megoldásaikkal (például Hyper-V, KVM), hogy nagyobb rugalmasságot érjenek el, és mivel a hardveres támogatás néha nem biztosít minden biztonsági funkciót. A hypervisor (virtualizációs réteg) például még magasabb szintű hozzáférést kap a védett mód alatt, és ezt sok rendszer közvetlenül kihasználja.

5. Teljesítmény és Optimalizáció

A hardveres védett mód bizonyos funkciói, mint például a szegmentált memóriamodell és a hardveres multitasking, nem elég gyorsak és optimalizáltak a modern igények kielégítésére.

______________A szoftveres megoldások jobban skálázhatók, és a modern operációs rendszerek fejlesztői gyakran inkább ezek mellett döntenek, hogy jobban kihasználják a processzor teljesítményét és optimalizálják az erőforrás-kezelést.___________

> A szabványosításnál sem volt szempont semmiféle hordozhatóság.

„Software developers writing in C are encouraged to conform to the standards, as doing so helps portability between compilers.” ( [link] )

> Ha kell ilyen, elég ha írsz egy olyan programot, ami nagy.

Volt kb. 10 év a történelemben, mikor már volt 64 kB-nál több RAM is a gépben, és még nem volt teljesen általános az, hogy az operációs rendszer védett módban fut. Akkor volt tétje az egész témakörnek, és ott voltak a nyakatekert szükséges rossz kényszermegoldások. De ez 30 éve volt.

40+n éve leírtam, hogy malloc(8192), és fordítottam belőle egy DOS-os programot, ami valós módban fut és nem is volt szükségem több memóriára az adott feladathoz. Ma egy programozó leírja, hogy malloc(16777216), és lefordít egy 64 bites, long módban futó Windowsra egy programot. Ugyanúgy egy egybefüggőnek tűnő memóriát kapunk, amit ugyanúgy kell kezelni, csak a méretek lettek mások. Hogy aztán mi van a motorháztető alatt? Az már tulajdonképpen egy más területre specializálódott kolléga dolga.

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

Megszakítást csak kérni lehet. Generálni? Hát, azt nemigen.

De mindegy, a legutóbb 25–30 éve *hívtam* meg megszakítás kérésére irányuló utasítást.

> Az efféle héjak, burkok pedig nem olyan szaharok, mint azt te feltételezed, hanem éppen ellenkezőleg, végletesen ki vannak tesztelve.

Ennyire nem lehet gyenge a szövegértésed. Nem azt mondtam, hogy az operációs rendszer esetén a rendszermag és a rendszerhéj rosszul van megírva, hanem azt, hogy nem a szétválasztástól lesz jól megírt, hanem attól lesz jól megírt, hogy jól írják meg. Egy API nem attól lesz biztonságos, hogy API, hanem attól, hogy biztonságosra írják meg.

„Egy nyilvános API segítségével lehetséges egy programrendszer szolgáltatásait használni anélkül, hogy annak belső működését ismerni kellene.” Lásd: [link]

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

A 80-s, meg talán még a 90-es években még lehetett talán elvárás, hogy egy programozó mindenhez értsen. Mára az informatika annyira szerteágazó terület lett, hogy szükséges specializálódni (ahogy úgy általában az ipar minden területén). Aki mindenhez ért, az semmihez sem ért. Persze kell valamiféle alaptudás az egésszel kapcsolatban, de vannak szakterületek, amihez önmagában kell elmélyültség és tapasztalat. Egy számlázó program ma aligha 250 soros, mert alapvető elvárás, hogy legyen benne egy API, amin keresztül a webshop automatikusan tud számlát generálni, hogy a NAV-nak adatot szolgáltasson, hogy mobiltelefonról is tudj számlát készíteni, hogy deviza számlát az MNB-től automatikusan lekért középárfolyamon számoljon el stb. stb… Ha te mikrokontrollert programozol évekig, amellett nem nagyon fogod tudni követni a OpenGL, a Docker, a .NET, a CSS 3, a HTTP/3 meg a MySQL meg az iOS, meg 7945 másik nyelv, rendszer, miegymás újdonságait úgy, hogy készség szinten tudd használni is.

A szoftverekkel szemben támasztott elvárások, meg a fejlesztés költségeivel szembeni elvárások (pl. fejlesztési idő) megnőttek, bizonyos dolgokat csak csapatmunkában észszerű csinálni, ehhez kialakulnak mindenféle komplex módszertanok, eszközök. Az általad nem túl nagyra becsült webfejlesztés is azért vált ketté frontend és backend ágra, mert önmagukban akkora ismertet, tapasztalatot igényelnek, ami egy embertől már nehezen volt elvárható, és amibe évek alatt jutsz el addig, hogy tapasztaltnak mondhatod magad és nem kezdőnek.

Frontendes vagy? Akkor nyilván ismered a HTML-t de úgy mélyrehatóbban, ismered a legújabb CSS feature-okat és hogy melyik böngésző mit támogat és milyen megszorításokkal, ismered a CSS preprocesszorokat, keretrendszereket (Sass, Bootstrap, Tailwind), nyilván vágod a Javascript mindenféle nyalánkságait, a JQuery-t, meg persze az olyan keretrendszereket, mint a Vue, React, Angular, és nyilván értesz a Wordpresshez. Meg tudod használni a Git-et, a különböző build eszközöket (Webpack, Vite), a template engine-ekhez, értesz a reszponzív tervezéshez, az akadálymentesítéshez, a keresőoptimalizáláshoz, az UI és UX módszertanokhoz, a tipográfiához, a Google Analyticshez, a teljesítményoptimalizáláshoz (Lazy loing, tree sharking), a progressív webalkalmazásokhoz, a biztonsághoz (XSS, CSRF stb…), a websockethez, a különböző tervezési eszközökhöz… Ja meg a GDPR-hoz, meg hasonlókhoz, már nem is szakmai, de mégiscsak érintett területekhez is.

A fenéket értesz, mert ez is más kezd specializálódni. Ha valaki Angularban nyomja profin, akkor aligha fog kapásból bekapcsolódni egy React alapú fejlesztésbe, és mire megtanulja, megszokja, az Angulart kellene újra felelevenítenie, megtanulni az újdonságait olyan szinten, amilyen szinten csak úgy lehet, ha aktívan használod.

Persze a mikrokontroller programozási tudással is nekikezdhetsz, hogy csinálsz egyedül némi HTML-t, alapszintű CSS-sel, meg Vanilla Javascripttel, meg szerver oldalon némi PHP scripttel, mire összedobsz egy szimpla fórumot, addigra egy 3 fős csapat már lefejlesztett egy komplett webshopot. Pláne nem fogsz beszállni egy olyan csapatba és ott hatékony munkát végezni, akik használják azokat a keretrendszereket, eszközöket, amiket pont a hatékonyság és a komplexitás hívott életre.

Ha ma valaki Java fejlesztő, akkor nem kérik tőle, hogy írjon egy hardverhez Linux drivert. Az egy másik szakma, amihez egy másik, más tudású szakember kell.

Ez olyan, hogy régen volt olyan szakma, hogy ezermester. Aztán lett olyan szakma, hogy háztartási gép szerelő. Aztán lett olyan szakma, hogy mosógépszerelő. Mert a mosógépek is olyan bonyolulttá váltak, hogy külön szakmává nőtte ki magát, ahol nem az a tudás, hogy tudod használni a csavarhúzót és a menetvágót, hanem az, hogy tudod, hogy a Whirlpool adott szériájának mik a tipikus hibái, vagy tudod, hogy az Electrolux X típusú mosógép vezérlő elektronikája kompatibilis az Y típuséval, és mindezt hol tudod beszerezni.

Vagy attól, hogy mindkettő orvos, egy kórházban nem kérik meg az urológust, hogy szemműtétet hajtson végre. Az egy másik specializáció, teljesen más tudást, ismeretet, meg tapasztalatot igényel.

> Tényleg azt gondolod, hogy a programozás egy egyszerű kis játék, amit bárki csak úgy meg tud tanulni? Hát, nézd, az igazi programozók, akiket elismerek, tudják, mennyi munka, tudás és szenvedély szükséges ahhoz, hogy valóban értsenek a kód írásához! A programozás nem csupán egy hobbi; ez egy életstílus.

Pont erről van szó. Mennyi egy egyetemi alapképzés? 3–5 év, amiből nettó 1 év elmegy mindenféle soha többet nem használt, vagy nem a szaktudáshoz hozzájáruló tudás átadásával? Pistike lehet, hogy 10 éves korától programozgat és mohó kíváncsisággal falja a tudást. Tényleg az egyetem fog belőle szakembert faragni? Pl. volt egy tantárgyunk, amihez kb. a jegyzet az Andrew S. Tanenbaum és által írt David J. Wetherall Számítógép-hálózatok című könyv volt. Miből gondoljuk, hogy ez a könyv csak egyetemi oktatásban érhető el, és a benne leírtak csak egyetemi oktatással sajátíthatók el? Ott a könyvesbolt vagy a könyvtár. Mi ér többet? Ha Aladár felveszi az egyetemen az adott tantárgyat, mert kötelező, különösebben nem is érdekli ez a téma, és épphogy levizsgázik belőle. Vagy az ér-e többet, hogy Béla önszántából veszi meg és olvassa el a könyvet háromszor, mert annyira érdekli a téma?

Egy egyetemen tankönyvekből, jegyzetekből tanulsz, meg előadásokból. Könyvet lehet venni a könyvesboltba, a net meg tele van előadásokkal. Az a tudás, amit az egyetem abban a 3–5 évben ad, az a tudás elsajátítható máshogy is. Persze meglesz a veszélye, hogy esetleg bizonyos dolgok rosszul rögzülnek, vagy a tudás valamilyen szempontokból hiányos lesz, de egy egyetemi képzés sem garancia arra, hogy valaki a diplomaosztó után is tudja és jól tudja azt, amit elvileg tanítottak.

Akiben nincs meg a tűz, a lelkesedés, az egyetem ide vagy oda, úgysem marad a szakmában. Akiben meg megvan a lelkesedés, rajongás, az meg el tudja sajátítani maga is azt, amit szükségesnek lát az adott területhez, legyen az kernelmodul írás, vagy Android alkalmazásfejlesztés. Már csak azért is, mert előbb lesz bárminek is megalkotója, aztán használója, tudója, mire végül megjelenik az oktatásban is. Ami ma újdonság, arról ma tudsz olvasni. Mire az bekerül a tantervbe, a jegyzetbe, addig eltelik legalább 2 év, és már lehet, hogy elavult lesz.

Az egyetemi képzés pár éve arra jó, hogy mindenbe belekóstoltat, de semmiben nem fog tudni elmélyíteni. Az egyetem után mindenről felszínes, kezdő szintű ismereteid lesznek, ha nincs előtörténeted, meg önmagadtól nem mélyedsz el valamiben.

Igen, egy bootcamp önmagában semmit nem ér. Annyit sem, mint az egyetem. De legalább célirányosan képez egy adott területre, amihez ha van alapod – akár autodidakta módon szerzett alapod –, van lelkesedésed, meg megszerzed utána a tapasztalatot is, akkor működhet. (Nota bene egy bootcamp tökéletes eszköz arra is, hogy egy amúgy programozó diplomával rendelkező ember továbbképezze magát, vagy visszatérjen a szakmába, ha ilyen-olyan okokból más pályán kezdett el dolgozni, és kijött a gyakorlatból.)