Impresszív memóriakezelési fejlesztések érkeztek a ReactOS-be

Lehet kort csinalni es akkor nem kell vegtelen lanc.

Amiről mint lentebb megállapítottad, hogy "Igen es szepen jol korbe fuggnek, aztan ha valamelyik lehal, lehal az egesz.", tehát biztos megéri erőltetni, csak éppen még ez sem igaz, mert nem lehet kört csinálni; gondolj már bele: van egy browsered, ami csak úgy tud böngészni, hogy felcsatlakozik egy szerverre és onnan kéri az adatokat, a szerver pedig felcsatlakozik egy másikra, mert neki is csatlakoznia kell az adatok lekérése végett, a másik meg visszacsatlakozik az elsőre, hogy elérje az adatokat, amiket vissza kell adnia az elsőnek? Ha az elsőnél megvannak az adatok (így működik egy normális szerver), akkor minek a második, ha meg nincsenek, akkor hogy kéri el tőle a második, hogy visszaadja neki? Ami a lényeg, hogy bármilyen elérési struktúrában előbb-vagy-utóbb végponthoz kell, hogy érkezz, különben nem tudsz honnan adatot kinyerni. Sem végtelen láncból, sem körbefüggésből. Valahol, valakinél meg kell, hogy legyen az adat, ha pedig megvan, akkor neki nem kell felcsatlakozni máshoz.

Na varjal, itt most kezdunk ket dolgot nagyon osszemosni. Van az hogy valami most browser, meg van ami kliens-szerver es a ketto nem feltetlenul ugyan az. Ha felcsatlakozol egy IRC szerverre az kliens-szerver, de nem muszaj semmi koze legyen egy webbrowserhez (persze van browserbe futo IRC kliens is, de nem kotelezo). Ugyan igy lehet webbrowserrel csak lokalis fajlokat nezegetni.

Nem volt összemosás, mert nem erről volt szó, hanem arról, hogy "ha ma kezdenek el fejleszteni egy szoftvert, akkor a kliens részét JavaScript-ben (+HTML, CSS) fogják megírni (meg lehet, hogy a szerveroldali részét is JavaScript-ben)." Ez az állítás hamis, mert van olyan szoftver, aminél egyszerűen lehetetlen kliens-szerver módon megoldani. Nem is csinálják így, ez egy lázálom. Az, hogy sok webes applikáció van, az nem jelenti azt, hogy mindent meg lehet így csinálni.

Lehet mindent belerakni egy webbrowserbe, legfeljebb csak feleslegesen nagy lesz az overheadje.

A browsert is bele lehet rakni egy browserbe? Meg a webszervert is? Tényleg futtatok egy browser-kernelt a szerveren, hogy fusson benne a webszerver, ami felcsatlakozik valahova?

A kliens-szerverre, meg barmilyen program kb barmilyen alreszet ki lehet szervezni hogy ne lokalisan fusson, hanem kuldje el egy szervernek majd varja meg az eredmenyt. Nyilvan, ha tulzasba viszed lassu lesz, de ettol meglehet.

Legyszives mondj egy peldat, mert nekem szar a kepzeloerom es nem tudok elkepzelni olyan amit ne lehetne ha nagyon akarod szetbontani kliens-szerver oldalra.

Még hányat? Ebben a posztban is mondtam már példát, meg eddig is. Bármi, ami önmagában szerver, arra nem lehet ráhúzni a kliens-szerver sémát; nincs olyan, hogy egy rendszerben az adatfüggésnek valahol ne legyen végpontja. Komolyan nem érted?

De nyilvan van. Csak te itt erosgeted hogy valamit nem lehet, en meg probalok peldat hozni ra hogy igenis lehet.

Nem, olyat nem lehet, hogy csinálsz egy körbefüggést, ahol a szerverek egymástól kérik le az adatot, ami egyiküknél sincs meg, ezért kell a másiktól elkérni.

Nem kene, de ez nem erdekli azokat a managereket akik azt hiszik hogy ezzel a felhositessel 0.5%-al tobb zse marad a zsebukben.

Akkor máshogy kérdem: ettől lerohad az egész világ? Nem, nem rohad le.

Itt menet kozben elment a beszelgetes afele hogy lehetseges-e, es en arra irom hogy igen. Nyilvan nem fog mindenki felulni a legujabb divatnak.

