22
-
kvp #22 "Naná, hogy message passing, máshogy nem is lehet."
Lehet, meghozza parameterekkel. Pont errol szol a publikalt anyaguk.
"Elárulom neked, hogy még a valós módú BIOS is message passing technikát használ"
Megint sikerult osszekeverni az interface-t a technologiaval. Az, hogy egy fuggveny strukturaban adja es kapja az adatokat, attol a rendszer meg nem hasznal uzenet alapu kommunikaciot. Ennek ismerve ugyanis a kuldes es fogadas, tovabba legtobb esetben az uznenet kuldesi/fogadasi listak meglete (message queues). Lokalis esetben sem mindig eleg mutatot atadni, mert eltero folyamatok kozott ez nem mukodik mindig. A lehetseges megoldasok ilyenkor vagy a masolas vagy az osztott memoria. A legtobb mai cluster rendszer osztott memoriaval probalkozik, mig ok inkabb masoljak az uzneteket, mivel igy implicit helyett explicit a kommunikacio, ami sokkal hatekonyabb es nem igenyel kulonosebb hardver tamogatast. A windows mar nagyon regen leszokott arrol, hogy lassak egymast a programok (a win32 ota), ezert a gdi uzneteket valojaban mar masolja a folyamatok kozott, csak mint latszik meg a programozok jo resze sem latja at hogyan mukodik. (pedig eleg egyszeru)
ps: Szerintem vita helyett mindeki olvassa el a minix es az amoeba os-ek idevonatkozo reszeit. Tanenbaum mar 20 eve leirta mirol van szo es pont diakok szamara, hogy erheto is legyen. A szempontok: osztott memoria vagy masolas / gepen belul vagy halozaton keresztul / architekturafuggo modon vagy atlalanos formatumban es ezek barmelyik kombinaciojara letezik gyakorlati pelda. -
Turdus #21 "Mindharom altalam emlitett megoldas message passing technologiat hasznal. Az, hogy egy uzenet a lokalis gepen belul vagy halozaton keresztul kerul atvitelre nem igazan szamit, amig mindket fel kepes kezelni az adott uzenetet. A peldak ilyen megoldasok, mind lokalis (windows), mind tavoli (x) hasznalatra."
Naná, hogy message passing, máshogy nem is lehet. Elárulom neked, hogy még a valós módú BIOS is message passing technikát használ (tipikus példa). Itt a tévedésed az, hogy "halozaton keresztul kerul atvitelre nem igazan szamit", mert igenis nagyon számít. Hogy csak egy példát említsek, local-ban általában elég egy pointer-t továbbadni (by reference), míg hálózaton keresztül az egész adatot mozgatni kell (by value). Alapvető különbség. -
Turdus #20 Én 10.4 alatt kipróbáltam Intel platformon, és bizony nem ablakban futott az. Ha ablakban akartad futtatni, ahhoz kellett (volna) venni paralell-t.
-
kvp #19 "kvp: "A jo hir, hogy a windows kernelek mar nagyon regen igy mukodnek, foleg a gdi es a device driver reteg, de unix-okon is ott van peldanak az x szerver es meg sok mar rendszerkomponens"
A winfos kernelek sosem működtek így. A device driver réteg főként nem, eleve mert nem sok teteje lenne másik gépnek küldeni a driver parancsot. Az X11 szerver szintén nem ilyen, semmi köze a clusterhez. Tessék jobban utánnaolvasni."
Mindharom altalam emlitett megoldas message passing technologiat hasznal. Az, hogy egy uzenet a lokalis gepen belul vagy halozaton keresztul kerul atvitelre nem igazan szamit, amig mindket fel kepes kezelni az adott uzenetet. A peldak ilyen megoldasok, mind lokalis (windows), mind tavoli (x) hasznalatra.
"Áruld már el nekem, hogy az hogy a fenébe lehetséges, hogy te minden egyes hírhez tudsz egy összegző kommentet írni, amiben elárulod, hogy ezt vagy azt már x éve kitalálták, ez és az volt az elődje, és ezt meg azt lehetne jobban csinálni."
Hobbi. Egyszeruen erdekelnek a regi technikai megoldasok, neha nagyon erdekes megoldasokat felejt el, majd fedez fel ujra a vilag. Egyebkent meg szeretek ilyen 'retro' rendszereket barkacsolni. Pl. nem sok ember csinal manapsag diszkret logikai ic-kbol sajat szamitogepet, pedig erdekes feladat es szvsz. jo szorakozas. Foleg ha vegul egy sajat fejlesztesu aramkorrel vezerlunk egy hazilag barkacsolt robotot.
"Arra már ki sem térek, hogy legtöbbször olyan ótvar tárgyi hibákkal, hogy rossz nézni."
Kitertel. Viszont a gond csak az, hogy a legtobb esetben nem esik le nehany embernek mirol beszelek. Pl. a windows driver retegeben a legtobben csak a fuggvenyhivasos api-t latjak, de az alatta levo i/o request packet-eket nem, pedig a ddk-ban le van irva a mukodesuk. Hasonlo az x esete, a legtobb mai linux guru nem tudja, hogy a technologiat eredetileg tavoli eleresre talalktak ki, nem lokalis hasznalatra. Igy lehet pl. egy geprol tobb eltero gephez tartozo monitorra csatlakozni, vagy egy a monitorhoz tartozo gepre tobb masik gep programjainak az ablakait behozni. Mindezt tcp/ip-n megvalositott message passing kommunikacioval. Az emlitett project pont ezt valositja meg x+1-edszer. Ezert lehet pl. egy x-es programmal elerni egy windows-os gep desktopjat es az ablakot arra kipakolni, ugy, hogy a programkod egy resze a window-os, egy resze a unix alapu gepen fut.
"Akarom a microsoft Doors-t"
Nem fog menni, a doors technologiat mar a sun solaris hasznalja jo ideje es ha jol tudom levedettek a nevet. -
#17
Hogy lehetséges ez? hát te nem tudod? ;D
Ismered a mondást, hogy a mókus tulajdonképpen egy patkány jó marketinggel.
Ha majd legközelebb hozzászólsz, mond azt, hogy te is k*vára tudod;) -
#16
Milyen cikk ez? Miért nincs egy kép vagy egy screenshot róla? -
Ulkesh #15 " tévedés, nincs benne MacOS9 emulátor. Nem ablakban futtatja az OSX, hanem önálló rendszerként (azaz nem tudsz reboot nélkül átváltani rá meg vissza)"
Az OSX a 10.4-es változatig tartalmazta az OS9-et és biza ablakban tudta az emulációs módban futtatni.
A mai rendszerek, főleg az intel platform miatt már nyomokban sem tartalmazzák az OS9-es környezetet. -
WoodrowWilson #14 Áruld már el nekem, hogy az hogy a fenébe lehetséges, hogy te minden egyes hírhez tudsz egy összegző kommentet írni, amiben elárulod, hogy ezt vagy azt már x éve kitalálták, ez és az volt az elődje, és ezt meg azt lehetne jobban csinálni.
Arra már ki sem térek, hogy legtöbbször olyan ótvar tárgyi hibákkal, hogy rossz nézni. -
#13
WinDos! jee...
Szerintem az egész felhasználói felületet újra kéne tervezni, mert néhol túl van bonyolítva, vagy már unalmas. :D -
Utokverek #12 Éljen!
Akarom a microsoft Doors-t ;) -
Turdus #11 cikkírónak: a Singularity és a Midori egy és ugyanaz, csak másik fejlesztési fázis.
NullZ3r0: tévedés, nincs benne MacOS9 emulátor. Nem ablakban futtatja az OSX, hanem önálló rendszerként (azaz nem tudsz reboot nélkül átváltani rá meg vissza)
kvp: "A jo hir, hogy a windows kernelek mar nagyon regen igy mukodnek, foleg a gdi es a device driver reteg, de unix-okon is ott van peldanak az x szerver es meg sok mar rendszerkomponens"
A winfos kernelek sosem működtek így. A device driver réteg főként nem, eleve mert nem sok teteje lenne másik gépnek küldeni a driver parancsot. Az X11 szerver szintén nem ilyen, semmi köze a clusterhez. Tessék jobban utánnaolvasni. -
Szefmester #10 Marketinszöveg: "windows retro, ugyanaz mint a win95 csak most kevesebb fagyással..." -
djw #9 a divatvilagban is ismetlodnek a dolgok ;) retronak hivjak, amikor elolrol indul a ciklus :) lehet, hogy nem is Windows 8 lesz a neve, hanem Windows Retro :D -
kvp #8 Megneztem mi ez a barrelfish. Gyakorlatilag egy operacios rendszer fuggetlen uzenetkuldesre alapozott cluster technologia. Ezt mar kozel 40 eve feltalaltak, meg valamikor a xerox alto-k idejeben. A legutobbi ket kutatasi celu megvalositasa a minix es az amoeba voltak, azok is jo 20 eve. Ezek szerint 20 evente mindig kitalalja valaki ugyanazt. A jo hir, hogy a windows kernelek mar nagyon regen igy mukodnek, foleg a gdi es a device driver reteg, de unix-okon is ott van peldanak az x szerver es meg sok mar rendszerkomponens. Hatalmas ujitas, de legalabb paran csinalhatnak belole phd-t es felnevelhetik a gyerekeiket. -
Szefmester #7 használnom is kell bőven.. -
#6
hát már most is a win7-ben is van egy win9x emulátor, egy x86-32 emulátor (a 64bitesben), egy xp emulátor... -
putyi #5 ez a legjobb összefoglalás -
NullZ3r0 #4 Tuti lesz benne Windows emulátor, mint a Mac OS X-ben a Mac OS 9 emulátor.
Amúgy attól tartok, a magjától eltekintve egy újabb Windows lesz, ugyanazzal a kinézettel, ugyanazokkal a felhasználói felület hibákkal és idegesítő mindent-jobban-tudással. -
Szefmester #3 mert microsoft...
kezdésnek kell a Midori hogy kihasználd a több magos procid, azon emulálod az AzureOS-t ha már van virtualizáció, mert kevés lesz neki a többmagos proci, és a nagy számítási felhőben pedig futtatod majd a Singularityt hogy ne omoljon össze mad a win7 emulátor mert programokat is akarsz használni, és az újak nem lesznek kompatibilisek :P
sztem.. :D -
#2
"Singularity a megbízhatóságra, a Midori a biztonságra és a párhuzamos feladatokra, az Azure OS pedig a számítási felhőkre alapozta újszerűségét"
ezeket miért nem lehet ötvözni, ha az alapoktól újra írják az egész rendszert? -
#1
Kb. 1 év múlva jön a hír: A Windows 7 is kihagyható :-D