Én meg azt magyarázom, hogy nem lehetséges. Az állítás az volt, hogy minden szoftver kliens-szerver módon működik, de a szerver maga is szoftver és ha egy felhős környezetben, ahol a kliens semmit nem tárol, a szerverek maguk is kliensek, akkor egy végtelen kapcsolódási láncot fogsz előállítani, ahol nincsen egyetlen végpont sem. Te összekevered az elosztott tárolást a minden is kliens-szerver felállással. Nem, nem lehet minden szoftver kliens-szerver; a szerver az szerver kell, hogy legyen; az, hogy ő kapcsolatot tart más szerverekkel és adatot kér be tőlük, az baromira nem ugyanaz. Rohadtul nem arról beszéltünk, hogy van egy browseres kliens, egy webszerver és egy adatbázisszerver és a browserbe úgy kerül adat, hogy a webszerver az adatbázis szerverből kéri le az adatokat, aztán egy másik formában (HTML) visszaadja a browsernek. Ti arról beszéltetek, hogy minden szoftverre rá lehet húzni azt a felállást, hogy ő egy kliens, ami egy browserben fut és csatlakozik egy webszerverre; hát ha a webszerver és az adatbázisszerver is egy browserben futó kliens, ami csatlakozik valahova, ami szintén...hol lesz az adat? Elvitte a felhőcica?

Hat ha azokat a pontokat ami a C szabvanyban benne van hogy freestanding environment eseten is tamogatnia kell nem tamogatja, akkor nem.

Es igen, ami nem teljesiti a szabvanyt, az nem szabvany C fordito. Ezert szabvagy. Pont. A rendort se fogja ertekelni, ha az autodba nincs tompitott fenyszoro, hogy azon kivul pedig minden pontban megfelel a kresz eloirasainak. (A standard elott meg hivhattak valamit C forditonak, mert akkor meg nem volt szabvany aminek meg kellett felelnie. Utana pedig lehet valami pre-standard C vagy hasonlo cimket raaggatni, ha nem felel meg a standardnak).

Tehát magyarán, ami 1972-ben megszületett, az akkor a C nyelv volt, de most már nem a C nyelv volt, mert a standard miatt már nem lehet C nyelvnek hívni. Ahogy azt sem, ha írok egy egysoros C programot, ami mikrokontrollerre lefordítva beállít egyetlen memóriacímet és nem kell hozzá semmi sem, akkor az sem C nyelvben van írva, hiába abba van írva. Hát ez azért nagyon nem így működik. Egyébként te nem szabvány fordítókról beszéltél, hanem arról, hogy ami nem használ libc-t, az nem C nyelv, mert a libc működését előírja a szabvány. És ez sem igaz.

Ilyet nem mondtam sehol.

Nem mondtad, de az analógiád ezt sugallta, mert rossz volt a hasonlat.

Csak arra akartam utalni, hogy attol hogy valamilyen megvalositas *bizonyos* emberek szamara elfogadhatatlan, nem jelenti azt hogy masok szamara is.

De az, hogy a világ nagyobb fele szarik a security-re, az nem azt jelenti, hogy mindenki.

Vagy hogy ettol megvalosithatatlan lenne.

A szar security? Az megvalósítható. A minden szoftver webes kliens-szerver? Az nem.

Igen, de ha minden programot igy irnak, akkor csinalni fogjak, nem csak elmeleti lehetosegkent csinalhatjak. Az hogy a keretrendszer nem teszi kotelezove az ilyen szempontbol irrelevans. Most is tudsz webre lenyegileg offline appot csinalni.

De nem erről volt szó. Nem az volt a kérdés, hogy lehet-e offline webappot csinálni; az nem is kliens-szerver, de ezt már leírtam fentebb.

Lenyegtelen, elmeleti megvalosithatosagrol beszelunk, nem arrol hogy 100-bol hany donteshozo menne bele.

De elméletben sem megvalósítható. Ha minden szoftver kliens-szerver alapokon működik, akkor a szerver is kliens-szerver alapon működik és neki is szednie kell az adatokat valahonnan, mert ő nem tárol adatokat, mert ő kliens. Nem érted, hogy ha a szerver sem tárol már semmit, ha a szerverből is klienst csinálsz, akkor gyakorlatilag te magad tetted lehetetlenné a minden kliens-szerver felállást, mert hogy lehet minden kliens-szerver felállású, ha a szerver maga is kliens? Hogy lehet szerver-kliens felállást létrehozni egy olyan rendszerben, ahol nincs szerver, mert az is kliens? Tényleg nem érted?

Miert ne? Van mar node.js-ben levo irc szerver, ki kell terjeszteni a browser apikat hogy lehessen szervert csinalni benne es valahogy beleeroszakolni hogy mittomen az eppen belepett userek listajat egy masik webszerveren tarolja es bam.

És az a másik webszerver, ahol az userek listája tárolva van, az is egy browserben futó kliens? Ő hova fog csatlakozni? Egy másik szerverhez, ami megint egy browserben futó kliens? Hol lesz végül az adat? Ha azon a bizonyos webszerveren, akkor az végpont és ő nem kliens-szerver felállású.

Ettol fuggetlenul a GCC az C/C++, a Clang az C++, az MSVC az C++, linuxon a kernel, glibc, musl, binutils, assembler, etc C, az msvc runtime az C++. Attol mert lehet mashogy, meg nem az a jellemzo.

Ez már megint csak a szavakkal való játszadozás. Te tettél egy állítást, hogy így működik, én ezt cáfoltam, hogy nem így működik, max működhet. Az egész érvelésedben ez a hiba, hogy van egy séma, ami N esetben működik, Σ-N esetben meg nem, de te ennek ellenére extrapolálod az egészre és nem veszed észre, hogy egyrészt ez egy hamis összeállítás, másrészt meg egy olyan állítást teszel, amivel rögtön meg is cáfolod az állítást: "minden szoftvert meg lehet írni browserben futó, szerverre kapcsolódó felhős kliensként, a szervert is beleértve", márpedig, ha a szerverek is kliensek, akkor végeredményben sehol sem lesz igazából szerver, tehát nem is létezhet kliens-szerver felállás, mert nincs is szerver, csak további kliensek. És nem, nem az elosztott tárolásról/terhelésről volt szó, hogy a szervereknél csak részadatok vannak és egymás közt kommunikálnak, hanem szó szerint arról, hogy minden szoftver megvalósítható úgy, hogy ő egy csak kliens, ami egy szerverre kell, hogy kapcsolódjon. Nem, így nem lehet az összes szoftvert megvalósítani. A szálindító kolléga azt állította, hogy ma már minden újonnan írt szoftvert így csinálnak, webes kliens-szerver módon (ez még úgy is hamis állítás lenne, ha csak az lett volna az állítás, hogy valamilyen webes technológiával/nyelven csinálják), te meg azóta ezt véded, hogy de, ez lehetséges, de közben az elosztott adattárolásról és szerverközi kommunikációról beszélsz, azt hozod példának, ami távolról sem ekvivalens azzal, amiről szó volt.
És egyben ezért volt gizike-gőzeke hasonlat a C-nyelvben írt C-fordító, mert nem a nyelvi autocompile/self-compile/whatever lehetségessége volt a kérdés, hanem a kliens szerver felállás generikus extrapolációja.

Es abbol mennyi ami tenyleg jelentos es sokan hasznaljak? Az hogy hacker pistike szabadidejeben csinal valamit es felrakja a githubra ahonnan letolti osszesen 2 ember az nem erdekel.

Lényegtelen, hogy mennyien használják, vagy, hogy téged mi érdekel és mi nem. Az, hogy valami neked nem kell, az nem jelenti, hogy másnak sem.

Ha nem valami egzotikus vagy nagyon microcontroller hardverre fejlesztesz, akkor a jelentosebbek a GCC, Clang, MSVC, Intel, talan meg ez a Borlandos csoda... de ezek igazabol mind C++ forditok amik tudnak C-t is.

És mint tudjuk a mikrokontrolleres környezet az manapság leírhatatlanul ritka, senki nem csinál ilyet, tehát, ha van is mondjuk húszféle uC C-compiler, az is irreleváns.
Különben is, a mikrokontrollerek szoftvere is egy kernelbe integrált browserben futtatott kliens, ami felcsatlakozik egy browserben futtatott webszerverre, ami csatlakozik egy másik browserben futtatott webszerverre, ami... Mi is volt a feladat? Két LED-et kapcsolgatni. De most van egy browser-OS-ünk. Mikrokontrollerre. Kötelező szerverkapcsolattal. És még mindig nem tudjuk, hogy - lévén felhőben vagyunk és a kliensek nem tárolnak adatot, a szerverek meg kliensekké változtak a minden szerver-kliens megközelítés miatt - honnan is jön majd az adat, amit a két LED kijelez.
Nem baj, hogy bizonyos szoftvereket már csak a fizikai korlátok miatt sem lehet megvalósítani webes alapokon?